[Dshield] Jail and Harden DNS

Jon R. Kibler Jon.Kibler at aset.com
Sun Mar 28 20:15:46 GMT 2004


Tony Earnshaw wrote:
> 
<SNIP!>
> 
> I wouldn't see any reason to run it chrooted, any more than I see any
> reason to run Postfix 2.0.19 chrooted. My main reason is, that there
> have never been any reported exploits with either. And many have tried
> ;)

There have been exploits reported against earlier versions of BIND, and 
it is only a matter of time before someone breaks this version. The 
reason for chroot-ing named is the same as for getting a flu shot -- it
is preventative medicine; should someone break named, you are protected.

> As a matter of curiosity, why don't you mention the 101 other much more
> susceptible daemons, starting with Apache/PHP and ending with sshd? Not
> to speak of Openssl's ASN.1 and buffer overflow stuff, for which
> static-compiled binaries would seem to pollute much of the exposed *nix
> stuff on the Internet, at the moment?

IMHO, every daemon that runs as root is a potential security risk. Even
if there are no known exploits against a daemon, it does not mean that
it is secure and you should relax your vigilance.

Any daemon that doesn't need to run as root shouldn't. Any daemon that
accesses only a small set of data (such as named) should run chroot-ed.
Unfortunately, many daemons must run as root and cannot be chroot-ed
and still run properly.

Any daemon that is not essential to a system's operation should not be
run (this applies to ALL O/Ses!). Any daemon that transfers data via
clear text (ftp, telnet, imap, pop, r* cmds, etc.) should not be run
and a secure replacement should be used instead.

Furthermore, any user that needs to access only a small set of 
applications should also run as chroot-ed user. (This probably means
that most users should run chroot-ed!)

I mentioned named because it seems to universally be the most 
insecurely configured daemon in default configurations. Our experience
also shows that it is most probed and misused daemon -- exceeding
probes against Apache by usually about 10 to 1. Also, there are many
DOS exploits against named, so it helps to harden it.

(Don't believe that most BIND installations are insecure? Look at the
example following the signature paragraph.)

Yes, there are are lot of daemons with known big holes in them, and there
is little you can do to protect them except to keep them patched. I picked
named because it can be easily protected but few know how. The daemons
with known security holes get a lot of after-the-fact publicity, and
most people keep them patched. Also, many other daemons, such as 
Apache, have default configurations that run them as non-root users, so
most are run as non-root users. By default, named is not!

Bottom line: I wrote the original posting to make people aware there is
a lot you can do to protect yourself against named DOS attacks and to
protect your system WHEN the next named exploit is found. 

As Ben Franklin said, "An ounce or prevention is worth a pound of cure."

Jon
-- 
Jon R. Kibler
Chief Technical Officer
A.S.E.T., Inc.
Charleston, SC  USA
(843) 849-8214



How insecure is most bind configurations?
=========================================
The insecurity of most bind configurations can be easily demonstrated
using the 'host' command and probing a few name servers. In the examples
below, pick any hostname to plug into the examples -- except for some
hostname for which the name server is authoritative.

First, let's pick on the SANS name server: NS1.GIAC.NET
-----
$ host SOMEHOSTNAME NS1.GIAC.NET
Using domain server:
Name: NS1.GIAC.NET
Address: 65.173.218.103#53
Aliases: 

Host SOMEHOSTNAME not found: 5(REFUSED)
-----
This is the response I would have hoped to find. The "REFUSED" indicates that the name server is refusing to answer requests for which it is not authoritative. 

Now let's pick on Earthlink (just about any ISP would do!):
-----
$ host SOMEHOSTNAME itchy.earthlink.net
Using domain server:
Name: itchy.earthlink.net
Address: 207.69.188.196#53
Aliases: 
-----
This is the response that you will see for most name servers. They will successfully perform a cache query, but not a recursive query. If a valid user of this name server had queried on SOMEHOSTNAME recently, it would have returned the IP address of the host. If you had queried with a "type=ANY", it would have returned who it thinks is the authoritative name server for the host.

In other words, because of a sloppy DNS configuration, this name server is doing A LOT of extra work. Work that could be exploited to create a DOS attack against the name server.


Now, let's pick on a REALLY insecure name server:
-----
$ host SOMEHOSTNAME DNS1.SYMPHONYONE.NET
Using domain server:
Name: DNS1.SYMPHONYONE.NET
Address: 64.122.43.162#53
Aliases: 

SOMEHOSTNAME has address 1.2.3.4
-----
This name server will do recursive queries for ANYONE! It is doing A LOT of extra work. It is VERY subject to a DOS attack. (We have sent them at least two notices about their insecure name servers and have never even received an acknowledgment!)

Even worse, this name sever will allow anyone to do a zone transfer of any domain for which they are authoritative. Just try a command something like this:

$ host -t axfr SYMPHONYONE.NET DNS1.SYMPHONYONE.NET


I hope that this example illustrates why name sever security should be taken seriously, even if there are no direct exploits (other than DOS) against BIND.




==================================================
Filtered by: TRUSTEM.COM's Email Filtering Service
http://www.trustem.com/
No Spam. No Viruses. Just Good Clean Email.



More information about the list mailing list