A Method for Defeating DoS/DDoS TCP SYN Flooding Attack The SYNDEF Noureldien A. Noureldien College of Technological Sciences Omdurman, Sudan Email:
[email protected]
Izzeldin M. Osman Sudan University of Science and Technology Khartoum, Sudan Email:
[email protected]
Abstract TCP SYN flooding attack is a well-known denial of service (DoS) attack that exploits a TCP three-way-handshake vulnerability. Recently many prominent web sites face a new type of denial of service attack known as Distributed Denial of Service attack (DDoS). Organizations deploying security measures such as firewalls, and intrusion detection systems could face the traditional DoS attack. There is no complete solution neither for protection from DDoS attack, nor for preserving network hosts from participating in such an attack. This paper presents anew protection method called the SYNDEF. The SYNDEF protects from SYN attacks launched by DoS/DDoS tool and preserves at the same time network hosts from participating in a DDoS SYN attack. The SYNDEF is based upon favorable aspects of firewalls and intrusion detection systems. The main advantages of SYNDEF are its ability to limit incoming and outgoing SYN traffic, and defeating ACK saturation DoS attack.
1. Introduction 1.1 Motivation A service is any aspect of a computer system’s functioning that provides benefits to a user. Any intervention that reduces or eliminates the availability of that service is called a Denial of Service, often abbreviated DoS [1]. The most common kinds of DoS attacks involve tying up a server, CPU cycles, or resources, disabling web traffic, and mail bombs. DoS attacks are as old as the Internet itself. In fact the first connection between computers in the ARPAnet resulted in a crash of the receiving system due to some bugs in the communication software, a classical DoS attack [2]. Another prominent attack is the Internet Worm [3]. It was at the beginning of 2000 when a complete new quality of DoS attack started to be used widely. The so-called Distributed Denial of Service attack (DDoS) stroke a huge number of prominent web sites including Yahoo, Ebay, Amazon and Buy.com [4]. Statistical analysis confirms that vulnerabilities in computer systems have increased, and that denial of service exploitation of these vulnerabilities, as measured by web site defacements, has also increased [5]. Another statistical analysis indicates that DoS and DDoS vulnerabilities and tools have been growing up and become more and more available in the cracking community.
1.2 Problem Description 1.2.1
Background
Before data can be transmitted between a source host S and a destination host D, TCP needs to establish a connection between S and D. When a normal TCP connection starts, a destination host D, receives a SYN (synchronize/start) packet from a source host S, and sends back a SYN+ACK (synchronize acknowledge) packet. The destination host must then hear an ACK (acknowledge) packet of the SYN ACK before the connection is established (see Figure 1). This is referred to as the TCP three-way handshake [6]. The three-way handshake also initializes the sequence numbers for the new connection between S and D. Sequence numbers are needed by the TCP to enable reliable packet delivery. S sends and initial sequence number x with the first SYN packet; SYNx . D acknowledges the S’s packet with ACKx+1 and sends its own sequence number SYNy. Finally S acknowledges D’s packet with ACKy+1 .
S
D SYNx
LISTEN
SYNy , ACKx+1 SYN_RECIEVED ACKy+1 CONNECTED
Figure 1. Three-way Handshake When a SYN packet arrives at a destination port on which a TCP server in a LISTEN state, there is a backlog queue of finite size that keeps tracks of the number of concurrent connections that can be in a half-open connection state, called the SYN_RECEIVED state. This queue typically empties quickly since the ACK packet is expected to arrive in a few milliseconds after the SYN+ACK packet. When the maximum number of half-open connections per port is reached (i.e backlog queue is filled) TCP discards all new incoming connection requests until it either cleared or completed some of the half-open connections. 1.2.2
The Attack
The SYN flooding attack came out of the underground and into the public spotlight the first week of 1996 on an attack on the New York-based ISP Panix Public Access Network Corp. [4,7]. The following description of a SYN flooding attack is based on an in-depth description published online in Phrack Magazine [8]. The TCP SYN flooding attack exploits the three-way handshake design by having an attacking source host generate TCP SYN packets with random source addresses toward a victim host. The victim destination host sends a SYN+ACK packets back to he random source address and adds an entry to the connection queue. Since the SYN+ACK is destined for an incorrect (spoofed) or non-existent host, the last part of the three-way handshake is never completed and
the entry remains in the connections backlog queue until a timer expires, typically for a bout one minute (see Figure 2). By generating phony TCP SYN packets from a random IP addresses at a rapid rate, it is possible to fill up the connection queue and deny TCP services such as e-mail, file transfer, or WWW to legitimate users. There is no easy way to trace the originator of the attack because the IP address of the source is forged.
A
D Nonexistent (spoofed) SYN
LISTEN
SYN SYN
SYN_RECEIVED
SYN+ACK
Figure 2. SYN Flooding Attack 1.3 How is an attack launched? Two methods are used to launch SYN flooding attack, the traditional DoS tools and the more sophisticated DDoS tools. The source code for SYN flood engines for both DoS and DDoS is easily found on the web. In some cases no knowledge other than following a well-designed GUI is required to point the program at a target and to press the appropriate start button. 1.3.1 DoS Attack The DoS attack does two things: It sends a flood of SYN packets to a destination IP address and a destination port. The source IP address of those packets is spoofed. Here is what happens. The packet is routed over the Internet to the destination target. The destination target, a Web server for example, will receive a SYN packet requesting a connection on port 80. The Web server will reply with a SYN+ACK packet. The destination of the SYN+ACK packet is spoofed. If the spoofed IP address is legitimate, the computer that happens to correspond to the spoofed IP address will simply send a RST (reset) packet because it have no idea why the target machine is sending it a SYN ACK packet. Each of the SYN requests will take a space in the OS’s backlog queue waiting for an ACK packet that will never arrive. The end result is that, the target quickly depletes its backlog and the attacker will try to maintain a density of SYN requests to ensure the backlog never has the ability to clear. Once the backlog fills, the server will stop accepting SYN packets, stopping the service until the backlog clears. Because source IP addresses of the offending packets are spoofed, it is impossible for the victim to trace the attacker or to filter requests by source IP address [1].
1.3.2 DDoS Attack The year 1998 brought the addition of three novel concepts to traditional DoS attacks. The first is the idea of distributing the attack across several hosts. The second is the idea of coordinating the attack among many machines. The third is using the distribution system to thwart all attempts of discovering the origin of the attack [9]. These ideas constitute what is known as Distributed Denial of Service attack (DDoS). A DDoS is a type of an attack technique that saturates the victim system with enormous network traffic to the point of unresponsiveness to the legitimate users. A DDoS attack system has a complicated mechanism and entails an extreme coordination between systems to maximize its attacking effectiveness. The attack systems involved three system components: handlers, agents and a victim respectively. A DDoS attack is possible by the coordination of many systems. To clog up the victim’s network with enormous network traffic, the attacker needs to use a number of systems as handlers and agents. The attacker commands handlers and the handlers control a troop of agents to generate network traffic. To make a successful attack, an attacker first needs to have a number of systems to secure a bridgehead, usually large systems with high-speed network connection. To compromise such systems as much as possible and install DDoS tools on each of them, an attacker must find those systems with various techniques such as network port scanning, OS determination by TCP/IP stack fingerprinting and other known infiltrating techniques. Also, to hide those DDoS tool’s presence after installation, the attacker may use other techniques such as IP address spoofing. The installed DDoS tools turn the compromised systems into attack zombies. Once the DDoS tools are installed on many compromised systems, the attacker finds it easy to launch an attack by controlling agents through handlers via commands. Once an attack begins, the target is not able to handle the tremendous volume of the bogus traffic [5]. 1.3.2.1 DDoS Tools and Their Attack Methods Currently several security professionals identified a few DDoS tools and wrote analysis reports on them [10][11][12][13][14][15]. The one big problem is that, the variants of such tools with more sophistication are showing up continuously and, as a result, the abundance of such tools is amplifying the potential threats of DDoS. The table below shows some common DDoS tools and their attack methods [5]. As you may see in the table, most of the DDoS tools can be used to launch SYN flooding attacks.
Tools Trin00 Tribe Flood Network Stacheldracht TFN 2K Shaft Mstream Trinity, Trinity V3
Flooding or Attack Methods UDP UDP, ICMP, SYN, Smurf UDP, ICMP, SYN, Smurf UDP, ICMP, SYN, Smurf UDP, ICMP, SYN Stream (ACK) UDP, SYN, RST, Random Flag, ACK, Fragment,..
2. Protection from the Attack To provide protection from DoS/DDoS TCP SYN flood attacks, basic security measures are mandatory. These measures can spread over the organization’s entire Internet infrastructure, that includes boarder routers, firewalls, active monitors, load balancer, and the target host/server. Most current technical solutions to SYN flood attacks have a real impact on the speed and response of a network [16]. In some cases human intervention to turn on SYN flood protection might be needed once an attack is identified. In the following subsections several methods or products which are designed to preclude the attack at different layers are discussed. 2.1 Boarder Routers 2.1.1 Ingress Filtering Internet Service Providers (ISPs) can take actions against DoS/DDoS that include: eliminating routing of spoofed packets by discarding any packet that contains any RFC 1918 or reserved IP address in the IP source address or destination address. Also they should perform Ingress filtering [17] on their routers to drop packets with IP addresses outside the range of a customer’s network, so that they can prevent attackers from using forged source addresses to launch a DoS attack. The weaknesses of applying ingress filtering technique is that, it does nothing to address flooding attacks that originate from valid IP addresses, and may negatively affect mobile IP services [17]. 2.1.2 Egress Filtering Boarder routers of organizations usually represent the delineation between an organization line of control and responsibility and the world. SANS institute urged network administrators to adopt egress filtering which prevents one’s network from being the source of forged communications used in DoS attacks [18]. An egress filter is designed for implementation in the routers at the edge of a network Theses filters analyze packets as they are forwarded to their intended destination, looking for forged (spoofed) IP addresses. Since any particular network is assigned a specific subset of IP addresses, any packet containing an invalid IP address is assumed to be spoofed, and the filter drops such packets. This ensures that only IP packets with valid source IP addresses leave the network and thus protects the outside from spoofed packets. Egress filtering has two severe shortcomings. Firstly, there is little incentive for an Internet Service Providers to provide egress filtering since it does not protect from the attack, it only keeps an attacker from using your network for a DDoS attack. If egress filtering is not employed by a significant number of networks, it will not be a viable solution to DDoS attacks. Secondly, egress filtering will not detect internally spoofed IP addresses. 2.1.3 MULTOPS Bandwidth Attack Detection This solution postulates that if a network administrator (a victim) were able to detect an IP addresses that participate in a DDoS attack, then measures could be taken to block only these particular addresses. The solution is a heuristic one, and defines a data-structure that network devices (such as routers) can use to detect (and eliminate) DoS attacks. The Multi-Level Tree for Online Packet Statistics (MULTOPS) is a tree of nodes that contains packet rate statistics for subnet prefixes at different aggregation levels [19]. MULTOPS uses disproportional rates to or
from hosts and subnets as a heuristic to detect (and potentially stop) attacks. To collect these statistics, a tree-shaped data-structure keeps track of packet rates to and from those subsets of the IP address space that display disproportional behavior. MULTOPS has several limitations. Firstly, deploying MULTOPS requires router reconfiguration and possibly new memory management schemes. Secondly, and more importantly, MULTOPS can not detect a randomize forged IP addresses originating from a single attacking machine or a DDoS attacks that uses hundreds of zombies. Finally, if the attacker is able to mount a proportional attack, MULTOPSZ is useless. 2.2 Firewalls The next layer of defense against the SYN flood attack will come at the firewall. Most firewalls built today are designed to enable a form of protection against SYN floods. Firewalls are better suited to fight the attack because they tend to be designed to examine packets and maintain connection and state information of session traffic. As a countermeasure to DoS attacks, firewalls can be configured as a relay, as a semi-transparent gateway [20], or combine other techniques. 2.2.1 Firewalls as a Relay In this approach, the firewall responds on behalf of the internal host. A connection to the host is established only after the three-way handshake is successfully competed. During an attack, the firewall responds to the SYN sent by the attacker; since the ACK never arrives, the firewall terminates the connection with an RST packet, and the host never receives the packet (see Figure 3). For legitimate connections, the firewall creates a new connection to the internal host on behalf of the client, and continues to act as a proxy for translating sequence numbers of packets flowing between the client and a server [20]. The strength of this approach is that, hosts are completely shielded from DoS attacks, and never receives spoofed SYN packets. The weakness is new delays are introduced for legitimate connections.
A
Firewall
D
SYNx
SYN + ACK Timeout RST
Figure 3. Rely Firewall during an Attack
2.2.2 Firewall as a Semi-transparent Gateway In this approach, the firewall passes SYN packets to the host. When the host responds with SYN+ACK packet, the firewall forwards this packet to the client, and sends as ACK (preacknowledgement) packet to the host. If the firewall does not receive a legitimate ACK from the
client after some timeout period, an RST packet is sent to the host to terminate the connection (see Figure 4). For legitimate connections, the duplicate ACK arriving at the host is discarded by the TCP protocol, and future packets flow without intervention by the firewall. The strength of this approach is no delays are introduced for legitimate connections, while the weakness is that, the timeout period needs be carefully selected so that access is not denied to legitimate connections with long response times. A
Firewall
D
SYN
LISTEN SYN_RECIEVED
SYN + ACK ACK
CONNECTED
Timeout RST CLOSED
Figure 4. Semi-transparent Gateway during an Attack
2.2.3 Other Firewalling Approaches Many firewalls use state tables to keep track of the number of half open connections that are being passed through to a host/server, and once the limit is exceeded, the first one in the queue is the first one dropped. Another solution is the Network Pump that has been used to protect Multi-level systems (systems in which devices are categorized as high or low) from DoS attacks [21]. This solution has practical limitations. The Nozzle is another solution that incorporates network pump and firewall aspects, and comprised of a series of rings applied in a layering fashion. Although this solution provides a threshold for trusted traffic, it is limitation include, cost of performance, difficulty of configuration, and the order in which rings can be evaluated when thresholds are exceeded [22]. 2.3 Active Monitoring This category of solutions consists of using software agents to continuously monitor TCP/IP traffic in a network at a given place. An agent can collect communication control information to generate a view of all connections that can be observed on a monitored network. Furthermore, active monitors can watch for certain conditions to arise and react appropriately. An example for an active SYN flooding monitor is synkill from COAST Laboratory [20]. The synkill is built on an addresses database that classify addresses as never seen addresses (null), correctly behave (good), potentially spoofed addresses (new), and certainly spoofed addresses (bad). The classification is based on observed network traffic and administratively supplied input. Synkill operates as a state machine that examines each TCP packet address to determine its set membership and performs its actions accordingly. The state machine was designed to ignore SYNs for addresses that are in the new, good, or perfect states,
and sends a RST packet for addresses in bad or evil state [20]. Although this solution provides an active anomaly detection tool for SYN flooding, but the main disadvantages of this approach is that, it has the same weaknesses of a semi-transparent gateway firewall, and it cannot defend against DDoS attacks that used legitimate (good) addresses to launch the attack. 2.4 Load Balancing The last network defense against SYN floods is to distribute the flood against as many hosts or network devices as possible. In the case of commercial web sites or corporate sites that are well known and have considerable throughput the load balancing is probably already in place. A solution that is based on Class Based Routing mechanisms in the Linux kernel is proposed [23]. The solution is oriented to suite big sites that used load-balancing server and aimed to keep the web servers under attack responding to normal requests. The solution uses a number of configurable input queues on the load balancer and output queues on the web servers. If the traffic monitor in the load balancer detects a possible DoS attack, it slows the traffic from the origination IP address by assigning it to a slower queue or block it at the firewall. 2.5 Host Protection 2.5.1 Operating System Protection Many OS vendors are advertising a system level resistance to SYN flood type attacks. Increasing the addressable memory to the host backlog queue is one possible option. This approach is inefficient because even if the number was increased exponentially, a typical SYN flood engine could overwhelm the backlog, in addition, allocating more memory to the backlog will degrades the performance of the host. A simple response to SYN floods is the first packet reject method. The first packet sent by every host is discarded. This renders the common SYN flood attack ineffective, but all normal connection requests are delayed to the first retransmit of the SYN packet. Thus, all requests will be considerably slower. On the other hand, the SYN flooding attack may be simply adapted by sending each SYN packet twice [23]. 2.5.2 Random Drop In the random drop approach, when a SYN packet reaches a server with a full connection pending queue, it replaces one of the pending requests chosen at random. The client whose connection entry is dropped is notified with a RST. If an attacker previously generated the replaced entry, the RST is simply lost in the network [24]. If the replaced entry was from a legitimate client, the RST will cause the client’s attempt to communicate with the server to fail. The obvious drawback of this approach is that, the attacker can still deny legitimate connections. 2.5.3 Moving Target Defense Another host/server protection technique is the so-called moving target defense. Here the host under attack changes its IP address to avoid being attacked. The problem here is that, the legitimate users of the system need to be informed that the IP address has changed, which is usually done by updating the DNS system. Due to caching it can take up to a number of days until all clients are informed of the update. This is clearly unacceptable, as the effects are as severe as any DoS attack can be. Furthermore, attackers only need to incorporate DNS lookups into their tools in order to evade this protection [23].
2.5.4 Forgery Immunity: The GENESIS System Yet another host/server protection method is the Gibson’s ENcryption-Enhanced Spoofing Immunity System (GENESIS) [25]. The central premise behind GENESIS is that, the victim server should not devote any resources to a TCP connection until the validity of such a connection is verified. In other words, the server will forget about the connection until an ACK packet is received; no resources are committed and the server is not waiting for a response. To avoid ACK flooding attack, and to differentiate between packets from valid IP addresses and spoofed ones, GENESIS added an encryption token to the server’s SYN+ACK packet and verified the existence of that token in the client’s returned ACK packet. While GENESIS is extremely powerful in blocking TCP floods originates from spoofed IP addresses, it has many problems: it would require modifying server operating system as well as router hardware, in addition, extra delays are added due to server encryption/decryption operations. Furthermore, GENESIS has nothing to do with the participating of the server itself (or a host behind the server) as a zombie in a DDoS SYN attack. 2.5.5 SYN Cookies SYN cookies [26] is another server protection method in which the server responds to the SYN packet with a SYN+ACK packet with a sequence number calculated from the source address, source port, source sequence, destination address, destination port, and secret seed. Then the server releases all states. If an ACK packet is received the server verifies whether it is a valid response and establish/ignore a connection accordingly. SYN cookies have the same GENESIS limitations.
3. The SYNDEF Solution The solution we present for protection from TCP SYN flood attack is called SYN DEFeasance (SYNDEF). SYNDEF incorporates many positive features from earlier products and solutions. It is primary a stateful inspection firewall that combines the capabilities of an intrusion detection system (IDS). As a firewall all traffic from untrusted network must pass through SYNDEF to reach the protected host and it can be configured to block traffic based upon certain predefined criteria such as source address, protocol, …etc. Like an intrusion detection system, SYNDEF polices the traffic for attack signatures and triggers the appropriate alerts and actions. 3.1 How SYNDEF Works The SYNDEF is compromised from a Rule Base (RB) that defies the site security policy, a connection Pending List Buffer (PL) that buffers half-open connections, a connections State Table (ST) that maintains a dynamic set of open connections, and an Untrusted Buffer (UB) that logs suspicious connections. SYNDEF performs several processing steps on every TCP packet that passes through it, and on timer and threshold events. 3.1.1
Observed TCP Packets: The following paragraphs shows how SYNDEF works for both incoming and outgoing
packets.
(a) SYN Packets When SYNDEF receive a SYN packet it checks it against the Rule Base. If the packet is not accepted, its socket is logged and the packet is dropped (see Figure 5). If the Rule Base accepts the packet, a search process for the packet socket in the Pending List buffer is performed. If the packet socket is not found, the filled portion of the Pending List will be checked to see whether the Pending List reaches its pre-configured threshold. If the threshold is not reached the packet’s socket will be added to both, the connection Pending List buffer and to the connection State Table, then a timeout or a path round-trip timer is started for the packet’s socket and the packet is forwarded to its destination (see Figure 6). (path round-trip time denotes the time it take from receiving the SYN packet in the Pending List buffer to receiving the ACK packet as a response to the SYN+ACK packet). If the threshold is reached, the packet socket will be logged into the Untrusted Buffer and the packet is dropped; then the timeout for the SYN packets in the Pending List buffer is decreased (see Figure 7). If the packet’s socket is found to be registered in the Pending List buffer, it will be logged into the Untrusted Buffer and the packet is dropped (See Figure 7). S
RB
D
S
RB SYN
PL
D
SYN
SYN RST
SYN add
add
PL
Figure 5. SYNDEF generates RST packet if the Rule Base not accept the SYN packet.
ST
Figure 6. SYNDEF forward SYN to D if it is socket is not in PL and | PL|
