(57)【要約】  本発明はSSHプロトコルに基づく会話解析方法及びシステムを提供し、前記方法は、以下のステップ101)と102)とを含む。ステップ101)  SSHプロトコル会話に基づくデータパケットを受信し、且つ受信した各データパケットに応じて以下の前処理をそれぞれ行い、即ち、１つのデータパケットがいくつかの完全なメッセージを含む場合、該データパケットから各完全なメッセージを順次に抽出し、一方１つのデータパケットに含まれたメッセージが完全ではない場合、まず現在のデータパケットに含まれる不完全なメッセージをキャッシュして、次に後続のデータパケットを受信し、後続のデータパケットに含まれるメッセージとキャッシュしたメッセージ内容とを結合して、最終的に、１つの完全なメッセージを生成する。ステップ102)  得られた各完全なメッセージからログ生成に関連する内容を抽出して、設定された形式でログに関連する内容をパッケージし、更に、解析ログを取得して会話解析を完了する。本発明の技術はSSH会話に基づく監査を実現することができ、例えば銀行などの組織のためにセキュリティ保証を提供することができる。【選択図】図１−ｂ
2017539163.tif 000002
【特許請求の範囲】
【請求項１】
SSHプロトコルに基づく会話解析方法であって、以下のステップ101)と102)とを含むことを特徴とするSSHプロトコルに基づく会話解析方法。
ステップ101)  SSHプロトコル会話に基づくデータパケットを受信し、且つ受信した各データパケットに応じて、以下の前処理（p1）又は（p2）をそれぞれ行う、即ち、
（p1）前記データパケットがいくつかの完全なメッセージを含む場合、該データパケットから各完全なメッセージを順次に抽出し、
（p2）前記データパケットに含まれるメッセージが完全ではない場合、まず該データパケットに含まれる不完全なメッセージをキャッシュし、次に後続のデータパケットを受信し、後続のデータパケットに含まれるメッセージとキャッシュした前記メッセージ内容を結合して、最終的に、１つの完全なメッセージを生成する。
ステップ102)  得られた各完全なメッセージからログ生成に関連する内容を抽出して、設定された形式でログに関連する内容をパッケージし、解析ログを生成して会話解析を完了する。
【請求項２】
前記ステップ102)の後に、以下のステップ103) を更に含むことを特徴とする請求項１に記載のSSHプロトコルに基づく会話解析方法。
ステップ103)  生成した前記解析ログをストリーム送信モードでログサーバーに送信し、前記ストリーム送信モードは、生成した前記解析ログをログキャッシュに書き込み、キャッシュしたログ長さが設定された送信長さに達すると、直ちにログサーバーに前記解析ログ情報を送信するモードである。
【請求項３】
前記ステップ101)は、以下のステップ101-1)と101-2)とを更に含むことを特徴とする請求項１に記載のSSHプロトコルに基づく会話解析方法。
ステップ101-1)  １つのSSHプロトコル会話に基づくデータパケットを受信した後に、まずバッファにキャッシュしたデータパケットがあるか否かを調査し、キャッシュしたデータパケットが存在しない場合、受信したデータパケットにおける一番目のメッセージの長さを直ちに計算し、一方、バッファにキャッシュしたデータパケットが存在する場合、現在のデータパケットはキャッシュしたデータパケットに含まれる内容の継続であると判断し、現在のデータパケットの内容をキャッシュしたデータパケットにコピーした後に、更に不完全なメッセージを結合して、結合した後に再び現在のキャッシュしたデータパケットにおける一番目のメッセージの長さを計算する。
ステップ101-2)  計算して得られた一番目のメッセージの長さと受信したデータパケットの長さとを比較し、その結果に応じて以下のステップ101-2)〜101-3)をそれぞれ実行する。
ステップ101-2-1)  一番目のメッセージの長さが受信したデータパケットの長さに等しい場合、現在のデータパケットの内容は１つの完全なメッセージであると判断し、該メッセージを直ちに解析する。
ステップ101-2-2)  一番目のメッセージの長さが受信したデータパケットの長さより小さい場合、該データパケットを分割処理し、即ちデータパケットから完全なメッセージを抽出し、且つメッセージの先頭アドレスとメッセージ長さで１つの完全なメッセージを特定する。
ステップ101-2-3)  一番目のメッセージの長さが受信したデータパケットの長さより大きい場合、該データパケットをキャッシュすることによって更にいくつかのデータパケットの結合を行い、最終的に１つの完全なメッセージを取得し、且つ得られた完全なメッセージを解析する。
【請求項４】
前記ステップ102)は、以下のステップ102-1)及び102-2)を含むことを特徴とする請求項１に記載のSSHプロトコルに基づく会話解析方法。
ステップ102-1)  メッセージコードに基づいてメッセージタイプを識別し、更に識別したタイプに応じてメッセージがログ生成に関連するか否かを判断し、メッセージがログ生成に関連しない場合、それを直ちに廃棄し、そうでない場合、ログ生成に関連する各メッセージタイプに応じて、それぞれ以下の処理（t1）〜（t4）を行う、即ち、
（t1）バージョン交渉メッセージに対しては、メッセージにおけるプロトコルバージョン番号を取得してキャッシュし、
（t2）ユーザ認証要求メッセージに対しては、メッセージからユーザ名を抽出してキャッシュし、
（t3）チャンネル要求メッセージに対しては、要求されたチャンネルタイプを取得してキャッシュし、
（t4）チャンネルにおいて伝送したメッセージに対しては、メッセージ方向によって要求に属するか、応答に属するかを判断し、且つメッセージ方向をキャッシュし、ここで、メッセージ方向がクライアント側からサーバー方向の場合、要求メッセージであり、逆方向の場合、応答メッセージであると判断する。
ステップ102-2)  キャッシュした内容及び応答データパケットに基づいて解析ログを生成し、生成したログは、TCP/IPクワッド、会話ID、会話にログインするユーザ名、ログイン時間、クライアント側の要求命令、要求開始時間、サーバー側がクライアント側に返す応答データ及び応答終了時間を含み、
前記クライアント側の要求命令とサーバー側がクライアント側に返す応答データは１つの会話の存続期間内で繰り返して発生しても良いが、生成された各解析ログは１つのクライアント側の要求命令と１つのサーバー側の応答のみを含み、即ち異なる解析ログの要求及び応答が互いに独立であり、
１つの会話の存続期間内における前記TCP/IPクワッド、会話ID、ログイン会話のユーザ名及びログイン時間情報は変わらない。
【請求項５】
クライアント側の各入力をメッセージの形式でサーバーに送信し、該入力の結果をサーバー側が返したエコーメッセージによって端末に表示し、エコーメッセージにおけるエスケープ文字を識別することによって、カーソル位置を正確に制御することを実現し、メッセージに含まれる要求文字を参照して要求命令を復元し、クライアント側の要求の終了を検出すると、復元した要求命令を直ちにログキャッシュに書き込むことを特徴とする請求項４に記載のSSHプロトコルに基づく会話解析方法。
【請求項６】
SSHプロトコル会話に基づくデータパケットを受信して、受信した各データパケットに応じて、以下の前処理（p1）又は（p2）をそれぞれ行う、即ち、
（p1）前記データパケットがいくつかの完全なメッセージを含む場合、該データパケットから各完全なメッセージを順次に抽出し、
（p2）前記データパケットに含まれるメッセージが完全ではない場合、まず該データパケットに含まれる不完全なメッセージをキャッシュして、次に後続のデータパケットを受信し、後続データパケットに含まれたメッセージとキャッシュしたメッセージ内容を結合して、最終的に、１つの完全なメッセージを生成する、
ためのパケット処理モジュールと、
得られた各完全なメッセージからログ生成に関連する内容を抽出して、設定された形式でログに関連する内容をパッケージし、更に、解析ログを取得して会話解析を完成するための解析モジュールと
を備えることを特徴とするSSHプロトコルに基づく会話解析システム。
【請求項７】
生成した解析ログをストリーム送信モードでログサーバーに送信するためのログ送信モジュールを更に備え、前記ストリーム送信モードは、生成された解析ログをログキャッシュに書き込み、キャッシュされたログ長さが設定された送信長さに達すると、直ちにログサーバーにログを送信するモードであることを特徴とする請求項６に記載のSSHプロトコルに基づく会話解析システム。
【請求項８】
前記パケット処理モジュールは、
１つのSSHプロトコル会話に基づくデータパケットを受信した後に、まずバッファにキャッシュしたデータパケットがあるか否かを調査し、キャッシュしたデータパケットが存在しない場合、受信したデータパケットにおける一番目のメッセージの長さを直ちに計算し、且つ第２処理サブモジュールを駆動し、一方、バッファにキャッシュしたデータパケットが存在する場合、現在のデータパケットはキャッシュしたデータパケットに含まれる内容の継続であると判断し、第３処理ユニットを直ちに駆動するための第１処理サブモジュールと、
計算して得られた一番目のメッセージの長さと受信したデータパケットの長さを比較し、その結果に応じて以下の第１〜第３処理ユニットを起動する、即ち、
一番目のメッセージの長さが受信したデータパケット長さに等しい場合、現在のデータパケットの内容は１つの完全なメッセージであると判断して、該メッセージを直ちに解析することができる第１処理ユニットを起動し、
一番目のメッセージの長さがデータパケットの長さより小さい場合、該データパケットを分割処理し、即ちデータパケットから完全なメッセージを抽出し、且つメッセージの先頭アドレスとメッセージ長さで１つの完全なメッセージを特定する第２処理ユニットを起動し、
一番目のメッセージの長さがデータパケットの長さより大きい場合、該データパケットをキャッシュすることによって更にいくつかのデータパケットの結合を行い、最終的に１つの完全なメッセージを取得し、完全なメッセージの長さを計算して得られた完全なメッセージを解析する第３処理ユニットを起動する、
ための第２処理サブモジュールと
を更に備えることを特徴とする請求項７に記載のSSHプロトコルに基づく会話解析システム。
【請求項９】
前記解析モジュールは、メッセージフィルタリングサブモジュールと、ログ生成サブモジュールとを更に備え、
前記メッセージフィルタリングサブモジュールは、メッセージコードに基づきメッセージタイプを識別し、識別したタイプに基づいてメッセージがログ生成に関連するか否かを判断し、メッセージがログ生成に関連しない場合、それを直ちに廃棄し、そうでない場合、ログ生成に関連する各メッセージタイプに応じて、以下の処理（t1）〜（t4）を行い、即ち、
（t1）バージョン交渉メッセージに対しては、メッセージにおけるプロトコルバージョン番号を取得してキャッシュし、
（t2）ユーザ認証要求メッセージに対しては、メッセージからユーザ名を抽出してキャッシュし、
（t3）チャンネル要求メッセージに対しては、要求されたチャンネルタイプを取得してキャッシュし、
（t4）チャンネルにおいて伝送したメッセージに対しては、メッセージ方向によって要求に属するか、応答に属するかを判断し、且つメッセージ方向をキャッシュし、ここで、メッセージ方向がクライアント側からサーバーの方向の場合、要求メッセージであり、逆方向の場合、応答メッセージであると判断し、
前記ログ生成サブモジュールは、キャッシュした内容及び応答データパケットに基づいて解析ログを生成することに用いられ、前記解析ログは、TCP/IPクワッド、会話ID、会話にログインするユーザ名、ログイン時間、クライアント側がの要求命令、要求開始時間、サーバー側がクライアント側に返った応答データ及び応答終了時間を含み、
前記クライアント側の要求命令とサーバー側がクライアント側に返す応答データは、１つの会話の存続期間内で繰り返して発生しても良いが、生成した各解析ログは１つのクライアント側の要求命令と１つのサーバー側の応答のみを含み、異なる解析ログの要求及び応答は互いに独立であり、
１つの会話の存続期間内における前記TCP/IPクワッド、会話ID、ログイン会話のユーザ名及びログイン時間情報は変わらないことを特徴とする請求項７に記載のSSHプロトコルに基づく会話解析システム。
【請求項１０】
前記ログ送信モジュールは、パッケージサブモジュールと、送信サブモジュールとを更に備え、
前記パッケージサブモジュールは、ログを送信する際に該ログにログヘッダーを追加することに用いられ、前記ログヘッダーは「ログ番号」、「セグメント化するかどうか」、「セグメント番号」及び「最後のセグメント」を含み、ここで、前記「ログ番号」は１つのログを特定することに用いられ、「セグメント化するかどうか」は、このログがセグメント化されて送信されるか否かをマークすることに用いられ、このマークが0である場合、このセグメントの内容がログ全体の内容であることを示し、そうでない場合、ログがいくつかのセグメントに分けられ、「セグメント番号」及び「最後のセグメント」は「セグメント化するかどうか」を1にマークした場合だけに意味があり、「セグメント番号」はログフラグメントの固有の識別番号であり、
前記送信サブモジュールは、パッケージされたログを記憶サーバーに送信するために用いられ、
前記記憶サーバーは、ログフラグメントを受信した後に同様な「ログ番号」を有するログフラグメントを「セグメント番号」が小さいものから大きいものへ順次に結合して１つの完全なログを生成することを特徴とする請求項７に記載のSSHプロトコルに基づく会話解析システム。 
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はコンピュータネットワークの技術分野に関し、具体的には、SSHプロトコルに基づく会話（session）解析方法及びシステムに関する。
【背景技術】
【０００２】
プロトコルは、様々なコンピュータアプリケーションの中で及びアプリケーション間で通信する方式であり、プロトコル解析は、既にネットワークアプリケーションにおいて不可欠な技術となっている。通信する二者は、通信内容をプロトコルに従ってパッケージして伝送し、あるプロトコルは更に伝送するデータを暗号化する。例えばSSHプロトコルは、不安全なネットワークにおいて安全なリモートログイン及びその他の安全なネットワークサービスを行うプロトコルであり、SSHチャンネルによって伝送されるデータは、いずれも暗号化されたデータである。
【０００３】
企業や組織のサービスシステムにおいて、業務の監視のためにクライアント側のログイン及び操作行為の監視や記録をする必要がある。ユーザ行為の監視は、一般的にサーバー側とクライアント側の間に中間者（man-in-the-middle）を加えて実施する。SSHプロトコルの通信において、中間者がインターセプトするデータパケットは、いずれも暗号化された内容であり、それを平文データパケットに暗号解読して、平文データパケットを解析し、解析した後に解析ログを生成する。監査者は、ログを解析することによってクライアント側の全ての操作行為を再表示することができ、それによりこれらの企業や組織のサービスシステムのためにセキュリティを提供する。監査の目的は、クライアント側とサーバーの間の正常な通信品質に影響を与えない前提でクライアント側の行為を監視することにある。中間者の処理効率は、クライアント側とサーバー側の通信品質に影響を及ぼし、プロトコル解析は、中間者処理の非常に重要な１ステップであるため、プロトコル解析の効率を高めることが強く要求されている。
【０００４】
従来、SSHプロトコルに基づく解析は少なく、従来のプロトコル解析技術はある予め設定された固定シーンのみに適用される場合が多く、拡張性（scalability）が悪い。なお、現在の方法は純粋なソフトウェアの解析方式を主として、並行性能（concurrency performance）を改善する必要がある。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明は、企業や組織のサービスシステムのために監査サポートを提供するために、SSHプロトコルに基づく会話解析方法及びシステムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記の目的を実現するために、本発明はSSHプロトコルに基づく会話解析方法を提供し、前記方法は、以下のステップを含む。
【０００７】
ステップ101)   SSHプロトコル会話に基づくデータパケットを受信し、且つ受信した各データパケットに応じて以下の前処理をそれぞれ行う。即ち、
前記データパケットがいくつかの完全な（フラグメントでない）メッセージを含む場合、該データパケットから各完全なメッセージを順次に抽出し、一方、
前記データパケットに含まれるメッセージが完全ではない（フラグメントである）場合、まず該データパケットに含まれる不完全なメッセージをキャッシュし、次に後続のデータパケットを受信し、後続データパケットに含まれたメッセージとキャッシュしたメッセージ内容を結合して、最終的に、１つの完全なメッセージを生成する。
【０００８】
ステップ102)  得られた各完全なメッセージからログ生成に関連する内容を抽出して、設定された形式でログに関連する内容をパッケージし、更に、解析ログを取得して会話解析を完成する。
【０００９】
選択的に、上記ステップ102)の後に、以下のステップを更に含む。
【００１０】
ステップ103)  生成した解析ログをストリーム送信モードでログサーバーに送信し、
ここで、前記ストリーム送信モードは、生成した解析ログをログキャッシュに書き込み、キャッシュしたログ長さが設定された送信長さに達すると、直ちにログサーバーに解析ログ情報を送信するモードである。
【００１１】
選択的に、上記ステップ101)は、以下のステップを更に含む。
【００１２】
ステップ101-1)  １つのSSHプロトコル会話に基づくデータパケットを受信した後に、まずバッファにキャッシュしたデータパケットがあるか否かを調査し、キャッシュしたデータパケットが存在しない場合、受信したデータパケットにおける一番目のメッセージの長さを直ちに計算し、一方、バッファにキャッシュしたデータパケットが存在する場合、現在のデータパケットはキャッシュしたデータパケットに含まれた内容の継続であると判断し、現在のデータパケット内容をキャッシュしたデータパケットにコピーした後に、更に不完全なメッセージを結合して、結合した後に再び現在のキャッシュしたデータパケットにおける一番目のメッセージの長さを計算する。
【００１３】
ステップ101-2)  計算して得られた一番目のメッセージの長さと受信したデータパケットの長さを比較し、その結果に応じて以下のステップ101-2-1)〜101-2-3）をそれぞれ実行する。
【００１４】
ステップ101-2-1)  一番目のメッセージの長さが受信したデータパケットの長さに等しい場合、現在のデータパケット内容は１つの完全なメッセージであると判断して、該メッセージを直ちに解析することができる。
【００１５】
ステップ101-2-2)  一番目のメッセージの長さが受信したデータパケットの長さより小さい場合、該データパケットを分割処理し、即ちデータパケットから完全なメッセージを抽出し、且つメッセージの先頭アドレスとメッセージ長さで１つの完全なメッセージを特定する。
【００１６】
ステップ101-2-3)  一番目のメッセージの長さが受信したデータパケットの長さより大きい場合、該データパケットをキャッシュすることによって更にいくつかのデータパケットの結合を行い、最終的に１つの完全なメッセージを取得し、且つ得られた完全なメッセージを解析する。
【００１７】
上記ステップ102)は、具体的には、以下のステップ102-1)及び102-2)を含む。
【００１８】
ステップ102-1)  メッセージコードに基づいてメッセージタイプを識別し、更に識別したタイプに応じてメッセージがログ生成に関連するか否かを判断し、メッセージがログ生成に関連しない場合、それを直ちに廃棄し、そうでない場合、ログ生成に関連する各メッセージタイプに応じて、それぞれ以下の処理を行う。
バージョン交渉メッセージに対しては、メッセージにおけるプロトコルバージョン番号を取得してキャッシュし、
ユーザ認証要求メッセージに対しては、メッセージからユーザ名を抽出してキャッシュし、
チャンネル要求メッセージに対しては、要求されたチャンネルタイプを取得してキャッシュし、
チャンネルにおいて伝送したメッセージに対しては、メッセージ方向によって要求に属するか、応答に属するかを判断し、且つメッセージ方向をキャッシュする。ここで、メッセージ方向がクライアント側からサーバーの方向の場合、要求メッセージであり、逆方向の場合、応答メッセージであると判断する。
【００１９】
ステップ102-2)  キャッシュした内容及び応答データパケットに基づいて解析ログを生成し、生成したログは、TCP/IPクワッド、会話ID、会話をログインするユーザ名、ログイン時間、クライアント側の要求命令（request command）、要求開始時間、サーバー側がクライアント側に返った応答データ及び応答終了時間を含む。
【００２０】
ここで、前記クライアント側の要求命令とサーバー側がクライアント側に返す応答データは、１つの会話の存続期間内で繰り返して発生しても良いが、生成された各解析ログは、１つのクライアント側の要求命令と１つのサーバー側の応答のみを含み、即ち異なる解析ログの要求及び応答は互いに独立であり、
１つの会話の存続期間内における前記のTCP/IPクワッド、会話ID、ログイン会話のユーザ名及びログイン時間情報は変わらない。
【００２１】
更に、選択的に、クライアント側は入力する度にメッセージの形式でサーバーに送信し、該入力した結果をサーバー側が返したエコーメッセージによって端末に表示し、エコーメッセージにおけるエスケープ文字を識別することによって、カーソル位置を正確に制御することを実現し、メッセージに含まれる要求文字（request character）を参照して要求命令を復元し、クライアント側の要求の終了を検出すると、復元した要求命令を直ちにログキャッシュに書き込む。ユーザ要求が終了した後にサーバーがクライアント側に返したデータを応答データとして、ログキャッシュに順次に書き込み、キャッシュしたログフラグメントの長さが設定された送信長さに達すると、直ちにログフラグメントを送信する。最終的な１つのログフラグメントの送信は、次回の要求をトリガーとして行うことができ、タイマーをトリガーとして行うこともできる。
【００２２】
なお、本発明はSSHプロトコルに基づく会話解析システムを更に提供する。このシステムは、
SSHプロトコル会話に基づくデータパケットを受信して、且つ受信した各データパケットに応じて、以下のような前処理をそれぞれ行う、即ち、
前記データパケットがいくつかの完全なメッセージを含む場合、該データパケットから各完全なメッセージを順次に抽出し、一方、
前記データパケットに含まれるメッセージが完全ではない場合、まず前記データパケットに含まれる不完全なメッセージをキャッシュして、次に後続のデータパケットを受信し、後続データパケットに含まれるメッセージとキャッシュしたメッセージ内容を結合して、最終的に、１つの完全なメッセージを生成する、
ためのパケット処理モジュールと、
得られた各完全なメッセージからログ生成に関連する内容を抽出して、設定された形式でログに関連する内容をパッケージし、更に、解析ログを取得して会話解析を完成するための解析モジュールとを備える。
【００２３】
選択的に、上記システムは、
生成した解析ログをストリーム送信モードでログサーバーに送信するためのログ送信モジュールを更に備え、ここで、前記のストリーム送信モードは、生成された解析ログをログキャッシュに書き込み、キャッシュされたログ長さが設定された送信長さに達すると、直ちにログサーバーにログを送信するモードである。
【発明の効果】
【００２４】
従来の技術と比べて、本発明は以下の利点を有する。
プロセスの簡単化 -- データパケットを処理することによって、１つの完全なメッセージを取得して、解析プロセスをより簡素化し、信頼性を高めることができる。
キャッシュの節約 -- １つの完全なメッセージを解析して、処理プロセスを簡素化すると同時に、メモリ空間も節約できる。なお、ログ伝送はストリーム送信の方式を採用してキャッシュ空間を大幅に節約し、各解析タスクのために小さいキャッシュ空間を適用すればログ生成及び送信のための需要を満たすことができる。
【図面の簡単な説明】
【００２５】
【図１−ａ】本発明による解析システムの各モジュールの論理構造模式図である。
【図１−ｂ】本発明の解析システムのアプリケーションシーン模式図である。
【図２】本発明による方法におけるパケット処理モジュールの処理フローチャートである。
【図３】本発明による方法における応答解析フローチャートである。
【図４】本発明による方法におけるストリーム送信したログフラグメント形式の模式図である。
【発明を実施するための形態】
【００２６】
以下、図面及び好ましい実施例を参照して本発明を詳細に説明する。
【００２７】
実施例１
上記の方法を実現するために、本発明は解析システムを提供する。この解析システムを図１−ａ及び１−ｂに示す。図１−ａは３つのモジュールの論理構造模式図であり、図面１−ｂは解析システムのアプリケーションシーン模式図である。本発明に関した３つのモジュール、即ち、パケット処理モジュール、解析モジュール及びログ送信モジュールを備える。
【００２８】
パケット処理モジュールは、受信したデータパケットを処理する。受信したデータパケットとメッセージとの関係は多対多のマッピングであり、即ち１つのデータパケットに１つ又は複数のメッセージを含む可能性があり、１つのメッセージが複数のデータパケットに存在する可能性もある。直接的にこのようなデータパケットを解析すると、メッセージ内容の欠落が発生しやすく、解析の不備を引き起こすおそれがある。このため、解析する前にまずデータパケットを処理する。複数のメッセージを含むデータパケットについては、データパケットからメッセージを順次に抽出して、毎回１つの完全なメッセージを抽出する。データパケットに含まれたメッセージが不完全である場合は、不完全なメッセージをキャッシュし、後続データパケットの受信を待って、新しく到着したデータ及びキャッシュにおけるメッセージ内容を結合して、１つの完全なメッセージを生成した後に解析モジュールに渡して処理する。該モジュールによって処理することにより、解析モジュールの処理プロセスが簡単化し、解析効率が向上する。
【００２９】
解析モジュールは前記方法の最もコアであるモジュールであり、１つの完全なSSHメッセージから生成ログに関連する内容を識別、分析、抽出して処理し、最終的に、既定形式に符合する解析ログを生成する。解析モジュールの入力は１つの完全なSSHメッセージであり、メッセージ形式は以下の通りである。
Unit32    packet_length
Byte      padding_length
Byte[n1]  payload              #n1=packet_length-padding_length-1
Byte[n2]  random_padding        #n2=padding_length
Byte[m]mac                      #m=mac_length;  （選択可能）
【００３０】
解析モジュールは、メッセージを取得した後に、まずpayloadからメッセージコードを取得する。メッセージコードはメッセージタイプの固有の識別であり、メッセージコードによって現在メッセージがSSHプロトコルのどの階段に対応するかが分かる。異なる階段のSSHメッセージに対して異なる分析及び処理を行う。例えばSSH_MSG_USERAUTH_REQUESTはSSHプロトコルのユーザ認証要求階段に対応するので、前記方法による該階段メッセージに対する解析の目的は主に認証を要求するユーザ名を取得することにある。パケット処理モジュールはデータパケットを識別しないため、パケット処理モジュールはSSH会話過程におけるすべてのデータパケットを処理することになり、解析モジュールが受信したメッセージは必然的にこの解析過程に関連しないメッセージを含む。このようなメッセージに対して、解析モジュールはいずれの処理を行わず、直ちに廃棄する。
【００３１】
ログ送信モジュールは、主に、生成したログをログサーバーに送信する役割を担う。従来の方法では、１つのログ生成が完了した後に送信するが、本発明の方法ではストリーム送信モードを採用してログを伝送する。解析モジュールは解析しながらログを生成し、生成したログをログキャッシュに書き込み、キャッシュしたログ長さが送信長さに達すると、直ちにログを送信する。したがって、１つの完全なログ生成が終了した後にログを送信する訳ではない。送信モジュールによるログに対する監視及びリアルタイム処理は、ある程度ログ伝送の効率を向上させ、同時にキャッシュ空間を節約する。
【００３２】
選択的に、上記パケット処理モジュールは、
１つのSSHプロトコル会話に基づくデータパケットを受信した後に、まずバッファにキャッシュしたデータパケットがあるか否かを調査し、キャッシュしたデータパケットが存在しない場合、受信したデータパケットにおける一番目のメッセージの長さを直ちに計算し且つ第２処理サブモジュールを起動し、一方、バッファにキャッシュしたデータパケットが存在する場合、現在のデータパケットはキャッシュしたデータパケットに含まれた内容の継続であると判断して、第３処理ユニットを直ちに駆動する第１処理サブモジュールと、
計算して得られた一番目のメッセージの長さと受信されたデータパケットの長さとを比較し、その結果に応じて以下の第１〜第３処理ユニットを起動する、即ち、
一番目のメッセージの長さが受信したデータパケット長さに等しい場合、現在のデータパケットの内容は１つの完全なメッセージであると判断し、該メッセージを直ちに解析することができる第１処理ユニットを起動し、
一番目のメッセージの長さがデータパケットの長さより小さい場合、該データパケットを分割処理し、即ちデータパケットから完全なメッセージを抽出し、且つメッセージの先頭アドレスとメッセージ長さで１つの完全なメッセージを特定する第２処理ユニットを起動し、
一番目のメッセージの長さがデータパケットの長さより大きい場合、該データパケットをキャッシュすることによって更にいくつかのデータパケットの結合を行い、最終的に１つの完全なメッセージを取得し、完全なメッセージの長さを計算して且つ得られた完全なメッセージを解析する第３処理ユニットを起動する、ための第２処理サブモジュールと、を更に含む。
【００３３】
選択的に、上記解析モジュールは、メッセージフィルタリングサブモジュール、及びログ生成サブモジュールを更に含む。
【００３４】
前記メッセージフィルタリングサブモジュールは、メッセージコードに基づきメッセージタイプを識別し、識別したタイプに基づいてメッセージがログ生成に関連するか否かを判断し、メッセージがログ生成に関連しない場合、それを直ちに廃棄し、そうでない場合、ログ生成に関連する各メッセージタイプに応じてそれぞれ以下の処理を行う。
【００３５】
バージョン交渉メッセージに対しては、メッセージにおけるプロトコルバージョン番号を取得してキャッシュし、
ユーザ認証要求メッセージに対しては、メッセージからユーザ名を抽出してキャッシュし、
チャンネル要求メッセージに対しては、要求されたチャンネルタイプを取得してキャッシュし、
チャンネルにおいて伝送したメッセージに対しては、メッセージ方向によって要求に属するか、応答に属するかを判断し、メッセージ方向をキャッシュし、ここで、メッセージ方向がクライアント側からサーバーの方向の場合、要求メッセージであり、逆方向の場合、応答メッセージであると判断する。
【００３６】
前記ログ生成サブモジュールは、キャッシュした内容及び応答データパケットに基づいて解析ログを生成し、解析ログはTCP/IPクワッド、会話ID、会話にログインするユーザ名、ログイン時間、クライアント側の要求命令、要求開始時間、サーバー側がクライアント側に返す応答データ及び応答終了時間を含む。
【００３７】
ここで、前記クライアント側の要求命令とサーバー側がクライアント側に返す応答データは、１つの会話の存続期間内で繰り返して発生してもよいが、生成した各解析ログは、１つのクライアント側の要求命令と１つのサーバー側の応答のみを含み、異なる解析ログの要求及び応答は互いに独立である。
１つの会話の存続期間内では、前記のTCP/IPクワッド、会話ID、ログイン会話のユーザ名及びログイン時間情報は変わらない。
【００３８】
更に選択的に、上記ログ送信モジュールは、パッケージサブモジュールと、送信サブモジュールとを更に含む。
【００３９】
前記パッケージサブモジュールは、ログを送信する際に該ログにログヘッダーを追加することに用いられ、前記ログヘッダーは「ログ番号」、「セグメント化するかどうか」、「セグメント番号」及び「最後のセグメント」を含む。ここで、「ログ番号」は１つのログを特定することに用いられる。「セグメント化するかどうか」はこのログがセグメント化されて送信するか否かをマークすることに用いられ、このマークが0である場合、このセグメントの内容がログ全体の内容であることを示し、そうでない場合、ログがいくつかのセグメントに分けられる。「セグメント番号」及び「最後のセグメント」は、「セグメント化するかどうか」を1にマークした場合だけ意味があり、「セグメント番号」はログフラグメントの固有の識別番号である。
【００４０】
前記送信サブモジュールは、パッケージされたログを記憶サーバーに送信することに用いられる。
【００４１】
ここで、記憶サーバーは、ログフラグメントを受信した後に、同様な「ログ番号」を有するログフラグメントを「セグメント番号」が小さいものから大きいものへ順次結合して１つの完全なログを生成する。
【００４２】
実施例２
本発明は企業や組織のサービス監査の需要を満たすために、SSHプロトコルに基づく会話解析方法を提供する。
【００４３】
本発明によるSSHプロトコルに基づく会話解析方法は、以下のステップを含み、この方法によって処理されるのは平文SSHデータパケットである。
【００４４】
１つのSSHデータパケットが到着すると、それをパケット処理モジュールに渡す。処理する前のデータパケットには、１つの不完全なメッセージが含まれる可能性があり、１つの完全なメッセージが含まれる可能性もあり、複数のメッセージが含まれる可能性もある。パケット処理モジュールはデータパケットを分割したり結合したりすることによって、１つの完全なメッセージを生成し、プロトコル解析モジュールによる解析ができるようにする。
【００４５】
ここで、データパケット分割の過程は、実際にデータパケットからメッセージを抽出する過程であり、メッセージの先頭アドレス及びメッセージ長さで１つのメッセージを特定する。そして、データパケット結合の過程は、キャッシュしたデータパケットによって実現され、再構成されたデータパケットをパケット処理モジュールに渡す。これにより、SSHメッセージのタイミングを確保することができ、結合後のメッセージの完全性とメッセージ内容の正確性が確保できる。
【００４６】
プロトコル解析モジュールは、メッセージコードに基づきメッセージタイプを識別する。異なるメッセージタイプは、SSH会話の異なる階段に対応し、解析モジュールは、該メッセージがログ生成に関連することを識別すると、メッセージヘッダーを解析し、該メッセージが生成ログに関連しないと、それを直ちに廃棄する。
【００４７】
ここで、異なるタイプのメッセージに対しては、解析の方法が異なる。バージョン交渉メッセージに対しては、直ちにメッセージをキャッシュし、ユーザ認証要求メッセージに対しては、メッセージからユーザ名を抽出してキャッシュし、チャンネル要求メッセージに対しては、要求されたチャンネルタイプを取得して、該チャンネルをSSH会話に用いることを確保し、チャンネルにおいて伝送しているメッセージに対しては、メッセージ方向によって要求に属するか、応答に属するかを判断し、メッセージ方向がC→Sであると、要求メッセージであると判断し、逆にメッセージ方向がS→Cであると、応答メッセージであると判断する。異なるタイプのメッセージを解析して、且つ関連内容をキャッシュして解析ログを生成する。
【００４８】
この方法が生成したログは、TCP/IPクワッド、会話ID、会話にログインするユーザ名、ログイン時間等の情報を含み、１つの会話の存続期間内で、バージョン交渉及びユーザ認証過程は１回のみ発生し、解析の際に維持したTCP/IPクワッド、会話ID、会話にログインするユーザ名、ログイン時間等の情報は、１つの会話存続期間内で変わらない。
【００４９】
生成したログはクライアント側の要求命令、要求開始時間、サーバー側がクライアント側に返った応答データ及び応答終了時間を更に含む。ログイン情報とは異なり、クライアント側の要求及びサーバー側の応答は１つの会話の存続期間内で繰り返して発生させることができる。この方法では、各ログに１つの要求と１つの応答のみを含むことに限るため、同一の会話の異なるログはTCP/IPクワッド、会話ID、会話にログインするユーザ名、ログイン時間等の情報を共有し、異なるログの要求及び応答は互いに独立である。
【００５０】
解析過程においてログを生成しながらキャッシュし、ログ伝送にはストリーム送信の方式を採用する。即ち、キャッシュしたログ長さが送信長さに達すると、ログを指定された記憶サーバーに送信する。したがって、１つのログの全部の生成が完成した後に送信する訳ではない。
【００５１】
図２はパケット処理モジュールの処理フローチャートであり、以下のステップを含む。
【００５２】
a)  パケット処理モジュールは、１つのデータパケットを受信した後に、まずバッファにキャッシュしたデータパケットがあるか否かを調査し、キャッシュしたデータパケットが存在しないと、データパケットの中の一番目のメッセージの長さを直ちに計算し、一方、キャッシュしたデータパケットが存在すると、現在のデータパケットがキャッシュしたデータパケット内容の継続であると判断し、現在のデータパケットの内容をキャッシュしたデータパケットにコピーした後に、不完全なメッセージを結合して、結合した後に再び現在のキャッシュしたデータパケットにおける一番目のメッセージの長さを計算する。
【００５３】
b)  算出した一番目のメッセージ長さとデータパケット長さを比較して、比較結果に応じてc)、d)、e)ステップを実行する。
【００５４】
c)  メッセージ長さがデータパケット長さに等しい場合、現在のデータパケット内容は１つの完全なメッセージであると判断して、直ちにメッセージを解析モジュールに渡して解析する。
【００５５】
d)  メッセージ長さがデータパケット長さより小さい場合、現在のデータパケットが１つだけの完全なメッセージを含むことに止まらないと判断し、データパケットから一番目の完全なメッセージを取出して、解析モジュールに渡して解析し、再び残りのデータパケットの中の一番目のメッセージの長さを計算し、b)ステップを繰り返す。
【００５６】
e)  メッセージ長さがデータパケット長さより大きい場合、現在のデータパケットに含まれる内容は１つのメッセージの一部だけであると判断し、不完全なメッセージを解析モジュールに渡すことができないので、現在のデータパケットをまだキャッシュしていない場合、該データパケットをキャッシュし、現在のデータパケットが既にバッファに位置する場合、データパケット内容をバッファのヘッダーに移動して、後続のキャッシュしようとするデータパケットのために記憶空間を空ける。
【００５７】
解析する際に、ユーザが入力した完全な要求を記録する必要があるが、ユーザの入力は様々なショートカットキー又はファンクションキーを併用して行なわれる場合がある。ユーザ要求を復元したい場合に、サーバー側がクライアント側に返すエコーメッセージを識別して理解することができる必要があるが、エコーメッセージを理解するキーはエコーメッセージにおけるエスケープ文字を識別することにある。
【００５８】
表１は本発明による方法のエコーメッセージにおけるエスケープ文字セットである。
【表１】
2017539163.tif 000003
【００５９】
クライアント側は、要求を入力する度にサーバー側からのエコーメッセージを受信し、エコーメッセージにクライアント側が入力した文字を含むとともに、エスケープ文字を含む。表１に示すように、エスケープ文字を解析することによって任意の時刻におけるカーソルの位置及び現在の要求内容を正確に特定することができ、それにより任意の要求内容を完全に復元することができる。
【００６０】
図３は応答解析フローチャートであり、以下のステップを含む。
1)  解析モジュールは１つのS→Cのメッセージを受信し、要求状態が「完了」（finished）であるか否かを判断する。
【００６１】
2)  要求状態が「完了」であると、現在メッセージが応答メッセージであることを示す。応答メッセージはいずれも「＼r＼n」から始まるので、「＼r＼n」メッセージを受信する際に、応答状態を「READY」にセットする。前記方法における応答に対する処理は、応答状態が「READY」である際に、全ての応答メッセージ内容を直接にキャッシュログに書き込む。
【００６２】
3)  ログキャッシュに応答内容を書き込む際に、現在のキャッシュログの長さを判断し、キャッシュログ長さがログ送信長さに達すると、直ちにログを送信する。
【００６３】
4)  次の要求が到着すると前回の応答は終了したと識別して、キャッシュログ長さに関わらず、キャッシュログの末部に応答終了時間及びログ終了マークを加え、直ちにログを送信する。
【００６４】
次回の要求がまだ到着していないと、前回解析して生成した最後のセグメントログの送信をタイマーによってトリガーする必要があり、タイマーはログ送信モジュールをトリガーしてログ状態を監視し、ログ状態が前のタイミングサイクルに対して何の変化もない場合、全部のログを生成したと判断し、直ちに現在にキャッシュしたログフラグメントを送信する。
【００６５】
ストリーム送信方式でログを伝送するため、毎回送信する内容は全部のログの小さいセグメントだけであり、ログ内容の完全性及び正確性を確保するために、ログフラグメントのそれぞれにログヘッダーを加え、ログヘッダーの形式は図４の破線ボックスに示す。ここで、「ログ番号」は１つのログを特定することに用いられる。「セグメント化するかどうか」はこのログがセグメント化して送信されるか否かをマークすることに用いられ、このマークが0である場合、このセグメントの内容がログ全体の内容であることを示し、そうでない場合、ログがいくつかのセグメントに分けられる。「セグメント番号」及び「最後のセグメント」は「セグメント化するかどうか」を1にマークする場合だけに意味があり、「セグメント番号」はログフラグメントの唯一の識別である。記憶サーバーはログフラグメントを受信した後に、同様な「ログ番号」を有するログフラグメントを「セグメント番号」の小さいものから大きいものへ順次に結合して１つの完全なログを結合することが可能である。 
【００６６】
上記の技術的解決手段を採用して得られたログを表２に示す。
表２は本発明による方法によってカスタマイズしたログ形式である。
【表２】
2017539163.tif 000004
【００６７】
以上のように、本発明はSSHプロトコルに基づく会話解析方法を提供し、この方法は、パケット処理モジュール、解析モジュール及びログ送信モジュールという３つのモジュールに関する。(1)パケット処理モジュールは、到着したデータパケットを分割して結合し、１つの完全なメッセージを取得して解析モジュールに渡し、(2)解析モジュールは、メッセージコードによってメッセージタイプを区別して、異なるタイプのメッセージから異なる内容を抽出して、再び抽出した内容を処理した後にログに書き込み、各ログに１回の要求と１回の応答のみを含み、(3)ログ送信モジュールは、ログ状態を監視する役割を担い、且つストリーム送信の方式でログを伝送する。即ちローカルでキャッシュしたログ長さが送信長さに達すると、ログ送信モジュールは、直ちにログを記憶サーバーに送信する。これにより、ログの生成が完了した後に送信する必要がないので、それによりキャッシュ空間を節約できる。本発明の技術はSSH会話に基づく監査を実現することができ、例えば銀行等の機構のためにセキュリティ保証を提供することができる。
【００６８】
最後に、以上の実施例は本発明の技術的解決手段を説明するためのものだけであり、制限するためのものではない。実施例を参照して本発明を詳細に説明したが、当業者は、本発明の技術的解決手段に対する修正や均等な置替えは、本発明の技術的解決手段の精神及び範囲を逸脱せず、本発明の請求項の範囲に含まれることを理解すべきである。
【図１−ａ】
2017539163.tif 000005
【図１−ｂ】
2017539163.tif 000006
【図２】
2017539163.tif 000007
【図３】
2017539163.tif 000008
【図４】
2017539163.tif 000009
【国際調査報告】
2017539163.tif 000010
2017539163.tif 000011
2017539163.tif 000012
2017539163.tif 000013