Countering SYN Flood Denial-of-Service Attacks
by Ross Oliver
August 29, 2001
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.
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),
sending enough data to consume all available network bandwidth (as in the
May, 2001 attacks against Gibson Research),
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:
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. In January 2001, the youth plead guilty to 56 criminal counts relating to the incident. CNN and other victims claim the attack caused damages totaling $1.7 billion.
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. 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:
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:
The author created a test environment to simulate a typical web server and web browser configuration. The test environment consisted of the following components:
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.
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.
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.
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.
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.
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.
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:
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.
The author would like to acknowledge the following organizations for their contributions to this report:
 "STOP Msg: 0x0000000A or 0x0000001E When Using PING," article in Microsoft Product Support Services database.
 Denial of Service Investigation & Exploration Pages, Gibson Research Corporation web site.
 "'Mafiaboy' busted in DoS attacks," ZDnet, April 19, 2000.
 U.S. Department of Justice, FBI press release, January 18, 2001.
 "'Mafiaboy' hacker awaits sentence in Canada," theage.com.au, June 13, 2001.
 "Denial of Service Attacks," CERT Coordination Center.
 "TCP Flooding Attack and Firewall-1 SYNDefender," Checkpoint Software Technologies, Ltd. web site.
 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).
 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.