Solucionar Falhas de Verificação de Antirrepetição de IPsec
Contents
Introdução
Este documento descreve um problema relacionado a falhas de verificação antirreprodução do Internet Protocol Security (IPsec) e fornece soluções possíveis.
Informações de Apoio
Uma visão geral dos ataques de repetição
Um ataque de repetição é uma forma de ataque à rede em que a transmissão de dados válida é gravada de forma maliciosa ou fraudulenta e depois repetida. É uma tentativa de subverter a segurança por alguém que registra comunicações legítimas e as repete para se passar por um usuário válido e interromper ou causar um impacto negativo em conexões legítimas.
Proteção de Verificação de Repetição IPsec
Um número de sequência que aumenta de forma monótona é atribuído a cada pacote criptografado pelo IPsec para fornecer proteção antirreprodução contra um invasor. O ponto final de IPsec receptor rastreia quais pacotes já foram processados quando ele usa esses números e uma janela móvel de números de sequência aceitáveis. O tamanho padrão da janela de antireprodução na implementação do Cisco IOS® é de 64 pacotes, como mostrado nesta imagem:
Quando um ponto final de túnel IPsec tem proteção antirreprodução habilitada, o tráfego IPsec de entrada é processado da seguinte maneira:
- Se o número de sequência cair dentro da janela e não tiver sido recebido anteriormente, a integridade do pacote será verificada. Se o pacote passar na verificação de integridade, ele será aceito e o roteador marcará que esse número de sequência foi recebido. Por exemplo, no diagrama anterior, um pacote com o número de sequência ESP (Encapsulating Security Payload) de 162 está dentro da janela de repetição.
- Se o número de sequência cair dentro da janela, mas tiver sido recebido anteriormente, o pacote será descartado. Esse pacote duplicado é descartado e a queda é registrada no contador de queda de repetição.
- Se o número de sequência for maior que o número de sequência mais alto na janela, a integridade do pacote será verificada. Se o pacote passar na verificação de integridade, a janela deslizante será movida para a direita. Por exemplo, se um pacote válido com um número de sequência de 189 for recebido, a nova borda direita da janela será definida como 189 e a borda esquerda será 125 (189 - 64 [tamanho da janela]).
- Se o número de sequência for menor que a borda esquerda, o pacote será descartado e registrado no contador de repetição. Este é considerado um pacote fora de ordem.
Nos casos em que ocorre uma falha de verificação de repetição e o pacote é descartado, o roteador gera uma mensagem de syslog semelhante a esta:
%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
Problemas que podem causar quedas de repetição de IPsec
Conforme descrito anteriormente, a finalidade das verificações de repetição é proteger contra repetições mal-intencionadas de pacotes legítimos. Algumas das condições comuns que podem resultar em falha na verificação de repetição incluem:
- O erro pode resultar de pacotes reordenados no caminho de rede entre os pontos finais do túnel durante a entrega. Isso provavelmente pode ocorrer se houver vários caminhos de rede entre os pares.
- O erro pode ser causado por caminhos de processamento de pacotes desiguais dentro do Cisco IOS. Por exemplo, os pacotes IPsec fragmentados que exigem remontagem de IP antes da descriptografia podem ser atrasados o suficiente, de modo que fiquem fora da janela de repetição no momento em que forem processados.
- O erro pode ser causado pela Qualidade de Serviço (QoS) habilitada no ponto de extremidade IPsec de envio ou no caminho da rede. Com a implementação do Cisco IOS, a criptografia IPsec ocorre antes da QoS na direção de saída. Certos recursos de QoS, como o enfileiramento de baixa latência (LLQ), podem fazer com que a entrega de pacotes IPsec fique fora de serviço e seja descartada pelo endpoint receptor devido a uma falha de verificação de repetição.
- Um problema operacional/de configuração de rede pode duplicar pacotes enquanto transitam pela rede.
- Um invasor (man-in-the-middle) poderia atrasar, descartar e duplicar o tráfego ESP.
Solucionar Problemas de Quedas de Repetição de IPsec
A chave para solucionar problemas de quedas de repetição de IPsec é identificar quais pacotes são descartados devido à repetição e usar capturas de pacotes para determinar se esses pacotes são realmente pacotes repetidos ou pacotes que chegaram ao roteador receptor fora da janela de repetição. Para corresponder corretamente os pacotes descartados ao que é capturado no farejador de rastreamento, a primeira etapa é identificar o peer e o fluxo de IPsec ao qual os pacotes descartados pertencem e o número de sequência ESP do pacote.
Usar o recurso de rastreamento de pacote de caminho de dados do Cisco IOS XE
Em plataformas de roteador que executam o software Cisco IOS® XE, as informações sobre o peer, bem como o Índice de Parâmetros de Segurança (SPI - Security Parameter Index) IPsec, são impressas na mensagem do Syslog quando ocorre uma queda de repetição para ajudar a identificar o peer e o túnel específico ao qual pertence o pacote descartado. No entanto, o número de sequência ESP não é impresso nesta saída. O número de sequência ESP é usado para identificar exclusivamente um pacote IPsec em um determinado fluxo IPsec. Sem o número de sequência, torna-se difícil identificar exatamente qual pacote é descartado em uma captura de pacote.
O recurso de rastreamento de pacote de caminho de dados do Cisco IOS® XE pode ser usado nesta situação quando a queda de repetição é observada, com esta mensagem de 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
Para ajudar a identificar o número de sequência ESP para o pacote descartado, conclua estes passos com o recurso de rastreamento de pacote:
Etapa 1. Configure a plataforma condicional debug filter para corresponder o tráfego do dispositivo par:
debug platform condition ipv4 10.2.0.200/32 ingress
debug platform condition start
Etapa 2. Habilite o rastreamento de pacote com a opção copy para copiar as informações do cabeçalho do pacote:
debug platform packet-trace packet 64
debug platform packet-trace copy packet input l3 size 100
Etapa 3. Quando erros de repetição forem detectados, use o packet trace buffer para identificar o pacote descartado devido à repetição, e o número de sequência ESP pode ser encontrado no pacote copiado:
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
A saída anterior mostra que os números de pacote 6 e 7 foram descartados, para que possam ser examinados em detalhes agora:
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
O número de sequência ESP tem um deslocamento de 24 bytes do início do cabeçalho IP (ou 4 bytes dos dados de payload do pacote IP), como enfatizado em negrito na saída anterior. Neste exemplo específico, o número de sequência ESP para o pacote descartado é 0x6.
Coletar capturas de pacotes
Além da identificação das informações de pacote para o pacote descartado devido à falha de verificação de repetição, uma captura de pacote para o fluxo IPsec em questão precisa ser coletada simultaneamente. Isso ajuda no exame do padrão de número de sequência ESP dentro do mesmo fluxo de IPsec para ajudar a determinar o motivo da queda de repetição. Para obter detalhes sobre como usar o Embedded Packet Capture (EPC) em roteadores Cisco IOS XE, consulte Exemplo de Configuração do Embedded Packet Capture para Cisco IOS e Cisco IOS XE.
Usar Análise do Número de Sequência do Wireshark
Depois que a captura de pacotes para os pacotes criptografados (ESP) na interface WAN tiver sido coletada, o Wireshark pode ser usado para executar a análise do número de sequência ESP para qualquer anomalia de número de sequência. Primeiro, certifique-se de que a verificação do número de sequência esteja ativada em Preferências > Protocolos > ESP conforme mostrado na imagem:
Em seguida, verifique se há problemas de ESP Sequence Number sob Analyze > Expert, da seguinte maneira:
Clique em qualquer um dos pacotes com o número de sequência incorreto para obter detalhes adicionais da seguinte maneira:
Solução
Depois que o peer é identificado e a captura de pacotes é coletada para as quedas de repetição, três cenários possíveis podem explicar as falhas de repetição:
- É um pacote válido que foi atrasado:
As capturas de pacotes ajudam a confirmar se o pacote é realmente válido e se o problema é insignificante (devido à latência da rede ou a problemas no caminho de transmissão) ou exige uma solução de problemas mais detalhada. Por exemplo, a captura mostra um pacote com um número sequencial de X que chega fora de ordem e o tamanho da janela de repetição está definido atualmente como 64. Se um pacote válido com número sequencial (X + 64) chegar antes do pacote X, a janela é deslocada para a direita e o pacote X é descartado devido a uma falha de repetição.
Nesses cenários, é possível aumentar o tamanho da janela de repetição ou desativar a verificação de repetição para garantir que tais atrasos sejam considerados aceitáveis e que os pacotes legítimos não sejam descartados. Por padrão, o tamanho da janela de repetição é relativamente pequeno (tamanho de janela de 64). Se você aumentar o tamanho, não aumentará muito o risco de um ataque. Para obter informações sobre como configurar uma janela IPsec Anti-Replay, consulte Como configurar a janela IPsec Anti-Replay: Expandindo e Desativando documento. - Isso se deve à configuração de QoS no endpoint de envio:
Se a reordenação de pacotes após o IPsec for causada pela configuração de QoS no dispositivo de envio IPsec, uma possível mitigação será usar o Multiple Sequence Number Space por IPsec SA disponível nas plataformas Cisco IOS XE.
- É um pacote duplicado que foi recebido anteriormente:
Se esse for o caso, dois ou mais pacotes com o mesmo número de sequência ESP dentro do mesmo fluxo IPsec podem ser observados na captura de pacotes. Nesse caso, espera-se que o pacote seja descartado, pois a proteção de repetição do IPsec funciona como planejado para evitar ataques de repetição na rede, e o syslog é apenas informativo. Se essa condição persistir, ela deverá ser investigada como uma possível ameaça à segurança.
Informações adicionais
Identificar e Solucionar Problemas de Repetição em Roteadores Legados com o Cisco IOS Classic
Os descartes de repetição de IPsec nos roteadores ISR G2 Series legados que usam o Cisco IOS são diferentes dos roteadores que usam o Cisco IOS XE, como mostrado aqui:
%CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed connection id=529, sequence number=13
A saída da mensagem não fornece o endereço IP do peer nem informações SPI. Para solucionar problemas nessa plataforma, use o "conn-id" na mensagem de erro. Identifique o "conn-id" na mensagem de erro e procure-o na saída do comando show crypto ipsec sa, já que a repetição é uma verificação por SA (em oposição a uma verificação por peer). A mensagem de syslog também fornece o número de sequência ESP, que pode ajudar a identificar exclusivamente o pacote descartado na captura de pacotes.
Isso é ilustrado aqui:
%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>
Como pode ser visto nessa saída, a queda de repetição é do endereço de peer 10.2.0.200 com um ESP SA SPI de entrada de 0xE7EDE943. Também pode ser observado na própria mensagem de log que o número de sequência ESP para o pacote descartado é 13. A combinação de endereço de peer, número SPI e número de sequência ESP pode ser usada para identificar exclusivamente o pacote descartado na captura de pacote.
Trabalhar com software Cisco IOS XE anterior
Nos roteadores que executam as versões anteriores do Cisco IOS XE, o "REPLAY_ERROR" relatado no syslog não pode imprimir o fluxo IPsec real com as informações de peer em que o pacote repetido é descartado, como mostrado aqui:
%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
Para identificar as informações corretas de peer e fluxo do IPsec, use o Identificador do Plano de Dados (DP - Data Plane) impresso na mensagem do syslog como o parâmetro de entrada SA Handle neste comando, para recuperar as informações de fluxo do IPsec no Processador de Fluxo Quântico (QFP - Quantum Flow Processor):
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>
Um script do Embedded Event Manager (EEM) também pode ser usado para automatizar a coleta de dados:
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"
Neste exemplo, a saída coletada é redirecionada para o flash de inicialização. Para ver essa saída, use o comando more bootflash:replay-error.txt.
Informações Relacionadas
- Projeto de Rede de Referência da Solução VPN IPSec (V3PN) Habilitada para Voz e Vídeo
- Como configurar a janela de antirreprodução IPsec: Expansão e desabilitação.
- Suporte Técnico e Documentação - Cisco Systems
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
7.0 |
14-Sep-2026
|
Recertificação |
6.0 |
21-Nov-2025
|
Tradução automática, marca, formatação e alguns links fixos. |
5.0 |
04-Sep-2024
|
SEO, Tradução Automática, Referências e Formatação Atualizados. |
2.0 |
13-Feb-2022
|
Informações adicionais |
1.0 |
15-Dec-2013
|
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)