TCP RST attack (the cause of all that MD5-o-rama)
Patrick W.Gilmore
patrick at ianai.net
Tue Apr 20 23:24:37 UTC 2004
On Apr 20, 2004, at 4:49 PM, Valdis.Kletnieks at vt.edu wrote:
> 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...
Well, we are talking about router vendors here, so let's limit it to
cisco + Juniper.
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
More information about the NANOG
mailing list