Zone transfers and the transmission of the zone database information, is a security matter that should not be taken lightly.
We go to great lengths of building a named.conf cfg, and securing who can execute a AXFR, but we rarely do anything to secure the contents of the AXFR from any MiTM.
"Security is only as strong as our weakest link" ; & truly applies here!
Take this gTLD nameserver { 128.16.5.32 } & for the
int gTLD zone. It's was found to be open to the world for AXFR ( zone transfers ) DEC 16 2013
This allows for any individual to harvest potential targets. Maybe not so much or a risk to a gTLD NS, since it lists authoritive NS for various domains with in that gTLD, but how about that
enterprise business that doesn't want to show it's hands, & expose information to the world as to what hosts/node is in it's zone database. It also open up your NS up for abuse & other security risk.
note: A simple email was sent to the contact listed in the SOA, making them aware of their exposure .
So back to our environment , to secure our AXFR from peering eyes, we can encrypt the zone-transfer via a simple ssh-tunnel between SALVES and MASTER. This will provide a simple means for securing the actual zone resource-records, during the AXFR operation. Depending on your security policy and posture , you can mandate various cipher for the execution of this tunnel.
(
e.g 3des AES BLOWFISH etc..... )
To do this tunnel, we will need to make some changes to our configuration files on the DNS name-servers.
note: There's no changes required from within any zone-database files
1:
1st we need to set the slaves to use a loopback addressed interface on our master server. This address will be present in our ssh tunnel. You should validate that the listener is operative on the loopback address at the master ;
( using lsof )
( conducting a AXFR on the master, using our 127net interface )
2:
A ssh-key must be shared between the master and slaves for automation of the logins. We want to avoid having to manually insert any passwords. This key should be secured between the master and all slave(s). And installed in our authorized keys file.
3:
On the slave, you will need to instruct it to use a SSH tunnel for connection to the master NS. I'm using a static defined ssh_config file on my knot_slave that assist with the SSH tunnel setup
( e.g contents of a basic file )
cat /etc/knot/ssh_config master
User root
HostName master
CheckHostIP no
StrictHostKeyChecking no
Compression yes
ConnectionAttempts 4
LocalForward 53 127.0.0.1:53
IdentityFile /root/.ssh/id_rsa
Port 2022
note: This file relies on a share key between the slave and master for hands-off automated logins, also these hosts sits within the dangerous internet, so sshd is running at the masters & on port 2022 and is also protected via a firewall. This would provide us protection from any script kiddies that are probing port 22/tcp and trying to brute-force/dictionary attack our accounts.
You have host of means to secure the ssh access using any of the following; iptables, firewalls, sshd,etc..... I highly recommend that you pick one method and secure it.
4: So on the masters& slave DNS NS you will have something of the following in our NS configuration files. These entries are from a knot name-server btw.
( a sanitized version of my knotd-master & slave conf file for this blog )
# cat master.conf
system { storage "/etc/knot";
}
interfaces { my_interface { address 127.0.0.1@53; } second_int { address 1.1.1.254@53; }
}
log { syslog { any notice, warning, error; }
}
#keys { key0.blog.hyperfeed.net hmac-md5 "Kyn1C/2NwR79F7wiAhPaJxWuCHWSzfzR95C9pgwAtp3N5hmLZAogusNmlyWFMN6Bdm/Chz9tczDKDW3Mrnn3uQ=="; }
remotes {
slave1 { address <public_address_ofslave>@53; }
loopback { address 127.0.0.1@53; }
}
zones { dnssec-enable on; dnssec-keydir "/etc/knot/key/blog.hyperfeed.net"; blog.hyperfeed.net { file "blog.hyperfeed.net"; xfr-out slave1,loopback; notify-out slave1; } }
log {
stdout { any info, notice; }
stderr { any debug, warning, error; }
syslog {}
file "/tmp/knotd.log" { any all; }
}
and
system { storage "/etc/knot";
}
interfaces { eth_int { address <x.x.x.x>@53; }
}
log { syslog { any notice, warning, error; }
}
#
remotes { master { address 127.0.0.1@53; } }
#
#
#
zones { blog.hyperfeed.net { file "blog.hyperfeed.net"; xfr-in master; notify-in master; } }
log {
stdout { any info, notice; }
stderr { any debug, warning, error; }
syslog {}
file "/tmp/knotd.log" { any all; }
}
And finally, you will need to test the AXFR manually from the slave & monitor the logs on the master. Do this after you have established the ssh tunnel.
AXFR request conducted from the my slave;
knotd.log on master showing a AXFR and via the client at our 127net address;
Okay so this is how you secure a AXFR zone database transfer & with simple encryption. The same principles would be applied for bind named or anything other DNS server package that you run.
The final activity that you would need to build is a check script that validates the ssh tunnel is establish and if not, than restart the
ssh -F for the tunnel.
note: Their used to be a opensource ssh check package but my investigations shows it hasn't been maintain nor would it work in this case.
( example a basic shell script on the slaves )
#!/bin/bash
#
###########################################################################
#
# ######## CHECK SCRIPT EXECUTED VIA CRONTAB EVERY min */1 ##########
# kfelix <at> socpuppets <dot> com #
##########################################################################
#
DATE=`date
+%T_%D`
#
# this variable would be set to your master dns-server ip_address or VIP if behind a VIP
#
MASTER=1.1.1.1
#
#
#
CHK=`lsof –nP
-i | grep $MASTER:2022 | awk ' { print
$2 }' `
#
#
#
if [[ -n "$CHK"
]] ;
then
echo “ We have a tunnel no action required”
;
else
echo “ OMG the tunnel is not up, I will restart
now & send a notice to my OPS team “
ssh
-f -N -F /etc/knot/ssh_config $MASTER ;
mail –s “ SSH TUNNEL $HOSTNAME RESTABLISHED $DATE”
noc@mydomain.com
fi
In conclusion, you could also craft site2site vpn between the DNS-servers. This would require more added resources such as firewall and might not be as easy to implement.
Other solutions that I have used, have based on deployment of OpenSwan Ipsec vpns, running on top of the DNS name-severs directly. Once again this might not be as easy to implement, and depending on the based OS Open/StrongSwan might not be supported.
Since most big public facing name-servers are using UNIX/LINUX, and ssh fits in quite easily. The tunneling of our AXFR & thru these ssh tunnels are effective and easy to deploy.
One other thing that should be pointed out, The NOTIFY from the master ( if enabled ) could be encrypted over the tunnel or not. The NOTIFY doesn't proposed as much risk outside of telling the salve that the zone information has changed for zone xyz and the SOA serial#.
- It's your call on how much of a risk that proposed during a AXFR and if the requirement for securing the notifies.
- Also TSIG is useless in this process, since TSIG does NOT hide or encrypt any part of the data.
- I hope this post become handy for any one hosting multiple zones like in a TLD or ISP environment.
- DNS is a protocol that I've been working with for at least 17+ years and security has never been fully implemented in this internet application
Another ideal that I entertain many many years ago, and deployed with bind; " was a script that took the NOTIFY from the master, and conducted a remote ssh cmd execution to build the tunnel and then refresh the zone in question via rndc ". I found that it worked , but it was quite messy.
It would be nice if the folks at ISC or knot would provide hooks into the current name-servers for the trigger or script execution upon receipt of a NOTIFYs. This would allow you to easy run thru a series of tasks and executions, based on the NOTIFY.
YMMV I hope this shed one ideal of securing AXFR zone-datebase information & specially for slaves that are situation external and require transfers thru the untrusted INTERNET
Freelance Network / Security Engineer
kfelix ----a---t---socpuppets ---d---o---t---com
