davidfischer
Joined 16 years ago
Karma
420
Submissions
87
Member since
Aug 2
Recent submissions
Comment · 1 month ago
> Do you have a list of the addresses that were hammering your site?
I could get a list of IPs, but it wouldn't be particularly helpful. It was hundreds of millions of unique IPs. Most IPs made fewer than 100 requests and then disappeared.
> Have you tried any of the techniques I list here?
We were already doing essentially all of the techniques there and they were not helpful in this attack. This wasn't some spider run amok. This was a dedicated attack with intelligence behind it.
> Do sets of the IP's show up in here [2]?
If we're looking at individual IPs, we've already lost.
> Are the bots mostly residential, VPS, Tor? What is the HTTP protocol breakdown? HTTP/1.1, 2.0, 3.0? Are they missing any expected client headers?
The article outlines most of this. It was a mix of residential and major/minor hosting providers and some corporates. If I were to say which was the largest, it was minor hosting providers. However, the attack pivoted between coming from different sources. At first it was coming mostly from minor hosting providers/VPS. By the end, it was entirely residential and corporate IPs. Tor was not involved at all (RTD supports accessing through Tor, but you are more likely to get a challenge). All the expected headers were there and UAs cycled between a very large set of standard UAs for normal browsers/devices. The attack was 95%+ HTTP2/HTTP3.
> [Edit] appears you are behind Cloudflare so the blackhole would be up to them. One could still return a 429 or 525 to the attackers.
It's trivial to setup an IP list[1] in CF and then you can apply all sorts of rules (lower rate limits, outright challenges, etc.) to it. It can be managed through Terraform as well. You can also use CIDR notation. This along with more classifications to specific ASNs are something we are looking at.
[1] https://developers.cloudflare.com/waf/tools/lists/custom-lis...
Comment · 1 month ago
Author here. This attack was extremely broad. I saw parts of this attack come from my own home ISP's ASN, though not my IP thankfully. If we just "blocked those places" there would be a lot of collateral damage. As it stood, we did temporarily bump up rate limiting for the biggest attack ASNs and we absolutely heard from real, regular users about it (Sorry to those affected).
Comment · 1 month ago
> The description/approach seems static and limited? Why not maintain a leaky bucket that counts each request (tickets/points) with higher cost for expensive requests (404, redirects). As the IP's reputation deteriorates (IPv4/32), it begins to spill over to a broader subnet like IPv4/31 then /30 and so on. Fight adaptivity with adaptivity. // maybe I describe something totally obvious, I'm not involved in the web ddos protection side of things.
The penalty box strategy I described in the post is along these lines. It penalizes excessive expensive requests directly. Specifically, it does add those to a score and will rate limit more broadly as necessary.
Comment · 1 month ago
It will probably be useless one day. In practice, it is still useful today though not for this attack.
Comment · 1 month ago
Here's my take:
* JA3s are mostly useless. JA4s supersede them entirely.
* Using JA4s in rate limits is pretty useful and helps a lot against proxy scraping. It was not very helpful in this attack.
* Bot detections are somewhat helpful but they don't solve scrapers/attacks by themselves. They're useful as a 2nd/3rd data point (eg. low bot score + bot detection + something else)
Comment · 1 month ago
My assumption would be that it would drastically reduce the attack to be borderline irrelevant. I've never turned on Under Attack so somebody else may have more insight and the docs[1] don't describe precisely what happens besides a JS interstitial.
I know that JS challenges, both interactive and non-interactive, can be solved by bots. I've seen it. However, I suspect that the challenges just get harder and harder until the attack levels drop.
[1] https://developers.cloudflare.com/fundamentals/reference/und...
Comment · 1 month ago
Author here. This was not a misconfigured data scraper. We see those every week[1]. This attack wasn't scraping useful content. It was almost entirely 404s and 302s and pulled virtually zero real docs. It specifically looked for URLs not served by the CDN and when it found a pattern, did millions of variations of it. Whether built by an AI or not, it was designed to cause outages and financial damage from autoscaling. However, as others have suggested, we may have been a test run for a real target.
[1] https://about.readthedocs.com/blog/2024/07/ai-crawlers-abuse...
Comment · 1 month ago
I've never seen the phrase "manual transmission user-agent". Using your own browser yourself is the new stick shift. Love it.
Comment · 1 month ago
I talked about that directly in the post. We didn't want to just challenge everyone. We use JS challenges but we try to use them sparingly. The rest of the ops team and I were fighting to stay up but it never got so bad that it was a choice between complete outage and using the Under Attack mode.
Comment · 1 month ago
It's terabytes of content and other than we're the host not really related to each other. However, for most projects, it's possible to download a zip file of all the HTML docs for that project. We have a lower rate limit to pull these, but a scraper can pull thousands of docs at once. We only host a few hundred thousand projects so pulling a zip of the latest docs for all of them could be done in a day or two at a very reasonable rate.
It's also possible to request the docs already processed into markdown[1]. Lastly, basically all of the docs come from Git. A smart scraper could just clone a project's repo.
[1] https://docs.readthedocs.com/platform/stable/reference/markd...
Comment · 1 month ago
I'm the author of the blog. I don't know. Internally, we were half joking that we were going to get ransom notice, but we never did.
The only thing that sort of correlates with this attack is that before it started, we began rolling out some slightly more aggressive rate limits one by one. This was mostly because anytime any new "company" thinks they're going to catchup with Claude/OpenAI, they scrape us very aggressively (and they're not respectful about it). My guess is that the attackers behind this attack were already probing us (they were) and they thought the window of opportunity might be closing.
Comment · 2 months ago
I use DDG on Android and it works pretty well there. I also saw this line in the article and it's somewhat of a stretch to call DDG either a "major" browser (as you point out) or a "non-Chromium browser". My understanding is it uses the browser engine bundled with the OS on Android/iOS/Mac/Windows and it isn't available for Linux.
The wikipedia article on it says:
> The core browser functionality is the WebView component provided by the operating system. This means the browser engine is Blink on Android and Windows, and WebKit on iOS and macOS.
Comment · 5 months ago
Nowadays, somebody can just ask claude to build them a scraper/bot that hooks into a proxy network and all of a sudden they can easily send 20k+ reqs/min from hundreds or thousands of IPs cycling them as they get rate limited or banned. In my work, the scrapers have gotten way more aggressive in the last 2 years or so. Frankly, I'm happy there is a solution.
There may be things to criticize Cloudflare for, but the problem of bots and scrapers destroying the open web was getting worse no matter what.
Comment · 7 months ago
I built EthicalAds (https://www.ethicalads.io/) for exactly this reason.
No tracking. No cookies. No behavioral targeting (targeting based on stuff you've previously done). Every website where our ads appear AND every advertiser is hand approved. No JS from advertisers: just a plain JPG/PNG and text.
We're small but on track to pay out $500k to publishers this year.
To contact me about Read the Docs or Ads, use my first name @ our domain names (either readthedocs.org or ethicalads.io).