Many servers on the web have been targeted by a new DDoS attack called Rapid Reset since mid-2023. This exploits a vulnerability in the HTTP/2 protocol that allows the number of requests to be multiplied.
Major cloud service providers such as Amazon, Google and Cloudflare are reporting a sharp increase in DDoS (Distributed Denial of Service) attacks. Google, for example, writes in an article from October 2023 that the number of DDoS attacks has increased exponentially in recent years. In August 2023, there was an even larger attack, which exceeded the previous largest attack from the previous year by a factor of 7.5. At its peak, there were 398 million requests per second. This was based on a technique called “Rapid Reset”, which is based on the HTTP/2 protocol.
Your security and maintenance specialist in the DataCentre
DDoS attacks aim to disrupt websites and services that are connected to and communicate via the internet and disrupt their accessibility. To achieve this, a large number of random requests are sent to the servers, which exceeds their capacity. The consequences of DDoS attacks can be serious and threaten the business operations of companies.
Rapid Reset uses HTTP/2 feature
Rapid Reset utilises a specific feature of the HTTP/2 protocol: stream multiplexing. So-called streams are used in HTTP/2. These are used to transmit various messages between the endpoints, the so-called frames. Stream multiplexing enables better utilisation of a TCP connection. Stream multiplexing enables clients to make various in-flight requests without having to manage individual connections.
Attackers send various requests within a stream, then reset this stream and cancels the request. However, the connection remains open. The server starts processing the requests, but terminates them due to the cancellation. The number of requests does not fall below the limit. This makes it possible to send a huge number of requests in succession.
Theoretically, the maximum number of open streams can be configured on the server, but in everyday use a client can open up to 100 streams, which are processed by the server in parallel.
In the HTTP/2 protocol, the client can inform the server that a previous stream should be cancelled by sending an RST_STREAM frame. This does not require any coordination between client and server, so that the client can initiate the cancellation unilaterally. The name “Rapid Reset” comes from the fact that an endpoint can send an RST_STREAM directly after sending a request frame. The other endpoint starts working, which results in a direct reset of the request. Although this cancels the request, the HTTP/2 connection remains open.
The basis of the rapid reset is that the maximum number of open streams is never reached due to the rapid cancellation of the requests. This means that an unlimited number of requests can be generated in each connection. The number of in-flight requests is no longer limited by the round-trip time (RTT), but only by the available bandwidth of the network.
The hackers rely on an asymmetrical distribution of processing costs between client and server: While making requests on the client side generates virtually no costs, the server itself has to carry out various tasks for cancelled requests, such as providing new data structures for the stream, parsing the request, unpacking the header and assigning URLs to resources.
Another advantage for potential attackers is that by explicitly cancelling requests immediately after they are generated, there is no possibility for the reverse proxy to respond. Cancelling the requests before creating a response reduces the downlink bandwidth from the server or proxy to the attacker.
How can you protect yourself from rapid reset attacks?
There are a number of measures that can lower the probability of rapid reset attacks or other DDoS attacks or reduce their impact. These include:
Early identification of vulnerabilities
Regular maintenance and server updates as well as proactive tests can help to recognise and eliminate vulnerabilities in the infrastructure at an early stage.
Broad monitoring and alerting
Seamless monitoring with prompt and graduated alerting ensures that a rapid response is possible in the event of an attack. Monitoring and alerting should be checked regularly as part of tests.
Install the latest patches and updates
If the implemented software is up to date, it ensures that patches and fixes to protect against security vulnerabilities are available in time, so that potential attackers have no chance of exploiting vulnerabilities.
Use of secure cloud infrastructure
Cloud providers such as Amazon, Microsoft, Akamai or Cloudflare have taken early measures against rapid reset attacks and ensure that the probability of successful attacks is low. For example, the use of a secure CDN can provide additional protection.
