JP2014179993A - Ｄｎｓトップトーカのホワイトリスト化 - Google Patents

Abstract

【課題】ドメイン・ネーム・システムを利用した分散サービス妨害（ＤＤｏＳ）攻撃を軽減する。
【解決手段】ドメイン・ネームの解決を行うためのクエリをドメイン名サーバに送るリゾルバに対するリゾルバ・プロファイルを取得し、リゾルバが信頼できるかどうかを判定するために信頼ポリシーと比較を行って、信頼できると見なされたリゾルバを、信頼できるリゾルバのリストに追加生成し、信頼できるリゾルバのリスト上のリゾルバからのクエリのみに応答するようにする。
【選択図】図１

Description

（関連出願）
本出願は、２０１１年８月１１日に出願した米国仮出願第６１／５２２，４９３号明細書の優先権の利益を主張する２０１２年８月１０日に出願した「Ｗｈｉｔｅ Ｌｉｓｔｉｎｇ ＤＮＳ Ｔｏｐ−Ｔａｌｋｅｒｓ」という名称の米国特許出願第１３／５７２，１８５号明細書の一部継続出願であり、これらの出願は共に参照により本明細書に組み込まれる。

本開示は一般に、分散サービス妨害（ＤＤｏＳ）攻撃、詳細にはトップレベル・ドメイン名サーバを標的とするＤＤｏＳ攻撃、または第三者サーバに対する攻撃においてトップレベル・ドメイン名サーバを使用するＤＤｏＳ攻撃を検出し、対処するためのシステムおよび方法を対象とする。

ドメイン・ネーム・システム（ＤＮＳ）は、インターネットまたはその他のネットワークに接続された装置およびリソースのためのネーミング・システムである。ＤＮＳは覚えやすいドメイン名を数値的なＩＰアドレスに変換するために、「リゾルバ」およびドメイン名サーバを使用することによってネットワーク・ナビゲーションのユーザ利便性を改善する。例えばＤＮＳは、ｗｗｗ．ｖｅｒｉｓｉｇｎ．ｃｏｍなどのウェブサイトを、ＩＰｖ４アドレス、ＩＰｖ６アドレス、電子メールサービス、その他などを含む広範なデータに変換する。

ドメイン名はツリー状の階層型名前空間を形成する。ツリー内の各ノードはリーフノードを除いてドメインと呼ばれる。ツリーの頂点においてルートドメインは、「．ｃｏｍ」、「．ｎｅｔ」、「．ｏｒｇ」、および「．ｅｄｕ」などのトップレベル・ドメイン（ＴＬＤ）に権限を委譲する。次いでＴＬＤは、「ｃｏｌｏｓｔａｔｅ．ｅｄｕ」ドメイン、「ｖｅｒｉｓｉｇｎ．ｃｏｍ」ドメインなどの第２レベル・ドメイン（ＳＬＤ）を生成するように権限を委譲する。ドメイン・データベースを構成する情報の保管場所は、ゾーンと呼ばれる論理名前空間に分割される。各ゾーンは単一の管理権限に属し、１組の権限のあるネームサーバによってサービスされる。各ゾーンに対する複数のサーバは冗長性および耐障害性をもたらす。

「．ｃｏｍ」および、「．ｎｅｔ」などのＴＬＤは、ＤＮＳにおいて重要な役割を果たす。ポピュラーなＴＬＤは、ＤＮＳの名前空間のファンアウト（ｆａｎ−ｏｕｔ）のため、おそらくＤＮＳルートよりも重要である。例えばリゾルバがルートから、「．ｃｏｍ」の参照を知った後にその参照はキャッシュされ、リゾルバは、「．ｃｏｍ」アドレスに対するすべての後続のクエリを、「．ｃｏｍ」ＴＬＤネームサーバに送ることができる。キャッシュされた情報の期限が切れるまでは、リゾルバは再びルートに照会する必要がなくなる。しかし「ｖｅｒｉｓｉｇｎ．ｃｏｍ」などのあらゆる一意のＳＬＤは、最初に検索されるときには、「．ｃｏｍ」ＴＬＤネームサーバに送られなければならない。「．ｃｏｍ」および「．ｎｅｔ」の下には１億個を超えるゾーンが存在し、いずれの所与の時点においてもこれらのゾーンの一部分だけがキャッシュされる。したがってすべての「．ｃｏｍ」または、「．ｎｅｔ」ＴＬＤネームサーバの崩壊は、キャッシュされていないいずれのゾーンも到達不能にする。

ＴＬＤ攻撃を犯すことは、ＤＮＳ通信の性質により比較的容易である。すなわちＤＮＳ通信は、通常はユーザ・データグラム・プロトコル（ＵＤＰ）を通じて送られる。ＵＤＰは接続ハンドシェイク、肯定応答、順序付け、またはエラー訂正を有さずに小さなデータパケットを伝送するための簡単な通信プロトコルである。ＵＤＰは処理オーバヘッドが低いことにより、ビデオおよびボイス・オーバー・アイピーなどのストリーミング・メディア用途のために、およびＤＮＳ解決などの多くの発信元からの小さなクエリに答えるために有用である。残念ながらこれらの同じ特性により、攻撃者が不正目的のためにＤＮＳ解決を用いることが可能になる。ＵＤＰはコネクションレス型であるので、攻撃者は接続ハンドシェイクを完了することを気にする必要なく、発信元アドレスを「偽装」する（すなわち、ＤＮＳサーバがクエリ応答を第三者に送るように、ＩＰパケット内に偽の発信元ＩＰアドレスを偽造する）ことができ、結果としてＤＮＳサーバはクエリを送っていないマシンに応答を送るようになる。さらに、クエリ・メッセージは比較的小さい（５１２バイト未満）が、応答における多数のリソース・レコードにより結果としての応答は大幅に大きくなり得る。これは攻撃者がＤＮＳサーバを利用して攻撃を拡大することを可能にする。ＤＮＳクエリおよび応答はまた状態をもつ伝送制御プロトコル（ＴＣＰ）を通して送ることができ、ＴＣＰは同様な脆弱性を示し、これも本明細書に開示される本発明の実施形態を用いて処理することができる。

一部の攻撃はＴＬＤ自体を標的とする。例えば「機能停止」攻撃は、ＴＬＤに打撃を加えてオフラインにする、または正規のクエリに応答できなくなる程度まで圧倒する目的で、ＴＬＤをクエリで溢れさせる。

他の攻撃は、ＴＬＤを用いて、第三者サーバに向けて攻撃トラフィックを増殖させる。例えば「反射器型」攻撃では、攻撃者は、（１つまたは複数の）偽造した発信元アドレスを用いて複数のＤＮＳクエリを発行し、ＴＬＤにすべての応答を罪のない被害者に向けて発行させ、被害者のホストサーバを圧倒する。

第３のタイプの攻撃は、多くがすべて同じＳＬＤの参照を要求するときに起きる。攻撃者は、ＴＬＤに先制的にサブドメイン全体をブラックリストに載せることにより自己防衛をするように促そうとする。あるいは攻撃者は単に、各攻撃パケットのクエリ名全体をわざわざランダム化しない場合もある。

集合的にこれらの攻撃は、その目的は標的とするサーバに打撃を加えてオフラインにし、結果としてサーバは正規の顧客にサービスできなくなるので、分散サービス妨害（ＤＤｏＳ）攻撃と呼ばれる。

実装形態では、コンピュータを利用して実現される、信頼できるＤＮＳリゾルバのリストを生成するための方法が開示される。方法は、コンピュータにおいて、リゾルバのトップトーカ・ステータス、照会されるドメイン名の分布の正常性、クエリタイプの分布の連続性、ＲＤビットステータス、および分散されたドメイン名サーバのトポロジ内の１つまたは複数のノードにおけるクエリ・トラフィックに関する情報のいずれか、または組み合わせに基づく、リゾルバがクエリをドメイン名サーバに送るためのリゾルバ・プロファイルを受信するステップと、リゾルバが信頼できるかどうかを判定するために、リゾルバ・プロファイルにポリシーを適用するステップと、リゾルバが信頼できると判定された場合に、コンピュータによって、リゾルバを信頼できるリゾルバのリストに追加するステップとを含むことができる。

実装形態では、受信するステップは、リゾルバからのクエリのＩＰ有効期間の分散の連続性に基づくリゾルバ・プロファイルを受信するステップを含むことができる。

実装形態では、方法は、リゾルバ・プロファイルが信頼できると判定されなかった場合は、攻撃状態の表示を発生するステップを含むことができる。

実装形態では、方法は、対応するリゾルバ・プロファイルが信頼できると判定されなかった場合は、リゾルバからのクエリを阻止するステップを含むことができる。

実装形態では、受信するステップは、トップレベル・ドメイン名サーバにクエリを送るリゾルバに対するプロファイルを受信するステップを含むことができる。

実装形態では、リゾルバ・プロファイルは、各プロファイル特性に対して１つの要素を含む配列を含むことができ、要素は、プロファイル特性が正常または異常であることを表す２進値を含むことができる。

実装形態では、ポリシーを適用するステップは、各プロファイル特性に対して１つの要素を含む１つまたは複数の配列を含むポリシーを適用するステップを含むことができ、要素は、正常または異常なプロファイル特性を表す２進値であり、リゾルバを追加するステップは、そのプロファイルが予め設定されたポリシー配列の１つと一致した場合は、リゾルバを信頼できるリゾルバのリストに追加するステップを含む。

実装形態では、信頼できるＤＮＳリゾルバのリストを生成するためのシステムが開示される。システムは、１つまたは複数のプロセッサを備える処理システムと、ネットワーク接続された装置から通信を受信し、ネットワーク接続された装置に通信を送信するための通信ポートと、命令を記憶したメモリとを備える。メモリには、命令が処理システムによって実行されたときに、コンピュータにおいて、リゾルバのトップトーカ・ステータス、照会されるドメイン名の分布の正常性、またはクエリタイプの分布の連続性、ＲＤビットステータス、および分散されたドメイン名サーバのトポロジ内の１つまたは複数のノードにおけるクエリ・トラフィックに関する情報のいずれか、または組み合わせに基づく、リゾルバがクエリをドメイン名サーバに送るためのリゾルバ・プロファイルを受信するステップと、リゾルバが信頼できるかどうかを判定するために、リゾルバ・プロファイルにポリシーを適用するステップと、リゾルバが信頼できると判定された場合に、コンピュータにより、リゾルバを信頼できるリゾルバのリストに追加するステップとからなる動作をシステムに行わせるための命令が格納されている。

実装形態では、受信するステップは、リゾルバからのクエリのＩＰ有効期間の分散の連続性に基づくリゾルバ・プロファイルを受け取るステップを含むことができる。

実装形態では、動作は、リゾルバ・プロファイルが信頼できると判定されなかった場合は、攻撃状態の表示を発生するステップを含むことができる。

実装形態では、動作は、対応するリゾルバ・プロファイルが信頼できると判定されなかった場合は、リゾルバからのクエリを阻止するステップを含むことができる。

実装形態では、受信するステップは、トップレベル・ドメイン名サーバにクエリを送るリゾルバに対するプロファイルを受信するステップを含むことができる。

実装形態では、リゾルバ・プロファイルは、各プロファイル特性に対して１つの要素を含む配列を含むことができ、要素は、プロファイル特性が正常または異常であることを表す２進値を含むことができる。

実装形態では、ポリシーを適用するステップは、各プロファイル特性に対して１つの要素を含む１つまたは複数の配列を含むポリシーを適用するステップを含むことができ、要素は、正常または異常なプロファイル特性を示す２進値であり、リゾルバを追加するステップは、そのプロファイルが予め設定されたポリシー配列の１つと一致した場合に、リゾルバを信頼できるリゾルバのリストに追加するステップを含むことができる。

実装形態では、コンピュータを利用して実現される、信頼できるＤＮＳリゾルバのリストを生成するための方法が開示される。方法は、コンピュータにおいて、リゾルバのトップトーカ・ステータス、照会されるドメイン名の分布の正常性、クエリタイプの分布の連続性、ＲＤビットステータス、および分散されたドメイン名サーバのトポロジ内の１つまたは複数のノードにおけるクエリ・トラフィックに関する情報のいずれか、または組み合わせに基づく、リゾルバがクエリをドメイン名サーバに送るためのリゾルバ・プロファイルを受信するステップと、リゾルバが信頼できるかどうかを判定するために、リゾルバ・プロファイルにポリシーを適用するステップと、コンピュータによって、リゾルバが信頼できると判定された場合に、リゾルバを信頼できるリゾルバのリストに追加するステップとを含むことができる。

実装形態では、受信するステップは、リゾルバからのクエリのＩＰ有効期間の分散の連続性に基づくリゾルバ・プロファイルを受け取るステップを含むことができる。

実装形態では、方法は、リゾルバ・プロファイルが信頼できると見なされなかった場合は、攻撃状態の表示を発生するステップを含むことができる。

実装形態では、方法は、対応するリゾルバ・プロファイルが信頼できると判定されなかった場合は、リゾルバからのクエリを阻止するステップを含むことができる。

実装形態では、受信するステップは、トップレベル・ドメイン名サーバにクエリを送るリゾルバに対するプロファイルを受信するステップを含むことができる。

実装形態では、リゾルバ・プロファイルは、各プロファイル特性に対して１つの要素を含む配列を含むことができ、要素は、プロファイル特性が正常または異常であることを表す２進値である。

実装形態では、ポリシーを適用するステップは、各プロファイル特性に対して１つの要素を含む１つまたは複数の配列を含むポリシーを適用するステップを含むことができ、要素は、正常または異常なプロファイル特性を表す２進値であり、リゾルバを追加するステップは、そのプロファイルが予め設定されたポリシー配列の１つと一致した場合は、リゾルバを信頼できるリゾルバのリストに追加するステップを含む。

実装形態では、信頼できるＤＮＳリゾルバのリストを生成するためのシステムが開示される。システムは、１つまたは複数のプロセッサを備える処理システムと、ネットワーク接続された装置から通信を受信し、ネットワーク接続された装置に通信を送信するための通信ポートと、命令を記憶したメモリとを備える。メモリには、命令は処理システムによって実行されたときに、コンピュータにおいて、リゾルバのトップトーカ・ステータス、照会されるドメイン名の分布の正常性、クエリタイプの分布の連続性、ＲＤビットステータス、および分散されたドメイン名サーバのトポロジ内の１つまたは複数のノードにおけるクエリ・トラフィックに関する情報のいずれか、または組み合わせに基づく、リゾルバがクエリをドメイン名サーバに送るためのリゾルバ・プロファイルを受け取るステップと、リゾルバが信頼できるかどうかを判定するために、リゾルバ・プロファイルにポリシーを適用するステップと、リゾルバが信頼できると判定された場合に、コンピュータにより、リゾルバを信頼できるリゾルバのリストに追加するステップとからなる動作をシステムに行わせるための命令が格納されている。

実装形態では、受信するステップは、リゾルバからのクエリのＩＰ有効期間の分散の連続性に基づくリゾルバ・プロファイルを受け取るステップを含むことができる。

実装形態では、動作は、リゾルバ・プロファイルが信頼できると判定されなかった場合は、攻撃状態の表示を発生するステップを含むことができる。

実装形態では、動作は、対応するリゾルバ・プロファイルが信頼できると判定されなかった場合は、リゾルバからのクエリを阻止するステップを含むことができる。

実装形態では、受信するステップは、トップレベル・ドメイン名サーバにクエリを送るリゾルバに対するプロファイルを受信するステップを含むことができる。

実装形態では、リゾルバ・プロファイルは、各プロファイル特性に対して１つの要素を含む配列を含むことができ、要素は、プロファイル特性が正常または異常であることを表す２進値を含む。

実装形態では、ポリシーを適用するステップは、各プロファイル特性に対して１つの要素を含む１つまたは複数の配列を含むポリシーを適用するステップを含むことができ、要素は、正常または異常なプロファイル特性を示す２進値であり、リゾルバを追加することは、そのプロファイルが予め設定されたポリシー配列の１つと一致した場合は、リゾルバを信頼できるリゾルバのリストに追加するステップを含む。

本明細書に組み込まれ、その一部を構成する添付の図面は、様々な実施形態を示し、説明と共に実施形態の原理を説明するために役立つ。

ＤＮＳシステムにおけるドメイン名サーバの図である。 ＤＮＳシステムにおけるエンドユーザ、リゾルバ、およびドメイン名サーバの間の通信を示す図である。 すべての発信元およびトップトーカに対するクエリタイプ分布のヒストグラムである。 正常なトラフィックと攻撃イベントとでクエリタイプ分布を比較したヒストグラムである。 正常なトラフィックの１０分間にわたるすべての発信元に対するクエリ名分布のヒストグラムである。 攻撃時のクエリ名分布のヒストグラムである。 クエリ特性を分析し、リゾルバ・プロファイルを構築し、信頼されるリゾルバの「ホワイトリスト」を生成する方法のフローチャートである。 総トラフィックを分析して攻撃が起きているかどうかを判定する方法のフローチャートである。 本教示の態様による、世界中の複数のノード・サイトにおけるトラフィックを追跡するように動作可能なモニタの例示の地理的な表示を示す図である。

以下の詳細な説明は、添付の図面を参照する。可能な限り図面および以下の説明では、同じ参照番号が同じまたは同様な部分を指すために用いられる。本明細書ではいくつかの例示的実施形態および特徴が述べられるが、本発明の趣旨および範囲から逸脱せずに変更、適合化、および他の実装形態が可能である。したがって以下の詳細な説明は、本発明を限定するものではない。代わりに本発明の適切な範囲は添付の特許請求の範囲によって定義される。

図１はＤＮＳにおけるドメイン名サーバの図である。ＤＮＳネームサーバ１００は、１つまたは複数のプロセッサ１１０、インターネット１５０を通じて１つまたは複数のネットワーク接続された装置と通信するための通信ポート１２０、以下で述べられる動作をシステムに行わせるための命令を記憶するためのコンピュータメモリ１３０、およびドメイン名およびＩＰアドレス情報を記憶したデータベースのためのコンピュータメモリ１４０を備える。いくつかの実施形態では命令を含んだコンピュータメモリ１３０と、ドメイン名およびＩＰアドレス情報を含んだコンピュータメモリ１４０とは、単一のコンピュータメモリに組み合わせることができる。

図２は、ＤＮＳシステム２００におけるエンドユーザ、リゾルバ、およびドメイン名サーバの間の通信を示す図である。スマートフォン２０５またはデスクトップコンピュータ２１０などのエンドユーザは、ローカル・リゾルバ２１５と通信する。ローカル・リゾルバ２１５は、ルートサーバ２２０、ＴＬＤネームサーバ２２５、およびゾーン名サーバ２３０と通信することによってドメイン名をＩＰアドレスと突き合わせる。リゾルバ２１５はドメインに対するＩＰアドレス情報を受け取った後に、一時的にその情報をそれ自体のサーバに記憶する。その理由からローカル・リゾルバ２１５は、時には「キャッシュ」リゾルバと呼ばれる。

エンドユーザ２０５がウェブサイトを閲覧するためにドメイン名を入力したときは、エンドユーザ２０５はドメイン名をリゾルバ２１５に送信する。次いでリゾルバは、ドメイン名全体が解決されるまで、ルートサーバ２２０から始めて、ＴＬＤネームサーバ２２５、ゾーン名サーバ２３０など、続けてネームサーバに照会する。

各クエリはその中に、そのクエリを送ったリゾルバのプロファイルを構築するために用いることができるいくつかの特性を含んでいる。それらの特性はまた、時間にわたる総トラフィックのプロファイルを構築するために用いることができる。以下で詳しく述べられるこれらの特性は、リゾルバの「トップトーカ」ステータス、個々のリゾルバからのクエリの間でのＩＰ有効期間（ＴＴＬ）の分散、クエリタイプ分布、クエリ名分布、再帰要求（ＲＤ）ビットステータス、および（１つまたは複数の）ネットワークのトポロジに基づくクエリ・トラフィックに関する情報を含む。開示される実施形態は、個々のリゾルバのクエリ・プロファイル、または総トラフィックにおける変化を検出することによってＤＤｏＳ攻撃を検出することができる。開示される実施形態はまたドメイン名サーバにおいて、悪意があると推定されるクエリを阻止するまたは無視することによって攻撃を軽減することができる。

トップトーカ・ステータス。トップトーカは最も活動的なリゾルバである。一実施形態ではトップトーカは、総計でクエリ・トラフィックの９０％を占める最も大きなリゾルバとして定義される。一般に、トップトーカ・リストは比較的少数のリゾルバからなる。例えば、ある期間にわたって数百万台のリゾルバがＴＬＤを照会する場合は、それらのうちのわずか４万台が全トラフィックの９０％に関与し得る。しかしトップトーカのリストは動的なものであり、それぞれの特定のＴＬＤネームサーバに対するそれらのそれぞれのクエリ量が変化するのに従って、新しいリゾルバが既存のものを置き換える。一実施形態ではトップトーカ・リストはローリング・ベースで更新される。他の実施形態ではトップトーカ・リストは様々な間隔で更新することができる。

ＩＰ ＴＴＬ分散。ＩＰ ＴＴＬは、パケットがルータを通過するたびにデクリメントするＩＰパケット内のカウンタである。カウンタがゼロに達するとパケットは廃棄される。この機構はＩＰパケットがインターネットシステム内を際限なく循環することを防止する。したがってＴＴＬ分散は、ルータの中継でカウントした、ＩＰパケットが移動した距離の相対的な尺度である。

所与の静的なネットワーク条件ならびに固定の発信元および送信先に対して、送信先において観察されるパケットのＩＰ ＴＴＬは、それらは同じルートを移動することが推定されるので、変化するとしても変化はわずかである。ＤＮＳクエリのためにＵＤＰを用いると、攻撃者によるアドレスの偽装は些細なことになるが、偽装されたアドレスからのＴＴＬは、実際のアドレスからのＩＰパケット内のＴＴＬとは不一致となり得る。したがって重要な正規のＤＮＳキャッシュ・リゾルバは非常に小さなＴＴＬ分散を示すが、偽装を伴う攻撃は高い分散を生じる傾向がある。

任意の所与の時点における単一の発信元からのパケットのＴＴＬ分散は、攻撃者が発信元アドレスを偽装していることを最も確実に示すものではない。むしろ分散の増加が、発信元に関係するＩＰレベルの変化を示すものである。ＩＰ ＴＴＬ分散の増加に対する１つの説明は、攻撃者が、現在活動しているまたは前にプロファイルされたアドレスを偽装していることである。この場合は、偽装されたＩＰパケットがＤＮＳネームサーバに到着したときには、偽装されたパケットが移動した経路は、真の発信元からのパケットが移動する経路とは異なることになる。さらに偽装されたアドレスを用いてクエリを送る複数の発信元がある場合は、それらのそれぞれのパケットも異なる経路を移動することになり、さらに大きなＴＴＬ分散に寄与する。

クエリタイプ・プロファイリング。リゾルバはいくつかの異なるタイプのクエリをＤＮＳサーバに送る。図３は非攻撃期間にわたる典型的なクエリタイプの分布を示す。図は、ＩＰｖ４アドレスに対するクエリ（タイプＡ）３１０が明らかに優位を占めることを示す。ＩＰｖ６アドレス（タイプＡＡＡＡ）３２０が次に最もポピュラーな要求されるタイプであり、メールサーバ（タイプＭＸ）３３０レコードより頻繁に要求される。ＤＮＳＳＥＣレコードタイプ、サービスロケーションレコードタイプ、さらには旧式のＡ６レコードを含む他の正規のクエリタイプ３４０が観察されるが、これらはクエリ・トラフィックのわずかな部分を構成するのみである。実装形態では非限定的に、ウェブトラフィック、ＤＮＳトラフィック、データベース・トラフィック、およびデジタル電話コールに関係するトラフィックに関係するトランザクションを含む、他のクエリまたはトランザクションタイプが観察され得る。

図３はまた、トップトーカに対するクエリタイプ分布は、すべてのトラフィックに対するものとおよそ同じであることを示す。これはＴＬＤネームサーバ２２５が、正常な挙動を比較的少数のリゾルバを用いて定量化することを可能にする。

攻撃イベントは、１つのタイプのクエリの過多によってクエリタイプ分布を歪ませ得る。図４は、正常なトラフィックのクエリタイプ分布と、攻撃イベント時のトラフィックとを比較している。リゾルバは通常は７０％のタイプＡクエリ４１０、２０％のタイプＡＡＡＡクエリ４２０、および１０％のタイプＭＸクエリ４３０を送ることが分かる。攻撃時にこれは、９０％のタイプＡクエリ４１０、５％のタイプＡＡＡＡクエリ４２０、および４％のタイプＭＸクエリ４３０に変化する。

一実施形態では、３つの最もポピュラーなクエリタイプのいずれかが、全体のクエリ・トラフィック内のその比率を少なくとも一定の係数だけ変化させた場合に、前のクエリタイプ分布からの偏移は「有意」であると見なす。例えば７０％から９０％へのタイプＡクエリの変化は有意と認められない場合もあるが、タイプＡＡＡＡクエリの比率はこの機能を始動するのに十分な顕著な対応する低下を有することになる。一実施形態ではこのクエリタイプの変則性検出は、単一の発信元からのクエリに対して適用することができる。他の実施形態ではこのクエリタイプの変則性検出は、総クエリ・トラフィックに適用することができる。

クエリ名プロファイリング。クエリタイプのプロファイルと異なり、クエリ名プロファイルは、膨大な数の可能性のある名前に対処しなければならない。可能性のあるクエリタイプは数百しかなく、データではそれらのうちのわずか３つだけが、クエリのかなりのパーセンテージに寄与することが示された。これと対照的に、可能性のあるクエリ名は数千万存在する。いくつかの正規の繁忙な発信元は、２〜３日の間だけで数百万の名前に対してクエリを発行することができる。さらにいくつかの悪意のある発信元は、これだけ多くのクエリを１分未満で発行することができる。

再帰要求（ＲＤ）ビットステータス。ＲＤビットはクエリ内でセットすることができ、応答内にコピーされる。ＲＤビットがセットされている場合は、ネームサーバはクエリを再帰的に追求するように指示される。再帰クエリのサポートはオプションであり、通常は再帰が望まれない場合は０にセットされ、再帰が望まれる場合は１にセットされる。実装形態では、ＲＤビットがセットされているかどうかの判定を行うことができ、この判定に応答して、要求者から送られたクエリが正常な、有効な、および／または正規のクエリであるかどうかに応じて処置をとることができる。例えば履歴データ、または履歴データにおける傾向を、特定の要求者に対するＲＤビットステータスに関係する正常な活動の一時的なベースラインをもたらすために用いることができる。ＲＤビットステータスに関する変則的な特性を有する、普通でないおよび／または予期しないクエリを受け取った場合は、要求者をホワイトリストから除去するまたはホワイトリストに含めないなどの処置をとることができる。実装形態ではＲＤビットステータスは、すべての要求者からのすべてのトラフィックに対して、またはトップトーカ・ステータスを有するものなどの、選択された要求者からの選択されたトラフィックに対して監視することができる。

ネットワーク・トポロジに基づくクエリ・トラフィックに関する情報。様々な要求者およびプロバイダのトポロジの全体にわたるクエリ・トラフィックに関する情報は、部分的に、どこで特定のエンティティが直接または間接にＤＤｏＳ攻撃に関わっているかを判断するために用いることができる。実装形態では、ネットワーク環境を有するノードによって収集された情報は測定され、総計され、例えば毎日または毎週の時間に対する傾向を求めるために比較される。例えばネットワーク内の特定のノードは、周期的に特定の要求者からクエリを受け取り得る。予期せずに特定のノード、および／または別のノード例えば隣接のノードが、予期しない並行した、または同時の、または実質的に同時の要求を特定の要求者から受け取った場合は、部分的に、特定の要求者を潜在的に変則的なまたは悪意のある要求者としてラベル付けするために、要求の送信先の変更を用いることができる。要求者をホワイトリストから除去するまたはホワイトリストに含めないなどの処置をとることができる。実装形態では、ネットワーク・トポロジに基づくクエリ・トラフィックに関する情報は、すべての要求者からのすべてのトラフィックに対して、またはトップトーカ・ステータスを有するものなどの、選択された要求者からの選択されたトラフィックに対して監視することができる。

図５は、１０分間だけの間にすべての発信元にわたって見られたＳＬＤ名の相対的なポピュラリティを示す。図５は１０個より少ないＳＬＤが、１万回より多く照会されたことを示す（点５１０）。１万個未満のＳＬＤが１００回より多く照会された（点５２０）。クエリ名空間の全体の大きさは、非常に長い期間の間プロファイリングすることが難しくなり得る空間的な複雑さを表している。これは大きなリゾルバはわずか数分で数万個のＳＬＤ要求を容易に送ることができるからである。したがってクエリ名測定の期間は、比較的短い持続時間に上限が定められる。このような短い期間は、リゾルバが照会する傾向のあるＳＬＤの分布のプロファイリングには適さない。しかし、トップトーカ（またはいずれかの繁忙なリゾルバ）が不相応な数のクエリを特定のＳＬＤに送っている場合を観察することが可能になる。常態では、リゾルバは、そのＩＰアドレスをキャッシュし、他のクエリをリゾルバ自体のサーバに送る前では、特定のＳＬＤに対して非常に少数の並行したクエリを送るべきである。したがって１つまたは複数のＳＬＤの頻度の急上昇は、攻撃を表すことができる。

図６は、攻撃イベント時のドメイン名分布を示す。攻撃者がゾーンを標的とする攻撃を開始した場合は、ＳＬＤ（［ＳＬＤ］．ｃｏｍ）はすべての攻撃クエリに共通となる。あるいは攻撃者は照会されるＳＬＤを単にわざわざランダム化しない場合もある。いずれの場合もクエリ名分布はクエリ名６１０において急上昇を示す。

ホワイトリストを生成する。図７は、本発明の一実施形態による、信頼されるリゾルバのホワイトリストを発生する方法を示すフローチャートである。リゾルバからのクエリ（７０５）は、いくつかの特性のステータスを判断するために分析される。これらの特性は、リゾルバがトップトーカであるかどうか（７１０）、リゾルバからのクエリのＩＰ ＴＴＬ分散が突然増加したか（７１５）、クエリタイプ・プロファイルが実質的な変化を受けたか（７２０）、クエリ名プロファイルが特定のＳＬＤの頻度の突然の急増を示すか（７２５）、ＲＤビットステータス（７２７）、およびトポロジに基づくクエリ・トラフィックに関する情報（７２９）の、１つまたは複数を含むことができる。これらの特性の１つまたは複数のステータスは、リゾルバ・プロファイルを構築（７３０）するために用いることができる。一実施形態ではリゾルバ・プロファイル（７３０）は、＜トップトーカ，ＩＰ ＴＴＬ，クエリタイプ，クエリ名，ＲＤビットステータス，トポロジ情報に基づくクエリ・トラフィック＞の形の、２進数の６個の組からなる。最初の位置における「１」は非トップトーカを示す。他の位置のいずれかにおける「１」はその特性が変則的であることを示す。例えば、＜０，１，０，０，０，０＞のプロファイルは、ＴＴＬ分散の増加を示すトップトーカである。

リゾルバ・プロファイル（７３０）は、次に信頼ポリシー（７３５）と比較される。信頼ポリシー（７３５）は、ＴＬＤが信頼できると見なした、したがってホワイトリストに割り当てる異なるリゾルバ・プロファイルからなる。例えば信頼ポリシーは、［＜０，０，０，０，０，０＞ ＜１，０，０，０，０，０＞ ＜０，１，０，０，０，０＞］と似たものとすることができる。このポリシーはすべての他の挙動が正常である限り、トップトーカと非トップトーカ・リゾルバの両方をホワイトリストに割り当てることになる。このポリシーはまた、トップトーカ・リゾルバがＩＰ ＴＴＬ分散を生じた場合でもトップトーカ・リゾルバをホワイトリストに割り当てる。ポリシーは静的である必要はなく、実際、条件が変化するのに従って任意の時点で変更することができる。一実施形態では、信頼できると見なされていないプロファイルを有する１つまたは複数のリゾルバを検出したことは、攻撃イベントが起きていることを示す。

ＴＬＤネームサーバは、いくつかのリゾルバが、信頼できるとは見なされずしたがってホワイトリストに割り当てられていないプロファイルを有する場合でも、すべてのクエリに応答し続けることができる。同様にネームサーバは、攻撃が進行中であると判断した後でも、すべてのクエリに応答し続けることができる。しかし攻撃が十分に深刻である場合は、ネームサーバはホワイトリスト・モードに移行することを選ぶことができる（７５５）。ホワイトリスト・モードではネームサーバは、ホワイトリスト上にないリゾルバからのクエリを無視（７６０）しながら、ホワイトリスト上のリゾルバからのクエリのみに対して応答する（７５０）。

攻撃を検出する。図８は、他の実施形態による、ネームサーバにおいてＤＤｏＳ攻撃を検出する方法のフローチャートである。この実施形態では、ＤＮＳネームサーバは総トラフィックのクエリ特性を監視し、発信元ごとのＩＰ ＴＴＬ分散（８１５）、クエリタイプ分布（８２０）、クエリ名分布（８２５）、ＲＤビットステータス（８２７）、トポロジ情報に基づくクエリ・トラフィック（８２９）などの、クエリ特性における変化を検出する。一実施形態では、総トラフィックの１つまたは複数のクエリ特性における変則的挙動を検出したことは、攻撃が起きていることを示す（８４０）。ＴＬＤネームサーバは、ネームサーバに攻撃が起きていると判定（８４０）した場合でも、すべてのクエリに応答（８５０）し続けることができる。しかし攻撃が十分に深刻である場合は、ネームサーバはホワイトリスト・モードに移行することを選ぶことができる（８５５）。ホワイトリスト・モードではネームサーバは、ホワイトリスト上にないリゾルバからのクエリを無視（８６０）しながら、ホワイトリスト上のリゾルバからのクエリのみに対して応答する（８５０）。

図９は、世界中の複数のノード・サイトにおけるトラフィックを追跡するように動作可能なモニタの例示の地理的な表示を示す。実装形態ではモニタ、例えばモニタ９０５、９１０、９１５、９２０、９２５、９３０、９３５、９４０、９４５、および９５０は、要求者からの、例えば非限定的に１つまたは複数のノードと通信しているＤＮＳクエリ発信元からの、トラフィックを見張りまたは監視し、要求者に対するプロファイルを構築し、モニタが注目するまたは監視する発信元についての統計を追跡し分析するように動作可能である。図９に示される数のモニタは単に例示の構成である。より多いまたは少ない数のモニタを用いることもできる。１つまたは複数の地理的な領域にわたるモニタの分散された展開またはトポロジによって、各個別のモニタは、要求者の変則的または疑わしい挙動を識別するために用いることができるクエリ・トラフィック・データを監視し供給することを受け持つことができる。例えばプロファイルは発信元ごとまたはサイトごとに構築することができ、例えば以下の１つまたは複数などの、上述のものを含む属性を含むことができる：トップトーカ・ステータス、リゾルバからのクエリのＩＰ ＴＴＬ分散、クエリタイプ、クエリ名、ＲＤビットステータス、トポロジに基づくクエリ・トラフィックに関する情報など。いくつかの実装形態では、モニタの処理時間またはサイクル、エネルギー消費、および記憶の負荷量を低減するために、トップトーカからのこれらの属性のみが追跡される。

発信元ごとの統計から、モニタはサイトのそれぞれに対する総計の観察をもたらすことができ、次いでさらに各サイトを世界的な観察に総計することができる。結果としてトポロジ全体にわたる、および複数のサイトにわたる傾向を判断することができ、いくつかの実施形態では是正処置を開始することができる。さらに１つまたは複数地理的な領域にわたるモニタの分散的な性質、および複数のモニタからのデータを総計する能力のため、１つまたは複数の個々のノードにおける疑わしいまたは潜在的に疑わしい挙動を識別することができる。例えばモニタ９３０および９３５において変則的または潜在的に疑わしいトラフィックが現れ始めたが、他の場所では現れない場合は、米国東部を中心とした要求者からのトラフィックは、他のトラフィックより精密な調査を行う正当な理由となり得る。

さらに現在のデータの傾向は履歴データの傾向と比較することができるため、すべてのトラフィックを中断する、より挑戦的な手法とは対照的に、正規のトラフィックに深刻な影響を及ぼさずにトラフィックを攻撃前の状態に正常化することができる。例えば要求者の攻撃前の状態は、非限定的に特定の時間間隔にわたるネットワーク活動、ネットワーク内の１つまたは複数のノードの間でのネットワーク活動などを含む、所定の期間にわたる要求者の挙動および／またはトラフィックの動的に導出されたフィンガープリントまたは識別子を含むことができる。追加としてまたは代替としてトラフィックは、要求者の攻撃前の状態またはフィンガープリントを含む、この全体的なトポロジをベースとする手法を用いることによって、１つまたは複数の特定のサイトおよび／または要求者に基づいてレート制限することができ、より制御された効率的な応答が可能になる。例えばレート制限は、データおよび／または上述のような６個の組に含まれた属性に基づく攻撃前の状態またはフィンガープリントを用いることができる。いくつかの実装形態では、履歴上のデータおよび／またはトポロジのデータを用いて可能性のある攻撃を、損害を最小にできる初期の時点で検出することにより、改善された結果をもたらすように機械学習の手法を用いることができる。

上記の説明は、その関連する実施形態と共に、例示のためにのみ提示されたものである。これは網羅的ではなく、本発明を開示された正確な形に限定するものではない。当業者は上記の説明から、変更および変形が上記の教示に照らして可能であり、または本発明の実施から得られることが理解されるであろう。例えば４つのプロファイル特性が述べられたが、実際的な実施形態は、より少ない特性またはより多い特性を使用してホワイトリストを発生することができる。述べられたステップは論じられたものと同じ順序で、または同じ程度の分離度を有して行う必要はない。同様に様々なステップは、同じまたは同様な目的を達成するために必要に応じて省略する、反復する、または組み合わせることができる。したがって本発明は上述の実施形態に限定されるものではなく、等価物の完全な範囲に照らして添付の特許請求の範囲によって定義される。

Claims (28)

1. コンピュータを利用して実現される、信頼できるＤＮＳリゾルバのリストを生成するための方法であって、
   コンピュータにおいて、リゾルバのトップトーカ・ステータス、照会されるドメイン名の分布の正常性、クエリタイプの分布の連続性、ＲＤビットステータス、および分散されたドメイン名サーバのトポロジ内の１つまたは複数のノードにおけるクエリ・トラフィックに関する情報のいずれか、または組み合わせに基づく、前記リゾルバがクエリをドメイン名サーバに送るためのリゾルバ・プロファイルを受信するステップと、
   前記リゾルバが信頼できるかどうかを判定するために、前記リゾルバ・プロファイルにポリシーを適用するステップと、
   前記リゾルバが信頼できると判定された場合に、前記コンピュータによって、前記リゾルバを信頼できるリゾルバのリストに追加するステップと
   を含む方法。
2. 前記受信するステップが、前記リゾルバからのクエリのＩＰ有効期間の分散の連続性に基づくリゾルバ・プロファイルを受信するステップを含む請求項１に記載の方法。
3. 前記リゾルバ・プロファイルが信頼できると判定されなかった場合に、攻撃状態の表示を発生するステップを含む請求項１に記載の方法。
4. 前記対応するリゾルバ・プロファイルが信頼できると判定されなかった場合に、リゾルバからのクエリを阻止するステップを含む請求項１に記載の方法。
5. 前記受信するステップが、トップレベル・ドメイン名サーバにクエリを送るリゾルバに対するプロファイルを受信するステップを含む請求項１に記載の方法。
6. 前記リゾルバ・プロファイルは、各プロファイル特性に対して１つの要素を含む配列を含み、
   前記要素は、プロファイル特性が正常または異常であることを表す２進値を含む請求項１に記載の方法。
7. 前記ポリシーを適用するステップは、各プロファイル特性に対して１つの要素を含む１つまたは複数の配列を含むポリシーを適用するステップを含み、
   前記要素は、正常または異常なプロファイル特性を表す２進値であり、
   前記リゾルバを追加するステップは、そのプロファイルが前記予め設定されたポリシー配列の１つと一致した場合は、前記リゾルバを前記信頼できるリゾルバのリストに追加するステップを含む請求項１に記載の方法。
8. 信頼できるＤＮＳリゾルバのリストを生成するためのシステムであって、
   １つまたは複数のプロセッサを備える処理システムと、
   ネットワーク接続された装置から通信を受信し、前記ネットワーク接続された装置に通信を送信するための通信ポートと、
   命令を記憶したメモリと
   を備え、
   前記メモリには、前記命令が前記処理システムによって実行されたときに、
   コンピュータにおいて、リゾルバのトップトーカ・ステータス、照会されるドメイン名の分布の正常性、またはクエリタイプの分布の連続性、ＲＤビットステータス、および分散されたドメイン名サーバのトポロジ内の１つまたは複数のノードにおけるクエリ・トラフィックに関する情報のいずれか、または組み合わせに基づく、前記リゾルバがクエリをドメイン名サーバに送るためのリゾルバ・プロファイルを受信するステップと、
   前記リゾルバが信頼できるかどうかを判定するために、前記リゾルバ・プロファイルにポリシーを適用するステップと、
   前記リゾルバが信頼できると判定された場合に、前記コンピュータによって、前記リゾルバを信頼できるリゾルバのリストに追加するステップと
   からなる動作を前記処理システムに行わせるための命令が格納されているシステム。
9. 前記受信するステップは、前記リゾルバからのクエリのＩＰ有効期間の分散の連続性に基づくリゾルバ・プロファイルを受信するステップを含む請求項８に記載のシステム。
10. 前記動作は、前記リゾルバ・プロファイルが信頼できると判定されなかった場合に、攻撃状態の表示を発生するステップを含む請求項８に記載のシステム。
11. 前記動作は、前記対応するリゾルバ・プロファイルが信頼できると判定されなかった場合に、前記リゾルバからのクエリを阻止するステップを含む請求項８に記載のシステム。
12. 前記受信するステップは、トップレベル・ドメイン名サーバにクエリを送るリゾルバに対するプロファイルを受信するステップを含む請求項８に記載のシステム。
13. 前記リゾルバ・プロファイルは、各プロファイル特性に対して１つの要素を含む配列を含み、
    前記要素は、プロファイル特性が正常または異常であることを表す２進値を含む
    請求項８に記載のシステム。
14. 前記ポリシーを適用するステップは、各プロファイル特性に対して１つの要素を含む１つまたは複数の配列を含むポリシーを適用するステップを含み、
    前記要素は、正常または異常なプロファイル特性を示す２進値であり、
    前記リゾルバを追加するステップは、そのプロファイルが前記予め設定されたポリシー配列の１つと一致した場合に、前記リゾルバを前記信頼できるリゾルバのリストに追加するステップを含む請求項８に記載のシステム。
15. コンピュータを利用して実現される、信頼できるＤＮＳリゾルバのリストを生成するための方法であって、
    コンピュータにおいて、リゾルバのトップトーカ・ステータス、照会されるドメイン名の分布の正常性、クエリタイプの分布の連続性、ＲＤビットステータス、および分散されたドメイン名サーバのトポロジ内の１つまたは複数のノードにおけるクエリ・トラフィックに関する情報のいずれか、または組み合わせに基づく、前記リゾルバがクエリをドメイン名サーバに送るためのリゾルバ・プロファイルを受信するステップと、
    前記リゾルバが信頼できるかどうかを判定するために、前記リゾルバ・プロファイルにポリシーを適用するステップと、
    前記リゾルバが信頼できると判定された場合に、前記コンピュータによって、前記リゾルバを信頼できるリゾルバのリストに追加するステップと
    を含む方法。
16. 前記受信するステップが、前記リゾルバからのクエリのＩＰ有効期間の分散の連続性に基づくリゾルバ・プロファイルを受信するステップを含む請求項１５に記載の方法。
17. 前記リゾルバ・プロファイルが信頼できると判定されなかった場合に、攻撃状態の表示を発生するステップを含む請求項１５に記載の方法。
18. 前記対応するリゾルバ・プロファイルが信頼できると判定されなかった場合に、リゾルバからのクエリを阻止するステップを含む請求項１５に記載の方法。
19. 前記受信するステップが、トップレベル・ドメイン名サーバにクエリを送るリゾルバに対するプロファイルを受信するステップを含む請求項１５に記載の方法。
20. 前記リゾルバ・プロファイルは、各プロファイル特性に対して１つの要素を含む配列を含み、
    前記要素は、プロファイル特性が正常または異常であることを表す２進値である請求項１５に記載の方法。
21. 前記ポリシーを適用するステップは、各プロファイル特性に対して１つの要素を含む１つまたは複数の配列を含むポリシーを適用するステップを含み、
    前記要素は、正常または異常なプロファイル特性を表す２進値であり、
    前記リゾルバを追加するステップは、そのプロファイルが前記予め設定されたポリシー配列の１つと一致した場合は、前記リゾルバを前記信頼できるリゾルバのリストに追加するステップを含む請求項１５に記載の方法。
22. 信頼できるＤＮＳリゾルバのリストを生成するためのシステムであって、
    １つまたは複数のプロセッサを備える処理システムと、
    ネットワーク接続された装置から通信を受信し、前記ネットワーク接続された装置に通信を送信するための通信ポートと、
    命令を記憶したメモリと
    を備え、
    前記メモリには、前記命令が前記処理システムによって実行されたときに、
    コンピュータにおいて、リゾルバのトップトーカ・ステータス、照会されるドメイン名の分布の正常性、クエリタイプの分布の連続性、ＲＤビットステータス、および分散されたドメイン名サーバのトポロジ内の１つまたは複数のノードにおけるクエリ・トラフィックに関する情報のいずれか、または組み合わせに基づく、前記リゾルバがクエリをドメイン名サーバに送るためのリゾルバ・プロファイルを受信するステップと、
    前記リゾルバが信頼できるかどうかを判定するために、前記リゾルバ・プロファイルにポリシーを適用するステップと、
    前記リゾルバが信頼できると判定された場合に、前記コンピュータによって、前記リゾルバを信頼できるリゾルバのリストに追加するステップと
    からなる動作を前記処理システムに行わせるための命令が格納されているシステム。
23. 前記受信するステップは、前記リゾルバからのクエリのＩＰ有効期間の分散の連続性に基づくリゾルバ・プロファイルを受信するステップを含む請求項２２に記載のシステム。
24. 前記動作は、前記リゾルバ・プロファイルが信頼できると判定されなかった場合に、攻撃状態の表示を発生するステップを含む請求項２２に記載のシステム。
25. 前記動作は、前記対応するリゾルバ・プロファイルが信頼できると判定されなかった場合に、前記リゾルバからのクエリを阻止するステップを含む請求項２２に記載のシステム。
26. 前記受信するステップは、トップレベル・ドメイン名サーバにクエリを送るリゾルバに対するプロファイルを受信するステップを含む請求項２２に記載のシステム。
27. 前記リゾルバ・プロファイルは、各プロファイル特性に対して１つの要素を含む配列を含み、
    前記要素は、プロファイル特性が正常または異常であることを表す２進値を含む請求項２２に記載のシステム。
28. 前記ポリシーを適用するステップは、各プロファイル特性に対して１つの要素を含む１つまたは複数の配列を含むポリシーを適用するステップを含み、
    前記要素は、正常または異常なプロファイル特性を示す２進値であり、
    前記リゾルバを追加するステップは、そのプロファイルが前記予め設定されたポリシー配列の１つと一致した場合に、前記リゾルバを前記信頼できるリゾルバのリストに追加するステップを含む請求項２２に記載のシステム。
    

Images