randomize source port

[Jeremy C. Reed]

As a quick test, I did the following:

--- in_pcb.c 5 May 2008 17:11:17 -0000 1.125
+++ in_pcb.c 11 Jul 2008 15:33:49 -0000
@@ -332,6 +332,8 @@
mymax = swp;
}

+ *lastport = mymax - (arc4random() % (mymax - mymin));
+
lport = *lastport - 1;
for (cnt = mymax - mymin + 1; cnt; cnt--, lport--) {
if (lport < mymin || lport > mymax)


With default sysctl:

net.inet.ip.anonportmin = 49152
net.inet.ip.anonportmax = 65535

Using gethostbyname2(3), I did many lookups (some simultaneously) to one
of my local nameservers.

Before my patch, the source port counted down from 65026 to 64845.

After my patch, the source port, I didn't see any noticable sequence of
counting down, such as:

52362
59398
64223
51205
55882
...
50004
64005
64193
51223
53918

And the range of 49202 to 65491.


By the way, FreeBSD has these sysctl tunables:

net.inet.ip.portrange.randomized
Enable random port allocation. (Default is on.)

net.inet.ip.portrange.randomcps
Maximum number of random port allocations in last second
before switching to a sequental one. (Default is 10.)

net.inet.ip.portrange.randomtime
Minimum time to keep sequental port allocation (while randomcps
is not reached) before switching back to a random one. (Default
is 45 seconds.)


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven M. Bellovin]

On Fri, 11 Jul 2008 11:00:21 -0500 (CDT)

Post by Jeremy C. Reed
--- in_pcb.c 5 May 2008 17:11:17 -0000 1.125
+++ in_pcb.c 11 Jul 2008 15:33:49 -0000
@@ -332,6 +332,8 @@
mymax = swp;
}
+ *lastport = mymax - (arc4random() % (mymax - mymin));
+
lport = *lastport - 1;
for (cnt = mymax - mymin + 1; cnt; cnt--, lport--) {
if (lport < mymin || lport > mymax)

How easy would it be to do a timing test? For example, assume a simple
program that just counted how many UDP ports it could bind to in ten
seconds? I expect some impact, but not a big one; arc4 is very cheap,
but measurement is always good.

More seriously -- when at boot time does urandom have enough entropy to
seed the PRNG? I've had problems on some server systems with things
like that.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

I'm not sure if directly randomising the port is a good idea.
I think it should at least be a random shuffle for the same reason that
the TCP sequence numbers are not using a direct PRNG. Note that a random
shuffle also avoids most of the motivation for moving to a sequential
numbers, at least if short living connections are concerned.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven M. Bellovin]

On Fri, 11 Jul 2008 18:22:45 +0200

Post by Joerg Sonnenberger
I'm not sure if directly randomising the port is a good idea.
I think it should at least be a random shuffle for the same reason
that the TCP sequence numbers are not using a direct PRNG.

I don't see the similarity. For sequence numbers, there's a
requirement in the RFC for a 4 microsecond counter; there's also
analysis concerning defense against old packets lying around the
network.

The possible issue here is consecutive use of the same port number; I
don't think it's a real concern.

Post by Joerg Sonnenberger
Note that
a random shuffle also avoids most of the motivation for moving to a
sequential numbers, at least if short living connections are
concerned.

I don't understand.



--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Steven M. Bellovin
On Fri, 11 Jul 2008 18:22:45 +0200

Post by Joerg Sonnenberger
I'm not sure if directly randomising the port is a good idea.
I think it should at least be a random shuffle for the same reason
that the TCP sequence numbers are not using a direct PRNG.

I don't see the similarity. For sequence numbers, there's a
requirement in the RFC for a 4 microsecond counter; there's also
analysis concerning defense against old packets lying around the
network.

Reusing the port number early increases both the chance of a collission
with an existing port and the chance that you can still hit the query id
case (for the special case of DNS).

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Steven M. Bellovin
...
How easy would it be to do a timing test? For example, assume a simple
program that just counted how many UDP ports it could bind to in ten
seconds? I expect some impact, but not a big one; arc4 is very cheap,
but measurement is always good.

Semi-related to this, I've been looking at this at work.
On a Sun Ultra20, I think it was ~2,000,000/second.
Compared with the libc random on Solaris, which was
10 or 100x that number.

But really it isn't how many per second you can do but
how much CPU it takes to do one and how much CPU
you have left for other things.

For example, with NAT using arc4random, it couldn't
hope to create 2,000,000 sessions per second.

I think you'd be lucky to be doing 200,000 bind()'s per
second to new ports :)

Post by Steven M. Bellovin
More seriously -- when at boot time does urandom have enough entropy to
seed the PRNG? I've had problems on some server systems with things
like that.

arc4random, as per libkern, reseeds itself either every 5 minutes or 16k
calls.

If arc4random is too CPU intensive, is it worth using libc's rand and
seeding
that automatically in the kernel as we do with arc4random?

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Darren Reed
If arc4random is too CPU intensive, is it worth using libc's rand and
seeding that automatically in the kernel as we do with arc4random?

It would be better to use the Mersenne twister or something like sober
as prng in that case. Both are cryptographhically strong PRNGs and can
be a lot faster than arc4random.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de