AT15: Random Recursive GET
Definition
This attack is a modified version of a Recursive GET but designed for forum sites or news sites where pages are indexed numerically, usually in a sequential manner. The attacking GET statements will insert a random number within a valid range of page reference numbers making each GET statement different than a previous one.
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. For Random Recursive GET some request parameters are randomized. RioRey uses the same algorithm to detect these attacks, but reports them separately when the randomized effect is detected.
HTTP Random 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 block list for this attack type. It is recommended that you use this button when decreasing filter sensitivity.
| 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 Random 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.