Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Dec 2003 02:47:32 -0700
From:      Brett Glass <brett@lariat.org>
To:        Mike Silbersack <silby@silby.com>
Cc:        net@freebsd.org
Subject:   Re: Controlling ports used by natd
Message-ID:  <6.0.0.22.2.20031223023730.037cbd28@localhost>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.0.0.22.2.20031223023730.037cbd28>