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).
著作権（C）IETFトラスト（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）を使用してビジネスを行う企業、国、または上の任意の組み合わせまたは変異体とすることができますこれら。 DoS攻撃は、ネットワークやコンピューティングリソースへの不正アクセスを獲得伴うかもしれないが、この文書の大部分は、我々はサービス拒否攻撃自体は被害者のコンピューティング施設の妥協を伴わない場合に焦点を当てます。
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のためのTCP接続を終端の観点[10]またはSSH [46]からエンドシステムです。
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サーバがデータを提供する（データベースなど）バックエンドソフトウェアをクラッシュさせることが可能かもしれません。
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.
不良による符号化とソフトウェアがクラッシュしただけでなく、アプリケーションソフトウェアに影響を与えるだけでなく、オペレーティングシステムのカーネルそのもの。古典的な例は、[21] 1996年に広く知られるようになったこれは、いわゆる「死のピング」です。これは、そのフラグメント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.
そのような死のピングなどの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.
CPUサイクルを利用できるO。
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の設計に）クラッシュさせます。
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フラッド[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攻撃は、本質的に被害者のCPU疲労困憊攻撃ですACK-洪水[23]、です。攻撃者は、確立されたことがない接続からのふりを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.
（CPUなど）いくつかのリソースが飽和するまで、着信トラフィックが増加するにつれて、O、OSによって行わ有用な仕事を増やすべきです。
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.
しかし、これは多くの場合、そうではありません。多くのシステムはどこ、飽和した後、負荷を増加させることが行われ、有用な作業を低下させる原因となる[33]ライブロックに苦しんでいます。この原因の一つは、システムが処理されていない、ので、時間の減少量は、これらのパケットが意図されたためにアプリケーションで使用可能であることが決してパケットのための時間処理ネットワーク割り込みの増加量を費やしているということです。
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サーバの場合には、おそらく最も一般的です。攻撃者は、急速にこのクォータを排出することができるよう、サービスが中断される可能性があります。同様の攻撃は、クォータの他の形態に対しても可能です。
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.
ルータのネットワーク上の最も単純な攻撃は、ルータがメモリの不足、またはルータが経路[26]を処理するのに十分なCPUパワーを有する十分に多くのルートがルーティングテーブルをオーバーロードすることです。私たちは、ネットワークの周りの様々なルーターの分布と能力に応じて、このような攻撃は、攻撃ルータの近くにルータを圧倒しない場合がありますのでご注意ますが、問題はネットワークの他の場所に表示することがあります。
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.
より微妙なDoS攻撃は、ネットワークに対してではなく、先に対して実行される可能性があります。いくつかの状況下では、一貫性のないルーティング情報の伝搬がループにトラフィックを引き起こす可能性があります。攻撃者は、これが忙しいパスで発生することがあります場合は、ループトラフィックが大幅に渋滞を引き起こすだけでなく、合法的な目的地に到達するために失敗することがあります。
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.
RFC 1112で指定されるように伝統的な任意-ソースマルチキャスト（ASM）、[4]複数のソースが同一のマルチキャストグループに送信することができ、及び受信機が指定しなければならないソース固有マルチキャスト（SSM）：2つのIPマルチキャストの形態は、本質的に存在します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.
多くの現代のルータは、一つ以上の制御プロセッサは、ルーティングプロトコルを処理する疎結合アーキテクチャを使用して、実際にデータトラフィックを転送専用のフォワーディングエンジン、内部ネットワーク・リンクを介して通信します。攻撃者は、制御プロセッサ及び転送エンジンとの間の通信リンクを圧倒するようなアーキテクチャでは、それが可能であってもよいです。フォワーディングエンジンは非常に高速リンクをサポートするので、これは可能であり、制御プロセッサは、単にトラフィックの同様の速度を扱うことができません。
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.
このような内部コミュニケーションを過負荷の影響を予測するのは難しいですし、非常に実装依存です。一つの可能な効果は、フォワーディングエンジンでの転送テーブルはルーティングプロトコルが起こっていると考えているものを反映した制御プロセッサにルーティングテーブルとの同期から外れていることかもしれません。これは、トラフィックが廃棄またはループにされることがあります。
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
攻撃者は、進行中の通信を破壊するために、エンドシステム自体を攻撃するのではなく、それも可能です。攻撃者は、TCPコネクションを観察することができれば、彼らが何の更なる進展がないことができるように、それをその接続をリセットしたりするために、脱同期化するためのいずれかのパケットを偽装するために、それは、[29]は比較的容易です。このような攻撃はありません
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パケットの処理を完了した後に認証が行われるので、輸送又は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.
このような攻撃の例としては、攻撃者が被害者のUDPエコーポートに送信されたパケットの送信元アドレスを偽装し[18]、に記載されています。送信元アドレスは、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（Dynamic Host Configuration Protocol）サーバによって割り当てられたアドレスプールを排出することによって、すべてのネットワークにアクセスしてから、他のローカルホストを防ぐことができるかもしれません。これは、イーサネットや無線LANカードの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.
ブロードキャストMACアドレスにユニキャストIPパケットのストリームを送信することにより、ローカルLAN上のブロードキャストストーム[16]を起こすことも可能です。 LAN上のいくつかのホストはその後、大幅にLAN上のトラフィックを増幅し、正しいMACアドレスにパケットを転送しようとすることができます。
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.
それにも関わらず、より洗練された攻撃に対するプロトコルの弱点のいくつかは注目に値します。これらの最も顕著なのは関連性は、このように、不正なアクセスポイント（AP）がそうでない場合は、正当な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基地局は、彼らがサポートできる団体の数のメモリが限られています。これを超えた場合、彼らはすべての関連付けをドロップすることがあります。負荷の少ないいる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とサベージ[15]は、このような攻撃の有効性を減らすいくつかの簡単な救済策について説明します。 IEEE 802.11ワットは認証解除を保護したり、フレームの関連付けを解除しますが、この攻撃は、協会のフレームの鍛造を経ても可能です。
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の存在を検出するための無線ネットワークでは、それが必要です。 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.
ステーションはそれが通信することを望むかもしれないAPSた発見するために認証する前に、それらを活用する必要があるため、ビーコンは、簡単に、暗号化することはできません。認証はビーコンのみを解釈した後に発生する可能性がありますので、暗号化されたビーコンは、鶏卵の問題を提示する：あなたは、認証を完了するまで、ビーコンを復号化するための鍵を得ることができない、とあなたは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.
その結果、ビーコンフレームセキュリティの議論は、主にビーコンフレームではなく、暗号化の認証に焦点を当てています。ここでも、解決策は難しいです。ステーションは、*の認証後（4ウェイハンドシェイクの間にAPまたはビーコンパラメータを検証することによって提供されるグループ鍵を用いて計算され、メッセージ整合性チェック（MIC）をチェックすることによってのいずれかで）ビーコン*を検証することが可能かもしれないが、やっそう*前*認証は、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攻撃[38]に供したとき、これは2002年10月に実証されました。ルートネームサーバの数がのでエニーキャストを使用して複製されている[1]さらに、DoS攻撃に対する耐性を向上させます。しかし、権威サーバが無効になっ中継持っているために重要である、または攻撃者が状態[40]を保持するためにDNSサーバを強制することが可能です。
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攻撃の形態とみなすことができます。したがって、1回の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を含むそれぞれが、その後、偽造のいずれかの応答が正しい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サービスのためのエニーキャストの使用は、スプーフィング攻撃にそれがさらに脆弱になります。彼の偽のDNSサーバにエニーキャストルートを受け入れるようにISPを説得することができ、攻撃者は、要求を受信し、偽の応答を生成するために手配することができます。エニーキャストDNSはまた、DNS上のDoS攻撃が容易になります。アイデアは、そのサーバーへのBGPルートを維持しながら、DNSサーバーのいずれかを無効にすることです。これは、（今は亡き）サーバーにルーティングされた任意のクライアントのための障害を作成します。
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または簡易ネットワーク管理プロトコル（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.
病理学的構造の場合、攻撃者は、最悪の場合の挙動を示すために、ファイアウォールのデータ構造の原因となるトラフィックを送信します。ファイアウォールが転送状態を調べるために、ハッシュテーブルを使用する場合、この例のようになり、攻撃者が使用するハッシュ関数を予測することができます。攻撃者は次いで、ファイアウォールのルックアップ性能は、nが数は、攻撃者ができ流れるO（N）とO（1）から変化させ、同じバケットにハッシュするフロー状態を大量に、生じさせることができるかもしれませんインスタンス化[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;侵入）のファイアウォールと同様の問題を抱えています。攻撃者がメモリから実行する、または病理学的構造の状態をインスタンス化するために、その利用可能な処理能力を排出するIDSを引き起こすことが可能であってもよいです。ファイアウォールとは異なり、IDSは通常、IDSで保護されたシステムへのサービスを拒否していないであろう、オープンに失敗します。しかし、それはIDSが検出されているであろうと、後続の攻撃が見逃されるだろうことを意味します。
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は、反応性です。つまり、敵対的なイベントの検出時に、彼らは敵対的システムから後続のトラフィックをブロックする、またはそのシステムからの継続的な接続を終了するように反応します。攻撃者は正当なシステムからのパケットを偽装、ひいてはIDSシステムが敵対的であると信じさせることが可能です。 IDSは、それゆえにへのサービス拒否攻撃、ブロックする正当なシステムからのトラフィックが発生します。正当なシステムは、その性能の他のシステムの多数の動作のために必須であるルータ、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.
ネットワークタイムサーバは、一般的に、セキュリティクリティカルなサービスとはみなされないが、いくつかの状況下でNTPサーバは、DoS攻撃を犯すために使用される可能性があります。
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.
最も明白な攻撃は、DoS攻撃のNTPサーバー自体にあります。多くのエンドシステムはかなり貧弱クロック精度を持っているので、ネットワークの時間にアクセスすることなく、彼らの時計は自然にドリフトします。これは良いクロックに依存している分散システムで問題が発生する可能性があります。それは未来にあるように修正タイムスタンプを知覚する場合たとえば、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つの機構は、ブラックホールリストの使用です。ダイヤルアップのISPやスパムを発信または中継するために使用するメールサーバのIPアドレスがブラックホールリストに追加されます。メールの受信者は、これらのリストに相談し、それが由来するか、リスト上のシステムによって中継されている場合、スパムを拒否することを選択しました。このようなリストで1つの重要な問題は、攻撃者は被害者がスパムの中継を担当しなかった場合でも、被害者がブラックホールリストされていることを引き起こすことが可能であることです。したがって、ブラックホールリスト自体は、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.
最も簡単なこのような攻撃は、被害者のスプーフィングされた送信元アドレスを持つICMPエコー要求パケットを増幅器として使用するネットワークのサブネットブロードキャストアドレスに送信され、「スマーフ」攻撃[22]でした。そのサブネット上のすべてのシステムは、その後、被害者に返す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を送信します。被害者に送信されたACKを、そして何の最終ACKがハンドシェイクを完了するために、受信されないとき、SYN | |サーバーは、SYNで応答しますACKは、回数を再送します。一般的に、この攻撃は反射器として任意に選択されたサーバの非常に大きなリストを使用しています。 ACK |攻撃を成功させるために、反射鏡は、SYNに応じて、被害者からのRSTを受けてはなりません。攻撃トラフィックが十分にサーバーへのサーバーまたはアクセスリンクを圧倒している場合しかし、その後、パケットロスが多くの反射が彼らのSYNに応じて、RSTを受信しないことを保証します| ACK、及びその再送信し続けます。 RSTを送信せずにACK |攻撃は黙って入ってくるSYNをドロップするファイアウォールによって悪化することができます。
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.
増幅の他の変形は、後続のメッセージを送信すべきプロトコル・ペイロード、ホストのIPアドレスまたは名前の中に含まれるプロトコルで起こります。そのようなプロトコルの例は、セッション記述プロトコル（SDP）によって定義されたペイロードを搬送するセッション開始プロトコル（SIP）[50]、[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 INVITEパケットを、典型的には数百バイトを行う場合、SIPの特定の場合では、ほぼ連続的な流れをもたらすことができますどこでもメガビット毎秒への第2のアップ当たり数キロビットからレートでメディアパケット。この特定の攻撃は、「ボイス・ハンマー」と呼ばれています。
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.
上記の他の技術とは異なり、この技術は、パケットを変更したりしても、その送信元IPアドレスを偽装するために、攻撃者を必要としません。これは、簡単に起動することができます。
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ハンドシェークは、クライアントの送信元アドレスを検証するために行われていない限り、要求のサイズよりかなり大きい応答を返すことができるプロトコルやメカニズムを設計することは避けてください。そのようなハンドシェークプロトコルの増幅の影響を緩和するために十分安全である予測不可能なnonceを組み込む必要があります。
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を持つよりも一般的な経験である - それは、自身の名前を取得していますので、一般的な：スラッシュドットまたはFarkedされ、フラッシュ群衆の一般的な供給源であるウェブサイトの後。それが予見可能な合法的なピーク負荷を処理できるように、このように、DoS攻撃に対する防御の最初の行は提供あなたのサービスにする必要があります。 Underprovisionedサイトがテイクダウンするのが最も簡単です。
Specific strategies for DoS defense fall into two broad categories:
2つの広いカテゴリーにDoS攻撃防御の秋のための具体的な戦略：
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.
ビューのエンドシステムのサーバーの観点から、簡単な一の目的は、自分のアドレスを確認するには、クライアントとのハンドシェイクを完了せずに状態をインスタンス化を避けるために、可能な限り、クライアントに仕事とstateholdingをプッシュすることです。 SYNクッキーなど、これを行うために使用されるかもしれない多くの技術があり、[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を再起動するか、一つ以上のピアリングをシャットダウン[26]：それが受信したルートを保存することができないBGPルータは、二つの選択肢を有しています。これは、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.
自動設定メカニズムを大幅に導入を容易にし、ネットワーク接続されたデバイスの数を手動で管理することができるものを超えて大きくなるにつれて、ますます必要です。しかし、認証されていない自動設定は、攻撃のための多くの道を開くことを認識すべきです。コンフィギュレーションの構成およびセキュリティの容易さとの間の明確な張力が単位が効果的に認証なし（例えば、空港のホットスポット）で動作することが望まれる環境があるため、特に、存在します。将来の自動設定プロトコルが異なるエンドシステムが同じ自動設定の枠組みの中で、このスペクトルの異なる点で動作できるようにする必要性を検討すべきです。しかし、これはまた、ネットワーク要素が認証されていないホストのために働く避けるべきであることを意味だけではなく、彼らは多かれ少なかれ直接ネットワークにアクセスさせます。
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.
一般に、ネットワークはでプロビジョニングされるべきプライベート、コンソールまたは制御ポートへのアクセスは、このような制御機能は、（インバンドのコントロールまたはデータプレーンのいずれかに対して起動DoS攻撃の面で利用可能になるように、アウトオブバンド） 通信網。典型的には、このようなアウトオブバンドネットワークは、まさにこの目的のために別々のインフラストラクチャ上でプロビジョニングされています。 （例えばルーティングまたはネットワーク管理トラフィックの優先順位付けなど）は、典型的な冗長性および容量管理技術の多くはこのような攻撃中に失敗するので、帯域外アクセスは、DoS攻撃を緩和するための重要な能力です。彼らは生きている隣接関係を維持できない可能性がありますように加えて、このようなVRRP [47]など多くの冗長化プロトコルは、このような攻撃の中に失敗することができます。
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.
失敗を処理するためのシステムを設計の基本原理は1つが失敗した場合に引き継ぐことができる冗長サーバを持つことです。これは、多くの場合、特定のサーバーおよび/またはリンクに焦点を当て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:
プロトコル構文は、プロトコル・メッセージとの交換のルールの形成を定義します。プロトコルの構文チェックによって対処の質問は、これらに限定されないが、以下：
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.
プロトコル構文検証の最初のステップは、着信メッセージが正当な当事者により送信されたことを保証することです。このチェックを実行するために複数の方法があります。一つは、送信元IPアドレスとメッセージのも、MACアドレスを確認することができます。 eBGPピアが正常に直接接続していることを利用し、一方は、パケット内のTTL値をチェックし、そのTTLある最大値未満である任意のBGPアップデートパケットを破棄することができる（典型的には、最大TTL - 1）[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].
プロトコルのセマンティクスは、値の解釈を、メッセージ内容の意味を定義し、アクションは内容に応じて撮影します。ここでは、セマンティックチェックを使用しての簡単な例です。リンク障害がプレフィックスPのための離脱メッセージBでは、ピアルータを送信するために自律システム（AS）A内のルータを起こした場合、Bは任意の代替パス、それはこの単純なチェックがあるPはA.経由しません到達するために見つけることを確認する必要があります有意に多い[42]におけるBGPの収束時間を改善することが示さ。
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]に記載されています。基本的な考え方は、プレフィックスPのルートの発表に有効な原点のASのリストを添付することです。今日のインターネットトポロジの豊富なコネクティビティに、リモートASは、複数の異なるパスからのルーティングアップデートを受信し、各アップデートがリストと同じ起源を運ぶかどうかを確認することができます。偽の起源はPに到達可能性を発表する、またはリストとしての原点を変更することができるが、それは、困難、不可能ではないだろう出て伝播する正しい更新をブロックするため、リモートのASは、矛盾を観察することにより、偽のアップデートの有無を検出することができます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.
BGPは、ほとんどの場合、ポリシー駆動され、個々のISPのポリシーが知られていないので、一般的に言って、BGPルートの妥当性を検証することは困難な場合があります。しかし、原理的には1が所定の場所にルーティングポリシーを反映して、最近の過去から観測されたルートに対する新しいアップデートを確認することができ、ポリシーは短い時間スケールで変化していないと仮定。研究活動は、この方向性を模索するために必要とされます。
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操作の堅牢性を向上させることができ、構成チューニングの数が存在します。一例では、BGPピア一個の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.
便利な設定のチューニングの別の例は、BGPのキープアライブを調整し、セッションのリセットを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節で説明したように、ルータの実装は、リソースexhaustionsの取り扱いに特別な注意を払う必要があります。例えば、通常の操作の下にルータが応答は、通常、数ミリ秒以内に受信されているため、優れたARP要求を保持するために大容量のキャッシュを必要としません。しかし、特定の条件がARPキャッシュの枯渇につながることができ、例えば、多くのパケットが存在しないIPアドレスに送信されたウイルスの攻撃中に、これ何の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の生のキュー構造上の低パケット毎秒（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.
ほとんどのオペレーティングシステムは、ネットワークがホストがその時のハンドリングネットワークトラフィックの量が少ない費やしている場合は良い解決策であるネットワークからデータを受信するために割り込みを使用します。しかし、これはホストがライブロックするために開いたまま、[33]、重い負荷の下でOSは、そのすべての時間の取り扱い割り込みとアプリケーションレベルでトラフィックを処理するのに必要な仕事をしていない時間を費やしています。 Serverオペレーティングシステムではなく、割り込み駆動型であることよりも、重い負荷のタイミングでネットワークのポーリングを使用して検討すべきである、と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.
ネットワークオペレータが強く検出し、異常なネットワーク活動をログに記録する監視フレームワークを確立することをお勧めします。一つは、1つの検出または理解していない攻撃を防御することはできません。そのような監視ツールは、「正常な」トラフィックのベースラインを設定するために使用することができ、異常な流れを検出し、異常な流れのタイプ及びソースを決定するために用いることができます。分散型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.
この文書は、サービス拒否攻撃にすべてのインターネットシステムのsucceptibilityを減らす建築ソリューションにつながる議論に拍車をかけるだろうという私たちの希望です。
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.
私たちは、この文書の以前のバージョンの彼らの建設的なコメントのためのバーン・パクソン、ポール・ヴィクシー、ロブ・トーマス、ダグの歌、ジョージ・ジョーンズ、ヤリArkko、ジェフ・ヒューストン、そしてバリー・グリーンに非常に感謝しています。
[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、 "階層エニーキャストグローバルサービスの分布"、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.バーンスタイン、 "SYNクッキー"、http://cr.yp.to/syncookies.html。
[3] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.
[3]チェン、E.、 "BGP-4のためのルートリフレッシュ機能"、RFC 2918、2000年9月。
[4] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[4]デアリング、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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]フェナー、B.、ハンドリー、M.、ホルブルック、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]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス拒否攻撃を破り"、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]ギル、V.、Heasley、J.、およびD.マイヤー、 "一般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.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル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.、チャンドラ、R.、およびR.ゴヴィンダン、 "BGPルートフラップダンピング"、RFC 2439、1998年11月。
[12] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[12] Waitzman、D.、ヤマウズラ、C.、およびS.デアリング、 "距離ベクトルマルチキャストルーティングプロトコル"、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.フォン安、M.ブルム、N.ホッパー、及びJ.ラングフォード。 CAPTCHA：セキュリティのためのハードAIの問題を使用します。 EUROCRYPT、2003年の議事録。
[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.
B. Christianson、B. Crispo、及びM.卵、編集者、セキュリティプロトコルに関する第8回国際ワークショップの議事録では[14] T.オーラ、P. Nikander、J. Leiwo、 "クライアントパズルとDOS耐性認証"、 、コンピュータサイエンス、ケンブリッジ、英国、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.サベージ、「802.11サービス拒否攻撃：実脆弱性と実用的なソリューション」、USENIXセキュリティシンポジウム、ワシントンD.C.、2003年8月。
[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プロトコルスイートのセキュリティ問題」、コンピュータコミュニケーションレビュー、巻。 19、第2頁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はカイスALR-19112002aを行い、http://www.rnp.br/cais/alertas/2002/cais-ALR、「バインドバージョン4,8の送信要求制御の脆弱性は、DNSスプーフィングを可能にします」 -19112002a.html。
[18] CERT Advisory CA-1996-01, "UDP Port Denial-of-Service Attack", Feb 1996.
[18] CERT勧告CA-1996から1901年、 "UDPポートサービス拒否攻撃"、1996年2月。
[19] CERT Advisory CA-1996-21, "TCP SYN Flooding and IP Spoofing Attacks", Sept 1996.
[19] CERT勧告CA-1996から1921年、 "TCPのSYNフラッドとIPスプーフィング攻撃"、1996年9月。
[20] CERT Advisory CA-2001-09, "Statistical Weaknesses in TCP/IP Initial Sequence Numbers", May 2001.
[20] CERT勧告CA-2001-09、 "TCP / IP初期シーケンス番号で統計的弱点"、2001年5月。
[21] CERT Advisory CA-1996-26, "Denial-of-Service Attack via ping", Dec 1996.
"pingを経由してサービス拒否攻撃" [21] CERT勧告CA-1996から26、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勧告CA-1998から1901年、 "スマーフIPサービス拒否攻撃"、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.
、2000年5月[23] CERTインシデント注IN-2000-05、 "サービスツールの拒否分散型 'mstream'"。
[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.チャン、R.ゴヴィンダン、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]シスコシステムズ、 "BGP最大プレフィクス機能の設定"、シスコドキュメント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]スコット・A・クロスビーとダン・Sウォラック、「アルゴリズムの複雑攻撃を経由してサービス拒否」、USENIXセキュリティシンポジウム、ワシントンD.C.、2003年8月。
[29] Laurent Joncheray, "Simple Active Attack Against TCP", 5th USENIX Security Symposium, 1995.
[29]ローラン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.ラフ、「ワイヤレスへのアプリケーションを搭載したコンピュータ攻撃の分類」、博士論文、バージニア工科大学、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.マオ、R.ゴヴィンダン、G. Varghese、R.カッツ、 "ルートフラップダンプニング悪化インターネットルーティング収束"、ACM SIGCOMM、2002年議事。
[32] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[32]フェナー、B.、エド。、およびD.マイヤー、エド。、 "は、Multicast Source Discovery Protocol（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。ラマクリシュナン、コンピュータシステム上のACMトランザクション、第15巻、3号、頁217から252まで、1997年「割り込み駆動型のカーネルでのライブロックを受信排除」。
[34] Watson, P., "Slipping in the Window: TCP Reset attacks", Presentation at 2004 CanSecWest, http://www.cansecwest.com/archives.html.
[34]ワトソン、P.、 "ウィンドウに滑り：TCPリセット攻撃"、プレゼンテーション2004たCanSecWest、http://www.cansecwest.com/archives.htmlで。
[35] V. Paxson, "An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks", Computer Communication Review 31(3), July 2001.
[35] V.パクソン、「分散型サービス妨害（DoS）攻撃の反射板を使用しての分析」、コンピュータコミュニケーションレビュー31（3）、2001年7月。
[36] Joe Stewart, "DNS Cache Poisoning - The Next Generation", Jan 27 2003, http://www.lurhq.com/dnscache.pdf.
[36]ジョー・スチュワート、 "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]スチュワート、R.、エド。、およびM. Dalal、エド。、進歩、2006年6月に、作業 "TCPのブラインドは、窓の攻撃に対するロバスト性を向上させます"。
[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 10月-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、 "エッジの保護"、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.
"権威のみのBINDのネームサーバの実行" [40] D.ウェッセル、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.ペイ、X.趙、L.ワング、D.マッシー、A.マンキン、F. S.ウー、およびL.チャン。アサーションのアプローチを通じてBGP CONVER-genceを向上させます。 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.、ミリ、M.、牙、L.、およびS.ノウサギ、 "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.趙、D.マッシー、A.マンキン、S.F.呉、D.ペイ、L.王、L.チャン、 "BGPの複数の起源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]シスコシステムズ、 "ハードウェアにビルセキュリティ"、ftp://ftp-eng.cisco.com/cons/isp/security/CPN-Summit-2004/パリ - 9月 - 04 / SE14-BUILDING-セキュリティにINTO-HARDWARE-c1_8_30_04.pdf、2004。
[46] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[46] Ylonenと、T.とC. Lonvick、 "セキュアシェル（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]ハリントン、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]マルキン、G.とA.ハーキン、 "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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[51] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[51]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "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.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[53] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988.
[53]ヘドリック、C.、 "ルーティング情報プロトコル"、RFC 1058、1988年6月。
Appendix A. IAB Members at the Time of This Writing
この記事の執筆時点では、付録A. IABメンバー
o Bernard Aboba
バーナードAboba O
o Loa Andersson
いいえロア・アンダーソンありません
o Brian Carpenter
Oブライアン・カーペンター
o Leslie Daigle
OレスリーDaigle氏
o Elwyn Davies
のエルウィン・デイヴィス
o Kevin Fall
Oケビン・秋
o Olaf Kolkman
オラフKolkman O
o Kurtis Lindvist
OカーティスLindqvist
o David Meyer
デビッド・マイヤーO
o David Oran
デビッド・オランO
o Eric Rescorla
エリックレスコラO
o Dave Thaler
デーブターラーO
o Lixia Zhang
張I OLの下で
Authors' Addresses
著者のアドレス
Mark J. Handley, Ed. UCL Gower Street London WC1E 6BT UK
マーク・J.ハンドリー、エド。 UCLガウアーストリートロンドンWC1E 6BT英国
EMail: M.Handley@cs.ucl.ac.uk
メールアドレス：M.Handley@cs.ucl.ac.uk
Eric Rescorla, Ed. Network Resonance 2483 E. Bayshore #212 Palo Alto 94303 USA
エリックレスコラ、エド。ネットワークレゾナンス2483 E.ベイショア第212位パロアルト94303 USA
EMail: ekr@networkresonance.com
メールアドレス：ekr@networkresonance.com
Internet Architecture Board IAB
インターネットアーキテクチャ委員会IAB
EMail: iab@ietf.org
メールアドレス：iab@ietf.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（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.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。