Security issue in BIND servers

[Kevin Darcy]

Bind Users wrote:

> Hi all
>
> Currently, I run BIND ver 9.1.3 for my both dns servers.
> Sometimes we need to do a zone transfer for remote site, either
> as a Master or Slave server. Therefore, TCP Port 53 was opened up.
> I'm concerned about the security although it was behind firewall as
> TCP port was quite fragile for attacking & hacking activities.
>
> 1) May be I could do some harderning. Any recommendation? How?

As others have pointed out, you should start by hardening the OS. If an
attacker gets into your nameserver through a non-BIND vulnerability, your
nameserver setup could be totally at their mercy and all of your careful
nameserver-protection for naught.

> 2) Is there any facility that BIND 9.1.3 could offered?

Other than the unprivileged and/or chroot facilities carried forward from
BIND 8, you mean? The rewrite of BIND 9 includes a lot of
security-oriented code features, such as near-obsessive sanity checks in
practically every function (including the checking of "magic" numbers in
various data structures to make sure nothing funny is going on) and very
restrictive control of dynamic memory allocation. These should greatly
reduce, if not eliminate, the most common kinds of vulnerabilities.

Note that BIND 9's integration of the zone-transfer-client functionality
(as opposed to being a separate "named-xfer" program as it was in BIND 8)
into named makes running chrooted a lot more convenient and safer than it
was previously. It used to be necessary to replicate lots of device
nodes, shared libraries, etc. for named-xfer, but none of that, if any,
is necessary any more.

> 3) How about the "Chroot" environment; copying BIND to "jail" or TSIG?
> Is there any issues that might occured if one of these items is
> implemented? Who has the experienced?

Running chroot and unprivileged is _de_rigeur_ for anyone who cares about
security, but can sometimes be a hassle, especially if you run a silly OS
that requires the chroot jail to be populated with lots of junk in order
for syslog to work properly. When running unprivileged, there can also be
complications if you want named to handle dynamically-created interfaces.

TSIG is a cryptographic way to secure *transactions*. If you can trust
two nodes, but not necessarily the network separating them, then TSIG can
secure secure zone transfers and/or Dynamic Updates which occur between
them. But if you can't trust the remote node, then TSIG doesn't buy you
as much (because the shared secret on the other node may have been
hijacked). So it's just one piece of a larger security puzzle. Also, like
all shared-secret-based crypto schemes, TSIG doesn't scale particularly
well. DNSSEC (the SIG/NXT/KEY flavor of same) is more scalable, but also
more complex, and may be rather tricky to implement since it's
hierarchical and the public root and TLD zones are not yet DNSSEC-signed.
I also understand that some of the more-obscure aspects of
DNSSEC relating to zone cuts are still being hashed out in the IETF.

> 4) What about Split DNS architecture, is it relates to this matter?

Split DNS doesn't really protect the nameserver itself, but it may
incrementally help protect the security of the whole enterprise by
allowing it to keep its internal names out of its external DNS. The exact
value of this is quite arguable...


- Kevin