Then, as noted in the article, you're trying to prove a negative to someone who doesn't really care at all, which is borderline impossible.
Automated abuse reports of things that are easily spoofed don't justify a report, but might justify a quick check to make sure your box is still operating correctly and hasn't been taken over.
That's the important part.
If they receive another one (or two, or a few) more abuse reports, they assume it is not fixed, and will expect a response then. Which ends up being annoying.
The legitimate answer would include some sort of real-world attestation about you from a trusted third party. Probably the very least, some evidence of your identity and jurisdiction. Maybe including a video call or something. Not just you anonymously claiming you're a good guy over the internet and expecting to be believed.
If there is technology and established protocols to prevent spoofing, but some ISPs refuse to follow these protocols, why should it be your burden to prove it wasn’t you?
Is it reasonable to allow people to get credit cards with your SSN, when it’s physically possible to confirm their identity when they present your SSN, but the bank is too lazy to do it, and we put it on you to show up and cancel the credit cards? And of course present 3rd party attestation that it wasn’t you who did this. Maybe even bring an alibi?
I hope I misunderstood your comment.
It's annoying to find someone (or some service) that is willing to attest on your behalf and have that person (or service) be trusted by your provider more than whoever filed the abuse complaint.
>Maybe including a video call or something.
It's annoying to find someone at your provider who will take the time to do this. It's annoying to take my time to have to do this.
My point, overall, was that this is just a really annoying problem.
Nice try Winnie Poo
Same with spoofed MAC addresses, email addresses, ARP messages, Neighbor Discovery, MitM TLS certificates ... It's amazing anything works anymore :D
I'm not sure how often this happens in practice but tracing the source of a spoofed packet is possible if you can coordinate with transit providers to follow the hops back to the source. One time JPMorgan worked with Cogent to tell us to stop sending packets with their IP addresses (Cogent is one of the most spoofer friendly tier 1's on the internet btw).
This is the first time I've heard of this being used to target TOR specifically which seems counterintuitive, you would think people sending out spoofed packets would be advocates of TOR. Probably just a troll, luckily providers that host TOR won't care about this type of thing.
> Probably just a troll
Or someone wanting TOR to be treated like nuclear waste, because it offends their surveillance ops.
So, I can assure you this is quite common. As a personal note, I know I’m a bit of an exception for operating multiple IP addresses, but I need the flexibility to send packets with any of my source addresses through any of my ISPs. That’s critical for me, and if an ISP filters based on source, it’s a deal-breaker—I’ll switch to a different ISP.
What would it take to get enough network providers to start rejecting traffic from all ASes that don't implement this, so that spoofing was no longer possible?
It's much easier to work on reducing reflection multipliers though, because you can scan (ipv4 anyway) for reflection vectors and yell at people that will respond with 10x the input bytes.
I suppose a difference is that they use unaffiliated parties to send the complaint, instead of contacting the authority directly.
I've had my main server thrown offline by a bogus abuse report claiming that they received an over 1Gbps DoS attack from my IP even though my server only has a 400 Mbps cap. Had a human actually read the report, they would've seen it was impossible and wouldn't have had to spend 2 days arguing with phone support on my holiday.
To me, the worst part is that "Watchdog Cyber Defense," Spamhaus, Shadowserver, or some wannabe extortion artist like UCEPROTECT can submit millions of automated reports that hosts are de facto required to listen to lest their IP space be blacklisted.
At the end of the day, the internet is people.
Just acquire a few boxes that don’t block spoofing outbound SYN packets and start spamming random IP’s from random IP’s with SYN packets.
It will generate a shitload of abuse emails and accomplish mostly nothing except fill up disk space with useless emails and such.
in the end, we had a load-balancer at .1 balancing a bunch of backend servers.
the complainer would have traffic to .1 that the load balancer would receive. Thing is, old or stale connections would drop out of the load balancer mapping table, and eventually the backend server connection would not get mapped, and the guy would get traffic direct from the backend server real ip address.
the traffic was actually generated by the customer, but these "unrelated" backend servers looked like they were hacking him.
They have posted several screenshots of discussions among people affected on various channels, including Mastodon and the official #tor-relays channel on IRC.
That isn't an argument for not improving things though, just a warning against perfection, if you chase it then you're liable to make really big mistakes that ruin everything.
You're not copying the MAC of someone else on the network.
Now as far as every other mail operator setting up their stuff right such that From spoofing is no longer feasible, well... Can't help ya there. I don't run my email to make money, so the incentive to adopt pathological configs for the sake of maximizing the number of users/Domains who can send from one IP ain't there.
If you actually have your own IP addresses this is normal and expected, but if you're able to use ISP A's IP addresses through ISP B or vice versa that has always been a bug that you are wrong to use.
If you are doing the latter this is firmly in the "reenable spacebar heating" category and I hope your ISPs fix their broken networks.
for those that need more context regarding the "reenable spacebar heating" comment
I worked at a company that hosted some web assets on-prem in one of their branches. They had a 1Gbps connection there. However, at HQ, we had multiple 10G connections and a pretty good data center. So, we moved the web VM to HQ but kept the assigned IP address (a public static from ISP-A). We routed it through a VPN to HQ. The server used our default GW and sent responses with source IP (ISP-A) via ISP-B (10G).
That way, we utilized 10G outbound, even though the inbound was limited to 1G. It was only for GET requests anyway. I know this wasn’t the most optimal setup, and we eventually changed the IP, but it seems like a valid use case.
Scenario 2: We had two connections from two different ISPs (our own ASN, our own /23 addresses). We wanted to load balance some traffic and sent half of our IPs through ISP-A and the other half through ISP-B. It worked fine, but when we tried to mix the balance a bit, we found an interesting glitch. We announced the first /24 to ISP-A and the second /24 to ISP-B, but ISP-A had RP filtering. So, we had to announce all the IPs to them.
The way the RP filter works, as you may guess, means we cannot prepend or anything. All traffic must come through them. If they see a better route for that prefix, they will filter it. For a few months, they refused to fix this, citing security. There’s no shame in security best practices, so I might as well name the ISP—Virgin Media.
Note that the internet with rp_filter is not $20/month. It was more like 5K+/month!! And we did not change it due to lack of alternatives there. But otherwise guess who loses the contract :)
I don't think your cases are good enough to allow anyone to spoof by default.
>As a personal note, I know I’m a bit of an exception ...That’s critical for me, and if an ISP filters based on source, it’s a deal-breaker—I’ll switch to a different ISP.
"Of course, Agent Bond."
As someone who always enables rp_filter everywhere... I'm very curious why?
I mean, technically those ISPs would be in violation too. You need your own ASN.
don't we want source based filtering tho? sounds like the problem is a LACK of source based filtering.
Turns out, most multiphomed IPv6 users need provider indepdent addresses, just like with IPv4. And then you need to make sure your all your ISPs allow you to use all your prefixes. On the plus side, it's much more likely to get an IPv6 allocation that's contiguous and that you won't outgrow; so probably you only need one v6 prefix, and you may not need to change it as often as with v4.
And they also said that it should work that way - just announce it somehow and it will work. Yes but no. It does not work.
I got hired into a pretty old small technology company that has over a decade of tech debt, and "how the whole system works" is different depending on which engineer you're talking to. You have to do a context shift to a different engineering reality just to do basic improvements to the system. Lots and lots of built up confusion over years of incremental changes, some of which under pressure no doubt, some well intentioned half-refactors, some almost dead code...imagine your well established corporate morass and then give it a shoestring budget.
It's scrappy in its own way, but the threads where people advocate "don't worry about the tech debt, if the company succeeds they will have the budget to fix it" don't account for the middle ground of not having huge success but having enough success to continue indefinitely. I guess that could mean you could fix the problem over longer time spans, but people do t stay at orgs like this long enough for that to happen, because the job of fixing it is no fun and you can't just throw huge amounts of money at the problem.
Unfortunately many people seem to think otherwise and will spaff abuse reports over an errant SYN packet
Isn't this precisely the role filled by notaries?
It's annoying to find a notary and pay for their services to attest that I'm not doing something.
I think even the cheapest 100bucks business plans from many ISPs come with /28 or /29. It is a complete waste because we had like 10 offices with 3-5 persons with laptops and NO servers. The common question from the ISPs is: Do you need some IPs? When we answer no, they give us /29.
Then have ULA addresses for internal network. Those will be routed with tunnels and VPNs. That separates accessing the internet from internal network, and means that don't need to have routable address space.
The only people who would need own address space have data centers and routers.
Except that ULAs don't really work. They are less prioritized than GUAs.
There has to be some ability to establish baseline trust.
Honest question as someone that is definitely not a networking expert.
In the abstract: if I own the infrastructure and someone uses that infrastructure to hurt someone, that someone who was hurt (or the parties who protect them) are going to come to me asking questions. If I just say "I don't know" and the law doesn't protect my willful ignorance, I'm at best enabling harm; I'm at worst socially or legally liable for negligence.
In the abstract, the systems of human governance recognize harm and seek to mitigate it.
So if I'm peered to a network using me as a bridge to do harm, I can't trust that network when the bad starts to outweigh the good. If I can't establish trust via human methods, I'm gonna cut that network off to protect myself.
(The Internet started as people who had working relationships with each other and grew out from there. Even though the web of connections is much larger and more indirect now, the whole thing is still at its core a human construct and beholden to human standards of conduct, because humans ultimately have their hands on the various plugs that are yankable).
Internet where you send a packet over the wire and the network takes it and delivers it per RFC. Basically OG Internet. Network of networks of more or less trusted peers.
Or Internet where you need to requisition every connection/circuit be provisined before it is routed, which includes explaining why you need the service, and where any provider in the chain will deny you transit by default? You now must forge an intimate relationship with every middle box between you and the other endpoint. This process must be repeated by everyone on the network. Just operating as a middle box for someone else is now fraught with legal liability; as anything one of your transit's end up doing, you are now considered complicit in.
Both of these architectures of an Internet are equally valid and functional. The society that uses them however is completely different.
I prefer the former, warts and all, and lack of throat to throttle short of the asshat running the software on the other end, over the latter, because with the former at least, we're not creating power nexii to attract asshats to NetOps positions.
With the latter setup, sure, your spam problem has an ostensibly way higher barrier to entry in the form of having to create human trust networks, but the accretion of social power distinctly changes the culture of the net sector, attracting a type of personality that should never, ever be trusted to be given a yay/nay authority over other folks access to a network.
I don't see why verifying that an IP from your own subnet isn't claiming to be from outside it requires everything in your second paragraph.
You're looking at this as a collective update of firewall rules, and content to stop there. I'm more concerned about what that gesture turns into once it's significance percolates out to the public at large. Societies rearrange themselves around technical capabilities. Continue reasoning about how that constraint evolves into new obligations and legal precedents on the network operator, and you should eventually arrive at why I'm content to leave that particular bear unpoked.
It never stops at the technical. Ever.
They're only validating that the traffic that they originate use the IP addresses that they manage. So ISP that has an interface with 100.0.0.1/24 make sure that any ingress on that interface has source IP addresses in that range. If everyone does this spoofing becomes impossible and there's no cooperation or whatever you described required.
there is no "ingress," just a firewall of bad peers.
>If you think about it:
* The integrity of registrar accounts that are the root of trust for most DNS zones (this was, last I checked, the overwhelming source of DNS corruption attacks),
* The security of one or more DNS lookups, depending (some CAs, like LetsEncrypt, do multi-perspective lookups), and
* The WebPKI Certificate Transparency system, which tracks the issuance of all certificates that Chrome and Mozilla will accept in a public ledger.
https://cabforum.org/working-groups/server/baseline-requirem...
If the DNS server is bad, it'll return e.v.i.l as the IP, your browser will talk to that, but it can't give a certificate that your computer thinks is valid. so your protected from accidentally logging in to a fake bank website, but also you can't access the correct bank website, so there's still a denial of service problem.
The certificate authority (CA) that gives out the certificates has to verify you own the domain that you're asking for the certificate for. One method is to look up the IP, but as that's problematic if they get the wrong IP, they usually check that from multiple places all over the world.
My understanding of the situation is, somebody in Network A is sending spoofed traffic to Network B. Hetzner receives abuse reports from Network B.
Should Hetzner either establish trust or cut off: Network A, Network B, or their customer?
Hetzner has or should have means to verify that their customer is not the one making port 22 requests. They are not the attacker. Network B is reporting the issue, they are also not the attacker. And Hetzner cannot identify Network A, at least not without Network B's cooperation. And even if Hetzner does identify and cut off Network A, the problem remains – Network A can still send spoofed traffic to Network B.