A type of denial of service attack in which the attacker sends a number of connection requests to the very small buffer space that exists to handle the usually rapid hand-shaking exchange of messages that sets up the session, and then fails to respond to the reply. This leaves the first packet in the buffer so that other, legitimate connection requests can't be accommodated. Although the packet in the buffer is dropped after a certain period of time without a reply, the effect of many of these bogus connection requests is to make it difficult for legitimate requests for a session to get established. In general, this problem depends on the operating system providing correct settings or allowing the network administrator to tune the size of the buffer and the timeout period.

See also: buffer overflow attack, teardrop attack, smurf attack

Please note that I wrote this in early 1997 when DOS attacks were just becoming a problem. It used to be on an old homepage, but when that went down the essay became homeless, so I have decided to post it on E2. Over the years this type of attack has become far more widespread and more advanced, but this essay should serve as a good introduction to the basic principles. I hope it's still interesting to people.

Denial of Service Attacks on any Internet Server Through SYN Flooding

Introduction

For the Internet to work there had to be a global standard so that all the connected machines could transfer data between each other. Without this system only those groups of machines who had decided on their own compatible methods could communicate. Since the aim of putting information on the WWW is usually to let anyone in the world access it, it makes sense to follow the global standard.

The standard that is used by web servers, telnet, talk and many other programs is called TCP or Transmission Control Protocol and is a part of IP or Internet Protocol that deals with domain and machine addresses. TCP allows machines to contact each other across the network and establish the link through which to communicate.

So How Does TCP Work?

The case is the same for all TCP connections, but I will describe the process from the point of view of a person looking at web pages. In this case, the client would be a browser program such as Netscape and the server would be a web server such as WebStar (for the Mac).

When the user clicks on a link in Netscape which takes them to a page on the WebStar server, a three way handshake is initialised to try and establish a TCP connection.

A SYN is a normal TCP packet with the synchronize sequence numbers field set. It's asking for attention.
  • 2: The server notes the value of this field and replies with an ACK.
An ACK is a packet that acknowledges the receipt of data and tells the client that the server is ready to receive more. The server looks in the SYN packet to find the IP address of the client, so it knows who to acknowledge. All TCP packets contain the address of the machine from which they were sent.
  • 3: The client then replies to the server with an ACK.
So now both the client and server know that each other are ready and the connection is created for data transfer to begin. The information about the new web page can now be requested and sent between the two.

TCP allows for many independent, simultaneous connections between machines, so lots of different people can look at web pages from different places or a group of people can connect to the same telnet service, for example. To make this possible, TCP uses ports as well as IP addresses to locate specific services as well as machines. Then these ports can also be split into sockets for multiple connections to each port.

How is TCP Abused to Deny Service?

The problem lies in the vulnerability of the three way handshake process. Due to the size and complexity of the ever-expanding Internet, most TCP connections are across long distances and the data packets have to be passed through many machines and across many links. For example, a connection from the University of Birmingham in England to the University of Washington in the United States goes through seventeen machines on route. (See appendix A. This can vary depending on network traffic and the availability of machines on the route.) The result of this is that packets can be delayed or even lost on the way.

To make connections more likely to work even when packets go missing, the server will usually sit and wait for a while after it has acknowledged the SYN, so that the client can send its ACK. If the server's ACK gets lost the client will not send an ACK back to complete the three way handshake, so the server sends another one a bit later. In fact, servers will usually send an ACK five or six times before giving up. Each time the ACK is sent, the server will wait for twice as long to give the client a better chance to respond through a busy route, so if the server allows six attempts and starts with a three second delay it will keep waiting for the client for up to 189 seconds.

This is where the denial of service attack comes in. The malicious user can write a program that sends out SYN packets to a server with fake return addresses that are unreachable, usually due to machines being temporarily off-line. The server then sends out its ACK to the fake address and awaits a response, but the packet will always be lost, so the server has another go, waits longer and keeps repeating this until it has used its default five or six goes.

The result is that the socket that the malicious client sent the SYN to is blocked for a while. This wouldn't normally be so bad and it is expected to happen now and then when a link is accidentally broken during the handshake, for example, but the denial of service attack does not stop there. The next step is to include a loop on the client's SYN sending program that makes it send out thousands of SYN packets to the same server, each one blocking a socket. Eventually, every port is blocked and legitimate users can establish no further connections. This sort of attack was initially considered impossible to trace since the only way to tell where a packet has come from is by looking at the return address and if this is fake you can't learn anything from it.

The attacker can also vary the fake IP addresses to make it harder for the server to spot which ones are false and ignore them. The results of this type of attack can vary in severity depending on the target server. The large number of open sockets can use a lot of memory, so this may deplete resources for programs running on the machine or even cause it to crash. In general, however, there will be no damage to the server or data on it. The real loss comes when you look at how many genuine users can't access the server, so if it's an ISP it's customers won't be able to use it or if it's an advertising site it's audience won't be able to see it.

Since blocked ports clear after a couple of minutes, they become available again, so any attack must be sustained to cause a prolonged problem unless the server actually crashes. In the case of a server crash the machine will only be out of action until the system administrator resets it.

Example Cases

SYN flooding attacks have been possible for years since TCP became the standard method of communication on the Internet, but there had been a few prominent cases in the online news over the previous few months. In September '96, a New York ISP called PANIX fell victim to an attack from an unknown source and in the months that followed software companies started releasing products to defend servers.

However, there were further cases where these programs proved useless due to the weight of the attack. One product was designed to monitor incoming SYN packets and send out RST or reset packets to suspicious addresses, but in use it turned out that the fake SYN packets arrived far too frequently for the RST's to clear them all. This is because the packets are small, so the malicious user can send hundreds per second without using much bandwidth at all.

More recently a Romanian teenager known as _METAL_ used SYN flooding to attack an ISP and a number of Internet Relay Chat servers, bringing down a large section of Undernet in the process. This sort of incident is likely to become much more widespread since two hacker 'zines, Phrack and 2600, gave example code for programs that will send out bad SYN packets in this way and people with gripes or just wannabe hackers will find them easy to implement.

It is not hard to imagine a scenario where someone breaks into several computers around the net and then starts SYN flood attacks against servers all over the world. As the attack method doesn't prevent outgoing connections from the server, they could deliberately target those servers now under their own control to make it harder for the other victims to alert the operators. Extreme as it may sound, this sort of abuse of TCP and the Internet in general would not be beyond the capabilities of thousands of people out there and it could cause a nightmare for the people and companies that find themselves victims.

How Can We Protect Our Servers?

] The first thing to know is that, as yet, there is no way to completely secure a server from this kind of attack short of not having it connected to the Internet. However, things are not as bad as they seemed at first and there are both semi-preventive measures and partial cures. Some of the companies that write web server software have already released advice and upgrade patches that are designed to make those servers less helpless in the face of an attack.

The following steps will decrease the problem for a server that is under attack:

  • Decrease the default number of times that your server sends out ACK packets to the client's apparent address. This will mean the block clears faster because there is less waiting before the server gives up on the client. However, you also give genuine clients less chance of connecting.
  • Increase the number of connections available. Each connection takes up typically under a hundred bytes of memory on the server, so it is possible to cater for many thousands of them. This means that you may be able to keep enough open for your genuine users to connect because the attacker might not be able send enough fake SYN packets quickly enough to keep them all blocked.
  • There are also steps that all ISPs can take to prevent people on their own sites from being able to attack remote servers. This is possible because the ISP's router can look at the address of packets that machines on the local network ask it to send to remote machines. If it spots a packet with a return IP address that doesn't belong to a machine in the local network then it can refuse to send it. However, local users would still be able to use unreachable addresses from within the local network, so the router would let them through, but the server would still be unable to send its ACK back to them. This could be done as easily as someone turning off a work station and then using its IP address in the bad SYN packets, so the solution is not foolproof.

Conclusion

SYN flood attacks are a problem that will not go away while we still use TCP. There are ways around all of the partial solutions that have been suggested so far, meaning that the most effective way to prevent attacks is for ISP operators to take up the community spirit and block as many outgoing attacks as possible. This way the malicious users are limited to faking addresses within their local area network and hence they are much easier to trace.

However, although most sytem operators would be happy to do this, there are bound to be some who don't and it only takes one to let a hacker fake IP addresses from anywhere on the Internet. This means that the only sure fire way to bring an end to SYN flood attacks is to change TCP, the basic fabric of the Internet. If done properly it would allow packets to be traced back to their origin in a way that did not rely on the data in the packet. The trouble is that, for a new protocol to be established, every single client and server on the Internet would need to be upgraded causing vast organisational difficulties and incurring great expense.

Appendix A

The route of a TCP transfer from the University of Birmingham to the University of Washington.

traceroute to becker1.u.washington.edu (140.142.12.67), 
30 hops max, 40 byte packets
 1  flipper-tw (147.188.195.6)  4 ms  2 ms  2 ms
 2  acs-gw (147.188.192.10)  2 ms  4 ms  2 ms
 3  gw-cc20.bham.ac.uk (147.188.172.1)  3 ms  2 ms  2 ms
 4  gw-sjips20.bham.ac.uk (147.188.171.1)  3 ms  2 ms  3 ms
 5  smds-gw.ulcc.ja.net (193.63.203.33)  25 ms  23 ms  24 ms
 6  * gw5.ulcc.ja.net (128.86.1.80)  30 ms  22 ms
 7  193.63.175.53 (193.63.175.53)  20 ms  31 ms  25 ms
 8  * 198.67.131.193 (198.67.131.193)  111 ms *
 9  icm-pen-1-H2/0-T3.icp.net (198.67.131.25)  174 ms  169 ms  164 ms
10  icm-pen-13-P1/0-OC3C.icp.net (198.67.142.97)  163 ms  159 ms  157 ms
11  mcinet-2.sprintnap.net (192.157.69.48)  174 ms  219 ms  200 ms
12  core2-hssi2-0.WestOrange.mci.net (204.70.1.49)  157 ms *  172 ms
13  borderx2-fddi-1.Seattle.mci.net (204.70.203.68)  275 ms  348 ms  232 ms
14  * * borderx2-fddi-1.Seattle.mci.net (204.70.203.68)  297 ms
15  * 204.70.203.118 (204.70.203.118)  308 ms *
16  204.200.8.12 (204.200.8.12)  452 ms *  399 ms
17  * kirby.cac.washington.edu (140.142.153.21)  460 ms *
18  becker1.u.washington.edu (140.142.12.67)  443 ms  422 ms  456 ms

Sources

    • Security Warning: TCP SYN Flooding and IP Spoofing Attacks
    • CERT Advisory CA-96.21
    • 19th September 1996
    • Computer Emergency Response Team
    • Project Neptune
    • Volume Seven, Issue Forty-Eight, File 13 of 18
    • July 1996
    • Phrack Magazine
    • Here Comes The Flood
    • Simson Garfinkel
    • packet.com
    • WebCom Security Software Failed in Server Attack
    • James Glave
    • Wired News


Update on October 15, 2001: shazamed has added a writeup below detailing how a method was devised for preventing "SYN and ACK sddress spoofing." cordelia has provided an explanation of why this will not solve the problem of the SYN attack described here, but I feel I need to comment further.

The point of the SYN attack I have described is not that the malicious client is attempting to spoof a complete three way handshake. They are intentionally completing only the first two stages of the handshake and then leaving the server waiting for the third stage to come in. During this time the socket is blocked, leaving it slightly less easy for legitimate clients to connect. If the malicious user floods the server in this way no legitimate clients will be able to use the service until some sockets are cleared.

Now the server can happily encrypt the ACK it sends to the client, but the client doesn't need to receive or reply to this ACK in order for the attack to work. The server is still left waiting for the client to send an ACK regardless of encryption.

There is a definitive solution to the Denial of Service attacks based on SYN and ACK address spoofing.
The solution comes from Steve Gibson and is called GENESIS (Gibson's ENcryption-Enhanced Spoofing Immunity System)

I base myself on FlameBoy excellent writeup for the vocabulary, so read it first.
Here is how it works:

  1.      Upon reception of the SYN packet from the client (user) browser, the server encrypts the client IP and adds to it the Client's Initial Sequence Number (CISN) ( number used to order the different packets sent over the internet in the right order at both ends) and send the whole as its own server SYN/ACK packet. the server does not hold this information in memory, hence no resource can be abused this way. If the IP is fake, the packet is lost, end of the story.
  2.     The client responds to this server SYN/ACK packet by its own ACK that includes the encrypted string.
  3.     Upon reception by the server, it subtracts the CISN from the ACK packet, decrypts the encrypted IP and compares it with the one declared by the client. If it matches: Bingo, the IP is authentic and was the one that sent the SYN packet in the first place. If not, the ACK is a fake and can be ignored.

According to the author, it can be implemented on any server as it fully complies with the TCP/IP protocol.

I do not intend to plagiarise Steve Gibson's already extremely comprehensive page so you should check it by yourself for crystal clear and detailed explanations : http://grc.com/r&d/nomoredos2.htm

Update October 14 2001: This method appears to be flawed : see cordelia's write-up below for details.

Defense against a SYN attack is typically done through the use of SYN cookies. Steve Gibson proposal is a flawed implementation, independently developed (without knowledge of the existence of SYN cookies*). It demonstrates nicely why security protocols should be peer reviewed.

The flaw is Gibson's implementation is that the server ISN is being set to Encrypt{client IP}+client ISN. Since the "secret" here is static, a hostile attacker needs only sniff a server SYN-ACK once to then be able to spoof the third step in the handshake.

In essence, GENESIS makes it impossible to fill up the SYN queue, by instead allowing a hostile attacker to freely fill up the connection pool. Oops. Demonstration:

Alice send SYN, with IP A, CISN N to Bob.
Bob computes {A}+N, sends SYN-ACK with SISN {A}+N, acknowledging CISN N. Bob forgets the connection.
Alice sends CISN N+1, ACK SISN {A}+N.
Bob checks that SISN-(CISN-1), decrypted, is A. If so, Bob assumes a three-way handshake exists.

Lucy detects either Alice's Akc, or Bob's SYN-ACK. While Lucy may not be able to break the key used to encrypt IPs, she can easily determine the value of {A}. Lucy now creates a random packet generator, which, for random value R, sends to Bob an ACK with the following parameters:

Source IP: A
CISN: R+1
SISN: {A}+R
Bob's only choice is to block Alice's IP, thus effectively blocking their communication - this is Steve's solution to this weakness.

*which is pretty impressive, since he claims to be a security researcher.

Log in or registerto write something here or to contact authors.