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.
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.
Same with spoofed MAC addresses, email addresses, ARP messages, Neighbor Discovery, MitM TLS certificates ... It's amazing anything works anymore :D
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.
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
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.
At the end of the day, the internet is people.
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.
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'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.
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.
I suppose a difference is that they use unaffiliated parties to send the complaint, instead of contacting the authority directly.
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.