From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 01:47:54 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 101FD16A4CE for ; Tue, 23 Dec 2003 01:47:54 -0800 (PST) Received: from lariat.org (lariat.org [63.229.157.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 237C443D5A for ; Tue, 23 Dec 2003 01:47:45 -0800 (PST) (envelope-from brett@lariat.org) Received: from runaround.lariat.org (IDENT:ppp1000.lariat.org@lariat.org [63.229.157.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id CAA15578; Tue, 23 Dec 2003 02:47:33 -0700 (MST) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <6.0.0.22.2.20031223023730.037cbd28@localhost> X-Sender: brett@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 23 Dec 2003 02:47:32 -0700 To: Mike Silbersack From: Brett Glass In-Reply-To: <20031223032000.T2131@odysseus.silby.com> References: <200312120312.UAA10720@lariat.org> <20031212074519.GA23452@pit.databus.com> <6.0.0.22.2.20031212011133.047ae798@localhost> <20031212083522.GA24267@pit.databus.com> <6.0.0.22.2.20031212103142.04611738@localhost> <20031212181944.GA33245@pit.databus.com> <6.0.0.22.2.20031212161250.045e9408@localhost> <20031213001913.GA40544@pit.databus.com> <6.0.0.22.2.20031212175801.04b066d8@localhost> <20031222182913.M2799@odysseus.silby.com> <20031223051259.GA36331@pit.databus.com> <6.0.0.22.2.20031222222449.03cd58c8@localhost> <20031223032000.T2131@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" cc: Barney Wolff cc: net@freebsd.org Subject: Re: Controlling ports used by natd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2003 09:47:54 -0000 At 02:29 AM 12/23/2003, Mike Silbersack wrote: >I think that it might be best to keep choosing ports inside of libalias. >Adding yet another port range would just complicate the kernel more >without much benefit. Actually, it would just change the code in libalias. It wouldn't change the kernel at all, except that it would make two 16-bit unsigned quantities available to libalias. (These variables might be instanced in jails, by the way.) >You know, since we're talking about blocking specific ports, port ranges >for specific applications, etc... it almost sounds like this is a firewall >issue. ipfw can already filter by uid, and you can already deny packets >to / from port ranges, so maybe it would be possible to add a quick hack >into the port binding routines that would check to see if sending a packet >to / from that port would be valid before completing the bind. Interesting point. After all, my original situation came up because there were conflicts between what IPFW and libalias thought would be valid ports. >Of course, >that would only give you deny capabilities, but I think that might be good >enough for your purposes, and it should be relatively straightforward to >implement. Also, it would not break ephemeral port binding, as that piece >of code will simply try all possible ports in the range before giving up. > >Unfortunately, I'm not familiar with ipfw's internals at all, I do not >know how easy it would be to query it for allow / deny with just a few >bits of ip information. Hmmm.... If you want to do this, It might be better to make a global bitmap whose contents are set by whatever firewall is in operation (IPFW, ipf, pf) and then masked by allowed port ranges. This would be a simple, fixed overhead operation. And it would probably speed the random, nondeterministic process via which libalias currentl picks a port. Yes, it'd waste some ports if you had snaky firewall rules that only sometimes blocked a port. But it's not worth the time it would take to test all the rules, which might depend on src/dst addresses, etc. --Brett