good to know, thanks for the info Maxim. El mar, 10 oct 2023 a las 17:55, Maxim Dounin (<mdou...@mdounin.ru>) escribió: > > Hello! > > On Tue, Oct 10, 2023 at 05:30:52PM -0400, Rick Gutierrez wrote: > > > In the open version 1.24 and 1.25 the correction will be applied?, ¿or in > > the new release? > > To re-iterate: > > We do not consider nginx to be affected by this issue. In the > default configuration, nginx is sufficiently protected by the > limit of allowed requests per connection (see > http://nginx.org/r/keepalive_requests for details), so an attacker > will be required to reconnect very often, making the attack > obvious and easy to stop at the network level. And it is not > possible to circumvent the max concurrent streams limit in nginx, > as nginx only allows additional streams when previous streams are > completely closed. > > Further, additional protection can be implemented in nginx by > using the "limit_req" directive, which limits the rate of requests > and rejects excessive requests. > > Overall, with the handling as implemented in nginx, impact of > streams being reset does no seem to be significantly different > from impacts from over workloads with large number of requests > being sent by the client, such as handling of multiple HTTP/2 > requests or HTTP/1.x pipelined requests. > > Nevertheless, we've decided to implemented some additional > mitigations which will help nginx to detect such attacks and drop > connections with misbehaving clients faster. The patch to do so > was committed (http://hg.nginx.org/nginx/rev/cdda286c0f1b) and > will be available in the next nginx release. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx mailing list > nginx@nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx
-- rickygm http://gnuforever.homelinux.com _______________________________________________ nginx mailing list nginx@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx