DDoS: Coordinated Attacks Analysis...sudo hping3 -S 192.168.1.109 --flood --rand-source -d 5000 -p 80. Other variants or values might apply, but for the purposes of testing, with these

Page 32 http://pentestmag.comEXTRA 05/2012(9)

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) leav-ing respond to genuine requests.

The concept of "Distributed" is concerning that these requests are made from hundreds, thou-sands of infected machines (commonly called "zombies") which are governed by "botnets" (http://

en.wikipedia.org/wiki/Botnet) in a coordinated man-ner 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 num-ber of "zombies" available on each Botnet. We can say that the greater the number of machines at-tackers, 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

DDoS: Coordinated Attacks AnalysisThis 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

Figure 1. Client establish a healthy connection with the server Figure 2. Crafted packages are sent to the server

http://en.wikipedia.org/wiki/Botnet

http://en.wikipedia.org/wiki/Botnet


That means it generates an average traffic result-ing 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 suc-cess 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 AttackAs a regular reader of this Magazine, you prob-ably know that the TCP/IP packets headers con-tain some flags, which have different functions, as for example, mark initiation, priority and final-ization 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 connec-tion 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 address-es, the answer will never come and the sequence is not completed, causing the victim to become ex-hausted with connections leaving no room for gen-uine 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 current-ly 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 ex-tortion 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 "Anony-mous", 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 "hive-mind" 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


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 han-dling, among other uses, very useful for all sysad-min and IT security professionals.

How can this attack be proven?As illustrated purposes and to complement this ar-ticle, and taking into account the complexity of hav-ing 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 (run-ning Fedora release 15 (Lovelock).

The idea is to flood the victim with crafted pack-ets (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.

To this demonstration, from each “attacker” ma-chine, we run “hping3” with the parameters in Ta-ble 1. It is important to have root privileges; there-fore 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 --rand-source -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 an-other 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 unavail-able due to the number of requests that the server has to process.

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.

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


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 sat-urated 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 net-work, simulating an environment similar to the Inter-net but without intermediaries (routers, proxies, etc) that can help mitigate risk using some countermea-sures, but if we consider the mentioned in the first part ("Understanding DDoS"), into a real and mas-sive attack, worldwide coordinated, without doubt these controls can be overwhelmed or ineffective.

Slow HTTP DDoS AttacksThis 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 "Slow-loris", 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 house-hold xDSL connections.

The main idea is based on how the HTTP serv-er 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 re-sponse 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 af-fect 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 head-

er, 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 le-gitimate ones.

How can this attack be proven?For this demonstration I did not need many at-tackers 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


Therefore, I will use the following scenario, which is enough for demonstration purpose:

VICTIM: IP: 192.168.1.109HTTP SERVER: Apache/2.2.22ATTACKER: IP: 192.168.1.104SOFTWARE: slowhttptest-1.4

There are some tools to make a proof of concept of this attack. I will use a seven layer tool devel-oped 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 (server-status) in the target server to monitor activity be-fore and during the attack demo.

Figure 6. Healthy state of Apache server

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


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


In a normal state, the server looks as in the Fig-ure 6. In the attacker machine, execute the follow-ing 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 re-quests to the server but not complete them, forc-ing 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 at-tack. 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, af-ter 5 seconds after attack was launched, the ser-vice was not available anymore, which is easily checked when trying to navigate the site attacked and after a few minutes without being able to ac-cess 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 sce-nario, 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


CountermeasuresI wanted to write in this section a magic formula to protect ourselves against DDoS, but unfortunately there is no effective way to defend ourselves com-pletely 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 ven-dors and variety of operating systems, etc., I’ll give you some tips generalized that system administra-tors always should keep in mind to deal with DDoS attacks.

The tips shown below apply for both types of at-tack 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 recom-mended 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 documenta-tion at: http://httpd.apache.org/docs/trunk/misc/security_tips.html

• If your application has a specific audience tar-get, for example, if the service is for people re-siding on Manchester, UK only, requests from China or Russia can be blocked by using IP ranges black list.

RAmiRo CAiReRamiro 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. ([email protected]); Twitter: @rcaire

http://httpd.apache.org/docs/trunk/misc/security_tips.html

http://httpd.apache.org/docs/trunk/misc/security_tips.html

mailto:[email protected]

DDoS: Coordinated Attacks Analysis...sudo hping3 -S 192.168.1.109 --flood --rand-source -d 5000 -p 80. Other variants or values might apply, but for the purposes of testing, with these

Documents