JP2018074395A - データ通信システム、キャッシュｄｎｓ装置及び通信攻撃防止方法 - Google Patents

Abstract

【課題】本開示は、ＡＳＰによる巡回調査の遅れ、リンクの無い悪意のＷｅｂサーバの潜在化、柔軟な通信制御ができない、クライアントの通信プライバシのＡＳＰへの流出、及び、クライアントの負荷の課題を解決することを目的とする。【解決手段】本開示は、ＤＮＳクエリをクライアント１２から受信すると、ＵＲＬに対応するＩＰアドレス及び安全性評価結果を含むＤＮＳレスポンスを権威ＤＮＳサーバ２３から受信し、受信した安全性評価結果が通信許可ポリシーを満たす場合、ＤＮＳレスポンスに記載のＩＰアドレスへの発信許可をクライアント１２に対して行うキャッシュＤＮＳサーバ１５と、ＩＳＰ網９２内に接続されている各ＵＲＬの安全性評価結果を保持し、ＤＮＳクエリを受信するとＤＮＳレスポンスをキャッシュＤＮＳサーバ１５に送信する権威ＤＮＳサーバ２３と、を備えるデータ通信システムである。【選択図】図４

Description

本開示は、インターネットにおけるＷｅｂサーバとクライアント間通信において、サーバに対する通信攻撃や、クライアントに対する通信攻撃を防止するデータ通信方法に関する。

図１は、関連技術に係るインターネットを介したＷｅｂサーバとクライアント間の接続構成例を示す。図１では、理解の容易のため、第１のＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）の管理するＩＳＰ網９１と、第２のＩＳＰの管理するＩＳＰ網９２と、がインターネット９３を介して接続されている例を示す。クライアント１２はＩＳＰ網９１内に接続されている端末の１つであり、ＩＳＰ網９１とインターネット９３との境界にあるゲートウェイルータ（以下、ＧＷと称する。）１１に接続し、ＧＷ１１はＩＳＰ網９１内のキャッシュＤＮＳサーバ１５と接続している。

Ｗｅｂサーバ２２はＩＳＰ網９２内に接続されている端末の１つであり、ＩＳＰ網９２とインターネットとの境界にあるＧＷ２１に接続し、ＧＷ２１はＩＳＰ網９２内の権威ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバ２３と接続している。なお、以下では、説明を簡易にするため、権威ＤＮＳサーバが管理するＵＲＬの範囲（ゾーン）に対応するＷｅｂサーバ２２は、ＩＳＰ網９２に接続するＷｅｂサーバ２２の範囲として説明する。

ＧＷ１１及びＧＷ２１は、ＩＳＰ網内からの発信はすべて通過させるが、外部からの発信は権威ＤＮＳサーバ及びＷｅｂサーバのＩＰアドレス宛の通信のみ、内部に転送する。ＧＷ１１とＧＷ２１は、インターネット９３を介して接続し、インターネット９３はＧＷ１１及びＧＷ２１から受信したＩＰパケットのＩＰアドレスを参照し、宛先となるＧＷ２１及びＧＷ１１に転送する。

ＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）のＩＤＳ（Ｉｎｔｒｕｓｉｏｎ Ｄｅｔｅｃｔｉｏｎ Ｓｙｓｔｅｍ）サーバ１４，２４は、それぞれ、インターネット９３に接続するＷｅｂサーバ間のリンク情報を用いて、各Ｗｅｂサーバに周期的に接続し、ＩＤＳ技術を活用して、各Ｗｅｂサーバからクライアントへのマルウェア感染や、他Ｗｅｂサーバへの成りすましなどクライアントの安全を脅かす処理（通信攻撃）がないか調査し、危険な処理を行うＷｅｂサーバのＵＲＬのリスト（ブラックリスト）や安全なＷｅｂサーバのＵＲＬのリスト（ホワイトリスト）を管理する。ＡＳＰは、例えば、Ｇｏｏｇｌｅ（登録商標）及びＭｉｃｒｏｓｏｆｔ（登録商標）である。なお、図１では、Ｗｅｂサーバ２２以外のＷｅｂサーバの図示を省略している。

クライアント１２のＷｅｂブラウザは、ＩＤＳサーバ１４，２４と通信し、当該ブラックリストまたはホワイトリストを活用して発信の制御を行う。なお、２０１６年５月の時点で、Ｆｉｒｅｆｏｘ（登録商標）、Ｓａｆａｒｉ（登録商標）、Ｃｈｒｏｍｅ（登録商標）はＧｏｏｇｌｅ（登録商標）社が提供するブラックリストを、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）やＥｄｇｅ（登録商標）はＭｉｃｒｏｓｏｆｔ（登録商標）社が提供するホワイトリストを使用することが可能である。以下、Ｆｉｒｅｆｏｘ（登録商標）の処理概要について、公開情報を元に説明する。

Ｆｉｒｅｆｏｘ（登録商標）は、Ｇｏｏｇｌｅ Ｓａｆｅ Ｂｒｏｗｓｉｎｇ（登録商標）というＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を利用し、当該ブラックリストをクライアント端末内にダウンロードする。ブラックリストは、危険なＵＲＬのそれぞれをハッシュしたリストである。ユーザが、クライアントのＦｉｒｅｆｏｘ（登録商標）を用いて、ユーザが指定したＵＲＬとの接続を指示すると、Ｗｅｂブラウザは、当該ＵＲＬのハッシュ値がブラックリストにある場合は、ＩＤＳサーバ１４，２４に当該ＵＲＬを通知する。ＩＤＳサーバ１４，２４は当該ＵＲＬがブラックリストにあるかどうかを、Ｆｉｒｅｆｏｘ（登録商標）に応答する。当該ＵＲＬがブラックリストにあった場合、Ｆｉｒｅｆｏｘ（登録商標）はユーザに警告を表示し、ユーザは危険なＷｅｂサーバに接続することを控えることができる。接続先ＷｅｂサーバのＵＲＬがブラックリストにない場合、クライアント（スタブリゾルバとも呼ばれる）は、当該ＵＲＬに対応するＷｅｂサーバのＩＰアドレスをＤＮＳクエリ（図２）により、キャッシュＤＮＳサーバ（フルサービスリゾルバとも呼ばれる）に問い合わせる。ＵＲＬがＷｅｂサーバ２２のホスト名の場合、キャッシュＤＮＳはＤＮＳプロトコルにより、ｒｏｏｔ ＤＮＳサーバや上位ドメインのＤＮＳサーバに当該ＵＲＬの対応する情報の管理を行っている権威ＤＮＳサーバ２３のＩＰアドレスを再帰検索により入手し、当該権威ＤＮＳサーバ２３にＤＮＳクエリを転送する。ここで、権威ＤＮＳサーバ２３は、コンテンツサーバとも呼ばれ、図の例ではＩＳＰ網９２の権威ＤＮＳサーバ２３として機能する。なお図１では、ｒｏｏｔ ＤＮＳサーバや上位ドメインのＤＮＳサーバの表記を省略している。

権威ＤＮＳサーバ２３は図３に示すように、Ｗｅｂサーバ２２のＩＰアドレス（アンサー部）と、当該権威ＤＮＳサーバが持つゾーン署名鍵（公開鍵と秘密鍵のペアで構成）の公開鍵（ＤＮＳＫＥＹ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ ＫＥＹ）レコード）と当該公開鍵に対応する秘密鍵で当該ＩＰアドレスのハッシュ値を暗号化した署名（ＲＲＳＩＧ（Ｒｅｓｏｕｒｃｅ Ｒｅｃｏｒｄ Ｓｉｇｎａｔｕｒｅ）レコード）を含むＤＮＳレスポンスをキャッシュＤＮＳサーバ１５に返送する。キャッシュＤＮＳサーバ１５は既存のＤＮＳＳＥＣ（ＤＮＳ ＳＥＣｕｒｉｔｙ Ｅｘｔｅｎｓｉｏｎｓ）のプロトコル手順を用いて、ｒｏｏｔ ＤＮＳサーバからの信頼性チェーンにより、キャッシュＤＮＳサーバ１５のゾーンに対応する署名鍵の本人性を確認する。次に当該公開鍵を用いて受信したＤＮＳレスポンスの署名を復号して、署名範囲のハッシュ値と比較する。一致した場合署名範囲に改ざんがないと判断し、当該ＩＰアドレスを含むＤＮＳレスポンスをクライアント１２に返却する。以上により、クライアント１２は、Ｗｅｂサーバ２２のＩＰアドレスを入手し、Ｗｅｂサーバ２２とのＩＰ通信が可能になる。

関連技術では、以下の課題がある。
第１の課題：ＡＳＰによる巡回調査の遅れ。２０１５年時点で世界中のドメイン数は３億を超過している。このため、１つのＡＳＰが全Ｗｅｂサーバを巡回して調査すると、調査間隔が長くなってしまい、調査の間に、攻撃者によりＷｅｂサーバが汚染され、クライアントにとって危険なＷｅｂサーバとなる可能性が無視できない。

第２の課題：リンクの無い悪意サーバの潜在化。クライアントに感染させたマルウェアと通信し、クライアント端末を遠隔操作するＣ＆Ｃサーバなどの悪意サーバは、ＵＲＬをＤＮＳサーバに登録せず、他のＷｅｂサーバからのリンクもない場合がある。当該サーバについては、Ｗｅｂリンクによる巡回調査が出来ない問題がある。

第３の課題：クライアントの通信プライバシのＡＳＰへの流出。ブラックリストを攻撃者が解読すると攻撃のヒントになるため、クライアントは危険な可能性のあるＵＲＬをＡＳＰに通知し、ＡＳＰが最終的な判定を行っている。このため、クライアントは通信の安全性と引き換えに、通信プライバシの一部をＡＳＰに公開せざるを得ない問題がある。

第４の課題：クライアントの負荷。クライアントは、ブラックリストのＡＳＰからの入手や、ハッシュ照合などの処理が必要であり、またそのためには、ＰＫＩ証明書の検証が必要である。センサなど電力や計算処理能力が低いマシン端末には負担が大きい。

特開２０１２−０８０３５８号公報 特開２００９−２３２１１６号公報

本開示は、ＡＳＰによる巡回調査の遅れ、リンクの無い悪意のＷｅｂサーバの潜在化、柔軟な通信制御ができない、クライアントの通信プライバシのＡＳＰへの流出、及び、クライアントの負荷の課題を解決することを目的とする。

具体的には、本開示のデータ通信システムは、
第１のＩＳＰ網に接続され、第１のＩＳＰ網内の各端末に対する第１の通信許可ポリシーを保持し、第１のＩＳＰ網とは異なる第２のＩＳＰ網に接続されているＷｅｂサーバのＵＲＬに対応するＩＰアドレスを問い合わせるＤＮＳクエリを第１のＩＳＰ網内の端末から受信すると、前記ＵＲＬに対応するＩＰアドレス及び安全性評価結果を含むＤＮＳレスポンスを第２のＩＳＰ網の権威ＤＮＳ装置から受信し、受信した安全性評価結果が第１の通信許可ポリシーを満たすか否かを判定し、第１の通信許可ポリシーを満たす場合、ＤＮＳレスポンスに記載のＩＰアドレスへの発信許可をＤＮＳクエリの送信元の端末に対して行うキャッシュＤＮＳ装置と、
第２のＩＳＰ網に接続され、第２のＩＳＰ網内に接続されている各ＵＲＬの安全性評価結果を保持し、第１のＩＳＰ網からＤＮＳクエリを受信すると、ＤＮＳクエリに記載されているＵＲＬに対応するＩＰアドレス及び安全性評価結果を含むＤＮＳレスポンスを、第１のＩＳＰ網のキャッシュＤＮＳ装置に送信する権威ＤＮＳ装置と、
を備える。

具体的には、本開示のキャッシュＤＮＳ装置は、
自装置の接続されている第１のＩＳＰ網とは異なる第２のＩＳＰ網に接続されているＷｅｂサーバのＵＲＬに対応するＩＰアドレスを問い合わせるＤＮＳクエリを、第１のＩＳＰ網内の端末から受信すると、前記ＵＲＬに対応するＩＰアドレス及び安全性評価結果を含むＤＮＳレスポンスを第２のＩＳＰ網の権威ＤＮＳから受信し、
第１のＩＳＰ網内の各端末に対する第１の通信許可ポリシーを保持し、第２のＩＳＰ網の権威ＤＮＳから受信した安全性評価結果が第１の通信許可ポリシーを満たすか否かを判定し、第１の通信許可ポリシーを満たす場合、ＤＮＳレスポンスに記載のＩＰアドレスへの発信許可をＤＮＳクエリの送信元の端末に対して行う。

具体的には、本開示の通信攻撃防止方法は、
第１のＩＳＰ網のキャッシュＤＮＳが、第１のＩＳＰ網とは異なる第２のＩＳＰ網に接続されているＷｅｂサーバのＵＲＬに対応するＩＰアドレスを問い合わせるＤＮＳクエリを、第１のＩＳＰ網内の端末から受信すると、前記ＵＲＬに対応するＩＰアドレス及び安全性評価結果を含むＤＮＳレスポンスを第２のＩＳＰ網の権威ＤＮＳから受信する手順と、
第１のＩＳＰ網のキャッシュＤＮＳが、第１のＩＳＰ網内の各端末に対する第１の通信許可ポリシーを参照し、権威ＤＮＳから受信した安全性評価結果が第１の通信許可ポリシーを満たすか否かを判定し、第１の通信許可ポリシーを満たす場合、ＤＮＳクエリで問い合わせのあったＩＰアドレスへの発信許可をＤＮＳクエリの送信元の端末に対して行う手順と、
を備える。

本開示によれば、ＡＳＰによる巡回調査の遅れ、リンクの無い悪意のＷｅｂサーバの潜在化、クライアントの通信プライバシのＡＳＰへの流出、及び、クライアントの負荷の課題を解決することができる。

関連技術に係るデータ通信システムの構成例を示す図である。 関連技術に係るＤＮＳクエリの一例を示す。 関連技術に係るＤＮＳレスポンスの一例を示す。 実施形態１に係るデータ通信システムの構成例を示す図である。 実施形態１に係るＤＮＳクエリの一例を示す。 実施形態１に係るＤＮＳレスポンスの一例を示す。 通信許可ポリシーの一例を示す。 ＤＮＳリソースレコードの標準フォーマットの一例を示す。 本開示に係るＲＤＡＴＡフォーマットの一例を示す。 ＲＤＡＴＡフォーマットに記載する安全性評価結果の具体例である。 実施形態２に係るデータ通信システムの構成例を示す図である。 実施形態２に係るＤＮＳレスポンスの一例を示す。 実施形態３に係るＤＮＳクエリの一例を示す。 実施形態３に係るＤＮＳレスポンスの一例を示す。

以下、本開示の実施形態について、図面を参照しながら詳細に説明する。なお、本開示は、以下に示す実施形態に限定されるものではない。これらの実施の例は例示に過ぎず、本開示は当業者の知識に基づいて種々の変更、改良を施した形態で実施することができる。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。

（実施形態１）
図４は、本実施形態に係るデータ通信システムの構成例である。本実施形態では、インターネット９３を介したＷｅｂサーバ２２とクライアント１２間の接続構成例を示す。図１の構成に対して、ＩＳＰ網９２内にＩＤＳサーバ２４を追加設置する。また、Ｗｅｂサーバ２２、キャッシュＤＮＳサーバ１５、権威ＤＮＳサーバ２３及びＧＷ１１に以下の処理を行う手段を追加することで前述の第１の課題〜第４の課題を解決する。

Ｗｅｂサーバ２２はＩＳＰ網９２に接続すると、既存技術であるＤＤＮＳ（Ｄｙｎａｍｉｃ ＤＮＳ）プロトコルなどを使用し、権威ＤＮＳサーバ２３にＵＲＬとＩＰアドレスの対応を登録する。権威ＤＮＳサーバ２３は、ＵＲＬの登録を受け付けると、ＩＤＳサーバ２４に当該ＵＲＬを登録する。以降、当該ＩＤＳサーバ２４は、ＩＳＰ網９２内の登録された全ＵＲＬに対応するホストの信頼性レベルを、既存のＩＤＳ技術を活用して周期的に自動調査し、その評価結果をＵＲＬ単位で権威ＤＮＳサーバ２３に登録する。ここで、評価結果は、例えば、安全／危険、及び最新調査時期、過去の危険判定履歴が例示でき、以下、「安全性評価結果」と表記する。権威ＤＮＳサーバ２３は、各ＵＲＬに対応するＩＰアドレスに加えて、当該安全性評価結果をＩＳＰ網９２のゾーンの秘密鍵で署名して、保持する。

ＩＳＰ網９１の運用者は、キャッシュＤＮＳサーバ１５に通信許可ポリシーＰ１を登録しておく。通信許可ポリシーＰ１は、ＩＳＰ網９１の内部の各端末と外部ホスト間の通信を許可するポリシーである。ここで、ポリシーは、例えば、外部ホストが帰属するＩＳＰによる安全判定があり、最新調査時期が２日以内、過去の危険判定から１月以上経過、などであり、以下、「通信許可ポリシー」と表記する。

キャッシュＤＮＳサーバ１５は、クライアント１２からＤＮＳクエリを受信すると、ＤＮＳプロトコルにより、ｒｏｏｔ ＤＮＳサーバや上位ドメインのＤＮＳサーバに当該ＵＲＬに対応する情報の管理を行っている権威ＤＮＳサーバ（図の例ではＩＳＰ網９２の権威ＤＮＳサーバ２３）のＩＰアドレス及び本開示への対応の有無を再帰検索により入手する。なお、権威ＤＮＳサーバ２３のＩＰアドレスを上位ＤＮＳサーバに登録時に本開示への対応有無も登録しておく。

キャッシュＤＮＳサーバ１５は、権威ＤＮＳサーバ２３のＩＰアドレスを入手すると、図５に示すように、クライアント１２から受信したＤＮＳクエリに、クライアント側ゾーンのドメイン名とキャッシュＤＮＳサーバ１５のＩＰアドレスを追加する。また、クライアント側ゾーン署名鍵の秘密鍵を用いて当該ＩＰアドレスとゾーン名に対する署名を作成し、当該ＤＮＳクエリに追加し、クライアント側ゾーン署名鍵の公開鍵を付与して、権威ＤＮＳサーバ２３に送信する。ここで、署名は、例えば、署名範囲のハッシュ値を秘密鍵で暗号化したものを用いることができる。本実施形態におけるクライアント側ゾーン署名鍵は、キャッシュＤＮＳサーバ１５の接続されているＩＳＰ網９１のゾーン署名鍵である。

権威ＤＮＳサーバ２３は、既存のＤＮＳＳＥＣのプロトコル手順を用いて、ｒｏｏｔ ＤＮＳサーバからの信頼性チェーンにより、キャッシュＤＮＳサーバ１５のゾーンに対応する署名鍵の本人性を確認する。次に当該公開鍵を用いて受信したＤＮＳクエリの署名を復号して、署名範囲のハッシュ値と比較し、一致した場合署名範囲に改ざんがないと判断すると、当該ＵＲＬに対応するＡレコード（ＩＰアドレス）と安全性評価結果、及びサーバ側ゾーン署名鍵の秘密鍵で作成した署名、そして、サーバ側ゾーン署名鍵の公開鍵を付与して、ＤＮＳレスポンスに格納して返送する（図６）。本実施形態におけるサーバ側ゾーン署名鍵は、権威ＤＮＳサーバ２３の接続されているＩＳＰ網９２のゾーン署名鍵である。

キャッシュＤＮＳサーバ１５は、既存のＤＮＳＳＥＣのプロトコル手順により、ｒｏｏｔ ＤＮＳサーバからの信頼性チェーンにより、権威ＤＮＳサーバ２３のゾーンに対応する署名鍵の本人性を確認する。次に当該公開鍵を用いてＤＮＳレスポンスに付与された署名を判定し、Ｗｅｂサーバ２２のＩＰアドレスとＩＳＰ網９２による安全性評価結果の改竄がない場合、当該情報をキャッシングするとともに、クライアント１２にＤＮＳレスポンスによりＷｅｂサーバ２２のＩＰアドレスを返却する。また、キャッシュＤＮＳサーバ１５は、当該安全性評価結果と通信許可ポリシーＰ１を照合し、通信を許可する場合、ＧＷ１１に当該ＩＰアドレスへの発信許可を指示する。通信許可ポリシーの例を図７に示す。

安全性評価結果と通信許可ポリシーをＤＮＳレスポンスへ格納する方法は既存のレスポンスプロトコルに準拠する。ただし、ＤＮＳパケットで伝送するリソースレコード（ドメイン名に関連するデータの種類）に、新たに、「安全性・ポリシーレコード」を定義し、リソースレコードの標準フォーマットに従い、それらをＤＮＳパケットに格納する。

リソースレコードの標準フォーマットを図８に示す。ここで、「ドメイン名」はＤＮＳクエリで問い合わせられたＵＲＬ中のホスト名である。「タイプ」はリソースレコードの種類を示す値である。「クラス」はドメイン名が帰属する名前空間のことであり、現状インターネットのみが使用されている。「ＴＴＬ」は当該リソースレコードの情報が有効な時間を示す。「ＲＤＡＴＡ」はリソースレコードの種類毎に定義される情報である。

「安全性・ポリシーレコード」では、新規にＲＤＡＴＡフォーマットを定義する。例を図９に示す。本例では、最大２５５個の安全性評価結果と、最大２５５個の通信許可ポリシーを伝送する。各安全性評価結果と通信許可ポリシーは、それぞれ項目コード（８ｂｉｔ）と、内容コード（８ｂｉｔ）の合計１６ｂｉｔ固定である。各項目と内容の例及び、それらを評価する方法の例を図１０に示す。なお通信許可ポリシーで指定する内容コードの値は、相手端末の安全性評価結果が同値または小さい場合に接続を許可する意味としている。

ＩＳＰ網９１のＧＷ１１は、発信許可を指示されたＩＰアドレスのリストを管理し、クライアント１２からＩＳＰ網９１外宛のＩＰパケットを受信すると、当該リストを参照し、宛先がリストにないＩＰパケットはＩＳＰ網９１外に転送せず廃棄する。

以上説明したように、本実施形態は、Ｗｅｂサーバ２２とクライアント１２間通信において、Ｗｅｂサーバ２２にＵＲＬを割り当てる第２のＩＳＰ網９２が、Ｗｅｂサーバ２２の安全性を評価し、その結果である安全性評価結果を権威ＤＮＳサーバ２３で公開する。そして、キャッシュＤＮＳサーバ１５が、権威ＤＮＳサーバ２３から得た安全性評価結果と、当該キャッシュＤＮＳサーバ１５が予め持つセキュリティポリシーＰ１を比較し、当該キャッシュＤＮＳサーバ１５を利用するクライアント１２に対し、Ｗｅｂサーバ２２との通信を許可するか判定し、通信を許可したＷｅｂサーバ２２宛のＩＰパケットのみ、インターネット９３への発信を許可する。

ここで、本実施形態は、キャッシュＤＮＳサーバ１５がＤＮＳクエリにキャッシュＤＮＳサーバ１５のＩＰアドレスとゾーン名を追加し、またそれらについて当該キャッシュＤＮＳサーバ１５のゾーンに対応するクライアント側ゾーン署名鍵で作成した署名を追加して、権威ＤＮＳサーバ２３に送信する。ここで、署名は、例えば、署名対象のハッシュ値を秘密鍵で暗号化したものである。権威ＤＮＳサーバ２３は、既存のＤＮＳＳＥＣのプロトコル手順を用いて、ｒｏｏｔ ＤＮＳサーバ（不図示）からの信頼性チェーンを用いて、当該ゾーンに対応するサーバ側ゾーン署名鍵の本人性を確認し、当該鍵を用いて当該署名を復号し、得られたハッシュ値を、署名範囲から計算したハッシュ値と比較して検証する。

本開示に係る第１の課題〜第４の課題のそれぞれを、本開示がどのように解決しているのか以下に説明する。
・第１の課題：ＡＳＰによる巡回調査の遅れについて。
本開示では、各ＩＳＰ網がＩＤＳサーバを備え、巡回調査をＩＳＰ網毎に分散して実施する。このため、各ＡＳＰがそれぞれ独立してインターネット９３内の全Ｗｅｂサーバを調査する場合と比較し、短い周期で、かつ精度の高い調査が可能となる。
・第２の課題：リンクの無い悪意のＷｅｂサーバの潜在化について。
本開示では、各ＩＳＰ網が権威ＤＮＳサーバを備え、ＷｅｂサーバにＵＲＬを割り当てるＩＳＰ網が、当該ドメイン内のＷｅｂサーバのみを、分散して調査する。このため、各ＡＳＰが全世界のＷｅｂサーバを調査する既存技術に比べて、調査対象数が少ないため、迅速に調査を行うことができる。また、本開示では権威ＤＮＳサーバ２３のレコードを参照して調査を行うため、ＵＲＬを持つｗｅｂサーバやクライアントについて、調査漏れがない。また、クライアント側のＩＳＰ網９１が、ＵＲＬを持たないＷｅｂサーバへの発信を遮断することで、悪意のＷｅｂサーバの潜在化を防止する。
・第３の課題：クライアントの通信プライバシのＡＳＰへの流出について。
本開示では、ＡＳＰに対して通信相手のＵＲＬを通知する必要が無い。
・第４の課題：クライアントの負荷
本開示では、クライアントによるブラックリストの管理や照合が不要である。

さらに、本開示では、Ｗｅｂサーバ２２側の安全性評価結果や通信許可ポリシーを通知する相手を、ＤＮＳＳＥＣにより割り当てられたゾーン署名鍵をもつキャッシュＤＮＳサーバ１５に限定しかつＩＰアドレスの成りすましを防いでいるため、悪意者への漏洩を防ぐ事が可能である。このため、安全なＷｅｂサーバと未調査のＷｅｂサーバの区別を含む詳細な情報を、クライアント側のＩＳＰ網９１に通知することができ、クライアント側で柔軟な通信制御が可能である。

なお、サーバ側のＩＳＰ網９２がクライアント側のＩＳＰ網９１の成りすましを防ぐ方法として、ＰＫＩ（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）やＳｉｎｇｌｅ Ｓｉｇｎ Ｏｎなどの既存技術の適用が考えられるが、ＩＳＰ網毎の公開鍵の管理やＩｄＰ（Ｉｄｅｎｔｉｔｙ Ｐｒｏｖｉｄｅｒ）アカウントの作成などＩＳＰの負担が大きく、また、既存のＤＮＳ手順以外に認証手順の追加が必要となり、処理性能や接続遅延が劣化する問題がある。一方、ｒｏｏｔ ＤＮＳサーバが信頼性のルートとなり、ＤＮＳリプライデータの改竄防止に使用するゾーン署名鍵の本人性を保証するＤＮＳＳＥＣ技術が普及しつつある。本開示は本鍵を流用し、ＤＮＳＳＥＣプロトコルを拡張することで、ＩＳＰの負担やＤＮＳ以外の手順の追加をせずに、ＤＮＳリクエストのＩＰアドレスの認証を実現することができる。

また、ＩＳＰ網９１とＩＳＰ網９２間の経路上で、ＤＮＳクエリやレスポンスを盗聴される可能性がある場合は、ＩＳＰ網９１及び９２間のメッセージ数を増やさずに、キャッシュＤＮＳサーバ１５と権威ＤＮＳサーバ２３間で共通鍵を共有し、暗号化することもできる。

なお、ＩＳＰ網９１とＩＳＰ網９２間の経路上で、ＤＮＳクエリやレスポンスの盗聴や改竄の危険がない場合は、共通鍵による暗号化を削除することで、ＤＮＳクエリ毎の署名作成や暗号化処理が不要となり、キャッシュＤＮＳサーバ１５や権威ＤＮＳサーバ２３の性能への影響を少なくすることが出来る。

（実施形態２）
Ｗｅｂサーバ２２のＩＰアドレスを知っている任意のクライアントからのＩＰパケットがＷｅｂサーバ２２まで到着すると、悪意者からＷｅｂサーバ２２が攻撃される可能性がある。本実施形態に係るデータ通信システムは、このようなＷｅｂサーバ２２に対する攻撃の防止を実現する。

図１１は、本実施形態に係るデータ通信システムの構成例である。本実施形態に係るデータ通信システムは、クライアント側のＩＳＰ網９１内に権威ＤＮＳサーバ１３とＩＤＳサーバ１４を追加し、以下の処理を行う構成をさらに備える。これにより、本実施形態に係るデータ通信システムは、Ｗｅｂサーバ２２に対する攻撃を防止する。

クライアント１２がＩＳＰ網９１に接続すると、権威ＤＮＳサーバ１３は、ＩＤＳサーバ２２と同様に、クライアント１２のＵＲＬとＩＰアドレスの対応を登録する。権威ＤＮＳサーバ１３はＵＲＬの登録を受け付けると、権威ＤＮＳサーバ２３と同様に、ＩＤＳサーバ１４に当該ＵＲＬを登録する。以降、当該ＩＤＳサーバ１４は、ＩＳＰ網９１内の登録された全ＵＲＬに対応するホストの信頼性レベルを既存のＩＤＳ技術を活用して全数、周期的に調査し、その調査結果をＵＲＬ単位で安全性評価結果として権威ＤＮＳサーバ１３に登録する。

ＩＳＰ網９２の運用者は、権威ＤＮＳサーバ２３に、当該ＩＳＰ網９２内部と外部ホスト間の通信を許可する通信許可ポリシーＰ２を登録しておく。権威ＤＮＳサーバ２３は、図１２に示すように、Ｗｅｂサーバ２２のＩＰアドレス（データ部中のアンサー部）及び実施形態１で生成した安全性評価結果に加え、通信許可ポリシーＰ２についてもサーバ側ゾーン署名鍵による署名を付けてＤＮＳレスポンスに格納して返送する。

権威ＤＮＳサーバ２３から受信したＤＮＳレスポンスに通信許可ポリシーＰ２が含まれている場合、キャッシュＤＮＳサーバ１５は、権威ＤＮＳサーバ１３をクライアント１２のＩＰアドレスで検索し、当該クライアント１２の安全性評価結果を読み取る。そして、Ｗｅｂサーバ２２の安全性評価結果がＩＳＰ網９１の通信許可ポリシーＰ１を満たし、かつ、クライアント１２の安全性評価結果がＩＳＰ網９２の通信許可ポリシーＰ２を満たした場合、キャッシュＤＮＳサーバ１５は、ＧＷ１１に当該ＩＰアドレスへの発信許可を指示する。通信許可ポリシーＰ１やＰ２を、ホスト毎あるいはホストの種類毎に分けることで、更に柔軟な通信制御が可能である。

以上説明したように、本実施形態は、Ｗｅｂサーバ２２側のＩＳＰが、クライアント１２に対して当該Ｗｅｂサーバ２２との通信を許可する条件を権威ＤＮＳサーバ２３で公開し、クライアント側のキャッシュＤＮＳサーバ１５が、クライアント側のＩＳＰが判定した当該クライアント１２の安全性評価結果と比較し、通信を許可するか判定する。これにより、本実施形態は、Ｗｅｂサーバや着信側ＩＳＰに代行して、発信側のＩＳＰがクライアント１２の安全性を判定し、Ｗｅｂサーバ２２への接続可否を判断するため、Ｗｅｂサーバ２２に対する攻撃を防止することができる。

（実施形態３）
本実施形態に係るデータ通信システムは、実施形態１又は実施形態２において、ＵＲＬなどの情報を暗号化する。

図１３に、本実施形態におけるＤＮＳクエリの一例を示す。キャッシュＤＮＳサーバ１５は、ＤＮＳクエリのクエリ部を共通鍵で暗号化し、当該共通鍵をサーバ側ゾーン署名鍵の公開鍵で暗号化し、クライアント側ゾーン署名鍵の秘密鍵による署名を付けて、権威ＤＮＳサーバ２３に送信する。ここで、共通鍵は、暗号アルゴリズムの識別情報を含む。

権威ＤＮＳサーバ２３は、当該ＤＮＳクエリの署名を当該クライアント側ゾーン署名鍵の公開鍵で検証し、署名範囲に改ざんがないか確認する。改ざんがない場合、権威ＤＮＳサーバ２３は、サーバ側ゾーン署名鍵の秘密鍵を用いて共通鍵を復号し、得た共通鍵を用いてクエリ部を復号する。

図１４に、本実施形態におけるＤＮＳレスポンスの一例を示す。権威ＤＮＳサーバ２３は、復号して得られた問い合わせＵＲＬに対応するアンサー部を作成し、ＤＮＳレスポンスのクエリ部と、アンサー部の署名と署名鍵以外のレコードを、当該共通鍵で暗号化して、キャッシュＤＮＳサーバ１５に返送する。ここで、アンサー部は、ＵＲＬのＩＰアドレス、Ｗｅｂサーバ２２の安全性評価結果、及び通信許可ポリシーＰ２を含む。

本実施形態は、キャッシュＤＮＳサーバ１５がＤＮＳクエリを送信時に、ＤＮＳクエリのクエリ部を共通鍵で暗号化し、当該共通鍵をサーバ側ゾーン署名鍵の公開鍵で暗号化し、クライアント側ゾーン署名鍵の秘密鍵による署名を付けて権威ＤＮＳサーバ２３に送信する。一方、権威ＤＮＳサーバ２３は、当該ＤＮＳクエリの署名を当該クライアント側ゾーン署名鍵の公開鍵で検証し、署名範囲に改ざんがない場合、当該サーバ側ゾーン署名鍵の秘密鍵で復号して得た共通鍵を用いてクエリ部を復号する。次に、復号して得られた問い合わせＵＲＬに対応するアンサー部を作成し、ＤＮＳレスポンスのクエリ部と、アンサー部の署名と署名鍵以外のレコードを、当該共通鍵で暗号化して当該キャッシュＤＮＳサーバに返送する。したがって、本実施形態により、権威ＤＮＳサーバ２３とキャッシュＤＮＳサーバ１５間の経路上での盗聴を防ぐことができる。

本開示は情報通信産業に適用することができる。

１１、２１：ＧＷ
１２：クライアント
１４、２４：ＩＤＳサーバ
１５：キャッシュＤＮＳサーバ
２２：Ｗｅｂサーバ
１３、２３：権威ＤＮＳサーバ
９１、９２：ＩＳＰ網
９３：インターネット

Claims (9)

1. 第１のＩＳＰ網に接続され、第１のＩＳＰ網内の各端末に対する第１の通信許可ポリシーを保持し、第１のＩＳＰ網とは異なる第２のＩＳＰ網に接続されているＷｅｂサーバのＵＲＬに対応するＩＰアドレスを問い合わせるＤＮＳクエリを第１のＩＳＰ網内の端末から受信すると、前記ＵＲＬに対応するＩＰアドレス及び安全性評価結果を含むＤＮＳレスポンスを第２のＩＳＰ網の権威ＤＮＳ装置から受信し、受信した安全性評価結果が第１の通信許可ポリシーを満たすか否かを判定し、第１の通信許可ポリシーを満たす場合、ＤＮＳレスポンスに記載のＩＰアドレスへの発信許可をＤＮＳクエリの送信元の端末に対して行うキャッシュＤＮＳ装置と、
   第２のＩＳＰ網に接続され、第２のＩＳＰ網内に接続されている各ＵＲＬの安全性評価結果を保持し、第１のＩＳＰ網からＤＮＳクエリを受信すると、ＤＮＳクエリに記載されているＵＲＬに対応するＩＰアドレス及び安全性評価結果を含むＤＮＳレスポンスを、第１のＩＳＰ網のキャッシュＤＮＳ装置に送信する権威ＤＮＳ装置と、
   を備えるデータ通信システム。
2. 第１のＩＳＰ網のキャッシュＤＮＳ装置は、自装置のＩＰアドレス及び第１のＩＳＰ網のゾーン名に第１のＩＳＰ網のゾーン署名鍵の秘密鍵を用いて署名を行ったもの、並びに、第１のＩＳＰ網のゾーン署名鍵の公開鍵を、第１のＩＳＰ網内の端末から受信したＤＮＳクエリに追加して第２のＩＳＰ網の権威ＤＮＳ装置に送信し、
   第２のＩＳＰ網の権威ＤＮＳ装置は、第１のＩＳＰ網のゾーン署名鍵の公開鍵を用いてＤＮＳクエリに記載されているＩＰアドレス及びゾーン名に改ざんがないことを確認する、
   請求項１に記載のデータ通信システム。
3. 第２のＩＳＰ網の権威ＤＮＳ装置は、ＤＮＳクエリに記載されているＵＲＬに対応するＩＰアドレス及び安全性評価結果に第２のＩＳＰ網のゾーン署名鍵の秘密鍵を用いて署名を行ったもの、並びに、第２のＩＳＰ網のゾーン署名鍵の公開鍵を、第１のＩＳＰ網のキャッシュＤＮＳ装置に送信し、
   第１のＩＳＰ網のキャッシュＤＮＳ装置は、第２のＩＳＰ網のゾーン署名鍵の公開鍵を用いてＤＮＳレスポンスに記載されているＩＰアドレス及び安全性評価結果に改ざんがないことを確認する、
   請求項１又は２に記載のデータ通信システム。
4. 第１のＩＳＰ網のキャッシュＤＮＳ装置は、ＤＮＳクエリに記載されているＵＲＬを共通鍵で暗号化し、当該共通鍵を第２のＩＳＰ網のゾーン署名鍵の公開鍵で暗号化し、暗号化した共通鍵、自装置のＩＰアドレス及び第１のＩＳＰ網のゾーン名に第１のＩＳＰ網のゾーン署名鍵の秘密鍵を用いて署名を行ったもの、並びに、第１のＩＳＰ網のゾーン署名鍵の公開鍵を、第１のＩＳＰ網内の端末から受信したＤＮＳクエリに追加して第２のＩＳＰ網の権威ＤＮＳ装置に送信し、
   第２のＩＳＰ網の権威ＤＮＳ装置は、第１のＩＳＰ網のゾーン署名鍵の公開鍵を用いてＤＮＳクエリに記載されている暗号化した共通鍵、ＩＰアドレス及びゾーン名に改ざんがないことを確認し、第２のＩＳＰ網のゾーン署名鍵の秘密鍵を用いて暗号化されている共通鍵を復号し、復号化した共通鍵を用いて暗号化されているＵＲＬを復号する、
   請求項１から３のいずれかに記載のデータ通信システム。
5. 第２のＩＳＰ網の権威ＤＮＳ装置は、ＤＮＳクエリに記載されていた共通鍵を用いて、ＤＮＳレスポンスに記載されているＵＲＬ、ＩＰアドレス及び安全性評価結果を暗号化する、
   請求項４に記載のデータ通信システム。
6. 第２のＩＳＰ網の権威ＤＮＳ装置は、第２のＩＳＰ網内の各端末に対する第２の通信許可ポリシーを、ＤＮＳレスポンスに追加して第１のＩＳＰ網のキャッシュＤＮＳ装置に送信し、
   第１のＩＳＰ網のキャッシュＤＮＳ装置は、ＤＮＳレスポンスに記載されている安全性評価結果が第１の通信許可ポリシーを満たし、かつ、ＤＮＳクエリの送信元の端末がＤＮＳレスポンスに記載されている第２の通信許可ポリシーを満たす場合、ＤＮＳレスポンスに記載されているＩＰアドレスへの発信許可をＤＮＳクエリの送信元の端末に対して行う、
   請求項１から５のいずれかに記載のデータ通信システム。
7. 第２のＩＳＰ網の権威ＤＮＳ装置は、ＤＮＳクエリに記載されていた共通鍵を用いて第２の通信許可ポリシーを暗号化し、暗号化されている第２の通信許可ポリシーに第２のＩＳＰ網のゾーン署名鍵の秘密鍵を用いて署名を行ったもの、並びに、第２のＩＳＰ網のゾーン署名鍵の公開鍵を、第１のＩＳＰ網のキャッシュＤＮＳ装置に送信し、
   第１のＩＳＰ網のキャッシュＤＮＳ装置は、第２のＩＳＰ網のゾーン署名鍵の公開鍵を用いてＤＮＳレスポンスに記載されている第２の通信許可ポリシーに改ざんがないことを確認する、
   請求項６に記載のデータ通信システム。
8. 自装置の接続されている第１のＩＳＰ網とは異なる第２のＩＳＰ網に接続されているＷｅｂサーバのＵＲＬに対応するＩＰアドレスを問い合わせるＤＮＳクエリを、第１のＩＳＰ網内の端末から受信すると、前記ＵＲＬに対応するＩＰアドレス及び安全性評価結果を含むＤＮＳレスポンスを第２のＩＳＰ網の権威ＤＮＳから受信し、
   第１のＩＳＰ網内の各端末に対する第１の通信許可ポリシーを保持し、第２のＩＳＰ網の権威ＤＮＳから受信した安全性評価結果が第１の通信許可ポリシーを満たすか否かを判定し、第１の通信許可ポリシーを満たす場合、ＤＮＳレスポンスに記載のＩＰアドレスへの発信許可をＤＮＳクエリの送信元の端末に対して行う、
   を備えるキャッシュＤＮＳ装置。
9. 第１のＩＳＰ網のキャッシュＤＮＳが、第１のＩＳＰ網とは異なる第２のＩＳＰ網に接続されているＷｅｂサーバのＵＲＬに対応するＩＰアドレスを問い合わせるＤＮＳクエリを、第１のＩＳＰ網内の端末から受信すると、前記ＵＲＬに対応するＩＰアドレス及び安全性評価結果を含むＤＮＳレスポンスを第２のＩＳＰ網の権威ＤＮＳから受信する手順と、
   第１のＩＳＰ網のキャッシュＤＮＳが、第１のＩＳＰ網内の各端末に対する第１の通信許可ポリシーを参照し、権威ＤＮＳから受信した安全性評価結果が第１の通信許可ポリシーを満たすか否かを判定し、第１の通信許可ポリシーを満たす場合、ＤＮＳクエリで問い合わせのあったＩＰアドレスへの発信許可をＤＮＳクエリの送信元の端末に対して行う手順と、
   を備える通信攻撃防止方法。

Images