Resolved Plesk and HTTP2 Rapid Reset

[Peter99]

Server operating system version

AlmaLinux 8.8 (Sapphire Caracal)

Plesk version and microupdate number

Version 18.0.56

Hi Plesk.

How are we secured by Plesk, against this known HTTP/2 Rapid Reset attacks?

HTTP/2 Rapid Reset Attack Protection

Cloudflare protects against HTTP/2 Rapid Reset DDoS attacks - sign up and get protected or reach out now for immediate under attack assistance.

www.cloudflare.com

 

[Rob Taylor]

Following for an answer... on Plesk, support for HTTP/2 is provided by NGINX, advice from NGINX to mitigate is:

HTTP/2 Rapid Reset Attack Impacting NGINX Products - NGINX

Update your NGINX configuration to mitigate a possible denial-of-service attack implemented on the server-side portion of the HTTP/2 specification.

www.nginx.com

So far not been able to work out how this can be applied at server level.

 

[Peter Debik]

Plesk is aware of this issue and is currently researching it, internal ID SEC-65158.

 

[Peter Debik]

Nginx by default sets the following values for the parameters:

• keepalive_requests = 1000;
• http2_max_concurrent_streams = 128.

When the default parameters are used, nginx instance isn’t affected by the vulnerability. Plesk doesn’t configure these parameters. Therefore, default Plesk instance isn’t affected.

If you have values other than the default, the probability of a successful attack increases as these values increase. For that case you can apply a custom patch mentioned in the article HTTP/2 Rapid Reset Attack Impacting F5 NGINX Products - NGINX (build the newest source-code from nginx repository), but it’s on your own risk, we didn’t test that. The best workaround now is set the values to default.

 

[Rob Taylor]

Many of theconfig files carry warnings about not editing - can you confirm the correct place in Plesk to configure those values on a server wide basis?

Thank you for your prompt response to this matter Peter!

 

[Peter Debik]

If you did not change these parameters before, there is no need to add them anywhere. If you changed them before, either remove them or replace the values by the defaults. If you wish to add them anyway, the right place is /etc/nginx/nginx.conf - or - you can create a new configuration file in /etc/nginx/conf.d/, ending on .conf, because that will be included in the http section of nginx.conf.

 

[Peter99]

If you did not change these parameters before, there is no need to add them anywhere. If you changed them before, either remove them or replace the values by the defaults. If you wish to add them anyway, the right place is /etc/nginx/nginx.conf - or - you can create a new configuration file in /etc/nginx/conf.d/, ending on .conf, because that will be included in the http section of nginx.conf.

Thank you indeed for a fast reply, Peter!
I just checked 3 of our Debian servers and 2 of our Almalinux server and these parameters seems missing on all servers in the /etc/nginx/nginx.conf
We haven't modified Nginx on any of the servers.
I will attempt to create a new file and add these parameters manually.

 

[Peter Debik]

You do not need to add these parameters if they are not present. The default setting will do.

 

[Peter99]

You do not need to add these parameters if they are not present. The default setting will do.

Oh i understand now. Thank you, Peter!

 

[HHawk]

I expect to release a fix for this asap as it can be very dangerous when I read the many articles on this... Seems urgent enough to automatically push an update/fix for this asap.

 

[Peter Debik]

@HHawk What fix is expected exactly? Would you want Plesk to remove custom configurations?

 

[Kaspar]

I expect to release a fix for this asap as it can be very dangerous when I read the many articles on this... Seems urgent enough to automatically push an update/fix for this asap.

From what I understand this issue posses limited threat as long as the default values are used for the keepalive_requests and http2_max_concurrent_streams parameters. Did you read anything different?

 

[HHawk]

Dubbed “HTTP/2 Rapid Reset,” the flaw requires making patches available for virtually every web server around the world before the problem can be eradicated.

Source: A New Protocol Vulnerability Will Haunt the Web for Years

It needs to be patched apparently. Nginx already updated their repo. DirectAdmin is also pushing an update soon. So I expect Plesk do the same, right?

 

[Kaspar]

I quickly read trough the Wired article. From what I can gather to article focuses on how the issue can be completely eradicated, which is by fixing the http/2 protocol. It does not mention that the severity depends on the implementation of the protocol by vendors. LiteSpeed for example stated that they are not affected. Nginx stated that the issue posses limited threat as long as the default values are used for the keepalive_requests and http2_max_concurrent_streams parameters.

As for DA, I could not find any statement from them. But their ngnix/apache/litespeed implementation might be different from Plesk, witch might necessitates a patch for them.

 

[Peter Debik]

The next stable Nginx version will be available April 2023. The current patches done in Nginx are on their "mainstream" version, which is a similar construction like the new RHEL "stream" - open heart surgery and banana principle where the product ripens after delivery to the user. The current Plesk security team assessment is that only if the two above mentioned variables are set to higher values, the risk increases. The higher the values, the higher the risk. You should be good with the default setting. But feel free to lower the values, if you prefer.

Plesk has the luxury of having experts specifically trained in security. We have to rely on the advice. It is not likely that the experts will be wrong. If new findings emerge, we will of course take action.

 

[Peter Debik]

https://support.plesk.com/hc/en-us/articles/18207328795287