Back in the day I would scan for DrDoS reflectors in a similar way, no hosting provider wants to get reports for port scanning so the source address of the scan would belong to an innocent cloud provider with a reputable IP that reflectors would happily send UDP replies to. The cloud provider would of course get a massive influx of complaints but you would just say that you aren't doing any scanning from your server (which they would verify) and they wouldn't shut your service off. The server sending out the spoofed scan packets is undetectable so you're able to scan the entire internet repeatedly without the typical abuse issues that come with it.
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.
Whenever I see the name Marek Majkowski come up, I know the blog post is going to be good.
I had to solve this exact problem a year ago when attempting to build an anycast forward proxy, quickly came to the conclusion that it'd be impossible without a massive infrastructure presence. Ironically I was using CF connections to debug how they might go about this problem, when I realized they were just using local unicast routes for egress traffic I stopped digging any deeper.
Maintaining a routing table in unimog to forward lopsided egress connections to the correct DC is brilliant and shows what is possible when you have a global network to play with, however I wonder if this opens up an attack vector where previously distributed connections are now being forwarded & centralized at a single DC, especially if they are all destined for the same port slice...
I had an almost identical idea to this website a while ago but never acted on it, props to the dev.
Here is how you win the IPv4 games, in order of most to least effective:
1) Have a large online following that is willing to visit your claim link or a page where you can embed an iframe / img / etc that points to your claim link.
2) Pay to use someone else's (consensual) botnet by paying a residential proxy service, this is the approach I just used and it cost me a few dollars for access to a massive amount of distributed IPv4 space.
3) Abuse cloud / serverless offerings as far as they will go, unlikely to win more than a few blocks this way.
4) Own IPv4 space.
Other less ethical approaches: possibly exploit the system by sending a XFF header the developer forgot to block (probably just checking socket address so unlikely to work here), spin up a Vultr VPS in the same DC and probe for a way to connect with a local address, hijack BGP space, run your own botnet, I'm reminded of an old exploit in WordPress XMLRPC...
From what I can see the current rankings are just me and mike fighting for the same proxy space (the vote goes to the most recent visit per IP), and everyone else falls into buckets 3 & 4.
Basically I did a 1&2 combo. I run a small anti-bot service for a few friends sites and started redirecting a particularly aggressive scraper to the claim URL.
I took approach #3 for 5 blocks. Surprisingly, that's good enough to get on the leaderboard, at least till someone keeps a simple script running longer than me.
I do wonder what an IPv6 version of this would look like, but how it'd work, and how active it'd be.
I am option 4 but it's never going to get me very far up the leaderboard. So I just grabbed one of the funny numbers in one of the /8s and called it a day.
"Our decision today was that the risk created by the content could not be dealt with in a timely enough matter by the traditional rule of law systems."
Booter services have been using CloudFlare for the better part of a decade, sure individual services come and go but the trend is persistent. So for booter services a decade is enough time for the rule of law to make the decision but another type of controversial platform follows it's own arbitrary timeline, and I would argue that is setting the most dangerous precedent of all, especially when the 'risk' created by a particular type of content doesn't outweigh any potential financial incentives.
Ok, I honestly know nothing about this topic, I just read the article and my comment is merely a critique of the original article's internal logic and nothing more.
Interesting. "Anti-scalping" is a novel keyword to me; I've always just seen these kinds of techinques discussed under the "anti promotion-fraud" banner. Time for more research!
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.