AT 10: HTTP Fragmentation
Definition
In this attack, the attacker (non-spoofed) establishes a valid HTTP connection with a web server. The attacker proceeds to fragment legitimate HTTP packets into tiny fragments, sending each fragment as slow as the server time out allows, holding up the HTTP connection for a long time without raising any alarms. For Apache and many other web servers designed with improper time-out mechanisms, this HTTP session time can be extended to a very long time period. By opening multiple extended sessions per bot, the attacker can silently stop a web service with just a handful of bots.
Attack Matrix Dimensions
| Nature of IP | Handshake | Source IP Range | Packet Rate | Packet Size | Packet Content | Fragmenting | Session Rate | Session Duration | VERB Rate |
|---|---|---|---|---|---|---|---|---|---|
| Non-Spoofed | Yes | Small | Very Low | Small | Valid | High | Very Low | Very Long | Very Low |
Defense Fundamentals
AT10 Fragmentation defense addresses the "Slowloris" attack and a number of variations that use Post methods. This defense mechanism finds incomplete HTTP requests or responses and proceeds to measure the time between these incomplete messages. Early indicators such as short messages which are not terminated properly are also evaluated.
Many SLOWLORIS/other implementations employing HTTP Fragmentation use an aggressive open session grab algorithm. Using this aggressive grab, an attacker can take down most common web servers with less than 50 bots. When launched, each bot will attempt to gather as many open sessions possible all at once. This often triggers our AT11 detector if the server is not already busy. In this situation, if the attacker is identified as Excessive Verb and filtered we will not re-classify it as HTTP Fragmentation attack. Often, if you see a mix of Excessive Verb and Fragmentation attacks, it is likely because the whole attack is a single aggressive Fragmentation attack.
| Description | Filter Sensitivity LEVEL | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 OFF | 1 | 2 | 3 | 4 | 5* | 6 | 7 | 8 | 9 | 10 | |
| Victim Attack Packet Threshold (ppm) | NA | 160 | 80 | 40 | 20 | 10* | 9 | 8 | 7 | 6 | 5 |
| Victim Attack Ratio | NA | 99 | 95 | 90 | 85 | 80* | 75 | 65 | 55 | 51 | 49 |
| Attacker Attack Packet Threshold (ppm) | NA | 160 | 80 | 40 | 20 | 10* | 9 | 8 | 7 | 6 | 5 |
| Attacker Attack Ratio | NA | 99 | 95 | 90 | 85 | 80* | 75 | 65 | 55 | 51 | 49 |
| Attack Flow Threshold (ppm) | NA | 40 | 20 | 10 | 5 | 1* | 1 | 1 | 1 | 1 | 1 |
| Attack Flow Ratio (bad/total .. %) | NA | 99 | 80 | 70 | 60 | 51* | 45 | 40 | 30 | 20 | 10 |
| Attacker IP Block time (minutes) | NA | 5 | 10 | 15 | 30 | 60* | 120 | 240 | 480 | 960 | 1440 |
Configuration Settings
Click Edit to change default setting(s). When done, remember to Save before moving on to next mitigation section.
You can hit Clear Filter List to remove all IPs from the filter list for this attack type. This is equivalent to running a Clear for all IPs under this attack type in Clear Filter List.
If you are changing filter settings, it is recommended you Clear Filter List after you have updated your settings to prevent addresses from getting blocked again before the new settings take effect.
| Feature | Default Setting | Comments |
|---|---|---|
| Filter Mode | Auto (Auto/Monitor) | Auto: Algorithms are executed and packets are filtered. Monitor: Packets are viewed, counted and all algorithms are executed. No filtering of these packets will occur in Monitor mode. DDoS traffic will be identified and represented in all attack-based charts and the Zone Traffic Chart will represent zero dropped traffic. Off: No filtering or monitoring is performed. |
| Filter sensitivity | Level 5 (1-10) | This feature allows the user to adjust the sensitivity level of the filter for HTTP Fragmentation based DDoS attacks. The recommended default setting is level 5. To reduce filter sensitivity, lower the setting number. The higher the setting, the more sensitive the filter becomes. Due to the aggressiveness of the setting, Level 10 is liable to drop some good traffic. Alter the sensitivity settings gradually as needed. |
| Show advanced controls | Disabled | Enabling this control opens up all of the advanced controls for AT10 (listed below). By default, the controls will populate at their settings for the currently set filter sensitivity level. The advanced controls require careful configuration in order to work correctly. They should only be adjusted after direct consultation with RioRey. |
| Victim Attack Packet Threshold (ppm) | Minimum number of attack packets delivered to an IP before it is considered a victim. | |
| Victim Attack Ratio | Minimum percentage of traffic that is considered attack traffic to declare a victim. | |
| Attacker Attack Packet Threshold (ppm) | Minimum number of attack packets sourced from an IP to a destination before it is considered an attacker. | |
| Attacker Attack Ratio | Minimum percentage of bad traffic from an IP to a destination before it is considered an attacker. | |
| Attack Flow Threshold (ppm) | Minimum number of attack sessions established between an attacker and a victim. | |
| Attack Flow Ratio (bad/total %) | Minimum percentage of sessions between an attacker and victim that are considered attack traffic. | |
| Attack IP Blocktime (minutes) | Number of minutes a declared attacker's IP will be blocked. | |
| Max request size to check | Maximum size of the data payload to check. | |
| Check IP length skip enable (RIOS 5.3.0 and greater) | Enables entry of a list of data payload sizes to skip analysis. | |
| Check IP length skip list (RIOS 5.3.0 and greater) | Entries that will be skipped. |
Attacker and Victim Identification
In HTTP Fragmentation attacks and all other layer 7 HTTP attacks, we can identify a single source IP sending attacking packets to the destination victim IP, a degree of certainty that is rare for other types of DDoS attack. In contrast, for example, in spoofed source IP UDP attacks one can often establish only a "confidence level" and not a definitive identification of each and every source IP.
With positive IP identification possible for layer 7 HTTP attacks, one must establish criteria for how quickly to block a particular source IP. Our current sensitivity level adjustment for layer 7 HTTP attacks is based on the number of attackers seen before declaring an attack event. We are mindful that some apparent "attackers" are legitimate computers experiencing a glitch: under normal networking conditions, good computers may exhibit bot-like behaviors when their software has a brief "hang" or "blue screen" or "slow response." With their complex Operating Systems and applications, modern computers can stall and generate packets that resemble a DDoS attack.
We need to control the instances we count these stalled computers as attackers, because once a Layer 7 attack is recognized and filtered, an offending source IP will be blocked from accessing the victim IP for the range of time configured. Knowing that false postives can occur, RIOS software will place a source IP into the block list only after it has made more than a few offenses.
Even though every offending IP is not blocked immediately, the network operator should be aware of every instance. Therefore, all Layer 7 attackers are tracked via the filter list.
The software adds a new Victim Destination IP only if that Victim sees sufficient attacking source IPs generating sufficient attacking sessions at the same time. Thus for Layer 7 attacks, an attack is defined as a certain number of simultaneous bad sessions. The operator can redefine when an attack event has started by increasing or decreasing the sensitivity level, which will raise or lower the threshold of tolerance for simultaneous bad sessions.
This tolerance adjustment gives the operator discretion on how much attack traffic will "leak through" during an attack. The operator decides priorities, knowing that increasing the speed and completeness with which an attack is stopped will likely increase the of number of false positives.