pavement

BIND, securing

From FreeBSDwiki
(Difference between revisions)
Jump to: navigation, search
(minor updates)
m (Reverted edits by DavidYoung (talk) to last revision by 200.38.30.168)
Line 1: Line 1:
 +
==Your DNS network design==
 +
Ideally, the strongest layout consists of '''at least''' two DNS servers on two wholly separate networks -- separate 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).
  
== Mr. Happy Man ==
+
==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 [[ACL]]s or a firewall etc).
  
For six hours each day, Bermudas Johnny Barnes stands at a busy traffic intersection telling all who pass that he loves them. His delight and sincerity are infectious, and the people of the island love him back. His service is a simple reminder of the power of happiness and loving-kindness to change any day for the better
+
==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 every machine 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.
  
[[http://goodvillenews.com/Mr-Happy-Man-VDrbVr.html Mr. Happy Man]]
+
==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.
  
[[http://goodvillenews.com/wk.html GoodvilleNews.com - good, positive news, inspirational stories, articles]]
+
==Poison is bad==
 +
DNS cache poisoning is one of many REALLY good reasons not to keep running ancient and outdated DNS services (like the BIND4 that shipped on those Sun servers your organization insists on maintaining for at least 30 more years). It's a little complicated to follow if you aren't familiar with the ins and outs and quirks of DNS resolution, but here's how it works:
  
== Guerilla Gardener Plants Joy in Potholes ==
+
# this is an example of a zone file a black hat would use to poison a victim's DNS cache.
 +
# this file is being run by the black hat on his own machine, '''at IP address 1.2.3.4'''.
 +
#
 +
poisoner.tld.      IN SOA  ns.poisoner.tld hostmaster.poisoner.tld. (34; 10800; 3600; 604800; 10;)
 +
 +
poisoner.tld.      IN  NS  ns.victim.tld.  # this record tells anyone asking about poisoner.tld to go to ns.victim.tld
 +
ns.victim.tld.    IN  A  1.2.3.4        # this record is the sneaky one - it "helpfully" tells them that the IP
 +
                                            # address for ns1.victim.tld is THIS machine's IP address!
  
Theyre the bane of cyclists and motorists alike, but one urban gardener has grown a fondness for potholes after deciding to spruce up cities around Europe by filling them up with miniature flower arrangements. Australian Steve Wheen, 34, who lives in London, has been using flowers and small-scale objects to transform urban potholes for the last three years. The self-styled guerrilla gardener has created mini gardens all around his home city but has now decided to bring joy to commuters across Europe with his unusual pothole creations.
+
# this is the bogus version of the victim.tld zone file which the black hat runs on the same
 +
# server as the poison file, above. After ns.victim.tld's cache is poisoned, it will actually
 +
# send users here instead of answering their queries itself!
 +
#
 +
victim.tld.        IN SOA  ns.victim.tld  hostmaster.victim.tld. (34; 10800; 3600; 604800; 10;)
 +
 +
victim.tld.        IN  NS  ns.victim.tld.  # these two records simply say "yes, I'll tell you all about victim.tld, don't 
 +
ns.victim.tld.    IN  A  1.2.3.4        # go anywhere else to ask"
 +
 +
www.victim.tld.    IN  A  1.2.3.5        # this is the IP address of a webpage chock full of spammy ads and malware
  
[[http://goodvillenews.com/Guerilla-Gardener-Plants-Joy-in-Potholes-CnUGQR.html Guerilla Gardener Plants Joy in Potholes]]
+
After the [[black hat]] sets up his domain and the bogus zone files above on his own server, at IP address 1.2.3.4, he asks the ''real'' nameserver for '''victim.tld''' to tell him what the IP address for '''www.poisoner.tld''' is.  Since it doesn't know, it asks '''ns.poisoner.tld''', which tells it that it needs to ask '''ns.victim.tld''' ''at the IP address 1.2.3.4'' for that information.  The victim caches that query result - so from here on out, even though it ''is'' '''ns.victim.tld''', if you ask it how to find '''ns.victim.tld''', it will respond with the [[black hat]]'s IP address, not its own.  And since the first step of client DNS resolution is to resolve the IP address of the [[authoritative nameserver]] for a domain, that further means that from here on out, any time anybody looks up ''any'' URL in the victim.tld domain, they'll get sent to the [[black hat]]'s nameserver - which will cheerfully send them to his own webpage full of ads and malware!
  
[[http://goodvillenews.com/wk.html GoodvilleNews.com - good, positive news, inspirational stories, articles]]
+
The good news is, DNS cache poisoning has been fixed (by refusing to cache query results coming from servers that aren't actually authoritative for the results they are giving) in BIND since 1997.  The bad news is, enough people are still running ancient legacy DNS services that there are still plenty of [[black hat]]s industriously trying to poison everything in sight just to see if it works.
  
== 5 Things You Can Do To Love Your Authentic Self More ==
+
Avoiding DNS cache poisoning is much simpler than understanding it: don't run outdated DNS services, make your authoritative servers non-recursive (don't let them answer questions about domains they aren't authoritative for), and wherever possible, limit public access to any caching DNS servers you run for you and/or your clients' benefit.
  
I had no idea that being your authentic self could make me as rich as Ive become. If I had, Id have done it a lot earlier. Oprah WinfreyIt can be easy to love other people but its not always easy to love your authentic self, am I right?
+
To learn more about poisoning, see Daniel J. Bernstein's article at http://cr.yp.to/djbdns/notes.html#poison
  
[[http://goodvillenews.com/5-Things-You-Can-Do-To-Love-Your-Authentic-Self-More-r2jcXE.html 5 Things You Can Do To Love Your Authentic Self More]]
+
To see if you can be poisoned, see http://ketil.froyn.name/poison.html
  
[[http://goodvillenews.com/wk.html GoodvilleNews.com - good, positive news, inspirational stories, articles]]
+
== See Also ==
  
== Man Climbs Worlds 14 Tallest Peaks ==
+
[[BIND (installing)]], [[BIND (configuring)]], [[BIND (managing)]]
  
Hirotaka Takeuchi has gotten official certification for his feat of climbing the worlds 14 tallest mountains. Hes the 30th person ever and the first Japanese person to accomplish the feat.
+
==External Links==
  
[[http://goodvillenews.com/Man-Climbs-Worlds-14-Tallest-Peaks-f1nJlP.html Man Climbs Worlds 14 Tallest Peaks]]
+
[[http://www.oreilly.com/catalog/dns4/chapter/ch11.html O'Reilly's BIND book's security chapter]]
  
[[http://goodvillenews.com/wk.html GoodvilleNews.com - good, positive news, inspirational stories, articles]]
+
[[http://www.boran.com/security/sp/bind_hardening8.html Hardening BIND 8]]
  
== Learning from the Wisdom of the Body ==
+
[[http://www.boran.com/security/sp/bind9_20010430.html Hardening BIND 9]]
  
"Its amazing that our interpretation of experiences can generate intense visceral responses. The fact that we get goosebumps when we are inspired or afraid is one of many everyday indicators of just how deeply and intricately connected our minds and bodies are. In fact, the mind and body are an intertwined whole -- and there is great wisdom in the totality of our mind-body experience.  
+
[[http://www.boran.com/security/sp/chrooting_bind.html Info on chroot'ing]]
  
[[http://goodvillenews.com/Learning-from-the-Wisdom-of-the-Body-lJQFSo.html Learning from the Wisdom of the Body]]
+
[[http://sysadmin.oreilly.com/news/views_05 ... \n
 
+
[[http://goodvillenews.com/wk.html GoodvilleNews.com - good, positive news, inspirational stories, articles]]
+

Revision as of 17:29, 25 August 2012

Contents

Your DNS network design

Ideally, the strongest layout consists of at least two DNS servers on two wholly separate networks -- separate 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 every machine 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 cache poisoning is one of many REALLY good reasons not to keep running ancient and outdated DNS services (like the BIND4 that shipped on those Sun servers your organization insists on maintaining for at least 30 more years). It's a little complicated to follow if you aren't familiar with the ins and outs and quirks of DNS resolution, but here's how it works:

# this is an example of a zone file a black hat would use to poison a victim's DNS cache.
# this file is being run by the black hat on his own machine, at IP address 1.2.3.4.
#
poisoner.tld.      IN SOA  ns.poisoner.tld hostmaster.poisoner.tld. (34; 10800; 3600; 604800; 10;)

poisoner.tld.      IN  NS  ns.victim.tld.  # this record tells anyone asking about poisoner.tld to go to ns.victim.tld
ns.victim.tld.     IN  A   1.2.3.4         # this record is the sneaky one - it "helpfully" tells them that the IP
                                           # address for ns1.victim.tld is THIS machine's IP address!
# this is the bogus version of the victim.tld zone file which the black hat runs on the same
# server as the poison file, above.  After ns.victim.tld's cache is poisoned, it will actually
# send users here instead of answering their queries itself!
#
victim.tld.        IN SOA  ns.victim.tld   hostmaster.victim.tld. (34; 10800; 3600; 604800; 10;)

victim.tld.        IN  NS  ns.victim.tld.  # these two records simply say "yes, I'll tell you all about victim.tld, don't   
ns.victim.tld.     IN  A   1.2.3.4         # go anywhere else to ask"

www.victim.tld.    IN  A   1.2.3.5         # this is the IP address of a webpage chock full of spammy ads and malware

After the black hat sets up his domain and the bogus zone files above on his own server, at IP address 1.2.3.4, he asks the real nameserver for victim.tld to tell him what the IP address for www.poisoner.tld is. Since it doesn't know, it asks ns.poisoner.tld, which tells it that it needs to ask ns.victim.tld at the IP address 1.2.3.4 for that information. The victim caches that query result - so from here on out, even though it is ns.victim.tld, if you ask it how to find ns.victim.tld, it will respond with the black hat's IP address, not its own. And since the first step of client DNS resolution is to resolve the IP address of the authoritative nameserver for a domain, that further means that from here on out, any time anybody looks up any URL in the victim.tld domain, they'll get sent to the black hat's nameserver - which will cheerfully send them to his own webpage full of ads and malware!

The good news is, DNS cache poisoning has been fixed (by refusing to cache query results coming from servers that aren't actually authoritative for the results they are giving) in BIND since 1997. The bad news is, enough people are still running ancient legacy DNS services that there are still plenty of black hats industriously trying to poison everything in sight just to see if it works.

Avoiding DNS cache poisoning is much simpler than understanding it: don't run outdated DNS services, make your authoritative servers non-recursive (don't let them answer questions about domains they aren't authoritative for), and wherever possible, limit public access to any caching DNS servers you run for you and/or your clients' benefit.

To learn more about poisoning, see Daniel J. Bernstein's article at http://cr.yp.to/djbdns/notes.html#poison

To see if you can be poisoned, see http://ketil.froyn.name/poison.html

See Also

BIND (installing), BIND (configuring), BIND (managing)

External Links

[O'Reilly's BIND book's security chapter]

[Hardening BIND 8]

[Hardening BIND 9]

[Info on chroot'ing]

[[http://sysadmin.oreilly.com/news/views_05 ... \n

Personal tools