De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Dit document beschrijft een probleem dat verband houdt met IPsec-storingen (Internet Protocol Security) bij een antiretrospectieve controle en biedt mogelijke oplossingen.
Een replay aanval is een vorm van netwerkaanval waarin de geldige gegevenstransmissie kwaadwillig of frauduleus wordt geregistreerd en later herhaald. Het is een poging om de beveiliging te ondermijnen door iemand die legitieme communicatie registreert en deze herhaalt om zich voor te doen als een geldige gebruiker en een negatieve impact op legitieme verbindingen te veroorzaken of te verstoren.
Een reeksnummer dat monotonisch wordt verhoogd, wordt per IPsec aan elk versleuteld pakket toegewezen om bescherming tegen terugspelen tegen een aanvaller te bieden. Het ontvangende IPsec-eindpunt houdt bij welke pakketten het al heeft verwerkt wanneer het deze getallen en een glijdend venster met acceptabele volgnummers gebruikt. De standaard grootte van het anti-replay venster in de Cisco IOS®-implementatie is 64 pakketten, zoals in deze afbeelding wordt getoond:
Wanneer een IPsec-tunneleindpunt anti-replay bescherming heeft ingeschakeld, wordt het inkomende IPsec-verkeer als volgt verwerkt:
In de gevallen waarin een fout bij de terugspeelcontrole optreedt en het pakket wordt gedropt, genereert de router een Syslog-bericht dat hier op lijkt:
%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 detectie van herhaling is gebaseerd op de veronderstelling dat IPsec Security Association (SA) slechts tussen twee peers bestaat. Group Encrypted Transport VPN (GETVPN) gebruikt één IPsec SPA tussen veel peers. Als gevolg hiervan maakt GETVPN gebruik van een geheel ander anti-replay controlemechanisme genaamd Time Based Anti-Replay Failure. Dit document is alleen van toepassing op tegengebaseerde anti-replay voor point-to-point IPsec-tunnels.
Opmerking: bescherming tegen terugspelen is een belangrijke beveiligingsservice die door het IPsec-protocol wordt geboden. IPsec anti-replay uitgeschakelde heeft beveiligingsimplicaties en moet met discretie worden uitgevoerd.
Zoals eerder beschreven, is het doel van terugspeelcontroles bescherming te bieden tegen kwaadwillige herhalingen van pakketten. Er zijn echter enkele scenario's waarin een mislukte terugspeelcontrole niet het gevolg kan zijn van een kwaadaardige reden:
De sleutel tot het oplossen van IPsec-terugspeeldruppels is om te identificeren welke pakketten wegens terugspelen worden laten vallen, en gebruik pakketopnamen om te bepalen of deze pakketten inderdaad teruggespeeld pakketten of pakketten zijn die op de ontvangende router buiten het terugspeelvenster zijn gearriveerd. Om de gedropte pakketten correct aan te passen aan wat in het snuffelspoor wordt opgenomen, 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.
Op routerplatforms die de Cisco IOS® XE uitvoeren, worden informatie over de peer en de IPsec Security Parameter Index (SPI) in het Syslog-bericht afgedrukt wanneer er een val optreedt, om problemen met de terugspelen te helpen oplossen. Een belangrijk element dat nog steeds niet wordt vermeld, is het ESP-volgnummer. Het ESP-volgnummer wordt gebruikt om een IPsec-pakket binnen een bepaalde IPsec-stroom uniek te identificeren. Zonder het opeenvolgingsaantal, wordt het moeilijk om precies te identificeren welk pakket in een pakketopname wordt gelaten vallen.
De Cisco IOS XE datapath-pakkettraceringsfunctie kan in deze situatie worden gebruikt wanneer de terugspeeldruppel 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
Voltooi deze stappen met de functie voor het overtrekken van pakketten om het ESP-volgnummer voor het gedropte pakket te helpen identificeren:
Stap 1. Stel het platform voorwaardelijk debug filter in om verkeer van het peer apparaat aan te passen:
debug platform condition ipv4 10.2.0.200/32 ingress
debug platform condition start
Stap 2. Packet-overtrekken met de kopieeroptie inschakelen om de pakketheader-informatie te kopiëren:
debug platform packet enable
debug platform packet-trace packet 64
debug platform packet-trace copy packet input l3 size 100
Stap 3. Wanneer terugspeelfouten worden gedetecteerd, gebruikt u de buffer voor pakkettracering om het pakket te identificeren dat is gevallen als gevolg van terugspelen, en het ESP-volgnummer wordt 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 output toont aan dat pakketnummers 6 en 7 worden gelaten vallen, zodat kunnen zij nu in detail 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 bij de IP-header (of 4 bytes van de payloadgegevens van het IP-pakket), zoals in de vorige uitvoer vet wordt benadrukt. In dit specifieke voorbeeld is het ESP-volgnummer voor het gedropte pakket 0x6.
Naast de identificatie van de pakketinformatie voor het pakket dat als gevolg van een fout bij de terugspeelcontrole is gedropt, moet een pakketopname voor de IPsec-stroom in kwestie tegelijkertijd worden verzameld. Dit helpt bij het onderzoek van het ESP sequentienummerpatroon binnen dezelfde IPsec-stroom om de reden voor de terugspeelval te bepalen. Zie Ingesloten pakketvastlegging voor Cisco IOS XE-routers en Cisco IOS XE Configuration Voorbeeld voor meer informatie over het gebruik van de ingesloten pakketvastlegging voor Cisco IOS en Cisco IOS XE.
Zodra het pakket voor de versleutelde (ESP) pakketten op de WAN-interface is verzameld, kan Wireshark worden gebruikt om ESP-sequentienummer te analyseren voor eventuele anomalieën van het volgnummer. Zorg er eerst voor dat Sequence Number Check is ingeschakeld onder Voorkeuren > Protocollen > ESP zoals in de afbeelding:
Controleer vervolgens of er problemen zijn met het ESP-volgnummer onder Analyse > informatie van experts als volgt:
Klik op een van de pakketten met het verkeerde volgnummer om als volgt aanvullende informatie te verkrijgen:
Nadat de peer is geïdentificeerd en pakketopname is verzameld voor de terugspeeldruppels, kunnen drie mogelijke scenario's de terugspeelfouten verklaren:
Tip: Als het terugspeelvenster is uitgeschakeld of gewijzigd in het IPSec-profiel dat op een Virtual Tunnel Interface (VTI) wordt gebruikt, worden de wijzigingen niet van kracht totdat het beveiligingsprofiel is verwijderd en opnieuw is toegepast of de tunnelinterface is hersteld. Dit wordt verwacht omdat IPsec-profielen een sjabloon zijn die wordt gebruikt om een tunnelprofielkaart te maken wanneer de tunnelinterface wordt opgestart. Als de interface reeds omhoog is, beïnvloeden de veranderingen in het profiel niet de tunnel tot de interface wordt teruggesteld.
Opmerking: de vroege aggregatie services router (ASR) 1000 modellen (zoals de ASR 1000 met ESP5, ESP10, ESP20 en ESP40, samen met de ASR 1001) ondersteunen geen venstergrootte van 1024, ook al stond de CLI die configuratie toe. Dientengevolge, kan de venstergrootte die in de show crypto ipsec als beveloutput wordt gemeld niet correct zijn. Gebruik de show crypto ipsec als peer ip-adres platform opdracht om de hardware anti-replay venstergrootte te verifiëren. De standaardvenstergrootte is 64 pakketten op alle platforms. Raadpleeg voor meer informatie Cisco bug-id CSC45946. De latere Cisco IOS XE-routerplatforms (zoals de ASR1K met ESP100 en ESP200, de ASR1001-X en ASR1002-X, geïntegreerde services router (ISR) 4000 Series routers en Catalyst 8000 Series routers) ondersteunen wel een venstergrootte van 1024 pakketten in versies 15.2(2)S en hoger.
Opmerking: storingen in de terugspeelknop worden alleen gezien als er een verificatiealgoritme is ingeschakeld in de IPsec-transformatieset. Een andere manier om deze foutmelding te onderdrukken is om authenticatie uit te schakelen en alleen encryptie uit te voeren; dit wordt echter sterk ontmoedigd vanwege de veiligheidsimplicaties van uitgeschakelde verificatie.
De IPsec-replay valt op de oudere ISR G2-routers die Cisco IOS gebruiken, en verschilt van routers die Cisco IOS XE gebruiken, zoals hier wordt getoond:
%CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed connection id=529, sequence number=13
De berichtoutput verstrekt niet het peer IP adres of de informatie van SPI. Om problemen op dit platform op te lossen, gebruik de "conn-id" in de foutmelding. Identificeer de "conn-id" in de foutmelding en zoek ernaar in de show crypto ipsec als 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.
Opmerking: met 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 uit deze output kan worden opgemaakt, is de replay drop van het 10.2.0.200 peer adres met een inkomende ESP SA SPI van 0xE7EDE943. Het kan ook van het logboekbericht zelf worden genoteerd dat het ESP opeenvolgingsaantal voor het gelaten vallen pakket 13 is. De combinatie van peer-adres, SPI-nummer en het ESP-volgnummer kan worden gebruikt om het pakket dat in de pakketopname is gevallen, op unieke wijze te identificeren.
Opmerking: het Cisco IOS Syslog-bericht is snelheidsbeperkt voor het dataplane-pakket dat naar één per minuut daalt. Om een nauwkeurige telling van het nauwkeurige aantal gelaten vallen pakketten te krijgen, gebruik de show crypto ipsec als detail opdracht zoals eerder getoond.
Op routers die met de eerdere Cisco IOS XE-releases werken, kan de "REPLAY_ERROR" die in Syslog wordt gerapporteerd, de werkelijke IPsec-stroom niet afdrukken met de peer-informatie waar het opnieuw weergegeven pakket wordt gedropt, 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 informatie over IPsec peer en flow te identificeren, gebruikt u de in het Syslog-bericht afgedrukte Handle Data Plane (DP) als de invoerparameter SA Handle in deze opdracht om de IPsec-stroominformatie over 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 gebruikt worden 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 output opnieuw gericht aan bootflash. Om deze uitvoer te zien, gebruik de opdracht meer bootflash:replay-error.txt.
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
5.0 |
04-Sep-2024 |
Bijgewerkt SEO, machinevertaling, referenties en opmaak. |
4.0 |
07-Jul-2023 |
Hercertificering |
2.0 |
13-Feb-2022 |
Aanvullende informatie |
1.0 |
15-Dec-2013 |
Eerste vrijgave |