RFC4987 日本語訳
4987 TCP SYN Flooding Attacks and Common Mitigations. W. Eddy. August 2007. (Format: TXT=48753 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group W. Eddy Request for Comments: 4987 Verizon Category: Informational August 2007
コメントを求めるワーキンググループW.渦巻要求をネットワークでつないでください: 4987年のベライゾンカテゴリ: 情報の2007年8月
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).
IETFが信じる著作権(C)(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 implementersと管理者の利益のために攻撃と共同防衛のテクニックに関する説明を格納しますが、少しの規格レベル推薦状もしません。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 記述. . . . . . . . . . . . . . . . . . . . . . 2 2.1を攻撃してください。 歴史. . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2。 動作理論. . . . . . . . . . . . . . . . . . . 3 3。 共同防衛. . . . . . . . . . . . . . . . . . . . . . . 6 3.1。 .63.2をフィルターにかけます。 予備. . . . . . . . . . . . . . . . . . . . 7 3.3を増加させます。 SYNによって容認されたタイマ. . . . . . . . . . . . . . . 7 3.4を減少させます。 最も古い半開きなTCB. . . . . . . . . . . . 7 3.5を再生します。 SYNは.83.6をキャッシュします。 SYNクッキー. . . . . . . . . . . . . . . . . . . . . . . 8 3.7。 ハイブリッド手法. . . . . . . . . . . . . . . . . . . . 10 3.8。 ファイアウォールとプロキシ. . . . . . . . . . . . . . . . . . 10 4。 分析. . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 13 6。 承認. . . . . . . . . . . . . . . . . . . . . . . 13 7。 有益である、.13付録A.SYNクッキー記述に、.16に参照をつけます。
Eddy Informational [Page 1] RFC 4987 TCP SYN Flooding August 2007
[1ページ]情報のRFC4987TCP SYN氾濫2007年8月に、渦巻いてください。
1. Introduction
1. 序論
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フラッディング攻撃はTCPサーバの過程を走らせるホストに影響するサービスの否定方法です。 攻撃はLISTEN状態に入れられたポートにSYNセグメントを受けた後にTCPがしばらく実行する州の保有を利用します。 基本的な考え方はホストがあるにせの半分接続に十分な状態を保有することを引き起こすのによるどんなリソースも新しい正統の接続を確立するのを残さなかったこの振舞いを利用することです。
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に提示されます。 SYNクッキーに関する詳細はAppendix Aに含まれています。
2. Attack Description
2. 攻撃記述
This section describes both the history and the technical basis of the SYN flooding attack.
このセクションは歴史とSYNフラッディング攻撃の技術的な基礎の両方について説明します。
Eddy Informational [Page 2] RFC 4987 TCP SYN Flooding August 2007
[2ページ]情報のRFC4987TCP SYN氾濫2007年8月に、渦巻いてください。
2.1. History
2.1. 歴史
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年にはビルチェスウィックとスティーブBellovin[B96]によってもう発見されました。 彼らがそれらの本での攻撃のときにパラグラフを含んで、次に、取り除いた、「ファイアウォールとインターネットセキュリティ:」 「陰険なハッカーを退ける」[CB94]。 残念ながら、対策は全く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.
記述と功績ツールのリリースがPhrack Magazine[P48-13]にある状態で、SYNフラッディング攻撃は1996年に最初に、ピーアールされました。 いくつかの小さい方の誤りは別として役に立つようにこの記事には十分高い品質があって、記事からのコードは、広く分配されて、使用されました。
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はすばやく攻撃[カリフォルニア-96.21]に関する状況報告を発表しました。 SYN氾濫は比較で当時他の知られているサービス不能攻撃に特に重大でした。 ネットワークのリソースを単に枯渇させる一般的な馬鹿力戦術を当てにするよりむしろ、SYN氾濫は終わりホストリソースを狙います。(リソースは使い果たすより少ないパケットを必要とします)。
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工程でまだ標準化されるか、または認可されていませんが。
2.2. Theory of Operation
2.2. 動作理論
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.
RFC793で説明されるように、TCP実現は、LISTEN状態がすべてで入られるのを許可するかもしれません、とIPの組のいくつか、またはだれも記述しないで、ポートナンバーはアプリケーションで指定しました。 ウェブサーバーのような多くの一般的なアプリケーションでは、リモートホストの情報のいずれも、あらかじめ知られているか、またはあらかじめ設定されません、サーバにおいて、詳細が早めに未知であるどんなクライアントと共にも接続を確立できるように。 「無限」のLISTENのこのタイプはそれがオペレーティングシステムで通常実行される方法によるSYNフラッディング攻撃の目標です。
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
成功のために、SYNフラッディング攻撃は犠牲者ホストTCP実現の振舞いに依存します。 特に、それは、犠牲者がそれが受け取られていて、限界がそのような状態の量にあるあらゆるTCP SYNセグメントのために保つことができるより状態を割り当てると仮定します。
Eddy Informational [Page 3] RFC 4987 TCP SYN Flooding August 2007
[3ページ]情報のRFC4987TCP SYN氾濫2007年8月に、渦巻いてください。
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.
いつでも。 現在のベースTCP仕様(RFC793[RFC0793])は入って来るSYNセグメントの標準の処理について説明します。 RFC793は、個々の接続のためにすべての州の情報を格納するためにTransmission Control Block(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.
接続がLISTEN状態にある地方のTCPポートにSYNを受け取るとき、状態はRFC793に従って次に、SYN- RECEIVEDに移行します、そして、いくらかのTCBが容認されたSYNセグメントのヘッダーフィールドからの情報で初期化されます。 実際には、多くのオペレーティングシステムはLISTENで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].
例として、リナックス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構造の数はオペレーティングシステムカーネルで制限されます。 限界が指定港番号にグローバルに適用されているか、または地方であることにかかわらずシステムはオンに構成変更します。 限界がSYN-RECEIVEDのそれらと同様に完全に確立した接続に適用されるかどうかの変化もあります。 一般的に、() アプリケーションがこの限界のために値を示すことができるシステムコールを聴いて、予備と呼ばれて、システムは典型的にパラメタを実行します。 予備限界に達していると、入って来るSYNセグメントを無視するか、または予備での未完成の接続を取り替えます。 予備を使用する概念が規格文書で説明されないので、予備に達しているとき、失敗の振舞いはスタックの間で異なるかもしれません(例えば、TCP RSTsは発生するかもしれません)。 正確な失敗の振舞いは、ホストを開始するか否かに関係なく、時間がたつにつれてSYNセグメントを再送し続けるように決定するか、またはすぐにやむでしょう。 リソースが制約つきであるときにだけ、地方のスタックの動きに影響して、相互運用性問題を引き起こさないので、実現のこれらの違いは許容しています。
Eddy Informational [Page 4] RFC 4987 TCP SYN Flooding August 2007
[4ページ]情報のRFC4987TCP SYN氾濫2007年8月に、渦巻いてください。
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フラッディング攻撃は、ネットワークのリソースか終わりのホストの記憶を積みすぎるのを試みませんが、ポートナンバーに関連している半開きな接続の予備を消耗させるのを単に試みます。 目標は回答を発生させないIPアドレス(しばしばだまされる)から生産されるSYN-ACKsに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実現は半分開かれた接続からメモリを一般的に取り戻します。 例えば、リリースされるために最初のSYN-ACKが送る、やむ満了原因SYN-ACK retransmissions、およびTCBにあるとき、75秒[SKK+97]のタイマは設定されるかもしれません。 TCP仕様は任意の時の後にコネクション確立に見切りをつけるこの振舞いを含んでいません。 純粋主義者の中にはTCP実現が、アプリケーションがあきらめるまで人工の領域(しかし何らかの保存しているレートへの指数のbackoffで)なしでSYNとSYN-ACKセグメントを再送し続けるべきであると言い表した人もいました。 これにもかかわらず、今日の共同運用システムは半開きなTCB生涯における何らかの人工の限界を実行します。 例えば、合計511秒以降引き返して、止まるのは、4.4BSD-Lite[Ste95]で観測できて、このコードから得られたいくつかのオペレーティングシステムでまだ練習されています。
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
有効なままで残るために、SYNフラッディング攻撃は、前の弾幕からのTCBsが開墾され始めるとすぐに、にせの接続要求の新しい弾幕を送る必要があります。 弾幕の頻度は犠牲者TCP実現のTCB改善タイマに合わせます。 潜在的により多くの注意、および頻度も引いて、必要とされるより高い頻度はさらに多くのパケットの出典を明示します。
Eddy Informational [Page 5] RFC 4987 TCP SYN Flooding August 2007
[5ページ]情報のRFC4987TCP SYN氾濫2007年8月に、渦巻いてください。
low will allow windows of time where legitimate connections can be
established.
安値は正統の接続を確立できる時間の窓を許容するでしょう。
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セグメントへの無反応であることは重要です。 普通の接続ホストのアドレスが使用されていると、それらのホストは、すぐに対応するTCBを解放するTCPリセットセグメントを犠牲者に送って、正統の接続が作られている予備の余地を許すでしょう。 オリジナルの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フラッディング攻撃を開始するのにホストの多数を使用するのを代わりに選ぶかもしれません。 例えば、攻撃者のコントロール(すなわち、"botnet")の下における易感染性宿主の収集を使用できました。 この場合、攻撃で利用された各ホストは目標から来るSYN-ACKsへのオペレーティングシステムのネイティブの応答を抑圧しなければならないでしょう。 また、攻撃TCPセグメントがここで使用された「弾幕」用語より連続したファッションに到着するのが示されるのも、可能です。 新しいSYNsのレートがTCBsが刈り取られるレートを超えている限り、攻撃はうまくいくでしょう。
3. Common Defenses
3. 共同防衛
This section discusses a number of defense techniques that are known to the community, many of which are available in off-the-shelf products.
このセクションはそれの多くがすぐ入手できる製品の中に利用可能である共同体において知られている多くのディフェンスのテクニックについて論じます。
3.1. Filtering
3.1. フィルタリング
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
だまされたソースIPアドレスがあるパケットを送る能力が制御ホストの軍隊がないときこの攻撃が働くのに必要であるので、だまされたIPパケットを送る攻撃者の能力を取り除くのは、TCPへの変更を全く必要としない効果的な解決です。 RFCs2827、3013年、および3704年に説明されたフィルター技術
Eddy Informational [Page 6] RFC 4987 TCP SYN Flooding August 2007
[6ページ]情報のRFC4987TCP SYN氾濫2007年8月に、渦巻いてください。
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に基づいてアドレス[RFC2827][RFC3013][RFC3704]をフィルターにかけるパケットのために最も良い現在の実務を表してください。 完全に効果的である間、終わりのホストはだまされたセグメントから攻撃を防ぐために方針をフィルターにかけるのを当てにするべきではありません、フィルタのグローバルな展開が保証されていなくてまたありそうでないときに。 また、易感染性宿主のグループを使用するか、または異なったアクセスプロバイダーの間で急速に変化する能力がある攻撃者はフィルタリングを無力な解決策にするでしょう。
3.2. Increasing Backlog
3.2. 増加する予備
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.
ディフェンスへの明白な試みは終わりのホストが、より大きい予備を使用することです。 予備のサイズが[Lem02]を育てるとき、レモンは無料OSの一つ4.4でそれを示して、この戦術にはいくつかの重大な否定的な一面があります。 実現は数100の予備、およびデータ構造を超えて比例するように設計されていません、そして、それが使用する検索アルゴリズムは、より大きい予備によって効率が悪いです。 他のTCP実現には他の解決策が利用可能であることで、大きい予備で彼らの性能を制限してください。そうすれば、スタックが非常に大きい予備を支持するために改良されるべきであるやむにやまれない理由が全く見えない同様の設計要素があると仮定するのは妥当です。 しかしながら、私たちが知っている限り、大きい予備が効率的なデータ構造と検索アルゴリズムを使用している実験が行われていません。
3.3. Reducing SYN-RECEIVED Timer
3.3. SYNによって容認されたタイマを減少させます。
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でTCBsの生涯を制限するタイマを減少させるのは失敗します。 より短いタイマが予備でにせの接続試みが同じくらい長い間持続するのを妨げて、その結果、正統の接続で、より早いようにスペースを開けている間、それは、正統の接続のある部分が完全に確立するようになるのを防ぐことができます。 また、弾幕頻度を直線的に比例している量で増加させるのが攻撃者を必要とするだけであるので、この戦術も効力がありません。 このタイマ減少は予備占有、またはSYNレセプションの何らかのレートに何らかの敷居に交差することへの応答として時々実行されます。
3.4. Recycling the Oldest Half-Open TCB
3.4. 最も古い半開きなTCBを再生します。
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.
全体の予備がいったん疲れ果てるようになると、いくつかの実現で、入って来るSYNsは最も古い半開きなTCBエントリーを上書きできます。 これは入って来る攻撃SYNsが予備をいっぱいにすることができるより少ない時間正統の接続を完全に確立できるという仮定の下で働きます。 攻撃しているパケットレートが高いときに、これが失敗できて、予備サイズは、小さく、体力を要しているディフェンスではありません。
Eddy Informational [Page 7] RFC 4987 TCP SYN Flooding August 2007
[7ページ]情報のRFC4987TCP SYN氾濫2007年8月に、渦巻いてください。
3.5. SYN Cache
3.5. 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.
Lemon[Lem02]が最も良い説明したSYNキャッシュはすなわち、すぐに完全なTCBを割り当てないことでSYNが割り当てる状態の量を最小にするのに基づいています。 接続が完全に確立されるまで、完全な州の配分は遅れます。 SYNキャッシュを実行するホストが彼らが入って来る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キャッシュのテクニックは効果的です。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]でデータを運ぶSYNsが使用されます。 多くのポピュラーなオペレーティングシステム[GN00]でT/TCPは実行されますが、それは現在、めったに使用されないように思えます。 1つのサイトの境界ルータ[All07]における測定値はどの36がT/TCP CCNEWオプション(0.001%)を運んだかに関する254万5785のSYNセグメント(SYN-ACKsでない)を登録しました。 これらは26人のユニークなホストから来ました、そして、他のT/TCPオプションは全く見られませんでした。 データがある2,287のSYNセグメントが見られました(0.09は%のすべてのSYNセグメントをそうします)、すべて。どれにまさに24バイトのデータがあったかについて。 これらの観測は、SYNキャッシュの問題とSYNセグメントに関するデータが展開で重要でないかもしれないことを示します。
3.6. SYN Cookies
3.6. 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
SYNクッキーは、SYN-RECEIVEDでの接続のために一歩先まで踏み込んで、状態を全く割り当てません。 代わりに、彼らは通常、彼らがSYN-ACKで伝えられた一連番号に維持する州(そして、厳密に必要のすべて)の状態の大部分をコード化します。 SYNがだまされなかったなら、TCBに入れるために状態を再建するのに、握手を終了するACKの承認番号(他のいくつかの分野に伴う)を使用できます。 日付、1
Eddy Informational [Page 8] RFC 4987 TCP SYN Flooding August 2007
[8ページ]情報のRFC4987TCP SYN氾濫2007年8月に、渦巻いてください。
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.
ダン・バーンスタインのウェブサイト[cr.yp.to]でSYNクッキーで最も良い参照を見つけることができます。 このテクニックはTCPヘッダーフィールド[RFC1144][RFC4413]で長く理解されている低エントロピーを利用します。 Appendix Aでは、私たちは、ウェブページが入手できなくなる可能性を避けるためにSYNクッキーのテクニックについて説明します。
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ビットと他のデータ[Lem02]のための25ビットを使用しました。 IPアドレスの端が欠けている暗号の細切れ肉料理で受け取られた初期の一連番号のXOR、TCPポートナンバー組、および秘密のビットにはこれらのビットをコード化する1つの方法がありました。 実際には、この細切れ肉料理は、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クッキーに関する問題は一般的に実行された計画がいくつかのTCPオプションと両立しないということです、クッキー世代計画がそれらを考えないなら。 例えば、4つの事前に定義された一般的なMSS値を表すのに2一連番号ビットを使用することによって、SYNの広告に掲載されているMaximum Segment Size(MSS)のコード化を設備してあります。 同様のテクニックがある他のTCPオプションに必要でしょう、それとなく他のTCPオプションの交渉された使用を検出できますが。 例として、ACKに関するタイムスタンプは、Timestamp使用がSYNとSYN-ACKに関して首尾よく交渉されたのを示します、接続の間の何らかの時点でのSelective Acknowledgement(SACK)オプションのレセプションは、SACKが交渉されたのを含意しますが。 通常、SACKブロックがホストによってそれらが最初に受け取られない場合TCPクッキーを使用することで送られるはずがないことに注意してください。 多くのTCP接続における一般的な単方向のデータフローに関しては、SACK用法を制限するとき、これは問題であるかもしれません。 この理由で、SYNクッキーは、デフォルトでそれらを実行するシステムの上で通常使用されないで、攻撃を暗示した高い応力条件、または管理動作で可能にされるだけです。
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
最近、無料OSの一つ7.0におけるリリースのために見いだされた新しいSYNクッキー技術は状態をコード化するための一連番号ビットに加えたTimestampオプションのビットを利用します。 Timestamp値がACKパケットのTimestamp Echo分野でecho backであるので、Timestampオプションで保存されたどんな状態も同様にそれが基本的なSYNクッキーの中に一連番号/承認から来ている方法に回復できます。 Timestampビットを使用して、それは、明らかに同様のもののためのビットが送る状態を保存して、窓のスケールを受けるのにおいて可能で、SACKによって許容されて、TCP-MD5によって可能にされます、典型的なSYNクッキーの中にどれが余地が全くないように。 SYNクッキーに固有の感染を改良するTimestampsのこの使用は無料OSの一つにユニークです。
Eddy Informational [Page 9] RFC 4987 TCP SYN Flooding August 2007
[9ページ]情報のRFC4987TCP SYN氾濫2007年8月に、渦巻いてください。
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.
私たちが知っている限り、実装。 制限はSYN自身がTimestampオプションを含んでいる場合にだけテクニックを使用できますが、このオプションが今日広く実装されるように思えるということです、そして、ホストのそのサポート窓のスケーリングとSACKはまた、タイムスタンプを通常サポートします。
Similarly to SYN caches, SYN cookies do not handle application data piggybacked on the SYN segment.
同様に、SYNキャッシュに、SYNクッキーは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クッキーに関する別の問題はアプリケーションのために最初のアプリケーションデータが受け身のホストによって送られるところにあります。 このホストが多くの接続を扱っているなら、パケット損失はありそうであるかもしれません。 創始者からの握手を完成するACKが無くなるとき、受け身側の応用層は、接続の存在について通知されて、データを決して送りません、創始者は、接続が首尾よく確立されたと考えますが。 最初アプリケーションの層のデータが受け身側によって送られる例のアプリケーションはSMTPです、RFC2821(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クッキー実装が存在していて、配布されますが、SYNクッキーの使用がデフォルト設定でしばしば無効にされるので、どのくらいの運用経験が実際にそれらで存在しているか、そして、またはそれらを使用すると新しい脆弱性が開くかどうかが不明瞭です。 SYNクッキーが典型的なウェブサーバーで使用されたインシデントの逸話は防備がないときに、あらゆるSYNパケットのためにMD5合計を計算する負担が受けた加えられた処理が比較でアプリケーションの可用性の損失に重要でないことを示すように思えます。 いくつかの計算上強制的なモバイルか組み込み機器に関しては、この状況は異なっているかもしれません。
3.7. Hybrid Approaches
3.7. ハイブリッド手法
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クッキーのテクニックを結合できます。 例えば、そして、キャッシュが完全になる場合、到着のキャッシュエントリーから新しいSYNsを一掃することの代わりにSYNクッキーを送ることができます。 そのようなハイブリッド手法はそれぞれのアプローチの肯定的な面の強い組み合わせを提供するかもしれません。 レモンはこのハイブリッド[Lem02]に関するユーティリティを実施説明しました。
3.8. Firewalls and Proxies
3.8. ファイアウォールとプロキシ
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
また、ファイアウォールベースの戦術は、SYNフラッディング攻撃から終わりのホストを防御するのに使用されるかもしれません。 基本概念が完成するまで接続試みを上映するファイアウォールへコネクション確立手順を積み下ろすことであり、次に、プロキシは保護された終わりのホストへの彼らであって戻ります。 これは、ファイアウォールかプロキシの問題になるように終わりのホストから遠くの問題を動かして、もう一方を導入するかもしれません。
Eddy Informational [Page 10] RFC 4987 TCP SYN Flooding August 2007
[10ページ]情報のRFC4987TCP SYN氾濫2007年8月に、渦巻いてください。
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].
問題は終わりから終わりへのTCPの予想された意味論を変更するのに関係しました。 これらのファイアウォールとプロキシ製品の中に使用された一般的な戦術は、接続が完全に確立されるまで、保護されたネットワークから上でベースのテクニックが議論した終わりのホストのひとりを実装して、入って来るSYNsを上映することです。 これは、握手[Eddy06]の様々な段階の創始者とリスナーにいくつかのパケットのソースアドレスを偽造することによって、達成されます。
4. Analysis
4. 分析
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 implementersがそのような回線保護装置の存在を仮定するのは、楽観的です。 TCP implementersは終わりホスト導入における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キャッシュとSYNクッキーアプローチはこれまで発見された唯一の実行可能なテクニックであるように思えます。 予備を増強して、SYN-RECEIVEDタイマを減少させるのはある程度まで問題が多いです。 SYNキャッシュはSYNクッキーより高いメモリーフットプリントを含意します。 しかしながら、SYNクッキーは、完全にいくつかのTCPオプションと互換性があるかもしれないというわけではなくて、状態を必要とする将来のTCP拡張子の開発を妨げるかもしれません。 これらの理由で、デフォルトでそれらを提供するシステムの上でSYNクッキーを可能にするべきではありません。 SYNキャッシュは、同じマイナス要素を持たないで、デフォルト処理方式として可能にされるかもしれません。
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月に、デーヴ・ボーマンはBSD/OSのためにBSDiでSYNキャッシュを実装しました。(それは、制限なしで共同体に与えられました)。 このコードは後で他のBSD異形に採用されたSYNキャッシュ実装の基礎であるように思えます。 私たちがデフォルトでというよりむしろいっぱいに説明したように予備がなったなら、キャッシュは使用されていました。 tcp-implメーリングリストへの注意で、このコードがSYN-ACKs[B97]を再送しないのがわかります。 より最近の実装は、この決定をひるがえして、SYN-ACKsを再送するのを選びました。 SYNsのための初期の再送信タイマーがひどく保守的であるか(いくつかのオペレーティングシステムのように)、または再送されたSYNsが無くなるとき、SYN- ACKパケットの損失が珍しくなく[SD01]、厳しく接続に関する実績を遅くすることができるのが知られています。 その上、SYN氾濫攻撃者に高い送付レートがあるなら、再送されたSYNsの損失がありそうであるので、SYN-ACKsが再送されないなら、効率的に正統の接続を確立するという可能性は小さくされます。
Eddy Informational [Page 11] RFC 4987 TCP SYN Flooding August 2007
[11ページ]情報のRFC4987TCP SYN氾濫2007年8月に、渦巻いてください。
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年に、386BSD派生のOSはボーマンのコードの変更されたバージョンを取り入れました。 元のコードからの2つの注目に値する違いがデフォルトで(すべての接続のために)キャッシュを使用するという決定によります。 これはSYN-ACKsのために「再-トランスミッション」を実行して、より完全なデータを保つのにより大きい構造を使用する必要性を含意しました。 元の構造は、IPv4接続のための32バイト長とIPv6サポートがある56バイトでした、現在の無料OSの一つ構造は196バイト長ですが。 以前に引用されるように、Lemonは無料OSの一つ4.4[Lem02]におけるSYNキャッシュとクッキーのテクニックを実装しました。 SYNキャッシュ構造が160バイトを取ったというレモンメモは完全なTCB(現在のキャッシュ構造への196バイト)のために736と比較されました。 私たちは、OpenBSD3.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.
リナックス、試験でも、2.6.5コードは8つのMSS値をコード化して、デフォルトでSYNクッキーを使用しないSYNクッキー実装を含んでいます。 2.6に前の数年の間、この機能性はリナックスカーネルで.5に存在しています。
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クッキーがIPv6と共に実装されるとき、SYN-ACKで使用されるIPv6流れラベル価値はパケットの残りにその流れの中で使用される流れラベルと一致しているべきです。 SYNキャッシュとSYNクッキーコード[MM05]によって生成されたSYN-ACKsで無作為の流れラベルを使用した実装バグがありました。
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].
Windows2000と共に始まって、マイクロソフトのウインドウズ・オペレーティングシステムには「TCP SYN攻撃保護」の特徴がありました。(登録でオンかオフにそれを切り換えることができます)。 デフォルトでどれに関してWindows2003SP1までそれがあるかで離れてデフォルトとしたこれ。 再送されたSYN-ACKsとの半開きな接続と半開きな接続の数が構成可能な敷居を超えて、次に、SYN-ACKsがあきらめる前に再送されるという回の数が減少して、「経路キャッシュエントリー」作成(いくつかの特徴(例えば、窓のスケーリング)が使用されるのを防ぐ)が遅れるとき可能にされたこの特徴[win2k3-wp]で。
Several vendors of commercial firewall products sell devices that can mitigate SYN flooding's effects on end hosts by proxying connections.
商業ファイアウォール製品のいくつかのベンダーが、接続をproxyingすることによって、続けてSYN氾濫の効果を緩和できるデバイスにホストを販売します。
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
TCPのデザインにおけるSYN氾濫脆弱性の発見と攻略はプロトコルデザイナーにとって、貴重なレッスンを提供しました。 Stream Control Transmissionプロトコル[RFC2960](より最近、設計された)は聴取終わりのベースの状態がないクッキー部品で4ウェイ握手を取り入れました。 このように、受け身初め側には、どんな状態も割り当てる前に創始者が本当に与えられたアドレスに存在するというより良い証拠があります。 Host Identityプロトコル塩基置換[MNJH07]は、4ウェイ握手として同様に設計されていますが、そうしなければならない創始者に送られたパズルにまたかかわります。
Eddy Informational [Page 12] RFC 4987 TCP SYN Flooding August 2007
[12ページ]情報のRFC4987TCP SYN氾濫2007年8月に、渦巻いてください。
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].
どんな状態も応答者によって予約される前に解決されてください。 サービス不能攻撃を避けるプロトコルセットアップへの設計の国がないことに関する一般概念はAuraとNikander[AN97]によって議論されました。
5. Security Considerations
5. セキュリティ問題
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の数に影響を及ぼすべきでなくて、一般的に利用可能な緩和の使用を奨励することによって、そのような攻撃にインターネットの丈夫さを増強するかもしれません。
6. Acknowledgements
6. 承認
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.
テッド・フェーバーとの会話は、このドキュメントを書くための起動力でした。 ジョーTouch、デーヴ・ボーマン、フェルナンドGont、ジーン-バティスト・マーチャンド、クリスチャンのHuitema、ケイトリンBestler、ペッカSavola、アンドレOppermann、アルフレッドHoenes、マーク・オールマン、ラース・エッゲルト、パシEronen、ウォレンKumari、デヴィッド・マローン、ロンBonica、およびリサDusseaultからのコメントと提案はこのドキュメントを強化する際に役に立ちました。 Appendix Aで贈られたTCP SYNクッキーへのオリジナルの作業は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のAdvanced Communications、Navigation、およびSurveillance Architecturesの組み合わせで基金を部分的に提供しました、そして、System Technologies(ACAST)は突出しています、Sensis社、NASAのスペースコミュニケーションズのArchitecture作業部会、およびNASAの地球科学Technologyオフィス。
7. Informative References
7. 有益な参照
[AN97] Aura, T. and P. Nikander, "Stateless Connections",
Proceedings of the First International Conference on
Information and Communication Security, 1997.
情報とコミュニケーションセキュリティの国際労働者協会コンファレンス、1997年の[AN97]香気とT.とP.Nikander、「状態がないコネクションズ」、議事。
[All07] Allman, M., "personal communication", February 2007.
[All07] オールマン、M.、「個人的なコミュニケーション」、2007年2月。
Eddy Informational [Page 13] RFC 4987 TCP SYN Flooding August 2007
[13ページ]情報のRFC4987TCP SYN氾濫2007年8月に、渦巻いてください。
[B96] Bennahum, D., "PANIX ATTACK", MEME 2.12, October 1996,
<http://memex.org/meme2-12.html>.
[B96] Bennahum、D.、「PANIX攻撃」、ミーム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クッキー(Re: 迅速な明確化であった…)」、IETF tcp-implメーリングリスト、1997年6月。
[CA-96.21] CERT, "CERT Advisory CA-1996-21 TCP SYN Flooding and IP
Spoofing Attacks", September 1996.
1996年9月の[カリフォルニア-96.21]本命と、「CERT勧告カリフォルニア-1996-21TCP SYN氾濫とIPスプーフィング攻撃」
[CB94] Cheswick, W. and S. Bellovin, "Firewalls and Internet
Security", ISBN: 0201633574, January 1994.
[CB94] チェスウィック、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] 渦巻、W.、「TCP SYNフラッディング攻撃に対するディフェンス」、第8コクチマスインターネットプロトコルジャーナル巻、No.4、2006年12月。
[GN00] Griffin, M. and J. Nelson, "T/TCP: TCP for
Transactions", Linux Journal, February 2000.
[GN00] グリフィン、M.、およびJ.ネルソン、「T/TCP:」 「トランザクションのためのTCP」、リナックスジャーナル、2000年2月。
[Lem02] Lemon, J., "Resisting SYN Flood DoS Attacks with a SYN
Cache", BSDCON 2002, February 2002.
[Lem02] レモン、J.、「SYNキャッシュとの抵抗SYN洪水DoS攻撃」、BSDCON2002、2002年2月。
[MM05] McGann, O. and D. Malone, "Flow Label Filtering
Feasibility", European Conference on Computer Network
Defense 2005, December 2005.
[MM05] マックガンとO.とD.マローン、「流れラベルフィルタリングの実行可能性」、コンピュータネットワークディフェンス2005、2005年12月のヨーロッパのコンファレンス。
[MNJH07] Moskowitz, R., Nikander, P., Jokela, P., and T.
Henderson, "Host Identity Protocol", Work in Progress,
June 2007.
仕事進行中の[MNJH07]マスコウィッツとR.、NikanderとP.とJokela、P.とT.ヘンダーソン、「ホストアイデンティティプロトコル」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、ルート、および無限、「プロジェクトネプチューン」、Phrack Magazine、Volume7、Issue48、18のFile13、1996年7月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC0793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed
serial links", RFC 1144, February 1990.
[RFC1144] ジェーコブソン、V.、「低速連続のリンクへのTCP/IPヘッダーを圧縮します」、RFC1144、1990年2月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm",
RFC 1321, April 1992.
[RFC1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions
Functional Specification", RFC 1644, July 1994.
[RFC1644]ブレーデン、B.、「T/TCP--、トランザクションに、機能的なTCP拡張子、仕様、」、RFC1644、7月1994日
Eddy Informational [Page 14] RFC 4987 TCP SYN Flooding August 2007
[14ページ]情報のRFC4987TCP SYN氾濫2007年8月に、渦巻いてください。
[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] ファーガソン、P.、およびD.Senieは「以下をフィルターにかけるイングレスをネットワークでつなぎます」。 「IP Source Address Spoofingを使うサービス妨害Attacksを破ります」、BCP38、RFC2827、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] スチュワート、R.、シェ、Q.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「ストリーム制御伝動プロトコル」、RFC2960(2000年10月)対パクソン
[RFC3013] Killalea, T., "Recommended Internet Service Provider
Security Services and Procedures", BCP 46, RFC 3013,
November 2000.
T. [RFC3013]Killalea、BCP46、RFC3013、11月2000日「インターネットサービスプロバイダセキュリティー・サービスと手順は推薦され」て、
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.とP.Savola、「Multihomedのためにネットワークをフィルターにかけるイングレス」BCP84、2004年3月のRFC3704。
[RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior",
RFC 4413, March 2006.
[RFC4413] 西洋とM.とS.マッキャン、「TCP/IP分野の振舞い」、RFC4413、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.
Communications(ICC2001)、6、1834-1840ページのボリューム(2001年6月)の[SD01]SeddighとN.とM.Devetsikiotis、「TCPの再送タイムアウトメカニズムの研究」、2001年のIEEEの国際コンファレンスのProceedings。
[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] シューバ、C.、Krsul、I.、キューン、M.、Spafford、E.、Sundaram、A.、およびD.ザンボーニ、「TCPにおけるサービス不能攻撃の分析」、セキュリティとプライバシー1997における1997年のIEEEシンポジウムの議事。
[Ste95] Stevens, W. and G. Wright, "TCP/IP Illustrated, Volume
2: The Implementation", January 1995.
[Ste95] スティーブンス、W.、およびG.ライト、「TCP/IPは例証して、ボリュームは2です」。 1995年1月の「実装。」
[cr.yp.to] Bernstein, D., "SYN cookies", visited in December 2005,
<http://cr.yp.to/syncookies.html>.
D.、「SYNクッキー」という[cr.yp.to]バーンスタインは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]マイクロソフト社、「マイクロソフトWindowsサーバ2003TCP/IP実装の詳細」、白書、2005年7月。
Eddy Informational [Page 15] RFC 4987 TCP SYN Flooding August 2007
[15ページ]情報のRFC4987TCP SYN氾濫2007年8月に、渦巻いてください。
Appendix A. SYN Cookies Description
付録A.SYNクッキー記述
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クッキー[cr.yp.to]の上にバーンスタインのウェブページからこの情報を取ります。 これは完全置換ではなく、そのウェブページの技術資料の書き直しです。 ここで説明された正確な手段以外のSYNクッキー概念を実装するわずかに異なった方法があります、SYN-ACK一連番号にデータを暗号化する基本的な考え方は一定ですが。
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クッキーがSYN-ACKで送られた初期シーケンス番号である、それは接続創始者の初期シーケンス番号、MSS、時間カウンタ、関連アドレス、およびポートナンバーに基づいて選ばれています。 SYNクッキーを含む実際のビットが選ばれている、量がトップ5ビットがカウンタが64秒毎に増加する32ビットの対価法32から来て、次の3ビットがSYNのものに近い使用可能なMSSをコード化して、下部24ビットがサーバで選択された秘密の機能であるようにIPアドレスの組、ポートナンバーの組に計算したSYNの一連番号と32ビットの間で違い(排他的論理和)をbitwiseして、使用される32ビットのカウンタを最初の5ビットbitwiseしてください。 初期の一連番号に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.
LISTENでの接続がSYNセグメントを受けるとき、SYNクッキーを生成して、SYN-ACKの一連番号でそれを送ることができます、いかなる他の状態も割り当てないで。 ACKが戻るなら、ACKセグメントのそれらの対価、IPアドレス、およびポートナンバーを考えて、カウンタと秘密の機能の出力の最近の値に対して承認された一連番号とACKセグメントの一連番号の違いをチェックできます。 マッチがあれば、接続を受け入れることができます、反対側がSYNクッキーを受けて、統計的に有効なクッキー値を非常に絶対に推測しそうになかったので。 マッチがなければ、それがたぶん最近送られた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フラッディング攻撃のままであることのときにさえ、SYNクッキーが可能にされていたホストは敏感なままであることができるでしょう。 窓のスケーリングオプションを無効にすることでSYNクッキーを使用する最も大きい代価があります。(オプションは高性能を無効にします)。
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.
バーンスタインのウェブページ[cr.yp.to]はSYNクッキーの初期の概念化と実装、およびこの歴史を記録するメールのアーカイブに関する詳しい情報を含んでいます。 それは、また、SYNクッキーの周りでされたいくつかの有病誤診クレームを記載して、有効なクッキーを推測する攻撃者による盲目の接続偽造にSYNクッキー実装の脆弱性を減少させるのを議論します。
Eddy Informational [Page 16] RFC 4987 TCP SYN Flooding August 2007
[16ページ]情報のRFC4987TCP SYN氾濫2007年8月に、渦巻いてください。
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クッキーアルゴリズムの最も良い記述は、バーンスタインからのメールの一部にあって、すなわち、ウェブサイトに格納されています(それがカウンタ法32から5ビット離れたところの先端を設定しないのに注意してください、しましたが、前の記述が代わりに2番目のMD5操作から29ビットとインデックスのための3ビットをMSSテーブルに使用するとき; また、秘密の値を確立するのと議論しません)。 このセクションの残りはバーンスタインのメール[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".
時間がたつにつれて、ゆっくり増加して、決して繰り返されないカウンタを維持してください、「右の6ビット移行する1970年以来の秒数」などのように。
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がISN x、掘り出し物によるmsstab[i]<が入って来るMSSと等しい最も大きいiを(saddr、スポーツ)から(daddr、dport)に入らせると。 計算してください。
z = MD5(sec1,saddr,sport,daddr,dport,sec1)
zはMD5と等しいです。(sec1、saddr、スポーツ、daddr、dport、sec1)
+ x
+ x
+ (counter << 24)
+ (カウンタ<<24)
+ (MD5(sec2,counter,saddr,sport,daddr,dport,sec2) % (1 <<
24))
+ (MD5(sec2、カウンタ、saddr、スポーツ、daddr、dport、sec2)%(1<<24))
and then
そして、その時
y = (i << 29) + (z % (1 << 29))
yは+と等しいです(i<<29)。(z%(1<<29))
Create a TCB as usual, with y as our ISN. Send back a SYNACK.
私たちのISNとしてyで通常通りでTCBを作成してください。 SYNACKを返送してください。
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.
例外: __私たちがTCBsのためのメモリを使い果たしたなら、「最後のオーバーフロー時間」から現在の時間を設定してください。 すべてのしゃれたオプションがオフにされている状態で、とにかくSYNACKを送ってください。
When an ACK comes back, follow this procedure to find a TCB:
ACKが戻ったらこの手順に従って、TCBを見つけてください:
Eddy Informational [Page 17] RFC 4987 TCP SYN Flooding August 2007
[17ページ]情報のRFC4987TCP SYN氾濫2007年8月に、渦巻いてください。
(1) Look for a (saddr,sport,daddr,dport) TCB. If it's there,
done.
(1) (saddr、スポーツ、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のどれかが29ビットの下部でISNに合っているかどうかわかるとしてyを再計算することを意味します。 それらのいずれもそうしないなら、あきらめてください。
(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
ウエスリーM.渦巻ベライゾン連邦政府のネットワーク・システムNASAグレンリサーチセンタ21000Brookpark、MS54-5クリーブランド、OH 44135番目
Phone: 216-433-6682 EMail: weddy@grc.nasa.gov
以下に電話をしてください。 216-433-6682 メールしてください: weddy@grc.nasa.gov
Eddy Informational [Page 18] RFC 4987 TCP SYN Flooding August 2007
[18ページ]情報のRFC4987TCP SYN氾濫2007年8月に、渦巻いてください。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Eddy Informational [Page 19]
渦巻情報です。[19ページ]
一覧
スポンサーリンク
