WPCloudDeploy Documentation

Rapid Reset HTTP/2 & WPCloudDeploy

On October 10th 2023, information about an HTTP/2 vulnerability (CVE-2023-44487) that could cause a Denial of Service (DDOS) attack on sites was released.  It now goes by the name “Rapid Reset HTTP/2”.

If you are concerned about being a victim of this type of attack, there are things you can do to help mitigate it.

First, you can place your servers and sites behind a proxy such as CloudFlare.  The services have already rolled out mitigations against these kinds of attacks and will drop the traffic before it even hits your servers.

AWS, Google Cloud and Microsoft Azure already have mitigations in place to address the threat so if your servers are running there you are also benefiting from the protections they have put in place to address the issue.  It is possible other Cloud Server Providers have also rolled out protections as well.

Second, if you are running NGINX, you can apply their recommended changes to your servers – you can view those recommendations on the related NGINX blog article.

In particular, they are recommending the following:

  • keepalive_requests should be kept at the default of 1000.  For WPCD, our default stack does not modify this value so it should already be using the 1000 default value.  This configuration item is set in /etc/nginx/nginx.conf.  See the NGINX docs on keepalive_requests more more information.
  • http2_max_concurrent_streams should be kept at the default of 128 streams.  WPCD’s default stack does not modify this value either so you should not have to make any changes to it.  View the NGINX docs on http2_max_concurrent_streams.  WPCD’s default stack does not turn on HTTP/2 on NGINX so if you haven’t flipped the flag for a site, then this is probably a non-issue for it.

They are also recommending that you look at the following two directives:

  • limit_conn which enforces a limit on the number of connections allowed from a single client.  WPCD’s default stack does not modify this value.  Read more about limit_conn in the NGINX documentation.
  • limit_req which enforces a limit on the number of requests that will be processed within a given amount of time from a single client.  This one is trickier because it depends on the site/application and how it’s used.  The WPCD default stack does set a limit on the number of requests that can hit the wp_login page.  Otherwise, any other pages are set to the NGINX default.  You can read more about limit_req in the NGINX docs.

The bottom line is that, for WPCD, you shouldn’t have to make any changes to your NGINX configuration if you’re using our default stack and values.

OpenLiteSpeed

The OpenLiteSpeed folks are stating that they are NOT affected by this vulnerability because of the way they’ve developed their implementation of HTTP/2.  So, again, for WPCD, you should not have to make any changes if you’re using our default configuration.

You can read more about OpenLiteSpeed’s analysis of the issue on their site.

Additional Resources

if you are running other application stacks besides WPCD, you should check out this github repository where recommendations are being updated for multiple stacks that are affected.

 

Share: