Alternate port randomization approaches
From: Mike Silbersack (silby_at_silby.com)
Date: 12/18/04
- Previous message: James: "Re: vlan double tagging"
- Next in thread: Maxim Konovalov: "Re: Alternate port randomization approaches"
- Reply: Maxim Konovalov: "Re: Alternate port randomization approaches"
- Reply: Mike Silbersack: "Update: Alternate port randomization approaches"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 18 Dec 2004 04:03:11 -0600 (CST) To: net@freebsd.org
There have been a few reports by users of front end web proxies and other
systems under FreeBSD that port randomization causes them problems under
load. This seems to be due to a combination of port randomization and
rapid connections to the same host causing ports to be recycled before the
ISN has advanced past the end of the previous connection, thereby causing
the TIME_WAIT socket on the receiving end to ignore the new SYN.
I haven't proven it, but I imagine that part of the problem is due to the
interaction of established and finished connections. Say that ports 1500
-> 1600 have established connections, and that arc4random picks port 1504
as the next one to try. Rather than picking another random port, we
simply look sequentially through the rest of the ports, and will pick
1601. I had considered continuing to do random port guesses until an
unused one was found, but that has the nasty property of looping an
undetermined amount of time, and it would most likely not help anything
anyway.
The solution I've come up with that should provide a decent tradeoff
between the increased security of port randomization and the realities of
the problem of quick port recycling is attached. What it does is only
randomize the first net.inet.ip.portrange.randomized ports assigned each
second. Beyond that, it uses sequentual allocation. The default I
picked, 20, is arbitrary. Initial testing by a front-end web proxy admin
shows that 20 is too high to avoid problems in his case, but 1 works
decently.
Although this isn't a perfect fix, I think that it should be acceptable
for the vast majority of systems, and I'd like to get it in before
4.11-release ships. To be conservative, I'll probably choose a value like
5, which should be fine for most systems out there. Super specialized
users will always be able to lower it to 0.
Since this is an important issue, I was wondering if anyone had any
suggestions on how to improve this method, or how to solve the problem in
another way.
Remember that 4.11 ships in the next few weeks, so any solution which gets
added to it must be relatively simple, we can't be doing anything like
changing the TCP state machine. (Yes, I've considered removing the ISN >
window requirement from the TIME_WAIT state, but that's not something to
be changing on a whim.)
Also note that 5.x and 6.x handle TIME_WAIT recycling in the exact same
way 4.x does; the sequence number check is just now in the function
tcp_timewait rather than in tcp_input. So, the same problems plagues all
versions. (Despite my other modifications to sequence number generation
which were attempts to fix it.)
Comments appreciated,
Mike "Silby" Silbersack
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
- TEXT/PLAIN attachment: in_pcb.c-lessrandomization.patch-4
- TEXT/PLAIN attachment: in_pcb.c-lessrandomization.patch
- Previous message: James: "Re: vlan double tagging"
- Next in thread: Maxim Konovalov: "Re: Alternate port randomization approaches"
- Reply: Maxim Konovalov: "Re: Alternate port randomization approaches"
- Reply: Mike Silbersack: "Update: Alternate port randomization approaches"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
