please review Bv9ARM-book changes for integrating AusCERT AL-1999.004
Jeremy C. Reed
reed at reedmedia.net
Thu Apr 26 18:01:54 UTC 2007
Last year I worked at integrating AusCERT AL-1999.004 into
bind9/doc/arm/Bv9ARM-book.xml. Currently the book points to non-existent
URI. I had several emails with AUSCERT and the primary author, Glen
Turner, and I received permission to re-use their content in the
BSD-licensed Bv9ARM-book.xml document. (Thank you again!)
Please review the following and share your comments and suggestions. I
also have questions below also. Then when ready I will help convert to
DocBook so can be integrated into the XML document.
What is out-dated below? What shouldn't be included in the
Bv9ARM-book.xml? What needs to be rewritten or improved? Does the AusCERT
AL-1999.004 even matter in 2007?
In my work, this is between the "Access Control Lists" and chroot
sections:
-=-=-=-=-=-=
9.2 Preventing Denial of Service (DoS) attacks
FOOTNOTE: This section is derived from AUSCERT ALERT AL-1999.004.
Reused by permission of AUSCERT and Glen Turner.
In 1999, a vulnerability and exploit tool were
published regarding a denial of service attack based on
exploiting the difference in size between a DNS query
and a DNS response and the willingness of DNS servers
to answer queries from any source. The vulnerability
may allow remote denial of service attacks against
target hosts whose IP addresses are spoofed in the DNS
query. There are three parties: the target, the traffic
multiplying DNS servers (amplifiers), and the attacker.
Any platform connected to the Internet may be the
target of the denial of service. Service is denied by
occupying all link bandwidth with responses to bogus
DNS queries and potential ICMP port unreachable
responses to these bogus responses. Any DNS server may
be used to multiply the denial of service attack.
Usually several DNS servers on networks with good
bandwidth to the target are required to effectively
attack the target, however the same effects can be
achieved by using a larger number of amplifiers with
smaller bandwidth capabilities. The attack is launched
from a remote location with moderate bandwidth to the amplifiers.
Small DNS queries are sent from the attacker to each of
the DNS servers. These queries contain the spoofed IP
address of the target. The DNS servers respond to the
small query with a large response. These responses are
routed to the target, causing link congestion and
possible denial of Internet connectivity.
If the number of DNS queries from the attacker is
large, then the traffic may congest the DNS server's
Internet link or degrade the DNS server's response
time. Although no different in principle from ICMP ECHO
("ping") flooding, DNS query traffic cannot be
traffic-shaped by network routers without greatly
inconveniencing legitimate users.
Since this attack relies upon spoofed source IP
addresses, source address checking by ISPs originating
traffic is the only means to entirely defeat this form
of denial of service attack.
??? TODO: is above still true? relevant?
Workaround
The tools and attacks are very straightforward and
administrators can prevent their DNS servers from being
used as amplifiers by configuring their servers to
answer queries from unexpected sources with a small
REFUSED response rather than a much larger name
resolution response.
??? TODO: is this in BIND now?
For the purposes of refusing queries from unexpected
sources, DNS queries directed to a particular name
server can be categorized into the following types. For
each type of query a typical access control
configuration is given. In addition, we suggest
** maybe instead of "we suggest" use "consider using" **
controls for zone transfers. While restricting access
to zone transfers is not directly related to the denial
of service attack described in this alert, it may
provide additional security for some sites.
9.2.1 (1) Queries for Any Name
Allow queries from "trusted" sources only. Trusted
sources are defined as hosts for which the DNS server
provides recursive DNS name resolution. These hosts
would usually lie within an ISP's or enterprise's
network. These hosts usually have the DNS server listed
in a configuration file such as /etc/resolv.conf or
supplied to it in a PPP, DHCP or BOOTP response. Allow
no zone transfers.
The default case is handled by setting the BIND options.
** or maybe instead of "default case use "common case" or "suggested
case". **
This is an extract from the file "/etc/named.conf" on
all of "example.com"'s BIND DNS servers.
// DNS clients at example.com
acl "trusted" {
localhost;
126.0.0.0/8; // Hosts at example.com
};
// Known fake source addresses shouldn't be replied to.
// For external queries, these should be blocked by
// example.com's border router.
acl "bogon" {
0.0.0.0/8; // Null address
1.0.0.0/8; // IANA reserved, popular fakes
2.0.0.0/8;
192.0.2.0/24; // Test address
224.0.0.0/3; // Multicast addresses
// Enterprise networks may or may not be
// bogus.
10.0.0.0/8;
172.16.0.0/12;
192.168.0.0/16;
};
options {
directory "/var/named";
allow-query {
trusted;
};
allow-transfer {
none;
};
blackhole {
bogon;
};
};
// Bootstrap the root.
// This is an example for overriding the defaults.
zone "." {
type hint;
file "named.ca";
};
// 127.0.0.0/24 The loopback network.
zone "0.0.127.in-addr.arpa" {
type master;
file "127.in-addr.arpa";
allow-query {
trusted;
};
// Every DNS server should be a
// master for 127.0.0.0/24.
allow-transfer {
none;
};
};
9.2.2 (2) Queries for Names in Primary Zones
A "primary zone" is a zone for which a server has the
DNS master file described in RFC1035 and the server is
one of the name servers that has been delegated the domain.
Allow queries from all sources. Allow zone transfers
from official and stealth secondaries.
"dns0.example.com" is the primary DNS server for the
zone "example.com".
This is an extract from the "/etc/named.conf" file on
"dns0.example.com". The extract defines the zone
"example.com" and lists the zone's secondary DNS servers.
// Official and stealth secondaries.
acl "example-xfer" {
126.0.2.2; // dns1.example.com (official)
126.0.1.1; // dns2.example.com (official)
126.0.3.4; // mailhub.example.com (stealth)
};
zone "example.com" {
type master; // official
file "primary/example.com";
allow-query {
any;
};
allow-transfer {
localhost;
example-xfer;
};
};
// 126.0.0.0/8
zone "0.126.in-addr.arpa" {
type master; // official
file "primary/0.126.in-addr.arpa";
allow-query {
any;
};
allow-transfer {
localhost;
example-xfer;
};
};
As noted above, any sub-domains of "example.com"
present on this DNS server must allow queries from any
source, as the parent domain on this server allows
queries from any source.
9.2.3 (3) Queries for Names in Official Secondary Zones
An "official secondary zone" is a zone for which the
server has a zone transfer of the DNS master file and
is one of the name servers that has been delegated the
domain. Official secondary zones exist to add
robustness to the Domain Name System.
Allow queries from all sources. Possibly allow zone
transfers from official and stealth secondaries.
"dns1.example.com" is an official secondary DNS server
for the zone "example.com".
This is an extract from the "/etc/named.conf" file on
"dns1.example.com". The extract defines the zone "example.com".
// Official and stealth secondaries.
acl "example-xfer" {
126.0.2.2; // dns1.example.com (official)
126.0.1.1; // dns2.example.com (official)
126.0.3.4; // mailhub.example.com (stealth)
};
zone "example.com" {
type slave; // official
file "secondary/example.com";
masters {
126.0.2.1; // dns0.example.com
};
allow-query {
any;
};
allow-transfer {
localhost;
example-xfer;
};
};
// 126.0.0.0/8
zone "0.126.in-addr.arpa" {
type slave; // official
file "secondary/0.126.in-addr.arpa";
masters {
126.0.2.1; // dns0.example.com
};
allow-query {
any;
};
allow-transfer {
localhost;
example-xfer;
};
};
As noted above, any sub-domains of "example.com"
present on this DNS server must allow queries from any
source, as the parent domain on this server allows
queries from any source.
9.2.4 (4) Queries for Names in Stealth Secondary Zones
A "stealth secondary zone" is a zone for which the
server has a zone transfer of the DNS master file but
is not one of the name servers that has been delegated
the domain. Stealth secondary zones are often used to
add performance to DNS resolution, especially at sites
reachable only across slow wide-area network links or
on machines containing DNS-intensive applications such
as e-mail.
Allow queries from "trusted" sources only. Allow no
zone transfers.
It may be administratively convenient to allow queries
from all sources, as this minimizes the risk of outages
if official secondary zones and stealth secondary zones
are confused or if all the users of the stealth
secondary zone are not known. If queries are limited to
"trusted" sources only, then a careful eye should be
kept on the DNS server log.
"mailhub.example.com" is a stealth secondary DNS server
for the zone "example.com".
This is an extract from the "/etc/named.conf" file on
"mailhub.example.com". The extract defines the zone
"example.com".
acl "trusted" {
localhost;
126.0.0.0/8; // Hosts at example.com
};
// Official and stealth secondaries.
acl "example-xfer" {
126.0.2.2; // dns1.example.com (official)
126.0.1.1; // dns2.example.com (official)
126.0.3.4; // mailhub.example.com (stealth)
};
zone "example.com" {
type slave; // stealth
file "secondary/example.com";
masters {
126.0.2.1; // dns0.example.com
};
allow-query {
trusted;
// or "any;" if you don't have good records
// of the expected users of the stealth
// secondary.
};
allow-transfer {
localhost;
example-xfer;
};
};
// 126.0.0.0/8
zone "0.126.in-addr.arpa" {
type slave; // stealth
file "secondary/0.126.in-addr.arpa";
masters {
126.0.2.1; // dns0.example.com
};
allow-query {
trusted;
// or "any;" if you don't have good records
// of the expected users of the stealth
// secondary.
};
allow-transfer {
localhost;
example-xfer;
};
};
As noted above, any sub-domains of "example.com"
present o this DNS server must allow queries from at
least the hosts in the "trusted" access control list,
as the parent domain on this server allows queries from
that list.
*** This paragraph above is getting redundant ***
An exception to the guidelines in (2) to (4) above is
that within the configuration of each DNS server, a
sub-domain cannot service a smaller range of query
sources than its parent domain. If a DNS server allows
queries from any source for the domain "example.com",
then it must also allow queries from any source for the
delegated sub-domain "instructive.example.com".
It is administratively useful to allow DNS zone
transfers between all primary and secondary DNS
servers. This eases the debugging of zone transfer faults.
Similarly, allowing DNS zone transfers to a limited
number of hosts used by network administrators may also
be convenient. Allowing zone transfers to all "trusted"
users may be too trusting in environments such as
Internet service providers or universities.
"Stealth primary zones" also exist. As these are mainly
used inside firewalled environments, it is not useful
to describe their configuration in this document
There are obvious limitations to these workarounds. As
stated previously, the only solution to this problem
currently is that all sites implement source address
checking to prevent packets with spoofed IP addresses
leaving their networks. Nonetheless, these suggestions
will assist in mitigating current forms of the attack
and may provide some additional security.
*** TODO: check this: A C source code patch must be applied
to all BIND 8.2.1 servers for the configuration
presented in this section to operate correctly. This
unsupported patch to BIND version 8.2.1 prevents BIND
returning REFUSED when it should be returning a
referral to a child zone.
This patch is available from:
ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.patch
*** not available ***
???: is this integrated yet???
These security policy examples given are typical of a
large university or ISP. It is noted where the
security policy could be relaxed in a less internally
hostile environment. Sites will, of course, need to
modify the examples to match their own policies as appropriate.
The examples in this section use a fictitious company
with the domain name "example.com" and the fictitious
IP address range 126.0.0.0/8.
When configuring a particular name server, first set
the default level of query and zone transfer access as
per the examples in (1) below. Then override this with
specific access controls for each zone, according to
its type (either (2) primary, (3) official secondary or
(4) stealth secondary). Each section here implements
the recommendations from the matching section number
from WORKAROUND.
*** TODO: since sections 1-4 are same as above then merge together
-- be more concise ***
*** TODO: make sure this is not redundant
9.3 Limiting Version Number Availability
*** TODO: test, maybe not needed anymore? or point to option or
config for this in this book ***
By default, the BIND version number can be read
globally using a DNS query utility such as "dig":
dig @dns0.example.com version.bind chaos txt
Allowing the version number of any software to be known
to everyone is usually undesirable. Access to the
version number can be restricted to local users by
adding the following to "/etc/named.conf" on all BIND
DNS servers:
// Control access to BIND version number to
// users at example.com only.
// Ref: BUGTRAQ posting from LaMont Jones
// <lamont at CRANSTON.FC.HP.COM> on 1998-06-12.
**** TODO: get rid of this "ref:" or use a footnote ***
zone "bind" chaos {
type master;
file "primary/bind";
allow-query {
trusted;
};
allow-transfer {
none;
};
};
And by also adding the file "/var/named/primary/bind"
containing only:
; File /var/named/primary/bind
$ORIGIN bind.
@ 1D CHAOS SOA localhost. root.localhost. (
1 ; serial
3H ; refresh
1H ; retry
1W ; expiry
1D ) ; minimum
CHAOS NS localhost.
; EOF
9.4 Controlling Log Messages
When being used to vector an attack, the BIND DNS
server can generate a large number of log messages of
the form:
unapproved query from [99.2.3.4].12345 for "example.net"
*** TODO: verify this log message ***
The BIND DNS server can be configured to log these
messages to a separate file, a separate syslog facility
(allowing logging on a remote machine) or to discard
all security messages.
Unfortunately, discarding security messages also
discards messages referring to users of stealth zones
that have been accidently denied access and messages
generated by the confusion of an official secondary
zone with a stealth secondary zone. It would be wise to
review the log messages for these events before
considering disabling security event logging.
9.5 Controlling Visibility of DNS Servers
Not all DNS servers are known to ISPs or the network
administrators of large enterprises. In particular,
there is no simple means of determining the presence of
caching-only DNS servers on hosts. These servers are
usually not configured to regulate the source of DNS queries.
As a result, these servers can be used to amplify
DNS-based denial of service attacks even if all the DNS
servers owned by the ISP regulate the source of DNS queries.
Organisations should consider limiting DNS UDP and TCP
access to just the known DNS servers by configuring
access restrictions on their network's border router.
These access restrictions can be summarized as:
* servers containing primary or official secondary zones:
*** TODO: how should this be formatted? ***
Remote *:* <-> address:53 Local (UDP/TCP)
* each DNS server that acts as a resolver (that is, is
listed in /etc/resolv.conf or supplied by PPP, DHCP
or BOOTP):
Remote *:53 <-> address:* Local (UDP/TCP)
* or, if the DNS servers are configured with
"query-source * port 53;":
Remote *:53 <-> address:53 Local (UDP)
Remote *:53 <-> address:* Local (TCP)
* servers containing unofficial secondary zones have
varying requirements, depending on the location of
the primary zone server:
Remote master:* <-> address:53 Local (UDP) (Notify)
Remote master:53 <-> address:* Local (UDP) (SOA query)
Remote master:53 <-> address:* Local (TCP) (IXFR)
* or, if the DNS servers are configured with
"query-source * port 53;":
Remote master:* <-> address:53 Local (UDP) (Notify)
Remote master:53 <-> address:53 Local (UDP) (SOA query)
Remote master:53 <-> address:* Local (TCP) (IXFR)
There are two traps for access list authors: Any DNS
UDP request may be given as a DNS TCP request; and the
DNS NOTIFY command must be allowed for servers of
primary zones to inform servers of secondary zones of a
change in the master file.
Implementing these access restrictions prevents queries
from hosts inside the network and denies direct access
from hosts inside the network to external name servers.
Denying direct access is unlikely to affect most hosts:
these make a recursive query to a pre-configured DNS server.
Denying direct access to external name servers is
likely to break caching-only DNS name servers on hosts.
These servers can be reconfigured to forward DNS
requests to one or more of the DNS servers that has DNS
visibility to the Internet. A caching-only name server
configuration is presented in Appendix [cha:Example-caching-only-name].
-=-=-=-=-=-=
Thanks!
Jeremy C. Reed
p.s. This is in regards to ticket #16479.
More information about the bind-workers
mailing list