BIND, securing
m (→Don't rely on just network security or just host security: use both) |
m (DNS poisoning) |
||
Line 13: | Line 13: | ||
==Don't rely on just network security or just host security: use both== | ==Don't rely on just network security or just host security: use both== | ||
Well, your network has a [[bastion host]] and it's protecting the whole network, including your DNS server, so why worry, right? Right. Maybe. Or Maybe Wrong. Maybe really wrong. In any case, better safe than sorry: recompile your FreeBSD kernel and include [[ipfw]] in it and set your firewall rules to just what you need: UDP/TCP 53 (DNS), TCP 22 (SSH), and possibly your [[webmin]] management port for your networks. | Well, your network has a [[bastion host]] and it's protecting the whole network, including your DNS server, so why worry, right? Right. Maybe. Or Maybe Wrong. Maybe really wrong. In any case, better safe than sorry: recompile your FreeBSD kernel and include [[ipfw]] in it and set your firewall rules to just what you need: UDP/TCP 53 (DNS), TCP 22 (SSH), and possibly your [[webmin]] management port for your networks. | ||
+ | |||
+ | ==Poison is bad== | ||
+ | DNS poisoning is fairly easy to get: run a server that allows recursive lookups and acts as authoritative for your domain. It's that easy. It works like this: a [[black hat]] will get his bad domain, spamandviruses.com and do a lookup against your name server for it. Now your nameserver has the DNS lookup info for spamandviruses.com cached. Then they'll go to their registrar and assign their authoritative DNS server to be ''your'' DNS server. Now they are free to spam and every name lookup for spamandviruses.com goes to YOUR dns server, and within a few days or hours you'll find your DNS server on a blacklist or five. Congratulations, your DNS has been poisoned. | ||
+ | |||
+ | Avoid DNS poisoning: make your authoritative servers non-recursive and run caching servers for your clients and make your slaves public (while keeping your authoritative server(s) stealth'd. | ||
==External Links== | ==External Links== |
Revision as of 14:15, 16 April 2006
Contents |
Your DNS network design
Ideally, the strongest layout consists of at least two DNS servers on two wholly seperate networks -- seperate physically and logically (different locations, different IP nets.) At least two, because really you'll probably want three -- two that people know about and one that people don't know about: your hidden master DNS server. So: make two slave DNS servers, point them to your authoritative nameserver, which for the sake of security should only allow updates TO your slaves and connections FROM your admin's IP addresses and the slave servers. If you can, make it a non-routeable address (10.0.0.0/8, 192.168/16, etc) that your slaves reach either directly or through a NAT'd firewall.
Do Not Pass Go, Do Not Collect 200$, Go Directly to Jail
Setting your DNS server inside a jail means that you're going to have a bit of a pain on the initial setup and install but you'll be that much more secure if your DNS server does get hacked. By placing just what it needs to run and nothing else in the jail, anyone that gets in will have a harder time doing anything with your server or to your network; no compilers means no binaries can be built on your system itself to give you a trojan: your would-be attackers would have to build the binaries somewhere else and copy them over and hope they work on your system. If you've got backups of your DNS data -- and you should, the slaves would essentially function as backups -- then even the dreaded rm -rf / inside your jail shouldn't be fatal: promote your slave to master for all your zones, rm -rf your jail directory and re-create it, make it a slave and copy your data over again by HUP'ing your server and you're good to go (you'll probably want to find out how they got in to do Bad Things so that it doesn't happen again, though).
Don't run as root
Make a dns account to run your nameserver from; block it from accessing the net over anything but UDP/TCP ports 53 (using ACLs or a firewall etc).
Use Views
Views are a feature of BIND 9, essentially it boils down to keeping two sets of data for a given zone and setting an ACL for each of them. So that internally, your network has a DNS server that has records for everymachine you want -- every single networked printer, router, switch, workstation and server, if you like -- and externally, only what needs to be accessible from the world has a record.
Don't rely on just network security or just host security: use both
Well, your network has a bastion host and it's protecting the whole network, including your DNS server, so why worry, right? Right. Maybe. Or Maybe Wrong. Maybe really wrong. In any case, better safe than sorry: recompile your FreeBSD kernel and include ipfw in it and set your firewall rules to just what you need: UDP/TCP 53 (DNS), TCP 22 (SSH), and possibly your webmin management port for your networks.
Poison is bad
DNS poisoning is fairly easy to get: run a server that allows recursive lookups and acts as authoritative for your domain. It's that easy. It works like this: a black hat will get his bad domain, spamandviruses.com and do a lookup against your name server for it. Now your nameserver has the DNS lookup info for spamandviruses.com cached. Then they'll go to their registrar and assign their authoritative DNS server to be your DNS server. Now they are free to spam and every name lookup for spamandviruses.com goes to YOUR dns server, and within a few days or hours you'll find your DNS server on a blacklist or five. Congratulations, your DNS has been poisoned.
Avoid DNS poisoning: make your authoritative servers non-recursive and run caching servers for your clients and make your slaves public (while keeping your authoritative server(s) stealth'd.
External Links
[O'Reilly's BIND book's security chapter]
[Implementing Views in BIND 9, by Cricket Liu]. Thumbing through O'Reilly's DNS & BIND book is highly recommended -- Cricket Liu quite literally wrote the book on DNS.