TCPセッション

デフォルトでは、TCP SYNチェックとシーケンスチェックオプションは、すべてのTCPセッションで有効になっています。Junosオペレーティングシステム(Junos OS)は、TCPセッション中に以下の操作を実行します。

• セッションの最初のパケットでSYNフラグを確認し、セッションの開始を試みる非SYNフラグを持つTCPセグメントを拒否します。

• ステートフルインスペクション中にTCPシーケンス番号を検証します。

ポリシーごとのTCPセッションチェック機能により、各ポリシーのSYNおよびシーケンスチェックを設定できます。現在、TCPオプションフラグであるno-sequence-checkとno-syn-checkは、サービスゲートウェイの動作を制御するためにグローバルレベルで使用できます。ポリシーごとのTCPオプションをサポートするには、以下の2つのオプションがあります。

• sequence-check-required: sequence-check-required 値は、グローバル値 no-sequence-check を上書きします。

• syn-check-required: syn-check-required 値は、グローバル値 no-syn-check を上書きします。

ポリシーごとのTCPオプションを設定するには、それぞれのグローバルオプションをオフにする必要があります。それ以外の場合、コミットチェックは失敗します。グローバルTCPオプションが無効で、SYNフラッド保護が最初のパケットを許可する場合、ポリシーごとのTCPオプションがSYNおよび/またはシーケンスチェックを実行するかどうかを制御します。

注:

• ポリシーごとの syn-check-required オプションは、 set security flow tcp-session no-syn-check-in-tunnel CLIコマンドの動作を上書きしません。

• グローバルSYNチェックを無効にすると、デバイスの有効性が低下します。 パケットフラッディングに対する防御において。

注意:

グローバルSYNチェックを無効にし、ポリシー検索後にSYNチェックを強制すると、ルーターが処理できるパケット数に大きな影響を与えます。これにより、CPUの負荷が高くなります。グローバルSYNチェックを無効にし、ポリシーごとのSYNチェックの適用を有効にする場合は、このパフォーマンスへの影響に注意する必要があります。

この例では、デバイス内の各ポリシーに対してTCPパケットセキュリティチェックを設定する方法を示しています。

この例では、デバイスでTCPパケットセキュリティチェックを無効にする方法を示しています。

この例では、SRXシリーズファイアウォールのすべてのTCPセッションの最大セグメントサイズを設定する方法を示しています。

パケット交換ネットワーク内では、需要が利用可能な容量を超えると、パケットはキューに入れられ、キューがいっぱいになるまで余剰パケットを保持し、その後パケットが廃棄されます。TCPがこのようなネットワーク上で動作する場合、エラーのないエンドツーエンドの通信を維持するために是正措置が取られます。

フローモジュールは、セッションの作成やセッションの終了などのセッションベースのイベントのRTLOGの生成をすでにサポートしています。SRXシリーズファイアウォールは、セッションが存在しないパケットドロップなどのパケットベースイベントのRTLOGの生成をサポートするようになりました。

SRXシリーズファイアウォールは、フローモジュールによってドロップされた非同期TCPアウトオブステートパケットのログ記録をサポートします。

TCPアウトオブステートパケットドロップロギング機能は、パケットの損失を回避し、エラーのない通信のために非同期パケットをログに記録することでパケット回復を可能にし、データベースサーバーの同期外を防ぎます。この機能は、セキュリティログ(RTLOG)ファシリティの上に構築されています。

TCPアウトオブステートパケットドロップログは、以下の条件下でのTCPパケットドロップログのキャプチャをサポートします。

• Session ages out—長いTCPセッション上で実行されているクラウドアプリケーションがあり、セッションが終了した後にこれらのアプリケーションがTCPセッションを更新しない場合、TCPパケットは破棄されます。この機能は、これらのドロップされたTCPパケットのログ記録をサポートします。

• Unsynchronized first packets due to attacks or asymmetric routes—2つのサイトにSRXシリーズファイアウォールを導入し、ルーティングによって非対称トラフィックが強制される場合、同期(SYN)パケットは1つのサイトで表示されますが、同期確認(SYN_ACK)パケットは別のサイトで表示されます。

  これは、SRXシリーズファイアウォールが、一致するステートテーブルエントリを持たないTCP ACKパケットを認識することを意味します。これは、接続が一定期間非アクティブであったり、接続テーブルがフラッシュされた (例えば、ポリシーのインストールや再起動など) が原因で発生する可能性があります。

  このケースで別のサイトで確認されたSYN_ACKパケットは、SRXシリーズファイアウォールによって拒否されましたが、ログには記録されませんでした。この機能は、拒否されたSYN_ACKパケットのロギングをサポートします。

• Other out-of-state conditions (like TCP sequence check fail and synchronization packet received in FIN state)—SRXシリーズファイアウォールがシーケンス障害を検出した場合、デバイスがTCP4ウェイクローズ状態であるがSYNパケットを受信した場合、または3ウェイハンドシェイクエラーが発生した場合、SRXシリーズファイアウォールはTCPパケットをドロップし、これらのドロップされたパケットはログに記録されます。

注:

同期されていないTCPアウトオブステートパケットドロップログは、セッションベースのログではなくパケットベースのログです。

TCPアウトオブステートパケットドロップロギングは、CPUが攻撃されるのを防ぐためのスロットルメカニズムで設計されており、各スロットル間隔内に一部のログをドロップできます。

フローモジュールによってドロップされたTCPアウトオブステートパケットのみがログに記録されます。TCPプロキシとIDPによってドロップされたTCPパケットはログに記録されません。

• TCP アウトオブステート パケット ドロップ ロギングの理解
• サポートされているTCPアウトオブステートロギング機能

あるホストから別のホストにデータが送信されると、一連のパケットとして送信されます。最大サイズのパケットが、データパスのどのリンクでもフラグメント化されることなく、送信元ノードから宛先ノードへのパスを通過できるため、パフォーマンスが向上し、ネットワークリソースが節約されます。パケットがそのリンクに設定された最大送信単位(MTU)よりも大きいため、パス内のリンクを通過するためにパケットをより小さなパケットにフラグメント化する必要がある場合、結果として得られる各フラグメントには、ペイロードまたはデータに加えて、パケットヘッダー情報が含まれている必要があります。オーバーヘッドが増加すると、スループットが低下し、ネットワークパフォーマンスが低下する可能性があります。また、パケットフラグメントは宛先ノードで再アセンブリする必要があり、追加のネットワークリソースを消費します。

一方、ホストがパスMTU(パス最大伝送単位)よりもはるかに小さいパケットを送信すると、ネットワークリソースが浪費され、その結果、最適とは言えないスループットになります。パス MTU 検出プロセスは、セッションのソースノードからデスティネーションノードにデータパスを通過するフラグメントの最適な MTU サイズを検出するために機能します。したがって、最適なパケットサイズはパスMTUのサイズです。フラグメント化は、パケットのサイズがパス MTU を超えると発生します。

アプリケーション層サービスがSRXシリーズファイアウォールで設定されている場合、サービスを適用してコンテンツを検査する前に、イングレスインターフェイスのパケットフラグメントを再構築する必要があります。これらの再構築されたパケットフラグメントは、データがエグレスインターフェイスから送信される前に、再度分解する必要があります。通常、SRXシリーズファイアウォールから次のリンクに送信されるフラグメントのサイズを決定するのは、エグレスインターフェイスのMTUサイズです。SRXシリーズファイアウォールのエグレスMTUサイズがパスMTUよりも大きい場合があり、データパスでパケットがフラグメント化され、パフォーマンスが低下したり、パケットドロップが発生する可能性があります。パケットフラグメントは、送信元から宛先へのパス内のすべてのリンクを通過するのに十分な大きさでなければなりません。

デフォルトでは、SRXシリーズファイアウォールは、エグレスインターフェイスに設定されたMTUサイズを使用して、送信するパケットフラグメントのサイズを決定します。ただし、受信フラグメント特性を保持する機能を有効にすると、SRXシリーズファイアウォールは受信パケットフラグメントのサイズを検出して保存します。

データパスでパケットがフラグメント化される可能性を減らすために、SRXシリーズファイアウォールはそのフローのエグレスMTUを追跡して調整します。これは、すべての受信フラグメントの最大サイズを識別します。この情報をエグレスインターフェイスの既存のMTUと組み合わせて使用して、エグレスインターフェイスから送信されたフラグメントパケットの正しいMTUサイズを決定します。SRXシリーズファイアウォールは、この2つの数値を比較します。小さい方の数値を取り、エグレスインターフェイスのMTUサイズに使用します。

set security flow preserve-incoming-frag-sizeコマンドを使用してデバイスを設定し、受信パケットフラグメントのサイズを考慮した機能を有効にします。

表1 は、SRXシリーズのエグレスMTUサイズを決定する方法をまとめたものです。

表1:SRXシリーズファイアウォールから出るフラグメントの最終的なエグレスMTUサイズの決定方法

受信フラグメントサイズ	既存のエグレス MTU サイズ	最終的なエグレス MTU サイズ
最大のフラグメントが	既存のエグレスMTUサイズより小さい	最大の受信フラグメントサイズが使用されます。
最大のフラグメントが	既存のエグレス MTU サイズよりも大きい	既存のエグレスインターフェイスMTUが使用されます。

注:

この機能は、SRXシリーズファイアウォールでサポートされています。スルートラフィックとトンネルから出るトラフィックをサポートします。これは、IPv4とIPv6の両方のトラフィックに適用されます。

次の 2 つの考慮事項がフラグメント サイズに影響します。

• コンテンツセキュリティやALGなどのストリームベースのアプリケーションでは、フラグメントが受信されていなくても、アプリケーション自体がパケットを変更または再アセンブリする可能性があります。この場合、既存のエグレスインターフェイスMTUが使用されます。

• パス MTU ディスカバリー パケットがセッションに配信されると、そのセッションのパス MTU はパス MTU パケットによって確立された値にリセットされます。

TCPプロキシ短絡は、デバイスでデフォルトで有効になっています。セッションにTCPプロキシを使用することに関心のあるユーザー(L7ポリシー適用プラグイン/高度なアプリケーションサービス)がいない場合に自動的にトリガーされます。TCP セッションの確立とポリシーの適用が成功すると、デバイスはセッションを短絡状態に移行し、後続のデータ パケットがクライアントとサーバー間を直接流れるようにします。

最初のハンドシェイクフェーズ中、デバイスは完全なTCPプロキシ動作を維持し、接続の両側のTCP状態、シーケンス番号、確認応答を個別に管理します。セッションが正当で安定していることが確認されると、デバイスはデータトラフィックのシーケンス番号や再送をプロキシしなくなります。代わりに、ポリシーコンプライアンスとセキュリティ違反がないかセッションを監視し続けながら、パケットを直接転送します。

TCPプロキシショート回線は、完全なTCPプロキシによる長期的なパフォーマンスオーバーヘッドなしに、強力なTCPセキュリティと検証を必要とする導入に適しています。特に、データセンター、サービスプロバイダエッジ、大規模なエンタープライズネットワークなどの高スループット環境で効果的です。