nessus shows bind running?

@Crisis:

Could this be from the way linodes are configured via UML, or do I need to look into this issue more?
I can't think of any reason why this would be UML specific…

-Chris

Well seems nessus shows it, but nmap doesn't, and I can't see anything opening port 53 on netstat.

Very odd.

If you telnet to 53, do you get a RST?

It refuses connections on port 53.

Then nothing is listening. Nessus is being dumb.

@mcowger:

Then nothing is listening. Nessus is being dumb.

Unless this ghost DNS server was listening on UDP ports and not TCP ports; telnet uses TCP and port 53 refusing a telnet connection only means that there is no DNS server listening for TCP connections on that port. There might be a DNS server listening for UDP packets on that port though.

Hmm any other good way to check for this?

I am positive that I have not installed Bind.

I ran chkrootkit, which didn't find anything, but that can only tell you so much…

Part of me is thinking this is getting picked up somehow because of the configuration of the linode servers, but I am not sure.

Anyone else willing to run nessus on their lindoe to check for flase Bind/port 53 detections?

@bji:

@mcowger:

Then nothing is listening. Nessus is being dumb.

Unless this ghost DNS server was listening on UDP ports and not TCP ports; telnet uses TCP and port 53 refusing a telnet connection only means that there is no DNS server listening for TCP connections on that port. There might be a DNS server listening for UDP packets on that port though.

Not true - BIND listens on both TCP and UDP port 53…if it were a vulnerable version of bind (as opposed to some other (non RFC compliant) DNS server, it would have listened on TCP/53 as well.

Where are you running your scan from? If it's from the box itself, there might be something answering only from the localhost. If you're running it from your ISP account, they might be transparently redirecting DNS queries to their servers.

And yes, some ISPs do this. It saves dealing with people who have their DNS mis-configured. Instead of fielding support calls because someone can't reach a site, redirect all DNS to your own servers so it just works no matter how they have it configured.

If you want a scan from outside, send me your IP and I can run one from my linode for you. I promise if I find something I won't crack it! :D

Oh, and check inetd/xinted, it might be running from there.

Just my thoughts.

–James

Thanks irgeek, that idea about the ISP redirecting DNS queries is logical. I am running it from a different linux box at my home network.

I ran into a similar situation once with a dialup ISP I once used. I got onto an IRC channel, and a channel op thought that I was running an IRC daemon on my IP. It turned out, the ISP was redirecting connections to port 6667 on their dialup IPs to their own EFnet server.