Live data from Hacker News

Understanding the recent DDoS attack against Read the Docs

about.readthedocs.com

61–70 of 73 posts

Re: Understanding the recent DDoS attack against Read the Docs

#61
Sorry for the stress that the team had mitigating this attack. Yet I'm always excited to see signs of competence on the attacking side: a targeted application-specific and adaptive attack at L7? Wow!

Here's another guess: a DDoS to steal your attention and mask other intrusion attempts.

> Defenses need to have broader rate limits across more than just IPs (ASNs, hostnames, etc.).

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.

> Attackers actively search for non-cacheable paths (e.g. dynamic redirects, search endpoints, and 404s).

To continue with my previous point. As long as individual server's resources permit (memory, socket limit) stall requests before processing them. Low reputation IPs get stalled for longer and the requests that exceed the queue get dropped. The idea is graceful degradation:

A good rep IP will not be stalled by sleep(). A poor rep IP will be stalled, but eventually receive its answer instead of some 429/403 (i.e. a user who opened many tabs at once). A bad rep IP will be slowed down by the wait times + rate-limits (queue exceeded) before getting completely banned for good. The point is to have more granularity before throwing errors at random users at the server-level.

Re: Understanding the recent DDoS attack against Read the Docs

#62
> they were overwhelming a hardcoded Nginx redirect (a simple rewrite regex directive)

1. I wonder how much optimization ngx_http_rewrite_module has? Does it precompile the patterns? LLM said yes, this SO answer [1] says that a JIT config option must be on. I consider "Just in Time" to be a half measure when the config itself is static.

2. From looking at NGINX docs, it looks to me there are some pitfalls to writing these rules. Like you must manually make sure to short-circuit the rewrites to exit early?

3. The caveat of regex is that catastrophically backtracking regexes do look simple. I don't see this issue being talked about enough. See links, if you, the reader, haven't heard of it yet.

[1] https://stackoverflow.com/questions/59284921/how-much-impact...

[3.1] https://joshua.hu/nginx-directives-regex-redos-denial-of-ser...

[3.2] https://en.wikipedia.org/wiki/ReDoS

[3.3] https://infrafolks.com/blog/regex-backtracking-devops/

[3.4] https://www.regular-expressions.info/catastrophic.html

[3.5] https://gixy.io/plugins/regex_redos/

Re: Understanding the recent DDoS attack against Read the Docs

#63

Sorry for the stress that the team had mitigating this attack. Yet I'm always excited to see signs of competence on the attacking side: a targeted application-specific and adaptive attack at L7? Wow! Here's another guess: a DDoS to steal your attention and mask other intrusion attempts. > Defenses need to have broader rate limits across more than just IPs (ASNs, hostnames, etc.). The description/approach seems static…

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

Re: Understanding the recent DDoS attack against Read the Docs

#65
post #53
post #39

I'd like to see more of a legal response. First, find out who's on the other end of a few hundred IP addresses. Start with ones in the US. Sue for damages. Use discovery to find out what's on the other end. Sue the maker of that device. If it turns out to be an appliance or smart TV, it may be possible to consolidate cases into one case against the manufacturer. Criminal negligence, tort interference with contract, h…

The problem is most of the botnet zombies are in places with very little rule of law like eastern europe/russia/south america/china. It is an exercise in futility and the richest customers just opt to just spend money on more protection than shutting down the zombies. If the zombie is in the US, hosts like Google or Amazon will take 1+ month to respond.

[deleted]

Re: Understanding the recent DDoS attack against Read the Docs

#66
post #13

A more interesting question is, what exactly do the attackers gain from hitting read the docs? Most of their docs hosting is static/easily CDN cached. Unlike database bound sites, you would need a lot more traffic to overload pure/mostly static hosting. Maybe it's a malicious AI lab looking to deny their competitors training data? As far as infosec profiling goes, this is probably the oddest case I have heard of. I a…

Yeah I’d be fascinated to hear the attacker’s perspective. Why go through so much work just to slightly inconvenience a random website?

There’s no financial motive and they’re not a political target. Why bother?

Re: Understanding the recent DDoS attack against Read the Docs

#67
post #53
post #39

I'd like to see more of a legal response. First, find out who's on the other end of a few hundred IP addresses. Start with ones in the US. Sue for damages. Use discovery to find out what's on the other end. Sue the maker of that device. If it turns out to be an appliance or smart TV, it may be possible to consolidate cases into one case against the manufacturer. Criminal negligence, tort interference with contract, h…

The problem is most of the botnet zombies are in places with very little rule of law like eastern europe/russia/south america/china. It is an exercise in futility and the richest customers just opt to just spend money on more protection than shutting down the zombies. If the zombie is in the US, hosts like Google or Amazon will take 1+ month to respond.

Then IP-range block those places until they get their affairs in order.

Re: Understanding the recent DDoS attack against Read the Docs

#68

Interesting that the Under Attack Mode wasn’t used at all here. I understand not wanting to break APIs but I feel temporarily challenging non-API usage could have at least helped without impacting users too much?

> without impacting users too much?

You mean essentially locking out users with non-default Chrome configuration.

Re: Understanding the recent DDoS attack against Read the Docs

#69
post #45
post #39

I'd like to see more of a legal response. First, find out who's on the other end of a few hundred IP addresses. Start with ones in the US. Sue for damages. Use discovery to find out what's on the other end. Sue the maker of that device. If it turns out to be an appliance or smart TV, it may be possible to consolidate cases into one case against the manufacturer. Criminal negligence, tort interference with contract, h…

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 t…

Fortunately you only need to find a one of the many possible devices to sue. Just winning a couple of these will send a message. The goal isn't the $$$ directly (the lawyers are the only ones who win) it is to send a message that you are forever responsible for your vulnerable devices and so you better make them secure.

The hard part is if any of the devices are from someplace that doesn't have a US (or whatever country they are in) presence. That country my ignore the lawsuit.

Re: Understanding the recent DDoS attack against Read the Docs

#70
post #49

Earlier quoted context omitted.

Doesn't matter from the point of view of a lawsuit from an outside attacked party.

IANAL, but a harmed party outside of the 'binding arbitration' nonsense might be a way work around arbitration and drag the company into a court.

Exactly, the harmed party is not subject to binding arbitration. The harmed party isn't going to bring someone to court for their bad devices - nobody has enough assets to be worth suing (other than perhaps to compel them cooperate with the discovery process) . However the company that made those devices is worth suing.

Alibaba is an interesting question though - if the device is from China (or some such) it isn't clear what the courts can do...

Post reply on HN