How to Protect Against an HTTPS Bomb DDoS Attack
As part of our efforts to continually optimize our DDoS Testing and expand the attack vectors used, we recently focused on analyzing a DDoS attack called HTTP/S Bomb.
The HTTP/S Bomb DDoS attack, which was identified by Radware (see their blog) and by Netscout (who call it a Large Payload POST attack), is difficult to detect and mitigate. It has the potential of a massive volumetric attack yet while using a limited number of HTTP requests.
Attack Profile
As described on the Radware blog, HTTP/S bomb attack uses the HTTP POST method to send large, complex POST requests (usually scripted as an XML data structure), which the target server then attempts to parse. However, due to the size and complexity of the POST request (i.e., the “bomb”), the server ends up using high amounts of computing resources, ultimately depleting them, and bringing the server down.
How We Simulated the Attack
To simulate the attack, we used the payload of the XML Document Size Attack to create the payload of the malicious HTTP requests. We used a 5 Mb payload. One of the advantages of this attack vector is that you can increase or decrease the payload size by controlling the document size.
Next, we executed the attack using an Apache Benchmark command.
Because of the large payload that can be used in each HTTP request, you can easily create a large attack size/volume and still use a small request per second approach. For example, if every request is 5 Mbps, you can use 100 bots with each sending 2 requests/second to generate an attack size of 1 Gbps. Every small increase in the attack rate can result in a huge attack size of dozens or hundreds of Gbps. Similarly, increasing the XML document size also increases the attack volume dramatically.
| Normal HTTPS POST Flood | HTTP/S Bomb | |
| RPS from each bot | 100 | 2 |
| Bandwidth from each request | 5 Kbps | 5 Mbps |
| Number of bots | 100 | 100 |
| Total RPS | 10,000 | 200 |
| Total bandwidth | 50 Mbps | 1 Gbps |
Our Insights
HTTP/S Bomb is an extremely effective attack vector for creating a volumetric DDoS attack. Unlike most volumetric attack vectors that use layer 3 or layer 4 protocols, this attack uses a layer 7 protocol (HTTP), allowing you to create an application pipe saturation.
Due to the low RPS (requests per second) of each bot, attackers can easily bypass rate-limit rules that are commonly used by WAF (on-premises and cloud) to protect against application DDoS attacks. This is since the number of requests per second sent from each bot is smaller than the threshold of the rate-limit rules, thereby preventing the attack detection. Lack of detection prevents mitigation, which is typically executed by blocking malicious requests or by activating bot-mitigating Web Challenges, such as Cookie Challenge or JavaScript Challenge.
When testing the HTTP/S Bomb attack with customers, we saw that it had a great impact over CPU utilization and latency of web servers and on CPU utilization of on-premises WAF appliances. In the screen below you can see the CPU utilization of the on-premises WAF reaches 98% within seconds after starting an attack.
Detecting and Mitigating HTTP/S Bomb
As mentioned above, because each bot uses a small number of requests per second, the attack cannot be detected using rate-limit rules.
However, the malicious HTTP requests used by the attack vector are characterized by a high value of Content-Length request header – an attribute that can be used for detection. See example below.
Developing a detection and mitigation measure using the above characteristic is not native in an on-premises or cloud WAF, and custom development and fine-tuning should be done.
Take the Next Step
Learn about our DDoS Testing service and how it can help you protect against an HTTP/S Bomb, as well as many other attack vectors.