JP2009238065A - 通信検知装置、通信検知方法、及び通信検知プログラム - Google Patents

Abstract

【課題】ピアツーピア通信の特徴に基づいて通信を検出する。
【解決手段】通信ログ記憶手段１ａには、装置間でやり取りされた通信データに関する情報が記録される。ログ分割手段１ｂは、通信ログ記憶手段１ａに格納される通信ログを、通信ログに記録される発信元と宛先に基づいて対象の装置ごとに分割する。分割ログ解析手段１ｃは、対象装置ごとに分割された通信ログを解析し、対象装置への接続要求に対する応答有無を検出し、応答成否テーブルを作成する。判定手段１ｅは、応答成否テーブルに基づいて装置から応答が得られなかった期間が判定条件を満たしたとき、ピアツーピア通信が行われたと判定する。
【選択図】図１

Description

本発明は通信検知装置、通信検知方法、及び通信検知プログラムに関し、特にネットワークに接続する装置間でやり取りされている通信を検知する通信検知装置、通信検知方法、及び通信検知プログラムに関する。

コンピュータネットワークの一形態であるピアツーピア（Peer to Peer）通信は、定まったクライアント、サーバを持たず、各ホスト間で直接データをやり取りする通信方式である。サーバへの負荷が集中しやすいクライアント・サーバ通信に比べて負荷が分散されやすいというメリットがある。このため、ネットワークを介したファイルの交換や流通に広く用いられている。ピアツーピア通信自体は優れた技術であるが、いわゆるファイル交換ソフトに利用され、著作権侵害をはじめとする違法なコンテンツ流通の温床となっていると指摘されている。また、ピアツーピア通信を通じてウィルス感染が広がったり、情報暴露型のウィルスによる機密情報や個人情報が漏洩するなどの問題も続発し、その対策が急務となっている。

従来、ネットワーク上においてピアツーピア通信を監視・制御する仕組みがいくつかある。これらは、既知のピアツーピア通信に特有のパターン（シグニチャ）を用いて検出を行う。しかし、こういったパターンはスキルを有する専門家が解析を行って一つ一つ作成しなければならず、日々新たに登場するピアツーピア通信のソフトウェアに対応できていないのが現状である。

また、一般に、コンピュータウィルスの検出についても、ウィルスに感染したファイルなどの特徴を定義したパターンを用いた検出方法が用いられている。しかし、日々新たなウィルスが登場しており、パターン作成とのいたちごっことなっている。そこで、パターンを用いない検出方法として、通信の接続に失敗した回数がある閾値を超えたホストを検出し、検出されたホストがワームに感染していると判定するワーム検出方法がある（例えば、特許文献１参照）。
米国特許第７，１５９，１４９号明細書

上記のように、ピアツーピア通信の検出に用いる新規パターンの作成が新たなソフトウェアの登場に追いつかない現状を踏まえ、パターンに依らずにピアツーピア通信を検出する技術が求められている。しかし、パターンに依らずにピアツーピア通信を検出することは容易ではないという問題点がある。

例えば、ピアツーピア通信の実体は、ＨＴＴＰ（HyperText Transfer Protocol）などのプロトコルを用いた通信であることが多い。これは、ＨＴＴＰなどの許可されたプロトコル以外の通信は、ネットワーク上のファイアウォールなどによってフィルタリングされてしまい、宛先に届かないためである。ここで、ＨＴＴＰは、通常のウェブブラウザがウェブサイトのアクセスに用いるプロトコルそのものである。すなわち、プロトコルレベルでは、通常のウェブサイトへのアクセスと、ピアツーピア通信との見分けがつかない。このため、単純にネットワーク上で通信を監視していても、大量のウェブサイトへのアクセスの中からピアツーピア通信を検出するのは困難である。

また、ワームのように短時間に送信を大量に行って多くの接続エラーを発生させるものは、接続エラーの回数が閾値を超えたことにより、検出することができる。しかしながら、ピアツーピア通信は、ホスト間における情報交換であり、動作が静かに進行するため、同じような手法で検出することは難しい。

本発明はこのような点に鑑みてなされたものであり、個々のソフトウェアに依存するパターンなどの情報ではなく、ピアツーピア通信の特徴に基づいて通信を検出する通信検知装置、通信検知方法、及び通信検知プログラムを提供することを目的とする。

上記課題を解決するために、ログ分割手段と、分割ログ解析手段と、判定手段と、を有し、ネットワークに接続する装置間で行われている通信を検知する通信検知装置が提供される。ログ分割手段は、装置間でやり取りされた通信データに関する情報を記録した通信ログが格納される通信ログ記憶手段から通信ログを読み出す。そして、通信ログに記録されている通信データの発信元と宛先とに基づいて通信ログを対象の装置ごとに分割する。分割ログ解析手段は、ログ分割手段によって装置ごとに分割された通信ログを解析する。装置に対する接続要求が行われた通信データを抽出するとともに、接続要求に対する装置からの応答を検索する。そして、応答が検出されたか否かに応じて応答成否テーブルを作成して応答成否テーブル記憶手段に格納する。判定手段は、応答成否テーブル記憶手段に格納される応答成否テーブルに基づいて、装置から応答が得られなかった期間が予め決められた判定条件を満たしたときは、ピアツーピア通信が行われたと判定する。

このような通信検知装置によれば、ログ分割手段は、通信ログ記憶手段に格納される通信ログを、対象の装置ごとに分割する。分割ログ解析手段は、対象装置ごとに分割された通信ログを解析し、対象装置への接続要求に対する応答有無に応じて応答成否テーブルを作成する。判定手段は、応答成否テーブルに基づいて装置から応答が得られなかった期間が判定条件を満たしたとき、ピアツーピア通信が行われたと判定する。

また、上記課題を解決するために、上記通信検知装置と同様の処理手順が実行される通信検知方法、及びコンピュータを上記通信検知装置と同様に機能させる通信検知プログラム、が提供される。

開示の通信検知装置、通信検知方法、及び通信検知プログラムによれば、通信ログに記録された対象装置への接続要求に対する応答の成否に基づいてピアツーピア通信を検出する。これにより、個々のソフトウェアに依存するパターンなどの情報を用いることなく、ピアツーピア通信を検出することが可能となる。

以下、本発明の実施の形態を図面を参照して説明する。図１は、実施の形態に適用される発明の概念図である。
通信検知装置１は、通信データのやり取りが記録された通信ログを格納する通信ログ記憶手段１ａ、通信ログを装置ごとに分割するログ分割手段１ｂ、分割された通信ログを解析して装置ごとに応答成否テーブルを作成する分割ログ解析手段１ｃ、応答成否テーブルが格納される応答成否テーブル記憶手段１ｄ、及びピアツーピア通信が行われたかどうかを判定する判定手段１ｅを有する。なお、このような各処理手段は、コンピュータが通知検知プログラムを実行することにより、その処理機能が実現される。

通信ログ記憶手段１ａには、ネットワークに接続する装置間でやり取りされた通信データに関する情報を記録した通信ログが格納される。通信ログには、通信データの発信元の通信アドレス（以下、発信元アドレスとする）、宛先の通信アドレス（以下、宛先アドレスとする）、通信データの検出時刻、通信データの種別、などの情報が記録されている。

ログ分割手段１ｂは、通信ログ記憶手段１ａから所定の期間の通信ログを読み出す。そして、読み出した通信ログに記録されている通信データの発信元アドレスと宛先アドレスとに基づいて通信ログを対象の装置ごとに分割する。例えば、外部ネットワークに接続する外部装置を対象装置として、または、内部ネットワークに接続する内部装置を対象装置として、装置ごとに通信ログを分割する。内部ネットワークは、社内ネットワークなどであり、通常、社内ネットワークに接続する内部装置の通信アドレスまたは通信アドレスの一部は既知である。これに対し、外部ネットワークに接続する外部装置の通信アドレスは未知である。例えば、発信元アドレスが内部装置の通信アドレスであり、宛先が未知であれば、内部装置から外部装置へ送られた通信データだとわかる。こうして、内部装置の通信アドレスが発信元または宛先に記録される通信ログを、当該内部装置に関する分割ログとする。同様に他の内部装置について通信ログを分割し、内部装置ごとに通信ログを分割する。対象装置が外部装置の場合についても同様の手順で、外部装置の通信アドレス（通信アドレスが未知のもの）ごとに通信ログを分割することができる。

分割ログ解析手段１ｃは、装置ごとに分割された通信ログを解析する。この装置に対する接続要求が行われた通信データを抽出するとともに、この接続要求に対する装置からの応答有無を検出して応答成否テーブルを作成する。応答成否テーブルは、接続要求の発信元アドレス、宛先アドレス、発信時刻、及び応答成否などが登録される。応答成否には、接続要求に対する応答が検出されたときは「成功」、検出されなかったときは「失敗」が設定される。応答成否テーブルは、応答成否テーブル記憶手段１ｄに格納される。

応答成否テーブル記憶手段１ｄには、対象装置ごとに生成された応答成否テーブルが格納される。
判定手段１ｅは、応答成否テーブル記憶手段１ｄに格納される装置ごとの応答成否テーブルを読み出し、装置から応答が得られなかった、すなわち、応答成否が「失敗」の期間を把握する。応答なしの期間の他、必要であれば、応答なしの時間帯などが把握される。把握された期間と、予め決められた判定条件を照合し、判定条件が満たされたときは、ピアツーピア通信が行われたと判定する。判定条件には、ピアツーピア通信の通信上の振る舞いの特徴に基づいて、ピアツーピア通信と推定できる条件が設定される。例えば、「指定時間以上連続して応答がないとき」、「指定時間帯に一定時間以上連続して応答がないとき」などが設定される。

このような構成の通信検知装置１の動作について説明する前に、ピアツーピア通信の特徴、すなわち、通信上の振る舞いの特徴について説明する。なお、通信上の振る舞いは、通信ログに記録される通信データのやり取りに基づいて把握する。図２は、ホストの状態に応じた通信上の振る舞いを示した図である。［Ａ］は、ホストの電源がオンの場合、［Ｂ］は、ホストの電源がオフの場合のやり取りを示している。なお、図の例は、ＴＣＰ（Transmission Control Protocol）で接続を確立するためのスリーウェイハンドシェイクが行われるときのやり取りを示している。このやり取りは、通信ログに記録される。

［Ａ］ホストの電源がオンの場合について、接続要求以降の通信ログに記録される通信データの一例を示した図である。ＴＣＰのスリーウェイハンドシェイク手順（以下、ＴＣＰハンドシェイクとする）では、まず接続する側（クライアント２）から、接続される側（ホスト３）に対し、接続要求を意味するＳＹＮパケット（４ａ）が送られる。ホスト３は、接続許可を意味するＡＣＫとパケット接続要求のＳＹＮパケットとを組み合わせたＳＹＮ ＡＣＫ（以下、ＳＹＮ／ＡＣＫとする）パケット（４ｂ）をクライアント２に送る。最後に、クライアント２からＡＣＫパケット（４ｃ）を送り、接続が確立される。ホスト３の電源がオンの場合は、一連のＴＣＰハンドシェイクが行われ、やり取りされたパケットが通信ログに記録される。

［Ｂ］ホストの電源がオフの場合について、接続要求以降の通信ログに記録される通信データの一例を示した図である。［Ａ］と同様に、まず、クライアント２からホスト３に対し、ＳＹＮパケット（４ｄ）が送られる。しかし、ホスト３は電源がオフしているため、応答を返すことができない。クライアント２は、ＳＹＮ／ＡＣＫパケットが得られないので接続をあきらめる。このように、ホスト３の電源がオフの場合は、通信ログにＳＹＮパケットは記録されるが、その後にＳＹＮ／ＡＣＫパケットは記録されない。

以上より、クライアント２からホスト３に送信されるＳＹＮパケットに対し、ホスト３が電源オンであればＳＹＮ／ＡＣＫパケットが応答として返されるが、ホスト３が電源オフであれば応答は返されない。このように、接続先のホスト３が稼働しているか否かにより通信上の振る舞いが異なってくる。

ここで、ホスト３が、ＨＴＴＰプロトコルを用いて何らかのサービスを提供するウェブ（Ｗｅｂ）サーバであるとする。例えば、インターネットショッピング、インターネットバンキング、各種情報の提供などの様々なサービスを提供するサーバあり、通常、インターネット上のユーザに広くサービスを提供することを目的としている。このため、ウェブサーバ、言い換えればウェブサーバとして機能するホストは、一時的なメンテナンス時を除いては、常時稼働している可能性が非常に高い。これに対し、ピアツーピアを用いたソフトウェアは、私的な目的で使用されるケースがほとんどである。検出目標とするファイル交換ソフトなどで用いられるピアツーピアソフトウェアは、通常、個人所有のパーソナルコンピュータなどにインストールされる。個人所有のパーソナルコンピュータは、ウェブサーバのように常時稼働しておく必要はなく、個人が利用するときのみ電源がオンされる可能性が高い。したがって、接続要求先が通常のウェブサイトであれば常時稼働しているが、ピアツーピア通信による接続要求先はそうではないという差異がある。

以上より、通信上の振る舞いには、次の性質が経験則的に成り立つと想定できる。
（１）ＳＹＮパケットに対して常にＳＹＮ／ＡＣＫを返すホスト３は、通常のウェブサーバである。

（２）ＳＹＮパケットに対してＳＹＮ／ＡＣＫを返さない場合もあるホスト３は、ピアツーピアソフトウェアがインストールされた個人所有のパーソナルコンピュータである。
通信検知装置１では、通信ログを解析し、接続要求を検出するとともに、接続要求に対する応答が検出されれば、（１）のケースであると判定する。一定期間応答無しなど、応答が検出されない状態が判定条件に合致すれば、（２）のケース、すなわち、ピアツーピア通信が行われたと判定する。

なお、インターネット上でのピアツーピア通信を調査した結果についての報告がコリンズらによってなされている（Michael P. Collins and Michael K. Reiter 著、"Finding Peer-to-Peer File-Sharing Using Coarse Network Behaviors", "Computer Security ？ ESORICS2006, Springer Berlin/Heidelberg，２００６年９月２１日, p.1-17）。この報告では、通常のＨＴＴＰ通信では、「接続失敗（Failed Connection）」だったものが１パーセントであったが、ピアツーピア通信を用いたソフトウェアとして著名なＢｉｔＴｏｒｒｅｎｔによる通信では、「接続失敗」だったものが６８パーセントもあったことが述べられている。

図１に戻って説明する。通信検知装置１では、このような通信上の特徴に基づいてピアツーピア通信を検出する。ログ分割手段１ｂでは、通信ログ記憶手段１ａに格納される所定期間の通信ログを読み出し、通信ログを対象装置ごとに分割する。対象装置を外部装置とするときは、外部装置の通信アドレスごとに通信ログが分割される。対象装置を内部装置とするときは、内部装置の通信アドレスごとに通信ログが分割される。分割ログ解析手段１ｃは、対象装置ごとに分割された通信ログを解析し、対象装置に対する接続要求が行われた通信データを抽出し、その応答の通信データを探す。発信元や宛先などの関連情報とともに、応答が検出できたときは「成功」、検出できなかったときは「失敗」を登録した応答成否テーブルを作成し、応答成否テーブル記憶手段１ｄに格納する。判定手段１ｅは、応答成否テーブルを参照し、判定条件と照合することによって、対象装置でピアツーピア通信が行われたかどうかを判定する。

以上の処理が実行されることにより、ピアツーピア通信を行っていた装置が把握される。
このように、ピアツーピア通信を行うソフトウェアがインストールされた個人が所有するパーソナルコンピュータなどと、ウェブサーバなどのサーバとは、パーソナルコンピュータの電源がオンされているときは、ネットワーク上の振る舞いに基づいて見分けることは困難である。しかし、個人のパーソナルコンピュータは常時稼働されていないのが普通であるのに対し、サーバは常時稼働されていることが普通である。したがって、応答が得られないホストを特定すれば、ピアツーピアソフトウェアがインストールされたパーソナルコンピュータを特定することができる。さらに、通常のサーバから応答を得られない可能性は非常に低いので、通常のサーバをピアツーピアソフトウェアがインストールされたパーソナルコンピュータであると誤認知する可能性は低い。すなわち、高い精度でピアツーピア通信を検出することができる。

以下、実施の形態を、企業内ネットワークに配備されるログ解析サーバに適用した場合を例に図面を参照して詳細に説明する。ここでは、ＨＴＴＰリクエストを検出してピアツーピア（以下、Ｐ２Ｐと略記する）通信を検出する場合を例に説明する。また、通信ログを取得するサーバのネットワーク上の位置に応じて、同じ動作について取得される通信ログが異なる。そこで、第１の実施の形態として通信ログがプロキシサーバの外側で収集される場合について説明し、第２の実施の形態として通信ログがプロキシサーバの内側で収集される場合について説明する。

第１の実施の形態として、ログ解析サーバに通信ログを提供するネットワーク監視装置がプロキシサーバの外側（プロキシサーバよりも外部ネットワークにより近い側）に配置されたときについて説明する。図３は、第１の実施の形態のシステム構成例を示した図である。

企業内ネットワーク１０は、ファイアウォール１２を介して外部のインターネット３０に接続されている。企業内ネットワーク１０には、ログ解析サーバ（Ｐ２Ｐ通信検知装置）１１、ネットワーク監視装置１３、プロキシサーバ１４、レイヤ３スイッチ（Ｌ３ＳＷ）１５、及び巻末１６ａ，１６ｂ，１６ｃ，１６ｄが接続されている。また、外部ネットワークであるインターネット３０には、企業内ネットワーク１０内の端末１６ａ，１６ｂ，１６ｃ，１６ｄと必要に応じてやり取りを行うパーソナルコンピュータ（以下、ＰＣとする）４１ａ，４１ｂ，４１ｃが接続されている。

ファイアウォール１２は、インターネット３０と企業内ネットワーク１０の境界を流れる通信データを監視し、パケットフィルタリングを行う。ネットワーク監視装置１３は、インターネット３０を介して行われた通信を監視し、通過した通信データを漏れなく捕捉する。捕捉された通信データに基づいて通信ログを作成し、所定の記憶装置に蓄積する。プロキシサーバ１４は、企業内ネットワーク１０に出入りするアクセスを一元管理する。例えば、ＨＴＴＰによる接続を中継する中継サーバである。Ｌ３ＳＷ１５は、レイヤ３（ネットワーク層）のデータでパケットの行き先を判断して転送を行う。サブネットに接続する端末１６ａ，１６ｂ，１６ｃ，１６ｄに送受信されるパケットを転送する。ログ解析サーバ１１は、通信検知装置１として機能し、ネットワーク監視装置１３から通信ログを取得し、Ｐ２Ｐ通信を検知する。なお、ログ解析サーバ１１を別途用意せず、ネットワーク監視装置１３上に通信検知装置１の機能を組み込むとしてもよい。また、プロキシサーバ１４が置かれていない場合は、プロキシサーバ１４の外側にネットワーク監視装置１３が置かれた第１の実施の形態と同様の状態となる。

ここで、ログ解析サーバのハードウェア構成について説明する。図４は、Ｐ２Ｐ通信検知装置のハードウェア構成例を示すブロック図である。
ログ解析サーバ１１は、ＣＰＵ（Central Processing Unit）１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０７を介してＲＡＭ（Random Access Memory）１０２、ハードディスクドライブ（ＨＤＤ：Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、通信インタフェース１０６が接続されている。

ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。ＨＤＤ１０３には、ＯＳやアプリケーションのプログラムが格納される。グラフィック処理装置１０４には、モニタ１０８が接続されており、ＣＰＵ１０１からの命令に従って画像をモニタ１０８の画面に表示させる。入力インタフェース１０５には、キーボード１０９ａやマウス１０９ｂが接続されており、キーボード１０９ａやマウス１０９ｂから送られてくる信号を、バス１０７を介してＣＰＵ１０１に送信する。通信インタフェース１０６は、企業内ネットワーク１０に接続されており、企業内ネットワーク１０を介して他装置との間でデータ交換を行う。

このようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図４には、ログ解析サーバのハードウェア構成を示したが、他の装置のハードウェア構成も同様である。

次に、ログ解析サーバ１１の主要部であるＰ２Ｐ通信検知部のソフトウェア構成について説明する。図５は、Ｐ２Ｐ通信検知部のソフトウェア構成例を示したブロック図である。

Ｐ２Ｐ通信検知部１１−１は、各種情報を記憶する記憶部１１０、ログ読込み部１２０、ログ分割部１３０、分割ログ解析部１４０、判定部１５０、及び出力部１６０を有し、通信ログ記憶装置１７０に格納される通信ログを解析してＰ２Ｐ通信を検知する。

記憶部１１０には、通信ログ１１１、分割ログ１１２、応答成否テーブル１１３、及び判定結果１１４が格納される。各情報の詳細は後述する。
ログ読込み部１２０は、通信ログ記憶装置１７０に格納される所定の期間の通信ログを読み込み、通信ログ１１１として記憶部１１０に格納する。ログ分割部１３０は、ログ分割手段１ｂとして機能し、通信ログ１１１を装置（以下、ホストとする）ごとに分割する。ここでは、インターネット３０に接続する外部ホストごとに通信ログ１１１を分割する。外部ホストごとに分割された通信ログは、分割ログ１１２として記憶部１１０に格納される。分割ログ解析部１４０は、分割ログ解析手段１ｃとして機能し、ＨＴＴＰ要求検索部１４１と、テーブル作成部１４２とを有する。ＨＴＴＰ要求検索部１４１は、分割ログ１１２を解析し、ＨＴＴＰ要求（リクエスト）を検索する。テーブル作成部１４２は、外部ホストに向けたＨＴＴＰリクエストが検出できたとき、この外部ホストに関する応答成否テーブル１１３を作成する。応答成否テーブル１１３は、記憶部１１０に格納される。判定部１５０は、判定手段１ｅとして機能し、応答成否テーブル１１３に基づいて外部ホストにＰ２Ｐソフトウェアがインストールされているかどうかを判定する。判定の結果は、判定結果１１４として記憶部１１０に格納される。出力部１６０は、判定結果１１４に基づいて、判定結果をユーザに提供する。

以下、各処理手段の動作及び処理によって生成されるデータについて詳細に説明する。
通信ログ記憶装置１７０には、ネットワーク監視装置１３によって取得された、監視地点（プロキシサーバ１４とファイアウォール１２との間）を通過した全てのＩＰパケットに関する情報が蓄積されている。ここでは、フィルタリングは行わず、全てのパケットが取得できるとする。なお、通信ログに記録される情報は、パケットのペイロード全てを残す必要はない。どのような情報が通信ログとして残るかは、ネットワーク監視ソフトウェアの種類によって異なるが、少なくとも発信元ＩＰアドレス、宛先ＩＰアドレス、検出の日時、プロトコル、パケット種別などは記録される。また、所定の期間は、例えば、１日、一週間などの期間である。なお、通信ログは、通信ログ記憶装置１７０にアクセスできるのであれば、直接読み込んでも良い。また、ネットワーク経由でネットワーク監視装置１３から取得してもよい。あるいは、記録媒体に記録された通信ログを読み込むとしてもよい。

Ｐ２Ｐ通信検知処理が開始されると、ログ読込み部１２０は、通信ログ記憶装置１７０から所定の期間の通信ログを読み込み、通信ログ１１１として記憶部１１０に格納する。
図６は、通信ログの一例を示した図である。

通信ログ１１１０は、識別番号（Ｎｏ．）１１１１、時刻１１１２、発信元ＩＰ（アドレス）１１１３、宛先ＩＰ（アドレス）１１１４、プロトコル１１１５、及び情報１１１６の情報項目を有する。識別番号１１１１は、通信ログの各行を識別する番号である。時刻１１１２は、パケットが検出された時刻である。発信元ＩＰ１１１３は、検出されたパケットを発信した発信元のＩＰアドレスである。宛先ＩＰ１１１４は、検出されたパケットを受け取る宛先のＩＰアドレスである。プロトコル１１１５は、検出されたパケットのプロトコルである。情報１１１６は、パケットに関し、発信元ポート、宛先ポート、パケットの種別などの情報である。例えば、＞で示された左側は、発信元のポート、右側は宛先のポートになる。また、［ ］内の文字列は、パケットの種別を表す。例えば、Ｎｏ．１の情報「２５２０ ＞ ｈｔｔｐ ［ＳＹＮ］・・・」には、発信元ポートが２５２０、宛先ポートがｈｔｔｐであり、ＳＹＮパケットが送られたことが記載されている。

ログ分割部１３０は、通信ログ１１１を外部ホストごとに分割する。ここで、企業内ネットワーク１０の出入り口における通信ログに記録されるのは、一部の制御通信を除いては、社内の内部ホスト（端末１６ａ，１６ｂ，１６ｃ，１６ｄ）と、社外、すなわち、インターネット３０に接続する外部ホスト（ＰＣ４１ａ、４１ｂ、４１ｃ）との間の通信である。すなわち、宛先ＩＰアドレスと発信元ＩＰアドレスのうち、いずれか一方が社内で使用しているＩＰアドレスであり、他方が社外のＩＰアドレスである。社内で使用しているＩＰアドレスの範囲は、当然に掌握されているため、どちらが社外のホストに該当するかは判別することができる。ここでは、簡単のため、１．２．０．０〜１．２．２５５．２５５までを社内アドレスとして用いているとする。通信ログ１１１に記録された発信元ＩＰアドレス及び宛先ＩＰアドレスが、社内アドレスの範囲に含まれているかどうかを照合し、範囲内に含まれていれば、内部ホストのＩＰアドレスと判定する。また、含まれていなければ、外部ホストのＩＰアドレスと判定する。たとえば、通信ログ１１１０のＮｏ．１の発信元ＩＰは１．２．３．４であるので、社内の内部ホストのＩＰアドレスであると判定される。また、宛先ＩＰは、１００．１．２．３であるので、社外の外部ホストのＩＰアドレスであると判定される。すなわち、Ｎｏ．１の通信は、社内の内部ホストから社外の外部ホストに向けて送られたＳＹＮパケットであることがわかる。なお、図６は、ネットワーク監視ソフトウェアとして著名なＷｉｒｅＳｈａｒｋの例である。もちろん、それ以外のネットワーク監視ソフトウェアによって取得された通信ログを用いるとしてもよい。

こうして検出された外部ホストのＩＰアドレスごとに通信ログを分割する。
図７は、通信ログの分割処理を説明するための図である。図では、簡単のため、識別番号、発信元ＩＰ、及び宛先ＩＰを抜き出している。

通信ログ１１１０ａは、分割前の通信ログである。なお、社内のＩＰアドレスの範囲は、１．２．０．０〜１．２．２５５．２５５とすることは同様である。
ここで、通信ログ１１１０ａのＮｏ．１について着目すると、前述の処理と同様にして、発信元ＩＰは１．２．３．４の内部ホストのＩＰアドレスであり、宛先ＩＰは１００．１．２．３の外部ホストのＩＰアドレスであることがわかる。ログ分割部１３０では、外部ホストについて通信ログを分割するので、外部ホスト１００．１．２．３に関し、通信ログ１１１０ａから、発信元ＩＰ及び宛先ＩＰに１００．１．２．３が検出される通信ログを全て抽出し、分割ログ１１２０ａを作成する。図の例では、通信ログ１１１０ａのＮｏ．１，３，４，９が抽出され、外部ホスト１００．１．２．３に関する分割ログ１１２０ａが作成されている。同様にして、通信ログ１１１０ａのＮｏ．２，５，８，１０が抽出され、外部ホスト１１０．１０．２０．３０に関する分割ログ１１２０ｂが作成されている。また、通信ログ１１１０ａのＮｏ．６，７が抽出され、外部ホスト１２０．１００．１０．１に関する分割ログ１１２０ｃが作成されている。作成された分割ログ１１２０ａ，１１２０ｂ，１１２０ｃは、記憶部１１０に格納される。

なお、図７では、外部ホストごとに通信ログを分割することを説明するために、発信元ＩＰと宛先ＩＰとを抜き出したが、ログ分割部１３０によって、図６に示した通信ログ１１１０の各情報項目を全て転記されるとする。ここで、通信ログ１１１０の各行は、全て外部ホスト１００．１．２．３に関する通信ログである。したがって、以下の説明では、外部ホスト１００．１．２．３に関する分割ログとして、図６に示した通信ログ１１１０の内容が転記されているとする。

続いて、分割ログ解析部１４０が、分割ログを順に解析する。
まず、ＨＴＴＰ要求検索部１４１は、分割ログ１１２０ａ，１１２０ｂ，１１２０ｃにＨＴＴＰリクエストが検出されるか否かを判定する。ＨＴＴＰ／１．１を例にとれば、ＨＴＴＰリクエストには、「ＨＴＴＰ ＧＥＴ」「ＨＴＴＰ ＨＥＡＤ」「ＨＴＴＰ ＰＯＳＴ」「ＨＴＴＰ ＰＵＴ」「ＨＴＴＰ ＤＥＬＥＴＥ」「ＨＴＴＰ ＯＰＴＩＯＮＳ」「ＨＴＴＰ ＴＲＡＣＥ」「ＨＴＴＰ ＣＯＮＮＥＣＴ」「ＨＴＴＰ ＰＡＴＣＨ」「ＨＴＴＰ ＬＩＮＫ」「ＨＴＴＰ ＵＮＬＩＮＫ」がある。ＨＴＴＰ要求検索部１４１では、分割ログの該当行と、ＨＴＴＰリクエストの全ての文字列を照合し、リクエストを検索する。通信ログ１１１０の例では、Ｎｏ．４の「ＨＴＴＰ ＧＥＴ」が検出される。

次に、検索に該当した各行に対し、宛先ＩＰアドレスが外部ホストであるかどうかを判定する。宛先ＩＰアドレスが外部ホストのものであれば、「外部ホストに向けたＨＴＴＰリクエスト」であると判定できる。宛先ＩＰアドレスが内部であれば、「内部ホストに向けたＨＴＴＰリクエスト」であると判定できる。外部ホストに向けたＨＴＴＰリクエストが検出できれば、処理をテーブル作成部１４２へ引き渡す。図の例では、Ｎｏ．４の「ＨＴＴＰ ＧＥＴ」の宛先ＩＰは、外部ホストのＩＰアドレスであるので、外部ホストに向けたＨＴＴＰリクエストと判定され、テーブル作成部１４２によって応答成否テーブルが作成される。

テーブル作成部１４２は、外部ホストに向けたＨＴＴＰリクエストが検出できた外部ホストに関する応答成否テーブルを作成する。前述のように、プロキシサーバ１４の外側で監視する場合、「応答」は、ＴＣＰハンドシェイクのＳＹＮパケットに対してＳＹＮ／ＡＣＫパケットが返ってきたかによって判定する。まず、分割ログを検索し、ＳＹＮパケットを検索する。図６のような通信ログの場合、［ＳＹＮ］の文字列を検索すればよい。ＳＹＮパケットが検索された場合は、検索されたパケットに関する検出時刻、発信元ＩＰ、宛先ＩＰ、発信元ポート、宛先ポートを抽出し、応答成否テーブル１１３に登録する。図６の場合、Ｎｏ．１が検出され、時刻「２００７−１２−２１ １８：５７：０２．３０７６４６」、発信元ＩＰ「１．２．３．４」、宛先ＩＰ「１００．１．２．３」、発信元ポート「２５２０」、及び宛先ポート「ｈｔｔｐ」が登録される。

次に、同じ分割ログからＳＹＮ／ＡＣＫパケットを検出する。検出方法は、ＳＹＮパケットと同様である。そして、検出されたパケットと、登録されたＳＹＮパケットに関する情報とを照合し、登録されたＳＹＮパケットに対する応答であるかどうかを判定する。ＳＹＮパケットに対応付けられる応答であれば、以下の条件を満たす。

・ＳＹＮ／ＡＣＫパケットの宛先ＩＰアドレス＝ＳＹＮパケットの発信元ＩＰアドレス
・ＳＹＮ／ＡＣＫパケットの発信元ＩＰアドレス＝ＳＹＮパケットの宛先ＩＰアドレス
・ＳＹＮ／ＡＣＫパケットの宛先ポート＝ＳＹＮパケットの発信元ポート
・ＳＹＮ／ＡＣＫパケットの発信元ポート＝ＳＹＮパケットの宛先ポート
・ＳＹＮ／ＡＣＫパケットの検出時刻がＳＹＮパケットの時刻よりも後であり、該当するＳＹＮパケットが複数ある場合には時刻の差が最も小さい
ＳＹＮパケットに対してこれらの条件に該当するＳＹＮ／ＡＣＫパケットが検出されれば、ＴＣＰハンドシェイクの応答があったものと解釈される。よって、応答成否テーブル１１３における当該ＳＹＮパケットのエントリーを「成功」とする。当然であるが、一つのＳＹＮ／ＡＣＫパケットに対応するのは、一つのＳＹＮパケットである。条件に合致するＳＹＮ／ＡＣＫパケットが検出できない場合、ＴＣＰハンドシェイクの応答がなかったものと解釈される。よって、応答成否テーブル１１３における当該ＳＹＮパケットのエントリーを「失敗」とする。このようにして、応答成否テーブル１１３の全てのエントリーを「成功」「失敗」のいずれかで埋める。

図６の例では、Ｎｏ．１のＳＹＮパケットに対し、Ｎｏ．２のＳＹＮ／ＡＣＫパケットが条件を満たす。したがって、Ｎｏ．１のＳＹＮパケットに対応する応答成否テーブル１１３には、「成功」が設定される。

図８は、応答成否テーブルの一例を示した図である。
応答成否テーブル１１３０は、識別番号（Ｎｏ．）１１３１、時刻１１３２、発信元ＩＰ（アドレス）１１３３、宛先ＩＰ（アドレス）１１３４、発信元ポート１１３５、宛先ポート１１３６、及び成否１１３７の情報項目を有する。

識別番号１１３１、時刻１１３２、発信元ＩＰ１１３３、及び宛先ＩＰ１１３４は、図６の同じ名称の情報項目と同じであるので説明は省略する。発信元ポート１１３５は、このパケットの発信元のポートを示している。宛先ポート１１３６は、このパケットを受け取る宛先のポートを示している。時刻１１３２、発信元ＩＰ１１３３、宛先ＩＰ１１３４、発信元ポート１１３５、及び宛先ポート１１３６は、ＨＴＴＰ要求検索部１４１が検出したリクエストパケットの情報が登録される。例えば、応答成否テーブル１１３０のＮｏ．１には、ＨＴＴＰ要求検索部１４１によって検出された図６の通信ログ１１１０のＮｏ．１のＳＹＮパケットに関する情報が転記されている。

成否１１３７には、当該パケットに対する応答が検出されたか否かを示す情報がテーブル作成部１４２によって登録される。応答が検出されたときは「成功」が登録され、応答が検出されなかったときは「失敗」が登録される。応答成否テーブル１１３０のＮｏ．１に登録されるＳＹＮパケットは応答を得られたので、「成功」が登録される。

また、応答成否テーブル１１３０のＮｏ．２に登録されているのは、図６の通信ログ１１１０のＮｏ．２１のＳＹＮパケットである。ここでは、Ｎｏ．２１のＳＹＮパケットに対応するＳＹＮ／ＡＣＫパケットは検出されなかったとする。この場合、成否１１３７には、「失敗」が登録される。ここで、成否１１３７の「・・・」で表記された区間は、前行と同じ値が登録されているとする。

以上の手順が、応答成否テーブル１１３０に登録されたリクエスト（ここでは、ＳＹＮパケット）全てに対して行われる。そして、応答成否テーブル１１３０の全項目が登録される。

次に、判定部１５０が、作成された応答成否テーブル１１３に基づいて、ピアツーピア通信が行われているかどうかを判定する。ここでは、「連続して５時間以上応答がなければ、ピアツーピア通信が行われている」という判定条件を用いて、図８の応答成否テーブル１１３０を判定するとして説明する。図８では、Ｎｏ．３からＮｏ．１００までの各行には「成功」、Ｎｏ．１０３からＮｏ．３１１までの各行には「失敗」、Ｎｏ．３１２以降の行には「成功」が登録されているとする。

判定部１５０は各行の成否１１３７の項目が「失敗」となっているところを検索する。識別番号順に検索を行うと、Ｎｏ．２の「失敗」が検出されるが、続くＮｏ．３は「成功」であり、その時間差は判定条件の「連続して５時間以上」を満たしていない。したがって、Ｎｏ．２からはＰ２Ｐ通信が行われているという判定はできない。次に、Ｎｏ．１０１の「失敗」が検出される。さらに、Ｎｏ．３１１まで連続して「失敗」が検出される。その時間差は、約１１時間３０分あり、判定条件の「連続して５時間以上」を満たしている。したがって、この結果に基づいて、Ｐ２Ｐ通信が行われていたと判定する。こうして、Ｐ２Ｐ通信が行われていたと判定された外部ホストのＩＰアドレスを、「Ｐ２Ｐ通信が疑われるＩＰアドレス」として判定結果１１４に登録する。このとき、必要であれば、リクエストを発信した相手のＩＰアドレスなども判定結果に設定する。また、応答が検出されなかった時間帯など、判定部１５０が統計処理した情報を登録するとしてもよい。判定の結果が登録された判定結果１１４は、記憶部１１０に格納される。

出力部１６０は、表示装置に表示するなどして、判定結果１１４を利用者に提供する。
図９は、判定結果表示画面の一例を示した図である。
判定結果表示画面１６００は、ログ解析サーバ１１のモニタ１０８、あるいは、企業内ネットワーク１０を介して接続する利用者端末のモニタに表示される。判定結果１１４に格納される「Ｐ２Ｐ通信が疑われるＩＰアドレス一覧」を読み出し、そのＩＰアドレスを一覧表示させる（１６０１）。また、該当する行の「詳細」１６０２が操作されたときは、Ｐ２Ｐ通信を行った相手先のＩＰアドレスや、応答が検出されなかった時間帯などの統計情報などが表示される。また、このＩＰアドレスの外部ホストに関する通信ログなどの情報を表示するとしてもよい。

なお、出力部１６０は、判定結果１１４を表示装置に表示するばかりでなく、Ｐ２Ｐ通信が疑われるＩＰアドレスの一覧情報を、ファイルとして外部に出力するとしてもよい。
次に、第１の実施の形態のログ解析サーバ１１において実行される通信検知方法の処理手順について説明する。

図１０は、第１の実施の形態の通信検知方法の処理手順を示したフローチャートである。利用者によって処理開始要求が行われて、あるいは、予め決められた所定のタイミングで処理が開始される。

［ステップＳ０１］ 通信ログ記憶装置１７０から所定の期間の通信ログを読込み、通信ログ１１１として記憶部１１０に格納する。
［ステップＳ０２］ 通信ログ１１１に格納される通信ログを、外部ホストごとに分割して、分割ログ１１２を生成する。外部ホストごとに分割された分割ログ１１２は、記憶部１１０に格納する。

［ステップＳ０３］ 分割ログ１１２のうち、１つの外部ホストに関する分割ログを読み出し、ＨＴＴＰリクエストがあるかどうかを検索する。検索対象とするのは、内部ホストから当該外部ホストに向けたＨＴＴＰリクエストである。

［ステップＳ０４］ ステップＳ０３において、分割ログに対応する外部ホストへのＨＴＴＰリクエストが検出されたか否かを判定する。検出されたときは、ステップＳ０５へ処理を進める。検出されないときは、処理をステップＳ０９に進める。

［ステップＳ０５］ 当該外部ホストに向けたＨＴＴＰリクエストが検出されたときは、この外部ホストに関する応答成否テーブルを作成する。応答成否テーブル作成処理の詳細は後述する。

［ステップＳ０６］ ステップＳ０５において作成された応答成否テーブルの内容と、判定条件とを照合する。例えば、判定条件が「連続で５時間以上成功が出現しない時間帯があるか」であれば、成功が検出されない時間帯を応答成否テーブルから算出する。そして、算出された時間と判定条件とを比較する。

［ステップＳ０７］ 応答成否テーブルに登録された登録内容が、判定条件に合致しているか否かを判定する。合致していれば、処理をステップＳ０８へ進める。合致していなければ、処理をステップＳ０９へ進める。

［ステップＳ０８］ 応答成否テーブルの内容が判定条件に合致していれば、この外部ホストを、Ｐ２Ｐ通信を行っている疑いがあると判定する。そしてそのＩＰアドレスを、「Ｐ２Ｐ通信を行っている疑いのあるＩＰアドレス一覧」に出力する。

［ステップＳ０９］ 全分割ログについて、すなわち、検出された全ての外部ホストについての処理が終了したかどうかを判定する。終了していなければ、ステップＳ０３に戻って、次の分割ログに対する処理を行う。全分割ログについて終了していれば、処理を終了する。

以上の処理手順が実行されることにより、Ｐ２Ｐ通信の通信上の振る舞いの特徴に基づいて、Ｐ２Ｐ通信を行った外部ホストが特定される。
次に、第１の実施の形態における応答成否テーブル作成処理ついて説明する。図１１は、第１の実施の形態における応答成否テーブル作成処理の手順を示したフローチャートである。

［ステップＳ５１］ 分割ログから、ＴＣＰハンドシェイクのＳＹＮパケットを検索する。
［ステップＳ５２］ ステップＳ５１においてＳＹＮパケットを検出できたかどうかを判定する。検出できたときは、処理をステップＳ５３へ進める。検出できなかったときは、処理を終了する。

［ステップＳ５３］ ＳＹＮパケットが検出できたときは、このＳＹＮパケットに対応すると見なすことのできる条件に合致するＳＹＮ／ＡＣＫパケットを検索する。条件は、ＳＹＮパケットの発信元ＩＰアドレスと宛先ＩＰアドレス、及び発信元ポートと宛先ポートが入れ替わっており、ＳＹＮパケットより後の時刻に検出されたＳＹＮ／ＡＣＫパケットである。

［ステップＳ５４］ 条件に合致するＳＹＮ／ＡＣＫパケットが検出されたかどうかを判定する。検出されたときは、処理をステップＳ５５に進める。検出されなかったときは、処理をステップＳ５６に進める。

［ステップＳ５５］ ＳＹＮパケットに対応するＳＹＮ／ＡＣＫパケットが検出されたときは、このＳＹＮパケットに関する情報項目を応答成否テーブルに登録し、成否の項に「成功」を登録する。応答成否テーブル登録後、処理をステップＳ５１に戻し、次のＳＹＮパケットの検索を行う。

［ステップＳ５６］ＳＹＮパケットに対応するＳＹＮ／ＡＣＫパケットが検出されなかったときは、このＳＹＮパケットに関する情報項目を応答成否テーブルに登録し、成否の項に「失敗」を登録する。応答成否テーブル登録後、処理をステップＳ５１に戻し、次のＳＹＮパケットの検索を行う。

以上の処理手順が実行されることにより、ＴＣＰのハンドシェイクが行われたか否かに応じて、応答成否が判定され、応答成否テーブルが作成される。なお、上記のフローチャートの説明では、ＳＹＮパケットを検出するごとにＳＹＮ／ＡＣＫパケットを検出するとしたが、はじめにＳＹＮパケットを全て検出して応答成否テーブルに登録しておき、続いてＳＹＮ／ＡＣＫパケットを全て抽出し、登録されているＳＹＮパケットに対応付けられるかに応じて、応答の成否を登録する、としてもよい。

次に、第２の実施の形態として、ログ解析サーバに通信ログを提供するネットワーク監視装置がプロキシサーバの内側（外部ネットワークにより遠い側）に配置されたときについて説明する。

図１２は、第２の実施の形態のシステム構成例を示した図である。図３に示した第１の実施の形態の構成と同じものには同じ番号を付し、説明は省略する。
第１の実施の形態では、ネットワーク監視装置１３がプロキシサーバ１４の外側（インターネット３０に近い側）であったのに対し、第２の実施の形態では、ネットワーク監視装置２３は、プロキシサーバ１４の内側、すなわち、インターネット３０から遠い側であり、プロキシサーバ１４とＬ３ＳＷ１５との間に配置される。ログ解析サーバ２１は、ネットワーク監視装置２３から通信ログを取得し、Ｐ２Ｐ通信を検知する処理を行う。

なお、第２の実施の形態におけるログ解析サーバ２１が有する処理機能の構成要素は、図５に示した第１の実施の形態の構成要素と同様である。そこで、図５に示した構成要素の符号を用いて、第２の実施の形態における機能を説明する。また、ログ解析サーバ２１は、図４に示したものと同様のハードウェア構成のコンピュータで実現することができる。

ここで、ネットワーク監視装置２３がプロキシサーバ１４の内側の配置されたときの通信上の振る舞い（検出される通信データ）について説明する。
図１３は、第２の実施の形態におけるホストの電源がオンの場合の通信上の振る舞いを説明する図である。

まず、クライアント２からプロキシサーバ５との間での接続を確立するため、ＴＣＰハンドシェイク（６０１）が開始される。ＴＣＰハンドシェイク（６０１）では、図２で説明したスリーウェイハンドシェイクの処理手順が行われる。プロキシサーバ５は、常に電源オンと見なすことができるので、ＴＣＰハンドシェイク（６０１）は、正常に完了されるとする。ＴＣＰハンドシェイク（６０１）の後、クライアント２からは、ホストへの接続を要求する「ＨＴＴＰ ＣＯＮＮＥＣＴ ｒｅｑ（リクエスト）」に対応するパケット（６０２）がプロキシサーバ５に対して送信される。これを受け取ったプロキシサーバ５は、クライアント２に対し、ＴＣＰ ＡＣＫパケット（６０３）をクライアント２に返す。さらに、要求先のホスト３とＴＣＰハンドシェイク（６０４）を行って、接続を確立する。続いて、ＨＴＴＰ ＧＥＴリクエストに対応するパケット（６０５）をホスト３に送信し、ＴＣＰ ＡＣＫパケット（６０６）と、「ＨＴＴＰ ｒｅｓ（レスポンス）２００ ＯＫ」に対応するパケット（６０７）を得る。なお、「２００ ＯＫ」の応答は、ＲＦＣ２６１６などによって定められており、「正常応答」を意味する。

プロキシサーバ５からは、ホスト３からの応答「ＨＴＴＰ ｒｅｓ ２００ ＯＫ」に対応するパケット（６０８）がクライアント２に送られる。
図１４は、第２の実施の形態におけるホストの電源がオフの場合の通信上の振る舞いを説明する図である。図１３と同じものには同じ番号を付す。

図１３と同様に、まず、クライアント２からプロキシサーバ５との間での接続を確立するため、ＴＣＰハンドシェイク（６０１）が開始される。プロキシサーバ５は、常に電源オンと見なすことができるので、ＴＣＰハンドシェイク（６０１）は、正常に完了されるとする。ＴＣＰハンドシェイク（６０１）の後、クライアント２からは、ホストへの接続を要求する「ＨＴＴＰ ＣＯＮＮＥＣＴ ｒｅｑ（リクエスト）」に対応するパケット（６０２）がプロキシサーバ５に対して送信される。これを受け取ったプロキシサーバ５は、クライアント２に対し、ＴＣＰ ＡＣＫパケット（６０３）をクライアント２に返す。さらに、要求先のホスト３とＴＣＰハンドシェイクを行うため、ホスト３に対し、ＴＣＰ ＳＹＮ パケット（６１０）を送信する。しかし、ホスト３は、電源オフであるため、応答は返らない。そこで、プロキシサーバ５は、クライアント２に対し、「ＨＴＴＰ ｒｅｓ ５０４ Ｇａｔｅｗａｙ Ｔｉｍｅｏｕｔ」に対応するパケット（６１１）を送信する。なお、「５０４ Ｇａｔｅｗａｙ Ｔｉｍｅｏｕｔ」も、ＲＦＣ２６１６などによって定められており、「応答が返らずタイムアウトとなったこと」を意味する。なお、以下の説明では、簡単のため、ＨＴＴＰリクエストに対応するパケットを単にＨＴＴＰリクエスト、ＨＴＴＰレスポンスに対応するパケットを単にＨＴＴＰレスポンスと表記する。

以上より、第１の実施の形態では、応答の成否をＳＹＮ／ＡＣＫパケットの有無で検出していたが、第２の実施の形態では、ＨＴＴＰレスポンス（ｒｅｓ）のステータスコードが、Ｇａｔｅｗａｙ Ｔｉｍｅｏｕｔであるか、それ以外であるかによって検出する。すなわち、図５に示した機能処理のうち、テーブル作成部１４２の処理が異なる。

第２の実施の形態のテーブル作成部１４２では、分割ログを検索し、ＨＴＴＰ ＣＯＮＮＥＣＴリクエストを検出する。図６に示した通信ログの場合、［ＨＴＴＰ ＣＯＮＮＥＣＴ］を検索すればよい。検索されたパケットから、時刻、発信元ＩＰアドレス、宛先ＩＰアドレスを抽出し、応答成否テーブル１１３の該当項目に登録する。なお、発信元ポート及び宛先ポートが通信ログに記録されている場合には、これらも登録される。

次に同じ分割ログを検索し、ＨＴＴＰレスポンスを見つける。図６に支援した通信ログの場合、［ＨＴＴＰ ＨＴＴＰ］を検索すればよい。次に、応答成否テーブル中の各ＨＴＴＰリクエストの応答に該当するＨＴＴＰレスポンスを、検索されたＨＴＴＰレスポンスから見つける。ＨＴＴＰリクエストに対応付けられる応答であれば、以下の条件を満たす。

・ＨＴＴＰレスポンスの宛先ＩＰアドレス＝ＨＴＴＰ ＣＯＮＮＥＣＴリクエストの発信元ＩＰアドレス
・ＨＴＴＰレスポンスの発信元ＩＰアドレス＝ＨＴＴＰ ＣＯＮＮＥＣＴリクエストの宛先ＩＰアドレス
・ＨＴＴＰレスポンスの検出時刻がＨＴＴＰ ＣＯＮＮＥＣＴリクエストの時刻よりも後であり、該当するＨＴＴＰ ＣＯＮＮＥＣＴリクエストが複数ある場合には時刻の差が最も小さい
通常、全てのＨＴＴＰ ＣＯＮＮＥＣＴリクエストに対してこれらの条件に該当するＨＴＴＰレスポンスが一つずつ見つかる。なお、もしＨＴＴＰレスポンスが見つからないＨＴＴＰ ＣＯＮＮＥＣＴリクエストがあった場合、そのときプロキシサーバ１４などに異常が発生していたと考えられる。かなり例外的なケースだが、対応としては、（ａ）そのようなリクエストは無視して処理する、（ｂ）検知処理そのものを無効とする、のいずれかを採ればよい。

最後に、ＨＴＴＰレスポンスのステータスコードの種類にしたがって、応答成否テーブルを埋める。ここで、ＨＴＴＰレスポンスのステータスコードは、「ＨＴＴＰ ＨＴＴＰ／１．１（１．１はＨＴＴＰのバージョンなので、１．０や０．９などの場合もある）」の直後から抽出できる。ステータスコードは、３桁の数字とその名称（英語）で表記される。代表的なものに、正常応答を示す「２００ ＯＫ」、宛先が検出されない「４０４ Ｎｏｔ Ｆｏｕｎｄ」などがある。第２の実施の形態のテーブル作成部１４２では、各ＨＴＴＰ ＣＯＮＮＥＣＴリクエストに対し、対応するＨＴＴＰレスポンスが、「５０４ Ｇａｔｅｗａｙ ｔｉｍｅｏｕｔ」以外であれば、「成功」、「５０４ Ｇａｔｅｗａｙ ｔｉｍｅｏｕｔ」であれば、「失敗」を該当するエントリーに登録する。このようにして、応答成否テーブル１１３の全てのエントリーを「成功」「失敗」のいずれかで埋める。

次に、第２の実施の形態のログ解析サーバ２１において実行される通信検知方法の処理手順について説明する。
全体の処理手順は、図１０に示した第１の実施の形態の処理手順と同じであるが、応答成否テーブル作成処理（ステップＳ５）が異なる。以下では、ログ解析サーバ２１における応答成否テーブル作成処理の処理手順について説明する。

図１５は、第２の実施の形態における応答成否テーブル作成処理の手順を示したフローチャートである。
［ステップＳ５０１］ 分割ログから、ＨＴＴＰ ＣＯＮＮＥＣＴリクエストを検索する。

［ステップＳ５０２］ ステップＳ５０１においてＨＴＴＰ ＣＯＮＮＥＣＴリクエストを検出できたかどうかを判定する。検出できたときは、処理をステップＳ５０３へ進める。検出できなかったときは、処理を終了する。

［ステップＳ５０３］ ＨＴＴＰ ＣＯＮＮＥＣＴリクエストが検出できたときは、このＨＴＴＰ ＣＯＮＮＥＣＴリクエストに対応すると見なすことのできる条件に合致するＨＴＴＰレスポンスを検索する。条件は、ＨＴＴＰ ＣＯＮＮＥＣＴリクエストの発信元ＩＰアドレスと宛先ＩＰアドレスが入れ替わっており、ＨＴＴＰ ＣＯＮＮＥＣＴリクエストより後の時刻に検出されたＨＴＴＰレスポンスである。

［ステップＳ５０４］ 検出されたＨＴＴＰレスポンスからステータスコードを読み出す。
［ステップＳ５０５］ ステップＳ５０４で読み出されたＨＴＴＰレスポンスのステータスコードが、「５０４ Ｇａｔｅｗａｙ ｔｉｍｅｏｕｔ」であるかどうかを判定する。「５０４ Ｇａｔｅｗａｙ ｔｉｍｅｏｕｔ」でなかったときは、処理をステップＳ５０６に進める。「５０４ Ｇａｔｅｗａｙ ｔｉｍｅｏｕｔ」であったときは、処理をステップＳ５０７に進める。

［ステップＳ５０６］ ＨＴＴＰレスポンスのステータスコードが「５０４ Ｇａｔｅｗａｙ ｔｉｍｅｏｕｔ」でなかったときは、このＨＴＴＰ ＣＯＮＮＥＣＴリクエストに関する情報項目を応答成否テーブルに登録し、成否の項に「成功」を登録する。応答成否テーブル登録後、処理をステップＳ５０１に戻し、次のＨＴＴＰ ＣＯＮＮＥＣＴリクエストの検索を行う。

［ステップＳ５０７］ ＨＴＴＰレスポンスのステータスコードが「５０４ Ｇａｔｅｗａｙ ｔｉｍｅｏｕｔ」であったときは、このＨＴＴＰ ＣＯＮＮＥＣＴリクエストに関する情報項目を応答成否テーブルに登録し、成否の項に「失敗」を登録する。応答成否テーブル登録後、処理をステップＳ５０１に戻し、次のＨＴＴＰ ＣＯＮＮＥＣＴリクエストの検索を行う。

以上の処理手順が実行されることにより、ＨＴＴＰ ＣＯＮＮＥＣＴリクエストに対応するＨＴＴＰレスポンスのステータスコードに応じて、応答成否が判定され、応答成否テーブルが作成される。

なお、上記のフローチャートの説明では、ＨＴＴＰ ＣＯＮＮＥＣＴリクエストを検出するごとにＨＴＴＰレスポンスを検出するとしたが、第２の実施の形態のテーブル作成部１４２の説明でしたような手順で行うとしてもよい。すなわち、はじめにＨＴＴＰ ＣＯＮＮＥＣＴリクエストを全て検出して応答成否テーブルに登録しておく。続いて、ＨＴＴＰレスポンスを全て抽出し、登録されているＨＴＴＰ ＣＯＮＮＥＣＴリクエストに対応付け、そのステータスコードに応じて応答の成否を登録する、としてもよい。

以上のように、ネットワーク監視装置２３がプロキシサーバ１４の内側に配置されている場合であっても、プロキシサーバ１４から得られるレスポンスのステータスコードに応じて外部ホストが応答を返さなかった期間を特定することができる。

なお、上記の実施の形態では、ＨＴＴＰ通信を利用したＰ２Ｐ通信の検知方法について説明したが、これに限定されることはない。他のインターネットプロトコル、例えば、ＳＭＴＰ（Simple mail Transfer Protocol），ＦＴＰ（File Transfer Protocol）においても適用可能である。すなわち、ホストの電源がオンのときの通信上の振る舞いと、ホストが電源オフのときの通信上の振る舞いとに基づいて、ホストが電源をオフしていた期間を特定する。これにより、ホストが常時オンしているサーバであるか、個人所有のパーソナルコンピュータなどであるか、を特定し、Ｐ２Ｐ通信を検知することができる。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、通信検知装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

（付記１） ネットワークに接続する装置間でやり取りされた通信データに関する情報を記録した通信ログが格納される通信ログ記憶手段から前記通信ログを読み出し、前記通信ログに記録されている前記通信データの発信元と宛先とに基づいて前記通信ログを対象の装置ごとに分割するログ分割手段と、
前記ログ分割手段によって前記装置ごとに分割された前記通信ログを解析し、前記装置に対する接続要求が行われた前記通信データを抽出するとともに、前記接続要求に対する前記装置からの応答が検出されたか否かに応じて応答成否テーブルを作成して応答成否テーブル記憶手段に格納する分割ログ解析手段と、
前記応答成否テーブル記憶手段に格納される前記応答成否テーブルに基づいて、前記装置から応答が得られなかった期間が予め決められた判定条件を満たしたときは、ピアツーピア通信が行われたと判定する判定手段と、
を有することを特徴とする通信検知装置。

（付記２） 前記ログ分割手段は、外部ネットワークに接続する通信アドレスが未知の外部装置を前記対象の装置として、内部ネットワークに接続する通信アドレスまたは通信アドレスの一部が既知の内部装置の通信アドレスと、前記通信ログに記録される前記発信元の通信アドレス及び前記宛先の通信アドレスとを照合し、前記発信元の通信アドレスまたは前記宛先の通信アドレスが前記内部装置の通信アドレスと一致しない前記外部装置の通信アドレスごとに前記通信ログを分割する、
ことを特徴とする付記１記載の通信検知装置。

（付記３） 前記ログ分割手段は、内部ネットワークに接続する通信アドレスまたは通信アドレスの一部が既知の内部装置を前記対象の装置として、前記内部装置の通信アドレスと、前記通信ログに記録される前記発信元の通信アドレス及び前記宛先の通信アドレスとを照合し、前記発信元の通信アドレスまたは前記宛先の通信アドレスが一致する前記内部装置の通信アドレスごとに前記通信ログを分割する、
ことを特徴とする付記１記載の通信検知装置。

（付記４） 前記判定手段は、電源がオンのときに接続要求を受けたときのホストの通信上の振る舞いに応じて取得される前記通信ログと、電源がオフのときに接続要求を受けたときの前記ホストの通信情報の振る舞いに応じて取得される前記通信ログとの差異に基づいて、前記ホストが常時稼働しているサーバであるか、使用時以外は電源がオフされている個人所有のコンピュータであるかを特定して、前記ピアツーピア通信が行われたか否かを判定する、
ことを特徴とする付記１記載の通信検知装置。

（付記５） 前記通信ログは、外部ネットワークと、内部ネットワークとの境界に設置されるファイアウォールを介して前記内部ネットワークに出入りされる前記通信データを直接監視できる地点に配置されるネットワーク監視装置によって取得され、
前記分割ログ解析手段は、分割された前記通信ログから前記宛先の通信アドレスが前記対象の装置のものである前記接続要求を検索し、検索された前記接続要求に対応付けられる応答が前記通信ログから検出されたときは、前記応答成否テーブルに成功を登録し、該応答が前記通信ログから検出できなかったときは前記応答成否テーブルに失敗を登録する、
ことを特徴とする付記４記載の通信検知装置。

（付記６） 前記分割ログ解析手段は、前記通信ログからＴＣＰプロトコルに基づくＴＣＰ接続要求パケットを検索して検出できたときは、前記ＴＣＰ接続要求パケットに対応するＴＣＰ接続確認応答を検索し、前記ＴＣＰ接続確認応答の有無に基づいて前記応答成否テーブルの登録を行う、
ことを特徴とする付記５記載の通信検知装置。

（付記７） 前記通信ログは、外部ネットワークと、内部ネットワークとの境界に設置されるファイアウォールと、前記通信データの中継を行う中継サーバを介して接続し、前記外部ネットワークに接続する装置からの応答を前記中継サーバからのステータス情報として取得するネットワーク監視装置によって取得され、
前記分割ログ解析手段は、分割された前記通信ログから前記宛先の通信アドレスが前記対象の装置のものである前記接続要求を検索し、検索された前記接続要求に対応付けられるステータス情報を前記中継サーバから取得し、前記ステータス情報に応じて前記応答成否テーブルに成功または失敗を登録する、
ことを特徴とする付記４記載の通信検知装置。

（付記８） 前記分割ログ解析手段は、前記通信ログからＨＴＴＰプロトコルに基づくＨＴＴＰリクエストに対応するＨＴＴＰレスポンスを検索し、前記ＨＴＴＰレスポンスのステータスコードに基づいて前記応答成否テーブルの登録を行う、
ことを特徴とする付記７記載の通信検知装置。

（付記９） ログ分割手段が、ネットワークに接続する装置間でやり取りされた通信データに関する情報を記録した通信ログが格納される通信ログ記憶手段から前記通信ログを読み出し、前記通信ログに記録されている前記通信データの発信元と宛先とに基づいて前記通信ログを対象の装置ごとに分割する手順と、
分割ログ解析手段が、前記ログ分割手段によって前記装置ごとに分割された前記通信ログを解析し、前記装置に対する接続要求が行われた前記通信データを抽出するとともに、前記接続要求に対する前記装置からの応答が検出されたか否かに応じて応答成否テーブルを作成して応答成否テーブル記憶手段に格納する手順と、
判定手段が、前記応答成否テーブル記憶手段に格納される前記応答成否テーブルに基づいて、前記装置から応答が得られなかった期間が予め決められた判定条件を満たしたときは、ピアツーピア通信が行われたと判定する手順と、
を有することを特徴とする通信検知方法。

（付記１０） コンピュータを、
ネットワークに接続する装置間でやり取りされた通信データに関する情報を記録した通信ログが格納される通信ログ記憶手段から前記通信ログを読み出し、前記通信ログに記録されている前記通信データの発信元と宛先とに基づいて前記通信ログを対象の装置ごとに分割するログ分割手段、
前記ログ分割手段によって前記装置ごとに分割された前記通信ログを解析し、前記装置に対する接続要求が行われた前記通信データを抽出するとともに、前記接続要求に対する前記装置からの応答が検出されたか否かに応じて応答成否テーブルを作成して応答成否テーブル記憶手段に格納する分割ログ解析手段、
前記応答成否テーブル記憶手段に格納される前記応答成否テーブルに基づいて、前記装置から応答が得られなかった期間が予め決められた判定条件を満たしたときは、ピアツーピア通信が行われたと判定する判定手段、
として機能させることを特徴とする通信検知プログラム。

実施の形態に適用される発明の概念図である。 ホストの状態に応じた通信上の振る舞いを示した図である。 第１の実施の形態のシステム構成例を示した図である。 ログ解析サーバのハードウェア構成例を示すブロック図である。 Ｐ２Ｐ通信検知部のソフトウェア構成例を示したブロック図である。 通信ログの一例を示した図である。 通信ログの分割処理を説明するための図である。 応答成否テーブルの一例を示した図である。 判定結果表示画面の一例を示した図である。 第１の実施の形態の通信検知方法の処理手順を示したフローチャートである。 第１の実施の形態における応答成否テーブル作成処理の手順を示したフローチャートである。 第２の実施の形態のシステム構成例を示した図である。 第２の実施の形態におけるホストの電源がオンの場合の通信上の振る舞いを説明する図である。 第２の実施の形態におけるホストの電源がオフの場合の通信上の振る舞いを説明する図である。 第２の実施の形態における応答成否テーブル作成処理の手順を示したフローチャートである。

符号の説明

１ 通信検知装置
１ａ 通信ログ記憶手段
１ｂ ログ分割手段
１ｃ 分割ログ解析手段
１ｄ 応答成否テーブル記憶手段
１ｅ 判定手段

Claims (6)

1. ネットワークに接続する装置間でやり取りされた通信データに関する情報を記録した通信ログが格納される通信ログ記憶手段から前記通信ログを読み出し、前記通信ログに記録されている前記通信データの発信元と宛先とに基づいて前記通信ログを対象の装置ごとに分割するログ分割手段と、
   前記ログ分割手段によって前記装置ごとに分割された前記通信ログを解析し、前記装置に対する接続要求が行われた前記通信データを抽出するとともに、前記接続要求に対する前記装置からの応答が検出されたか否かに応じて応答成否テーブルを作成して応答成否テーブル記憶手段に格納する分割ログ解析手段と、
   前記応答成否テーブル記憶手段に格納される前記応答成否テーブルに基づいて、前記装置から応答が得られなかった期間が予め決められた判定条件を満たしたときは、ピアツーピア通信が行われたと判定する判定手段と、
   を有することを特徴とする通信検知装置。
2. 前記判定手段は、電源がオンのときに接続要求を受けたときのホストの通信上の振る舞いに応じて取得される前記通信ログと、電源がオフのときに接続要求を受けたときの前記ホストの通信情報の振る舞いに応じて取得される前記通信ログとの差異に基づいて、前記ホストが常時稼働しているサーバであるか、使用時以外は電源がオフされている個人所有のコンピュータであるかを特定して、前記ピアツーピア通信が行われたか否かを判定する、
   ことを特徴とする請求項１記載の通信検知装置。
3. 前記通信ログは、外部ネットワークと、内部ネットワークとの境界に設置されるファイアウォールを介して前記内部ネットワークに出入りされる前記通信データを直接監視できる地点に配置されるネットワーク監視装置によって取得され、
   前記分割ログ解析手段は、分割された前記通信ログから前記宛先の通信アドレスが前記対象の装置のものである前記接続要求を検索し、検索された前記接続要求に対応付けられる応答が前記通信ログから検出されたときは、前記応答成否テーブルに成功を登録し、該応答が前記通信ログから検出できなかったときは前記応答成否テーブルに失敗を登録する、
   ことを特徴とする請求項２記載の通信検知装置。
4. 前記通信ログは、外部ネットワークと、内部ネットワークとの境界に設置されるファイアウォールと、前記通信データの中継を行う中継サーバを介して接続し、前記外部ネットワークに接続する装置からの応答を前記中継サーバからのステータス情報として取得するネットワーク監視装置によって取得され、
   前記分割ログ解析手段は、分割された前記通信ログから前記宛先の通信アドレスが前記対象の装置のものである前記接続要求を検索し、検索された前記接続要求に対応付けられるステータス情報を前記中継サーバから取得し、前記ステータス情報に応じて前記応答成否テーブルに成功または失敗を登録する、
   ことを特徴とする請求項２記載の通信検知装置。
5. ログ分割手段が、ネットワークに接続する装置間でやり取りされた通信データに関する情報を記録した通信ログが格納される通信ログ記憶手段から前記通信ログを読み出し、前記通信ログに記録されている前記通信データの発信元と宛先とに基づいて前記通信ログを対象の装置ごとに分割する手順と、
   分割ログ解析手段が、前記ログ分割手段によって前記装置ごとに分割された前記通信ログを解析し、前記装置に対する接続要求が行われた前記通信データを抽出するとともに、前記接続要求に対する前記装置からの応答が検出されたか否かに応じて応答成否テーブルを作成して応答成否テーブル記憶手段に格納する手順と、
   判定手段が、前記応答成否テーブル記憶手段に格納される前記応答成否テーブルに基づいて、前記装置から応答が得られなかった期間が予め決められた判定条件を満たしたときは、ピアツーピア通信が行われたと判定する手順と、
   を有することを特徴とする通信検知方法。
6. コンピュータを、
   ネットワークに接続する装置間でやり取りされた通信データに関する情報を記録した通信ログが格納される通信ログ記憶手段から前記通信ログを読み出し、前記通信ログに記録されている前記通信データの発信元と宛先とに基づいて前記通信ログを対象の装置ごとに分割するログ分割手段、
   前記ログ分割手段によって前記装置ごとに分割された前記通信ログを解析し、前記装置に対する接続要求が行われた前記通信データを抽出するとともに、前記接続要求に対する前記装置からの応答が検出されたか否かに応じて応答成否テーブルを作成して応答成否テーブル記憶手段に格納する分割ログ解析手段、
   前記応答成否テーブル記憶手段に格納される前記応答成否テーブルに基づいて、前記装置から応答が得られなかった期間が予め決められた判定条件を満たしたときは、ピアツーピア通信が行われたと判定する判定手段、
   として機能させることを特徴とする通信検知プログラム。

Images