Hi

I have made a posting here: http://www.linuxquestions.org/questi...stions-748932/

It was suggested I post my questions on the security forum, so here goes.

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 am still a "green ninja" when it comes to DNS so I would like to ask the following questions.

My work pc is connected to the internet using a temporary internet connection which I am testing out. My server is connected to the internet via a DSL router. So both machines have different IP's which is great for testing purposes.

That said, 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? (I know of scapy & hping are there any others available)?

TIA
wvw

If you're only running one DNS server, you should block 53/tcp. That socket is only used for domain transfers to other authoritative servers. That will stop you from "telnetting" to your DNS server as well.

UDP is the transport for DNS queries - and you can't telnet to that because telnet is a TCP protocol.

Metasploit is a framework commonly used to pentest many things, including DNS.

So what you are saying is when I have successfully telneted to my server on port 53 I cannot do much in the form of sending commands as such? This is best done with software (like metasploit)?

That's not what I said at all.

I said, if you're not replicating your DNS between authoritive DNS servers, then you should block 53/tcp connections from everyone to avoid the issue of abuse and exploitation completely.

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.

Hi Admiral Beotch

I think I misquoted you. When I read your reply to my quote, I realised what you had said and what I was looking for were 2 completely different pieces of information. Sorry about the misunderstanding.

Thanks for the reply though.

Hi unSpawn

WOW! What a beautiful post! I have had a quick read through it and am tempted to say that it covers a few of the questions I had about DNS. Although I like the idea of securing each layer, before looking at external exploits/attacks.

I am re-reading it step by step to make sure I understand everything from your post.

I think you should blog that post

Thank you very much for the decent reply

No worries here. Hope you got the info you needed.

What he said ;-p

LoLerz