Re: Securing bind..
On Sun, 30 Dec 2001 16:17, Jor-el wrote:
> On Sun, 30 Dec 2001, Russell Coker wrote:
> > Also don't allow recursion from outside machines.
> Why does this help?
When someone sends a recursive query to your server then they know (with a
good degree of accuracy) what requests are going to be made by that server
and what responses will be expected. So you can send a recursive query for
www.microsoft.com, then send a dozen packets appearing to be responses from
the Microsoft DNS servers giving an IP address of one of your servers. While
you're at it you make sure that the false packets you sent had long TTL
entries so that they stay in the cache for a while. Then suddenly you have
all clients of that DNS server thinking that the MS servers are on your IP
addresses (with lots of potential for abuse).
Another issue is that if at some future time a bug is discovered in bind that
results in a security hole when doing recursion then you want to only be
vulnerable to your own network (who you can hunt down if they abuse it)
rather than the rest of the world.
> > Another possibility is to have the port for outgoing connections be
> > something other than 53 (54 seems unused) and use iptables or ipchains to
> > block data from the outside world coming to port 53.
> Security through obscurity? Quite frankly, I find this strategy
Please read my messages carefully before flaming me.
DNS cache machine sents out requests from source port 54 (not obscure - every
administrator of every DNS server on the net can easily discover this).
Recursive requests go to port 53 (getting a DNS client to even talk to
another port is difficult or impossible depending on the client).
iptables/ipchains blocks access to port 53 from untrusted IPs (IE everything
outside your LAN or dialup pool).
Bind will not be expecting any data other than replies to it's requests on
port 54 (the port that is open to the outside world) so even if you screw up
in your configuration of bind to not allow recursion from the outside world
you're still protected.
Smart people NEVER rely on only one layer of protection if they can avoid it.
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page