The most recent vulnerability sweeping across CDNs and web server development teams is CVE-2023-44487, or the HTTP/2 Rapid Reset vulnerability. In this article, we’ll be giving you our explanation on what this vulnerability does, as well as how to protect yourself from it. We’ll also go over the latest news on this vulnerability’s patches.
Table of Contents
What is the HTTP/2 Rapid Reset vulnerability?
Simply put, this vulnerability abuses part of the HTTP/2 specification. HTTP/2 supports multiple requests at the same time, which helps with performance. However, this feature can be exploited when combined with the use of the RST_STREAM command. That command cancels the open connection from having to respond with any data, which normally is a good thing. However, since the connection is never fully established, this can be exploited.
By requesting and cancelling each request, the abuser never hits a concurrent request limit. This allows the attackers to scale this attack to huge levels. CloudFlare set a new record in mitigated requests per second – 201 million requests per second caught by their DDoS system.
How does this vulnerability affect my websites?
This vulnerability can cause huge problems for those using unpatched web servers or don’t use a CDN that supports mitigating this attack vector. Attackers will be able to perform an enormous number of requests to your website without requiring many computers to do so. It’s possible that even one computer will be enough to bring down your websites completely.
This kind of attack can also affect other services that share a server with your website. For example, your server’s CPU cycles or network bandwidth may get used up completely as your server tries to handle all of the requests. That’s why it’s critical to protect yourself from this vulnerability.
How do I fix this vulnerability?
Currently the situation is a little unclear on fixing this vulnerability. The vulnerability takes advantage of the core functionality of the HTTP/2 specification, so an actual “fix” isn’t straightforward. NGINX announced configuration changes that you can make to reduce the risk as much as possible.
How to fix HTTP/2 Rapid Reset on NGINX:
These changes should work on any Linux distribution that supports running a recent version of NGINX.
- Set your keepalive_requests value to the default of 1000 requests.
- Set http2_max_concurrent_streams to the default of 128 streams.
- Set limit_conn to a value that makes sense for the number of connections a single visitor might make to your site.
- Set limit_req to a reasonable number for your website’s use case. This controls the number of requests from one visitor that will get processed per each period of time.
Here’s an example of a server configuration with all recommended settings applied:
html {
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_req_zone $binary_remote_addr zone=perip:10m rate=1r/s;
server {
listen your.ip.address.here:443 ssl http2 default_server;
keepalive_requests 1000;
http2_max_concurrent_streams 128;
limit_conn perip 10;
limit_req zone=perip burst=5 nodelay;
<continue your website configuration here>
}
}How to fix HTTP/2 Rapid Reset on Apache or HTTPD:
Apache or HTTPD are not fully affected by the vulnerability CVE-2023-44487 (HTTP/2 Rapid Reset) as confirmed by this message on GitHub. There is a risk of increased CPU usage when someone tries to attack your Apache instance, however this can also be prevented. The full fix depends on a patched version of libnghttp2. Unfortunately, it may take some time for that patch to be released as part of Apache. You may need to wait for a newer version of Apache that comes with the patched libnghttp2 library.
How to fix HTTP/2 Rapid Reset on any web server:
Currently the easiest and most straightforward way to protect your websites from the CVE-2023-44487 vulnerability is to use a CDN that has DDoS mitigations in place for this vulnerability. For example, CloudFlare has full protection against the HTTP/2 Rapid Reset vulnerability. The same applies for Microsoft Azure, Fastly, Amazon Web Services, Google Cloud, and so on. It’s important that your CDN supports Layer 7 or application layer attack mitigation.
Another option that may be acceptable in some scenarios is to disable the use of HTTP/2 altogether and switch to HTTP/1.1. This however can drastically affect the performance of your website. It’s important to gauge the risk of an attack on your website and decide whether the speed penalty is worthwhile for your use case.
Conclusion
Needless to say, this is a fascinating exploit of the HTTP/2 specification. If there are any updates to this situation, we will monitor and update this article with new fixes as they become available. For now, if you use a CDN with DDoS protection that supports Layer 7 attack mitigation, you are most likely safe.
If you use our Managed Linux VPS hosting services, we can set up CloudFlare for you to protect you from DDoS attacks. Additionally, we will apply any available patches and best practices to your web servers to protect you from this Rapid Reset vulnerability. That’s all part of our fully managed support, which comes included with every VPS at no extra cost.
Did you find this post informative or helpful? Share it with those that can also benefit from protecting their websites and businesses! We appreciate you reading this post. If you liked it, feel free to leave a comment below.