Date: Thu, 30 Dec 2004 04:42:15 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Maxim Konovalov <maxim@FreeBSD.org> Cc: net@FreeBSD.org Subject: Re: Update: Alternate port randomization approaches Message-ID: <20041230042939.L35911@odysseus.silby.com> In-Reply-To: <20041229155419.I74642@mp2.macomnet.net> References: <20041218033226.L28788@odysseus.silby.com> <20041229155419.I74642@mp2.macomnet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 29 Dec 2004, Maxim Konovalov wrote: > On Wed, 29 Dec 2004, 03:02-0600, Mike Silbersack wrote: >> This appears to work for Igor, and it seems safe enough to commit before >> 4.11-RC2. But, if possible, I'd like a few more sets of eyes to doublecheck >> the concept and code; please take a look at it if you have a chance. > > Again, it's not clear for me why we don't follow our usual > deveplopment cycle here: commit & test in HEAD and then MFC to STABLE? > > -- > Maxim Konovalov The problems random port allocation exposes only occur in situations where machine A is making repeated connections to machine B, so it's limited to situations like front-end web proxies, connections to database servers, and a few other things. General web servers, ftp servers, SMTP servers, etc, aren't affected. So, committing to -current won't cause us to learn anything; specific testers are needed. I should have worked on this issue months ago, but I didn't, so I'm trying to come up with something safe as quickly as possible. This is necessitated because 4.11 is going to be the last in the 4.11 series, so this can't be pushed off until after 4.11 is published - there'd be little point in bothering at that time. Igor has been generous enough to test the various iterations of this patch as I've developed them and tested on a production system to see if they work for him. Based on his results, I think we're pretty close to an acceptable compromised between security (full randomization) and proper operation (no randomization.) We're now looking at settings more along the lines of a 10 connections per second ceiling and a 45 second threshold before randomization is reenabled, FWIW. I'm not too concerned about general testing because these patches are quite simple; they're modifications of the previous behavior, so they won't create any new problems. As far as bugs in the implementaton go, well, anyone is welcome to do a quick review. :) Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041230042939.L35911>