[要約] RFC 5358は、リフレクタ攻撃での逆引き名前サーバーの使用を防止するためのガイドラインです。その目的は、ネットワークのセキュリティを向上させ、リフレクタ攻撃のリスクを軽減することです。
Network Working Group J. Damas
Request for Comments: 5358 ISC
BCP: 140 F. Neves
Category: Best Current Practice Registro.br
October 2008
Preventing Use of Recursive Nameservers in Reflector Attacks
リフレクター攻撃での再帰名の使用を防ぐ
Status of This Memo
本文書の位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Abstract
概要
This document describes ways to prevent the use of default configured recursive nameservers as reflectors in Denial of Service (DoS) attacks. It provides recommended configuration as measures to mitigate the attack.
このドキュメントでは、デフォルトの設定された再帰名アーバーの使用を防止する方法について説明します。攻撃を軽減するための測定値として推奨される構成を提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 2
3. Problem Description . . . . . . . . . . . . . . . . . . . . . . 2
4. Recommended Configuration . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 6
Recently, DNS [RFC1034] has been named as a major factor in the generation of massive amounts of network traffic used in Denial of Service (DoS) attacks. These attacks, called reflector attacks, are not due to any particular flaw in the design of the DNS or its implementations, except that DNS relies heavily on UDP, the easy abuse of which is at the source of the problem. The attacks have preferentially used DNS due to common default configurations that allow for easy use of open recursive nameservers that make use of such a default configuration.
最近、DNS [RFC1034]は、サービス拒否（DOS）攻撃で使用される膨大な量のネットワークトラフィックの生成の主要な要因として指定されています。リフレクター攻撃と呼ばれるこれらの攻撃は、DNSがUDPに大きく依存していることを除いて、DNSの設計またはその実装の特定の欠陥によるものではありません。攻撃には、このようなデフォルトの構成を使用するオープンな再帰的な名前サーバーを簡単に使用できる一般的なデフォルト構成により、優先的にDNSが使用されています。
In addition, due to the small query-large response potential of the DNS system, it is easy to yield great amplification of the source traffic as reflected traffic towards the victims.
さらに、DNSシステムの小さなクエリと大規模な応答の可能性があるため、被害者への反射トラフィックとしてソーストラフィックを大きく増幅するのは簡単です。
DNS authoritative servers that do not provide recursion to clients can also be used as amplifiers; however, the amplification potential is greatly reduced when authoritative servers are used. It is also impractical to restrict access to authoritative servers to a subset of the Internet, since their normal operation relies on them being able to serve a wide audience; hence, the opportunities to mitigate the scale of an attack by modifying authoritative server configurations are limited. This document's recommendations are concerned with recursive nameservers only.
クライアントに再帰を提供しないDNS権威あるサーバーもアンプとして使用できます。ただし、権威あるサーバーを使用すると、増幅ポテンシャルが大幅に減少します。また、通常の操作が幅広い視聴者にサービスを提供できることに依存しているため、信頼できるサーバーへのアクセスをインターネットのサブセットに制限することは非現実的です。したがって、権威あるサーバーの構成を変更することにより、攻撃のスケールを軽減する機会は限られています。このドキュメントの推奨事項は、再帰的な名前サーバーのみに関係しています。
In this document we describe the characteristics of the attack and recommend DNS server configurations that specifically alleviate the problem described, while pointing to the only real solution: the wide-scale deployment of ingress filtering to prevent use of spoofed IP addresses [BCP38].
このドキュメントでは、攻撃の特性について説明し、説明した問題を特異的に軽減するDNSサーバー構成を推奨しますが、唯一の実際の解決策を指しています。スプーフィングされたIPアドレスの使用を防ぐためのイングレスフィルタリングの幅広い展開[BCP38]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
Because most DNS traffic is stateless by design, an attacker could start a DoS attack in the following way:
ほとんどのDNSトラフィックは設計によるステートレスであるため、攻撃者は次の方法でDOS攻撃を開始できます。
1. The attacker starts by configuring a record on any zone he has access to, normally with large RDATA and Time to Live (TTL).
1. 攻撃者は、アクセスできるゾーンでレコードを構成することから始めます。通常、大きなrdataとLive（TTL）を使用します。
2. Taking advantage of clients on non-BCP38 networks, the attacker then crafts a query using the source address of their target victim and sends it to an open recursive nameserver.
2. 非BCP38ネットワークのクライアントを利用して、攻撃者はターゲット被害者のソースアドレスを使用してクエリを作成し、オープンな再帰名サーバーに送信します。
3. Each open recursive nameserver proceeds with the resolution, caches the record, and finally sends it to the target. After this first lookup, access to the authoritative nameservers is normally no longer necessary. The record will remain cached at the open recursive nameserver for the duration of the TTL, even if it's deleted from the zone.
3. 各オープン再帰名サーバーは解像度を進行し、レコードをキャッシュし、最終的にターゲットに送信します。この最初の検索の後、信頼できる名前アーバーへのアクセスは通常必要ありません。レコードは、ゾーンから削除されていても、TTLの期間中、オープンな再帰名でキャッシュされたままになります。
4. Cleanup of the zone might, depending on the implementation used in the open recursive nameserver, afford a way to clean the cached record from the open recursive nameserver. This would possibly involve queries luring the open recursive nameserver to lookup information for the same name that is being used in the amplification.
4. ゾーンのクリーンアップは、オープンな再帰名サーバーで使用されている実装に応じて、オープン再帰名サーバーからキャッシュされたレコードをクリーンする方法を提供する可能性があります。これには、増幅で使用されているのと同じ名前の情報を検索するために、オープン再帰名を誘導するクエリが含まれる可能性があります。
Because the characteristics of the attack normally involve a low volume of packets amongst all the kinds of actors besides the victim, it's unlikely any one of them would notice their involvement based on traffic pattern changes.
攻撃の特性は通常、被害者以外のすべての種類の俳優の間で少量のパケットを含むため、トラフィックパターンの変化に基づいて彼らの関与に気付く可能性は低いです。
Taking advantage of an open recursive nameserver that supports EDNS0 [RFC2671], the amplification factor (response packet size / query packet size) could be around 80. With this amplification factor, a relatively small army of clients and open recursive nameservers could generate gigabits of traffic towards the victim.
EDNS0 [RFC2671]をサポートするオープンな再帰名サーバーを利用すると、増幅係数（応答パケットサイズ /クエリパケットサイズ）は約80です。被害者への交通。
With the increasing length of authoritative DNS responses derived from deployment of DNSSEC [RFC4033] and NAPTR resource records as used in ENUM services, authoritative servers will eventually be more useful as actors in this sort of amplification attack.
ENUMサービスで使用されるDNSSEC [RFC4033]およびNAPTRリソースレコードの展開に由来する権威あるDNS応答の長さが増加すると、権威あるサーバーは、この種の増幅攻撃のアクターとして最終的により有用になります。
Even if this amplification attack is only possible due to non-deployment of BCP38, it is easier to leverage because of historical reasons. When the Internet was a much closer-knit community, some nameserver implementations were made available with default configurations that, when used for recursive nameservers, made the server accessible to all hosts on the Internet.
この増幅攻撃がBCP38の非展開のためにのみ可能であっても、歴史的な理由により、活用が簡単になります。インターネットがはるかに緊密なコミュニティである場合、再帰的な名前サーバーに使用すると、インターネット上のすべてのホストがサーバーにアクセスできるようにするデフォルト構成で、一部の名前サーバーの実装が利用可能になりました。
For years this was a convenient and helpful configuration, enabling wider availability of services. As this document aims to make apparent, it is now much better to be conscious of one's own nameserver services and focus the delivery of services on the intended audience of those services -- be they a university campus, an enterprise, or an ISP's customers. The target audience also includes operators of small networks and private server managers who decide to operate nameservers with the aim of optimising their DNS service, as these are more likely to use default configurations as shipped by implementors.
何年もの間、これは便利で役立つ構成であり、サービスをより広く利用できるようにしました。このドキュメントは明らかなことを目的としているため、自分の名前サーバーサービスを意識し、大学のキャンパス、企業、ISPの顧客など、これらのサービスの対象視聴者にサービスの提供を集中させる方がはるかに優れています。ターゲットオーディエンスには、DNSサービスを最適化する目的で名前を操作することを決定する小さなネットワークとプライベートサーバーマネージャーのオペレーターも含まれます。これらは、実装者が出荷するデフォルト構成を使用する可能性が高いためです。
In this section we describe the Best Current Practice for operating recursive nameservers. Following these recommendations would reduce the chances of any given recursive nameserver being used for the generation of an amplification attack.
このセクションでは、再帰的な名前を操作するための最良の現在のプラクティスについて説明します。これらの推奨事項に従って、増幅攻撃の生成に使用される特定の再帰名サーバーの可能性を減らすことができます。
The generic recommendation to nameserver operators is to use the means provided by the implementation of choice to provide recursive name lookup service to only the intended clients. Client authorization can usually be done in several ways:
名前サーバーオペレーターへの一般的な推奨事項は、選択の実装によって提供される手段を使用して、意図したクライアントのみに再帰名検索サービスを提供することです。通常、クライアントの承認はいくつかの方法で行うことができます。
o IP address based authorization. Use the IP source address of the DNS queries and filter them through an Access Control List (ACL) to service only the intended clients. This is easily applied if the recursive nameserver's service area is a reasonably fixed IP address range that is protected against external address spoofing, usually the local network.
o IPアドレスベースの承認。DNSクエリのIPソースアドレスを使用し、アクセス制御リスト（ACL）を介してフィルタリングして、意図したクライアントのみにサービスを提供します。これは、再帰的な名前サーバーのサービスエリアが、通常ローカルネットワークである外部アドレススプーフィングから保護されている合理的に固定されたIPアドレス範囲である場合、簡単に適用されます。
o Incoming interface based selection. Use the incoming interface for the query as a discriminator to select which clients are to be served. This is of particular applicability for SOHO (Small Office, Home Office) devices, such as broadband routers that include embedded recursive nameservers.
o 着信インターフェイスベースの選択。クエリの入力インターフェイスを識別器として使用して、どのクライアントが提供されるかを選択します。これは、埋め込まれた再帰名サーバーを含むブロードバンドルーターなど、SOHO（小さなオフィス、ホームオフィス）デバイスに特に適用可能です。
o TSIG [RFC2845] or SIG(0) [RFC2931] signed queries to authenticate the clients. This is a less error prone method that allows server operators to provide service to clients who change IP address frequently (e.g., roaming clients). The current drawback of this method is that very few stub resolver implementations support TSIG or SIG(0) signing of outgoing queries. The effective use of this method implies, in most cases, running a local instance of a caching nameserver or forwarder that will be able to TSIG sign the queries and send them on to the recursive nameserver of choice.
o TSIG [RFC2845]またはSIG（0）[RFC2931]は、クライアントを認証するためにクエリに署名しました。これは、サーバーオペレーターがIPアドレスを頻繁に変更するクライアント（クライアントのローミングなど）にサービスを提供できるようにするエラーが発生しやすい方法ではありません。この方法の現在の欠点は、非常に少ないスタブリゾルバー実装が、発信クエリのTSIGまたはSIG（0）の署名をサポートすることです。この方法の効果的な使用は、ほとんどの場合、クエリに署名して選択した再帰名サーバーにTSIGを送信できるキャッシュアーバーまたはフォワーダーのローカルインスタンスを実行することを意味します。
o For mobile users, use a local caching nameserver running on the mobile device or use a Virtual Private Network to a trusted server.
o モバイルユーザーの場合、モバイルデバイスで実行されているローカルキャッシュ名前サーバーを使用するか、仮想プライベートネットワークを使用して信頼できるサーバーに使用します。
In nameservers that do not need to be providing recursive service, for instance servers that are meant to be authoritative only, turn recursion off completely. In general, it is a good idea to keep recursive and authoritative services separate as much as practical. This, of course, depends on local circumstances.
再帰サービスを提供する必要のない名前サーバー、たとえば権威あるもののみを意図したサーバーは、再帰を完全にオフにします。一般的に、再帰的で権威あるサービスを実用的なものと同じくらい分離することをお勧めします。もちろん、これは現地の状況に依存します。
Even with all these recommendations, network operators should consider deployment of ingress filtering [BCP38] in routers to prevent use of address spoofing as a viable course of action. In situations where more complex network setups are in place, "Ingress Filtering for Multihomed Network" [BCP84] maybe a useful additional reference.
これらすべての推奨事項があっても、ネットワークオペレーターは、実行可能なアクションコースとしてのアドレススプーフィングの使用を防ぐために、ルーターのイングレスフィルタリング[BCP38]の展開を検討する必要があります。より複雑なネットワークセットアップが整っている状況では、「マルチホームネットワークのイングレスフィルタリング」[BCP84]は、おそらく有用な追加参照です。
By default, nameservers SHOULD NOT offer recursive service to external networks.
デフォルトでは、名前サーバーは外部ネットワークに再帰サービスを提供すべきではありません。
This document does not create any new security issues for the DNS protocol, it deals with a weakness in implementations.
このドキュメントは、DNSプロトコルの新しいセキュリティ問題を作成するものではなく、実装の弱点を扱います。
Deployment of SIG(0) transaction security [RFC2931] should consider the caveats with SIG(0) computational expense as it uses public key cryptography rather than the symmetric keys used by TSIG [RFC2845]. In addition, the identification of the appropriate keys needs similar mechanisms as those for deploying TSIG or, alternatively, the use of DNSSEC [RFC4033] signatures (RRSIGs) over the KEY RRs if published in DNS. This will in turn require the appropriate management of DNSSEC trust anchors.
SIG（0）トランザクションセキュリティ[RFC2931]の展開は、TSIG [RFC2845]で使用される対称キーではなく、公開キー暗号化を使用するため、SIG（0）計算費用を備えた警告を考慮する必要があります。さらに、適切なキーの識別には、TSIGを展開するための同様のメカニズム、あるいはDNSで公開されている場合、キーRRS上のDNSSEC [RFC4033]シグネチャ（RRSIG）の使用と同様のメカニズムが必要です。これには、DNSSECトラストアンカーの適切な管理が必要になります。
The authors would like to acknowledge the helpful input and comments of Joe Abley, Olafur Gudmundsson, Pekka Savola, Andrew Sullivan, and Tim Polk.
著者は、ジョー・エイブリー、オラファー・グドムンドソン、ペッカ・サヴォラ、アンドリュー・サリバン、ティム・ポークの有益な意見とコメントを認めたいと思います。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671] Vixie、P。、「DNSの拡張メカニズム（EDNS0）」、RFC 2671、1999年8月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845] Vixie、P.、Gudmundsson、O.、Eastlake、D。、およびB. Wellington、「DNSのシークレットキートランザクション認証」、RFC 2845、2000年5月。
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s)", RFC 2931, September 2000.
[RFC2931] EastLake、D。、「DNSリクエストとトランザクション署名（SIG（0）s）」、RFC 2931、2000年9月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの紹介と要件」、RFC 4033、2005年3月。
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[BCP38] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[BCP84] Baker、F。およびP. Savola、「マルチホームネットワークのイングレスフィルタリング」、BCP 84、RFC 3704、2004年3月。
Authors' Addresses
著者のアドレス
Joao Damas Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 US
Joao Damas Internet Systems Consortium、Inc。950 Charter Street Redwood City、CA 94063 US
Phone: +1 650 423 1300
EMail: Joao_Damas@isc.org
URI: http://www.isc.org/
Frederico A. C. Neves NIC.br / Registro.br Av. das Nacoes Unidas, 11541, 7 Sao Paulo, SP 04578-000 BR
Frederico A. C. Neves nic.br / Registro.br av。Das Nacoes Unidas、11541、7 Sao Paulo、SP 04578-000 BR
Phone: +55 11 5509 3511
EMail: fneves@registro.br
URI: http://registro.br/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。