DDoS: Coordinated Attacks Analysis

DDoS: Coordinated Attacks Analysis This article will cover some concepts about a well-known attack named DDoS (Distributed Denial-of-Service) with some lab demonstrations as a Proof of Concept with countermeasures. In this paper we will focus on two types of attacks, which are "SYN flood" and "Slow HTTP DDoS Attack".t It is likely that you already know this attack named Distributed Denial-of-Service (DDoS) which is an extension of the classic well-known DoS (Denial of Service) that arise when the target server is overloaded with TCP or UDP requests to particular service (usually running on the port 80, web service, but this depends on the intentions of the attacker, any service could be vulnerable) leaving respond to genuine requests. The concept of "Distributed" is concerning that these requests are made from hundreds, thousands of infected machines (commonly called "zombies") which are governed by "botnets" (http:// en.wikipedia.org/wiki/botnet) in a coordinated manner at the same time, which is a sum of bandwidth, memory and processing consumption on the target that, generally, any server could not handle ending in a collapse of service targeted due to the failure to answer each request. The key to success in DDoS attacks is the number of "zombies" available on each Botnet. We can say that the greater the number of machines attackers, the worse the attack is. As an example, let s do the following quick estimate: 3000 hosts * 128 KiB/s (common home-users upstream) = 384000 KiB/s = 375 MiB/s Figure 1. Client establish a healthy connection with the server Figure 2. Crafted packages are sent to the server Page 32

That means it generates an average traffic resulting from 375 MiB/s, which is a sufficient bandwidth to collapse more than almost any system (even if it is protected) as the links that the ISP gives to the target servers are lower than this value. But this is not the only factor influencing the success of a DDoS attack; we can also mention the variant to be performed, misconfiguration of the target servers, the duration of the attack, etc. SYN Flood Attack As a regular reader of this Magazine, you probably know that the TCP/IP packets headers contain some flags, which have different functions, as for example, mark initiation, priority and finalization of the connection, etc. The conversation between the parties begins with the Three-Way Handshake and this is the key to the SYN Flood Attack. Well, this attack is based on sending a big amount of crafted packets to the target machine, enabling the SYN bit (S flag) in the TCP connection and altering the source IP address (by using spoofing techniques). The victim responds with a SYN/ACK (SA flags), whereas this is a legitimate connection and waits for an ACK (A flag) from the pretended client. Because of these fake addresses, the answer will never come and the sequence is not completed, causing the victim to become exhausted with connections leaving no room for genuine connections. Figure 1 shows a normal sequence of the Three- Way Handshake. While modifying the headers, the connection will be made as follows in the Figure 2. This is with no doubt one of the most known for their simplicity, effectiveness and notoriety attack since it is the main technique used by the currently worldwide known hacktivist group "Anonymous" who use DDoS as a tool of "rights claim". But it is clear that this does not always apply to ordinary cyber-criminals, who mostly use it as a tool of extortion against companies or governments and sometimes also for economic earnings. There are a lot of tools to perform a SYN Flood Attack, including the main weapons of "Anonymous", called LOIC (Low Orbit Ion Cannon) and HOIC (High Orbit Ion Cannon). These tools can be handled by the user or by using the mode "hivemind" through IRC channel or in a distributed and coordinated attack. They are very powerful tools and should be used responsibly. Figure 3. Many SYN packets will be sent to the server Page 33

However, in this article I will use another tool that does not have the attack as main purpose of use, I'm talking about Hping3, which is a great tool to test firewall rules, stress testing, package handling, among other uses, very useful for all sysadmin and IT security professionals. How can this attack be proven? As illustrated purposes and to complement this article, and taking into account the complexity of having a real botnet, I mounted a virtual environment in my lab, in which I use four machines (running Backtrack 5 R2) that generate to be many more to attack a vulnerable and unprotected server (running Fedora release 15 (Lovelock). The idea is to flood the victim with crafted packets (enabling the SYN flag), simulating an attack from hundreds of different hosts. The scenario is visible in Figure 3. As we have already mentioned, HPING3 is an excellent tool with the possibility of use in several situations, I recommend check out the help (hping3 -h) to see many more options. Table1. Parameters for running hping3 Parameter Function -S Set SYN flag --flood Sent packets as fast as possible. Don't show replies --rand-source Random source address mode. -d Fix the data size (packet body, in bytes). -p Destination port. To this demonstration, from each attacker machine, we run hping3 with the parameters in Table 1. It is important to have root privileges; therefore we use "sudo" to run the command. Given that the target is 192.168.1.109, that we will use the SYN flag, that we'll do in "flooding" mode, with each request with a different origin and the HTTP port, the command looks as follows: sudo hping3 -S 192.168.1.109 --flood --randsource -d 5000 -p 80. Other variants or values might apply, but for the purposes of testing, with these parameters is more than enough to cause a DDoS condition. Ok, let s start the attack from the four machines simultaneously (Listing 1). Meanwhile, let's see what happens on the target server. To do so, I will use the traffic analyzer "IPTraf" but you can use another one of your choice (wireshark or tcpdump for example). The traffic flow looks like this: Figure 4. After a few seconds, the site will become unavailable due to the number of requests that the server has to process. Listing 1. Starting the attack :~$ sudo hping3 -S 192.168.1.109 --flood --rand-source -d 5000 -p 80 HPING 192.168.1.109 (eth0 192.168.1.109): S set, 40 headers + 5000 data bytes hping in flood mode, no replies will be shown Figure 4. Traffic analysis on the server Page 34

When trying to access to the site under attack on port 80, a timeout it is obtained because the server cannot answer to legitimate requests for being saturated with malformed packets (Figure 5). As we have seen, a server that is not properly protected can be easily compromised using some few resources. However, this was just a Proof of Concept, which was performed on an internal network, simulating an environment similar to the Internet but without intermediaries (routers, proxies, etc) that can help mitigate risk using some countermeasures, but if we consider the mentioned in the first part ("Understanding DDoS"), into a real and massive attack, worldwide coordinated, without doubt these controls can be overwhelmed or ineffective. Slow HTTP DDoS Attacks This is the second attack discussed in this paper and one of my favorite in the way the web server is compromised without further resources available. Slow HTTP DDoS attack resembles the "Slowloris", an oldie attack to exploit a design flaw of handling concurrent connections. This is a technique that affects web servers (Apache mostly, but others too, including IIS) that is unique to cause a big impact with a minimal bandwidth requirement, even using a few household xdsl connections. The main idea is based on how the HTTP server handles threads, and unlike other attacks (such as the previously discussed "SYN Flood") in which you need hundreds, thousands of packets to flood the victim, the key is trying to maintain connections open as long as possible by sending a partial response to the server. Since the pool of available threads is finite, the collapse arise when it is saturated, resulting in a Denial of Service condition. It should be noted that this attack does not affect the entire server but the web service only, and the service is restored immediately once the attack has finished. Let s see in detail how this technique works: A client sends a GET request with a crafted header, which will not be sent to the server completely; such server, by design of the HTTP protocol, would wait for the rest of the data. To perform this, it is necessary to suppress the sending of CRLF (completion signal) of the packet header. If there are many connections at the same time, the server will keep those resources busy until stopping responding to new requests, including legitimate ones. How can this attack be proven? For this demonstration I did not need many attackers machines, since, as explained before, the key is to compromise a server with few resources available. Figure 5. Server cannot respond to a single and legitimate request Page 35

Therefore, I will use the following scenario, which is enough for demonstration purpose: VICTIM: IP: 192.168.1.109 HTTP SERVER: Apache/2.2.22 ATTACKER: IP: 192.168.1.104 SOFTWARE: slowhttptest-1.4 There are some tools to make a proof of concept of this attack. I will use a seven layer tool developed by Sergey Shekyan, named "Slowhttptest", which is useful for simulating (and make it real) Slow HTTP DDoS attacks. I strongly recommend this tool because of its flexibility to perform other tests (such as "Apache Range Header Attacks"), the ability to generate graphs and as it is the most current available tool to perform tests/attacks of Slow HTTP DDoS. The installation procedure is not included in this article, but do not worry, it is very well documented on the official website of the project. I will use the Apache monitoring module (serverstatus) in the target server to monitor activity before and during the attack demo. Listing 2. Command executed in the attacker machine $ slowhttptest -c 1000 -H -g -o attack_stats -i 10 -r 200 -t GET -u http://192.168.1.109 -x 30 -p 3 Figure 6. Healthy state of Apache server Page 36

Listing 3. Launching the attack Using: test type: SLOW HEADERS number of connections: 1000 URL: http://192.168.1.109/ verb: GET Content-Length header value: 4096 follow up data max size: 604 interval between follow up data: 10 seconds connections per seconds: 200 probe connection timeout: 3 seconds test duration: 240 seconds Sat Jul 28 08:58:47 2012:slow HTTP test status on 0th second: initializing: 0 pending: 1 connected: 0 error: 0 closed: 0 service available: YES Sat Jul 28 08:58:52 2012:slow HTTP test status on 5th second: initializing: 0 pending: 586 connected: 252 error: 0 closed: 0 service available: NO Sat Jul 28 08:58:58 2012:slow HTTP test status on 10th second: initializing: 0 pending: 573 connected: 427 error: 0 closed: 0 service available: NO Figure 7. Apache server status under attack Page 37

In a normal state, the server looks as in the Figure 6. In the attacker machine, execute the following command (Listing 2). -c number of connections (limited to 65539) -H type of attack to be performed (in this case, Slow Down en Headers) -g generate statistics in CSV and HTML formats -o output file -i Seconds. Interval between follow up data in seconds, per connection -r connections per second -t header/verb to use -u target URL, the same format you type in browser, e.g https://host[:port]/ -x max length of follow up data -p timeout to wait for HTTP response on probe connection, after which server is considered inaccessible With this setup, I will launch an attack type "Slow Down Headers", that means, we will make requests to the server but not complete them, forcing the server to maintain those connections into a reading state generating up to 1000 concurrent connections. As shown in the options, I will put as an option to generate an HTML file for later analysis of the attack. Now we are launching the attack (Listing 3). From the target server (before its takedown) I grabbed the connections state: Figure 7. As shown in the process slowhttptest attack, after 5 seconds after attack was launched, the service was not available anymore, which is easily checked when trying to navigate the site attacked and after a few minutes without being able to access will be obtained a timeout (See Figure 5). Once the attack finished, the tool give us the attack report (Figure 8). As you can see, is a powerful tool which should be used responsibly. It is also very useful for "Stress testings" against its own servers to test the load on them. As mentioned before, in this case the evidence is against an unprotected server, but in a real scenario, major infrastructure protected, these types of attacks retain their effectiveness, but even if we think as a possibility for distributed attack. Figure 8. Slowhttptest output report Page 38

Countermeasures I wanted to write in this section a magic formula to protect ourselves against DDoS, but unfortunately there is no effective way to defend ourselves completely against thousands of attacking machines, so what I can do is to provide some tips to mitigate the risk and not to be so exposed. Not to get too technical, as there are many vendors and variety of operating systems, etc., I ll give you some tips generalized that system administrators always should keep in mind to deal with DDoS attacks. The tips shown below apply for both types of attack outlined in this article (and for others too). Bear in mind Always keep abreast of software updates in use that is exposed to the Internet. One of the most useful techniques recommended is a mixed implementation of: Firewall SPI Load Balancer Reverse Proxy Limit the number of concurrent connections from a specific IP address (100 should be nice). Once that limit is reached, packets are dropped. Limit the number of connections per second. Limit the connection lifetime to a reasonable value. Taking into account that Apache is one of the most worldwide used HTTP Servers, follow its recommendations from the official documentation at: http://httpd.apache.org/docs/trunk/misc/ security _tips.html If your application has a specific audience target, for example, if the service is for people residing on Manchester, UK only, requests from China or Russia can be blocked by using IP ranges black list. Ramiro Caire Ramiro Caire is an IT professional & Security Consultant. His main interest areas range from Consultancy to Pen Testing, including Vulnerability Assessment, Networks Designing and Infrastructures. He is currently focused on Security Assessment, planning strategies and Cyber Security research. (ramiro.caire@gmail.com); Twitter: @ rcaire Page 39