Domain Name Server (207)
7.3 Securing a DNS Server (20)
7.3.4 Making information harder to get
Like all other programs, the BIND nameserver has features and security holes that can be misused. Criminal hackers (crackers) are well aware of this and keep track of versions and their security related issues. It is wise not to advertise your vulnerabilities so you may want to disable version number reporting in BIND.
Also, bulk name server data can be used to disclose details about your infrastructure. Hence restrictions can be installed to prevent a user from obtaining a large amount of nameserver data or at least to get it in a short timeframe. Another reason to do so is that nameservers are built to answer a large number of short queries in a short timeframe. Having to serve large blobs of data unexpectedly might disrupt services.
It is important to remember that hiding information is security through obscurity. Doing so the easy way to get information has been blocked, but there may be other ways to get the same information. Security through obscurity makes it harder, but not impossible to get the information. It does however introduce a longer timeframe in which you may be able to detect that break-in attempts are being made and act accordingly, for example by blocking the requestors IP address in your firewalls.
7.3.4.1 Hiding the version number
The command
dig @target chaos version.bind txt
will show the version of the BIND name server on host target.
The BIND version can be hidden by entering a version statement inside the options statement in named.conf. In the following example, the version will be set to the string hidden.
options { // ...
// hide bind version version "hidden";
};
The CERT article (Nijssen99) shows a way to limit access to the bind zone. This an alternative to replacing the BIND version.
7.3.4.2 Limiting access
There are several ways to limit access to name server data. First, an access control list must be defined. This is done with the aclstatement.
acl "trusted" { localhost;
192.168.1.0/24;
};
This acl defines an access control list with label trusted. ACL labels are used to simplify administration: you only need to update your ACLs in one place, after that each reference to a label will automatically point to the updated data.
A nameserver supports queries by resolvers and zone transfers by other name servers.
normal queries Normal queries occur when a resolver needs data only on a very limited subset of the data. For example it wants to know which IP address associates with a hostname. The allow-query statement controls from which hosts these queries are accepted.
zone transfers The internet name space is build on the idea of a hierarchy of domains. To find the IP address of a host, you need its fully qualified domain name. That name consists of a series of subdomain names separated by dots, for example:
www.example.com. The hostname is in the first part, i.e. “www”. It is part of the “example” domain, which in turn is part of the “com” domain. Data for each domain is served by nameservers, data that relates to one domain is called ’a zone’. Nameservers will sent out all data for a zone to allow slave (backup) servers to get the information from a master of the same zone. It is important to restrict these “zone transfers” to just the servers that need that data - no more.
Zone transfers are controlled by the allow-transfer statement. This statement may also be specified in the zone statement, thereby overriding the global options allow-transfer statement. Traditionally, zone transfers can be initiated by anybody.
The allow-query statements can be used inside a zone statement or inside an options statement as well. It can contain either an acl label (like trusted), none, or one or more IP addresses or IP ranges. Use labels whenever you can: keeping track of permissions is far more easy that way and makes you less vulnerable to accidental oversights that may create security holes.
7.3.4.2.1 Limiting zone transfers
Both dig and host can initiate a zone transfer. By default, both master and slave servers are allowed to send all zone information.
An example using the dig command:
$ dig axfr @ns12.zoneedit.com zonetransfer.me
; <<> DiG 9.8.3-P1 <<>> axfr @ns12.zoneedit.com zonetransfer.me
; (1 server found)
zonetransfer.me. 301 IN TXT "Remember to call or email Pippa on +44 123 4567890 \ or [email protected] when making DNS changes"
zonetransfer.me. 301 IN TXT "google-site-verification= ←-tyP28J7JAUHA9fw2sHXMgcCC0I6XBmmoVi04VlMewxA"
testing.zonetransfer.me. 301 IN CNAME www.zonetransfer.me.
info.zonetransfer.me. 7200 IN TXT "ZoneTransfer.me service provided by Robin \
Wood - [email protected]. See www.digininja.org/projects/zonetransferme.php for more ←-information."
asfdbbox.zonetransfer.me. 7200 IN A 127.0.0.1
canberra_office.zonetransfer.me. 7200 IN A 202.14.81.230
asfdbvolume.zonetransfer.me. 7800 IN AFSDB 1 asfdbbox.zonetransfer.me.
email.zonetransfer.me. 2222 IN NAPTR 1 1 "" "E2U+email" "" email.zoneedit.com. ←-zonetransfer.me.
dzc.zonetransfer.me. 7200 IN TXT "AbCdEfG"
dr.zonetransfer.me. 300 IN LOC 53 20 56.558 N 1 38 33.526 W 0.00m 1m 10000m 10m rp.zonetransfer.me. 321 IN RP robin.zonetransfer.me.zonetransfer.me. robinwood.
←-zonetransfer.me.
sip.zonetransfer.me. 3333 IN NAPTR 2 3 "au" "E2U+sip" "!^.*$!sip:customer- ←[email protected]!".
_sip._tcp.zonetransfer.me. 14000 IN SRV 0 0 5060 www.zonetransfer.me.
dc_office.zonetransfer.me. 7200 IN A 143.228.181.132
;; XFR size: 37 records (messages 37, bytes 2673)
The previous example shows the complete information about zonetransfer.me. The command host -l does the same but formats its output differently:
Only validated slave name servers should be allowed to issue a zone transfer request. This can be done by making adjustments to the configuration files (named.conf) of both the master and all slaves for a particular zone, see the next example:
On master name servers On the master name server you should use the allow-transfer statement to limit zone transfers to a list of known slave servers.
acl "my_slave_servers" {
224.123.240.3; // cat.example.org };
// ...
zone "example.org" IN { type master;
// ....
allow-transfer { my_slave_servers;
};
};
Now only the slaves (only the host cat in the example) can request a zone transfer from this master name server.
On slave name servers On a slave name server you should never allow any zone transfers. This can be achieved by setting the allow-transferclause to ’none’:
zone "example.org" IN { type slave;
// ....
allow-transfer { none;
};
};
Note
IMPORTANT: Don’t forget to protect the reverse zone as well!
7.3.4.2.2 Limiting queries
Though strictly spoken any client should be allowed to query a nameserver, in practice you may want to limit queries to a range of hosts, for example the hosts in your own networks. This can be done as follows:
acl "myhosts" { 224.123.240.0/24;
};
// ...
zone "example.org" IN { // ...
allow-queries { myhosts;
};
};
This limits queries to hosts with an IP address that starts with 224.123.240.