TIME_WAIT Assassination in FreeBSD???

[Jarrod Lee Petz]

Hi Daniel,

Thank you for the information. I agree with your comment below.

" But if you're simply running the ftp client on an otherwise idle host,
and two subsequent bind() calls get assigned the same 'random' port,
I'd say the port randomization is not working properly :)"

Does anyone have any further information or advice they could offer for
this issue? I have found a few other references via Google to people
experiencing issues with ephemeral port randomisation and FreeBSD. It
appears this does not just impact FTP but also WebServers & Proxy software.
So as I feared other protocols/software besides active FTP is impacted. To
what extent it would seem no one really knows unless things have
changed(this stuff is a few years dated).

This link in particular
http://www.silby.com/eurobsdcon05/eurobsdcon_silbersack.pdf
" At present, FreeBSD attempts to avoid this
quick port recycling problem by falling back
to sequential port allocation whenever the
machine is making more than 10 outbound
connections per second. This solution is
more of a hack than anything, and has been
slated to be replaced as soon as a better
method can be found."

And this http://www.bsdcan.org/2006/papers/ImprovingTCPIP.pdf

I retested again, this time on FreeBSD 9.0 Beta 2. I can confirm the
behaviour described is still present. If I test with many worker FTP
processes or even one  process without a delay. Then the ten connections
per second limit is reached and port randomisation is disabled making the
problem disappear. However when I only have one worker process and a
delay(which I usually have to capture a decent tcpdump) then the connection
rate is lower and port randomisation stays in effect which produces the
issue.

So what should would be the best approach for this. I'm still not sure.
Does anyone know of work being done on a different port randomisation
algorithm?

Should I disable port randomisation until/unless a better selection
algorithm comes along? This is made out to sound like a fairly big security
risk in practice I don't really understand how bad? For secured SSL/TLS
traffic
would this cause concern?
OR
Should I just move to passive FTP and try not to worry about other
protocols/software encountering sporadic issues?

Regards Jarrod

-----Original Message-----
From: Daniel Hartmeier [mailto:daniel at benzedrine.cx] 
Sent: Tuesday, 6 September 2011 1:12 AM
To: petz at nisshoko.net
Cc: freebsd-hackers at freebsd.org
Subject: Re: TIME_WAIT Assassination in FreeBSD???

In FreeBSD, the ftp client allocates the port for an active-mode data
connection by calling bind(2) with so_port set to 0, which means it lets
the kernel pick a port, see

 
http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/lukemftp/src/Attic/ftp.c?r
ev=1.1.1.8;content-type=text%2Fplain;hideattic=0

The kernel code where the port is picked is in function in_pcb_lport(),
see

 
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in_pcb.c?rev=1.281;con
tent-type=text%2Fplain

Basically, there is a range of ports (49152-65535, adjustable with
sysctl), and the algorithm picks a random port within that range:

        if (dorandom)
                *lastport = first + (arc4random() % (last - first));

It checks whether that port is available. If not, it increments it by
one, and tries again, etc. in a loop, until it finds one.

So, for your case, it is unlikely that two subsequent bind() calls from
the ftp client would result in the same port being picked randomly,
unless a large part of the port range is unavailable.

You can get port re-use that is quick enough to confuse pf, for
instance, by opening new connections (to the same destination address
and port) at a high rate, e.g. when running the Apache web server
benchmark tool.

But if you're simply running the ftp client on an otherwise idle host,
and two subsequent bind() calls get assigned the same 'random' port,
I'd say the port randomization is not working properly :)

HTH,
Daniel