JP2007272628A - 情報検知処理方法及び装置 - Google Patents

Abstract

【課題】アプリケーションレイヤのデータ検査の処理の一部をハードウェア処理にオフロードし、ソフトウェア処理の負荷を軽減できる情報検知処理装置を提供する。
【解決手段】フロー情報検索部２１は、入力データのフローが、ソフトウェア処理対象であるか否かを判断する。ソフトウェア処理対象であれば、ソフトウェア処理部１１で入力データの検査を行う。ソフトウェア処理対象でない場合には、条件判定部２２にて、ソフトウェア処理へ切り替える条件が成立しているか否かを判定する。成立している場合には、ソフトウェア処理部１１で入力データの検査を行い、成立していない場合には、ハードウェア処理部２３で検査を行う。
【選択図】図２

Description

本発明は、情報検知処理方法及び装置に関し、更に詳しくは、ネットワークトラヒックをデータ処理してアプリケーションデータの情報検知を行う情報検知処理方法及び装置に関する。

ネットワークトラヒックをデータ処理して、アプリケーションデータの情報検知を行う技術がある。情報検知とは不正アクセスや迷惑トラヒック、ウィルスなどを含むトラヒックをデータから特定する検知処理を指す。ネットワークパケットの検知処理において、ソフトウェア処理からハードウェア処理に情報検知処理をオフロードし、ソフトウェア処理の負担を軽減する技術がある（例えば特許文献１参照）。特許文献１では、ソフトウェア処理によるファイアウォール処理の前処理を行うプレフィルタリングモジュールを用いる。プレフィルタリングモジュールは、制御情報を含むパケットを、ファイアウォール処理に転送する。ファイアウォールは、該当セッションの通過可否を判定し、その結果を、プレフィルタリングモジュールに通知する。通過可と判定された場合には、パケット転送をプレフィルタリングモジュールで行い、ファイアウォール処理の負担を軽減する。プレフィルタリングモジュールにオフロードされた処理は、タイムアウト、又は、セッションが終了するという制御情報を受信するまで継続される。
特表２００３−５２５５５７号公報

特許文献１に記載の技術は、主に、ＴＣＰ／ＩＰなどのセッションのパケットフィルタリング処理には効果的である。しかし、特許文献１に記載の処理と同様な処理を、アプリケーションレイヤの検査を行う侵入検知装置や、ウィルス検知装置などに適用することは困難である。これは、侵入検知処理では、アプリケーションプロトコルの検知処理やアプリケーションが転送するデータ形式に応じたさまざまな処理が必要であり、特許文献１のファイアウォール処理に相当するソフトウェア処理で、以降の全てのパケットの転送状態を決定できないからである。すなわち、１つのアプリケーションセッション中には、ソフトウェアでの詳細検査が必要な箇所が、複数の箇所に散在しており、先頭箇所だけの検査では不十分で、プレフィルタリングモジュールへのオフロードが機能しないという問題があった。

アプリケーションレイヤのデータ検査にあたっては、単純なパタンマッチのみならず、プロトコルデータの構造解析やデータの復号、圧縮データの伸張などを行ってから、不正データか否かの検査を行う必要もある。このような処理内容は、１つのセッションで一意に決まるものではなく、アプリケーションデータの構造に基づいて、対象となる処理を選択する必要がある。このような背景から、一般に、アプリケーションレイヤのデータ検査では、ソフトウェア処理によって検査が行われているが、ソフトウェア処理では、ＣＰＵ負荷が増大して、処理性能の向上が困難であるという問題があった。

本発明は、上記従来技術の問題点を解消し、アプリケーションレイヤのデータ検査の処理の一部をハードウェア処理にオフロードし、ソフトウェア処理の負荷を軽減できる情報検知処理方法及び装置を提供することを目的とする。

上記目的を達成するために、本発明の情報検知処理方法は、アプリケーションレイヤの通信トラヒックデータに基づいて、ハードウェア処理又はソフトウェア処理により、フロー単位で情報検知を行う情報検知処理装置における情報検知処理方法であって、入力データに対応するフローが、ソフトウェア処理対象であるか否かを判断し、前記入力データに対応するフローが、ソフトウェア処理対象であると判断すると、ソフトウェア処理により情報検知を行い、ソフトウェア処理対象でないと判断すると、フローデータの内容に基づいて、フローごとに設定されるソフトウェア処理対象に切り替える条件が成立しているか否かを判定し、前記条件が成立していると判定すると、入力データに対応するフローをソフトウェア処理対象に設定してソフトウェア処理により情報検知を行い、前記ソフトウェア処理での情報検知が終了すると、前記フローに対してソフトウェア処理対象の設定を解除することを特徴とする。

本発明の情報検知処理方法では、ソフトウェア処理対象に設定されていないフローについて、ソフトウェア処理に切り替える条件が成立したか否かを判定し、条件が成立したと判定すると、情報検知を、ソフトウェア処理により行う。本発明では、ソフトウェアでの詳細検査が必要な箇所でソフトウェア処理に切り替わるように、ソフトウェア処理への切り替え条件を設定することで、１つのアプリケーションセッション中の所望の箇所をソフトウェアで処理し、その他の箇所をハードウェアで処理できる。また、ソフトウェア処理による詳細な検査において、これ以降のデータに対してはソフトウェア処理で処理する必要がないと判断した場合には、ソフトウェア処理対象の設定を解除して、以降のデータをハードウェア処理によって検査する。このようにすることで、アプリケーションレイヤのデータ検査の処理の一部を効率的にハードウェア処理にオフロードすることができ、ソフトウェア処理の負荷を軽減することができる。

本発明の情報検知処理方法では、前記条件が成立していないと判定すると、ハードウェア処理により情報検知を行う構成を採用できる。ソフトウェア処理対象に設定されていない箇所のうちで、ソフトウェア処理対象への切り替え条件が成立していない箇所をハードウェア処理で検査することで、必要な箇所のみをソフトウェアで詳細に検査でき、ソフトウェア処理の負荷を軽減できる。

本発明の情報検知処理方法は、前記条件が成立しているか否かの判定では、前記入力データのフローのプロトコル種別に対応して設定された所定のキーワードを前記入力データから抽出すると、前記条件が成立していると判定する構成を採用できる。

本発明の情報検知処理方法は、前記ソフトウェア処理では、情報検知を終了すると、入力データのフローの処理内容に基づいて、前記ソフトウェア処理対象に切り替える条件を個別に設定する構成を採用できる。ソフトウェア処理では、データ検査の結果、特定の部分をハードウェア処理によって検査させた後に、ソフトウェア処理に復帰したい場合がある。この場合には、ソフトウェア処理側から、ソフトウェア処理へ切り替える条件を設定することにより、ソフトウェア処理が意図した箇所で、ソフトウェア処理に復帰させることができる。

本発明の情報検知処理方法では、前記条件が成立しているか否かの判定では、ソフトウェア処理によって指定されたデータサイズを処理すると、前記ソフトウェア処理へ切り替える条件が成立していると判定する構成を採用できる。例えば、ＨＴＴＰプロトコルのＨＴＴＰリクエストに対するレスポンス方向のデータにおけるファイルのデータ本体部分について、ソフトウェア処理による詳細な検査が不要であった場合には、ソフトウェア処理側から、そのファイル本体分のサイズのデータをハードウェア処理で処理したことを、ソフトウェア処理へ切り替える条件として設定する。このようにすることで、ソフトウェア処理による検査が不要な部分を読み飛ばして、必要な箇所のみを、ソフトウェア処理で検査できる。

本発明の情報検知処理方法では、前記条件が成立しているか否かの判定では、ソフトウェア処理によって指定された、入力データのフローに依存する特定の文字列を抽出すると、前記ソフトウェア処理へ切り替え条件が成立していると判定する構成を採用できる。この場合には、特定の文字列の抽出を契機として、ソフトウェア処理に復帰できる。なお、ソフトウェア処理へ切り替える条件については、上記したものを、単独で、或いは、組み合わせて設定できる。組み合わせて設定した場合には、組み合わされた複数の条件のうちの何れかに該当したときに、条件が成立したと判定すればよい。

本発明の情報検知処理装置は、アプリケーションレイヤの通信トラヒックデータに基づいて、フロー単位で情報検知を行う情報検知処理装置であって、入力データを入力するデータ入力部と、ハードウェア処理により、前記入力データの情報検知を行うハードウェア処理部と、ソフトウェア処理により、前記入力データの情報検知を行うソフトウェア処理部と、フローごとに、ソフトウェア処理対象であるか、又は、ハードウェア処理対象であるかを示す情報を記憶するフロー管理情報を参照して、前記入力データのフローが、ソフトウェア処理対象であるか否かを取得するフロー情報検索部と、前記フロー情報検索部が、ソフトウェア処理対象である旨の情報を取得すると、前記ソフトウェア処理部で前記情報検知を行わせ、ソフトウェア処理対象でない旨の情報を取得すると、フローデータの内容に基づいて、ソフトウェア処理に切り替える条件が成立しているか否かを判定し、条件が成立していると判定すると、前記ソフトウェア処理部で前記情報検知を行わせ、成立していないと判定すると、前記ハードウェア処理部で前記情報検知を行わせる条件判定部とを備え、前記ソフトウェア処理部は、情報検知を終了すると、前記フロー管理情報の前記入力データに対応するフローをハードウェア処理対象に変更することを特徴とする。

本発明の情報検知処理装置では、入力データのフローがソフトウェア処理対象であれば、ソフトウェア処理部によって、情報検知を行う。ソフトウェア処理対象でない場合には、フローデータの内容に基づいて、ソフトウェア処理へ切り替える条件が成立しているか否かを判定し、成立している場合には、ソフトウェア処理部で情報検知を行い、成立していない場合には、ハードウェア処理部で情報検知を行う。本発明では、ソフトウェアでの詳細検査が必要な箇所でソフトウェア処理部による情報検知に切り替わるように、ソフトウェア処理への切り替え条件を設定することで、１つのアプリケーションセッション中の所望の箇所をソフトウェア処理部で処理し、その他の箇所をハードウェア処理部で処理することができる。また、ソフトウェア処理部による詳細な検査において、これ以降のデータに対してはソフトウェア処理部で処理する必要がないと判断した場合には、ソフトウェア処理対象の設定を解除して、以降のデータをハードウェア処理部によって検査する。これにより、アプリケーションレイヤのデータ検査の処理の一部を効率的にハードウェア処理部にオフロードすることができ、ソフトウェア処理部の負荷を軽減することができる。

本発明の情報検知処理装置では、前記フロー管理情報が、フローごとに、前記ソフトウェア処理に切り替える条件が成立しているか否かを判定するための条件情報を有しており、前記条件判定部は、該条件情報を参照して、ソフトウェア処理に切り替える条件が成立しているか否かを判定する構成を採用できる。

本発明の情報検知処理装置は、ネットワークを介してデータを受信し、該受信したデータにレイヤ４受信処理を行って前記データ入力部にデータを入力するレイヤ４受信処理部を更に備える構成を採用できる。また、前記ハードウェア処理部又は前記ソフトウェア処理部による情報検知処理後のデータに対してレイヤ４送信処理を行い、データを送信するレイヤ４送信処理部を更に備える構成を採用できる。

本発明の情報検知処理装置では、前記条件判定部は、前記入力データのフローのプロトコル種別に対応して設定された所定のキーワードを前記入力データから抽出すると、ソフトウェア処理へ切り替える条件が成立していると判定する構成を採用できる。

本発明の情報検知処理装置では、前記ソフトウェア処理部は、情報検知を終了すると、入力データのフローの処理内容に基づいて、前記ソフトウェア処理に切り替える条件を個別に設定する構成を採用できる。ソフトウェア処理部は、データ検査の結果、特定の部分をハードウェア処理部によって検査させた後に、ソフトウェア処理部による検査に復帰したい場合がある。この場合には、ソフトウェア処理部側から、ソフトウェア処理へ切り替える条件を設定することにより、ソフトウェア処理部が意図した箇所で、ソフトウェア処理部による検査に復帰させることができる。

本発明の情報検知処理装置では、前記条件判定部は、前記ソフトウェア処理部によって指定されたデータサイズを処理すると、前記ソフトウェア処理へ切り替える条件が成立していると判定する構成を採用できる。また、前記条件判定部は、前記ソフトウェア処理部によって指定された、入力データのフローに依存する特定の文字列を抽出すると、前記ソフトウェア処理へ切り替える条件が成立していると判定する構成を採用できる。

本発明の情報検知処理方法及び装置では、ソフトウェア処理対象に設定されていないフローについて、ソフトウェア処理に切り替える条件が成立したか否かを判定し、条件が成立したと判定すると、情報検知を、ソフトウェア処理により行う。本発明では、ソフトウェアでの詳細検査が必要な箇所でソフトウェア処理に切り替わるように、ソフトウェア処理への切り替え条件を設定することで、１つのアプリケーションセッション中の所望の箇所をソフトウェアで処理し、その他の箇所をハードウェアで処理でき、アプリケーションレイヤのデータ検査の処理の一部を効率的にハードウェア処理にオフロードすることで、ソフトウェア処理の負荷を軽減することができる。

以下、図面を参照し、本発明の実施の形態を詳細に説明する。図１は、本発明の第１実施形態の情報検知処理装置の構成を示している。情報検知処理装置１００は、ＣＰＵ１０、データ処理部２０、ネットワークインタフェース３１、３２、レイヤ４受信処理部３３、及び、レイヤ４送信処理部３４を備える。情報検知処理装置１００は、対となったネットワークインタフェース３１、３２に接続された２つの端末２０１、２０２間の通信内容を、アプリケーションレイヤレベルで検査する装置である。

端末２０１、２０２は、ネットワークインタフェース３１、３２を介して、ＩＰパケットベースのデータ通信で、データの送受信を行う。ネットワークインタフェース３１及び３２は、それぞれレイヤ３までのパケット送受信処理を行う。レイヤ４受信処理部３３は、ネットワークインタフェース３１、３２が受信したパケットのレイヤ４の終端処理を行う。レイヤ４受信処理部３３は、例えば、レイヤ４として広く使われているＴＣＰ（Transmission Control Protocol、ＲＦＣ７９３）の終端処理を行い、順序制御された状態のパケットデータをデータ処理部２０に受け渡す。また、ＵＤＰ（User Datagram Protocol、ＲＦＣ７６８）の場合では、チェックサム検査等の終端処理を行なった後のパケットデータを、データ処理部２０に受け渡す。

図２は、ＣＰＵ１０及びデータ処理部２０の詳細な構成を示している。ＣＰＵ１０は、ソフトウェア処理部１１を有する。データ処理部２０は、フロー情報検索部２１、条件判定部２２、ハードウェア処理部２３、及び、選択部２４を有する。端末２０１、２０２間の通信内容の検査は、ソフトウェア処理部１１又はハードウェア処理部２３で行われる。ハードウェア処理部２３は、入力データに対して、パタンチェックや文字列検索などによりデータ検査処理を行う。ソフトウェア処理部１１は、入力データに対して、プロトコルの不正判定やデータのデコード、圧縮の伸張などの前処理を行った上で、パタンチェックや文字列検索などによるデータ検査処理を行う。選択部２４は、ソフトウェア処理部１１又はハードウェア処理部２３で検査されたデータを、レイヤ４送信処理部３４に出力する。

フロー情報検索部２１は、アプリケーションを特定する単位であるフロー情報を元に検索処理を行い、該当フローが、ソフトウェア処理部１１によるソフトウェア処理の対象であるか否かを示す情報を取得する。フロー情報は、ＩＰアドレス(送信元、宛先)、レイヤ４のプロトコル、及び、ポート番号で規定される。具体的には、送信元ＩＰアドレス、宛先ＩＰアドレス、ＴＣＰポート番号（発信元、宛先）で規定される。これらが逆になったものについても、同一のフローとなる。例えば、発信元（ＩＰ１，ポート番号１）→宛先（ＩＰ２，ポート番号２）のパケットと、発信元（ＩＰ２，ポート番号２）→宛先（ＩＰ１，ポート番号１）のパケットとは、同一のフローに属していて互いに反対の方向のフローである。すなわち、あるアプリケーションにおいて、クライアントとサーバ間で通信する双方向のデータの組をフローと定義する。フローを特定する情報としては、いくつか考えられ、例えば、ヘッダ情報そのものとすることができる。或いは、レイヤ４受信処理部３３でフローを特定し、そのフローに装置内の識別子を付与してその識別子でフローを特定してもよい。以下では、フローの特定には、フロー識別子を用いるものとする。

条件判定部２２は、フロー情報検索部２１によって、ソフトウェア処理対象である旨の情報が取得されたフローについては、入力データをソフトウェア処理部１１に受け渡し、入力データをソフトウェア処理部１１で検査させる。条件判定部２２は、フロー情報検索部２１によって、ソフトウェア処理対象でない、つまり、ハードウェア処理部２３によるハードウェア処理対象である旨の情報が取得されたフローについては、ソフトウェア処理部１１での検査に切り替える条件が成立しているか否かを判断し、成立していると判断したときには、入力データをソフトウェア処理部１１に受け渡す。また、条件が成立していないと判断したときには、入力データをハードウェア処理部２３に受け渡す。

図３（ａ）は、フロー情報検索部２１及び条件判定部２２の詳細な構成を示している。フロー情報検索部２１は、フロー状態検索部４１とフロー管理テーブル４２とを有する。フロー管理テーブル４２の具体例を、同図（ｂ）に示す。フロー管理テーブル４２は、フローの識別子単位で、ソフトウェア処理対象であるか否かを示す情報と、ハードウェア処理部２３で検査を行う際のハードウェア処理部２３に対する指示情報と、条件判定部２２でハードウェア処理とソフトウェア処理とを切り替える際の条件を示す指示情報とを有する。このフロー管理テーブル４２には、個々のフローに依存した情報が格納される。フロー状態検索部４１は、フロー管理テーブル４２から、入力データのフローに該当するエントリを抽出する。

条件判定部２２は、条件判定処理部４３とプロトコル条件テーブル４４とを有する。プロトコル条件テーブル４４の具体例を、図３（ｃ）に示す。プロトコル条件テーブル４４は、プロトコル種別ごとに、複数の条件が設定されている。例えば、同図（ｃ）では、ＨＴＴＰのプロトコルに対して、「条件１」として「ｕｐ：メソッド文字列」が設定され、「条件２」として「ｄｏｗｎ：データ長」が設定されている。これら条件は、プロトコルごとに事前に設定することができるほか、ソフトウェア処理部１１からの指示によって、動的に設定することもできる。条件判定処理部４３は、ハードウェア処理対象のフローについて、フロー管理テーブル４２（同図（ｂ））の条件判定部２２への指示情報と、プロトコル条件テーブル４４で設定された条件とに基づいて、入力データを、ハードウェア処理部２３による検査から、ソフトウェア処理部１１による検査に切り替えるか否かを判断する。

図４は、情報検知処理装置１００の動作手順を示している。フロー情報検索部２１は、レイヤ４受信処理部３３から、レイヤ４組み立て後のパケットを受信すると（ステップＡ１）、フロー管理テーブル４２の入力データに対応するフロー情報を検索し（ステップＡ２）、当該フローがソフトウェア処理対象であるか否かを示す情報を取得する。条件判定部２２は、当該フローがソフトウェア処理対象である否かを判断し（ステップＡ３）、ソフトウェア処理対象であると判断すると、入力データを、ソフトウェア処理部１１に受け渡す。ソフトウェア処理部１１は、受け取ったデータの検査を実行する（ステップＡ４）。

ソフトウェア処理部１１は、入力データの検査を行い、検査後のデータを、選択部２４に出力する。その際、ソフトウェア処理部１１は、ソフトウェア処理での検査が完了したか否かを判断し（ステップＡ５）、検査が完了したと判断すると、フロー情報検索部２１に信号を送信して、フロー管理テーブル４２の「ソフトウェア処理」（図３（ｂ））を「ソフトウェア処理対象＝ＮＯ」に設定させ、ソフトウェア処理対象の設定を解除する（ステップＡ６）。検査が完了していない場合には、ソフトウェア処理対象の解除は行わず、ソフトウェア処理部１１による検査を継続する。

ソフトウェア処理部１１は、例えば、ＨＴＴＰやＳＭＴＰのプロトコルのトラヒックデータを検査する際には、コマンドやレスポンスデータから、所定の情報パラメータを抽出すると、以後のソフトウェア処理は不要であると判断して、ソフトウェア処理対象の設定を解除する。その際、ソフトウェア処理部１１は、後続するデータをハードウェア処理部２３で処理する際の指示がある場合には、フロー管理テーブル４２（図３（ｂ））の「ハードウェア処理への指示情報」に、その指示の内容を書き込む。例えば、以後のデータについては検査が必要ない場合には、ハードウェア処理部２３に対して、何も検査しないという指示情報を書き込む。

また、ソフトウェア処理部１１は、ソフトウェア処理対象の設定解除に際して、必要に応じて、フロー管理テーブル４２（図３（ｂ））の「条件判定部への指示情報」やプロトコル条件テーブル４４（図３（ｃ））の条件を書き換えて、ハードウェア処理部２３による検査からソフトウェア処理部１１による検査に切り替える条件を設定する。例えば、ＨＴＴＰプロトコルで、ＨＴＴＰリクエストに対するレスポンスデータのデータ本文部分をハードウェア処理部２３によって処理させた後にソフトウェア処理に切り替えたい場合には、プロトコル条件テーブル４４に、「ｄｏｗｎ：データ本文のサイズ」を書き込み、そのサイズのデータの処理後に、ソフトウェア処理に復帰するように設定する。

条件判定部２２は、ステップＡ３で、ソフトウェア処理対象でないと判断すると、当該フローについて、ソフトウェア処理対象に切り替える条件が成立しているか否かを判定する（ステップＡ７）。この判定処理では、プロトコルとフローデータの方向とに対して、フロー管理テーブル４２及びプロトコル条件テーブル４４（図３（ｂ）及び（ｃ））で指定された条件と一致するか否かの判定を行う。具体的には、プロトコルのコマンドやメソッド、レスポンスを示す特定の文字列を、該当するプロトコルに応じて検索する。より詳細には、ＧＥＴやＰＯＳＴなどのＨＴＴＰのメソッドを指定する文字列やレスポンスの文字列、ＳＭＴＰにおけるトランザクション区切りのコマンド文字列などを検索する。図３（ｃ）に示すプロトコル条件テーブル４４では、条件にフローの方向（ｕｐ，ｄｏｗｎ）と比較文字列とが指定されており、これにより、コマンド、レスポンスのそれぞれに対する判定条件が指定される。

条件判定部２２は、ステップＡ７で、条件が成立していないと判断すると、入力データをハードウェア処理部２３に受け渡す。ハードウェア処理部２３は、フロー管理テーブル４２の「ハードウェア処理への指示情報」を参照して、指定された指示に基づいて、受け取ったデータの検査を行う（ステップＡ９）。ステップＡ９のハードウェア処理部２３によるデータの検査は、典型的にはハードウェアによる文字列検索やシグネチャとのパタンマッチ処理である。ハードウェア処理部２３は、例えば、メールに含まれるキーワード文字列検索による迷惑メール検知や、不正侵入、不正攻撃の検知をハードウェア処理にて実施する。ハードウェア処理部２３は、「ハードウェア処理への指示情報」で、「何もしない」が指定されていた場合には、何もせずにデータを選択部２４へ通過させる。

条件判定部２２は、ステップＡ７で条件が成立していると判断すると、フロー管理テーブル４２をソフトウェア処理対象に設定する（ステップＡ８）。その後、ステップＡ４に進み、ソフトウェア処理部１１により入力データの検査を行う。選択部２４は、ステップＡ６でソフトウェア処理部１１で検査された後のデータ、又は、ステップＡ９でハードウェア処理部２３で検査された後のデータを、レイヤ４送信処理部３４に出力する（ステップＡ１０）。レイヤ４送信処理部３４は、選択部２４から入力されたデータを、端末２０１又は２０２に送信する。

図５は、入力データを例示している。データ処理部２０には、レイヤ４受信処理部３３から、同図に示すパケット＃１〜＃１２が順次に入力されるとする。ＴＣＰの場合に、これら入力データを組み立てて得られる、対応するアプリケーションフローのペイロードを１−１、２−１、１−２と示す。ペイロード１−１と１−２とは、同一方向のフローであり、例えばクライアントからサーバへのデータペイロードである。また、ペイロード２−１は、サーバからクライアントへのデータペイロードである。

データ処理部２０に、パケット＃１が入力されると、このフローに対する初期状態としてフロー管理テーブル４２に「ソフトウェア処理状態」が記憶されていると、パケット＃１は、ソフトウェア処理部１１に受け渡され、ソフトウェア処理により、情報検知処理が行われる。次いで、パケット＃２がソフトウェア処理部１１に入力され、ソフトウェア処理において、これ以上のソフトウェア処理が不要であると判断されると、ソフトウェア処理部１１は、フロー情報検索部２１に所定の信号を送信し、フロー管理テーブル４２における当該フローを、「ソフトウェア処理＝ＮＯ」に設定させる。

パケット＃３は、パケット＃２の処理後にフロー管理テーブル４２が「ソフトウェア処理＝ＮＯ」に設定されているため、条件判定部２２による条件判定処理の後、ハードウェア処理部２３に受け渡されて、ハードウェア処理される。以降、パケット＃３に後続するパケット＃４〜＃１０も同様に、条件判定処理の後にハードウェア処理部２３に受け渡され、ハードウェア処理でデータ検査が行われる。条件判定部２２は、パケット＃１１に、フロー管理テーブル４２の条件判定部への指示情報（図３（ｂ））で指定された対象文字列と一致する文字列があることを抽出すると、フロー管理テーブル４２を「ソフトウェア処理＝ＹＥＳ」に設定した後に、パケット＃１１をソフトウェア処理部１１に受け渡し、ソフトウェア処理による検査に切り替える。パケット＃１１に後続するパケット＃１２についても、ソフトウェア処理によって、検査が行われる。

本実施形態では、フロー管理テーブル４２を参照して、入力データのフローがソフトウェア処理対象であるか否かを調べ、ソフトウェア処理対象であるときには、ソフトウェア処理部１１によって入力データの検査を行う。ソフトウェア処理対象でないときには、ソフトウェア処理に切り替える条件が成立してるか否かを調べ、成立しているときには、ソフトウェア処理に切り替えてソフトウェア処理部１１によって入力データの検査を行い、成立していないときには、ハードウェア処理部２３によって入力データの検査を行う。このようにすることで、ひとつのアプリケーションセッション中でソフトウェア処理部１１での検査とハードウェア処理部２３での検査とを動的に切り替えることができ、詳細な検査が必要な箇所のみをソフトウェア処理で検査し、それ以外の箇所をハードウェア処理部２３へオフロードすることで、ソフトウェア処理の負荷の増大を防止できる。

以下、実施例を用いて説明する。図６は、第１実施例で処理されるデータを示している。第１実施例では、ネットワークトラヒックは、ＨＴＴＰ（Hypertext Transmission Protocol、ＲＦＣ２６１６）トラヒックである。同図におけるデータ１−１、１−２は、クライアントからのコマンドデータであり、データ２−１、２−２はサーバからのレスポンスデータである。ＨＨＴＰのコマンドとレスポンスデータとを用いたプロトコルの不正チェックを行う場合には、プロトコルのコマンドとレスポンスをチェックすればよい。一方で、データ２−１とデータ２−２の区切りを探すためには、データ２−１、２−２の内容をチェックして本文情報を取得し、その長さ分のデータを読み飛ばすと共に、空行（連続する改行文字）を認識する必要がある。本実施例では、この処理をソフトウェア処理で実現することをスキップする。

具体的には、データ１−１をソフトウェア処理部１１で検査した後、引き続き、データ２−１をソフトウェア処理部１１で検査する。データ２−１の検査で、レスポンス文字列のチェックを完了すると、データ２−１の残りの部分はソフトウェアで処理する必要がないと判断して、フロー管理テーブル４２を「ソフトウェア処理＝ＮＯ」に設定する。その際、ソフトウェア処理部１１は、データ２−１のデータ本文をハードウェア処理部２３で検査させた後に、ソフトウェア処理部１１での検査に復帰するように、データ２−１のデータ本文のデータサイズ２５００ｂｙｔｅを取得して、プロトコル条件テーブル４４に、「ｄｏｗｎ：２５００ｂｙｔｅ」を設定する。データ本文のデータサイズは、“Content-Length」の行から取得できる。

条件判定部２２は、レスポンス方向のデータに関して、ソフトウェア処理部１１によって設定された条件「ｄｏｗｎ：２５００ｂｙｔｅ」が成立するか否かを判断しつつ、コマンド方向のデータに関して、「条件判定部への指示情報」で指定されたＧＥＴやＰＯＳＴなどのコマンドメソッド文字列が検出されたか否かを判断する。レスポンス方向に指定されたデータ長（２５００ｂｙｔｅ）のデータが通過し、或いは、コマンド方向のデータにコマンドメソッド文字列のデータが検出されことで、データ１−２は、「ソフトウェア処理対象＝ＹＥＳ」となり、ソフトウェア処理部１１で検査される。データ２−２についても、データ２−１と同様に、レスポンス文字列の検査後に「ソフトウェア処理対象＝ＮＯ」に設定し、ファイル開始からファイル終わりまでの２００００ｂｙｔｅのデータが通過したことをソフトウェア処理に切り替える条件に設定して、データ２−２の検査終了後に、ソフトウェア処理へ復帰するようにする。このようにすることにより、詳細な検査が必要な箇所をソフトウェア処理部１１で処理させ、それ以外の箇所を、ハードウェア処理部２３で検査させることができる。

図７は、第２実施例で処理されるデータを示している。第２実施例では、ネットワークトラヒックは、ＳＭＴＰ（Simple Mail Transfer Protocol、RFC2821）トラヒックである。同図におけるデータ３−１〜３−７はクライアントからのコマンドデータであり、データ４−１〜４−７はサーバからのレスポンスデータである。ＳＭＴＰでは、一つのＳＭＴＰセッションで複数の電子メールを送信することができる。このときに、個々のメールトランザクションを開始するコマンドとして、「ＨＥＬＯ」、「ＥＨＬＯ」、「ＲＳＥＴ」がある。図７に示すデータでは、データ３−１で、トランザクション開始を検出してソフトウェア処理部１１による検査を開始し、以降、データ４−１〜４−４、データ３−２〜３−４を、ソフトウェア処理部１１で検査する。

ソフトウェア処理部１１は、メール本文に対応するデータ３−５の開始時点で、フロー管理テーブル４２を更新し、ソフトウェア処理対象の設定を解除する。これにより、データ３−５は、ハードウェア処理部２３に転送されて、ハードウェア処理により検査される。プロトコル条件テーブル４４には、ソフトウェア処理へ切り替える条件として、メール本文の終了を示す文字列である空行文字（ＣＲ＋ＬＦ＋“．”＋ＣＲ＋ＬＦ、ただしＣＲ＝０ｘ０Ｄ、ＬＦ＝０ｘ０Ａ）が設定されている。条件判定部２２は、データ３−５の最終部分で空行文字を検出すると、フロー管理テーブル４２を更新して、ソフトウェア処理対象に設定する。これにより、次のメールトランザクションのプロトコル不正チェックを、ソフトウェア処理にて行うことができる。

なお、ソフトウェア処理部１１がソフトウェア処理対象を解除するタイミングは、データ３−５には限定されない。例えば、迷惑メール判定などの場合には、データ３−２で、ＭＡＩＬ ＦＲＯＭコマンドで示される送信元アドレスが、あらかじめ登録された信頼できる送信元と一致するか否かを判定して、一致する場合には、その時点で、ソフトウェア処理対象を解除してもよい。この場合には、データ４−２以降のデータは、ハードウェア処理部２３で検査されることになり、ソフトウェアの処理負担を軽減することができる。

図８は、第３実施例で処理されるデータを示している。第３実施例では、データは、ＳＭＴＰで転送される電子メール本文がＭＩＭＥ（multipurpose internet mail extensions、ＲＦＣ２０４５〜２０４９）で規定されるフォーマットに従って複数種別のデータを含んでいる。各パートは、デリミタ(区切り文字)と呼ばれる文字列で区切られており、テキストデータや画像ファイル、実行ファイルなど、種々のデータ種別を持っている。同図では、文字列“-multipart”がデリミタに相当する。条件判定部２２は、プロトコル条件テーブル４４（図３（ｃ））に登録された条件により、このデリミタを検出すると、ソフトウェア処理に切り替える条件が成立したと判断するように設定される。

図８では、データ先頭ではソフトウェア処理によりデータの検査を行い、第１パートの途中で、ソフトウェア処理からハードウェア処理に処理が切り替わる。その後、第１パートと第２パートとの区切りのデリミタを検出することで、検査をソフトウェア処理に切り替える。第２パートでは、ソフトウェア処理からハードウェア処理への切り替えは行われずに、ソフトウェア処理状態のまま、第３パートの検査を継続して行う。

第３パートの途中でソフトウェア処理からハードウェア処理への切り替えが行われ、第３パートの残りの部分は、ハードウェア処理部２３によって検査される。第３パートの終了部分でデリミタが検出されると、検査をソフトウェア処理に切り替える。このように、区切りの文字列をソフトウェア処理への切り替えの条件として設定することで、各パートの先頭ではソフトウェアで詳細な検査を行い、パート中の詳細な検査が不要な箇所ではハードウェア処理による検査に切り替えることができる。従って、ソフトウェア処理の負荷を下げることができる。

図９は、本発明の第２実施形態のアプリケーションデータ検査処理装置の構成を示している。第１実施形態との違いは、レイヤ４受信処理部３３は、レイヤ４プロトコルのモニタのみを行い、端末間の通信データを終端しない点である。ソフトウェア処理部１１及びハードウェア処理部２３は、入力データの検査に応じた制御信号を、選択部２４を介して、送信処理部３５に入力する。本実施形態では、ソフトウェア処理部１１及びハードウェア処理部２３では、レイヤ４の受信処理によって組み立てられたデータに対して検査を行い、端末装置間のデータについては、レイヤ４受信処理を行わない。この場合でも、図３に示した動作手順と同様な動作手順で入力データの検査を行うことができ、第１実施形態と同様な効果を得ることができる。

なお、ソフトウェア処理部１１でソフトウェア処理を完了してハードウェア処理部２３に移行する条件、及び、ハードウェア処理部２３による検査からソフトウェア処理部１１による検査に切り替える条件は、処置の対象となるプロトコルやデータ種別に依存する。上記実施形態や実施例で示した条件は一例であり、上記で説明したものに限定されるものではない。

以上、本発明をその好適な実施形態に基づいて説明したが、本発明の情報検知処理方法及び装置は、上記実施形態例にのみ限定されるものではなく、上記実施形態の構成から種々の修正及び変更を施したものも、本発明の範囲に含まれる。

本発明の第１実施形態の情報検知処理装置の構成を示すブロック図。 ＣＰＵ及びデータ処理部の詳細な構成を示すブロック図。 （ａ）は、フロー情報検索部及び条件判定部の詳細な構成を示すブロック図、（ｂ）は、フロー管理テーブルの具体例を示す図、（ｃ）は、プロトコル条件テーブルの具体例を示す図。 情報検知処理装置の動作手順を示すフローチャート。 入力データの具体例を示す図。 第１実施例で処理されるデータを示す図。 第２実施例で処理されるデータを示す図。 第３実施例に処理されるデータを示す図。 本発明の第２実施形態のアプリケーションデータ検査処理装置の構成を示すブロック図。

符号の説明

１０：ＣＰＵ
１１：ソフトウェア処理部
２０：データ処理部
２１：フロー情報検索部
２２：条件判定部
２３：ハードウェア処理部
２４：選択部
３３：レイヤ４受信処理部
３４：レイヤ４送信処理部
３５：送信処理部
３１、３２：ネットワークインタフェース
４１：フロー状態検索部
４２：フロー管理テーブル
４３：条件判定処理部
４４：プロトコル条件テーブル

Claims (14)

1. アプリケーションレイヤの通信トラヒックデータに基づいて、ハードウェア処理又はソフトウェア処理により、フロー単位で情報検知を行う情報検知処理装置における情報検知処理方法であって、
   入力データに対応するフローが、ソフトウェア処理対象であるか否かを判断し、
   前記入力データに対応するフローが、ソフトウェア処理対象であると判断すると、ソフトウェア処理により情報検知を行い、ソフトウェア処理対象でないと判断すると、フローデータの内容に基づいて、フローごとに設定されるソフトウェア処理対象に切り替える条件が成立しているか否かを判定し、前記条件が成立していると判定すると、入力データに対応するフローをソフトウェア処理対象に設定してソフトウェア処理により情報検知を行い、
   前記ソフトウェア処理での情報検知が終了すると、前記フローに対してソフトウェア処理対象の設定を解除することを特徴とする情報検知処理方法。
2. 前記条件が成立していないと判定すると、ハードウェア処理により情報検知を行う、請求項１に記載の情報検知処理方法。
3. 前記条件が成立しているか否かの判定では、前記入力データのフローのプロトコル種別に対応して設定された所定のキーワードを前記入力データから抽出すると、前記条件が成立していると判定する、請求項１に記載の情報検知処理方法。
4. 前記ソフトウェア処理では、情報検知を終了すると、入力データのフローの処理内容に基づいて、前記ソフトウェア処理対象に切り替える条件を個別に設定する、請求項１に記載の情報検知処理方法。
5. 前記条件が成立しているか否かの判定では、ソフトウェア処理によって指定されたデータサイズを処理すると、前記ソフトウェア処理へ切り替える条件が成立していると判定する、請求項４に記載の情報検知処理方法。
6. 前記条件が成立しているか否かの判定では、ソフトウェア処理によって指定された、入力データのフローに依存する特定の文字列を抽出すると、前記ソフトウェア処理へ切り替え条件が成立していると判定する、請求項４に記載の情報検知処理方法。
7. アプリケーションレイヤの通信トラヒックデータに基づいて、フロー単位で情報検知を行う情報検知処理装置であって、
   入力データを入力するデータ入力部と、
   ハードウェア処理により、前記入力データの情報検知を行うハードウェア処理部と、
   ソフトウェア処理により、前記入力データの情報検知を行うソフトウェア処理部と、
   フローごとに、ソフトウェア処理対象であるか、又は、ハードウェア処理対象であるかを示す情報を記憶するフロー管理情報を参照して、前記入力データのフローが、ソフトウェア処理対象であるか否かを取得するフロー情報検索部と、
   前記フロー情報検索部が、ソフトウェア処理対象である旨の情報を取得すると、前記ソフトウェア処理部で前記情報検知を行わせ、ソフトウェア処理対象でない旨の情報を取得すると、フローデータの内容に基づいて、ソフトウェア処理に切り替える条件が成立しているか否かを判定し、条件が成立していると判定すると、前記ソフトウェア処理部で前記情報検知を行わせ、成立していないと判定すると、前記ハードウェア処理部で前記情報検知を行わせる条件判定部とを備え、
   前記ソフトウェア処理部は、情報検知を終了すると、前記フロー管理情報の前記入力データに対応するフローをハードウェア処理対象に変更することを特徴とする情報検知処理装置。
8. 前記フロー管理情報が、フローごとに、前記ソフトウェア処理に切り替える条件が成立しているか否かを判定するための条件情報を有しており、前記条件判定部は、該条件情報を参照して、ソフトウェア処理に切り替える条件が成立しているか否かを判定する、請求項７に記載の情報検知処理装置。
9. ネットワークを介してデータを受信し、該受信したデータにレイヤ４受信処理を行って前記データ入力部にデータを入力するレイヤ４受信処理部を更に備える、請求項７に記載の情報検知処理装置。
10. 前記ハードウェア処理部又は前記ソフトウェア処理部による情報検知処理後のデータに対してレイヤ４送信処理を行い、データを送信するレイヤ４送信処理部を更に備える、請求項７に記載の情報検知処理装置。
11. 前記条件判定部は、前記入力データのフローのプロトコル種別に対応して設定された所定のキーワードを前記入力データから抽出すると、ソフトウェア処理へ切り替える条件が成立していると判定する、請求項７に記載の情報検知処理装置。
12. 前記ソフトウェア処理部は、情報検知を終了すると、入力データのフローの処理内容に基づいて、前記ソフトウェア処理に切り替える条件を個別に設定する、請求項７に記載の情報検知処理装置。
13. 前記条件判定部は、前記ソフトウェア処理部によって指定されたデータサイズを処理すると、前記ソフトウェア処理へ切り替える条件が成立していると判定する、請求項１２に記載の情報検知処理装置。
14. 前記条件判定部は、前記ソフトウェア処理部によって指定された、入力データのフローに依存する特定の文字列を抽出すると、前記ソフトウェア処理へ切り替える条件が成立していると判定する、請求項１２に記載の情報検知処理装置。

Images