> Hi all. I'm wondering if someone could help me find information on linux
> and its ability to withstand syn attacks.
ftp://ftp.op.net/pub/src/syn-prophylactica/
http://www.dna.lth.se/~erics/linux.html
ftp://koobera.math.uic.edu/pub/docs/syncookies-archive (all sorts
of info)
CA-96.21.tcp_syn_flooding from your nearest Cert mirror.
Phrack Issue 48, File 13
> I compiled support for syn and rst cookies in 2.0.31-pre2, and it seems to
> hold 128 SYN_RECV connections when being attacked by the syn flood.
Try without RST cookies - they are 'a fun feature' yet not as good
as SYN cookies.
128 seems to be the magic number where it starts worrying there are so many
SYN state connections and starts throwing them out.
> Can someone tell me what exactly these cookies are, and why it is that
Here is how I understand it... I may be wrong... scratch that, I am
probably wrong... (and it's been a while since I looked at these)
Normally
machine1 gets SYN request
machine1 sends SYNACK and stores stuff in buffer (sequence number, from host,
to host, from port, to port)
if machine2 gets the SYNACK it then sends machine1 an ACK
With Syn cookies:
machine1 has a randomly rotating number, valid for 1 minute.
machine1 gets SYN request
machine1 generates unique sequence number from md5(from host,to host, from port,
to port,random-cookie)
machine1 sends the SYNACK using the unique sequence number and forgets
about the SYN
If machine2 never responds, too bad
if it does respond, machine1 re-computes the md5 hash with the current
random number. If it matches it simply creates the socket.
(I also presume that it stores the previous "magic number" or "cookie"
from the last minute, since a packet arriving on the minute it rotates
the cookie will otherwise always be trashed)
> Linux is the only one who seems to have adopted this mechanism?
I don't know if it is - one of the links above has stuff for Sun and others.
Oskar