[要約] RFC 6305は、PRISONER.IANA.ORGによる攻撃についての報告と対策を提案しています。目的は、この攻撃に対する理解を深め、対策を講じるためのガイドラインを提供することです。
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!
私は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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントの読者は、インターネットからの予期しないインバウンドトラフィックによってトリガーされたファイアウォールまたは侵入検出システムからのアラームを経験した可能性があります。トラフィックはおそらく、以下でさらに説明するいくつかのホストの1つから発生しているように見えました。
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]で指定されたアドレスブロックを個人使用のために使用しています。このようなアドレスの1つの例は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.
これらの住所の範囲は世界中の多くのサイトで使用されているため、個々の住所はそれぞれ局所的な重要性を持つことができます。たとえば、1つのサイトで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アドレス10.1.30.20は、DNS名20.30.1.10.in-addr.arpaに対応しています。
2. A DNS query is constructed for that name, requesting a DNS record of the type "PTR".
2. その名前のDNSクエリが作成され、タイプ「PTR」のDNSレコードが要求されます。
3. The DNS query is sent to a resolver.
3. 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 Prisoner.iana.org（192.175.48.1）
o BLACKHOLE-1.IANA.ORG (192.175.48.6)
o Blackhole-1.iana.org（192.175.48.6）
o BLACKHOLE-2.IANA.ORG (192.175.48.42)
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.
これらのサーバーのいずれかに送信されたリクエストにより、クライアントに返信されます。応答は通常、UDPデータグラムになりますが、TCPを介してリクエストを行うには完全に有効です。どちらの場合も、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.
o 最終的にAS112サーバーに向けられたリクエストは通常、アプリケーションによって自動的にトリガーされるため、ファイアウォールログのレビューは、長期間にわたって発生する多数のポリシー違反を示している場合があります。
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.
o AS112サーバーからの応答がファイアウォールによってブロックされている場合、ホストはしばしば再試行し、多くの場合、比較的高い頻度で再試行します。これにより、インバウンドトラフィックがサービス拒否（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にリストされている名前サーバーの1つから回答を受け取るサイトは、おそらくすぐに危険にさらされておらず、それらの回答に関連するトラフィックには、おそらく関係するサイトによる緊急行動は必要ありません。ただし、このドキュメントは、個々のサイトのセキュリティポリシーを決定することを目指すことはできません。また、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.
1. そもそもこれらのDNSリバースマッピングクエリを作成しないようにします。場合によっては、たとえば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. AS112サーバーへのDNSリバースマッピングクエリをブロックし、サイトとインターネット間のファイアウォールを使用してサイトを離れることができます。これは賢明であるように見えるかもしれませんが、そのような尺度は意図しない結果をもたらす可能性があります。たとえば、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名の名前はすべてdomain iana.orgの下に命名されています（セクション5を参照）。IANAは、インターネットの基本的なインフラストラクチャの多くの技術的側面の調整を担当する組織です。AS112 Project NameServersは、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.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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] Eabley、J。およびW. Maton、「AS112 NameServer Operations」、RFC 6304、2011年7月。
Authors' Addresses
著者のアドレス
Joe Abley ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 US
Joeabley Icann 4676 Admiralty Way、Suite 330 Marina Del Rey、CA 90292 US
Phone: +1 519 670 9327
EMail: joe.abley@icann.org
William F. Maton Sotomayor National Research Council of Canada 1200 Montreal Road Ottawa, ON K1A 0R6 Canada
ウィリアムF.マトンソトマヨールカナダ国立研究評議会1200モントリオールロードオタワ、K1A 0R6カナダ
Phone: +1 613 993 0880
EMail: wmaton@ryouko.imsb.nrc.ca