BIND Dns

BIND 9 is an implementation of the Domain Name System (DNS) protocols. named daemon is an Internet Domain Name Server for UNIX like operating systems. Dynamic update messages may be used to update records in a master zone on a nameserver. When named receives a specially crafted dynamic update message an internal assertion check is triggered which causes named to exit. An attacker which can send DNS requests to a nameserver can cause it to exit, thus creating a Denial of Service situation. configuring named to ignore dynamic updates is NOT sufficient to protect it from this vulnerability. This exploit is public. Please upgrade immediately.
[continue reading…]

I’ve three nameserver load-balanced (LB) in three geo locations. Each LB has a front end public IP address and two backend IP address (one for BIND and another for zone transfer) are assigned to actual bind 9 server running Red Hat Enterprise Linux 5.2 as follows:

LB1 - 202.54.1.2 -> Master BIND 9.x
LB2 - 75.54.1.2  -> Slave BIND 9.x
LB3 - 41.54.1.2 -> Slave BIND 9.x

So when a zone transfer initiates from slave server, all I get following errors in master BIND 9 server (LB1):

Jan  1 14:11:20 ns1 named[5323]: client 75.54.xx.xx#50968: zone transfer 'example.com/AXFR/IN' denied
Jan  1 14:11:20 ns1 named[5323]: client 75.54.xx.xx#54359: zone transfer 'example.org/AXFR/IN' denied

[continue reading…]

Red Hat has shipped a new version of its dnsmasq caching software to plug source UDP port bug. This could have made DNS spoofing attacks (CVE-2008-1447) easier. Dnsmasq is lightweight ultra fast dns cache server forwarder and DHCP server. It is designed to provide DNS and, optionally, DHCP, to a small network.

This update has been rated as having moderate security impact, to upgrade your software, type the following command:
# yum update

This software only available under RHEL 5 / CentOS Linux 5.x. If you are using Debian / Ubuntu Linux, enter:
# apt-get update
# apt-get upgrade

I already wrote about verifying your own or ISP recursive resolvers using dig command under Linux and UNIX. However, most windows users don’t have dig command installed. You can use nslookup command as follows (open dos prompt by visiting Start > Run > type “cmd” > Enter:
nslookup -type=txt -timeout=30 porttest.dns-oarc.net
nslookup -type=txt -timeout=30 porttest.dns-oarc.net ns1.your-isp.com
nslookup -type=txt -timeout=30 porttest.dns-oarc.net NS-SERVER-IP

You must see the word GOOD otherwise your dns is open to attack.

Check DNS Cache Poisoning Under Windows Xp / Vista / Server Edition using nslookup command

An unpatched security hole in BIND 9 package could be used by attackers to poison your DNS cache. Attacker to take control of all hosted domains and can can lead to misdirected web traffic and email rerouting.

This update changes Debian’s BIND 9 packages to implement the recommended countermeasure: UDP query source port randomization. This change increases the size of the space from which an attacker has to guess values in a backwards-compatible fashion and makes successful attacks significantly more difficult.

Details

  • Package : bind9
  • Vulnerability : DNS cache poisoning
  • Problem type : remote
  • Debian-specific: no
  • CVE Id(s) : CVE-2008-1447
  • CERT advisory : VU#800113

How do I fix BIND9 bug under Debian Linux?

Install the BIND 9 upgrade, using following commands, enter:
# apt-get update
# apt-get install bind9

Sample output:

Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
  libdns22 libisc11 libisccc0 libisccfg1
Suggested packages:
  bind9-doc
The following packages will be upgraded:
  bind9 libdns22 libisc11 libisccc0 libisccfg1
5 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
Need to get 1267kB of archives.
After unpacking 4096B disk space will be freed.
Do you want to continue [Y/n]? y
Get:1 http://security.debian.org stable/updates/main bind9 1:9.3.4-2etch3 [319kB]
Get:2 http://security.debian.org stable/updates/main libisc11 1:9.3.4-2etch3 [188kB]
Get:3 http://security.debian.org stable/updates/main libisccc0 1:9.3.4-2etch3 [96.7kB]
Get:4 http://security.debian.org stable/updates/main libisccfg1 1:9.3.4-2etch3 [111kB]
Get:5 http://security.debian.org stable/updates/main libdns22 1:9.3.4-2etch3 [552kB]
Fetched 1267kB in 1s (724kB/s)
Reading changelogs... Done
(Reading database ... 27244 files and directories currently installed.)
Preparing to replace bind9 1:9.3.4-2etch1 (using .../bind9_1%3a9.3.4-2etch3_amd64.deb) ...
Stopping domain name service...: bind.
Unpacking replacement bind9 ...
Preparing to replace libisc11 1:9.3.4-2etch1 (using .../libisc11_1%3a9.3.4-2etch3_amd64.deb) ...
Unpacking replacement libisc11 ...
Preparing to replace libisccc0 1:9.3.4-2etch1 (using .../libisccc0_1%3a9.3.4-2etch3_amd64.deb) ...
Unpacking replacement libisccc0 ...
Preparing to replace libisccfg1 1:9.3.4-2etch1 (using .../libisccfg1_1%3a9.3.4-2etch3_amd64.deb) ...
Unpacking replacement libisccfg1 ...
Preparing to replace libdns22 1:9.3.4-2etch1 (using .../libdns22_1%3a9.3.4-2etch3_amd64.deb) ...
Unpacking replacement libdns22 ...
Setting up libisc11 (9.3.4-2etch3) ...

Setting up libdns22 (9.3.4-2etch3) ...

Setting up libisccc0 (9.3.4-2etch3) ...

Setting up libisccfg1 (9.3.4-2etch3) ...

Setting up bind9 (9.3.4-2etch3) ...

Configuration file `/etc/bind/db.root'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : background this process to examine the situation
 The default action is to keep your current version.
*** db.root (Y/I/N/O/D/Z) [default=N] ? y
Installing new version of config file /etc/bind/db.root ...
Starting domain name service...: bind.

Also, verify that source port randomization is active. Check that the /var/log/daemon.log file does not contain messages of the following form:

 named[6106]: /etc/bind/named.conf.options:28: using specific
    query-source port suppresses port randomization and can be insecure.

If you see message replace replace the port numbers contained within them with “*” sign (e.g.,
replace “port 53” with “port *”) in /etc/bind/named.conf.option file.

How do I fix this issue under Red Hat Linux / RHEL ?

Simply type the command, enter:
# yum update

RIP: BIND 8 under Debian 4.x

Debian team also posted BIND 8 deprecation notice. From the announcement:

The BIND 8 legacy code base could not be updated to include the recommended countermeasure (source port randomization, see DSA-1603-1 for details). There are two ways to deal with this situation:

1. Upgrade to BIND 9 (or another implementation with source port randomization). The documentation included with BIND 9 contains a migration guide.

2. Configure the BIND 8 resolver to forward queries to a BIND 9 resolver. Provided that the network between both resolvers is trusted, this protects the BIND 8 resolver from cache poisoning attacks (to the same degree that the BIND 9 resolver is protected).

This problem does not apply to BIND 8 when used exclusively as an authoritative DNS server. It is theoretically possible to safely use BIND 8 in this way, but updating to BIND 9 is strongly recommended.
BIND 8 (that is, the bind package) will be removed from the etch distribution in a future point release.

I. Background
BIND 9 is an implementation of the Domain Name System (DNS) protocols.
The named(8) daemon is an Internet Domain Name Server. DNS requests
contain a query id which is used to match a DNS request with the response
and to make it harder for anybody but the DNS server which received the
request to send a valid response.

II. Problem Description

The BIND DNS implementation does not randomize the UDP source port when
doing remote queries, and the query id alone does not provide adequate
randomization.

III. Impact

The lack of source port randomization reduces the amount of data the
attacker needs to guess in order to successfully execute a DNS cache
poisoning attack. This allows the attacker to influence or control
the results of DNS queries being returned to users from target systems.

IV. Workaround

Limiting the group of machines that can do recursive queries on the DNS
server will make it more difficult, but not impossible, for this
vulnerability to be exploited.

To limit the machines able to perform recursive queries, add an ACL in
named.conf and limit recursion like the following:

acl example-acl {
192.0.2.0/24;
};

options {
recursion yes;
allow-recursion { example-acl; };
};

V. Solution

Perform one of the following:

1) Upgrade your vulnerable system to 6-STABLE or 7-STABLE, or to the
RELENG_7_0 or RELENG_6_3 security branch dated after the correction
date.

2) To patch your present system:

The following patches have been verified to apply to FreeBSD 6.3 and
7.0 systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

[FreeBSD 6.3] # fetch http://security.FreeBSD.org/patches/SA-08:06/bind63.patch
# fetch http://security.FreeBSD.org/patches/SA-08:06/bind63.patch.asc
[FreeBSD 7.0] # fetch http://security.FreeBSD.org/patches/SA-08:06/bind7.patch
# fetch http://security.FreeBSD.org/patches/SA-08:06/bind7.patch.asc

b) Execute the following commands as root:

# cd /usr/src
# patch

NOTE WELL: This update causes BIND to choose a new, random UDP port for
each new query; this may cause problems for some network configurations,
particularly if firewall(s) block incoming UDP packets on particular
ports. The avoid-v4-udp-ports and avoid-v6-udp-ports options should be
used to avoid selecting random port numbers within a blocked range.

NOTE WELL: If a port number is specified via the query-source or
query-source-v6 options to BIND, randomized port selection will not be
used. Consequently it is strongly recommended that these options not
be used to specify fixed port numbers.

The latest revision of this advisory is available at FreeBSD

An updated caching-nameserver package that fixes a bug is now available under Red Hat Enterprise Linux.

The caching-nameserver package includes the configuration files that will make BIND, the DNS name server, act as a simple caching nameserver. Many users on dial-up connections use this package along
with BIND for this purpose. The address of L root server have been updated. All users of caching-nameserver should upgrade to this updated package, which resolves this issue.

To update just enter the following command as root user:
# up2date -u

DNS server can be attacked using various techniques such as

[a] DNS spoofing [b] Cache poisoning [c] Registration hijacking

One of the simplest ways to defend is limit zone transfers between nameservers by defining ACL. I see many admin allows BIND to transfer zones in bulk outside their network or organization. There is no need to do this. Remember you don’t have to make an attacker’s life easier.

How to restrict zone trasfer with IP address?

You need to define ACL in /etc/named.conf file. Let us say IP 192.168.191.10 and 25.111.24.6 are allowed to transfer your zones.
# vi named.conf
Here is sample entery for domain nixcraft.com (ns1 configuration):

acl trusted-servers  {
        192.168.191.10;  //ns2
        25.111.24.6;   //ns3
};
zone nixcraft.com  {
        type master;
        file "zones/nixcraft.com";
        allow-transfer { trusted-servers; };
};

Next add zone nixcraft.com. Please note that you must use set of hosts later in each zone’s configuration block i.e. put line allow-transfer { trusted-servers; }; for each zone / domain name. Restart named:
# /etc/init.d/named restart

How do I test zone transfers restrictions are working or not?

Use any UNIX dns tool command such as nslookup, host or dig. For example, following example uses host command to request zone transfer:
$ host -T axfr nixcraft.com
Output:

;; Connection to 74.86.49.133#53(74.86.49.133) for axfr failed: connection refused.

Transaction signatures (TSIG)

Another recommend option is to use transaction signatures (TSIG) to authorize zone transfers. This makes more difficult to spoof IP addresses.

You can use a tool called named- checkconf to check BIND dns server (named daemon) configuration file syntax under Linux / UNIX. It checks the syntax, but not the semantics, of a named configuration file i.e. it can check for syntax errors or typographical errors but cannot check for wrong MX / A address assigned by you. Nevertheless, this is an excllent tool for troubleshooting DNS server related problems.

How do I check my bind configuration for errors?

Simply run command as follows:
# named-checkconf /etc/named.conf
You may want to chroot to directory so that include directives in the configuration file are processed as if run by a similarly chrooted named:
# named-checkconf -t /var/named/chroot /etc/named.conf
If there is no output, the configuration is considered correct and you can safely restart or reload bind configuration file. If there is an error it will be displayed on screen:
# named-checkconf /etc/named.conf
Output:

/etc/named.conf:58: open: /etc/named.root.hints: file not found

Related tool: BIND-DNS server zone file validity checking tool

The domain name service provided by BIND (named) software. It uses both UDP and TCP protocol and listen on port 53. DNS queries less than 512 bytes are transferred using UDP protocol and large queries are handled by TCP protocol such as zone transfer.

i) named/bind server – TCP/UDP port 53

ii)Client (browser, dig etc) – port > 1023

Allow outgoing DNS client request:

Following iptables rules can be added to your shell script.

SERVER_IP is your server ip address

DNS_SERVER stores the nameserver (DNS) IP address provided by ISP or your own name servers.

Following rules are useful when you run single web/smtp server or even DSL/LL/dialup Internet connections:

SERVER_IP="202.54.10.20"
DNS_SERVER="202.54.1.5 202.54.1.6"
for ip in $DNS_SERVER
do
iptables -A OUTPUT -p udp -s $SERVER_IP --sport 1024:65535 -d $ip --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp -s $ip --sport 53 -d $SERVER_IP --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT-p tcp -s $SERVER_IP --sport 1024:65535 -d $ip --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s $ip --sport 53 -d $SERVER_IP --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
done

(B) Allow incoming DNS request at port 53:

Use following rules only if you are protecting dedicated DNS server.

SERVER_IP is IP address where BIND(named) is listing on port 53 for incoming DNS queries.

Please note that here I’m not allowing TCP protocol as I don’t have secondary DNS server to do zone transfer.

SERVER_IP="202.54.10.20"
iptables -A INPUT -p udp -s 0/0 --sport 1024:65535 -d $SERVER_IP --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p udp -s $SERVER_IP --sport 53 -d 0/0 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp -s 0/0 --sport 53 -d $SERVER_IP --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p udp -s $SERVER_IP --sport 53 -d 0/0 --dport 53 -m state --state ESTABLISHED -j ACCEPT

Please note if you have secondary server, add following rules to above rules so that secondary server can do zone transfer from primary DNS server:

DNS2_IP="202.54.10.2"
iptables -A INPUT -p tcp -s $DNS2_IP --sport 1024:65535 -d $SERVER_IP --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -s $SERVER_IP --sport 53 -d $DNS2_IP --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT