I agree they they should, but that would be hard before, now in the IoT-hell where even your lightbulbs and internet-facing and capable of being proxies seems like a herculean effort.

Pretty sure I saw an article on HN a few days ago about, in part, how a bunch on seemingly innocuous apps for smart tvs, stuff like screen savers and the like, all ran proxy servers (in the users residential address) under the hood. I think it was in the GamerNexus investigation on the whole LG Tv spying on people IIRC.

I'd love to see China and Russia sued for hammering my personal websites for the past 20 years... will it ever happen? Hell no, LOL.

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...

That has only partially mitigated much smaller attacks (residential proxy scraping etc) on my employer's site.

We're currently on the "Business" plan, but I'm coming to the conclusion that we need to upgrade to the "Enterprise Advantage" plan for the JA3/4 fingerprinting and detection ID features.

I get put off by "Contact Sales" pricing.

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...

> Most of their docs hosting is static/easily CDN cached

The article says

> and it purposefully attacked areas that bypassed caching

So that doesn't work. Also, it seems that they were trying to cause financial harm, not to take down the infrastructure but to make it costly for the org itself. That's smart.

I don't quite understand your post, but is your question why don't the ISPs of the sources of the abusive traffic sort it out?

The distributed nature of DDoS means each participating host isn't sending that much traffic, and there are often tens or hundreds of thousands of participating hosts. An ISP should verify claims of abuse before cutting off customers, and since most of the customers are presumably unaware of what their systems are doing, there will be a lot of unhappy customers and then you've got to spend a lot of customer support time on helping them clean up their systems so they can get back online.

I spent a fair amount of time sending out abuse reports for phishing / malware senders about a decade ago, and most abuse reporting addresses are a black hole. Even if you do get to someone who will do something about abuse, they won't do it quickly.

There's be a few high profile longer term DDoS attacks lately, but when I was running infra that got a lot of stuff, it was mostly people kicking the tires on DDoS as a service offerings and most attacks were 90 seconds long ... there's no way I'm convincing an ISP to drop a pwned customer over that.

Starting from there, this DDoS sounds like layer 7 DDoS which is easy to track to the immediate senders, but a ton of DDoS is volumetric stuff, often volumetric reflection attacks where the senders spoof your address. If you're getting that, best you can do is get the reflectors kicked off (or cleaned up) ... tracing back to the sending hosts means getting a reflector (and their ISPs) engaged to do a lot of labor intensive work.

All of that investigation stuff takes qualified people lots of time, that's your money reason it doesn't happen.

https://www.scispace.com/pdf/drawbridge-software-defined-ddo...

I saw this quite a few years ago. It is possibly relevant. I don't know what, if anything, came of it since then.

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.

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.

Could be testing in preparation for attacking something more critical?

I run a similar service, and we get almost daily attacks like this. Sometimes it's a specific high-profile customer, other times it's broader.

I can't speak for RTD, but I think it's less "documentation site" and more just that we sit on the domains of high-profile products and the tools are just looking for any hole they can find?

Often it's even the company themselves, for whatever reason (security research, etc).

Either testing for something bigger OR demonstrating their power to a 3rd party with minimal real disruption

Could have been a live-fire exercise by a nation state.

Edit: why the down vote? That is literally in the realm of possibility!

If automatic scaling were free, this would be true...

Why would an AI crawler do this?

> Attackers found and deliberately targeted URLs that resulted in cache misses, such as non-existent pages with unique paths (404s) as well as temporary redirects (302s)