Hi Tristan, On Tue, Oct 10, 2023 at 12:56:12PM +0000, Tristan wrote: > Hi all, > > This just got disclosed: > - > https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/ > - > https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack
Yes, finally it's public. > Seems like a clever update to the "good old" h2 multiplexing abuse vectors: > 1. client opens a lot of H2 streams on a connection > 2. Spams some requests > 3. immediately sends h2 RST frames for all of them > 4. Go back to 1. repeat. Yes, precisely one of those I tested last week among the usual approchaes consisting in creating tons of streams while staying within the protocol's validity limits. The only thing it did was to detect the pool issue I mentioned in the dev7 announce. > The idea being to cause resource exhaustion on the server/proxy at least > when it allocates stream related buffers etc, and the underlying server too > since it likely sees the requests before they get cancelled. > > Looking at HAProxy I'd like to know if someone's aware of a decent > mitigation option? We first need to check if at all we're affected, since we keep a count of the attached streams for precisely this case and we refrain from processing headers frames when we have too many streams, so normally the mux will pause waiting for the upper layers to close. > My current first guess was to adapt F5's recommendations here > https://my.f5.com/manage/s/article/K000137106, ie set > tune.h2.fe.max-concurrent-streams 10 I *tend* to think that just like for H1 with connect+GET+shut(), "option abortonclose" should be sufficient. But I'll run more tests. > But I'm not sure if there's a way to apply the suggested measure (by Google > this time) of catching misbehaving clients (opening more streams that > advertised, or sending a lot of reset frames). It's possible that storing http_fail_rate in a stick-table could be sufficient to flag them as abusing. I don't know yet. > Finally I'll note that I don't currently have access to a good way to test > how much it affects HAProxy. And maybe it doesn't due to some peculiar > implementation detail. But that would be good to know. I'll run some tests on this, I can forge sequences of frames like this. Thanks, Willy
