Tech Mavens

Home

Countering SYN Flood Denial-of-Service Attacks

by Ross Oliver
Tech Mavens

August 29, 2001

Abstract

Denial-of-service attacks continue to plague Internet sites.  One type of denial-of-service attack, the SYN flood, is particularly effective at disabling web servers.  This report examines the details of a SYN flood attack, describes methods of defending against such attacks, and presents benchmarking results of four commercial network products against actual SYN flood attacks.

Introduction

Denial-of-service (often abbreviated as DoS) is a class of attacks in which an attacker attempts to prevent legitimate users from accessing an Internet service, such as a web site.  This can be done by exercising a software bug that causes the software running the service to fail (such as the “Ping of Death” attack against Windows NT systems[1]), sending enough data to consume all available network bandwidth (as in the May, 2001 attacks against Gibson Research[2]), or sending data in such a way as to consume a particular resource needed by the service.

A SYN flood is one particular kind of denial-of-service attack.  It falls into the third category described above. Named for the SYN (short for Synchronize) packet that initiates a TCP/IP connection, a SYN flood consumes all available slots in a server’s TCP connections table, and by doing so, prevents other users from establishing new TCP/IP connections.  One service that is particularly vulnerable to a SYN flood attack is HTTP, used by nearly all web servers.  Web browsers establish one or more new TCP/IP connections to the web server for every web page viewed, so if new connections cannot be established, the web server is essentially unusable.

How SYN Floods Work

A SYN flood exploits a basic weakness in the TCP/IP protocol.  Establishing a new TCP/IP network connection requires a three-step process:

1. The originator of the connection (such as a web browser) initiates the connection by sending a packet having the SYN flag set in the TCP header (referred to as a “SYN packet”).
   
2. The receiver responds by sending back to the originator a packet that has the SYN and ACK flags set (a “SYN/ACK packet”)
   
3. The originator acknowledges receipt of the 2^nd packet by sending to the receiver a third packet with only the ACK flag set (an “ACK packet”).

Only after this three-step handshaking process is complete is the TCP connection is considered “open” and data exchange can begin between the originator and recipient. Between steps 2 and 3, the receiver must keep a record of this incomplete connection while waiting for the ACK packet.  Most systems have only a limited amount of space for such records. If too many connections are left in the incomplete state, the receiver will run out of space, and requests for new connections from legitimate users will be lost. Most TCP/IP implementations impose a relatively long timeout period (several minutes) before incomplete connections are cleared out.

During a SYN flood attack, the attacker sends a large number of SYN packets alone, without the corresponding ACK packet response to the victim’s SYN/ACK packets. The victim’s connections table rapidly fills with incomplete connections, crowding out the legitimate traffic. Because the rate of attacking SYN packets usually far exceeds that of normal traffic, even when a table entry eventually is cleared out, another attacking SYN packet rather than a legitimate connection will fill it.

SYN flood attacks received international attention during February of 2000.  Major Internet sites including CNN, Yahoo, and Amazon suffered SYN flood attacks over a period of several days.  After several months of investigation, law enforcement officials arrested a 15-year-old Canadian youth who used the alias “Mafiaboy” and charged him with perpetrating the attacks.[3]  In January 2001, the youth plead guilty to 56 criminal counts relating to the incident.[4] CNN and other victims claim the attack caused damages totaling $1.7 billion.[5]

How could a teenage boy cripple multi-million dollar enterprises such as CNN and Amazon?  Three characteristics make SYN flood attacks difficult to counter.  First, data packets that cause other types of denial-of-service attacks, such as Ping of Death or Smurf, can be blocked entirely by a firewall.  But because SYN packets are a necessary part of legitimate traffic, they cannot be filtered out altogether.  Second, SYN packets are relatively small, so an attacker can send large numbers of packets using relatively low-bandwidth Internet connections. Finally, because the attacker does not need to receive any data from the victim, the attacker can place random source IP addresses in the attacking packets to camouflage the actual source of the attack, and make filtering all but impossible.

Responding to SYN Floods

Increasing the size of the network connections table would seem to be the most straightforward way to mitigate the effect of a SYN flood. However, the table is normally part of the operating system kernel, and may not be configurable.  Even if the table can be resized, it would need to be enlarged by several orders of magnitude to be effective against a SYN flood of more than a few seconds.  Such a large table would significantly degrade network performance, or require major redesign of the network code within the operating system kernel.

CERT has suggested employing “hot spare” servers to be placed in service during an attack[6].   This is essentially an attempt to “out horsepower” the attacker.  However, having expensive server equipment sitting idle until an attack occurs is a very expensive option, not likely to be economically viable.

Identifying the origin of the attack is another approach.  But if the attacker uses forged source IP addresses, locating the source would involve tracing the actual network traffic through routers and ISPs, a very time-consuming process.  In the case of a distributed attack, identifying all compromised machines and contacting their respective owners could take weeks or even months.

To provide the ability to endure SYN flood attacks, at least temporarily, manufacturers of firewalls and other network security devices have developed a variety of defense methods to incorporate into their products.  Some of the methods currently on the market include: 

• SYN threshold: establishes a limit or quota on the number of incomplete connections, and discard SYN packets if the number of incomplete connections reaches the limit. This is the simplest type of SYN flood defense, and is implemented in several firewall products.
   
• SYNDefender: when a SYN packet is received, the firewall synthesizes the final ACK packet in step 3, so the receiver does not need to wait for the actual ACK packet from the originator. Check Point Software Technologies, Ltd. developed this technique for its Firewall-1 product [7].
   

• SYN proxy: the firewall synthesizes and sends the SYN/ACK packet back to the originator, and waits for the final ACK packet. After the firewall receives the ACK packet from the originator, the firewall then “replays” the three-step sequence to the receiver.
   

• SYN cookies: this method attempts to eliminate the need to store incomplete connection information by including a package of information, or a “cookie” in the SYN/ACK packet sent by the receiver to the originator. When the originator responds with the ACK packet, the cookie is returned and the receiver is able to extract the information needed to rebuild the connection.

Measuring the Effectiveness of SYN Flood Defense Methods

To find out how effective these methods are against an actual SYN flood attack, the author selected the following products to test:

• Cisco PIX 520, offering SYN threshold

• Nokia IP330 with Firewall-1, offering SYNDefender

• Netscreen 100, offering SYN proxy

• AppSafe AS 2500, offering SYN proxy

The author created a test environment to simulate a typical web server and web browser configuration.  The test environment consisted of the following components:

Web server: Intel-based PC running Linux Red Hat 7.1 operating system, and Apache 2.0 web server daemon.

Web client: Intel-based PC running Windows 2000, and wget utility[9] to retrieve web pages from the web server.

Attack host: Intel-based PC running Linux Red Hat 7.1 operating system.

Firewall to be tested.

Each system was equipped with a 100-megabit/sec. Ethernet interface, and networked in the following manner:

To generate the SYN flood attack, the author created a program that could construct and transmit large numbers of SYN packets. To simulate the most hostile attack possible, the program was designed to assign random source IP addresses in the SYN packets, to defeat attempts at filtering by IP address. The rate of transmitted SYN packets could be varied to identify the threshold of reliable defense for each tested device.

To measure the web server response time, a set of wget commands were collected into a DOS batch script, along with a timing utility to record the elapsed time of each pass through the script. The script would continuously repeat the wget sequence and report elapsed time of each pass until manually interrupted.

Test Methodology

Each product was installed in turn in the "firewall" position in the test network, and all devices were configured as needed to allow both the web client and attack system to contact the web server.  After the configuration was verified to be operational, the web page fetch script was started on the web client host.  The SYN flood generator was activated for 60 seconds at a given rate of SYN packets per second. Any change to the web server response time was then noted. The attack was repeated with an incrementally larger rate of SYN packets until the web client could no longer connect to the web server.

Test Results

Baseline

When no attack was underway, the running time of the web page fetch script was 1.38 seconds.  To measure the effect of a SYN flood with no firewall protection, a SYN flood attack of 100 SYNs/sec. was launched against the web server with no firewall in place. The network connections table of the Linux operating system filled to capacity after receiving 121 SYN packets (as reported by “netstat  –an”). Once the connections table was full, all attempts by the web client to access the web server failed with “connection timed out.” The connections remained in the SYN_RECEIVED state for five minutes, making the web server unusable for that period of time.

Cisco PIX 520

The Cisco PIX 520 has a default SYN threshold (called “embryonic connections” by Cisco) of 3000. When an attack of 100 SYNs/sec was launched, the result was much the same as with no firewall: the Linux connection table filled in just under 2 seconds, and the web server became unusable.

The test was repeated with the SYN threshold of the PIX changed to 50. In this configuration, the PIX discarded the legitimate SYN packets along with the attack. As a result, only about 1 in 100 attempts to connect to the web server succeeded.  The only advantage was that service resumed immediately after the attack ceased.

[UPDATE: the newest version of the PIX software implements a different form of SYN flood defense, which may be more effective than a simple threshold scheme.  Future testing is planned to determine its capabilities]

Nokia IP330

The IP330 firewall appliance was able to successfully defend against a SYN attack of up to 500 SYNs/sec. Web server response time increased, but continued to function.  At a rate greater than 500 SYNs/sec., the web client could not connect to the web server.

Netscreen 100

The Netscreen 100 contains a configurable parameter called “SYN Attack Threshold.” The value of this parameter is the number of incomplete connections that the Netscreen 100 will allow to pass through before it begins to proxy connections.  The default value is 200.  At this value, the connections table of the web server being protected filled up in the same was as with no firewall.

After reducing the value of “SYN Attack Threshold” to 50, the Netscreen 100 was able to defend against an attack of 14,000 SYNs/sec. Response time did increase from the baseline of 1.38 seconds to an average of 22 seconds, but nearly all the web client’s page requests continued to be served.  As the attack increased above 14,000 SYNs/sec., the number of failed connections grew exponentially, so that the web server became unusable.

AppSafe AS 2500

The SYN flood defense capability of the AppSafe AS 2500 is not enabled in the factory configuration.  Before testing, “SYN Flood Mitigation” was activated in the “Attack Mitigation” section of the configuration.  Also, the “Unknown Treatment” setting of the “SYN Flood Parameters” was set to “suspicious.”  This setting controls the AppSafe’s treatment of connection requests from an IP address from which no successful connection has been received.

The AppSafe AS 2500 was able to defend against an attack of 22,000 SYNs/sec.  This was the maximum rate the attacking host could generate.  Response times remained at the baseline of 1.38 seconds, and no failed connections were recorded.

Evaluating Performance Results

The test results show the level of defense against SYN floods offered by each product, but how can an organization determine determine which product supplies an adequate defense?  If we assume an attacker transmits SYN packets that are 64 bytes long, and is able to use 100 percent of the available bandwidth, we can compute the intensity of an attack from various types of Internet connections:

This table shows that a single home-based attacker can successfully disrupt the operation of an unprotected web server, or one behind a Cisco PIX.  The Nokia/Firewall-1 product could protect against a single home-based attacker, but would be vulnerable to a distributed attack involving as few as three DSL users.  In contrast, both the Netscreen 100 and AppSafe could defend against an attacker using one or even several T1 connections.  The Netscreen could still be overwhelmed by a large-scale distributed attack, and since the test was limited to 22,000 SYNs/sec., the performance of the AppSafe under such conditions is unknown.

Very little information has been published on measuring the instances and characteristics of SYN flood attacks actually happening across the Internet today.  One study, based on measurements of SYN flood attack "backscatter,"  observed over 12,000 attacks against more than 5,000 individual IP addresses during a one-week period.  Of the attacks observed, 46 percent exceeded the 500 SYNs/sec limit of Firewall-1, while 2.4 percent exceeded the 14,000 SYNs/sec capabilities of the Netscreen 100[10].

Another aspect to consider when selecting a device is ease of deployment.  Many security incidents catch organizations unprepared, and speed of response to an attack is very important.  Both the Netscreen 100 and the AppSafe can be configured for “bridge” mode (Netscreen calls this “transparent mode”) so that either could be inserted into a network without reconfiguring network routes or addresses of existing equipment.  Rapid on-demand deployment would be extremely useful during an attack.  The ability to relocate the defensive devices to different locations as needed could reduce the total number of units required.

Conclusion

While SYN floods continue to be one of the most challenging types of network attacks to defend against, this test demonstrates that effective defenses are available in the marketplace today.  But the wide variation in effectiveness of the different products shows the critical importance of  verifying performance before relying on any particular product or technique.  Cost is certainly not a good indication of performance. All four products have a list price in the range of $10,000 to $15,000, and the least expensive device, with a list price of $9,995, the Netscreen 100 was the second best performer.

While defense against external attacks is definitely necessary, the growth in distributed attacks shows that preventing your systems from being unwilling participants in an attack is equally important.

Directions for Further Research

This evaluation represents only a small portion of the possibilities for performance testing in the face of a SYN flood attack.  Other avenues of research include:

• Testing additional products: Time constraints limited this test to four products. Other commercial products are available that claim some form of SYN flood defense.  In addition, the manufacturers of all four tested products offer more powerful versions of their products.  Testing other market-leading firewalls, even if no special SYN flood defense is claimed, would reveal the specifics of how these products are affected by SYN flood attacks.
   

• Higher intensity attacks: The SYN flood defense capabilities of the AppSafe AS 2500 product exceeded the capabilities of the test environment, so more testing is needed to find its upper limits. An execution profile of the SYN flood generator program revealed that approximately 75 percent of execution time was spent on computation of packet checksums.  The computer used as the attack generator was an older 200MHz Pentium, so more CPU power could increase the attack intensity. Another possible technique is to construct the SYN packets and compute the checksums in advance, saving them to a disk file for later transmission.
   

• Testing a production network: while this test attempted to be as realistic as possible, testing an actual production network might reveal information that is not apparent under laboratory conditions.

Other products offering SYN flood defenses exist but were not included in this evaluation because of time constraints or availability, and would be candidates for similar tests.  The products tested will also continue to evolve, so retesting of future versions will also be worthwhile to see how product performances change over time.

Acknowledgements

The author would like to acknowledge the following organizations for their contributions to this report:

Atebion, Inc.
Yipes Communications, Inc.
Top Layer Networks, Inc.
Information Warehouse! Inc.

References

[1] "STOP Msg: 0x0000000A or 0x0000001E When Using PING," article in Microsoft Product Support Services database.

[2] Denial of Service Investigation & Exploration Pages, Gibson Research Corporation web site.

[3] "'Mafiaboy' busted in DoS attacks," ZDnet, April 19, 2000.

[4] U.S. Department of Justice, FBI press release, January 18, 2001.

[5] "'Mafiaboy' hacker awaits sentence in Canada," theage.com.au, June 13, 2001.

[6] "Denial of Service Attacks," CERT Coordination Center.

[7] "TCP Flooding Attack and Firewall-1 SYNDefender," Checkpoint Software Technologies, Ltd. web site.

[8] Gnu wget web site

[9] Number of compromised systems involved in the May 2001 distributed denial-of-service attack against Gibson Research.  SYNs/sec figure assumes all systems are connected via 128Kbit/sec Internet links (e.g. DSL, ISDN, cable modem).

[10] David Moore, Geoffrey M. Voelker, and Stefan Savage. Inferring Internet Denial-of-Service Activity. 10th USENIX Security Symposium, August 2001.

Copyright © 2001 by Tech Mavens, Inc.  All rights reserved.