By Rik Farrow

Learn about the TCP SYN Flood attack, which could be used to shut down your Internet Web (or other) server if the host operating system hasn't been patched.

Questions regarding this article should be directed to the author at rik@spirit.com .

A New Twist on an Old Attack

Dur ing January of 1995, the world became aware of a new style of attack on Internet sites -- Sequence Number Guessing . Successful attacks left the system wide open for root access from anywhere on the Internet. A side effect of the attack is that a trusted system would ignore any packets received on the port that services remote log-in requests. The TCP SYN Flooding attack consists of a tool that only implements one portion of the Sequence Number Guessing attack, with a completely different focus.

TCP SYN Flooding causes servers to quit responding to requests to open new connections with clients -- a denial of service attack. Denial of service attacks prevent people from using the affected system or networks. These attacks usually proceed by overloading the target in some fashion. For example, simply sending large ping packets can ``fill up'' a site's connection to the Internet. Illegally large ping packets, e asily generated by Microsoft products, such as Windows 95 or NT, can cause some systems to crash or reboot as described on the CERT (<URL:http://www.cert.org/>) system in their ping advisory (<URL:ftp://info.cert.org/pub/cert_advisories/CA-96.26.ping>).

CERT has also published an advisory about SYN Flooding (<URL:ftp://info.cert.org/pub/cert_advisories/CA-96.21.tcp_syn_flooding>) that contains a description and information about amelioration, including lists of vendors that have patches for this attack. SYN Flooding hit the public-radar screens in September of 1996, when several Internet service providers, including Panix, disappeared from the Net.

The TCP SYN Flooding attack takes advantage of the way the TCP protocol establishes a new connection. Each time a client, such as a Netscape browser, attempts to open a connection with a server, some information is stored on the server. Because the information stored takes up memory and operating system resources, only a limited number of in-progress connections are allowed, typically less than ten (more commonly six or less). When the server receives an acknowledgement from the client, the server considers the connection open, and the queue resources are freed for accepting another new connection.

The attacking software generates spoofed packets that appear to be valid new connections to the server. These spoofed packets enter the queue, but the connection is never completed -- leaving these new connections in the queue until they time out. Only a few of these packets need to be sent to the server, making this attack simple to carry out even using a slow, dial-up (like PPP or SLIP) connection from the attacker's computer. The system under attack quits responding to new connections until some time after th e attack stops. We provide a technical explanation of this attack at the end of this article.

Solutions

Although some have described TCP SYN Flooding as a ``bug'' in TCP/IP, it is more correctly a ``feature'' of the design. TCP/IP was designed for a friendly Internet, and a limited connection queue has worked fine for years.

Early fixes have focused on increasing the length of the queues and reducing a timeout value. The timeout value controls how long an entry waits in the queue until an acknowledgement is received. The problem with simply making the queue longer is that there are actually many queues (one for each TCP server on the system--HTTP, FTP, SMTP, etc.), and lengthening the queues to very large values, for example, eight kilobytes, results in an operating system requiring enormous amounts of memory (over 100 megabytes for a system with 25 server applications).

Shortening the timeouts can also help when used with longer queue lengths be cause the spoofed packets get removed from the queues more quickly. Shortening the timeouts also affects new outgoing connections, and remote users with slow links (these people would never get connected to this server otherwise).

The best solution is the modify the TCP implementation to reduce the amount of information stored for each in-progress connection. Another modification checks the return route of the new connection, and if it is different than the received packets (which is normal during this attack) to drop this connection. To see more details about solutions, see the Specific TCP SYN Flooding Solutions section below.

The CERT advisory on SYN Flooding includes an up-to-date list of the vendors who have patches for this attack. All server systems are vulnerable unless patched if traffic from the Internet (or any hostile network) are permitted.

The CERT advi sory also suggests that Internet Service Providers (ISPs) filter packets that they receive from their customers. Packets that have return addresses (source addresses) that don't belong to the ISP's customers must be rejected, foiling this attack, as well as other attacks that rely on source address spoofing. Unfortunately, it is unlikely that all ISPs will ever filter all IP traffic coming from their customers any time soon.

Specific TCP SYN Flooding Solutions

The ISP filtration solution would not only stop TCP SYN flooding attacks cold, but also block other attacks that rely on source-address spoofing. Unfortunately, getting all ISPs to implement this solution is not likely. Although ISPs do have an interest in stopping this attack (many ISPs have been victims), adding security costs money -- without any obvious financial return -- reducing profit.

Adding the appropriate packet filters takes time and technical ability, whereas not adding filtering will n ot affect an ISP's ability to service customers in any way. In other words, it costs money to add the security that will only indirectly save money (if the ISP loses money due to an attack). However, there is at least one solution that the smaller ISPs can use that is quite painless.

The other solutions involve changing the operating system's TCP/IP networking. The simplest solutions increase the size of the queues and reduce the timeout values, increasing the targeted system's resistance to the attacks. Better solutions involve modifying the way the operating system handles the connection queue or its overflow, and techniques for transparently detecting packets with spoofed source addresses.

Bigger Queues

The earliest solutions require increasing the size of the connection queue and reducing the timeout values. Changing these values ranges from adding simple commands to be executed while rebooting to patching the kernel (Unix operating system). Note that I have only included information for Unix systems in this article.

The first parameter to change governs the maximum number of half-open connections in the queue for each listening socket, SOMAXCONN in many versions of Unix. The second parameter governs both the time a half-open connection remains in the queue, and the time to wait until a server responds to a client's initial ACK, and is called TCPTV_KEEP_INIT .

In the examples that follow, we will be setting the queue length to 1024 entries and the timeout value to 25 seconds. There are side effects to using these values, which will be discussed at the end of this section.

The Berkeley Unix system (BSD/OS) and its derivatives permit adjusting these parameters using the sysctl command as shown here:

# 
sysctl net.inet.tcp.conntimeo 25

# 
sysctl net.socket.maxconn 1024

These two command lines could be included in the /etc/rc.l ocal file, so they will be executed every time the system is rebooted.

Sun Microsystem's Solaris 2.x (and perhaps other SVR4-based systems) support the ndd command for adjusting kernel parameters, as shown:

# 
/usr/sbin/ndd -set /dev/tcp tcp_ip_abort_cinterval 25000

# 
/usr/sbin/ndd -set /dev/tcp tcp_conn_req_max 1024

You should add these two commands to /etc/init.d/inetinit so they will be executed automatically with every reboot.

For systems without the ability to change kernel parameters via a command, rebuilding the operating system is necessary. For example, in Digital Unix, you change the two parameters in header files and then rebuild the operating system. In /usr/sys/include/sys/socket.h , change the SOMAXCONN definition so the 8 becomes 1024. In /usr/sys/include/netinet/tcp_timer.h change the TCPTV_KEEP_INIT definition from 75*PR_SLOWHZ to 25*PR_SLOWHZ . Then rebuild the kernel using Digital Unix procedures, which are unique to this Unix version.

You can also rebuild the kernel changing these same two parameters with Berkeley-derived Unix system. However, they're found in different locations, namely /usr/src/sys/netinet/tcp_timer.h and /usr/src/sys/sys/socket.h . Once you rebuild the kernel, it is no longer necessary to use sysctl with every reboot -- you have ``hard coded'' the change.

Obviously, if you don't have the source code to your operating system, you can't recompile your kernel to change these values. For example, SunOS 4.x versions do not include the necessary source files (unless you have a source license). However, the ``How to make BSD (SunOS) kernels SYN-attack resistant'' Web page provides links to pre-compiled modules for the sun4c and sun4m architectures -- w ith the necessary parameters already changed. (I cannot guarantee the authenticity of these patches, although a binary compare should show only minimal differences between the current and patches versions of these object modules).

Sun Microsystems provides the SunSolve Online Web site they describe as an ``in-depth, customer-accessible information resource for Sun customers that provides collections of informational documents, patch descriptions, a symptom-and-resolution database, as well as download-access to the latest system patches.'' Although, many SunSolve services require a user to register, where registration is for SunService Contract Customers only, this sites does have a publicly available area that includes public patch access.

Sun has promised design improvements, but only for Solaris 2.4, 2.5, and 2.5.1. Mark Groff of Sun Microsystems has written a good paper on this topic .

Trouble with Larg er Queues

Nothing is free. The Groff paper just referenced points out that each queue entry consumes approximately 600 bytes of memory. By increasing the queue length from 8 to 1024, we have increased the amount of memory needed during an attack from 4800 bytes to 609,600 bytes per queue . And there's a queue for each listening server. A typical Internet server supports Inetd, Named, Sendmail, and a Web server (other servers are supported by Inetd), for a total increase of 2,438,400 bytes.

A queue length of 1024 can handle a slow attack, but not a fast attack (coming from a well-connected source instead of a PPP- or SLIP-connected source). If you bump the queue length to 8192, you've added 16 megabytes to your memory requirements for the kernel -- and even this might not be enough to withstand a fast attack.

Groff points out that you cannot increase the size of the queue on SunOS system beyond a certain point because you can run out of ``mbufs'' (internal memory buffers use d by the operating system mainly for networking; the size of an mbuf is machine dependent, 128 bytes on BSD/OS). SunOS has a fixed limit of two megabytes for mbufs, and running out of mbufs would cause a system panic (a controlled crash and reboot). Read his article for more particulars on the limits for SunOS kernels.

If your server supports more services, it also requires more memory for the longer queues (all servers that respond to a TCP scan can be attacked). You need to protect private servers with a firewall or packet filter, and reduce the total number of services available on public servers.

Many services, such as FTP and Telnet, are started by the inetd daemon (under direction of the /etc/inetd.conf file); other services, such as Sendmail, Named, or HTTP servers, are started by specifying command lines in the files that execute when the system boots to multi-user operation. Both types of services can be disabled by ``commenting out'' the ap propriate lines using the # character.

Groff also points out that it is necessary to edit and recompile the sources to your servers. In particular, the listen() system call includes a parameter for the queue length, and this must be increased to match the new value for the operating system if all you do is increase queue length and decrease timeouts. Note that some versions of Inetd include a parameter that lets you adjust the queue length at startup time (BSD/OS versions, for example).

The shorter timeouts can also be a source for trouble. While 25 seconds appears to be a safe value (if it takes more than 25 seconds to exchange one pair of packets, maybe you should try again later), people coming from dial-up connected systems might be excluded. If a smaller value, such as ten seconds, is chosen, you will very likely be excluding sites connected via PPP, SLIP and modems.

Better Solutions

A redesign of the TCP/IP implementation appears a viable option. If the queue could be made longer without requiring so much memory, then the trouble with having a longer queue is reduced. Also, if there was some way to determine if a packet's source address were fraudulent, it would be possible to keep spoofed packets from ever entering the queue.

One vendor, BSDI has published solutions to both making the queue elements smaller and rejecting spoofed packets. One kernel patch adds an overflow queue, so when the queue becomes full, new connection requests can go into an overflow queue. The overflow queue is kept as a hashed list for quick lookup, and only the minimum amount of state (information) is stored, keeping memory requirements lower.

BSDI also announced a patch that checks for spoofed source addresses, called address verification. When a packet is received, the source address of the packet can be compared to the route to that address. If the route doe sn't exist, or would pass through a different interface than the packet was received from, the packet contains a spoofed source address. Checking this requires a table lookup, but still doesn't take too much time or resources.

Address verification won't work in all cases. It can't be used if there are more than one route available, for example, an ISP with multiple connections to the Internet or to a client. Using address verification on your Web server won't help very much because the route for most packets will always be the same (out the single interface they were received through).

Where address verification helps the most is for ISPs who support dial-in lines using PPP or SLIP. Address verification would prevent source address spoofing without having to add packet filtering.

Other Solutions

Some security product vendors, such as Checkpoint Technologies and Internet Security Sys tems (ISS) have announced products for dealing with TCP SYN flooding.

Checkpoint offers an add-on module for their Firewall-1 product that is supposed to block this attack. Firewall-1 works by checking packets before they enter the IP layer of the TCP/IP stack, and could reasonably be expected to work (I haven't received any reports about this or tried it myself).

ISS sells a product named RealSecure that watches network traffic, detects (somehow) the packets involved in a TCP SYN flood, and sends ``resets'' to the affected servers to prevent the queues from filling up. Again, this approach is feasible, but depends on how good the watcher is at determining which packets represent an attack and which are valid packets.

To summarize, if you have a server that can be reached from the Internet, it is very likely to be vulnerable to this attack if it has not been patched. Increasing queue length while reducing the timeout value (and the number of services offered) are the quick fixes . Adding patches that implement new designs for handling the queue, such as the ones from BSDI, are longer-term fixes. Also, use firewalls or packet filters to protect servers that are supposed to be inaccessible to the Internet.

Technical Description of SYN Flood Attacks

SYN flooding attacks are an obvious evolution of the Sequence Number Attack. The actual attack engine, along with an explanation of the attack, can be found in a Phrack article in either ZIP format from an FTP archive or as a Gzipped-tar archive from a Web server . Article 13 describes a program written specifically for Linux -- and while the language of the article is technical -- it is clearly written. The article describes the attack engine as portable to any system that supports raw sockets.

The SYN in SYN flood stands for the Synchronize flag in TCP headers. The SYN flag gets set when a system first sends a packet in a TCP connection, and indicates that the receiving system should store the sequence number included in this packet.

Both the client and the server send a packet with an initial sequence number and the SYN flag set. The client, opening the connection, sends a packet with just the SYN flag set. The server makes one of two responses. If there is no application listening at the port address indicated in the client's packet, the server returns a packet with the RST (reset) flag set in the TCP header, telling the client to break off the connection.

On the other hand, if there is an application listening, the server both acknowledges the first packet and sends its own initial sequence number. In this packet's TCP header, both the SYN and ACK (Acknowledge) flags are set. When the client receives the server's first packet, it enters the ESTABLISHED state. Until the server enters the ESTABLISHED state, information about the first packet received from the client remains in the connection queue for that service.

The TCP stack functions as a state machine, and you can view the state of each port, representing an application, by using the netstat command as shown here:

% 
netstat -a -f inet

Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp 0 0 bear.1053 rave
n.telnet ESTABLISHED
tcp 0 0 *.6000 *.* LISTEN
tcp 0 0 *.daytime *.* LISTEN
tcp 0 0 *.ident *.* LISTEN
tcp 0 0 *.telnet *.* LISTEN
tcp 0 0 *.ftp *.* LISTEN
tcp 0 0 *.printer *.* LISTEN
tcp 0 0 *.domain *.* LISTEN
tcp 0 0 *.sunrpc *.* LISTEN
udp 0 0 *.domain *.* 
udp 0 0 localhost.domain *.* 
udp 0 0 bear.domain *.* 
udp 0 0 *.sunrpc *.* 
udp 0 0 *.syslog *.* 
% []

For this discussion, we are most interested in the last three columns of output. In both local and foreign addresses, the host name appears first followed by a dot and the service name or port address. Most server applications will be named (using the /etc/services file, which maps the port addresses to service name). Most client applications will be represented by numbers, for example, 1053 for a Telnet client. An asterisk represents a wild card.

The state for each application (actually a socket, the combination of the local address and port and foreign address and port and the protocol type) appears in the last column of netstat 's output. A connection is established after the initial SYN packet has been acknowledged, shown in the connection between bear.1053 and raven.telnet. The LISTEN state represents server applications that are waiting for connections so named because the listen() call initiates listening for a connection. Note that servers for UDP-based applications do not show state because UDP is stateless.

There are other possible states. For example, wh en the client has closed a connection (by sending a packet with the FIN for finish flag set), the server acknowledges this packet, then sends its own packet with the FIN flag set, entering the TIME_WAIT state. If you have an active Web server, you may see this state depicted often in netstat output.

TCP enters the SYN_RCVD state after receiving the first packet from a client. During a SYN flooding attack, you will see many lines in netstat output in the SYN_RCVD state as many packets have been received, acknowledgements have been sent, but no acknowledgements have been received from the clients.

The Linux-based attack engine permits the attacker to choose the target, number of packets to send, ports to attack, how often to send packets, and how long to continue the attack. Most TCP/IP implementations, includings Windows NT, accept only a limited number of ``half-open'' connections (when the S YN packet has been received from the client, but the client has not acknowledged the server's SYN-ACK packet). So the attacking system only needs to send as few as five packets per minute for each port targeted on the attacked system. The attacker can determine which ports have servers listening by using port scanning software, such as strobe (36K) .

The attacker must also choose a source address to spoof. When client software uses TCP/IP, the IP stack inserts the source address of the sending system in the IP header. The attack tool, by using a raw socket, creates phony TCP and IP headers, and inserts a spoofed source address. The spoofed source address is key to this attack's success.

During a normal TCP connection sequence, packets are routed from the client to the server and vice versa. Figure 3 shows that during TCP SYN Flooding, the attacker sends packets with the SYN flag set, but a spoofed source address. The server keeps information about this packet in the connection queue for the service, and sends a response with the SYN and ACK flags set to the source address. The system at that source address doesn't exist or cannot respond, so the packet ``gets lost'' and the server never gets an ACK. Without the acknowledgement, the information stays in the server's connection queue until it times out.

While you might think that TCP/IP is ``broken'' after reading this article, there really are good reasons for the design behind how TCP connections become established. But that discussion would take another article to cover.