(57)【要約】中央フィルタからディテクタへの応答または肯定応答を必要とせずに、１つまたは複数のパケット・ネットワーク内で、たとえば悪意のある攻撃中に、中央フィルタに制御メッセージを信頼できる形で送達する方法および装置を提供する。ディテクタは、１つまたは複数のソースＩＰアドレスから受信されるパケットの分析に基づいて、望まれないトラフィックがターゲット犠牲者によって受信されることを判定するステップと、サービス・プロバイダに関連する中央フィルタに告発メッセージを送信するステップであって、告発メッセージが、ターゲット犠牲者へのパケットのそれによる送信が制限される、捨てられる、または許可されるうちの１つまたは複数になる少なくとも１つのソース・コンピューティング・デバイスのソース・アドレスを識別し、告発メッセージが、中央フィルタからの即座の肯定応答を必要としない告発プロトコルを使用して送信される、ステップとによって、ターゲット犠牲者によって、望まれないトラフィックに対して防御する。さらに、告発メッセージを、中央フィルタに冗長に送信することができ、告発メッセージは、好ましくは自己完結である。
2010508760.tif 000002
【特許請求の範囲】
【請求項１】
ターゲット犠牲者によって、望まれないトラフィックに対して防御する方法であって、ターゲット犠牲者が、１つまたは複数の宛先アドレスを有し、
１つまたは複数のソースＩＰアドレスから受信されるパケットの分析に基づいて、望まれないトラフィックが前記ターゲット犠牲者によって受信されることを判定するステップと、
サービス・プロバイダに関連する中央フィルタに告発メッセージを送信するステップであって、前記告発メッセージが、前記ターゲット犠牲者へのパケットのそれによる送信が制限される、捨てられる、または許可されるのうちの１つまたは複数になる少なくとも１つのソース・コンピューティング・デバイスのソース・アドレスを識別し、前記告発メッセージが、前記中央フィルタからの即座の肯定応答を必要としない告発プロトコルを使用して送信される、ステップと
を含む方法。
【請求項２】
前記望まれないトラフィックが、悪意のある攻撃またはサービス拒否攻撃を含む、請求項１に記載の方法。
【請求項３】
前記告発メッセージが、前記中央フィルタに冗長に送信される、請求項１に記載の方法。
【請求項４】
前記告発メッセージが、自己完結である、請求項１に記載の方法。
【請求項５】
前記告発プロトコルが、粗いクロック同期化を提供する、請求項１に記載の方法。
【請求項６】
前記中央フィルタから共有される状態を受信するステップと、前記状態に対するすべての変更を維持するステップとをさらに含む、請求項１に記載の方法。
【請求項７】
前記告発プロトコルが、前記告発プロトコルをねらう悪意のある攻撃を回避する１つまたは複数の特徴を含む、請求項１に記載の方法。
【請求項８】
前記告発メッセージが、複数の前記ターゲット犠牲者からの衝突する告発メッセージのうちの１つまたは複数を調停することを可能にし、前記告発プロトコルをねらう悪意のある攻撃を回避することを可能にし、前記告発メッセージの重複するコピーを破棄することを可能にするシーケンス番号を含む、請求項１に記載の方法。
【請求項９】
ターゲット犠牲者によって、望まれないトラフィックに対して防御する装置であって、ターゲット犠牲者が、１つまたは複数の宛先アドレスを含み、
メモリと、
前記メモリに結合された少なくとも１つのプロセッサであって、
１つまたは複数のソースＩＰアドレスから受信されるパケットの分析に基づいて、望まれないトラフィックが前記ターゲット犠牲者によって受信されることを判定し、
サービス・プロバイダに関連する中央フィルタに告発メッセージを送信し、前記告発メッセージが、前記ターゲット犠牲者へのパケットのそれによる送信が制限され、捨てられ、または許可されるのうちの１つまたは複数になる少なくとも１つのソース・コンピューティング・デバイスのソース・アドレスを識別し、前記告発メッセージが、前記中央フィルタからの即座の肯定応答を必要としない告発プロトコルを使用して送信される
ように動作可能である少なくとも１つのプロセッサと
を含む装置。
【請求項１０】
前記告発メッセージが、前記中央フィルタに冗長に送信される、請求項９に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケットベースの通信ネットワークのコンピュータ・セキュリティ技法に関し、より具体的には、そのようなパケットベースのネットワークでの、サービス拒否攻撃または別の悪意のある攻撃などの望まれないトラフィックを検出し、告発する方法および装置に関する。
【背景技術】
【０００２】
サービス拒否ＤｏＳ攻撃などの悪意のある攻撃は、コンピュータ・リソースをその所期のユーザから使用不能にすることを試みる。たとえば、ウェブ・サーバに対するＤｏＳ攻撃は、しばしば、ホスティングされるウェブ・ページを使用不能にする。
【０００３】
ＤｏＳ攻撃は、限られたリソースが正当なユーザではなく攻撃者に割り振られる必要がある時に、かなりのサービス妨害を引き起こし得る。攻撃する機械は、通常、攻撃のターゲット犠牲者に向けられた多数のインターネット・プロトコルＩＰパケットをインターネットを介して送信することによって、損害を与える。たとえば、ＤｏＳ攻撃は、ネットワークを「氾濫させ」、これによって、正当なネットワーク・トラフィックを妨げる試み、またはサーバが処理できるものより多数の要求を送信し、これによって１つまたは複数のサーバへのアクセスを妨げることによってサーバを一時不通にする試みを含み得る。
【０００４】
複数の技法が、そのような悪意のある攻撃に対して防御するために提案され、または提唱されてきた。たとえば、米国特許出願第１１／１９７，８４２号、名称「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｄｅｆｅｎｄｉｎｇ  Ａｇａｉｎｓｔ  Ｄｅｎｉａｌ  ｏｆ  Ｓｅｒｖｉｃｅ  Ａｔｔａｃｋｓ  ｉｎ  ＩＰ  Ｎｅｔｗｏｒｋｓ  ｂｙ  Ｔａｒｇｅｔ  Ｖｉｃｔｉｍ  Ｓｅｌｆ−Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ａｎｄ  Ｃｏｎｔｒｏｌ」および米国特許出願第１１／１９７，８４１号、名称「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｄｅｆｅｎｄｉｎｇ  Ａｇａｉｎｓｔ  Ｄｅｎｉａｌ  ｏｆ  Ｓｅｒｖｉｃｅ  Ａｔｔａｃｋｓ  ｉｎ  ＩＰ  Ｎｅｔｗｏｒｋｓ  Ｂａｓｅｄ  ｏｎ  Ｓｐｅｃｉｆｉｅｄ  Ｓｏｕｒｃｅ／Ｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  Ａｄｄｒｅｓｓ  Ｐａｉｒｓ」に、ＤｏＳ攻撃を検出し、告発する技法が開示されている。
【０００５】
そのような悪意のある攻撃に対して防御するシステムは、通常、カスタマ・ネットワークを悪意のある攻撃から保護するために、カスタマ・ネットワークに関連するディテクタと、サービス・プロバイダのネットワーク内の中央フィルタとを使用する。一般に、ディテクタは、カスタマ・ネットワークに対する悪意のある攻撃を検出し、中央フィルタに１つまたは複数の告発メッセージまたは通知メッセージを送信する。たとえば、悪意のある攻撃が、カスタマ・ネットワーク上で行われていると判定した時に、ディテクタは、中央フィルタに１つまたは複数のソース／宛先ＩＰアドレス対を送信することができ、この中央フィルタは、サービス・プロバイダに、そのソースＩＰアドレスおよび宛先ＩＰアドレスが送信されたソース／宛先ＩＰアドレス対のいずれかのソースＩＰアドレスおよび宛先ＩＰアドレスと一致するＩＰパケットの送信を制限させ、これによって、悪意のある攻撃を制限する（または除去する）。ディテクタは、通常、カスタマ・ネットワークの近くに配置される。
【０００６】
しかし、悪意のある攻撃は、通常、中央フィルタからディテクタへの制御メッセージが失われるか大きく遅延される可能性が高くなるほどに激しいパケット消失につながる。さらに、ディテクタは、悪意のある攻撃中に、ビジーになり、重い負荷を受ける可能性が高い。そのような悪意のある攻撃に対して防御する既存システムは、通常、中央フィルタへの制御メッセージ送信の肯定応答を必要とする、Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ（ＴＬＳ）、Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ（ＳＳＬ）、Ｓｅｃｕｒｅ  Ｓｈｅｌｌ（ＳＳＨ）、または別の伝送制御プロトコルＴＣＰベースのプロトコルを使用する。そのようなチャネルは、悪意のある攻撃中を除いて、通常は十分である。悪意のある攻撃中には、中央フィルタからの肯定応答が、ディテクタによって受信されない場合があり、あるいは、ディテクタの入力バッファが過負荷になる時にディテクタに到着する場合がある。一般に、ディテクタは、すべての以前の告発メッセージが中央フィルタによって正しく肯定応答されるまで、処理を継続することができない。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】米国特許出願第１１／１９７，８４２号
【特許文献２】米国特許出願第１１／１９７，８４１号
【非特許文献】
【０００８】
【非特許文献１】Ｉｎｔｅｒｎｅｔ  ＲＦＣ  ２１０４
【発明の概要】
【発明が解決しようとする課題】
【０００９】
したがって、中央フィルタからディテクタへの応答を必要としない、１つまたは複数のパケット・ネットワークでの悪意のある攻撃中に中央フィルタに制御メッセージを信頼できる形で送達する方法および装置の必要が存在する。
【課題を解決するための手段】
【００１０】
一般に、たとえば悪意のある攻撃中に、中央フィルタからディテクタへの応答または肯定応答を必要とせずに１つまたは複数のパケット・ネットワーク内で中央フィルタに制御メッセージを信頼できる形で送達する方法および装置が提供される。本発明の一態様によれば、ディテクタは、１つまたは複数のソースＩＰアドレスから受信されるパケットの分析に基づいて、望まれないトラフィックがターゲット犠牲者によって受信されることを判定するステップと、サービス・プロバイダに関連する中央フィルタに告発メッセージを送信するステップであって、告発メッセージが、ターゲット犠牲者へのパケットのそれによる送信が制限され、捨てられ、または許可されるのうちの１つまたは複数になる少なくとも１つのソース・コンピューティング・デバイスのソース・アドレスを識別し、告発メッセージが、中央フィルタからの即座の肯定応答を必要としない告発プロトコルを使用して送信される、ステップとによって、ターゲット犠牲者によって、望まれないトラフィックに対して防御する。
【００１１】
本発明のさらなる態様によれば、告発メッセージを、中央フィルタに冗長に送信することができ、告発メッセージは、好ましくは自己完結である。中央フィルタおよびディテクタは、状態情報を共有し、任意選択で、状態情報に対するすべての変更を維持する。
【００１２】
本発明のさらなる態様によれば、開示される告発プロトコルは、告発プロトコル自体をねらう悪意のある攻撃を回避する１つまたは複数の特徴を含む。たとえば、告発メッセージは、任意選択で、（ｉ）複数のターゲット犠牲者からの衝突する告発メッセージを調停することを可能にし、（ｉｉ）告発プロトコルをねらう悪意のある攻撃を回避することを可能にし、（ｉｉｉ）告発メッセージの重複するコピーを破棄することを可能にする、シーケンス番号を含む。
【００１３】
本発明のより完全な理解ならびに本発明のさらなる特徴および利益は、次の詳細な説明および図面を参照することによって得られる。
【図面の簡単な説明】
【００１４】
【図１】本発明が動作できるネットワーク環境を示す図である。
【図２】図１の中央フィルタ・システムを示す概略ブロック図である。
【図３】図１のディテクタを示す概略ブロック図である。
【図４】本発明の特徴を組み込むサービス拒否フィルタリング・プロセスの例示的実施態様を説明する流れ図である。
【図５】本発明の特徴を組み込むサービス拒否フィルタリング・プロセスの例示的実施態様を説明する流れ図である。
【図６】ＵＤＰパケットの前に付加されたＵＤＰ要求のＨＭＡＣ鍵を示す図である。
【図７】セキュアな信頼できるストリーム内のＤＰレコード・ヘッダおよびトレイラの例示的レイアウトを示す図である。
【発明を実施するための形態】
【００１５】
本発明は、１つまたは複数のパケット・ネットワーク内での悪意のある攻撃中に中央フィルタに制御メッセージを信頼できる形で送達する方法および装置を提供する。本発明の一態様によれば、カスタマ・ネットワークにあるディテクタとサービス・プロバイダのネットワークにある中央フィルタとの間の通信のための告発プロトコルが提供される。１つの例示的実施態様で、告発プロトコルは、１対の通信チャネルを含む。第１通信チャネルは、ＴＬＳチャネルなどの信頼できるセキュアな認証されたストリームである。第２通信チャネルは、認証をブートストラップするのにセキュア・チャネルを使用する、たとえばＵＤＰの上の、信頼できない認証された非ストリーム・プロトコルとすることができる。たとえば、ユーザ・データグラム・プロトコルＵＤＰを使用して、ＴＣＰベースのプロトコルを使用する従来の技法で要求される即座の肯定応答を回避することができる。この形で、たとえば悪意のある攻撃に起因する、中央フィルタからディテクタへの戻り経路内に激しいパケット消失があり、中央フィルタ肯定応答が失われる傾向がある場合に、所望の保護を、それでも達成することができる。さらに、順方向経路上のディテクタから中央フィルタへの制御メッセージの冗長送信が、順方向経路での穏当なパケット消失を克服するのに使用される。一般に、攻撃中に中央フィルタからディテクタにパケットを送信することよりも、ディテクタから中央パケットに複数の冗長パケットを送信することが好ましい。
【００１６】
図１に、本発明が動作できるネットワーク環境１００を示す。図１に示されているように、企業ネットワーク１５０は、図３に関して下でさらに説明するディテクタ３００を使用して、悪意のある攻撃に対してそれ自体を保護する。企業ネットワーク１５０は、企業ユーザが、サービス・プロバイダ・ネットワーク１２０によってインターネットまたは別のネットワークにアクセスすることを可能にする。サービス・プロバイダ・ネットワーク１２０は、企業ネットワーク１５０のユーザにサービスを提供し、入ポート１１５によってさまざまなソースからパケットを受信し、これらを企業ネットワーク１５０内の示された宛先に送信する。
【００１７】
１つの例示的実施形態で、ディテクタ３００は、図２に関して下でさらに述べる中央フィルタ２００と協力して、悪意のある攻撃からそれ自体を保護する。一般に、下でさらに述べるように、ディテクタ３００は、企業ネットワーク１５０に対する、サービス拒否攻撃などの悪意のある攻撃を検出し、サービス・プロバイダによって維持される中央フィルタ２００に通知する。
【００１８】
中央フィルタ２００は、サービス・プロバイダ・ネットワーク１２０によって企業ネットワーク１５０に達するトラフィックを制限するように働く。ディテクタ３００は、通常、企業ネットワーク１５０のファイヤウォールの背後にあり、ディテクタ３００は、通常、告発メッセージをＩＳＰの中央フィルタ２００に送信する。ディテクタ３００および中央フィルタ２００は、本発明の特徴および機能を提供するように本明細書で変更される、米国特許出願第１１／１９７，８４２号、名称「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｄｅｆｅｎｄｉｎｇ  Ａｇａｉｎｓｔ  Ｄｅｎｉａｌ  ｏｆ  Ｓｅｒｖｉｃｅ  Ａｔｔａｃｋｓ  ｉｎ  ＩＰ  Ｎｅｔｗｏｒｋｓ  ｂｙ  Ｔａｒｇｅｔ  Ｖｉｃｔｉｍ  Ｓｅｌｆ−Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ａｎｄ  Ｃｏｎｔｒｏｌ」および米国特許出願第１１／１９７，８４１号、名称「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｄｅｆｅｎｄｉｎｇ  Ａｇａｉｎｓｔ  Ｄｅｎｉａｌ  ｏｆ  Ｓｅｒｖｉｃｅ  Ａｔｔａｃｋｓ  ｉｎ  ＩＰ  Ｎｅｔｗｏｒｋｓ  Ｂａｓｅｄ  ｏｎ  Ｓｐｅｃｉｆｉｅｄ  Ｓｏｕｒｃｅ／Ｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  Ａｄｄｒｅｓｓ  Ｐａｉｒｓ」に基づいて実施することができる。
【００１９】
ディテクタ３００は、サービス拒否攻撃が企業ネットワーク１５０に対して行われつつあると判定した時に、１つまたは複数のソース／宛先ＩＰアドレス対を中央フィルタ２００に送信し、このソース／宛先ＩＰアドレス対は、サービス・プロバイダ・ネットワーク１２０に、そのソースＩＰアドレスおよび宛先ＩＰアドレスが送信されたソース／宛先ＩＰアドレス対のいずれかのソースＩＰアドレスおよび宛先ＩＰアドレスと一致するＩＰパケットの送信を制限させ（たとえば、ブロックさせるかレート制限させる）、これによって、企業ネットワーク１５０内の攻撃犠牲者への１つまたは複数のソース・デバイス１１０からのサービス拒否攻撃を制限する（または除去する）。ディテクタ３００は、任意選択で、信頼できないＵＤＰ接続１３５または主セキュア認証済み接続１３０の使用によってソース／宛先ＩＰアドレス対を送信する。本発明の一態様によれば、ディテクタ３００と中央フィルタ２００との間の通信のために告発プロトコルが提供される。
【００２０】
したがって、サービス拒否攻撃の犠牲者は、攻撃者をそのサービス・プロバイダに告発することによって「押し戻す」ことができ、このサービス・プロバイダは、これに応答して、ブロックされなければならないソース／宛先ＩＰ対のテーブルを更新する。より具体的には、攻撃が行われつつあることを認識した時に、犠牲者（企業ネットワーク１５０）は、攻撃の一部と思われるパケットで指定されるソースＩＰアドレスおよび宛先ＩＰアドレスの１つまたは複数の対を識別し、中央フィルタ２００によるブロックのためにこれらのＩＰアドレス対をサービス・プロバイダに通信する。
【００２１】
図１に示されているように、加入者（企業ネットワーク１５０）宛のパケットは、一般に「よい」トラフィックおよび「悪い」トラフィックに対応するクラスに分類される。たとえば、それぞれ、カテゴリＡ  １０５−Ａからのよいトラフィックは、配送され（許可され）、カテゴリＢ  １０５−ＢおよびカテゴリＮ  １０５−Ｎからの悪いトラフィックは、それぞれレート制限されるか捨てられる。企業ネットワーク１５０に関連する宛先アドレスにトラフィックを送信するソース・コンピューティング・デバイス１１０は、Ｎ個の例示的カテゴリのうちの１つに分類される。告発は、よいトラフィックと悪いトラフィックとの間の境界をシフトする。
【００２２】
ある種の例示的実施形態によれば、攻撃者（すなわち、１つまたは複数の識別されたソースＩＰアドレス）は、ネットワークから完全に排除される必要があるのではなく、パケットを犠牲者（すなわち、１つまたは複数の識別された宛先ＩＰアドレス）に送信することだけを禁じられることに留意されたい。これは、特に、１つまたは複数の指定されたソースＩＰアドレスが、犠牲者および関連する機械に対する所与の攻撃のために乗っ取られた正当なユーザ（たとえば、ゾンビ）を表す場合に、有利である場合がある。したがって、乗っ取られた機械の所有者は、正当な目的にそのシステムを使用し続けることができるが、犠牲者に対して行われる攻撃（おそらくは、正当なユーザに未知の）は、それでも、有利に阻まれる。さらに、そのような例示的実施形態による技法が、所与の犠牲者による攻撃者の過度に熱心な識別からの保護をも有利に提供することに留意されたい。本発明の原理によれば、攻撃の識別は、明白な犠牲者の裁量に一任されるので、所与の犠牲者へのトラフィックだけが排除されまたは制限されていることが、明らかに有利である。
【００２３】
悪意のある攻撃を、変化する度合の単純さまたは洗練を有する１つまたは複数のアルゴリズムによって、犠牲者によって認識することができ、これらのアルゴリズムは、本発明の範囲の外であるが、多数のアルゴリズムが、当業者に明白であろう。たとえば、本発明の１つの例示的実施形態によれば、パケット・トレースを検査することができ、攻撃を、単一の識別されたソースまたは複数の識別されたソースのいずれかからの非常に高いトラフィック・レベル（たとえば、高いパケット・レート）の存在だけに基づいて識別することができる。これが、サービス拒否攻撃の存在を識別する１つの従来の方法であり、当業者に馴染みのあるものであろうことに留意されたい。
【００２４】
しかし、他の実施態様では、パケット内容およびアプリケーション・ログのアプリケーション・ベースの分析を実行して、たとえば、存在しないデータベース要素の頻繁なデータベース検索があったことを認識すること、１人の人が開始できるレートより高いレートで発生する、一見人間からの複数の要求があったことを認識すること、構文的に無効な要求を識別すること、および通常に発生するアクティビティの動作での特に敏感な時刻でのトラフィックの疑わしい量を識別することなど、疑わしい性質を有するパケット、パケットのシーケンス、またはアクションを識別することができる。後者のクラスの疑わしいパケットの例は、たとえば、株式取引ウェブ・サイトが、差し迫った株取引中の敏感な時に特に破壊的なトラフィックに気付く場合に、識別することができる。さらなる変形では、たとえば上で説明した状況のうちの１つまたは複数を含めることができる可能な攻撃の複数の異なるしるしを、より洗練された分析で有利に組み合わせて、攻撃の存在を識別することができる。
【００２５】
例示的な検出システムは、２つのモードのうちの１つで動作することができる。ゾーンが、「デフォルトドロップ」モードである時に、デフォルト挙動は、デフォルトドロップ上に明示的にリストされたトラフィックを除く、そのゾーン宛のすべてのトラフィックをフィルタリングすることである。一般に、デフォルトドロップ・モードでは、フィルタは、明示的に許可され（たとえば、事前定義の許可フィルタと一致し）ない限り、すべてのトラフィックを自動的に捨てる。その一方で、ゾーンがデフォルトアロウモードである時に、事前定義のドロップ・フィルタと明示的に一致するトラフィックを除いて、加入者へのすべてのトラフィックが、フィルタによって渡される。
【００２６】
図２は、本発明のプロセスを実施できる、図１の中央フィルタ・システム２００の概略ブロック図である。図２に示されているように、メモリ２３０は、本明細書で開示されるサービス拒否フィルタリングの方法、ステップ、および機能を実施するようにプロセッサ２２０を構成する。メモリ２３０は、分散させまたはローカルとすることができ、プロセッサ２２０は、分散させまたは単一とすることができる。メモリ２３０は、電気メモリ、磁気メモリ、もしくは光学メモリ、またはこれらの任意の組合せ、あるいは他のタイプのストレージ・デバイスとして実施することができる。プロセッサ２２０を構成する各分散プロセッサが、一般に、それ自体のアドレス可能メモリ空間を含むことに留意されたい。コンピュータ・システム２００の一部またはすべてを、特定用途向け集積回路または汎用集積回路に組み込むことができることにも留意されたい。
【００２７】
図２に示されているように、例示的なメモリ２３０は、サービス拒否フィルタ・ルール・ベース２６０と、図４に関して下でさらに述べる１つまたは複数のサービス拒否フィルタリング・プロセス４００とを含む。一般に、例示的なサービス拒否フィルタ・ルール・ベース２６０は、中央フィルタ２００によって制限されまたは許可されなければならないトラフィックに関連するソース／宛先アドレス対を含む従来のフィルタ・ベースである。サービス拒否フィルタリング・プロセス４００は、本発明による、サービス拒否または他の攻撃に対して防御する例示的な方法である。
【００２８】
中央フィルタ２００を、サービス・プロバイダ・ネットワーク１２０に含まれる独立型ボックスとして、またはその代わりに、ネットワーク１２０内に既に存在する他の点では通常のネットワーク要素に組み込まれた回線カードとして、実施することができる。さらに、ある種の例示的実施形態によれば、中央フィルタ２００を、ネットワーク１２０内で攻撃起点に相対的に近い位置にキャリアによって有利に展開することができ、あるいは、中央フィルタ２００を、当初に、プレミアム・カスタマを攻撃から有利に防御するように配置することができる。
【００２９】
図３は、本発明のプロセスを実施できる、図１のディテクタ３００の概略ブロック図である。図３に示されているように、メモリ３３０は、本明細書で開示されるサービス拒否フィルタリングの方法、ステップ、および機能を実施するようにプロセッサ３２０を構成する。メモリ３３０は、分散させまたはローカルとすることができ、プロセッサ３２０は、分散させまたは単一とすることができる。メモリ３３０は、電気メモリ、磁気メモリ、もしくは光学メモリ、またはこれらの任意の組合せ、あるいは他のタイプのストレージ・デバイスとして実施することができる。プロセッサ３２０を構成する各分散プロセッサが、一般に、それ自体のアドレス可能メモリ空間を含むことに留意されたい。コンピュータ・システム３００の一部またはすべてを、特定用途向け集積回路または汎用集積回路に組み込むことができることにも留意されたい。図３に示されているように、例示的なメモリ３３０は、図５に関して下でさらに述べる、１つまたは複数のサービス拒否検出プロセス５００を含む。
【００３０】
図４は、本発明の特徴を組み込むサービス拒否フィルタリング・プロセス４００の例示的実施態様を説明する流れ図である。例示的なサービス拒否フィルタリング・プロセス４００が、「デフォルトアロウ」モード用に実施されることに留意されたい。「デフォルトドロップ」モード用の実施態様は、当業者にたやすく明白になるはずである。一般に、サービス拒否フィルタリング・プロセス４００は、本発明による、サービス拒否または他の攻撃に対して防御する例示的方法である。例示的なサービス拒否フィルタリング・プロセス４００は、中央フィルタ２００で実行され、ステップ４１０中に、企業ネットワーク１５０内の所与のターゲット犠牲者に対してサービス拒否攻撃が行われつつあることのＵＤＰ表示をディテクタ３００から受信することによって開始される。
【００３１】
その後、ステップ４２０中に、ネットワーク・キャリアが、サービス拒否攻撃を阻むためにブロックされなければならないＩＰパケットを表す１つまたは複数のソース／宛先ＩＰアドレス対をディテクタ３００から受信する。実例として、ソースＩＰアドレスは、攻撃する（たとえば、「ゾンビ」）コンピューティング・デバイス１１０のアドレスであり、宛先ＩＰアドレスは、ターゲット犠牲者自体に関連するアドレスである。ディテクタ３００からのメッセージは、下で述べるＤＰに従って送信される。
【００３２】
次に、ネットワーク・キャリアは、ステップ４３０中に、そのソースＩＰアドレスおよび宛先ＩＰアドレスが受信されたソース／宛先ＩＰアドレス対のソースＩＰアドレスおよび宛先ＩＰアドレスと一致するＩＰパケットを識別するために、ＩＰパケット・トラフィックを監視する。ステップ４４０中にテストを実行して、１つまたは複数のパケットが、サービス拒否フィルタ・ルール・ベース２６０内のアドレス対と一致するかどうかを判定する。
【００３３】
ステップ４４０中に、１つまたは複数のパケットがサービス拒否フィルタ・ルール・ベース２６０内のアドレス対と一致すると判定される場合には、ステップ４６０中に、そのパケットを捨てるか制限しなければならない。ステップ４４０中に、１つまたは複数のパケットがサービス拒否フィルタ・ルール・ベース２６０内のアドレス対と一致しないと判定される場合には、ステップ４７０中に、そのパケットが、企業ネットワーク１５０への送信を許可される。
【００３４】
図５は、本発明の特徴を組み込むサービス拒否検出プロセス５００の例示的実施態様を説明する流れ図である。一般に、サービス拒否検出プロセス５００は、本発明による、サービス拒否または他の攻撃に対して防御する例示的方法である。例示的なサービス拒否検出プロセス５００は、ディテクタ３００によってターゲット犠牲者で実行され、ステップ５１０中に、受信されたＩＰパケットの分析に基づいて、ターゲット犠牲者に対してサービス拒否攻撃または別の悪意のある攻撃が行われつつあることを判定することによって開始される。次に、ステップ５２０中に、サービス拒否攻撃を阻むために、１つまたは複数のソース／宛先ＩＰアドレス対を、ブロックされなければならないＩＰパケットを表すものとして識別する（実例として、ソースＩＰアドレスは、攻撃する「ゾンビ」機械１１０のアドレスであり、宛先ＩＰアドレスは、ターゲット犠牲者自体に関連するアドレスである）。最後に、ステップ５３０中に、識別されたソース／宛先ＩＰアドレス対を、開示されるＤＰを使用して犠牲者のキャリア・ネットワークの中央フィルタ２００に送信して、キャリア・ネットワークが、一致するソースＩＰアドレスおよび宛先ＩＰアドレスを有するＩＰパケットの送信をブロックできるようにする。
【００３５】
告発プロトコル
１つの例示的実施態様で、ディテクタ３００と中央フィルタ２００との間の告発プロトコルＤＰ通信チャネルは、告発用のＵＤＰポートおよびほとんどの他の通信用のＴＬＳ接続からなる。ＤＰトランザクションは、２つのタイプを有する。ＵＤＰ上の第１のタイプは、おそらくは中央フィルタ２００からの任意選択の応答によって回答される、ディテクタ３００から中央フィルタ２００への要求パケットからなる。通常はＴＬＳｖ１上の第２のタイプは、最終的に対応するレコード内で回答されるＳＳＬ「レコード」からなる。ほとんどのＤＰトランザクションは、ディテクタ３００によって始められる。本発明の一態様によれば、ほとんどのＤＰ要求は、応答または肯定応答を必要としない。
【００３６】
基本的なＤＰトランザクションは、ディテクタ３００から中央フィルタ２００への告発である。各ディテクタ３００は、「ゾーン」すなわち、加入者（企業ネットワーク１５０）によって所有されるＩＰアドレスのサブセットであるＩＰアドレスのセットの代わりに話す。ディテクタ３００は、そのゾーンに「属する」と言われる。ディテクタ３００は、それが属するゾーン宛のトラフィックを告発する（ディテクタ３００自体のＩＰアドレスが、それが属するゾーンの一部である必要はない）。
【００３７】
すべての告発トランザクションは、ディテクタ３００によって始められる。加入者からの告発は、その加入者が少なくともパケットの受信を望む可能性が最も低い時、すなわちその加入者が過負荷である時に送信される可能性が高い。加入者から中央フィルタ２００への経路上のパケット消失レートが通常より高い可能性があり、その時に中央フィルタ２００が通常よりも多少忙しい可能性があることもありえる（または、可能性が高い）が、加入者からのインバウンド経路が、攻撃を受けている加入者への経路ほどにクリティカルに過負荷である可能性は低い。加入者から中央フィルタ２００への経路は、サービス・プロバイダのネットワーク内にある。したがって、開示されるＤＰは、告発の時に加入者に向かうトラフィックを始めるのを避けることを試みる。したがって、告発は、信頼できる形で送信されるのではなく、肯定応答は、中央フィルタ２００から受信されない。
【００３８】
そうではなく、加入者は、好ましくは、中央フィルタ２００に１つの応答を送信させるのではなく、各告発要求の複数のコピーを送信する。複数のコピーは、告発要求が安全に中央フィルタ２００に到着する確率を高める。たとえば、５つのコピーが送信され、パケットがランダムに捨てられる場合に、パケット消失レートが２０％（ドロップ・レートが通常は５％を十分に下回る）であっても、要求の少なくとも１つのコピーが到着する見込みは、極端に高い。これらの極端な数（２０％パケット消失レートおよび５つのコピー）を用い、パケット送信が、すべての消失が独立になるように分散されると仮定すると、少なくとも１つのコピーが着く見込みは、それでも、９９．９６％より高い。
【００３９】
この同一の推理は、パケットが順番に到着することに不必要に依存しないようにするために、各パケットを自己完結したものにすることをも保証する。前に示したように、ＤＰトランザクションは、一般に、企業によって（ディテクタ３００を介して）開始され、中央フィルタ２００によって開始されるＤＰトランザクションはない。これは、部分的には、上で説明した考慮によって、ならびに企業の周囲のファイヤウォールによりフレンドリになるために要求／応答モデルを維持し、ＤＰパケットが安全に着くことができる尤度を高めるために、動機付けられたものである。
【００４０】
中央フィルタ２００は、どのフィルタ・ルールが公式にインストールされているのかを判定する。ディテクタ３００は、単に、告発を中央フィルタ２００に発行する。告発が中央フィルタ２００に到着するという甲鉄の保証はない。さらに、複数のディテクタ３００が、宛先の所与のゾーンについて敵対するソースを告発することができる。その結果、ディテクタ３００は、インストールされたフィルタのセットを確実に知ることができない。加入者が、どのフィルタが実際にインストールされているのか、どのフィルタが中央フィルタ２００に一度も到着していないのか、およびどのフィルタが他のディテクタ３００によってまたは衝突に起因して（下を参照されたい）除去されまたは作成されたのかを知ることが、望ましい。このために、事態が多少落ち着いた時に、加入者は、中央フィルタ２００に状況レポートを要求することができる。この状況レポートは、どの要求が到着したのか、どのフィルタがインストールされたのか、および他の情報（下で詳細を示す）をリストする。
【００４１】
状況を信頼できる形で受信し、認証をブートストラップするために、開示されるＤＰは、各ディテクタ３００と中央フィルタ２００との間の（信頼できる）通信チャネル（ＴＬＳ）を提供する。
【００４２】
中央フィルタ２００および各ディテクタ３００は、ある共有される状態を維持するために協調しなければならない。最も明白な共有される状態は、インストールされたフィルタ・ルールのセットであるが、告発のシーケンス番号および認証に関する情報など、ＤＰ自体に関連する他の共有される状態もある。例示的実施形態は、適度に同期化されたクロックだけを必要とする。ディテクタ３００または中央フィルタ２００上で不要なものを実行する必要を回避するために、開示されるＤＰは、下の「Ｂ．認証」と題するセクションで述べるように、非常に粗いクロック「同期化」を提供し、その結果、Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ（ＮＴＰ）を用いて動作する必要がなくなる。多数の加入者が、企業ネットワークにまたがるイベント相関を単純にするために、いずれにせよディテクタ３００上でＮＴＰを実行することを望む（しかし、これは、ＤＰが動作するために必要ではない）。
【００４３】
フィルタとプロトコル状態との両方について、開示されるＤＰは、ディテクタ３００および中央フィルタ２００が、初期共有状態に信頼できる形で合意し、その後、両側が、時間の経過に伴って、状態に対する変更を記憶することを要求する。ディテクタ３００と中央フィルタ２００との間の不一致の場合に、中央フィルタ２００が、必ず、共有される状態の「真の」像を有する。同期化された状態に保たれるべきフィルタ状態の量は、ディテクタ３００次第である（ディテクタ３００は、過去の告発をまったく気にせず、その分析のすべてを現在のトラフィック・フローに基づくものとすることができる）。プロトコル状態は、ＤＰによって要求される。
【００４４】
ディテクタ３００は、周期的な状況要求によって、フィルタ状態を中央フィルタ２００と再同期化することができる。通常、中央フィルタ２００は、最後の状況要求以降のフィルタ状態変化だけを返す（要求された場合には、インストールされた時にかかわりなく、現在アクティブなすべてのフィルタを返すこともできるが）。通常、中央フィルタ２００は、ゾーン内のすべてのディテクタ３００のフィルタを返すが、要求された場合には、このディテクタ３００によって要求された告発だけを返すことができる。
【００４５】
ディテクタ３００は、同期化要求によって、シーケンス番号および認証鍵を再同期化することができる。同期化トランザクションでは、ディテクタ３００が、新しいシーケンス番号を一方的に選択し、中央フィルタ２００が、認証用の新しいセッション鍵を生成する。
【００４６】
ディテクタ３００がクラッシュするか、ともかくも情報を失う場合に、ディテクタ３００は、最近のフィルタ・ルールだけではなく、すべてのフィルタ・ルールを要求することができる。いつでも、ディテクタ３００は、告発のために認証情報を再ネゴシエートすることができる（下を参照されたい）。
【００４７】
中央フィルタ２００が、すべてのフィルタ・ルールをリセットする場合に（ゾーン変更、モード変更、またはある致命的ＤＢクラッシュ）、中央フィルタ２００は、ディテクタ３００との関連を故意に忘れ、中央フィルタ２００から再同期応答を返すために次のディテクタ・トランザクションを促す。ディテクタ３００が、中央フィルタ２００と再同期化する時に、中央フィルタ２００は、そのディテクタ３００に、そのディテクタ３００の以前の状態がもはや無効であり、すべての状況を要求する必要があることを知らせることができる。
【００４８】
中央フィルタ２００が、奇形のパケットまたは認証されていないパケットを受信する場合がある。その場合に、中央フィルタ２００は、たとえば各ホストに３０秒おきに１エラー・パケットの最大レートまで、（正当な）送信側にエラー・パケットを返す。レート制限は、たとえば攻撃者が告発プロトコルを使用してサービス拒否攻撃を始めるのを防ぐために、セットすることができる。
【００４９】
衝突する告発
告発は、パケットが分類に一致する場合に、複数の可能な異なるアクションを指定することができる。その結果、衝突が発生する場合がある。たとえば、あるディテクタ３００が、サブネット全体がウェブ・クローラを起動していると思われ、レート制限されなければならないと指定する場合がある。もう１つのディテクタ３００が、そのサブネット内の特定のホストが実際の攻撃を起こしていることを検出し、そのホストからのすべてのパケットを捨てなければならないと指定する場合がある。そのような衝突の場合に、後者のルールは、明らかに、前者のルールより特定であり、後者のルールは、単一のホストに言及し、単にソースをレート制限するのではなく捨てるように言う。そのような衝突では、より厳密なルールが適用されると論じることが理にかなっている。しかし、要求されるアクションが逆である、すなわち、１つのディテクタ３００が単一ソースに対するレート制限を要求し、もう１つのディテクタ３００が、サブネット（そのソースを含む）からのすべてのパケットを捨てることを要求すると仮定する。前者のルールがより特定である（サブネット全体ではなく単一のホストに言及する）と論じることができ、あるいは、後者のルールがより厳密である（パケットをまばらにするのではなく捨てるように言う）と、同等によく論じることができる。例示的実施形態は、最も特定のソース・アドレスが優先される規約を採用する。
【００５０】
それでも、明確にするために、最良の実践は、ディテクタ３００が衝突するルールを発行するのを避けることである。新しいセットを発行する前に、既存の衝突するルールを撤回することが、いつでも可能である。しかし、告発の信頼性の欠如を考慮すると、中央フィルタ２００が、より以前の衝突するルールが撤回されたことを発見する前に新しいルールを受信することが考えられる。さらに、複数のディテクタ３００が同一のゾーンを管理するならば、２つのディテクタ３００が、衝突を放棄せずに衝突する告発を独立に発行することが可能である。
【００５１】
衝突に出会う時の中央フィルタ２００の挙動を指定しなければならない。１つの例示的実施形態では、基本的なポリシは、衝突（ソース・アドレスの同一の指定を有するが２つの異なるアクションまたは理由を有する２つのルール）の場合に、より後のルールがより前のルールをオーバーライドすることである（「より後」は、ルールが中央フィルタに到着する時を指す）。
【００５２】
ＤＰプロトコル・アルゴリズム
Ａ．信頼できる送信
上で論じたように、パケットは、中央フィルタ２００からディテクタ３００への他方の方向で送信されるのではなく、ディテクタ３００から中央フィルタ２００に送信されなければならない。さらに、各パケットは、自立していることができ、順序通りの送達を必要としない。その結果、各告発パケットが到着し、順番に到着することを保証するのではなく、開示されるＤＰは、各パケットの複数のコピーを送信することによって成功の到着の見込みを確立的に改善することを選ぶ。ＤＰ告発要求は、たとえばＳＹＮＣＨ要求に応答して指定される、中央フィルタ２００上のポートへのＵＤＰパケット内で送信される。一般に、各告発パケットは、ｐ回送信され、肯定応答は不要である。１つの例示的実施態様では、ｐが、５に固定され、パケット・ペーシングに対する形式的要件は、与えられない。
【００５３】
順序付け要件のために（衝突解決ルールが明確な勝者を選択しない直接に衝突するフィルタ・ルールの場合に、最も新しいルールがより古いルールをオーバーライドするルールを与えられて）、ＤＰシーケンス番号が、送信順序を決定するためにアプリケーションまで渡される。中央フィルタ２００は、複数のディテクタ３００からの告発のシリアライザとして働く。単一のディテクタ３００からの要求は、シーケンス番号によって、曖昧さなしに順序付けられる。インターリービングの順序は、中央フィルタ２００によって一方的に判断される。中央フィルタ２００は、大域的順序のどこで、各ディテクタ３００が状況応答を最後に受信したかを記憶する。
【００５４】
複数のパケットを送信することの背後にある意図は、各パケットの少なくとも１つのコピーが中央フィルタ２００に到着することであって、中央フィルタ２００をパケットで氾濫させることではない。さらに、攻撃者が、開示されるＤＰに対するＤｏＳ攻撃を開始するためのてこの作用点を有してはならない。中央フィルタ２００は、平均して、１トランザクションあたり１つのパケットを処理しなければならない。中央フィルタ２００が、各パケットが正しいディテクタ３００によって送信されたことを確信するために各パケットを認証するという要件は、パケット処理が高価になる場合があることを意味する。
【００５５】
ほとんどの冗長パケットは、高価な計算なしで破棄することができる。一実施形態では、最も安価なテストが最初に実行される。たとえば、シーケンス番号は、暗号化されず、告発要求についてチェックするために計算的に安価である。同様に、ディテクタ名が既知であるかどうかをチェックすることも、安価である。重複する要求および範囲外のシーケンス番号は、他のテストを実行する前に簡単に破棄される。
【００５６】
開示されるＤＰでは、告発トランザクションは、ディテクタ３００によってＵＤＰ上で開始される。ＤＰは、他の要求について別々のＴＬＳ接続（ＴＣＰを介する）を維持する。
【００５７】
Ｂ．認証
例示的実施態様でのＤＰの基本的な認証機構は、クライアント証明書を用いてＴＬＳｖ１によって提供される認証ハンドシェークである。信頼されるＩＰＳ証明局の公開鍵が、中央フィルタ２００および各ディテクタ３００に事前にロードされる。各ディテクタ３００および中央フィルタ２００は、その認証局ＣＡによって署名された、その公開鍵の証明書を有する。さらに、加入者ディテクタ３００は、中央フィルタ２００の完全修飾ドメイン名を与えられ、この完全修飾ドメイン名は、サーバ証明書ＳｕｂｊｅｃｔのＣＮ部分でもある。
【００５８】
鍵は、ディテクタのＩＰアドレスではなく「名前」に関連し、ＩＰアドレスは、複数の理由から変化し得る。下で注記するように、ＤＰは、任意の時に所与の名前を有する最大１つのディテクタ３００を実施する。標準ＴＬＳプロトコルに従って、中央フィルタ２００は、ＣＡによって署名された証明書だけを受け入れることを指定するＣｅｒｔｉｆｉｃａｔｅ  Ｒｅｑｕｅｓｔメッセージを送信する。ディテクタ３００は、クライアント認証プロセスの一部として２つのメッセージを応答する。第１に、ディテクタ３００は、ディテクタの名前およびディテクタの公開鍵を含む証明書を供給する。第２に、ディテクタ３００は、ディテクタの秘密鍵によって署名されたＴＬＳハンドシェーク・メッセージのすべてのダイジェストを含むＣｅｒｔｉｆｉｃａｔｅ  Ｖｅｒｉｆｙメッセージを送信する。ここで、中央フィルタ２００は、証明書で言及されたディテクタ３００としてクライアントを認証することができる。
【００５９】
ＴＬＳｖ１接続が確立されたならば、中央フィルタ２００は、告発をＵＤＰを介して発行できるようになる前に、このセキュアな暗号化されたチャネルを使用して、ランダムに選択された１６０ビットの秘密ナンスをディテクタ３００に送信しなければならない。
【００６０】
すべてのＤＰ告発パケットは、認証される。１つの例示的実施形態では、開示されるＤＰでの告発は、（ａ）ＵＤＰパケット内容、（ｂ）タイム・カウンタ（ＲＳＴＡＲＴ以降の「単位」数、ここで、「単位」の長さおよびＲＳＴＡＲＴの時刻は、同期化中に確立される）の暗号ハッシュによって認証される。（ｃ）秘密ナンス、および（ｄ）ＴＬＳチャネルによって使用されるＤＰポート番号。（ｂ）は、反射攻撃に対する最小限の防御であり、（ｃ）は、中央フィルタ２００に対してディテクタ３００を認証する。例示的実施形態で使用されるＭＡＣ関数は、ＨＭＡＣ−ＳＨＡ１（詳細については、Ｉｎｔｅｒｎｅｔ  ＲＦＣ  ２１０４を参照されたい）であり、上の余分なフィールドは、ＨＭＡＣ鍵として使用される。
【００６１】
２０ビットのシーケンス番号を、パケットの内部に含めることができるが、各サーバが、単位カウンタが増分される前に２２０個未満の要求を送信すると仮定されたい。ＤＰのエンドポイントは、所与のシーケンス番号を有する最初の有効なパケットだけを受け入れる。シーケンス番号がラップ・アラウンドする時までに、単位カウンタが、単純な反射攻撃に対して防御するために増分されている。ディテクタ３００は、シーケンス番号の上位ビット（第２１ビット）として単位カウンタの数の下位ビットを含む。これは、「日付」（ＲＳＴＡＲＴ時刻以降の単位数）が中央フィルタ２００に関する任意の時にディテクタ３００上で変化することを可能にし、中央フィルタ２００は、それでも、隠された日付が何であるかを計算することができる（１「日」［単位］あたり少なくとも１つの同期化交換がある限り）。これは、密に同期化されたクロックの必要を回避することを可能にする。
【００６２】
ディテクタ３００が、１つの時間単位内に２２０個を超えるパケットの送信を試みるというありそうにない場合に、そのディテクタ３００は、中央フィルタ２００に新しい秘密ナンスを要求しなければならない。そのディテクタ３００は、シーケンス番号がラップ・アラウンドすることの可能性を低くするために、単位の長さ（１日の分数として表される）を選択する。
【００６３】
これらの暗号ハッシュの計算が高価になり得ると思われる可能性があり、その出費は、各パケットの多数のコピーを送信することによって悪化する可能性がある。しかし、所与のシーケンス番号が成功して受信されたならば、すべての重複を、ハッシュを計算せずに破棄できることに留意されたい。攻撃者からのランダムに構成されたパケットは、受け入れられる可能性が低い。というのは、受け入れることのできるシーケンス番号のウィンドウが、シーケンス番号空間全体と比較して非常に小さいからである。中央フィルタ２００は、期待されるウィンドウの外のパケットを破棄する。さらなるウィンドウイングは、ディテクタ名に基づくものとすることができ、ディテクタ名は、疎に割り振ることができ、たとえば、２バイト・フィールド内で１００個程度の有効な値とすることができる。
【００６４】
攻撃者が告発要求をスヌーピングすることができ、ディテクタ名をコピーし、シーケンス番号を取り込み、その後にウィンドウ内の最後のパケットの多数の悪いコピーを送信する懸念がある場合に、スヌーパに対して保護される、高速破棄の方法を提供することができる。実際には、この余分なレベルの保護が不要であると期待される、すなわち、ＳＨＡ１を実行することのコストが、この追加の複雑さを正当化するのに十分な受信側のボトルネックではなくなると期待される。それでも、このセキュア高速破棄方法を、下で述べる。
【００６５】
Ｃ．セキュア高速破棄
セキュア高速破棄方法は、任意選択である。この任意選択の方法の空間は、例示的なＤＰ版では告発パケット内で提供されるが、このセキュア高速破棄アルゴリズムは、実際にこの保護が必要であると判定されない限り、ＤＰ内でイネーブルされない。
【００６６】
基本的な手法は、次のとおりである。各告発要求は、計算しやすいＬビット・ストリングＳＬ（ストリングがシーケンス番号フィールドのパディングにおさまるようにするために、暫定的にＬ＝５）を含む。ＳＬは、シーケンス番号と、ＳＳＬチャネルを介して中央フィルタ２００によって供給される秘密鍵の対との単純な関数の結果である。パケットが無効であるかどうかをチェックすることは、計算的に安価であり、ＳＬが期待される値でない場合には、パケットは破棄される。パケットが有効であるかどうかを判定するためには、それでも、暗号ハッシュのチェックが必要であるが、これは、１シーケンス番号あたり約１回発生する。
【００６７】
ディテクタ３００が、ＨＭＡＣ−ＳＨＡ１の共有鍵を中央フィルタ２００と同期化する時に、中央フィルタ２００は、ストリング長Ｌ、鍵長Ｂ、Ｂ＋ＬビットのストリングＳ、および１≦Ｋ≦Ｂになる小さい整数Ｋをも提供しなければならない。これらのいずれもが、攻撃者には未知であるが、ＬおよびＢは、頻繁に変化することができ、ＳおよびＫと同一の意味で「秘密」と考えられてはならない。シーケンス番号ｓを有する告発要求に関して、ＳＬは、ビット位置ｂから始まるＳ内のＬビット・サブストリングである。ｂは、ｓ、Ｂ、およびＫの関数である。ＳＬは、パケットのＨＭＡＣ−ＳＨＡ１ハッシュの第ｂ０位置に挿入される（ＳＨＡ１ハッシュの長さをＬビットだけ延ばす）。
【００６８】
Ｌ＝５およびＢ＝１０１９の場合に、パターンは、約２２０個の告発パケットまで繰り返さず、約２２０個の告発パケットの時には、新しいナンスが、どの場合でもＨＭＡＣ−ＳＨＡ１ハッシュについて選択されなければならない。ストリングＳＬが、スヌープする攻撃者にランダムに見えるならば、ＳＬの単純なチェックは、攻撃するパケットのストリームを２Ｌ倍だけ細くしなければならない。しかし、より大きいＬの選択は、攻撃者がＳを、およびその後にＫを再構成できる見込みを増やし、したがって、Ｌは、この問題を防ぐために２Ｌ２Ｌ＜Ｂ（ＬがＯ（ｌｏｇＢ）であることを意味する）になるように選択されなければならない（すべての可能なＬビット・サブストリングがＳ内に１回を超えて現れる可能性が高くなるようにするために）。
【００６９】
Ｄ．ＤＰメッセージ・サービス
開示されるＤＰは、ディテクタ３００および中央フィルタ２００が信頼できる形でお互いにメッセージを送信する手段を提供する。ＳＳＬ／ＴＬＳが、ストリーム内のレコードを実施する。ＳＳＬレコードを、各レコードをそのレコードのタイプ（状況、メッセージ、および状況応答など）を単純に記述するＤＰレコード・ヘッダから開始するＤＰレコードとして使用することができる。しかし、我々の経験では、すべてのＴＬＳ実施態様が、クライアントへのＡＰＩでレコード境界を保存するわけではない（ＳＳＬ書き込みは（データが大きすぎない限り）、ＳＳＬレコードを作るが、ＳＳＬ読み取りは、部分的レコードまたは複数のレコードを返すことができる）。その結果、プラットフォームにまたがる最大の可搬性をもたらすために、ＤＰの例示的実施形態は（おそらくは冗長に）それ自体のレコード・マーキング・プロトコルをＳＳＬレコード内で実施する。理想的には、１つのＤＰレコードが、各ＳＳＬレコード内におさまらなければならないが、レコード・プロトコルは、かかわりなく働く。ＤＰは、レコードを開始するのにレコードの始めマーカを使用し、終了するのにレコードの終りマーカを使用する。各レコードは、タイプおよび長さフィールドから始まる。長さフィールドは、ビット／バイト詰込を回避することを可能にし、開始レコード・マーカまたは終了レコード・マーカのいずれかがレコード内に現れることが、ルールに従ったものである。長さフィールドは、ヘッダおよびトレイラを含まない、メッセージ内のバイト数である。
【００７０】
開始マーカおよび終了マーカは、例示的実施形態では４バイト・シーケンスであるが、ＤＰメッセージに対するアライメント要件はない。メッセージの本体は、任意の長さとすることができ、長さが３２ビット（４バイト）の倍数である必要はない。開始マーカおよび終了マーカは、サーバまたはクライアントが奇形レコードを発行する場合にレコード境界を回復することを可能にし、シーケンス［レコードの終り］［レコードの始め］およびそれに続く、それ自体が［レコードの終り］［レコードの始め］対をポイントする長さフィールドを検索するだけでよい。
【００７１】
Ｅ．パケット・フォーマット、バージョン番号、および互換性
開示されるＤＰに対する変更は、後方互換でなければならない。ＳＳＬチャネルを利用するプロトコル動作に対する非互換の変更は、非互換フォーマットを有する古いタイプの再利用ではなく、新しいレコードタイプ識別子を割り振る。告発トランザクションに対する非互換の変更は、変更されたＤＰ仕様の一部として、新しいＤＰポート番号の選択を必要とする。ＤＰは、２つの形のうちの１つで、ＤＰチャネルのリモート端の非ＤＰエージェントを検出する。ＳＳＬ接続のリモート端は、認証に失敗するか、ＤＰ初期同期化プロトコルに従うことに失敗するかのいずれかになる。非互換性が、なんらかの理由でＳＳＬ接続確立中に検出されない場合に、暗号ハッシュは、リモート端がＤＰでないからまたはハッシュでＤＰの非互換バージョン番号を使用しているからのいずれかで、ＵＤＰトラフィックについて失敗する。これは、ワイヤを介してＤＰによって送信されるデータ内のバージョン番号またはマジック・ナンバの必要をなくす。
【００７２】
パケットおよび動作
前に示したように、ディテクタ３００は、ＤＰチャネルを介して中央フィルタ２００と通信する。ＤＰチャネルは、ディテクタ３００および中央フィルタ２００が通信するために、現在確立されていなければならない。各ディテクタ３００は、中央フィルタ２００の特定のインスタンスに束縛される。中央フィルタ２００は、それに束縛されていないディテクタ３００とは通信しない。所与の中央フィルタ２００に束縛された各ディテクタ３００は、その中央フィルタ２００によって使用される数値の「名前」を有する。
【００７３】
ＤＰチャネル確立の第１ステップは、ディテクタ３００から中央フィルタ２００へのＳＳＬ／ＴＳＬ接続を開始することである。中央フィルタ２００は、ＳＳＬ／ＴＬＳ認証プロセスを介して、通信するディテクタ３００を真正として識別する。ディテクタ３００は、ＴＳＬハンドシェークのクライアント認証フェーズでディテクタ３００が中央フィルタ２００に供給する証明書内で使用される名前になることを請求する。この名前は、事前に定義された形でなければならない。
【００７４】
ＴＬＳチャネルが確立されたならば、ディテクタ３００は、そのＴＬＳチャネル上で同期化要求を送信しなければならない。このＴＬＳチャネルは、同期化要求がディテクタ３００から中央フィルタ２００に送信され、同期化肯定応答がディテクタ３００から中央フィルタ２００に返されるまで、初期化されたとは考えられない。例示的同期化要求は、他の値の中でも、次の告発トランザクションのシーケンス番号を含む（各告発トランザクションのシーケンス番号は、次の同期化要求まで、１つ増分される）。例示的同期化要求は、「時間単位」の長さおよびランダム開始時刻「ＲＳＴＡＲＴ」をも初期化する。中央フィルタ２００は、ランダムに生成された１６０ビットのセッション鍵と、ディテクタ３００を増分フィルタ状態で満足できるかどうかの表示またはディテクタ３００がすべてのフィルタ状態を必要とするかどうかの表示とを含む同期化肯定応答を応答する。
【００７５】
この交換の後に、ディテクタ３００は、経路ＭＴＵを確立し、最初の状況応答を要求し、受信しなければならない。この時点で、ＤＰチャネルが確立される。上で説明したように、ＤＰトランザクションの４つの基本的なタイプすなわち、同期化、告発、状況照会、およびメッセージがある。最初の３つのトランザクション・タイプ（同期化、告発、および状況照会）は、すべてがディテクタ３００によって開始される。しかし、メッセージは、ＳＳＬチャネルを介して、ディテクタ３００または中央フィルタ２００の要求でどちらの方向にも送信され得る。
【００７６】
告発トランザクションは、ＵＤＰチャネルを介してディテクタ３００上のランダム・ポートから中央フィルタ２００上のＤＰポートに送信される。通常の場合に、中央フィルタ２００は、応答をまったく送信しない。エラー、障害、または潜在的な攻撃の場合に、中央フィルタ２００は、再同期またはエラー・パケットのいずれかを応答することができる。これらの応答は、ＴＬＳチャネルがまだ存在することがわかっている時に、そのＴＬＳチャネルを介して送信される。ＴＬＳチャネルが存在しない場合には、応答は、ＵＤＰを介して送信され、この場合に、その応答は、ＴＬＳチャネルを再確立するための再同期メッセージでなければならない。一般的なルールは、着信パケットがきちんと形成されており、中央フィルタ２００が、クライアントが正当であると考える場合に、中央フィルタ２００が、再同期メッセージを送信することである。そうでない場合には、中央フィルタ２００は、エラー・メッセージを送信する。
【００７７】
すべての他のトランザクションは、ＴＬＳチャネルを利用する。
【００７８】
Ａ．ＵＤＰトランザクション（告発および応答）
前に示したように、ＨＭＡＣ−ＳＨＡ１メッセージ認証は、パケットの内容ならびにナンス、日付カウンタ、およびグローバルＤＰポート番号を含む鍵に対して計算される。図６に、ＵＤＰパケットの前に付加されたＵＤＰ要求のＨＭＡＣ鍵を示す。
【００７９】
上で示したように、ＲＳＴＡＲＴ以降の単位数は、ＤＰがＤｏＳ攻撃のソースになることを防ぐ。
【００８０】
Ｂ．ＳＳＬチャネル
ＴＬＳチャネルを介して送信されるすべてのＤＰ通信は、レコードに分解される。１つの例示的実施形態で、単一ＤＰレコードの最大サイズは、１６０００バイトである。ＳＳＬプロトコルへのＡＰＩが許容する場合に、１ＳＳＬレコードあたり正確に１つのＤＰレコードを有することが、よい実践である。例示的なＤＰレコードは、たとえば、事前定義の４バイトのシーケンスから始まり、もう１つの事前定義の４バイトのシーケンスで終わる。ＤＰレコードのタイプは、メッセージ・マーカの始めに直接に続く３２ビット整数としてエンコードされる（ネットワーク・バイト順で）。ＤＰレコードの長さは、タイプに直接続く３２ビット整数としてエンコードされる（ネットワーク・バイト順で）。図７に、セキュアな信頼できるストリーム内のＤＰレコード・ヘッダおよびトレイラの例示的レイアウトを示す。
【００８１】
本発明は、１つまたは複数の補足ツールと共に働くことができる。たとえば、そのようなツールに、活用されるサービス拒否攻撃の認識のためのインターネット・サーバ・プラグイン、さまざまなＩＤＳシステム（侵入検出システム）へのリンク、ネットワーク診断用のデータベース（上の議論を参照されたい）、および所与のキャリアのインフラストラクチャ内のザッパ機能性の配置に関するガイダンスを提供する方法を含めることができる。これら補足ツールのうちのさまざまなツールを提供する本発明の例示的実施形態は、本明細書の開示に鑑みて、当業者に明白であろう。
【００８２】
システムおよび製造品の詳細
当技術分野で既知のとおり、本明細書で述べた方法および装置を、コンピュータ可読コード手段がその上で実施されたコンピュータ可読媒体をそれ自体が含む製造品として配布することができる。コンピュータ可読プログラム・コード手段は、コンピュータ・システムと共に、本明細書で述べた方法を実行するステップの一部またはすべてを実行するか本明細書で述べた装置を作成するように動作可能である。コンピュータ可読媒体は、記録可能媒体（たとえば、フロッピ・ディスク、ハード・ドライブ、コンパクト・ディスク、メモリ・カード、半導体デバイス、チップ、特定用途向け集積回路ＡＳＩＣ）とすることができ、あるいは伝送媒体（たとえば、光ファイバ、ワールド・ワイド・ウェブ、ケーブル、または時分割多元接続、符号分割多元接続もしくは他の無線周波数チャネルを使用する無線チャネルを含むネットワーク）とすることができる、コンピュータ・システムと共に使用するのに適切な情報を格納できる既知のまたはこれから開発されるすべての媒体を使用することができる。コンピュータ可読コード手段は、磁気媒体上の磁気変動またはコンパクト・ディスクの表面上の高さ変動など、コンピュータが命令およびデータを読み取ることを可能にするすべての機構である。
【００８３】
本明細書で説明したコンピュータ・システムおよびサーバのそれぞれは、本明細書で開示される方法、ステップ、および機能を実施するように関連するプロセッサを構成するメモリを含む。メモリは、分散させまたはローカルとすることができ、プロセッサは、分散させまたは単一とすることができる。メモリは、電気メモリ、磁気メモリ、もしくは光学メモリ、またはこれらの任意の組合せ、あるいは他のタイプのストレージ・デバイスとして実施することができる。さらに、用語「メモリ」は、関連するプロセッサによってアクセスされるアドレス可能空間内のアドレスから読み取るかこれに書き込むことができるすべての情報を含むのに十分に広義に解釈されなければならない。この定義を用いると、ネットワーク上の情報は、それでもメモリ内にある。というのは、関連するプロセッサが、ネットワークから情報を取り出すことができるからである。
【００８４】
図示され本明細書で説明された実施形態および変形形態が、単に本発明の原理を示すものであることと、本発明の範囲および趣旨から逸脱せずに当業者がさまざまな変更を実施できることとを理解されたい。
【図１】
2010508760.tif 000003
【図２】
2010508760.tif 000004
【図３】
2010508760.tif 000005
【図４】
2010508760.tif 000006
【図５】
2010508760.tif 000007
【図６】
2010508760.tif 000008
【図７】
2010508760.tif 000009
【国際調査報告】
2010508760.tif 000010
2010508760.tif 000011