Security Basics mailing list archives
RE: managing a SYN flood
From: "David Gillett" <gillettdavid () fhda edu>
Date: Mon, 8 Mar 2004 12:39:10 -0800
-----Original Message----- From: nick [mailto:nick () mobilia it] Managing a syn flood really can't be done at the server level, even if you're denying all the traffic coming from the IP address (or addresses), it's still going to be clogging your pipe.
All true, except that while a SYN flood *may* clog the pipe, that's not it's primary mode of attack. The first packet of a TCP "3-way handshake" has the SYN flag set. When the server sees that, it responds with a packet with SYN and ACK set. A packet with just ACK set completes the handshake. In order to recognize and process that ACK packet, the server needs to remember that it already saw a corresponding SYN and sent a SYN-ACK. That "remembering" function is implemented by a connection table in the server. Connection tables are often of fixed size. A SYN flood DOS/DDOS attack is based on the premise that hosts might not gracefully handle the condition where the connection table becomes full; or at least may start rejecting valid connection requests if it has enough half-processed spurious ones. SYN packets are quite small. By comparison, the time a naive host will keep a half-opened connection in its table, waiting for the ACK, is quite large. A stream of SYNs sufficient to keep a host's table full might not use enough bandwidth to interfere with other servers/users at the site, let alone actually "clog the pipe". (The attacker is never going to send the ACK packet, so he's free to spoof the source address. If he makes it randomly different on every packet, that will limit how much help an upstream provider can be.) The most effective mitigations for a SYN flood are to modify the host's connection table handling code, either to time incomplete connections out more agressively, or discard incomplete connections as necessary when the table is full to accept new connections. A few network appliances claim to detect and block such attacks. I'm not sure how effective they can be if the source addresses are spoofed at random. David Gillett --------------------------------------------------------------------------- Ethical Hacking at the InfoSec Institute. Mention this ad and get $545 off any course! All of our class sizes are guaranteed to be 10 students or less to facilitate one-on-one interaction with one of our expert instructors. Attend a course taught by an expert instructor with years of in-the-field pen testing experience in our state of the art hacking lab. Master the skills of an Ethical Hacker to better assess the security of your organization. Visit us at: http://www.infosecinstitute.com/courses/ethical_hacking_training.html ----------------------------------------------------------------------------
Current thread:
- managing a SYN flood Bruyere, Michel (Mar 04)
- Re: managing a SYN flood JGrimshaw (Mar 04)
- Re: managing a SYN flood nick (Mar 08)
- RE: managing a SYN flood David Gillett (Mar 08)
- <Possible follow-ups>
- Re: managing a SYN flood H Carvey (Mar 04)
- RE: managing a SYN flood Joshua M. Jones (Mar 08)
- RE: managing a SYN flood Aditya, ALD [Aditya Lalit Deshmukh] (Mar 10)