Concealing a Name Servers Version

Concealing a Name Server s Version

7.2.1 Problem

Modern BIND name servers respond with their version to queries for TXT records attached to the pseudo-domain name version.bind in the CHAOSNET class. For example:

$ dig version.bind txt chaos ; <<>> DiG 9.2.1 <<>> version.bind txt chaos ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5096 ;; 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 "9.2.1"

You want to conceal the version a name server returns.

7.2.2 Solution

The simplest way to accomplish this is to use the version options substatement. The version substatement takes it as a string to return to version.bind queries as an argument. For example:

options { directory "/var/named"; version "None of your business"; };

Some folks, however, don't want their name servers to return anything, not even a bogus answer, to unauthorized queriers. Others want authorized queriers to see the real version instead of a bogus one.

To set that up, create a CHAOSNET zone called bind and a zone statement for it in named.conf. Then use allow-query to restrict queries to the zone. Here's a sample bind zone data file:

$TTL 1d @ CH SOA ns1.foo.example. hostmaster.foo.example. ( 2002052600 86400 3600 604800 3600 ) CH NS ns1.foo.example. version.bind. CH TXT "BIND 9.2.1"

Notice that the records in the bind zone are all in the CHAOSNET class, as you would expect.

On a BIND 8 name server, the zone statement for the bind zone might look like this:

zone "bind" chaos { type master; file "db.bind"; allow-query { localnets; }; };

On BIND 9, the configuration is a little more complicated. Even if you don't explicitly use views, BIND 9 creates zones in an implicit "default" view in the Internet class. So you can't just create a CHAOSNET zone in the default view, because the zone and the view have different classes: you need to create a new CHAOSNET view and define the bind zone in it. And, if you weren't using views before, you need to create an explicit Internet view for your other zones and move their zone statements into the view.

For example, if your BIND 9 name server's named.conf file looks like this now:

options { directory "/var/named"; }; zone "foo.example" { type master; file "db.foo.example"; };

You might change it to look like this:

options { directory "/var/named"; }; view internet in { zone "foo.example" { type master; file "db.foo.example"; }; }; view chaosnet chaos { zone "bind" { type master; file "db.bind"; allow-query { localnets; }; }; };

7.2.3 Discussion

Camouflaging a name server's version is no substitute for running an up-to-date version of BIND or for configuring the name server securely. About the best you can hope for is that concealing a name server's version will prevent hackers from identifying it as an obvious, first-choice target if the version of BIND it's running has a vulnerability.

7.2.4 See Also

"BIND Version" in Chapter 11 of DNS and BIND.