摘自：https://f5.com/resources/white-papers/mitigating-ddos-attacks-with-f5-technology
Mitigating Application Attacks
At the top of the OSI stack is the application layer. This is the area where it's most difficult to detect or defend against malicious behavior, and in particular, conventional firewalls provide little defensive value. Consequently, the application layer is being targeted by most of today's attackers.
Figure 6: Application attacks are the most prevalent today.
An application attack is different from a network attack in that it is specific to the application being targeted. Whereas a SYN flood can be launched against an IP address, an application attack will usually exploit properties specific to the victim, such as the repeated downloading of a single PDF file on the website. To lower-level security devices such as firewalls, the attack connections are indistinguishable from normal traffic.
BIG-IP ASM brings together a variety of anti-attack and DDoS prevention technologies specifically designed to mitigate application layer attacks, including the majority of the OWASP Top 10. BIG-IP ASM learns the expected input for every page in the site it protects and generates a security policy to protect that page. Because BIG-IP ASM is application-aware, it can foil application-layer attacks that abuse the application, the database, or the business logic.
BIG-IP ASM can distinguish between humans and robots as the sources of traffic and use this information during an attack to block non-human visitors. It can also inject JavaScript redirect code into the stream to foil the majority of botnet slaves while allowing access to legitimate browsers. Finally, BIG-IP ASM can also rate-limit traffic to specific application servers when it detects that an attack may be underway.
Mitigating Specific Application Attacks
Today's DDoS attack tools often use multiple attack vectors, mixing flood types. As attacks against the application layer increasingly grow multi-pronged, they've sometimes earned the name diverse distributed denial-of-service (3DoS) attacks. Whether they use high- or low-bandwidth approaches or both, these attacks can be very difficult to identify and defeat.
A solution that can provide early warning about the attack vectors and defend against multiple, simultaneous vectors is therefore the most effective. The combination of BIG-IP LTM, appropriate iRules, and BIG-IP ASM defeats a large number of application-layer attacks.
| OSI Layer | Attack | BIG IP LTM + iRule | BIG-IP ASM |
|---|---|---|---|
| Application (Layers 6–7) | Slowloris (Nuclear DDoSer, Slowhttptest) | ✔ | ✔ |
| Keep-Dead | ✔ | ✔ | |
| Slow POST (R-U-Dead-Yet, Tor Hammer, Nuclear DDoSer, Slowhttptest) | ✔ | ✔ | |
| HashDoS | ✔ | ✔ | |
| Apache Killer (Slowhttptest) | ✔ | ✔ | |
| HTTP GET Flood, Recursive GET Flood (Web Scraping), Dirt Jumper (HTTP Flood) | ✔ | ✔ | |
| #RefRef (exploits SQLi / OWASP Top 10 vulnerability as entry) | ✔ | ||
| XML Bomb (DTD Attack), XML External Entity DoS | ✔ |
Figure 7: Multiple attack vectors can be defeated by BIG-IP technologies and products working together.
Simple GET floods
One of the most common application layer attacks is a GET flood that simply requests static URLs. BIG-IP LTM can mitigate these attacks with an iRule that filters on the requested URL, and BIG-IP ASM can rate-limit requests based on server performance, client requests per IP address, and increases in requests from specific URIs.
Recursive GET floods
Recursive GET floods are GET flood attacks that iterate through the website, retrieving every object that can be requested. Unlike simple GET floods, recursive floods cannot be filtered with a URL-matching iRule.
BIG-IP ASM can mitigate these attacks from a different angle, however, by monitoring the application's response time (which is by itself the most accurate detection method) and then sequentially applying three different countermeasures:
- A smart JavaScript injection that will verify that the user is indeed using a browser. Most attacking tools are not browser-based, since browsers are not designed to send a lot of requests per second. In addition, this countermeasure can deal even with an attacker using a website behind a proxy without affecting the traffic of legitimate users connecting through the same proxy. In either case, the identified attacker's connection is dropped.
- If the JavaScript injection doesn't solve the problem, (for example, when it doesn't effect a positive change in latency), then BIG-IP ASM will rate-limit GET requests from even the chattiest IP addresses.
- If neither the first nor the second countermeasures solves the issue, BIG-IP ASM escalates to rate-limiting per URL.
Malicious POST floods
POST floods are gaining momentum as attackers have figured out that this technique is a good way to get around various intermediaries, such as content delivery networks (CDNs) and caching services. Typically POST floods bypass these and go straight to the origin servers. Sending a POST, which is nearly as easy for a client as sending a GET, has a much greater chance of tying up valuable resources on the origin server.
BIG-IP ASM can use its techniques for identifying human vs. robotic connections to foil POST attacks. As with recursive GET floods, it can also rate-limit based on the URI, server performance, or the number of requests per client.
Mitigating Low Bandwidth HTTP Attacks
Low-bandwidth attacks are a specific form of application-layer attack that are often undetectable by conventional means because they use very little incoming bandwidth.
Slowloris attacks
The Slowloris and PyLoris attack tools achieve denial of service by feeding an HTTP header to a server in an extremely slow fashion. Slowloris starts by probing the target service to determine its inactivity timeout—usually about five minutes or 300 seconds. Once the interval is known, Slowloris opens connections that emulate a simple browser and sends a bogus HTTP header just ahead of the timeout (for instance, every 299 seconds):
HTTP/1.1
GET /
X: a <299 second pause> X: a <299 second pause> X: a <299 second pause>
The connections will go on like this forever. When enough of them have engaged a specific web server, that server will no longer have enough connections to accept new requests, resulting in a denial of service.
BIG-IP LTM, as a standard, layer 7, full-proxy virtual server for HTTP, mitigates these attacks in its TMOS high-performance traffic management microkernel or simply dilutes the attack with the PVA. It will never pass along Slowloris and Pyloris requests because it will be waiting for the final double carriage return that marks the end of the headers. Since the attack tools never send that token, BIG-IP LTM does not consider the connections valid. Eventually they will be discarded without ever consuming resources behind the ADC.
For distributed Slowloris attacks, where millions of Slowloris connections may pile up at the BIG-IP device, a Slowloris iRule takes a more proactive approach to dealing with the attack.
Slow POST attacks
The slow POST attack is similar to the Slowloris attack but can only be mitigated with the BIG-IP ASM module. Slow POST works by starting an HTTP POST operation (like an upload) and then feeding the upload data in very slowly:
HTTP/1.1
POST /target-url
Content-Length: 1048576
Host: a a <pause> b <pause> c <pause>
BIG-IP ASM mitigates this and other low-bandwidth attacks by cataloging the performance of each request and then limiting the number of very slow connections per CPU core.
By establishing and enforcing a limit on these kinds of attacks, BIG-IP ASM allows access to legitimate clients with poor connections while defending the resources from malicious overloading.
HashDoS
All major web services platforms (e.g., Java, ASP.NET, and Apache) use the same fast hash algorithm for the dictionary tables. Their reliance on the same hash function made all of these platforms vulnerable to a clever attack released in late 2011 called the HashDoS attack. It worked by sending a single large POST filled with thousands of tailored form variables that overwhelmed the hashing function of any single target server. A single POST message, pre-computed and sent over a 33 K connection by a client as weak as a handset, could tie up a server for over an hour.
BIG-IP LTM mitigates this HashDoS attack through the application of a public iRule that drops any POST that contains an excessive number of form variables or an excessively large payload. By mitigating the problem at the ADC, organizations protect all back-end web server platforms at the same time. BIG-IP ASM mitigates this attack by using a signature and limiting the total number of parameters that can be sent on a single request.
Figure 8: F5 solutions protect all web service platforms against HashDoS attacks.