AT14: Recursive GET
Definition
Another refinement to the VERB attack is a Recursive GET attack. The attacker collects several pages or images and generates GET requests that “walk” through these pages or images. This method can be combined with any of the VERB attack methods to make this attack very difficult to detect because the requests appear to be legitimate.
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 | Low | -- | Valid | -- | Low | Short | Low |
Defense Fundamentals
HTTP Recursive GET and HTTP Excessive VERB are similar types of attacks. For Excessive VERB, most of the HTTP fields tend to be identical. RioRey uses the same algorithm to detect these attacks, but reports them separately when the recursive effect is detected for a Recursive GET attack.
HTTP Recursive GET adjustment are currently internal, inherited values from the settings in HTTP Excessive VERB. There are no separate sensitivity settings.
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 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. |
Attacker and Victim Identification
In HTTP Recursive GET 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.