[要約] RFC 4732は、インターネットのサービス拒否攻撃に関する考慮事項をまとめたものです。このRFCの目的は、サービス拒否攻撃の理解と対策のためのガイドラインを提供することです。
Network Working Group M. Handley, Ed.
Request for Comments: 4732 UCL
Category: Informational E. Rescorla, Ed.
Network Resonance
Internet Architecture Board
IAB
November 2006
Internet Denial-of-Service Considerations
インターネットの拒否に関する考慮事項
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
Abstract
概要
This document provides an overview of possible avenues for denial-of-service (DoS) attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities.
このドキュメントは、インターネットシステムに対するサービス拒否（DOS）攻撃の可能性のある手段の概要を提供します。目的は、プロトコル設計者とネットワークエンジニアをより堅牢なデザインに向けて奨励することです。攻撃の有効性を低下させる部分的なソリューションと、一部のソリューションがどのように誤って代替脆弱性を開くかについて説明します。
Table of Contents
目次
1. Introduction ....................................................3
2. An Overview of Denial-of-Service Threats ........................4
2.1. DoS Attacks on End-Systems .................................4
2.1.1. Exploiting Poor Software Quality ....................4
2.1.2. Application Resource Exhaustion .....................5
2.1.3. Operating System Resource Exhaustion ................6
2.1.4. Triggered Lockouts and Quota Exhaustion .............7
2.2. DoS Attacks on Routers .....................................8
2.2.1. Attacks on Routers through Routing Protocols ........8
2.2.2. IP Multicast-based DoS Attacks ......................9
2.2.3. Attacks on Router Forwarding Engines ...............10
2.3. Attacks on Ongoing Communications .........................11
2.4. Attacks Using the Victim's Own Resources ..................12
2.5. DoS Attacks on Local Hosts or Infrastructure ..............12
2.6. DoS Attacks on Sites through DNS ..........................15
2.7. DoS Attacks on Links ......................................16
2.8. DoS Attacks on Firewalls ..................................17
2.9. DoS Attacks on IDS Systems ................................18
2.10. DoS Attacks on or via NTP ................................18
2.11. Physical DoS .............................................18
2.12. Social Engineering DoS ...................................19
2.13. Legal DoS ................................................19
2.14. Spam and Black-Hole Lists ................................19
3. Attack Amplifiers ..............................................20
3.1. Methods of Attack Amplification ...........................20
3.2. Strategies to Mitigate Attack Amplification ...............22
4. DoS Mitigation Strategies ......................................22
4.1. Protocol Design ...........................................23
4.1.1. Don't Hold State for Unverified Hosts ..............23
4.1.2. Make It Hard to Simulate a Legitimate User .........23
4.1.3. Graceful Routing Degradation .......................24
4.1.4. Autoconfiguration and Authentication ...............24
4.2. Network Design and Configuration ..........................25
4.2.1. Redundancy and Distributed Service .................25
4.2.2. Authenticate Routing Adjacencies ...................25
4.2.3. Isolate Router-to-Router Traffic ...................26
4.3. Router Implementation Issues ..............................26
4.3.1. Checking Protocol Syntax and Semantics .............26
4.3.2. Consistency Checks .................................27
4.3.3. Enhance Router Robustness through
Operational Adjustments ............................28
4.3.4. Proper Handling of Router Resource Exhaustion ......28
4.4. End-System Implementation Issues ..........................29
4.4.1. State Lookup Complexity ............................29
4.4.2. Operational Issues .................................30
5. Conclusions ....................................................30
6. Security Considerations ........................................31
7. Acknowledgements ...............................................31
8. Normative References ...........................................31
9. Informative References .........................................32
Appendix A. IAB Members at the Time of This Writing ...............36
A Denial-of-Service (DoS) attack is an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work. The victim can be a network server, client or router, a network link or an entire network, an individual Internet user or a company doing business using the Internet, an Internet Service Provider (ISP), country, or any combination of or variant on these. Denial-of-service attacks may involve gaining unauthorized access to network or computing resources, but for the most part in this document we focus on the cases where the denial-of-service attack itself does not involve a compromise of the victim's computing facilities.
サービス拒否（DOS）攻撃は、1つ以上のマシンが被害者を標的とし、被害者が有用な仕事をしないようにしようとする攻撃です。被害者は、ネットワークサーバー、クライアントまたはルーター、ネットワークリンクまたはネットワーク全体、個々のインターネットユーザーまたはインターネットを使用してビジネスを行っている企業、インターネットサービスプロバイダー（ISP）、国、または任意の組み合わせまたはバリアントの組み合わせです。これらは。サービス拒否攻撃には、ネットワークまたはコンピューティングリソースへの不正アクセスを獲得することが含まれますが、このドキュメントのほとんどの場合、サービス拒否攻撃自体が被害者のコンピューティング施設の妥協を伴わない場合に焦点を当てます。
Because of the closed context of the original ARPANET and NSFNet, no consideration was given to denial-of-service attacks in the original Internet Architecture. As a result, almost all Internet services are vulnerable to denial-of-service attacks of sufficient scale. In most cases, sufficient scale can be achieved by compromising enough end-hosts (typically using a virus or worm) or routers, and using those compromised hosts to perpetrate the attack. Such an attack is known as a Distributed Denial-of-Service (DDoS) attack. However, there are also many cases where a single well-connected end-system can perpetrate a successful DoS attack.
元のArpanetとNSFNETの閉鎖コンテキストのため、元のインターネットアーキテクチャでのサービス拒否攻撃については考慮されませんでした。その結果、ほとんどすべてのインターネットサービスは、十分な規模のサービス拒否攻撃に対して脆弱です。ほとんどの場合、十分なエンドホスト（通常はウイルスまたはワームを使用する）またはルーターを妥協し、それらの侵害されたホストを使用して攻撃を実行することにより、十分なスケールを達成できます。このような攻撃は、分散されたサービス拒否（DDOS）攻撃として知られています。ただし、単一の適切に接続された最終システムが成功したDOS攻撃を実行できる場合も多くあります。
This document is intended to serve several purposes:
このドキュメントは、いくつかの目的を果たすことを目的としています。
o To highlight possible avenues for attack, and by so doing encourage protocol designers and network engineers towards designs that are more robust.
o 攻撃の可能性のある道を強調し、そうすることで、プロトコルデザイナーとネットワークエンジニアをより堅牢なデザインに向けて奨励します。
o To discuss partial solutions that reduce the effectiveness of attacks.
o 攻撃の有効性を低下させる部分的なソリューションを議論する。
o To highlight how some partial solutions can be taken advantage of by attackers to perpetrate alternative attacks.
o 攻撃者が代替攻撃を実行するために、一部の部分的なソリューションをどのように利用できるかを強調するため。
This last point appears to be a recurrent theme in DoS, and highlights the lack of proper architectural solutions. It is our hope that this document will help initiate informed debate about future architectural solutions that might be feasible and cost-effective for deployment.
この最後のポイントは、DOSの繰り返しのテーマであるように見え、適切な建築ソリューションの欠如を強調しています。この文書が、展開に実現可能で費用対効果の高い将来の建築ソリューションについての情報に基づいた議論を開始するのに役立つことを願っています。
In addition, it is our hope that this document will spur discussion leading to architectural solutions that reduce the susceptibility of all Internet systems to denial-of-service attacks.
さらに、この文書が、すべてのインターネットシステムのサービス拒否攻撃に対する感受性を低下させる建築ソリューションにつながる議論を促進することを期待しています。
We note that in principle it is not possible to distinguish between a sufficiently subtle DoS attack and a flash crowd (where unexpected heavy but non-malicious traffic has the same effect as a DoS attack). Whilst this is true, such malicious attacks are usually more expensive to launch than many of the crude attacks that have been seen to date. Thus, defending against DoS is not about preventing all possible attacks, but rather is largely a question of raising the bar sufficiently high for malicious traffic.
原則として、十分に微妙なDOS攻撃とフラッシュ群衆を区別することはできないことに注意してください（予期しない重いが非悪質なトラフィックがDOS攻撃と同じ効果がある場合）。これは真実ですが、このような悪意のある攻撃は通常、これまで見られてきた多くの粗攻撃よりも発売するのに高価です。したがって、DOSに対する防御は、可能なすべての攻撃を防ぐことではなく、悪意のあるトラフィックのためにバーを十分に高くするという問題です。
However, it is also important to note that not all DoS problems are malicious. Failed links, flash crowds, misconfigured bots, and numerous other causes can result in resource exhaustion problems, and so the overall goal should be to be robust to all forms of overload.
ただし、すべてのDOSの問題が悪意があるわけではないことに注意することも重要です。失敗したリンク、フラッシュクラウド、誤解されたボット、およびその他の多くの原因により、リソースの疲労問題が発生する可能性があるため、全体的な目標はあらゆる形態の過負荷に堅牢である必要があります。
In this section, we will discuss a wide range of possible DoS attacks. This list cannot be exhaustive, but the intent is to provide a good overview of the spectrum of possibilities that need to be defended against.
このセクションでは、幅広いDOS攻撃について説明します。このリストは網羅的なものではありませんが、意図は、防御する必要がある可能性のスペクトルの適切な概要を提供することです。
We do not provide descriptions of any attacks that are not already publicly well documented.
まだ公開されていない攻撃の説明は提供していません。
We first discuss attacks on end-systems. An end-system in this context is typically a PC or network server, but it can also include any communication endpoint. For example, a router also is an end-system from the point of view of terminating TCP connections for BGP [10] or ssh [46].
最初に、エンドシステムに対する攻撃について説明します。このコンテキストでの最終システムは、通常、PCまたはネットワークサーバーですが、通信エンドポイントも含めることができます。たとえば、ルーターは、BGP [10]またはSSH [46]のTCP接続を終了するという観点からの最終システムでもあります。
The simplest DoS attacks on end-systems exploit poor software quality on the end-systems themselves, and cause that software to simply crash. For example, buffer-overflow attacks might be used to compromise the end-system, but even if the buffer-overflow cannot be used to gain access, it will usually be possible to overwrite memory and cause the software to crash. Such vulnerabilities can in principle affect any software that uses data supplied from the network. Thus, not only might a web server be potentially vulnerable, but it might also be possible to crash the back-end software (such as a database) to which a web server provides data.
最終システムに対する最も単純なDOS攻撃は、最終システム自体のソフトウェアの品質の低さを活用し、そのソフトウェアに単純にクラッシュさせます。たとえば、バッファーオーバーフロー攻撃を使用して最終システムを妥協する場合がありますが、バッファーオーバーフローを使用してアクセスを得ることができなくても、通常、メモリを上書きしてソフトウェアをクラッシュさせることができます。このような脆弱性は、原則として、ネットワークから提供されたデータを使用するソフトウェアに影響を与える可能性があります。したがって、Webサーバーが潜在的に脆弱であるだけでなく、Webサーバーがデータを提供するバックエンドソフトウェア（データベースなど）をクラッシュさせることも可能かもしれません。
Software crashes due to poor coding affect not only application software, but also the operating system kernel itself. A classic example is the so-called "ping of death", which became widely known in 1996 [21]. This exploit caused many popular operating systems to crash when sent a single fragmented ICMP echo request packet whose fragments totaled more than the 65535 bytes allowed in an IPv4 packet.
コーディングが不十分なためソフトウェアがクラッシュし、アプリケーションソフトウェアだけでなく、オペレーティングシステムのカーネル自体にも影響します。典型的な例は、いわゆる「死のping」であり、1996年に広く知られるようになりました[21]。このエクスプロイトにより、IPv4パケットで許可された65535バイトを超えるフラグメントが合計である単一の断片化されたICMPエコーリクエストパケットを送信すると、多くの一般的なオペレーティングシステムがクラッシュしました。
While DoS attacks such as the ping of death are a significant problem, they are not a significant architectural problem. Once such an attack is discovered, the relevant code can easily be patched, and the problem goes away. We should note though that as more and more software becomes embedded, it is important not to lose the possibility of upgrading the software in such systems.
死のpingなどのDOS攻撃は重大な問題ですが、重大な建築上の問題ではありません。そのような攻撃が発見されると、関連するコードに簡単にパッチを適用でき、問題はなくなります。ただし、ますます多くのソフトウェアが組み込まれるにつれて、そのようなシステムでソフトウェアをアップグレードする可能性を失わないことが重要であることに注意する必要があります。
Network applications exist in a context that has finite resources. In processing network traffic, such an application uses these resources to do its intended task. However, an attacker may be able to prevent the application from performing its intended task by causing the application to exhaust the finite supply of a specific resource.
ネットワークアプリケーションは、有限リソースを持つコンテキストに存在します。ネットワークトラフィックの処理では、このようなアプリケーションはこれらのリソースを使用して、意図したタスクを実行します。ただし、攻撃者は、アプリケーションが特定のリソースの有限供給を排出することにより、アプリケーションが意図したタスクを実行するのを防ぐことができる場合があります。
The obvious resources that might be exhausted include:
使い果たされる可能性のある明らかなリソースは次のとおりです。
o Available memory.
o 使用可能なメモリ。
o The CPU cycles available.
o 利用可能なCPUサイクル。
o The disk space available to the application.
o アプリケーションで利用可能なディスクスペース。
o The number of processes or threads or both that the application is permitted to use.
o アプリケーションが使用できるプロセスまたはスレッドの数、またはその両方。
o The configured maximum number of simultaneous connections the application is permitted.
o アプリケーションが許可されている構成された最大数の同時接続。
This list is clearly not exhaustive, but it illustrates a number of points.
このリストは明らかに網羅的ではありませんが、多くのポイントを示しています。
Some resources are self-renewing: CPU cycles fall in this category -- if the attack ceases, more CPU cycles become available.
一部のリソースは自己再生です。CPUサイクルはこのカテゴリに分類されます。攻撃が停止すると、より多くのCPUサイクルが利用可能になります。
Some resources such as disk space require an explicit action to free up -- if the application cannot do this automatically then the effects of the attack may be persistent after the attack has ceased.
ディスクスペースなどの一部のリソースは、解放するために明示的なアクションを必要とします。アプリケーションが自動的にこれを実行できない場合、攻撃の影響は停止した後も持続する可能性があります。
This problem has been understood for many years, and it is common practice for logs and incoming email to be stored in a separate disk partition (/var on Unix systems) in order to limit the impact of exhaustion.
この問題は長年にわたって理解されており、疲労の影響を制限するために、ログと着信電子メールを別のディスクパーティション（UNIXシステムの/var）に保存することが一般的な慣行です。
Some resources are constrained by configuration: the maximum number of processes and the maximum number of simultaneous connections are not normally hard limits, but rather are configured limits. The purpose of such limits is clearly to allow the machine to perform other tasks in the event the application misbehaves. However, great care needs to be taken to choose such limits appropriately. For example, if a machine's sole task is to be an FTP server, then setting the maximum number of simultaneous connections to be significantly less than the machine can service makes the attacker's job easier. But setting the limit too high may permit the attacker to cause the machine to crash (due to poor OS design in handling resource exhaustion) or permit livelock (see below), which are generally even less desirable failure modes.
一部のリソースは構成によって制約されます。プロセスの最大数と同時接続の最大数は通常、厳しい制限ではなく、構成された制限です。このような制限の目的は、アプリケーションが不正行為をした場合に、マシンが他のタスクを実行できるようにすることです。ただし、そのような制限を適切に選択するには、細心の注意が必要です。たとえば、マシンの唯一のタスクがFTPサーバーになる場合、最大数の同時接続数をマシンがサービスを提供できるよりも大幅に低く設定すると、攻撃者のジョブが容易になります。しかし、制限を高く設定しすぎると、攻撃者がマシンのクラッシュを引き起こす可能性があります（リソースの疲労の処理においてOSの設計が不十分であるため）またはLivelockを許可します（以下を参照）。
Conceptually, OS resource exhaustion and application resource exhaustion are very similar. However, in the case of application resource exhaustion, the operating system may be able to protect other tasks from being affected by the DoS attack. In the case of the operating system itself running out of resources, the problem may be more catastrophic.
概念的には、OSリソースの使い果たしとアプリケーションリソースの疲労は非常に似ています。ただし、アプリケーションリソースの使い果たしの場合、オペレーティングシステムは、他のタスクをDOS攻撃の影響を受けないように保護できる場合があります。オペレーティングシステム自体がリソースが不足している場合、問題はより壊滅的なものになる可能性があります。
Perhaps the best-known DoS attack on an operating system is the TCP SYN-flood [19], which is essentially a memory-exhaustion attack. The attacker sends a flood of TCP SYN packets to the victim, requesting connection setup, but then does not complete the connection setup. The victim instantiates state to handle the incoming connections. If the attacker can instantiate state faster than the victim times it out, then the victim will run out of memory that it can use to hold TCP state, and so it cannot service legitimate TCP connection setup attempts. This issue was exacerbated in some implementations by the use of a small dedicated storage space for half-open connections, which made the attack easier than it might otherwise have been. In the case of a poorly coded operating system, running out of resources may also cause a system crash.
おそらく、オペレーティングシステムに対する最もよく知られているDOS攻撃は、TCP syn-flood [19]であり、これは本質的にメモリ排除攻撃です。攻撃者は、TCP synパケットの洪水を被害者に送信し、接続のセットアップを要求しますが、接続セットアップは完了しません。被害者は、入ってくる接続を処理するために状態をインスタンス化します。攻撃者が被害者がそれを獲得するよりも速く状態をインスタンス化できる場合、被害者はTCP状態を保持するために使用できる記憶を使い果たし、合法的なTCP接続のセットアップの試みにサービスを提供できません。この問題は、半分のオープン接続のために小さな専用ストレージスペースを使用することにより、いくつかの実装で悪化しました。コード化されていないオペレーティングシステムの場合、リソースが不足している場合も、システムがクラッシュする可能性があります。
An alternative TCP DoS attack is the Ack-flood [23], which is essentially a CPU exhaustion attack on the victim. The attacker floods the victim with TCP packets pretending to be from connections that have never been established. A busy server that has a large number of outstanding connections needs to check which connection the packet corresponds to. Some TCP implementations implemented this search rather inefficiently, and so the attacker could use all the victim's CPU resources servicing these packets rather than servicing legitimate requests.
別のTCP DOS攻撃はACK-flood [23]であり、これは本質的に被害者に対するCPU疲労攻撃です。攻撃者は、確立されたことのない接続からのふりをするTCPパケットで被害者に殺到します。パケットが対応する接続を確認するには、多数の未解決の接続があるビジーサーバーが必要です。一部のTCP実装は、この検索をかなり非効率的に実装したため、攻撃者は合法的なリクエストにサービスを提供するのではなく、これらのパケットにサービスを提供するすべての被害者のCPUリソースを使用できます。
We note that strong authentication mechanisms do not necessarily mitigate against such CPU exhaustion attacks. In fact, poorly designed authentication mechanisms using cryptographic methods can exacerbate the problem. If such an authentication mechanism allows an attacker to present a packet to the victim that requires relatively expensive cryptographic authentication before the packet can be discarded, then this makes the attacker's CPU exhaustion attack easier.
強力な認証メカニズムは、そのようなCPU疲労攻撃に対して必ずしも軽減しないことに注意してください。実際、暗号化方法を使用した不十分に設計された認証メカニズムは、問題を悪化させる可能性があります。このような認証メカニズムにより、攻撃者がパケットを破棄する前に比較的高価な暗号認証を必要とするパケットを被害者に提示することができる場合、これにより攻撃者のCPU疲労攻撃が容易になります。
CPU exhaustion attacks can be also be exacerbated by poor OS handling of incoming network traffic. In the absence of malicious traffic, an ideal OS should behave as follows:
CPU排出攻撃は、着信ネットワークトラフィックの障害の低いOSの取り扱いによっても悪化する可能性があります。悪意のあるトラフィックがない場合、理想的なOSは次のように動作する必要があります。
o As incoming traffic increases, the useful work done by the OS should increase until some resource (such as the CPU) is saturated.
o 着信トラフィックが増加すると、OSによって行われる有用な作業は、ある程度のリソース（CPUなど）が飽和するまで増加するはずです。
o From this point on, as incoming traffic continues to increase the useful work done should be constant.
o この時点から、入ってくるトラフィックが増加し続けているため、行われた有用な作業は一定でなければなりません。
However, this is often not the case. Many systems suffer from livelock [33] where, after saturation, increasing the load causes a decrease in the useful work done. One cause of this is that the system spends an increasing amount of time processing network interrupts for packets that will never be processed, and hence a decreasing amount of time is available for the application for which these packets were intended.
ただし、これはしばしばそうではありません。多くのシステムは、飽和後、負荷を増やすと、行われた有用な作業が減少するため、Livelock [33]に苦しんでいます。この原因の1つは、システムが、処理されないパケットのネットワーク割り込みを処理する時間をますます費やすため、これらのパケットが意図されていたアプリケーションには、時間を短縮する時間を利用できます。
Many user-authentication mechanisms attempt to protect against password guessing attacks by locking the user out after a small number of failed authentications. If an attacker can guess or discover a user's ID, they may be able to trigger such a mechanism, locking out the legitimate user.
多くのユーザー認証メカニズムは、少数の失敗した認証の後にユーザーをロックアウトすることにより、パスワード推測攻撃から保護しようとします。攻撃者がユーザーのIDを推測または発見できる場合、そのようなメカニズムをトリガーして、正当なユーザーをロックできる場合があります。
Another way to deny service using protection mechanisms is to cause a quota to be exhausted. This is perhaps most common in the case of small web servers being commercially hosted, where the server has a contract with the hosting company allowing a fixed amount of traffic per day. An attacker may be able to rapidly exhaust this quota, and cause service to be suspended. Similar attacks may be possible against other forms of quota.
保護メカニズムを使用してサービスを拒否する別の方法は、クォータを使い果たすことです。これはおそらく、小さなWebサーバーが商業的にホストされている場合に最も一般的であり、サーバーはホスティング会社と契約を結んでおり、1日あたりの一定量のトラフィックを許可しています。攻撃者はこのクォータを迅速に使い果たし、サービスを一時停止することができます。他の形式のクォータに対して同様の攻撃が可能になる場合があります。
In the absence of such quotas, if the victim is charged for their network traffic, a financial denial-of-service may be possible.
このようなクォータがない場合、被害者がネットワークトラフィックに対して請求された場合、財政的なサービスの拒否が可能になる場合があります。
Many of the denial-of-service attacks that can be launched against end-systems can also be launched against the control processor of an IP router, for example, by flooding the command and control access ports. In the case of a router, these attacks may cause the router to stall, or may cause the router to cease processing routing packets. Even if the router does not stop servicing routing packets, it may become sufficiently slow that routing protocols time out. In any of these circumstances, the consequence of routing failure is not only that the router ceases to forward traffic, but also that it causes routing protocol churn that may have further side effects.
エンドシステムに対して起動できるサービス拒否攻撃の多くは、たとえば、コマンドおよび制御アクセスポートに浸水するなど、IPルーターの制御プロセッサに対して起動することもできます。ルーターの場合、これらの攻撃により、ルーターが失速するか、ルーターが処理ルーティングパケットを停止する可能性があります。ルーターがルーティングパケットのサービスを停止しなくても、ルーティングプロトコルがタイムアウトするほど十分に遅くなる可能性があります。これらの状況のいずれにおいても、ルーティングの障害の結果は、ルーターがトラフィックを転送するのをやめることだけでなく、さらに副作用がある可能性のあるルーティングプロトコルチャーンを引き起こすことでもあります。
An example of such a side effect is caused by BGP route flap damping [11], which is intended to reduce global routing churn. If an attacker can cause BGP routing churn, route flap damping may then cause the flapping routes to be suppressed [31]. This suppression likely causes the networks served by those routes to become unreachable.
このような副作用の例は、グローバルルーティングの解約を削減することを目的としたBGPルートフラップダンピング[11]によって引き起こされます。攻撃者がBGPルーティングチャーンを引き起こす可能性がある場合、ルートフラップダンピングにより、フラッピングルートが抑制される可能性があります[31]。この抑制により、これらのルートが提供するネットワークが到達不能になる可能性があります。
A DoS attack on the router control processor might also prevent the router from being managed effectively. This may prevent actions being taken that would mitigate the DoS attack, and it might prevent diagnosis of the cause of the problem.
ルーター制御プロセッサに対するDOS攻撃は、ルーターが効果的に管理されるのを防ぐこともできます。これにより、DOS攻撃を軽減するアクションが妨げられ、問題の原因の診断を防ぐ可能性があります。
In addition to their roles as end-systems, most routers run dynamic routing protocols. The routing protocols themselves can be used to stage a DoS attack on a router or a network of routers. This requires the ability to send traffic from addresses that might plausibly have generated the relevant routing messages, which is somewhat difficult with interior routing protocols but fairly easy with External Border Gateway Protocol (eBGP), for instance.
エンドシステムとしての役割に加えて、ほとんどのルーターは動的ルーティングプロトコルを実行します。ルーティングプロトコル自体を使用して、ルーターまたはルーターのネットワークに対するDOS攻撃をステージングできます。これには、関連するルーティングメッセージをもっともらしく生成する可能性のあるアドレスからトラフィックを送信する機能が必要です。これは、インテリアルーティングプロトコルではやや難しいが、外部のボーダーゲートウェイプロトコル（EBGP）ではかなり簡単です。
The simplest attack on a network of routers is to overload the routing table with sufficiently many routes that the router runs out of memory, or the router has insufficient CPU power to process the routes [26]. We note that depending on the distribution and capacities of various routers around the network, such an attack might not overwhelm routers near to the attacking router, but might cause problems to show up elsewhere in the network.
ルーターのネットワークに対する最も単純な攻撃は、ルーターがメモリから走る十分に多くのルートでルーティングテーブルを過負荷するか、ルーターがルートを処理するためにCPUパワーが不十分であることです[26]。ネットワーク周辺のさまざまなルーターの分布と容量に応じて、このような攻撃は攻撃ルーターの近くにルーターを圧倒しない可能性がありますが、ネットワーク内の他の場所に問題が現れる可能性があることに注意してください。
Some routing protocol implementations allow limits to be configured on the maximum number of routes to be heard from a neighbor [27].
一部のルーティングプロトコルの実装により、隣人から聞くルートの最大数で制限を構成することができます[27]。
However, limits often make the problem worse rather than better, by making it possible for the attacker to push out legitimate routes with spoofed routes, thus creating an easy form of DoS attack.
ただし、攻撃者がスプーフィングされたルートで合法的なルートを押し出し、DOS攻撃の簡単な形を作成することを可能にすることにより、制限は多くの場合、問題を改善するよりも悪化させます。
An alternative attack is to overload the routers on the network by creating sufficient routing table churn that routers are unable to process the changes. Many routing protocols allow damping factors to be configured to avoid just such a problem. However, as with table size, such a threshold applied inconsistently may allow the spoofed routes to merge with legitimate routes before the mechanism is applied, causing legitimate routes to be damped.
別の攻撃は、ルーターが変更を処理できないほど十分なルーティングテーブルチャーンを作成することにより、ネットワーク上のルーターをオーバーロードすることです。多くのルーティングプロトコルにより、このような問題を回避するために、減衰係数を構成します。ただし、テーブルサイズと同様に、そのようなしきい値が一貫して適用されない場合、メカニズムが適用される前に、スプーフィングされたルートが正当なルートとマージされ、合法的なルートが減衰される可能性があります。
The simplest routing attack on a specific destination is for an attacker to announce a spoofed desirable route to that destination. Such a route might be desirable because it has low metric, or because it is a more specific route than the legitimate route. In any event, if the route is believed, it will cause traffic for the victim to be drawn towards the attacking router, where it will typically be discarded.
特定の目的地に対する最も単純なルーティング攻撃は、攻撃者がその目的地へのスプーフィングされた望ましいルートを発表することです。このようなルートは、メトリックが低いため、または正当なルートよりも具体的なルートであるため、望ましい場合があります。いずれにせよ、ルートが信じられている場合、被害者が攻撃ルーターに引き寄せられ、通常は廃棄されます。
A more subtle denial-of-service attack might be launched against a network rather than against a destination. Under some circumstances, the propagation of inconsistent routing information can cause traffic to loop. If an attacker can cause this to happen on a busy path, the looping traffic might cause significant congestion, as well as fail to reach the legitimate destination.
より微妙なサービス拒否攻撃は、目的地に対してではなく、ネットワークに対して開始される場合があります。状況によっては、一貫性のないルーティング情報の伝播により、トラフィックがループする可能性があります。攻撃者がこれを忙しい経路で発生させることができる場合、ループするトラフィックはかなりの渋滞を引き起こし、正当な目的地に到達できない可能性があります。
In the past, there have been cases where different generations of routers interpreted a routing protocol specification differently. In particular, BGP specifies that in the case of an error, the BGP peering should be dropped. However, if some of the routers in a network treat a particular route as valid and other routers treat the route as invalid, then it may be possible to inject a BGP route at one point in the Internet and cause peerings to be dropped at many other places in the Internet. Unlike many of the examples above, while such an issue might be a serious short-term problem, this is not a fundamental architectural problem. Once the problem is understood, deploying patched routing code can permanently solve the issue.
過去には、異なる世代のルーターがルーティングプロトコルの仕様を異なる方法で解釈した場合がありました。特に、BGPは、エラーの場合、BGPピアリングを削除する必要があることを指定します。ただし、ネットワーク内の一部のルーターが特定のルートを有効なルートとして処理し、他のルーターを他のルーターがルートを無効として扱う場合、インターネットのある時点でBGPルートを注入し、他の多くの場合にピーリングをドロップすることができる場合がありますインターネット内の場所。上記の例の多くとは異なり、そのような問題は深刻な短期的な問題かもしれませんが、これは基本的な建築上の問題ではありません。問題が理解されると、パッチされたルーティングコードを展開すると、問題を永久に解決できます。
There are essentially two forms of IP multicast: traditional Any-Source Multicast (ASM), as specified in RFC 1112 [4] where multiple sources can send to the same multicast group, and Source-Specific Multicast (SSM) where the receiver must specify both the IP source address and the group address. The two forms of multicast provide rather different DoS possibilities.
IPマルチキャストには、基本的に2つの形式があります。複数のソースが同じマルチキャストグループに送信できるRFC 1112 [4]で指定されている従来の任意のソースマルチキャスト（ASM）と、受信者が指定する必要があるソース固有のマルチキャスト（SSM）があります。IPソースアドレスとグループアドレスの両方。マルチキャストの2つの形式は、かなり異なるDOSの可能性を提供します。
ASM protocols such as PIM-SM [6], MSDP [32], and DVMRP [12] typically cause some routers to instantiate routing state at the time a packet is sent to a multicast group. They do this to ensure that the traffic goes to the group receivers and not to non-receivers. Such protocols are particularly vulnerable to DoS attacks, as an attacker that sends to many multicast groups may cause both multicast routing table explosion (and hence control processor memory exhaustion) and multicast forwarding table exhaustion (and hence forwarding card memory exhaustion or thrashing).
PIM-SM [6]、MSDP [32]、DVMRP [12]などのASMプロトコルは、通常、パケットがマルチキャストグループに送信されたときにルーティング状態をインスタンス化するために、いくつかのルーターを引き起こします。彼らはこれを行い、トラフィックがグループレシーバーにかけて、非受信者ではないことを保証します。このようなプロトコルは、多くのマルチキャストグループに送信する攻撃者がマルチキャストルーティングテーブルの爆発（したがって制御プロセッサメモリの疲労）とマルチキャスト転送テーブルの排出（したがって、カードメモリの消耗またはスラッシングを転送する）の両方を引き起こす可能性があるため、DOS攻撃に対して特に脆弱です。
ASM also permits an attacker to send traffic to the same group as legitimate traffic, potentially causing network congestion and denying service to the legitimate group.
ASMはまた、攻撃者が合法的なトラフィックと同じグループにトラフィックを送信することを許可し、ネットワークの輻輳を引き起こし、正当なグループへのサービスを拒否する可能性があります。
SSM does not permit senders to send to arbitrary groups unless a receiver has requested the traffic. Thus, sender-based attacks on multicast routing state are not possible with SSM. However, as with ASM, a receiver can still join a large number of multicast groups causing routers to hold a large amount of multicast routing state, potentially causing memory exhaustion and hence denial-of-service to legitimate traffic.
SSMは、受信者がトラフィックを要求していない限り、送信者が任意のグループに送信することを許可しません。したがって、SSMでは、マルチキャストルーティング状態に対する送信者ベースの攻撃は不可能です。ただし、ASMと同様に、受信者は、ルーターが大量のマルチキャストルーティング状態を保持する多数のマルチキャストグループに参加することができ、メモリの疲労を引き起こす可能性があり、したがって正当なトラフィックにサービスの拒否を引き起こす可能性があります。
With IPv6, hosts are required to send ICMP Packet Too Big or Parameter Problem messages under certain circumstances, even if the destination address is a multicast address. If the attacker can place himself in the appropriate position in the multicast tree, a packet with an unknown but mandatory Destination Option, for instance, could generate a very large number of responses to the claimed sender.
IPv6を使用すると、宛先アドレスがマルチキャストアドレスであっても、特定の状況下でICMPパケットまたはパラメーターの問題メッセージが大きすぎるか、パラメーターの問題メッセージを送信する必要があります。攻撃者がマルチキャストツリーの適切な位置に自分自身を置くことができる場合、たとえば、未知のが必須の宛先オプションを備えたパケットは、クレームされた送信者に対する非常に多くの応答を生成できます。
With IPv4, the same problem exists with multicast ICMP Echo Request packets, but these are somewhat easier to filter.
IPv4では、マルチキャストICMPエコーリクエストパケットでも同じ問題が存在しますが、これらはフィルタリングがやや簡単です。
The examples above should not be taken as exhaustive. These are actually specific cases of a general problem that can happen when a multicast/broadcast request solicits a reply from a large number of nodes.
上記の例は、網羅的なものと見なされるべきではありません。これらは、実際には、マルチキャスト/ブロードキャスト要求が多数のノードからの返信を求めるときに発生する可能性のある一般的な問題の特定のケースです。
Router vendors implement many different mechanisms for packet forwarding, but broadly speaking they fall into two categories: ones that use a forwarding cache, and ones that do not. With a forwarding cache, the forwarding engine does not hold the full routing table, but rather holds just the currently active subset of the forwarding table.
ルーターベンダーは、パケット転送にさまざまなメカニズムを実装していますが、大まかに言えば、転送キャッシュを使用するカテゴリとそうでないカテゴリの2つのカテゴリに分類されます。転送キャッシュを使用すると、転送エンジンは完全なルーティングテーブルを保持するのではなく、転送テーブルの現在アクティブなサブセットだけを保持します。
Many modern routers use a loosely coupled architecture, where one or more control processors handle the routing protocols and communicate over an internal network link to special-purpose forwarding engines, which actually forward the data traffic. In such architectures, it may be possible for an attacker to overwhelm the communications link between the control processor and the forwarding engine. This is possible because the forwarding engines support very high speed links, and the control processor simply cannot handle a similar rate of traffic.
多くの最新のルーターは、1つ以上の制御プロセッサがルーティングプロトコルを処理し、内部ネットワークリンクを介して、実際にデータトラフィックを転送する特別な目的の転送エンジンに通信し、ゆるく結合したアーキテクチャを使用しています。このようなアーキテクチャでは、攻撃者が制御プロセッサと転送エンジンの間の通信リンクを圧倒することが可能かもしれません。これは、転送エンジンが非常に高速リンクをサポートしており、制御プロセッサが同様のトラフィックレートを処理できないため、これは可能です。
There may be many ways in which an attacker can trigger communication between the forwarding engines and the control processor. The simplest way is for the attacker to simply send to the router's IP address, but this should in principle be relatively easy to prevent using filtering on the forwarding engines. Another way might be to cause the router to forward data packets using the "slow path". This involves sending packets that require special attention from the forwarding router; if the forwarding engine is not smart enough to perform such forwarding, then it will typically pass the packet to the control processor. In a router using a forwarding cache, it may be possible to overload the internal communications by thrashing the forwarding cache. Finally, any form of data-triggered communication between the forwarding engine and the control processor might cause such a problem. Certain multicast routing protocols including PIM-SM contain many such data triggered events that could potentially be problematic.
攻撃者が転送エンジンと制御プロセッサ間の通信をトリガーできる多くの方法があるかもしれません。最も簡単な方法は、攻撃者がルーターのIPアドレスに単純に送信することですが、これは原則として、転送エンジンでのフィルタリングの使用を防ぐのが比較的簡単である必要があります。別の方法は、「スローパス」を使用してルーターにデータパケットを転送させることです。これには、転送ルーターから特別な注意が必要なパケットを送信することが含まれます。転送エンジンがそのような転送を実行するほどスマートでない場合、通常、パケットを制御プロセッサに渡します。転送キャッシュを使用したルーターでは、転送キャッシュをスラッシングして内部通信を過負荷することが可能かもしれません。最後に、転送エンジンと制御プロセッサとの間のあらゆる形態のデータトリガー通信がそのような問題を引き起こす可能性があります。PIM-SMを含む特定のマルチキャストルーティングプロトコルには、問題が発生する可能性があるこのような多くのデータトリガーイベントが含まれています。
The effects of overloading such internal communications are hard to predict and are very implementation-dependent. One possible effect might be that the forwarding table in the forwarding engine gets out of synchronization with the routing table in the control processor that reflects what the routing protocols believe is happening. This might cause traffic to be dropped or to loop.
このような内部通信を過負荷にすることの効果は、予測が困難であり、非常に実装に依存しています。考えられる効果の1つは、転送エンジンの転送テーブルが、ルーティングプロトコルが起こっていると思われることを反映する制御プロセッサのルーティングテーブルと同期しないことです。これにより、トラフィックがドロップされるか、ループする可能性があります。
Finally, if an attacker can generate traffic that causes a router to auto-install access control list (ACL) entries, perhaps by triggering a response from an intrusion detection system, then it may be possible to exhaust the ACL resources on the router. This might prevent future attacks from being filtered, or worse, cause ACL processing to be handled by the route processor.
最後に、攻撃者がルーターがアクセス制御リスト（ACL）エントリを自動インストールする原因となるトラフィックを生成できる場合、おそらく侵入検知システムからの応答をトリガーすることにより、ルーターのACLリソースを使い果たすことができる場合があります。これにより、将来の攻撃がフィルタリングされるのを防ぐことができ、さらに悪いことに、ACL処理がルートプロセッサによって処理される可能性があります。
Instead of attacking the end-system itself, it is also possible for an attacker to disrupt ongoing communications. If an attacker can observe a TCP connection, then it is relatively easy for them to spoof packets to either reset that connection or to de-synchronize it so that no further progress can be made [29]. Such attacks are not prevented by transport or application-level security mechanisms such as TLS [5] or ssh, because the authentication takes place after TCP has finished processing the packets.
最終システム自体を攻撃する代わりに、攻撃者が進行中のコミュニケーションを混乱させることも可能です。攻撃者がTCP接続を観察できる場合、その接続をリセットするか、それ以上の進捗を行うことができないようにパケットをスプーフィングするか、それを非同期化することは比較的簡単です[29]。このような攻撃は、TCPがパケットの処理を終了した後に認証が行われるため、TLS [5]やSSHなどのアプリケーションレベルのセキュリティメカニズムによって防止されません。
If an attacker cannot observe a TCP connection, but can infer that such a connection exists, it is theoretically possible to reset or de-synchronize that connection by spoofing packets into the connection. However, this might require an excessively large number of spoofed packets to guess both the port of the active end of the TCP connection (in most cases, the port of the passive end is predictable) and the currently valid TCP sequence numbers. However, as some operating systems have poorly implemented predictable algorithms for selecting either the dynamically selected port or the TCP initial sequence number [41] [20], then such attacks have been found to be feasible [34]. Advice as to how to reduce the vulnerability in the specific case of TCP is available in [37].
攻撃者がTCP接続を観察できないが、そのような接続が存在すると推測できる場合、パケットを接続にスプーフィングすることにより、その接続をリセットまたは非同期化することが理論的に可能です。ただし、これには、TCP接続のアクティブエンドのポート（ほとんどの場合、パッシブエンドのポートが予測可能）と現在有効なTCPシーケンス番号の両方を推測するために、過度に多数のスプーフィングされたパケットが必要になる場合があります。ただし、一部のオペレーティングシステムでは、動的に選択されたポートまたはTCP初期シーケンス番号[41] [20]を選択するための予測可能なアルゴリズムが不十分に実装されているため、そのような攻撃は実行可能であることがわかりました[34]。TCPの特定の場合の脆弱性を減らす方法に関するアドバイスは、[37]で利用できます。
An attacker might be able to significantly reduce the throughput of a connection by sending spoofed ICMP source quench packets, although most modern operating systems should ignore such packets. However, care should be taken in the design of future transport and signaling protocols to avoid the introduction of similar mechanisms that could be exploited.
攻撃者は、スプーフィングされたICMPソースクエンチパケットを送信することにより、接続のスループットを大幅に減らすことができる場合がありますが、ほとんどの最新のオペレーティングシステムはそのようなパケットを無視する必要があります。ただし、悪用される可能性のある同様のメカニズムの導入を避けるために、将来の輸送およびシグナル伝達プロトコルの設計には注意が必要です。
Instead of directly overloading the victim, it may be possible to cause the victim or a machine on the same subnet as the victim to overload itself.
被害者に直接オーバーロードする代わりに、被害者と同じサブネットの被害者またはマシンにそれ自体を過負荷にすることが可能かもしれません。
An example of such an attack is documented in [18], where the attacker spoofs the source address on a packet sent to the victim's UDP echo port. The source address is that of another machine that is running a UDP chargen server (a chargen server sends a character pattern back to the originating source). The result is that the two machines bounce packets back and forth as fast as they can, overloading either the network between them or one of the end-systems itself.
このような攻撃の例は[18]に文書化されており、攻撃者は被害者のUDPエコーポートに送信されたパケットのソースアドレスをスプーフィングします。ソースアドレスは、UDP chargenサーバーを実行している別のマシンのアドレスです（chargenサーバーは、キャラクターパターンを元のソースに送り返します）。その結果、2つのマシンがパケットをできるだけ早く前後にバウンスし、それらの間のネットワークまたは最終システムの間のネットワークを過負荷にします。
There are a number of attacks that might only be performed by a local attacker.
地元の攻撃者によってのみ実行される可能性のある多くの攻撃があります。
An attacker with access to a subnet may be able to prevent other local hosts from accessing the network at all by simply exhausting the address pool allocated by a Dynamic Host Configuration Protocol (DHCP) server. This requires being able to spoof the MAC address of an ethernet or wireless card, but this is quite feasible with certain hardware and operating systems.
サブネットにアクセスできる攻撃者は、他のローカルホストがダイナミックホスト構成プロトコル（DHCP）サーバーによって割り当てられたアドレスプールを使い果たすだけで、ネットワークにアクセスするのを防ぐことができる場合があります。これには、イーサネットまたはワイヤレスカードのMACアドレスをスプーフィングできる必要がありますが、これは特定のハードウェアとオペレーティングシステムで非常に実現可能です。
An alternative DHCP-based attack is simply to respond faster than the legitimate DHCP server, and to give out an address that is not useful to the victim.
別のDHCPベースの攻撃は、単に正当なDHCPサーバーよりも速く応答することであり、被害者にとって有用ではない住所を提供することです。
These sorts of bootstrapping attacks tend to be difficult to avoid because most of the time trust relationships are established after IP communication has already been established.
これらの種類のブートストラップ攻撃は、IP通信がすでに確立された後にほとんどの時間信頼関係が確立されているため、回避するのが難しい傾向があります。
Similar attacks are possible through ARP spoofing [16]; an attacker can respond to ARP requests before the victim and prevent traffic from reaching the victim. Some brands of ethernet switch allow an even simpler attack: simply send from the victim's MAC address, and the switch will redirect traffic destined for the victim to the attacker's port. This attack might also potentially be used to block traffic from the victim by engaging screening or flap-dampening algorithms in the switch, depending on the switch design.
同様の攻撃は、ARPスプーフィング[16]によって可能です。攻撃者は、被害者の前にARPリクエストに応答し、トラフィックが被害者に届かないようにすることができます。一部のブランドのイーサネットスイッチは、さらに簡単な攻撃を可能にします。被害者のMACアドレスから送信するだけで、スイッチは攻撃者の港の被害者向けのトラフィックをリダイレクトします。また、この攻撃は、スイッチの設計に応じて、スイッチ内のスクリーニングまたはフラップ減衰アルゴリズムを関与させることにより、被害者からのトラフィックをブロックするために使用される可能性があります。
It may be possible to cause broadcast storms [16] on a local LAN by sending a stream of unicast IP packets to the broadcast MAC address. Some hosts on the LAN may then attempt to forward the packets to the correct MAC address, greatly amplifying the traffic on the LAN.
ユニキャストIPパケットのストリームをブロードキャストMACアドレスに送信することにより、ローカルLANにブロードキャストストーム[16]を引き起こす可能性があります。LANの一部のホストは、パケットを正しいMacアドレスに転送しようとする場合があり、LANのトラフィックを大幅に増幅します。
802.11 wireless networks provide many opportunities to deny service to other users. In some cases, the lack of defenses against DoS was a deliberate choice--because 802.11 operates on unlicensed spectrum it was assumed that there would be sources of interference and that producing intentional radio-level jamming would be trivial. Thus, the amount of DoS protection possible at higher levels was minimal.
802.11ワイヤレスネットワークは、他のユーザーへのサービスを拒否する多くの機会を提供します。場合によっては、DOSに対する防御の欠如は意図的な選択でした - 802.11が免許のないスペクトルで動作し、干渉の原因があり、意図的な無線レベルの詰まりが些細なことであると想定されていました。したがって、より高いレベルで可能なDOS保護の量は最小限でした。
Nevertheless, some of the weaknesses of the protocols against more sophisticated attacks are worth noting. The most prominent of these is that association is unprotected, thus allowing rogue access points (APs) to solicit notifications that would otherwise have gone to legitimate APs.
それにもかかわらず、より洗練された攻撃に対するプロトコルの弱点のいくつかは注目に値します。これらの中で最も顕著なのは、関連性が保護されていないため、不正なアクセスポイント（APS）が、そうでなければ合法的なAPに行った通知を求めることです。
The SSID field provides effectively no defense against this kind of attack. Unless encryption is enabled, it is trivial to announce the presence of a base station (or even of an ad-hoc mode host) with the same network name (SSID) as the legitimate basestation. Even adding authentication and encryption a la 802.1X and 802.11i may not help much in this respect. The SSID space is unmanaged, so everyone is free to put anything they want in the SSID field. Most host stacks don't deal gracefully with this. Moreover, SSIDs are very often set to the manufacturer's default, making them highly predictable.
SSIDフィールドは、この種の攻撃に対する防御を効果的に提供しません。暗号化が有効になっていない限り、合法的な根拠と同じネットワーク名（SSID）を持つ基地局（またはアドホックモードホストの存在）の存在を発表するのは簡単です。802.1xおよび802.11iに認証と暗号化を追加することでさえ、この点であまり役に立たないかもしれません。SSIDスペースは管理されていないため、誰もがSSIDフィールドに必要なものを自由に置くことができます。ほとんどのホストスタックはこれを優雅に扱っていません。さらに、SSIDはメーカーのデフォルトに非常によく設定されているため、非常に予測可能になります。
Some 802.11 basestations have limited memory for the number of associations they can support. If this is exceeded, they may drop all associations. In an attempt to forestall this problem, some APs advertise their load so as to enable stations to choose APs that are less loaded. However, crude implementations of these algorithms can result in instability.
いくつかの802.11のbasestationsは、サポートできる関連付けの数に対するメモリが限られています。これを超えた場合、それらはすべての関連付けを落とす可能性があります。この問題を未然に防ぐために、一部のAPは、荷重が少ないAPを選択できるように、負荷を宣伝しています。ただし、これらのアルゴリズムの粗い実装は不安定になる可能性があります。
Finally, as the authentication in 802.11 takes place at a comparatively high level in the stack, it is possible to simply deauthenticate or disassociate the victim from the basestation, even if Wired Equivalent Privacy (WEP) is in use [30]. Bellardo and Savage [15] describe some simple remedies that reduce the effectiveness of such attacks. While IEEE 802.11w will protect Deauthenticate or Disassociate frames, this attack is still possible via forging of Association frames.
最後に、802.11の認証はスタック内で比較的高いレベルで行われるため、有線同等のプライバシー（WEP）が使用されていても、犠牲者を基礎から単純に免疫または分離することが可能です[30]。BellardoとSavage [15]は、そのような攻撃の有効性を低下させるいくつかの簡単な救済策を説明しています。IEEE 802.11Wは、断層または関連性のあるフレームを保護しますが、この攻撃は関連性フレームの鍛造によって依然として可能です。
What all these attacks have in common is that they exploit vulnerabilities in the link auto-configuration mechanisms. In a wireless network, it is necessary for a station to detect the presence of APs in order to choose which one to connect to. In 802.11, this is handled via the Beacon and Probe Request/Response mechanisms.
これらすべての攻撃に共通しているのは、リンクの自動構成メカニズムの脆弱性を活用することです。ワイヤレスネットワークでは、ステーションが接続するAPを選択するためにAPの存在を検出する必要があります。802.11では、これはビーコンおよびプローブリクエスト/応答メカニズムを介して処理されます。
Beacons cannot easily be encrypted, because the station needs to utilize them prior to authentication in order to discover which APs it may wish to communicate with. Since authentication can only occur after interpreting the Beacon, an encrypted Beacon would present a chicken-egg problem: you can't obtain a key to decrypt the Beacon until completing authentication, and you may not be able to figure out which AP to authenticate with prior to decrypting the Beacon. Note that in principle you could encrypt Beacons with a shared (per-AP) key but this would require each station to trial-decrypt beacons until it finds one that matches up to whatever shared authentication secret it had. This is not particularly convenient.
ステーションは、通信したいAPを発見するために、認証の前にそれらを利用する必要があるため、ビーコンを簡単に暗号化することはできません。認証はビーコンを解釈した後にのみ発生する可能性があるため、暗号化されたビーコンは鶏卵の問題を提示します。認証を完了するまでビーコンを復号化するキーを取得することはできません。ビーコンを復号化する前に。原則として、共有（APパー）キーを使用してビーコンを暗号化できますが、これには各ステーションがビーコンを試用する必要があることに注意してください。これは特に便利ではありません。
As a result, discussions of Beacon frame security have largely focused on authentication of Beacon frames, not encryption. Even here, solutions are difficult. While it may be possible for a station to validate a Beacon *after* authentication (either by checking a Message Integrity Check (MIC) computed with the group key provided by the AP or verifying the Beacon parameters during the 4-way handshake), doing so *before* authentication may require synchronization of keys between APs within an SSID.
その結果、ビーコンフレームセキュリティの議論は、暗号化ではなく、ビーコンフレームの認証に大きく焦点を当てています。ここでも、解決策は困難です。ステーションは *認証後（APによって提供されるグループキーで計算されたメッセージ整合性チェック（MIC）をチェックするか、4ウェイハンドシェイク中にビーコンパラメーターを検証する）を確認することでビーコン *認証を検証することができますが、実行することは可能ですが、したがって、 *認証が必要になる場合は、SSID内のAP間のキーの同期が必要になる場合があります。
In today's Internet, DNS is of sufficient importance that if access to a site's DNS servers is denied, the site is effectively unreachable, even if there is no actual communication problem with the site itself.
今日のインターネットでは、DNSは十分に重要であり、サイトのDNSサーバーへのアクセスが拒否された場合、サイト自体に実際の通信の問題がない場合でも、サイトは効果的に到達できません。
Many of the attacks on end-systems described above can be perpetrated on DNS servers. As servers go, DNS servers are not particularly vulnerable to DoS. So long as a DNS server has sufficient memory, a modern host can usually respond very rapidly to DNS requests for which it is authoritative. This was demonstrated in October 2002 when the root nameservers were subjected to a very large DoS attack [38]. A number of the root nameservers have since been replicated using anycast [1] to further improve their resistance to DoS. However, it is important for authoritative servers to have relaying disabled, or it is possible for an attacker to force the DNS servers to hold state [40].
上記のエンドシステムに対する攻撃の多くは、DNSサーバーで実行できます。サーバーが進むにつれて、DNSサーバーはDOSに対して特に脆弱ではありません。DNSサーバーが十分なメモリを持っている限り、最新のホストは通常、それが権威あるDNS要求に非常に迅速に応答することができます。これは、ルートネームサーバーが非常に大きなDOS攻撃を受けた2002年10月に実証されました[38]。その後、多くのルートネームサーバーがAnycast [1]を使用して複製され、DOSに対する抵抗がさらに向上しています。ただし、権威あるサーバーが障害者を中継することが重要であるか、攻撃者がDNSサーバーに状態を強制させることが可能です[40]。
Many of the routing attacks can also be used against DNS servers by targeting the routing for the server. If the DNS server is co-located with the site for which is authoritative, then the fact that the DNS server is also unavailable is of secondary importance. However, if all the DNS servers are made unavailable, this may cause email to that site to bounce rather than being stored while the mail servers are unreachable, so distribution of DNS server locations is important.
ルーティング攻撃の多くは、サーバーのルーティングをターゲットにすることにより、DNSサーバーに対しても使用できます。DNSサーバーが権威あるサイトと共同で配置されている場合、DNSサーバーも利用できないという事実は二次的に重要です。ただし、すべてのDNSサーバーが利用できない場合、これにより、メールサーバーが到達できない間に保存されるのではなく、そのサイトへの電子メールがバウンスする可能性があるため、DNSサーバーの場所の配布が重要です。
Causing network congestion on links to and from a DNS server can have similar effects to end-system attacks or routing attacks, causing DNS to fail to obtain an answer, and effectively denying access to the site being served.
DNSサーバーとのリンクでネットワークの輻輳を引き起こすと、エンドシステム攻撃やルーティング攻撃と同様の効果があり、DNSが回答の取得に失敗し、サービスが提供されているサイトへのアクセスを効果的に拒否します。
We note that if an attacker can deny external access to all the DNS servers for a site, this will not only cause email to that site to be dropped, but it will also cause email from that site to be dropped. This is because recent versions of mail transfer agents such as sendmail will drop email if the mail originates from a domain that does not exist. This is a classic example of unexpected consequences. Sendmail performs this check as an anti-spam measure, and spam itself can be viewed as a form of DoS attack. Thus, defending against one DoS attack opens up the vulnerability that allows another DoS attack. If a receiving implementation is using a black-hole list (see Section 2.14) served by DNS, an attacker can also mount a DoS attack by attacking the black-hole server.
攻撃者がサイトのすべてのDNSサーバーへの外部アクセスを拒否できる場合、これによりそのサイトへの電子メールがドロップされるだけでなく、そのサイトからの電子メールがドロップされることにも注意してください。これは、sendmailなどのメール転送エージェントの最近のバージョンが、存在しないドメインからメールが発生した場合、電子メールを削除するためです。これは、予想外の結果の典型的な例です。SendMailはこのチェックをスパムアンチスパムメジャーとして実行し、スパム自体はDOS攻撃の形式と見なすことができます。したがって、あるDOS攻撃から防御することで、別のDOS攻撃を可能にする脆弱性が開かれます。受信実装がDNSが提供するブラックホールリスト（セクション2.14を参照）を使用している場合、攻撃者はブラックホールサーバーを攻撃することでDOS攻撃を実施することもできます。
Finally, a data corruption attack is possible if a site's nameserver is permitted to relay requests from untrusted third parties [40]. The attacker issues a query for the data he wishes to corrupt, and the victim's nameserver relays the request to the authoritative nameserver. The request contains a 16-bit ID that is used to match up the response with the request. If the attacker spoofs sufficient response packets from the authoritative nameserver just before the official response arrives, each containing a forged response and a different DNS ID, then there is a reasonable chance that one of the forged responses will have the correct DNS ID. The incorrect data will then be believed and cached by the victim's nameserver, so giving the incorrect response to future queries. The probability of the attack can further be increased if the attacker issues many different requests for the same data with different DNS IDs, because many nameserver implementations will issue relayed requests with different DNS IDs, and so the response only has to match any one of these request IDs [17] [36].
最後に、サイトの名前サーバーが信頼されていない第三者からのリクエストを中継することを許可されている場合、データ腐敗攻撃が可能です[40]。攻撃者は、破損したいデータのクエリを発行し、被害者の名前サーバーはリクエストを権威ある名前サーバーにリレーします。リクエストには、応答をリクエストと一致させるために使用される16ビットIDが含まれています。攻撃者が公式の応答が到着する直前に権威ある名前サーバーから十分な応答パケットをスプーフィングする場合、それぞれに偽造応答と異なるDNS IDが含まれている場合、偽造応答の1つが正しいDNS IDを持つという合理的な可能性があります。誤ったデータは、被害者の名前サーバーによって信じられ、キャッシュされるため、将来のクエリに対する誤った応答を与えます。攻撃者が異なるDNS IDを持つ同じデータに対して多くの異なるリクエストを発行すると、攻撃の確率がさらに増加する可能性があります。多くの名前サーバーの実装は異なるDNS IDで中継リクエストを発行するため、応答はこれらのいずれかと一致する必要があります。IDを要求[17] [36]。
The use of anycast for DNS services makes it even more vulnerable to spoofing attacks. An attacker who can convince the ISP to accept an anycast route to his fake DNS server can arrange to receive requests and generate fake responses. Anycast DNS also makes DoS attacks on DNS easier. The idea is to disable one of the DNS servers while maintaining the BGP route to that server. This creates failures for any client that is routed to the (now defunct) server.
DNSサービスにAnycastを使用すると、スプーフィング攻撃に対してさらに脆弱になります。ISPに、偽のDNSサーバーへのaycastルートを受け入れるように説得できる攻撃者は、リクエストを受け取り、偽の応答を生成するように手配できます。Anycast DNSは、DNSに対するDOS攻撃も容易にします。アイデアは、そのサーバーへのBGPルートを維持しながら、DNSサーバーの1つを無効にすることです。これにより、（現在の）サーバーにルーティングされているクライアントに障害が発生します。
The simplest DoS attack is to simply send enough non-congestion-controlled traffic such that a link becomes excessively congested, and legitimate traffic suffers unacceptably high packet loss.
最も単純なDOS攻撃は、リンクが過度に混雑するように十分な非合成制御トラフィックを単純に送信することです。
Under some circumstances, the effect of such a link DoS can be much more extensive. We have already discussed the effects of denying access to a DNS server. Congesting a link might also cause a routing protocol to drop an adjacency if sufficient routing packets are lost, potentially greatly amplifying the effects of the attack. Good router implementations will prioritize the transmission of routing packets, but this is not a total panacea. If routers are peered across a shared medium such as ethernet, it may be possible to congest the medium sufficiently that routing packets are still lost.
状況によっては、このようなリンクDOSの効果ははるかに広範囲に及ぶ可能性があります。DNSサーバーへのアクセスを拒否する効果については、すでに説明しています。リンクを混雑させると、十分なルーティングパケットが失われた場合、ルーティングプロトコルが隣接をドロップし、攻撃の効果を大幅に増幅する可能性があります。優れたルーターの実装は、ルーティングパケットの送信に優先順位を付けますが、これは総万能薬ではありません。ルーターがイーサネットなどの共有メディアを覗き込んでいる場合、ルーティングパケットがまだ失われるように媒体を十分に混雑させることができるかもしれません。
Even if a link DoS does not cause routing packets to be lost, it may prevent remote access to a router using ssh or Simple Network Management Protocol (SNMP) [48]. This might make the router unmanageable, or prevent the attack from being correctly diagnosed.
リンクDOSがルーティングパケットを紛失しない場合でも、SSHまたはSimple Network Management Protocol（SNMP）を使用してルーターへのリモートアクセスを防ぐ可能性があります[48]。これにより、ルーターが管理不能になるか、攻撃が正しく診断されないようにする可能性があります。
The prioritization of routing packets can itself cause a DoS problem. If the attacker can cause a large amount of routing flux, it may be possible for a router to send routing packets at a high enough rate that normal traffic is effectively excluded. However, this is unlikely except on low-bandwidth links.
ルーティングパケットの優先順位付け自体がDOSの問題を引き起こす可能性があります。攻撃者が大量のルーティングフラックスを引き起こす可能性がある場合、ルーターが通常のトラフィックが効果的に除外されるほど高いレートでルーティングパケットを送信できる可能性があります。ただし、低帯域幅リンクを除いて、これはほとんどありません。
Finally, it may be possible for an attacker to deny access to a link by causing the router to generate sufficient monitoring or report traffic that the link is filled. SNMP traps are one possible vector for such an attack, as they are not normally congestion controlled.
最後に、ルーターが十分な監視を生成したり、リンクが満たされていることを報告することにより、攻撃者がリンクへのアクセスを拒否することが可能かもしれません。SNMPトラップは、通常、混雑制御されていないため、このような攻撃のためのベクトルの1つです。
Attackers with physical access to multiple access links can easily bring down the link. This is particularly easy to mount and difficult to counter with wireless networks.
複数のアクセスリンクに物理的にアクセスできる攻撃者は、リンクを簡単にダウンさせることができます。これは特に簡単に取り付けられ、ワイヤレスネットワークで対抗するのが困難です。
Firewalls are intended to defend the systems behind them against attack. In that they restrict the traffic that can reach those systems, they may also aid in defending against denial-of-service attacks. However, under some circumstances the firewall itself may also be used as a weapon in a DoS attack.
ファイアウォールは、攻撃に対して背後のシステムを守ることを目的としています。それらがこれらのシステムに到達する可能性のあるトラフィックを制限するという点で、彼らはまた、サービス拒否攻撃から防御するのに役立ちます。ただし、状況によっては、ファイアウォール自体がDOS攻撃の武器としても使用される場合があります。
There are many different types of firewall, but generally speaking they fall into stateful and stateless classes. The state here refers to whether the firewall holds state for the active flows traversing the firewall. Stateless firewalls generally can only be attacked by attempting to exhaust the processing resources of the firewall. Stateful firewalls can be attacked by sending traffic that causes the firewall to hold excessive state or state that has pathological structure.
さまざまな種類のファイアウォールがありますが、一般的に言えば、それらはステートフルでステートレスのクラスに分類されます。ここの状態は、ファイアウォールを横断するアクティブなフローの状態をファイアウォールが保持しているかどうかを指します。一般に、ステートレスファイアウォールは、ファイアウォールの処理リソースを排出しようとすることによってのみ攻撃できます。ステートフルファイアウォールは、ファイアウォールが病理学的構造を持つ過度の状態または状態を保持するトラフィックを送信することにより攻撃することができます。
In the case of excessive state, the firewall simply runs out of memory, and can no longer instantiate the state required to pass legitimate flows. Most firewalls will then fail disconnected, causing denial-of-service to the systems behind the firewall.
過度の状態の場合、ファイアウォールは単に記憶を使い果たし、正当なフローを通過するために必要な状態を即座に即座にすることができなくなります。その後、ほとんどのファイアウォールは切断されなくなり、ファイアウォールの背後にあるシステムにサービス拒否を引き起こします。
In the case of pathological structure, the attacker sends traffic that causes the firewall's data structures to exhibit worst-case behaviour. An example of this would be when the firewall uses hash tables to look up forwarding state, and the attacker can predict the hash function used. The attacker may then be able to cause a large amount of flow state to hash to the same bucket, which causes the firewall's lookup performance to change from O(1) to O(n), where n is the number of flows the attacker can instantiate [28]. Thus, the attacker can cause forwarding performance to degrade to the point where service is effectively denied to the legitimate traffic traversing the firewall.
病理構造の場合、攻撃者はトラフィックを送信し、ファイアウォールのデータ構造が最悪の動作を示す原因となります。この例は、ファイアウォールがハッシュテーブルを使用して前進状態を検索するときであり、攻撃者は使用されるハッシュ関数を予測できることです。攻撃者は、大量のフロー状態を同じバケツにハッシュすることができる可能性があります。これにより、ファイアウォールのルックアップパフォーマンスがO（1）からO（n）に変更されます。ここで、nは攻撃者ができるフローの数です。インスタンス化[28]。したがって、攻撃者は、ファイアウォールを横断する正当なトラフィックに対してサービスが効果的に拒否されるポイントまで転送パフォーマンスを低下させる可能性があります。
Intrusion detection systems (IDSs) suffer from similar problems to firewalls. It may be possible for an attacker to cause the IDS to exhaust its available processing power, to run out of memory, or to instantiate state with pathological structure. Unlike a firewall, an IDS will normally fail open, which will not deny service to the systems protected by the IDS. However, it may mean that subsequent attacks that the IDS would have detected will be missed.
侵入検知システム（IDS）は、ファイアウォールと同様の問題に苦しんでいます。攻撃者がIDを利用可能な処理能力を使い果たしたり、メモリを使い果たしたり、病理学的構造で状態をインスタンス化することが可能かもしれません。ファイアウォールとは異なり、IDは通常開いています。これは、IDSによって保護されているシステムへのサービスを拒否しません。ただし、IDが検出した後続の攻撃が見逃されることを意味する場合があります。
Some IDSs are reactive; that is, on detection of a hostile event they react to block subsequent traffic from the hostile system, or to terminate an ongoing connection from that system. It may be possible for an attacker to spoof packets from a legitimate system, and hence cause the IDS to believe that system is hostile. The IDS will then cause traffic from the legitimate system to be blocked, hence denying service to it. The effect can be particularly bad if the legitimate system is a router, DNS server, or other system whose performance is essential for the operation of a large number of other systems.
一部のIDSはリアクティブです。つまり、敵対的な出来事を検出すると、敵対的なシステムからの後続のトラフィックをブロックするか、そのシステムから継続的な接続を終了するために反応します。攻撃者が合法的なシステムからパケットを吹き飛ばす可能性があるため、IDはシステムが敵対的であると信じることができます。IDは、正当なシステムからのトラフィックがブロックされるため、サービスへのサービスを拒否します。正当なシステムがルーター、DNSサーバー、または他の多くのシステムの動作に不可欠な他のシステムである場合、効果は特に悪い場合があります。
Network time servers are generally not considered security-critical services, but under some circumstances NTP servers might be used to perpetrate a DoS attack.
ネットワークタイムサーバーは一般にセキュリティ批判的なサービスとは見なされませんが、状況によっては、DOS攻撃を実行するためにNTPサーバーを使用する場合があります。
The most obvious such attack is to DoS the NTP servers themselves. Many end-systems have rather poor clock accuracy and so, without access to network time, their clock will naturally drift. This can cause problems with distributed systems that rely on good clocks. For example, one commonly used revision control system can fail if it perceives the modification timestamp to be in the future.
最も明白なこのような攻撃は、NTPサーバー自体をDOSすることです。多くのエンドシステムは、クロックの精度がかなり低いため、ネットワーク時間にアクセスできない場合、クロックは自然に漂います。これにより、適切な時計に依存する分散システムに問題が発生する可能性があります。たとえば、一般的に使用される修正制御システムの1つは、変更タイムスタンプが将来的になると認識している場合、失敗する可能性があります。
If the NTP servers relied on by a host can be subverted, either through compromising or impersonating them, then the attacker may be able to control the host's system clock. This can cause many unexpected consequences, including the premature expiry of dated resources such as encryption or authentication keys. This in turn can prevent access to other more critical services.
ホストが依存しているNTPサーバーが侵害またはなりすまして、攻撃者がホストのシステムクロックを制御できる場合があります。これは、暗号化や認証キーなどの日付のあるリソースの早期の有効期限を含む、多くの予期せぬ結果を引き起こす可能性があります。これにより、他のより重要なサービスへのアクセスを防ぐことができます。
The discussion thus far has centered on denial-of-service attacks perpetrated using the network. However, computer systems are only as resilient as the weakest link. It may be easier to deny service by causing a power failure, by cutting network cables, or by simply switching a system off, and so physical security is at least as important as network security. Physical attacks can also serve as entry points for non-physical DoS, for instance, by reducing the resources available to deal with overcapacity.
これまでの議論は、ネットワークを使用して行われたサービス拒否攻撃に集中してきました。ただし、コンピューターシステムは、最も弱いリンクと同じくらい回復力があります。停電を引き起こすこと、ネットワークケーブルを切断するか、システムをオフにするだけでサービスを拒否する方が簡単かもしれません。物理的攻撃は、過剰能力に対処するために利用可能なリソースを減らすことにより、非物理的DOSのエントリポイントとしても機能します。
The weakest link may also be human. In defending against DoS, the possibility of denial-of-service through social engineering should not be neglected, such as convincing an employee to make a configuration change that prevents normal operation.
最も弱いリンクは人間かもしれません。DOSを擁護する際、ソーシャルエンジニアリングによるサービス拒否の可能性は、従業員に通常の運用を防ぐ構成を変更するよう説得するなど、無視すべきではありません。
Computer systems cannot be considered in isolation from the social and legal systems in which they operate. This document focuses primarily on the technical issues, but we note that "cease and desist" letters, government censorship, and other legal mechanisms also touch on denial-of-service issues.
コンピューターシステムは、運営されている社会システムと法制度から単独で考慮することはできません。このドキュメントは主に技術的な問題に焦点を当てていますが、「中止」文字、政府の検閲、およびその他の法的メカニズムもサービス拒否の問題に触れていることに注意してください。
Unsolicited commercial email, also known as "spam", can effectively cause denial-of-service to email systems. While the intent is not denial-of-service, the large amount of unwanted mail can waste the recipient's time or cause legitimate email to fail to be noticed amongst all the background noise. If spam filtering software is used, some level of false positives is to be expected, and so these messages are effectively denied service.
「スパム」とも呼ばれる未承諾のコマーシャルメールは、電子メールシステムにサービス拒否を効果的に引き起こす可能性があります。意図はサービスの拒否ではありませんが、大量の不要なメールは、受信者の時間を無駄にしたり、すべてのバックグラウンドノイズの中で合法的な電子メールを発見したりすることがあります。スパムフィルタリングソフトウェアを使用すると、ある程度の誤検知が予想されるため、これらのメッセージはサービスを効果的に拒否されます。
One mechanism to reduce spam is the use of black-hole lists. The IP addresses of dial-up ISPs or mail servers used to originate or relay spam are added to black-hole lists. The recipients of mail choose to consult these lists and reject spam if it originates or is relayed by systems on the list. One significant problem with such lists is that it may be possible for an attacker to cause a victim to be black-hole-listed, even if the victim was not responsible for relaying spam. Thus, the black-hole list itself can be a mechanism for effecting a DoS attack. Note that every black-hole list has its own policy regarding additions, and some are less susceptible to this DoS attack than others. Consumers of black-hole list technology are advised to investigate these policies before they subscribe. Similar considerations apply to feeds of bad BGP bad route advertisements.
スパムを減らすメカニズムの1つは、ブラックホールリストの使用です。Dial-Up ISPまたはリレースパムの発信またはリレーに使用されるメールサーバーのIPアドレスがブラックホールリストに追加されます。メールの受信者は、これらのリストを参照することを選択し、リストのシステムが発生した、またはリレーされている場合はスパムを拒否することを選択します。そのようなリストの重要な問題の1つは、攻撃者が被害者がスパムを中継する責任を負わなかったとしても、被害者をブラックホールに上場させることができる可能性があることです。したがって、ブラックホールリスト自体は、DOS攻撃に影響を与えるメカニズムになります。すべてのブラックホールリストには追加に関する独自のポリシーがあり、一部は他のDOS攻撃よりもこのDOS攻撃の影響を受けにくいことに注意してください。ブラックホールリストテクノロジーの消費者は、購読する前にこれらのポリシーを調査することをお勧めします。同様の考慮事項は、悪いBGPの悪いルート広告のフィードにも当てはまります。
Many of the attacks described above rely on sending sufficient traffic to overwhelm the victim. Such attacks are made much easier by the existence of "attack amplifiers", where an attacker can send traffic from the spoofed source address of the victim and cause larger responses to be returned to the victim. A detailed discussion of such reflection attacks can be found in [35].
上記の攻撃の多くは、被害者を圧倒するのに十分な交通を送ることに依存しています。このような攻撃は、「攻撃アンプ」の存在によってはるかに容易になります。攻撃者は、被害者のスプーフィングされたソースアドレスからトラフィックを送信し、より大きな反応を被害者に返還することができます。このような反射攻撃の詳細な議論は[35]にあります。
The simplest such attack was the "smurf" attack [22], where an ICMP echo request packet with the spoofed source address of the victim is sent to the subnet-broadcast address of a network to be used as an amplifier. Every system on that subnet then responds with an ICMP echo response that returns to the victim. Smurf attacks are no longer such a serious problem, as these days routers usually drop such packets and end-systems do not respond to them.
最も単純な攻撃は「Smurf」攻撃[22]でした。この攻撃では、ICMPエコーリクエストパケットが被害者のスプーフィングされたソースアドレスを使用して、アンプとして使用されるネットワークのサブネットブロードキャストアドレスに送信されます。そのサブネット上のすべてのシステムは、被害者に戻るICMPエコー応答で応答します。スマーフ攻撃はもはやそれほど深刻な問題ではありません。最近のルーターは通常、そのようなパケットをドロップし、エンドシステムはそれらに応答しません。
An alternative form of attack amplifier is typified by a DNS reflection attack. An attacker sends a DNS request to a DNS server requesting resolution of a domain name. Again the source address of the request is the spoofed address of the victim. The request is carefully chosen so that the size of the response is significantly greater than the size of the request, thereby providing the amplification. As an aside, it is interesting to note that the largest DNS responses tend to be those incorporating DNSsec authentication information. This attack amplifier can only be used by an attacker with the ability to spoof the source address of the victim. However, we note that if the victim's DNS server is configured to relay requests from external clients, it may be possible to cause it to congest its own incoming network link.
攻撃アンプの代替形式は、DNS反射攻撃によって代表されます。攻撃者は、ドメイン名の解決策を要求するDNSリクエストをDNSサーバーに送信します。繰り返しますが、リクエストのソースアドレスは、被害者のスプーフィングされたアドレスです。リクエストは、応答のサイズがリクエストのサイズよりも大幅に大きくなり、増幅を提供するように慎重に選択されます。余談ですが、最大のDNS応答はDNSSEC認証情報を組み込んだものである傾向があることに注意するのは興味深いことです。この攻撃アンプは、攻撃者が被害者のソースアドレスをスプーフィングする能力を備えたみを使用できます。ただし、被害者のDNSサーバーが外部クライアントからのリクエストを中継するように構成されている場合、独自のネットワークリンクを混雑させることができる場合があることに注意してください。
Another variant of attack amplifier involves amplification through retransmission. This is typified by a TCP amplification attack known as "bang.c". The attacker sends a spoofed TCP SYN with the source address of the victim to an arbitrary TCP server. The server will respond with a SYN|ACK that is sent to the victim, and when no final ACK is received to complete the handshake, the SYN|ACK will be retransmitted a number of times. Typically, this attack uses a very large list of arbitrarily chosen servers as reflectors. For the attack to be successful, the reflector must not receive a RST from the victim in response to the SYN|ACK. However, if the attack traffic sufficiently overwhelms the server or access link to the server, then packet loss will ensure that many reflectors do not receive a RST in response to their SYN|ACK, and so continue to retransmit. The attack can be exacerbated by firewalls that silently drop the incoming SYN|ACK without sending a RST.
攻撃アンプの別のバリアントには、再送信による増幅が含まれます。これは、「BANG.C」として知られるTCP増幅攻撃によって代表されます。攻撃者は、任意のTCPサーバーに被害者のソースアドレスとスプーフィングされたTCP Synを送信します。サーバーは、被害者に送信されるsyn | ACKで応答し、握手を完了するために最終的なACKが受信されない場合、Syn | ACKは何度も再送信されます。通常、この攻撃は、リフレクターとして任意に選択されたサーバーの非常に大きなリストを使用します。攻撃を成功させるために、リフレクターはsyn | ackに応じて被害者から最初のRを受け取ってはなりません。ただし、攻撃トラフィックがサーバーまたはサーバーへのリンクを十分に圧倒する場合、パケットの損失により、多くのリフレクターがSyn | Ackに応じてRSTを受け取らないことを保証し、再送信を続けます。攻撃は、RSTを送信せずに入ってくるSyn | Ackを静かに落とすファイアウォールによって悪化する可能性があります。
Care must also be taken with services that relay requests. If an attacker can send a request to a proxy, and that proxy now attempts to connect to a victim whose address is chosen by the attacker, then, if the proxy repeatedly resends the request when receiving no answer, this can also serve as an attack amplifier.
また、リレーションリクエストを中継するサービスには注意する必要があります。攻撃者がプロキシにリクエストを送信でき、その代理人が攻撃者によって住所が選択された被害者に接続しようとする場合、プロキシが回答を受け取らないときにリクエストを繰り返し再送信する場合、これも攻撃として役立つことができます増幅器。
Another variant of amplification occurs in protocols that include, within the protocol payload, an IP address or name of host to which subsequent messages should be sent. An example of such a protocol is the Session Initiation Protocol (SIP) [50], which carries a payload defined by the Session Description Protocol (SDP) [51]. The SDP payload of the SIP message conveys the IP address and port to which media packets, typically encoded using the Real Time Transport Protocol (RTP) [52], are sent.
増幅のもう1つのバリアントは、プロトコルペイロード内で、後続のメッセージを送信するIPアドレスまたはホストの名前を含むプロトコルで発生します。このようなプロトコルの例は、セッション開始プロトコル（SIP）[50]です。これは、セッション説明プロトコル（SDP）[51]で定義されたペイロードを搭載しています。SIPメッセージのSDPペイロードは、通常、リアルタイムトランスポートプロトコル（RTP）[52]を使用してエンコードされるメディアパケットが送信されるIPアドレスとポートを伝えます。
To launch this attack, an attacker sends a protocol message, and sets the IP address within the payload to point to the attack target. The recipient of the message will generate subsequent traffic to that IP address. Depending on the protocol, this attack can provide substantial amplification properties. In the specific case of SIP, if a caller makes calls to high-bandwidth media sources (such as a video server or streaming audio server), a single SIP INVITE packet, typically a few hundred bytes, can result in a nearly continuous stream of media packets at rates anywhere from a few kbits per second up to megabits per second. This particular attack is called the "voice hammer".
この攻撃を開始するために、攻撃者はプロトコルメッセージを送信し、ペイロード内にIPアドレスを設定して攻撃ターゲットを指します。メッセージの受信者は、そのIPアドレスへの後続のトラフィックを生成します。プロトコルに応じて、この攻撃は実質的な増幅特性を提供できます。SIPの特定のケースでは、発信者が高帯域幅メディアソース（ビデオサーバーやストリーミングオーディオサーバーなど）に電話をかけると、通常数百バイトの単一のSIP招待パケットがほぼ連続的なストリームをもたらす可能性があります。メディアパケットは、1秒あたり数kbitから1秒あたりのメガビットまでのレートで。この特定の攻撃は「音声ハンマー」と呼ばれます。
Unlike the other techniques described above, this technique does not require the attacker to modify packets or even spoof their source IP address. This makes it easier to launch.
This attack is prevented through careful protocol design. Protocols should, whenever possible, avoid including IP addresses or hostnames within protocol payloads as addresses to which subsequent messaging should be sent. Rather, when possible, messages should be sent to the source IP from which the protocol packet came. If such a design is not possible, the protocol should include a handshake whereby it can be positively determined that the protocol entity at that IP address or hostname does, in fact, wish to receive that subsequent messaging. That handshake itself needs to be lightweight (to avoid being the source of another DoS attack), and secured against the spoofing of the handshake response.
この攻撃は、慎重なプロトコル設計によって防止されます。プロトコルは、可能な限り、後続のメッセージを送信するアドレスとして、プロトコルペイロード内にIPアドレスまたはホスト名を含めることを避ける必要があります。むしろ、可能であれば、プロトコルパケットが来たソースIPにメッセージを送信する必要があります。そのような設計が不可能な場合、プロトコルには、そのIPアドレスまたはホスト名のプロトコルエンティティが実際にその後続のメッセージを受け取ることを望んでいることを積極的に決定できる握手を含める必要があります。その握手自体は（別のDOS攻撃の原因であることを避けるために）軽量である必要があり、握手反応のスプーフィングに対して確保されます。
Finally, a somewhat similar attack is possible with some protocols where one message leads to another message that is not sent as a reply to the source address of the first message. This can be an issue with protocols to enable mobility, for example, and might permit an attacker to avoid ingress filtering. Such protocols are notoriously difficult to get right.
最後に、あるメッセージが最初のメッセージのソースアドレスへの返信として送信されない別のメッセージにつながる一部のプロトコルでは、やや似た攻撃が可能です。これは、たとえばモビリティを有効にするプロトコルの問題になる可能性があり、攻撃者が侵入フィルターを避けることを可能にする可能性があります。このようなプロトコルは、正しくなるのが難しいことで有名です。
In general, the architectural lessons to be learnt are simple:
一般に、学習すべき建築のレッスンは簡単です。
o As far as possible, perform ingress filtering [7] [39] to prevent source address spoofing.
o 可能な限り、イングレスフィルタリング[7] [39]を実行して、ソースアドレスのスプーフィングを防ぎます。
o Avoid designing protocols or mechanisms that can return significantly larger responses than the size of the request, unless a handshake is performed to validate the client's source address. Such a handshake needs to incorporate an unpredictable nonce that is secure enough to mitigate the amplification effects of the protocol.
o クライアントのソースアドレスを検証するために握手が実行されない限り、リクエストのサイズよりも大幅に大きな応答を返すことができるプロトコルまたはメカニズムの設計は避けてください。このような握手は、プロトコルの増幅効果を緩和するのに十分な安全性のない予測不可能な非CEを組み込む必要があります。
o All retransmission during initial connection setup should be performed by the client.
o 最初の接続セットアップ中のすべての再送信は、クライアントが実行する必要があります。
o Proxies should not arbitrarily relay requests to destinations chosen by a client.
o プロキシは、クライアントが選択した目的地にリクエストを任意に中継するべきではありません。
o Avoid signaling third-party connections. Any unavoidable third-party connections set up by a signaling protocol should incorporate lightweight validation before sending significant data.
o サードパーティの接続の信号を避けてください。シグナリングプロトコルによって設定された避けられないサードパーティ接続は、重要なデータを送信する前に軽量検証を組み込む必要があります。
A general problem with DoS defense is that it is not in principle possible to distinguish between a flash crowd and a DoS attack. Indeed, having your site taken down by a flash crowd is probably a more common experience than having it DoS-ed -- so common it has acquired its own names: being Slashdotted or Farked, after the web sites that are common sources of flash crowds. Thus, the first line of defense against DoS attacks must be to provision your service so that it can handle a foreseeable legitimate peak load. Underprovisioned sites are the easiest to take down.
DOS防衛の一般的な問題は、フラッシュの群衆とDOS攻撃を区別することは原則的には不可能ではないということです。確かに、あなたのサイトをフラッシュの群衆に倒すことは、おそらくそれをdos-edにするよりも一般的な経験です。。したがって、DOS攻撃に対する防衛の最初のラインは、予見可能な正当なピーク負荷を処理できるようにサービスを提供することでなければなりません。不十分なサイトを削除するのが最も簡単です。
Specific strategies for DoS defense fall into two broad categories:
DOS防衛の特定の戦略は、2つの広範なカテゴリに分類されます。
1. Avoiding allowing attacks that are better than generic resource consumption.
1. 一般的なリソース消費よりも優れた攻撃を許可することを避けます。
2. Minimizing the extent to which generic resource consumption attacks crowd out legitimate users.
2. 一般的なリソース消費が正当なユーザーを攻撃する程度を最小限に抑えます。
In the remainder of this section, we consider specific applications of these two approaches at a variety of levels of network system architecture.
このセクションの残りの部分では、さまざまなレベルのネットワークシステムアーキテクチャでこれら2つのアプローチの特定のアプリケーションを検討します。
From an end-system server point of view, one simple aim is to avoid instantiating state without having completed a handshake with the client to validate their address, and as far as possible to push work and stateholding to client. There are a number of techniques that might be used to do this, including SYN cookies [2] [14]. All client-server protocols should probably be designed to allow such techniques to be used, but the enabling of the mechanism should normally be at the server's discretion to avoid unnecessary work under normal circumstances.
最終システムのサーバーの観点からは、1つの簡単な目的は、クライアントとの握手を完了することなく、アドレスを検証することなく状態をインスタンス化することを避け、できる限り作業と保有をクライアントに押し進めることです。Syn Cookie [2] [14]を含む、これを行うために使用される可能性のある多くの手法があります。すべてのクライアントサーバープロトコルは、おそらくそのような手法を使用できるように設計する必要がありますが、メカニズムの有効化は通常、通常の状況下で不必要な作業を避けるためにサーバーの裁量である必要があります。
Other than having massive overcapacity, the only real defense against resource consumption attacks is to preferentially discriminate against attackers. The general idea is to find something that legitimate users can do but attackers can't. The most commonly proposed approaches include:
1. Puzzles: force the attacker to do some computation that would not be onerous for a single user but is too expensive to do en masse [14].
1. パズル：攻撃者に、単一のユーザーにとって面倒ではないが、大量に存在するには高すぎる計算を強制します[14]。
2. Reverse Turing tests: specialized puzzles that are hard for machines to do but easy for humans, thus making automated attacks hard [13].
2. 逆チューリングテスト：マシンがやるのが難しいが人間にとって簡単な特殊なパズルであるため、自動攻撃が激しくなります[13]。
3. Reachability testing: force the proposed client to demonstrate that it can receive traffic at a given IP address. This makes it easier to trace attackers.
3. 到達可能性テスト：提案されたクライアントに、特定のIPアドレスでトラフィックを受信できることを示すように強制します。これにより、攻撃者を簡単に追跡できます。
All of these techniques have substantial limitations. Puzzles tend to discriminate against legitimate users with slow computers. In addition, the wide availability of remotely controlled compromised machines ("bots") means that attackers have ample computing power at their disposal. There has been substantial work in attacking reverse Turing tests automatically, thus making them of limited applicability. Finally, reachability testing is substantially weakened by bots because the attacker does not need to hide his source address.
これらのすべての手法には、大きな制限があります。パズルは、遅いコンピューターで合法的なユーザーを差別する傾向があります。さらに、リモート制御された侵害マシン（「ボット」）が幅広く利用できるため、攻撃者は十分なコンピューティングパワーを自由に使用できます。逆チューリングテストを自動的に攻撃することにはかなりの作業があり、したがって、それらを限られた適用性にしました。最後に、攻撃者がソースアドレスを隠す必要がないため、到達可能性テストはボットによって大幅に弱体化します。
A goal with routing protocols is that of graceful degradation in overload, and automatic recovery after the source of the overload has been remedied. Some routing protocols satisfy this goal more than others. Although RIP [53] doesn't scale well, if a router runs out of memory when receiving a RIP route, it can just drop the route and send an infinite metric to its peers. The route will later be refreshed, and if the original source of the problem has been resolved, the router will now be able to process it correctly.
ルーティングプロトコルの目標は、過負荷の優雅な分解の目標と、過負荷の原因が改善された後の自動回復の目標です。一部のルーティングプロトコルは、他のルーティングよりもこの目標を満たしています。RIP [53]はうまくスケーリングしませんが、RIPルートを受信するときにルーターがメモリから外れている場合、ルートを落としてピアに無限のメトリックを送信するだけです。ルートは後で更新され、問題の元のソースが解決された場合、ルーターはそれを正しく処理できるようになります。
On the other hand, BGP is stateful in the sense that a peer assumes you have processed or chosen to filter any route that it sent you. There is no mechanism to refresh state in the base BGP spec, and even the later route refresh option [3] is hard to use in the presence of overload. A BGP router that cannot store a route it received has two choices: completely restart BGP or shut down one or more peerings [26]. This means that the effects of a BGP overload are rather more severe than they need to be, and so amplifies the effect of any attack.
一方、BGPは、ピアが送信したルートを処理またはフィルタリングするために処理または選択したと想定しているという意味でステートフルです。ベースBGP仕様に状態を更新するメカニズムはありません。また、後のルートリフレッシュオプション[3]でさえ、過負荷の存在下で使用するのは困難です。受け取ったルートを保存できないBGPルーターには、BGPを完全に再起動するか、1つ以上のピーリングをシャットダウンするという2つの選択肢があります[26]。これは、BGPの過負荷の効果が必要よりもかなり深刻であり、攻撃の効果を増幅することを意味します。
In general, few routing protocol designs actively consider the possible behaviour of routers under overload conditions; this should be an explicit part of future routing protocol designs. Although precise details should clearly be left to implementors, the protocol design needs to give them the capability to do their job properly.
一般に、過負荷条件下でのルーターの可能性のある動作を積極的に考慮するルーティングプロトコル設計はほとんどありません。これは、将来のルーティングプロトコル設計の明示的な部分である必要があります。正確な詳細は明らかに実装者に委ねる必要がありますが、プロトコル設計は、彼らに仕事を適切に行う能力を彼らに与える必要があります。
Autoconfiguration mechanisms greatly ease deployment, and are increasingly necessary as the number of networked devices grows beyond what can be managed manually. However, it should be recognised that unauthenticated autoconfiguration opens up many avenues for attack. There is a clear tension between ease of configuration and security of configuration, especially because there are environments in which it is desirable for units to operate with effectively no authentication (e.g., airport hotspots). Future autoconfiguration protocols should consider the need to allow different end-systems to operate at different points in this spectrum within the same autoconfiguration framework. However, this also implies that the network elements should avoid acting for unauthenticated hosts, instead just letting them access the network more or less directly.
自動構成メカニズムは展開を大幅に容易にし、ネットワーク化されたデバイスの数が手動で管理できるものを超えて増加するにつれてますます必要になっています。ただし、認識されていないオートコンチュレーションが攻撃のための多くの道を開くことが認識されるべきです。構成の容易さと構成のセキュリティの間には明確な緊張があります。特に、ユニットが認証を効果的に操作しないことが望ましい環境（空港のホットスポットなど）があるためです。将来の自動構成プロトコルは、同じAutoConfigurationフレームワーク内のこのスペクトルの異なるポイントで異なるエンドシステムを動作させる必要性を考慮する必要があります。ただし、これは、ネットワーク要素が認定されていないホストの動作を避け、代わりにネットワークに多かれ少なかれ直接アクセスできるようにする必要があることも意味します。
In general, networks should be provisioned with private, out-of-band access to console or control ports so that such control facilities will be available in the face of a DoS attack launched against either the control or data plane of the (in-band) network. Typically, such out-of-band networks are provisioned on a separate infrastructure for exactly this purpose. Out-of-band access is a crucial capability for DoS mitigation, since many of the typical redundancy and capacity management techniques (such as prioritizing routing or network management traffic) fail during such attacks. In addition, many redundancy protocols such as VRRP [47] can fail during such attacks as they may be unable to keep adjacencies alive.
There are several default configuration settings that can also be exploited to generate several of the attacks outlined in this document. For example, some vendors may have features such as IP redirect, directed broadcast, and proxy ARP enabled by default. Similar defaults, such as publicly readable SNMP [48] communities (e.g., "public") can be used to reveal otherwise confidential information to a prospective attacker. Finally, other unauthenticated configuration management protocols such as TFTP [49] should be avoided if possible; at the very least access to TFTP configuration archives should be protected and TFTP should be filtered at administrative boundaries. Finally, since many of the password encryption techniques used by router vendors are reversible, keeping such passwords on a configuration archive (as part of a configuration file), even in the encrypted form written by the router, can lead to unauthorized access if the archive is compromised.
このドキュメントで概説されているいくつかの攻撃を生成するために活用できるデフォルトの構成設定がいくつかあります。たとえば、一部のベンダーには、IPリダイレクト、監督されたブロードキャスト、デフォルトで有効になっているプロキシARPなどの機能がある場合があります。公開されているSNMP [48]コミュニティ（「パブリック」など）などの同様のデフォルトを使用して、攻撃者に機密情報を明らかにすることができます。最後に、可能であれば、TFTP [49]などの他の認定されていない構成管理プロトコルを避ける必要があります。少なくともTFTP構成アーカイブへのアクセスを保護し、TFTPを管理境界でフィルタリングする必要があります。最後に、ルーターベンダーが使用するパスワード暗号化手法の多くは可逆的であるため、ルーターによって書かれた暗号化されたフォームであっても、構成アーカイブ（構成ファイルの一部として）にそのようなパスワードを保持することができますが、アーカイブが不正アクセスにつながる可能性があります。妥協されます。
A basic principle of designing systems to handle failure is to have redundant servers that can take over when one fails. This is equally true in the case of DoS attacks, which often focus on a given server and/or link. If service delivery points can be distributed across the network, then it becomes much harder to attack the entire service. In particular, this makes attacks on a single network link more difficult.
障害を処理するシステムを設計することの基本原則は、失敗したときに引き継ぐことができる冗長なサーバーを持つことです。これは、DOS攻撃の場合にも同様に当てはまります。DOS攻撃は、特定のサーバーやリンクに焦点を当てていることがよくあります。ネットワーク全体にサービス提供ポイントを配布できる場合、サービス全体を攻撃することがはるかに困難になります。特に、これにより、単一のネットワークリンクに対する攻撃がより困難になります。
In general, cryptographic authentication mechanisms are too costly to form the main part in DoS prevention. However, routing adjacencies are too important to risk an attacker being able to inject bad routing information, which can affect more than the router in question. Additional non-cryptographic mechanisms should then be used to avoid arbitrary end-systems being able to cause the router to spend CPU cycles on validating authentication data.
一般に、暗号化認証メカニズムは、DOS予防の主要な部分を形成するには費用がかかりすぎます。ただし、ルーティングの隣接は、攻撃者が悪いルーティング情報を注入できるリスクを冒すことはあまりにも重要であり、問題のルーターよりも影響を与える可能性があります。次に、追加の非暗号化メカニズムを使用して、任意の最終システムが認証データの検証にCPUサイクルを使用することを任意しないようにする必要があります。
For BGP, at the very least, this implies the use of TCP MD5 [9] or IPsec authentication, combined with the GTSM [8] to prevent eBGP association with non-immediate neighbors. In the future, this will likely imply better authentication of the routing information itself.
BGPの場合、少なくともこれは、TCP MD5 [9]またはIPSEC認証の使用をGTSM [8]と組み合わせて、EBGPが非誤った隣接体との関連を防ぐことを意味します。将来的には、これはルーティング情報自体のより良い認証を暗示する可能性があります。
As far as is feasible, router-to-router traffic should be isolated from data traffic. How this should be implemented depends on the precise technologies available, both in the router and at the link layer. The goal should be that failure of the link for data traffic should also cause failure for the routing traffic, but that an attacker cannot directly send packets to the control processor of the routers.
実行可能な限り、ルーター間トラフィックはデータトラフィックから分離する必要があります。これを実装する方法は、ルーターとリンクレイヤーの両方で、利用可能な正確なテクノロジーに依存します。目標は、データトラフィックのリンクの故障もルーティングトラフィックの障害を引き起こすはずであるが、攻撃者はパケットをルーターの制御プロセッサに直接送信できないことです。
A downside of this is that some diagnostic techniques (such as pinging consecutive routers to find the source of a delay) may no longer be possible. Ideally, alternative mechanisms (which do not open up additional avenues for DoS) should be designed to replace such lost techniques.
これの欠点は、いくつかの診断技術（遅延の原因を見つけるための連続ルーターのpingなど）がもはや不可能である可能性があるということです。理想的には、代替メカニズム（DOSの追加の手段を開いていない）は、このような失われた技術を置き換えるように設計する必要があります。
Because a router can be considered as an end-system, it can potentially benefit from all the prevention mechanisms prescribed for end-system implementation. However, one basic distinction between a router and a host is that the former implements routing protocols and forwards data, which in turn lead to additional router-specific implementation considerations. The issues described below are meant to be illustrative and not exhaustive.
ルーターは最終システムと見なすことができるため、最終システムの実装に規定されているすべての予防メカニズムから潜在的に恩恵を受けることができます。ただし、ルーターとホストの間の基本的な区別の1つは、前者がルーティングプロトコルを実装し、データを転送し、それが追加のルーター固有の実装の考慮事項につながることです。以下に説明する問題は、網羅的ではないことを意図しています。
Protocol syntax defines the formation of the protocol messages and the rules of exchanges. The questions addressed by protocol syntax checking includes, but is not limited to, the following:
プロトコル構文は、プロトコルメッセージの形成と交換のルールを定義します。プロトコル構文チェックで扱われている質問には、以下が含まれますが、これらに限定されません。
1. Who sent the message?
1. 誰がメッセージを送ったのですか？
2. Does the content conform to the protocol format?
2. コンテンツはプロトコル形式に準拠していますか？
3. Was the message sent with correct timing? The first step in protocol syntax verification is to ensure that an incoming message was sent by a legitimate party. There are multiple ways to perform this check. One can verify the source IP address and even the MAC address of the message. Utilizing the fact that eBGP peers are normally directly connected, one can also check the TTL value in a packet and discard any BGP updates packet whose TTL is less than some maximum value (typically, max TTL - 1) [8]. Cryptographic authentication should also be used whenever available to verify that an incoming message is indeed from an expected sender. For BGP, at the very least, this implies the use of TCP MD5 [9] or IPsec authentication.
3. メッセージは正しいタイミングで送信されましたか？プロトコル構文の検証の最初のステップは、合法的な当事者によって着信メッセージが送信されるようにすることです。このチェックを実行するには複数の方法があります。ソースIPアドレスとメッセージのMACアドレスさえ確認できます。EBGPピアが通常直接接続されているという事実を利用して、パケットでTTL値をチェックし、TTLが最大値（通常、最大TTL -1）よりも少ないBGP更新パケットを破棄することもできます[8]。また、着信メッセージが実際に予想される送信者からであることを確認するために、暗号化認証も使用できる場合はいつでも使用する必要があります。BGPの場合、少なくともこれは、TCP MD5 [9]またはIPSEC認証の使用を意味します。
In addition to the sender verification, it is also important to check the syntax of a received routing message, as opposed to assuming that all messages came in a correct format. It happened in the past that routers crashed upon receiving ill-formed routing messages. Such faults will be prevented by performing rigorous syntax checking.
送信者の検証に加えて、すべてのメッセージが正しい形式であると仮定するのではなく、受信したルーティングメッセージの構文を確認することも重要です。過去に、ルーターが不正なルーティングメッセージを受信するとクラッシュしたことが起こりました。このような障害は、厳密な構文チェックを実行することにより防止されます。
Protocol semantics define the meaning of the message content, the interpretation of the values, and the actions to be taken according to the content. Here is a simple example of using semantic checking. When a link failure causes a router in Autonomous System (AS) A to send a peer router B a withdrawal message for prefix P, B should make sure that any alternative path it finds to reach P does not go through A. This simple check is shown to significantly improve BGP convergence time in many cases [42].
Another example of using semantic checking against false routing injection is described in [44]. The basic idea is to attach to the route announcement for prefix P a list of the valid origin ASes. Due to the rich connectivity in today's Internet topology, a remote AS will receive routing updates from multiple different paths and can check to see whether each update carries the identical origin AS list. Although a false origin may announce reachability to P, or alter the origin AS list, it would be difficult, if not impossible, to block the correct updates from propagating out, and thus remote ASes can detect the existence of false updates by observing the inconsistency of the received origin AS lists for P. Research studies show that the "allowed origin list" test can effectively detect the majority of falsely originated updates.
誤ったルーティング注入に対するセマンティックチェックを使用する別の例は、[44]に記載されています。基本的なアイデアは、有効な原点ASEのリストのプレフィックスPのルートアナウンスに添付することです。今日のインターネットトポロジの豊富な接続性により、複数の異なるパスからルーティングアップデートを受け取るリモートは、各更新がリストとして同一の原点を持つかどうかを確認することができます。誤った起源は、Pへの到達可能性を発表したり、原点をリストとして変更したりする可能性がありますが、不可能ではないにしても、伝播の正しい更新をブロックすることは困難です。P.のリストとして受信した原点の研究は、「許可されたオリジンリスト」テストが誤って発生した更新の大部分を効果的に検出できることを示しています。
Generally speaking, verifying the validity of BGP routes can be challenging because BGP is policy driven and policies of individual ISPs are not known in most cases. But assuming that policies do not change in short time scale, in principle one could verify new updates against observed routes from the recent past, which reflect the routing policies in place. Research work is needed to explore this direction.
Note that while the above steps are all fairly simple and don't really "bulletproof" the protocol, each adds some degree of protection. As such, the combination of the above techniques can result in an effective reduction in the probability of undetected faults.
上記の手順はすべてかなり単純であり、実際にはプロトコルを「防弾」していませんが、それぞれがある程度の保護を追加することに注意してください。そのため、上記の手法の組み合わせにより、検出されない断層の可能性が効果的に減少する可能性があります。
There exist a number of configuration tunings that can enhance robustness of BGP operations. One example is to let BGP peers coordinate the setting of a limit on the number of prefixes that one BGP speaker will send to its peer [43]. Although such a check does not validate the prefix owned by each peer, it can prevent false announcements of large numbers of invalid routes. Had all BGP routers been configured with this simple checking earlier, several large-scale routing outages in the past could have been prevented. Note, however, that care must be taken with hard limits of this type because they can be used to mount a DoS because implementations often discard excess routes indiscriminately, thus potentially causing black-holing of correct routes.
BGP操作の堅牢性を高めることができる多くの構成チューニングが存在します。1つの例は、BGPピアに、1つのBGPスピーカーがピアに送信する接頭辞の数の制限の設定を調整できるようにすることです[43]。このようなチェックは、各ピアが所有するプレフィックスを検証しませんが、多数の無効なルートの誤った発表を防ぐことができます。すべてのBGPルーターがこの簡単なチェックを以前に構成していた場合、過去のいくつかの大規模なルーティング停止が防止された可能性があります。ただし、実装が過剰なルートを無差別に廃棄し、したがって正しいルートのブラックホーリングを引き起こす可能性があるため、DOSをマウントするために使用できるため、このタイプの厳しい制限で注意を払わなければならないことに注意してください。
Another example of useful configuration tuning is to adjust the BGP's KeepAlive and Hold Timer values to minimize BGP peering session resets. Previous measurements show that heavy traffic load, such as those caused by worms, can cause BGP KeepAlive messages to be delayed or dropped, which in turn cause BGP peering session breakdown. Such load-induced session breaks and re-establishments can lead to an excessive amount of BGP updates during the periods when stable routing is needed most.
便利な構成チューニングのもう1つの例は、BGPのキープライブと保持タイマーの値を調整して、BGPピアリングセッションのリセットを最小限に抑えることです。以前の測定では、ワームによって引き起こされたものなど、交通量の多い負荷がBGPのキープライブメッセージを遅延または削除する可能性があることを示しています。このような負荷誘発セッションの破損と再確立は、安定したルーティングが最も必要な期間中に過剰な量のBGP更新につながる可能性があります。
In addition to the resource exhaustion problems that are generally apply to all end-systems, as described in Section 2, router implementations must also take special care in handling resource exhaustions when they occur in order to keep the router operating despite the problem. For example, under normal operations a router does not require a large cache to hold outstanding ARP requests because the replies are normally received within a few milliseconds. However, certain conditions can lead to ARP cache exhaustion, for example, during a virus attack where many packets are sent to non-existing IP addresses, thus there are no ARP replies to the requests for those addresses. Such phenomena have happened in the past and led to routers failing to forward packets.
セクション2で説明されているように、一般にすべての最終システムに適用されるリソースの使い果たしの問題に加えて、ルーターの実装は、問題にもかかわらずルーターが動作し続けるために、リソースの疲労を処理することに特に注意する必要があります。たとえば、通常の操作では、ルーターは、回答が通常数ミリ秒以内に受信されるため、未解決のARP要求を保持するために大きなキャッシュを必要としません。ただし、特定の条件は、たとえば、多くのパケットが存在しないIPアドレスに送信されるウイルス攻撃中にARPキャッシュの疲労につながる可能性があるため、それらのアドレスのリクエストに対するARP応答はありません。このような現象は過去に起こり、ルーターがパケットを転送できないことにつながりました。
Another example is queue management. Many high-end routers are designed so that most packets can be handled purely in specialized processors (Application-Specific Integrated Circuit (ASICs), Field Programmable Gate-Arrays (FPGAs), etc.). However, exceptional packets must be routed to a supporting general purpose CPU for handling. On some such systems, it may be possible mount a low-effort DoS attack by saturating the queues between the specialized hardware and the supporting processor.
別の例は、キュー管理です。多くのハイエンドルーターは、ほとんどのパケットを特殊なプロセッサ（アプリケーション固有の統合回路（ASIC）、フィールドプログラマブルゲートアレイ（FPGA）など）で純粋に処理できるように設計されています。ただし、例外的なパケットは、ハンドリングのためにサポートする汎用CPUにルーティングする必要があります。このようなシステムでは、特殊なハードウェアとサポートプロセッサの間のキューを飽和させることにより、低エフォルトDOS攻撃をマウントする可能性があります。
So the attack vector on routers/network devices is a low packets-per-second (PPS) queue saturation attack on the ASIC's raw queue structure. The countermeasure here is to have multiple such queues designed in such a way that it's difficult for an attacker to arrange to fill multiple queues [45].
したがって、ルーター/ネットワークデバイスの攻撃ベクトルは、ASICの生キュー構造に対する1秒あたりのパケット（PPS）キュー飽和攻撃です。ここでの対策は、攻撃者が複数のキューを埋めるように手配するのが難しいように、複数のそのようなキューを設計することです[45]。
Any system that instantiates per-connection state should take great care to implement state-lookup mechanisms in such a way that performance cannot be controlled by the attacker. One way to achieve this is to use hash tables where the hash mechanism is keyed in such a way that the attacker cannot instantiate a large number of flows in the same hash bucket.
接続ごとの状態をインスタンス化するシステムは、攻撃者がパフォーマンスを制御できないように、状態を見通したメカニズムを実装するために細心の注意を払う必要があります。これを達成する1つの方法は、攻撃者が同じハッシュバケットに多数のフローをインスタンス化できないように、ハッシュメカニズムがキーがキー化されるハッシュテーブルを使用することです。
Most operating systems use network interrupts to receive data from the network, which is a good solution if the host spends only a small amount of its time handling network traffic. However, this leaves the host open to livelock [33], where under heavy load the OS spends all its time handling interrupts and no time doing the work needed to handle the traffic at the application level. Server operating systems should consider using network polling at times of heavy load, rather than being interrupt-driven, and should be carefully architected so that as far as reasonably possible, traffic received by the OS is processed to completion or very cheaply discarded.
ほとんどのオペレーティングシステムは、ネットワーク割り込みを使用してネットワークからデータを受信します。これは、ホストがネットワークトラフィックの処理に少量しか費やしていない場合に適したソリューションです。ただし、これにより、ホストはLivelock [33]に開いたままになります。この場合、OSはすべての時間を費やして割り込みを処理する時間を費やし、アプリケーションレベルでトラフィックを処理するために必要な作業を行う時間はありません。サーバーオペレーティングシステムは、割り込み駆動型ではなく重い負荷の場合にネットワークポーリングの使用を検討する必要があり、OSが受け取ったトラフィックが完了または非常に安価に処理されるように、合理的に可能な限り可能な限り慎重にアーキテクチャ化する必要があります。
Most recent TCP implementations use fairly good random mechanisms for allocating the TCP initial sequence numbers. In general, any dynamically allocated value used purely to identify a communication session should be allocated using an unpredictable mechanism, as this increases the search space for an attacker that wishes to disrupt ongoing communications. Thus, the dynamically allocated port of the active end of a TCP connection might also be randomly allocated.
最新のTCP実装は、TCP初期シーケンス番号を割り当てるためにかなり良いランダムメカニズムを使用します。一般に、通信セッションを識別するために純粋に使用される動的に割り当てられた値は、予測不可能なメカニズムを使用して割り当てる必要があります。したがって、TCP接続のアクティブ端の動的に割り当てられたポートもランダムに割り当てられる可能性があります。
With DNS, the ID that is used to match responses with requests should also be randomly generated. However, as the ID field is only 16 bits, the protection is rather limited.
DNSでは、応答とリクエストを一致させるために使用されるIDもランダムに生成する必要があります。ただし、IDフィールドはわずか16ビットであるため、保護はかなり限られています。
Many DoS attacks are generic bandwidth consumption attacks that operate by clogging the link that connects the victim server to the Internet. Filtering these attacks at the server does no good because the traffic has already traversed the link that is the scarce resource. Such flows need to be filtered at some point closer to the attacker. Where possible, operators should filter out obviously bad traffic. In particular, they should perform ingress filtering [7].
多くのDOS攻撃は、被害者サーバーをインターネットに接続するリンクを詰まらせることで動作する一般的な帯域幅消費攻撃です。サーバーでのこれらの攻撃のフィルタリングは、トラフィックが既に希少なリソースであるリンクを横断しているため、良くありません。このようなフローは、攻撃者に近いある時点でろ過する必要があります。可能であれば、オペレーターは明らかに悪いトラフィックを除外する必要があります。特に、彼らは侵入フィルタリングを実行する必要があります[7]。
Network operators are strongly encouraged to establish a monitoring framework to detect and log abnormal network activity. One cannot defend against an attack that one doesn't detect or understand. Such monitoring tools can be used to set a baseline of "normal" traffic, and can be used to detect aberrant flows and determine the type and source of the aberrant flows. This is extremely helpful when responding to distributed DoS attacks or a flash crowd, and should be in place prior to the event.
ネットワークオペレーターは、異常なネットワークアクティビティを検出および記録するための監視フレームワークを確立することを強くお勧めします。検出したり理解したりしない攻撃から守ることはできません。このような監視ツールは、「通常の」トラフィックのベースラインを設定するために使用でき、異常な流れを検出し、異常なフローのタイプとソースを決定するために使用できます。これは、分散したDOS攻撃またはフラッシュクラウドに対応する場合に非常に役立ち、イベントの前に配置する必要があります。
In this document, we have highlighted possible avenues for DoS attacks on networks and networked systems, with the aim of encouraging protocol designers and network engineers towards designs that are more robust. We have discussed partial solutions that reduce the effectiveness of attacks, and highlighted how some partial solutions can be taken advantage of by attackers to perpetrate alternative attacks.
このドキュメントでは、プロトコルデザイナーとネットワークエンジニアをより堅牢なデザインに向けて奨励することを目的として、ネットワークとネットワークシステムに対するDOS攻撃の可能性のある手段を強調しました。攻撃の有効性を低下させる部分的なソリューションについて議論し、攻撃者が代替攻撃を実行するためにいくつかの部分的なソリューションをどのように利用できるかを強調しました。
Our focus has primarily been on protocol and network architecture issues, but there are many things that network and service operators can do to lessen the threat. Further advice and information for network operators can be found in [24] [39] [25].
私たちの焦点は主にプロトコルとネットワークアーキテクチャの問題にありましたが、ネットワークおよびサービスオペレーターが脅威を軽減するためにできることはたくさんあります。ネットワークオペレーターのさらなるアドバイスと情報は、[24] [39] [25]にあります。
It is our hope that this document will spur discussion leading to architectural solutions that reduce the succeptibility of all Internet systems to denial-of-service attacks.
このドキュメントが、すべてのインターネットシステムのサービス拒否攻撃に対する容易性を低下させる建築ソリューションにつながる議論を促進することを願っています。
This entire document is about security.
このドキュメント全体はセキュリティに関するものです。
We are very grateful to Vern Paxson, Paul Vixie, Rob Thomas, Dug Song, George Jones, Jari Arkko, Geoff Huston, and Barry Greene for their constructive comments on earlier versions of this document.
Vern Paxson、Paul Vixie、Rob Thomas、Dug Song、George Jones、Jari Arkko、Geoff Huston、およびBarry Greeneに、この文書の以前のバージョンに関する建設的なコメントに感謝しています。
[1] J. Abley, "Hierarchical Anycast for Global Service Distribution", http://www.isc.org/index.pl?/pubs/tn/ index.pl?tn=isc-tn-2003-1.txt.
[1] J. Abley、「グローバルサービスディストリビューション用の階層的なanycast」、http://www.isc.org/index.pl?/pubs/tn/ index.pl?tn=isc-tn-2003-1.txt。
[2] D.J. Bernstein, "SYN Cookies", http://cr.yp.to/syncookies.html.
[2] D.J.Bernstein、「Syn Cookies」、http：//cr.yp.to/syncookies.html。
[3] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.
[3] Chen、E。、「BGP-4のルートリフレッシュ機能」、RFC 2918、2000年9月。
[4] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[4] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[5] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[6] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[6] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、「プロトコル独立マルチキスト - スパースモード（PIM -SM）：プロトコル仕様（改訂）」、RFC 4601、2006年8月。
[7] 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.
[7] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[8] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004.
[8] Gill、V.、Heasley、J。、およびD. Meyer、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 3682、2004年2月。
[9] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[9] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[10] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[10] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[11] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[11] Villamizar、C.、Chandra、R。、およびR. Govindan、「BGP Route Flap Damping」、RFC 2439、1998年11月。
[12] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[12] Waitzman、D.、Partridge、C。、およびS. Deering、「距離ベクトルマルチキャストルーティングプロトコル」、RFC 1075、1988年11月。
[13] L. von Ahn, M. Blum, N. Hopper, and J. Langford. CAPTCHA: Using hard AI problems for security. In Proceedings of Eurocrypt, 2003.
[13] L. von Ahn、M。Blum、N。Hopper、およびJ. Langford。CAPTCHA：セキュリティのためにハードAIの問題を使用します。2003年のEuroCryptの議事録。
[14] T. Aura, P. Nikander, J. Leiwo, "DOS-resistant authentication with client puzzles", In B. Christianson, B. Crispo, and M. Roe, editors, Proceedings of the 8th International Workshop on Security Protocols, Lecture Notes in Computer Science, Cambridge, UK, April 2000.
[14] T. Aura、P。Nikander、J。Leiwo、「クライアントパズルによるドス耐性認証」、B。クリスチャンソン、B。クリスポ、およびM.ロー、編集者、セキュリティプロトコルに関する第8回国際ワークショップの議事録、講義ノート2000年4月、英国ケンブリッジのコンピューターサイエンス。
[15] J. Bellardo, S. Savage, "802.11 Denial-of-Service Attacks: Real Vulnerabilities and Practical Solutions", Proceedings of the USENIX Security Symposium, Washington D.C., August 2003.
[15] J. Bellardo、S。Savage、「802.11サービス拒否攻撃：真の脆弱性と実用的なソリューション」、2003年8月、ワシントンD.C.のUsenix Security Symposiumの議事録。
[16] S.M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", Computer Communication Review, Vol. 19, No. 2, pp. 32-48, April 1989.
[16] S.M.Bellovin、「TCP/IPプロトコルスイートのセキュリティ問題」、Computer Communication Review、Vol。19、No。2、pp。32-48、1989年4月。
[17] CCAIS/RNP Alertas do Cais ALR-19112002a, "Vulnerability in the sending requests control of Bind versions 4 and 8 allows DNS spoofing", http://www.rnp.br/cais/alertas/2002/cais-ALR-19112002a.html.
[17] ccais/rnp alertas do cais alr-19112002a、「bindバージョン4および8の送信要求制御の脆弱性により、dnsスプーフィングが可能になります」、http://www.rnp.br/cais/alertas/2002/cais-alr-19112002a。HTML。
[18] CERT Advisory CA-1996-01, "UDP Port Denial-of-Service Attack", Feb 1996.
[18] CERT Advisory CA-1996-01、「UDPポートサービス拒否攻撃」、1996年2月。
[19] CERT Advisory CA-1996-21, "TCP SYN Flooding and IP Spoofing Attacks", Sept 1996.
[19] CERT Advisory CA-1996-21、「TCP Syn洪水とIPスプーフィング攻撃」、1996年9月。
[20] CERT Advisory CA-2001-09, "Statistical Weaknesses in TCP/IP Initial Sequence Numbers", May 2001.
[20] CERT Advisory CA-2001-09、「TCP/IP初期シーケンス番号の統計的弱点」、2001年5月。
[21] CERT Advisory CA-1996-26, "Denial-of-Service Attack via ping", Dec 1996.
[21] CERT Advisory CA-1996-26、「Pingによるサービス拒否攻撃」、1996年12月。
[22] CERT Advisory CA-1998-01, "Smurf IP Denial-of-Service Attacks", http://www.cert.org/advisories/CA-1998-01.html, Jan 1998.
[22] Cert Advisory CA-1998-01、「Smurf IP denial-of-Service攻撃」、http：//www.cert.org/advisories/CA-1998-01.html、1998年1月。
[23] CERT Incident Note IN-2000-05, "'mstream' Distributed Denial of Service Tool", May 2000.
[23] 2000年5月、2000年5月の「「MSTREAM」分散拒否ツール」、2000年5月の証明書。
[24] CERT/CC - "Managing the Threat of Denial of Service Attacks", http://www.cert.org/archive/pdf/Managing_DoS.pdf.
[24] CERT/CC-「サービス拒否の脅威の管理」、http://www.cert.org/archive/pdf/managing_dos.pdf。
[25] CERT/CC - "Trends in Denial of Service Attack Technology", http://www.cert.org/archive/pdf/DoS_trends.pdf.
[25] CERT/CC-「サービス拒否攻撃テクノロジーの動向」、http：//www.cert.org/archive/pdf/dos_trends.pdf。
[26] D.F. Chang, R. Govindan, J. Heidemann, "An Empirical Study of Router Response to Large Routing Table Load", Proceedings of the 2nd Internet Measurement Workshop (IMW 2002), 2002.
[26] D.F.Chang、R。Govindan、J。Heidemann、「大規模なルーティングテーブル負荷に対するルーター応答の経験的研究」、第2インターネット測定ワークショップ（IMW 2002）の議事録、2002年。
[27] Cisco Systems, "Configuring the BGP Maximum-Prefix Feature", Cisco Document ID: 25160, http://www.cisco.com/warp/public/459/bgp-maximum-prefix.html.
[27] Cisco Systems、「BGP Maximum-Prefix機能の構成」、Cisco Document ID：25160、http：//www.cisco.com/warp/public/459/bgp-maximum-prefix.html。
[28] Scott A Crosby and Dan S Wallach, "Denial of Service via Algorithmic Complexity Attacks", Proceedings of the USENIX Security Symposium, Washington D.C., August 2003.
[28] Scott a Crosby and Dan S Wallach、「アルゴリズムの複雑さ攻撃によるサービス拒否」、2003年8月、ワシントンD.C.のUsenix Security Symposiumの議事録。
[29] Laurent Joncheray, "Simple Active Attack Against TCP", 5th USENIX Security Symposium, 1995.
[29] Laurent Joncheray、「TCPに対する簡単なアクティブ攻撃」、第5回USENIXセキュリティシンポジウム、1995年。
[30] M. Lough, "A Taxonomy of Computer Attacks with Applications to Wireless", PhD thesis, Virginia Polytechnic Institute, April 2001.
[30] M. Lough、「ワイヤレスへのアプリケーションによるコンピューター攻撃の分類法」、博士論文、バージニア工科大学、2001年4月。
[31] Z. Mao, R. Govindan, G. Varghese, R. Katz, "Route Flap Dampening Exacerbates Internet Routing Convergence", Proceedings of ACM SIGCOMM, 2002.
[31] Z. Mao、R。Govindan、G。Varghese、R。Katz、「ルートフラップ減衰はインターネットルーティングの収束を悪化させます」、ACM Sigcommの議事録、2002年。
[32] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[32] Fenner、B.、ed。、およびD. Meyer、ed。、「マルチキャストソースディスカバリープロトコル（MSDP）」、RFC 3618、2003年10月。
[33] J. Mogul, KK. Ramakrishnan, "Eliminating Receive Livelock in an Interrupt-driven Kernel", ACM Transactions on Computer Systems, Vol 15, Number 3, pp. 217-252, 1997.
[33] J.モーグル、KK。Ramakrishnan、「中割り込み駆動型カーネルでのリベロックを排除する」、コンピューターシステムのACMトランザクション、Vol 15、Number 3、pp。217-252、1997。
[34] Watson, P., "Slipping in the Window: TCP Reset attacks", Presentation at 2004 CanSecWest, http://www.cansecwest.com/archives.html.
[34]
[35] V. Paxson, "An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks", Computer Communication Review 31(3), July 2001.
[35] V. Paxson、「分散型サービス拒否攻撃にリフレクターを使用することの分析」、コンピューター通信レビュー31（3）、2001年7月。
[36] Joe Stewart, "DNS Cache Poisoning - The Next Generation", Jan 27 2003, http://www.lurhq.com/dnscache.pdf.
[36] Joe Stewart、「DNSキャッシュ中毒 - 次世代」、2003年1月27日、http：//www.lurhq.com/dnscache.pdf。
[37] Stewart, R., Ed., and M. Dalal, Ed., "Improving TCP's Robustness to Blind In-Window Attacks", Work in Progress, June 2006.
[37] Stewart、R.、ed。、およびM. Dalal、ed。、「Window In Window攻撃に対するTCPの堅牢性の向上」、2006年6月、進行中の作業。
[38] P. Vixie, G. Sneeringer, M. Schleifer, "Events of 21-Oct-2002", http://f.root-servers.org/october21.txt.
[38] P. Vixie、G。Sneeringer、M。Schleifer、「21-OCT-2002のイベント」、http：//f.root-servers.org/october21.txt。
[39] P. Vixie, "Securing the Edge", http://www.icann.org/committees/security/sac004.txt.
[39] P. Vixie、「Edgeのセキュリティ」、http：//www.icann.org/committees/security/sac004.txt。
[40] D. Wessels, "Running An Authoritative-Only BIND Nameserver", http://www.isc.org/index.pl?/pubs/tn/ index.pl?tn=isc-tn-2002-2.txt.
[40] D. Wessels、「権威のある専用バインドネームサーバーの実行」、http://www.isc.org/index.pl?/pubs/tn/ index.pl?tn=isc-tn-2002-2.txt。
[41] M. Zalewski, "Strange Attractors and TCP/IP Sequence Number Analysis", http://www.bindview.com/Services/Razor/Papers/2001/tcpseq.cfm.
[41] M. Zalewski、「奇妙なアトラクタとTCP/IPシーケンス番号分析」、http：//www.bindview.com/services/razor/papers/2001/tcpseq.cfm。
[42] D. Pei, X. Zhao, L. Wang, D. Massey, A. Mankin, F. S. Wu, and L. Zhang. Improving BGP Conver-gence Through Assertions Approach. In Proc. of IEEE INFOCOM, June 2002.
[42] D. Pei、X。Zhao、L。Wang、D。Massey、A。Mankin、F。S。Wu、およびL. Zhang。アサーションアプローチを通じてBGPコンバージェンスを改善します。Proc。IEEE Infocom、2002年6月。
[43] Chavali, S., Radoaca, V., Miri, M., Fang, L., and S. Hares, "Peer Prefix Limits Exchange in BGP", Work in Progress, April 2004.
[43] Chavali、S.、Radoaca、V.、Miri、M.、Fang、L。、およびS. Hares、「ピアプレフィックス制限BGP」、2004年4月、作業中の作業。
[44] X. Zhao, D. Massey, A. Mankin, S.F. Wu, D. Pei, L. Wang, L. Zhang, "BGP Multiple Origin AS (MOAS) Conflicts", http://nanog.org/mtg-0110/lixia.html, 2001.
[44] X. Zhao、D。Massey、A。Mankin、S.F。Wu、D。Pei、L。Wang、L。Zhang、「BGP Multise Origin as（MOAS）競合」、http://nanog.org/mtg-0110/lixia.html、2001。
[45] Cisco Systems, "Building Security Into the Hardware", ftp://ftp-eng.cisco.com/cons/isp/security/CPN-Summit-2004/ Paris-Sept-04/SE14-BUILDING-SECURITY-INTO-THE-HARDWARE-c1_8_30_04.pdf, 2004.
[45]
[46] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[46] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）プロトコルアーキテクチャ」、RFC 4251、2006年1月。
[47] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, April 2004.
[47] Hinden、R。、「仮想ルーター冗長プロトコル（VRRP）」、RFC 3768、2004年4月。
[48] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[48] Harrington、D.、Presuhn、R。、およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMP）管理フレームワークを説明するためのアーキテクチャ」、STD 62、RFC 3411、2002年12月。
[49] Malkin, G. and A. Harkin, "TFTP Timeout Interval and Transfer Size Options", RFC 2349, May 1998.
[49] Malkin、G。およびA. Harkin、「TFTPタイムアウト間隔と転送サイズオプション」、RFC 2349、1998年5月。
[50] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[50]
[51] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[51] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[52] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[52] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[53] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988.
[53] Hedrick、C。、「ルーティング情報プロトコル」、RFC 1058、1988年6月。
o Bernard Aboba
o バーナード・アボバ
o Loa Andersson
o ロア・アンダーソン
o Brian Carpenter
o ブライアンカーペンター
o Leslie Daigle
o レスリー・ダイグル
o Elwyn Davies
o エルウィン・デイビス
o Kevin Fall
o ケビンフォール
o Olaf Kolkman
o オラフ・コルマン
o Kurtis Lindvist
o Kurtis Lindvist
o David Meyer
o デビッド・マイヤー
o David Oran
o デビッド・オラン
o Eric Rescorla
o エリック・レスカラ
o Dave Thaler
o デイブ・タラー
o Lixia Zhang
o リキシア・チャン
Authors' Addresses
著者のアドレス
Mark J. Handley, Ed. UCL Gower Street London WC1E 6BT UK
マークJ.ハンドリー編UCL Gower Street London WC1E 6BT UK
EMail: M.Handley@cs.ucl.ac.uk
Eric Rescorla, Ed. Network Resonance 2483 E. Bayshore #212 Palo Alto 94303 USA
エリック・レスコルラ編ネットワーク共鳴2483 E. Bayshore＃212 Palo Alto 94303 USA
EMail: ekr@networkresonance.com
Internet Architecture Board IAB
インターネットアーキテクチャボードIAB
EMail: iab@ietf.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。