From owner-freebsd-isp Fri Sep 13 14:31:11 1996 Return-Path: owner-isp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA18920 for isp-outgoing; Fri, 13 Sep 1996 14:31:11 -0700 (PDT) Received: from bitbucket.edmweb.com (redshirt01.edmweb.com [204.244.190.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA18906 for ; Fri, 13 Sep 1996 14:31:04 -0700 (PDT) Received: (from steve@localhost) by bitbucket.edmweb.com (8.6.12/8.6.12) id OAA00287; Fri, 13 Sep 1996 14:30:19 -0700 Date: Fri, 13 Sep 1996 14:30:15 -0700 (PDT) From: Steve Reid 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 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-isp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 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. -- | ===================================================================:)