HTTP traffic is dominating the internet. In fact, when people are asked about the internet, they are sometimes sure the internet is their browser that connects them to everything online. Data centers also experience a high volume of HTTP traffic and many enterprises are seeing more and more of their revenues coming from online sales. However, as the popularity grows, the risks grow with it, and just like any protocol, HTTP is vulnerable to attacks. Attackers use Denial-of-Service (DoS) attack techniques in order to create denial-of-service on web servers. Such attacks are used to make a point, make some profit or simply for fun. In this blog post I will describe the common DDoS attacks that are launched against HTTP servers.
First, HTTP is running over TCP. As a result, the web server can face many TCP-related attacks. When planning HTTP service protection, it is important to keep in mind that the attack surface is much broader than just the HTTP protocol. Any DDoS attack today is using multiple vectors to create a denial-of-service, and in order to prevent it, one should be able to protect from all of these vector. See also a discussion on more exotic attacks at the end of this post.
The common TCP network attacks are:
SYN flood – maybe the oldest of them all, but still used as a vector in most attacks. The attacker is sending many SYN packets which are sent to the server. Since the attack does not need to see the return traffic, the IPs do not have to be real and are usually spoofed IPs. This fact also makes it harder to understand where the attack is coming from, and help the attacker to remain anonymous. The SYN attacks techniques have evolved throughout the years, together with the mitigation techniques.
The main idea behind a SYN attack, is that every SYN is opening a session in the TCP stack – the stack needs to preserve some memory to keep the session state. Sending a lot of SYN packets can easily exhaust the memory allocated for sessions (the session pool) in the TCPIP stack. SYN attacks have grown more sophisticated over the years. The most recent variant is the Tsunami SYN Flood Attack which uses large packets with a TCP SYN bit to saturate the internet pipe while causing damage to the TCPIP stack in parallel.
- Other than SYN floods, the TCP network attack surface is exploiting all other TCP flags as well- ACK floods, RST floods, Push-ACK floods, FIN floods and any combination of these bits are all used in various attacks. Attackers will try everything, as long as it has the potential to create havoc.
The HTTP L7 attack surface is wide, and consists of several vectors, which will be discussed below. The main difference between the HTTP L7 attacks, and the network attack described above, is the fact that an HTTP transaction requires a valid IP – one cannot spoof an IP for an HTTP request, as the TCP handshake requires the IP to accept and respond to the packets. If you do not own the IP, you will never be able to establish the connection. This difference used to pose a big problem to attackers who wanted to use HTTP attacks, however, in today’s world with the recent IoT botnets that rule its attack surface, owning a large amount of real IP addresses is no longer considered an impossible challenge. Once the connection is established from a real IP address, several options are available for attacks:
- Garbage flood – the least sophisticated attack vector is opening a connection to the HTTP port (usually ports 80 or 443) to send garbage binary data to it. Such an attack is usually overlooked in mitigation as the server, as well as the security devices protecting it, are expecting “valid” HTTP traffic. The purpose of this attack is usually to flood internal buffers and queues in the web server, and even in the mitigation devices in front of it. The attack is also sometimes used to saturate the internet pipes, although there are easier attack techniques to do that.
- GET flood – the most common usage of the HTTP protocol is an GET request. The GET flood uses the same GET request method, but in a high volume. The attacker is trying to make the server over-load and stop serving legitimate GET requests. This attack is usually following the HTTP protocol standards to avoid mitigation using RFP compliancy checks.
- Other HTTP methods– other than the common GET method, the HTTP protocol allows other methods as well, such as HEAD, POST and more. Attacks using these methods are usually used in parallel to a GET flood, in order to try and attack less common areas in the server code. A POST request is usually larger than a GET request, and as a result a large POST request is less suspicious than a large GET request, and more likely to get to the server un-noticed by the mitigation devices protecting it. This allows more memory consumption on the server, and more chances for denial-of-service.
- Reverse Bandwidth floods – these attacks are trying to saturate the internet link from “behind” – they are trying to cause the server to send traffic that will saturate the up-link of the server to the LAN or to the internet. Even if a server has just one large page, attackers can send many requests for this specific page. This will make the server send it again and again and saturate the server’s own uplink connection. This technique is used to avoid detection from mitigation devices, who usually measure the inbound traffic for saturation, and not always the outbound traffic as well.
- HTTP fuzzers and misbehaved fields – these attacks are sending garbage or bad values on specific HTTP protocol fields. The attack will send a G3T request (instead of a GET request), send traffic on HTTP version 1,1 (instead of HTTP 1.1) and so on. Another option is to use random values in the field place in the communication. The attackers are trying to crash the web server, which will happen if the server is not checking for the validity of these input values. Note that unlike previous attacks, this attack does not have to consume high traffic volume or high PPS – it is trying to create damage “under the radar” of the mitigation devices.
- Low and slow attack – these attacks consume even lower BW and PPS than the fuzzers. The attack is using very little traffic and thus it is harder to detect. This attack is sending legitimate HTTP traffic, but at a very low pace. The attack will send a GET request using many small packets with a large time gap between them – the attacker will first send the “G” in its own packet, after a while he will send the “E” and after some more time the “T” and so on. While this is a legitimate behavior according to the HTTP and TCP protocols, this behavior is consuming a lot of resources from the server – it has to keep the connection open, waiting for the full request to arrive. Since the connection pool is limited, it is very easy to reach pool saturation, with very little traffic.
- Cache bypassing attacks – many web servers today are behind CDNs, allowing faster delivery of the content to the global users around the world. The CDN gives the server owners a false sense of security, since they expect the CDNs to stop any flood before it gets to their server. However, the CDN security measure can be easily bypassed by sending requests for non-cacheable content. Requests for dynamic content as well as non-existing content will make the CDN reach to the servers. The servers can be attacked using all of the attacks described in this post, and the CDN will actually be used as part of the attack itself.
- OWASP top 10 attacks – on top of the above attacks, which are denial-of-service attacks, there are many more HTTP attacks which go deeper into the HTTP protocol, and try to gain other assets from the servers. Attacks such as cross-side-scripting, SQL injections and more are trying to make the server serve content it is not supposed to serve. The top 10 attacks of this nature are known as OWASP top-10. These are usually not denial-of-service attacks, and a Web Application Firewall (WAF) provides the best mitigation for them. The WAF can be effective as either an on-premises device or a service in the cloud.
It is important to note that protecting the web service itself is not enough to guarantee service. Other attacks can still cause the service to be down. One example is a pipe saturation attack, even with UDP garbage traffic that has nothing to do with HTTP. Another attack is the recent SMB attack that was found in the wild. All these attacks are aiming at the services around the web server – internet pipe, other non-HTTP services offered by the same device, and more, in order to create denial-of-service.
Another type of attack is to attack the DNS server that is used to translate the domain into an IP address. Such a method was used in the famous Dyn attack in Oct. 2016 using the Mirai botnet. It is important to note that the attackers were able to cause a denial-of-service to large web sites such as Twitter and Amazon, without sending even a single packet to the web sites’ direction. Instead, the attackers attacked the internet infrastructure that allows users to get to these sites – they attacked Dyn which served as the DNS provider to these services, and caused the sites to go into a denial-of-service state.
There are many HTTP attacks that can cause denial-of-service. The best way to mitigate these attacks is to choose a protection service that can handle all of them – attacks using high bandwidth or PPS, and attacks using low traffic, attacks directly related to HTTP and attacks on related services. The only way to establish real protection against HTTP attacks is to use adoptive services, which evolve and develop over time. Having the right equipment is only half the battle. It is important to work with a security centric company that can provide expert advice under attack, and evolve and develop its tools to handle the evolving attacks. For web service, as well as for the entire internet, every down second counts. Keeping your site always up is not an easy task, but it can be done using the right products.
Download “Web Application Security in a Digitally Connected World” to learn more.
Lior Rozen is the Director of Technologies for Radware. With over a decade of experience, he is a cyber-security expert, architecting innovative cyber security solutions and deployments tailored for Radware’s customers’ needs. Before taking his current position, Lior was the director of R&D for Radware’s DefensePro, managing all R&D aspects of this DDoS-protection market-leader technology. Lior led the shift to virtualized-ready software architecture, while promoting partnerships with leading security companies. Lior writes about network security and technology.
This is a Security Bloggers Network syndicated blog post authored by Lior Rozen. Read the original post at: Radware Blog