"daN." wrote: > > The reason (in most cases) that SYN flooding works is not that it takes up > your entire bandwidth like smurf or something would do. SYN flooding works > because when a machine accepts a SYN packet it has to take CPU time and > memory to setup an internal state of that packet (ie it assigns a chunck of > memory and puts things like RemoteIP/RemotePort/timestamp etc in it...) so > a SYN flood can usually either gobble up all availible memory or all CPU > time long before it eat's up the pipe... That is not the problem at all. The server has a finite buffer for connection attempts that are in the SYN Received state waiting for the client ACK that allows them to transition to the Established state. If the client ACK does not arrive within a timeout window the server removes the connection attempt from the buffer. A SYN Flood operates by sending enough SYN packets to fill the buffer within the timeout window and then keeps sending to immediately fill buffer slots once the server clears them. The server doesn't run out of CPU or memory, it simply runs out of slots in the buffer for legitimate connection attempts. There are strategies for managing this buffer that make it more resistant to attack. Simply increasing the buffer size and decreasing the timeout value are not sufficient. I don't have the exact page number, but see the section of Unix Network Programming Volume 1 (Second Edition) that describes the backlog parameter of listen(). There are references to two strategies for making the stack more resistant to SYN Floods. On the face of it I don't see how RSA's strategy improves anything but I also have yet to read the entire thing. -paul
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:05:37 PDT