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 SANS.

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 time?”

U1.1 Description

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 pretty solid.

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 production.

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 disingenuous.

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 kept reading:

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 latest BIND4.

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 binaries.

“What can they be thinking?” is what I was thinking at this point. Onward:

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 say that.)

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 support.

(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.)

Onward:

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. Onward:

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 statement.

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 *you* that.

Permit zone transfers only to secondary DNS servers in trusted domains.

That’s passe. Don’t restrict zone transfers based on server IP address; instead, restrict them based on TSIG keys. (SANS ought to know that, etc.)

Disable zone transfers to parent or child domains, using delegation and forwarding instead.

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: http://www.losurs.org/docs/howto/Chroot-BIND.html

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 poisoning

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:
http//www.cert.org/advisories/CA-2002-15.html

I’m sorry, I know this sounds catty, but… 2002 is “recent”?

Multiple Denial of Service vulnerabilities on ISC BIND 8:
http://www.isc.org/products/BIND/bind-security.html

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:
http://www.kb.cert.org/vuls/id/734644

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 is good.

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 better reason.

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 today.

Paul Vixie
Maintainer/author, BIND4.9 - BIND8.1
Co-founder and President, ISC