CHAPTER 1 INTRODUCTION

1.1 INTERNET SECURITY The Internet was originally designed for openness and scalability. However there were a number of issues that evolved with the evolution of the internet. For example, the Internet Protocol (IP) was designed to support ease of attachment of hosts to networks, and provides little support for verifying the contents of IP packet header fields. This makes it possible to fake the source address of packets, and hence difficult to identify the source of traffic. Moreover, there is no support in the IP layer to check if a source is authorized to access a service. Packets are delivered to their destination, and the server at the destination must decide whether to accept and service these packets. While defenses such as firewalls were added to protect the servers from the attacks and threats posed, a key challenge for these defenses was to discriminate legitimate requests for service from malicious access attempts. If it is easier for sources to generate service requests than it is for a server to check the validity of those requests, then it is difficult to protect the server from unauthorized and illegitimate requests that waste the resources of the server. This creates the opportunity for a class of attack known as a denial of service attack [1].

1.2 DENIAL OF SERVICE ATTACKS A denial of service (DoS) attack is an attempt to make a computer resource such as network bandwidth, CPU time, etc., unavailable to the legitimate users. It disrupts services by limiting the access to the machine or the service instead of subverting the attack. Such attacks are much easier to carry out than remotely gaining administrative access to the target system. Because of this, DoS have become very common on the internet. DoS attacks have different types and the earliest form of this is the flood attack. During a flood attack, the attacker simply sends more traffic than what the victim can handle, hence it requires the attacker to have a faster network connection than that of the victim. This is the lowest tech of the denial of service attacks and also

1

1.Control traffic directs the “zombies” to attack the victim

Attacker

Zombie1 Zombie2 src: random dst: victim

Zombie3

2.”Zombies” send streams of attack traffic to the victim

Victim

Figure 1.1 Structure of a typical DDoS attack

the most difficult to prevent. A large scale modification of the same attack is the distributed denial of service attack [1].

1.3 DISTRIBUTED DENIAL OF SERVICE ATTACKS A distributed denial of service(DDoS) attack is a coordinated attack on the availability of services of a given target system or network that is launched indirectly through many compromised computing systems. The services under attack are those of the “primary victim”, while the compromised systems used to launch the attack are often called the “secondary victims.” The use of secondary victims in a DDoS attack provides the attacker with the ability to wage a much larger and more disruptive attack while remaining anonymous since the secondary victims actually perform the attack making it more difficult for network forensics to track down the real attacker. A typical DDoS attack architecture is shown in Figure 1.1. In February of 2000, one of the first major DDoS attacks was waged against Yahoo.com, keeping it off the Internet for about 2 hours, costing it lost advertising revenue. More recently, attackers used a series of DDoS attacks against a variety of companies providing anti-spam services. These attacks caused many of them to shut down their services. DDoS attacks are relatively new and not well understood.

2

Flood attacks are also a form of this type of attack. One of the common DDoS flood attacks is the SYN flood attack [1].

Client SYN_SENT (active open)

Server LISTEN

Client FIN_WAIT1

Server CLOSE_WAIT (passive close)

(passive open) (active close)

SYN_RCVD ESTABLISHED FIN_WAIT2 TIME_WAIT ESTABLISHED CLOSED LAST_ACK

Figure 1.2 TCP Connection Establishment and Release

1.4 SYN FLOOD ATTACKS SYN flood attack represents 90% of a large number of DDoS attacks. Any internet service using the TCP protocol such as the Web, FTP, or mail is a potential target of a TCP SYN flooding attack. The attack means to tie up the memory of server machines with half–open connections. Many spoofed clients send an important number of connection set–up requests to a single server and, consequently, legitimate clients cannot connect any more to the server, whose resources have been depleted. The spoofed clients are typically named zombies, and operate under the control of a master through some infection process. At a specific time, the master sends to the zombies specific instructions to indicate the start of the attack and the address of the victim, and launch a global attack.

The server receiving a SYN packet sends a SYN/ACK packet back to the originating address. In an attack, the server will never receive the final ACK packet which would complete the handshake. In the best case, if it does exist, the server may receive a RST (connection reset) from that machine. When the server’s backlog queue is filled with such SYN packets, it can no longer accept SYN packets from legitimate users trying to connect. The SYN flooding attack involves many zombies that initiate, at the same time, incomplete TCP handshakes. This high volume of 3

attempts at handshakes will overwhelm a service victim [1]. The illustration of the TCP 3-way handshake is shown in Figure 1.2.

This project aims in analyzing the weaknesses of some of the existing schemes for the detection of the SYN flood DDoS attack and proposing a new mechanism which basically addresses some of these existing issues and effectively tries to block the successful execution of the attack. The rest of the report is organized as follows: Chapter 2 deals with the survey of the current techniques that exist to deal with the attack and some of the weaknesses these techniques posses. Chapter 3 discusses the need for a new method and the motivation for the proposed scheme. Chapter 4 discusses the implementation and the experimental setup under which the scheme was tested in a monitored environment. Chapter 5 presents the results and the conclusion of the work done.

4

CHAPTER 2 LITERATURE SURVEY

2.1

INTRODUCTION

A number of solutions have been proposed for defending against the DDoS SYN flood attack. These mechanisms have been classified into groups based on a number of parameters. The methods under each of this classification have their own accuracy and effectiveness in dealing with the attack. These existing mechanisms are briefly presented in the following sections:

2.2

REVIEW OF THE EXISTING SOLUTIONS

2.2.1. BASIC METHODS OF DETECTION AND PREVENTION A simple method to combat a SYN flood attack would be to use a “first packet reject” method. The first packet sent by the host is always discarded. Although a common SYN flood attack can be avoided by this method, a delayed re transmission or a transmission of each SYN packet twice can result in a successful attack [2].

Another technique, the moving target defense is employed in which the host under attack changes its IP address to avoid being attacked. However all the legitimate IP addresses need to be informed of the change by updating the DNS system which apart from taking days to update, the attacker needs to use DNS lookups to evade this protection [2].

One other method is to use several web servers which are accessed by load balancing tools which can manipulate the traffic using class based queuing or ipchains filtering [2].

5

2.2.2. BASED ON THE DETECTION TIME AND ACCURACY

With respect to this category, there are mainly two groups of detection techniques. One is offline based and the other is online based. Offline detection can be classified into two categories, viz., specific detection and anomaly detection. Specific detection techniques use rule matching

methods to see if the packets have any attack features [3]. The anomaly based detection has more accuracy than the rule match approach where normal traffic is analyzed and report if there is an anomaly. Principle Component Analysis (PCA), entropy computational method etc., have all been successful in thwarting the attack. The solution proposed in [4] made use of maximum and relative entropy and subspace to mine and analyze traffic anomalies. While the scheme in [5] used PCA to analyze the origindestination flow aggregation and entropy time series of traffic measure. Similarly, the solution proposed in [6] puts forward IP behavioral analysis in an online, real time DDoS attack detection and prevention system to distinguish between the attacker, victim and normal user and then block the traffic of the attacker. Finally, the mechanism used in [7] utilizes the Chi-Square method for the statistical analysis of the IP address and detects the attack based on the anomaly access of the post using the destination port number.

2.2.3 BASED ON THE LOCATION OF THE DETECTOR

Most of the current DDoS attack detection and prevention schemes can be classified into 4 categories according to the location of the detector, viz., at the victim server, at the source, between the source and the server or at the host side. The scheme that was presented in [8] detected the SYN flooding attacks at leaf routers that connect end hosts to the Internet. The key idea of method presented in [8] is that the SYN-FIN pair’s behavior should show invariant in normal network traffic and a non-parameter CUSUM method is utilized to accumulate these pairs. The scheme in [9] proposes an approach by using SYN Cache and Cookie method against SYN flooding attack. The basic idea is to use cache or cookies to evaluate the security status of a connection before establishing the real connection with a protected server. For those methods that provide detection at the victim server side, the main challenge is to consume all Cache and host when numerous connections are coming at the same time. The SYN Cookie can’t keep any 6

connection state of TCP, but calculate a certain Cookie value which is sent to the client. When client provides this Cookie in third round handshake, by calculating again, it can be determined whether the Cookie value which is new is equal to the last Cookie value. The solution presented in [10] compiled an IP address database of previous successful connections. When the network is suffering from congestion, an IP address that does not appear in the database seems more suspicious. The scheme in [11] proposes an active detecting method against SYN flooding attack. This approach is based on the fact that the normal half-open connection maintained inside a server exists as a result of network traffic congestions while the half-open connections caused by a SYN flooding are launched only by attackers. But when an attack comes across an existing congestion in the network, the accuracy of detection will be affected. The methods deployed at the attack source side can filter attack data before these cause harm to Internet. The mechanism in [12] detected SYN flooding attacks at attack source. By monitoring outgoing and incoming data stream, and comparing with normal stream model, the action of attack can be found. While the solution presented in [13] monitors the number of connections opened by each host at the border router of the source network. Entropy computation is used to identify the attack.

2.3

SUMMARY

The different mechanisms available to counter the attack have been seen. However, as it can be seen, each method has its own problems and do not effectively detect all the attacks launched at every point of time. This results in further work that needs to be done in this field to achieve a complete hundred percent efficiency in detecting these attacks before network performance is compromised.

7

CHAPTER 3 MOTIVATION

The proposed schemes so far have known to have succumbed to different modes of distributed attack. Some of the problems faced by the existing solutions include that the protocols are typically based on simple counting in a stateless environment that can be easily bypassed. Thus a mechanism that records the state of every TCP connection request that is active at any instant of time is needed. Moreover, attacks may use IP spoofing which makes the trace back of the attack even more difficult. The traditional defense mechanisms are more effective only in the later stages of the attack when the attacking signatures are obvious. Hence, the aggregation of numerous malicious packets on the victim server makes it difficult to launch a counter attack. Also distinguishing the legitimate packets from the attack packets becomes difficult in the later stages, because of which an early-stage detection mechanism is required. Also these schemes were tested in a environment where in multiple DoS attacks were launched and its performance evaluated. However the DDoS attack is of a much larger scale, due to which some of these mechanisms either tend to become inefficient or tend to fail in dealing with the attack. This led to the need to identify a more robust model that could mainly address all the problems faced by the current solutions such that the multistage distributed flood attack can be detected and prevented more effectively.

8

CHAPTER 4 THE IMPLEMENTATION
4.1 INTRODUCTION Upon analyzing the weaknesses in the existing solutions and realizing the need for a more robust and an efficient technique to detect these attacks, a new solution that would solve some of the issues with the current counter-mechanisms has been proposed. This chapter is organized as follows: Initially a brief overview of the concept is given. Then the implementation details of the proposed solution are seen through the schematic block diagram. Further, the software design and the tools used for this scheme are discussed and finally details of the experimental setup in which the performance and the efficiency of the implementation was tested is given. 4.2 OVERVIEW OF THE SCHEME The implementation is basically divided into different modules, with each module having a specific functionality that acts as a detection mechanism if a multi stage distributed flood attack is launched. Amongst the exiting schemes, every solution addresses only one issue - attack detection. Moreover, since the performance of most of these efficient schemes was measured against a DoS attack, it is proposed to verify the new scheme against the same attack and check its efficiency if a large scale DDoS attack were to attack the system. Keeping all these factors in mind, a multi stage detection mechanism has been established. Firewalls are basically one of the defense mechanisms that can be used to deal with the SYN flood attack. Using iptable firewalls in a linux environment, the iptable is reconfigured such that a multi stage detection mechanism is facilitated. Since each stage combines the best features of every algorithm proposed, it is proposed that apart from the increase in efficiency and effectiveness in thwarting the attacks almost fully, the overall load on the detection module especially when it is flooded with millions of packets within a few seconds can also be reduced. The implementation thus behaves like a multi stage filtering mechanism. The iptable uses the functionality of a monitor module where in the protocol filters and blacklists those IP addresses which might be potential attackers. Thus, further packets from the blacklisted IP addresses will

9

be dropped by the firewall, thus preventing the successful run of a DDoS attack. The implementation of this solution is seen in a more detailed manner in the following sections: 4.3 SCHEMATIC BLOCK DIAGRAM iptables NETWORK FIREWALL iptables CONFIGU-RATION FILE

SYSTEM LOG FILE

PROCESSING MODULE C++ PROGRAM

NETWORK APPLICATION

SYN-MATCHES

TCP-MATCHES

Figure 4.1 4.4 SOFTWARE DESIGN Iptables are Linux’s firewall that has been a part of the kernel since version 2.4. It is often referred to as a packet filter as it examines each packet that is transferred to and from the host. Iptables have three components, viz. tables, chains, and rules which form the building block of the firewall. Figure 4.2 shows the representation of these components of the iptables firewall. (i) Rule: Consists of conditions for choosing the packet and all the things that can be done with the packet (ii) Chain: Rules are grouped into chains. It is a set of rules determining what to do with a packet. The default chains are; input, output, and forward.

10

(iii)Table: Chains are grouped into tables. There are 3 basic tables in the iptable; filter, NAT and mangle each having a default policy. This project work focuses on the filter table.

Rule Tables Chain Rule Rule Chain

Figure 4.2 Iptables Structure The filter table is the default table for any rule. This table can be used to allow or block traffic. Rules are added to the table. Once a rule is matched, an action is taken with respect to the packet which can be either ACCEPT or DROP. This is referred to as a default policy. Generally the default policy in the firewall is to DROP all the incoming packets and to ACCEPT packets that maybe from trusted IP addresses. However this is not modeled very well to the real world environment especially with all the IP addresses used for data and video streaming and torrents. As a part of the first stage of implementation, the default firewall policy in the filter table is set to ACCEPT all packets. Then add rules to DROP or specifically block packets that may be from specific IP addresses or address ranges, or for certain ports that may have a private or no service running. The challenge now lies in identifying those ports from which the packets must be blocked. That is blacklisting the ports that may be a potential source of a DDoS flood attack. This is a part of the monitor module in the implementation. Initially a simple mechanism is used as part of the second stage of implementation to identify whether a potential DDoS attack is about to occur. The firewall rules are configured such that all the packets that arrive at the interface are forwarded by the firewall to the monitor module to determine whether the request is from a legitimate IP address or not. In the monitor module, a variable COUNT counts the number of TCP SYN requests from any particular IP and logs it into a file. The file is periodically monitored to see if the number of requests 11

exceeds a particular threshold value that is favorable for the given connection in a given time interval. If it does exceed this threshold, the particular IP is blacklisted and further packets from it are blocked. If the threshold value is satisfied then the next stage of the module is executed. In the third stage of the implementation the firewall rules are reconfigured such that the IP addresses that may have to be blacklisted can be identified. In order to accomplish this, the iptables logging mechanism is altered. The implementation is as follows; the firewall logs all the TCP and the TCP SYN packets separately identified by different and unique prefixes for each packet, so that they can be filtered out separately. After that is done, a system command grep is used to filter the SYN packets alone from the system log file and create two separate files; one for the TCP SYN packets and the other for the rest of the packets. A separate C module is then called which processes the two files and updates all the information about the active connections such as the number of TCP packets, SYN packets for each IP address etc. If there is any change in the parameter value and is above the minimum threshold value for the given connection, then the corresponding IP is blacklisted. Once the IP to be blacklisted is identified, a script is then executed immediately which adds the corresponding to rules to the firewall to DROP all the packets that arrive at the host from that IP address. This address is added to a separate table that is maintained with the list of all the IP addresses that have been blocked. The purpose of maintaining a list of blocked IP addresses is, that if the simple attack detection method in the first stage fails, then instead of completely executing the other stages in the module, the IP address under suspicion can simply be matched against those already in the list does saving some execution bottleneck. Thus there is a step by step filtering of the packets at each stage which will thwart most of the DDoS attacks.

12

4.5 EXPERIMENTAL SETUP The entire setup of the implementation in a monitored environment can be described as follows: The first block is a packet generation software called Mausezahn (mz) which is an open-source standard for packet generation in linux. The software runs through a "bash" script, and provides options to script any type of packet with any possible (and some impossible) packet configurations. The default destination for these packets is the local ethernet port (eth0). The packet generation is done by the following script commands:

mz -t tcp mz -t tcp flags=syn

The second functional block is at the network interface, that is, the firewall. The incoming packets are viewed, from a practical standpoint, as just more traffic coming into the local ehternet port (eth0). The "iptables" firewall configuration file is consulted on how to deal with the packets. The particular rules of interest are the following:

iptables -I INPUT -p tcp -j LOG --log-prefix ALLTCP111 iptables -I INPUT -p tcp --syn -j LOG --log-prefix SYNTCP222

LOG tcp -- anywhere anywhere LOG level warning prefix `ALLTCP111' LOG tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN LOG level – warning prefix `SYNTCP222'

These rules log the entire packet data into the system log file "/var/log/messages", which is the third functional block. The log data contains information like Incoming port, Outgoing port, Source IP address, Destination IP address, Protocol, Flags set (SYN, FIN, RST, ACK, ACK/SYN), Time To Live, Type of Service, Window Size, and some more state information. These are logged along with a number of other system logs performed by the logging daemon. The iptable logs are differenctiated by prefixes - ALLTCP111 and SYNTCP222 for general TCP packets and SYN packets respectively. 13

In order to extract relevant log information, two kernel-level, user-defined "bash" scripts are executed, namely "syntrack" and "tcptrack", which retrieve data from the log and write it to seperate files "SYNMATCHES" and "TCPMATCHES". These files constitute the fourth block of the implementation structure. The scripts can be scheduled to run periodically using KORN, the linux-based task scheduler daemon, and hence constantly update the two files mentioned above.

The fifth block is a C++ program-module that processes these files. The processing involves tracking the number of TCP and SYN packets that are coming in from different IP Addressess, and notifying the firewall if the processing indicates that any IP Address has over-shot the allowed threshold and is hence suspected of being a point of attack launch. This processing is based on calculating the parameter value for that IP Address.

The notification is done by means of executing a system-call that updates the firewall configuration file. This system-call is another user-defined "bash" script which dynamically adds configuration rules to iptables. The syntax for the system call is given below:

system ("proj1