Hi Everyone,
This just made my radar:
<https://thehackernews.com/2023/10/http2-rapid-reset-zero-day.html>.
>From the article:
F5, in an independent advisory of its own, said the attack impacts the
NGINX HTTP/2 module and has urged its customers to update their NGINX
configuration to limit the number of concurrent streams to a default of
128 and persist HTTP connections for up to 1000 requests.
Jeff
Hi,
from the article, these are the default values, so not too much to worry
yet.
Le mar. 10 oct. 2023 à 20:51, Jeffrey Walton <noloader at gmail.com> a écrit :
> Hi Everyone,
>
> This just made my radar:
> <https://thehackernews.com/2023/10/http2-rapid-reset-zero-day.html>.
>
> From the article:
>
> F5, in an independent advisory of its own, said the attack impacts the
> NGINX HTTP/2 module and has urged its customers to update their NGINX
> configuration to limit the number of concurrent streams to a default of
> 128 and persist HTTP connections for up to 1000 requests.
>
> Jeff
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20231010/494847b7/attachment.htm>
Hello!
On Tue, Oct 10, 2023 at 02:50:37PM -0400, Jeffrey Walton wrote:
> Hi Everyone,
>
> This just made my radar:
> <https://thehackernews.com/2023/10/http2-rapid-reset-zero-day.html>.
>
> From the article:
>
> F5, in an independent advisory of its own, said the attack impacts the
> NGINX HTTP/2 module and has urged its customers to update their NGINX
> configuration to limit the number of concurrent streams to a default of
> 128 and persist HTTP connections for up to 1000 requests.
The "the attack impacts the NGINX HTTP/2 module" claim is
incorrect, see here:
https://mailman.nginx.org/pipermail/nginx-devel/2023-October/S36Q5HBXR7CAIMPLLPRSSSYR4PCMWILK.html
Hope this helps.
--
Maxim Dounin
http://mdounin.ru/
On Tue, Oct 10, 2023 at 3:04 PM Maxim Dounin <mdounin at mdounin.ru> wrote:
>
> On Tue, Oct 10, 2023 at 02:50:37PM -0400, Jeffrey Walton wrote:
>
> > This just made my radar:
> > <https://thehackernews.com/2023/10/http2-rapid-reset-zero-day.html>.
> >
> > From the article:
> >
> > F5, in an independent advisory of its own, said the attack impacts the
> > NGINX HTTP/2 module and has urged its customers to update their NGINX
> > configuration to limit the number of concurrent streams to a default of
> > 128 and persist HTTP connections for up to 1000 requests.
>
> The "the attack impacts the NGINX HTTP/2 module" claim is
> incorrect, see here:
>
> https://mailman.nginx.org/pipermail/nginx-devel/2023-October/S36Q5HBXR7CAIMPLLPRSSSYR4PCMWILK.html
>
> Hope this helps.
Thanks Maxim.
The Nginx team may want to publish a blog post or knowledge article. I
got 0 hits when searching the site
<https://www.google.com/search?q="rapid+reset"+site:nginx.org>. It
will help admins and executives find the team's information.
Jeff
In the open version 1.24 and 1.25 the correction will be applied?, ¿or in
the new release?
Regards
On Tue, Oct 10, 2023 at 3:46 PM Jeffrey Walton <noloader at gmail.com> wrote:
> On Tue, Oct 10, 2023 at 3:04 PM Maxim Dounin <mdounin at mdounin.ru> wrote:
> >
> > On Tue, Oct 10, 2023 at 02:50:37PM -0400, Jeffrey Walton wrote:
> >
> > >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20231010/0a6fbc54/attachment.htm>
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/
good to know, thanks for the info Maxim.
El mar, 10 oct 2023 a las 17:55, Maxim Dounin (<mdounin at 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 at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
--
rickygm
http://gnuforever.homelinux.com