One document matched: draft-ietf-dnsop-as112-under-attack-help-help-06.xml
<?xml version="1.0" encoding="UTF-8"?><?rfc linefile="1:draft-ietf-dnsop-as112-under-attack-help-help.xml"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="info" ipr="trust200902"
docName="draft-ietf-dnsop-as112-under-attack-help-help-06">
<?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>ICANN</organization>
<address>
<postal>
<street>4676 Admiralty Way, Suite 330</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>
<phone>+1 519 670 9327</phone>
<email>joe.abley@icann.org</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 day="29" month="April" year="2011"/>
<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 DNS reverse mapping queries
for those addresses on the public Internet. However, such
queries are frequently observed. Authoritative 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 and Target Audience">
<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 several hosts
discussed further below.</t>
<t>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. One example of such addresses is 10.1.30.20.</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="DNS Reverse Mapping">
<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.1.30.20 corresponds to the DNS name
20.30.1.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="DNS Reverse Mapping 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 in 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 reverse DNS (the so-called
<xref target="RFC5855">reverse servers</xref> which serve
"IN-ADDR.ARPA").</t>
<t>To isolate this traffic, and reduce the load on the rest
of the reverse 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 DNS reverse mapping queries in
the first place. In some cases servers can be configured
not to perform DNS reverse mapping 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 DNS reverse mapping 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 DNS reverse mapping queries
might lead to long DNS lookup timeouts, for example,
which could cause applications to malfunction. (It may
also lead to the belief that the Internet or the local
network is down.)</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.ietf-dnsop-default-local-zones"/>.</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>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
loose coordination with the IANA.</t>
<t>This document makes no request of 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>
<section title="Acknowledgements">
<t>The authors wish to acknowledge the assistance of S. Moonesamy
in the preparation of this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='RFC1034'>
<front>
<title abbrev='Domain Concepts and Facilities'>Domain names - concepts and facilities</title>
<author initials='P.' surname='Mockapetris' fullname='P. Mockapetris'>
<organization>Information Sciences Institute (ISI)</organization></author>
<date year='1987' day='1' month='November' /></front>
<seriesInfo name='STD' value='13' />
<seriesInfo name='RFC' value='1034' />
<format type='TXT' octets='129180' target='http://www.rfc-editor.org/rfc/rfc1034.txt' />
</reference>
<reference anchor='RFC1918'>
<front>
<title>Address Allocation for Private Internets</title>
<author initials='Y.' surname='Rekhter' fullname='Yakov Rekhter'>
<organization>Cisco systems</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country></postal>
<phone>+1 914 528 0090</phone>
<facsimile>+1 408 526 4952</facsimile>
<email>yakov@cisco.com</email></address></author>
<author initials='R.' surname='Moskowitz' fullname='Robert G. Moskowitz'>
<organization>Chrysler Corporation</organization>
<address>
<postal>
<street>25999 Lawrence Ave</street>
<city>Center Line</city>
<region>MI</region>
<code>48015</code>
<country>US</country></postal>
<phone>+1 810 758 8212</phone>
<facsimile>+1 810 758 8173</facsimile>
<email>rgm3@is.chrysler.com</email></address></author>
<author initials='D.' surname='Karrenberg' fullname='Daniel Karrenberg'>
<organization>RIPE Network Coordination Centre</organization>
<address>
<postal>
<street>Kruislaan 409</street>
<city>Amsterdam</city>
<region />
<code>1098 SJ</code>
<country>NL</country></postal>
<phone>+31 20 5925065</phone>
<facsimile>+31 20 5925090</facsimile>
<email>Daniel.Karrenberg@ripe.net</email></address></author>
<author initials='G.' surname='Groot' fullname='Geert Jan de Groot'>
<organization>RIPE Network Coordination Centre</organization>
<address>
<postal>
<street>Kruislaan 409</street>
<city>Amsterdam</city>
<region />
<code>1098 SJ</code>
<country>NL</country></postal>
<phone>+31 20 5925065</phone>
<facsimile>+31 20 5925090</facsimile>
<email>GeertJan.deGroot@ripe.net</email></address></author>
<author initials='E.' surname='Lear' fullname='Eliot Lear'>
<organization>Silicon Graphics, Inc.</organization>
<address>
<postal>
<street>2011 N. Shoreline Blvd.</street>
<street>Mail Stop 15-730</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-1389</code>
<country>US</country></postal>
<phone>+1 415 960 1980</phone>
<facsimile>+1 415 961 9584</facsimile>
<email>lear@sgi.com</email></address></author>
<date year='1996' month='February' /></front>
<seriesInfo name='BCP' value='5' />
<seriesInfo name='RFC' value='1918' />
<format type='TXT' octets='22270' target='http://www.rfc-editor.org/rfc/rfc1918.txt' />
</reference>
</references>
<references title="Informative References">
<reference anchor='I-D.ietf-dnsop-default-local-zones'>
<front>
<title>Locally-served DNS Zones</title>
<author initials='M' surname='Andrews' fullname='Mark Andrews'>
<organization />
</author>
<date month='September' day='22' year='2010' />
<abstract><t>Experience with the Domain Name System (DNS) has shown that there are a number of DNS zones all iterative resolvers and recursive nameservers should automatically serve, unless configured otherwise. RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space and other well known zones with similar characteristics.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dnsop-default-local-zones-14' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-14.txt' />
</reference>
<reference anchor="I-D.ietf-dnsop-as112-ops">
<front>
<title>AS112 Nameserver Operations</title>
<author initials='J.' surname="Abley" fullname='Joe Abley'>
<organization abbrev="TekSavvy">TekSavvy Solutions, Inc.</organization>
<address>
<postal>
<street>330 Richmond Street, Suite 205</street>
<city>Chatham</city>
<region>ON</region>
<code>N7M 1P7</code>
<country>Canada</country>
</postal>
<phone>+1 519 670 9327</phone>
<email>jabley@teksavvy.com</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="October" year="2009"/>
</front>
</reference>
<reference anchor="RFC5855">
<front>
<title>Nameservers for IPv4 and IPv6 Reverse Zones</title>
<author initials='J.' surname='Abley' fullname='J. Abley'>
<organization /></author>
<author initials='T.' surname='Manderson' fullname='T. Manderson'>
<organization /></author>
<date year='2010' month='May' />
<abstract>
<t>This document specifies a stable naming scheme for the nameservers that serve the zones IN-ADDR.ARPA and IP6.ARPA in the DNS. These zones contain data that facilitate reverse mapping (address to name). This memo documents an Internet Best Current Practice.</t></abstract></front>
<seriesInfo name='BCP' value='155' />
<seriesInfo name='RFC' value='5855' />
<format type='TXT' octets='23027' target='http://www.rfc-editor.org/rfc/rfc5855.txt' />
</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>
<t hangText="02">Updated pointer to DNSOP working group-adopted
of Mark Andrew's full-service resolver zones, renamed to
ietf-dnsop-default-local-zones.</t>
<t hangText="02">Updated author's addresses.</t>
<t hangText="03">Version number bump at request of dnsop chair.</t>
<t hangText="04">Version number bump at request of dnsop
chair. Contact information section truncated to protect
the innocent. Minor, non-substantive wordsmithing. References
updated.</t>
<t hangText="05">Version number bump at request of dnsop chair.
References updated.</t>
<t hangText="06">Change references to root servers to reverse
servers, since IN-ADDR.ARPA has been re-delegated since this
document was first written. Add acknowledgements section.</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:36:38 |