Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I have have recently run
apt-get update
apt-get upgrade
on a debian etch server and when I do
named -v
I get "BIND 9.3.4-P1.1". Is this version safe from the recent announcement of bind vulnerability to cache poisoning? Or do I need to download some deb file and upgrade with that? Sorry, I just don't know debian that well.
I have have recently run
apt-get update
apt-get upgrade
on a debian etch server and when I do
named -v
I get "BIND 9.3.4-P1.1". Is this version safe from the recent announcement of bind vulnerability to cache poisoning? Or do I need to download some deb file and upgrade with that? Sorry, I just don't know debian that well.
The easiest way I know is to have a PC using your DNS server being used for lookups. Then go to www.dnsstuff.com and you will find a link there to test for this vulnerability. The tables I have been able to find do not answer for all the versions available. I last updated 2 DNS servers that tables did not answer. The test before the update failed and then passed after the update. Most seem to be related to the lack of source port randomization. I am not sure what to tell you if DNS fails the test after the update.
Yeah, you are definitely much better off running an actual test for a vulnerability instead of relying solely on a version number. There are cases when a vulnerability is supposed to be patched in a certain version, but do to human error it wasn't. Those cases don't get noticed until, for example, someone looks at the source code or does some vulnerability testing. Of course, doing tests for all known vulnerabilities on all your packages might be impractical, but in cases such as this extremely serious DNS issue where tests abound I think it's important to test your box as a precaution.
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660
Rep:
Code:
$ dig +short porttest.dns-oarc.net TXT
That will tell you for sure (using the nameserver in your /etc/resolv.conf) if you are vulnerable.
Note that even if you installed the patch, your distribution might have the query-source-port hard-coded to 53 in /etc/named.conf, so you'd still be vulnerable. Also, if you're forwarding requests to another nameserver instead of having your nameserver perform recursive lookups, you may still be vulnerable because the nameserver that you're forwarding to might be vulnerable. Last, it's possible for firewalls to re-write the source ports in a linear, or very poorly randomized fashion, which would maintain a high degree of vulnerability.
The test above will show you, for that machine, whether it's vulnerable to poisoned DNS caches results.
If you are running a caching DNS server and your DNS server does not have port randomization and a strong transaction id generation algorithm, it is vulnerable for cache poisoning. A bag guy can poison your DNS cache with improper data.
Latest stable releases are :
BIND 9.5.0-P2
BIND 9.4.2-P2
BIND 9.3.5-P2
Have a look into the blogs of Dan Kaminsky,who discovered this vulnerability. Check his blogs at http://www.doxpara.com/
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.