Problemen oplossen met de IPsec-antireplaycontrole
Inhoud
Inleiding
In dit document wordt een probleem beschreven met betrekking tot mislukte anti-replaycontroles van Internet Protocol Security (IPsec) en worden mogelijke oplossingen geboden.
Achtergrondinformatie
Overzicht van Replay Attacks
Een replay aanval is een vorm van netwerkaanval waarbij geldige datatransmissie kwaadwillig of frauduleus wordt vastgelegd 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 een negatieve impact op legitieme verbindingen te verstoren of te veroorzaken.
IPsec Replay Check Protection
Een volgnummer dat monotoon toeneemt, wordt toegewezen aan elk gecodeerd pakket door IPsec om antireplay-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 antireplay-venster in de Cisco IOS®-implementatie is 64 pakketten, zoals weergegeven in deze afbeelding:
Wanneer een IPsec-tunneleindpunt antireplaybeveiliging 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 de router markeert dat dit volgnummer is ontvangen. In het vorige diagram bevindt zich bijvoorbeeld een pakket met ESP-volgnummer (Encapsulating Security Payload) van 162 in het afspeelvenster.
- Als het volgnummer binnen het venster valt, maar eerder is ontvangen, wordt het pakket gedropt. Dit gedupliceerde pakket wordt weggegooid en de druppel wordt opgenomen in de herhalingsvalcounter.
- 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 er bijvoorbeeld een geldig pakket met een volgnummer van 189 wordt ontvangen, wordt de nieuwe rechterrand van het venster ingesteld op 189 en is de linkerrand 125 (189 - 64 [venstergrootte]).
- Als het volgnummer lager is dan de linkerrand, wordt het pakket gedropt en opgenomen in de afspeelteller. Dit wordt beschouwd als een out-of-order pakket.
In de gevallen waarin een herhalingscontrole mislukt en het pakket wordt gedropt, genereert de router een syslog bericht vergelijkbaar 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
Problemen die IPsec-herhalingsdruppels kunnen veroorzaken
Zoals eerder beschreven, is het doel van herhalingscontroles om te beschermen tegen kwaadaardige herhalingen van legitieme pakketten. Enkele van de meest voorkomende voorwaarden die kunnen leiden tot mislukte herhalingscontrole zijn:
- De fout kan het gevolg zijn van pakketten die tijdens de levering in het netwerkpad tussen de tunneleindpunten worden herbesteld. Dit kan waarschijnlijk gebeuren als er meerdere netwerkpaden tussen de peers zijn.
- De fout kan worden veroorzaakt door ongelijke paden voor pakketverwerking in het Cisco IOS. Bijvoorbeeld, gefragmenteerde IPsec-pakketten die IP-herassemblage vereisen voordat decodering kan worden vertraagd genoeg, dat ze buiten het replay-venster vallen tegen de tijd dat ze worden verwerkt.
- De fout kan worden veroorzaakt door de Quality of Service (QoS) die is ingeschakeld op het verzendende IPsec-eindpunt of binnen het netwerkpad. Met de implementatie van Cisco IOS vindt de IPsec-codering plaats voordat QoS in de regresrichting gaat. Bepaalde QoS-functies, zoals Low Latency Queueing (LLQ), kunnen ervoor zorgen dat de levering van IPsec-pakketten buiten bedrijf wordt gesteld en door het ontvangende eindpunt wordt onderbroken vanwege een fout in de herhalingscontrole.
- Een netwerkconfiguratie/operationeel probleem kan pakketten dupliceren terwijl ze het netwerk doorlopen.
- Een aanvaller (man-in-the-middle) kan mogelijk het ESP-verkeer vertragen, laten vallen en dupliceren.
Problemen oplossen met IPsec Replay Drops
De sleutel tot het oplossen van IPsec-herhalingsdruppels is om te identificeren welke pakketten worden gedropt als gevolg van herhaling, en pakketopnames te gebruiken om te bepalen of deze pakketten inderdaad opnieuw worden afgespeeld pakketten of pakketten die op de ontvangende router zijn aangekomen buiten het herhalingsvenster. Om de gedropte pakketten correct af te stemmen op wat in het sniffer-spoor wordt vastgelegd, is de eerste stap om de peer en de IPsec-stroom te identificeren 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-software wordt uitgevoerd, wordt informatie over de peer en de IPsec Security Parameter Index (SPI) afgedrukt in het syslog-bericht wanneer een herhalingsdrop optreedt om de peer en de specifieke tunnel waartoe het gedropte pakket behoort, te identificeren. Het ESP-volgnummer wordt echter niet afgedrukt in deze uitvoer. Het ESP-volgnummer wordt gebruikt om een IPsec-pakket binnen een bepaalde IPsec-stroom uniek 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 herhalingsdrop 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
Voer de volgende stappen uit met de functie voor het traceren van pakketten om het ESP-volgnummer voor het gedropte pakket te identificeren:
Stap 1. Stel het voorwaardelijke foutopsporingsfilter van 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. Schakel pakkettracering in met de kopieeroptie om de pakketkopinformatie te kopiëren:
debug platform packet-trace packet 64
debug platform packet-trace copy packet input l3 size 100
Stap 3. Wanneer er fouten in het opnieuw afspelen worden gedetecteerd, gebruikt u de buffer voor het traceren van pakketten om het pakket te identificeren dat is gevallen als gevolg van het opnieuw afspelen, en het ESP-volgnummer is te vinden 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 output 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 vanaf het begin van de IP-header (of 4 bytes van de IP-pakketpayload-gegevens), zoals in de vorige uitvoer vetgedrukt benadrukt. In dit specifieke voorbeeld is het ESP-volgnummer voor het gedropte pakket 0x6.
Packet Captures verzamelen
Naast de identificatie van de pakketinformatie voor het pakketje dat is gevallen als gevolg van het mislukken van de herhalingscontrole, moet tegelijkertijd een pakketopname voor de betreffende IPsec-stroom worden verzameld. Dit helpt bij het onderzoek van het ESP-sequentienummerpatroon binnen dezelfde IPsec-stroom om de reden voor de herhalingsval te bepalen. Voor meer informatie over het gebruik van de Embedded Packet Capture (EPC) op Cisco IOS XE-routers, raadpleegt u Embedded Packet Capture for Cisco IOS en Cisco IOS XE Configuration Example.
Nummeranalyse van de wireshark-reeks 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. Controleer eerst of de volgnummercontrole is ingeschakeld onder Voorkeuren > Protocollen > ESP zoals weergegeven in de afbeelding:
Controleer vervolgens op problemen met ESP-volgnummers onder Analyseren > Deskundige informatie als volgt:
Klik op een van de pakketten met het verkeerde volgnummer om de volgende aanvullende gegevens te verkrijgen:
Oplossing
Nadat de peer is geïdentificeerd en pakketopname is verzameld voor de replay-drops, kunnen drie mogelijke scenario's de replay-mislukkingen verklaren:
- Het is een geldig pakket dat vertraagd is:
Met pakketopnamen wordt bevestigd of het pakket daadwerkelijk geldig is en of het probleem onbeduidend is (als gevolg van netwerklatentie of problemen met het transmissiepad) of een meer diepgaande probleemoplossing vereist. De opname toont bijvoorbeeld een pakket met een volgnummer X dat niet in orde is en de grootte van het afspeelvenster is momenteel ingesteld op 64. Als een geldig pakket met volgnummer (X + 64) arriveert voordat pakket X, wordt het venster naar rechts verschoven en wordt pakket X gedropt vanwege een herhalingsfout.
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 aanvaardbaar worden geacht en de legitieme pakketten niet worden weggegooid. Standaard is de grootte van het afspeelvenster vrij klein (venstergrootte 64). Als u de grootte verhoogt, verhoogt dit het risico op een aanval niet sterk. Raadpleeg voor informatie over het configureren van een IPsec Anti-Replay-venster het venster IPsec Anti-Replay configureren: document uitbreiden en uitschakelen. - Dit is te wijten aan de QoS-configuratie op het verzendeindpunt:
Als pakketbestellingen na IPsec worden veroorzaakt door QoS-configuratie op het IPsec-verzendende apparaat, is een mogelijke beperking het gebruik van Multiple Sequence Number Space per IPsec SA dat beschikbaar is op Cisco IOS XE-platforms.
- Het is een dubbel pakket dat eerder is ontvangen:
Als dit het geval is, kunnen twee of meer pakketten met hetzelfde ESP-volgnummer binnen dezelfde IPsec-stroom worden waargenomen bij het vastleggen van pakketten. In dit geval wordt de pakketval verwacht omdat de IPsec-afspeelbeveiliging werkt zoals bedoeld om herhalingsaanvallen in het netwerk te voorkomen, en het syslog is slechts informatief. Als deze aandoening aanhoudt, moet deze worden onderzocht als een potentiële bedreiging voor de veiligheid.
Aanvullende informatie
Problemen oplossen Replay-fouten op oudere routers met Cisco IOS Classic
De IPsec-replay-drops op de oudere ISR G2-routers die de Cisco IOS gebruiken, verschillen van routers die de Cisco IOS XE gebruiken, zoals hier wordt getoond:
%CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed connection id=529, sequence number=13
De uitvoer van het bericht geeft geen informatie over het peer-IP-adres of de SPI. Om problemen op dit platform op te lossen, gebruikt u de "conn-id" in de foutmelding. Identificeer de "conn-id" in de foutmelding 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 uniek identificeren van het gedropte pakket in de pakketopname.
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 herhalingsval van het 10.2.0.200 peer-adres met een inkomende ESP SA-SPI van 0xE7EDE943. Uit het logbericht zelf kan ook worden opgemaakt dat het ESP-volgnummer voor het gedropte pakket 13 is. De combinatie van peer-adres, SPI-nummer en het ESP-volgnummer kan worden gebruikt om op unieke wijze het pakket te identificeren dat bij het vastleggen van pakketten is gevallen.
Werken met eerdere Cisco IOS XE-software
Op routers die de eerdere Cisco IOS XE-releases uitvoeren, kan de "REPLAY_ERROR" die in het syslog wordt gerapporteerd, de werkelijke IPsec-stroom niet afdrukken met de peer-informatie waar het opnieuw afgespeelde pakket is neergezet, zoals hier wordt getoond:
%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 in het syslog-bericht is afgedrukt als invoerparameter SA Handle in deze opdracht, om de IPsec-stroominformatie op de Quantum Flow Processor (QFP) op te halen:
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
- IPSec VPN (V3PN)-oplossing voor spraak- en videocommunicatie — Referentienetwerkontwerp
- IPsec Anti-Replay Window: Uitbreiden en uitschakelen.
- Technische ondersteuning en documentatie – Cisco Systems
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
7.0 |
14-Sep-2026
|
hercertificering |
6.0 |
21-Nov-2025
|
Machinevertaling, branding, opmaak en enkele vaste koppelingen. |
5.0 |
04-Sep-2024
|
Bijgewerkte SEO, machinevertaling, referenties en opmaak. |
2.0 |
13-Feb-2022
|
Aanvullende informatie |
1.0 |
15-Dec-2013
|
Eerste vrijgave |
Feedback