JP2012109996A - 1つまたは複数のパケット・ネットワーク内で悪意のある攻撃中に制御メッセージを送達する方法および装置 - Google Patents

1つまたは複数のパケット・ネットワーク内で悪意のある攻撃中に制御メッセージを送達する方法および装置 Download PDF

Info

Publication number
JP2012109996A
JP2012109996A JP2011280852A JP2011280852A JP2012109996A JP 2012109996 A JP2012109996 A JP 2012109996A JP 2011280852 A JP2011280852 A JP 2011280852A JP 2011280852 A JP2011280852 A JP 2011280852A JP 2012109996 A JP2012109996 A JP 2012109996A
Authority
JP
Japan
Prior art keywords
detector
central filter
accusation
packet
filter
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2011280852A
Other languages
English (en)
Inventor
Michael Bally Greenwald
グリーンワルド,マイケル,バリー
Eric Henry Grosse
グロッセ,エリック,ヘンリー
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia of America Corp
Original Assignee
Alcatel Lucent USA Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alcatel Lucent USA Inc filed Critical Alcatel Lucent USA Inc
Publication of JP2012109996A publication Critical patent/JP2012109996A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/22Arrangements for preventing the taking of data from a data transmission channel without authorisation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441Countermeasures against malicious traffic
    • H04L63/1458Denial of Service
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/141Denial of service attacks against endpoints in a network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227Filtering policies
    • H04L63/0236Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227Filtering policies
    • H04L63/0263Rule management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101Access control lists [ACL]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

【課題】1つまたは複数のパケット・ネットワーク内で、悪意のある攻撃中に、ディテクタから中央フィルタに肯定応答を必要とせずに、制御メッセージを信頼できる形で送達する方法および装置を提供する。
【解決手段】ディテクタは、1つまたは複数のソースIPアドレスからのパケットの分析に基づいて、望まれないトラフィックがターゲット装置で受信されることを判定するステップと、サービス・プロバイダに関連する中央フィルタに告発メッセージを送信するステップとを含む。送信が制限される、捨てられる、および許可されるのうちの1つまたは複数であると少なくとも1つのソース・コンピューティング・デバイスのソース・アドレスを前記告発メッセージ内で指定し、前記中央フィルタからの即座の肯定応答を必要としない告発プロトコルを使用して告発メッセージが送信されることによって、望まれないトラフィックに対して防御する。
【選択図】図1

Description

本発明は、パケットベースの通信ネットワークのコンピュータ・セキュリティ技法に関し、より具体的には、そのようなパケットベースのネットワークでの、サービス拒否攻撃または別の悪意のある攻撃などの望まれないトラフィックを検出し、告発する方法および装置に関する。
サービス拒否DoS攻撃などの悪意のある攻撃は、コンピュータ・リソースをその所期のユーザから使用不能にすることを試みる。たとえば、ウェブ・サーバに対するDoS攻撃は、しばしば、ホスティングされるウェブ・ページを使用不能にする。
DoS攻撃は、限られたリソースが正当なユーザではなく攻撃者に割り振られる必要がある時に、かなりのサービス妨害を引き起こし得る。攻撃する機械は、通常、攻撃のターゲット犠牲者に向けられた多数のインターネット・プロトコルIPパケットをインターネットを介して送信することによって、損害を与える。たとえば、DoS攻撃は、ネットワークを「氾濫させ」、これによって、正当なネットワーク・トラフィックを妨げる試み、またはサーバが処理できるものより多数の要求を送信し、これによって1つまたは複数のサーバへのアクセスを妨げることによってサーバを一時不通にする試みを含み得る。
複数の技法が、そのような悪意のある攻撃に対して防御するために提案され、または提唱されてきた。たとえば、米国特許出願第11/197,842号、名称「Method and Apparatus for Defending Against Denial of Service Attacks in IP Networks by Target Victim Self−Identification and Control」および米国特許出願第11/197,841号、名称「Method and Apparatus for Defending Against Denial of Service Attacks in IP Networks Based on Specified Source/Destination IP Address Pairs」に、DoS攻撃を検出し、告発する技法が開示されている。
そのような悪意のある攻撃に対して防御するシステムは、通常、カスタマ・ネットワークを悪意のある攻撃から保護するために、カスタマ・ネットワークに関連するディテクタと、サービス・プロバイダのネットワーク内の中央フィルタとを使用する。一般に、ディテクタは、カスタマ・ネットワークに対する悪意のある攻撃を検出し、中央フィルタに1つまたは複数の告発メッセージまたは通知メッセージを送信する。たとえば、悪意のある攻撃が、カスタマ・ネットワーク上で行われていると判定した時に、ディテクタは、中央フィルタに1つまたは複数のソース/宛先IPアドレス対を送信することができ、この中央フィルタは、サービス・プロバイダに、そのソースIPアドレスおよび宛先IPアドレスが送信されたソース/宛先IPアドレス対のいずれかのソースIPアドレスおよび宛先IPアドレスと一致するIPパケットの送信を制限させ、これによって、悪意のある攻撃を制限する(または除去する)。ディテクタは、通常、カスタマ・ネットワークの近くに配置される。
しかし、悪意のある攻撃は、通常、中央フィルタからディテクタへの制御メッセージが失われるか大きく遅延される可能性が高くなるほどに激しいパケット消失につながる。さらに、ディテクタは、悪意のある攻撃中に、ビジーになり、重い負荷を受ける可能性が高い。そのような悪意のある攻撃に対して防御する既存システムは、通常、中央フィルタへの制御メッセージ送信の肯定応答を必要とする、Transport Layer Security(TLS)、Secure Socket Layer(SSL)、Secure Shell(SSH)、または別の伝送制御プロトコルTCPベースのプロトコルを使用する。そのようなチャネルは、悪意のある攻撃中を除いて、通常は十分である。悪意のある攻撃中には、中央フィルタからの肯定応答が、ディテクタによって受信されない場合があり、あるいは、ディテクタの入力バッファが過負荷になる時にディテクタに到着する場合がある。一般に、ディテクタは、すべての以前の告発メッセージが中央フィルタによって正しく肯定応答されるまで、処理を継続することができない。
米国特許出願第11/197,842号 米国特許出願第11/197,841号
Internet RFC 2104
したがって、中央フィルタからディテクタへの応答を必要としない、1つまたは複数のパケット・ネットワークでの悪意のある攻撃中に中央フィルタに制御メッセージを信頼できる形で送達する方法および装置の必要が存在する。
一般に、たとえば悪意のある攻撃中に、中央フィルタからディテクタへの応答または肯定応答を必要とせずに1つまたは複数のパケット・ネットワーク内で中央フィルタに制御メッセージを信頼できる形で送達する方法および装置が提供される。本発明の一態様によれば、ディテクタは、1つまたは複数のソースIPアドレスから受信されるパケットの分析に基づいて、望まれないトラフィックがターゲット犠牲者によって受信されることを判定するステップと、サービス・プロバイダに関連する中央フィルタに告発メッセージを送信するステップであって、告発メッセージが、ターゲット犠牲者へのパケットのそれによる送信が制限され、捨てられ、または許可されるのうちの1つまたは複数になる少なくとも1つのソース・コンピューティング・デバイスのソース・アドレスを識別し、告発メッセージが、中央フィルタからの即座の肯定応答を必要としない告発プロトコルを使用して送信される、ステップとによって、ターゲット犠牲者によって、望まれないトラフィックに対して防御する。
本発明のさらなる態様によれば、告発メッセージを、中央フィルタに冗長に送信することができ、告発メッセージは、好ましくは自己完結である。中央フィルタおよびディテクタは、状態情報を共有し、任意選択で、状態情報に対するすべての変更を維持する。
本発明のさらなる態様によれば、開示される告発プロトコルは、告発プロトコル自体をねらう悪意のある攻撃を回避する1つまたは複数の特徴を含む。たとえば、告発メッセージは、任意選択で、(i)複数のターゲット犠牲者からの衝突する告発メッセージを調停することを可能にし、(ii)告発プロトコルをねらう悪意のある攻撃を回避することを可能にし、(iii)告発メッセージの重複するコピーを破棄することを可能にする、シーケンス番号を含む。
本発明のより完全な理解ならびに本発明のさらなる特徴および利益は、次の詳細な説明および図面を参照することによって得られる。
本発明が動作できるネットワーク環境を示す図である。 図1の中央フィルタ・システムを示す概略ブロック図である。 図1のディテクタを示す概略ブロック図である。 本発明の特徴を組み込むサービス拒否フィルタリング・プロセスの例示的実施態様を説明する流れ図である。 本発明の特徴を組み込むサービス拒否フィルタリング・プロセスの例示的実施態様を説明する流れ図である。 UDPパケットの前に付加されたUDP要求のHMAC鍵を示す図である。 セキュアな信頼できるストリーム内のDPレコード・ヘッダおよびトレイラの例示的レイアウトを示す図である。
本発明は、1つまたは複数のパケット・ネットワーク内での悪意のある攻撃中に中央フィルタに制御メッセージを信頼できる形で送達する方法および装置を提供する。本発明の一態様によれば、カスタマ・ネットワークにあるディテクタとサービス・プロバイダのネットワークにある中央フィルタとの間の通信のための告発プロトコルが提供される。1つの例示的実施態様で、告発プロトコルは、1対の通信チャネルを含む。第1通信チャネルは、TLSチャネルなどの信頼できるセキュアな認証されたストリームである。第2通信チャネルは、認証をブートストラップするのにセキュア・チャネルを使用する、たとえばUDPの上の、信頼できない認証された非ストリーム・プロトコルとすることができる。たとえば、ユーザ・データグラム・プロトコルUDPを使用して、TCPベースのプロトコルを使用する従来の技法で要求される即座の肯定応答を回避することができる。この形で、たとえば悪意のある攻撃に起因する、中央フィルタからディテクタへの戻り経路内に激しいパケット消失があり、中央フィルタ肯定応答が失われる傾向がある場合に、所望の保護を、それでも達成することができる。さらに、順方向経路上のディテクタから中央フィルタへの制御メッセージの冗長送信が、順方向経路での穏当なパケット消失を克服するのに使用される。一般に、攻撃中に中央フィルタからディテクタにパケットを送信することよりも、ディテクタから中央フィルタに複数の冗長パケットを送信することが好ましい。
図1に、本発明が動作できるネットワーク環境100を示す。図1に示されているように、企業ネットワーク150は、図3に関して下でさらに説明するディテクタ300を使用して、悪意のある攻撃に対してそれ自体を保護する。企業ネットワーク150は、企業ユーザが、サービス・プロバイダ・ネットワーク120によってインターネットまたは別のネットワークにアクセスすることを可能にする。サービス・プロバイダ・ネットワーク120は、企業ネットワーク150のユーザにサービスを提供し、入ポート115によってさまざまなソースからパケットを受信し、これらを企業ネットワーク150内の示された宛先に送信する。
1つの例示的実施形態で、ディテクタ300は、図2に関して下でさらに述べる中央フィルタ200と協力して、悪意のある攻撃からそれ自体を保護する。一般に、下でさらに述べるように、ディテクタ300は、企業ネットワーク150に対する、サービス拒否攻撃などの悪意のある攻撃を検出し、サービス・プロバイダによって維持される中央フィルタ200に通知する。
中央フィルタ200は、サービス・プロバイダ・ネットワーク120によって企業ネットワーク150に達するトラフィックを制限するように働く。ディテクタ300は、通常、企業ネットワーク150のファイヤウォールの背後にあり、ディテクタ300は、通常、告発メッセージをISPの中央フィルタ200に送信する。ディテクタ300および中央フィルタ200は、本発明の特徴および機能を提供するように本明細書で変更される、米国特許出願第11/197,842号、名称「Method and Apparatus for Defending Against Denial of Service Attacks in IP Networks by Target Victim Self−Identification and Control」および米国特許出願第11/197,841号、名称「Method and Apparatus for Defending Against Denial of Service Attacks in IP Networks Based on Specified Source/Destination IP Address Pairs」に基づいて実施することができる。
ディテクタ300は、サービス拒否攻撃が企業ネットワーク150に対して行われつつあると判定した時に、1つまたは複数のソース/宛先IPアドレス対を中央フィルタ200に送信し、このソース/宛先IPアドレス対は、サービス・プロバイダ・ネットワーク120に、そのソースIPアドレスおよび宛先IPアドレスが送信されたソース/宛先IPアドレス対のいずれかのソースIPアドレスおよび宛先IPアドレスと一致するIPパケットの送信を制限させ(たとえば、ブロックさせるかレート制限させる)、これによって、企業ネットワーク150内の攻撃犠牲者への1つまたは複数のソース・デバイス110からのサービス拒否攻撃を制限する(または除去する)。ディテクタ300は、任意選択で、信頼できないUDP接続135または主セキュア認証済み接続130の使用によってソース/宛先IPアドレス対を送信する。本発明の一態様によれば、ディテクタ300と中央フィルタ200との間の通信のために告発プロトコルが提供される。
したがって、サービス拒否攻撃の犠牲者は、攻撃者をそのサービス・プロバイダに告発することによって「押し戻す」ことができ、このサービス・プロバイダは、これに応答して、ブロックされなければならないソース/宛先IP対のテーブルを更新する。より具体的には、攻撃が行われつつあることを認識した時に、犠牲者(企業ネットワーク150)は、攻撃の一部と思われるパケットで指定されるソースIPアドレスおよび宛先IPアドレスの1つまたは複数の対を識別し、中央フィルタ200によるブロックのためにこれらのIPアドレス対をサービス・プロバイダに通信する。
図1に示されているように、加入者(企業ネットワーク150)宛のパケットは、一般に「よい」トラフィックおよび「悪い」トラフィックに対応するクラスに分類される。たとえば、それぞれ、カテゴリA 105−Aからのよいトラフィックは、配送され(許可され)、カテゴリB 105−BおよびカテゴリN 105−Nからの悪いトラフィックは、それぞれレート制限されるか捨てられる。企業ネットワーク150に関連する宛先アドレスにトラフィックを送信するソース・コンピューティング・デバイス110は、N個の例示的カテゴリのうちの1つに分類される。告発は、よいトラフィックと悪いトラフィックとの間の境界をシフトする。
ある種の例示的実施形態によれば、攻撃者(すなわち、1つまたは複数の識別されたソースIPアドレス)は、ネットワークから完全に排除される必要があるのではなく、パケットを犠牲者(すなわち、1つまたは複数の識別された宛先IPアドレス)に送信することだけを禁じられることに留意されたい。これは、特に、1つまたは複数の指定されたソースIPアドレスが、犠牲者および関連する機械に対する所与の攻撃のために乗っ取られた正当なユーザ(たとえば、ゾンビ)を表す場合に、有利である場合がある。したがって、乗っ取られた機械の所有者は、正当な目的にそのシステムを使用し続けることができるが、犠牲者に対して行われる攻撃(おそらくは、正当なユーザに未知の)は、それでも、有利に阻まれる。さらに、そのような例示的実施形態による技法が、所与の犠牲者による攻撃者の過度に熱心な識別からの保護をも有利に提供することに留意されたい。本発明の原理によれば、攻撃の識別は、明白な犠牲者の裁量に一任されるので、所与の犠牲者へのトラフィックだけが排除されまたは制限されていることが、明らかに有利である。
悪意のある攻撃を、変化する度合の単純さまたは洗練を有する1つまたは複数のアルゴリズムによって、犠牲者によって認識することができ、これらのアルゴリズムは、本発明の範囲の外であるが、多数のアルゴリズムが、当業者に明白であろう。たとえば、本発明の1つの例示的実施形態によれば、パケット・トレースを検査することができ、攻撃を、単一の識別されたソースまたは複数の識別されたソースのいずれかからの非常に高いトラフィック・レベル(たとえば、高いパケット・レート)の存在だけに基づいて識別することができる。これが、サービス拒否攻撃の存在を識別する1つの従来の方法であり、当業者に馴染みのあるものであろうことに留意されたい。
しかし、他の実施態様では、パケット内容およびアプリケーション・ログのアプリケーション・ベースの分析を実行して、たとえば、存在しないデータベース要素の頻繁なデータベース検索があったことを認識すること、1人の人が開始できるレートより高いレートで発生する、一見人間からの複数の要求があったことを認識すること、構文的に無効な要求を識別すること、および通常に発生するアクティビティの動作での特に敏感な時刻でのトラフィックの疑わしい量を識別することなど、疑わしい性質を有するパケット、パケットのシーケンス、またはアクションを識別することができる。後者のクラスの疑わしいパケットの例は、たとえば、株式取引ウェブ・サイトが、差し迫った株取引中の敏感な時に特に破壊的なトラフィックに気付く場合に、識別することができる。さらなる変形では、たとえば上で説明した状況のうちの1つまたは複数を含めることができる可能な攻撃の複数の異なるしるしを、より洗練された分析で有利に組み合わせて、攻撃の存在を識別することができる。
例示的な検出システムは、2つのモードのうちの1つで動作することができる。ゾーンが、「デフォルトドロップ」モードである時に、デフォルト挙動は、デフォルトドロップ上に明示的にリストされたトラフィックを除く、そのゾーン宛のすべてのトラフィックをフィルタリングすることである。一般に、デフォルトドロップ・モードでは、フィルタは、明示的に許可され(たとえば、事前定義の許可フィルタと一致し)ない限り、すべてのトラフィックを自動的に捨てる。その一方で、ゾーンがデフォルトアロウモードである時に、事前定義のドロップ・フィルタと明示的に一致するトラフィックを除いて、加入者へのすべてのトラフィックが、フィルタによって渡される。
図2は、本発明のプロセスを実施できる、図1の中央フィルタ・システム200の概略ブロック図である。図2に示されているように、メモリ230は、本明細書で開示されるサービス拒否フィルタリングの方法、ステップ、および機能を実施するようにプロセッサ220を構成する。メモリ230は、分散させまたはローカルとすることができ、プロセッサ220は、分散させまたは単一とすることができる。メモリ230は、電気メモリ、磁気メモリ、もしくは光学メモリ、またはこれらの任意の組合せ、あるいは他のタイプのストレージ・デバイスとして実施することができる。プロセッサ220を構成する各分散プロセッサが、一般に、それ自体のアドレス可能メモリ空間を含むことに留意されたい。コンピュータ・システム200の一部またはすべてを、特定用途向け集積回路または汎用集積回路に組み込むことができることにも留意されたい。
図2に示されているように、例示的なメモリ230は、サービス拒否フィルタ・ルール・ベース260と、図4に関して下でさらに述べる1つまたは複数のサービス拒否フィルタリング・プロセス400とを含む。一般に、例示的なサービス拒否フィルタ・ルール・ベース260は、中央フィルタ200によって制限されまたは許可されなければならないトラフィックに関連するソース/宛先アドレス対を含む従来のフィルタ・ベースである。サービス拒否フィルタリング・プロセス400は、本発明による、サービス拒否または他の攻撃に対して防御する例示的な方法である。
中央フィルタ200を、サービス・プロバイダ・ネットワーク120に含まれる独立型ボックスとして、またはその代わりに、ネットワーク120内に既に存在する他の点では通常のネットワーク要素に組み込まれた回線カードとして、実施することができる。さらに、ある種の例示的実施形態によれば、中央フィルタ200を、ネットワーク120内で攻撃起点に相対的に近い位置にキャリアによって有利に展開することができ、あるいは、中央フィルタ200を、当初に、プレミアム・カスタマを攻撃から有利に防御するように配置することができる。
図3は、本発明のプロセスを実施できる、図1のディテクタ300の概略ブロック図である。図3に示されているように、メモリ330は、本明細書で開示されるサービス拒否フィルタリングの方法、ステップ、および機能を実施するようにプロセッサ320を構成する。メモリ330は、分散させまたはローカルとすることができ、プロセッサ320は、分散させまたは単一とすることができる。メモリ330は、電気メモリ、磁気メモリ、もしくは光学メモリ、またはこれらの任意の組合せ、あるいは他のタイプのストレージ・デバイスとして実施することができる。プロセッサ320を構成する各分散プロセッサが、一般に、それ自体のアドレス可能メモリ空間を含むことに留意されたい。コンピュータ・システム300の一部またはすべてを、特定用途向け集積回路または汎用集積回路に組み込むことができることにも留意されたい。図3に示されているように、例示的なメモリ330は、図5に関して下でさらに述べる、1つまたは複数のサービス拒否検出プロセス500を含む。
図4は、本発明の特徴を組み込むサービス拒否フィルタリング・プロセス400の例示的実施態様を説明する流れ図である。例示的なサービス拒否フィルタリング・プロセス400が、「デフォルトアロウ」モード用に実施されることに留意されたい。「デフォルトドロップ」モード用の実施態様は、当業者にたやすく明白になるはずである。一般に、サービス拒否フィルタリング・プロセス400は、本発明による、サービス拒否または他の攻撃に対して防御する例示的方法である。例示的なサービス拒否フィルタリング・プロセス400は、中央フィルタ200で実行され、ステップ410中に、企業ネットワーク150内の所与のターゲット犠牲者に対してサービス拒否攻撃が行われつつあることのUDP表示をディテクタ300から受信することによって開始される。
その後、ステップ420中に、ネットワーク・キャリアが、サービス拒否攻撃を阻むためにブロックされなければならないIPパケットを表す1つまたは複数のソース/宛先IPアドレス対をディテクタ300から受信する。実例として、ソースIPアドレスは、攻撃する(たとえば、「ゾンビ」)コンピューティング・デバイス110のアドレスであり、宛先IPアドレスは、ターゲット犠牲者自体に関連するアドレスである。ディテクタ300からのメッセージは、下で述べるDPに従って送信される。
次に、ネットワーク・キャリアは、ステップ430中に、そのソースIPアドレスおよび宛先IPアドレスが受信されたソース/宛先IPアドレス対のソースIPアドレスおよび宛先IPアドレスと一致するIPパケットを識別するために、IPパケット・トラフィックを監視する。ステップ440中にテストを実行して、1つまたは複数のパケットが、サービス拒否フィルタ・ルール・ベース260内のアドレス対と一致するかどうかを判定する。
ステップ440中に、1つまたは複数のパケットがサービス拒否フィルタ・ルール・ベース260内のアドレス対と一致すると判定される場合には、ステップ460中に、そのパケットを捨てるか制限しなければならない。ステップ440中に、1つまたは複数のパケットがサービス拒否フィルタ・ルール・ベース260内のアドレス対と一致しないと判定される場合には、ステップ470中に、そのパケットが、企業ネットワーク150への送信を許可される。
図5は、本発明の特徴を組み込むサービス拒否検出プロセス500の例示的実施態様を説明する流れ図である。一般に、サービス拒否検出プロセス500は、本発明による、サービス拒否または他の攻撃に対して防御する例示的方法である。例示的なサービス拒否検出プロセス500は、ディテクタ300によってターゲット犠牲者で実行され、ステップ510中に、受信されたIPパケットの分析に基づいて、ターゲット犠牲者に対してサービス拒否攻撃または別の悪意のある攻撃が行われつつあることを判定することによって開始される。次に、ステップ520中に、サービス拒否攻撃を阻むために、1つまたは複数のソース/宛先IPアドレス対を、ブロックされなければならないIPパケットを表すものとして識別する(実例として、ソースIPアドレスは、攻撃する「ゾンビ」機械110のアドレスであり、宛先IPアドレスは、ターゲット犠牲者自体に関連するアドレスである)。最後に、ステップ530中に、識別されたソース/宛先IPアドレス対を、開示されるDPを使用して犠牲者のキャリア・ネットワークの中央フィルタ200に送信して、キャリア・ネットワークが、一致するソースIPアドレスおよび宛先IPアドレスを有するIPパケットの送信をブロックできるようにする。
告発プロトコル
1つの例示的実施態様で、ディテクタ300と中央フィルタ200との間の告発プロトコルDP通信チャネルは、告発用のUDPポートおよびほとんどの他の通信用のTLS接続からなる。DPトランザクションは、2つのタイプを有する。UDP上の第1のタイプは、おそらくは中央フィルタ200からの任意選択の応答によって回答される、ディテクタ300から中央フィルタ200への要求パケットからなる。通常はTLSv1上の第2のタイプは、最終的に対応するレコード内で回答されるSSL「レコード」からなる。ほとんどのDPトランザクションは、ディテクタ300によって始められる。本発明の一態様によれば、ほとんどのDP要求は、応答または肯定応答を必要としない。
基本的なDPトランザクションは、ディテクタ300から中央フィルタ200への告発である。各ディテクタ300は、「ゾーン」すなわち、加入者(企業ネットワーク150)によって所有されるIPアドレスのサブセットであるIPアドレスのセットの代わりに話す。ディテクタ300は、そのゾーンに「属する」と言われる。ディテクタ300は、それが属するゾーン宛のトラフィックを告発する(ディテクタ300自体のIPアドレスが、それが属するゾーンの一部である必要はない)。
すべての告発トランザクションは、ディテクタ300によって始められる。加入者からの告発は、その加入者が少なくともパケットの受信を望む可能性が最も低い時、すなわちその加入者が過負荷である時に送信される可能性が高い。加入者から中央フィルタ200への経路上のパケット消失レートが通常より高い可能性があり、その時に中央フィルタ200が通常よりも多少忙しい可能性があることもありえる(または、可能性が高い)が、加入者からのインバウンド経路が、攻撃を受けている加入者への経路ほどにクリティカルに過負荷である可能性は低い。加入者から中央フィルタ200への経路は、サービス・プロバイダのネットワーク内にある。したがって、開示されるDPは、告発の時に加入者に向かうトラフィックを始めるのを避けることを試みる。したがって、告発は、信頼できる形で送信されるのではなく、肯定応答は、中央フィルタ200から受信されない。
そうではなく、加入者は、好ましくは、中央フィルタ200に1つの応答を送信させるのではなく、各告発要求の複数のコピーを送信する。複数のコピーは、告発要求が安全に中央フィルタ200に到着する確率を高める。たとえば、5つのコピーが送信され、パケットがランダムに捨てられる場合に、パケット消失レートが20%(ドロップ・レートが通常は5%を十分に下回る)であっても、要求の少なくとも1つのコピーが到着する見込みは、極端に高い。これらの極端な数(20%パケット消失レートおよび5つのコピー)を用い、パケット送信が、すべての消失が独立になるように分散されると仮定すると、少なくとも1つのコピーが着く見込みは、それでも、99.96%より高い。
この同一の推理は、パケットが順番に到着することに不必要に依存しないようにするために、各パケットを自己完結したものにすることをも保証する。前に示したように、DPトランザクションは、一般に、企業によって(ディテクタ300を介して)開始され、中央フィルタ200によって開始されるDPトランザクションはない。これは、部分的には、上で説明した考慮によって、ならびに企業の周囲のファイヤウォールによりフレンドリになるために要求/応答モデルを維持し、DPパケットが安全に着くことができる尤度を高めるために、動機付けられたものである。
中央フィルタ200は、どのフィルタ・ルールが公式にインストールされているのかを判定する。ディテクタ300は、単に、告発を中央フィルタ200に発行する。告発が中央フィルタ200に到着するという甲鉄の保証はない。さらに、複数のディテクタ300が、宛先の所与のゾーンについて敵対するソースを告発することができる。その結果、ディテクタ300は、インストールされたフィルタのセットを確実に知ることができない。加入者が、どのフィルタが実際にインストールされているのか、どのフィルタが中央フィルタ200に一度も到着していないのか、およびどのフィルタが他のディテクタ300によってまたは衝突に起因して(下を参照されたい)除去されまたは作成されたのかを知ることが、望ましい。このために、事態が多少落ち着いた時に、加入者は、中央フィルタ200に状況レポートを要求することができる。この状況レポートは、どの要求が到着したのか、どのフィルタがインストールされたのか、および他の情報(下で詳細を示す)をリストする。
状況を信頼できる形で受信し、認証をブートストラップするために、開示されるDPは、各ディテクタ300と中央フィルタ200との間の(信頼できる)通信チャネル(TLS)を提供する。
中央フィルタ200および各ディテクタ300は、ある共有される状態を維持するために協調しなければならない。最も明白な共有される状態は、インストールされたフィルタ・ルールのセットであるが、告発のシーケンス番号および認証に関する情報など、DP自体に関連する他の共有される状態もある。例示的実施形態は、適度に同期化されたクロックだけを必要とする。ディテクタ300または中央フィルタ200上で不要なものを実行する必要を回避するために、開示されるDPは、下の「B.認証」と題するセクションで述べるように、非常に粗いクロック「同期化」を提供し、その結果、Network Time Protocol(NTP)を用いて動作する必要がなくなる。多数の加入者が、企業ネットワークにまたがるイベント相関を単純にするために、いずれにせよディテクタ300上でNTPを実行することを望む(しかし、これは、DPが動作するために必要ではない)。
フィルタとプロトコル状態との両方について、開示されるDPは、ディテクタ300および中央フィルタ200が、初期共有状態に信頼できる形で合意し、その後、両側が、時間の経過に伴って、状態に対する変更を記憶することを要求する。ディテクタ300と中央フィルタ200との間の不一致の場合に、中央フィルタ200が、必ず、共有される状態の「真の」像を有する。同期化された状態に保たれるべきフィルタ状態の量は、ディテクタ300次第である(ディテクタ300は、過去の告発をまったく気にせず、その分析のすべてを現在のトラフィック・フローに基づくものとすることができる)。プロトコル状態は、DPによって要求される。
ディテクタ300は、周期的な状況要求によって、フィルタ状態を中央フィルタ200と再同期化することができる。通常、中央フィルタ200は、最後の状況要求以降のフィルタ状態変化だけを返す(要求された場合には、インストールされた時にかかわりなく、現在アクティブなすべてのフィルタを返すこともできるが)。通常、中央フィルタ200は、ゾーン内のすべてのディテクタ300のフィルタを返すが、要求された場合には、このディテクタ300によって要求された告発だけを返すことができる。
ディテクタ300は、同期化要求によって、シーケンス番号および認証鍵を再同期化することができる。同期化トランザクションでは、ディテクタ300が、新しいシーケンス番号を一方的に選択し、中央フィルタ200が、認証用の新しいセッション鍵を生成する。
ディテクタ300がクラッシュするか、ともかくも情報を失う場合に、ディテクタ300は、最近のフィルタ・ルールだけではなく、すべてのフィルタ・ルールを要求することができる。いつでも、ディテクタ300は、告発のために認証情報を再ネゴシエートすることができる(下を参照されたい)。
中央フィルタ200が、すべてのフィルタ・ルールをリセットする場合に(ゾーン変更、モード変更、またはある致命的DBクラッシュ)、中央フィルタ200は、ディテクタ300との関連を故意に忘れ、中央フィルタ200から再同期応答を返すために次のディテクタ・トランザクションを促す。ディテクタ300が、中央フィルタ200と再同期化する時に、中央フィルタ200は、そのディテクタ300に、そのディテクタ300の以前の状態がもはや無効であり、すべての状況を要求する必要があることを知らせることができる。
中央フィルタ200が、奇形のパケットまたは認証されていないパケットを受信する場合がある。その場合に、中央フィルタ200は、たとえば各ホストに30秒おきに1エラー・パケットの最大レートまで、(正当な)送信側にエラー・パケットを返す。レート制限は、たとえば攻撃者が告発プロトコルを使用してサービス拒否攻撃を始めるのを防ぐために、セットすることができる。
衝突する告発
告発は、パケットが分類に一致する場合に、複数の可能な異なるアクションを指定することができる。その結果、衝突が発生する場合がある。たとえば、あるディテクタ300が、サブネット全体がウェブ・クローラを起動していると思われ、レート制限されなければならないと指定する場合がある。もう1つのディテクタ300が、そのサブネット内の特定のホストが実際の攻撃を起こしていることを検出し、そのホストからのすべてのパケットを捨てなければならないと指定する場合がある。そのような衝突の場合に、後者のルールは、明らかに、前者のルールより特定であり、後者のルールは、単一のホストに言及し、単にソースをレート制限するのではなく捨てるように言う。そのような衝突では、より厳密なルールが適用されると論じることが理にかなっている。しかし、要求されるアクションが逆である、すなわち、1つのディテクタ300が単一ソースに対するレート制限を要求し、もう1つのディテクタ300が、サブネット(そのソースを含む)からのすべてのパケットを捨てることを要求すると仮定する。前者のルールがより特定である(サブネット全体ではなく単一のホストに言及する)と論じることができ、あるいは、後者のルールがより厳密である(パケットをまばらにするのではなく捨てるように言う)と、同等によく論じることができる。例示的実施形態は、最も特定のソース・アドレスが優先される規約を採用する。
それでも、明確にするために、最良の実践は、ディテクタ300が衝突するルールを発行するのを避けることである。新しいセットを発行する前に、既存の衝突するルールを撤回することが、いつでも可能である。しかし、告発の信頼性の欠如を考慮すると、中央フィルタ200が、より以前の衝突するルールが撤回されたことを発見する前に新しいルールを受信することが考えられる。さらに、複数のディテクタ300が同一のゾーンを管理するならば、2つのディテクタ300が、衝突を放棄せずに衝突する告発を独立に発行することが可能である。
衝突に出会う時の中央フィルタ200の挙動を指定しなければならない。1つの例示的実施形態では、基本的なポリシは、衝突(ソース・アドレスの同一の指定を有するが2つの異なるアクションまたは理由を有する2つのルール)の場合に、より後のルールがより前のルールをオーバーライドすることである(「より後」は、ルールが中央フィルタに到着する時を指す)。
DPプロトコル・アルゴリズム
A.信頼できる送信
上で論じたように、パケットは、中央フィルタ200からディテクタ300への他方の方向で送信されるのではなく、ディテクタ300から中央フィルタ200に送信されなければならない。さらに、各パケットは、自立していることができ、順序通りの送達を必要としない。その結果、各告発パケットが到着し、順番に到着することを保証するのではなく、開示されるDPは、各パケットの複数のコピーを送信することによって成功の到着の見込みを確立的に改善することを選ぶ。DP告発要求は、たとえばSYNCH要求に応答して指定される、中央フィルタ200上のポートへのUDPパケット内で送信される。一般に、各告発パケットは、p回送信され、肯定応答は不要である。1つの例示的実施態様では、pが、5に固定され、パケット・ペーシングに対する形式的要件は、与えられない。
順序付け要件のために(衝突解決ルールが明確な勝者を選択しない直接に衝突するフィルタ・ルールの場合に、最も新しいルールがより古いルールをオーバーライドするルールを与えられて)、DPシーケンス番号が、送信順序を決定するためにアプリケーションまで渡される。中央フィルタ200は、複数のディテクタ300からの告発のシリアライザとして働く。単一のディテクタ300からの要求は、シーケンス番号によって、曖昧さなしに順序付けられる。インターリービングの順序は、中央フィルタ200によって一方的に判断される。中央フィルタ200は、大域的順序のどこで、各ディテクタ300が状況応答を最後に受信したかを記憶する。
複数のパケットを送信することの背後にある意図は、各パケットの少なくとも1つのコピーが中央フィルタ200に到着することであって、中央フィルタ200をパケットで氾濫させることではない。さらに、攻撃者が、開示されるDPに対するDoS攻撃を開始するためのてこの作用点を有してはならない。中央フィルタ200は、平均して、1トランザクションあたり1つのパケットを処理しなければならない。中央フィルタ200が、各パケットが正しいディテクタ300によって送信されたことを確信するために各パケットを認証するという要件は、パケット処理が高価になる場合があることを意味する。
ほとんどの冗長パケットは、高価な計算なしで破棄することができる。一実施形態では、最も安価なテストが最初に実行される。たとえば、シーケンス番号は、暗号化されず、告発要求についてチェックするために計算的に安価である。同様に、ディテクタ名が既知であるかどうかをチェックすることも、安価である。重複する要求および範囲外のシーケンス番号は、他のテストを実行する前に簡単に破棄される。
開示されるDPでは、告発トランザクションは、ディテクタ300によってUDP上で開始される。DPは、他の要求について別々のTLS接続(TCPを介する)を維持する。
B.認証
例示的実施態様でのDPの基本的な認証機構は、クライアント証明書を用いてTLSv1によって提供される認証ハンドシェークである。信頼されるIPS証明局の公開鍵が、中央フィルタ200および各ディテクタ300に事前にロードされる。各ディテクタ300および中央フィルタ200は、その認証局CAによって署名された、その公開鍵の証明書を有する。さらに、加入者ディテクタ300は、中央フィルタ200の完全修飾ドメイン名を与えられ、この完全修飾ドメイン名は、サーバ証明書SubjectのCN部分でもある。
鍵は、ディテクタのIPアドレスではなく「名前」に関連し、IPアドレスは、複数の理由から変化し得る。下で注記するように、DPは、任意の時に所与の名前を有する最大1つのディテクタ300を実施する。標準TLSプロトコルに従って、中央フィルタ200は、CAによって署名された証明書だけを受け入れることを指定するCertificate Requestメッセージを送信する。ディテクタ300は、クライアント認証プロセスの一部として2つのメッセージを応答する。第1に、ディテクタ300は、ディテクタの名前およびディテクタの公開鍵を含む証明書を供給する。第2に、ディテクタ300は、ディテクタの秘密鍵によって署名されたTLSハンドシェーク・メッセージのすべてのダイジェストを含むCertificate Verifyメッセージを送信する。ここで、中央フィルタ200は、証明書で言及されたディテクタ300としてクライアントを認証することができる。
TLSv1接続が確立されたならば、中央フィルタ200は、告発をUDPを介して発行できるようになる前に、このセキュアな暗号化されたチャネルを使用して、ランダムに選択された160ビットの秘密ナンスをディテクタ300に送信しなければならない。
すべてのDP告発パケットは、認証される。1つの例示的実施形態では、開示されるDPでの告発は、(a)UDPパケット内容、(b)タイム・カウンタ(RSTART以降の「単位」数、ここで、「単位」の長さおよびRSTARTの時刻は、同期化中に確立される)の暗号ハッシュによって認証される。(c)秘密ナンス、および(d)TLSチャネルによって使用されるDPポート番号。(b)は、反射攻撃に対する最小限の防御であり、(c)は、中央フィルタ200に対してディテクタ300を認証する。例示的実施形態で使用されるMAC関数は、HMAC−SHA1(詳細については、Internet RFC 2104を参照されたい)であり、上の余分なフィールドは、HMAC鍵として使用される。
20ビットのシーケンス番号を、パケットの内部に含めることができるが、各サーバが、単位カウンタが増分される前に220個未満の要求を送信すると仮定されたい。DPのエンドポイントは、所与のシーケンス番号を有する最初の有効なパケットだけを受け入れる。シーケンス番号がラップ・アラウンドする時までに、単位カウンタが、単純な反射攻撃に対して防御するために増分されている。ディテクタ300は、シーケンス番号の上位ビット(第21ビット)として単位カウンタの数の下位ビットを含む。これは、「日付」(RSTART時刻以降の単位数)が中央フィルタ200に関する任意の時にディテクタ300上で変化することを可能にし、中央フィルタ200は、それでも、隠された日付が何であるかを計算することができる(1「日」[単位]あたり少なくとも1つの同期化交換がある限り)。これは、密に同期化されたクロックの必要を回避することを可能にする。
ディテクタ300が、1つの時間単位内に220個を超えるパケットの送信を試みるというありそうにない場合に、そのディテクタ300は、中央フィルタ200に新しい秘密ナンスを要求しなければならない。そのディテクタ300は、シーケンス番号がラップ・アラウンドすることの可能性を低くするために、単位の長さ(1日の分数として表される)を選択する。
これらの暗号ハッシュの計算が高価になり得ると思われる可能性があり、その出費は、各パケットの多数のコピーを送信することによって悪化する可能性がある。しかし、所与のシーケンス番号が成功して受信されたならば、すべての重複を、ハッシュを計算せずに破棄できることに留意されたい。攻撃者からのランダムに構成されたパケットは、受け入れられる可能性が低い。というのは、受け入れることのできるシーケンス番号のウィンドウが、シーケンス番号空間全体と比較して非常に小さいからである。中央フィルタ200は、期待されるウィンドウの外のパケットを破棄する。さらなるウィンドウイングは、ディテクタ名に基づくものとすることができ、ディテクタ名は、疎に割り振ることができ、たとえば、2バイト・フィールド内で100個程度の有効な値とすることができる。
攻撃者が告発要求をスヌーピングすることができ、ディテクタ名をコピーし、シーケンス番号を取り込み、その後にウィンドウ内の最後のパケットの多数の悪いコピーを送信する懸念がある場合に、スヌーパに対して保護される、高速破棄の方法を提供することができる。実際には、この余分なレベルの保護が不要であると期待される、すなわち、SHA1を実行することのコストが、この追加の複雑さを正当化するのに十分な受信側のボトルネックではなくなると期待される。それでも、このセキュア高速破棄方法を、下で述べる。
C.セキュア高速破棄
セキュア高速破棄方法は、任意選択である。この任意選択の方法の空間は、例示的なDP版では告発パケット内で提供されるが、このセキュア高速破棄アルゴリズムは、実際にこの保護が必要であると判定されない限り、DP内でイネーブルされない。
基本的な手法は、次のとおりである。各告発要求は、計算しやすいLビット・ストリングS(ストリングがシーケンス番号フィールドのパディングにおさまるようにするために、暫定的にL=5)を含む。Sは、シーケンス番号と、SSLチャネルを介して中央フィルタ200によって供給される秘密鍵の対との単純な関数の結果である。パケットが無効であるかどうかをチェックすることは、計算的に安価であり、Sが期待される値でない場合には、パケットは破棄される。パケットが有効であるかどうかを判定するためには、それでも、暗号ハッシュのチェックが必要であるが、これは、1シーケンス番号あたり約1回発生する。
ディテクタ300が、HMAC−SHA1の共有鍵を中央フィルタ200と同期化する時に、中央フィルタ200は、ストリング長L、鍵長B、B+LビットのストリングS、および1≦K≦Bになる小さい整数Kをも提供しなければならない。これらのいずれもが、攻撃者には未知であるが、LおよびBは、頻繁に変化することができ、SおよびKと同一の意味で「秘密」と考えられてはならない。シーケンス番号sを有する告発要求に関して、Sは、ビット位置bから始まるS内のLビット・サブストリングである。bは、s、B、およびKの関数である。Sは、パケットのHMAC−SHA1ハッシュの第b0位置に挿入される(SHA1ハッシュの長さをLビットだけ延ばす)。
L=5およびB=1019の場合に、パターンは、約220個の告発パケットまで繰り返さず、約220個の告発パケットの時には、新しいナンスが、どの場合でもHMAC−SHA1ハッシュについて選択されなければならない。ストリングSが、スヌープする攻撃者にランダムに見えるならば、Sの単純なチェックは、攻撃するパケットのストリームを2L倍だけ細くしなければならない。しかし、より大きいLの選択は、攻撃者がSを、およびその後にKを再構成できる見込みを増やし、したがって、Lは、この問題を防ぐために2L2<B(LがO(logB)であることを意味する)になるように選択されなければならない(すべての可能なLビット・サブストリングがS内に1回を超えて現れる可能性が高くなるようにするために)。
D.DPメッセージ・サービス
開示されるDPは、ディテクタ300および中央フィルタ200が信頼できる形でお互いにメッセージを送信する手段を提供する。SSL/TLSが、ストリーム内のレコードを実施する。SSLレコードを、各レコードをそのレコードのタイプ(状況、メッセージ、および状況応答など)を単純に記述するDPレコード・ヘッダから開始するDPレコードとして使用することができる。しかし、我々の経験では、すべてのTLS実施態様が、クライアントへのAPIでレコード境界を保存するわけではない(SSL書き込みは(データが大きすぎない限り)、SSLレコードを作るが、SSL読み取りは、部分的レコードまたは複数のレコードを返すことができる)。その結果、プラットフォームにまたがる最大の可搬性をもたらすために、DPの例示的実施形態は(おそらくは冗長に)それ自体のレコード・マーキング・プロトコルをSSLレコード内で実施する。理想的には、1つのDPレコードが、各SSLレコード内におさまらなければならないが、レコード・プロトコルは、かかわりなく働く。DPは、レコードを開始するのにレコードの始めマーカを使用し、終了するのにレコードの終りマーカを使用する。各レコードは、タイプおよび長さフィールドから始まる。長さフィールドは、ビット/バイト詰込を回避することを可能にし、開始レコード・マーカまたは終了レコード・マーカのいずれかがレコード内に現れることが、ルールに従ったものである。長さフィールドは、ヘッダおよびトレイラを含まない、メッセージ内のバイト数である。
開始マーカおよび終了マーカは、例示的実施形態では4バイト・シーケンスであるが、DPメッセージに対するアライメント要件はない。メッセージの本体は、任意の長さとすることができ、長さが32ビット(4バイト)の倍数である必要はない。開始マーカおよび終了マーカは、サーバまたはクライアントが奇形レコードを発行する場合にレコード境界を回復することを可能にし、シーケンス[レコードの終り][レコードの始め]およびそれに続く、それ自体が[レコードの終り][レコードの始め]対をポイントする長さフィールドを検索するだけでよい。
E.パケット・フォーマット、バージョン番号、および互換性
開示されるDPに対する変更は、後方互換でなければならない。SSLチャネルを利用するプロトコル動作に対する非互換の変更は、非互換フォーマットを有する古いタイプの再利用ではなく、新しいレコードタイプ識別子を割り振る。告発トランザクションに対する非互換の変更は、変更されたDP仕様の一部として、新しいDPポート番号の選択を必要とする。DPは、2つの形のうちの1つで、DPチャネルのリモート端の非DPエージェントを検出する。SSL接続のリモート端は、認証に失敗するか、DP初期同期化プロトコルに従うことに失敗するかのいずれかになる。非互換性が、なんらかの理由でSSL接続確立中に検出されない場合に、暗号ハッシュは、リモート端がDPでないからまたはハッシュでDPの非互換バージョン番号を使用しているからのいずれかで、UDPトラフィックについて失敗する。これは、ワイヤを介してDPによって送信されるデータ内のバージョン番号またはマジック・ナンバの必要をなくす。
パケットおよび動作
前に示したように、ディテクタ300は、DPチャネルを介して中央フィルタ200と通信する。DPチャネルは、ディテクタ300および中央フィルタ200が通信するために、現在確立されていなければならない。各ディテクタ300は、中央フィルタ200の特定のインスタンスに束縛される。中央フィルタ200は、それに束縛されていないディテクタ300とは通信しない。所与の中央フィルタ200に束縛された各ディテクタ300は、その中央フィルタ200によって使用される数値の「名前」を有する。
DPチャネル確立の第1ステップは、ディテクタ300から中央フィルタ200へのSSL/TSL接続を開始することである。中央フィルタ200は、SSL/TLS認証プロセスを介して、通信するディテクタ300を真正として識別する。ディテクタ300は、TSLハンドシェークのクライアント認証フェーズでディテクタ300が中央フィルタ200に供給する証明書内で使用される名前になることを請求する。この名前は、事前に定義された形でなければならない。
TLSチャネルが確立されたならば、ディテクタ300は、そのTLSチャネル上で同期化要求を送信しなければならない。このTLSチャネルは、同期化要求がディテクタ300から中央フィルタ200に送信され、同期化肯定応答がディテクタ300から中央フィルタ200に返されるまで、初期化されたとは考えられない。例示的同期化要求は、他の値の中でも、次の告発トランザクションのシーケンス番号を含む(各告発トランザクションのシーケンス番号は、次の同期化要求まで、1つ増分される)。例示的同期化要求は、「時間単位」の長さおよびランダム開始時刻「RSTART」をも初期化する。中央フィルタ200は、ランダムに生成された160ビットのセッション鍵と、ディテクタ300を増分フィルタ状態で満足できるかどうかの表示またはディテクタ300がすべてのフィルタ状態を必要とするかどうかの表示とを含む同期化肯定応答を応答する。
この交換の後に、ディテクタ300は、経路MTUを確立し、最初の状況応答を要求し、受信しなければならない。この時点で、DPチャネルが確立される。上で説明したように、DPトランザクションの4つの基本的なタイプすなわち、同期化、告発、状況照会、およびメッセージがある。最初の3つのトランザクション・タイプ(同期化、告発、および状況照会)は、すべてがディテクタ300によって開始される。しかし、メッセージは、SSLチャネルを介して、ディテクタ300または中央フィルタ200の要求でどちらの方向にも送信され得る。
告発トランザクションは、UDPチャネルを介してディテクタ300上のランダム・ポートから中央フィルタ200上のDPポートに送信される。通常の場合に、中央フィルタ200は、応答をまったく送信しない。エラー、障害、または潜在的な攻撃の場合に、中央フィルタ200は、再同期またはエラー・パケットのいずれかを応答することができる。これらの応答は、TLSチャネルがまだ存在することがわかっている時に、そのTLSチャネルを介して送信される。TLSチャネルが存在しない場合には、応答は、UDPを介して送信され、この場合に、その応答は、TLSチャネルを再確立するための再同期メッセージでなければならない。一般的なルールは、着信パケットがきちんと形成されており、中央フィルタ200が、クライアントが正当であると考える場合に、中央フィルタ200が、再同期メッセージを送信することである。そうでない場合には、中央フィルタ200は、エラー・メッセージを送信する。
すべての他のトランザクションは、TLSチャネルを利用する。
A.UDPトランザクション(告発および応答)
前に示したように、HMAC−SHA1メッセージ認証は、パケットの内容ならびにナンス、日付カウンタ、およびグローバルDPポート番号を含む鍵に対して計算される。図6に、UDPパケットの前に付加されたUDP要求のHMAC鍵を示す。
上で示したように、RSTART以降の単位数は、DPがDoS攻撃のソースになることを防ぐ。
B.SSLチャネル
TLSチャネルを介して送信されるすべてのDP通信は、レコードに分解される。1つの例示的実施形態で、単一DPレコードの最大サイズは、16000バイトである。SSLプロトコルへのAPIが許容する場合に、1SSLレコードあたり正確に1つのDPレコードを有することが、よい実践である。例示的なDPレコードは、たとえば、事前定義の4バイトのシーケンスから始まり、もう1つの事前定義の4バイトのシーケンスで終わる。DPレコードのタイプは、メッセージ・マーカの始めに直接に続く32ビット整数としてエンコードされる(ネットワーク・バイト順で)。DPレコードの長さは、タイプに直接続く32ビット整数としてエンコードされる(ネットワーク・バイト順で)。図7に、セキュアな信頼できるストリーム内のDPレコード・ヘッダおよびトレイラの例示的レイアウトを示す。
本発明は、1つまたは複数の補足ツールと共に働くことができる。たとえば、そのようなツールに、活用されるサービス拒否攻撃の認識のためのインターネット・サーバ・プラグイン、さまざまなIDSシステム(侵入検出システム)へのリンク、ネットワーク診断用のデータベース(上の議論を参照されたい)、および所与のキャリアのインフラストラクチャ内のザッパ機能性の配置に関するガイダンスを提供する方法を含めることができる。これら補足ツールのうちのさまざまなツールを提供する本発明の例示的実施形態は、本明細書の開示に鑑みて、当業者に明白であろう。
システムおよび製造品の詳細
当技術分野で既知のとおり、本明細書で述べた方法および装置を、コンピュータ可読コード手段がその上で実施されたコンピュータ可読媒体をそれ自体が含む製造品として配布することができる。コンピュータ可読プログラム・コード手段は、コンピュータ・システムと共に、本明細書で述べた方法を実行するステップの一部またはすべてを実行するか本明細書で述べた装置を作成するように動作可能である。コンピュータ可読媒体は、記録可能媒体(たとえば、フロッピ・ディスク、ハード・ドライブ、コンパクト・ディスク、メモリ・カード、半導体デバイス、チップ、特定用途向け集積回路ASIC)とすることができ、あるいは伝送媒体(たとえば、光ファイバ、ワールド・ワイド・ウェブ、ケーブル、または時分割多元接続、符号分割多元接続もしくは他の無線周波数チャネルを使用する無線チャネルを含むネットワーク)とすることができる、コンピュータ・システムと共に使用するのに適切な情報を格納できる既知のまたはこれから開発されるすべての媒体を使用することができる。コンピュータ可読コード手段は、磁気媒体上の磁気変動またはコンパクト・ディスクの表面上の高さ変動など、コンピュータが命令およびデータを読み取ることを可能にするすべての機構である。
本明細書で説明したコンピュータ・システムおよびサーバのそれぞれは、本明細書で開示される方法、ステップ、および機能を実施するように関連するプロセッサを構成するメモリを含む。メモリは、分散させまたはローカルとすることができ、プロセッサは、分散させまたは単一とすることができる。メモリは、電気メモリ、磁気メモリ、もしくは光学メモリ、またはこれらの任意の組合せ、あるいは他のタイプのストレージ・デバイスとして実施することができる。さらに、用語「メモリ」は、関連するプロセッサによってアクセスされるアドレス可能空間内のアドレスから読み取るかこれに書き込むことができるすべての情報を含むのに十分に広義に解釈されなければならない。この定義を用いると、ネットワーク上の情報は、それでもメモリ内にある。というのは、関連するプロセッサが、ネットワークから情報を取り出すことができるからである。
図示され本明細書で説明された実施形態および変形形態が、単に本発明の原理を示すものであることと、本発明の範囲および趣旨から逸脱せずに当業者がさまざまな変更を実施できることとを理解されたい。

Claims (1)

  1. ターゲット装置によって、望まれないトラフィックに対して防御する方法であって、ターゲット装置は1つまたは複数の宛先アドレスを有し、
    1つまたは複数のソースIPアドレスから受信されるパケットの分析に基づいて、望まれないトラフィックが前記ターゲット装置によって受信されることを判定するステップと、
    サービス・プロバイダに関連する中央フィルタに告発メッセージを送信するステップとを含み、前記ターゲット装置へのパケットのそれによる送信が制限される、捨てられる、および許可されるのうちの1つまたは複数であると前記告発メッセージ内で指定される少なくとも1つのソース・コンピューティング・デバイスのソース・アドレスを、前記告発メッセージが識別し、前記告発メッセージが、前記中央フィルタからの即座の肯定応答を必要としない告発プロトコルを使用して送信される、方法。
JP2011280852A 2006-11-03 2011-12-22 1つまたは複数のパケット・ネットワーク内で悪意のある攻撃中に制御メッセージを送達する方法および装置 Pending JP2012109996A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/592,726 2006-11-03
US11/592,726 US8914885B2 (en) 2006-11-03 2006-11-03 Methods and apparatus for delivering control messages during a malicious attack in one or more packet networks

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2009535274A Division JP2010508760A (ja) 2006-11-03 2007-10-23 1つまたは複数のパケット・ネットワーク内で悪意のある攻撃中に制御メッセージを送達する方法および装置

Publications (1)

Publication Number Publication Date
JP2012109996A true JP2012109996A (ja) 2012-06-07

Family

ID=39361195

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2009535274A Pending JP2010508760A (ja) 2006-11-03 2007-10-23 1つまたは複数のパケット・ネットワーク内で悪意のある攻撃中に制御メッセージを送達する方法および装置
JP2011280852A Pending JP2012109996A (ja) 2006-11-03 2011-12-22 1つまたは複数のパケット・ネットワーク内で悪意のある攻撃中に制御メッセージを送達する方法および装置

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2009535274A Pending JP2010508760A (ja) 2006-11-03 2007-10-23 1つまたは複数のパケット・ネットワーク内で悪意のある攻撃中に制御メッセージを送達する方法および装置

Country Status (6)

Country Link
US (1) US8914885B2 (ja)
EP (1) EP2095603B1 (ja)
JP (2) JP2010508760A (ja)
KR (1) KR20090094236A (ja)
CN (1) CN101536455B (ja)
WO (1) WO2008063344A2 (ja)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2915598A1 (fr) * 2007-04-27 2008-10-31 France Telecom Procede de filtrage de flots indesirables en provenance d'un terminal presume malveillant
US7949721B2 (en) * 2008-02-25 2011-05-24 International Business Machines Corporation Subnet management discovery of point-to-point network topologies
US7962564B2 (en) * 2008-02-25 2011-06-14 International Business Machines Corporation Discovery of a virtual topology in a multi-tasking multi-processor environment
US8762125B2 (en) * 2008-02-25 2014-06-24 International Business Machines Corporation Emulated multi-tasking multi-processor channels implementing standard network protocols
US8009589B2 (en) * 2008-02-25 2011-08-30 International Business Machines Corporation Subnet management in virtual host channel adapter topologies
US8065279B2 (en) * 2008-02-25 2011-11-22 International Business Machines Corporation Performance neutral heartbeat for a multi-tasking multi-processor environment
US20090216893A1 (en) * 2008-02-25 2009-08-27 International Business Machines Corporation Buffer discovery in a parrallel multi-tasking multi-processor environment
JP5605237B2 (ja) * 2010-06-30 2014-10-15 沖電気工業株式会社 通信制御装置及びプログラム、並びに、通信システム
US20120268271A1 (en) * 2011-04-19 2012-10-25 Mcmullin Dale Robert Methods and systems for detecting compatibility issues within an electrical grid control system
US8661522B2 (en) * 2011-07-28 2014-02-25 Arbor Networks, Inc. Method and apparatus for probabilistic matching to authenticate hosts during distributed denial of service attack
US20130094515A1 (en) * 2011-08-31 2013-04-18 Nils Gura Systems, apparatus, and methods for removing duplicate data packets from a traffic flow of captured data packets transmitted via a communication network
JP2014236461A (ja) * 2013-06-05 2014-12-15 日本電信電話株式会社 遮断システム、遮断サーバ、遮断方法、およびプログラム
EP2852118B1 (en) * 2013-09-23 2018-12-26 Deutsche Telekom AG Method for an enhanced authentication and/or an enhanced identification of a secure element located in a communication device, especially a user equipment
US9077639B2 (en) * 2013-11-18 2015-07-07 Arbor Networks, Inc. Managing data traffic on a cellular network
US9686077B2 (en) * 2014-03-06 2017-06-20 Microsoft Technology Licensing, Llc Secure hardware for cross-device trusted applications
JP6644141B2 (ja) * 2016-06-08 2020-02-12 シャープ株式会社 応答装置および応答装置の制御方法、制御プログラム
US10868828B2 (en) * 2018-03-19 2020-12-15 Fortinet, Inc. Mitigation of NTP amplification and reflection based DDoS attacks
CN108494800A (zh) * 2018-04-27 2018-09-04 广州西麦科技股份有限公司 一种数据包安全检测及处理方法、装置、p4交换机及介质
CN113395247B (zh) * 2020-03-11 2023-01-13 华为技术有限公司 一种防止对SRv6 HMAC校验进行重放攻击的方法和设备

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002094558A (ja) * 2000-09-14 2002-03-29 Toshiba Corp パケット転送方法、移動端末装置及びルータ装置
JP2004247955A (ja) * 2003-02-13 2004-09-02 Toshiba Solutions Corp 通信システムおよび通信方法
JP2004260789A (ja) * 2003-02-04 2004-09-16 Hitachi Kokusai Electric Inc パケット通信装置
JP2005151039A (ja) * 2003-11-13 2005-06-09 Nippon Telegr & Teleph Corp <Ntt> 攻撃パケット防御システム
JP2005159922A (ja) * 2003-11-28 2005-06-16 National Institute Of Information & Communication Technology 通信装置、通信システム及び通信方法
JP2006109152A (ja) * 2004-10-06 2006-04-20 Matsushita Electric Ind Co Ltd ネットワーク上で通信を行う接続要求機器、応答機器、接続管理装置、及び通信システム
WO2006040880A1 (ja) * 2004-10-12 2006-04-20 Nippon Telegraph And Telephone Corporation サービス不能攻撃防御システム、サービス不能攻撃防御方法およびサービス不能攻撃防御プログラム
JP2006270894A (ja) * 2005-03-25 2006-10-05 Fuji Xerox Co Ltd ゲートウェイ装置、端末装置、通信システムおよびプログラム
US20060248588A1 (en) * 2005-04-28 2006-11-02 Netdevices, Inc. Defending Denial of Service Attacks in an Inter-networked Environment
JP2009504099A (ja) * 2005-08-05 2009-01-29 ルーセント テクノロジーズ インコーポレーテッド IPネットワークにおいてターゲット被害者自己識別及び制御によってDoS攻撃を防御する方法

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6111894A (en) * 1997-08-26 2000-08-29 International Business Machines Corporation Hardware interface between a switch adapter and a communications subsystem in a data processing system
US6711166B1 (en) * 1997-12-10 2004-03-23 Radvision Ltd. System and method for packet network trunking
US6505254B1 (en) * 1999-04-19 2003-01-07 Cisco Technology, Inc. Methods and apparatus for routing requests in a network
TW453072B (en) * 1999-08-18 2001-09-01 Alma Baba Technical Res Lab Co System for montoring network for cracker attacic
CN1498368A (zh) * 2001-03-20 2004-05-19 ���˹���Ѷ��� 使用虚拟专用网络抵抗IPQoS拒绝服务攻击的系统、方法和设备
US7543051B2 (en) * 2003-05-30 2009-06-02 Borland Software Corporation Method of non-intrusive analysis of secure and non-secure web application traffic in real-time
CN100362802C (zh) * 2004-06-29 2008-01-16 华为技术有限公司 一种抵御拒绝服务攻击的方法
US20060056403A1 (en) * 2004-09-13 2006-03-16 Pleasant Daniel L System and method for robust communication via a non-reliable protocol
US20060185008A1 (en) * 2005-02-11 2006-08-17 Nokia Corporation Method, apparatus and computer program product enabling negotiation of firewall features by endpoints
JP4790731B2 (ja) * 2005-02-18 2011-10-12 イーエムシー コーポレイション 派生シード
US20060218636A1 (en) * 2005-03-24 2006-09-28 David Chaum Distributed communication security systems
US7590129B2 (en) * 2005-12-07 2009-09-15 Alcatel Lucent Complementary residential gateway management
US20080089433A1 (en) * 2006-10-13 2008-04-17 Jun Hyok Cho Method and apparatus for adapting to dynamic channel conditions in a multi-channel communication system

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002094558A (ja) * 2000-09-14 2002-03-29 Toshiba Corp パケット転送方法、移動端末装置及びルータ装置
JP2004260789A (ja) * 2003-02-04 2004-09-16 Hitachi Kokusai Electric Inc パケット通信装置
JP2004247955A (ja) * 2003-02-13 2004-09-02 Toshiba Solutions Corp 通信システムおよび通信方法
JP2005151039A (ja) * 2003-11-13 2005-06-09 Nippon Telegr & Teleph Corp <Ntt> 攻撃パケット防御システム
JP2005159922A (ja) * 2003-11-28 2005-06-16 National Institute Of Information & Communication Technology 通信装置、通信システム及び通信方法
JP2006109152A (ja) * 2004-10-06 2006-04-20 Matsushita Electric Ind Co Ltd ネットワーク上で通信を行う接続要求機器、応答機器、接続管理装置、及び通信システム
WO2006040880A1 (ja) * 2004-10-12 2006-04-20 Nippon Telegraph And Telephone Corporation サービス不能攻撃防御システム、サービス不能攻撃防御方法およびサービス不能攻撃防御プログラム
JP2006270894A (ja) * 2005-03-25 2006-10-05 Fuji Xerox Co Ltd ゲートウェイ装置、端末装置、通信システムおよびプログラム
US20060248588A1 (en) * 2005-04-28 2006-11-02 Netdevices, Inc. Defending Denial of Service Attacks in an Inter-networked Environment
JP2009504099A (ja) * 2005-08-05 2009-01-29 ルーセント テクノロジーズ インコーポレーテッド IPネットワークにおいてターゲット被害者自己識別及び制御によってDoS攻撃を防御する方法

Also Published As

Publication number Publication date
JP2010508760A (ja) 2010-03-18
EP2095603B1 (en) 2016-05-04
KR20090094236A (ko) 2009-09-04
US20080109891A1 (en) 2008-05-08
US8914885B2 (en) 2014-12-16
EP2095603A2 (en) 2009-09-02
CN101536455B (zh) 2013-01-02
WO2008063344A3 (en) 2009-01-15
WO2008063344A2 (en) 2008-05-29
CN101536455A (zh) 2009-09-16

Similar Documents

Publication Publication Date Title
US8914885B2 (en) Methods and apparatus for delivering control messages during a malicious attack in one or more packet networks
Iyengar et al. QUIC: A UDP-based multiplexed and secure transport
US9438592B1 (en) System and method for providing unified transport and security protocols
US9992222B2 (en) Systems and methods for inhibiting attacks with a network
US7940761B2 (en) Communication connection method, authentication method, server computer, client computer and program
US8499146B2 (en) Method and device for preventing network attacks
US7370354B2 (en) Method of remotely managing a firewall
US8800001B2 (en) Network authentication method, method for client to request authentication, client, and device
US8990573B2 (en) System and method for using variable security tag location in network communications
US7290281B1 (en) Method and apparatus for cryptographically blocking network denial of service attacks based on payload size
JP2006185194A (ja) サーバ装置、通信制御方法及びプログラム
JP4183664B2 (ja) 認証方法、サーバ計算機、クライアント計算機、および、プログラム
KR100856918B1 (ko) IPv6 기반 네트워크상에서의 IP 주소 인증 방법 및IPv6 기반 네트워크 시스템
Stewart et al. RFC 5061: Stream control transmission protocol (SCTP) dynamic address reconfiguration
JP2004363915A (ja) DoS攻撃対策システムおよび方法およびプログラム

Legal Events

Date Code Title Description
RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20120926

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130117

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130819

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130822

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20131122

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20131127

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140221

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140619

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20140919

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20140925

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20141219

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20150331