Skip to main content

Remove LAME Logging and Version Exposure in BIND

Got lame server errors? Are you exposing your bind version?

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.
Simple Bind Configuration Changes
Lame Server Errors

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. 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 do 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)

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

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. Here is an example:
; <<>> DiG 9.2.1 <<>> @ns1.somewhere.com version.bind chaos txt
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27169
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;version.bind. CH TXT

;; ANSWER SECTION:
VERSION.BIND. 0 CH TXT "8.2.3-REL"

;; Query time: 2 msec
;; SERVER: 216.12.210.61#53(ns1.somewhere.com)
;; WHEN: Sun Aug 10 15:02:44 2003
;; MSG SIZE rcvd: 64

As you can see in the answer section, the version of bind is returned. This can allow automated exploit and scanning tools identify your server as a possible target. By making a configuration change, you can switch your version to any string that you like. Historically, the phrase "surely you must be joking" is the string that many system administrators select. Here is an example:
; <<>> DiG 9.2.1 <<>> @ns1.somewhere.com version.bind chaos txt
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44970
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;version.bind. CH TXT

;; ANSWER SECTION:
version.bind. 0 CH TXT "surely you must be joking"

;; Query time: 2 msec
;; SERVER: 64.246.46.230#53(ns1.somewhere.com)
;; WHEN: Sun Aug 10 15:08:16 2003
;; MSG SIZE rcvd: 68

As you can see above, this server does not return any version details.

Security by obfuscation is not a good security policy. By this I mean that by hiding your version number you may disrupt some automated scanning and other tools, but it is not a substitute for keeping BIND updated. Do not rely on this simple configuration change for security. Does it help? Maybe ... but it is not a security solution. The change simply makes it more difficult for hackers to discover what version of BIND you are running.
Updating Your BIND Configuration

Why some of these settings are not default, I do not know. The change is very easy and requires editing of one file.

The file that you need to change is:

/etc/named.conf

options {
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
};



Your IPs of course will be different but otherwise your file will be similar. To disable lame logging errors



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; };
};


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.

Comments

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

Popular posts from this blog

Check remote UDP connectivity from Linux

Hi there, You all know how to check TCP port connectivity from a Linux or UNIX machine to a remote machine using telnet as per th example below $ telnet 127.0.0.1 25 but we can't adopt TELNET to check UDP connectivity. Linux and most of the UNIXes come with a network layer utility called nc (abbreviation for netcat) which is very useful to check UDP connectivity and to explore a lot with both TCP and UDP. An example is shown below # nc -v -u -z -w 3 172.24.16.131 123 Connection to 172.24.16.131 123 port [udp/ntp] succeeded!

The best putty package available

Bored of Black screened Task bar filling putty? Issues with porting Saved sessions from machine to machine? Do you like tabbed SSH sessions? Start using portaputty instead of normal putty and link it with puttycm . Puttycm supports sessions to be saved in its own Database files. You can use the Putty sessions you have saved already right inside putty. You can have any number of databases which allow you to arrange Remote servers in folders and convenient namings. I personally recommend creating Database with puttycm rather than using the sessions saved in putty which doesn't offer any option to create folders and saving sessions under that directory tree. You can even save username/password to get it logged automatically and there is an option to pass commands to be run soon after login. I can't recommend this since some bug was found with these options. Portaputty is a variant of putty which stores all the Configuration data in text files instead of MS Window

PING.sh

#!/usr/bin/env bash ## Ping all machines in a Network PING="$(which ping) -c 1 -W 1" echo "Enter Subnet(eg:192.168.0)" read Subnet echo "Do you want to PING the entire network or a RANGE of IPs ? Enter your choice" echo 1. Ping Entire Network echo 2. Ping a RANGE read choice if [ $choice = 1 ]; then { echo Pinging..... for((i=1;i<255;i++)); do ${PING} ${Subnet}.${i} > /dev/null 2> /dev/null if [ $? -eq 0 ]; then echo -e "${Subnet}.${i} is up" fi done } fi if [ $choice = 2 ]; then { echo Enter the Starting IP of Range read a echo Enter the Last IP of Range read b echo Pinging..... for((i=$a;i<$b;i++)); do ${PING} ${Subnet}.${i} > /dev/null 2> /dev/null if [ $? -eq 0 ]; then echo -e "${Subnet}.${i} is up" fi done } fi exit 0