Recently I have been watching my log files a lot more closely. While doing so, I noticed A LOT of interesting things. The first I will mention is, for the love of god just block all of the Chinese IP space. The vast majority of password cracking attempts are from China, and reporting it to them does absolutely nothing.

 

But recently, something else caught my eye.

 Feb 10 22:55:37 core named[18088]: client 83.117.170.114#2478: transfer of 'fazey.org/IN': AXFR started
 Feb 10 22:55:37 core named[18088]: client 83.117.170.114#2478: transfer of 'fazey.org/IN': AXFR ended

Wait a minute… Did that IP just attempt a zone transfer? Worse yet…did my DNS server actually do it? Sure as shit it did.

 

So, what is a zone transfer(AXFR)?
Well, when you have a slave DNS server, it will periodically dump your zones and update itself. So there is a feature called a zone transfer. It provides all of the records for a given zone. By default zone transfers are allowed from all IPs. So if you have configured your own bind/named, it is easy to miss.

 

So how do we do it?
You do a dig at the nameserver for the domain, and you append the request AXFR. If successful, the output will look like this:

 [root@core log]# dig @ns1.fazey.org fazey.org AXFR
 
 ; <<>> DiG 9.6.2-P2-RedHat-9.6.2-4.P2.fc11 <<>> @ns1.fazey.org fazey.org AXFR
 ; (1 server found)
 ;; global options: +cmd
 fazey.org.              86400   IN      SOA     fazey.org. root.fazey.org. 2012040905 28800 7200 604800 86400
 fazey.org.              86400   IN      NS      ns1.fazey.org.
 fazey.org.              86400   IN      NS      ns2.fazey.org.
 fazey.org.              86400   IN      MX      10 mail.fazey.org.
 fazey.org.              86400   IN      A       64.85.161.114
 mail.fazey.org.         86400   IN      A       64.85.161.115
 [...]
 ns1.fazey.org.          86400   IN      A       64.85.161.114
 ns2.fazey.org.          86400   IN      A       64.85.161.115
 www.fazey.org.          86400   IN      CNAME   fazey.org.
 fazey.org.              86400   IN      SOA     fazey.org. root.fazey.org. 2012040905 28800 7200 604800 86400
 ;; Query time: 5 msec
 ;; SERVER: 64.85.161.114#53(64.85.161.114)
 ;; WHEN: Tue Feb 12 18:50:50 2013
 ;; XFR size: 26 records (messages 1, bytes 619)

 [root@core log]#

As you can see, being able to dump my entire zone file would make doing recon a breeze for any attacker.

So how do we fix it? edit your /etc/named.conf, and there is a field called options:


 options {
         directory "/var/named";
         dnssec-enable yes;
         dnssec-validation yes;
         dnssec-lookaside . trust-anchor dlv.isc.org.;
         allow-transfer { none;};
         version "[null]";
 };

The two options we add are:

  • allow-transfer { none;};
  • version “[null]”;

These two directives prevent version requests, and zone transfers. If you have a slave DNS server, where it says none, you would put the IP of your slave. That would allow your slave DNS server to function, but not leave you wide open for zone transfers. I recommend everyone use these options in their global option config.

So, we added our config, and we restarted named. Now, lets take a look at what the request returns:

 [root@core log]# dig @ns1.fazey.org fazey.org AXFR
 
 ; <<>> DiG 9.6.2-P2-RedHat-9.6.2-4.P2.fc11 <<>> @ns1.fazey.org fazey.org AXFR
 ; (1 server found)
 ;; global options: +cmd
 ; Transfer failed.
 [root@core log]#

As you can see, we now have the desired affect of being rejected. Do yourself a favor and get your configuration updated before you notice the foreign IPs attempting zone transfers.

Related Posts