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