特表 2023-547698 ネットワークセキュリティ保護方法および保護デバイス

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2023-11-13

(54)【発明の名称】ネットワークセキュリティ保護方法および保護デバイス

(51)【国際特許分類】

   H04L 41/0604 20220101AFI20231106BHJP

   H04L 12/22 20060101ALI20231106BHJP

   H04L 43/02 20220101ALI20231106BHJP

【ＦＩ】

H04L41/0604

H04L12/22

H04L43/02

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2023527654

(86)(22)【出願日】2021-04-20

(85)【翻訳文提出日】2023-05-30

(86)【国際出願番号】 CN2021088490

(87)【国際公開番号】W WO2022100002

(87)【国際公開日】2022-05-19

(31)【優先権主張番号】202011250597.7

(32)【優先日】2020-11-10

(33)【優先権主張国・地域又は機関】CN

(81)【指定国・地域】

(71)【出願人】

【識別番号】503433420

【氏名又は名称】華為技術有限公司

【氏名又は名称原語表記】ＨＵＡＷＥＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＣＯ．，ＬＴＤ．

【住所又は居所原語表記】Ｈｕａｗｅｉ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ Ｂｕｉｌｄｉｎｇ， Ｂａｎｔｉａｎ， Ｌｏｎｇｇａｎｇ Ｄｉｓｔｒｉｃｔ， Ｓｈｅｎｚｈｅｎ， Ｇｕａｎｇｄｏｎｇ ５１８１２９， Ｐ．Ｒ． Ｃｈｉｎａ

(74)【代理人】

【識別番号】100132481

【弁理士】

【氏名又は名称】赤澤 克豪

(74)【代理人】

【識別番号】100115635

【弁理士】

【氏名又は名称】窪田 郁大

(72)【発明者】

【氏名】何 新乾

(72)【発明者】

【氏名】周 侃

【テーマコード（参考）】

5K030

【Ｆターム（参考）】

5K030GA15

5K030HD03

5K030KA07

5K030LB19

(57)【要約】

本出願は、ネットワークセキュリティ保護方法および保護デバイスを提供し、通信技術の分野に関する。保護デバイスは、セッションにおいてクライアントデバイスとサーバとの間で交換されるデータパケットのアプリケーション層データに基づいて、異なる検出モード間での適応的な切り替えを実装する。これは、フローモードのみが使用される場合に脅威が見逃される場合を回避し、プロキシモードのみが使用される場合に大量の不必要なリソースが占有される場合を回避する。したがって、保護効果が改善される。

【特許請求の範囲】

【請求項1】

ネットワークセキュリティ保護方法であって、前記方法は、
保護デバイスによって、第１のモードを使用して、伝送制御プロトコルＴＣＰセッションにおけるデータパケットに対してセキュリティ検出を行う処理において、前記ＴＣＰセッションにおける第１のデータパケットを取得するステップであって、前記ＴＣＰセッションは、クライアントデバイスとサーバとの間のセッションであり、前記保護デバイスは、前記クライアントデバイスと前記サーバとの間に配置され、前記第１のモードは、前記保護デバイスによってサポートされる検出モードのセット内のモードである、ステップと、
前記保護デバイスによって、前記第１のデータパケットのアプリケーション層データに基づいて、第２のモードに切り替えることを決定するステップであって、前記第２のモードは、前記検出モードのセット内の前記第１のモード以外のモードである、ステップと、
前記保護デバイスによって、前記第２のモードに切り替え、前記第２のモードを使用して、前記ＴＣＰセッションにおける後続のパケットに対してセキュリティ検出を行うステップと
を含む、方法。

【請求項2】

前記検出モードセットは、パケットフィルタリングモード、フローモード、またはプロキシモードを含む請求項１に記載の方法。

【請求項3】

前記第１のモードは、フローモードであり、前記第２のモードは、プロキシモードであり、前記保護デバイスによって、前記第１のデータパケットのアプリケーション層データに基づいて、第２のモードに切り替えることを決定する前記ステップは、
前記保護デバイスによって、前記アプリケーション層データに基づいて、前記第１のデータパケットのアプリケーション層プロトコルタイプを識別するステップと、
前記保護デバイスによって、アプリケーション層プロトコルタイプと検出モードとの間の対応に基づいて、前記第１のデータパケットの前記アプリケーション層プロトコルタイプが前記プロキシモードに対応すると決定するステップと、
前記保護デバイスによって、切り替えられるべき前記第２のモードが、前記第１のデータパケットの前記アプリケーション層プロトコルタイプに対応する前記プロキシモードであると決定するステップと
を含む請求項１に記載の方法。

【請求項4】

前記第１のモードは、プロキシモードであり、前記第２のモードは、フローモードであり、前記セキュリティ検出は、アンチウイルスＡＶ検出であり、前記保護デバイスによって、前記第１のデータパケットのアプリケーション層データに基づいて、第２のモードに切り替えることを決定する前記ステップは、
前記保護デバイスによって、前記第１のデータパケットの前記アプリケーション層データに対して行われるＡＶ検出の結果が、ウィルスはないというものである場合、前記保護デバイスによって、切り替えられるべき前記第２のモードが前記フローモードであると決定するステップ
を含む請求項１に記載の方法。

【請求項5】

前記第１のモードは、プロキシモードであり、前記第２のモードは、フローモードであり、前記保護デバイスによって、前記第１のデータパケットのアプリケーション層データに基づいて、第２のモードに切り替えることを決定する前記ステップは、
前記第１のデータパケットの前記アプリケーション層データが、前記クライアントデバイスおよび前記サーバが前記ＴＣＰセッションにおいて暗号化された通信を行おうとしていることを示す場合、前記保護デバイスによって、切り替えられるべき前記第２のモードが前記フローモードであると決定するステップ
を含む請求項１に記載の方法。

【請求項6】

保護デバイスによって、ＴＣＰセッションにおいて第１のデータパケットを取得する前記ステップの前に、前記方法は、
前記保護デバイスによって、前記クライアントデバイスと前記サーバとの間で送信される第１のハンドシェイクパケットを取得するステップであって、前記第１のハンドシェイクパケットは、前記ＴＣＰセッションを作成するために使用され、前記第１のハンドシェイクパケットは、第１のオプションおよび第２のオプションを備え、前記第１のオプションは、前記保護デバイスによってサポートされるオプションであり、前記第２のオプションは、前記保護デバイスによってサポートされないオプションである、ステップと、
前記保護デバイスによって、前記第１のハンドシェイクパケットから前記第２のオプションを削除して、第２のハンドシェイクパケットを取得するステップと、
前記保護デバイスによって、前記第１のハンドシェイクパケットの宛先デバイスへ前記第２のハンドシェイクパケットを送るステップと
をさらに含む請求項１乃至５のいずれか一項に記載の方法。

【請求項7】

前記第１のモードは、前記フローモードであり、前記第２のモードは、前記プロキシモードであり、前記保護デバイスによって、前記第２のモードに切り換える前記ステップは、
前記保護デバイスによって、前記第１のオプションに基づいて、前記ＴＣＰセッションにおいて第２のデータパケットについての肯定応答パケットを生成するステップであって、前記第２のデータパケットは、前記第１のモードを使用して、前記保護デバイスによって受信され、バッファされたパケットである、ステップと、
前記保護デバイスによって、前記第２のデータパケットのソースデバイスへ前記第２のデータパケットについての前記肯定応答パケットを送るステップであって、前記第２のデータパケットの前記ソースデバイスは、前記クライアントデバイスまたは前記サーバである、ステップと
を含む請求項６に記載の方法。

【請求項8】

前記第１のモードは、前記フローモードであり、前記第２のモードは、前記プロキシモードであり、前記保護デバイスによって、前記第２のモードに切り替える前記ステップは、
前記ＴＣＰセッションにおける第３のデータパケットが再送信条件を満たす場合、前記保護デバイスによって、前記第１のオプションに基づいて、前記第３のデータパケットの宛先デバイスへ前記第３のデータパケットを再送するステップであって、前記第３のデータパケットは、前記第１のモードを使用して、前記保護デバイスによって送られたパケットであり、前記第３のデータパケットの前記宛先デバイスは、前記クライアントデバイスまたは前記サーバである、ステップ
を含む請求項６に記載の方法。

【請求項9】

前記第１のモードは、前記プロキシモードであり、前記第２のモードは、前記フローモードであり、前記保護デバイスによって、前記第２のモードに切り替える前記ステップは、
前記ＴＣＰセッションにおける第４のデータパケットが再送信条件を満たす場合、前記保護デバイスによって、前記第１のオプションに基づいて、前記第４のデータパケットの宛先デバイスへ前記第４のデータパケットを再送するステップであって、前記第４のデータパケットは、前記第１のモードを使用して、前記保護デバイスによって送られたパケットであり、前記第４のデータパケットの前記宛先デバイスは、前記クライアントデバイスまたは前記サーバである、ステップ
を含む請求項６に記載の方法。

【請求項10】

前記第１のモードは、前記プロキシモードであり、前記第２のモードは、前記フローモードであり、前記保護デバイスによって、前記第２のモードに切り替える前記ステップは、
前記保護デバイスによって、前記ＴＣＰセッションにおいて第５のデータパケットを検出して、第６のデータパケットを取得するステップであって、前記第５のデータパケットは、前記第１のモードを使用して、前記保護デバイスによって受信されたパケットであり、前記保護デバイスは、前記第１のオプションに基づいて、前記第５のデータパケットを構文解析した後に、前記第５のデータパケットのソースデバイスへ前記第５のデータパケットについての肯定応答パケットを送っており、前記第５のデータパケットの前記ソースデバイスは、前記クライアントデバイスまたは前記サーバである、ステップと、
前記保護デバイスによって、前記第１のオプションに基づいて、前記第５のデータパケットの宛先デバイスへ前記第６のデータパケットを送るステップであって、前記第５のデータパケットの前記ソースデバイスが前記クライアントデバイスである場合、前記第５のデータパケットの前記宛先デバイスは、前記サーバであり、または、前記第５のデータパケットの前記ソースデバイスが前記サーバである場合、前記第５のデータパケットの前記宛先デバイスは、前記クライアントデバイスである、ステップ
を含む請求項６に記載の方法。

【請求項11】

前記第６のデータパケットが再送信条件を満たす場合、前記保護デバイスによって、前記第１のオプションに基づいて、前記第５のデータパケットの前記宛先デバイスへ前記第６のデータパケットを再送する、請求項１０に記載の方法。

【請求項12】

前記再送信条件は、前記保護デバイスが、データパケットについての肯定応答パケットを受信していないことを含み、または
前記第１のオプションは、選択的な肯定応答ＳＡＣＫオプションであり、前記再送信条件は、前記保護デバイスが、データパケットの宛先デバイスからのＳＡＣＫオプション内の情報に基づいて、前記データパケットにおいてパケット損失が発生したと決定することを含む請求項８、９、または１１に記載の方法。

【請求項13】

前記第１のハンドシェイクパケットは、前記クライアントデバイスからの同期シーケンス番号ＳＹＮパケットであり、前記第１のハンドシェイクパケットの前記宛先デバイスは、前記サーバであり、または
前記第１のハンドシェイクパケットは、前記サーバからの同期シーケンス番号肯定応答ＳＹＮ ＡＣＫパケットであり、前記第１のハンドシェイクパケットの前記宛先デバイスは、前記クライアントデバイスである請求項６乃至１２のいずれか一項に記載の方法。

【請求項14】

保護デバイスであって、前記保護デバイスは、クライアントデバイスとサーバとの間に配置され、前記保護デバイスは、
第１のモードを使用して、伝送制御プロトコルＴＣＰセッションにおいてデータパケットに対してセキュリティ検出を行うように構成された処理ユニットであって、前記第１のモードは、前記保護デバイスによってサポートされる検出モードのセット内のモードである、処理ユニットと、
前記処理ユニットが、前記第１のモードを使用して、セキュリティ検出を行う処理において、前記ＴＣＰセッションにおいて第１のデータパケットを取得するように構成された取得ユニットであって、前記ＴＣＰセッションは、前記クライアントデバイスと前記サーバとの間のセッションである、取得ユニットと
を備え、
前記処理ユニットは、前記第１のデータパケットのアプリケーション層データに基づいて、第２のモードに切り替えることを決定するようにさらに構成され、前記第２のモードは、前記検出モードのセット内の前記第１のモード以外のモードであり、
前記処理ユニットは、前記第２のモードに切り替え、前記第２のモードを使用して、前記ＴＣＰセッションにおける後続のパケットに対してセキュリティ検出を行うようにさらに構成される、保護デバイス。

【請求項15】

前記第１のモードは、フローモードであり、前記第２のモードは、プロキシモードであり、前記処理ユニットは、前記アプリケーション層データに基づいて、前記第１のデータパケットのアプリケーション層プロトコルタイプを識別し、アプリケーション層プロトコルタイプと検出モードとの間の対応に基づいて、前記第１のデータパケットの前記アプリケーション層プロトコルタイプが前記プロキシモードに対応すると決定し、切り替えられるべき前記第２のモードが、前記第１のデータパケットの前記アプリケーション層プロトコルタイプに対応する前記プロキシモードであると決定するように構成される請求項１４に記載の保護デバイス。

【請求項16】

前記第１のモードは、プロキシモードであり、前記第２のモードは、フローモードであり、前記セキュリティ検出は、アンチウイルスＡＶ検出であり、前記処理ユニットは、前記第１のデータパケットの前記アプリケーション層データに対して行われるＡＶ検出の結果が、ウィルスはないというものである場合、切り替えられるべき前記第２のモードが前記フローモードであると決定するように構成される請求項１４に記載の保護デバイス。

【請求項17】

前記第１のモードは、プロキシモードであり、前記第２のモードは、フローモードであり、前記処理ユニットは、前記第１のデータパケットの前記アプリケーション層データが、前記クライアントデバイスおよび前記サーバが前記ＴＣＰセッションにおいて暗号化された通信を行おうとしていることを示す場合、切り替えられるべき前記第２のモードが前記フローモードであると決定するように構成される請求項１４に記載の保護デバイス。

【請求項18】

前記取得ユニットは、前記クライアントデバイスと前記サーバとの間で送信される第１のハンドシェイクパケットを取得するようにさらに構成され、前記第１のハンドシェイクパケットは、前記ＴＣＰセッションを作成するために使用され、前記第１のハンドシェイクパケットは、第１のオプションおよび第２のオプションを含み、前記第１のオプションは、前記保護デバイスによってサポートされるオプションであり、前記第２のオプションは、前記保護デバイスによってサポートされないオプションであり、
前記処理ユニットは、前記第１のハンドシェイクパケットから第２のオプションを削除して、第２のハンドシェイクパケットを取得するようにさらに構成され、
前記保護デバイスは、送信ユニットをさらに備え、前記送信ユニットは、前記第１のハンドシェイクパケットの宛先デバイスへ前記第２のハンドシェイクパケットを送るように構成される請求項１４乃至１７のいずれか一項に記載の保護デバイス。

【請求項19】

前記第１のモードは、前記フローモードであり、前記第２のモードは、前記プロキシモードであり、前記処理ユニットは、前記第１のオプションに基づいて、前記ＴＣＰセッションにおける第２のデータパケットについての肯定応答パケットを生成するように構成され、前記第２のデータパケットは、前記第１のモードを使用して、前記保護デバイスによって受信され、バッファされたパケットであり、
前記送信ユニットは、前記第２のデータパケットのソースデバイスへ前記第２のデータパケットについての前記肯定応答パケットを送るように構成され、前記第２のデータパケットの前記ソースデバイスは、前記クライアントデバイスまたは前記サーバである請求項１８に記載の保護デバイス。

【請求項20】

前記第１のモードは、前記フローモードであり、前記第２のモードは、前記プロキシモードであり、前記送信ユニットは、前記ＴＣＰセッションにおける第３のデータパケットが再送信条件を満たす場合、前記第１のオプションに基づいて、前記第３のデータパケットの宛先デバイスへ前記第３のデータパケットを再送するように構成され、前記第３のデータパケットは、前記第１のモードを使用して、前記保護デバイスによって送られたパケットであり、前記第３のデータパケットの前記宛先デバイスは、前記クライアントデバイスまたは前記サーバである請求項１８に記載の保護デバイス。

【請求項21】

前記第１のモードは、前記プロキシモードであり、前記第２のモードは、前記フローモードであり、前記送信ユニットは、前記ＴＣＰセッションにおける第４のデータパケットが再送信条件を満たす場合、前記第１のオプションに基づいて、前記第４のデータパケットの宛先デバイスへ前記第４のデータパケットを再送するように構成され、前記第４のデータパケットは、前記第１のモードを使用して、前記保護デバイスによって送られたパケットであり、前記第４のデータパケットの前記宛先デバイスは、前記クライアントデバイスまたは前記サーバである請求項１８に記載の保護デバイス。

【請求項22】

前記第１のモードは、前記プロキシモードであり、前記第２のモードは、前記フローモードであり、前記処理ユニットは、前記ＴＣＰセッションにおける第５のデータパケットを検出して、第６のデータパケットを取得するように構成され、前記第５のデータパケットは、前記第１のモードを使用して、前記保護デバイスによって受信されたパケットであり、前記保護デバイスは、前記第１のオプションに基づいて、前記第５のデータパケットを構文解析した後に、前記第５のデータパケットのソースデバイスへ前記第５のデータパケットについての肯定応答パケットを送っており、前記第５のデータパケットの前記ソースデバイスは、前記クライアントデバイスまたは前記サーバであり、
前記送信ユニットは、前記第１のオプションに基づいて、前記第５のデータパケットの宛先デバイスへ前記第６のデータパケットを送るように構成され、前記第５のデータパケットの前記ソースデバイスが前記クライアントデバイスである場合、前記第５のデータパケットの前記宛先デバイスは、前記サーバであり、または、前記第５のデータパケットの前記ソースデバイスが前記サーバである場合、前記第５のデータパケットの前記宛先デバイスは、前記クライアントデバイスである請求項１８に記載の保護デバイス。

【請求項23】

前記送信ユニットは、前記第６のデータパケットが再送信条件を満たす場合、前記第１のオプションに基づいて、前記第５のデータパケットの前記宛先デバイスへ前記第６のデータパケットを再送するように構成される請求項２２に記載の保護デバイス。

【請求項24】

保護デバイスであって、前記保護デバイスは、プロセッサと通信インターフェースとを備え、前記プロセッサは、プログラムコードを実行して、前記保護デバイスが、請求項１乃至１３のいずれか一項に記載の方法を行うことを可能にするように構成され、前記通信インターフェースは、パケットを受信するように、または送るように構成される、保護デバイス。

【請求項25】

コンピュータプログラム製品であって、前記コンピュータプログラム製品は、１つまたは複数のコンピュータプログラム命令を備え、前記コンピュータプログラム命令が、コンピュータによってロードされ、実行される場合、前記コンピュータは、請求項１乃至１３のいずれか一項に記載のネットワークセキュリティ保護方法を行うことを可能にされる、コンピュータプログラム製品。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、通信技術の分野に関し、特に、ネットワークセキュリティ保護方法および保護デバイスに関する。

【背景技術】

【0002】

本出願は、２０２０年１１月１０日に出願され、「ＮＥＴＷＯＲＫ ＳＥＣＵＲＩＴＹ ＰＲＯＴＥＣＴＩＯＮ ＭＥＴＨＯＤ ＡＮＤ ＰＲＯＴＥＣＴＩＯＮ ＤＥＶＩＣＥ」と題された中国特許出願第２０２０１１２５０５９７．７号の優先権を主張し、この中国特許出願は、その全体が参照によって本明細書に組み込まれている。

【0003】

既存のネットワークセキュリティ保護解決策の基本原理は、２つのネットワークの間、または保護されるデバイスと別のデバイスとの間に、保護デバイス（例えば、ファイアウォール）を配置することであり、保護デバイスは、保護デバイスを通過するパケットを検出する。保護デバイスの検出モードは、パケットフィルタリングモード、フローモード、およびプロキシモードを含む。パケットフィルタリングモードは、単純な処理ロジックを有する。パケットフィルタリングモードの原理は、保護デバイスが、ファイアウォールを通って流れるデータパケットのパケットヘッダ情報と特定された規則とを比較し、比較結果に基づいて、データパケットを転送するか、またはデータパケットを破棄するかを決定するというものである。

【0004】

フローモードの基本原理は、保護デバイスが、通信ピア（例えば、クライアントデバイスおよびサーバ）間の通信セッションにおけるパケットに対して、パケットフィルタリングモードにおける検出と同様の検出を行い、検出結果およびセッションコンテキスト情報に基づいて、セッションに脅威があるかどうか、およびパケットを破棄するか、またはパケットを転送するかを決定するというものである。フローモードにおいて、保護デバイスが、クライアントデバイスまたはサーバによって送られたパケットを修正することはほとんどなく、保護デバイスが、クライアントデバイスおよびサーバへ能動的にパケットを送ることはほとんどない。しかしながら、フローモードにおいて、複雑なネットワーク攻撃を検出することは困難であり、セキュリティ保護要件が十分に満たされることはできない。例えば、アンチウイルスシナリオにおいて、フローモードは、通常、高度なウィルスが検出されることができず、ウィルス拡散が完全に阻止されることはできない場合を引き起こす。

【0005】

プロキシモードの原理は、サーバの代わりに保護デバイスが、クライアントデバイスへ肯定応答パケットを送り、クライアントデバイスの代わりに保護デバイスが、サーバへ肯定応答パケットを送るというものである。プロキシモードにおいて、保護デバイスは、パケットを確実に送るために、伝送制御プロトコル／インターネットプロトコル（ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ／ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ、ＴＣＰ／ＩＰ）プロトコルスタックを使用する必要がある。プロキシモードは、複雑なネットワーク攻撃を検出することを助け、セキュリティ保護要件をより良好に満たすことができる。しかしながら、プロキシモードにおいて、保護デバイスは、大量のデータパケットをバッファおよび再アセンブルし、完全なプロトコルスタックをサポートする必要がある。したがって、大量のリソースが消費される。

【0006】

前述の３つの検出モードにおいて、パケットフィルタリングモードおよびフローモードは、複雑な攻撃を検出する能力を著しく欠いており、プロキシモードは、あまりにも多くのリソースを消費し、包括的な検出を実装することができない。結果として、既存のネットワークセキュリティ保護技術は、不十分な保護効果を有する。

【発明の概要】

【0007】

本出願の実施形態は、ネットワークセキュリティ保護技術の保護効果を改善するための、ネットワークセキュリティ保護方法および保護デバイスを提供する。技術的解決策は、以下の通りである。

【0008】

第１の態様によれば、ネットワークセキュリティ保護方法が提供される。本方法において、保護デバイスは、第１のモードを使用してＴＣＰセッションにおけるデータパケットに対してセキュリティ検出を行う処理において、ＴＣＰセッションにおける第１のデータパケットを取得し、ＴＣＰセッションは、クライアントデバイスとサーバとの間のセッションであり、保護デバイスは、クライアントデバイスとサーバとの間に配置され、第１のモードは、保護デバイスによってサポートされる検出モードのセット内のモードであり、保護デバイスは、第１のデータパケットのアプリケーション層データに基づいて、第２のモードに切り換えることを決定し、第２のモードは、検出モードのセット内の第１のモード以外のモードであり、保護デバイスは、第２のモードに切り替え、第２のモードを使用して、ＴＣＰセッションにおける後続のパケットに対してセキュリティ検出を行う。

【0009】

第１の態様において提供される方法において、保護デバイスは、セッションにおいてクライアントデバイスとサーバとの間で交換されるデータパケットに基づいて、異なる検出モードの間で適応的に切り替える。これは、フローモードのみが使用される場合に脅威が見逃される場合を回避し、プロキシモードのみが使用される場合に大量の不必要なリソースが占有される場合を回避する。したがって、保護効果および性能が改善される。

【0010】

任意選択で、検出モードセットは、パケットフィルタリングモード、フローモード、またはプロキシモードを含む。

【0011】

前述の任意選択の手法において、保護デバイスが複数の検出モードをサポートする場合、保護デバイスは、パケットフィルタリングモード、フローモード、またはプロキシモードなどの複数のモード内のモードを必要に応じて選択し、それによって、より多くの適用シナリオの要件を満たし、柔軟性を改善することができる。

【0012】

任意選択で、第１のモードは、フローモードであり、第２のモードは、プロキシモードであり、保護デバイスが、第１のデータパケットのアプリケーション層データに基づいて、第２のモードに切り替えることを決定することは、以下を含む。保護デバイスは、アプリケーション層データに基づいて、第１のデータパケットのアプリケーション層プロトコルタイプを識別し、保護デバイスは、アプリケーション層プロトコルタイプと検出モードとの間の対応に基づいて、第１のデータパケットのアプリケーション層プロトコルタイプがプロキシモードに対応すると決定し、保護デバイスは、切り替えられるべき第２のモードが、第１のデータパケットのアプリケーション層プロトコルタイプに対応するプロキシモードであると決定する。

【0013】

前述の任意選択の手法において、同じＴＣＰセッション相互作用処理において、検出モードは、アプリケーション層プロトコルタイプに基づいて、適応的に選択され、その結果、保護デバイスの検出モードがアプリケーション層検出の要件を満たすことが確実にされ、それによって、セキュリティとデバイスリソース占有とのバランスを取ることを助ける。

【0014】

任意選択で、第１のモードは、プロキシモードであり、第２のモードは、フローモードであり、セキュリティ検出は、アンチウイルス（ａｎｔｉ－ｖｉｒｕｓ、ＡＶ）検出であり、保護デバイスが、第１のデータパケットのアプリケーション層データに基づいて、第２のモードに切り替えることを決定することは、以下を含む。第１のデータパケットのアプリケーション層データに対して保護デバイスによって行われるＡＶ検出の結果が、ウィルスが存在しないというものである場合、保護デバイスは、切り替えられるべき第２のモードがフローモードであると決定する。

【0015】

前述の任意選択の手法において、ＡＶ検出結果に基づいて、クライアントデバイスとサーバとの間で交換されるデータパケットがウィルスを含まないことを見出した場合、保護デバイスは、プロキシモードからフローモードに切り替えて、フローモードを使用して後続の処理手順を加速し、デバイスのリソース占有を低減し、検出性能を改善することを助ける。

【0016】

任意選択で、第１のモードは、プロキシモードであり、第２のモードは、フローモードであり、保護デバイスが、第１のデータパケットのアプリケーション層データに基づいて、第２のモードに切り替えることを決定することは、以下を含む。第１のデータパケットのアプリケーション層データが、クライアントデバイスおよびサーバがＴＣＰセッションにおいて暗号化された通信を行おうとしていることを示す場合、保護デバイスは、切り替えられるべき第２のモードがフローモードであると決定する。

【0017】

前述の任意選択の手法において、保護デバイスは、クライアントデバイスおよびサーバが暗号化された通信を続いて行おうとしていることを見出した場合、プロキシモードからフローモードに切り替える。これは、保護デバイスが暗号化／復号機能をサポートしないことが理由で、保護デバイスがプロキシモードを使用して、暗号化されたデータを検出することができないシナリオに際してフローモードに戻ることを助け、それによって、フローモードを使用して後続の処理手順を加速し、デバイスのリソース占有を低減し、検出性能を改善する。

【0018】

任意選択で、保護デバイスが、ＴＣＰセッションにおいて第１のデータパケットを取得する前に、本方法は、以下をさらに含む。
保護デバイスは、クライアントデバイスとサーバとの間で送信された第１のハンドシェイクパケットを取得し、第１のハンドシェイクパケットは、ＴＣＰセッションを作成するために使用され、第１のハンドシェイクパケットは、第１のオプションおよび第２のオプションを含み、第１のオプションは、保護デバイスによってサポートされるオプションであり、第２のオプションは、保護デバイスによってサポートされないオプションであり、保護デバイスは、第１のハンドシェイクパケットから第２のオプションを削除して、第２のハンドシェイクパケットを取得し、保護デバイスは、第１のハンドシェイクパケットの宛先デバイスへ第２のハンドシェイクパケットを送る。

【0019】

前述の任意選択の手法において、クライアントデバイスおよびサーバデバイスが、保護デバイスによってサポートされないオプションを使用することによって通信を行うことが理由で、モード切り替え手順においてクライアントまたはサーバによって使用されるオプションを構文解析することが保護デバイスにとって困難な場合に引き起こされるパケット送信障害が回避され、それによって、モード切り替え手順における信頼性および成功率を改善する。

【0020】

任意選択で、第１のモードは、フローモードであり、第２のモードは、プロキシモードであり、保護デバイスが第２のモードに切り替えることは、以下を含む。保護デバイスは、第１のオプションに基づいて、ＴＣＰセッションにおける第２のデータパケットについての肯定応答パケットを生成し、第２のデータパケットは、保護デバイスによって第１のモードを使用して受信され、バッファされたパケットであり、保護デバイスは、第２のデータパケットのソースデバイスへ第２のデータパケットについての肯定応答パケットを送り、第２のデータパケットのソースデバイスは、クライアントデバイスまたはサーバである。

【0021】

前述の任意選択の手法において、データパケットがフローモードを使用してバッファされた複雑な場合おいて、モードをどのように切り替えるかに関する実装が提供され、それによって、解決策の可用性を改善する。

【0022】

任意選択で、第１のモードは、フローモードであり、第２のモードは、プロキシモードであり、保護デバイスが第２のモードに切り替えることは、以下を含む。ＴＣＰセッションにおける第３のデータパケットが再送信条件を満たす場合、保護デバイスは、第１のオプションに基づいて、第３のデータパケットの宛先デバイスへ第３のデータパケットを再送し、第３のデータパケットは、保護デバイスによって第１のモードを使用して送られたパケットであり、第３のデータパケットの宛先デバイスは、クライアントデバイスまたはサーバである。

【0023】

前述の任意選択の手法において、データパケットがフローモードを使用して送られた複雑な場合において、モードをどのように切り替えるかに関する実装が提供され、それによって、解決策の可用性を改善する。

【0024】

任意選択で、第１のモードは、プロキシモードであり、第２のモードは、フローモードであり、保護デバイスが第２のモードに切り替えることは、以下を含む。ＴＣＰセッションにおける第４のデータパケットが再送信条件を満たす場合、保護デバイスは、第１のオプションに基づいて、第４のデータパケットの宛先デバイスへ第４のデータパケットを再送し、第４のデータパケットは、保護デバイスによって第１のモードを使用して送られたパケットであり、第４のデータパケットの宛先デバイスは、クライアントデバイスまたはサーバである。

【0025】

前述の任意選択の手法において、データパケットがプロキシモードを使用して送られた複雑な場合において、モードをどのように切り替えるかに関する実装が提供され、それによって、解決策の可用性を改善する。

【0026】

任意選択で、第１のモードは、プロキシモードであり、第２のモードは、フローモードであり、保護デバイスが第２のモードに切り替えることは、以下を含む。保護デバイスは、ＴＣＰセッションにおける第５のデータパケットを検出して、第６のデータパケットを取得し、第５のデータパケットは、保護デバイスによって第１のモードを使用して受信されたパケットであり、保護デバイスは、第１のオプションに基づいて第５のデータパケットを構文解析した後に、第５のデータパケットのソースデバイスへ第５のデータパケットについての肯定応答パケットを送り、第５のデータパケットのソースデバイスは、クライアントデバイスまたはサーバであり、保護デバイスは、第１のオプションに基づいて、第５のデータパケットの宛先デバイスへ第６のデータパケットを送り、第５のデータパケットのソースデバイスがクライアントデバイスである場合、第５のデータパケットの宛先デバイスは、サーバであり、または第５のデータパケットのソースデバイスがサーバである場合、第５のデータパケットの宛先デバイスは、クライアントデバイスである。

【0027】

前述の任意選択の手法において、データパケットがプロキシモードを使用して受信された複雑な場合において、モードをどのように切り替えるかに関する実装が提供され、それによって、解決策の可用性を改善する。

【0028】

任意選択で、第６のデータパケットが再送信条件を満たす場合、保護デバイスは、第１のオプションに基づいて、第５のデータパケットの宛先デバイスへ第６のデータパケットを再送する。

【0029】

前述の任意選択の手法において、プロキシモードを使用して以前に送られたデータパケットの送信障害が回避され、通信信頼性が改善される。

【0030】

任意選択で、再送信条件は、以下を含む。保護デバイスは、データパケットについての肯定応答パケットを受信しておらず、または、第１のオプションは、選択的な肯定応答（ｓｅｌｅｃｔｉｖｅ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ、ＳＡＣＫ）オプションであり、再送信条件は、以下を含む。保護デバイスは、データパケットの宛先デバイスからのＳＡＣＫオプションにおける情報に基づいて、データパケットにおいてパケット損失が発生したと決定する。

【0031】

前述の任意選択の手法は、保護デバイスがプロキシモードを使用してパケット送信信頼性を確実にすることを助ける。

【0032】

任意選択で、第１のハンドシェイクパケットは、クライアントデバイスからの同期シーケンス番号（ｓｙｎｃｈｒｏｎｉｚｅ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒｓ、ＳＹＮ）パケットであり、第１のハンドシェイクパケットの宛先デバイスは、サーバであり、または、第１のハンドシェイクパケットは、サーバからの同期シーケンス番号肯定応答（ｓｙｎｃｈｒｏｎｉｚｅ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒｓ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ、ＳＹＮ ＡＣＫ）パケットであり、第１のハンドシェイクパケットの宛先デバイスは、クライアントデバイスである。

【0033】

第２の態様によれば、保護デバイスが提供される。保護デバイスは、第１の態様または第１の態様の任意選択の手法のいずれか１つを実装する機能を有する。保護デバイスは、少なくとも１ユニットを含み、少なくとも１ユニットは、第１の態様または第１の態様の任意選択の手法のいずれか１つにおいて提供される方法を実装するように構成される。

【0034】

いくつかの実施形態において、保護デバイスにおけるユニットは、ソフトウェアを使用することによって実装され、保護デバイスにおけるユニットは、プログラムモジュールである。いくつかの他の実施形態において、保護デバイスにおけるユニットは、ハードウェアまたはファームウェアを使用することによって実装される。第２の態様において提供される保護デバイスの詳細については、第１の態様または第１の態様の任意選択の手法のいずれか１つを参照されたい。詳細は、ここでは再度説明されない。

【0035】

第３の態様によれば、保護デバイスが提供される。保護デバイスは、プロセッサと通信インターフェースとを含む。プロセッサは、命令を実行し、その結果、保護デバイスが、第１の態様または第１の態様の任意選択の手法のいずれか１つにおいて提供される方法を行うように構成される。通信インターフェースは、パケットを受信するように、または送るように構成される。第３の態様において提供される保護デバイスの詳細については、第１の態様または第１の態様の任意選択の手法のいずれか１つを参照されたい。詳細は、ここでは再度説明されない。

【0036】

第４の態様によれば、コンピュータ可読記憶媒体が提供される。記憶媒体は、少なくとも１つの命令を記憶し、命令は、プロセッサによって読み取られ、その結果、保護デバイスは、第１の態様または第１の態様の任意選択の手法のいずれか１つにおいて提供される方法を行う。

【0037】

第５の態様によれば、コンピュータプログラム製品が提供される。コンピュータプログラム製品は、１つまたは複数のコンピュータプログラム命令を含み、コンピュータプログラム命令がコンピュータによってロードされ、実行される場合、コンピュータは、第１の態様または第１の態様の任意選択の手法のいずれか１つにおいて提供される方法を行うことを可能にされる。

【0038】

第６の態様によれば、チップが提供される。チップが保護デバイス上で稼働する場合、保護デバイスは、第１の態様または第１の態様の任意選択の手法のいずれか１つにおいて提供される方法を行うことを可能にされる。

【0039】

第７の態様によれば、ネットワークシステムが提供される。ネットワークシステムは、保護デバイスと、クライアントデバイスと、サーバとを含み、保護デバイスは、第１の態様または第１の態様の任意選択の手法のいずれか１つによる方法を行うように構成される。

【図面の簡単な説明】

【0040】

【図1】本出願の一実施形態による、フローモードにおけるパケット交換のフローチャートである。

【図2】本出願の一実施形態による、プロキシモードにおけるパケット交換のフローチャートである。

【図3】本出願の一実施形態による典型的な適用シナリオの概略図である。

【図4】本出願の一実施形態による保護デバイスの構造の概略図である。

【図5】本出願の一実施形態によるネットワークセキュリティ保護方法のフローチャートである。

【図6】本出願の一実施形態による、クライアントとサーバとの間の三方向ハンドシェイクのフローチャートである。

【図7】本出願の一実施形態による、三方向ハンドシェイクフェーズにおける保護デバイスの処理のフローチャートである。

【図8】本出願の一実施形態による保護デバイスのシステムアーキテクチャの図である。

【図9】本出願の一実施形態による保護デバイスのシステムアーキテクチャの図である。

【図10】本出願の一実施形態による保護デバイスの構造の概略図である。

【発明を実施するための形態】

【0041】

本出願の目的、技術的解決策、および利点をより明確にするために、以下は、添付の図面を参照しつつ、本出願の実装を詳細にさらに説明する。

【0042】

最も初期のファイアウォールは、転送されたデータパケットをフィルタリングするために従来のルータに基づいたアクセス制御リスト（ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｌｉｓｔ、ＡＣＬ）を追加することによって実装され、パケットフィルタリングファイアウォールと称される。パケットフィルタリングの基本原理は、以下の通りでる。ファイアウォールは、まず、転送されるべきデータパケットのパケットヘッダ情報を取得する。パケットヘッダ情報は、ネットワーク層情報、例えば、インターネットプロトコル（ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ、ＩＰ）アドレス、ソースポート、および宛先ポートなどである。次いで、ファイアウォールは、パケットヘッダ情報と特定された規則（ＡＣＬにおけるエントリ）とを比較し、ファイアウォールは、比較結果に基づいて、データパケットを転送または破棄する。

【0043】

例えば、ＡＣＬを使用することによって特定される規則は、外部インターネットのユーザが、企業の内部サーバ（ポート８０）のみにアクセスすることを可能にされるが、ファイル転送プロトコル（ｆｉｌｅ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ、ＦＴＰ）サーバ（ポート２１）にアクセスすることができないというものである。この場合において、ファイアウォールがパケットフィルタリング手段を使用する場合において、データパケットが外部インターネットからのものであり、宛先ポート番号が８０であるとき、ファイアウォールは、データパケットを転送し、または、データパケットが外部インターネットからのものであり、宛先ポート番号が２１であるとき、ファイアウォールは、データパケットを破棄する。

【0044】

フローモード（ｆｌｏｗ ｍｏｄｅ）は、前述のパケットフィルタリングモードに基づいたセッション状態情報をさらに伴う。図１は、フローモードにおけるパケット交換の処理を示す。フローモードにおいて、ファイアウォールは、クライアントおよびサーバによって送られた元のパケットに対してパケットフィルタリングマッチングを行い、パケットを破棄するか、またはパケットを転送するかを決定する。フローモードにおいて、ファイアウォールは、セッション状態情報を維持するが、ファイアウォールは、パケットを修正することはほとんどなく、パケットを能動的に生成し、クライアントおよびサーバへパケットを送ることはほとんどない。パケット送信の信頼性は、クライアントおよびサーバに配置される伝送制御プロトコル（ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ、ＴＣＰ）／ＩＰプロトコルスタックに依存する。例えば、クライアントによって送られたデータパケットが、ファイアウォールによって検出された後に、データパケットがサーバへ送られているときに予期せず失われた場合、クライアント上のＴＣＰ再送信機構に基づいて、クライアントは、失われたパケット損失を再送する責任を負う。

【0045】

ネットワークおよびアプリケーションの複雑さの増加に伴って、ネットワーク層情報検出のための単純なパケットフィルタリング技術は、セキュリティ保護要件を満たすことができない。例えば、パケットが、ハイパーテキスト転送プロトコル（ｈｙｐｅｒ ｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ、ＨＴＴＰ）トンネリング技術を使用することによって送信される場合、ポート８０は、ＦＴＰアプリケーションを実際に搬送することができる。

【0046】

これを考慮して、コンテンツ層データを検査するためのディープパケットインスペクション（ｄｅｅｐ ｐａｃｋｅｔ ｉｎｓｐｅｃｔｉｏｎ、ＤＰＩ）技術が出現する。典型的なＤＰＩ技術は、例えば、アプリケーション識別技術および侵入防止システム（ｉｎｔｒｕｓｉｏｎ ｐｒｅｖｅｎｔｉｏｎ ｓｙｓｔｅｍ、ＩＰＳ）技術を含む。しかしながら、フローモードは、依然としてＤＰＩ技術において主に使用されている。具体的には、パケットは修正されることがほとんどなく、新しいパケットは生成されることがほとんどない。ほとんどの場合において、セキュリティ検出のみが元のパケットに対して行われるが、検出されるコンテンツは、ネットワーク層情報のみからアプリケーション層情報へ深化し、すなわち、パケットコンテンツ全体が検出される。新しいパケットを生成する場合は、通常、以下の通りである。攻撃が検出された場合、またはセッションがブロックされる必要がある場合、保護デバイスは、接続再設定（ｒｅｓｅｔ ｔｈｅ ｃｏｎｎｅｃｔｉｏｎ、ＲＳＴ）パケットを単純に構築し、ＴＣＰに従ってＲＳＴパケットを送って、トラフィックをブロックする。

【0047】

しかしながら、検出結果を取得するために比較的大量のデータが必要とされる、または比較的大量のデータが修正される必要がある、いくつかの複雑なセキュリティ検出サービスの場合、フローモードは、複雑なセキュリティ検出サービスを十分にサポートすることができない。例えば、アンチウイルス（ａｎｔｉ－ｖｉｒｕｓ、ＡＶ）シナリオにおいて、攻撃が検出されないという問題が、フローモードにおいて発生する可能性がある。これは、フローモードが大きな限界を有するからである。フローモードの限界は、以下の通りである。データ取得は、フローモードを使用するクライアントとサーバとの間の通信に依存する。受信されたデータは、フローモードを使用して、できるだけ早く転送される必要がある。さもなければ、クライアントとサーバとの間の相互作用が影響を受け得る。

【0048】

ＡＶ検出シナリオが、例として使用される。アンチウイルス機能は、いくつかの進化したウィルスを検出するために、完全な送信されたファイルが取得されることを必要とする。しかしながら、ＴＣＰ送信機構は、クライアントが特定のデータ（ファイルの一部）を送った後に、サーバが応答する必要があり、クライアントは、応答を受信した後にのみ、後続のデータを送り続けることを必要とする。しかしながら、サーバは、サーバがクライアントからデータを受信した後にのみ、応答する。したがって、ファイアウォールがフローモードを使用する場合、データパケットのみが送られることが可能である。サーバが、ファイアウォールからデータパケットを受信し、応答した後にのみ、クライアントは、後続のデータパケットを送る。ファイアウォールは、データパケットが送られた後にのみ、（ファイアウォールによってバッファされ、コピーされた）抽出されたファイルに対してウィルス検出を行い始めることができる。この場合において、ファイアウォールがウィルスを発見しても、ファイアウォールは、ウィルスをブロックすることができない。これは、ほとんど全部のデータパケットがサーバへ送られており、ウィルスの実際に有効な部分が送られており、攻撃が形成されているからである。サーバのための保護効果が不十分であることは明らかである。また、フローモードにおいて、ファイアウォールがウィルスを検出しても、ファイアウォールは、セッションを単純にブロックすることによって攻撃をブロックすることしかできず、ユーザがセッション中断理由を十分に認識することを確実にすることができない。また、セッションがブロックされた場合、アプリケーションは、いくつかの再開可能なデータ転送機構を通じて、残りのデータコンテンツを送ることができる。結果として、ファイアウォールは、ウィルス拡散を完全にはブロックすることができない。

【0049】

ウィルスをブロックするために、プロキシモード（ｐｒｏｘｙ ｍｏｄｅ）を導入する研究もある。

【0050】

図２は、プロキシモードにおけるパケット交換の処理を示す。プロキシモードにおいて、ファイアウォールは、シミュレーションされるサーバとしての役割を果たし、サーバの代わりにファイアウォールが、クライアントと相互作用する。また、ファイアウォールは、シミュレーションされるクライアントとしての役割を果たし、クライアントの代わりにファイアウォールが、サーバと相互作用する。例えば、ウィルス検出シナリオにおいて、サーバの代わりにファイアウォールが、クライアントへ肯定応答（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ、ＡＣＫ）パケットを送り、その結果、クライアントは、肯定応答パケットのトリガリングの下で、後続のデータパケットを送り続ける。ファイアウォールとクライアントとがデータパケットを交換する処理において、データパケットは、サーバへ送られない。ファイアウォールが、クライアントから全てのデータパケットを取得し、次いで、完全なファイルコンテンツを取得した後に、ファイアウォールは、ウィルス検出を開始する。ファイアウォールがウィルスを発見した場合、ファイアウォールは、ウィルスを含有するファイル全体を削除して、ウィルスがサーバへ送られないことを確実にする。代替として、ファイアウォールは、アタッチメントを削除しないが、プロンプト情報を追加することによってアタッチメント内のウィルスの存在をユーザに通知する。ウィルスが発見されないファイルの場合、クライアントの代わりにファイアウォールが、サーバへファイルを送る。

【0051】

プロキシモードにおいて、ファイアウォールは、データパケットのソース側（例えば、クライアント）へ肯定応答パケットを能動的に返し、その結果、ソース側は、肯定応答パケットのトリガリングの下で、後続のデータパケットを送り続けることが、プロキシモードの原理から分かる。したがって、ファイアウォールは、より多くのデータパケットを受信し、それによって、検出のためのより多くのデータを取得することができる。プロキシモードが複雑なネットワーク攻撃を検出し、セキュリティ検出の精度を改善することに役立つことは明らかである。また、プロキシモードにおいて、ファイアウォールは、ファイルの完全なコンテンツを検出し、ファイルが安全であると決定した後にのみ、データパケットの宛先側（例えば、サーバ）へファイルを転送する。これは、ファイルがウィルスを含有することは検出されたが、ウィルスを含有するファイルが宛先側へ転送済みとなる場合を回避する。ウィルス拡散がより良好にブロックされることが可能であり、セキュリティ保護の効果が改善されることが可能であることは、明らかである。

【0052】

しかしながら、プロキシモードにおいて、ファイアウォールがデータパケットの宛先側（例えば、サーバ）へデータパケットを転送する前に、ファイアウォールは、データパケットのソース側（例えば、クライアント）へ肯定応答パケットを送っている。したがって、ファイアウォールが、データパケットの宛先側へデータパケットを続いて送る処理において、データパケットが失われていると、ファイアウォールは、データパケットを再送信する必要がある。したがって、ファイアウォールは、再送信機能を実装するために完全なＴＣＰ／ＩＰプロトコルスタックを有する必要があり、肯定応答パケットが受信されないデータパケットをバッファする必要がある。

【0053】

フローモードおよびプロキシモードを要約することによって、２つの検出モードにおいて、プロキシモードは、アンチウイルスなどの複雑なサービスの要件を満たすことができ、より良好な保護効果を有することができることが分かる。しかしながら、プロキシモードにおいて、ファイアウォールは、大量のパケットをバッファする必要があり、パケットを確実に送るためにＴＣＰ／ＩＰプロトコルスタックをサポートする必要がある。したがって、フローモードと比較して、プロキシモードは、より多くのリソースを消費する必要があり、プロキシモードは、より複雑な処理ロジックを有する。

【0054】

一般的な解決策は、ファイアウォールが、ユーザの設定に基づいたプロキシモードを使用して、複雑なサービス処理を必要とするトラフィックを処理し、ファイアウォールが、フローモードを使用して、他のトラフィックを処理することである。

【0055】

しかしながら、プロキシモードを使用する従来の処理解決策において、標準的なＴＣＰ／ＩＰプロトコルスタックのセッションを確立することは、ファイアウォールが、ＴＣＰ同期シーケンス番号（ｓｙｎｃｈｒｏｎｉｚｅ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒｓ、ＳＹＮ）パケットを受信する瞬間に、処理のためにプロキシモードを使用するべきかどうかを決定することを必要とする。しかしながら、ライブネットワーク（非標準ポート）上のトラフィックの複雑さ、およびユーザ設定（アプリケーション層ベースの設定）の柔軟性に起因して、特定のデータパケット交換を行った後にのみ、ファイアウォールは、処理のためにプロキシモードを使用するべきかどうかを決定することができる。

【0056】

非標準ポートのパケットは、アプリケーション層プロトコルに対応する標準ポート番号を使用することによって、サーバまたはクライアントによって交換されないパケットである。非標準ポートのパケットを検出するシナリオにおいて、ファイアウォールは、パケットのポート番号を使用することによってアプリケーション層プロトコルのタイプを直接識別することができない。メールが簡易メール転送プロトコル（ｓｉｍｐｌｅ ｍａｉｌ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ、ＳＭＴＰ）に基づいて送信されるシナリオが、例として使用される。一般に、ＳＭＴＰはＴＣＰポート２５上で稼働し、すなわち、ＳＭＴＰに対応する標準ポート番号は２５である。しかしながら、多くのシナリオにおいて、メールサーバは、ポート２５を使用せず、任意のＴＣＰポート上で稼働する。例えば、前もって知られておらず、かつ、ＴＣＰポート２６上で稼働するＳＭＴＰメールサーバが、ライブネットワーク内に存在する。クライアントは、このサーバを通じてメールを送る。ファイアウォールが、クライアントによって送られたＳＹＮパケットを受信した場合、ファイアウォールデバイスは、ＳＹＮパケット内のポート番号が２６であることを見出す。しかしながら、ファイアウォールデバイスは、ＴＣＰポート２６上で稼働するプロトコルを前もって知らない。したがって、ＳＹＮパケットを受信した場合、ファイアウォールは、このセッションを処理するためにプロキシモードを使用するべきかどうかを決定することができない。

【0057】

前述のシナリオにおける要件を考慮して、いくつかの研究において、ファイアウォールが、ＳＹＮパケット、例えば、ＴＣＰポート２５上にないＳＭＴＰトラフィック、またはＴＣＰポート４４３上にないセキュリティソケット層（ｓｅｃｕｒｉｔｙ ｓｏｃｋｅｔｓ ｌａｙｅｒ、ＳＳＬ）トラフィックを受信する場合に、プロキシモードを使用するべきかどうかを決定することができない場合について、ファイアウォールは、トラフィックを検出するためにフローモードをデフォルトで使用する。ファイアウォールが、プロトコル識別を通じてパケットのプロトコルタイプを見出した後に、ファイアウォールは、サーバＩＰアドレスおよびポート番号を記録して、プロトコル識別テーブルを形成する。新しいセッションが続いて確立される場合、すなわち、後続のセッションのＳＹＮパケットが到着する場合、ファイアウォールは、プロトコル識別テーブルに基づいてプロトコルタイプを識別した後に、プロキシモードを使用して、後続のセッションを処理する。

【0058】

研究過程において、前述の解決策が多くの欠点を有することが見出されている。第１のフローは、プロキシモードを使用して処理されない。したがって、検出のためにプロキシモードに依存する複雑なサービス、例えば、ＳＳＬ復号などの特性の場合、第１のフローにおいて攻撃挙動がある場合、ファイアウォールは、その攻撃挙動を検出することができない。結果として、攻撃は検出されず、ネットワークセキュリティは著しく影響を受ける。また、プロトコル識別の精度、ならびに同じサーバＩＰアドレスおよびポート上のプロトコルの動的な変化は、この方法の不正確な適用につながることがあり、上位層サービスの正確な実装が確実にされることができない。

【0059】

攻撃が検出されないという問題を回避するために、別の方法は、受信されたＳＹＮパケットを処理するためにプロキシモードを使用するべきかどうかが決定されない場合に、ファイアウォールが処理のためにプロキシモードをデフォルトで使用するというものである。

【0060】

研究過程において、前述の解決策も多くの欠点を有することが見出されている。ファイアウォールは、プロキシモードを使用して処理される必要のない大量のトラフィックを処理するためにプロキシモードを使用するので、ファイアウォールは、大量のデバイスリソースを消費し、不十分な性能を有する。ファイアウォールによって検出されることが可能な全体的なトラフィックが減少し、処理遅延が増加し、不十分なユーザ体験をもたらす。ユーザは、必要なセキュリティ検出がトラフィックに対して行われることを確実にするために、ファイアウォールに対してデバイス更新を行うことさえ必要とされ得る。

【0061】

これを考慮して、本出願の実施形態は、フローモードとプロキシモードとの間で適応的に切り替えるための解決策を提供する。この技術的解決策を実装することによって、ファイアウォールまたは別の保護デバイスは、アプリケーション層のセキュリティ検出要件に基づいて、同じＴＣＰセッション内の後続のデータパケットを検出するために、フローモードまたはプロキシモードを動的に選択し、それによって、オンデマンドの動的な切り替えを実装することができる。

【0062】

したがって、この技術的解決策は、フローモードとプロキシモードとの両方を利用し、単一の検出モードが使用される場合に存在する前述の欠点を克服することができる。具体的には、フローモードが第１のフローに対してデフォルトで使用される解決策と比較して、この技術的解決策は、全てのトラフィック、非標準ポートの第１のフローに対してさえ、十分なセキュリティ検出が行われることを確実にすることができ、脅威が見逃されず、それによって、セキュリティ保護効果を十分に改善する。プロキシモードがデフォルトで使用される解決策と比較して、この技術的解決策は、プロキシセッションの量を大幅に低減し、デバイスのリソース消費を低減し、デバイスの全体的な処理能力を改善する。

【0063】

以下は、システム稼働環境、ハードウェア装置、ソフトウェア装置、および方法手順などの複数の視点から、技術的解決策を詳細に説明する。

【0064】

図３を参照すると、以下は、本出願の一実施形態において提供されるシステム稼働環境を説明する。

【0065】

図３は、本出願の一実施形態による典型的な適用シナリオ１０の概略図である。適用シナリオ１０は、クライアントデバイス１１、サーバ１２、および保護デバイス１３を含む。以下は、クライアントデバイス１１、サーバ１２、および保護デバイス１３を別々に説明する。

【0066】

（１）クライアントデバイス１１

【0067】

クライアントデバイス１１は、ＴＣＰセッションにおいてアクセスを開始するデバイスである。クライアントデバイス１１は、パーソナルコンピュータ、携帯電話、サーバ１２、ノート型コンピュータ、ＩＰ電話、カメラ、タブレット型コンピュータ、ウェアラブルデバイス等を含むが、これらに限定されない。例えば、クライアントデバイス１１は、企業内の従業員のオフィスデバイスである。

【0068】

いくつかの実施形態において、メールボックスクライアントまたはファイル転送クライアントなどのアプリケーションが、クライアントデバイス１１にインストールされる。クライアントデバイス１１は、アプリケーションを使用することによってアプリケーション層データを生成し、アプリケーション層プロトコルに基づいて、サーバ１２とアプリケーション層データを交換して、以下の方法実施形態をトリガする。例示的なシナリオにおいて、メールボックスクライアントを稼働させる処理では、クライアントデバイス１１は、ＳＭＴＰに基づいてサーバ１２へメールを送信する。別の例示的なシナリオにおいて、ファイル転送クライアントを稼働させる処理では、クライアントデバイス１１は、ＦＴＰに基づいてサーバ１２へファイルを送信する。

【0069】

いくつかの実施形態において、システムアーキテクチャ１０は、多数のクライアントデバイス１１を含む。簡潔さのために、１つのクライアントデバイス１１が、図３における説明のための例として使用されている。

【0070】

（２）サーバ１２

【0071】

サーバ１２は、ＴＣＰセッションにおいてサービスを提供するデバイスである。例えば、サーバ１２は、メールサーバ１２であり、メールサーバ１２は、ＳＭＴＰに基づいて、クライアントのためのメール転送サービスを提供する。別の例として、サーバ１２は、ファイルサーバ１２であり、ファイルサーバ１２は、ＦＴＰに基づいて、クライアントのためのファイル転送サービスを提供する。別の例として、サーバ１２は、ウェブサイトサーバである。

【0072】

クライアントデバイス１１とサーバ１２との間のファイル転送は、双方向であってよく、すなわち、クライアントデバイス１１は、サーバ１２へファイルを送ってよく、サーバ１２は、クライアントデバイス１１へファイルを送ってよい。

【0073】

（３）保護デバイス１３

【0074】

保護デバイス１３は、クライアントデバイス１１とサーバ１２との間に配置される。保護デバイス１３は、ネットワーク上でクライアントデバイス１１およびサーバ１２に別々に接続される。保護デバイス１３は、ネットワーク内で送信されるパケットに対してセキュリティ検出を行うように構成される。セキュリティ検出は、ＩＰＳ検出、ＡＶ検出等を含むが、これらに限定されない。保護デバイス１３は、ファイアウォール、侵入検出システム（ｉｎｔｒｕｓｉｏｎ ｄｅｔｅｃｔｉｏｎ ｓｙｓｔｅｍ、ＩＤＳ）デバイス、またはＩＰＳデバイスを含むが、これらに限定されない。保護デバイス１３は、例えば、ネットワーク内でインラインモードで配置されるネットワーク検出デバイスである。

【0075】

保護デバイス１３によってサポートされる複数の検出モードは、検出モードセットを形成する。検出モードセットは、少なくとも１つの検出モードを含む。例えば、検出モードセットは、パケットフィルタリングモード、フローモード、プロキシモード等を含む。

【0076】

以下は、保護デバイス１３によってサポートされる検出モードのセットが、フローモードおよびプロキシモードを含む例を使用することによって、保護デバイス１３の内部論理機能アーキテクチャを説明する。

【0077】

図３に示されるように、保護デバイス１３は、上位層サービスモジュール１３０、フローモード処理モジュール１３１、プロキシモード処理モジュール１３２、およびＴＣＰ／ＩＰプロトコルスタックモジュール１３３を含む。

【0078】

（ａ）上位層サービスモジュール１３０

【0079】

上位層サービスモジュール１３０は、例えば、保護デバイス１３上でアプリケーションを使用することによって実装される。上位層サービスモジュール１３０は、アプリケーション層においてサービスを処理するように構成される。本出願のいくつかの実施形態において、上位層サービスモジュール１３０は、アプリケーション層データに基づいてプロトコル識別を行って、識別されたプロトコルタイプに基づいて、パケットを検出するために使用されるべき特定の検出モードを決定するように構成される。

【0080】

（ｂ）フローモード処理モジュール１３１

【0081】

フローモード処理モジュール１３１は、フローモードを使用して、ＴＣＰセッションにおいてパケットを処理するタスクの責任を負う。例えば、フローモード処理モジュール１３１は、フローモードを使用して、クライアントデバイス１１またはサーバ１２からデータパケットを受信し、受信されたデータパケットをバッファし、クライアントデバイス１１またはサーバ１２へデータパケットを転送し、クライアントデバイス１１またはサーバ１２から肯定応答パケットを受信し、クライアントデバイス１１またはサーバ１２へ肯定応答パケットを転送するように構成される。フローモード処理モジュール１３１の具体的な構成については、図８における関連する説明を参照されたい。

【0082】

（ｃ）プロキシモード処理モジュール１３２

【0083】

プロキシモード処理モジュール１３２は、プロキシモードを使用して、ＴＣＰセッションにおいてパケットを処理するタスクの責任を負う。いくつかの実施形態において、プロキシモード処理モジュール１３２およびＴＣＰ／ＩＰプロトコルスタックモジュール１３３は、別々に配設される。プロキシモード処理モジュール１３２およびＴＣＰ／ＩＰプロトコルスタックモジュール１３３が別々に配設される例は、図３における説明のために使用される。いくつかの他の実施形態において、プロキシモード処理モジュール１３２およびＴＣＰ／ＩＰプロトコルスタックモジュール１３３は、同じモジュール内に一体化される。

【0084】

（ｄ）ＴＣＰ／ＩＰプロトコルスタックモジュール１３３

【0085】

ＴＣＰ／ＩＰプロトコルスタックモジュール１３３は、ＴＣＰ／ＩＰに基づいてパケットを送信して、パケット送信信頼性を確実にするように構成される。ＴＣＰ／ＩＰプロトコルスタックモジュール１３３の具体的な構成については、図８または図９における関連する説明を参照されたい。いくつかの実施形態において、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３は、ソフトウェアを使用することによって実装される。いくつかの他の実施形態において、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３は、ハードウェアを使用することによって実装され、またはソフトウェアとハードウェアとの組み合わせを使用することによって実装される。例えば、保護デバイス１３は、アクセラレータを用いて構成される。アクセラレータは、ＴＣＰ／ＩＰプロトコルスタックに関連するステップを処理するための専用ハードウェアである。ＴＣＰ／ＩＰプロトコルスタックモジュール１３３は、アクセラレータを使用することによって実装されて、ＴＣＰ／ＩＰプロトコルスタックをアクセラレータにオフロードし、それによって、中央処理ユニット（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＣＰＵ）の負荷を低減する。

【0086】

ＴＣＰ／ＩＰプロトコルスタックモジュール１３３は、主に肯定応答返答および再送信機構を使用することによって送信信頼性を確実にする。具体的には、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３がデータパケットを受信した後に、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３は、データパケットのソース側へ肯定応答パケットを返す。ＴＣＰ／ＩＰプロトコルスタックモジュール１３３がデータパケットを送った後に、データパケットが再送信条件を満たす場合、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３は、データパケットの宛先側へデータパケットを再送する。

【0087】

いくつかの実施形態において、再送信条件は、データパケットについての肯定応答パケットが受信されないことを含む。例えば、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３がピア側へデータパケットを送った後に、データパケットに対応する肯定応答パケットが、予め設定された期間内に受信されない場合、再送信条件が満たされ、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３は、データパケットを自動的に再送信する。

【0088】

いくつかの他の実施形態において、再送信条件は、ピア側（クライアントデバイス１１またはサーバ１２）によって送られる肯定応答パケット内の選択的肯定応答（ｓｅｌｅｃｔｉｖｅ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ、ＳＡＣＫ）オプションにおける情報に基づいて、パケット損失がデータパケット内で発生したと決定することを含む。この再送信条件は、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３がＳＡＣＫオプションをサポートする場合に適用可能である。具体的には、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３がピア側へデータパケットを送った後に、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３は、ピア側から肯定応答パケットを受信する。ＴＣＰ／ＩＰプロトコルスタックモジュール１３３が、肯定応答パケット内のＳＡＣＫオプションにおける範囲および記録された最大シーケンス番号（ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ、Ｓｅｑ）に基づいて、データパケットは失われたと決定した場合、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３は、データパケットを再送信する。例えば、保護デバイス１３は、そのＳｅｑ番号がそれぞれ１、２、３および４である、４つのパケットを送る。そのＳｅｑ番号が１であるパケットは、ネットワーク上の理由で失われ、そのＳｅｑ番号が２、３、および４である３つのパケットは、ピア側へ成功裡に送信される。ピア側が、そのＳｅｑ番号が２、３、および４である３つのパケットを受信した場合、ピア側は、肯定応答パケット内のＳＡＣＫオプションを使用することによって、そのＳｅｑ番号が２、３、および４である３つのパケットが受信され、そのＳｅｑ番号が１であるパケットのみが受信されないことを保護デバイス１３に通知する。この場合において、そのＳｅｑ番号が１であるパケットは、再送信条件を満たし、保護デバイス１３は、そのＳｅｑ番号が１であるパケットを再送信する。

【0089】

図４は、本出願の一実施形態による保護デバイスの構造の概略図である。任意選択で、図４に示される構造を有する保護デバイスは、図３、図８、または図９における保護デバイス１３である。

【0090】

保護デバイス２００は、少なくとも１つのプロセッサ２０１、通信バス２０２、メモリ２０３、および少なくとも１つの通信インターフェース２０４を含む。

【0091】

プロセッサ２０１は、例えば、本出願の解決策を実装するように構成された、汎用中央処理ユニット（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＣＰＵ）、ネットワークプロセッサ（ｎｅｔｗｏｒｋ ｐｒｏｃｅｓｓｏｒ、ＮＰ）、グラフィック処理ユニット（ｇｒａｐｈｉｃｓ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＧＰＵ）、ニューラルネットワーク処理ユニット（ｎｅｕｒａｌ－ｎｅｔｗｏｒｋ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔｓ、ＮＰＵ）、データ処理ユニット（ｄａｔａ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＤＰＵ）、マイクロプロセッサ、または、１つもしくは複数の集積回路である。例えば、プロセッサ２０１は、特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ、ＡＳＩＣ）、プログラマブルロジックデバイス（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅ、ＰＬＤ）、または、これらの組み合わせを含む。ＰＬＤは、例えば、複合プログラマブルロジックデバイス（ｃｏｍｐｌｅｘ ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅ、ＣＰＬＤ）、フィールドプログラマブルゲートアレイ（ｆｉｅｌｄ－ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ、ＦＰＧＡ）、ジェネリックアレイロジック（ｇｅｎｅｒｉｃ ａｒｒａｙ ｌｏｇｉｃ、ＧＡＬ）、または、これらの任意の組合せである。

【0092】

いくつかの実施形態において、プロセッサ２０１は、図５に示される方法５００におけるＳ５２０およびＳ５３０を行う際に保護デバイス２００をサポートするように構成される。いくつかの実施形態において、プロセッサ２０１は、図７に示される方法７００におけるＳ７２０およびＳ７５０を行う際に保護デバイス２００をサポートするようにさらに構成される。

【0093】

通信バス２０２は、前述の構成要素間で情報を送信するように構成される。通信バス２０２は、アドレスバス、データバス、制御バス等に分類され得る。表現の簡単さのために、１つの太線のみが、図４における表現のために使用されているが、これは、１つのバスのみまたは１つのタイプのバスのみがあることを意味しない。

【0094】

メモリ２０３は、例えば、読み出し専用メモリ（ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ、ＲＯＭ）、もしくは静的な情報および命令を記憶することができる別のタイプの静的記憶デバイス、ランダムアクセスメモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ、ＲＡＭ）、もしくは情報および命令を記憶することができる別のタイプの動的記憶デバイス、電気的消去可能プログラマブル読み出し専用メモリ（ｅｌｅｃｔｒｉｃａｌｌｙ ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ、ＥＥＰＲＯＭ）、コンパクトディスク読み出し専用メモリ（ｃｏｍｐａｃｔ ｄｉｓｃ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ、ＣＤ－ＲＯＭ）もしくは別のコンパクトディスクストレージ、光ディスクストレージ（コンパクトディスク、レーザディスク、光ディスク、デジタル多用途ディスク、ブルーレイディスク等を含む）、磁気ディスクストレージ媒体もしくは別の磁気ストレージデバイス、または、期待されるプログラムコードを命令もしくはデータ構造の形式で搬送もしくは記憶するために使用されることが可能であり、かつ、コンピュータによってアクセスされることが可能である任意の他の媒体であるが、これらに限定されない。例えば、メモリ２０３は、独立して存在し、通信バス２０２を使用することによってプロセッサ２０１へ接続される。メモリ２０３は、代替として、プロセッサ２０１に一体化されてよい。

【0095】

いくつかの実施形態において、メモリ２０３は、受信されたパケットをバッファする際、および送られたパケットをバッファする際に、保護デバイス２００をサポートするように構成される。例えば、図８または図９を参照すると、メモリ２０３は、受信されたパケットキュー１３１１１、受信されたパケットキュー１３１２１、送られたパケットキュー１３３１２、または送られたパケットキュー１３３２２のうちの少なくとも１つを含む。

【0096】

通信インターフェース２０４は、送受信機などの任意の装置を使用することによって、別のデバイスまたは通信ネットワークと通信するように構成される。例えば、図３に示される配置シナリオを参照すると、通信インターフェース２０４は、クライアントデバイス１１またはサーバ１２と通信するように構成される。通信インターフェース２０４は、有線通信インターフェースを含み、または無線通信インターフェースを含んでよい。有線通信インターフェースは、例えば、イーサネットインターフェースであってよい。イーサネットインターフェースは、光学インターフェース、電気インターフェース、または、これらの組み合わせであってよい。無線通信インターフェースは、無線ローカルエリアネットワーク（ｗｉｒｅｌｅｓｓ ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ、ＷＬＡＮ）インターフェース、セルラーネットワーク通信インターフェース、または、これらの組み合わせであってよい。

【0097】

いくつかの実施形態において、通信インターフェース２０４は、図５に示される方法５００におけるＳ５１０を行う際に保護デバイス２００をサポートするように構成される。いくつかの実施形態において、通信インターフェース２０４は、図７に示される方法７００におけるＳ７３０およびＳ７８０を行う際に保護デバイス２００をサポートするようにさらに構成される。

【0098】

特定の実装期間中に、一実施形態において、プロセッサ２０１は、１つまたは複数のＣＰＵ、例えば、図４に示されるＣＰＵ０およびＣＰＵ１を含み得る。

【0099】

特定の実装期間中に、一実施形態において、保護デバイス２００は、複数のプロセッサ、例えば、図４に示されるプロセッサ２０１およびプロセッサ２０５を含み得る。プロセッサの各々は、シングルコアプロセッサ（ｓｉｎｇｌｅ－ＣＰＵ）またはマルチコアプロセッサ（ｍｕｌｔｉ－ＣＰＵ）であり得る。本明細書におけるプロセッサは、データ（例えば、コンピュータプログラム命令）を処理するように構成された、１つまたは複数のデバイス、回路、および／または処理コアであり得る。

【0100】

特定の実装期間中に、一実施形態において、保護デバイス２００は、出力デバイスおよび入力デバイスをさらに含んでよい。出力デバイスは、プロセッサ２０１と通信し、複数の手法で情報を表示し得る。例えば、出力デバイスは、液晶ディスプレイ（ｌｉｑｕｉｄ ｃｒｙｓｔａｌ ｄｉｓｐｌａｙ、ＬＣＤ）、発光ダイオード（ｌｉｇｈｔ－ｅｍｉｔｔｉｎｇ ｄｉｏｄｅ、ＬＥＤ）表示デバイス、ブラウン管（ｃａｔｈｏｄｅ ｒａｙ ｔｕｂｅ、ＣＲＴ）表示デバイス、またはプロジェクター（ｐｒｏｊｅｃｔｏｒ）であってよい。入力デバイスは、プロセッサ２０１と通信し、複数の手法でユーザから入力を受信し得る。例えば、入力デバイスは、マウス、キーボード、タッチスクリーンデバイス、または感知デバイスであってよい。

【0101】

いくつかの実施形態において、メモリ２０３は、本出願の解決策を行うためのプログラムコード２１０を記憶するように構成され、プロセッサ２０１は、メモリ２０３内に記憶されたプログラムコード２１０を実行し得る。具体的には、保護デバイス２００は、プロセッサ２０１とメモリ２０３内のプログラムコード２１０とを使用することによって、図５に示される方法５００または図７に示される方法７００を実装し得る。

【0102】

本出願のこの実施形態における保護デバイス２００は、図５に示される方法５００または図７に示される方法７００における保護デバイスに対応し得る。また、保護デバイス２００内のプロセッサ２０１、通信インターフェース２０４等は、図５に示される方法５００または図７に示される方法７００における保護デバイスの機能および／または様々な実装されたステップならびに方法を実装し得る。簡潔さのために、詳細は、ここでは再度説明されない。

【0103】

図５を参照して、以下は、本出願の一実施形態において提供されるネットワークセキュリティ保護方法を説明する。

【0104】

図５は、本出願の一実施形態によるネットワークセキュリティ保護方法５００のフローチャートである。

【0105】

任意選択で、方法５００におけるクライアントデバイス、サーバ、および保護デバイスのネットワーク配置シナリオが、図３に示される。方法５００におけるクライアントデバイスは、図３におけるクライアントデバイス１１であり、方法５００におけるサーバは、システムアーキテクチャ１０におけるサーバ１２であり、方法５００における保護デバイスは、図３における保護デバイス１３である。

【0106】

任意選択で、方法５００における保護デバイスは、図４に示される構造を有する。

【0107】

方法５００は、ステップＳ５１０からステップＳ５３０を含む。ステップＳ５１０からステップＳ５３０において、保護デバイスがモード切り替えを一回行う処理は、保護デバイスがＴＣＰセッションのために検出モードをどのように切り替えるかを説明するための例として使用される。保護デバイスは、実際の状況に応じて、モード切り替えを複数回行ってよく、各モード切り替え処理は、ステップＳ５１０からステップＳ５３０における処理と同様である。

【0108】

ステップＳ５１０：保護デバイスは、第１のモードを使用して、ＴＣＰセッションにおけるデータパケットに対してセキュリティ検出を行う処理において、ＴＣＰセッションにおける第１のデータパケットを取得する。

【0109】

この実施形態において、異なる検出モードを区別するために、「第１のモード」および「第２のモード」が、異なる検出モードを説明するために使用される。異なるデータパケットを区別するために、「第１のデータパケット」および「第２のデータパケット」が、異なるデータパケットを説明するために使用される。

【0110】

第１のモードは、保護デバイスによってサポートされる検出モードのセット内のモードである。例えば、第１のモードは、フローモード、プロキシモード、またはパケットフィルタリングモードである。

【0111】

第１のデータパケットは、第１のモードを使用して、保護デバイスによって受信され、バッファされたパケットである。第１のデータパケットは、クライアントデバイスとサーバとの間で交換されたコンテンツを含む。いくつかの実施形態において、第１のデータパケットのソースデバイスは、クライアントデバイスであり、第１のデータパケットの宛先デバイスは、サーバである。例えば、第１のデータパケットは、サーバからのデータパケットに基づいてクライアントデバイスによって生成されるパケットであり、第１のデータパケットは、クライアントデバイスがサーバへフィードバックする必要のある応答コンテンツを含む。いくつかの他の実施形態において、第１のデータパケットのソースデバイスは、サーバであり、第１のデータパケットの宛先デバイスは、クライアントデバイスである。例えば、第１のデータパケットは、クライアントデバイスからのデータパケットに基づいてサーバによって生成されるパケットであり、第１のデータパケットは、サーバがクライアントデバイスへフィードバックする必要のある応答コンテンツを含む。

【0112】

ステップＳ５２０：保護デバイスは、第１のデータパケットのアプリケーション層データに基づいて、第２のモードに切り換えることを決定する。

【0113】

第２のモードは、検出モードのセット内の第１のモード以外のモードである。例えば、第１のモードはフローモードであり、第２のモードはプロキシモードであり、保護デバイスは、方法５００を行うことによって、フローモードからプロキシモードへ切り替える。別の例として、第１のモードはプロキシモードであり、第２のモードはフローモードであり、保護デバイスは、方法５００を行うことによって、プロキシモードからフローモードに切り替える。別の例として、第１のモードはパケットフィルタリングモードであり、第２のモードはプロキシモードであり、保護デバイスは、方法５００を行うことによって、パケットフィルタリングモードからプロキシモードに切り替える。別の例として、第１のモードはプロキシモードであり、第２のモードはパケットフィルタリングモードであり、保護デバイスは、方法５００を行うことによって、プロキシモードからパケットフィルタリングモードに切り替える。

【0114】

ステップＳ５３０：保護デバイスは、第２のモードに切り替え、第２のモードを使用して、ＴＣＰセッションにおける後続のパケットに対してセキュリティ検出を行う。

【0115】

いくつかの実施形態において、ステップＳ５１０からステップＳ５３０は、１つのＴＣＰセッションにおいて複数回行われる。具体的には、保護デバイスは、ステップＳ５１０からステップＳ５３０を複数回行って、１つのＴＣＰセッションにおいて検出モードを複数回切り替える。例えば、ＴＣＰセッションが確立された後に、保護デバイスは、まず、フローモードを使用して、ＴＣＰセッションにおけるデータパケットを検出する。次いで、保護デバイスは、ステップＳ５１０からステップＳ５３０を行って、フローモードからプロキシモードに切り替え、プロキシモードを使用して、ＴＣＰセッションにおける後続のデータパケットを検出する。次いで、保護デバイスは、ステップＳ５１０からステップＳ５３０を行って、プロキシモードからフローモードに再び切り替え、ＴＣＰセッションが終了するまで、フローモードを使用して、ＴＣＰセッションにおける後続のデータパケットを検出する。

【0116】

上記に提供される方法において、保護デバイスは、セッションにおいてクライアントデバイスとサーバとの間で交換されるデータパケットに基づいて、異なる検出モード間で適応的に切り替える。これは、要件に基づいてモード選択を行うこと助け、フローモードのみが使用される場合に脅威が見逃される場合を回避し、プロキシモードのみが使用される場合に大量の不必要なリソースが占有される場合を回避する。したがって、保護効果および性能が改善される。

【0117】

ステップＳ５２０において、保護デバイスが特定の検出モードに切り替えることをどのように決定するかには、複数の実装がある。以下は、説明のための例として、実装１から実装３を使用する。

【0118】

実装１：保護デバイスは、アプリケーション層プロトコルタイプに基づいて、切り替えられるべき検出モードを決定する。

【0119】

アプリケーション層プロトコルは、クライアントデバイス上のアプリケーションおよびサーバ上のアプリケーションによって使用されて、パケットを互いに送信するためのプロトコルである。多くのタイプのアプリケーション層プロトコルがある。例えば、アプリケーション層プロトコルは、電子メール転送プロトコルである。例えば、アプリケーション層プロトコルは、ＳＭＴＰ、ポストオフィスプロトコル３（ｐｏｓｔ ｏｆｆｉｃｅ ｐｒｏｔｏｃｏｌ ３、ＰＯＰ３）、またはインターネットメッセージアクセスプロトコル４（ｉｎｔｅｒｎｅｔ ｍｅｓｓａｇｅ ａｃｃｅｓｓ ｐｒｏｔｏｃｏｌ ４、ＩＭＡＰ４）である。別の例として、アプリケーション層プロトコルは、ファイル転送プロトコルである。例えば、アプリケーション層プロトコルは、ＦＴＰである。もちろん、アプリケーション層プロトコルは、任意選択で、ＴＣＰ／ＩＰプロトコルスイートに所属する別のプロトコルであり、アプリケーション層プロトコルの特定のタイプは、この実施形態において限定されない。

【0120】

いくつかの実施形態において、実装１において、第１のモードはフローモードであり、第２のモードはプロキシモードである。言いかえれば、実装１は、フローモードからプロキシモードに切り替えるシナリオに対して適用される。例えば、ＴＣＰセッションがクライアントデバイスとサーバとの間に確立された後に、保護デバイスは、以下のステップＳ５２０１からステップＳ５２０３を行う。

【0121】

ステップＳ５２０１：保護デバイスは、アプリケーション層データに基づいて、第１のデータパケットのアプリケーション層プロトコルタイプを識別する。

【0122】

いくつかの実施形態において、保護デバイスは、アプリケーション層データ、およびアプリケーション層プロトコルに対応するキーワードに基づいて、アプリケーション層プロトコルタイプを識別する。

【0123】

例えば、アプリケーション層プロトコルに対応するキーワードは、アプリケーション層プロトコルの仕様に従ってデータパケットに含まれる必要のあるキーワードである。例えば、アプリケーション層プロトコルに対応するキーワードは、アプリケーション層プロトコルに関連する標準またはドラフトを使用することによって特定される。いくつかの実施形態において、アプリケーション層プロトコルに対応するキーワードは、アプリケーション層プロトコルにおいてログインコマンド内で搬送されるキーワードである。ログインコマンドは、サーバにログインすることを要求するために使用される。２つのプロトコル、すなわち、ＳＭＴＰおよびＦＴＰを参照して、以下は、キーワードと、キーワードを使用することによってアプリケーション層プロトコルタイプを識別する手法とを説明するための例を使用する。

【0124】

例えば、アプリケーション層プロトコルはＳＭＴＰであり、ＳＭＴＰにおけるログインコマンドは、ＨＥＬＯ（ｈｅｌｌｏ、ｈｅｌｌｏ）コマンドを含む。ＳＭＴＰに対応するキーワードは、例えば、ＨＥＬＯコマンド内で搬送されるキーワードである。ＨＥＬＯコマンド内で搬送されるキーワードは、ＨＥＬＯである。ＨＥＬＯコマンドのフォーマットは、「ＨＥＬＯ ｘｘｘｘ」として簡単に表現され得る。「ＨＥＬＯ ｘｘｘｘ」における「ｘｘｘｘ」は、ＨＥＬＯコマンドに含まれるパラメータであり、パラメータは、通常、ＳＭＴＰクライアントのドメインネームを意味する。この場合において、保護デバイスによって受信されるアプリケーション層データがＨＥＬＯを含む場合、保護デバイスは、アプリケーション層プロトコルのタイプがＳＭＴＰであると識別し得る。もちろん、ＨＥＬＯコマンドは、ＳＭＴＰにおけるログインコマンドの例にすぎず、ＨＥＬＯは、ＳＭＴＰに対応するキーワードの例にすぎない。ＨＥＬＯコマンドは、ＳＭＴＰにおける別のログインコマンド、例えば、ＥＨＬＯ（ｅｘｔｅｎｄｅｄ ｈｅｌｌｏ）コマンドに置換され得る。ＳＭＴＰに対応するキーワードは、別のログインコマンドにおけるキーワードに置換され得る。ＳＭＴＰを識別するために使用されるキーワードは、この実施形態において限定されない。

【0125】

別の例として、アプリケーション層プロトコルは、ＦＴＰであり、ＦＴＰにおけるログインコマンドは、ＵＳＥＲコマンドを含む。ＴＰに対応するキーワードは、例えば、ＵＳＥＲコマンド内で搬送されるキーワードである。具体的には、ＵＳＥＲコマンド内で搬送されるキーワードは、ＵＳＥＲである。ＵＳＥＲコマンドは、「ＵＳＥＲ ｘｘｘ」として簡単に表現され得る。「ＵＳＥＲ ｘｘｘ」における「ｘｘｘ」は、ＵＳＥＲコマンドに含まれるパラメータであり、パラメータは、通常、ユーザ名を意味する。この場合において、保護デバイスによって受信されたアプリケーション層データが、ＵＳＥＲを含む場合、保護デバイスは、アプリケーション層プロトコルのタイプがＦＴＰであると識別し得る。もちろん、ＵＳＥＲコマンドは、ＦＴＰにおけるログインコマンドの例にすぎず、ＵＳＥＲは、ＦＴＰに対応するキーワードの例にすぎない。ＵＳＥＲコマンドは、ＦＴＰにおける別のログインコマンド、例えば、ｐａｓｓコマンドまたはｐａｖｓコマンドに置換され得る。ＦＴＰに対応するキーワードは、別のログインコマンドにおけるキーワード、例えば、ｐａｓｓまたはｐａｖｓに置換され得る。ＦＴＰを識別するために使用されるキーワードは、この実施形態において限定されない。

【0126】

ステップＳ５２０２：保護デバイスは、アプリケーション層プロトコルタイプと検出モードとの間の対応に基づいて、第１のデータパケットのアプリケーション層プロトコルタイプがプロキシモードに対応すると決定する。

【0127】

例えば、アプリケーション層プロトコルタイプと検出モードとの間の対応は、ＳＭＴＰとプロキシモードとの間の対応を含む。保護デバイスが、アプリケーション層プロトコルタイプはＳＭＴＰであると識別した後に、保護デバイスは、ＳＭＴＰとプロキシモードとの間の対応に基づいて、第１のデータパケットのアプリケーション層プロトコルタイプはプロキシモードに対応すると決定する。この場合において、保護デバイスは、プロキシモードに切り替え、プロキシモードを使用して、ＳＭＴＰに基づいて送信されるメールに対してアンチウイルス検出を行う。

【0128】

別の例として、アプリケーション層プロトコルタイプと検出モードとの間の対応は、ＦＴＰとフローモードとの間の対応を含む。保護デバイスが、アプリケーション層プロトコルタイプはＦＴＰであると識別した後に、保護デバイスは、ＦＴＰとフローモードとの間の対応に基づいて、第１のデータパケットのアプリケーション層プロトコルタイプはフローモードに対応すると決定する。この場合において、保護デバイスは、フローモードを使用して、ＴＣＰセッションにおける後続のパケットに対してセキュリティ検出を行い続ける。

【0129】

ステップＳ５２０３：保護デバイスは、切り替えられるべき第２のモードが、第１のデータパケットのアプリケーション層プロトコルタイプに対応するプロキシモードであると決定する。

【0130】

以下は、２つの例、すなわち、例１および例２を使用することによって、保護デバイスが、実装１においてステップＳ５２０１におけるプロトコルに対応するキーワードを使用することによって、どのようにプロトコルタイプを識別するかを説明する。

【0131】

例１：クライアントは、ＳＭＴＰに基づいて、サーバと相互作用する。

【0132】

ＴＣＰセッションがクライアントデバイスとサーバとの間に確立された後に、サーバは、クライアントデバイスへウェルカムメッセージを送る。保護デバイスがサーバからウェルカムメッセージを受信した後に、保護デバイスは、クライアントデバイスへウェルカムメッセージを転送する。ウェルカムメッセージを受信した後に、クライアントデバイスは、「ＨＥＬＯ ｘｘｘｘ」を含むアプリケーション層データを送る。アプリケーション層データを受信した後に、保護デバイスは、アプリケーション層データが「ＨＥＬＯ」を含むことを見出し、次いで、ＳＭＴＰが現在のＴＣＰセッションにおいて稼働されることを識別する。

【0133】

例えば、クライアントによって送られるアプリケーション層データは、以下の通りである。
２２０ ｄｓｈｎａｙｄｅｒ．ｆｓｃｉｎｔｅｒｎｅｔ．ｃｏｍ ＥＳＭＴＰ ｐｏｓｔｆｉｘ
ＨＥＬＯ ｌｏｃａｌｈｏｓｔ
ＭＡＩＬ ＦＲＯＭ： ＜ｔｅｓｔ＞
ＲＣＰＴ ＴＯ： ＜[e-mail]＞
ｄａｔａ
Ｆｒｏｍ：“ｔｅｓｔ” ＜ｔｅｓｔ＞
Ｔｏ： ＜[e-mail]＞
Ｓｕｂｊｅｃｔ：ｏｐｅｎ ｏｂｊｅｃｔ ｔａｇ－ｅｘｐｌｏｉｔ．ｈｔｍｌ
Ｃｏｎｔｅｎｔ－Ｔｙｐｅ：ｔｅｘｔ／ｈｔｍｌ；ｃｈａｒｓｅｔ＝“ｉｓｏ－８８５９－１

【0134】

ここでは、「２２０ ｄｓｈｎａｙｄｅｒ．ｆｓｃｉｎｔｅｒｎｅｔ．ｃｏｍ ＥＳＭＴＰ ｐｏｓｔｆｉｘ」は、ウェルカムメッセージであり、「ＨＥＬＯ ｌｏｃａｌｈｏｓｔ」は、ＨＥＬＯコマンドである。

【0135】

例２：クライアントは、ＦＴＰに基づいて、サーバと相互作用する。

【0136】

ＴＣＰセッションがクライアントデバイスとサーバとの間に確立された後に、サーバは、クライアントデバイスへウェルカムメッセージを送る。保護デバイスがサーバからウェルカムメッセージを受信した後に、保護デバイスは、クライアントデバイスへウェルカムメッセージを転送する。ウェルカムメッセージを受信した後に、クライアントデバイスは、「ＵＳＥＲ ｘｘｘ」を含むアプリケーション層データを送る。アプリケーション層データを受信した後に、保護デバイスは、アプリケーション層データが「ＵＳＥＲ」を含むことを見出し、次いで、ＦＴＰが現在のＴＣＰセッションにおいて稼働されることを識別する。

【0137】

例えば、クライアントによって送られるアプリケーション層データは、以下の通りである。
２２０ ｒｅｄｈａｔ＿５２．ｔｅｓｔ ＦＴＰ ｓｅｒｖｅｒ（Ｖｅｒｓｉｏｎ ｗｕ－２．４．２－ａｃａｄｅｍ［ＢＥＴＡ－１８］（１）Ｍｏｎ Ａｕｇ ３ １９：１７：２０ ＥＤＴ １９９８）ｒｅａｄｙ．
ＵＳＥＲ ａｎｏｎｙｍｏｕｓ
３３１ Ｇｕｅｓｔ ｌｏｇｉｎ ｏｋ，ｓｅｎｄ ｙｏｕｒ ｃｏｍｐｌｅｔｅ ｅ－ｍａｉｌ ａｄｄｒｅｓｓ ａｓ ｐａｓｓｗｏｒｄ．
ＰＡＳＳ [e-mail]
２３０ Ｇｕｅｓｔ ｌｏｇｉｎ ｏｋ，ａｃｃｅｓｓ ｒｅｓｔｒｉｃｔｉｏｎｓ ａｐｐｌｙ．
ＭＫＤ ／ｉｎｃｏｍｉｎｇ
５５０ ／ｉｎｃｏｍｉｎｇ：Ｐｅｒｍｉｓｓｉｏｎ ｄｅｎｉｅｄ．
ＣＮＤ ／ｉｎｃｏｍｉｎｇ
２５０ ＣＷＤ ｃｏｍｍａｎｄ ｓｕｃｃｅｓｓｆｕｌ．

【0138】

ここでは、「２２０ ｒｅｄｈａｔ＿５２．ｔｅｓｔ ＦＴＰ ｓｅｒｖｅｒ（Ｖｅｒｓｉｏｎ ｗｕ－２．４．２－ａｃａｄｅｍ［ＢＥＴＡ－１８］（１）Ｍｏｎ Ａｕｇ ３ １９：１７：２０ ＥＤＴ １９９８）ｒｅａｄｙ」は、ウェルカムメッセージであり、「ＵＳＥＲ ａｎｏｎｙｍｏｕｓ」は、ＵＳＥＲコマンドである。ＵＳＥＲコマンドは、ＦＴＰサーバへの匿名ログインを示す。

【0139】

前述の例１および例２においては、２つのアプリケーション層プロトコル、すなわち、ＳＭＴＰおよびＦＴＰが、説明のための例として使用されている。実装１の適用範囲は、これらのプロトコルに限定されない。実装１は、プロトコルタイプおよびアプリケーション層データに基づいており、かつ、検出モードが変更されることを必要とするかどうかが、いくつかのパケットが交換された後にのみ決定されることが可能である、様々なトラフィック処理シナリオに対して適用されることが可能である。

【0140】

保護デバイスがアプリケーション層プロトコルタイプと検出モードとの間の対応をどのように取得するかには、複数の実装がある。いくつかの実施形態において、保護デバイスは、ユーザの設定動作に基づいて、アプリケーション層プロトコルタイプと検出モードとの間の対応を決定する。例えば、ユーザは、ＳＭＴＰに基づいて送信されるトラフィックに対してＡＶ検出を設定する。ＡＶ検出のためにプロキシモードが通常は必要とされるので、保護デバイスは、ＳＭＴＰがプロキシモードに対応すると決定する。

【0141】

いくつかの実施形態において、保護デバイスがトラフィックを検出する処理において、ユーザは、設定を修正し、その結果、アプリケーション層プロトコルタイプと検出モードとの間の対応が更新される。このシナリオにおいて、保護デバイスは、アプリケーション層プロトコルタイプと検出モードとの間の更新された対応に基づいて、どの検出モードに切り替えられるべきかを決定し、その結果、ユーザ設定がリアルタイムで有効になる。例えば、ユーザは、トラフィックを検出するために元はフローモードを使用することから、トラフィックを検出するためにプロキシモードを使用することへ変更するように設定を修正する。設定修正を検出した後に、保護デバイスは、トラフィックのための検出モードをプロキシモードに切り替える。

【0142】

実装１において説明される解決策を行うことによって、保護デバイスは、アプリケーション層検出の要件に動的に基づいて、同じＴＣＰセッションの相互作用処理における検出モードを適応的に選択することができる。これは、オンデマンドの動的な切り替えを実装し、セキュリティとデバイスリソース占有とのバランスを取る。

【0143】

実装２：保護デバイスは、ＡＶ検出結果に基づいて、切り替えられるべき検出モードを決定する。

【0144】

いくつかの実施形態において、実装２において、第１のモードはプロキシモードであり、第２のモードはフローモードである。言いかえれば、実装２は、プロキシモードからフローモードに切り替えるシナリオに対して適用される。

【0145】

具体的には、保護デバイスは、第１のデータパケットのアプリケーション層データに対してＡＶ検出を行って、ＡＶ検出結果を取得する。ＡＶ検出結果が、ウィルスはないというものである場合、保護デバイスは、切り替えられるべき第２のモードがフローモードであると決定する。例えば、クライアントがＳＭＴＰに基づいてサーバと相互作用するシナリオにおいて、保護デバイスがクライアントとサーバとの間のメールを転送する場合、保護デバイスは、プロキシモードを使用して、メールのコンテンツ（メールアタッチメントを含む）に対してＡＶ検出を行う。メールのＡＶ検出結果が、メールはウィルスを含有しない、またはメールは安全であるというものである場合、保護デバイスは、プロキシモードからフローモードに切り替える。

【0146】

実装３：保護デバイスは、クライアントおよびサーバが暗号化された通信を開始しようとしていることを識別することによって、切り替えられるべき検出モードを決定する。

【0147】

いくつかの実施形態において、実装３において、第１のモードはプロキシモードであり、第２のモードはフローモードである。言いかえれば、実装３は、プロキシモードからフローモードに切り替えるシナリオに対して適用される。具体的には、第１のデータパケットのアプリケーション層データが、クライアントデバイスおよびサーバがＴＣＰセッションにおいて暗号化された通信を行おうとしていることを示す場合、保護デバイスは、切り替えられるべき第２のモードがフローモードであると決定する。いくつかの実施形態において、保護デバイスは、暗号化された通信コマンドのキーワードを予め記憶し、第１のデータパケットのアプリケーション層データが、暗号化された通信コマンドのキーワードを含む場合、クライアントデバイスおよびサーバが暗号化された通信を行おうとしていると決定する。例えば、暗号化された通信コマンドは、ｓｔａｒｔｔｌｓコマンドである。

【0148】

実装１から実装３は、互いに組み合わされ得る。実装１と実装２との組み合わせが、例として使用される。例示的な適用シナリオにおいて、保護デバイスは、前述の方法５００を使用することによって、ＳＭＴＰベースのメールに対してセキュリティ検出を行い、サーバは、具体的にはメールサーバであり、ＳＭＴＰクライアントが、クライアントデバイスにインストールされる。セッションがＳＭＴＰクライアントとメールサーバとの間に確立された後に、保護デバイスは、まず、フローモードを使用して、セッション内のデータパケットを検出する。次いで、セッションにおけるＳＭＴＰクライアントとメールサーバとの間の相互作用期間中に、保護デバイスが、ＳＭＴＰクライアントとメールサーバとの間で交換されるデータパケットを使用することによって、セッションに対応するアプリケーション層プロトコルはＳＭＴＰであることを見出した場合、保護デバイスは、フローモードからプロキシモードに切り替える。保護デバイスは、プロキシモードを使用して、セッションにおいてＳＭＴＰクライアントとメールサーバとの間で交換される後続のデータパケットを検出する。具体的には、保護デバイスは、ＳＭＴＰクライアントによって送られる全てのメールデータに対してＡＣＫを行い、その結果、ＳＭＴＰクライアントは、保護デバイスへメール全体（アタッチメントを含む）を完全に送る。保護デバイスは、メールデータに対してアンチウイルス検出を行う。保護デバイスが、メールデータはウィルスを含有しないと決定した場合、ＳＭＴＰクライアントの代わりに保護デバイスが、保護デバイスのＴＣＰ／ＩＰプロトコルスタックを通じて、サーバへメールデータを送る。保護デバイスが、プロキシモードを使用して、１回または複数回検出を行うことによって、ＳＭＴＰクライアントとサーバとの間で送信されるメールは安全であると決定した場合、保護デバイスは、プロキシモードからフローモードに切り替えて、後続の処理手順を加速させる。

【0149】

以下は、三方向ハンドシェイクフェーズにおける保護デバイスの処理手順を説明する。

【0150】

理解を簡単にするために、以下は、まず、ＴＣＰにおける三方向ハンドシェイク原理を説明する。

【0151】

図６は、クライアントとサーバとの間の三方向ハンドシェイクのフローチャートである。図６に示される手順において、クライアントは、ＴＣＰセッションのイニシエータであり、サーバは、ＴＣＰセッションのレシーバである。クライアントとサーバとの間の相互作用は、主に３つのフェーズ、すなわち、セッション確立、データ送信、およびセッション終了を含む。図６は、データ送信の具体的な手順を示していない。

【0152】

セッションは、三方向ハンドシェイク（ｔｈｒｅｅ－ｗａｙ ｈａｎｄｓｈａｋｅ）を通じて確立される。クライアントおよびサーバが、ＴＣＰを使用することによってデータを送信する必要がある場合、クライアントは、ＳＹＮパケットを使用してＴＣＰセッションを開始して、ネゴシエーションを確立する。これは、三方向ハンドシェイクと称される。三方向ハンドシェイクは、３つのパケット、すなわち、ＳＹＮパケット、同期シーケンス番号肯定応答（ｓｙｎｃｈｒｏｎｉｚｅ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒｓ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ、ＳＹＮ ＡＣＫ）パケット、およびＡＣＫパケットの相互作用処理に関連する。具体的には、三方向ハンドシェイクは、以下のステップ１からステップ３を含む。

【0153】

ステップ１：クライアントは、サーバへＳＹＮパケットを送る。ＳＹＮパケットは、ＴＣＰセッションを確立するために必要とされるオプションを含む。例えば、オプションは、最大セグメントサイズ（ｍａｘｉｍｕｍ ｓｅｇｍｅｎｔ ｓｉｚｅ、ＭＳＳ）、ＳＡＣＫ、データバッファサイズ（ＴＣＰウィンドウ）等である。

【0154】

ＳＹＮパケット内のＳｅｑ番号は、クライアントの最初のシーケンス番号（ｉｎｉｔｉａｌ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ、ＩＳＮ）である。ＳＹＮパケット内のＩＳＮは、クライアントによってランダムに生成される値である。ＳＹＮパケット内のＩＳＮは、ＩＳＮ（ｃ）として簡単に表現され得る。ＩＳＮ（ｃ）における「ｃ」は、クライアント（ｃｌｉｅｎｔ）を意味する。

【0155】

ステップ２：サーバは、ＳＹＮパケットを受信し、サーバは、クライアントへＳＹＮ ＡＣＫパケットを送る。ＳＹＮ ＡＣＫパケットは、サーバによってサポートされるオプションを含む。サーバは、ＳＹＮ ＡＣＫパケットを送って、クライアントからのＳＹＮパケットが受信されたことをクライアントに通知し、サポートされるオプションをクライアントに通知する。

【0156】

ＳＹＮ ＡＣＫパケット内のＳｅｑ番号は、ＩＳＮである。ＳＹＮ ＡＣＫパケット内のＩＳＮは、サーバによってランダムに生成される値である。ＳＹＮ ＡＣＫパケット内のＩＳＮは、ＩＳＮ（ｓ）として簡単に表現され得る。ＩＳＮ（ｓ）における「ｓ」は、サーバ（ｓｅｒｖｅｒ）を意味する。ＳＹＮ ＡＣＫパケット内のＡＣＫ番号は、ＩＳＮ（ｃ）＋１である。

【0157】

ステップ３：クライアントは、ＳＹＮ ＡＣＫパケットを受信し、クライアントは、サーバへＡＣＫパケットを送って、三方向ハンドシェイクを完了する。ＡＣＫパケット内のＳｅｑ番号は、ＩＳＮ（ｃ）＋１である。ＡＣＫパケット内のＡＣＫ番号は、ＩＳＮ（ｓ）＋１である。

【0158】

クライアントとサーバとの間のハンドシェイクが完了した後に、クライアントおよびサーバが、データ送信フェーズにおいてデータパケットを交換する場合、クライアントおよびサーバは、ハンドシェイクを通じてネゴシエートされるパケットシーケンス番号（Ｓｅｑ）およびＭＳＳを使用することによって、セグメント内のデータを連続して送る。各回にクライアントまたはサーバによって送られるデータの量の最大値は、ピアパーティによってアドバタイズされるウィンドウサイズである。レシーバは、ＡＣＫパケットを使用することによって、受信されたデータパケットを肯定応答し、レシーバによって受信されることが可能な最大データ長を更新する。また、ネットワーク内の異常なパケット損失、および過度に速い送信によって引き起こされたパケット損失を処理するために、一連のタイマおよび輻輳アルゴリズムが、ＴＣＰにおいてさらに必要とされる。

【0159】

前述の記載は、三方向ハンドシェイクの基本原理を説明している。任意選択で、バージョン限界または性能限界などの要因に起因して、いくつかの場合において、保護デバイスのプロトコルスタックは、全部のオプションではなく、一部のオプションのみをサポートしてよい。クライアントデバイスおよびサーバが、保護デバイスのプロトコルスタックによってサポートされないオプションを使用することによって、セッションネゴシエーションを行う場合に、保護デバイスがプロキシモードを使用して検出を行うとき、検出は失敗し得る。この場合において、本出願の一実施形態は、改善されたパケット処理手法を提供する。保護デバイスは、三方向ハンドシェイクフェーズにおいて、交換されたパケットを処理して、プロトコルスタックがオプションをサポートしないという要因によって引き起こされる検出障害を回避する。以下は、本出願の一実施形態による、三方向ハンドシェイクフェーズにおける保護デバイスの処理手順を説明する。

【0160】

三方向ハンドシェイクフェーズにおける保護デバイスの処理手順は、以下のステップＳ５０１からステップＳ５０３を含む。

【0161】

以下に説明されるステップＳ５０１からステップＳ５０３と、ステップＳ５１０からステップＳ５３０との間の関係は、ステップＳ５０１からステップＳ５０３と、ステップＳ５１０からステップＳ５３０とがそれぞれ、同じＴＣＰセッションの異なるフェーズのためのものである、というものである。ステップＳ５０１からステップＳ５０３は、ＴＣＰセッション確立をトリガするために、三方向ハンドシェイクフェーズに対して適用される。ステップＳ５１０からステップＳ５３０は、ＴＣＰセッション確立後に、データ送信フェーズに対して適用される。時系列の観点から、保護デバイスは、まず、三方向ハンドシェイクフェーズにおいてステップＳ５０１からステップＳ５０３を行う。ＴＣＰセッションが確立された場合、クライアントデバイスおよびサーバがデータパケットを交換する処理において、保護デバイスは、前述のステップＳ５１０からステップＳ５３０を行う。

【0162】

ステップＳ５０１：保護デバイスは、クライアントデバイスとサーバとの間で送信される第１のハンドシェイクパケットを取得する。

【0163】

第１のハンドシェイクパケットは、ＴＣＰセッションを作成するために使用される。第１のハンドシェイクパケットは、ＴＣＰにおける三方向ハンドシェイクパケットである。具体的には、第１のハンドシェイクパケットは、ＳＹＮパケットまたはＳＹＮ ＡＣＫパケットのうちの少なくとも１つである。第１のハンドシェイクパケットは、ＴＣＰヘッダを含み、ＴＣＰヘッダは、可変長を有するオプション（ｏｐｔｉｏｎ）フィールドを含む。オプションフィールドのコンテンツは、オプションに関する具体的な情報である。オプションは、ＳＡＣＫオプション、ＭＳＳオプション、ウィンドウ拡張オプション、タイムスタンプオプション等を含むが、これらに限定されない。

【0164】

第１のハンドシェイクパケットがＳＹＮパケットである場合、第１のハンドシェイクパケットのソースデバイスは、クライアントデバイスである。ステップＳ５０１は、以下を含む。保護デバイスは、クライアントデバイスからＳＹＮパケットを受信する。

【0165】

第１のハンドシェイクパケットがＳＹＮ ＡＣＫパケットである場合、第１のハンドシェイクパケットのソースデバイスは、サーバである。ステップＳ５０１は、以下を含む。保護デバイスは、サーバからＳＹＮ ＡＣＫパケットを受信する。

【0166】

ステップＳ５０２：保護デバイスは、第１のハンドシェイクパケットから第２のオプションを削除して、第２のハンドシェイクパケットを取得する。

【0167】

例えば、第１のハンドシェイクパケットは、第１のオプションと第２のオプションとを含む。保護デバイスは、第１のオプションおよび第２のオプションが保護デバイスのＴＣＰ／ＩＰプロトコルスタックによってサポートされるオプションであるかどうかを別々に決定する。保護デバイスが、第１のオプションは保護デバイスのＴＣＰ／ＩＰプロトコルスタックによってサポートされるオプションであると決定した場合、保護デバイスは、第１のオプションを予約する。保護デバイスが、第２のオプションは保護デバイスのＴＣＰ／ＩＰプロトコルスタックによってサポートされないオプションであると決定した場合、保護デバイスは、第２のオプションを削除する。処理を通じて保護デバイスによって取得された第２のハンドシェイクパケットは、第１のオプションを含むが、第２のオプションを含まない。

【0168】

ステップＳ５０３：保護デバイスは、第１のハンドシェイクパケットの宛先デバイスへ、第２のハンドシェイクパケットを送る。

【0169】

第１のハンドシェイクパケットがＳＹＮパケットである場合、第１のハンドシェイクパケットの宛先デバイスは、サーバである。第２のハンドシェイクパケットは、オプションを削除することによって取得されるＳＹＮパケットである。ステップＳ５０３は、以下を含む。保護デバイスは、オプションを削除することによって取得されたＳＹＮパケットをサーバへ送る。

【0170】

第１のハンドシェイクパケットがＳＹＮ ＡＣＫパケットである場合、第１のハンドシェイクパケットの宛先デバイスは、クライアントデバイスである。第２のハンドシェイクパケットは、オプションを削除することによって取得されるＳＹＮ ＡＣＫパケットである。ステップＳ５０３は、以下を含む。保護デバイスは、オプションを削除することによって取得されたＳＹＮ ＡＣＫパケットをクライアントデバイスへ送る。

【0171】

前述の記載は、ステップＳ５０１からステップＳ５０３を使用することによって、保護デバイスが三方向ハンドシェイクフェーズにおいてオプションを削除する手順を説明している。以下は、前述のオプション削除手順に基づいて、三方向ハンドシェイクを行う完全な手順を説明する。

【0172】

図７を参照されたい。本出願の一実施形態において、三方向ハンドシェイクフェーズは、図７に示される手順７００を含む。手順７００は、以下のステップＳ７１０からステップＳ７８０を含む。ステップＳ７１０およびステップＳ７２０におけるＳＹＮパケット、ならびにステップＳ７４０およびステップＳ７５０におけるＳＹＮ ＡＣＫパケットは、第１のハンドシェイクパケットの例である。ステップＳ７２０およびステップＳ７３０においてオプションを削除することによって取得されたＳＹＮパケット、ならびにステップＳ７５０およびステップＳ７６０においてオプションを削除することによって取得されたＳＹＮ ＡＣＫパケットは、第２のハンドシェイクパケットの例である。

【0173】

ステップＳ７１０：クライアントデバイスは、ＳＹＮパケットを生成し、送る。

【0174】

ステップＳ７２０：保護デバイスは、クライアントからＳＹＮパケットを受信する。保護デバイスは、ＳＹＮパケットを構文解析し、ＳＹＮパケットから、クライアントのＭＳＳ、ウィンドウ、タイムスタンプ、およびＳＡＣＫなどのオプションを抽出する。保護デバイスは、保護デバイスのローカルＴＣＰ／ＩＰプロトコルスタックによってサポートされるオプションに基づいて、ＳＹＮパケットから、ローカルＴＣＰ／ＩＰプロトコルスタックによってサポートされないオプションを削除し、ＳＹＮパケット内のローカルＴＣＰ／ＩＰプロトコルスタックによってサポートされるオプションを予約して、オプションを削除することによって取得されたＳＹＮパケットを取得する。

【0175】

ステップＳ７３０：保護デバイスは、オプションを削除することによって取得されたＳＹＮパケットをサーバへ送る。

【0176】

ステップＳ７４０：サーバは、オプションを削除することによって取得されたＳＹＮパケットを受信し、ＳＹＮ ＡＣＫパケットを生成し、送る。

【0177】

ステップＳ７５０：保護デバイスは、サーバからＳＹＮ ＡＣＫパケットを受信する。ステップＳ７２０におけるそれと同様に、保護デバイスは、ＳＹＮ ＡＣＫパケットを構文解析し、ＳＹＮ ＡＣＫパケットから、サーバのＭＳＳ、ウィンドウ、タイムスタンプ、およびＳＡＣＫなどのオプションを抽出する。保護デバイスは、保護デバイスのローカルＴＣＰ／ＩＰプロトコルスタックによってサポートされるオプションに基づいて、ＳＹＮ ＡＣＫパケットから、サポートされないオプションを削除し、ＳＹＮ ＡＣＫパケット内のローカルＴＣＰ／ＩＰプロトコルスタックによってサポートされるオプションを予約して、オプションを削除することによって取得されたＳＹＮ ＡＣＫパケットを取得する。

【0178】

ステップＳ７６０：保護デバイスは、オプションを削除することによって取得されたＳＹＮ ＡＣＫパケットをクライアントへ送る。

【0179】

ステップＳ７７０：クライアントは、オプションを削除することによって取得されたＳＹＮ ＡＣＫパケットを受信し、ＡＣＫパケットを生成し、送る。

【0180】

ステップＳ７８０：保護デバイスは、クライアントからＡＣＫパケットを受信し、保護デバイスは、クライアントからサーバへＡＣＫパケットを転送して、クライアントとサーバとの間のセッションの確立を完了する。

【0181】

前述の記載は、この実施形態において提供される三方向ハンドシェイク手順を説明しており、以下は、三方向ハンドシェイク手順に基づいて、モード切り替えを行う手順を説明する。

【0182】

以下に説明されるモード切り替え手順は、前述の方法５００におけるステップＳ５３０の例である。上述した三方向ハンドシェイク手順と、以下に説明されるモード切り替え手順との間の主な関連性は、保護デバイスが三方向ハンドシェイク手順においてサポートされないオプションを削除するので、モード切り替え手順においてパケット交換に関連するオプションは、保護デバイスのＴＣＰ／ＩＰプロトコルスタックによってサポートされるオプションであることが確実にされることが可能である点にあり、それによって、モード切り替え手順においてクライアントまたはサーバによって使用されるオプションを保護デバイスが構文解析することが困難であることが理由で引き起こされるパケット送信故障を回避し、モード切り替え手順における信頼性および成功率を改善する。以下は、そのような効果を達成するための原理を説明する。

【0183】

ＴＣＰにおいて、どのオプションがＴＣＰセッションにおいてデータパケットを送信するために使用されるかは、三方向ハンドシェイクパケット使用することによってネゴシエートされる。具体的には、三方向ハンドシェイクフェーズにおいて、送信側および受信側（クライアントおよびサーバ）は各々、送信側または受信側によってサポートされるオプションを三方向ハンドシェイクパケットに対して追加し、三方向ハンドシェイクパケットをピアエンドへ送って、送信側または受信側によってサポートされるオプションのピア側に通知する。送信側または受信側が、ピア側から三方向ハンドシェイクパケットを受信した後に、三方向ハンドシェイクパケットがオプションを搬送し、送信側または受信側がそのオプションをサポートする場合、送信側または受信側は、そのオプションをネゴシエートされたオプションとして使用する。セッションが確立された後に、送信側または受信側は、ネゴシエートされたオプションを使用して、データを送信する。

【0184】

しかしながら、この実施形態において提供される三方向ハンドシェイク手順において、保護デバイスは、三方向ハンドシェイクパケットから、サポートされないオプションを削除し、オプションを削除することによって取得された三方向ハンドシェイクパケットをクライアントデバイスまたはサーバへ転送する。したがって、クライアントデバイスまたはサーバへ送信される三方向ハンドシェイクパケットは、保護デバイスによってサポートされないオプションを含まない。言いかえれば、クライアントデバイスまたはサーバへ送信される三方向ハンドシェイクパケット内の全てのオプションは、保護デバイスによってサポートされるオプションである。したがって、クライアントデバイスとサーバとによってネゴシエートされた各オプションは、保護デバイスによってサポートされるオプションである。これは、クライアントデバイスとサーバとによってネゴシエートされたオプションが、保護デバイスによってサポートされないオプションを含む場合を回避する。そのため、セッションが確立された後に、セッションにおいてクライアントとサーバとの間で交換されるパケット内の全てのオプションは、保護デバイスによってサポートされるオプションである。

【0185】

したがって、この実施形態において提供されるモード切り替え手順において、クライアントとサーバとの間のセッションの処理において、保護デバイスが、現在のセッションについての検出モードを切り替えることを決定した場合、モード切り替えの後に保護デバイスによって受信されるパケット内のオプションは、保護デバイスによってサポートされるオプションであるので、保護デバイスは、切り替えの後に使用されるモードにおいて、保護デバイスによってサポートされるオプションを使用することによって、受信されたパケットを処理して、保護デバイスが、セッション処理において切り替えの後に使用されるモードに成功裡に入ることを確実にすることができ、その結果、セッションにおける後続のパケットは、切り替えの後に使用されるモードにおいて検出されることが可能である。

【0186】

例えば、切り替え後に使用されるモードがプロキシモードである場合、保護デバイスは、保護デバイスのＴＣＰ／ＩＰプロトコルスタックの能力に基づいて、最初の三方向ハンドシェイクフェーズにおけるクライアントデバイスとサーバとの間のハンドシェイクに干渉して、クライアントデバイスとサーバとによってネゴシエートされる全てのオプションが、保護デバイスのローカルＴＣＰ／ＩＰプロトコルスタックによってサポートされることが可能であることを確実にする。したがって、続いてプロキシモードに切り替えられると、クライアントデバイスとサーバとが、ネゴシエートされたオプションを使用することによってパケットを交換する場合、保護デバイスのＴＣＰ／ＩＰプロトコルスタックは、サポートされるオプションを使用することによって、クライアントデバイスと相互作用するためのサーバに置換することができ、保護デバイスのＴＣＰ／ＩＰプロトコルスタックは、サポートされるオプションを使用することによって、サーバと相互作用するためのクライアントデバイスに置換することができ、その結果、プロキシモードを使用して検出を行うタスクが、誤りなしで成功裡に実行される。例えば、保護デバイス上のＴＣＰ／ＩＰプロトコルスタックはＳＡＣＫオプションをサポートしないが、クライアントデバイスおよびサーバがＳＡＣＫオプションをサポートする場合に、クライアントデバイスとサーバとが三方向ハンドシェイクフェーズにおいてＳＡＣＫオプションを使用することをネゴシエートするとき、保護デバイスがプロキシモードに切り替えた後に、保護デバイスがＳＡＣＫオプションを構文解析することは困難である。結果として、送信故障が引き起こされ、サービスが中断される。しかしながら、保護デバイスは、ハンドシェイクパケット内のＳＡＣＫオプションを削除し、その結果、クライアントデバイスとサーバとは、三方向ハンドシェイクフェーズにおいてＳＡＣＫオプションを使用することをネゴシエートしない。したがって、保護デバイスがプロキシモードに切り替えた後に、受信され続けるパケットはＳＡＣＫオプションを含まず、それによって、保護デバイスがＳＡＣＫオプションを構文解析することが困難であるために引き起こされる送信故障を回避する。

【0187】

保護デバイスによってフローモードとプロキシモードとの間で行われるモード切り替えは、保護デバイスによって行われるモード切り替えの特定の処理を説明するために、以下で例として使用される。詳細については、以下のシナリオ１およびシナリオ２を参照されたい。

【0188】

シナリオ１：フローモードからプロキシモードへの切り替え

【0189】

シナリオ１において、保護デバイスは、フローモードを使用して、いくつかのデータパケットをバッファ済みであり得る。例えば、フローモードにおいて、保護デバイスは、ウィンドウ内で受信されたデータパケットをバッファして、フローリアセンブリを行う。別の例として、保護デバイスは、ピア側へ転送済みであるが、ピア側が肯定応答パケットを返していない、いくつかのデータパケットを、フローモードを使用して、バッファする。これらの以前にバッファされたデータパケットに対して、保護デバイスは、以下の解決策を行って、モード切り替え処理過程をさらに加速し、オプション削除によってもたらされる効果を達成することに基づいて、モード切り替え処理遅延を低減する。

【0190】

以下は、２つの態様、すなわち、態様（１）および態様（２）を使用することによって、シナリオ１における具体的な実装を説明する。

【0191】

態様（１）は、フローモードを使用して以前にバッファされた受信されたデータパケットを、保護デバイスがどのように処理するかを説明する。

【0192】

保護デバイスがＴＣＰセッションについてフローモードからプロキシモードに切り替える処理において、保護デバイスは、保護デバイスのＴＣＰ／ＩＰプロトコルスタックを使用することによって、フローモードを使用して、以前にバッファされた受信されたデータパケットに対してＡＣＫ処理を実行する。具体的には、フローモードを使用して、以前にバッファされた、クライアントデバイスによって送られたデータパケットに対して、保護デバイスは、ＴＣＰ／ＩＰプロトコルスタックを通じて肯定応答パケットを能動的に生成し、肯定応答パケットをクライアントデバイスへ送って、クライアントデバイスに応答するためのシミュレーションされるサーバとして動作する。フローモードを使用して、以前にバッファされた、サーバによって送られたデータパケットに対して、保護デバイスは、ＴＣＰ／ＩＰプロトコルスタックを通じて肯定応答パケットを能動的に生成し、肯定応答パケットをサーバへ送って、サーバに応答するためのシミュレーションされるクライアントデバイスとして動作する。

【0193】

例えば、保護デバイスは、三方向ハンドシェイクフェーズにおいて、第１のオプション（保護デバイスによってサポートされるオプション）を予約し、第２のオプション（保護デバイスによってサポートされないオプション）を削除する。前述の方法５００において、第１のモードはフローモードであり、第２のモードはプロキシモードである。前述の方法５００において、保護デバイスは、第１のモードを使用して、第２のデータパケットを受信し、バッファする。保護デバイスが第２のモードに切り替えることを決定した後に、保護デバイスは、第１のオプションに基づいて、ＴＣＰセッションにおける第２のデータパケットについての肯定応答パケットを生成し、保護デバイスは、第２のデータパケットについての肯定応答パケットを第２のデータパケットのソースデバイスへ送る。

【0194】

いくつかの実施形態において、第２のデータパケットは、クライアントによってサーバへ送られるパケットである。具体的には、保護デバイスが、第１のモードを使用して、ＴＣＰセッションにおいてデータパケットを検出する処理において、クライアントは、第２のデータパケットを送り、保護デバイスは、クライアントから第２のデータパケットを受信し、バッファし、保護デバイスが第２のモードに切り替えることを決定した後に、保護デバイスは、第２のデータパケットについての肯定応答パケットをクライアントへ送る。

【0195】

いくつかの他の実施形態において、第２のデータパケットは、サーバによってクライアントへ送られるパケットである。具体的には、保護デバイスが、第１のモードを使用して、ＴＣＰセッションにおいてデータパケットを検出する処理において、サーバは、第２のデータパケットを送り、保護デバイスは、サーバから第２のデータパケットを受信し、バッファし、保護デバイスが第２のモードに切り替えることを決定した後に、保護デバイスは、第２のデータパケットについての肯定応答パケットをサーバへ送る。

【0196】

態様（２）は、フローモードを使用してピア側へ転送済みであるが、ピア側から肯定応答パケットが受信されないデータパケットを、保護デバイスがどのように処理するかを説明する。

【0197】

保護デバイスがＴＣＰセッションについてフローモードからプロキシモードへ切り替える処理において、フローモードを使用してピア側へ転送済みであるが、ピア側から肯定応答パケットが受信されないデータパケットについて、保護デバイスは、保護デバイスのＴＣＰ／ＩＰプロトコルスタックを使用することによって、データパケットの送信信頼性について責任を負う。具体的には、フローモードを使用してサーバへ転送済みであるが、肯定応答パケットが受信されないデータパケットについて、保護デバイスは、シミュレーションされるクライアントとしての役割を果たし、パケット損失が発生した場合に、データパケットをサーバへ再送信して、データパケットがサーバに到達することを確実にする。フローモードを使用してクライアントへ転送済みであるが、肯定応答パケットが受信されないデータパケットについて、保護デバイスは、シミュレーションされるサーバとしての役割を果たし、パケット損失が発生した場合に、データパケットをクライアントへ再送信して、データパケットがクライアントに到達することを確実にする。

【0198】

例えば、保護デバイスは、三方向ハンドシェイクフェーズにおいて、第１のオプション（保護デバイスによってサポートされるオプション）を予約し、第２のオプション（保護デバイスによってサポートされないオプション）を削除する。前述の方法５００において、第１のモードはフローモードであり、第２のモードはプロキシモードである。前述の方法５００において、保護デバイスは、第１のモードを使用して、ＴＣＰセッションにおける第３のデータパケットを送る。保護デバイスが第２のモードに切り替えることを決定した後に、第３のデータパケットが再送信条件を満たす場合、保護デバイスは、第１のオプションに基づいて、第３のデータパケットの宛先デバイスへ第３のデータパケットを再送する。

【0199】

いくつかの実施形態において、第３のデータパケットは、クライアントによってサーバへ送られるパケットである。具体的には、保護デバイスが第１のモードを使用して、ＴＣＰセッションにおいてデータパケットを検出する処理において、クライアントは、第３のデータパケットを送り、保護デバイスは、第３のデータパケットを受信し、第３のデータパケットに対してセキュリティ検出を行い、第３のデータパケットをサーバへ転送し、保護デバイスが第２のモードに切り替えることを決定した後に、第３のデータパケットが再送信条件を満たす場合、保護デバイスは、第３のデータパケットをサーバへ再送する。

【0200】

いくつかの実施形態において、第３のデータパケットは、サーバによってクライアントへ送られるパケットである。具体的には、保護デバイスが第１のモードを使用して、ＴＣＰセッションにおいてデータパケットを検出する処理において、サーバは、第３のデータパケットを送り、保護デバイスは、第３のデータパケットを受信し、第３のデータパケットに対してセキュリティ検出を行い、第３のデータパケットをクライアントへ転送し、保護デバイスが第２のモードに切り替えることを決定した後に、第３のデータパケットが再送信条件を満たす場合、保護デバイスは、第３のデータパケットをクライアントへ再送する。

【0201】

前述の態様（１）および態様（２）から、フローモードからプロキシモードに切り替えるシナリオにおいて、保護デバイスは、ハンドシェイクフェーズにおいてネゴシエートされるオプション（第１のオプション）に基づいて、フローモードを使用して以前にバッファされたパケットに対してＡＣＫ処理を行い、信頼できる送信について責任を負い、その結果、フローモードを使用して保護デバイスによって以前にバッファされたデータパケットも、プロキシモードを使用して迅速に処理されることが可能であり、それによって、フローモードからプロキシモードに切り替えるために必要とされる時間を短縮することが分かる。

【0202】

図８を参照されたい。保護デバイスは、図８における機能的なモジュールを提供することによって、前述の処理手順をサポートする。

【0203】

保護デバイスのＴＣＰ制御層は、フローモード処理モジュール１３１１、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１、フローモード処理モジュール１３１２、およびＴＣＰ／ＩＰプロトコルスタックモジュール１３３２を含む。図３におけるフローモード処理モジュール１３１は、図８におけるフローモード処理モジュール１３１１と、フローモード処理モジュール１３１２とを含む。図３におけるＴＣＰ／ＩＰプロトコルスタックモジュール１３３は、図８におけるＴＣＰ／ＩＰプロトコルスタックモジュール１３３１と、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３２とを含む。

【0204】

フローモード処理モジュール１３１１は、フローモードを使用して、クライアントデバイス１１との相互作用を処理するように構成される。フローモード処理モジュール１３１１は、受信されたパケットキュー１３１１１と、送られたパケットキュー１３１１２とを含む。受信されたパケットキュー１３１１１は、フローモードを使用して、クライアントデバイス１１から受信されたデータパケットをバッファするように構成される。いくつかの実施形態において、受信されたパケットキュー１３１１１は、１つのウィンドウ内でクライアントデバイス１１から受信されたデータパケットをバッファするように特に構成される。受信されたパケットキュー１３１１１内にバッファされたデータパケットは、ＴＣＰ層においてフローリアセンブリを行うために使用される。送られたパケットキュー１３１１２は、フローモードを使用して、クライアントデバイス１１へ送られたデータパケットをバッファするように構成される。いくつかの実施形態において、送られたパケットキュー１３１１２は、送られてはいるが、クライアントデバイス１１からの肯定応答パケットが依然として受信されないデータパケットをバッファするように特に構成される。

【0205】

フローモード処理モジュール１３１２は、フローモードを使用して、サーバ１２との相互作用を処理するように構成される。フローモード処理モジュール１３１２は、受信されたパケットキュー１３１２１と、送られたパケットキュー１３１２２とを含む。受信されたパケットキュー１３１２１は、フローモードを使用して、サーバ１２から受信されたデータパケットをバッファするように構成される。いくつかの実施形態において、受信されたパケットキュー１３１２１は、１つのウィンドウ内でサーバ１２から受信されたデータパケットをバッファするように特に構成される。受信されたパケットキュー１３１２１にバッファされたデータパケットは、ＴＣＰ層においてフローリアセンブリを行うために使用される。送られたパケットキュー１３１２２は、フローモードを使用して、サーバ１２へ送信されたデータパケットをバッファするように構成される。いくつかの実施形態において、送られたパケットキュー１３１２２は、送られてはいるが、サーバ１２からの肯定応答パケットが依然として受信されないデータパケットをバッファするように特に構成される。

【0206】

ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１は、クライアントデバイス１１と相互作用するように構成されたＴＣＰ／ＩＰプロトコルスタックモジュールである。

【0207】

ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１は、受信されたパケットキュー１３３１１と、送られたパケットキュー１３３１２とを含む。受信されたパケットキュー１３３１１は、プロキシモードを使用して、クライアントデバイス１１から受信されたデータパケットをバッファするように構成される。送られたパケットキュー１３３１２は、プロキシモードを使用して、クライアントデバイス１１へ送られるデータパケットをバッファするように構成される。いくつかの実施形態において、送られたパケットキュー１３３１２は、プロキシモードを使用してクライアントデバイス１１へ送られてはいるが、肯定応答パケットが依然として受信されないデータパケットをバッファするように特に構成される。

【0208】

ＴＣＰ／ＩＰプロトコルスタックモジュール１３３２は、サーバ１２と相互作用するＴＣＰ／ＩＰプロトコルスタックモジュールである。ＴＣＰ／ＩＰプロトコルスタックモジュール１３３２は、受信されたパケットキュー１３３２１と、送られたパケットキュー１３３２２とを含む。受信されたパケットキュー１３３２１は、プロキシモードを使用して、サーバ１２から受信されたデータパケットをバッファするように構成される。送られたパケットキュー１３３２２は、プロキシモードを使用して、サーバ１２へ送信されるデータパケットをバッファするように構成される。いくつかの実施形態において、送られたパケットキュー１３３２２は、プロキシモードを使用してサーバ１２へ送信されてはいるが、肯定応答パケットが依然として受信されないデータパケットをバッファするように特に構成される。

【0209】

以下は、保護デバイスが図３または図８に示されるモジュール使用することによってフローモードからプロキシモードに切り替える処理手順をどのように実装するかを説明する。

【0210】

図３および図８に示されるように、上位層サービスモジュール１３０が、処理のためにプロキシモードに入ることが必要であると決定した場合、上位層サービスモジュール１３０は、ＴＣＰ制御層へ命令を供給して、プロキシモードに切り替えられる必要があることをＴＣＰ制御層に通知する。上位層サービスモジュール１３０によって送られた命令を受信した後に、ＴＣＰ制御層は、以下のステップＳ５３０ａからステップＳ５３０ｄを行う。

【0211】

ステップＳ５３０ａ：ＴＣＰ制御層は、フローモード処理モジュール１３１によって記録されたＴＣＰ三方向ハンドシェイクネゴシエーション情報に基づいて、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３を使用することによってセッションペアを迅速に確立する。セッションペアは、プロキシサーバセッションと、プロキシクライアントセッションとを含む。プロキシサーバセッションは、実際のクライアントとの相互作用について責任を負う。プロキシクライアントセッションは、実際のサーバとの相互作用について責任を負う。ネゴシエーション情報は、三方向ハンドシェイク処理期間中にネゴシエートされるオプション（例えば、第１のオプション）を含む。

【0212】

ステップＳ５３０ｂ：ＴＣＰ制御層は、フローモード処理モジュール１３１においてバッファされたデータパケットをＴＣＰ／ＩＰプロトコルスタックモジュール１３３へ送る。ＴＣＰ／ＩＰプロトコルスタックモジュール１３３は、フローモード処理モジュール１３１から送られるパケットに対してＡＣＫ処理を行って、実際のクライアントまたは実際のサーバに応答する。

【0213】

具体的には、図８に示されるように、フローモード処理モジュール１３１１における受信されたパケットキュー１３１１１は、クライアントデバイス１１からのデータパケットをバッファする。ＴＣＰ制御層は、受信されたパケットキュー１３１１１内にバッファされたデータパケットを、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１内の受信されたパケットキュー１３３１１へ送る。ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１は、フローモード処理モジュール１３１１によって送られたパケットに対してＡＣＫ処理を行って、クライアントデバイス１１に応答する。

【0214】

フローモード処理モジュール１３１２内の受信されたパケットキュー１３１２１は、サーバ１２からのデータパケットをバッファする。ＴＣＰ制御層は、受信されたパケットキュー１３１２１内にバッファされたデータパケットを、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３２内の受信されたパケットキュー１３３２１へ送る。ＴＣＰ／ＩＰプロトコルスタックモジュール１３３２は、フローモード処理モジュール１３１２によって送られたパケットに対してＡＣＫ処理を行って、サーバ１２に応答する。

【0215】

ステップＳ５３０ｃ：ＴＣＰ制御層は、ＴＣＰ／ＩＰプロトコルスタックモジュール／プロキシモード処理モジュール内の送られたパケットキューに対して、フローモード処理モジュール１３１によって転送済みであるが、ＡＣＫが依然として受信されないパケットを追加する。具体的には、フローモード処理モジュール１３１１とＴＣＰ／ＩＰプロトコルスタックモジュール１３３１とは両方とも、クライアントデバイス１１との相互作用を処理する責任を負い、フローモード処理モジュール１３１２とＴＣＰ／ＩＰプロトコルスタックモジュール１３３２とは両方とも、サーバ１２との相互作用を処理する責任を負う。フローモードからプロキシモードに切り替える処理において、ＴＣＰ制御層は、フローモード処理モジュール１３１１内の送られたパケットキュー１３１１２内にバッファされたパケットを、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１内の送られたパケットキュー１３３１２に対して追加する。ＴＣＰ制御層は、フローモード処理モジュール１３１２内の送られたパケットキュー１３１２２内にバッファされたパケットを、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３２内の送られたパケットキュー１３３２２に対して追加する。

【0216】

例えば、上位層サービスモジュール１３０は、クライアントデバイス１１によって送られたデータパケットに基づいて、プロキシモードが使用される必要があると決定する。ＴＣＰ制御層が、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１へ、クライアントデバイス１１によって続いて送られたデータパケットを送った後に、ＴＣＰ制御層は、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１へ、フローモード処理モジュール１３１１によってクライアントデバイス１１へ転送されたデータパケットを送って、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１を使用することによってプロキシクライアントの機能実装する必要がある。ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１は、パケット損失またはタイムアウトによって引き起こされる再送信動作について責任を負う。

【0217】

ステップＳ５３０ｄ：ＴＣＰ制御層は、フローモードにおいて使用されたリソースをクリアし、ＴＣＰセッションにおける後続のパケットを処理するためにプロキシモードに入る。

【0218】

例えば、ＴＣＰ制御層は、フローモード処理モジュール１３１１内の受信されたパケットキュー１３１１１および送られたパケットキュー１３１１２、ならびにフローモード処理モジュール１３１２内の受信されたパケットキュー１３１２１および送られたパケットキュー１３１２２によって占有されるバッファ空間を解放する。

【0219】

上記に提供されるシステムアーキテクチャにおいては、カスタマイズされたＴＣＰ／ＩＰプロトコルスタックが使用されており、その結果、フローモードからプロキシモードへの適応的な切り替えが、データパケット交換フェーズにおけるデータパケット交換に基づいて実装されるだけでなく、データパケットがフローモードを使用してバッファされた複雑な場合もサポートされ、それによって、解決策の可用性を改善する。

【0220】

シナリオ２：プロキシモードからフローモードへの切り替え

【0221】

保護デバイスが処理のためにプロキシモードを使用する処理において、保護デバイスのＴＣＰ／ＩＰプロトコルスタックモジュールと保護デバイスの上位層サービスモジュールとは各々、特定の量のデータパケットをバッファする。プロキシモードからフローモードに切り替えるための理想的な時点は、保護デバイスのＴＣＰ／ＩＰプロトコルスタックモジュールおよび上位層サービスモジュールのいずれも、バッファされたデータパケットを有しないところである。そのような理想的な時点においてモード切り替えが行われる場合、保護デバイスは、フローモード処理に関連するリソース、状態等を確立し、ＴＣＰ／ＩＰプロトコルスタックに関連するリソースを解放して、モード切り替えを完了する。しかしながら、一般に、この理想的な状態は満たされることができない。これは、ＴＣＰ／ＩＰプロトコルスタックモジュール内の２つのタイプのバッファ（受信されたパケットキューおよび送られたパケットキュー）が、通常は空ではないからである。例えば、保護デバイスがプロキシモードに切り換えることを決定した場合、ＴＣＰ／ＩＰプロトコルスタックモジュール内の送られたパケットキューは、送られており、かつ、ピア側から肯定応答が待たれる、バッファされたいくつかのパケットを有することがあり、ＴＣＰ／ＩＰプロトコルスタックモジュール内の受信されたパケットキューは、ＴＣＰ／ＩＰプロトコルスタックモジュールによって肯定応答されており、かつ、上位層サービス処理を待つ、バッファされたいくつかのパケットを有することがある。プロキシモードを使用して以前にバッファされたこれらのデータパケットに対して、保護デバイスは、以下の解決策を行って、オプション削除によってもたらされる効果を達成することに基づいて、これらのデータパケットの送信信頼性をさらに確実にする。

【0222】

以下は、２つの態様、すなわち、態様（ａ）および態様（ｂ）を使用することによって、シナリオ２における具体的な実装を説明する。

【0223】

態様（ａ）は、保護デバイスが、プロキシモードを使用して、以前にバッファされている送られたデータパケットをどのように処理するかを説明する。

【0224】

保護デバイスが、ＴＣＰセッションについてプロキシモードからフローモードに切り替える処理において、プロキシモードを使用して以前に送られたデータパケットについて、保護デバイスは、保護デバイスのＴＣＰ／ＩＰプロトコルスタックを使用することによって、これらのデータパケットの送信信頼性について責任を負う。具体的には、保護デバイスは、これらのデータパケットについて、ピア側からの肯定応答パケットを待ち続ける。保護デバイスが、これらのデータパケットについて、ピア側からの肯定応答パケットを受信した後に、保護デバイスは、これらのデータパケットをバッファから削除する。保護デバイスが、タイムアウト前に肯定応答パケットが受信されないという事実、ＳＡＣＫオプション、または別の手法に基づいて、パケット損失がこれらのデータパケットにおいて発生したことを見出した場合、保護デバイスは再送信を行う。

【0225】

例えば、保護デバイスは、三方向ハンドシェイクフェーズにおいて、第１のオプション（保護デバイスによってサポートされるオプション）を予約し、第２のオプション（保護デバイスによってサポートされないオプション）を削除する。前述の方法５００において、第１のモードはプロキシモードであり、第２のモードはフローモードである。前述の方法５００において、保護デバイスは、第１のモードを使用して、ＴＣＰセッションにおける第４のデータパケットを送っている。保護デバイスが第２のモードに切り換えることを決定した後に、第４のデータパケットが再送信条件を満たす場合、保護デバイスは、第１のオプションに基づいて、第４のデータパケットの宛先デバイスへ第４のデータパケットを再送する。

【0226】

いくつかの実施形態において、第４のデータパケットは、クライアントによってサーバへ送られるパケットである。具体的には、保護デバイスが第１のモードを使用してＴＣＰセッションにおいてデータパケットを検出する処理において、クライアントは、第４のデータパケットを送り、保護デバイスは、第４のデータパケットを受信し、第１のオプションに基づいて第４のデータパケットを構文解析した後に、保護デバイスは、クライアントデバイスへ肯定応答パケットを送る。また、保護デバイスは、第４のデータパケットに対してセキュリティ検出を行う。第４のデータパケットに対する検出が成功した場合、保護デバイスは、第４のデータパケットをサーバへ送る。保護デバイスが第２のモードに切り換えることを決定した後に、第４のデータパケットが再送信条件を満たす場合、保護デバイスは、第１のオプションに基づいて、第４のデータパケットをサーバへ再送する。

【0227】

いくつかの他の実施形態において、第４のデータパケットは、サーバによってクライアントへ送られるパケットである。具体的には、保護デバイスが第１のモードを使用してＴＣＰセッションにおいてデータパケットを検出する処理において、サーバは、第４のデータパケットを送り、保護デバイスは、第４のデータパケットを受信し、第１のオプションに基づいて第４のデータパケットを構文解析した後に、保護デバイスは、肯定応答パケットをサーバへ送る。また、保護デバイスは、第４のデータパケットに対してセキュリティ検出を行う。第４のデータパケットに対する検出が成功した場合、保護デバイスは、第４のデータパケットをクライアントへ送る。保護デバイスが第２のモードに切り換えることを決定した後に、第４のデータパケットが再送信条件を満たす場合、保護デバイスは、第１のオプションに基づいて、第４のデータパケットをクライアントへ再送する。

【0228】

態様（ｂ）は、保護デバイスが、プロキシモードを使用して、以前にバッファされている受信されたデータパケットをどのように処理するかを説明する。

【0229】

保護デバイスがＴＣＰセッションについてプロキシモードからフローモードに切り替える処理において、プロキシモードを使用して、受信され、肯定応答されたデータパケットについて、保護デバイスは、まず、これらのデータパケットに対してセキュリティ検出を行い、次いで、保護デバイスのＴＣＰ／ＩＰプロトコルスタックモジュールを使用することによって、検出されたデータパケットを確実に送る。信頼できる送信とは、ＴＣＰ／ＩＰプロトコルスタックがＴＣＰ再送信機構に基づいて、ＴＣＰセッションのピア側（クライアントまたはサーバ）へデータパケットを送ることを意味する。

【0230】

例えば、保護デバイスは、三方向ハンドシェイクフェーズにおいて、第１のオプション（保護デバイスによってサポートされるオプション）を予約し、第２のオプション（保護デバイスによってサポートされないオプション）を削除する。前述の方法５００において、第１のモードはプロキシモードであり、第２のモードはフローモードである。前述の方法５００において、保護デバイスは、第１のモードを使用して、ＴＣＰセッションにおける第５のデータパケットを受信済みであり、保護デバイスは、第１のオプションに基づいて第５のデータパケットを構文解析した後に、第５のデータパケットのソースデバイスへ第５のデータパケットについての肯定応答パケットを送っている。保護デバイスが第２のモードに切り換えることを決定した後に、保護デバイスは、第５のデータパケットを検出して、第６のデータパケットを取得し、保護デバイスは、第１のオプションに基づいて、第５のデータパケットの宛先デバイスへ第６のデータパケットを送る。

【0231】

いくつかの実施形態において、第５のデータパケットは、クライアントによってサーバへ送られるパケットである。具体的には、保護デバイスが第１のモードを使用してＴＣＰセッションにおいてデータパケットを検出する処理において、クライアントは、第５のデータパケットを送り、保護デバイスは、第５のデータパケットを受信し、第１のオプションに基づいて第５のデータパケットを構文解析した後に、保護デバイスは、クライアントデバイスへ第５のデータパケットについての肯定応答パケットを送る。保護デバイスが第２のモードに切り替えることを決定した後に、保護デバイスは、第５のデータパケットを検出して、第６のデータパケットを取得し、保護デバイスは、第１のオプションに基づいて、第６のデータパケットをサーバへ送る。また、第６のデータパケットが再送信条件を満たす場合、保護デバイスは、第１のオプションに基づいて、サーバへ第６のデータパケットを再送する。

【0232】

いくつかの他の実施形態において、第５のデータパケットは、サーバによってクライアントへ送られるパケットである。具体的には、保護デバイスが第１のモードを使用してＴＣＰセッションにおいてデータパケットを検出する処理において、サーバは、第５のデータパケットを送り、保護デバイスは、第５のデータパケットを受信し、第１のオプションに基づいて第５のデータパケットを構文解析した後に、保護デバイスは、第５のデータパケットについての肯定応答パケットをサーバへ送る。保護デバイスが第２のモードに切り替えることを決定した後に、保護デバイスは、第５のデータパケットを検出して、第６のデータパケットを取得し、保護デバイスは、第１のオプションに基づいて、第６のデータパケットをクライアントへ送る。また、第６のデータパケットが再送信条件を満たす場合、保護デバイスは、第１のオプションに基づいて、クライアントへ第６のデータパケットを再送する。

【0233】

図９を参照して、以下は、保護デバイスが、図９に示されるモジュールを使用することによって、プロキシモードからフローモードに切り替える処理手順をどのように実装するかを説明する。

【0234】

図９を参照されたい。保護デバイスがプロキシモードからフローモードに切り替えるステップは、以下のステップＳ５３０ａ’からステップＳ５３０ｉ’を含む。

【0235】

ステップＳ５３０ａ’：ＴＣＰ制御層は、新しいパケットをプロトコルスタックにプッシュする動作を停止する。具体的には、上位層サービスモジュール１３０がフローモードに切り替えることを決定した後に、ＴＣＰ制御層がクライアントデバイス１１からデータパケットを新たに受信した場合、ＴＣＰ制御層は、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１内の受信されたパケットキュー１３１１１にデータパケットを追加することを停止し、ＴＣＰ制御層がサーバ１２からデータパケットを新たに受信した場合、ＴＣＰ制御層は、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３２内の受信されたパケットキュー１３３２１にデータパケットを追加することを停止する。

【0236】

ステップＳ５３０ｂ’：ＴＣＰ制御層は、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１内の受信されたパケットキュー１３１１１内の順不同のデータパケット、およびＴＣＰ／ＩＰプロトコルスタックモジュール１３３２内の受信されたパケットキュー１３３２１内の順不同のデータパケットを破棄する。

【0237】

具体的には、ＴＣＰ／ＩＰプロトコルスタックモジュールが、順不同なデータパケットについての肯定応答パケットを返さないので、順不同なデータパケットは確実に破棄されることが可能である。順不同なデータパケットは、データパケットのＳｅｑ番号が連続しないことを意味する。例えば、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１内の受信されたパケットキュー１３１１１は、そのＳｅｑ番号が１から５であるデータパケット、および、そのＳｅｑ番号が８から１０であるデータパケットをバッファするが、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１内の受信されたパケットキュー１３１１１は、そのＳｅｑ番号が６および７であるデータパケットを含有しない。この場合において、そのＳｅｑ番号が８から１０であるデータパケットは、順不同なデータパケットである。ステップＳ５３０ｂを行う場合、ＴＣＰ制御層は、そのＳｅｑ番号が８から１０であるデータパケットを破棄する。

【0238】

ステップＳ５３０ｃ’：ＴＣＰ制御層は、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１内の受信されたパケットキュー１３１１１内のデータパケット、およびＴＣＰ／ＩＰプロトコルスタックモジュール１３３２内の受信されたパケットキュー１３３２１のデータパケットを、処理のために上位層サービスモジュール１３０へ投入し、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１内の受信されたパケットキュー１３１１１、およびＴＣＰ／ＩＰプロトコルスタックモジュール１３３２内の受信されたパケットキュー１３３２１をクリアする。

【0239】

ステップＳ５３０ｄ’：上位層サービスモジュール１３０は、処理されたデータパケットをＴＣＰ制御層へ送り、次いで、上位層サービスモジュール１３０は、バッファをクリアする。ＴＣＰ制御層は、ピア側におけるＴＣＰ／ＩＰプロトコルスタックモジュール内の送られたパケットキューへ、処理されたデータパケットを送る。

【0240】

具体的には、データパケットが、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１内の受信されたパケットキュー１３１１１からのものである場合、ＴＣＰ制御層は、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３２内の送られたパケットキュー１３３２２へ、データパケットを送り、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３２内の送られたパケットキュー１３３２２は、サーバ１２へデータパケットを送る。データパケットが、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３２内の受信されたパケットキュー１３３２１からのものである場合、ＴＣＰ制御層は、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１内の送られたパケットキュー１３３１２へデータパケットを送り、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１内の送られたパケットキュー１３３１２は、クライアントへデータパケットを送る。

【0241】

ステップＳ５３０ｅ’：送られたパケットキュー内のデータパケットについては、保護デバイスは、ＴＣＰ／ＩＰプロトコルスタックモジュールを使用することによってデータパケットを確実に送り、ＴＣＰ／ＩＰプロトコルスタックモジュールによって送られたデータパケットの最大Ｓｅｑ番号を記録する。送られたデータパケットの最大Ｓｅｑ番号は、例えば、送られたデータの長さに基づいて、初期シーケンス番号（ＩＳＮ）を増加させることによって取得される値である。例えば、クライアントの初期シーケンス番号、すなわち、ＩＳＮ（ｃ）が１０００であり、保護デバイスが、クライアントのための２０００バイトのデータを転送済みである場合、最大Ｓｅｑ番号は３００１であり、ただし、ＳＹＮパケットは、１バイトを占有する。

【0242】

ステップＳ５３０ｆ’：クライアントまたはサーバから後続のデータパケットを受信した後に、保護デバイスは、フローモードを使用して、後続のデータパケットを処理する。

【0243】

保護デバイスが、クライアントまたはサーバから肯定応答パケットを受信した場合、肯定応答パケットを処理するステップは、以下のステップＳ５３０ｇ’またはステップＳ５３０ｈ’を含む。具体的には、保護デバイスがＳＡＣＫオプションをサポートしない場合、保護デバイスは、三方向ハンドシェイクフェーズにおいてハンドシェイクパケットからＳＡＣＫオプションを削除し、以下のステップＳ５３０ｇ’に従って、肯定応答パケットを処理する。保護デバイスがＳＡＣＫオプションをサポートする場合、保護デバイスは、三方向ハンドシェイクフェーズにおいてハンドシェイクパケット内のＳＡＣＫオプションを予約し、以下のステップＳ５３０ｈ’に従って、肯定応答パケットを処理する。

【0244】

ステップＳ５３０ｇ’：保護デバイスが、肯定応答パケットについてＳＡＣＫオプションをサポートしない場合、保護デバイスは、肯定応答パケットのＡＣＫ番号を決定する。肯定応答パケットのＡＣＫ番号が、記録された最大Ｓｅｑ番号以下ある場合、保護デバイスは、ＴＣＰ／ＩＰプロトコルスタックモジュールへ肯定応答パケットを送る。肯定応答パケットのＡＣＫ番号が、記録された最大Ｓｅｑ番号より大きい場合、保護デバイスは、ステップＳ５３０ｉへジャンプし、フローモードを使用して、肯定応答パケットを処理する。

【0245】

ＴＣＰ／ＩＰプロトコルスタックモジュールへ肯定応答パケットを送ることと、フローモードを使用して肯定応答パケットを処理することとは、２つの異なるアクションである。

【0246】

保護デバイスが、フローモードを使用して、肯定応答パケットを処理する場合、保護デバイスは、ピア側へ肯定応答パケットを転送する。例えば、肯定応答パケットがサーバからのものである場合、保護デバイスは、クライアントへ肯定応答パケットを転送する。肯定応答パケットがクライアントからのものである場合、保護デバイスは、サーバへ肯定応答パケットを転送する。

【0247】

保護デバイスが、ＴＣＰ／ＩＰプロトコルスタックモジュールへ肯定応答パケットを送る場合、保護デバイスは、ピア側へ肯定応答パケットを転送しない。代わりに、ＴＣＰ／ＩＰプロトコルスタックモジュールは、肯定応答パケットを処理する。例えば、肯定応答パケットがサーバからのものである場合、保護デバイスは、クライアントへ肯定応答パケットを転送しない。代わりに、ＴＣＰ／ＩＰプロトコルスタックモジュールは、シミュレーションされるサーバとして動作して、肯定応答パケットを処理する。

【0248】

ステップＳ５３０ｈ’：保護デバイスがＳＡＣＫオプションをサポートする場合、保護デバイスは、ＳＡＣＫオプションにおける範囲および記録された最大Ｓｅｑ番号に基づいて、ＴＣＰに従って処理を行う。肯定応答パケットが、ＴＣＰ／ＩＰプロトコルスタックによって送られたデータパケットについての肯定応答パケットである場合、保護デバイスは、処理のためにＴＣＰ／ＩＰプロトコルスタックへ肯定応答パケットを送る。肯定応答パケットが、フローモードを使用して転送されたデータパケットについての肯定応答パケットである場合、保護デバイスは、フローモードを使用して肯定応答パケットを処理して、処理のためにピアデバイスへ肯定応答パケットを送る。さらに、ＳＡＣＫオプションが、ＴＣＰ／ＩＰプロトコルスタックによって送られたデータと、フローモードを使用して転送されたデータとの両方を肯定応答する場合、保護デバイスは、ＴＣＰ／ＩＰプロトコルスタックによる処理とフローモードを使用した処理とのために肯定応答パケットを分割する。

【0249】

例えば、ソース側は、７つのパケットを連続して送り、７つのパケットは、それぞれパケット１、パケット２、パケット３、パケット４、パケット５、パケット６、およびパケット７である。パケット４は失われ、パケット１、パケット２、パケット３、パケット５、パケット６、およびパケット７は、宛先側へ成功裡に送信される。ソース側と宛先側とが、三方向ハンドシェイク期間中にＳＡＣＫオプションを使用することをネゴシエートする場合、宛先側は、ＳＡＣＫオプションを使用して、パケット４が失われたことを示すことができる。具体的には、宛先側によって返される肯定応答パケットは、ＡＣＫ番号とＳＡＣＫオプションとを含む。ＡＣＫ番号は、パケット１、パケット２、およびパケット３が受信済みであることを示すために使用され、ＳＡＣＫオプション内のシーケンス番号は、パケット５、パケット６、およびパケット７が受信済みであることを示すために使用される。したがって、送り側は、ＳＡＣＫオプション内のＡＣＫ番号およびシーケンス番号に基づいて、パケット４が失われたことを知ることができる。保護デバイスがプロキシモードからフローモードに切り換えるシナリオを参照すると、例えば、保護デバイスは、プロキシモードを使用して、パケット１、パケット２、パケット３、パケット４、およびパケット５を受信し、保護デバイスは、保護デバイスのＴＣＰ／ＩＰプロトコルスタックを使用することによって、パケット１、パケット２、パケット３、パケット４、およびパケット５を送る。フローモードに切り替えることを決定した後に、保護デバイスは、続いてパケット６およびパケット７を受信する。保護デバイスは、フローモードを使用して、パケット６およびパケット７を転送する。保護デバイス、クライアント、およびサーバが全て、ＳＡＣＫオプションを使用する場合、保護デバイスは、肯定応答パケットを受信した場合に、肯定応答パケットを分割する。保護デバイスは、保護デバイスのＴＣＰ／ＩＰプロトコルスタックを使用することによって、肯定応答パケット内のパケット１、パケット２、パケット３、パケット４、およびパケット５に対応するコンテンツを処理する。例えば、パケット４が失われた場合、保護デバイスは、保護デバイスのＴＣＰ／ＩＰプロトコルスタックを使用することによって、パケット４を再送信する。肯定応答パケット内のパケット６およびパケット７に対応するコンテンツについては、保護デバイスは、フローモードを使用して、コンテンツを処理するようにソース側に通知する。

【0250】

ステップＳ５３０ｉ’：ＴＣＰ／ＩＰプロトコルスタックモジュール内の現在のＴＣＰセッションについての送られたパケットキュー内にバッファされた全てのデータパケットが送られ、これらのデータパケットについての肯定応答パケットを保護デバイスが受信済みである場合、保護デバイスは、ＴＣＰ／ＩＰプロトコルスタックモジュールの関連するリソースを削除する。保護デバイスは、フローモードを使用して、ＴＣＰセッションにおける全ての後続のパケットを処理する。

【0251】

上記に提供されるシステムアーキテクチャにおいては、カスタマイズされたＴＣＰ／ＩＰプロトコルスタックが使用されており、その結果、プロキシモードからフローモードへの適応的な切り替えが、データパケット交換フェーズにおけるデータパケット交換結果に基づいて実装されるだけでなく、データパケットがプロキシモードを使用してバッファされた複雑な場合もサポートされ、それによって、解決策の可用性を改善する。

【0252】

図１０は、保護デバイスの可能な構造の概略図である。

【0253】

例えば、図１０に示される保護デバイス８００は、図５に示される方法５００における保護デバイスの機能を実装する。いくつかの実施形態において、図１０に示される保護デバイス８００は、図７に示される方法７００における保護デバイスの機能を実装するようにさらに構成される。

【0254】

いくつかの実施形態において、図１０に示される保護デバイス８００は、図３、図８、または図９における保護デバイス１３である。例えば、図１０に示される保護デバイス８００内の処理ユニット８０２は、図８または図９におけるフローモード処理モジュール１３１１、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１、フローモード処理モジュール１３１２、およびＴＣＰ／ＩＰプロトコルスタックモジュール１３３２のうちの少なくとも１つを使用することによって実装される。

【0255】

図１０に示されるように、保護デバイス８００は、取得ユニット８０１と処理ユニット８０２とを含む。任意選択で、保護デバイス８００は、送信ユニットをさらに含む。保護デバイス８００内のユニットの全部または一部は、ソフトウェア、ハードウェア、ファームウェア、または、これらの任意の組合せを使用することによって実装される。保護デバイス８００内のユニットは、方法５００または方法７００における保護デバイスの対応する機能を行うように別々に構成される。具体的には、取得ユニット８０１は、Ｓ５１０を行う際に保護デバイス８００をサポートするように構成される。処理ユニット８０２は、Ｓ５２０およびＳ５３０を行う際に保護デバイス８００をサポートするように構成される。いくつかの実施形態において、処理ユニット８０２は、Ｓ７２０およびＳ７５０を行う際に保護デバイス８００をサポートするようにさらに構成される。送信ユニットは、Ｓ７３０およびＳ７８０を行う際に保護デバイス８００をサポートするように構成される。

【0256】

本出願のこの実施形態において、ユニットへの分割は、例であり、単なる論理的な機能分割である。実際の実装期間中には、別の分割手法が任意選択で使用されてよい。

【0257】

いくつかの実施形態において、保護デバイス８００内のユニットは、１つのユニットへ一体化される。例えば、保護デバイス８００内のユニットは、同じチップ上に一体化される。チップは、処理回路、ならびに処理回路に内部で接続され、処理回路と通信する入力インターフェースおよび出力インターフェースを含む。処理ユニット８０２は、チップ内の処理回路を使用することによって実装される。取得ユニット８０１は、チップ内の入力インターフェースを使用することによって実装される。送信ユニットは、チップ内の出力インターフェースを使用することによって実装される。例えば、チップは、１つまたは複数のフィールドプログラマブルゲートアレイ（ｆｉｅｌｄ－ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ、ＦＰＧＡ）、プログラマブル論理デバイス（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅ、ＰＬＤ）、コントローラ、状態機械、ゲートロジック、ディスクリートハードウェア構成要素、任意の他の適切な回路、または本出願において説明される様々な機能を行うことができる回路の任意の組み合わせを使用することによって実装される。

【0258】

いくつかの他の実施形態において、保護デバイス８００の各ユニットは、物理的に単独で存在する。いくつかの他の実施形態において、保護デバイス８００のいくつかのユニットは、物理的に単独で存在し、その他のユニットは、１つのユニットへ一体化される。例えば、いくつかの実施形態において、保護デバイス８００内の取得ユニット８０１および送信ユニットは、同じハードウェア（通信インターフェースなど）へ一体化される。いくつかの実施形態において、異なるユニットの一体化は、ハードウェアの形式で実装され、すなわち、異なるユニットが、同じハードウェアに対応する。別の例として、異なるユニットの一体化は、ソフトウェアユニットの形式で実装される。

【0259】

保護デバイス８００が、ハードウェアを使用することによって実装される場合、保護デバイス８００内の処理ユニット８０２は、例えば、図４に示される保護デバイス２００内のプロセッサ２０１を使用することによって実装される。保護デバイス８００内の取得ユニット８０１および送信ユニットは、例えば、図４に示される保護デバイス２００内の通信インターフェース２０４を使用することによって実装される。

【0260】

保護デバイス８００が、ソフトウェアを使用することによって実装される場合、保護デバイス８００内の各ユニットは、例えば、保護デバイス２００内のプロセッサ２０１が、メモリ２０３に記憶されたプログラムコード２１０を読み取った後に生成されるソフトウェアである。例えば、保護デバイス８００は、仮想化デバイスである。仮想化デバイスは、バーチャルマシン、コンテナ、およびポッドのうちの少なくとも１つを含むが、これらに限定されない。いくつかの実施形態において、保護デバイス８００は、バーチャルマシンの形式でハードウェアデバイス（例えば、物理サーバ）上に配置される。例えば、保護デバイス８００は、ネットワーク機能仮想化（ｎｅｔｗｏｒｋ ｆｕｎｃｔｉｏｎｓ ｖｉｒｔｕａｌｉｚａｔｉｏｎ、ＮＦＶ）技術と組み合わせて汎用物理サーバに基づいて実装される。バーチャルマシンが実装のために使用される場合、保護デバイス８００は、例えば、バーチャルホスト、仮想ルータ、または仮想スイッチである。本出願を読むことによって、当業者は、ＮＦＶ技術を参照した仮想化を通じて、汎用物理サーバ上の保護デバイス８００を取得し得る。いくつかの他の実施形態において、保護デバイス８００は、コンテナ（例えば、ドッカーコンテナ）の形式でハードウェアデバイス上に配置される。例えば、保護デバイス８００が前述の方法実施形態を行う手順は、イメージファイル内にパッケージ化され、ハードウェアデバイスは、イメージファイルを稼働させることによって保護デバイス８００を作成する。いくつかの他の実施形態において、保護デバイス８００は、ポッドの形式でハードウェアデバイス上に配置される。ポッドは、複数のコンテナを含み、各コンテナは、保護デバイス８００内の１つまたは複数のユニットを実装するように構成される。

【0261】

当業者は、本明細書において開示される実施形態において説明される例と組み合わせて、方法ステップおよびユニットが、電子ハードウェア、コンピュータソフトウェア、または、これらの組み合わせによって実行されることが可能であることを認識し得る。ハードウェアとソフトウェアとの間の互換性を明確に説明するために、前述の記載は、各実施形態のステップおよび構成を機能に従って一般に説明してきた。機能がハードウェアによって行われるか、またはソフトウェアによって行われるかは、技術的解決策の特定の用途および設計制約に依存する。当業者は、特定の用途ごとに、説明される機能を実装するために異なる方法を使用し得るが、その実装が本出願の範囲を越えると見なされるべきではない。

【0262】

好都合で簡単な説明の目的のために、前述の説明されるシステム、装置、およびユニットの詳細な動作処理については、前述の方法実施形態における対応する処理を参照することが、当業者によって明確に理解され得る。詳細は、ここでは再度説明されない。

【0263】

本出願において、「第１の」および「第２の」などの用語は、基本的に同じ機能を有する同じアイテムまたは同様のアイテムを区別するために使用されている。「第１の」と「第２の」との間に論理的または時系列的な依存性はなく、数量および実行シーケンスは限定されないことが理解されるべきである。例えば、様々な例の範囲から逸脱せずに、第１のデータパケットは、第２のデータパケットと称されてよく、同様に、第２のデータパケットは、第１のデータパケットと称されてよい。第１のデータパケットと第２のデータパケットとの両方が、データパケットであってよく、いくつかの場合においては、別々の異なるデータパケットであってよい。

【0264】

本出願における「少なくとも１つの」という用語は、１つまたは複数を意味する。

【0265】

前述の実施形態の全部または一部は、ソフトウェア、ハードウェア、ファームウェア、または、これらの任意の組合せによって実装され得る。ソフトウェアが、実施形態を実装するために使用される場合、実施形態は、コンピュータプログラム製品の形式で完全にまたは部分的に実装され得る。コンピュータプログラム製品は、１つまたは複数のコンピュータプログラム命令を含む。コンピュータプログラム命令が、コンピュータ上にロードされ、実行される場合、本出願の実施形態による手順または機能の全部または一部が生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、または他のプログラム可能な装置であってよい。

【0266】

コンピュータ命令は、コンピュータ可読記憶媒体に記憶されてよく、またはコンピュータ可読記憶媒体から別のコンピュータ可読記憶媒体へ送信されてよい。例えば、コンピュータプログラム命令は、ウェブサイト、コンピュータ、サーバ、またはデータセンタから、別のウェブサイト、コンピュータ、サーバ、またはデータセンタへ、有線手法または無線手法で送信され得る。コンピュータ可読記憶媒体は、コンピュータによってアクセス可能な任意の使用可能な媒体、または、１つもしくは複数の使用可能な媒体を一体化したサーバまたはデータセンタなどのデータ記憶デバイスであってよい。使用可能な媒体は、磁気媒体（例えば、フロッピーディスク、ハードディスク、または磁気テープ）、光学媒体（例えば、デジタルビデオディスク（ｄｉｇｉｔａｌ ｖｉｄｅｏ ｄｉｓｃ、ＤＶＤ））、半導体媒体（例えば、ソリッドステートドライブ）等であってよい。前述の記憶媒体は、プログラムコードを記憶することができる任意の媒体、例えば、ＵＳＢフラッシュドライブ、リムーバブルハードディスク、読み出し専用メモリ（ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ、ＲＯＭ）、ランダムアクセスメモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ、ＲＡＭ）、磁気ディスク、または光ディスクなどを含む。

【0267】

前述の実施形態は、本出願を限定するためではなく、単に本出願の技術的解決策を説明するために意図されている。本出願は、前述の実施形態を参照して詳細に説明されているが、当業者は、本出願の実施形態の技術的解決策の範囲から逸脱せずに、前述の実施形態において説明される技術的解決策に対する変形を依然として行ってよく、または、そのいくつかの技術的特徴に対して均等な置換を行ってよいことを理解するべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【手続補正書】

【提出日】2023-05-30

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

ネットワークセキュリティ保護方法であって、前記方法は、
保護デバイスによって、第１のモードを使用して、伝送制御プロトコルＴＣＰセッションにおけるデータパケットに対してセキュリティ検出を行う処理において、前記ＴＣＰセッションにおける第１のデータパケットを取得するステップであって、前記ＴＣＰセッションは、クライアントデバイスとサーバとの間のセッションであり、前記保護デバイスは、前記クライアントデバイスと前記サーバとの間に配置され、前記第１のモードは、前記保護デバイスによってサポートされる検出モードのセット内のモードである、ステップと、
前記保護デバイスによって、前記第１のデータパケットのアプリケーション層データに基づいて、第２のモードに切り替えることを決定するステップであって、前記第２のモードは、前記検出モードのセット内の前記第１のモード以外のモードである、ステップと、
前記保護デバイスによって、前記第２のモードに切り替え、前記第２のモードを使用して、前記ＴＣＰセッションにおける後続のパケットに対してセキュリティ検出を行うステップと
を含む、方法。

【請求項2】

前記第１のモードは、フローモードであり、前記第２のモードは、プロキシモードであり、前記保護デバイスによって、前記第１のデータパケットのアプリケーション層データに基づいて、第２のモードに切り替えることを決定する前記ステップは、
前記保護デバイスによって、前記アプリケーション層データに基づいて、前記第１のデータパケットのアプリケーション層プロトコルタイプを識別するステップと、
前記保護デバイスによって、アプリケーション層プロトコルタイプと検出モードとの間の対応に基づいて、前記第１のデータパケットの前記アプリケーション層プロトコルタイプが前記プロキシモードに対応すると決定するステップと、
前記保護デバイスによって、切り替えられるべき前記第２のモードが、前記第１のデータパケットの前記アプリケーション層プロトコルタイプに対応する前記プロキシモードであると決定するステップと
を含む請求項１に記載の方法。

【請求項3】

前記第１のモードは、プロキシモードであり、前記第２のモードは、フローモードであり、前記セキュリティ検出は、アンチウイルスＡＶ検出であり、前記保護デバイスによって、前記第１のデータパケットのアプリケーション層データに基づいて、第２のモードに切り替えることを決定する前記ステップは、
前記保護デバイスによって、前記第１のデータパケットの前記アプリケーション層データに対して行われるＡＶ検出の結果が、ウィルスはないというものである場合、前記保護デバイスによって、切り替えられるべき前記第２のモードが前記フローモードであると決定するステップ
を含む請求項１に記載の方法。

【請求項4】

前記第１のモードは、プロキシモードであり、前記第２のモードは、フローモードであり、前記保護デバイスによって、前記第１のデータパケットのアプリケーション層データに基づいて、第２のモードに切り替えることを決定する前記ステップは、
前記第１のデータパケットの前記アプリケーション層データが、前記クライアントデバイスおよび前記サーバが前記ＴＣＰセッションにおいて暗号化された通信を行おうとしていることを示す場合、前記保護デバイスによって、切り替えられるべき前記第２のモードが前記フローモードであると決定するステップ
を含む請求項１に記載の方法。

【請求項5】

保護デバイスによって、ＴＣＰセッションにおいて第１のデータパケットを取得する前記ステップの前に、前記方法は、
前記保護デバイスによって、前記クライアントデバイスと前記サーバとの間で送信される第１のハンドシェイクパケットを取得するステップであって、前記第１のハンドシェイクパケットは、前記ＴＣＰセッションを作成するために使用され、前記第１のハンドシェイクパケットは、第１のオプションおよび第２のオプションを備え、前記第１のオプションは、前記保護デバイスによってサポートされるオプションであり、前記第２のオプションは、前記保護デバイスによってサポートされないオプションである、ステップと、
前記保護デバイスによって、前記第１のハンドシェイクパケットから前記第２のオプションを削除して、第２のハンドシェイクパケットを取得するステップと、
前記保護デバイスによって、前記第１のハンドシェイクパケットの宛先デバイスへ前記第２のハンドシェイクパケットを送るステップと
をさらに含む請求項１に記載の方法。

【請求項6】

前記第１のモードは、フローモードであり、前記第２のモードは、プロキシモードであり、前記保護デバイスによって、前記第２のモードに切り換える前記ステップは、
前記保護デバイスによって、前記第１のオプションに基づいて、前記ＴＣＰセッションにおいて第２のデータパケットについての肯定応答パケットを生成するステップであって、前記第２のデータパケットは、前記第１のモードを使用して、前記保護デバイスによって受信され、バッファされたパケットである、ステップと、
前記保護デバイスによって、前記第２のデータパケットのソースデバイスへ前記第２のデータパケットについての前記肯定応答パケットを送るステップであって、前記第２のデータパケットの前記ソースデバイスは、前記クライアントデバイスまたは前記サーバである、ステップと
を含む請求項５に記載の方法。

【請求項7】

前記第１のモードは、フローモードであり、前記第２のモードは、プロキシモードであり、前記保護デバイスによって、前記第２のモードに切り替える前記ステップは、
前記ＴＣＰセッションにおける第３のデータパケットが再送信条件を満たす場合、前記保護デバイスによって、前記第１のオプションに基づいて、前記第３のデータパケットの宛先デバイスへ前記第３のデータパケットを再送するステップであって、前記第３のデータパケットは、前記第１のモードを使用して、前記保護デバイスによって送られたパケットであり、前記第３のデータパケットの前記宛先デバイスは、前記クライアントデバイスまたは前記サーバである、ステップ
を含む請求項５に記載の方法。

【請求項8】

前記第１のモードは、プロキシモードであり、前記第２のモードは、フローモードであり、前記保護デバイスによって、前記第２のモードに切り替える前記ステップは、
前記ＴＣＰセッションにおける第４のデータパケットが再送信条件を満たす場合、前記保護デバイスによって、前記第１のオプションに基づいて、前記第４のデータパケットの宛先デバイスへ前記第４のデータパケットを再送するステップであって、前記第４のデータパケットは、前記第１のモードを使用して、前記保護デバイスによって送られたパケットであり、前記第４のデータパケットの前記宛先デバイスは、前記クライアントデバイスまたは前記サーバである、ステップ
を含む請求項５に記載の方法。

【請求項9】

前記第１のモードは、プロキシモードであり、前記第２のモードは、フローモードであり、前記保護デバイスによって、前記第２のモードに切り替える前記ステップは、
前記保護デバイスによって、前記ＴＣＰセッションにおいて第５のデータパケットを検出して、第６のデータパケットを取得するステップであって、前記第５のデータパケットは、前記第１のモードを使用して、前記保護デバイスによって受信されたパケットであり、前記保護デバイスは、前記第１のオプションに基づいて、前記第５のデータパケットを構文解析した後に、前記第５のデータパケットのソースデバイスへ前記第５のデータパケットについての肯定応答パケットを送っており、前記第５のデータパケットの前記ソースデバイスは、前記クライアントデバイスまたは前記サーバである、ステップと、
前記保護デバイスによって、前記第１のオプションに基づいて、前記第５のデータパケットの宛先デバイスへ前記第６のデータパケットを送るステップであって、前記第５のデータパケットの前記ソースデバイスが前記クライアントデバイスである場合、前記第５のデータパケットの前記宛先デバイスは、前記サーバであり、または、前記第５のデータパケットの前記ソースデバイスが前記サーバである場合、前記第５のデータパケットの前記宛先デバイスは、前記クライアントデバイスである、ステップ
を含む請求項５に記載の方法。

【請求項10】

前記第６のデータパケットが再送信条件を満たす場合、前記保護デバイスによって、前記第１のオプションに基づいて、前記第５のデータパケットの前記宛先デバイスへ前記第６のデータパケットを再送するステップをさらに含む請求項９に記載の方法。

【請求項11】

前記再送信条件は、前記保護デバイスが、データパケットについての肯定応答パケットを受信していないことを含み、または
前記第１のオプションは、選択的な肯定応答ＳＡＣＫオプションであり、前記再送信条件は、前記保護デバイスが、データパケットの宛先デバイスからのＳＡＣＫオプション内の情報に基づいて、前記データパケットにおいてパケット損失が発生したと決定することを含む請求項７、８、または１０に記載の方法。

【請求項12】

前記第１のハンドシェイクパケットは、前記クライアントデバイスからの同期シーケンス番号ＳＹＮパケットであり、前記第１のハンドシェイクパケットの前記宛先デバイスは、前記サーバであり、または
前記第１のハンドシェイクパケットは、前記サーバからの同期シーケンス番号肯定応答ＳＹＮ ＡＣＫパケットであり、前記第１のハンドシェイクパケットの前記宛先デバイスは、前記クライアントデバイスである請求項５乃至１０のいずれか一項に記載の方法。

【請求項13】

前記検出モードのセットは、パケットフィルタリングモード、フローモード、またはプロキシモードを含む請求項１乃至１０のいずれか一項に記載の方法。

【請求項14】

保護デバイスであって、前記保護デバイスは、クライアントデバイスとサーバとの間に配置され、前記保護デバイスは、
第１のモードを使用して、伝送制御プロトコルＴＣＰセッションにおいてデータパケットに対してセキュリティ検出を行うように構成された処理ユニットであって、前記第１のモードは、前記保護デバイスによってサポートされる検出モードのセット内のモードである、処理ユニットと、
前記処理ユニットが、前記第１のモードを使用して、セキュリティ検出を行う処理において、前記ＴＣＰセッションにおいて第１のデータパケットを取得するように構成された取得ユニットであって、前記ＴＣＰセッションは、前記クライアントデバイスと前記サーバとの間のセッションである、取得ユニットと
を備え、
前記処理ユニットは、前記第１のデータパケットのアプリケーション層データに基づいて、第２のモードに切り替えることを決定するようにさらに構成され、前記第２のモードは、前記検出モードのセット内の前記第１のモード以外のモードであり、
前記処理ユニットは、前記第２のモードに切り替え、前記第２のモードを使用して、前記ＴＣＰセッションにおける後続のパケットに対してセキュリティ検出を行うようにさらに構成される、保護デバイス。

【請求項15】

前記第１のモードは、フローモードであり、前記第２のモードは、プロキシモードであり、前記処理ユニットは、前記アプリケーション層データに基づいて、前記第１のデータパケットのアプリケーション層プロトコルタイプを識別し、アプリケーション層プロトコルタイプと検出モードとの間の対応に基づいて、前記第１のデータパケットの前記アプリケーション層プロトコルタイプが前記プロキシモードに対応すると決定し、切り替えられるべき前記第２のモードが、前記第１のデータパケットの前記アプリケーション層プロトコルタイプに対応する前記プロキシモードであると決定するように構成される請求項１４に記載の保護デバイス。

【請求項16】

前記第１のモードは、プロキシモードであり、前記第２のモードは、フローモードであり、前記セキュリティ検出は、アンチウイルスＡＶ検出であり、前記処理ユニットは、前記第１のデータパケットの前記アプリケーション層データに対して行われるＡＶ検出の結果が、ウィルスはないというものである場合、切り替えられるべき前記第２のモードが前記フローモードであると決定するように構成される請求項１４に記載の保護デバイス。

【請求項17】

前記第１のモードは、プロキシモードであり、前記第２のモードは、フローモードであり、前記処理ユニットは、前記第１のデータパケットの前記アプリケーション層データが、前記クライアントデバイスおよび前記サーバが前記ＴＣＰセッションにおいて暗号化された通信を行おうとしていることを示す場合、切り替えられるべき前記第２のモードが前記フローモードであると決定するように構成される請求項１４に記載の保護デバイス。

【請求項18】

前記取得ユニットは、前記クライアントデバイスと前記サーバとの間で送信される第１のハンドシェイクパケットを取得するようにさらに構成され、前記第１のハンドシェイクパケットは、前記ＴＣＰセッションを作成するために使用され、前記第１のハンドシェイクパケットは、第１のオプションおよび第２のオプションを含み、前記第１のオプションは、前記保護デバイスによってサポートされるオプションであり、前記第２のオプションは、前記保護デバイスによってサポートされないオプションであり、
前記処理ユニットは、前記第１のハンドシェイクパケットから第２のオプションを削除して、第２のハンドシェイクパケットを取得するようにさらに構成され、
前記保護デバイスは、送信ユニットをさらに備え、前記送信ユニットは、前記第１のハンドシェイクパケットの宛先デバイスへ前記第２のハンドシェイクパケットを送るように構成される請求項１４乃至１７のいずれか一項に記載の保護デバイス。

【請求項19】

前記第１のモードは、フローモードであり、前記第２のモードは、プロキシモードであり、前記処理ユニットは、前記第１のオプションに基づいて、前記ＴＣＰセッションにおける第２のデータパケットについての肯定応答パケットを生成するように構成され、前記第２のデータパケットは、前記第１のモードを使用して、前記保護デバイスによって受信され、バッファされたパケットであり、
前記送信ユニットは、前記第２のデータパケットのソースデバイスへ前記第２のデータパケットについての前記肯定応答パケットを送るように構成され、前記第２のデータパケットの前記ソースデバイスは、前記クライアントデバイスまたは前記サーバである請求項１８に記載の保護デバイス。

【請求項20】

前記第１のモードは、フローモードであり、前記第２のモードは、プロキシモードであり、前記送信ユニットは、前記ＴＣＰセッションにおける第３のデータパケットが再送信条件を満たす場合、前記第１のオプションに基づいて、前記第３のデータパケットの宛先デバイスへ前記第３のデータパケットを再送するように構成され、前記第３のデータパケットは、前記第１のモードを使用して、前記保護デバイスによって送られたパケットであり、前記第３のデータパケットの前記宛先デバイスは、前記クライアントデバイスまたは前記サーバである請求項１８に記載の保護デバイス。

【請求項21】

前記第１のモードは、プロキシモードであり、前記第２のモードは、フローモードであり、前記送信ユニットは、前記ＴＣＰセッションにおける第４のデータパケットが再送信条件を満たす場合、前記第１のオプションに基づいて、前記第４のデータパケットの宛先デバイスへ前記第４のデータパケットを再送するように構成され、前記第４のデータパケットは、前記第１のモードを使用して、前記保護デバイスによって送られたパケットであり、前記第４のデータパケットの前記宛先デバイスは、前記クライアントデバイスまたは前記サーバである請求項１８に記載の保護デバイス。

【請求項22】

前記第１のモードは、プロキシモードであり、前記第２のモードは、フローモードであり、前記処理ユニットは、前記ＴＣＰセッションにおける第５のデータパケットを検出して、第６のデータパケットを取得するように構成され、前記第５のデータパケットは、前記第１のモードを使用して、前記保護デバイスによって受信されたパケットであり、前記保護デバイスは、前記第１のオプションに基づいて、前記第５のデータパケットを構文解析した後に、前記第５のデータパケットのソースデバイスへ前記第５のデータパケットについての肯定応答パケットを送っており、前記第５のデータパケットの前記ソースデバイスは、前記クライアントデバイスまたは前記サーバであり、
前記送信ユニットは、前記第１のオプションに基づいて、前記第５のデータパケットの宛先デバイスへ前記第６のデータパケットを送るように構成され、前記第５のデータパケットの前記ソースデバイスが前記クライアントデバイスである場合、前記第５のデータパケットの前記宛先デバイスは、前記サーバであり、または、前記第５のデータパケットの前記ソースデバイスが前記サーバである場合、前記第５のデータパケットの前記宛先デバイスは、前記クライアントデバイスである請求項１８に記載の保護デバイス。

【請求項23】

前記送信ユニットは、前記第６のデータパケットが再送信条件を満たす場合、前記第１のオプションに基づいて、前記第５のデータパケットの前記宛先デバイスへ前記第６のデータパケットを再送するように構成される請求項２２に記載の保護デバイス。

【請求項24】

保護デバイスであって、前記保護デバイスは、プロセッサと通信インターフェースとを備え、前記プロセッサは、プログラムコードを実行して、前記保護デバイスが、請求項１乃至９のいずれか一項に記載の方法を行うことを可能にするように構成され、前記通信インターフェースは、パケットを受信するように、または送るように構成される、保護デバイス。

【請求項25】

コンピュータプログラムであって、前記コンピュータプログラムは、１つまたは複数のコンピュータプログラム命令を備え、前記コンピュータプログラム命令が、コンピュータによってロードされ、実行される場合、前記コンピュータは、請求項１乃至９のいずれか一項に記載のネットワークセキュリティ保護方法を行うことを可能にされる、コンピュータプログラム。

【手続補正2】

【補正対象書類名】明細書

【補正対象項目名】００６９

【補正方法】変更

【補正の内容】

【0069】

いくつかの実施形態において、適用シナリオ１０は、多数のクライアントデバイス１１を含む。簡潔さのために、１つのクライアントデバイス１１が、図３における説明のための例として使用されている。

【手続補正3】

【補正対象書類名】明細書

【補正対象項目名】０１０５

【補正方法】変更

【補正の内容】

【0105】

任意選択で、方法５００におけるクライアントデバイス、サーバ、および保護デバイスのネットワーク配置シナリオが、図３に示される。方法５００におけるクライアントデバイスは、図３におけるクライアントデバイス１１であり、方法５００におけるサーバは、適用シナリオ１０におけるサーバ１２であり、方法５００における保護デバイスは、図３における保護デバイス１３である。

【手続補正4】

【補正対象書類名】明細書

【補正対象項目名】０１２５

【補正方法】変更

【補正の内容】

【0125】

別の例として、アプリケーション層プロトコルは、ＦＴＰであり、ＦＴＰにおけるログインコマンドは、ＵＳＥＲコマンドを含む。ＴＰに対応するキーワードは、例えば、ＵＳＥＲコマンド内で搬送されるキーワードである。具体的には、ＵＳＥＲコマンド内で搬送されるキーワードは、ＵＳＥＲである。ＵＳＥＲコマンドは、「ＵＳＥＲ ｘｘｘ」として簡単に表現され得る。「ＵＳＥＲ ｘｘｘ」における「ｘｘｘ」は、ＵＳＥＲコマンドに含まれるパラメータであり、パラメータは、通常、ユーザ名を意味する。この場合において、保護デバイスによって受信されたアプリケーション層データが、ＵＳＥＲを含む場合、保護デバイスは、アプリケーション層プロトコルのタイプがＦＴＰであると識別し得る。もちろん、ＵＳＥＲコマンドは、ＦＴＰにおけるログインコマンドの例にすぎず、ＵＳＥＲは、ＦＴＰに対応するキーワードの例にすぎない。ＵＳＥＲコマンドは、ＦＴＰにおける別のログインコマンド、例えば、ｐａｓｓコマンドまたはｐａｓｖコマンドに置換され得る。ＦＴＰに対応するキーワードは、別のログインコマンドにおけるキーワード、例えば、ｐａｓｓまたはｐａｓｖに置換され得る。ＦＴＰを識別するために使用されるキーワードは、この実施形態において限定されない。

【手続補正5】

【補正対象書類名】明細書

【補正対象項目名】０１５８

【補正方法】変更

【補正の内容】

【0158】

クライアントとサーバとの間のハンドシェイクが完了した後に、クライアントおよびサーバが、データ送信フェーズにおいてデータパケットを交換する場合、クライアントおよびサーバは、ハンドシェイクを通じてネゴシエートされるパケットシーケンス番号（Ｓｅｑ）およびＭＳＳを使用することによって、セグメント内のデータを連続して送る。各回にクライアントまたはサーバによって送られるデータの量の最大値は、ピアパーティによってアドバタイズされるウィンドウサイズである。レシーバは、ＡＣＫパケットを使用することによって、受信されたデータパケットを肯定応答し、レシーバによって受信されることが可能なデータの最大データ長を更新する。また、ネットワーク内の異常なパケット損失、および過度に速い送信によって引き起こされたパケット損失を処理するために、一連のタイマおよび輻輳アルゴリズムが、ＴＣＰにおいてさらに必要とされる。

【手続補正6】

【補正対象書類名】明細書

【補正対象項目名】０２３７

【補正方法】変更

【補正の内容】

【0237】

具体的には、ＴＣＰ／ＩＰプロトコルスタックモジュールが、順不同なデータパケットについての肯定応答パケットを返さないので、順不同なデータパケットは確実に破棄されることが可能である。順不同なデータパケットは、データパケットのＳｅｑ番号が連続しないことを意味する。例えば、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１内の受信されたパケットキュー１３１１１は、そのＳｅｑ番号が１から５であるデータパケット、および、そのＳｅｑ番号が８から１０であるデータパケットをバッファするが、ＴＣＰ／ＩＰプロトコルスタックモジュール１３３１内の受信されたパケットキュー１３１１１は、そのＳｅｑ番号が６および７であるデータパケットを含有しない。この場合において、そのＳｅｑ番号が８から１０であるデータパケットは、順不同なデータパケットである。ステップＳ５３０ｂ’を行う場合、ＴＣＰ制御層は、そのＳｅｑ番号が８から１０であるデータパケットを破棄する。

【手続補正7】

【補正対象書類名】明細書

【補正対象項目名】０２４４

【補正方法】変更

【補正の内容】

【0244】

ステップＳ５３０ｇ’：保護デバイスが、肯定応答パケットについてＳＡＣＫオプションをサポートしない場合、保護デバイスは、肯定応答パケットのＡＣＫ番号を決定する。肯定応答パケットのＡＣＫ番号が、記録された最大Ｓｅｑ番号以下ある場合、保護デバイスは、ＴＣＰ／ＩＰプロトコルスタックモジュールへ肯定応答パケットを送る。肯定応答パケットのＡＣＫ番号が、記録された最大Ｓｅｑ番号より大きい場合、保護デバイスは、ステップＳ５３０ｉ’へジャンプし、フローモードを使用して、肯定応答パケットを処理する。

【国際調査報告】