Internet Engineering Task Force (IETF) J. Abley
Request for Comments: 6305 ICANN
Category: Informational W. Maton
ISSN: 2070-1721 NRC-CNRC
July 2011
I'm Being Attacked by PRISONER.IANA.ORG!
Abstract
抽象
Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites.
インターネットに接続されている多くのサイトでは、グローバルに一意でないIPv4アドレスを使用しています。例としては、個々のサイト内の私的使用のためのRFC 1918で指定されたアドレスです。
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.
ホストは通常、公共のインターネット上のアドレスに対してDNSの逆マッピングクエリを送信することはありません。しかし、このようなクエリが頻繁に観察されています。権威サーバはAS112プロジェクトとして知られる緩く協調努力の一環として、このようなクエリに権威ある答えを提供するために展開されています。
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.
AS112サーバに送信されたクエリは、通常は意図的ではないので、それらのサーバーから戻って受け取った回答は、一般的に予想外です。予期しない着信トラフィックは、侵入検知システムやファイアウォールでアラームを起動することができ、そのようなシステムのオペレータは、しばしば誤って、彼らが攻撃されていると信じています。
This document provides background information and technical advice to those firewall operators.
この文書では、これらのファイアウォールのオペレータに背景情報と技術的なアドバイスを提供します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6305.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6305で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction and Target Audience . . . . . . . . . . . . . . . 3
2. Private-Use Addresses . . . . . . . . . . . . . . . . . . . . . 3
3. DNS Reverse Mapping . . . . . . . . . . . . . . . . . . . . . . 3
4. DNS Reverse Mapping for Private-Use Addresses . . . . . . . . . 4
5. AS112 Nameservers . . . . . . . . . . . . . . . . . . . . . . . 4
6. Inbound Traffic from AS112 Servers . . . . . . . . . . . . . . 5
7. Corrective Measures . . . . . . . . . . . . . . . . . . . . . . 5
8. AS112 Contact Information . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
12.1. Normative References . . . . . . . . . . . . . . . . . . . 7
12.2. Informative References . . . . . . . . . . . . . . . . . . 7
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.
このドキュメントの読者はよくインターネットからの予想外のインバウンドトラフィックによってトリガー、ファイアウォールや侵入検知システムからアラームを経験している可能性があります。トラフィックはおそらく、さらに後述するいくつかのホストの一つに由来すると思われます。
The published contacts for those hosts may well have suggested that you consult this document.
それらのホストのための公表の接点はよくあなたがこの文書を相談することを示唆している可能性があります。
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 appropriate. This document contains information that may assist you.
あなたは、このようなイベントにフォローアップしている場合、あなたは、通常のセキュリティ手順に従ってください、あなたが適切であると考えてどんな行動取ることが奨励されています。この文書では、あなたを支援する可能性のある情報が含まれています。
Many sites connected to the Internet make use of address blocks designated in [RFC1918] for private use. One example of such addresses is 10.1.30.20.
インターネットに接続されている多くのサイトでは、私的使用のために[RFC1918]で指定されたアドレスブロックを使用しています。そのようなアドレスの一例は10.1.30.20です。
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.
アドレスのこれらの範囲は、世界中の多くのサイトで使用されているので、個々のアドレスは今までローカルな意味を持つことができます。例えば、ホストは、ほぼ確実に一つのサイトに192.168.18.234を、番号別のサイトにある同じアドレスを持つホストとは何の関係もありません。
The Domain Name System (DNS) [RFC1034] can be used to obtain a name for a particular network address. The process by which this happens is as follows:
ドメインネームシステム（DNS）[RFC1034]は、特定のネットワークアドレスの名前を取得するために使用することができます。次のようにこの問題が発生するプロセスは以下のとおりです。
1. The network address is rearranged in order to construct a name that 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.
1.ネットワークアドレスをDNSで調べることができます名前を構築するために再配置されます。例えば、IPv4のDNS名20.30.1.10.IN-ADDR.ARPAに10.1.30.20対応に取り組みます。
2. A DNS query is constructed for that name, requesting a DNS record of the type "PTR".
2. DNSクエリがタイプ「PTR」のDNSレコードを要求し、その名前のために構成されています。
4. 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.
応答は、クエリに応答して受信された場合4、答えは通常、ネットワークアドレスに対応するホスト名、またはまったくホスト名が見つからないことができるという事実のいずれかを示します。
This procedure is generally carried out automatically by software, and hence is 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.
アプリケーションは、例えば、ログファイルの追加情報を収集するために、IPアドレスを検索するための理由があるかもしれません。
As noted in Section 2, 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 that has no global meaning.
第2節で述べたように、私的使用のアドレスは、ローカルな意味を持っています。これは、インターネットへのクエリを送信することは賢明ではないことを意味します。グローバルな意味を持っていない質問に対する有益な答えを提供するために、パブリックDNSのための方法はありません。
Despite the fact that the public DNS cannot provide answers, many sites have misconfigurations in the way they connect to the Internet; this 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 reverse servers [RFC5855], which serve "IN-ADDR.ARPA").
パブリックDNSは答えを提供することができないという事実にもかかわらず、多くのサイトは、彼らがインターネットに接続する方法で、設定ミスを持っています。内部インフラストラクチャに関連するようなクエリでは、この結果は、サイト外に送信されています。パブリックDNSの観点から、これらのクエリはジャンクです - 彼らが提供DNSの逆の操作（いわゆる逆サーバ[RFC5855]を支えるネームサーバによって受信された有効答えて不要なトラフィックが発生することができません"IN-ADDR.ARPA"）。
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 <http://www.as112.net/>.
このトラフィックを分離し、逆DNSインフラストラクチャの残りの部分への負荷を軽減するために、専用のサーバーが受信し、これらのジャンククエリに返信するには、インターネットで展開されています。これらのサーバーは「AS112プロジェクト」として知られる緩く協調努力で多くの場所で展開されています。 AS112のプロジェクトについての詳細は、<http://www.as112.net/>で見つけることができます。
The nameservers responsible for answering queries relating to private-use addresses are as follows:
次のように私的使用のアドレスに関連するクエリに答えるための責任のネームサーバは、次のとおりです。
o PRISONER.IANA.ORG (192.175.48.1)
お ＰりそねＲ。いあな。おＲＧ （１９２。１７５。４８。１）
o BLACKHOLE-1.IANA.ORG (192.175.48.6)
お ＢぁＣＫほぇー１。いあな。おＲＧ （１９２。１７５。４８。６）
o BLACKHOLE-2.IANA.ORG (192.175.48.42)
お ＢぁＣＫほぇー２。いあな。おＲＧ （１９２。１７５。４８。４２）
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 that originated the DNS request will be 53.
これらのサーバーのいずれかに送信された要求は、クライアントに返される応答になります。それはTCPを介して行われる要求のために完全に有効なのですが、応答は通常、UDPデータグラムになります。どちらの場合も、DNS要求を発信し、サイトに戻ってパケットの送信元ポートは53になります。
Where firewalls or intrusion detection systems (IDSs) are configured to block traffic received from AS112 servers, superficial review of the traffic may seem alarming to site administrators.
ファイアウォールや侵入検知システム（IDS;侵入が）AS112サーバから受信したトラフィックをブロックするように設定されている場合は、トラフィックの表面的な見直しは、サイトの管理者にアラーム見えるかもしれません。
o 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.
AS112サーバに最終的には監督の要求は、通常、アプリケーションが自動的に起動されているので、O、ファイアウォールのログのレビューは、長期間にわたって発生したポリシー違反の多数を示すかもしれません。
o 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.
AS112サーバからの応答がファイアウォールによってブロックされている場合は、O、ホストは多くの場合、多くの場合、比較的高い頻度で、再試行します。これは、インバウンドトラフィックはサービス拒否（DoS）攻撃として誤って分類されることがあります。いくつかのケースでは、連続した再試行のために個々のホストによって使用される送信元ポートは、ポート・スキャンに似せてAS112サーバからの応答を引き起こすことができる（例えば、単調に）予測可能な様式で増加します。
o 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 that may trigger additional firewall alarms and obfuscate the process of identifying the originally problematic traffic.
Oサイト管理者は、例えば、インバウンドトラフィックによって発生したアラームに応じて、リモートホストのアクティブな測定を実行しようとすることどうやらサイトを攻撃しているホストに関する情報を収集するために、ポートスキャンを開始します。そのようなスキャンは、通常、測定を実行するサイトに追加インバウンドトラフィックになり、例えば、追加のファイアウォールアラームをトリガし、元々問題のトラフィックを識別するプロセスを難読化することができるICMPメッセージの見かけの洪水。
A site that receives responses from one of the nameservers listed in Section 5 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 that dictate that corrective measures should be taken to stop the responses from AS112 servers.
第5節に記載されているネームサーバのいずれかから応答を受信サイトは、おそらく当面の危険下にあり、そしてそれらの応答に関連したトラフィックは、おそらく関係サイトによって何の緊急行動を必要としません。しかし、この文書では、個々のサイトのセキュリティポリシーを決定するために熱望することができない、多くのサイトが是正措置がAS112サーバからの応答を停止するために取られるべきであることを指示完全に有効な政策を持っていることが認識されます。
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 that 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.
トラフィックから送信されたクエリに応答して生成されていること：この文書で説明応答を生成しているAS112ネームサーバの事業者が、サイトによって受信されたインバウンドトラフィックのための最終的な責任はないことに留意すべきですサイト、および着信トラフィックを停止するので、唯一の効果的な対策が行われてから、元のクエリを防ぐためです。
Possible measures that might be taken to prevent these queries include:
これらのクエリを防ぐために取られるかもしれない可能性のある措置が含まれます：
1. 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.
これらのDNSは逆マッピングクエリを最初の場所になってから1ストップホスト。いくつかのケースでは、サーバは、例えば、DNSの逆マッピングルックアップを実行しないように設定することができます。一般的なサイト全体のアプローチとして、しかし、この措置が原因関与ホストおよびアプリケーションの数が多いため、実装がしばしば困難です。
2. 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.)
2.ブロックDNSは逆マッピングクエリーをAS112サーバへのサイトとインターネットの間にファイアウォールを使用してサイトを離れるから。これは賢明なように見えるかもしれませんが、このような措置は、意図しない結果が生じる可能性：DNS逆マッピングクエリに対する回答を受け取ることができないことは、アプリケーションが誤動作を引き起こす可能性があり、例えば、長いDNSルックアップタイムアウトにつながる可能性があります。 （それはまた、インターネットやローカルネットワークがダウンしているという信念につながる可能性があります。）
3. 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 [RFC6303].
3.使用されている私的使用のアドレスブロックに対応するゾーンの正式答えるためにサイト内のすべてのDNSリゾルバを設定します。これは、これまでパブリックDNSにこれらのクエリを送信するために必要とするからリゾルバを防ぐ必要があります。レゾルバの構成のこの局面のためのガイダンスと推奨事項は、[RFC6303]に見出すことができます。
4. Implement a private AS112 node within the site. Guidance for constructing an AS112 node may be found in [RFC6304].
4.サイト内のプライベートAS112ノードを実装します。 AS112のノードを構成するためのガイダンスは、[RFC6304]に見出すことができます。
More information about the AS112 project can be found at <http://www.as112.net/>.
AS112プロジェクトの詳細については、<http://www.as112.net/>で見つけることができます。
The AS112 nameservers are all named under the domain IANA.ORG (see Section 5). 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 that is sanctioned by and operated in loose coordination with the IANA.
AS112のネームサーバは、すべてのドメインIANA.ORG（第5節を参照）の下に名前が付けられます。 IANAは、インターネットの基本的なインフラの多くの技術的側面の調整を担当する組織です。 AS112プロジェクトネームサーバはによって認可とIANAと緩い連携して動作され、インターネットへの公共サービスを提供しています。
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.
このドキュメントの目的は、サイト管理者が適切にAS112ノードから受信したトラフィックを識別し、適切な措置がそれに反応して撮影することができるように背景情報を提供するために支援することです。
Hosts should never normally send queries to AS112 servers: queries relating to private-use addresses should be answered locally within a site. Hosts that send queries to AS112 servers may well leak information relating to private infrastructure to the public network; this could represent a security risk.
ホストは通常、AS112サーバにクエリを送信することはありません：私的使用のアドレスに関連するクエリは、サイト内で局所的に答えられるはずです。 AS112サーバにクエリを送信するホストは、公共ネットワークへの民間インフラに関連する情報を漏らすこと。これは、セキュリティ上のリスクを表すことができます。
The authors wish to acknowledge the assistance of S. Moonesamy in the preparation of this document.
著者は、この文書の作成にS. Moonesamyの支援を認めることを望みます。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6 Reverse Zones", BCP 155, RFC 5855, May 2010.
[RFC5855] Abley、J.及びT. Manderson、 "IPv4およびIPv6リバースゾーンのネームサーバ"、BCP 155、RFC 5855、2010年5月。
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 6303, July 2011.
[RFC6303]アンドリュース、M.、 "ローカル添えDNSゾーン"、BCP 163、RFC 6303、2011年7月。
[RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", RFC 6304, July 2011.
[RFC6304] Abley、J.およびW. Maton、 "AS112ネームサーバの操作"、RFC 6304、2011年7月。
Authors' Addresses
著者のアドレス
Joe Abley ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 US
ジョーAbley ICANN 4676アドミラルティ・ウェイ、スイート330マリナ・デル・レイ、CA 90292米国
Phone: +1 519 670 9327 EMail: joe.abley@icann.org
電話：+1 519 670 9327 Eメール：joe.abley@icann.org
William F. Maton Sotomayor National Research Council of Canada 1200 Montreal Road Ottawa, ON K1A 0R6 Canada
K1A 0R6カナダONカナダ1200年モントリオール道路オタワのウィリアム・F. Matonソトマイヨール国立研究評議会、
Phone: +1 613 993 0880 EMail: wmaton@ryouko.imsb.nrc.ca
電話：+1 613 993 0880 Eメール：wmaton@ryouko.imsb.nrc.ca