One document matched: draft-ietf-dnsop-as112-under-attack-help-help-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1034 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
<!ENTITY rfc1918 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml'>
<!ENTITY rfc4271 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml'>
<!ENTITY rfc2870 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2870.xml'>
<!ENTITY draft-andrews-full-service-resolvers PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.andrews-full-service-resolvers'>
]>
<rfc category="info" ipr="full3978"
docName="draft-ietf-dnsop-as112-under-attack-help-help-01">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>I'm Being Attacked by PRISONER.IANA.ORG!</title>
<author initials='J.' surname="Abley" fullname='Joe Abley'>
<organization abbrev="Afilias">Afilias Canada Corp.</organization>
<address>
<postal>
<street>Suite 204, 4141 Yonge Street</street>
<city>Toronto</city>
<region>ON</region>
<code>M2P 2A8</code>
<country>Canada</country>
</postal>
<phone>+1 416 673 4176</phone>
<email>jabley@ca.afilias.info</email>
</address>
</author>
<author initials='W.' surname="Maton" fullname='William F. Maton Sotomayor'>
<organization abbrev="NRC-CNRC">National Research Council
of Canada</organization>
<address>
<postal>
<street>1200 Montreal Road</street>
<city>Ottawa</city>
<region>ON</region>
<code>K1A 0R6</code>
<country>Canada</country>
</postal>
<phone>+1 613 993 0880</phone>
<email>wmaton@ryouko.imsb.nrc.ca</email>
</address>
</author>
<date month="November" year="2007"/>
<abstract>
<t>Many sites connected to the Internet make use of IPv4
addresses which are not globally unique. Examples are the
addresses designated in RFC1918 for private use within
individual sites.</t>
<t>Hosts should never normally send reverse DNS queries for
those addresses on the public Internet. However, such queries
are frequently observed. Authority servers are deployed to
provide authoritative answers to such queries as part of a
loosely-coordinated effort known as the AS112 project.</t>
<t>Since queries sent to AS112 servers are usually not
intentional, the replies received back from those servers
are typically unexpected. Unexpected inbound traffic can
trigger alarms on intrusion detection systems and firewalls,
and operators of such systems often mistakenly believe that
they are being attacked.</t>
<t>This document provides background information and technical
advice to those firewall operators.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Readers of this document may well have experienced an alarm
from a firewall or an intrusion-detection system, triggered
by unexpected inbound traffic from the Internet. The traffic
probably appeared to originate from one of the following
hosts:
<list style="symbols">
<t>PRISONER.IANA.ORG (192.175.48.1)</t>
<t>BLACKHOLE-1.IANA.ORG (192.175.48.6)</t>
<t>BLACKHOLE-2.IANA.ORG (192.175.48.42)</t>
</list>
The published contacts for those hosts may well have
suggested that you consult this document.</t>
<t>If you are following up on such an event, you are encouraged
to follow your normal security procedures and take whatever
action you consider to be be appropriate. This document
contains information which may assist you.</t>
</section>
<section title="Private-Use Addresses" anchor="priv">
<t>Many sites connected to the Internet make use of address
blocks designated in <xref target="RFC1918"/> for private
use. Examples of such addresses are 10.1.30.20, 172.18.24.100
and 192.168.1.1.</t>
<t>Because these ranges of addresses are used by many sites
all over the world, each individual address can only ever
have local significance. For example, the host numbered
192.168.18.234 in one site almost certainly has nothing to
do with a host with the same address located in a different
site.</t>
</section>
<section title="Reverse DNS">
<t>The <xref target="RFC1034">Domain Name System (DNS)</xref>
can be used to obtain a name for a particular network
address. The process by which this happens is as follows:
<list style="numbers">
<t>The network address is rearranged in order to construct
a name which can be looked up in the DNS. For example, the
IPv4 address 10.3.70.25 corresponds to the DNS name
25.70.3.10.IN-ADDR.ARPA.</t>
<t>A DNS query is constructed for that name, requesting
a DNS record of the type "PTR".</t>
<t>The DNS query is sent to a resolver.</t>
<t>If a response is received in response to the query, the
answer will typically indicate either the hostname
corresponding to the network address, or the fact that no
hostname can be found.</t>
</list>
This procedure is generally carried out automatically by
software, and is hence largely hidden from users and
administrators. Applications might have reason to look up
an IP address in order to gather extra information for a
log file, for example.</t>
</section>
<section title="Reverse DNS for Private-Use Addresses" anchor="privrdns">
<t>As noted in <xref target="priv"/>, private-use addresses
have only local significance. This means that sending
queries out to the Internet is not sensible: there is no
way for the public DNS to provide a useful answer to a
question which has no global meaning.</t>
<t>Despite the fact that the public DNS cannot provide
answers, many sites have misconfigurations in the way they
connect to the Internet which results to such queries
relating to internal infrastructure being sent outside the
site. From the perspective of the public DNS, these queries
are junk -- they cannot be answered usefully and result in
unnecessary traffic being received by the nameservers which
underpin the operation of the public DNS (the so-called
root servers).</t>
<t>To isolate this traffic, and reduce the load on the rest
of the DNS infrastructure, dedicated servers have been
deployed in the Internet to receive and reply to these junk
queries. These servers are deployed in many places in a
loosely-coordinated effort known as the "AS112 Project".
More details about the AS112 Project can be found at <eref
target="http://www.as112.net/"/>.</t>
</section>
<section title="AS112 Nameservers" anchor="nameservers">
<t>The nameservers responsible for answering queries relating
to private-use addresses are as follows:
<list style="symbols">
<t>PRISONER.IANA.ORG (192.175.48.1)</t>
<t>BLACKHOLE-1.IANA.ORG (192.175.48.6)</t>
<t>BLACKHOLE-2.IANA.ORG (192.175.48.42)</t>
</list>
A request sent to one of these servers will result in a
response being returned to the client. The response will
typically be a UDP datagram, although it's perfectly valid
for requests to be made over TCP. In both cases the source
port of packets returning to the site which originated the
DNS request will be 53.</t>
</section>
<section title="Inbound Traffic from AS112 Servers">
<t>Where firewalls or intrusion detection systems (IDS) are
configured to block traffic received from AS112 servers,
superficial review of the traffic may seem alarming to
site administrators.
<list style="symbols">
<t>Since requests directed ultimately to AS112 servers
are usually triggered automatically by applications,
review of firewall logs may indicate a large number of
policy violations occurring over an extended period of
time.</t>
<t>Where responses from AS112 servers are blocked by
firewalls, hosts will often retry, often with a relatively
high frequency. This can cause inbound traffic to be
misclassified as a denial-of-service (DoS) attack. In
some cases the source ports used by individual hosts for
successive retries increase in a predictable fashion
(e.g. monotonically), which can cause the replies from
the AS112 server to resemble a port scan.</t>
<t>A site administrator may attempt to perform active
measurement of the remote host in response to alarms
raised by inbound traffic, e.g. initiating a port scan
in order to gather information about the host which is
apparently attacking the site. Such a scan will usually
result in additional inbound traffic to the site
performing the measurement, e.g. an apparent flood of
ICMP messages which may trigger additional firewall
alarms and obfuscate the process of identifying the
original problem traffic.</t>
</list>
</t>
</section>
<section title="Corrective Measures">
<t>A site which receives responses from one of the nameservers
listed in <xref target="nameservers"/> is probably under
no immediate danger, and the traffic associated with those
responses probably requires no emergency action by the site
concerned. However, this document cannot aspire to dictate
the security policy of individual sites, and it is recognised
that many sites will have perfectly valid policies which
dictate that corrective measures should be taken to stop
the responses from AS112 servers.</t>
<t>It should be noted, however, that the operators of AS112
nameservers which are generating the responses described
in this document are not ultimately responsible for the
inbound traffic received by the site: that traffic is
generated in response to queries which are sent out from
the site, and so the only effective measures to stop the
inbound traffic is to prevent the original queries from
being made.</t>
<t>Possible measures which might be taken to prevent these
queries include:
<list style="numbers">
<t>Stop hosts from making these reverse DNS queries in
the first place. In some cases servers can be configured
not to perform reverse DNS lookups, for example. As a
general site-wide approach, however, this measure is
frequently difficult to implement due to the large
number of hosts and applications involved.</t>
<t>Block reverse DNS queries to the AS112 servers from
leaving the site using firewalls between the site and
the Internet. Although this might appear to be sensible,
such a measure might have unintended consequences: the
inability to receive an answer to reverse DNS queries
might lead to long DNS lookup timeouts, for example,
which could cause applications to malfunction.</t>
<t>Configure all DNS resolvers in the site to answer
authoritatively for the zones corresponding to the
private-use address blocks in use. This should prevent
resolvers from ever needing to send these queries to
the public DNS. Guidance and recommendations for
this aspect of resolver configuration can be found in
<xref target="I-D.andrews-full-service-resolvers"/>.</t>
<t>Implement a private AS112 node within the site. Guidance for
constructing an AS112 node may be found in
<xref target="I-D.ietf-dnsop-as112-ops"/>.</t>
</list>
</t>
</section>
<section title="AS112 Contact Information">
<t>Operational contact information for the network addresses
of AS112 servers is registered with Regional Internet
Registries (RIRs). Readers who continue to have concerns
about traffic received from AS112 servers after reading
this document are encouraged to contact the AS112 Network
Operations Centre.</t>
<t>More information about the AS112 project can be found
at <eref target="http://www.as112.net/"/>.</t>
</section>
<section title="IANA Considerations">
<t>The AS112 nameservers are all named under the domain
IANA.ORG (see <xref target="nameservers"/>). The IANA is
the organisation responsible for the coordination of many
technical aspects of the Internet's basic infrastructure.
The AS112 project nameservers provide a public service to
the Internet which is sanctioned by and operated in
coordination with the IANA.</t>
</section>
<section title="Security Considerations" anchor="security">
<t>The purpose of this document is to help site administrators
properly identify traffic received from AS112 nodes, and
to provide background information to allow appropriate
measures to be taken in response to it.</t>
<t>Hosts should never normally send queries to AS112 servers:
queries relating to private-use addresses should be answered
locally within a site. Hosts which send queries to AS112
servers may well leak information relating to private
infrastructure to the public network, which could represent
a security risk.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc1034;
&rfc1918;
</references>
<references title="Informative References">
&draft-andrews-full-service-resolvers;
<reference anchor="I-D.ietf-dnsop-as112-ops">
<front>
<title>AS112 Nameserver Operations</title>
<author initials='J.' surname="Abley" fullname='Joe Abley'>
<organization abbrev="Afilias Canada">Afilias Canada Corp.</organization>
<address>
<postal>
<street>Suite 204, 4141 Yonge Street</street>
<city>Toronto</city>
<region>ON</region>
<code>M2P 2A8</code>
<country>Canada</country>
</postal>
<phone>+1 416 673 4176</phone>
<email>jabley@ca.afilias.info</email>
</address>
</author>
<author initials='W.' surname="Maton" fullname='William F. Maton Sotomayor'>
<organization abbrev="NRC-CNRC">National Research Council
of Canada</organization>
<address>
<postal>
<street>1200 Montreal Road</street>
<city>Ottawa</city>
<region>ON</region>
<code>K1A 0R6</code>
<country>Canada</country>
</postal>
<phone>+1 613 993 0880</phone>
<email>wmaton@ryouko.imsb.nrc.ca</email>
</address>
</author>
<date month="February" year="2007"/>
</front>
</reference>
</references>
<section title="Change History">
<t>This section to be removed prior to publication.</t>
<t>
<list style="hanging">
<t hangText="00">Initial draft, circulated as
draft-jabley-as112-being-attacked-help-help-00 and
reviewed at the DNSOP working group meeting at IETF 66.</t>
<t hangText="00">Document adopted by the DNSOP working
group and renamed accordingly.</t>
<t hangText="01">Version number bump at request of wg chair.</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:36:38 |