from Hacker News

HTTP/2 rapid reset attack impacting Nginx products

by 120bits on 10/12/23, 7:04 PM with 62 comments

  • by sickofparadox on 10/12/23, 8:12 PM

    Important to note that unless your Nginx instance has a special (read: very high) keepalive limit configured, Nginx has a fairly reasonable defense against HTTP/2 rapid reset attack by default, as the article says. Still, interesting to see the response to these attacks.
  • by dang on 10/12/23, 7:52 PM

    Related. 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 zero-day vulnerability results in record-breaking DDoS attacks - https://news.ycombinator.com/item?id=37830998 - Oct 2023 (69 comments)

    The novel HTTP/2 'Rapid Reset' DDoS attack - https://news.ycombinator.com/item?id=37830987 - Oct 2023 (103 comments)

  • by ComputerGuru on 10/12/23, 11:20 PM

    I’m stuck trying to figure out if this is technically desired behavior or not. If you were retroactively designing http/2 with this knowledge, would you have done anything different?
  • by nimbius on 10/12/23, 11:38 PM

    FYI this is for the commercial nginx product, hastily purchased by F5 a few years back when software load balancers were annihilating their hardware offering.

    Curious to see f5 still playing games with their own cve disclosure on the bigip product though...assigning it a mitre cw400 is just lying.

    https://my.f5.com/manage/s/article/K000137106

  • by eastdakota on 10/12/23, 8:39 PM

    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.
  • by codetrotter on 10/12/23, 8:02 PM

    Hehe, 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

  • by amelius on 10/13/23, 6:45 AM

    > this vulnerability can be exploited to execute a denial-of-service attack

    Title should contain this info.

  • by getcrunk on 10/13/23, 12:45 AM

    > layer 4 monitoring and alerting tools

    What do you guys use? Anything foss and not an applicance?

  • by 1vuio0pswjnm7 on 10/12/23, 11:53 PM

    If someone asked me how to "speed up the web", I would not suggest "use HTTP/2". I would remove ads and other garbage. As a decades long non-popular browser and TCP client user, I can testify this works very effectively. I prefer to have full control over the resources that I request, whether text or binary, so no auto-loading resources, no Javascript-requested resources and no HTTP/2 "server push". The clients I use do not auto-load resources, run Javascript nor carry out "server push". Works great for me. Web is not slow.

    According to HTTP/2 proponents, the protocol originated at an online advertising services company and was developed by companies that profit from sale and delivery of online advertising, HTTP/2 was designed to "speed up the web".

    I respect that opinions on HTTP/2 may differ. If someone loves HTTP/2, then I respect that opinion. In return I ask that others respect opinions that may differ from their own, including mine. NB. This comment speaks only for the web user submitting it. It does not speak for other web users. IMHO, no HN commenter can speak for other web users either. Thank you.

  • by blackbeans on 10/14/23, 4:49 PM

    What about the old and proven Apache? Is it affected?
  • by phendrenad2 on 10/12/23, 8:58 PM

    How does HTTP/1.1 stand up to the current attack?
  • by andrewstuart on 10/12/23, 10:43 PM

    Anyone know if it affects Caddy?
  • by bullen on 10/13/23, 8:16 AM

    Just use HTTP/1.1, it's the final protocol.

    Nothing Google or Microsoft does will dethrone it.

    Forget the browser; use a C or Java client and HTTP.

    If they block port 80, just use another port.

    They cannot win.

  • by ChrisArchitect on 10/12/23, 8:36 PM

    Why the submission OP?

    Lots of discussion and submissions related to this over the last few days, not to mention this submitted 2 days ago