Date: 13 August 1999
Click here for printable version
Click here for PGP verifiable version
-----BEGIN PGP SIGNED MESSAGE-----
===========================================================================
A U S C E R T A L E R T
AL-1999.004 -- AUSCERT ALERT
Denial of Service (DoS) attacks using the Domain Name System (DNS)
13 August 1999
Last revised: 13 August 1999
A complete revision history is at the end of this file.
===========================================================================
PROBLEM:
AusCERT has received information about a new form of denial of
service attack based on exploiting the difference in size between
a Domain Name System (DNS) query and a DNS response and the
willingness of DNS servers to answer queries from any source.
This vulnerability may allow remote denial of service attacks
against target hosts whose IP addresses are spoofed in the DNS
query.
Information regarding this vulnerability has been made
publicly available and a tool has been posted to the BUGTRAQ
mailing list which apparently exploits this vulnerability.
AusCERT has been advised of sustained instances of the use of
this tool to conduct denial of service attacks against sites
within Australia.
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.
IMPACT:
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.
Information regarding this vulnerability has been made
publicly available. A tool to exploit this vulnerability
was posted to the BUGTRAQ mailing list on 30 July 1999 by
smaster@sail.it in message <199907310000.AA154206596@sail.it>.
AusCERT members have observed this tool in use against
hosts on their networks.
SOLUTION:
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.
Appendix A of CERT advisory CA96.21 "TCP SYN Flooding and IP
Spoofing Attacks" gives more information on configuring
networks to defeat IP address spoofing. That advisory is
available from:
http://www.cert.org/advisories/CA-96.21.tcp_syn_flooding.html
Additional information may also be found in RFC2267 "Network
Ingress Filtering: Defeating Denial of Service Attacks which
employ IP Source Address Spoofing". That RFC is available
from your local RFC repository including:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.isi.edu/in-notes/rfc2267.txt
WORKAROUND:
The current 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.
[In the discussion below, "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.]
For the purposes of refusing queries from unexpected sources, DNS
queries directed to a particular name server can be categorised
into the following types. For each type of query a typical access
control configuration is given. In addition, we suggest 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.
(1) QUERIES FOR ANY NAME.
Allow queries from "trusted" sources only. Allow no zone
transfers.
(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.
(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.
(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 minimises 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.
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.
LIMITATIONS:
There are obvious limitations to the workarounds presented in this
alert. 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.
BIND VERSION 8 EXAMPLE CONFIGURATION EXTRACTS:
Internet Software Consortium's Berkeley Internet Name Domain
is a popular DNS server for UNIX and other POSIX-like
operating systems. This section implements the above
recommendations for BIND version 8.2.1.
The current release of BIND (including source code) and other
information is available at the ISC webpage:
http://www.isc.org/view.cgi?/products/BIND/index.phtml
BIND 8.2.1 is also available directly via ftp from:
ftp://ftp.isc.org/isc/bind/src/8.2.1/
ftp://ftp.auscert.org.au/pub/mirrors/ftp.isc.org/bind/src/8.2.1/
Earlier releases of BIND are vulnerable to the faults listed
in CERT Summary CS98.05 (redistributed as AusCERT ESB-98.080).
At the time of issue of this document, ISC recommends
upgrading to BIND 8.2.1.
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
If you wish to check the integrity of the above patch file, please
download the 'detached PGP signature' file from:
ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.patch.asc
and check it with the AusCERT public key available from:
ftp://ftp.auscert.org.au/pub/auscert/AUSCERT_PGP.key
The security policy examples given in this alert are typical of
a large university or ISP. They implement the suggested
recommendations on access control as presented in the WORKAROUND
section. 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. The BIND configuration file is called
"/etc/named.conf". The configuration file may have some other
name on your BIND server.
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.
(1) DEFAULT.
The default case is handled by setting the BIND options.
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.
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;
};
};
(2) PRIMARY ZONES.
"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 was 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.
(3) OFFICIAL SECONDARY ZONES.
"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 was 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.
(4) STEALTH SECONDARY ZONES.
"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 was noted above, any sub-domains of "example.com"
present on 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.
OTHER BIND VERSION 8 SECURITY OPTIONS:
LIMITING VERSION NUMBER AVAILABILITY
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@CRANSTON.FC.HP.COM> on 1998-06-12.
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
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"
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.
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 summarised as:
- servers containing primary or official secondary zones:
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. Firstly, any DNS
UDP request may be given as a DNS TCP request. Secondly, 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 for UNIX and other
POSIX-like hosts running BIND version 8 is presented in
Appendix A.
APPENDIX A: ISC BIND 8.2.1 CACHING-ONLY NAME SERVER CONFIGURATION
A BIND version 8 configuration extract for a caching-only
name server designed to service only the host it is running on
is given below. The DNS names and IP addresses used
correspond to those in the section "BIND Version 8 Example
Configuration Extracts" above.
Extracts from file "/etc/named.conf":
options {
// "only" misleads -- if all the forwarders fail we
// are no worse off than with only a /etc/resolv.conf,
// but we get the benefit of DNS name caching in the
// meantime.
forward only;
forwarders {
// From previous "nameserver" entries in
// /etc/resolv.conf.
126.0.2.1; // dns0.example.com
126.0.2.2; // dns1.example.com
126.0.1.1; // dns2.example.com
};
allow-query {
localhost;
};
listen-on {
// Ignore spoofed packets on externally
// visible interfaces.
127.0.0.1; // loopback
};
};
// Bootstrap the root.
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 {
localhost;
};
};
// Control access to BIND version number.
zone "bind" chaos {
type master;
file "primary/bind";
allow-query {
localhost;
};
};
Complete file "/etc/resolv.conf":
search example.com
nameserver 127.0.0.1
- ----------------------------------------------------------------------------
AusCERT would like to acknowledge Glen Turner of the University of
Adelaide, who contributed a substantial volume of the information in this
alert. Vital assistance and information was also provided by Mark Andrews
of the Internet Software Consortium. Thanks is due to Alan Cowie of the
NSW Regional Network Organisation for his feedback regarding this issue.
AusCERT also wishes to thank Chris Teakle and Mark Suter of The
University of Queensland for providing expert comments and feedback on
the content of this alert.
- ----------------------------------------------------------------------------
[AusCERT issues an alert when the risk posed by a vulnerability that may
not have been thoroughly investigated and for which a work-around or fix
may not yet have been developed requires notification.]
The AusCERT team has made every effort to ensure that the information
contained in this document is accurate at the time of publication. However,
the decision to use the information described is the responsibility of
each user or organisation. The appropriateness of this document for an
organisation or individual system should be considered before application
in conjunction with local policies and procedures. AusCERT takes no
responsibility for the consequences of applying the contents of this
document.
If you believe that your system has been compromised, contact AusCERT or
your representative in FIRST (Forum of Incident Response and Security
Teams).
AusCERT maintains an anonymous FTP service which is found on:
ftp://ftp.auscert.org.au/pub/. This archive contains past SERT
and AusCERT Advisories, and other computer security information.
AusCERT maintains a World Wide Web service which is found on:
http://www.auscert.org.au/.
Internet Email: auscert@auscert.org.au
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business
hours which are GMT+10:00 (AEST). On call
after hours for emergencies.
Postal:
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072
AUSTRALIA
===========================================================================
Revision History:
13 Aug 1999 Corrected typographical errors in numbering of headers
in "CONFIGURATION EXTRACTS" section.
===========================================================================
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: ftp://ftp.auscert.org.au/pub/auscert/AUSCERT_PGP.key
iQCVAwUBN7ReYyh9+71yA2DNAQHLyQP9FAHN2lsBbtl8DFiVx01JKOkOG7D1hFm2
xeCs261N6vMuKgi8GRi4oY7r9KUWXo7RP9k/Lflx4zFc2eBcNyWcsE4eDhL2Zl0t
piAgRQqCrRLZY/c/g1Kgs2v8zpIoLDu16RK+gEaEhctWHqaKQ102XmqjlMFEUTzC
otnSHEZS0Gw=
=/RmC
-----END PGP SIGNATURE-----
|