JP2016127394A - 情報処理装置、方法およびプログラム - Google Patents

Abstract

【課題】リアルタイムでより正確性の高いプロトコル判定を行うことを課題とする。
【解決手段】情報処理装置に、データが受信される毎に、予め設定された第一のプロトコルの特徴に従って該データを解析することで、通信フローに係るプロトコルが該第一のプロトコルであるか否かを推定する第一の解析部と、第一の解析部による解析結果に拘らず、当該通信フローに属するデータが受信される毎に、予め設定された第二のプロトコルの特徴に従って該データを解析することで、該通信フローに係るプロトコルが該第二のプロトコルであるか否かを推定する第二の解析部と、を備えた。
【選択図】図３

Description

本開示は、プロトコルを判定するための技術に関する。

従来、外部ネットワークからのパケットがＴＣＰによる通信である場合に、パケット中に含まれるデータセグメントのコピーをセッション情報と関連付けして一時的に保留し、セッション情報と同一で最後のデータセグメントを有するパケットを受信すると、同一のセッション情報を有するデータセグメントを組み立てるデータセグメント組立部と、受信したデータセグメントまたは組み立てたデータセグメントを解析し、不正アクセスが含まれている場合には最後に受信したデータセグメントが含まれるパケットを廃棄する不正アクセス解析部と、を備える侵入検知装置が提案されている（特許文献１を参照）。

また、受信されたデータパケットのヘッダーおよびコンテンツに含まれる情報を用いてデータパケットを分類し、ヘッダー情報およびコンテンツの双方に基づいてパケットを処理するフロー命令を決定し、フロー命令を用いてパケットを処理する、データパケット検査方法が提案されている（特許文献２を参照）。

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

従来、通信の分類には、通信プロトコルによる分類が使われており、宛先ポート番号による識別が行なわれてきた。しかし、この方法では、プロトコル標準のポート番号を利用しない通信や、故意にポート番号を偽装した通信について、正しくプロトコルを識別することが出来ない。また、他の識別方法として、通信初期のデータを用いてプロトコルを識別する方法があるが、この方法では、類似したプロトコル（例えば、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）とＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）とＰＯＰ３（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ３）等）について、プロトコル識別の誤りが発生し得る。更に、このような類似プロトコル以外にも、プロトコル標準に任意のメソッドやコマンドを追加して利用することや、プロトコル仕様が改訂され新しいメソッドやコマンドが追加される場合もある。このため、初期データでプロトコルを正しく識別することは困難であり、正しく識別する場合にはプロトコルを一意に識別できるまで全ての受信データを蓄積する必要があり、リアルタイム性に乏しかった。

本開示は、上記した問題に鑑み、リアルタイムでより正確性の高いプロトコル判定を行うことを課題とする。

本開示の一例は、取得されたデータが属する通信フローを識別するフロー管理手段と、前記通信フローに属するデータが受信される毎に、予め設定された第一のプロトコルの特徴に従って該データを解析することで、該通信フローに係るプロトコルが該第一のプロトコルであるか否かを推定する第一の解析手段と、前記第一の解析手段による解析結果に拘
らず、前記通信フローに属するデータが受信される毎に、予め設定された第二のプロトコルの特徴に従って該データを解析することで、該通信フローに係るプロトコルが該第二のプロトコルであるか否かを推定する第二の解析手段と、を備え、前記フロー管理手段は、前記通信フローに属するデータの解析の結果が１または複数の中止条件の何れかを満たした場合に、前記第一の解析手段または前記第二の解析手段による、前記通信フローに係るデータの解析を中止させる、情報処理装置である。

本開示は、情報処理装置、システム、コンピューターによって実行される方法またはコンピューターに実行させるプログラムとして把握することが可能である。また、本開示は、そのようなプログラムをコンピューターその他の装置、機械等が読み取り可能な記録媒体に記録したものとしても把握できる。ここで、コンピューター等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的または化学的作用によって蓄積し、コンピューター等から読み取ることができる記録媒体をいう。

本開示によれば、リアルタイムでより正確性の高いプロトコル判定を行うことが可能となる。

実施形態に係るシステムの構成を示す概略図である。 実施形態に係るネットワーク監視装置のハードウェア構成を示す図である。 実施形態に係るネットワーク監視装置の機能構成の概略を示す図である。 実施形態に係る、フローテーブルの概要を示す図である。 実施形態に係る、データ処理の流れの概要を示すフローチャートである。 実施形態に係る、プロトコル解析／検査処理の流れの概要を示すフローチャートである。 実施形態に係る、解析再開／中止処理の流れの概要を示すフローチャートである。 実施形態に係るシステムの構成のバリエーションを示す概略図である。

以下、本開示に係る情報処理装置、方法およびプログラムの実施の形態を、図面に基づいて説明する。但し、以下に説明する実施の形態は、実施形態を例示するものであって、本開示に係る情報処理装置、方法およびプログラムを以下に説明する具体的構成に限定するものではない。実施にあたっては、実施の態様に応じた具体的構成が適宜採用され、また、種々の改良や変形が行われてよい。

本実施形態では、本開示に係る情報処理装置、方法およびプログラムを、ネットワークを監視するためのシステムにおいて実施した場合の実施の形態について説明する。但し、本開示に係る情報処理装置、方法およびプログラムは、プロトコルを判定するための技術について広く用いることが可能であり、本開示の適用対象は、本実施形態において示した例に限定されない。

＜システムの構成＞
図１は、本実施形態に係るシステム１の構成を示す概略図である。本実施形態に係るシステム１は、複数の情報処理端末９０（以下、「ノード９０」と称する）が接続されるネットワークセグメント２と、ノード９０に係る通信を監視するためのネットワーク監視装置２０と、を備える。また、ネットワークセグメント２内のノード９０は、インターネットや広域ネットワークを介して遠隔地において接続された各種のサーバーと、ルータ１０を介して通信可能である。本実施形態において、ネットワーク監視装置２０は、ネットワ
ークセグメント２のスイッチまたはルータ（図１に示した例では、ルータ１０）と、その上位にある他のスイッチまたはルータと、の間に接続されることで、通過するパケットやフレーム等を取得する。この場合、ネットワーク監視装置２０は、取得したパケットのうち、遮断しなくてもよいパケットについては転送するインラインモードで動作する。

図２は、本実施形態に係るネットワーク監視装置２０のハードウェア構成を示す図である。なお、図２においては、ネットワーク監視装置２０以外の構成（ルータ１０、ノード９０等）については、図示を省略している。ネットワーク監視装置２０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の記憶装置１４、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）１５等の通信ユニット、等を備えるコンピューターである。

図３は、本実施形態に係るネットワーク監視装置２０の機能構成の概略を示す図である。なお、図３においては、ネットワーク監視装置２０以外の構成（ルータ１０およびノード９０等）については、図示を省略している。ネットワーク監視装置２０は、記憶装置１４に記録されているプログラムが、ＲＡＭ１３に読み出され、ＣＰＵ１１によって実行されることで、通信取得部２１、フロー管理部２２、複数のプロトコル解析部２３．１−２３．ｎ（単に何れか１のプロトコル解析部を指す場合は、単に「プロトコル解析部２３」と記載する）、複数の検査部２４．１−２４．ｍ（単に何れか１の検査部を指す場合は、単に「検査部２４」と記載する）およびイベント処理部２５を備える情報処理装置として機能する。なお、本実施形態では、ネットワーク監視装置２０の備える各機能は、汎用プロセッサであるＣＰＵ１１によって実行されるが、これらの機能の一部または全部は、１または複数の専用プロセッサによって実行されてもよい。また、これらの機能の一部または全部は、クラウド技術等を用いて、遠隔値に設置された装置や、分散設置された複数の装置によって実行されてもよい。

通信取得部２１は、ネットワークに接続された端末によって送受信される通信のデータを取得する。なお、本実施形態において、ネットワーク監視装置２０による監視および検知の対象となる「端末」には、ネットワークセグメント２に接続されたノード９０の他、ノード９０とルータ１０を介して通信するその他の装置（他のネットワークに属するノードや外部サーバー等）を含む。

フロー管理部２２は、通信取得部２１によって取得されたデータが属する通信フロー（以下、単に「フロー」とも称する）を識別し、また、夫々のフローに属するデータが受信される毎に、取得されたデータや解析結果、検査結果に基づいてフローテーブルを更新することで、フローを管理する。ここで、フローとは、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ
Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）のコネクション等、１まとまりのデータの送受信を識別するための単位である。

図４は、本実施形態に係る、フローテーブルの概要を示す図である。フローテーブルには、ネットワーク監視装置２０によって取得される通信のフロー毎に、当該フローに係る情報（以下、「フロー関連情報」と称する）が管理されている。本実施形態において、フローはフローＩＤが付されることで識別されており、フロー管理部２２は、フローＩＤをキーとして、フローテーブルから目的のフロー関連情報を索出することが出来る。また、フローは、パケットのヘッダーに含まれるプロトコル番号（但し、偽装されている可能性がある）、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号等を参照することで識別される。このため、新たなフローに係るパケットが受信されると
、フロー管理部２２は、フローＩＤを採番し、先述したフローの識別に用いられる情報との対応関係を保持する。

夫々のフロー関連情報には、各プロトコル解析部２３がその関連付けられたフローに対しデータを継続して解析するかどうかの解析ステータス、およびその解析コンテキストが格納されている。解析ステータスには、「解析する」もしくは「解析しない」が設定される。解析ステータスの初期値は「解析する」である。また、解析コンテキストには、そのプロトコルとフローに関連した検査部２４が検査に必要とする情報と、その検査状況（本実施形態では、「検査項目に該当」、「検査項目に非該当」および「保留」の何れか）が格納される。

また、フロー管理部２２は、対象データの解析結果および検査結果を参照し、フローに属するデータの解析または検査の結果が１または複数の中止条件の何れかを満たした場合に、当該中止条件を満たしたプロトコル解析部２３による、当該フローに係るデータの解析を中止させる。ここで、あるプロトコル解析部２３による解析を中止するための１または複数の中止条件は、フローにおいて当該プロトコルに係る全ての検査項目の検査が完了したこと、フローにおいて当該プロトコルが終了したこと、およびフローの当該プロトコルとしての解釈が失敗したこと、の少なくとも何れかを含む。例えば、ＨＴＴＰ解析部２３．１による解析を中止するための中止条件は、フローにおいてＨＴＴＰに係る全ての検査項目の検査が完了したこと、フローにおいてＨＴＴＰが終了したこと（例えば、ＴＣＰコネクションの終了等）、およびフローのＨＴＴＰとしての解釈が失敗したこと、の少なくとも何れかを含む。また、例えば、ＦＴＰ解析部２３．４による解析を中止するための中止条件は、フローにおいてＦＴＰに係る全ての検査項目の検査が完了したこと、フローにおいてＦＴＰが終了したこと（例えば、ＱＵＩＴコマンドによる終了等）、およびフローのＦＴＰとしての解釈が失敗したこと、の少なくとも何れかを含む。

更に、フロー管理部２２は、あるプロトコル解析部２３によって、あるフローのプロトコルが他のプロトコルに遷移したことが検知された場合に、当該他のプロトコルを担当するプロトコル解析部２３による、当該フローに係るデータの解析を再開させる。例えば、フロー管理部２２は、ＨＴＴＰ解析部２３．１によって、フローがＣＯＮＮＥＣＴメソッドを利用し他のプロトコルに遷移したことが検知された場合に、ＳＳＬ／ＴＬＳ（ＨＴＴＰＳ）解析部２３．２やＦＴＰ解析部２３．４等を含む他のプロトコル解析部２３による、フローに係るデータの解析を再開させる。

更に、フロー管理部２２は、あるプロトコル解析部２３によって、あるフローのプロトコルが当該プロトコル解析部２３が担当するプロトコルであると確定された場合に、他のプロトコル解析部２３による、当該フローに係るデータの解析を中止させる。例えば、フロー管理部２２は、ＨＴＴＰ解析部２３．１によって、フローのプロトコルがＨＴＴＰであると確定された場合に、ＳＩＰ解析部２３．３による、当該フローに係るデータの解析を中止させる。

プロトコル解析部２３は、例えば、ＨＴＴＰ解析部２３．１、ＳＩＰ解析部２３．３およびＦＴＰ解析部２３．４等、ネットワーク監視装置２０が解析の対象とするプロトコル毎に用意され、対象データを並列的に解析する。夫々のプロトコル解析部２３は、他のプロトコル解析部２３による解析結果に拘らず、フローに属するデータが受信される毎に、予め設定されたプロトコルの特徴に従って対象データを解析することで、当該フローに係るプロトコルが当該プロトコルであるか否かを推定する。例えば、ＨＴＴＰ解析部２３．１は、ＳＩＰ解析部２３．３やＦＴＰ解析部２３．４等の解析結果に拘らず、フローに属するデータが受信される毎に、ＨＴＴＰの特徴に従って対象データを解析することで、当該フローに係るプロトコルがＨＴＴＰであるか否かを推定する。

検査部２４は、プロトコル解析部２３によって、フローに係るプロトコルが当該プロトコル解析部２３の担当するプロトコルであると判定された場合に、当該プロトコルに応じて定められた検査項目に従ってデータを検査する。例えば、ＨＴＴＰ検査部２４．１は、ＨＴＴＰ解析部２３．１によってフローに係るプロトコルがＨＴＴＰであると判定された場合に、ＨＴＴＰについて定められた検査項目に従ってデータを検査する。

イベント処理部２５は、プロトコル解析部２３または検査部２４によって、フローにおけるイベントが検知された場合に、当該イベントに係るデータ（証跡）を保存または当該イベントの検知をユーザーに通知する。本実施形態において検知されるイベントとしては、例えば、業務に不要なアプリケーションによるネットワーク上での通信や、プロトコルに沿っていない通信、マルウェアによる通信、等がある。

＜処理の流れ＞
次に、本実施形態に係るシステム１によって実行される処理の流れを、フローチャートを用いて説明する。なお、以下に説明するフローチャートに示された処理の具体的な内容および処理順序は、本開示を実施するための一例である。具体的な処理内容および処理順序は、本開示の実施の形態に応じて適宜選択されてよい。

図５は、本実施形態に係るデータ処理の流れの概要を示すフローチャートである。本実施形態に係るデータ処理は、ネットワーク監視装置２０によって、ネットワーク上を流れるデータが取得される度に実行される。なお、本実施形態では、データが複数のパケットに分割されている場合には、複数のパケットが受信されることで所定の単位のデータが取得される毎に実行される。但し、本フローチャートに示された処理は、パケットが受信される毎に実行されてもよい。

ステップＳ１０１およびステップＳ１０２では、データが取得され、対象データに係るフローが識別される。通信取得部２１は、ネットワーク上を流れるデータを取得する（ステップＳ１０１）。ここで、通信取得部２１は、データが複数のパケットに分割されている場合には、分割された複数のパケットの受信を待つことで、所定の単位のデータを取得する。データが取得されると、フロー管理部２２は、対象データを含むパケットのヘッダー等を参照することで、対象データに係るフローを識別する（ステップＳ１０２）。

より具体的には、フロー管理部２２は、通信取得部２１によって新たに通信（入力パケット）が取得されると、入力パケットの整形、分類、および有効な既存フローへの関連付けを行う。また、ネットワーク監視装置２０は、入力パケットを端末単位（送信元／宛先ＩＰアドレス（ＭＡＣアドレス）単位）、トランスポート層のプロトコル（ＴＣＰ、ＵＤＰ、ＩＣＭＰ等）単位に分類、および既存フローとの関連付けを行う。そして、フロー管理部２２は、フローテーブルを参照することで、識別されたフローに係る情報を取得する。その後、処理はステップＳ１０３へ進む。

ステップＳ１０３では、対象データが、各プロトコル解析部２３による解析の対象であるか否かが判定される。本実施形態では、複数のプロトコル解析部２３が、解析の対象となるプロトコル毎に用意されている。フロー管理部２２は、フローテーブルを参照することで、対象データが、各プロトコル解析部２３による解析の対象であるか否かを判定する。具体的には、フロー管理部２２は、対象データが属するフローの各プロトコルの解析ステータスが「解析する」に設定されているか「解析しない」に設定されているかを判定することで、解析対象であるか否かを判定する。なお、解析ステータスには、対象データがフローにおける２回目以降のデータである場合、前回のプロトコル解析／検査の結果に応じて何れかの値が設定されている（ステップＳ１０５を参照）。対象データがフローにお
ける最初のデータである場合、解析ステータスには、初期値である「解析する」が設定されている。その後、処理はステップＳ１０４へ進む。

ステップＳ１０４では、必要なプロトコル解析部２３に対してプロトコル解析が依頼される。フロー管理部２２は、対象データのフローが解析の対象に設定されているプロトコル解析部２３を呼び出し、対象データのプロトコル解析を依頼する。プロトコル解析部２３による解析処理の詳細は、プロトコル解析／検査処理の流れの概要を示すフローチャート（図６）を参照して後述する。依頼を受けた全てのプロトコル解析部２３から処理が戻されると、処理はステップＳ１０５へ進む。

ステップＳ１０５では、フローテーブルが更新される。各プロトコル解析部２３の処理が終了すると、フロー管理部２２は、プロトコル解析／検査処理の結果（後述するステップＳ２１０における、各プロトコル解析部２３による設定内容）に従って、フローテーブルの解析ステータスを更新し、次回データを待ち合わせる。具体的には、フロー管理部２２は、当該フローについて解析を継続するよう設定したプロトコル解析部２３について、当該フローの当該プロトコルについての解析ステータスを「解析する」へ更新し、当該フローについて解析を中止するよう設定したプロトコル解析部２３について、当該フローの当該プロトコルについての解析ステータスを「解析しない」に更新する。その後、本フローチャートに示された処理は終了する。

図６は、本実施形態に係る、予め定義されたプロトコル毎に実行されるプロトコル解析／検査処理の流れの概要を示すフローチャートである。プロトコル解析部２３および検査部２４は、プロトコル毎に用意されており、本実施形態に係るプロトコル解析／検査処理は、データ処理において、各プロトコルについてのプロトコル解析部２３が呼び出される毎に実行される。即ち、本実施形態では、ＨＴＴＰ、ＦＴＰ、およびＳＳＬ／ＴＬＳ等のプロトコル毎に、ＨＴＴＰ解析部２３．１、ＦＴＰ解析部２３．４およびＳＳＬ／ＴＬＳ解析部２３．２等の各プロトコルに対応したプロトコル解析部２３が用意される。また、プロトコル毎に、ＨＴＴＰ検査部２４．１、ＦＴＰ検査部２４．４およびＳＳＬ／ＴＬＳ検査部２４．２等の各プロトコルに対応した検査部２４が用意される。そして、データが取得される毎にこれらのプロトコル解析部２３．１−２３．ｎおよび検査部２４．１−２４．ｍが呼び出され、並列に実行されることで、１のデータに対してプロトコル毎のプロトコル解析／検査処理が実行される。

ステップＳ２０１では、対象データが、当該プロトコルであるか否かの解析（パース）が行われる。各プロトコル解析部２３は、対象データを参照し、データのパース処理やトランザクションの管理など各プロトコルの必要に応じた解析を行なう。解析は、具体的には、予め定義されたプロトコルのデータパターンとの比較等によって行われる。この際、本実施形態に係るプロトコル解析部２３は、パケットヘッダーに設定されたプロトコル番号等が偽装されている可能性も考慮して、プロトコル番号のみに依拠せずに、対象データが当該プロトコル解析部２３の担当するプロトコルであるか否かを解析する。

各プロトコル解析部２３は、例えば、対象データを当該プロトコル解析部２３の担当するプロトコルとして解析し、対象データが当該プロトコルのデータとして成立するために必須の要素を含んでいるか否かを判定することで、対象データが当該プロトコルであるか否かを解析する。但し、プロトコルの解析に用いられる方法は、本開示における例示に限定されない。例えば、当該プロトコル解析部２３に係るプロトコルのデータパターンとの一致点や不一致点についてポイントを累積し、このポイントと閾値とを比較する方法を用いて、これまでに受信された対象データの当該プロトコルらしさを判定することで、対象データが当該プロトコル解析部２３の担当するプロトコルであるか否かが解析されてもよい。解析の結果得られた情報（例えば、前記ポイント等）はフロー管理部２２へ渡され、
上記説明したステップＳ１０５のフローテーブル更新処理において、解析コンテキストへ格納される。なお、対象データが当該フローに係る２回目以降のデータである場合、即ち、以前に当該フローに係るデータを当該プロトコル解析部２３が解析したことがある場合、解析にあたって、対象データに加えて前回までの解析コンテキストも参照される。その後、処理はステップＳ２０２へ進む。

ステップＳ２０２では、プロトコル解析の結果が判定される。ステップＳ２０１におけるプロトコル解析の結果、対象データのプロトコルが、当該プロトコル解析部２３が対象としているプロトコルであると判定された場合（例えば、ＨＴＴＰ解析部２３．１が、対象データがＨＴＴＰのデータであると判定した場合等）、処理はステップＳ２０３へ進む。一方、プロトコル解析の結果、対象データのプロトコルが、当該プロトコル解析部２３が対象としているプロトコルでないと判定された場合、処理はステップＳ２１０へ進む。

ステップＳ２０３およびステップＳ２０４では、対象データが、当該プロトコルについて予め用意された複数の検査ルールによる検査の対象であるか否かが判定される。各プロトコル解析部２３は、プロトコル解析によって当該プロトコルであると判定された対象データについて、フローテーブルの解析コンテキストを参照することで、解析の進捗にあわせて検査可能かつ、検査結果が明らかでない検査項目を特定する。具体的には、プロトコル解析部２３は、当該プロトコルについて予め設定された各検査項目について、対象データが、例えば対象データが当該フローにおける検査項目を検査可能な段階に相当している等の理由で検査可能であり（ステップＳ２０３）、且つ当該検査項目について未検査であるかまたは検査結果が「保留」である（ステップＳ２０４）場合、その検査項目について対象データを検査可能であると判定する。その後、処理はステップＳ２０５へ進む。

ステップＳ２０５では、各検査部２４に対して検査が依頼される。各プロトコル解析部２３は、ステップＳ２０３およびステップＳ２０４において特定された検査項目について、検査部２４に対して検査を依頼する。検査の依頼を受けた各検査部２４は、解析結果をもとに検査項目を検査し、プロトコル解析部２３へ検査結果をフィードバックする。なお、検査部２４による各検査項目の検査は並列的に処理される。フィードバックされる検査結果は、「検査項目に該当」、「検査項目に非該当」および「保留」の何れかである。ここで、「保留」は、現時点までに受信したデータでは検査の結論が出なかった事を意味する。その後、処理はステップＳ２０６へ進む。

ステップＳ２０６では、フィードバックの結果に応じて、各プロトコルについて解析の継続／中止が決定される。各プロトコル解析部２３は、検査を依頼した各検査部２４からフィードバックされた検査結果を集約し、当該プロトコル解析部２３が担当するプロトコルの解析および検査を継続するか中止するかを決定する。その後、処理はステップＳ２０７へ進む。

具体的には、例えば、当該プロトコルについて、結論が出ていない検査項目がある場合、即ち、結論が「保留」されている検査項目または未検査の検査項目が有る場合、当該プロトコルの解析および検査の継続が決定される。即ち、検査結果が「保留」された検査項目が残っている限り、プロトコル解析部２３は次のデータの解析を継続する。但し、プロトコル解析部２３がプロトコル解釈上の終了を検出した場合、「保留」された検査項目が残っている場合であっても、当該フローの、当該プロトコル解析部２３による解析は終了となる。

また、例えば、当該プロトコルについて、全ての検査項目の結論が出た場合、具体的には、全ての検査項目について「検査項目に該当」または「検査項目に非該当」というフィードバックが得られ、「保留」または未検査の検査項目が無くなった場合、当該プロトコ
ルの解析および検査の中止が決定される。

ステップＳ２０７からステップＳ２０９では、当該プロトコル解析部２３による解析が完了したフローについて、イベント処理が行われる。具体的な判定基準は、ステップＳ２０６における解析の継続／中止の決定のための基準と同様である。即ち、対象データが属するフローについて、当該プロトコルに係る検査が全て完了した（未完了の検査項目が無い）と判定された場合（ステップＳ２０７のＹＥＳ）、または、当該プロトコルの手続き（フロー）等が終了したと判定された場合（ステップＳ２０８のＹＥＳ）に、イベント処理が行われる。各プロトコル解析部２３は、検査結果に基づいて処理するべきイベントがある場合には、イベント処理部２５へイベント処理を依頼する（ステップＳ２０９）。

イベント処理部２５は、処理の依頼を受けて、証跡の保存や管理者へ通知などの処理を行なう。その後、処理はステップＳ２１０へ進む。例えば、イベント処理部２５は、検査の結果、端末が不正な活動を行っていると判定された場合に、当該端末による通信を遮断してもよい。なお、端末が不正な活動を行っていると判定された場合の対処方法は、通信の遮断に限定されない。ネットワーク監視装置２０は、端末が不正な活動を行っていると判定された場合に、アラート（警告）の通知を行ってもよいし、不正な活動を行っている端末の治癒（例えば、マルウェアの除去や脆弱性の除去）を行ってもよい。

ステップＳ２１０では、各プロトコルについて解析の継続／中止が設定される。プロトコル解析部２３は、ステップＳ２０６における決定の結果に従って、当該プロトコルとして次のデータを期待し解析を継続するか中止するかを設定する。また、ステップＳ２０２においてプロトコル解析部２３が解析に失敗したと判定された場合、プロトコル解析部２３は、自身のプロトコルに該当しないと判断し、次データ以降の解析の中止を決定する。その後、処理はステップＳ２１１へ進む。

ステップＳ２１１およびステップＳ２１２では、プロトコルの遷移または確定が検知された場合に、他のプロトコル解析部２３に対して再開／中止依頼が行われる。先述の通り、あるフローに対し、あるプロトコル解析部２３が解析を中止した場合、次回以降の当該フローに属するデータはそのプロトコル解析部２３の解析対象とならない。このため、単一のフローにおいて、解析継続中のプロトコルから、他のプロトコルへの遷移が起こった場合に、本実施形態では、プロトコルの遷移を検知したプロトコル解析部２３から他のプロトコル解析部２３に対し、解析を再開するよう依頼する。

一方、フォーマットが類似したプロトコルに係る複数のプロトコル解析部２３が重複して解析を継続している場合、あるプロトコル解析部２３が、当該フローのプロトコルが自身の担当するプロトコルであると確信した場合でも、他のプロトコル解析部２３が解析を継続してしまう可能性がある。このため、本実施形態では、より確度の高い識別が可能であったプロトコル解析部２３は、他のプロトコル解析部２３に対し、当該他のプロトコル解析部２３の解析を中止するよう依頼する。その後、本フローチャートに示された処理は終了し、処理はデータ処理のステップＳ１０５（図５を参照）へ戻る。

図７は、本実施形態に係る解析再開／中止処理の流れを示すフローチャートである。本フローチャートに示された処理は、各プロトコル解析部２３が、他のプロトコル解析部２３から発行された解析再開／中止の依頼（ステップＳ２１２を参照）を受けたことを契機として、プロトコル解析部２３毎に実行される。

解析再開／中止の依頼を受けたプロトコル解析部２３は、当該依頼に応じるか否かを判定する（ステップＳ３０１）。判定の結果、解析再開の依頼に応じる場合には、当該プロトコル解析部２３として次のデータを期待して解析を再開することを決定する（ステップ
Ｓ３０２）。また、解析中止の依頼に応じる場合には、当該プロトコル解析部２３としての解析を中止することを決定する（ステップＳ３０２）。その後、本フローチャートに示された処理は終了し、処理はデータ処理のステップＳ１０５（図５を参照）へ戻る。

ステップＳ３０２において解析の再開の決定が行われた場合、フロー管理部２２は、フローテーブル中の、当該フローの当該プロトコルに係る解析ステータスを「解析する」に更新する（ステップＳ１０５）。また、ステップＳ３０２において解析の中止の決定が行われた場合、フロー管理部２２は、フローテーブル中の、当該フローの当該プロトコルに係る解析ステータスを「解析しない」に更新する（ステップＳ１０５）。

＜実施例１＞
ここで、本実施形態に係るネットワーク監視装置２０によって、ＨＴＴＰ通信の識別と検査が行われる場合の実施例を説明する。はじめに、ノード９０とサーバーがＴＣＰ３ＷＡＹハンドシェイクをおこない通信を開始すると、フロー管理部２２がこれを識別し、ノード９０対サーバーの通信フローがフローテーブルに登録される。そして、ネットワーク監視装置２０が、ノード９０が発行したＧＥＴリクエストを取得すると、フロー管理部２２がフローを識別し、フローテーブルを参照する。フローテーブルにはプロトコル解析部２３のプロトコル毎にデータ解析フラグが設定されており、初期値は「解析する」である。このため、フロー管理部２２は、データを解析する各プロトコル解析部２３へ受信データと解析コンテキストを参照させて解析を開始する。

ＨＴＴＰ解析部２３．１は、例えば、データ先頭文字列ＧＥＴをＧＥＴメソッドと解釈し、スペースの後の文字列をＵＲＩ、その後のスペースから改行までをＨＴＴＰバージョン文字列と解釈する。この解析結果は解析コンテキストに格納される。メソッド、ＵＲＩ、バージョンを参照するＨＴＴＰの検査項目がある場合、検査結果が確定していなければ、検査をＨＴＴＰ検査部２４．１へ依頼し、検査する。

ＨＴＴＰ検査部２４．１は解析コンテキストを参照し、検査項目に基づいて検査する。検査結果は解析コンテキストへ格納されるが、プロトコル解析の進捗が足りず、結論が出ない場合は検査結果を「保留」として、次回以降のデータを待つ。ＨＴＴＰ解析部２３．１は、ＨＴＴＰ検査部２４．１の検査結果に「保留」があるか、未検査の項目がある場合、検査のために次回以降のデータが必要であるため、解析を継続する。一方、例えばＳＭＢ解析部２３．５は、期待するＳＭＢマジックがなく解釈できるデータではないため、解析失敗として解析を中止する。

＜実施例２＞
次に、本実施形態に係るネットワーク監視装置２０によって、「検査項目Ｘ：通信がＨＴＴＰ／１．１通信であった場合にＨｏｓｔヘッダーが設定されているか否か」を検査するが実行される場合の実施例を説明する。

取得された１つ目のデータが「ＧＥＴ ／ ＨＴＴＰ／１．１」であり、２つ目のデータが「Ｈｏｓｔ： ａａａ．ｂｂｂ．ｃｃｃ」である場合、１つ目のデータをＨＴＴＰ解析部２３．１が解析し、メソッド、ＵＲＩ、バージョンまで解析が成功し、解析コンテキストに格納する。ＨＴＴＰ検査部２４．１は、検査項目Ｘについて、この解析コンテキストを参照して検査を行うが、この時点ではＨｏｓｔヘッダーの情報が無く検査の結論を出せない。このため、検査結果は「保留」となり、次回のデータが待ち受けられる。ＨＴＴＰ解析部２３．１は、検査結果が「保留」であるため、フローテーブルを「解析する」に更新する。

続いて２つ目のデータがＨＴＴＰ解析部２３．１によって解析され、メソッド、ＵＲＩ
、バージョンに加え、Ｈｏｓｔヘッダーが存在することが分かり、この情報が解析コンテキストに格納される。ＨＴＴＰ検査部２４．１は、検査項目Ｘについて、この解析コンテキストを参照し、ＨＴＴＰ／１．１通信であり且つＨｏｓｔヘッダーが設定されていることを確認することで、当該検査結果を「検査項目Ｘに該当」と判定する。

一方、もし、取得された１つ目のデータが「ＧＥＴ ／ ＨＴＴＰ／１．０」であった場合、１つ目のデータをＨＴＴＰ解析部２３．１が解析し、メソッド、ＵＲＩ、バージョンまで解析が成功するが、ＨＴＴＰ検査部２４．１は、検査項目Ｘについて、ＨＴＴＰのバージョンが１．０であるため、１つ目のデータの時点で「検査項目Ｘに非該当」と判定する。そして、検査項目が検査項目Ｘのみであるならば、ＨＴＴＰ解析部２３．１は、解析を継続する必要が無いため、以降の解析を中止する。

＜実施例３＞
次に、本実施形態に係るネットワーク監視装置２０によって、ノード９０がＨＴＴＰのＣＯＮＮＥＣＴメソッドを使用したリクエストを送信後、プロキシサーバーから「２００
Ｃｏｎｎｅｃｔｉｏｎ Ｅｓｔａｂｌｉｓｈｅｄレスポンス」を受信し、トンネルを利用したＨＴＴＰＳ通信を開始する通信フローのデータが取得された場合の実施例を説明する。

ＨＴＴＰ解析部２３．１は、フロー最初の取得データを用いてＣＯＮＮＥＣＴメソッドを解釈できるため、解析は継続される。ＳＳＬ／ＴＬＳ解析部２３．２等の他のプロトコル解析部２３は、ＣＯＮＮＥＣＴリクエストのフォーマットが自身のプロトコルに従って解釈できないため、解析に失敗し以降の解析を中止する。続いて、ネットワーク監視装置２０によって「２００レスポンス」が受信されると、このデータは前回の解析に成功し解析を継続中であるＨＴＴＰ解析部２３．１が解析する。

ここで、「２００レスポンス」はＣＯＮＮＥＣＴメソッドの成功を表しているため、以降、プロキシサーバーがトンネルとなり、任意のプロトコルによる通信が可能であることがわかる。このため、ＨＴＴＰ解析部２３．１は、解析を中止した他のプロトコル解析部２３に対し、解析再開の依頼を行なう。再開の依頼を受け入れた各プロトコル解析部２３は、次回以降のデータについて解析を再開する。ここで、トンネル通信がＨＴＴＰＳであった場合、次のデータは「Ｃｌｉｅｎｔ Ｈｅｌｌｏ」である。解析を再開したＳＳＬ／ＴＬＳ解析部２３．２は、このデータについて解析に成功し、以降解析を継続する。一方、ＨＴＴＰ解析部２３．１や他のプロトコル解析部２３は解析に失敗するため、以降の解析を中止する。

＜バリエーション＞
上記実施形態では、ネットワーク監視装置２０が、スイッチまたはルータと、その上位にある他のスイッチまたはルータと、の間に接続されることでノード９０によって送受信されるパケットやフレーム等を取得し、遮断しなくてもよいパケットについては転送するインラインモードで動作する例について説明した（図１を参照）。但し、上記実施形態に示したネットワーク構成は、本開示を実施するための一例であり、実施にあたってはその他のネットワーク構成が採用されてもよい。

例えば、ネットワーク監視装置２０は、スイッチまたはルータ（図１に示した例では、ルータ１０）のモニタリングポート（ミラーポート）に接続されることで、ノード９０によって送受信されるパケットやフレーム等を取得してもよい（図８を参照）。この場合、ネットワーク監視装置２０は、取得したパケットを転送しないパッシブモードで動作する。また、例えば、ネットワーク監視装置２０は、モニタリングポート（ミラーポート）に接続されず、単にネットワークセグメント２に接続されている場合であっても、ネットワ
ークセグメント２を流れるフレームを、自身のＭＡＣアドレス宛でないものも含めて全て取得することで、ノード９０によって送受信されるパケットやフレーム等を取得することが出来る。この場合も、ネットワーク監視装置２０は、パッシブモードで動作する。また、例えば、ネットワーク監視装置２０は、ルータまたはスイッチに内包されてもよい。

＜効果＞
本実施形態に係る情報処理装置、方法およびプログラムによれば、リアルタイムでより正確性の高いプロトコル判定を行うことが可能となる。更に、本実施形態によれば、プロトコルを一意に識別できるまでの受信データを蓄積する必要がないため、少ないデータ蓄積量で、正確性の高いプロトコル判定を行うことが出来る。

１ システム
２０ ネットワーク監視装置
９０ ノード

Claims (11)

1. 取得されたデータが属する通信フローを識別するフロー管理手段と、
   前記通信フローに属するデータが受信される毎に、予め設定された第一のプロトコルの特徴に従って該データを解析することで、該通信フローに係るプロトコルが該第一のプロトコルであるか否かを推定する第一の解析手段と、
   前記第一の解析手段による解析結果に拘らず、前記通信フローに属するデータが受信される毎に、予め設定された第二のプロトコルの特徴に従って該データを解析することで、該通信フローに係るプロトコルが該第二のプロトコルであるか否かを推定する第二の解析手段と、を備え、
   前記フロー管理手段は、前記通信フローに属するデータの解析の結果が１または複数の中止条件の何れかを満たした場合に、前記第一の解析手段または前記第二の解析手段による、前記通信フローに係るデータの解析を中止させる、
   情報処理装置。
2. 前記第一の解析手段によって前記通信フローに係るプロトコルが前記第一のプロトコルであると判定された場合に、該第一のプロトコルに応じて定められた検査項目に従って前記データを検査する第一の検査手段と、
   前記第二の解析手段によって前記通信フローに係るプロトコルが前記第二のプロトコルであると判定された場合に、該第二のプロトコルに応じて定められた検査項目に従って前記データを検査する第二の検査手段と、を更に備え、
   前記フロー管理手段は、前記通信フローに属するデータの解析または検査の結果が１または複数の中止条件の何れかを満たした場合に、前記第一の解析手段または前記第二の解析手段による、前記通信フローに係るデータの解析を中止させる、
   請求項１に記載の情報処理装置。
3. 前記第一の解析手段による解析を中止するための前記１または複数の中止条件は、前記通信フローにおいて前記第一のプロトコルに係る全ての検査項目の検査が完了したこと、前記通信フローにおいて該第一のプロトコルが終了したこと、および前記通信フローの該第一のプロトコルとしての解釈が失敗したこと、の少なくとも何れかを含み、
   前記第二の解析手段による解析を中止するための前記１または複数の中止条件は、前記通信フローにおいて前記第二のプロトコルに係る全ての検査項目の検査が完了したこと、前記通信フローにおいて該第二のプロトコルが終了したこと、および前記通信フローの該第二のプロトコルとしての解釈が失敗したこと、の少なくとも何れかを含む、
   請求項２に記載の情報処理装置。
4. 前記フロー管理手段は、前記第一の解析手段による解析結果および前記第二の解析手段による解析結果を保持し、前記通信フローに属するデータが受信される毎に更新する、
   請求項１から３の何れか一項に記載の情報処理装置。
5. 前記フロー管理手段は、保持されている解析結果を参照することで、前記第一の解析手段または前記第二の解析手段による、前記通信フローに係るデータの解析を中止するか否かを判定する、
   請求項４に記載の情報処理装置。
6. 前記フロー管理手段は、前記第一の解析手段によって、前記通信フローのプロトコルが前記第二のプロトコルに遷移したことが検知された場合に、前記第二の解析手段による、前記通信フローに係るデータの解析を再開させ、
   前記フロー管理手段は、前記第二の解析手段によって、前記通信フローのプロトコルが前記第二のプロトコル以外のプロトコルに遷移したことが検知された場合に、前記第一の
   解析手段による、前記通信フローに係るデータの解析を再開させる、
   請求項１から５の何れか一項に記載の情報処理装置。
7. 前記フロー管理手段は、前記第一の解析手段によって、前記通信フローのプロトコルが該第一のプロトコルであると確定された場合に、前記第二の解析手段による、前記通信フローに係るデータの解析を中止させ、
   前記フロー管理手段は、前記第二の解析手段によって、前記通信フローのプロトコルが該第二のプロトコルであると確定された場合に、前記第一の解析手段による、前記通信フローに係るデータの解析を中止させる、
   請求項１から６の何れか一項に記載の情報処理装置。
8. 前記解析手段または前記検査手段によって、前記通信フローにおけるイベントが検知された場合に、当該イベントに係るデータを保存または当該イベントの検知をユーザーに通知するイベント処理手段を更に備える、
   請求項２に記載の情報処理装置。
9. 前記ネットワークに接続された端末による通信のデータを取得する通信取得手段を更に備える、
   請求項１から８の何れか一項に記載の情報処理装置。
10. コンピューターが、
    取得されたデータが属する通信フローを識別するフロー管理ステップと、
    前記通信フローに属するデータが受信される毎に、予め設定された第一のプロトコルの特徴に従って該データを解析することで、該通信フローに係るプロトコルが該第一のプロトコルであるか否かを推定する第一の解析ステップと、
    前記第一の解析ステップにおける解析結果に拘らず、前記通信フローに属するデータが受信される毎に、予め設定された第二のプロトコルの特徴に従って該データを解析することで、該通信フローに係るプロトコルが該第二のプロトコルであるか否かを推定する第二の解析ステップと、を実行し、
    前記フロー管理ステップでは、前記通信フローに属するデータの解析の結果が１または複数の中止条件の何れかを満たした場合に、前記第一の解析ステップまたは前記第二の解析ステップによる、前記通信フローに係るデータの解析を中止させる、
    方法。
11. コンピューターを、
    取得されたデータが属する通信フローを識別するフロー管理手段と、
    前記通信フローに属するデータが受信される毎に、予め設定された第一のプロトコルの特徴に従って該データを解析することで、該通信フローに係るプロトコルが該第一のプロトコルであるか否かを推定する第一の解析手段と、
    前記第一の解析手段による解析結果に拘らず、前記通信フローに属するデータが受信される毎に、予め設定された第二のプロトコルの特徴に従って該データを解析することで、該通信フローに係るプロトコルが該第二のプロトコルであるか否かを推定する第二の解析手段と、として機能させ、
    前記フロー管理手段は、前記通信フローに属するデータの解析の結果が１または複数の中止条件の何れかを満たした場合に、前記第一の解析手段または前記第二の解析手段による、前記通信フローに係るデータの解析を中止させる、
    プログラム。

Images