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-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 + 64)を持つ有効なパケットがパケットXの前に到着すると、ウィンドウが右にシフトされ、リプレイ障害のためにパケットXがドロップされます。
   
   このようなシナリオでは、リプレイウィンドウのサイズを増やすか、リプレイチェックを無効にして、このような遅延を許容できるものと見なし、正当なパケットが廃棄されないようにすることができます。デフォルトでは、リプレイウィンドウのサイズはかなり小さくなっています（ウィンドウサイズは64）。 サイズを大きくしても、攻撃のリスクが大幅に高まることはありません。IPSecアンチリプレイウィンドウの設定方法については、『IPSecアンチリプレイウィンドウの設定方法：拡張と無効化』を参照してください。

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

   注：初期のアグリゲーションサービスルータ(ASR)1000モデル（ASR1000とASR1001を一緒に使用したESP5、ESP10、ESP20、およびESP40など）では、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、Integrated Service Router(ISR)4000シリーズルータ、Catalyst8000シリーズルータなど)は、バージョン15.2(2)S以降で1024パケットのウィンドウサイズをサポートします。

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

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

追加情報

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