idnits 2.17.1 draft-ietf-dnsop-as112-under-attack-help-help-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 29, 2011) is 4739 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-dnsop-default-local-zones-14 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Abley 3 Internet-Draft ICANN 4 Intended status: Informational W. Maton 5 Expires: October 31, 2011 NRC-CNRC 6 April 29, 2011 8 I'm Being Attacked by PRISONER.IANA.ORG! 9 draft-ietf-dnsop-as112-under-attack-help-help-06 11 Abstract 13 Many sites connected to the Internet make use of IPv4 addresses which 14 are not globally unique. Examples are the addresses designated in 15 RFC1918 for private use within individual sites. 17 Hosts should never normally send DNS reverse mapping queries for 18 those addresses on the public Internet. However, such queries are 19 frequently observed. Authoritative servers are deployed to provide 20 authoritative answers to such queries as part of a loosely- 21 coordinated effort known as the AS112 project. 23 Since queries sent to AS112 servers are usually not intentional, the 24 replies received back from those servers are typically unexpected. 25 Unexpected inbound traffic can trigger alarms on intrusion detection 26 systems and firewalls, and operators of such systems often mistakenly 27 believe that they are being attacked. 29 This document provides background information and technical advice to 30 those firewall operators. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on October 31, 2011. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction and Target Audience . . . . . . . . . . . . . . . 3 67 2. Private-Use Addresses . . . . . . . . . . . . . . . . . . . . 4 68 3. DNS Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 5 69 4. DNS Reverse Mapping for Private-Use Addresses . . . . . . . . 6 70 5. AS112 Nameservers . . . . . . . . . . . . . . . . . . . . . . 7 71 6. Inbound Traffic from AS112 Servers . . . . . . . . . . . . . . 8 72 7. Corrective Measures . . . . . . . . . . . . . . . . . . . . . 9 73 8. AS112 Contact Information . . . . . . . . . . . . . . . . . . 10 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 79 12.2. Informative References . . . . . . . . . . . . . . . . . 14 80 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 83 1. Introduction and Target Audience 85 Readers of this document may well have experienced an alarm from a 86 firewall or an intrusion-detection system, triggered by unexpected 87 inbound traffic from the Internet. The traffic probably appeared to 88 originate from one of several hosts discussed further below. 90 The published contacts for those hosts may well have suggested that 91 you consult this document. 93 If you are following up on such an event, you are encouraged to 94 follow your normal security procedures and take whatever action you 95 consider to be be appropriate. This document contains information 96 which may assist you. 98 2. Private-Use Addresses 100 Many sites connected to the Internet make use of address blocks 101 designated in [RFC1918] for private use. One example of such 102 addresses is 10.1.30.20. 104 Because these ranges of addresses are used by many sites all over the 105 world, each individual address can only ever have local significance. 106 For example, the host numbered 192.168.18.234 in one site almost 107 certainly has nothing to do with a host with the same address located 108 in a different site. 110 3. DNS Reverse Mapping 112 The Domain Name System (DNS) [RFC1034] can be used to obtain a name 113 for a particular network address. The process by which this happens 114 is as follows: 116 1. The network address is rearranged in order to construct a name 117 which can be looked up in the DNS. For example, the IPv4 address 118 10.1.30.20 corresponds to the DNS name 20.30.1.10.IN-ADDR.ARPA. 120 2. A DNS query is constructed for that name, requesting a DNS record 121 of the type "PTR". 123 3. The DNS query is sent to a resolver. 125 4. If a response is received in response to the query, the answer 126 will typically indicate either the hostname corresponding to the 127 network address, or the fact that no hostname can be found. 129 This procedure is generally carried out automatically by software, 130 and is hence largely hidden from users and administrators. 131 Applications might have reason to look up an IP address in order to 132 gather extra information for a log file, for example. 134 4. DNS Reverse Mapping for Private-Use Addresses 136 As noted in Section 2, private-use addresses have only local 137 significance. This means that sending queries out to the Internet is 138 not sensible: there is no way for the public DNS to provide a useful 139 answer to a question which has no global meaning. 141 Despite the fact that the public DNS cannot provide answers, many 142 sites have misconfigurations in the way they connect to the Internet 143 which results in such queries relating to internal infrastructure 144 being sent outside the site. From the perspective of the public DNS, 145 these queries are junk -- they cannot be answered usefully and result 146 in unnecessary traffic being received by the nameservers which 147 underpin the operation of the reverse DNS (the so-called reverse 148 servers [RFC5855] which serve "IN-ADDR.ARPA"). 150 To isolate this traffic, and reduce the load on the rest of the 151 reverse DNS infrastructure, dedicated servers have been deployed in 152 the Internet to receive and reply to these junk queries. These 153 servers are deployed in many places in a loosely-coordinated effort 154 known as the "AS112 Project". More details about the AS112 Project 155 can be found at . 157 5. AS112 Nameservers 159 The nameservers responsible for answering queries relating to 160 private-use addresses are as follows: 162 o PRISONER.IANA.ORG (192.175.48.1) 164 o BLACKHOLE-1.IANA.ORG (192.175.48.6) 166 o BLACKHOLE-2.IANA.ORG (192.175.48.42) 168 A request sent to one of these servers will result in a response 169 being returned to the client. The response will typically be a UDP 170 datagram, although it's perfectly valid for requests to be made over 171 TCP. In both cases the source port of packets returning to the site 172 which originated the DNS request will be 53. 174 6. Inbound Traffic from AS112 Servers 176 Where firewalls or intrusion detection systems (IDS) are configured 177 to block traffic received from AS112 servers, superficial review of 178 the traffic may seem alarming to site administrators. 180 o Since requests directed ultimately to AS112 servers are usually 181 triggered automatically by applications, review of firewall logs 182 may indicate a large number of policy violations occurring over an 183 extended period of time. 185 o Where responses from AS112 servers are blocked by firewalls, hosts 186 will often retry, often with a relatively high frequency. This 187 can cause inbound traffic to be misclassified as a denial-of- 188 service (DoS) attack. In some cases the source ports used by 189 individual hosts for successive retries increase in a predictable 190 fashion (e.g. monotonically), which can cause the replies from the 191 AS112 server to resemble a port scan. 193 o A site administrator may attempt to perform active measurement of 194 the remote host in response to alarms raised by inbound traffic, 195 e.g. initiating a port scan in order to gather information about 196 the host which is apparently attacking the site. Such a scan will 197 usually result in additional inbound traffic to the site 198 performing the measurement, e.g. an apparent flood of ICMP 199 messages which may trigger additional firewall alarms and 200 obfuscate the process of identifying the original problem traffic. 202 7. Corrective Measures 204 A site which receives responses from one of the nameservers listed in 205 Section 5 is probably under no immediate danger, and the traffic 206 associated with those responses probably requires no emergency action 207 by the site concerned. However, this document cannot aspire to 208 dictate the security policy of individual sites, and it is recognised 209 that many sites will have perfectly valid policies which dictate that 210 corrective measures should be taken to stop the responses from AS112 211 servers. 213 It should be noted, however, that the operators of AS112 nameservers 214 which are generating the responses described in this document are not 215 ultimately responsible for the inbound traffic received by the site: 216 that traffic is generated in response to queries which are sent out 217 from the site, and so the only effective measures to stop the inbound 218 traffic is to prevent the original queries from being made. 220 Possible measures which might be taken to prevent these queries 221 include: 223 1. Stop hosts from making these DNS reverse mapping queries in the 224 first place. In some cases servers can be configured not to 225 perform DNS reverse mapping lookups, for example. As a general 226 site-wide approach, however, this measure is frequently difficult 227 to implement due to the large number of hosts and applications 228 involved. 230 2. Block DNS reverse mapping queries to the AS112 servers from 231 leaving the site using firewalls between the site and the 232 Internet. Although this might appear to be sensible, such a 233 measure might have unintended consequences: the inability to 234 receive an answer to DNS reverse mapping queries might lead to 235 long DNS lookup timeouts, for example, which could cause 236 applications to malfunction. (It may also lead to the belief 237 that the Internet or the local network is down.) 239 3. Configure all DNS resolvers in the site to answer authoritatively 240 for the zones corresponding to the private-use address blocks in 241 use. This should prevent resolvers from ever needing to send 242 these queries to the public DNS. Guidance and recommendations 243 for this aspect of resolver configuration can be found in 244 [I-D.ietf-dnsop-default-local-zones]. 246 4. Implement a private AS112 node within the site. Guidance for 247 constructing an AS112 node may be found in 248 [I-D.ietf-dnsop-as112-ops]. 250 8. AS112 Contact Information 252 More information about the AS112 project can be found at 253 . 255 9. IANA Considerations 257 The AS112 nameservers are all named under the domain IANA.ORG (see 258 Section 5). The IANA is the organisation responsible for the 259 coordination of many technical aspects of the Internet's basic 260 infrastructure. The AS112 project nameservers provide a public 261 service to the Internet which is sanctioned by and operated in loose 262 coordination with the IANA. 264 This document makes no request of the IANA. 266 10. Security Considerations 268 The purpose of this document is to help site administrators properly 269 identify traffic received from AS112 nodes, and to provide background 270 information to allow appropriate measures to be taken in response to 271 it. 273 Hosts should never normally send queries to AS112 servers: queries 274 relating to private-use addresses should be answered locally within a 275 site. Hosts which send queries to AS112 servers may well leak 276 information relating to private infrastructure to the public network, 277 which could represent a security risk. 279 11. Acknowledgements 281 The authors wish to acknowledge the assistance of S. Moonesamy in the 282 preparation of this document. 284 12. References 286 12.1. Normative References 288 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 289 STD 13, RFC 1034, November 1987. 291 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 292 E. Lear, "Address Allocation for Private Internets", 293 BCP 5, RFC 1918, February 1996. 295 12.2. Informative References 297 [I-D.ietf-dnsop-as112-ops] 298 Abley, J. and W. Maton, "AS112 Nameserver Operations", 299 October 2009. 301 [I-D.ietf-dnsop-default-local-zones] 302 Andrews, M., "Locally-served DNS Zones", 303 draft-ietf-dnsop-default-local-zones-14 (work in 304 progress), September 2010. 306 [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6 307 Reverse Zones", BCP 155, RFC 5855, May 2010. 309 Appendix A. Change History 311 This section to be removed prior to publication. 313 00 Initial draft, circulated as 314 draft-jabley-as112-being-attacked-help-help-00 and reviewed at the 315 DNSOP working group meeting at IETF 66. 317 00 Document adopted by the DNSOP working group and renamed 318 accordingly. 320 01 Version number bump at request of wg chair. 322 02 Updated pointer to DNSOP working group-adopted of Mark Andrew's 323 full-service resolver zones, renamed to ietf-dnsop-default-local- 324 zones. 326 02 Updated author's addresses. 328 03 Version number bump at request of dnsop chair. 330 04 Version number bump at request of dnsop chair. Contact 331 information section truncated to protect the innocent. Minor, 332 non-substantive wordsmithing. References updated. 334 05 Version number bump at request of dnsop chair. References 335 updated. 337 06 Change references to root servers to reverse servers, since IN- 338 ADDR.ARPA has been re-delegated since this document was first 339 written. Add acknowledgements section. 341 Authors' Addresses 343 Joe Abley 344 ICANN 345 4676 Admiralty Way, Suite 330 346 Marina del Rey, CA 90292 347 US 349 Phone: +1 519 670 9327 350 Email: joe.abley@icann.org 352 William F. Maton Sotomayor 353 National Research Council of Canada 354 1200 Montreal Road 355 Ottawa, ON K1A 0R6 356 Canada 358 Phone: +1 613 993 0880 359 Email: wmaton@ryouko.imsb.nrc.ca