[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ISN] Thoughts About "Protection Against BIND"
By Paul Vixie
Oct 11, 2004
Imagine my surprise upon reading a BBC article which identified ISC
BIND as the top security vulnerability to UNIX systems. At ISC, we
have striven for a decade to repair BIND's reputation, and by all
accounts we have made great progress. "What could this be about," I
wondered, as I scanned the BBC article for more details.
It turns out that BBC was merely parroting what it had been told by
OK, let's see what SANS has to say:
Top Vulnerabilities to UNIX Systems (U)
U1. BIND Domain Name System
Ouch! So at this point I'm asking, "OK, what have we done wrong this
The Berkeley Internet Name Domain (BIND) package has become the
worlds most widely used implementation of the Domain Name Service (DNS).
DNS is a critical system that facilitates the conversion of hostnames
(e.g. www.sans.org) into the corresponding registered IP address.
Yeah, yeah, so far, so good. What's the problem, though?
Due to the ubiquity and critical nature of BIND, it has been made the
target of frequent attack.
Ubiquity isn't a vulnerability, though... So, I kept reading:
Denial of Service (DoS) attacks, which generally result in a complete
loss of naming services to Internet sites, have long plagued BIND.
Um. Actually, DDoS attacks do not plague BIND. In fact, DDoS attacks
have nothing to do with BIND per se -- a DDoS is an attack on a
network, and will affect all services offered by that network,
including web services like those offered by Amazon and Ebay. So, what
can they mean? Are they among the many people who are confused about
the difference between BIND (which is software) and DNS (which is a
protocol and a service)? In other words, do they really mean that DDoS
attacks have long plagued DNS?
If so, then the mystery actually just deepens. UltraDNS and Akamai
both offer DNS services and both of them wrote their own software (so,
they are not running BIND), yet both of them have been the victim of
high profile DDoS attacks which affected very visible customers
including Google. Why would SANS single out BIND as a DDoS target,
when DDoS attacks are not against software, and recent DDoS attacks
against DNS have not involved BIND?
So, still mystified, I kept reading:
Various other attacks such as buffer overflows and cache poisoning
have been discovered within BIND.
Well, OK, they've got that part right at least. The BIND software that
was part of BSD was terrible. And after wrestling with it for a
decade, ISC decided to rewrite it from scratch. The result, BIND9, is
Although the BIND development team has historically been quick to
respond to and/or repair vulnerabilities, an excessive number of
outdated, mis-configured and/or vulnerable servers still remain in
By the above-quoted text, this whole article is due to older versions
of BIND and mis-configured servers running BIND, yet the title of the
article was simply "BIND Domain Name System". This seems somewhat
But I kept reading.
A number of factors contribute to this condition. Chief among them
are administrators who are not aware of security upgrades, systems which
are running BIND daemon (called "named") unnecessarily, and bad
configuration files. Any of these can affect a denial of service, a
buffer overflow or DNS cache poisoning.
Yes, that's all true. I heard someone from Microsoft say that if they
could just get people to upgrade from Win/95 and apply published
patches, the whole Internet would be safer. And that's also true. I
don't quite understand SANS's reason for mentioning it, though.
"Unpatched Or Misconfigured Software Is Unsafe" is not exactly
headline news. But if they like that one, how does "Either A Democrat
Or A Republican Will Be Next U.S. President" sound? It's disturbing,
it's true, and everybody already knows it, so, "so what?"
But you've got to understand something -- I know some people who work
at SANS and those people -- the ones I know -- are not idiots. So, I
Among the most recently discovered BIND weaknesses was a denial of
service discussed in CERT Advisory CA-2002-15. In this case, an
attacker could send specific DNS packets to force an internal
consistency check which itself is vulnerable, causing the BIND daemon
to shut down. Another was a buffer overflow attack, discussed in CERT
Advisory CA-2002-19, in which an attacker could utilize vulnerable
implementations of the DNS resolver libraries. By sending malicious
DNS responses, the attacker could exploit this vulnerability and
execute arbitrary code or even cause a denial of service.
I love this! Thank you, SANS, for helping to get the word out. We've
been telling our vendors and our user community to stop running or
shipping BIND versions containing these vulnerabilities for years now.
Several years, in fact. Ever since we cooperated in disclosing and
repairing those problems. But it's 2004, and those two vulnerabilities
were published in 2002, so why would it make any sense to announce
them in 2004? Are they still newsworthy?
A further risk is posed by a vulnerable BIND server, which may be
compromised and used as a repository for illicit material without the
administrator's knowledge, or in stepping-stone attacks which use the
server as a platform for further malicious activity.
I hate this! Damn you, SANS, for making me remember the fictional
State Science Institute and its condemnation-without-facts of Reardon
Metal. For the record, there has never been an exploit of the kind
you're describing in any version of BIND9, and there is no known
exploit of this kind in the latest version of BIND8, or even the
OK, so by this point in reading SANS's article, I'm angry, and I'm
starting to think of the article as a "hit piece". But I kept reading:
U1.2 Operating Systems Affected
Just about every UNIX and Linux system is distributed with some
version of BIND. The installation of BIND can be intentional for
server purposes or unintentional in a general installation. A binary
version of BIND is also available for the Windows platform.
It is widely considered to be good practice to run a non-authoritative
BIND server on every host, for the purpose of caching-for-reuse all
data fetched from the global DNS. And for the record, full buildable
open source code is available for BIND on Windows -- not just
"What can they be thinking?" is what I was thinking at this point.
U1.4 How to Determine if you are Vulnerable
Any DNS server running a version of BIND that was bundled with the
operating system, should be compared against the current patches
released by the appropriate vendor. If a running version of BIND is
compiled from source from the Internet Software Consortium (ISC), it
should be checked to ensure it is the latest version. Outdated and/or
un-patched versions of BIND are most likely vulnerable.
All true, every word of it.
On most system implementations, the command "named -v" will show the
installed BIND version enumerated as X.Y.Z where X is the major
version, Y is the minor version, and Z is a patch level. Currently
the three major versions for BIND are 4, 8 and 9. If on is running a BIND
server built from source, one should avoid using version 4, opting
instead for version 9. You can retrieve the latest source, version
9.3.0rc2, from the ISC.
Actually, the latest version is 9.3.0 (it's not just a release
candidate any more). But it's sure nice to hear them calling us ISC.
Just "ISC", though, please, and never "the ISC". (A lawyer told me to
A proactive approach to maintaining the security of BIND is to
subscribe to customized alerting and vulnerability reports, such as
those available from SANS or by keeping up with advisories posted at
OSVDB. In addition to security alerts, an updated vulnerability
scanner can be highly effective in diagnosing any potential
vulnerabilities within DNS systems.
Or, interested parties could join ISC's BIND Forum, with or without
the Advanced Security Notification option. You'll not only get the
straight scoop on upcoming releases, you can help set our priorities,
and help pay the production cost of BIND. We (ISC) are a nonprofit
corporation, and BIND is completely free software -- more free even
than FSF/GNU/Linux, since it can be bundled or repackaged or otherwise
redistributed with or without source code, and with no license or
royalty payments of any kind.
Or, interested parties could engage ISC in a support contract for
BIND, which would include several of the above-described benefits of
the our BIND Forum, but would also get you high-quality phone/e-mail
(I'm not just setting the record straight -- a lot of folks just don't
know about ISC's BIND Forum and BIND Support offerings.)
U1.5 How to Protect Against It
OK, wait just a minute. They've got a section entitled "How to
Determine if you are Vulnerable" and now one entitled "How to Protect
Against It" and the "it" in question is (from the title of this
article) "BIND Domain Name System". Do folks really need to determine
if they are vulnerable to BIND? And, for that matter, do folks really
need to be protected against BIND?
But I digress. Fortunately we're almost at the end of this thing.
To generally protect against BIND vulnerabilities:
Disable the BIND daemon (called "named") on any system which is not
specifically designated and authorized to be a DNS server.
This would be a mistake. If your local DNS policy makes every
workstation and every server into its own "caching recursive
forwarding name server" then you are helping yourself and helping the
Internet and you shouldn't stop just because SANS tells you to. But
one of the other things they recommend is a great idea:
Apply all vendor patches or upgrade DNS servers to the latest
version. For more information about hardening a BIND installation,
see the articles about securing name services as referenced in CERT's
UNIX Security Checklist.
For patches and checklists, you can also just visit ISC's BIND Home
Page at <http://www.isc.org/sw/bind>. ISC publishes links to useful
things about BIND configuration, even if they originate elsewhere.
To complicate automated attacks or scans of a system, hide the
"Version String" banner in BIND by replacing the actual version of
BIND with a bogus version number in the "named.conf" file options
This is just foolishness. Any attacker whose age is requires more than
one digit to describe will just "fingerprint" your system, including
your kernel and all of your services including DNS. They don't need to
know what version string you report, and they wouldn't believe it, and
they've stopped asking.
And SANS ought to *know* that; moreover, they ought to be telling
Permit zone transfers only to secondary DNS servers in trusted
I'm not sure what this means but I think I don't like the sound of it.
You should not do anything special about parent or child domains --
just create them, properly delegate them, and let DNS figure out where
they are and how to reach them.
Jail: To prevent a compromised BIND service from exposing ones entire
system, restrict BIND so that it runs as a non-privileged user in a
chroot()ed directory. For BIND 9, see:
This is a great idea, which is why we have it as a standard BIND9
feature, and why we describe it in the standard BIND documentation.
Disable recursion and glue fetching to defend against DNS cache
I think that what they mean is "don't run authority service and
recursive service in the same name server", and this is good advice.
It's so good in fact that we wrote about it in , specifically
ISC-TN-2002-2. Yup, two years ago. I guess it isn't news?
To protect against recently discovered BIND vulnerabilities:
For the Denial of Service Vulnerability on ISC BIND 9:
I'm sorry, I know this sounds catty, but... 2002 is "recent"?
Multiple Denial of Service vulnerabilities on ISC BIND 8:
Better still, just don't run BIND8 now that BIND9 is solid. But the
URL they give makes good reading, even if I do say so myself.
Cache poisoning via negative responses:
OK, to give SANS credit, they found something that's less than two
years old. However, it's in BIND8. Oops. You should all upgrade to
BIND9 now. Even FreeBSD now ships BIND9 as their default name server.
BIND8 is dead! Long live the king!
There exist many excellent guides to hardening BIND. One excellent
guide on hardening BIND on Solaris systems, as well as additional
references for BIND documentation, can be viewed at Running the BIND9
DNS Server Securely and the archives of BIND security papers
available from Afentis. You can also view documentation covering
general BIND security practices.
Those are good articles. But Jacco's site at <http://www.bind9.net/>
is also very good, and includes all kinds of useful links. Education
Administrators can also look at alternatives to BIND such as DJBDNS
located at http://cr.yp.to/djbdns.html.
OK, so some of you were wondering why I bothered to respond to this
obvious "hit piece" written by someone without much background in the
field -- maybe the same yet-to-be-fired marketing wizard who came up
with the name "Internet Storm Center" when the term ISC had another,
much stronger, much older, meaning. I was going to Just Hit Delete --
something you should never do with spam, by the way! Until I saw the
DJBDNS reference. Mr. Bernstein has what could politely be called a
grudge against... well, almost everybody. His software seems to work,
and it has a loyal and committed user base. But if you're going to
look at alternatives to BIND, you need more options, and you need a
For more options, check out Nominum's ANS and CNS products, and
NLNetLabs' "NSD", and Cisco's DNS/DHCP Manager, and Microsoft's
Advanced Server product. (I'm sorry if I'm leaving somebody out,
that's off the top of my head.)
For a better reason, discard "I don't want to have to learn about
patches and apply them every year or two" since no vendor will ever be
able to guaranty this. If you want help staying patched, talk to ISC
about BIND support, or talk to your operating system vendor, or talk
to your ISP. Help is out there.
My faith in and charity toward SANS has taken a sharp step downward
Maintainer/author, BIND4.9 - BIND8.1
Co-founder and President, ISC
Open Source Vulnerability Database (OSVDB) Everything is Vulnerable - http://www.osvdb.org/