Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Sep 1996 14:30:15 -0700 (PDT)
From:      Steve Reid <steve@edmweb.com>
To:        didier@omnix.fr.org
Cc:        iap@vma.cc.nd.edu, linuxisp@jeffnet.org, freebsd-isp@freebsd.org, os2-isp@dental.stat.com
Subject:   Re: SYN attacks in the Washington Post
Message-ID:  <Pine.BSF.3.91.960913124421.191B-100000@bitbucket.edmweb.com>
In-Reply-To: <Pine.BSF.3.95.960913100159.14681B-100000@zapata.omnix.fr.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> could you explain the principle of the SYN attack ?

A normal TCP connection is started with a three-way handshake, like this: 

1- Client sends a TCP packet with the SYN (syncronize sequence numbers)
bit set. The client is saying, "Can I connect?"  Client connection is now
in a half-open state (SYN_SENT). 

2- Server receives SYN, and sends back a TCP packet with both the SYN
and ACK (acknowlegement) bits set. The server is saying, "Yes, connect and
send your data."  Server connection is now in a half-open state (SYN_RCVD).

3- Client sends a TCP packet with the ACK bit set, along with whatever
data it means to send. This puts the TCP connection into the ESTABLISHED
state on the client end, and also on the server end when the packet gets 
there. 

The problem is, the server can only handle so many half-open (SYN_RCVD)
TCP connections. This number is hard-wired into the kernel, and is 
usually between 6 and 16 (sometimes higher). Once this number of 
half-open connections is reached, the kernel will ignore new connection 
attemps, because it can't keep track of any more SYN_RCVD connections. It 
_must_ receive an ACK to complete the connection, otherwise it sits in a 
SYN_RCVD state until it times out (usually after 75 seconds).

An attacker can easily use up the maximum number of half-open connections
by sending out SYN packets with a forged source address. For instance, if
the attacker were to send a SYN packet with a source address of
198.41.0.253 to your web server, the server would go into SYN_RCVD
state and respond with a SYN|ACK (that's the second part of the
handshake). The SYN|ACK would be sent to 198.41.0.253, becuase that's
where the server thinks the SYN came from. However, because there is
nothing at 198.41.0.253 (ping it and you'll get nothing) the SYN|ACK
goes into the bitbucket. Since there is no host to complete the third part
of the handshake (ACK+data) the server sits in the SYN_RCVD state for 75
seconds. Meanwhile, the attacker sends out more bogus SYN packets, and the
server eventually ignores _all_ SYN packets, even from legitimate
connection attempts. 

This attack requires very little bandwidth- multiple servers could be
knocked down with a single 28.8k connection. Tracing the attack back to
the source would require cooperation from the operators of every network
administrator between the victim and the attacker (virtually impossible). 
All that's needed to attempt the attack is one of the programs published
in 2600, Phrack, etc. and an internet-connected machine with access to raw
sockets.

If the attacker is sending packets with the same address every time, then
you could just block that address. But most likely, the attacker's program
will choose addresses completely at random, and you can't even begin to
block them all. 

There are a few things you can do...

1- Get a kernel that can handle more SYN_RCVD connections. IIRC, according
to the SYN bombing article in Phrack 48, FreeBSD 2.1.5-RELEASE can handle
128 SYN_RCVD connections. The ability to have more connections half-open
means the attacker has to send a lot more packets to bring your server
down. 

2- Change the SYN_RCVD timeout value in the kernel from 75 seconds down to
around 10 seconds, or even less. If you go too low, legitimate connections
might time out, but 75 is _way_ higher than you need. Lowering the timeout
means the attacker has to send SYN packets a lot more often to keep your
server down. 

3- Set your router so that it will _not_ allow packets to be sent from
your network with an address that doesn't match your network. For
instance, if your network is 198.41.0.*, don't allow your router to
send out packets unless the source address matches 198.41.0.*. This
doesn't offer any protection to you, but it will prevent your network from
being used to launch a SYN bombing attack. If someone does attempt it,
they will be limited to forging adresses in your subnet (such as
198.41.0.253) which the victim can easily block, and you can easily
trace. You could even go so far as to only allow addresses from valid
hosts on your network, which will make SYN bombing from your network
impossible. 


Disclaimer: I am not a networking expert. I'm just regurgitating what 
I've heard about this attack.


=====================================================================
| Steve Reid - SysAdmin & Pres, EDM Web (http://www.edmweb.com/)    |
| Email: steve@edmweb.com   Home Page: http://www.edmweb.com/steve/ |
| PGP (2048/9F317269) Fingerprint: 11C89D1CD67287E68C09EC52443F8830 |
|          -- Disclaimer: JMHO, YMMV, TANSTAAFL, IANAL. --          |
===================================================================:)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.960913124421.191B-100000>