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.