On Fri, 18 Feb 2000, Paul Cardon wrote:
: "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.
OK, so suppose the size of the buffer is B, and suppose the amount of
total available memory is M. If you set B > M, then memory can be maxed
out although there would be some cutoff points depending on how you set
the timeout. If the pipe cannot supply packets at a rate fast enough to
initiate enough connections to overflow B before the timeout kicks in then
SYN flood is obviously not possible. Conversely, if you have a large
bandwidth connection then it is not obvious that your server could stay
ahead of a SYN flood. Of course, if you set B < M, then you will not max
out all of the server memory even if the connections fill B, but the SYN
flood will still work because your server is not able to setup anymore
connections since it is limited by B anyway.
: 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.
Unix Network Programming page 99 (thanks for pointing me there).
--Michael B. Rash | "...the whole aim of practical politics is
| to keep the populace alarmed (and hence
http://www.math.umd.edu/~mbr | clamorous to be led to safety) by an
| endless series of hobgoblins..." -Mencken
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:05:01 PDT