JP2005073272A

JP2005073272A - Ｔｃｐステートレス・ホグによるｔｃｐサーバに対する分散サービス妨害攻撃を防御する方法および装置

Info

Publication number: JP2005073272A
Application number: JP2004244509A
Authority: JP
Inventors: Dong Lin; リンドング
Original assignee: Lucent Technologies Inc
Current assignee: Nokia of America Corp
Priority date: 2003-08-25
Filing date: 2004-08-25
Publication date: 2005-03-17
Anticipated expiration: 2024-08-25
Also published as: JP4373306B2; US7404210B2; US20050060557A1

Abstract

【課題】一定の形態の分散サービス妨害（ＤＤｏＳ）攻撃の防御を提供すること。
【解決手段】ＴＣＰステートレス・ホグによる分散サービス妨害（ＤＤｏＳ）攻撃は、ＲＦＣ１１２２によって与えられるキープ・アライブ機構に対する拡張を使用することによって覆される。ＴＣＰサーバは、可能なアタッカから新しいＴＣＰ接続要求を受信し、それに対して、「無効」シーケンス番号を使用してキープ・アライブ・プローブ・パケットを送り戻す。例示的には、この「無効」シーケンス番号は、実際の現シーケンス番号からかなり離れるように選択された乱数を含む。応答パケットを潜在的アタッカから受信したとき、ＴＣＰサーバが、受信したパケット中の肯定応答番号の正確さを検証し、それによって潜在的アタッカがＴＣＰステートレス・ホグである可能性があるか否かを判定する。
【選択図】図１

Description

本発明は、一般にインターネット・セキュリティの分野に関し、より詳細には、一定の形態の分散サービス妨害（ＤＤｏＳ）攻撃を防御する問題に関する。

関連出願への相互参照
本願は、先にＤ．Ｌｉｎによって２００３年８月２５日に出願された仮特許出願第６０／４９７８８６号「ＤｅｆｅｎｓｅＡｇａｉｎｓｔＳｔａｔｅＡｔｔａｃｋｓＯｎＴＣＰＳｅｒｖｅｒｓ」の特典を主張するものである。

サービス妨害（ＤｏＳ）攻撃は、限られたサーバ資源が正当なユーザにではなくアタッカに割り振られたときに、サービスの破壊を引き起こす。分散サービス妨害（ＤＤｏＳ）攻撃は、地理的に異なるインターネット・ノードから被害者に向けて、協調したＤｏＳ攻撃を送り出す。攻撃側マシンは通常、リモート・マスタによって制御される、損なわれたゾンビ・マシンである。通常攻撃対象となる資源は、リンク帯域幅、サーバ・メモリ、およびＣＰＵ時間を含む。分散ＤｏＳ攻撃は、収束するトラフィックの全体的効果のためにさらに強力であり、特にアタッカがネットワーク・トポロジの内部知識を持っているときはそうである。「ＴＣＰＳＹＮフラッド」、「スマーフＩＰｐｉｎｇ」、およびルート・ネーム・サーバに対する帯域幅攻撃はすべて、以前に配置された攻撃の例である（こうした攻撃はそれぞれ当業者には周知であろう）。しかし、以前に知られていたよりもずっと多くの攻撃が実際には存在していたことが報告されている。

資源枯渇を阻止するようにサーバ・オペレーティング・システムを改良する多数の手法が存在する。その一部では、（当業者に周知の）ステートフル・ハンドシェーク・プロトコルに対する攻撃からサーバを保護するために、より良好なネットワーク・プロトコル設計原理が考慮されている。ＩＰトレース・バックは別の周知の手法である。ＩＰトレース・バックは、攻撃パケットをその発信元までたどるようネットワーク全体で協調する作業である。しかし、このような手法は明らかに、ネットワーク全体での協働および協調を必要とする。

実際に、以前の多くの攻撃は、入口フィルタリングがインターネット全体に配置されていた場合、またはソース・アドレス検証プロトコルが広く使用されていた場合、完全に防ぐことができたはずである。また、最近の帯域幅攻撃の多くの被害者は、非スプーフＩＣＭＰ応答パケットによってフラッディングされたが、対応するＩＣＭＰエコー要求はすべてスプーフされた（当業者には周知のように、「スプーフされた」パケットとは、ソース・アドレスが虚偽であるか誤っているものである）。監視およびネットワーク輻輳制御のために、署名によるヒューリスティック・ベースの帯域幅攻撃検出も考慮された。例えば、提案された一手法では、着信パケットがＵＤＰ、ＴＣＰ、ＴＣＰＳＹＮ、およびＣＧＩの各カテゴリに分類され（各カテゴリは、完全に当業者には周知である）、次いでクラス・ベースのレート制御および重み付きフェア・キューイングが実施される。

さらに、ＤＤｏＳ攻撃ツールは、時間と共に変化し、進化する傾向がある。例えば、出口フィルタリングが広く配置されると共に、アタッカは、疑いなく、オープンのままにされる可能性が最も高いドア（例えば、ＴＣＰ、ＤＮＳ）を利用することになる。攻撃署名は、検出を逃れるために変化または消滅する可能性がある。したがって、精巧な将来の攻撃は、正当なものとほとんど区別できなくなる可能性が高い。したがって、この問題に対して、フィルタリング・ベースの手法単独では、非効率であるだけでなく不十分である。多くの偽の正量（ｆａｌｓｅｐｏｓｉｔｉｖｅ）により、研究者は、新しいヒューリスティックスを求めて最初からやり直すことを余儀なくされる。

ＴＣＰサーバに対するＤＤｏＳ攻撃の特定の一タイプは、目標とするサーバのメモリが枯渇し、したがって正当なユーザからサービス要求を受諾することができなくなるまで、目標とするサーバとの新しいＴＣＰ接続を連続的に作成することによって送り出される可能性がある（当業者には周知のように、ＴＣＰは周知の国防総省標準伝送制御プロトコルである。例えば「ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ」（ＤｅｆｅｎｓｅＡｄｖａｎｃｅｄＲｅｓｅａｒｃｈＰｒｏｊｅｃｔｓＡｇｅｎｃｙ向けにＩｎｆｏｒｍａｔｉｏｎＳｃｉｅｎｃｅｓＩｎｓｔｉｔｕｔｅで作成）Ｊ．Ｐｏｓｔｅｌ編、ＲｅｑｕｅｓｔｆｏｒＣｏｍｍｅｎｔｓ（ＲＦＣ）７９３、１９８１年９月、「ｗｗｗ．ｆａｑｓ．ｏｒｇ／ｒｆｃｓ／ｒｆｃ７９３．ｈｔｍｌ」を参照されたい。ＲＦＣ７９３は、本明細書にあたかも完全に記載されているかのように参照により本明細書に組み込まれる）。このような攻撃の有害な効果は、確立された各ＴＣＰ接続が必然的にＴＣＰサーバ上に状態を作成し、したがってこうした状態を格納するために割り当てられたメモリ量が、オープン接続の総数に比例することに起因する。このような攻撃は従来「Ｎａｐｔｈａ」と呼ばれ、当業者に周知であるが、本明細書ではより一般的に「ＴＣＰステートレス・ホグ」攻撃と呼ぶことにする。
仮特許出願第６０／４９７８８６号「ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ」ｐｒｅｐａｒｅｄｆｏｒＤｅｆｅｎｓｅＡｄｖａｎｃｅｄＲｅｓｅａｒｃｈＰｒｏｊｅｃｔｓＡｇｅｎｃｙｂｙＩｎｆｏｒｍａｔｉｏｎＳｃｉｅｎｃｅｓＩｎｓｔｉｔｕｔｅ、Ｊ．Ｐｏｓｔｅｌ編、ＲｅｑｕｅｓｔｆｏｒＣｏｍｍｅｎｔｓ（ＲＦＣ）７９３、１９８１年９月、「ｗｗｗ．ｆａｑｓ．ｏｒｇ／ｒｆｃｓ／ｒｆｃ７９３．ｈｔｍｌ」「ＲｅｑｕｉｒｅｍｅｎｔｓｆｏｒＩｎｔｅｒｎｅｔＨｏｓｔｓ − ＣｏｍｍｕｎｉｃａｔｉｏｎＬａｙｅｒｓ」、ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ，Ｒ．Ｂｒａｄｅｎ編、ＮｅｔｗｏｒｋＷｏｒｋｉｎｇＧｒｏｕｐ、ＲｅｑｕｅｓｔｆｏｒＣｏｍｍｅｎｔｓ（ＲＦＣ）１１２２、セクション４．２．３．６、１９８９年１０月、「ｗｗｗ．ｆａｑｓ．ｏｒｇ／ｒｆｃｓ／ｒｆｃｌｌ２２．ｈｔｍｌ」

ＴＣＰステートレス・ホグ（すなわちＮａｐｔｈａ）攻撃の周知の防御法は存在しない。しかし、ＴＣＰキープ・アライブ機構が、インターネット・コミュニティの公式の仕様として当業者に周知である。例えば「ＲｅｑｕｉｒｅｍｅｎｔｓｆｏｒＩｎｔｅｒｎｅｔＨｏｓｔｓ − ＣｏｍｍｕｎｉｃａｔｉｏｎＬａｙｅｒｓ」、ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ，Ｒ．Ｂｒａｄｅｎ編、ＮｅｔｗｏｒｋＷｏｒｋｉｎｇＧｒｏｕｐ、ＲｅｑｕｅｓｔｆｏｒＣｏｍｍｅｎｔｓ（ＲＦＣ）１１２２，セクション４．２．３．６、１９８９年１０月、「ｗｗｗ．ｆａｑｓ．ｏｒｇ／ｒｆｃｓ／ｒｆｃｌｌ２２．ｈｔｍｌ」を参照されたい（ＲＦＣ１１２２のセクション４．２．３．６は、本明細書にあたかも完全に記載されているかのように参照により本明細書に組み込まれる）。有利には、このキープ・アライブ機構は、クライアントがネットワーク障害中に接続をクラッシュまたは異常終了した場合に、普通なら無限にハングして不必要に資源を消費する可能性のあるサーバ・アプリケーションで呼び出すことができる。このようなキープ・アライブ機構は、攻撃の進行中に、原理上はＴＣＰサーバを軽減するのに使用することができるが、アタッカが多くのコストを払わなくとも容易に覆される可能性がある。

本発明者は、有利には、ＲＦＣ１１２２によって与えられるキープ・アライブ機構を、ＴＣＰステートレス・ホグを効果的に検出してそれを覆す仕方で修正（すなわち強化）することができることを理解した。具体的には、本発明の原理によれば、ＴＣＰサーバが、可能なアタッカから新しいＴＣＰ接続要求を受信する。次いで、有利には、キープ・アライブ・プローブ・パケットがＴＣＰサーバによって潜在的アタッカに送信されるが、本発明の原理によれば、「無効」シーケンス番号を使用してパケットが送信される。本発明の例示的一実施形態によれば、有利には、この「無効」シーケンス番号は、実際の現シーケンス番号からかなり離れるように選択された乱数を含む。最後に、応答パケットを潜在的アタッカから受信したとき、ＴＣＰサーバが、受信したパケット中の肯定応答番号の正確さを検証し、それによって潜在的アタッカがＴＣＰステートレス・ホグである可能性があるか否かを判定する。

図１に、本発明の例示的実施形態によるＴＣＰステートレス・ホグ防御機構を組み込むＤＤｏＳゲートウェイの機能ブロック図を示す。有利には、この例示的ＤＤｏＳゲートウェイは、保護すべきリンクから１ホップ上流側のネットワーク・エッジに配置される。例示的ゲートウェイの動作の際には、まず、コアから到来するパケットがディスパッチ・モジュール１１によってディスパッチされ、ＴＣＰパケットが互いに分離される（非ＴＣＰパケットは非ＴＣＰモジュール１２によって処理される）。ゲートウェイの前の状態を有する各データ・パケットは、検査モジュール１３によって決定される一定のバッファ管理ポリシーの対象となる様々なキューに分類することができる。しかしＳＹＮパケットは、転送すべき前の状態を必要とせず、したがって、有利には、接続モジュール１４によって別々に処理される。次いで、データ・パケット、ＳＹＮパケット、および非ＴＣＰプロトコルからのパケットが、ＦｌｏｗＱモジュール１５により、保護されるリンク上に出現するようにスケジュールされる。逆方向については、ＴＣＰサーバからのパケットが、ウォッチ・モジュール１６によって検査され、コアからの着信パケットをさらに処理するためのステートフル情報を提供する。有利には、本発明の例示的実施形態による、以下で詳細に説明するＴＣＰステートレス・ホグ検出機構は、ウォッチ・モジュール１６に組み込まれる。

当業者には完全に周知であるように、ＲＦＣ１１２２のセクション４．２．３．６に記載のＴＣＰキープ・アライブ機構は通常、クライアントがネットワーク障害中に接続をクラッシュまたは異常終了した場合に、普通なら無限にハングして不必要に資源を消費する可能性のあるサーバ・アプリケーションで呼び出される。具体的には、データまたは肯定応答パケット（ＡＣＫとも呼ばれる）が期間内の接続に関して受信されたときに、キープ・アライブ・パケットを所与の接続に送信することができる。それに応答して、キープ・アライブ・パケットの受信側は、肯定応答パケット（ＡＣＫ）を送り返すと予想される。本発明の原理によれば、有利には、まさにこの機構を使用して、攻撃の進行中に、ＴＣＰサーバを軽減することができる。

しかし、ＲＦＣ１１２２に記載のキープ・アライブ機構は、アタッカが多くのコストを払わなくともＴＣＰステートレス・ホグによって容易に覆される可能性がある。具体的には、通常はそれ自体がブレークインの被害者である攻撃側マシンは、単に適切なＡＣＫでキープ・アライブ・プローブに応答することができ、サーバが接続をクローズすることを実質上防止する。具体的には、アタッカは単に、「シーケンス番号」および「肯定応答番号」のフィールドを切り換えることにより、受信したキープ・アライブ・パケットから直接、戻りＡＣＫ（肯定応答パケット）を作成する。それによって、攻撃側ホスト上で必要なメモリは一定となり、攻撃のために作成されるＴＣＰ接続の数と無関係となる。

しかし、本発明の原理およびその例示的実施形態によれば、有利には、ＴＣＰキープ・アライブ機構が、ＴＣＰステートレス・ホグ攻撃を効果的に検出してそれを覆す仕方で修正される。本発明の例示的一実施形態によれば、本発明の技法を、新しいＴＣＰ実装または既存のＴＣＰ実装に直接適合させることができる。本発明の別の例示的実施形態によれば、本発明の技法を、ＤＤｏＳゲートウェイ中のネットワーク・エッジに配置して、レガシー・システムを保護することができる。

当業者に完全に周知であるかのようであるが、キープ・アライブ・プローブ・パケットはとりわけ、サーバからクライアントに送信された最後のデータ・オクテットに対応するシーケンス番号を含む。クライアントは、同じオクテットと一致して、肯定応答で応答すると予想される。したがって、上述のように、キープ・アライブ・プロセスに何らかの修正がない場合、アタッカは単に、シーケンス番号をコピーすることによってプローブに回答することができる。

しかし本発明の原理によれば、有利には、「無効」番号が、キープ・アライブ・プローブ・パケット中のシーケンス番号として使用される。具体的には、ＴＣＰの仕様（すなわちＲＦＣ７９３）によれば、肯定応答セグメントが、現送信シーケンス番号と、受信されると予想される次のシーケンス番号を示す肯定応答を含むことに留意されたい。ＴＣＰシーケンス番号は３２ビット符号なし整数であり、ラップ・アラウンドするので、任意の番号を原理上は有効な番号とすることができる。しかし、１つの可能な「無効」番号は、初期シーケンス番号から１を引いたものである（これはある意味では、「最も可能性の低い」有効番号、すなわち「最も可能性の高い」無効番号である）。したがって、本発明の例示的一実施形態によれば、初期シーケンス番号から１を引いたものが、送信されるキープ・アライブ・パケット中の「無効」シーケンス番号として使用される。

しかし、任意の固定数または固定の（すなわち決定性の）アルゴリズムによって生成された数は、使用されている特定のアルゴリズムをアタッカが知っている場合にアタッカによって潜在的に推測される可能性があることに留意されたい。したがって、本発明の別の好ましい例示的実施形態によれば、有利には、「無効」シーケンス番号がランダムに（すなわち、乱数発生器を使用して）選ばれる。さらに、この好ましい実施形態によれば、接続で現在使用されている可能性のある数との潜在的な混乱を回避するために、有利には、選択空間が可能な限り現シーケンス番号から離れるように選択空間を定義することができる。例えば、ＴＣＰ接続が、１度のラウンド・トリップのうちに３２ビット整数空間を使い果たす可能性は極めて低い。したがって、本発明の好ましい例示的実施形態によれば、有利には、以下の式を使用して、ランダムに選んだ「無効」シーケンス番号「ｋｅｅｐ−ａｌｉｖｅ．ｓｅｑ」を選択する。
ｋｅｅｐ−ａｌｉｖｅ．ｓｅｑ＝ｓｎｄ＿ｕｎａ−２^３０−ｒａｎｄｏｍ（２^２０）（１）

上式で、「ｓｎｄ＿ｕｎａ」は、最小の未承認送信側シーケンス番号（すなわち、最大の承認シーケンス番号に１を加えたもの）であり、「ｒａｎｄｏｍ（２^２０）」は、ゼロと２の２０乗の間に一様に分布するランダムに生成した整数を表す。具体的には、上記の式（１）が３２ビット符号なし整数を生成し、したがって計算で生じるアンダーフローおよびオーバーフローがラップ・アラウンドすること、すなわち演算はすべて２^３２を法として実施されることに留意されたい。

有効な肯定応答の構築は、正当かつ適合するＴＣＰ実装で行われるのと同様に、応答側ホスト上の状態を維持することを必要とすることに留意されたい。ＴＣＰ仕様（すなわちＲＦＣ７９３）は肯定応答セグメントが現送信シーケンス番号と、受信されると予想される次のシーケンス番号を示す肯定応答を含むことを必要とするので、すべての適合するＴＣＰ実装は、最後のシーケンス番号で応答するように規定される。ＴＣＰステートレス・ホグ・プログラムは、正しい応答を生成することができない。どんな不正確な応答も、ＴＣＰサーバおよびＤＤｏＳゲートウェイで容易に検出することができる。したがって、有利には、こうした不正確な応答回答に関連する接続を１００％の精度で除去することができる。

具体的には、本発明の例示的実施形態によれば、例示的ＤＤｏＳゲートウェイが、ＴＣＰ接続の確立を開始したネットワーク・ソースに、前述のように無効シーケンス番号を含むキープ・アライブ・パケットを送信する。次いで、例示的ＤＤｏＳゲートウェイは、ネットワーク・ソースから受信した（または受信しなかった）応答に基づいて以下のように動作する。
１．ネットワーク・ソースがキープ・アライブ・パケットに応答することに失敗した場合、通常通り、かつキープ・アライブ機構の規格で指定される通りに、接続がタイムアウトとなり、システムから除去される。これは、「デッド（ｄｅａｄ）」接続の結果であるか、またはネットワーク・ソースが実際にＴＣＰステートレス・ホグであり、応答するように（または応答できるように）プログラムされないことの結果であることのいずれかである可能性があることに留意されたい。
２．ネットワーク・ソースが「正しい」ＡＣＫ（すなわち、「正しい」肯定応答番号が含まれる肯定応答パケット）で応答した場合、接続は有効であり（すなわち、ネットワーク・ソースがＴＣＰステートレス・ホグではないとみなすことができ）、未修正のまま維持される。
３．ネットワーク・ソースが不正確なＡＣＫ（すなわち、「不正確な」肯定応答番号が含まれる肯定応答パケット）で応答した場合、接続は疑いなく無効な接続である（例えば、ネットワーク・ソースはＴＣＰステートレス・ホグである）。したがって、本発明の例示的実施形態によれば、この場合、有利には、接続がシステムから除去される。

具体的には、キープ・アライブ・パケットに対する正しい応答は一般に、（ｓｎｄ＿ｕｎａ−１）に等しい肯定応答番号、またはパケットが通過中に並び替えられる場合にはわずかに小さい値に等しい肯定応答番号を搬送すべきである。したがって、有利には、「正しい」肯定応答番号は、値「ｓｎｄ＿ｕｎａ」（すなわち最小の未承認送信側シーケンス番号）に近い任意の数とみなすことができ、一方、有利には、「不正確な」肯定応答番号は、「ｓｎｄ＿ｕｎａ」から遠距離の任意の値とみなすことができる。有利には、式（１）中の項「２^３０」の減算は、値「ｓｎｄ＿ｕｎａ」とキープ・アライブ・パケット中に含まれるシーケンス番号との間にそのような遠距離を生み出すために使用される。

本発明の例示的一実施形態によれば、返されたＡＣＫ中に含まれる肯定応答番号が（ｓｎｄ＿ｕｎａ−Ｗ）から（ｓｎｄ＿ｕｎａ）の範囲内にない場合、ネットワーク・ソースがＴＣＰステートレス・ホグであるとみなされ、有利には、接続が除去される。項Ｗは、有利には過渡的ｏｕｔｏｆｏｒｄｅｒパケットが存在する状態を可能にする小さい定数である。例示的には、Ｗの最大値は、例えば前のＴＣＰ輻輳ウィンドウ・サイズに等しく設定することができる（当業者に周知のＴＣＰ輻輳ウィンドウは、上記で参照したＴＣＰ標準ＲＦＣ７９３の一部として定義される）。接続がある期間アイドル状態であった場合、有利には、Ｗを値ゼロに設定できることに留意されたい。

本発明の別の例示的実施形態によれば、動的ホスト毎（あるいはサブネット毎）アイドル接続限界を実施することによって上述の方法が強化される。具体的には、この特定の例示的実施形態によれば、ホスト毎またはサブネット毎のアイドル接続の総数が、リアル・タイムで監視され分類される。アイドル接続の総数が所定の限界を超えたとき、有利には、最もアイドルである接続を有するホストまたはサブネットからの接続を、新しく到来する接続に置き換える。

図２に、本発明の例示的実施形態によるＴＣＰステートレス・ホグを防御する方法のフローチャートを示す。まずブロック２１で、ネットワーク・ソースからＴＣＰ接続要求を受信し、それに応答してＴＣＰ接続を確立する。次いでブロック２２では、本発明の原理による、上記で例示的に説明した無効シーケンス番号を含むキープ・アライブ・パケットを、与えられたＴＣＰ接続の確立を開始したネットワーク・ソースに送信する。例示的フローチャートのブロック２３では、キープ・アライブ・パケット（すなわちＡＣＫ）に対する応答を待ち、タイムアウトが生じた場合（すなわち、応答パケットを適切な所定の期間内に受信しなかった場合）、フローはブロック２５に進み、（通常通り）与えられたＴＣＰ接続を終了する。そうでない場合、ブロック２４で応答パケットの内容を検査して、（例えば上記で定義したように）肯定応答番号が「正しい」か、それとも「不正確」であるかを判定する。正しい場合、フローはブロック２６に進み、接続を維持する（すなわち、有効とみなす）。しかし、不正確である場合、フローはブロック２５に進み、接続が、ＴＣＰステートレス・ホグによって確立されたか、または単にデッド接続であると推定されるので、与えられたＴＣＰ接続を終了する。

詳細な説明の補足
上記の議論のすべては、単に本発明の一般的原理を例示するに過ぎないことに留意されたい。本明細書で明示的に説明または図示していないが、本発明の原理を具体化し、本発明の精神および範囲内に含まれる様々な他の構成を、当業者が考案できることを理解されよう。さらに、本明細書で引用したすべての例および条件付き言語は主に、読者が本発明の原理および本発明者等によって提供された概念を理解し、当技術分野を発展させる際の助けとなるように、明白に、教育的な目的のためだけに意図されるものであり、具体的に引用した例および条件に限定されないと解釈すべきである。さらに、本発明の原理、態様、および実施形態を引用する本明細書のすべての陳述ならびにその特定の例は、その構造的と機能的均等物を共に包含するものとする。このような均等物は、現在周知の均等物と将来開発される均等物、すなわち構造の如何に関わらず同じ機能を実施する、開発される任意の要素を共に含むものとする。

したがって例えば、任意のフローチャート、流れ図、状態遷移図、疑似コードなどが、実質上コンピュータ可読媒体として表すことができ、したがってコンピュータまたはプロセッサにより、そうしたコンピュータまたはプロセッサが明示的に示されているか否かに関わらず実行することのできる様々なプロセスを表すことを当業者は理解されよう。したがって、例えばそうしたフローチャートで示されるブロックは、潜在的に、例えばフローチャート・ブロックで説明したような特定の機能を指定する手段として本クレイムで表すことのできる物理的要素を表すと理解することができる。さらに、このようなフローチャート・ブロックは、例えば、ディスクや半導体記憶装置などの前述のコンピュータ可読媒体に含めることができる物理的信号または格納された物理的データを表すと理解することもできる。

本発明の例示的実施形態によるＴＣＰステートレス・ホグ防御機構を組み込むＤＤｏＳゲートウェイの機能ブロック図を示す図である。本発明の例示的実施形態によるＴＣＰステートレス・ホグを防御する方法のフローチャートを示す図である。本発明の例示的実施形態によるＴＣＰステートレス・ホグを防御機構を組み込むＤＤｏＳゲートウェイにおける、ＳＹＮパケットの処理を示す図である。

Claims

ＴＣＰステートレス・ホグによって行われるサービス妨害攻撃を防御する方法であって、
ネットワーク・ソースからＴＣＰ接続要求を受信し、それに応答してＴＣＰ接続を確立する工程と、
前記ＴＣＰ接続に関連するキープ・アライブ・パケットを前記ネットワーク・ソースに送信する工程であって、前記キープ・アライブ・パケットが無効シーケンス番号を有する工程と、
前記ネットワーク・ソースから、前記ＴＣＰ接続に関連する前記キープ・アライブ・パケットに対する応答を受信する工程と、
前記受信した応答に基づいて、前記ネットワーク・ソースがＴＣＰステートレス・ホグであるか否かを判定する工程とを含む方法。
前記無効シーケンス番号が、ランダムに生成された数に基づいて導出される請求項１に記載の方法。
前記無効シーケンス番号がさらに、現シーケンス番号に基づいて導出される請求項２に記載の方法。
前記無効シーケンス番号が、前記無効シーケンス番号が前記現シーケンス番号と数値的に隔たるよう保証する公式に基づいて導出される請求項３に記載の方法。
前記受信した応答が承認番号を有し、前記ネットワーク・ソースがＴＣＰステートレス・ホグであるか否かを判定する前記工程が、前記承認番号を前記現シーケンス番号と比較する工程を含む請求項３に記載の方法。
前記ネットワーク・ソースがＴＣＰステートレス・ホグであるか否かを判定する前記工程が、前記承認番号が前記現シーケンス番号から所定の数値距離内にないときに、前記ネットワーク・ソースがＴＣＰステートレス・ホグであると判定する工程を含む請求項５に記載の方法。
前記ネットワーク・ソースがＴＣＰステートレス・ホグであるか否かを判定する前記工程が、前記ネットワーク・ソースがＴＣＰステートレス・ホグであると判定したとき、前記ＴＣＰ接続を除去する工程をさらに含む請求項１に記載の方法。
アイドル接続の数値カウントを維持する工程と、アイドル接続の前記数値カウントが所定のアイドル接続限界を超過したときに前記ＴＣＰ接続を除去する工程とをさらに含む請求項１に記載の方法。
ＴＣＰステートレス・ホグによって行われるサービス妨害攻撃を防御する装置であって、
ネットワーク・ソースからＴＣＰ接続要求を受信し、それに応答してＴＣＰ接続を確立する手段と、
前記ＴＣＰ接続に関連するキープ・アライブ・パケットを前記ネットワーク・ソースに送信する手段であって、前記キープ・アライブ・パケットが無効シーケンス番号を有する手段と、
前記ネットワーク・ソースから、前記ＴＣＰ接続に関連する前記キープ・アライブ・パケットに対する応答を受信する手段と、
前記受信した応答に基づいて、前記ネットワーク・ソースがＴＣＰステートレス・ホグであるか否かを判定する手段とを備える装置。