Controlling ports used by natd

[Mike Silbersack]

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