TOP > 国内特許検索 > パケットデータ抽出装置、パケットデータ抽出装置の制御方法、制御プログラム、コンピュータ読み取り可能な記録媒体 > 明細書

明細書 :パケットデータ抽出装置、パケットデータ抽出装置の制御方法、制御プログラム、コンピュータ読み取り可能な記録媒体

発行国 日本国特許庁(JP)
公報種別 特許公報(B2)
特許番号 特許第5536962号 (P5536962)
登録日 平成26年5月9日(2014.5.9)
発行日 平成26年7月2日(2014.7.2)
発明の名称または考案の名称 パケットデータ抽出装置、パケットデータ抽出装置の制御方法、制御プログラム、コンピュータ読み取り可能な記録媒体
国際特許分類 H04L  12/28        (2006.01)
FI H04L 12/28 200
請求項の数または発明の数 7
全頁数 15
出願番号 特願2013-544236 (P2013-544236)
出願日 平成24年11月8日(2012.11.8)
国際出願番号 PCT/JP2012/079000
国際公開番号 WO2013/073448
国際公開日 平成25年5月23日(2013.5.23)
優先権出願番号 2011250179
優先日 平成23年11月15日(2011.11.15)
優先権主張国 日本国(JP)
審査請求日 平成26年2月12日(2014.2.12)
特許権者または実用新案権者 【識別番号】503360115
【氏名又は名称】独立行政法人科学技術振興機構
発明者または考案者 【氏名】河野 健二
【氏名】山田 浩史
早期審査対象出願または早期審理対象出願 早期審査対象出願
個別代理人の代理人 【識別番号】110000338、【氏名又は名称】特許業務法人HARAKENZO WORLD PATENT & TRADEMARK
審査官 【審査官】大石 博見
参考文献・文献 特開2011-70549(JP,A)
特開2009-49972(JP,A)
調査した分野 H04L 12/28
特許請求の範囲 【請求項1】
通信途中のパケットから目的とするデータを抽出するパケットデータ抽出装置であって、
通信途中のパケットを一時的に記憶する一時記憶部に格納されている対象パケットのペイロードを参照して、当該対象パケットのペイロードに含まれるメッセージのプロシージャ名を確認するプロシージャ名確認手段と、
上記プロシージャ名確認手段によって確認されたプロシージャ名にあらかじめ対応付けられた、目的データの格納位置を示すデータ位置情報に従って、該データ位置情報によって特定される目的パケットのペイロードから目的データを取得する目的データ取得手段と、を備えることを特徴とするパケットデータ抽出装置。
【請求項2】
対象パケットがメッセージの先頭部分を格納しているパケットであるか否かを確認するパケット確認手段をさらに備え、
上記プロシージャ名確認手段は、上記パケット確認手段によって、対象パケットがメッセージの先頭部分を格納していることが確認された場合のみ、当該対象パケットのペイロードに含まれるメッセージのプロシージャ名を確認するものであることを特徴とする請求項1に記載のパケットデータ抽出装置。
【請求項3】
上記目的データ取得手段は、上記データ位置情報によって指定された位置のデータのみを取得することを特徴とする請求項1または2に記載のパケットデータ抽出装置。
【請求項4】
VMMに設けられることを特徴とする請求項1または2に記載のパケットデータ抽出装置。
【請求項5】
通信途中のパケットから目的とするデータを抽出するパケットデータ抽出装置の制御方法であって、
通信途中のパケットを一時的に記憶する一時記憶部に格納されている対象パケットのペイロードを参照して、当該対象パケットのペイロードに含まれるメッセージのプロシージャ名を確認するプロシージャ名確認ステップと、
上記プロシージャ名確認ステップにて確認されたプロシージャ名にあらかじめ対応付けられた、目的データの格納位置を示すデータ位置情報に従って、該データ位置情報によって特定される目的パケットのペイロードから目的データを取得する目的データ取得ステップと、を含むことを特徴とするパケットデータ抽出装置の制御方法。
【請求項6】
請求項1または2に記載のパケットデータ抽出装置の上記各手段としてコンピュータを機能させるための制御プログラム。
【請求項7】
請求項6に記載の制御プログラムを記録したコンピュータ読み取り可能な記録媒体。
発明の詳細な説明 【技術分野】
【0001】
本発明は、通信途中のパケットから目的とするデータを抽出するパケットデータ抽出装置、パケットデータ抽出装置の制御方法、制御プログラム、コンピュータ読み取り可能な記録媒体に関する。
【背景技術】
【0002】
例えば、ファイルメタデータ改竄型ルートキット(rootkit)は、コンピュータウィルスの一形態であり、感染するとサービスの停止や情報漏洩に繋がり、サービスの品質に深刻な被害を与える。ファイルメタデータ改竄型ルートキットは、オペレーティングシステムカーネル内のデータを変更するため、一般的なアンチウィルスソフトでの検出が極めて困難である。このルートキットを検出するためには、ネットワークシステムを構築して、仮想マシンモニタでやり取りされるパケットを監視することが極めて有効である。この例のように、従来、通信中のパケットから情報を抽出することが行われている。
【0003】
ここで、図6を参照して、パケットを用いた通常のメッセージ送受信の概略について説明する。
【0004】
図6に示すように、メッセージの送信の場合、まず、送信側のアプリケーション(図中左側のApplication)が、メッセージを作成し(S51)、OS(operating system)(図中左側のOS)にメッセージ送信をリクエストする(S52)。そして、OSが、取得したメッセージをパケットに分割し、ヘッダを付けて(S53)、受信側へ送信する(S54)。
【0005】
また、メッセージの受信の場合、受信側のOS(図中右側のOS)が、パケットを受信し(S54)、ヘッダを外すとともに、ヘッダに従ってメッセージを作成し(S55)、作成したメッセージをアプリケーション(図中右側のApplication)へ送信する(S56)。そして、アプリケーションが、OSから取得したメッセージをメモリに格納する(S57)。
【0006】
このように、メッセージの送信側のOSは、NIC(Network Interface Card)に送る際に、メッセージをパケットに変換する。このとき、OSは、送信先でメッセージの復元する際に必要な情報、例えば、シーケンス番号(順番),ポート番号(接続の識別子)等を含むヘッダをパケットに付与する。一方、メッセージの受信側のOSは、パケットのヘッダを参照して、パケットからメッセージを構築する。
【0007】
つづいて、図7および図8を参照して、パケットを用いて送受信されるメッセージからデータを抽出する従来手法について説明する。ここでは、VMM(Virtual Machine Monitor)において、メッセージから目的とするデータを抽出する場合を例に説明する。
【0008】
図7に示すように、送信側のOS(図中左側のOS)は、VMMが提供する仮想Network Interface Cardにパケットを送る。つまり、VMMは、OSによって分割されたパケットを取得する。そして、VMMは、取得したパケットを受信側のOS(図中右側のOS)へ送信するとともに、取得したパケットからメッセージを再構成して、得たい情報である目的データを得る。
【0009】
具体的には、図8に示すように、VMMは、取得したパケットのヘッダ情報を確認し(S61)、ヘッダ以外(ペイロード)をコピーし(S62)、その後、パケットを送信する(S63)。これと同時に、VMMは、コピーしたデータからメッセージを構築し(S64)、メッセージから目的データを抽出する(S65)。
【0010】
このように、VMMは、パケットのペイロードのコピーを生成して、パケットのヘッダ情報を基に配置する。すなわち、VMMは、パケットに分割されていたメッセージを再構成した後で、目的データを抽出する。
【先行技術文献】
【0011】

【非特許文献1】TCP Reassembler for Layer7-aware Network Intrusion Detection/Prevention Systems, Miyuki Hanaoka, Makoto Shimamura, and Kenji Kono, IEICE Trans. on Information and Systems, Vol.E90-D, No.12, pp.2019-2032, Dec. 2007
【発明の概要】
【発明が解決しようとする課題】
【0012】
しかし、上記の従来手法によれば、VMMは、パケットから必要な情報を抽出する際に、パケットのペイロードのコピーを生成し、当該コピーをパケットのヘッダ情報を基に配置して、メッセージとして構成した後で、当該メッセージから得たい情報を抽出していた。すなわち、ペイロードのコピーを生成し、メッセージとして構成する必要があった。具体的には、図7の例では、VMMは、目的データ“E”を取得するために、順次取得した3つのパケットのペイロードのコピーを作成した上で、メッセージに再構成していた。
【0013】
このように、従来手法によれば、ペイロードのコピーを作成するために、処理に時間がかかるとともに、メッセージの再構成は、OSでも行われる処理であるため、オーバヘッドとなっていた。すなわち、パケットから必要な情報を抽出する際に、大きなオーバヘッドが発生してしまい、稼働しているサービスの品質への影響が大きかった。
【0014】
本発明は、上記の問題点に鑑みてなされたものであり、その目的は、パケットから必要なデータを効率よく抽出することができるパケットデータ抽出装置、パケットデータ抽出装置の制御方法、制御プログラム、コンピュータ読み取り可能な記録媒体を実現することにある。
【課題を解決するための手段】
【0015】
上記課題を解決するために、本発明の一態様に係るパケットデータ抽出装置は、通信途中のパケットから目的とするデータを抽出するパケットデータ抽出装置であって、通信途中のパケットを一時的に記憶する一時記憶部に格納されている対象パケットのペイロードを参照して、当該対象パケットのペイロードに含まれるメッセージのプロシージャ名を確認するプロシージャ名確認手段と、上記プロシージャ名確認手段によって確認されたプロシージャ名にあらかじめ対応付けられた、目的データの格納位置を示すデータ位置情報に従って、該データ位置情報によって特定される目的パケットのペイロードから目的データを取得する目的データ取得手段と、を備える。
【0016】
また、上記課題を解決するために、本発明の一態様に係るパケットデータ抽出装置の制御方法は、通信途中のパケットから目的とするデータを抽出するパケットデータ抽出装置の制御方法であって、通信途中のパケットを一時的に記憶する一時記憶部に格納されている対象パケットのペイロードを参照して、当該対象パケットのペイロードに含まれるメッセージのプロシージャ名を確認するプロシージャ名確認ステップと、上記プロシージャ名確認ステップにて確認されたプロシージャ名にあらかじめ対応付けられた、目的データの格納位置を示すデータ位置情報に従って、該データ位置情報によって特定される目的パケットのペイロードから目的データを取得する目的データ取得ステップと、を含む。
【発明の効果】
【0017】
それゆえ、本発明の一態様に係るパケットデータ抽出装置およびパケットデータ抽出装置の制御方法によれば、ネットワークを流れる通信パケットすべてをメッセージに変換するのではなく、変換するパケットを適宜取捨選択するため、効率良くファイルのメタデータを取得できるという効果を奏する。また、従来のようにメッセージをコピーしないので、処理が早いという効果を奏する。よって、オーバヘッドがなく、稼働しているサービスが被るオーバヘッドを抑えて、パケットから必要なデータを効率よく抽出できるという効果を奏する。
【図面の簡単な説明】
【0018】
【図1】本発明の実施形態を示すものであり、パケットデータ抽出装置の構成の詳細を示す機能ブロック図である。
【図2】図1に示したパケットデータ抽出装置の動作を示す模式図である。
【図3】図1に示したパケットデータ抽出装置の処理の流れを示すフローチャートである。
【図4】図1に示したパケットデータ抽出装置を適用した、ファイルメタデータ改竄型ルートキット検知システムの概略を示すブロック図である。
【図5】図4に示したファイルメタデータ改竄型ルートキット検知システムで用いるデータ位置情報の例を示す説明図である。
【図6】従来技術を示すものであり、パケットを用いたメッセージ送受信の概略を示す説明図である。
【図7】従来技術を示すものであり、パケットを用いて送受信されるメッセージからデータを抽出する従来手法を示す模式図である。
【図8】図7に示した従来手法の処理の流れを示すフローチャートである。
【発明を実施するための形態】
【0019】
以下、本発明の一実施形態について、詳細に説明する。図1~図5に基づいて、本実施形態に係るパケットデータ抽出装置10について説明すれば以下のとおりである。

【0020】
(1.装置構成)
図1を参照して、パケットデータ抽出装置10の構成について説明する。図1は、パケットデータ抽出装置10の構成の詳細を示す機能ブロック図である。

【0021】
パケットデータ抽出装置10は、通信途中のパケットを一時的に記憶するバッファ(一時記憶部)20に格納されているパケットから、目的とするデータ(目的データ)を抽出する装置である。本実施の形態では、パケットデータ抽出装置10は、VMM(仮想マシンモニタ)100に、その一部として組み込まれているものとする。なお、パケットデータ抽出装置10は、パケットの送信側の装置に、パケットを送信するアプリケーションの下位層として設けられてよいし、パケットの受信側の装置に、パケットを受信するアプリケーションの下位層として設けられてよい。また、パケットデータ抽出装置10は、パケットの送信側の装置とパケットの受信側の装置とを繋ぐネットワーク上に設けられてよい。

【0022】
本実施の形態では、サーバ-クライアント間通信に適用した場合を例に説明する。図2において(図1も同様)、図中左側のApplicationがサーバ、図中右側のApplicationがクライアントである。クライアントはサーバへリクエストメッセージを送信し、サーバはクライアントからのリクエストメッセージに呼応して、データメッセージをクライアントへ送信する。なお、本実施の形態では、クライアントからサーバへのリクエストを記述したメッセージを「CtoSメッセージ」、「CtoSメッセージ」を分割したパケットを「StoCパケット」と記載する。また、リクエストメッセージに呼応してサーバから送信されるデータメッセージを「StoCメッセージ」、「StoCメッセージ」を分割したパケットを「StoCパケット」と記載する。

【0023】
詳細には、図1に示すように、パケットデータ抽出装置10は、パケット確認部(パケット確認手段)11、プロシージャ名確認部(プロシージャ名確認手段)12、目的データ取得部(目的データ取得手段)13、位置情報記憶部14を備えて構成されている。

【0024】
パケット確認部11は、対象パケットPのヘッダを確認することにより、対象パケットPがメッセージの先頭部分を格納しているパケットであるか否かを確認する。すなわち、パケット確認部11は、メッセージの先頭部分を格納している先頭パケットPhを検出する。特に、パケット確認部11は、CtoSメッセージが分割された対象パケットP(CtoSパケット)を検出し、検出した対象パケットPのヘッダを確認する。そして、対象パケットPがCtoSメッセージの先頭部分を格納しているパケットであるか否かを確認する。

【0025】
また、パケット確認部11は、プロシージャ名確認部12によって確認されたプロシージャ名にあらかじめ対応付けられた、目的データの格納位置を示すデータ位置情報14b(後述)に従って、上記CtoSメッセージに呼応するStoCメッセージが分割された対象パケットP(StoCパケット)を検出する。そして、検出した対象パケットPのヘッダを確認することにより、データ位置情報14bによって特定される目的パケットPtを検出する。すなわち、パケット確認部11は、目的データを含む目的パケットPtを検出する。

【0026】
プロシージャ名確認部12は、メッセージのプロシージャ名の格納位置を示すプロシージャ名位置情報14a(後述)に従って、バッファ20に格納されている対象パケットP(CtoSパケット)のペイロードを参照する。そして、当該対象パケットPのペイロードに含まれるCtoSメッセージのプロシージャ名を確認する。なお、本実施の形態では、プロシージャ名を利用するが、メッセージのプロシージャが識別可能であれば、各プロシージャにユニークに割り当てられたID番号等の他の情報を利用してもよい。

【0027】
特に、本実施の形態では、パケット確認部11によって、対象パケットP(CtoSパケット)がCtoSメッセージの先頭部分を格納していることが確認された場合のみ、プロシージャ名確認部12は、当該対象パケットP(CtoSパケット)のペイロードに含まれるCtoSメッセージのプロシージャ名を確認するものとする。通常、CtoSメッセージのプロシージャ名は、当該CtoSメッセージの先頭部分に存在する。そのため、当該CtoSメッセージを分割した複数のCtoSパケットのうちの先頭のCtoSパケットに含まれることになる。よって、CtoSメッセージにプロシージャ名を含むCtoSパケットを検出するためには、CtoSパケットのヘッダを参照して、CtoSメッセージの先頭部分を含む先頭パケットPhであるか否かを判定すればよい。それゆえ、ヘッダを参照して、CtoSメッセージの先頭部分を含まないCtoSパケットであれば、それ以後の処理を省略できる。よって、プロシージャ名確認部12は、CtoSパケットのヘッダを参照するだけで、CtoSメッセージのプロシージャ名を含むCtoSパケットを検出できるため、効率がよい。

【0028】
目的データ取得部13は、CtoSメッセージに呼応するStoCメッセージが分割されたStoCパケットにおいて、プロシージャ名確認部12によって確認されたプロシージャ名にあらかじめ対応付けられた、目的データの格納位置を示すデータ位置情報14b(後述)に従って、該データ位置情報14bによって特定される目的パケットPtのペイロードから目的データを取得する。特に、本実施の形態では、目的データ取得部13は、データ位置情報14bによって指定された位置のデータのみを取得するものとする。また、目的データ取得部13は、目的パケットPtのペイロードから目的データを取得する際、ペイロードの先頭からメッセージ変換を行うが、目的データを取得した時点でメッセージ変換を終了する。

【0029】
位置情報記憶部14は、プロシージャ名位置情報14aおよびデータ位置情報14bをあらかじめ記憶している。

【0030】
プロシージャ名位置情報14aは、CtoSメッセージのプロシージャ名の当該CtoSメッセージにおける格納位置を示す。なお、本実施の形態では、プロシージャ名のCtoSメッセージにおける格納位置は、メッセージのプロトコルに応じて決められており、同じプロトコルではプロシージャ間で共通であるものとする。

【0031】
データ位置情報14bは、プロシージャのプロシージャ名と、当該プロシージャのStoCメッセージから取得するデータ(目的データ)のデータ名および当該StoCメッセージにおける格納位置とが対応付けられた情報である。すなわち、データ位置情報14bを参照することで、プロシージャ名に対応付けられた目的データのデータ名と、当該目的データのStoCメッセージにおける格納位置と、が分かる。

【0032】
(2.位置情報)
さらに、図2に示す具体例に沿って、パケットデータ抽出装置10において、位置情報記憶部14にあらかじめ与えておく2種類の位置情報(プロシージャ名位置情報14a、データ位置情報14b)について説明する。図2は、パケットデータ抽出装置10の動作を示す模式図である。なお、ここでは、メッセージのプロトコルがNFS(Network File System)プロトコルであり、ファイルメタデータを抽出する場合を例に説明する。また、図2には、クライアントが送信したCtoSメッセージに呼応するStoCメッセージが分割されたStoCパケットを、パケットデータ抽出装置10が処理する過程を示している。なお、クライアントが送信したCtoSメッセージを処理する過程は、図2では省略されているが、図2の記載と後述する動作の説明から理解できる。

【0033】
上述のように、パケットデータ抽出装置10には、プロシージャ名位置情報14aおよびデータ位置情報14bがあらかじめ位置情報記憶部14に記憶されている。

【0034】
プロシージャ名位置情報14aは、プロシージャ名の位置を示す情報(例えば、「メッセージの先頭byte目から」)である。すなわち、メッセージのどの位置にプロシージャ名があるかを示している。具体的には、図2に示すように、「プロシージャ名の位置: 80byte目」のように記述できる。

【0035】
ここで、NFSプロトコルでは、メッセージ内のプロシージャ名が含まれている位置が決まっている。よって、プロシージャ名確認部12は、プロシージャ名位置情報14aに従ってパケットのペイロードを参照すれば、プロシージャ名を抽出できる。すなわち、プロシージャ名を抽出するために、パケットをすべてスキャンする必要はない。

【0036】
次に、データ位置情報14bは、プロシージャ名と、取得するデータ名およびその位置とを対応付けた情報である。すなわち、プロシージャ名毎に、どのデータをどの位置から抽出できるかを示している。具体的には、図2の例では、「GETATTRには、Inodeが118byte目に、File Sizeが150byte目に格納されている」等の内容の情報が得られる。

【0037】
ここで、NFSプロトコルでは、各プロシージャのメッセージに含まれるデータおよびその位置が決まっている。つまり、プロシージャによって、メッセージに含まれるデータおよびその位置が異なっている。そこで、目的データ取得部13は、データ位置情報14bに従ってペイロードを参照すれば、データを抽出できる。すなわち、目的とするデータを抽出するために、ペイロードからメッセージを構築する必要はない。

【0038】
また、パケットのヘッダにはパケットサイズおよびシーケンス番号が含まれている。そのため、各パケットのパケットサイズおよびシーケンス番号から、当該パケットのペイロードのデータがパケットに分割される前のメッセージのどの部分に該当するかが分かる。このことを利用して、パケット確認部11は目的データを含む目的パケットPtを検出する。

【0039】
また、NFSプロトコルのメッセージからファイルメタデータを抽出する場合、ファイルメタデータを含むプロシージャのみをデータ位置情報14bに登録しておくことで、不必要なプロシージャのパケットを処理しないようにできる。なお、NFSプロトコルでは、全22種類のプロシージャ中、15種類がファイルメタデータを含むプロシージャであり、そのすべてが1個のパケットによって送信可能な長さのメッセージを有する。すなわち、これら15種のプロシージャを対象とする場合、常に先頭パケットPhにファイルメタデータ(目的データ)が含まれることになる。

【0040】
(3.動作)
次に、図3を参照して、パケットデータ抽出装置10の処理の流れを説明する。図3はパケットデータ抽出装置10の処理の流れを示すフローチャートである。

【0041】
バッファ20にはVMM100を通過する通信途中のパケットが順次、一時的に格納される。なお、バッファ20に格納されており、パケットデータ抽出装置10が処理中のパケットを対象パケットPと記す。

【0042】
パケットデータ抽出装置10は、バッファ20に格納されている対象パケットPを順次検出しながら、以下の処理を行う。

【0043】
まず、パケット確認部11が、バッファ20に格納されている対象パケットP(CtoSパケット)のヘッダを順次確認することにより、CtoSメッセージの先頭部分を含むCtoSパケットの先頭パケットPhを検出する(S11;先頭パケット確認ステップ)。

【0044】
次に、プロシージャ名確認部12が、プロシージャ名位置情報14aに従って、ステップ11にて検出されたCtoSメッセージの先頭パケットPhのペイロードからメッセージのプロシージャ名を確認する(S12;プロシージャ名確認ステップ)。

【0045】
次に、目的データ取得部13が、ステップS12にて確認されたプロシージャ名にあらかじめ対応付けられたデータ位置情報14bを、位置情報記憶部14から取得する(S13;データ位置情報取得ステップ)。

【0046】
次に、ステップS13にて取得されたデータ位置情報14bに従って、パケット確認部11が、上記CtoSメッセージに呼応するStoCメッセージが分割されたStoCパケットを検出する。そして、パケット確認部11は、検出したStoCパケットから、データ位置情報14bによって特定される位置(目的パケットPtの位置)のデータを含む目的パケットPtを検出する(S14;目的パケット確認ステップ)。

【0047】
このとき、データ位置情報14bが示す位置がStoCメッセージの先頭パケットPhのペイロードに含まれるメッセージ内にあれば、StoCメッセージの先頭パケットPhが目的パケットPtとなる。また、図2に示すように、データ位置情報14bが示す位置が3番目のStoCパケットのペイロードに含まれるStoCメッセージ内にあれば、3番目のStoCパケットが目的パケットPtとなる。この場合、パケット確認部11が、2番目、3番目のStoCパケットのヘッダを順次確認して、3番目のStoCパケットをパケットPtとして検出する。

【0048】
最後に、目的データ取得部13が、ステップS14にて検出された目的パケットPtのペイロードから目的データを取得する(S15;目的データ取得ステップ)。

【0049】
(4.まとめ)
以上のように、パケットデータ抽出装置10によれば、仮想マシンモニタと呼ばれるソフトウェアレイヤにおいて、パケットレベルで、ネットワークファイルシステムプロトコルからファイルのメタデータを効率的に抽出することができる。すなわち、パケットデータ抽出装置10は、ネットワークを流れる通信パケットすべてをメッセージに変換するのではなく、変換するパケットを適宜取捨選択することで、効率良くファイルのメタデータを取得することができる。詳細には、パケットデータ抽出装置10は、従来のようにStoCメッセージをコピーしないので、処理が早い。また、StoCメッセージを構築しないので、オーバヘッドがなく、稼働しているサービスが被るオーバヘッドを抑えることができる。

【0050】
なお、本実施の形態では、NFSプロトコルを例に説明したが、これに限定されない。すなわち、適用可能なプロトコルとしては、NFSプロトコルのように、プロシージャを送信してファイルを操作するプロトコルであればよい。また、プロシージャ毎に、目的とするデータのメッセージにおける位置があらかじめ規定されていればよい。具体例としては、NFSプロトコルの他、FTP(File Transfer Protocol)プロトコル、HTTP(Hyper Text Transfer Protocol)プロトコルが挙げられる。

【0051】
(5.適用例)
以下、上記パケットデータ抽出装置10の適用例について説明する。

【0052】
(5.1.ルートキット検知)
ファイルメタデータ改竄型ルートキットは、コンピュータウィルスの一形態であり、感染するとサービスの停止や情報漏洩に繋がり、サービスの品質に深刻な被害を与える。ファイルメタデータ改竄型ルートキットは、オペレーティングシステムカーネル内のデータを変更するため、一般的なアンチウィルスソフトでの検出が極めて困難である。なお、VMWatcherは、すでに知られたファイルメタデータ改竄型ルートキットを検知するが、未知のそれには無力である。Strider Ghostbusterは、未知のファイルメタデータ改竄型ルートキットを検知可能であるが、稼働しているサービスの品質への影響は大きい。

【0053】
ファイルメタデータ改竄型ルートキットによるサービスの停止や情報漏洩は、サービス提供者側にとっては深刻であるため、システムがそれに感染しているかを監視することが必要である。そして、ファイルメタデータ改竄型ルートキットを検出するために、ネットワークシステムを構築して、仮想マシンモニタでやり取りされるパケットを監視することが極めて有効である。ただし、稼働しているサービスが被るオーバヘッドをできるだけ抑えることも必要である。

【0054】
そこで、ファイルメタデータ改竄型ルートキットの検知機構に、上述したパケットデータ抽出装置10を組み込むことで、仮想マシン上で動作するアプリケーションやオペレーティングシステムが被るオーバヘッドを抑えつつ、ルートキットの監視を実現することができる。

【0055】
図4は、パケットデータ抽出装置10を適用した、ファイルメタデータ改竄型ルートキット検知システムの概略を示すブロック図である。また、図5は、ファイルメタデータ改竄型ルートキット検知システムで用いるデータ位置情報の例を示す説明図である。図5には、上述したNFSプロトコルのプロシージャのうち、ファイルメタデータを含む15種類のプロシージャが挙げられている。

【0056】
図4に示すVMMには、受信したファイルのメタデータをパケットから抽出するために、パケットデータ抽出装置10が組み込まれている。そして、アプリケーションは、パケットデータ抽出装置10がパケットから抽出したファイルメタデータと、OSが取得したファイルメタデータとの内容を比較する。そして、それら2つのファイルメタデータが一致していなければ、OSがファイルメタデータ改竄型ルートキットに感染していると判断できる。

【0057】
なお、詳細には、VM viewが、ファイルシステム関連のシステムコールの引数・返り値(stat(),fstat(),getdent()等)を取得する。一方、VMM View(パケットデータ抽出装置10)が、ネットワークファイルシステムNFSのメッセージからファイルメタデータを取得する。そして、VM内のviewとVMM内のviewとを比較して、一致していなければ、ルートキットに感染していると判断する。

【0058】
このように、パケットデータ抽出装置10を、ファイルメタデータ改竄型ルートキットの検知機構に組み込むことで、仮想マシン上で動作するアプリケーションやオペレーティングシステムが被るオーバヘッドを抑えつつ、ルートキットの監視を実現することができる。よって、ルートキットが行うサービス停止や情報漏洩といった被害を防止することに大きく貢献することができる。

【0059】
(5.2.ファイルアクセスモニタ)
パケットデータ抽出装置10は、VMM100において、NFSプロトコルを監視するため、OSやアプリケーションを変更することなく、ファイルのアクセス数やアクセスパターンを取得することができる。よって、ファイル配置の最適化や冗長化に有効である。具体的には、近いタイミングにアクセスされるファイル群を同じディレクトリに配置してディスクアクセスを削減したり、アクセス頻度の高いファイルは複製を作成して負荷を分散するなどの措置が可能となる。

【0060】
(5.3.ファイルアクセス制御)
パケットデータ抽出装置10は、OSやアプリケーションの設定を変更することなくファイルへのアクセス制御が可能である。よって、ファイル改竄を防止することができる。すなわち、たとえOSがウィルスに犯されたとしても、VMMは犯されていないので、アクセス禁止に設定しておいたファイルにはアクセスできない。

【0061】
(6.補足)
最後に、パケットデータ抽出装置10の各ブロック、特にパケット確認部11、プロシージャ名確認部12、データ取得部13は、ハードウェアロジックによって構成してもよいし、次のようにCPUを用いてソフトウェアによって実現してもよい。

【0062】
後者の場合、パケットデータ抽出装置10は、各機能を実現するプログラムの命令を実行するCPU(central processing unit)、上記プログラムを格納したROM(read only memory)、上記プログラムを展開するRAM(random access memory)、上記プログラムおよび各種データを格納するメモリ等の記憶装置(記録媒体)などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアであるパケットデータ抽出装置10の制御プログラムのプログラムコード(実行形式プログラム、中間コードプログラム、ソースプログラム)をコンピュータで読み取り可能に記録した記録媒体を、上記パケットデータ抽出装置10に供給し、そのコンピュータ(またはCPUやMPU)が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。

【0063】
上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ系、フロッピー(登録商標)ディスク/ハードディスク等の磁気ディスクやCD-ROM/MO/MD/DVD/CD-R等の光ディスクを含むディスク系、ICカード(メモリカードを含む)/光カード等のカード系、あるいはマスクROM/EPROM/EEPROM(登録商標)/フラッシュROM等の半導体メモリ系などを用いることができる。

【0064】
また、パケットデータ抽出装置10を通信ネットワークと接続可能に構成し、上記プログラムコードを通信ネットワークを介して供給してもよい。この通信ネットワークとしては、特に限定されず、例えば、インターネット、イントラネット、エキストラネット、LAN、ISDN、VAN、CATV通信網、仮想専用網(virtual private network)、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、通信ネットワークを構成する伝送媒体としては、特に限定されず、例えば、IEEE1394、USB、電力線搬送、ケーブルTV回線、電話線、ADSL回線等の有線でも、IrDAやリモコンのような赤外線、Bluetooth(登録商標)、802.11無線、HDR、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。

【0065】
本発明は上述した実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、実施形態に開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。

【0066】
以上より、本発明に係るパケットデータ抽出装置は、通信途中のパケットから目的とするデータを抽出するパケットデータ抽出装置であって、通信途中のパケットを一時的に記憶する一時記憶部に格納されている対象パケットのペイロードを参照して、当該対象パケットのペイロードに含まれるメッセージのプロシージャ名を確認するプロシージャ名確認手段と、上記プロシージャ名確認手段によって確認されたプロシージャ名にあらかじめ対応付けられた、目的データの格納位置を示すデータ位置情報に従って、該データ位置情報によって特定される目的パケットのペイロードから目的データを取得する目的データ取得手段と、を備えることを特徴としている。

【0067】
また、本発明に係るパケットデータ抽出装置の制御方法は、通信途中のパケットから目的とするデータを抽出するパケットデータ抽出装置の制御方法であって、通信途中のパケットを一時的に記憶する一時記憶部に格納されている対象パケットのペイロードを参照して、当該対象パケットのペイロードに含まれるメッセージのプロシージャ名を確認するプロシージャ名確認ステップと、上記プロシージャ名確認ステップにて確認されたプロシージャ名にあらかじめ対応付けられた、目的データの格納位置を示すデータ位置情報に従って、該データ位置情報によって特定される目的パケットのペイロードから目的データを取得する目的データ取得ステップと、を含むことを特徴としている。

【0068】
上記の構成によれば、対象パケットのペイロードに含まれるメッセージのプロシージャ名を確認し、該プロシージャ名にあらかじめ対応付けられた、目的データの格納位置を示すデータ位置情報に従って、該データ位置情報によって特定される目的パケットのペイロードから目的データを取得する。

【0069】
したがって、データ位置情報を参照することによって、プロシージャ名が分かれば、目的データを格納した目的パケットを特定できるため、プロシージャ名を確認した後は、目的パケットの検出と目的パケットのペイロードから目的データの取得を行えばよい。

【0070】
このように、ネットワークを流れる通信パケットすべてをメッセージに変換するのではなく、変換するパケットを適宜取捨選択するため、効率良くファイルのメタデータを取得できるという効果を奏する。また、従来のようにメッセージをコピーしないので、処理が早いという効果を奏する。よって、オーバヘッドがなく、稼働しているサービスが被るオーバヘッドを抑えて、パケットから必要なデータを効率よく抽出できるという効果を奏する。

【0071】
さらに、本発明に係るパケットデータ抽出装置は、対象パケットがメッセージの先頭部分を格納しているパケットであるか否かを確認するパケット確認手段をさらに備え、上記プロシージャ名確認手段は、上記パケット確認手段によって、対象パケットがメッセージの先頭部分を格納していることが確認された場合のみ、当該対象パケットのペイロードに含まれるメッセージのプロシージャ名を確認するものであることを特徴としている。

【0072】
上記の構成によれば、さらに、対象パケットがメッセージの先頭部分を格納していることが確認された場合のみ、当該対象パケットのペイロードに含まれるメッセージのプロシージャ名を確認する。

【0073】
通常、メッセージのプロシージャ名は、当該メッセージの先頭部分に存在するため、当該メッセージを分割した複数のパケットのうちの先頭のパケットに含まれることになる。そこで、メッセージにプロシージャ名を含むパケットを検出するためには、パケットのヘッダを参照して、メッセージの先頭部分を含む先頭パケットであるか否かを判定すればよい。そして、メッセージの先頭部分を含まないパケットであれば、それ以後の処理を省略できる。よって、メッセージのプロシージャ名を含むパケットを効率良く検出できるという効果を奏する。

【0074】
さらに、本発明に係るパケットデータ抽出装置は、上記目的データ取得手段は、上記データ位置情報によって指定された位置のデータのみを取得することを特徴としている。

【0075】
上記の構成によれば、さらに、データ位置情報には目的データの位置が示されているため、データ位置情報によって指定された位置のデータを取得すれば、目的データが取得できる。よって、データ位置情報によって指定された位置のデータのみを取得することで、パケットから必要なデータを効率よく抽出できるという効果を奏する。

【0076】
さらに、本発明に係るパケットデータ抽出装置は、VMMに設けられることを特徴としている。

【0077】
上記の構成によれば、さらに、VMMに設けることによって、OSやアプリケーションを変更することなく、ファイルメタデータを取得して、プロトコルを監視することができる。よって、種々の応用が可能となる。

【0078】
なお、上記パケットデータ抽出装置は、コンピュータによって実現してもよく、この場合には、コンピュータを上記各手段として動作させることにより上記のパケットデータ抽出装置をコンピュータにて実現させる制御プログラム、およびそれを記録したコンピュータ読み取り可能な記録媒体も、本発明の範疇に入る。
【産業上の利用可能性】
【0079】
本発明のパケットデータ抽出装置は、稼働しているサービスが被るオーバヘッドをできるだけ抑えて、パケットから必要なデータを抽出することができるため、ファイルメタデータ改竄型ルートキット検知、ファイルアクセスモニタ、ファイルアクセス制御等に利用することができる。
【符号の説明】
【0080】
10 パケットデータ抽出装置(パケットデータ抽出装置)
11 パケット確認部(パケット確認手段)
12 プロシージャ名確認部(プロシージャ名確認手段)
13 目的データ取得部(目的データ取得手段)
14b データ位置情報
20 バッファ(一時記憶部)
100 VMM
P 対象パケット
S11 先頭パケット確認ステップ
S12 プロシージャ名確認ステップ
S13 データ位置情報取得ステップ
S14 目的パケット確認ステップ
S15 目的データ取得ステップ
図面
【図1】
0
【図2】
1
【図3】
2
【図4】
3
【図5】
4
【図6】
5
【図7】
6
【図8】
7