OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: [Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo]

From: Doug Barton (dougbFreeBSD.org)
Date: Fri Jul 11 2008 - 12:44:46 CDT


Jeremy Chadwick wrote:

> The problem here is WRT network ACLs. The only solution is to bind BIND
> to a specific IP address and permit any outbound TCP or UDP traffic +
> any inbound TCP or UDP traffic to port 53.

Not quite any inbound traffic, named will pick a source port > 1024. In
the current beta versions there is an option to restrict the ports
chosen to a range.

I'm also not quite sure what kind of server you're talking about here.
If it's authoritative, then by definition you have to allow all inbound
traffic to port 53.

> Most network administrators
> I know of won't like that, as they deny all incoming *and* outgoing
> traffic, then apply permit ACLs. There's no "clean" or "strict" permit
> ACL, while with port XX, you can at least narrow down things UDP-wise a
> bit more.

False economy. The "danger" of allowing inbound UDP traffic is
infinitely less than the danger of having a recursive resolver's cache
poisoned. The new way of things would be to define those UDP ports that
run services other than named on the system, add those to the avoid-*
option(s) in named.conf, and block those ports at the firewall, leaving
everything else open.

Of course, almost any modern firewall should have keep-state
functionality for UDP, so all of this should be moot.

> I'll add that the stock src/etc/namedb/named.conf even advocates the use
> of query-source ...

It doesn't advocate, it gives an example. This is the reason I am
resistant to adding too many examples to our installed named.conf, it is
too easy for people to misinterpret them.

Doug

--

     This .signature sanitized for your protection
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribefreebsd.org"