dns cache poison

L

lkbryant

Verified User
Joined
Aug 16, 2005
Messages
283
hello

one of my client keep getting dns cache poison vulnerability show up on his mcafee scan alert.

now i want to know, is this something i need to fix where my nameserver resides? or on the server where the web server resides?

currently i have a single nameserver and have multi-server setup for our other servers. the vulnerability was detected on one of those multi-server web server setup.

now, do i patch my main name server, or do i also have to patch my web server as well? (by patch, will just yum update bind do the trick?)


Thanks in advance.
 
How many times do we have to cover this.

Unless your client is using your nameservers for dns resolution to surf the web then its not your nameserver that McAfee is detecting. Your client's isp needs to patch their nameservers.

You should not be running a caching nameserver. You have no reason to.

There are plenty of other posts here that explain this issue and it generally does not affect web hosts at all.
 
i appreciate your reply but that doesn't really solve the problem.

the issue is that it still gets marked like that whenever we run the audit from mcafee.

btw this server is on a a child server as we run a multi-server setup where DNS is handled by separate server.
 
the issue is that it still gets marked like that whenever we run the audit from mcafee.
Click to expand...

You did not say that in the beginning. You said it was your client and in that case it would be his isp that had the problem and was being scanned not your server.

You did not say you were scanning your own server.

You may try putting

Code: 
recursion no;

in the option of /etc/named.conf and then reload named and see if that helps.
 
But don't forget if you do that, that you must have recursive servers in your /etc/resolv.conf file.

Jeff
 
okay well it looks like yum doesn't fix the vulnerability as stated by the mcafee guy here:

--------------
Thank you for contacting McAfee Secure Support.

Tee version of BIND that you are running is suseptable. All stable versions of BIND 9 to date (except the ones released simultaneously with this paper) are vulnerable, i.e. BIND 9 versions 9.4.0-9.4.1, 9.3.0-9.3.4, 9.2.0-9.2.8, 9.1.0-9.1.3 and 9.0.0-9.0.1.



Reference: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2926

Please feel free to contact us if you have any additional questions.
--------------


So what does this mean? is it because im not on centos-plus ?

the bind i have now is: BIND 9.3.4-P1 (seems the newest from yum repo)

what is the best way of going about this issue (upgrading to latest bind)?
 
Yeah me neither but that means the clients can't put up their mcafee hackersafe secured logo on their website. -_-
 
Well I know there are patches out there for it. Did you put the recursion no in your options in named.conf. Is the mcafee thing really looking at the vulnerbility or just a version reply?
 
Our systems run with recursion no; turned in in the last line of the options section.

We keep our systems up to date with yum.

On CentOS4:
Code: 
# named -v
BIND 9.2.4
# grep bind /var/log/yum.log
Jul 27 15:22:03 Erased: bind-chroot
Jul 27 15:27:17 Updated: bind-libs.i386 20:9.2.4-27.0.1.el4
Jul 27 15:27:17 Updated: bind-utils.i386 20:9.2.4-27.0.1.el4
Jul 27 15:27:19 Updated: bind.i386 20:9.2.4-27.0.1.el4
Dec 17 06:26:34 Updated: bind-libs.i386 20:9.2.4-28.el4
Dec 17 06:26:39 Updated: bind-utils.i386 20:9.2.4-28.el4
Dec 17 06:27:05 Updated: bind.i386 20:9.2.4-28.el4
Jul 09 05:07:03 Updated: bind-libs.i386 20:9.2.4-28.0.1.el4
Jul 09 05:07:03 Updated: bind-utils.i386 20:9.2.4-28.0.1.el4
Jul 09 05:07:05 Updated: bind.i386 20:9.2.4-28.0.1.el4
Sep 13 07:17:24 Updated: bind-libs.i386 20:9.2.4-30.el4
Sep 13 07:17:32 Updated: bind-utils.i386 20:9.2.4-30.el4
Sep 13 07:19:01 Updated: bind.i386 20:9.2.4-30.el4
#
and on CentOS5:
Code: 
# named -v
BIND 9.3.4-P1
# grep bind /var/log/yum.log
Sep 24 19:17:48 Updated: bind-libs - 30:9.3.4-6.0.2.P1.el5_2.i386
Sep 24 19:18:04 Updated: bind-utils - 30:9.3.4-6.0.2.P1.el5_2.i386
Sep 24 19:18:35 Updated: bind - 30:9.3.4-6.0.2.P1.el5_2.i386
[root@da14 ~]#
So now do the test on our nameservers yourself from your server (or desktop if you're running Linux, FreeBSD or OS-X). Check a CentOS4 box:
Code: 
$ dig @da12.namelessnet.net www.earthlink.net
Check a CentOS5 box:
Code: 
$ dig @da14.namelessnet.net www.earthlink.net
On both you should get a question section and an authority section but no answer section. Because we're NOT vulnerable.

Now test both of those nameservers using McAfee. If they list us as vulnerable then their software is not testing, but rather doing version lookups. Version lookups will NEVER work on CentOS or RedHat Linux distributions, because they always backport fixes; they never change version numbers. If McAfee is doing it wrong, then that's McAfee's problem, and your clients should get their testing/certifying done somewhere else.

If my servers pass and yours don't, then update to the latest versions or check your configurations.

Jeff
 
Thanks for your help guys, looks like you guys are right about this as they just looking at version replies.

I had to manually contact them and let them know this was a false alarm.

Strange how they would allow this type of automated auditing when it would clearly not work on redhat-based systems or any backporting os's.
 
You must log in or register to reply here.
Back
Top