Date: Fri, 26 Dec 2003 13:59:57 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Brett Glass <brett@lariat.org> Cc: net@freebsd.org Subject: Re: Controlling ports used by natd Message-ID: <20031226135400.D22953@odysseus.silby.com> In-Reply-To: <6.0.0.22.2.20031223023730.037cbd28@localhost> References: <200312120312.UAA10720@lariat.org> <20031212074519.GA23452@pit.databus.com> <20031212083522.GA24267@pit.databus.com> <20031212181944.GA33245@pit.databus.com> <20031213001913.GA40544@pit.databus.com> <20031222182913.M2799@odysseus.silby.com> <6.0.0.22.2.20031222222449.03cd58c8@localhost> <6.0.0.22.2.20031223023730.037cbd28@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 23 Dec 2003, Brett Glass wrote: > 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.) Ah, so you want a central location for all users of libalias to pull settings from. I think that might be better served by a /etc/libalias.conf or something. > 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 The problem is that a bitmap is really too simplistic, because you might allow certain ports to certain IPs and not others. I don't think the overhead of checking ipfw would be too great, considering that every packet would normally go through all those rules anyway; my concern is simply that ipfw / ipf do not have a "test" function that will run without a real packet being passed. Well, in any case, I don't have time to work on this project anytime soon. If one of you guys can come up with some relatively simple solution to the problem (perhaps some simple comma-delimited sysctl which lists ports to deny) that works, I'd be happy to look into merging it. Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031226135400.D22953>