From some first-hand experience over the last few months… these suggestions and patch will help prevent a single client from overwhelming an NGINX server, but it will do little to stop even a modest botnet from generating enough requests to be a problem. Keeping some state on IPs and downgrading those that exceed limits to HTTP/1.1 I believe is the only effective defense. Tuning those thresholds to get them right is… challenging.
HTTP/2 rapid reset attack impacting Nginx products
11–20 of 66 posts
Re: HTTP/2 rapid reset attack impacting Nginx products
#12Hehe, when I heard about the attack a couple of days ago I was interested to know if Nginx was affected and did a search on Google for the CVE of that attack followed by the name of Nginx. I didn’t find anything relevant so I assumed that Nginx was not affected. Turns out that was not a good assumption :p
I immediately thought I’m happy not having to operate anything with nginx in front of it.
Re: HTTP/2 rapid reset attack impacting Nginx products
#13How does HTTP/1.1 stand up to the current attack?
Re: HTTP/2 rapid reset attack impacting Nginx products
#14How does HTTP/1.1 stand up to the current attack?
Not impacted.
Re: HTTP/2 rapid reset attack impacting Nginx products
#15Hehe, when I heard about the attack a couple of days ago I was interested to know if Nginx was affected and did a search on Google for the CVE of that attack followed by the name of Nginx. I didn’t find anything relevant so I assumed that Nginx was not affected. Turns out that was not a good assumption :p
If you read the article, you'll see that the default configuration is not affected.
CVEs aren't restricted to only consider default configs.
Re: HTTP/2 rapid reset attack impacting Nginx products
#16Related. Others? HAProxy is not affected by the HTTP/2 Rapid Reset Attack - https://news.ycombinator.com/item?id=37837043 - Oct 2023 (31 comments) The largest DDoS attack to date, peaking above 398M rps - https://news.ycombinator.com/item?id=37831062 - Oct 2023 (461 comments) HTTP/2 Rapid Reset: deconstructing the record-breaking attack - https://news.ycombinator.com/item?id=37831004 - Oct 2023 (22 comments) HTTP/2 z…
Also Go's HTTP/2 packages - https://news.ycombinator.com/item?id=37863419
Re: HTTP/2 rapid reset attack impacting Nginx products
#17Why the submission OP? Lots of discussion and submissions related to this over the last few days, not to mention this submitted 2 days ago
Because Nginx is a very widespread high performance web server that initially seemed not to be impacted but now it turns out that it is.
Re: HTTP/2 rapid reset attack impacting Nginx products
#18Earlier quoted context omitted.
If you read the article, you'll see that the default configuration is not affected.
CVEs aren't restricted to only consider default configs.
There is a difference between an application being innately vulnerable and a user configuration exposing a vulnerability.
Interestingly enough, HAProxy seems to have the same mitigation:
> Until HAProxy dips below the configured stream limit again, new stream creation remains pending—regular timeouts eventually apply and the stream is cut if the situation does not resolve itself. This can occur during an attack.
https://www.haproxy.com/blog/haproxy-is-not-affected-by-the-...
That is, if I read it correctly, default configuration is safe and you can use configuration of stream limits to ensure you are not vulnerable, but they are saying HAProxy is not vulnerable...at least in the title. Later on they soften the language:
> HAProxy remains resistant to HTTP/2 Rapid Reset
Re: HTTP/2 rapid reset attack impacting Nginx products
#19Why the submission OP? Lots of discussion and submissions related to this over the last few days, not to mention this submitted 2 days ago
Because Nginx is a very widespread high performance web server that initially seemed not to be impacted but now it turns out that it is.
There is no new revelation here.
Re: HTTP/2 rapid reset attack impacting Nginx products
#20[deleted]