IPSecアンチリプレイチェック障害のトラブルシューティング

はじめに

このドキュメントでは、インターネットプロトコルセキュリティ(IPsec)アンチリプレイチェックの障害に関連する問題について説明し、考えられる解決策を示します。

 背景説明

リプレイアタックの概要

リプレイアタックはネットワーク攻撃の一種で、有効なデータ伝送が悪意をもって、または不正に記録され、後で繰り返されます。これは、有効なユーザになりすまして正当な接続を中断または悪影響を及ぼすために、正当な通信を記録して繰り返すユーザによって、セキュリティを弱体化させる試みです。

IPsecリプレイチェック保護

IPsecにより暗号化されたパケット毎に単調増加するシーケンス番号を割り当て、攻撃者に対するアンチリプレイ保護を提供する。受信側のIPsecエンドポイントは、これらの番号と、受け入れ可能なシーケンス番号のスライディングウィンドウを使用して、すでに処理したパケットを追跡します。Cisco IOS®実装のデフォルトのアンチリプレイウィンドウサイズは、次の図に示すように64パケットです。

IPsecトンネルエンドポイントでアンチリプレイ保護が有効になっている場合、着信IPsecトラフィックは次のように処理されます。

• シーケンス番号がウィンドウ内にあり、以前に受信されていない場合、パケットの整合性がチェックされます。パケットが整合性検証チェックに合格すると、そのパケットは受け入れられ、ルータはこのシーケンス番号が受信されたことを示すマークを付けます。たとえば、Encapsulating Security Payload(ESP)シーケンス番号162を持つパケットです。
• シーケンス番号がウィンドウ内にあるが、以前に受信された場合、パケットはドロップされます。この重複パケットは破棄され、ドロップはリプレイカウンタに記録されます。

• シーケンス番号がウィンドウ内で最も大きいシーケンス番号よりも大きい場合、パケットの整合性がチェックされます。パケットが整合性検証チェックに合格すると、スライディングウィンドウが右に移動します。たとえば、シーケンス番号が189の有効なパケットを受信した場合、ウィンドウの新しい右エッジは189に設定され、左エッジは125（189 - 64 [ウィンドウサイズ]）になります。
• シーケンス番号が左端より小さい場合、パケットはドロップされ、リプレイカウンタに記録されます。これは不正なパケットと見なされます。

リプレイチェックが失敗し、パケットがドロップされた場合、ルータは次のようなSyslogメッセージを生成します。

%IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replay error, DP Handle n, src_addr x.x.x.x, dest_addr y.y.y.y, SPI 0xzzzzzzzz

注：リプレイ検出は、IPSecセキュリティアソシエーション(SA)が2つのピア間にのみ存在するという前提に基づいています。Group Encrypted Transport VPN(GETVPN)は、多数のピア間で1つのIPsec SAを使用します。その結果、GETVPNでは、時間ベースのアンチリプレイ障害と呼ばれるまったく異なるアンチリプレイチェックメカニズムが使用されます。このドキュメントでは、ポイントツーポイントIPSecトンネルのカウンタベースのアンチリプレイのみを取り上げます。

注：アンチリプレイ保護は、IPsecプロトコルが提供する重要なセキュリティサービスです。IPSecアンチリプレイを無効にすると、セキュリティに影響を与えるため、慎重に行う必要があります。

IPSecリプレイドロップを引き起こす可能性のある問題

すでに説明したように、リプレイ チェックの目的は、悪意によるパケットの繰り返しを防止することです。ただし、次に示すシナリオでは、失敗したリプレイチェックが悪意のある理由によるものではない場合があります。

• このエラーは、トンネルのエンドポイント間のネットワークパスで十分なパケットが並べ替えられることによって発生する可能性があります。これは、ピア間に複数のネットワークパスがある場合に発生する可能性があります。

• このエラーは、Cisco IOS内のパケット処理パスが不均等であることが原因で発生する可能性があります。たとえば、フラグメント化されたIPsecパケットは、復号化の前にIPの再構成を必要とする場合、処理されるまでにリプレイウィンドウの範囲外に入るために十分に遅延する可能性があります。
• エラーは、送信側のIPsecエンドポイントまたはネットワークパス内で有効になっているQuality of Service(QoS)が原因で発生する可能性があります。Cisco IOSの実装では、出力方向のQoSの前にIPsec暗号化が行われます。低遅延キューイング(LLQ)などの特定のQoS機能により、IPSecパケット配信が順不同になり、リプレイチェックの失敗が原因で受信側エンドポイントによってドロップされる可能性があります。

• ネットワークの設定や動作に問題があると、パケットがネットワークを通過する際にパケットが重複する可能性があります。
• 攻撃者（中間者）は、ESPトラフィックを遅延、ドロップ、および複製する可能性があります。

IPSec リプレイ ドロップのトラブルシューティング

IPSecリプレイドロップのトラブルシューティングで重要となるのは、リプレイが原因でドロップされたパケットを識別し、パケットキャプチャを使用してこれらのパケットが実際にリプレイされたパケットか、リプレイウィンドウ外の受信側ルータに到着したパケットかを判別することです。ドロップされたパケットをスニファトレースでキャプチャされた内容と正しく照合するには、最初のステップとして、ドロップされたパケットが属するピアとIPsecフロー、およびパケットのESPシーケンス番号を特定します。

Cisco IOS XEデータパスパケットトレース機能の使用

Cisco IOS® XEを実行するルータプラットフォームでは、ドロップが発生するとアンチリプレイ問題のトラブルシューティングに役立てるため、ピアに関する情報とIPsec Security Parameter Index（SPI；セキュリティパラメータインデックス）がSyslogメッセージに出力されます。ただし、失われていない重要な情報は、ESPシーケンス番号です。ESP シーケンス番号は、特定の IPSec フローの中の IPSec パケットを一意に識別するのに使用されます。このシーケンス番号がないと、どのパケットがドロップされたかをパケット キャプチャで識別することが難しくなります。

Cisco IOS XEデータパスのパケットトレース機能は、リプレイドロップが発生した場合に次のsyslogメッセージを表示して使用できます。

%IOSXE-3-PLATFORM: F0: cpp_cp: QFP:0.0 Thread:060 TS:00000001132883828011
%IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replay error, DP Handle 3, src_addr 10.2.0.200, dest_addr 10.1.0.100, SPI 0x4c1d1e90

ドロップされたパケットの ESP シーケンス番号を特定するには、パケット トレース機能で次の手順を実行します。

ステップ 1：ピアデバイスからのトラフィックと照合するために、プラットフォームの条件付きデバッグフィルタを設定します。

debug platform condition ipv4 10.2.0.200/32 ingress
debug platform condition start

ステップ 2：パケット ヘッダー情報をコピーするため、次のように、copy オプションを付加した状態でパケット トレースを有効にします。

debug platform packet enable
debug platform packet-trace packet 64 
debug platform packet-trace copy packet input l3 size 100

ステップ 3：リプレイ エラーが検出されたら、パケット トレース バッファを使用して、リプレイを原因としてドロップされたパケットを識別します。ESP シーケンス番号は、コピーされたパケットの中に表示されます。

Router#show platform packet-trace summary 
Pkt   Input            Output           State  Reason
0     Gi4/0/0          Tu1              CONS   Packet Consumed
1     Gi4/0/0          Tu1              CONS   Packet Consumed
2     Gi4/0/0          Tu1              CONS   Packet Consumed
3     Gi4/0/0          Tu1              CONS   Packet Consumed
4     Gi4/0/0          Tu1              CONS   Packet Consumed
5     Gi4/0/0          Tu1              CONS   Packet Consumed
6     Gi4/0/0          Tu1              DROP   053 (IpsecInput)
7     Gi4/0/0          Tu1              DROP   053 (IpsecInput)
8     Gi4/0/0          Tu1              CONS   Packet Consumed
9     Gi4/0/0          Tu1              CONS   Packet Consumed
10    Gi4/0/0          Tu1              CONS   Packet Consumed
11    Gi4/0/0          Tu1              CONS   Packet Consumed
12    Gi4/0/0          Tu1              CONS   Packet Consumed
13    Gi4/0/0          Tu1              CONS   Packet Consumed

上記の出力から、パケット番号 6 と 7 がドロップされていることがわかります。これで、次の詳細な調査が可能になります。

Router#show platform packet-trace packet 6
 
/>Packet: 6           CBUG ID: 6
Summary
  Input     : GigabitEthernet4/0/0
  Output    : Tunnel1
  State     : DROP 053 (IpsecInput)
  Timestamp : 3233497953773
Path Trace
  Feature: IPV4
    Source      : 10.2.0.200
    Destination : 10.1.0.100
    Protocol    : 50 (ESP)
  Feature: IPSec
    Action    : DECRYPT
    SA Handle : 3
    SPI       : 0x4c1d1e90
    Peer Addr : 10.2.0.200
    Local Addr: 10.1.0.100
  Feature: IPSec
    Action    : DROP
    Sub-code  : 019 - CD_IN_ANTI_REPLAY_FAIL
Packet Copy In
  45000428 00110000 fc329575 0a0200c8 0a010064 4c1d1e90 00000006 790aa252
  e9951cd9 57024433 d97c7cb8 58e0c869 2101f1ef 148c2a12 f309171d 1b7a4771
  d8868af7 7bae9967 7d880197 46c6a079 d0143e43 c9024c61 0045280a d57b2f5e
  23f06bc3 ab6b6b81 c1b17936 98939509 7aec966e 4dd848d2 60517162 9308ba5d

上記の出力で太字で強調されているように、ESPシーケンス番号のオフセットは、IPヘッダー（またはIPパケットのペイロードデータの4バイト）から始まる24バイトです。この例では、ドロップされたパケットの ESP シーケンス番号は 0x6 です。

パケットキャプチャの収集

リプレイチェック障害が原因でドロップされたパケットのパケット情報の識別に加えて、問題のIPsecフローのパケットキャプチャは同時に収集する必要があります。これは、同じIPSecフロー内のESPシーケンス番号パターンを調べて、リプレイドロップの理由を特定するのに役立ちます。Cisco IOS XEルータでEmbedded Packet Capture(EPC)を使用する方法の詳細については、「Cisco IOSおよびCisco IOS XEの組み込みパケットキャプチャの設定例」を参照してください。

Wiresharkシーケンス番号分析の使用

WANインターフェイス上の暗号化(ESP)パケットのパケットキャプチャが収集されると、Wiresharkを使用して、シーケンス番号の異常に対するESPシーケンス番号分析を実行できます。まず、図に示すように、Preferences > Protocols > ESP でSequence Number Checkが有効になっていることを確認します。

次に、次のようにAnalyze > Expertの情報でESPシーケンス番号の問題を確認します。

誤ったシーケンス番号のパケットをクリックすると、次のような詳細情報が表示されます。

解決方法

ピアが特定され、リプレイドロップのパケットキャプチャが収集された後、次の3つのシナリオがリプレイエラーの原因となる可能性があります。

1. 遅延した有効なパケットである場合：
   パケット キャプチャは、パケットが実際に有効であるか、また、問題は（ネットワーク遅延または伝送パスの問題による）軽微なものであるか詳細なトラブルシューティングが必要であるか、確認するのに役立ちます。たとえば、キャプチャは、誤った順序で到着するXのシーケンス番号のパケットを示し、リプレイウィンドウサイズは現在64に設定されています。パケットXの前にシーケンス番号(X + 64)の有効なパケットが到着すると、ウィンドウが右に移動し、パケットXがリプレイ障害のためにドロップされます。
   
   このようなシナリオでは、リプレイウィンドウのサイズを増やすか、リプレイチェックを無効にして、このような遅延を許容できるものと見なし、正当なパケットが廃棄されないようにすることができます。デフォルトでは、リプレイウィンドウのサイズはかなり小さくなります（ウィンドウサイズは64）。サイズを大きくしても、攻撃のリスクが大幅に高まることはありません。IPSecアンチリプレイウィンドウの設定方法については、『IPSecアンチリプレイウィンドウの設定方法：拡張と無効化』を参照してください。
   
   

   ヒント：仮想トンネルインターフェイス(VTI)で使用されているIPSecプロファイルでリプレイウィンドウを無効にするか変更した場合、保護プロファイルを削除して再適用するか、トンネルインターフェイスをリセットするまで、変更は有効になりません。IPsecプロファイルは、トンネルインターフェイスの起動時にトンネルプロファイルマップを作成するために使用されるテンプレートであるため、これは正常な動作です。インターフェイスがすでにアップ状態である場合、プロファイルに対する変更は、インターフェイスがリセットされるまでトンネルに影響しません。

   注：初期のアグリゲーションサービスルータ(ASR)1000モデル（ASR1000とESP5、ESP10、ESP20、ESP40およびASR1001など）では、CLIでウィンドウサイズ1024の設定が許可されていましたが、サポートされていませんでした。その結果、show crypto ipsec saコマンドの出力でレポートされるウィンドウサイズが正しくなくなります。ハードウェアのアンチリプレイウィンドウのサイズを確認するには、show crypto ipsec sa peer ip-address platformコマンドを使用します。デフォルトのウィンドウ サイズは、すべてのプラットフォームで 64 パケットとなっています。詳細は、Cisco Bug ID CSCso45946 を参照してください。新しいCisco IOS XEルーティングプラットフォーム(ESP100およびESP200を搭載したASR1K、ASR1001-XおよびASR1002-X、サービス統合型ルータ(ISR)4000シリーズルータ、Catalyst 8000シリーズルータなど)では、バージョン15.2(2)S以降で1024パケットのウィンドウサイズがサポートされます。

   
   
2. 送信側エンドポイントのQoS設定が原因である場合：
   IPSec後のパケットのリオーダーがIPSec送信側デバイスのQoS設定によって発生する場合、緩和の可能性として、IOS XEプラットフォームで使用可能なIPSec SAごとの複数シーケンス番号スペースを使用できます。
   
   
   
3. 以前に受信した重複パケットである場合：
   この場合、同じIPSecフロー内の同じESPシーケンス番号を持つ2つ以上のパケットがパケットキャプチャで観察される可能性があります。この場合、IPsecリプレイ保護が意図したとおりに機能し、ネットワークでのリプレイ攻撃を防止するため、パケットのドロップが予想されます。syslogは単なる情報です。この状態が続く場合は、潜在的なセキュリティの脅威として調査する必要があります。

注：リプレイチェックの失敗が発生するのは、IPSecトランスフォームセットで認証アルゴリズムが有効になっている場合だけです。このエラーメッセージを抑制する別の方法として、認証を無効にして暗号化のみを実行する方法があります。ただし、認証を無効にした場合のセキュリティ上の影響があるため、この方法はお勧めしません。

追加情報

Cisco IOS Classic搭載のレガシールータでのリプレイエラーのトラブルシューティング

Cisco IOSを使用するレガシーISR G2シリーズルータでのIPsecリプレイドロップは、次に示すようにCisco IOS XEを使用するルータとは異なります。

%CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed connection id=529, sequence number=13

メッセージ出力は、ピアのIPアドレスまたはSPI情報を提供しません。このプラットフォームでトラブルシューティングを行うには、エラーメッセージで「conn-id」を使用します。リプレイはSAごとの（セキュリティアソシエーション）チェック（as opposed to aピアごととは異なる）であるため、エラーメッセージで「conn-id」を特定し、show crypto ipsec sa出力でそれを探します。Syslogメッセージには、パケットキャプチャでドロップされたパケットを一意に識別するのに役立つESPシーケンス番号も含まれています。

注：コードのバージョンによって、「conn-id」は着信SAのconn idまたはflow_idになります。

これを以下に示します。

%CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed connection id=529, sequence number=13

Router#show crypto ipsec sa | in peer|conn id
   current_peer 10.2.0.200 port 500
        conn id: 529, flow_id: SW:529, sibling_flags 80000046, crypto map: Tunnel0-head-0
        conn id: 530, flow_id: SW:530, sibling_flags 80000046, crypto map: Tunnel0-head-0
Router#

Router#show crypto ipsec sa peer 10.2.0.200 detail  

   interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 10.1.0.100

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 10.2.0.200 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 27, #pkts encrypt: 27, #pkts digest: 27
    #pkts decaps: 27, #pkts decrypt: 27, #pkts verify: 27
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #pkts no sa (send) 0, #pkts invalid sa (rcv) 0
    #pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
    #pkts invalid prot (recv) 0, #pkts verify failed: 0
    #pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
    #pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
    ##pkts replay failed (rcv): 21
    #pkts internal err (send): 0, #pkts internal err (recv) 0

     local crypto endpt.: 10.1.0.100, remote crypto endpt.: 10.2.0.200
     path mtu 2000, ip mtu 2000, ip mtu idb Serial2/0
     current outbound spi: 0x8B087377(2332586871)
     PFS (Y/N): N, DH group: none

               inbound esp sas:
      spi: 0xE7EDE943(3891128643)
        transform: esp-gcm ,
        in use settings ={Tunnel, }
        conn id: 529, flow_id: SW:529, sibling_flags 80000046, crypto map:
        Tunnel0-head-0
        sa timing: remaining key lifetime (k/sec): (4509600/3223)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

<SNIP>

この出力からわかるように、リプレイドロップは、0xE7EDE943のインバウンドESP SA SPIを持つ10.2.0.200ピアアドレスによるものです。また、ログメッセージ自体から、ドロップされたパケットのESPシーケンス番号が13であることもわかります。ピアアドレス、SPI番号、およびESPシーケンス番号の組み合わせを使用して、パケットキャプチャでドロップされたパケットを一意に識別できます。

注:Cisco IOS Syslogメッセージは、1分に1つに減少するデータプレーンパケットに対してレート制限されています。ドロップされたパケットの厳密なカウントを正確に取得するには、前に示したように show crypto ipsec sa detail コマンドを使用します。

以前のCisco IOS XEソフトウェアとの連携

以前のCisco IOS XEリリースを実行しているルータでは、次に示すように、Syslogに報告される「REPLAY_ERROR」は、リプレイされたパケットがドロップされたピア情報を含む実際のIPsecフローを出力できません。

%IOSXE-3-PLATFORM: F0: cpp_cp: QFP:00 Thread: 095 TS:00000000240306197890
%IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replay error, DP Handle 3

正しいIPsecピアとフローの情報を特定するには、Syslogメッセージに出力されたデータプレーン(DP)ハンドルをこのコマンドで入力パラメータSA Handleとして使用し、Quantum Flow Processor(QFP)のIPsecフロー情報を取得します。

Router#show platform hardware qfp active feature ipsec sa 3
QFP ipsec sa Information

         QFP sa  id: 3
          pal sa id: 2
         QFP spd id: 1
          QFP sp id: 2
            QFP spi: 0x4c1d1e90(1276976784)
         crypto ctx: 0x000000002e03bfff
              flags: 0xc000800 
                   : src:IKE  valid:Yes  soft-life-expired:No  hard-life-expired:No
                   : replay-check:Yes  proto:0  mode:0  direction:0
                   : qos_preclassify:No  qos_group:No
                   : frag_type:BEFORE_ENCRYPT  df_bit_type:COPY
                   : sar_enable:No  getvpn_mode:SNDRCV_SA
                   : doing_translation:No  assigned_outside_rport:No
                   : inline_tagging_enabled:No
          qos_group: 0x0
                mtu: 0x0=0
          sar_delta: 0
         sar_window: 0x0
         sibling_sa: 0x0
             sp_ptr: 0x8c392000
            sbs_ptr: 0x8bfbf810
     local endpoint: 10.1.0.100
    remote endpoint: 10.2.0.200
   cgid.cid.fid.rid: 0.0.0.0
               ivrf: 0
               fvrf: 0
    trans udp sport: 0
    trans udp dport: 0
    first intf name: Tunnel1
  <SNIP>

Embedded Event Manager(EEM)スクリプトを使用して、データ収集を自動化することもできます。

event manager applet Replay-Error 
 event syslog pattern "%IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replay error"
 action 1.0 regexp "([0-9]+)$" "$_syslog_msg" dph
 action 2.0 cli command "enable"
 action 3.0 cli command "show platform hardware qfp active feature ipsec sa $dph |
 append bootflash:replay-error.txt"

この例では、収集された出力はブートフラッシュにリダイレクトされます。この出力を表示するには、more bootflash:replay-error.txtコマンドを使用します。

関連情報

• 音声ビデオ対応 IPSec VPN（V3PN）ソリューション参照ネットワーク設計
• IPSecアンチリプレイウィンドウの設定方法：展開と無効化」を参照してください。
• テクニカル サポートとドキュメント - Cisco Systems