Monday, July 23, 2007

Remove LAME Logging and Version Exposure in BIND

Got LAME server errors? Are you exposing your BIND version?

Problem Scenario

Are lame-server errors filling up your logs? Are you letting bind send its version out to potential attackers? You can fix these issues with some simple changes.

If you look in your message logs, you may see an error about a “lame server”. A lame server is when the NS record for a domain specifies a server that is not authoritative for the domain.

Cause

For example, the NS record for www.domain.com may list ns1.domain.com as one of its nameserver; however, if you actually query ns1.domain.com, the nameserver does not answer as an authoritative server. The latter is due to a mis-configuration of that nameserver, not yours. Lame servers are increasingly common as more and more people run their own DNS, often with improper configurations. Errors will look something like this in your messages log:


lame server resolving ‘www.domain.com'
 (in ‘domain.com’?) : 192.168.1.1#53: 1 Time(s)

Impact

On a busy server, especially if you have a lot of users and email traffic, your servers logs can fill up with lame-server entries, thus obscuring more important system messages. A simple configuration change, outlined below, can stop lame server logging. We will get to the changes soon, but first, you may also want to know how to hide your bind version.
BIND Version

Solution

The file that you need to change is:

/etc/named.conf

To disable lame logging errors, add the logging section as given below.

options {
 directory “/var/named”;
 dump-file “/var/named/data/cache_dump.db”;
 statistics-file “/var/named/data/named_stats.txt”;
};
logging {
 category lame-servers { null; };
};


Add-on

BIND has had a history of exploits and security issues. Many scanners and exploit tools rely on the version number to identify exploitable servers. These scanners note the version and flag the server for later investigation by the hacker. Getting your server to show the version of BIND is very easy with dig unless secured at Server end.

VERSION.BIND. 0 CH TXT “8.2.3-REL”

Now set your bind version simply change the file to include these statements.

options {
 directory “/var/named”;
 dump-file “/var/named/data/cache_dump.db”;
 statistics-file “/var/named/data/named_stats.txt”;
version “surely you must be joking”;
};

Save these changes and then restart bind. You should now not have lame-server errors in your logs nor should a dig return the version of your BIND server.

To make sure the changes worked, run the following command:
dig @ns1.domain.com version.bind chaos txt

Now your server should return the string you set in the configuration file. As mentioned before, this is not a substitute to updating BIND, but these simple are a part of a comprehensive approach to server security. For more information on BIND, see the official documents at the BIND web site.

1 comment:

Anonymous said...

hey dude nice one... I also have a nice tech site at www.itech7.com If you permit we can exchange links.

AT&T USA | Internet not working | Fix by custom APN

If the AT&T Mobile internet is not working on your cellphone, it can be fixed easily by adding an APN configuration. You can read this a...