TCP RST attack (the cause of all that MD5-o-rama)

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. :slight_smile:

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?

Date: Tue, 20 Apr 2004 19:24:37 -0400
From: Patrick W. Gilmore

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".

I don't think we're even that far along. If I'm reading FreeBSD
4.9 and NetBSD 1.6.2 source correctly,

  /usr/src/sys/netinet/in_pcb.c

tells all.

Does anyone know if / how modern OSes randomize ephemeral
ports?

AFAIK, sequential search is about it. Try a port number, verify
that the src/dist ip+port combination is available, then go on to
the next lport if the guessed one is in use.

Eddy

E.B. Dreger wrote:

I don't think we're even that far along. If I'm reading FreeBSD
4.9 and NetBSD 1.6.2 source correctly,

/usr/src/sys/netinet/in_pcb.c

Should have stretched as far as OpenBSD then. Same file.

tells all.

AFAIK, sequential search is about it. Try a port number, verify
that the src/dist ip+port combination is available, then go on to
the next lport if the guessed one is in use.

As far as I can see - I have never read the code before, just the commit
messages - the OpenBSD version does a circular, random search between high
and low targets.

Peter

Date: Wed, 21 Apr 2004 07:45:36 +0100
From: Peter Galbavy

E.B. Dreger wrote:
> I don't think we're even that far along. If I'm reading FreeBSD
> 4.9 and NetBSD 1.6.2 source correctly,
>
> /usr/src/sys/netinet/in_pcb.c

Should have stretched as far as OpenBSD then. Same file.

Didn't have it handy, too lazy to grab a tarball, and didn't want
to overreach. :slight_smile:

Eddy

E.B. Dreger wrote:

> Date: Wed, 21 Apr 2004 07:45:36 +0100
> From: Peter Galbavy

> E.B. Dreger wrote:
> > I don't think we're even that far along. If I'm reading FreeBSD
> > 4.9 and NetBSD 1.6.2 source correctly,
> >
> > /usr/src/sys/netinet/in_pcb.c
>
> Should have stretched as far as OpenBSD then. Same file.

Didn't have it handy, too lazy to grab a tarball, and didn't want
to overreach. :slight_smile:

CVS Web is da bomb.

   http://cvsweb.freebsd.org/
   http://cvsweb.netbsd.org/
   http://www.openbsd.org/cgi-bin/cvsweb/