[要約] 要約：RFC 4987は、TCP SYNフラッディング攻撃の説明と一般的な対策についての情報を提供しています。 目的：このRFCの目的は、TCP SYNフラッディング攻撃に関する理解を深め、ネットワークのセキュリティを向上させるための対策を提供することです。
Network Working Group W. Eddy
Request for Comments: 4987 Verizon
Category: Informational August 2007
TCP SYN Flooding Attacks and Common Mitigations
TCP Syn洪水攻撃と一般的な緩和
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 (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks, but does not make any standards-level recommendations.
このドキュメントは、数年間コミュニティによく知られているTCP Syn洪水攻撃について説明しています。これらの攻撃に対するさまざまな対策、およびそれぞれのトレードオフについて説明します。このドキュメントは、TCP実装者とTCPサーバーまたはネットワークの管理者の利益のために、攻撃と一般的な防衛技術の説明をアーカイブしますが、標準レベルの推奨事項を作成しません。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Attack Description . . . . . . . . . . . . . . . . . . . . . . 2
2.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 3
3. Common Defenses . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Increasing Backlog . . . . . . . . . . . . . . . . . . . . 7
3.3. Reducing SYN-RECEIVED Timer . . . . . . . . . . . . . . . 7
3.4. Recycling the Oldest Half-Open TCB . . . . . . . . . . . . 7
3.5. SYN Cache . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. SYN Cookies . . . . . . . . . . . . . . . . . . . . . . . 8
3.7. Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 10
3.8. Firewalls and Proxies . . . . . . . . . . . . . . . . . . 10
4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
7. Informative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. SYN Cookies Description . . . . . . . . . . . . . . . 16
The SYN flooding attack is a denial-of-service method affecting hosts that run TCP server processes. The attack takes advantage of the state retention TCP performs for some time after receiving a SYN segment to a port that has been put into the LISTEN state. The basic idea is to exploit this behavior by causing a host to retain enough state for bogus half-connections that there are no resources left to establish new legitimate connections.
Syn Flooding Attackは、TCPサーバープロセスを実行するホストに影響を与えるサービス拒否法です。この攻撃は、TCPの状態保持を利用して、リスニング状態に入れられたポートにSynセグメントを受け取った後、しばらくの間実行されます。基本的なアイデアは、ホストが新しい正当なつながりを確立するためのリソースが残っていないという偽の半接続のために十分な状態をホストに保持することにより、この動作を悪用することです。
This SYN flooding attack has been well-known to the community for many years, and has been observed in the wild by network operators and end hosts. A number of methods have been developed and deployed to make SYN flooding less effective. Despite the notoriety of the attack, and the widely available countermeasures, the RFC series only documented the vulnerability as an example motivation for ingress filtering [RFC2827], and has not suggested any mitigation techniques for TCP implementations. This document addresses both points, but does not define any standards. Formal specifications and requirements of defense mechanisms are outside the scope of this document. Many defenses only impact an end host's implementation without changing interoperability. These may not require standardization, but their side-effects should at least be well understood.
このSyn洪水攻撃は長年にわたってコミュニティによく知られており、ネットワークオペレーターとエンドホストによって野生で観察されてきました。Synの洪水の効果を低下させるために、多くの方法が開発および展開されています。攻撃の悪名と広く利用可能な対策にもかかわらず、RFCシリーズは、脆弱性をイングレスフィルタリング[RFC2827]の動機として例として文書化し、TCP実装の緩和技術を提案していません。このドキュメントは両方のポイントに対処しますが、標準を定義しません。防衛メカニズムの正式な仕様と要件は、このドキュメントの範囲外です。多くの防御は、相互運用性を変更することなく、エンドホストの実装にのみ影響します。これらは標準化を必要としないかもしれませんが、それらの副作用は少なくともよく理解されるべきです。
This document intentionally focuses on SYN flooding attacks from an individual end host or application's perspective, as a means to deny service to that specific entity. High packet-rate attacks that target the network's packet-processing capability and capacity have been observed operationally. Since such attacks target the network, and not a TCP implementation, they are out of scope for this document, whether or not they happen to use TCP SYN segments as part of the attack, as the nature of the packets used is irrelevant in comparison to the packet-rate in such attacks.
このドキュメントは、その特定のエンティティへのサービスを拒否する手段として、個々のエンドホストまたはアプリケーションの観点からのSynフラッディング攻撃に意図的に焦点を当てています。ネットワークのパケット処理機能と容量を対象とする高いパケットレート攻撃が操作的に観察されています。このような攻撃はTCP実装ではなくネットワークを標的にしているため、使用されるパケットの性質は攻撃の一部としてTCP Synセグメントを使用するかどうかにかかわらず、このドキュメントの範囲外です。そのような攻撃のパケット率。
The majority of this document consists of three sections. Section 2 explains the SYN flooding attack in greater detail. Several common mitigation techniques are described in Section 3. An analysis and discussion of these techniques and their use is presented in Section 4. Further information on SYN cookies is contained in Appendix A.
このドキュメントの大部分は、3つのセクションで構成されています。セクション2では、Syn洪水攻撃についてさらに詳しく説明します。いくつかの一般的な緩和手法については、セクション3で説明します。これらの手法の分析と説明とその使用については、セクション4に記載されています。SynCookieの詳細情報は、付録Aに記載されています。
This section describes both the history and the technical basis of the SYN flooding attack.
このセクションでは、Syn洪水攻撃の歴史と技術的根拠の両方について説明します。
The TCP SYN flooding weakness was discovered as early as 1994 by Bill Cheswick and Steve Bellovin [B96]. They included, and then removed, a paragraph on the attack in their book "Firewalls and Internet Security: Repelling the Wily Hacker" [CB94]. Unfortunately, no countermeasures were developed within the next two years.
TCP Synの洪水の衰弱は、1994年にビルチェスウィックとスティーブベロビン[B96]によって発見されました。彼らには、本の攻撃に関する段落を含め、削除しました。残念ながら、今後2年以内に対策は開発されていません。
The SYN flooding attack was first publicized in 1996, with the release of a description and exploit tool in Phrack Magazine [P48-13]. Aside from some minor inaccuracies, this article is of high enough quality to be useful, and code from the article was widely distributed and used.
Syn Flooding攻撃は、1996年に最初に公表され、Phrack Magazine [P48-13]に説明とエクスプロイトツールがリリースされました。いくつかの軽微な不正確さは別として、この記事は役立つほど十分な品質があり、記事のコードは広く分散され、使用されていました。
By September of 1996, SYN flooding attacks had been observed in the wild. Particularly, an attack against one ISP's mail servers caused well-publicized outages. CERT quickly released an advisory on the attack [CA-96.21]. SYN flooding was particularly serious in comparison to other known denial-of-service attacks at the time. Rather than relying on the common brute-force tactic of simply exhausting the network's resources, SYN flooding targets end-host resources, which require fewer packets to deplete.
1996年9月までに、Syn洪水攻撃が野生で観察されました。特に、1つのISPのメールサーバーに対する攻撃により、よく知られた停止が発生しました。CERTは、攻撃に関するアドバイザリーをすぐに発表しました[CA-96.21]。Syn洪水は、当時の他の既知のサービス拒否攻撃と比較して特に深刻でした。Syn Floodは、ネットワークのリソースを単純に使い果たすという一般的なブルートフォースの戦術に依存するのではなく、ターゲットを掘り下げます。
The community quickly developed many widely differing techniques for preventing or limiting the impact of SYN flooding attacks. Many of these have been deployed to varying degrees on the Internet, in both end hosts and intervening routers. Some of these techniques have become important pieces of the TCP implementations in certain operating systems, although some significantly diverge from the TCP specification and none of these techniques have yet been standardized or sanctioned by the IETF process.
コミュニティは、Syn洪水攻撃の影響を防止または制限するための多くの大きく異なる技術をすぐに開発しました。これらの多くは、インターネット上、両方のエンドホストと介入ルーターでさまざまな程度に展開されています。これらの手法のいくつかは、特定のオペレーティングシステムでのTCP実装の重要な部分になっていますが、一部の手法はTCP仕様から大きく異なるものであり、これらの手法はまだIETFプロセスによって標準化または認可されていません。
As described in RFC 793, a TCP implementation may allow the LISTEN state to be entered with either all, some, or none of the pair of IP addresses and port numbers specified by the application. In many common applications like web servers, none of the remote host's information is pre-known or preconfigured, so that a connection can be established with any client whose details are unknown to the server ahead of time. This type of "unbound" LISTEN is the target of SYN flooding attacks due to the way it is typically implemented by operating systems.
RFC 793で説明されているように、TCP実装により、アプリケーションで指定されたIPアドレスとポート番号のペア、または一部、またはいずれかでリスニング状態を入力できる場合があります。Webサーバーなどの多くの一般的なアプリケーションでは、リモートホストの情報はいずれも事前に知られていないため、詳細がサーバーに不明なクライアントとの接続を確立できます。このタイプの「Unbound」リスニングは、通常、オペレーティングシステムによって実装される方法により、Syn Flooding攻撃のターゲットです。
For success, the SYN flooding attack relies on the victim host TCP implementation's behavior. In particular, it assumes that the victim allocates state for every TCP SYN segment when it is received, and that there is a limit on the amount of such state than can be kept at any time. The current base TCP specification, RFC 793 [RFC0793], describes the standard processing of incoming SYN segments. RFC 793 describes the concept of a Transmission Control Block (TCB) data structure to store all the state information for an individual connection. In practice, operating systems may implement this concept rather differently, but the key is that each TCP connection requires some memory space.
成功のために、Syn Flooding Attackは、被害者ホストTCP実装の行動に依存しています。特に、被害者は、受信したときにすべてのTCP Synセグメントに状態を割り当てること、およびそのような状態の量にいつでも保持できるよりも制限があると想定しています。現在のベースTCP仕様であるRFC 793 [RFC0793]は、着信シンセグメントの標準処理について説明しています。RFC 793は、個々の接続のためにすべての状態情報を保存するための伝送制御ブロック（TCB）データ構造の概念を説明しています。実際には、オペレーティングシステムはこの概念をかなり異なる方法で実装する場合がありますが、重要なのは、各TCP接続に何らかのメモリ空間が必要であることです。
Per RFC 793, when a SYN is received for a local TCP port where a connection is in the LISTEN state, then the state transitions to SYN-RECEIVED, and some of the TCB is initialized with information from the header fields of the received SYN segment. In practice, many operating systems do not alter the TCB in LISTEN, but instead make a copy of the TCB and perform the state transition and update on the copy. This is done so that the local TCP port may be shared amongst several distinct connections. This TCB-copying behavior is not actually essential for this purpose, but influences the way in which applications that wish to handle multiple simultaneous connections through a single TCP port are written. The crucial result of this behavior is that, instead of updating already-allocated memory, new (or unused) memory must be devoted to the copied TCB.
RFC 793ごとに、接続がリスニング状態にあるローカルTCPポートのSynが受信されると、状態はSyn-Receivedに移行し、TCBの一部は受信したSynセグメントのヘッダーフィールドからの情報で初期化されます。実際には、多くのオペレーティングシステムはリッスンでTCBを変更するのではなく、TCBのコピーを作成して、コピーの状態移行と更新を実行します。これは、ローカルTCPポートがいくつかの異なる接続の中で共有できるように行われます。このTCBコーピーの動作は、この目的には実際には不可欠ではありませんが、単一のTCPポートを介した複数の同時接続を処理したいアプリケーションが書かれている方法に影響します。この動作の重要な結果は、すでに割り当てられたメモリを更新する代わりに、コピーされたTCBに新しい（または未使用の）メモリを捧げる必要があることです。
As an example, in the Linux 2.6.10 networking code, a "sock" structure is used to implement the TCB concept. By examination, this structure takes over 1300 bytes to store in memory. In other systems that implement less-complex TCP algorithms and options, the overhead may be less, although it typically exceeds 280 bytes [SKK+97].
例として、Linux 2.6.10ネットワークコードでは、TCBコンセプトを実装するために「靴下」構造が使用されます。検査により、この構造はメモリに保存するために1300バイトを超えます。複雑なTCPアルゴリズムとオプションを実装する他のシステムでは、通常、280バイトを超えているが、オーバーヘッドは少ない場合がある[SKK 97]。
To protect host memory from being exhausted by connection requests, the number of TCB structures that can be resident at any time is usually limited by operating system kernels. Systems vary on whether limits are globally applied or local to a particular port number. There is also variation on whether the limits apply to fully established connections as well as those in SYN-RECEIVED. Commonly, systems implement a parameter to the typical listen() system call that allows the application to suggest a value for this limit, called the backlog. When the backlog limit is reached, then either incoming SYN segments are ignored, or uncompleted connections in the backlog are replaced. The concept of using a backlog is not described in the standards documents, so the failure behavior when the backlog is reached might differ between stacks (for instance, TCP RSTs might be generated). The exact failure behavior will determine whether initiating hosts continue to retransmit SYN segments over time, or quickly cease. These differences in implementation are acceptable since they only affect the behavior of the local stack when its resources are constrained, and do not cause interoperability problems.
ホストメモリが接続要求によって使い果たされるのを防ぐために、通常、いつでも居住できるTCB構造の数は、通常、オペレーティングシステムのカーネルによって制限されます。システムは、制限がグローバルに適用されるか、特定のポート番号に対してローカルであるかによって異なります。また、制限が完全に確立された接続に適用されるかどうか、および同期の接続に適用されるかどうかについてもバリエーションがあります。一般的に、システムは、典型的なlisten（）システムコールにパラメーターを実装します。これにより、アプリケーションはバックログと呼ばれるこの制限の値を提案できます。バックログの制限に到達すると、着信シンセグメントが無視されるか、バックログ内の未完成の接続が交換されます。バックログを使用するという概念は標準ドキュメントでは説明されていないため、バックログに到達したときの故障動作はスタック間で異なる場合があります（たとえば、TCP RSTSが生成される場合があります）。正確な障害動作により、ホストを開始することが時間の経過とともにシンセグメントを再送信し続けるか、すぐに停止するかどうかが判断されます。これらの実装の違いは、リソースが制約されている場合にのみローカルスタックの動作に影響を与え、相互運用性の問題を引き起こさないため、受け入れられます。
The SYN flooding attack does not attempt to overload the network's resources or the end host's memory, but merely attempts to exhaust the backlog of half-open connections associated with a port number. The goal is to send a quick barrage of SYN segments from IP addresses (often spoofed) that will not generate replies to the SYN-ACKs that are produced. By keeping the backlog full of bogus half-opened connections, legitimate requests will be rejected. Three important attack parameters for success are the size of the barrage, the frequency with which barrages are generated, and the means of selecting IP addresses to spoof.
Syn Flooding Attackは、ネットワークのリソースやエンドホストのメモリに過負荷をかけようとはしませんが、ポート番号に関連付けられた半分の開いた接続のバックログを使い果たすだけです。目標は、生成されたsyn-ackへの返信を生成しないIPアドレス（しばしばスプーフィング）からSynセグメントの迅速な弾幕を送信することです。バックログを偽の半分の接続でいっぱいに保つことにより、正当な要求が拒否されます。成功のための3つの重要な攻撃パラメーターは、弾幕のサイズ、弾幕が生成される頻度、およびIPアドレスをスプーフィングに選択する手段です。
Barrage Size
弾幕サイズ
To be effective, the size of the barrage must be made large enough to reach the backlog. Ideally, the barrage size is no larger than the backlog, minimizing the volume of traffic the attacker must source. Typical default backlog values vary from a half-dozen to several dozen, so the attack might be tailored to the particular value determined by the victim host and application. On machines intended to be servers, especially for a high volume of traffic, the backlogs are often administratively configured to higher values.
効果的であるためには、弾幕のサイズをバックログに到達するのに十分な大きさにする必要があります。理想的には、弾幕のサイズはバックログよりも大きくないため、攻撃者が調達する必要があるトラフィックの量を最小限に抑えます。典型的なデフォルトのバックログ値は、半ダースから数ダースまで異なるため、攻撃は被害者のホストとアプリケーションによって決定される特定の値に合わせて調整される可能性があります。特に大量のトラフィックのためにサーバーであることを目的としたマシンでは、バックログは多くの場合、より高い値に管理的に構成されます。
Barrage Frequency
弾幕頻度
To limit the lifetime of half-opened connection state, TCP implementations commonly reclaim memory from half-opened connections if they do not become fully opened after some time period. For instance, a timer of 75 seconds [SKK+97] might be set when the first SYN-ACK is sent, and on expiration cause SYN-ACK retransmissions to cease and the TCB to be released. The TCP specifications do not include this behavior of giving up on connection establishment after an arbitrary time. Some purists have expressed that the TCP implementation should continue retransmitting SYN and SYN-ACK segments without artificial bounds (but with exponential backoff to some conservative rate) until the application gives up. Despite this, common operating systems today do implement some artificial limit on half-open TCB lifetime. For instance, backing off and stopping after a total of 511 seconds can be observed in 4.4 BSD-Lite [Ste95], and is still practiced in some operating systems derived from this code.
半分にオープンした接続状態の寿命を制限するために、TCP実装は、しばらくの間、半分に開かれた接続からメモリを取り戻します。たとえば、75秒のタイマー[SKK 97]が最初のsyn-ackが送信されると設定され、有効期限が切れたときにSyn-ack再送信を停止し、TCBがリリースされます。TCP仕様には、任意の時間後に接続確立をあきらめるというこの動作は含まれていません。一部の純粋主義者は、TCPの実装では、アプリケーションがあきらめるまで、人工的な境界なし（ただし、いくつかの保守的な速度までの指数関数的なバックオフを持つ）をsynおよびsyn-ackセグメントを再送信し続けるべきであると表明しました。それにもかかわらず、今日の一般的なオペレーティングシステムは、半分のOPEN TCB寿命にいくつかの人為的な制限を実装しています。たとえば、4.4 BSD-Lite [STE95]で合計511秒後に後退して停止することができ、このコードから派生した一部のオペレーティングシステムでまだ実践されています。
To remain effective, a SYN flooding attack needs to send new barrages of bogus connection requests as soon as the TCBs from the previous barrage begin to be reclaimed. The frequency of barrages are tailored to the victim TCP implementation's TCB reclamation timer. Frequencies higher than needed source more packets, potentially drawing more attention, and frequencies that are too low will allow windows of time where legitimate connections can be established.
効果的なままにするために、Syn Flooding Attackは、前の弾幕からのTCBが回収され始めるとすぐに、偽の接続要求の新しい弾幕を送信する必要があります。弾幕の頻度は、被害者TCP実装のTCB再生タイマーに合わせて調整されます。必要な頻度が必要な頻度は、より多くのパケット、より多くの注意を引く可能性があり、低すぎる周波数は正当な接続を確立できる時間の窓を可能にします。
IP Address Selection
IPアドレスの選択
For an effective attack, it is important that the spoofed IP addresses be unresponsive to the SYN-ACK segments that the victim will generate. If addresses of normal connected hosts are used, then those hosts will send the victim a TCP reset segment that will immediately free the corresponding TCB and allow room in the backlog for legitimate connections to be made. The code distributed in the original Phrack article used a single source address for all spoofed SYN segments. This makes the attack segments somewhat easier to identify and filter. A strong attacker will have a list of unresponsive and unrelated addresses that it chooses spoofed source addresses from.
効果的な攻撃のために、スプーフィングされたIPアドレスが、被害者が生成するSyn-ackセグメントに反応しないことが重要です。通常の接続ホストのアドレスが使用される場合、それらのホストは被害者にTCPリセットセグメントを送信し、対応するTCBを直ちに解放し、バックログの部屋を正当な接続を行うことができます。元のPhrackの記事に配布されたコードは、すべてのスプーフィングされたSynセグメントに単一のソースアドレスを使用しました。これにより、攻撃セグメントが識別してフィルタリングしやすくなります。強力な攻撃者は、からのスプーフィングされたソースアドレスを選択する無関係で無関係なアドレスのリストを持っています。
It is important to note that this attack is directed at particular listening applications on a host, and not the host itself or the network. The attack also attempts to prevent only the establishment of new incoming connections to the victim port, and does not impact outgoing connection requests, nor previously established connections to the victim port.
この攻撃は、ホスト自体やネットワークではなく、ホストの特定のリスニングアプリケーションに向けられていることに注意することが重要です。また、攻撃は、被害者港への新しい着信接続の確立のみを防止しようとし、発信接続要求に影響を与えず、以前に犠牲者港への接続を確立しません。
In practice, an attacker might choose not to use spoofed IP addresses, but instead to use a multitude of hosts to initiate a SYN flooding attack. For instance, a collection of compromised hosts under the attacker's control (i.e., a "botnet") could be used. In this case, each host utilized in the attack would have to suppress its operating system's native response to the SYN-ACKs coming from the target. It is also possible for the attack TCP segments to arrive in a more continuous fashion than the "barrage" terminology used here suggests; as long as the rate of new SYNs exceeds the rate at which TCBs are reaped, the attack will be successful.
実際には、攻撃者はスプーフィングされたIPアドレスを使用しないことを選択する場合がありますが、代わりに多数のホストを使用してSyn洪水攻撃を開始することを選択する場合があります。たとえば、攻撃者の制御下にある侵害されたホストのコレクション（つまり、「ボットネット」）を使用できます。この場合、攻撃で利用されている各ホストは、ターゲットから来るSyn-ackに対するオペレーティングシステムのネイティブな応答を抑制する必要があります。また、攻撃TCPセグメントがここで使用される「弾幕」用語よりも、より連続的に到着する可能性があります。新しいSynのレートがTCBSが享受されるレートを超える限り、攻撃は成功します。
This section discusses a number of defense techniques that are known to the community, many of which are available in off-the-shelf products.
このセクションでは、コミュニティに知られている多くの防衛技術について説明します。その多くは、既製の製品で入手できます。
Since in the absence of an army of controlled hosts, the ability to send packets with spoofed source IP addresses is required for this attack to work, removing an attacker's ability to send spoofed IP packets is an effective solution that requires no modifications to TCP. The filtering techniques described in RFCs 2827, 3013, and 3704 represent the best current practices for packet filtering based on IP addresses [RFC2827][RFC3013][RFC3704]. While perfectly effective, end hosts should not rely on filtering policies to prevent attacks from spoofed segments, as global deployment of filters is neither guaranteed nor likely. An attacker with the ability to use a group of compromised hosts or to rapidly change between different access providers will also make filtering an impotent solution.
制御されたホストの軍隊が存在しない場合、この攻撃を機能させるためには、スプーフィングされたソースIPアドレスでパケットを送信する機能が必要であるため、攻撃者のスプーフィングされたIPパケットを送信する能力を削除することは、TCPの変更を必要としない効果的なソリューションです。RFCS 2827、3013、および3704で説明されているフィルタリング手法は、IPアドレス[RFC2827] [RFC3013] [RFC3704]に基づくパケットフィルタリングの最良の現在のプラクティスを表しています。完全に効果的ですが、エンドホストは、フィルターのグローバルな展開は保証されておらず、可能性がないため、攻撃がスプーフィングされたセグメントを防ぐためにポリシーのフィルタリングに依存してはなりません。侵害されたホストのグループを使用したり、異なるアクセスプロバイダー間で急速に変化することができる攻撃者も、フィルタリングが無力なソリューションになります。
An obvious attempt at a defense is for end hosts to use a larger backlog. Lemon has shown that in FreeBSD 4.4, this tactic has some serious negative aspects as the size of the backlog grows [Lem02]. The implementation has not been designed to scale past backlogs of a few hundred, and the data structures and search algorithms that it uses are inefficient with larger backlogs. It is reasonable to assume that other TCP implementations have similar design factors that limit their performance with large backlogs, and there seems to be no compelling reason why stacks should be re-engineered to support extremely large backlogs, since other solutions are available. However, experiments with large backlogs using efficient data structures and search algorithms have not been conducted, to our knowledge.
防御の明らかな試みは、エンドホストがより大きなバックログを使用することです。レモンは、FreeBSD 4.4では、バックログのサイズが大きくなるにつれて、この戦術にはいくつかの深刻なネガティブな側面があることを示しています[LEM02]。この実装は、数百の過去のバックログをスケーリングするように設計されていません。また、使用するデータ構造と検索アルゴリズムは、より大きなバックログでは非効率的です。他のTCP実装には、大きなバックログでパフォーマンスを制限する同様の設計要因があると想定するのは合理的です。他のソリューションが利用可能であるため、非常に大きなバックログをサポートするためにスタックを再設計する必要がある理由はないようです。ただし、効率的なデータ構造と検索アルゴリズムを使用した大きなバックログを使用した実験は、私たちの知る限り行われていません。
Another quickly implementable defense is shortening the timeout period between receiving a SYN and reaping the created TCB for lack of progress. Decreasing the timer that limits the lifetime of TCBs in SYN-RECEIVED is also flawed. While a shorter timer will keep bogus connection attempts from persisting for as long in the backlog, and thus free up space for legitimate connections sooner, it can prevent some fraction of legitimate connections from becoming fully established. This tactic is also ineffective because it only requires the attacker to increase the barrage frequency by a linearly proportional amount. This timer reduction is sometimes implemented as a response to crossing some threshold in the backlog occupancy, or some rate of SYN reception.
別の迅速な実装可能な防御は、Synを受信してから作成されたTCBを刈り取るまでのタイムアウト期間を短縮することです。Syn-ReceivedでTCBの寿命を制限するタイマーを減らすことにも欠陥があります。より短いタイマーは、バックログでの長い間、偽の接続の試みが持続しないようにし、したがって正当な接続のためにスペースをより早く解放しますが、合法的な接続の一部が完全に確立されるのを防ぐことができます。また、この戦術は、攻撃者が直線的に比例する量だけ弾幕の頻度を増やす必要があるため、効果的ではありません。このタイマーの削減は、バックログの占有率の一部のしきい値、またはSyn受信のレートを通過するための応答として実装されることがあります。
Once the entire backlog is exhausted, some implementations allow incoming SYNs to overwrite the oldest half-open TCB entry. This works under the assumption that legitimate connections can be fully established in less time than the backlog can be filled by incoming attack SYNs. This can fail when the attacking packet rate is high and/or the backlog size is small, and is not a robust defense.
バックログ全体が使い果たされると、一部の実装により、着信Synが最も古い半分のTCBエントリを上書きすることができます。これは、正当な接続は、バックログが着信攻撃Synによって埋めることができるよりも短い時間で完全に確立できるという仮定の下で機能します。これは、攻撃パケットレートが高く、バックログのサイズが小さく、堅牢な防御ではない場合に失敗する可能性があります。
The SYN cache, best described by Lemon [Lem02], is based on minimizing the amount of state that a SYN allocates, i.e., not immediately allocating a full TCB. The full state allocation is delayed until the connection has been fully established. Hosts implementing a SYN cache have some secret bits that they select from the incoming SYN segments. The secret bits are hashed along with the IP addresses and TCP ports of a segment, and the hash value determines the location in a global hash table where the incomplete TCB is stored. There is a bucket limit for each hash value, and when this limit is reached, the oldest entry is dropped.
レモン[LEM02]で最もよく説明されているSynキャッシュは、Synが割り当てる状態の量、つまり完全なTCBをすぐに割り当てない状態の量を最小化することに基づいています。完全な状態割り当ては、接続が完全に確立されるまで遅延します。Synキャッシュを実装するホストには、着信シンセグメントから選択する秘密のビットがあります。シークレットビットは、セグメントのIPアドレスとTCPポートとともにハッシュされ、ハッシュ値は、不完全なTCBが保存されているグローバルハッシュテーブルの位置を決定します。ハッシュ値ごとにバケット制限があり、この制限に達すると、最古のエントリが削除されます。
The SYN cache technique is effective because the secret bits prevent an attacker from being able to target specific hash values for overflowing the bucket limit, and it bounds both the CPU time and memory requirements. Lemon's evaluation of the SYN cache shows that even under conditions where a SYN flooding attack is not being performed, due to the modified processing path, connection establishment is slightly more expedient. Under active attack, SYN cache performance was observed to approximately linearly shift the distribution of times to establish legitimate connections to about 15% longer than when not under attack [Lem02].
Syn Cache手法は、秘密のビットが攻撃者がバケットの制限をオーバーフローするために特定のハッシュ値をターゲットにすることができなくなり、CPU時間とメモリの要件の両方に境界を掲載することを防ぐため、効果的です。レモンのSynキャッシュの評価は、変更された処理パスにより、Syn洪水攻撃が実行されていない条件下でさえ、接続確立がわずかに適切であることを示しています。アクティブな攻撃では、Synキャッシュのパフォーマンスが、攻撃を受けていない場合よりも合法的な接続を約15％長く確立するために、時間の分布をほぼ線形シフトすることが観察されました[LEM02]。
If data accompanies the SYN segment, then this data is not acknowledged or stored by the receiver, and will require retransmission. This does not affect the reliability of TCP's data transfer service, but it does affect its performance to some small extent. SYNs carrying data are used by the T/TCP extensions [RFC1644]. While T/TCP is implemented in a number of popular operating systems [GN00], it currently seems to be rarely used. Measurements at one site's border router [All07] logged 2,545,785 SYN segments (not SYN-ACKs), of which 36 carried the T/TCP CCNEW option (or 0.001%). These came from 26 unique hosts, and no other T/TCP options were seen. 2,287 SYN segments with data were seen (or 0.09% of all SYN segments), all of which had exactly 24 bytes of data. These observations indicate that issues with SYN caches and data on SYN segments may not be significant in deployment.
データがSynセグメントに付随する場合、このデータは受信者によって確認または保存されておらず、再送信が必要になります。これは、TCPのデータ転送サービスの信頼性には影響しませんが、パフォーマンスに少し影響します。キャリングデータは、T/TCP拡張[RFC1644]によって使用されます。T/TCPは多くの一般的なオペレーティングシステム[GN00]に実装されていますが、現在はめったに使用されていないようです。1つのサイトのBorder Router [All07]での測定は、2,545,785のSynセグメント（Syn-ackではない）を記録しました。これらは26のユニークなホストから来ており、他のT/TCPオプションは見られませんでした。データを含む2,287のSynセグメントが見られました（またはすべてのSynセグメントの0.09％）。これらには、正確に24バイトのデータがありました。これらの観察結果は、Syn Cachesの問題とSynセグメントに関するデータが展開において重要ではない可能性があることを示しています。
SYN cookies go a step further and allocate no state at all for connections in SYN-RECEIVED. Instead, they encode most of the state (and all of the strictly required) state that they would normally keep into the sequence number transmitted on the SYN-ACK. If the SYN was not spoofed, then the acknowledgement number (along with several other fields) in the ACK that completes the handshake can be used to reconstruct the state to be put into the TCB. To date, one of the best references on SYN cookies can be found on Dan Bernstein's web site [cr.yp.to]. This technique exploits the long-understood low entropy in TCP header fields [RFC1144][RFC4413]. In Appendix A, we describe the SYN cookie technique, to avoid the possibility that the web page will become unavailable.
syn Cookieはさらに一歩進んで、シンが記録された接続のためにまったく状態を割り当てません。代わりに、彼らは通常、Syn-ackに送信されるシーケンス番号に留まるという州のほとんど（および厳密に必要なすべての）をエンコードします。Synがスプーフィングされていない場合、握手を完了するACK内の確認番号（他のいくつかのフィールドとともに）を使用して、TCBに入れる状態を再構築できます。これまで、Syn Cookieの最高の参照の1つは、Dan BernsteinのWebサイト[cr.yp.to]にあります。この手法は、TCPヘッダーフィールド[RFC1144] [RFC4413]で、長年にわたる低エントロピーを活用しています。付録Aでは、Webページが利用できなくなる可能性を回避するために、Syn Cookieテクニックについて説明します。
The exact mechanism for encoding state into the SYN-ACK sequence number can be implementation dependent. A common consideration is that to prevent replay, some time-dependent random bits must be embedded in the sequence number. One technique used 7 bits for these bits and 25 bits for the other data [Lem02]. One way to encode these bits has been to XOR the initial sequence number received with a truncated cryptographic hash of the IP address and TCP port number pairs, and secret bits. In practice, this hash has been generated using MD5 [RFC1321]. Any similar one-way hash could be used instead without impacting interoperability since the hash value is checked by the same host who generates it.
Syn-ackシーケンス番号に状態をエンコードするための正確なメカニズムは、実装に依存する可能性があります。よくある考慮事項は、リプレイを防ぐために、シーケンス番号に時間依存のランダムビットを埋め込む必要があることです。1つの手法は、これらのビットに7ビット、他のデータに25ビットを使用しました[LEM02]。これらのビットをエンコードする1つの方法は、IPアドレスの切り捨てられた暗号化ハッシュとTCPポート番号ペア、および秘密ビットで受信された初期シーケンス番号をXORにすることです。実際には、このハッシュはMD5 [RFC1321]を使用して生成されています。ハッシュ値がそれを生成するのと同じホストによってチェックされるため、相互運用性に影響を与えることなく、同様の一方向ハッシュを代わりに使用できます。
The problem with SYN cookies is that commonly implemented schemes are incompatible with some TCP options, if the cookie generation scheme does not consider them. For example, an encoding of the Maximum Segment Size (MSS) advertised on the SYN has been accommodated by using 2 sequence number bits to represent 4 predefined common MSS values. Similar techniques would be required for some other TCP options, while negotiated use of other TCP options can be detected implicitly. A timestamp on the ACK, as an example, indicates that Timestamp use was successfully negotiated on the SYN and SYN-ACK, while the reception of a Selective Acknowledgement (SACK) option at some point during the connection implies that SACK was negotiated. Note that SACK blocks should normally not be sent by a host using TCP cookies unless they are first received. For the common unidirectional data flow in many TCP connections, this can be a problem, as it limits SACK usage. For this reason, SYN cookies typically are not used by default on systems that implement them, and are only enabled either under high-stress conditions indicative of an attack, or via administrative action.
Syn Cookieの問題は、Cookie生成スキームがそれらを考慮しない場合、一般的に実装されたスキームがいくつかのTCPオプションと互換性がないことです。たとえば、Synで宣伝されている最大セグメントサイズ（MSS）のエンコーディングは、2つのシーケンス番号ビットを使用して4つの定義された一般的なMSS値を表して収容されています。他のいくつかのTCPオプションには同様の手法が必要になりますが、他のTCPオプションのネゴシエートされた使用は暗黙的に検出できます。例として、ACKのタイムスタンプは、タイムスタンプの使用がSynとSyn-ackで正常にネゴシエートされたことを示していますが、接続中のある時点での選択的承認（SACK）オプションの受信は、Sackがネゴシエートされたことを意味します。サックブロックは、通常、最初に受信されない限り、TCP Cookieを使用してホストが送信しないでください。多くのTCP接続における一般的な単方向データフローの場合、サックの使用を制限するため、これは問題になる可能性があります。このため、Syn Cookieは通常、デフォルトではそれらを実装するシステムでは使用されず、攻撃を示す高ストレス条件下でのみ有効になっているか、管理アクションを介して有効になります。
Recently, a new SYN cookie technique developed for release in FreeBSD 7.0 leverages the bits of the Timestamp option in addition to the sequence number bits for encoding state. Since the Timestamp value is echoed back in the Timestamp Echo field of the ACK packet, any state stored in the Timestamp option can be restored similarly to the way that it is from the sequence number / acknowledgement in a basic SYN cookie. Using the Timestamp bits, it is possible to explicitly store state bits for things like send and receive window scales, SACK-allowed, and TCP-MD5-enabled, for which there is no room in a typical SYN cookie. This use of Timestamps to improve the compromises inherent in SYN cookies is unique to the FreeBSD implementation, to our knowledge. A limitation is that the technique can only be used if the SYN itself contains a Timestamp option, but this option seems to be widely implemented today, and hosts that support window scaling and SACK typically support timestamps as well.
Similarly to SYN caches, SYN cookies do not handle application data piggybacked on the SYN segment.
Syn Cachesと同様に、Syn CookieはSynセグメントでピギーバックされたアプリケーションデータを処理しません。
Another problem with SYN cookies is for applications where the first application data is sent by the passive host. If this host is handling a large number of connections, then packet loss may be likely. When a handshake-completing ACK from the initiator is lost, the passive side's application layer never is notified of the connection's existence and never sends data, even though the initiator thinks that the connection has been successfully established. An example application where the first application-layer data is sent by the passive side is SMTP, if implemented according to RFC 2821, where a "service ready" message is sent by the passive side after the TCP handshake is completed.
Syn Cookieのもう1つの問題は、パッシブホストによって最初のアプリケーションデータが送信されるアプリケーションです。このホストが多数の接続を処理している場合、パケットの損失が可能性があります。イニシエーターからの握手を完全に描写するACKが失われた場合、Initiatorが接続が正常に確立されたと考えていても、パッシブサイドのアプリケーションレイヤーは接続の存在を通知されず、データを送信することはありません。パッシブ側によって最初のアプリケーション層データが送信されるアプリケーションの例は、RFC 2821に従って実装されている場合、SMTPです。この場合、TCPハンドシェイクが完了した後、「サービス対応」メッセージがパッシブ側によって送信されます。
Although SYN cookie implementations exist and are deployed, the use of SYN cookies is often disabled in default configurations, so it is unclear how much operational experience actually exists with them or if using them opens up new vulnerabilities. Anecdotes of incidents where SYN cookies have been used on typical web servers seem to indicate that the added processing burden of computing MD5 sums for every SYN packet received is not significant in comparison to the loss of application availability when undefended. For some computationally constrained mobile or embedded devices, this situation might be different.
Syn Cookieの実装は存在し、展開されていますが、Syn Cookieの使用はデフォルト構成ではしばしば無効になっているため、実際に実際に存在するか、またはそれらを使用すると新しい脆弱性が開くかどうかは不明です。典型的なWebサーバーでSyn Cookieが使用されているインシデントの逸話は、受信したすべてのSynパケットのコンピューティングMD5合計の追加の処理負担が、無防備なアプリケーションの可用性の損失と比較して重要ではないことを示しているようです。計算に制約されている一部のモバイルまたは組み込みデバイスの場合、この状況は異なる場合があります。
The SYN cache and SYN cookie techniques can be combined. For example, in the event that the cache becomes full, then SYN cookies can be sent instead of purging cache entries upon the arrival of new SYNs. Such hybrid approaches may provide a strong combination of the positive aspects of each approach. Lemon has demonstrated the utility of this hybrid [Lem02].
SynキャッシュとSyn Cookieのテクニックを組み合わせることができます。たとえば、キャッシュがいっぱいになった場合、新しいSynsの到着時にキャッシュエントリをパージする代わりにSyn Cookieを送信できます。このようなハイブリッドアプローチは、各アプローチの肯定的な側面の強力な組み合わせを提供する可能性があります。レモンは、このハイブリッドの有用性を実証しています[LEM02]。
Firewall-based tactics may also be used to defend end hosts from SYN flooding attacks. The basic concept is to offload the connection establishment procedures onto a firewall that screens connection attempts until they are completed and then proxies them back to protected end hosts. This moves the problem away from end hosts to become the firewall's or proxy's problem, and may introduce other problems related to altering TCP's expected end-to-end semantics. A common tactic used in these firewall and proxy products is to implement one of the end host based techniques discussed above, and screen incoming SYNs from the protected network until the connection is fully established. This is accomplished by spoofing the source addresses of several packets to the initiator and listener at various stages of the handshake [Eddy06].
ファイアウォールベースの戦術は、Syn洪水攻撃から最終ホストを守るためにも使用できます。基本的な概念は、接続確立手順をファイアウォールにオフロードすることです。ファイアウォールは、接続が完了するまで接続の試行をスクリーニングし、保護されたエンドホストにプロキシに戻します。これにより、問題がエンドホストから遠ざかり、ファイアウォールまたはプロキシの問題になり、TCPの予想されるエンドツーエンドセマンティクスの変更に関連する他の問題を導入する可能性があります。これらのファイアウォールおよびプロキシ製品で使用される一般的な戦術は、上記で説明したエンドホストベースの手法の1つを実装し、接続が完全に確立されるまで保護されたネットワークから入ってくるSynをスクリーニングすることです。これは、握手のさまざまな段階でいくつかのパケットのソースアドレスをイニシエーターとリスナーにスプーフィングすることによって達成されます[EDDY06]。
Several of the defenses discussed in the previous section rely on changes to behavior inside the network; via router filtering, firewalls, and proxies. These may be highly effective, and often require no modification or configuration of end-host software. Given the mobile nature and dynamic connectivity of many end hosts, it is optimistic for TCP implementers to assume the presence of such protective devices. TCP implementers should provide some means of defense to SYN flooding attacks in end-host implementations.
前のセクションで説明したいくつかの防御は、ネットワーク内の動作の変更に依存しています。ルーターフィルタリング、ファイアウォール、およびプロキシを介して。これらは非常に効果的である可能性があり、多くの場合、エンドホストソフトウェアの変更または構成を必要としません。多くのエンドホストのモバイル性と動的接続性を考えると、TCP実装者がそのような保護デバイスの存在を引き受けることは楽観的です。TCP実装者は、エンドホストの実装でフラッディング攻撃をSYNにするための何らかの防御手段を提供する必要があります。
Among end-host modifications, the SYN cache and SYN cookie approaches seem to be the only viable techniques discovered to date. Increasing the backlog and reducing the SYN-RECEIVED timer are measurably problematic. The SYN cache implies a higher memory footprint than SYN cookies; however, SYN cookies may not be fully compatible with some TCP options, and may hamper development of future TCP extensions that require state. For these reasons, SYN cookies should not be enabled by default on systems that provide them. SYN caches do not have the same negative implications and may be enabled as a default mode of processing.
エンドホストの変更の中で、Syn CacheとSyn Cookieアプローチは、これまでに発見された唯一の実行可能な手法のようです。バックログを増やし、シンライブされたタイマーを減らすことは、測定的に問題があります。Synキャッシュは、Syn Cookieよりも高いメモリフットプリントを意味します。ただし、Syn CookieはいくつかのTCPオプションと完全に互換性がない場合があり、状態を必要とする将来のTCP拡張機能の開発を妨げる可能性があります。これらの理由により、Syn Cookieは、それらを提供するシステムでデフォルトで有効にするべきではありません。Syn Cachesには同じネガティブな意味がなく、デフォルトの処理モードとして有効になる場合があります。
In October of 1996, Dave Borman implemented a SYN cache at BSDi for BSD/OS, which was given to the community with no restrictions. This code seems to be the basis for the SYN cache implementations adopted later in other BSD variants. The cache was used when the backlog became full, rather than by default, as we have described. A note to the tcp-impl mailing list explains that this code does not retransmit SYN-ACKs [B97]. More recent implementations have chosen to reverse this decision and retransmit SYN-ACKs. It is known that loss of SYN-ACK packets is not uncommon [SD01] and can severely slow the performance of connections when initial retransmission timers for SYNs are overly conservative (as in some operating systems) or retransmitted SYNs are lost. Furthermore, if a SYN flooding attacker has a high sending rate, loss of retransmitted SYNs is likely, so if SYN-ACKs are not retransmitted, the chance of efficiently establishing legitimate connections is reduced.
1996年10月、Dave BormanはBSD/OSのBSDIでSynキャッシュを実装しました。これは、制限なしでコミュニティに与えられました。このコードは、他のBSDバリアントで後に採用されたSynキャッシュの実装の基礎と思われます。説明したように、バックログがデフォルトではなくいっぱいになったときにキャッシュが使用されました。TCP-IMPLメーリングリストへのメモは、このコードがsyn-ack [B97]を再送信しないことを説明しています。この決定を逆転させ、syn-ackを再送信するために、より最近の実装が選択されています。syn-ackパケットの損失は珍しいことではなく、[SD01]は珍しくなく、Synの最初の再送信タイマーが過度に保守的である場合（一部のオペレーティングシステムのように）、再送信されたSynが失われると、接続のパフォーマンスが大幅に遅くなることが知られています。さらに、SYNフラッディング攻撃者の送信率が高い場合、再送信されたSynの損失が可能性が高いため、Syn-ackが再送信されない場合、正当な接続を効率的に確立する可能性が低下します。
In 1997, NetBSD incorporated a modified version of Borman's code. Two notable differences from the original code stem from the decision to use the cache by default (for all connections). This implied the need to perform retransmissions for SYN-ACKs, and to use larger structures to keep more complete data. The original structure was 32 bytes long for IPv4 connections and 56 bytes with IPv6 support, while the current FreeBSD structure is 196 bytes long. As previously cited, Lemon implemented the SYN cache and cookie techniques in FreeBSD 4.4 [Lem02]. Lemon notes that a SYN cache structure took up 160 bytes compared to 736 for the full TCB (now 196 bytes for the cache structure). We have examined the OpenBSD 3.6 code and determined that it includes a similar SYN cache.
1997年、NetBSDはボルマンのコードの修正バージョンを組み込みました。元のコードとの2つの顕著な違いは、デフォルトでキャッシュを使用するという決定（すべての接続に対して）に起因します。これは、syn-ackの再送信を実行し、より大きな構造を使用してより完全なデータを維持する必要性を暗示しています。元の構造は、IPv4接続の長さ32バイト、IPv6サポートを備えた56バイトで、現在のFreeBSD構造は196バイトです。前述のように、レモンはFreeBSD 4.4 [LEM02]にSynキャッシュとCookie技術を実装しました。レモンは、Synキャッシュ構造が完全なTCBで736と比較して160バイトを占有したことに注目しています（現在はキャッシュ構造で196バイト）。OpenBSD 3.6コードを調べ、同様のSynキャッシュが含まれていると判断しました。
Linux 2.6.5 code, also by examination, contains a SYN cookie implementation that encodes 8 MSS values, and does not use SYN cookies by default. This functionality has been present in the Linux kernel for several years previous to 2.6.5.
Linux 2.6.5コードは、試験により、8 MSS値をエンコードするSyn Cookie実装を含み、デフォルトではSyn Cookieを使用しません。この機能は、2.6.5よりも数年前にLinuxカーネルに存在しています。
When a SYN cache and/or SYN cookies are implemented with IPv6, the IPv6 flow label value used on the SYN-ACK should be consistent with the flow label used for the rest of the packets within that flow. There have been implementation bugs that caused random flow labels to be used in SYN-ACKs generated by SYN cache and SYN cookie code [MM05].
Synキャッシュおよび/またはSyn CookieがIPv6で実装される場合、Syn-ackで使用されるIPv6フローラベル値は、そのフロー内の残りのパケットに使用されるフローラベルと一致する必要があります。実装バグがあり、Syn CacheおよびSyn Cookieコード[MM05]によって生成されたSyn-ackでランダムフローラベルを使用しました。
Beginning with Windows 2000, Microsoft's Windows operating systems have had a "TCP SYN attack protection" feature, which can be toggled on or off in the registry. This defaulted to off, until Windows 2003 SP1, in which it is on by default. With this feature enabled, when the number of half-open connections and half-open connections with retransmitted SYN-ACKs exceeds configurable thresholds, then the number of times that SYN-ACKs are retransmitted before giving up is reduced, and the "Route Cache Entry" creation is delayed, which prevents some features (e.g., window scaling) from being used [win2k3-wp].
Windows 2000から始めて、MicrosoftのWindowsオペレーティングシステムには、レジストリでオンまたはオフに切り替えることができる「TCP Syn攻撃保護」機能があります。これは、Windows 2003 SP1がデフォルトでオンになるまで、デフォルトでオフになりました。この機能を有効にして、再送信されたsyn-ackを使用した半分のオープン接続の数とハーフオープン接続が構成可能なしきい値を超えると、syn-ackがあきらめる前に再送信される回数が減少し、「ルートキャッシュ入力が減少する）「作成が遅れているため、いくつかの機能（たとえば、ウィンドウスケーリング）が使用されない[win2k3-wp]。
Several vendors of commercial firewall products sell devices that can mitigate SYN flooding's effects on end hosts by proxying connections.
コマーシャルファイアウォール製品のいくつかのベンダーは、接続をプロキシによってSyn Floodingの効果を緩和できるデバイスを販売しています。
Discovery and exploitation of the SYN flooding vulnerability in TCP's design provided a valuable lesson for protocol designers. The Stream Control Transmission Protocol [RFC2960], which was designed more recently, incorporated a 4-way handshake with a stateless cookie-based component for the listening end. In this way, the passive-opening side has better evidence that the initiator really exists at the given address before it allocates any state. The Host Identity Protocol base exchange [MNJH07] is similarly designed as a 4-way handshake, but also involves a puzzle sent to the initiator that must be solved before any state is reserved by the responder. The general concept of designing statelessness into protocol setup to avoid denial-of-service attacks has been discussed by Aura and Nikander [AN97].
TCPの設計におけるSyn Floodingの脆弱性の発見と搾取は、プロトコルデザイナーにとって貴重な教訓を提供しました。より最近設計されたストリーム制御伝送プロトコル[RFC2960]は、リスニングエンド用のステートレスクッキーベースのコンポーネントを備えた4ウェイハンドシェイクを組み込みました。このようにして、受動的なオープニング側は、開始者が特定のアドレスに実際に存在するというより良い証拠を持っています。ホストIDプロトコルベースエクスチェンジ[MNJH07]は、同様に4ウェイハンドシェイクとして設計されていますが、レスポンダーによって予約される前に解決しなければならないイニシエーターに送信されるパズルも含まれます。Statelessnessをプロトコルセットアップに設計して、サービス拒否攻撃を回避するという一般的な概念は、AuraとNikander [AN97]によって議論されています。
The SYN flooding attack on TCP has been described in numerous other publications, and the details and code needed to perform the attack have been easily available for years. Describing the attack in this document does not pose any danger of further publicizing this weakness in unmodified TCP stacks. Several widely deployed operating systems implement the mitigation techniques that this document discusses for defeating SYN flooding attacks. In at least some cases, these operating systems do not enable these countermeasures by default; however, the mechanisms for defeating SYN flooding are well deployed, and easily enabled by end-users. The publication of this document should not influence the number of SYN flooding attacks observed, and might increase the robustness of the Internet to such attacks by encouraging use of the commonly available mitigations.
TCPに対するSyn洪水攻撃は、他の多くの出版物で説明されており、攻撃を実行するために必要な詳細とコードは何年も簡単に利用できます。このドキュメントで攻撃を説明することは、変更されていないTCPスタックのこの弱点をさらに公表する危険をもたらすものではありません。いくつかの広く展開されているオペレーティングシステムは、このドキュメントがSyn洪水攻撃を破るために議論する緩和技術を実装しています。少なくとも場合によっては、これらのオペレーティングシステムは、デフォルトでこれらの対策を有効にしません。ただし、Syn洪水を打ち負かすメカニズムは十分に展開されており、エンドユーザーによって簡単に可能になります。この文書の公開は、観察されたSyn洪水攻撃の数に影響を与えないはずであり、一般的に利用可能な緩和の使用を促進することにより、そのような攻撃に対するインターネットの堅牢性を高める可能性があります。
A conversation with Ted Faber was the impetus for writing this document. Comments and suggestions from Joe Touch, Dave Borman, Fernando Gont, Jean-Baptiste Marchand, Christian Huitema, Caitlin Bestler, Pekka Savola, Andre Oppermann, Alfred Hoenes, Mark Allman, Lars Eggert, Pasi Eronen, Warren Kumari, David Malone, Ron Bonica, and Lisa Dusseault were useful in strengthening this document. The original work on TCP SYN cookies presented in Appendix A is due to D.J. Bernstein.
Ted Faberとの会話は、この文書を書くための推進力でした。ジョー・タッチ、デイブ・ボーマン、フェルナンド・ゴント、ジャン・バプティスト・マーチャンド、クリスチャン・フイテマ、ケイトリン・ベストラー、ペッカ・サヴォーラ、アンドレ・オッパーマン、アルフレッド・ホーエン、マーク・オールマン、ラース・エッガート、パシ・エレノン、ウォーレン・クマリ、デイヴィッド・マローンからのコメントと提案、そしてLisa Dusseaultは、この文書を強化するのに役立ちました。付録Aに掲載されているTCP syn Cookieのオリジナル作業は、D.J。バーンスタイン。
Work on this document was performed at NASA's Glenn Research Center. Funding was partially provided by a combination of NASA's Advanced Communications, Navigation, and Surveillance Architectures and System Technologies (ACAST) project, the Sensis Corporation, NASA's Space Communications Architecture Working Group, and NASA's Earth Science Technology Office.
この文書の作業は、NASAのグレン研究センターで行われました。NASAの高度な通信、ナビゲーション、および監視アーキテクチャおよびシステムテクノロジー（ACAST）プロジェクト、Sensis Corporation、NASAのSpace Communications Architecture Working Group、NASAのEarth Science Technology Officeの組み合わせにより、資金調達は部分的に提供されました。
[AN97] Aura, T. and P. Nikander, "Stateless Connections", Proceedings of the First International Conference on Information and Communication Security, 1997.
[AN97] Aura、T。およびP. Nikander、「Stateless Connections」、情報通信セキュリティに関する最初の国際会議の議事録、1997年。
[All07] Allman, M., "personal communication", February 2007.
[All07] Allman、M。、「個人的なコミュニケーション」、2007年2月。
[B96] Bennahum, D., "PANIX ATTACK", MEME 2.12, October 1996, <http://memex.org/meme2-12.html>.
[B96] Bennahum、D。、「Panix Attack」、Meme 2.12、1996年10月、<http://memex.org/meme2-12.html>。
[B97] Borman, D., "Re: SYN/RST cookies (was Re: a quick clarification...)", IETF tcp-impl mailing list, June 1997.
[B97]ボーマン、D。、「Re：syn/rst cookie（re：a Quick clarification ...）」、IETF TCP-IMPLメーリングリスト、1997年6月。
[CA-96.21] CERT, "CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks", September 1996.
[CA-96.21] CERT、「CERT Advisory CA-1996-21 TCP Syn洪水とIPスプーフィング攻撃」、1996年9月。
[CB94] Cheswick, W. and S. Bellovin, "Firewalls and Internet Security", ISBN: 0201633574, January 1994.
[CB94] Cheswick、W。およびS. Bellovin、「ファイアウォールとインターネットセキュリティ」、ISBN：0201633574、1994年1月。
[Eddy06] Eddy, W., "Defenses Against TCP SYN Flooding Attacks", Cisco Internet Protocol Journal Volume 8, Number 4, December 2006.
[Eddy06] Eddy、W。、「TCP Syn洪水攻撃に対する防御」、Cisco Internet Protocol Journal Volume 8、Number 4、2006年12月。
[GN00] Griffin, M. and J. Nelson, "T/TCP: TCP for Transactions", Linux Journal, February 2000.
[GN00] Griffin、M。およびJ. Nelson、「T/TCP：TCP：TCP for Transactions」、Linux Journal、2000年2月。
[Lem02] Lemon, J., "Resisting SYN Flood DoS Attacks with a SYN Cache", BSDCON 2002, February 2002.
[LEM02] Lemon、J。、「Syn Flood DOS攻撃への抵抗Syn Cache」、BSDCON 2002、2002年2月。
[MM05] McGann, O. and D. Malone, "Flow Label Filtering Feasibility", European Conference on Computer Network Defense 2005, December 2005.
[MM05] McGann、O。およびD. Malone、「フローラベルフィルタリングの実現可能性」、コンピューターネットワーク防衛に関する欧州会議、2005年12月。
[MNJH07] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", Work in Progress, June 2007.
[Mnjh07] Moskowitz、R.、Nikander、P.、Jokela、P。、およびT. Henderson、「Host Identity Protocol」、2007年6月、作業進行中。
[P48-13] daemon9, route, and infinity, "Project Neptune", Phrack Magazine, Volume 7, Issue 48, File 13 of 18, July 1996.
[P48-13] Daemon9、Route、およびInfinity、「Project Neptune」、Phrack Magazine、Volume 7、Issue 48、File 13 of 18、1996年7月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[RFC1144] Jacobson、V。、「低速シリアルリンクのTCP/IPヘッダーの圧縮」、RFC 1144、1990年2月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジストアルゴリズム」、RFC 1321、1992年4月。
[RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
[RFC1644] Braden、B。、「T/TCP -TCPトランザクションの機能仕様のためのTCP拡張」、RFC 1644、1994年7月。
[RFC2827] 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.
[RFC2827] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV。Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[RFC3013] Killalea, T., "Recommended Internet Service Provider Security Services and Procedures", BCP 46, RFC 3013, November 2000.
[RFC3013] Killalea、T。、「推奨されるインターネットサービスプロバイダーセキュリティサービスと手順」、BCP 46、RFC 3013、2000年11月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704] Baker、F。およびP. Savola、「マルチホームネットワークのイングレスフィルタリング」、BCP 84、RFC 3704、2004年3月。
[RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413, March 2006.
[RFC4413] West、M。およびS. McCann、「TCP/IPフィールド行動」、RFC 4413、2006年3月。
[SD01] Seddigh, N. and M. Devetsikiotis, "Studies of TCP's Retransmission Timeout Mechanism", Proceedings of the 2001 IEEE International Conference on Communications (ICC 2001), volume 6, pages 1834-1840, June 2001.
[SD01] Seddigh、N。およびM. Devetsikiotis、「TCPの再送信タイムアウトメカニズムの研究」、2001年のIEEE国際通信会議（ICC 2001）、第6巻、1834-1840、2001年6月の議事録。
[SKK+97] Schuba, C., Krsul, I., Kuhn, M., Spafford, E., Sundaram, A., and D. Zamboni, "Analysis of a Denial of Service Attack on TCP", Proceedings of the 1997 IEEE Symposium on Security and Privacy 1997.
[Skk 97] Schuba、C.、Krsul、I.、Kuhn、M.、Spafford、E.、Sundaram、A.、およびD. Zamboni、「TCPに対するサービス拒否攻撃の分析」、1997年の議事録IEEE Symposium on Security and Privacy 1997。
[Ste95] Stevens, W. and G. Wright, "TCP/IP Illustrated, Volume 2: The Implementation", January 1995.
[Ste95] Stevens、W。and G. Wright、「TCP/IP Illustrated、Volume 2：The Information」、1995年1月。
[cr.yp.to] Bernstein, D., "SYN cookies", visited in December 2005, <http://cr.yp.to/syncookies.html>.
[Cr.yp.to] Bernstein、D。、「Syn Cookies」、2005年12月に訪問、<http://cr.yp.to/syncookies.html>。
[win2k3-wp] Microsoft Corporation, "Microsoft Windows Server 2003 TCP/IP Implementation Details", White Paper, July 2005.
[Win2K3-WP] Microsoft Corporation、「Microsoft Windows Server 2003 TCP/IP実装の詳細」、2005年7月。
This information is taken from Bernstein's web page on SYN cookies [cr.yp.to]. This is a rewriting of the technical information on that web page and not a full replacement. There are other slightly different ways of implementing the SYN cookie concept than the exact means described here, although the basic idea of encoding data into the SYN-ACK sequence number is constant.
この情報は、Syn Cookies [cr.yp.to]に関するBernsteinのWebページから取得されます。これは、そのWebページの技術情報の書き換えであり、完全な代替品ではありません。Syn-ackシーケンス番号にデータをエンコードするという基本的な考え方は一定ですが、Syn Cookieの概念を実装する他のわずかに異なる方法がここで説明されていますが、他にはわずかに異なる方法があります。
A SYN cookie is an initial sequence number sent in the SYN-ACK, that is chosen based on the connection initiator's initial sequence number, MSS, a time counter, and the relevant addresses and port numbers. The actual bits comprising the SYN cookie are chosen to be the bitwise difference (exclusive-or) between the SYN's sequence number and a 32 bit quantity computed so that the top five bits come from a 32-bit counter value modulo 32, where the counter increases every 64 seconds, the next 3 bits encode a usable MSS near to the one in the SYN, and the bottom 24 bits are a server-selected secret function of pair of IP addresses, the pair of port numbers, and the 32-bit counter used for the first 5 bits. This means of selecting an initial sequence number for use in the SYN-ACK complies with the rule that TCP sequence numbers increase slowly.
Syn Cookieは、syn-ackで送信される初期シーケンス番号であり、接続イニシエーターの初期シーケンス番号、MSS、タイムカウンター、および関連するアドレスとポート番号に基づいて選択されます。Syn Cookieを含む実際のビットは、Synのシーケンス番号と32ビット数量の間のビットワイズ差（排他的またはまたは）に選択され、上位5ビットは32ビットカウンター値Modulo 32から来るようになります。64秒ごとに増加し、次の3ビットはSynの1つに近い使用可能なMSSをエンコードし、下部24ビットは、IPアドレスのペア、ポート番号のペア、および32ビットのサーバーが選択した秘密関数です最初の5ビットに使用されるカウンター。Syn-ackで使用する初期シーケンス番号を選択するこの手段は、TCPシーケンス数がゆっくりと増加するというルールに準拠しています。
When a connection in LISTEN receives a SYN segment, it can generate a SYN cookie and send it in the sequence number of a SYN-ACK, without allocating any other state. If an ACK comes back, the difference between the acknowledged sequence number and the sequence number of the ACK segment can be checked against recent values of the counter and the secret function's output given those counter values and the IP addresses and port numbers in the ACK segment. If there is a match, the connection can be accepted, since it is statistically very likely that the other side received the SYN cookie and did not simply guess a valid cookie value. If there is not a match, the connection can be rejected under the heuristic that it is probably not in response to a recently sent SYN-ACK.
リスニングの接続がSynセグメントを受信すると、Syn Cookieを生成し、他の状態を割り当てることなく、Syn-ackのシーケンス番号に送信できます。ACKが戻ってきた場合、ACKセグメントのカウンターの最近の値と、ACKセグメントのIPアドレスとポート番号を考慮して、ACKセグメントのACKセグメントのシーケンス番号の違いを確認できます。。一致がある場合、反対側がSyn Cookieを受け取っており、単に有効なCookie値を推測しなかった可能性が非常に高いため、接続を受け入れることができます。一致がない場合、最近送られたsyn-ackに応じていないというヒューリスティックの下で、接続を拒否することができます。
With SYN cookies enabled, a host will be able to remain responsive even when under a SYN flooding attack. The largest price to be paid for using SYN cookies is in the disabling of the window scaling option, which disables high performance.
Syn Cookieを有効にすると、Syn Flooding攻撃を受けている場合でも、ホストは応答性を維持できます。Syn Cookieを使用するために支払われる最大の価格は、高性能を無効にするウィンドウスケーリングオプションの無効化です。
Bernstein's web page [cr.yp.to] contains more information about the initial conceptualization and implementation of SYN cookies, and archives of emails documenting this history. It also lists some false negative claims that have been made about SYN cookies, and discusses reducing the vulnerability of SYN cookie implementations to blind connection forgery by an attacker guessing valid cookies.
BernsteinのWebページ[cr.yp.to]には、Syn Cookieの初期概念化と実装、およびこの履歴を文書化するメールのアーカイブに関する詳細情報が含まれています。また、Syn Cookieについて行われたいくつかの誤ったネガティブな主張をリストし、有効なCookieを推測する攻撃者によるSyn Cookieの実装の脆弱性を低下させることを議論しています。
The best description of the exact SYN cookie algorithms is in a part of an email from Bernstein, that is archived on the web site (notice it does not set the top five bits from the counter modulo 32, as the previous description did, but instead uses 29 bits from the second MD5 operation and 3 bits for the index into the MSS table; establishing the secret values is also not discussed). The remainder of this section is excerpted from Bernstein's email [cr.yp.to]:
正確なSyn Cookieアルゴリズムの最良の説明は、WebサイトにアーカイブされているBernsteinからの電子メールの一部にあります（前の説明がしたように、Counter Modulo 32から上位5ビットを設定するのではなく、代わりに2番目のMD5操作から29ビット、MSSテーブルへのインデックスに3ビットを使用します。秘密の値を確立することについても説明しません）。このセクションの残りの部分は、バーンスタインのメール[cr.yp.to]から抜粋しています。
Here's what an implementation would involve:
実装に関係するものは次のとおりです。
Maintain two (constant) secret keys, sec1 and sec2.
2つの（一定の）シークレットキー、Sec1とSec2を維持します。
Maintain a (constant) sorted table of 8 common MSS values, msstab[8].
8つの一般的なMSS値の（一定）ソートされたテーブル、MSSTAB [8]を維持します。
Keep track of a "last overflow time".
「最後のオーバーフロー時間」を追跡します。
Maintain a counter that increases slowly over time and never repeats, such as "number of seconds since 1970, shifted right 6 bits".
「1970年以降の秒数は、右6ビットをシフトした」など、時間とともにゆっくりと繰り返されることのないカウンターを維持します。
When a SYN comes in from (saddr,sport) to (daddr,dport) with ISN x, find the largest i for which msstab[i] <= the incoming MSS. Compute
synが（saddr、sport）からisn xで（daddr、dport）に登場すると、msstab [i] <=入っているmssの最大のIを見つけます。計算します
z = MD5(sec1,saddr,sport,daddr,dport,sec1)
z = md5（Sec1、saddr、sport、daddr、dport、sec1）
+ x
+ バツ
+ (counter << 24)
+ (MD5(sec2,counter,saddr,sport,daddr,dport,sec2) % (1 <<
24))
and then
その後
y = (i << 29) + (z % (1 << 29))
Create a TCB as usual, with y as our ISN. Send back a SYNACK.
yをisnとして、通常どおりTCBを作成します。シナックを送り返します。
Exception: _If_ we're out of memory for TCBs, set the "last overflow time" to the current time. Send the SYNACK anyway, with all fancy options turned off.
例外：_IF_私たちはTCBの記憶から外れており、「最後のオーバーフロー時間」を現在の時刻に設定しています。とにかくシナックを送ってください。すべての派手なオプションがオフになります。
When an ACK comes back, follow this procedure to find a TCB: (1) Look for a (saddr,sport,daddr,dport) TCB. If it's there, done.
ACKが戻ってきたら、この手順に従ってTCBを見つけます。（1）（SADDR、SPORT、DADDR、DPORT）TCBを探します。それがそこにあるなら、やった。
(2) If the "last overflow time" is earlier than a few minutes ago, give up.
(2) 「最後のオーバーフロー時間」が数分前より早い場合は、あきらめてください。
(3) Figure out whether our alleged ISN makes sense. This means recomputing y as above, for each of the counters that could have been used in the last few minutes (say, the last four counters), and seeing whether any of the y's match the ISN in the bottom 29 bits. If none of them do, give up.
(3) 申し立てられたISNが理にかなっているかどうかを把握してください。これは、最後の数分で使用できる各カウンター（最後の4つのカウンターなど）で、上記のようにyを再計算し、yのいずれかが下部29ビットのISNと一致するかどうかを確認することを意味します。それらのどれもしない場合は、あきらめてください。
(4) Create a new TCB. The top three bits of our ISN give a usable MSS. Turn off all fancy options.
(4) 新しいTCBを作成します。ISNの上位3ビットは、使用可能なMSSを提供します。すべての派手なオプションをオフにします。
Author's Address
著者の連絡先
Wesley M. Eddy Verizon Federal Network Systems NASA Glenn Research Center 21000 Brookpark Rd, MS 54-5 Cleveland, OH 44135
Wesley M. Eddy Verizon Federal Network Systems Nasa Glenn Research Center 21000 Brookpark Rd、MS 54-5クリーブランド、OH 44135
Phone: 216-433-6682 EMail: weddy@grc.nasa.gov
電話：216-433-6682メール：weddy@grc.nasa.gov
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。