LinuxQuestions.org - DNS Security related question

Quote:

Originally Posted by wvw (Post 3660449)

I have configured DNS on an ubuntu 8 server and it's working very neatly. However I am very paranoid about the vulnerabilities on port 53. (..) I have telneted to my server (from my workstation) on port 53 and had a connection. What commands can I execute once connected? What software do people use to run malicious code on a DNS Server?

If I understand your other threads OP correctly then you're running a DNS server on your LAN. If that is the case, then as long as you can trust your LAN clients and as long as your DNS server is not exposed to the Internet, the risk of server or data compromise is way low. (Note I won't say "no risk at all" because I do not know your situation and I won't say "don't worry" because that is the wrong approach regardless.)

One approach to assess and mitigate risks could be to divide them in categories, like threats due to (unordered):
- software,
- configuration,
- server and data compromise.

Providing services means people, and other services, will come to trust and depend on them. Choosing the right software for the job is not only important in terms of security but also performance and versatility. For instance if your requirements are way low (maintenance) then for a LAN comprising of say 10 hosts with statically assigned IP addresses you wouldn't even need a DNS server as /etc/hosts or equivalent could do or a tiny caching DNS server like say Pdnsd. On the other hand if you require full-fledged DNS server software to test all possible scenarios then you have some mature, maintained contenders to choose from like ISC BIND (or see here, MaraDNS (or see here) or Djbdns (or see here). "Mature" implies the software has seen years of development, use and support to ensure it is being used in production environments, that critical configuration options are supported and fatal (software!) flaws are corrected. "Maintained" means the software is actively developed and supported (not always easily seen from release versions but a look at CVE vulnerability listings and time-to-fix responses, development and user mailing lists and CVS repo should show activity).

Company or personal preference does play a role in choosing DNS software: if you are (supposed to be ;-p) experienced in say using ISC BIND then it would make sense to build on that unless critical requirements change. If you're not experienced then a good way would be to get a "How Things Work" grip on the DNS protocol itself checking the RFC's at http://www.ietf.org or http://www.faqs.org, the software vendors documentation (say http://www.isc.org/sw/bind/bind-security.php for BIND) and basic DNS configuration HOWTOs like Securing and Optimizing Linux: DNS and BIND (old, PDF, FTP), Chapter 5.7 "Securing BIND" from the (old but extensive and still valid) Securing Debian HOWTO, Create Your Own Web Server With BIND And Apache On CentOS 5 (Simplified) (or see http://www.howtoforge.com/trip_searc...=BIND+tids%3A8).

While it is not a guarantee for the future by looking at current CVE vulnerability listings (and time-to-fix responses) you also have an idea of what to expect in terms of addressing future vulnerabilities (which is important since the DNS protocol itself and acceptance of new security-related features is somewhat, ahh, troublesome to put it politely (http://www.dnssec.net/)) but broadening your horizon wrt RFC's and vulnerabilities will also help you understand threats that are intrinsic to the DNS protocol, especially since running a DNS for public access basically means deliberately exposing security risks, (see the SANS Reading Room on DNS Issues), running services (mitigating compromise: Run ISC BIND/DNS in a chroot jail) or configuration (Securing Debian HOWTO chapter 5.7.1 about not allowing XFERs and such, the CYMRU Secure BIND Template) and fixes like Avoid Cache Poisoning.

At this point you will have addressed your basic setup (What am I serving or divulging and to whom? Do I have any remote slaves? Who is allowed to update zone information?), have addressed local compromise mitigation by either a chroot/jail or virtualization or using MAC like SELinux or GRSecurity, have addressed cache poisoning, rebinding, pharming (nice overview here and here) and access restrictions by configuring the DNS server and auditing by configuring DNS server logging. You might also have configured the firewall to drop bogon traffic and rate-limit requests, deployed a log watcher like Logwatch (Swatch or SEC) to read and report logged problems (also see Menandmice's BIND 8/9 log messages) (also see their nice Q&A at http://www.menandmice.com/knowledgeh...a/default.aspx), a backup system and a Zone Management Tool (common sense, configuration errors), a file integrity checker like Samhain or Aide or even tripwire to ensure software integrity, a general purpose IDS like Snort or Prelude to warn about traffic anomalies and a DNS traffic analyser, all so you can respond to auditing reports by reconfiguring or taking other measures. You might even have run local and remote OpenVAS or Nessus and web-based tests on your OS (after all it doesn't make sense to secure DNS if the OS is a swiss cheese) (http://www.cisecurity.org/bench_linux.html) and DNS to confirm it is not vulnerable (say http://www.bind9.net/dns-tools, https://www.dns-oarc.net and also search for "Dan Kaminsky").

In short what I've tried to point at is that it in a layered security approach you should work through and satisfy each layers requirements before moving on to the next, and that looking for local and remote problems or vulnerabilities does not make much sense if the whole stack isn't secured first. In closing I apologise for the length of this reply but I hope it may also serve others looking for information about DNS.