Problemen met de controle van de IPsec anti-replay oplossen

Inleiding

In dit document wordt een probleem beschreven dat verband houdt met fouten in de anti-replay-controle van Internet Protocol Security (IPsec) en worden mogelijke oplossingen geboden.

Achtergrondinformatie

Een overzicht van Replay-aanvallen

Een replay-aanval is een vorm van netwerkaanval waarbij geldige gegevensoverdracht kwaadwillig of frauduleus wordt geregistreerd en later wordt herhaald. Het is een poging om de beveiliging te ondermijnen door iemand die legitieme communicatie registreert en herhaalt om zich voor te doen als een geldige gebruiker en legitieme verbindingen te verstoren of een negatieve impact te hebben.

IPsec Replay Check-beveiliging

Een volgnummer dat monotoon toeneemt, wordt door IPsec toegewezen aan elk gecodeerd pakket om anti-replay-bescherming te bieden tegen een aanvaller. Het ontvangende IPsec-eindpunt houdt bij welke pakketten het al heeft verwerkt wanneer het deze nummers gebruikt en een schuifvenster met acceptabele volgnummers. De standaard grootte van het anti-replay-venster in de Cisco IOS®-implementatie is 64 pakketten, zoals weergegeven in deze afbeelding:

Wanneer een IPsec-tunneleindpunt anti-replay-beveiliging heeft ingeschakeld, wordt het binnenkomende IPsec-verkeer als volgt verwerkt:

• Als het volgnummer binnen het venster valt en niet eerder is ontvangen, wordt de integriteit van het pakket gecontroleerd. Als het pakket de integriteitscontrole doorstaat, wordt het geaccepteerd en geeft de router aan dat dit volgnummer is ontvangen. Bijvoorbeeld in het vorige diagram een pakket met Encapsulating Security Payload (ESP) volgnummer van 162.
• Als het volgnummer binnen het venster valt, maar eerder is ontvangen, wordt het pakket verwijderd. Dit gedupliceerde pakket wordt weggegooid en de druppel wordt opgenomen in de replay-teller.

• Als het volgnummer groter is dan het hoogste volgnummer in het venster, wordt de integriteit van het pakket gecontroleerd. Als het pakket de integriteitscontrole doorstaat, wordt het schuifvenster naar rechts verplaatst. Als bijvoorbeeld een geldig pakket met een volgnummer van 189 wordt ontvangen, wordt de nieuwe rechterrand van het venster ingesteld op 189 en de linkerrand is 125 (189 - 64 [venstergrootte]).
• Als het volgnummer lager is dan de linkerrand, wordt het pakket weggelaten en opgenomen in de replay-teller. Dit wordt beschouwd als een out-of-order pakket.

In de gevallen waarin een replay check-fout optreedt en het pakket is gevallen, genereert de router een syslog-bericht dat vergelijkbaar is met dit:

%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

Opmerking: De herhalingsdetectie is gebaseerd op de veronderstelling dat de IPsec Security Association (SA) tussen slechts twee peers bestaat. Group Encrypted Transport VPN (GETVPN) maakt gebruik van één IPsec SA tussen veel peers. Als gevolg hiervan maakt GETVPN gebruik van een heel ander anti-replay-controlemechanisme dat Time Based Anti-Replay Failure wordt genoemd. Dit document heeft alleen betrekking op tegengestelde anti-replay voor point-to-point IPsec-tunnels.

Opmerking: Anti-replay-beveiliging is een belangrijke beveiligingsservice die het IPsec-protocol biedt. Het uitschakelen van IPsec anti-replay heeft gevolgen voor de veiligheid en moet alleen met de nodige voorzichtigheid worden gedaan.

Problemen die kunnen leiden tot IPsec-terugspeeldalingen

Zoals eerder beschreven, is het doel van replay-controles om te beschermen tegen kwaadaardige herhalingen van legitieme pakketten. Enkele van de meest voorkomende voorwaarden die kunnen leiden tot een mislukte replay check zijn:

• De fout kan het gevolg zijn van pakketten die tijdens de levering opnieuw worden geordend in het netwerkpad tussen de tunneleindpunten. Dit kan waarschijnlijk gebeuren als er meerdere netwerkpaden tussen de peers zijn.

• De fout kan worden veroorzaakt door ongelijke pakketverwerkingspaden in het Cisco IOS. Bijvoorbeeld, gefragmenteerde IPsec-pakketten die IP-hermontage vereisen voordat ze worden gedecodeerd, kunnen voldoende worden vertraagd, zodat ze buiten het replay-venster vallen tegen de tijd dat ze worden verwerkt.
• De fout kan worden veroorzaakt door de Quality of Service (QoS) ingeschakeld op het verzenden van IPsec-eindpunt of binnen het netwerkpad. Met de Cisco IOS-implementatie vindt IPsec-codering plaats voordat QoS in de richting van uitgang gaat. Bepaalde QoS-functies, zoals Low Latency Queueing (LLQ), kunnen ervoor zorgen dat IPsec-pakketbezorging buiten de orde raakt en door het ontvangende eindpunt wordt verwijderd vanwege een mislukte replay-controle.

• Een netwerkconfiguratie/operationeel probleem kan pakketten dupliceren tijdens het transport van het netwerk.
• Een aanvaller (man-in-the-middle) kan mogelijk het ESP-verkeer vertragen, laten vallen en dupliceren.

Problemen met IPsec Replay Drops oplossen

De sleutel tot het oplossen van problemen met IPsec replay drops is om te identificeren welke pakketten worden gedropt als gevolg van replay, en gebruik packet captures om te bepalen of deze pakketten inderdaad opnieuw worden afgespeeld pakketten of pakketten die zijn aangekomen op de ontvangende router buiten het replay-venster. Om de gedropte pakketten correct af te stemmen op wat is vastgelegd in het snuffelspoor, is de eerste stap het identificeren van de peer- en IPsec-stroom waartoe de gedropte pakketten behoren en het ESP-volgnummer van het pakket.

Cisco IOS XE Datapath Packet Tracing-functie gebruiken

Op routerplatforms waarop Cisco IOS® XE wordt uitgevoerd, wordt informatie over de peer en de IPsec Security Parameter Index (SPI) afgedrukt in het syslog-bericht wanneer een terugspeeldrop optreedt om de peer-tunnel te identificeren en het gedropte pakket toe te behoren. Het ESP-volgnummer wordt echter niet afgedrukt in deze uitvoer. Het ESP-volgnummer wordt gebruikt om een IPsec-pakket binnen een bepaalde IPsec-stroom op unieke wijze te identificeren. Zonder het volgnummer wordt het moeilijk om precies te identificeren welk pakket wordt gedropt in een pakketopname.

De Cisco IOS® XE datapath packet-trace-functie kan in deze situatie worden gebruikt wanneer de terugspeelval wordt waargenomen, met dit syslog-bericht:

%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

Om het ESP-volgnummer voor het gedropte pakket te helpen identificeren, voert u deze stappen uit met de functie voor het traceren van pakketten:

Stap 1. Stel het voorwaardelijke foutopsporingsfilter voor het platform in om het verkeer van het peer-apparaat te matchen:

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

Stap 2. Met de optie kopiëren kunt u pakketkopinformatie kopiëren door pakkettracering in te schakelen:

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

Stap 3. Wanneer replay-fouten worden gedetecteerd, gebruikt u de packet trace buffer om het pakket te identificeren dat is gevallen als gevolg van replay, en het ESP-volgnummer kan worden gevonden in het gekopieerde pakket:

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

De vorige uitvoer laat zien dat pakketnummers 6 en 7 zijn weggelaten, zodat ze nu in detail kunnen worden onderzocht:

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

Het ESP-volgnummer heeft een offset van 24 bytes die begint vanaf de IP-header (of 4 bytes van de IP-pakketpayloadgegevens), zoals vetgedrukt in de vorige uitvoer wordt benadrukt. In dit specifieke voorbeeld is het ESP-volgnummer voor het gedropte pakket 0x6.

Pakketopnamen verzamelen

Naast de identificatie van de pakketinformatie voor het pakket dat is gevallen als gevolg van het falen van de replay-controle, moet tegelijkertijd een pakketopname voor de betreffende IPsec-stroom worden verzameld. Dit helpt bij het onderzoek van het ESP-volgnummerpatroon binnen dezelfde IPsec-stroom om de reden voor de terugspeeldaling te bepalen. Zie Ingebouwde pakketopname voor Cisco IOS XE-configuratievoorbeeld voor meer informatie over het gebruik van de Embedded Packet Capture (EPC) op Cisco IOS XE-routers.

Analyse van het volgnummer van Wireshark gebruiken

Zodra de pakketopname voor de gecodeerde (ESP) pakketten op de WAN-interface is verzameld, kan Wireshark worden gebruikt om ESP-sequentienummeranalyse uit te voeren voor eventuele sequentienummeranomalieën. Zorg er eerst voor dat Volgnummercontrole is ingeschakeld onder Voorkeuren > Protocollen > ESP zoals weergegeven in de afbeelding:

Controleer vervolgens als volgt of er problemen zijn met het ESP-volgnummer onder Analyse > Expert-informatie:

Klik op een van de pakketten met het verkeerde volgnummer voor meer informatie:

Oplossing

Nadat de peer is geïdentificeerd en packet capture is verzameld voor de replay-drops, kunnen drie mogelijke scenario's de replay-mislukkingen verklaren:

1. Het is een geldig pakket dat is vertraagd:
   Packet captures helpen te bevestigen of het pakket daadwerkelijk geldig is en of het probleem onbeduidend is (vanwege problemen met de netwerklatentie of het transmissiepad) of een meer diepgaande probleemoplossing vereist. De opname toont bijvoorbeeld een pakket met een volgnummer van X dat niet in orde aankomt en de grootte van het replay-venster is momenteel ingesteld op 64. Als een geldig pakket met volgnummer (X + 64) arriveert voor pakket X, wordt het venster naar rechts verschoven en wordt pakket X verwijderd vanwege een replay-fout.
   
   In dergelijke scenario's is het mogelijk om de grootte van het replay-venster te vergroten of de replay-controle uit te schakelen om ervoor te zorgen dat dergelijke vertragingen als acceptabel worden beschouwd en de legitieme pakketten niet worden weggegooid. Standaard is de grootte van het replay-venster vrij klein (venstergrootte van 64). Als u de grootte verhoogt, verhoogt dit het risico op een aanval niet aanzienlijk. Raadpleeg voor informatie over het configureren van een IPsec Anti-Replay-venster het venster IPsec Anti-Replay configureren: document uitbreiden en uitschakelen.

   Tip: Als het replay-venster is uitgeschakeld of gewijzigd in het IPSec-profiel dat wordt gebruikt in een Virtual Tunnel Interface (VTI), worden de wijzigingen pas van kracht als het beschermingsprofiel is verwijderd en opnieuw is toegepast of als de tunnelinterface opnieuw is ingesteld. Dit is te verwachten gedrag omdat IPsec-profielen een sjabloon zijn die wordt gebruikt om een tunnelprofielkaart te maken wanneer de tunnelinterface wordt opgeroepen. Als de interface al actief is, hebben wijzigingen in het profiel geen invloed op de tunnel totdat de interface opnieuw is ingesteld.

   Opmerking: de vroege Aggregation Services Router (ASR) 1000-modellen (zoals de ASR1000 met ESP5, ESP10, ESP20 en ESP40, samen met de ASR1001) ondersteunden geen venstergrootte van 1024, hoewel de CLI die configuratie toestond. Als gevolg hiervan kan de venstergrootte die wordt gerapporteerd in de uitvoer van de opdracht show crypto ipsec sa niet correct zijn. Gebruik de opdracht show crypto ipsec sa peer <ip-adres> platform om de grootte van het anti-replay venster van de hardware te verifiëren. De standaard venstergrootte is 64 pakketten op alle platforms. Raadpleeg Cisco bug ID CSCso45946 voor meer informatie. De latere Cisco IOS XE-routeringsplatforms (zoals de ASR1K met ESP100 en ESP200, de ASR1001-X en ASR1002-X, Integrated Service Router (ISR) 4000-serie routers en Catalyst8000-serie routers) ondersteunen een venstergrootte van 1024 pakketten in Versies 15.2(2)S en hoger.

2. Dit is te wijten aan de QoS-configuratie op het verzendende eindpunt:
   Als het opnieuw bestellen van pakketten na IPsec wordt veroorzaakt door QoS-configuratie op het IPsec-verzendapparaat, is een mogelijke beperking het gebruik van Multiple Sequence Number Space per IPsec SA beschikbaar op Cisco IOS XE-platforms.
   
   
   
3. Het is een duplicaat pakket dat eerder werd ontvangen:
   Als dit het geval is, kunnen twee of meer pakketten met hetzelfde ESP-volgnummer binnen dezelfde IPsec-stroom worden waargenomen in de pakketopname. In dit geval wordt de pakketdaling verwacht omdat de IPsec-replaybescherming werkt zoals bedoeld om replayaanvallen in het netwerk te voorkomen, en de syslog is slechts informatief. Als deze toestand aanhoudt, moet deze worden onderzocht als een potentiële bedreiging voor de veiligheid.

Opmerking: fouten in de terugspeelcontrole worden alleen gezien wanneer een verificatiealgoritme is ingeschakeld in de IPsec-transformatieset. Een andere manier om deze foutmelding te onderdrukken is door de verificatie uit te schakelen en alleen encryptie uit te voeren; dit wordt echter sterk afgeraden vanwege de veiligheidsimplicaties van uitgeschakelde authenticatie.

Aanvullende informatie

Problemen oplossen bij het opnieuw afspelen van oudere routers met Cisco IOS Classic

De IPsec-replay valt op de oudere ISR G2-serie routers die de Cisco IOS gebruiken, zijn anders dan routers die de Cisco IOS XE gebruiken, zoals hier wordt weergegeven:

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

De berichtuitvoer geeft geen IP-adres of SPI-informatie van de peer. Om problemen op dit platform op te lossen, gebruikt u de "conn-id" in de foutmelding. Identificeer de "conn-id" in het foutbericht en zoek ernaar in de show crypto ipsec sa-uitvoer, omdat replay een per-SA-controle is (in tegenstelling tot een per-peer). Het syslog-bericht bevat ook het ESP-volgnummer, dat kan helpen bij het identificeren van het gedropte pakket in de pakketopname.

Opmerking: Bij verschillende versies van code is de "conn-id" ofwel de conn-id of flow_id voor de inkomende SA.

Dit wordt hier geïllustreerd:

%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>

Zoals te zien is aan deze uitvoer, is de replay drop afkomstig van het 10.2.0.200 peer adres met een inkomende ESP SA SPI van 0xE7EDE943. Het kan ook worden opgemerkt uit het logbericht zelf dat het ESP-volgnummer voor het gedropte pakket 13 is. De combinatie van het peer-adres, het SPI-nummer en het ESP-volgnummer kan worden gebruikt om op unieke wijze het pakket te identificeren dat in de pakketopname is gevallen.

Opmerking: het Cisco IOS-syslog-bericht is beperkt in de snelheid voor het dataplane-pakket dat daalt tot één per minuut. Om een nauwkeurige telling te krijgen van het exacte aantal gedropte pakketten, gebruikt u de opdracht crypto ipsec sa detail tonen zoals eerder getoond.

Werken met oudere Cisco IOS XE-software

Op routers die de eerdere Cisco IOS XE-releases uitvoeren, kan de "REPLAY_ERROR" die in de syslog wordt gemeld, de werkelijke IPsec-stroom niet afdrukken met de peer-informatie waar het opnieuw afgespeelde pakket is gevallen, zoals hier wordt weergegeven:

%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

Om de juiste IPsec peer- en flow-informatie te identificeren, gebruikt u de Data Plane (DP) Handle die is afgedrukt in het syslog-bericht als de invoerparameter SA Handle in deze opdracht, om de IPsec-stroominformatie op te halen op de Quantum Flow Processor (QFP):

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>

Een Embedded Event Manager (EEM)-script kan ook worden gebruikt om de gegevensverzameling te automatiseren:

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"

In dit voorbeeld wordt de verzamelde uitvoer omgeleid naar de bootflash. Gebruik de opdracht meer bootflash:replay-error.txt om deze uitvoer te zien.

Gerelateerde informatie

• Voor spraak en video geschikte IPSec VPN (V3PN)-oplossing Referentienetwerkontwerp
• Het IPsec Anti-Replay-venster configureren: uitbreiden en uitschakelen.
• Technische ondersteuning en documentatie – Cisco Systems