Changes in version 5.8:
- 186/8 and 187/8 allocated to LACNIC (SEP 2007).
Removed from the bogon filter.
Changes in version 5.7:
- 94/8 and 95/8 allocated to RIPE (JUL 2007). Removed
from the bogon filter.
Changes in version 5.6:
- 46/8 re-listed as IANA Reserved (APR 2007). Added to
the bogon filter. 7/8 removed from bogon filters due to dispute in
allocation status.
Changes in version 5.5:
- 92/8 and 93/8 allocated to RIPE (MAR 2007). Removed
from the bogon filter.
Changes in version 5.4:
- 116/8, 117/8, 118/8, 119/8 and 120/8 allocated to
APNIC (JAN 2007). Removed from the bogon filter.
Changes in version 5.3:
- 96/8, 97/8, 98/8 and 99/8 allocated to ARIN (OCT
2006). Removed from the bogon filter.
Changes in version 5.2:
- 7/8, 78/8 and 79/8 allocated to RIPE (AUG 2006).
Removed from the bogon filter.
Changes in version 5.1:
- 121/8, 122/8 and 123/8 allocated to APNIC (JAN 2006).
Removed from the bogon filter.
Changes in version 5.0:
- 89/8, 90/8 and 91/8 allocated to RIPE (JUN 2005).
Removed from the bogon filter.
Changes in version 4.9:
- 74/8, 75/8 and 76/8 allocated to ARIN (JUN 2005).
Removed from the bogon filter. - 189/8 and 190/8 allocated to LACNIC (JUN 2005).
Removed from the bogon filter.
Changes in version 4.8:
- 41/8 allocated to AfriNIC (APR 2005). Removed from the
bogon filter.
Changes in version 4.7:
- 73/8 allocated to ARIN (MAR 2005). Removed from the
bogon filter.
Changes in version 4.6:
- 124/8, 125/8 and 126/8 allocated to APNIC (JAN 2005).
Removed from the bogon filter.
Changes in version 4.5:
- 71/8 and 72/8 allocated to ARIN (AUG 2004). Removed
from the bogon filter.
Changes in version 4.4:
- 58/8 and 59/8 allocated to the APNIC (APR 2004).
Removed from the bogon filter.
Changes in version 4.3:
- 85/8, 86/8, 87/8, and 88/8 allocated to the RIPE NCC
(APR 2004). Removed from the bogon filter.
Changes in version 4.2:
- Removed 70/8 (allocated to ARIN JAN 2004) from the
bogon filters.
Changes in version 4.1:
- Removed 83/8 and 84/8 (allocated to RIPE NCC NOV 2003)
from the bogon filters.
Changes in version 4.0:
- APNIC returned the 223/8 allocation to IANA and
received the 60/8 allocation in its place on 07 April 2003.
Changes in version 3.9:
- Added the following netblocks to the bogon filters,
designated as RESERVED by IANA on 04 April 2003:
· · 173/8 Apr 03 IANA - Reserved · 174/8 Apr 03 IANA - Reserved · 175/8 Apr 03 IANA - Reserved · 176/8 Apr 03 IANA - Reserved · 177/8 Apr 03 IANA - Reserved· 178/8 Apr 03 IANA - Reserved· 179/8 Apr 03 IANA - Reserved· 180/8 Apr 03 IANA - Reserved· 181/8 Apr 03 IANA - Reserved· 182/8 Apr 03 IANA - Reserved· 183/8 Apr 03 IANA - Reserved· 184/8 Apr 03 IANA - Reserved· 185/8 Apr 03 IANA - Reserved· 186/8 Apr 03 IANA - Reserved· 187/8 Apr 03 IANA - Reserved· 189/8 Apr 03 IANA - Reserved· 190/8 Apr 03 IANA - ReservedChanges in version 3.8:
- Removed 201/8 (allocated to LACNIC APR 2003) from the
bogon filters.
Changes in version 3.7a:
- Updated link to Linux chroot BIND HOWTO.
Changes in version 3.7:
- Removed 222/8 and 223/8 (allocated to APNIC FEB 2003)
from the bogon filters.
Changes in version 3.6:
- Removed a dead link to the Nominum BIND FAQ.
- Added a link to the comp.protocols.tcp-ip.domains FAQ.
Changes in version 3.5:
- Removed 82/8 from the bogon filtering. This netblock
was allocated to RIPE (NOV 2002).
Changes in version 3.4:
- Removed 69/8 from the bogon filtering. This netblock
was allocated to ARIN (AUG 2002).
Changes in version 3.0:
- Updated the bogon filtering.
- Migrated to views for security.
- Ported entire template to BIND version 9.X.
- Tested the template with BIND 9.1.3.
- Added additional reference links, including a Linux
chroot jail. - Added additional security features.
Changes in version 3.1:
- Further filtered access to the 127.in-addr.arpa zone.
- Added a link to the Men & Mice article on DNS
spoofing. - Corrected a mistaken description of the authors.bind
TXT records. - Clarified a point regarding the use of quotes in ACL
names in BIND 8 and BIND 9. - Thanks, Cricket! :)
Changes in version 3.2:
- Removed 220/8 from the bogons/blackhole list. Thanks,
Trey! :)
Changes in version 3.3:
- Removed 221/8 from the bogons/blackhole list.
Introduction
The ubiquitous BIND (Berkeley Internet Name Domain) server
is distributed with most UNIX variants and provides name services to countless
networks. However, the BIND server is not without certain vulnerabilities, and
is often a choice target for Internet vandals. These vandals utilize BIND
vulnerabilities to gain root access to the host or to turn the host into a
launching platform for DDOS attacks. An improper or insufficiently robust BIND
configuration can also "leak" information about the hosts and addressing within
the intranet. Miscreants can also take advantage of an insecure BIND
configuration and poison the cache, thus permitting host impersonation and
redirecting legitimate traffic to black holes or malicious hosts. This article
presents a template for deploying a secure BIND configuration, thus mitigating
some of the risk of running the BIND server.
If you are not familiar with BIND configuration, I highly recommend that you
pick up a copy of DNS and BIND, by Albitz and Liu, published by O'Reilly
and Associates.
There are numerous RFCs and FAQs associated with DNS. I value the following
most of all:
RFC2870 Root Name Server Operational Requirements (aka BCP40)
comp.protocols.tcp-ip.domains FAQ
Ask Mr. DNS
BIND Mailing List Archives
Building and Running BIND 9 by Steve Friedl
Obtaining assistance with the BIND is easily done, as there
is a large community of clueful folks both developing and using the BIND. You
may wish to subscribe to the BIND9 mailing list.
There are several documents detailing the risks of improperly configured BIND
servers, or risks in the older versions of BIND. Please take a look at the
following:
CERT Advisory CA-2001-02 Multiple Vulnerabilities in BIND
Men & Mice overview of DNS spoofing
SANS DNS Overview with a discussion of DNS Spoofing
As a prerequisite, the host on which the BIND is run should be secured with
the latest patches and armoring techniques. The IP stack should also be tuned to
provide robust performance and resistance to DoS attacks. Please review my
IP Stack Tuning Guide for suggestions along these lines.
If you are looking for the previous version of the Secure BIND Template that
includes the split-brain DNS method and support for BIND 8, please read the
Secure BIND Template Version 2.2 . Versions of the BIND template prior
to 3.0 are no longer under active development, though I will continue to answer
questions on version 2.2.
While I list the bogon ranges in this template on /8 boundaries, you may
prefer a greater level of aggregation. For this please see my
Bogon List.
It is not enough to secure the name server itself or the BIND software
configuration. The border must also be resistant to attacks, and can be used to
defend the name servers. Please take a look at the
Secure IOS Template as well as the
Secure BGP Template for ideas on border defense using Cisco routers.
Please feel free to share any suggestions or bug reports with me. This
template would not be half as useful without the suggestions and insights of
those who have read it. Feedback is always welcome! Send all feedback to
robt@cymru.com.
Credits
My thanks to several folks who offered suggestions, input,
and took the time to review this document. Special thanks go out to Roy
Arends, who contributed copious amounts of time, numerous reviews, lots of
great ideas, and several valuable lessons. :)
- Roy Arends
- Onno Ebbinge
- Shawn Hernan
- Mike Hoskins
- LaMont Jones
- Chris Lindsey
- Cricket Liu
- Peter Peters
- Rafi Sadowsky
- Trey Valenta
- Wietse Venema
- The
FIRST community
Tools
There exist myriad tools for debugging BIND configuration
errors. Aside from the log files, I recommend that you include the following
tools in your DNS toolbox. Keep in mind that the miscreants often use these
tools when scanning a network, so it is a good idea to test your network
security before someone with evil intent scans your network.
- dnswalk
- dig
- host
Secure the BIND Configuration
The following configuration presumes that the host network
is connected to the Internet. It is assumed that the reader has a working
knowledge of the BIND version 9, as this article will not detail the creation of
zone files or general DNS configuration and maintenance. Instead, this article
supplements and protects an existing BIND configuration. This is a "split
brain" DNS model using the views feature of BIND 9.
For our purposes, we will assume that our external (visible to the Internet)
network is 8.8.8.0/24. Our internal network is 7.7.7.0/24. In your network,
this may be a netblock from the RFC1918 address space. Our name server has the
IP address 8.8.8.1.
Technicality: Our bogon ACL would block all queries from hosts in the
7.7.7.0/24 netblock. This is an example only, after all, so please do not use
7.7.7.0/24 as your internal netblock, and do not remove 7.7.7.0/24 from the
bogon ACL list. See
RFC1918 for the details regarding the three netblocks (10/8, 172.16/12,
and 192.168/16) designated for internal only use.
Ensure that you have the latest version of the BIND. You can obtain the
latest version by visiting the Internet Software Consortium BIND site at
http://www.isc.org/products/BIND/ The compilation and installation of
the BIND is well detailed at this site. This template has been most recently
tested with BIND version 9.1.3.
BIND 9.1.3 contains two interesting records in the CHAOS class - version.bind
and authors.bind, both type TXT. The version.bind TXT record will return the
version of BIND running on the server. The authors.bind TXT records (by
default, there are multiple TXT records for authors.bind) will return a list of
the authors of the BIND 9.X. While the version.bind TXT record may assist
admins, it runs counter to the philosophy of "keep the miscreants guessing."
Some of the scanning tools used by the miscreants query for the BIND version.
For this reason, it is recommended that you hide these records from external
hosts. This is done through a view, and it will be demonstrated in the template
below.
You may wish to ensure that your BGP configuration does not dampen the
netblocks that contain the DNS root servers. Please consult my
Secure BGP Template for further details on this topic.
The chroot Jail
It is best to run BIND in a chroot'd jail. This will
prevent a miscreant from using named to access or manipulate other files on the
host system, as well as preventing an overflow in BIND from granting a shell to
the miscreant. Presently, this document contains links to a chroot jail for
Solaris, FreeBSD, and Linux. Other will be added as time and testing allow.
After building the chroot environment, create a small passwd file in the
jail. The passwd file should contain only a root account and the BIND user.
Call the user under which BIND will run named. Assign a UID
greater than 100 to the named user, and remember to sync up the passwd file with
the shadow file (pwconv in Solaris). Do not create a password for
this accounts. Instead, lock it with entries in the shadow file such as this
one:
root:*LK*:6445::::::
named:*LK*:11136::::::
I recommend using a shell that will allow no access, such as my own denial
shell,
nocando. The nocando denial shell, which includes detailed logging, can
be found in the
Tools section of my web site. The home directory for this account will
be the directory we create below.
Next, create a directory structure to contain our configuration files. For
example, use /jail/bind/var/named. In this directory, create a
subdirectory named master for our master zones and slave for our
slave zones, if such zones exist. Change the ownership of these subdirectories
to the proper named UID, e.g.:
chown -R
named:named /jail/bind/var/named
Configure the zone files normally, and place them in the proper
subdirectories. Don't forget the hint file (often named db.cache), the
loopback zone, and a named.conf file. Details regarding the creation of
the hint and zone files can be found in the following:
- "Configuring BIND 8", by Don Kuenz, "Inside
Solaris" Magazine. - DNS and BIND, by Albitz and Liu,
published by O'Reilly and Associates.
We will now configure the named configuration files, with views for internal
and external clients.
named.conf
The ordering of our views is very important. The named
daemon accepts the first match. Because our external view permits all clients,
our internal clients also match this view. For this reason we place our internal
view first (permitting only our approved internal hosts) and our external view
second (permitting all comers).
//
@(#)named.conf 02 OCT 2001 Rob Thomas robt@cymru.com
// Set up
our ACLs
// In BIND
8, ACL names with quotes were treated as different from
// the same
name without quotes. In BIND 9, both are treated as
// the
same.
acl "xfer"
{
none;
// Allow no transfers. If we have other
// name servers, place them here.
};
acl
"trusted" {
// Place our internal and DMZ subnets in
here so that
// intranet and DMZ clients may send DNS
queries. This
// also prevents outside hosts from using
our name server
// as a resolver for other domains.
8.8.8.0/24;
localhost;
};
acl
"bogon" {
// Filter out the bogon networks.
These are networks
// listed by IANA as test, RFC1918,
Multicast, experi-
// mental, etc. If you see DNS queries
or updates with
// a source address within these
networks, this is likely
// of malicious origin. CAUTION: If you
are using RFC1918
// netblocks on your network, remove
those netblocks from
// this list of blackhole ACLs!
0.0.0.0/8;
1.0.0.0/8;
2.0.0.0/8;
5.0.0.0/8;
10.0.0.0/8;
23.0.0.0/8;
27.0.0.0/8;
31.0.0.0/8;
36.0.0.0/8;
37.0.0.0/8;
39.0.0.0/8;
42.0.0.0/8;
46.0.0.0/8;
49.0.0.0/8;
50.0.0.0/8;
100.0.0.0/8;
101.0.0.0/8;
102.0.0.0/8;
103.0.0.0/8;
104.0.0.0/8;
105.0.0.0/8;
106.0.0.0/8;
107.0.0.0/8;
108.0.0.0/8;
109.0.0.0/8;
110.0.0.0/8;
111.0.0.0/8;
112.0.0.0/8;
113.0.0.0/8;
114.0.0.0/8;
115.0.0.0/8;
169.254.0.0/16;
172.16.0.0/12;
173.0.0.0/8;
174.0.0.0/8;
175.0.0.0/8;
176.0.0.0/8;
177.0.0.0/8;
178.0.0.0/8;
179.0.0.0/8;
180.0.0.0/8;
181.0.0.0/8;
182.0.0.0/8;
183.0.0.0/8;
184.0.0.0/8;
185.0.0.0/8;
192.0.2.0/24;
192.168.0.0/16;
197.0.0.0/8;
198.18.0.0/15;
223.0.0.0/8;
224.0.0.0/3;
};
logging {
channel default_syslog {
// Send most of the
named messages to syslog.
syslog local2;
severity debug;
};
channel audit_log {
// Send the security
related messages to a separate file.
file "/var/named/bind/named.log";
severity debug;
print-time yes;
};
category default { default_syslog; };
category general { default_syslog; };
category security { audit_log;
default_syslog; };
category config { default_syslog; };
category resolver { audit_log; };
category xfer-in { audit_log; };
category xfer-out { audit_log; };
category notify { audit_log; };
category client { audit_log; };
category network { audit_log; };
category update { audit_log; };
category queries { audit_log; };
category lame-servers { audit_log; };
};
// Set
options for security
options {
directory "/var/named";
pid-file "/var/named/named.pid";
statistics-file
"/var/named/named.stats";
memstatistics-file
"/var/named/named.memstats";
dump-file "/var/adm/named.dump";
zone-statistics yes;
//
Prevent DoS attacks by generating bogus zone transfer
// requests. This will result in
slower updates to the
// slave servers (e.g. they will await
the poll interval
// before checking for updates).
notify no;
// Generate more efficient zone transfers.
This will place
// multiple DNS records in a DNS
message, instead of one per
// DNS message.
transfer-format many-answers;
//
Set the maximum zone transfer time to something more
// reasonable. In this case, we state
that any zone transfer
// that takes longer than 60 minutes is
unlikely to ever
// complete. WARNING: If you have
very large zone files,
// adjust this to fit your
requirements.
max-transfer-time-in 60;
//
We have no dynamic interfaces, so BIND shouldn't need to
// poll for interface state {UPDOWN}.
interface-interval 0;
allow-transfer {
// Zone tranfers limited to members
of the
// "xfer" ACL.
xfer;
};
allow-query {
// Accept queries from our
"trusted" ACL. We will
// allow anyone to query our master
zones below.
// This prevents us from becoming a
free DNS server
// to the masses.
trusted;
};
allow-query-cache {
// Accept queries of our cache from
our "trusted" ACL.
trusted;
};
blackhole {
// Deny anything from the bogon
networks as
// detailed in the "bogon" ACL.
bogon;
};
};
view "internal-in" in {
// Our internal (trusted) view. We
permit the internal networks
// to freely access this view. We
perform recursion for our
// internal hosts, and retrieve data
from the cache for them.
match-clients { trusted; };
recursion yes;
additional-from-auth yes;
additional-from-cache yes;
zone "." in {
// Link in the root server hint file.
type hint;
file "db.cache";
};
zone "0.0.127.in-addr.arpa" in {
// Allow queries for the 127/8 network,
but not zone transfers.
// Every name server, both slave and
master, will be a master
// for this zone.
type master;
file "master/db.127.0.0";
allow-query {
any;
};
allow-transfer {
none;
};
};
zone "internal.ournetwork.com" in {
// Our internal A RR zone. There may be
several of these.
type master;
file "master/db.internal";
};
zone "7.7.7.in-addr.arpa" in {
// Our internal PTR RR zone. Again,
there may be several of these.
type master;
file "master/db.7.7.7";
};
};
//
Create a view for external DNS clients.
view "external-in" in {
// Our external (untrusted) view. We
permit any client to access
// portions of this view. We do not
perform recursion or cache
// access for hosts using this view.
match-clients { any; };
recursion no;
additional-from-auth no;
additional-from-cache no;
// Link in
our zones
zone "." in {
type hint;
file "db.cache";
};
zone "ournetwork.net" in {
type master;
file "master/db.ournetwork";
allow-query {
any;
};
};
zone "8.8.8.in-addr.arpa" in {
type master;
file "master/db.8.8.8";
allow-query {
any;
};
};
};
//
Create a view for all clients perusing the CHAOS class.
// We allow internal hosts to query our
version number.
// This is a good idea from a support point
of view.
view
"external-chaos" chaos {
match-clients { any; };
recursion no;
zone "." {
type hint;
file "/dev/null";
};
zone "bind" {
type master;
file "master/db.bind";
allow-query {
trusted;
};
allow-transfer {
none;
};
};
};
The db.bind zone file
The db.bind zone file is used to track
miscreants who attempt to query the CHAOS TXT records version.bind and
authors.bind. You can also use this zone file to change the strings returned by
such queries. Using the "version" directive in the options stanza will block
the version.bind query, but it will not log such attempts.
;
@(#)db.bind v1.2 25 JAN 2001 Rob Thomas robt@cymru.com
;
$TTL 1D
$ORIGIN bind.
@ 1D CHAOS SOA localhost.
root.localhost. (
2001013101 ; serial
3H ; refresh
1H ; retry
1W ; expiry
1D ) ; minimum
CHAOS NS localhost.
version.bind. CHAOS TXT "BIND 9.1.3+robhacks"
authors.bind. CHAOS TXT "are better
coders than I. :)"
Once the creation
of the named.conf and zone file is completed, it is wise to verify the syntax of
these files. This can be accomplished with two tools:
named-checkconf -
integrity check the conf file.
named-checkzone -
integrity check the zone files.
Starting the chroot named daemon
Once the configuration is complete, it is time
to start the chroot named daemon. Without changing /etc/init.d/inetsvc
on Solaris, it is wise to test the configurations first. Remember that we are
running our named daemon in a chroot jail. To start the DNS service, type:
cd /jail/bind
/usr/sbin/chroot /jail/bind
usr/local/sbin/named -u named
By typing ps -fu
named, you can verify that the chroot named daemon is running.
Once you have
/etc/resolv.conf properly configured, you should be able to launch queries.
Test a few basic queries for both internal and external names and addresses.
Then test an intranet client to ensure that the ACLs are functioning properly.
If you have secondary name servers, ensure that zone transfers are functional
and complete. If possible, test the name server from an external host to ensure
that the ACLs are functional and that logging is working.
Once all testing is
successfully completed, modify /etc/init.d/inetsvc to start the chroot
named daemon at boot. Comment out the current named lines and insert the
following:
# Start
chroot DNS
if [ -f /jail/bind/usr/local/sbin/named -a
-f /jail/bind/usr/local/etc/named.conf ];
then
echo "Starting chroot BIND server."
(cd /jail/bind; /usr/sbin/chroot
/jail/bind usr/local/sbin/named -u named)
fi
Conclusion
The BIND is a popular application used by many
to provide name services. However, it is not without certain risks. By
implementing a secure configuration, with a separation of internal and external
name services, we can increase the security and reliability of our name services
and protected networks.
Rob Thomas
http://www.cymru.com
0 comments:
Post a Comment