I've helped multiple people remove residential proxy malware that was turning their network into a brightdata exit node and they had no idea / did not consent to it. Why is google selectively targeting one provider while letting others operate freely?
The difference in min TCP RTT and min RTT to respond to a websocket payload is a dead giveaway that there's a middlebox terminating TCP somewhere along the path. You can bypass this by sourcing your request within 30ms of wherever TCP is being terminated, anything under that threshold could be caused by regular noise and isn't a reliable fingerprint. Due to how many gateway's there are between you and a residential proxy exit node this makes fingerprinting them extremely easy.
I expect it won't be long until someone deploys the first proxy service that handles the initial CONNECT payload in the kernel before offloading packet forwarding to an eBPF script that will proxy packets between hosts at layer 3, making this fingerprinting technique obsolete. The cat and mouse game continues.
> I expect it won't be long until someone deploys the first proxy service that handles the initial CONNECT payload in the kernel before offloading packet forwarding to an eBPF script that will proxy packets between hosts at layer 3, making this fingerprinting technique obsolete.
https://github.com/sshuttle/sshuttle basically works like this. I've used it for many years. I don't think it'll be possible to detect using this technique.
like its similar to connect or socks proxy except it is using SSH as a transport layer instead of TCP as a transport layer and its doing it transparently without having applications to be written to use the proxy. but if you are just converting TCP packets into a datastream and then sending them somewhere else where you convert them back to TCP packets then this is what this TCP RTT strategy is fundamentally meant to detect. i suspect the TCP only RTT thing works because of the delayed ack behaviour of most operating systems and this will still happen with sshuttle unless you are explicitly using quick-ack. also, quick-ack just works around the TCP-RTT issue and not the differences in timing between TCP and TLS or other higher protocols. i think if you are testing for other RTT differences then quick-ack would make them more obvious.
also, if you have an sshuttle proxy this site cannot detect it may be due to how close the server is to the client. i have a CONNECT based proxy it is able to detect around 5% of the time (maybe only that often due to a bug) but this is because there is probably less than 10ms latency between the proxy and the client and probably around 50ms latency between the proxy and the server for some reason (?).
Solutions exist that can completely block credential stuffing attacks most people just don't know about them, for example: https://layer3intel.com/tripwire
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.
You can check if your network is infected here: https://layer3intel.com/is-my-network-a-residential-proxy