Locking down DNS

DNS is the Achilles Heel of the interwebs.  Here are few things you can do to reduce the chances that evil haxors will abuse your bind name server. I will assume you’ve already disabled unnecessary services; I try to do this first on any server I’m setting up.

1) chroot bind

Chroot bind and makes sure it’s not running as root. Chrooting ensures that if your name server is exploited, the evil-doer (carbon-based, binary-based, or both) will only gain access to a very small area of your system that will be of little use to them. In CentOS, it’s very easy to set up a chrooted bind:

yum install bind-chroot -y

The above creates a new directory /var/named/chroot and bind will not have access to any files outside of it and it’s subdirectories. Doing this through yum will also copy any existing named.conf and zone files to the new chroot.

2) limit recursive queries

Recursive queries are requests that your name server is not authoritative for which require information from an outside DNS server.  Recursion should be limited to your own network(s) when possible. Unless you’re an ISP or hosting open DNS, full recursion is not necessary. The allow-recursion setting allows you to define which systems are able to do this, anything else is denied. In your named.conf, under options:

allow-recursion { 192.168.1.0/24;  };

Keep in mind, systems that you are not allowing recursive lookups will still get results for a query if it exists in the DNS cache.

3) limit zone transfers

If you are actually hosting zone files for your domain, you should lock down zone transfers to slaves. If you allow open zone transfers, anyone will have easy access to a list of all the servers in your DNS zones.  Limiting this will at least inconvenience those looking for an easy list of targets on your network. It also minimizes your exposure to undiscovered flaws in DNS. The allow-transfer setting should go under options in named.conf.

allow-transfer { 192.168.1.3; }

To test your server, you can attempt a zone transfer using dig.

dig @192.168.1.2 domainname.com axfr

4) harden your server

Bastille Unix is a system hardening script. It changes the SUID on many executables that only root would need on a DNS server. This is another step in limiting your exposure to unpatched or zero day vulnerabilities. You will first need to build a config running either the curses (bastille -c) or X (bastille -x)  option. Once you’ve selected which items to lock down, you will have the option to enable the config immediately. On CentOS you’ll need some dependencies which are not available in the standard repositories. This HowToForge tutorial goes through the process in perfect detail.

5) lock down SSH access

I also like to disable root logins in sshd_config. This adds another layer haxors need to step through if they’re going to crack root via SSH. I like to limit SSH logins to specific networks via hosts.allow:

sshd : 192.168.1. : allow
sshd : ALL : deny

6) iptables rules

Last, but not least, is a simple firewall. Deny everything by default, open up only what you need, in many cases just SSH and DNS. I’ve been tweaking /etc/sysconfig/iptables, but you’re technically not supposed to edit the file manually. I’m not going to post any rules here since this is something you’ll need to fully think out, and it’s not something you want to take lightly. After you’ve implemented some rules, make sure you test and it behaves as you’d expect.

nathan@nate:~/$ nmap -T4 -PN 192.168.1.2

Starting Nmap 4.62 ( http://nmap.org ) at 2009-01-22 10:26 EST
Interesting ports on 192.168.1.2 (192.168.1.2):
Not shown: 1713 filtered ports
PORT   STATE SERVICE
22/tcp open  ssh
53/tcp open  domain

Nmap done: 1 IP address (1 host up) scanned in 6.044 seconds

Advertisements

About this entry