|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: TCP RST attack (the cause of all that MD5-o-rama)
On Apr 20, 2004, at 4:49 PM, [email protected] wrote: Well, we are talking about router vendors here, so let's limit it to cisco + Juniper.On Tue, 20 Apr 2004 15:40:38 EDT, "Patrick W.Gilmore" said:Assuming a well randomized starting sequence number (just give me this one for the moment),Nope. I won't give you that one, because that's a big chunk of the problem: http://lcamtuf.coredump.cx/newtcp/ (one year later) http://razor.bindview.com/publish/papers/tcpseq.html (original paper) It seems that Cisco has its act mostly together, but a *LOT* of other vendors don't, even a year after... Even assuming the 4K range (1024 -> 5000), the numbers are essentially "random" for a non-recently-rebooted router. There is no way for you to know when the session started, or what number the router was at when it did start. Besides, in my original post, I said that the best way to defend against this is good randomization, and commented that we might not have that now. :) Speaking of good randomization, does anyone have a good algorithm to randomize ephemeral ports? Obviously "pick random number, see if port is open, if it is, repeat" is not a good idea, especially on a busy host with lots of connections. I was thinking something like "pick 65K random numbers on boot, store in file/array, cycle through". Perhaps just pick a random number on boot, start at that high port number, then sequentially cycle? The last one would not be good for hosts which accept connections (gives you a good idea of current port number), but would work for routers with BGP sessions which were weeks or months long. Does anyone know if / how modern OSes randomize ephemeral ports? -- TTFN, patrick
|