Contents

Introdução

Pré-requisitos

Requisitos

Componentes Utilizados

Informações de Apoio

Como coletar e exportar capturas da família de produtos NGFW?

Coletar Capturas FXOS

Habilitar e Coletar Capturas Lina do FTD

Habilitar e Coletar Capturas Snort de FTD

Troubleshooting

Caso 1. Sem TCP SYN na interface de saída

Capturar análise

Ações recomendadas

Causas possíveis e resumo das ações recomendadas

Caso 2. TCP SYN do cliente, TCP RST do servidor

Capturar análise

Ações recomendadas

Caso 3. Handshake triplo do TCP + RST de um endpoint

Capturar análise

3.1 - Handshake triplo do TCP + RST atrasado do cliente

Ações recomendadas

3.2 - Handshake triplo do TCP + FIN/ACK atrasado do cliente + RST atrasado do servidor

Ações recomendadas

3.3 - Handshake triplo do TCP + RST atrasado do cliente

Ações recomendadas

3.4 - Handshake triplo do TCP + RST imediato do servidor

Ações recomendadas

Caso 4. TCP RST do cliente

Capturar análise

Ações recomendadas

Caso 5. Transferência TCP lenta (Cenário 1)

Cenário 1. Transferência lenta

Capturar análise

Ações recomendadas

Cenário 2. Transferência rápida

Caso 6. Transferência TCP lenta (Cenário 2)

Capturar análise

Ações recomendadas

Caso 7. Problema de conectividade de TCP (Corrupção de pacote)

Capturar análise

Ações recomendadas

Caso 8. Problema de conectividade UDP (pacotes ausentes)

Capturar análise

Ações recomendadas

Caso 9. Problema de conectividade HTTPS (Cenário 1)

Capturar análise

Ações recomendadas

Caso 10. Problema de conectividade HTTPS (Cenário 2)

Capturar análise

Ações recomendadas

Caso 11. Problema de conectividade IPv6

Capturar análise

Ações recomendadas

Caso 12. Problema de conectividade intermitente (envenenamento ARP)

Capturar análise

Ações recomendadas

Caso 13. Identificar Identificadores de Objeto (OIDs - Object Identifiers) SNMP que causam problemas na CPU

Capturar análise

Ações recomendadas

Informações Relacionadas

Introdução

Este documento descreve várias técnicas de análise de captura de pacotes que visam solucionar problemas de rede de forma eficaz.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

- Arquitetura da plataforma Firepower

- Logs de NGFW

- Packet Tracer de NGFW

Além disso, antes de começar a analisar capturas de pacotes, é altamente recomendável atender a estes requisitos:

- Conhecer a operação do protocolo - Não comece a verificar uma captura de pacote se não entender como o protocolo capturado opera.

- Conhecer a topologia - Você deve conhecer os dispositivos de trânsito de ponta a ponta. Se isso não for possível, você deve pelo menos conhecer os dispositivos upstream e downstream.

- Conheça o dispositivo - Você deve saber como o dispositivo lida com pacotes, quais são as interfaces envolvidas (entrada/saída), qual é a arquitetura do dispositivo e quais são os vários pontos de captura.

- Conhecer a configuração - Você deve saber como um fluxo de pacote deve ser tratado pelo dispositivo em termos de:

- Interface de roteamento/saída

- Políticas aplicadas

- Tradução de Endereço de Rede (NAT)

- Conhecer as ferramentas disponíveis - Junto com as capturas, é recomendável estar pronto para aplicar outras ferramentas e técnicas (como registro e rastreadores) e, se necessário, correlacioná-las com os pacotes capturados

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

- A maioria dos cenários é baseada no FP4140 executando o software FTD 6.5.x.

- FMC executando o software 6.5.x.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

A captura de pacotes é uma das ferramentas de solução de problemas mais negligenciadas disponíveis atualmente. Diariamente, o Cisco TAC resolve muitos problemas com a análise dos dados capturados.

O objetivo deste documento é ajudar os engenheiros de rede e segurança a identificar e solucionar problemas comuns de rede com base principalmente na análise de captura de pacotes.

Todos os cenários apresentados neste documento são baseados em casos de usuários reais vistos no Centro de Assistência Técnica da Cisco (TAC).

O documento aborda as capturas de pacotes do ponto de vista do Cisco Next-Generation Firewall (NGFW), mas os mesmos conceitos também se aplicam a outros tipos de dispositivos.

Como coletar e exportar capturas da família de produtos NGFW?

No caso de um dispositivo Firepower (1xxx, 21xx, 41xx, 93xx) e um aplicativo Firepower Threat Defense (FTD), um processamento de pacote pode ser visualizado conforme mostrado na imagem.

1. Um pacote entra na interface de entrada e é tratado pelo switch interno do chassi.

2. O pacote entra no mecanismo FTD Lina, que faz principalmente verificações de L3/L4.

3. Se a política exigir que o pacote seja inspecionado pelo mecanismo Snort (principalmente inspeção L7).

4. O mecanismo Snort retorna um veredito para o pacote.

5. O mecanismo LINA descarta ou encaminha o pacote de acordo com a conclusão do Snort.

6. O pacote sai do chassi através do switch interno do chassi.

Com base na arquitetura mostrada, as capturas de FTD podem ser realizadas em três (3) locais diferentes:

- FXOS

- Mecanismo FTD Lina

- Mecanismo Snort de FTD

Coletar Capturas FXOS

O processo é descrito neste documento:

https://www.cisco.com/c/en/us/td/docs/security/firepower/fxos/fxos271/web-guide/b_GUI_FXOS_ConfigGuide_271/troubleshooting.html#concept_E8823CC63C934A909BBC0DF12F301DED

As capturas de FXOS só podem ser feitas na direção de entrada do ponto de vista interno do switch são mostradas na imagem aqui.

Aqui são mostrados dois pontos de captura por direção (devido à arquitetura de switch interno).

Os pacotes capturados nos pontos 2, 3 e 4 têm uma tag de rede virtual (VNTag).

Observação: as capturas no nível do chassi FXOS estão disponíveis apenas nas plataformas FP41xx e FP93xx. FP1xxx e FP21xx não fornecem esse recurso.

Habilitar e Coletar Capturas Lina do FTD

Principais pontos de captura:

- Interface de entrada

- Interface de saída

- Caminho de segurança acelerado (ASP)

Você pode usar a interface do usuário do Firepower Management Center (FMC UI) ou a CLI do FTD para ativar e coletar as capturas do FTD Lina.

Habilite a captura a partir do CLI na interface INSIDE:

firepower# capture CAPI interface INSIDE match icmp host 192.168.103.1 host 192.168.101.1

Essa captura corresponde ao tráfego entre os IPs 192.168.103.1 e 192.168.101.1 em ambas as direções.

Habilite a captura ASP para ver todos os pacotes descartados pelo mecanismo FTD Lina:

firepower# capture ASP type asp-drop all

Exportar uma captura Lina de FTD para um servidor FTP:

firepower# copy /pcap capture:CAPI ftp://ftp_username:ftp_password@192.168.78.73/CAPI.pcap

Exportar uma captura FTD Lina para um servidor TFTP:

firepower# copy /pcap capture:CAPI tftp://192.168.78.73

A partir da versão 6.2.x do FMC, você pode ativar e coletar capturas FTD Lina da interface do FMC.

Outra maneira de coletar capturas de FTD de um firewall gerenciado pelo FMC é essa.

Passo 1

No caso de captura LINA ou ASP, copie a captura para o disco FTD.

firepower# copy /pcap capture:capin disk0:capin.pcap

Source capture name [capin]?

Destination filename [capin.pcap]?

!!!!

Passo 2

Navegue até o modo especialista, localize a captura salva e copie-a para o local /ngfw/var/common:

firepower#

Console connection detached.

> expert

admin@firepower:~$ sudo su

Password:

root@firepower:/home/admin# cd /mnt/disk0

root@firepower:/mnt/disk0# ls -al | grep pcap

-rwxr-xr-x 1 root root     24 Apr 26 18:19 CAPI.pcap

-rwxr-xr-x 1 root root  30110 Apr  8 14:10 capin.pcap

-rwxr-xr-x 1 root root   6123 Apr  8 14:11 capin2.pcap

root@firepower:/mnt/disk0# cp capin.pcap /ngfw/var/common

Etapa 3

Faça login no FMC que gerencia o FTD e navegue até Devices > Device Management. Localize o dispositivo FTD e selecione o ícone Solução de problemas:

Passo 4

Selecione Solução de problemas avançada:

Especifique o nome do arquivo de captura e selecione Download:

Para obter mais exemplos sobre como habilitar/coletar capturas da interface do usuário do FMC, consulte este documento:

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212474-working-with-firepower-threat-defense-f.html

Habilitar e Coletar Capturas Snort de FTD

O ponto de captura é mostrado na imagem aqui.

Habilitar captura no nível do Snort:

> capture-traffic

Please choose domain to capture traffic from:

0 - br1

1 - Router

Selection? 1

Please specify tcpdump options desired.

(or enter '?' for a list of supported options)

Options: -n host 192.168.101.1

Para gravar a captura em um arquivo com o nome capture.pcap e copiá-lo via FTP para um servidor remoto:

> capture-traffic

Please choose domain to capture traffic from:

0 - br1

1 - Router

Selection? 1

Please specify tcpdump options desired.

(or enter '?' for a list of supported options)

Options: -w capture.pcap host 192.168.101.1

CTRL + C <- to stop the capture

> file copy 10.229.22.136 ftp / capture.pcap

Enter password for ftp@10.229.22.136:

Copying capture.pcap

Copy successful.

>

Para obter mais exemplos de captura em nível de Snort que incluam diferentes filtros de captura, marque este documento:

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212474-working-with-firepower-threat-defense-f.html

Troubleshooting

Caso 1. Sem TCP SYN na interface de saída

A topologia é mostrada na imagem aqui:

Descrição do problema: o HTTP não funciona

Fluxo afetado:

IP orig.: 192.168.0.100

IP do Horário de Verão: 10.10.1.100

Protocolo: TCP 80

Capturar análise

Habilitar capturas no mecanismo LINA do FTD:

firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100

firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100

Capturas - Cenário Funcional:

Como linha de base, é sempre muito útil ter capturas de um cenário funcional.

A captura feita na interface NGFW INSIDE é como mostrado na imagem:

Pontos principais:

1. Handshake triplo do TCP.

2. Intercâmbio de dados bidirecional.

3. Não há atrasos entre os pacotes (com base na diferença de tempo entre os pacotes)

4. O MAC origem é o dispositivo downstream correto.

A captura feita na interface NGFW OUTSIDE é mostrada na imagem aqui:

Pontos principais:

1. Os mesmos dados da captura CAPI.

2. O MAC destino é o dispositivo upstream correto.

Capturas - cenário não funcional

Na CLI do dispositivo, as capturas são assim:

firepower# show capture

capture CAPI type raw-data interface INSIDE [Capturing - 484 bytes]

match ip host 192.168.0.100 host 10.10.1.100

capture CAPO type raw-data interface OUTSIDE [Capturing - 0 bytes]

match ip host 192.168.0.100 host 10.10.1.100

Conteúdo CAPI:

firepower# show capture CAPI

6 packets captured

1: 11:47:46.911482   192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

2: 11:47:47.161902   192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

3: 11:47:49.907683   192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

4: 11:47:50.162757   192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

5: 11:47:55.914640   192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,nop,sackOK>

6: 11:47:56.164710   192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,nop,sackOK>

firepower# show capture CAPO

0 packet captured

0 packet shown

Esta é a imagem da captura CAPI no Wireshark:

Pontos principais:

1. Somente os pacotes TCP SYN são vistos (sem handshake triplo do TCP).

2. Há duas sessões TCP (portas de origem 3171 e 3172) que não podem ser estabelecidas. O cliente de origem reenvia os pacotes TCP SYN. Esses pacotes retransmitidos são identificados pelo Wireshark como retransmissões de TCP.

3. As retransmissões de TCP ocorrem a cada ~3 e depois a cada 6 segundos etc.

4. O endereço MAC origem é proveniente do dispositivo downstream correto.

Com base nas duas capturas, pode concluir-se que:

- Um pacote de 5 tuplas específicas (src/dst IP, src/dst port, protocol) chega ao firewall na interface esperada (INSIDE).

- Um pacote não deixa o firewall na interface esperada (EXTERNA).

Ações recomendadas

As ações listadas nesta seção têm como objetivo restringir ainda mais o problema.

Ação 1. Verifique o rastreamento de um pacote emulado.

Use a ferramenta packet-tracer para ver como um pacote deve ser tratado pelo firewall. Caso o pacote seja descartado pela política de acesso do firewall, o rastreamento do pacote emulado será semelhante a esta saída:

firepower# packet-tracer input INSIDE tcp 192.168.0.100 11111 10.10.1.100 80

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 3

Type: ROUTE-LOOKUP

Subtype: Resolve Egress Interface

Result: ALLOW

Config:

Additional Information:

found next-hop 192.168.2.72 using egress ifc  OUTSIDE

Phase: 4

Type: ACCESS-LIST

Subtype: log

Result: DROP

Config:

access-group CSM_FW_ACL_ global

access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268439946 event-log flow-start

access-list CSM_FW_ACL_ remark rule-id 268439946: ACCESS POLICY: FTD_Policy - Default

access-list CSM_FW_ACL_ remark rule-id 268439946: L4 RULE: DEFAULT ACTION RULE

Additional Information:

Result:

input-interface: INSIDE

input-status: up

input-line-status: up

output-interface: OUTSIDE

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x00005647a4f4b120 flow (NA)/NA

Ação 2. Verifique os rastreamentos de pacotes ativos.

Ative o rastreamento de pacotes para verificar como os pacotes TCP SYN reais são tratados pelo firewall. Por padrão, somente os primeiros 50 pacotes de entrada são rastreados:

firepower# capture CAPI trace

Limpe o buffer de captura:

firepower# clear capture /all

Caso o pacote seja descartado pela Política de Acesso do firewall, o rastreamento será semelhante a esta saída:

firepower# show capture CAPI packet-number 1 trace

6 packets captured

1: 12:45:36.279740       192.168.0.100.3630 > 10.10.1.100.80: S 2322685377:2322685377(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 3

Type: ROUTE-LOOKUP

Subtype: Resolve Egress Interface

Result: ALLOW

Config:

Additional Information:

found next-hop 192.168.2.72 using egress ifc  OUTSIDE

Phase: 4

Type: ACCESS-LIST

Subtype: log

Result: DROP

Config:

access-group CSM_FW_ACL_ global

access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268439946 event-log flow-start

access-list CSM_FW_ACL_ remark rule-id 268439946: ACCESS POLICY: FTD_Policy - Default

access-list CSM_FW_ACL_ remark rule-id 268439946: L4 RULE: DEFAULT ACTION RULE

Additional Information:

Result:

input-interface: INSIDE

input-status: up

input-line-status: up

output-interface: OUTSIDE

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x00005647a4f4b120 flow (NA)/NA

1 packet shown

Ação 3. Verifique os logs do FTD Lina.

Para configurar o Syslog no FTD via FMC, consulte este documento:

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/200479-Configure-Logging-on-FTD-via-FMC.html

É altamente recomendável ter um servidor Syslog externo configurado para logs FTD Lina. Se não houver um servidor Syslog remoto configurado, habilite os logs de buffer local no firewall enquanto soluciona os problemas. A configuração de log mostrada neste exemplo é um bom ponto inicial:

firepower# show run logging

…

logging enable

logging timestamp

logging buffer-size 1000000

logging buffered informational

Defina o pager do terminal como 24 linhas para controlar o pager do terminal:

firepower# terminal pager 24

Limpe o buffer de captura:

firepower# clear logging buffer

Teste a conexão e verifique os logs com um filtro do analisador. Neste exemplo, os pacotes são descartados pela Política de acesso de firewall:

firepower# show logging | include 10.10.1.100

Oct 09 2019 12:55:51: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3696 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]

Oct 09 2019 12:55:51: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3697 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]

Oct 09 2019 12:55:54: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3696 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]

Oct 09 2019 12:55:54: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3697 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]

Ação 4. Verifique as quedas de firewall ASP.

Se você suspeitar que o pacote foi descartado pelo firewall, poderá ver os contadores de todos os pacotes descartados pelo firewall no nível do software:

firepower# show asp drop

Frame drop:

No route to host (no-route)                                                234

Flow is denied by configured rule (acl-drop)                                71

Last clearing: 07:51:52 UTC Oct 10 2019 by enable_15

Flow drop:

Last clearing: 07:51:52 UTC Oct 10 2019 by enable_15

Você pode habilitar as capturas para ver todas as quedas de nível de software do ASP:

firepower# capture ASP type asp-drop all buffer 33554432 headers-only

Dica: se você não estiver interessado no conteúdo do pacote, poderá capturar apenas os cabeçalhos do pacote (opção apenas cabeçalhos). Isso permite capturar muito mais pacotes no buffer de captura. Além disso, você pode aumentar o tamanho do buffer de captura (por padrão é 500Kbytes) para um valor de até 32 Mbytes (opção de buffer). Finalmente, a partir do FTD versão 6.3, a opção de tamanho de arquivo permite configurar um arquivo de captura de até 10 GBytes. Nesse caso, você só pode ver o conteúdo da captura em um formato pcap.

Para verificar o conteúdo da captura, você pode usar um filtro para restringir sua pesquisa:

firepower# show capture ASP | include 10.10.1.100

18: 07:51:57.823672   192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

19: 07:51:58.074291   192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

26: 07:52:00.830370   192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

29: 07:52:01.080394   192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

45: 07:52:06.824282   192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,nop,sackOK>

46: 07:52:07.074230   192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,nop,sackOK>

Nesse caso, como os pacotes já estão rastreados no nível da interface, o motivo para a queda não é mencionado na captura ASP. Lembre-se de que um pacote só pode ser rastreado em um lugar (interface de entrada ou queda de ASP). Nesse caso, é recomendável usar vários descartes de ASP e definir um motivo específico para o descarte. Aqui está uma abordagem recomendada:

1. Limpe os contadores de queda ASP atuais:

firepower# clear asp drop

2. Envie o fluxo cujos problemas você soluciona através do firewall (execute um teste).

3. Verifique novamente os contadores suspensos do ASP e anote os que foram aumentados.

firepower# show asp drop

Frame drop:

No route to host (no-route)                                                234

Flow is denied by configured rule (acl-drop)                                71

4. Habilite a(s) captura(ões) ASP para as quedas específicas vistas:

firepower# capture ASP_NO_ROUTE type asp-drop no-route

firepower# capture ASP_ACL_DROP type asp-drop acl-drop

5. Envie o fluxo cujos problemas você soluciona através do firewall (execute um teste).

6. Verifique as capturas ASP. Nesse caso, os pacotes foram descartados devido a uma rota ausente:

firepower# show capture ASP_NO_ROUTE | include 192.168.0.100.*10.10.1.100

93: 07:53:52.381663   192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

95: 07:53:52.632337   192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

101: 07:53:55.375392   192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

102: 07:53:55.626386   192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

116: 07:54:01.376231   192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,nop,sackOK>

117: 07:54:01.626310   192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,nop,sackOK>

Ação 5. Verifique a tabela de conexão FTD Lina.

Pode haver casos em que você espera que o pacote saia da interface 'X', mas por quaisquer razões ele sai da interface 'Y'. A determinação da interface de saída do firewall é baseada nesta ordem de operação:

1. Pesquisa de Conexão Estabelecida

2. Consulta de conversão de endereço de rede (NAT) - A fase UN-NAT (NAT de destino) tem precedência sobre a pesquisa de PBR e de rota.

3. Roteamento baseado em políticas (PBR)

4. Pesquisa na tabela de roteamento

Para verificar a tabela de conexão do FTD:

firepower# show conn

2 in use, 4 most used

Inspect Snort:

preserve-connection: 2 enabled, 0 in effect, 4 most enabled, 0 most in effect

TCP DMZ  10.10.1.100:80 INSIDE  192.168.0.100:11694, idle 0:00:01, bytes 0, flags aA N1

TCP DMZ  10.10.1.100:80 INSIDE  192.168.0.100:11693, idle 0:00:01, bytes 0, flags aA N1

Pontos principais:

- Com base nas flags (Aa), a conexão é embrionária (semiaberta - somente TCP SYN foi visto pelo firewall).

- Com base nas portas de origem/destino, a interface de entrada é INSIDE e a interface de saída é DMZ.

Isso pode ser visualizado na imagem aqui:

Observação: como todas as interfaces FTD têm um nível de segurança 0, a ordem da interface na saída show conn é baseada no número da interface. Especificamente, a interface com número vpif-num mais alto (número de interface da plataforma virtual) é selecionada como interna, enquanto a interface com número vpif-inferior é selecionada como externa. Você pode ver o valor de interface vpif com o comando show interface detail. Aprimoramento relacionado, o bug da Cisco ID CSCvi15290 ENH: FTD mostra a direcionalidade da conexão na saída 'show conn' do FTD

firepower# show interface detail | i Interface number is|Interface [P|E].*is up

...

Interface Ethernet1/2 "INSIDE", is up, line protocol is up

Interface number is 19

Interface Ethernet1/3.202 "OUTSIDE", is up, line protocol is up

Interface number is 20

Interface Ethernet1/3.203 "DMZ", is up, line protocol is up

Interface number is 22

Observação: a partir da versão 6.5 do software Firepower, a versão 9.13.x do ASA, as saídas dos comandos show conn long e show conn detail fornecem informações sobre o iniciador e o respondedor da conexão

Saída 1:

firepower# show conn long

...

TCP OUTSIDE: 192.168.2.200/80 (192.168.2.200/80) INSIDE: 192.168.1.100/46050 (192.168.1.100/46050), flags aA N1, idle 3s, uptime 6s, timeout 30s, bytes 0

Initiator: 192.168.1.100, Responder: 192.168.2.200

Connection lookup keyid: 228982375

Saída 2:

firepower# show conn detail

...

TCP OUTSIDE: 192.168.2.200/80 INSIDE: 192.168.1.100/46050,

flags aA N1, idle 4s, uptime 11s, timeout 30s, bytes 0

Initiator: 192.168.1.100, Responder: 192.168.2.200

Connection lookup keyid: 228982375

Além disso, o comando show conn long exibe os IPs com NAT dentro de um parêntese no caso de uma conversão de endereço de rede:

firepower# show conn long

...

TCP OUTSIDE: 192.168.2.222/80 (192.168.2.222/80) INSIDE: 192.168.1.100/34792 (192.168.2.150/34792), flags aA N1, idle 0s, uptime 0s, timeout 30s, bytes 0, xlate id 0x2b5a8a4314c0

Initiator: 192.168.1.100, Responder: 192.168.2.222

Connection lookup keyid: 262895

Ação 6. Verifique o cache do firewall Address Resolution Protocol (ARP).

Se o firewall não puder resolver o próximo salto, o firewall descarta silenciosamente o pacote original (TCP SYN nesse caso) e envia continuamente Solicitações ARP até resolver o próximo salto.

Para ver o cache ARP do firewall, use o comando:

firepower# show arp

Além disso, para verificar se há hosts não resolvidos, você pode usar o comando:

firepower# show arp statistics

Number of ARP entries in ASA: 0

Dropped blocks in ARP: 84

Maximum Queued blocks: 3

Queued blocks: 0

Interface collision ARPs Received: 0

ARP-defense Gratuitous ARPS sent: 0

Total ARP retries: 182 < indicates a possible issue for some hosts

Unresolved hosts: 1 < this is the current status

Maximum Unresolved hosts: 2

Se quiser verificar mais a operação ARP, você pode ativar uma captura específica do ARP:

firepower# capture ARP ethernet-type arp interface OUTSIDE

firepower# show capture ARP

...

4: 07:15:16.877914       802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50

5: 07:15:18.020033       802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50

Nesta saída, o firewall (192.168.2.50) tenta resolver o próximo salto (192.168.2.72), mas não há resposta ARP

A saída aqui mostra um cenário funcional com resolução ARP apropriada:

firepower# show capture ARP

2 packets captured

1: 07:17:19.495595       802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50

2: 07:17:19.495946       802.1Q vlan#202 P0 arp reply 192.168.2.72 is-at 4c:4e:35:fc:fc:d8

2 packets shown

firepower# show arp

INSIDE 192.168.1.71 4c4e.35fc.fcd8 9

OUTSIDE 192.168.2.72 4c4e.35fc.fcd8 9

Caso não haja uma entrada ARP no local, um rastreamento de um pacote TCP SYN ao vivo mostra:

firepower# show capture CAPI packet-number 1 trace

6 packets captured

1: 07:03:43.270585       192.168.0.100.11997 > 10.10.1.100.80: S 4023707145:4023707145(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 3

Type: ROUTE-LOOKUP

Subtype: Resolve Egress Interface

Result: ALLOW

Config:

Additional Information:

found next-hop 192.168.2.72 using egress ifc  OUTSIDE

…

Phase: 14

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 4814, packet dispatched to next module

…

Phase: 17

Type: ROUTE-LOOKUP

Subtype: Resolve Egress Interface

Result: ALLOW

Config:

Additional Information:

found next-hop 192.168.2.72 using egress ifc  OUTSIDE

Result:

input-interface: INSIDE

input-status: up

input-line-status: up

output-interface: OUTSIDE

output-status: up

output-line-status: up

Action: allow

Como pode ser visto na saída, o trace mostra Action: allow mesmo quando o próximo salto não está acessível e o pacote é descartado silenciosamente pelo firewall! Nesse caso, a ferramenta packet-tracer também deve ser verificada, pois fornece uma saída mais precisa:

firepower# packet-tracer input INSIDE tcp 192.168.0.100 1111 10.10.1.100 80

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 3

Type: ROUTE-LOOKUP

Subtype: Resolve Egress Interface

Result: ALLOW

Config:

Additional Information:

found next-hop 192.168.2.72 using egress ifc  OUTSIDE

…

Phase: 14

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 4816, packet dispatched to next module

…

Phase: 17

Type: ROUTE-LOOKUP

Subtype: Resolve Egress Interface

Result: ALLOW

Config:

Additional Information:

found next-hop 192.168.2.72 using egress ifc  OUTSIDE

Result:

input-interface: INSIDE

input-status: up

input-line-status: up

output-interface: OUTSIDE

output-status: up

output-line-status: up

Action: drop

Drop-reason: (no-v4-adjacency) No valid V4 adjacency, Drop-location: frame 0x00005647a4e86109 flow (NA)/NA

Em versões recentes do ASA/Firepower, a mensagem anterior foi otimizada para:

Drop-reason: (no-v4-adjacency) No valid V4 adjacency. Check ARP table (show arp) has entry for nexthop., Drop-location: f

Causas possíveis e resumo das ações recomendadas

Se você vir apenas um pacote TCP SYN nas interfaces de entrada, mas nenhum pacote TCP SYN enviado para fora da interface de saída esperada, algumas causas possíveis são:

Possível causa

Ações recomendadas

O pacote é descartado pela política de acesso de firewall.

- Use packet-tracer ou capture w/trace para ver como o firewall lida com o pacote.

- Verifique os logs do firewall.

- Verifique as quedas de firewall ASP (show asp drop ou capture type asp-drop).

- Verifique os eventos de conexão do FMC. Isso pressupõe que a regra tenha o registro em log habilitado.

O filtro de captura está errado.

- Use packet-tracer ou capture w/trace para ver se há conversão de NAT que modifique o IP de origem ou destino. Nesse caso, ajuste o filtro de captura.

- A saída do comando show conn long mostra os IPs com NAT.

O pacote é enviado para uma interface de saída diferente.

- Use packet-tracer ou capture w/trace para ver como o firewall lida com o pacote. Lembre-se da ordem das operações que consideram a determinação da interface de saída, a conexão atual, UN-NAT, PBR e a consulta da tabela de roteamento.

- Verifique os logs do firewall.

- Verifique a tabela de conexão do firewall (show conn).

Se o pacote for enviado a uma interface errada porque corresponde a uma conexão atual, use o comando clear conn address e especifique a tupla 5 da conexão que você deseja limpar.

Não há rota em direção ao destino.

- Use packet-tracer ou capture w/trace para ver como o firewall lida com o pacote.

- Verifique as quedas de firewall ASP (show asp drop) para saber o motivo da queda de no-route.

Não há entrada ARP na interface de saída.

- Verifique o cache ARP do firewall (show arp).

- Use o packet-tracer para ver se há uma adjacência válida.

A interface de saída está inoperante.

Verifique a saída do comando show interface ip brief no firewall e verifique o status da interface.

Caso 2. TCP SYN do cliente, TCP RST do servidor

Esta imagem mostra a topologia:

Descrição do problema: o HTTP não funciona

Fluxo afetado:

IP orig.: 192.168.0.100

IP do Horário de Verão: 10.10.1.100

Protocolo: TCP 80

Capturar análise

Habilitar capturas no mecanismo LINA do FTD.

firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100

firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100

Capturas - cenário não funcional:

A partir da CLI do dispositivo, as capturas são as seguintes:

firepower# show capture

capture CAPI type raw-data trace interface INSIDE [Capturing - 834 bytes]

match ip host 192.168.0.100 host 10.10.1.100

capture CAPO type raw-data interface OUTSIDE [Capturing - 878 bytes]

match ip host 192.168.0.100 host 10.10.1.100

Conteúdo CAPI:

firepower# show capture CAPI

1: 05:20:36.654217   192.168.0.100.22195 > 10.10.1.100.80: S 1397289928:1397289928(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

2: 05:20:36.904311   192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

3: 05:20:36.905043   10.10.1.100.80 > 192.168.0.100.22196: R 1850052503:1850052503(0) ack 2171673259 win 0

4: 05:20:37.414132   192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

5: 05:20:37.414803   10.10.1.100.80 > 192.168.0.100.22196: R 31997177:31997177(0) ack 2171673259 win 0

6: 05:20:37.914183   192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,nop,sackOK>

...

Conteúdo do CAPO:

firepower# show capture CAPO

1: 05:20:36.654507   802.1Q vlan#202 P0 192.168.0.100.22195 > 10.10.1.100.80: S 2866789268:2866789268(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>

2: 05:20:36.904478   802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4785344:4785344(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>

3: 05:20:36.904997   802.1Q vlan#202 P0 10.10.1.100.80 > 192.168.0.100.22196: R 0:0(0) ack 4785345 win 0

4: 05:20:37.414269   802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4235354730:4235354730(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>

5: 05:20:37.414758   802.1Q vlan#202 P0 10.10.1.100.80 > 192.168.0.100.22196: R 0:0(0) ack 4235354731 win 0

6: 05:20:37.914305   802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4118617832:4118617832(0) win 8192 <mss 1380,nop,nop,sackOK>

Esta imagem mostra a captura de CAPI no Wireshark.

Pontos principais:

1. A origem envia um pacote TCP SYN.

2. Um TCP RST é enviado para a origem.

3. A origem retransmite os pacotes TCP SYN.

4. Os endereços MAC estão corretos (nos pacotes de entrada, o endereço MAC origem pertence ao roteador downstream, o endereço MAC destino pertence à interface INTERNA do firewall).

Esta imagem mostra a captura de CAPO no Wireshark:

Pontos principais:

1. A origem envia um pacote TCP SYN.

2. Um TCP RST chega à interface EXTERNA.

3. A origem retransmite os pacotes TCP SYN.

4. Os endereços MAC estão corretos (nos pacotes de saída, o firewall OUTSIDE é o MAC origem, o roteador upstream é o MAC destino).

Com base nas duas capturas, pode concluir-se que:

- O handshake triplo do TCP entre o cliente e o servidor não é concluído

- Há um TCP RST que chega à interface de saída do firewall

- O firewall "fala" com os dispositivos upstream e downstream apropriados (com base nos endereços MAC)

Ações recomendadas

As ações listadas nesta seção têm como objetivo restringir ainda mais o problema.

Ação 1. Verifique o endereço MAC origem que envia o TCP RST.

Verifique se o MAC de destino visto no pacote TCP SYN é o mesmo que o MAC de origem visto no pacote TCP RST.

Esta verificação tem como objetivo confirmar duas coisas:

- Verifique se não há fluxo assimétrico.

- Verifique se o MAC pertence ao dispositivo upstream esperado.

Ação 2. Comparar pacotes de entrada e saída.

Compare visualmente os 2 pacotes no Wireshark para verificar se o firewall não modifica/corrompe os pacotes. Algumas diferenças esperadas são destacadas.

Pontos principais:

1. Os carimbos de data/hora são diferentes. Por outro lado, a diferença deve ser pequena e razoável. Isso depende dos recursos e das verificações de política aplicados ao pacote, bem como da carga no dispositivo.

2. O comprimento dos pacotes pode ser diferente, especialmente se houver um cabeçalho dot1Q adicionado/removido pelo firewall apenas em um lado.

3. Os endereços MAC são diferentes.

4. Um cabeçalho dot1Q pode estar no lugar se a captura tiver sido feita em uma subinterface.

5. Os endereços IP são diferentes caso o NAT ou a conversão de endereço de porta (PAT) seja aplicada ao pacote.

6. As portas origem ou destino são diferentes caso o NAT ou o PAT sejam aplicados ao pacote.

7. Se você desabilitar a opção Relative Sequence Number do Wireshark, verá que os números de sequência/confirmação TCP são modificados pelo firewall devido à aleatoriedade do Initial Sequence Number (ISN).

8. Algumas opções TCP podem ser substituídas. Por exemplo, o firewall altera, por padrão, o tamanho máximo de segmento (MSS) do TCP para 1380, a fim de evitar a fragmentação de pacotes no caminho de trânsito.

Ação 3. Faça uma captura no destino.

Se possível, faça uma captura no próprio destino. Se isso não for possível, realize uma captura o mais perto possível do destino. O objetivo aqui é verificar quem envia o TCP RST (é o servidor de destino ou algum outro dispositivo no caminho?).

Caso 3. Handshake triplo do TCP + RST de um endpoint

Esta imagem mostra a topologia:

Descrição do problema: o HTTP não funciona

Fluxo afetado:

IP orig.: 192.168.0.100

IP do Horário de Verão: 10.10.1.100

Protocolo: TCP 80

Capturar análise

Habilitar capturas no mecanismo LINA do FTD.

firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100

firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100

Capturas - cenário não funcional:

Há algumas maneiras diferentes pelas quais esse problema pode se manifestar em capturas.

3.1 - Handshake triplo do TCP + RST atrasado do cliente

O firewall captura CAPI e CAPO contêm os mesmos pacotes, como mostrado na imagem.

Pontos principais:

1. O handshake triplo do TCP passa pelo firewall.

2. O servidor retransmite o SYN/ACK.

3. O cliente retransmite o ACK.

4. Após ~20 seg, o cliente desiste e envia um TCP RST.

Ações recomendadas

As ações listadas nesta seção têm como objetivo restringir ainda mais o problema.

Ação 1. Faça capturas o mais perto possível dos dois endpoints.

As capturas de firewall indicam que o cliente ACK não foi processado pelo servidor. Isto baseia-se nos seguintes fatos:

- O servidor retransmite o SYN/ACK.

- O cliente retransmite o ACK.

- O cliente envia um TCP RST ou FIN/ACK antes de qualquer dado.

A captura no servidor mostra o problema. O ACK do cliente do handshake triplo TCP nunca chegou:

3.2 - Handshake triplo do TCP + FIN/ACK atrasado do cliente + RST atrasado do servidor

O firewall captura CAPI e CAPO contêm os mesmos pacotes, como mostrado na imagem.

Pontos principais:

1. O handshake triplo do TCP passa pelo firewall.

2. Após ~5 s, o cliente envia um FIN/ACK.

3. Após ~20 seg, o servidor desiste e envia um TCP RST.

Com base nessa captura, pode-se concluir que, embora haja um handshake triplo do TCP através do firewall, parece que ele nunca é realmente concluído em um endpoint (as retransmissões indicam isso).

Ações recomendadas

Idêntico ao do caso 3.1

3.3 - Handshake triplo do TCP + RST atrasado do cliente

O firewall captura CAPI e CAPO contêm os mesmos pacotes, como mostrado na imagem.

Pontos principais:

1. O handshake triplo do TCP passa pelo firewall.

2. Após ~20 seg, o cliente desiste e envia um TCP RST.

Com base nestas capturas, pode concluir-se que:

- Após 5 a 20 segundos, um endpoint desiste e decide encerrar a conexão.

Ações recomendadas

Idêntico ao do caso 3.1

3.4 - Handshake triplo do TCP + RST imediato do servidor

O firewall captura o CAPI e o CAPO contêm esses pacotes, como mostrado na imagem.

Pontos principais:

1. O handshake triplo do TCP passa pelo firewall.

2. Há um TCP RST do servidor alguns milissegundos após o pacote ACK.

Ações recomendadas

Ação: Fazer capturas o mais próximo possível do servidor.

Um TCP RST imediato do servidor pode indicar um servidor com defeito ou um dispositivo no caminho que envia o TCP RST. Faça uma captura no próprio servidor e determine a origem do TCP RST.

Caso 4. TCP RST do cliente

Esta imagem mostra a topologia:

Descrição do problema: o HTTP não funciona.

Fluxo afetado:

IP orig.: 192.168.0.100

IP do Horário de Verão: 10.10.1.100

Protocolo: TCP 80

Capturar análise

Habilitar capturas no mecanismo LINA FTD.

firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100

firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100

Capturas - cenário não funcional:

Estes são os conteúdos CAPI.

firepower# show capture CAPI

14 packets captured

1: 12:32:22.860627   192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

2: 12:32:23.111307   192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

3: 12:32:23.112390   192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0

4: 12:32:25.858109   192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

5: 12:32:25.868698   192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0

6: 12:32:26.108118   192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

7: 12:32:26.109079   192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0

8: 12:32:26.118295   192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0

9: 12:32:31.859925   192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,nop,sackOK>

10: 12:32:31.860902   192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0

11: 12:32:31.875229   192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0

12: 12:32:32.140632   192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0

13: 12:32:32.159995   192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,nop,sackOK>

14: 12:32:32.160956   192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0

14 packets shown

Estes são os conteúdos do CAPO:

firepower# show capture CAPO

11 packets captured

1: 12:32:22.860780   802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 1386249852:1386249852(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>

2: 12:32:23.111429   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 3000518857:3000518857(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>

3: 12:32:23.112405   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 3514091874:3514091874(0) win 0

4: 12:32:25.858125   802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 1386249852:1386249852(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>

5: 12:32:25.868729   802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: R 2968892337:2968892337(0) win 0

6: 12:32:26.108240   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 3822259745:3822259745(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>

7: 12:32:26.109094   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 40865466:40865466(0) win 0

8: 12:32:31.860062   802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 4294058752:4294058752(0) win 8192 <mss 1380,nop,nop,sackOK>

9: 12:32:31.860917   802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: R 1581733941:1581733941(0) win 0

10: 12:32:32.160102   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 4284301197:4284301197(0) win 8192 <mss 1380,nop,nop,sackOK>

11: 12:32:32.160971   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 502906918:502906918(0) win 0

11 packets shown

Os logs do firewall mostram:

firepower# show log | i 47741

Oct 13 2019 13:57:36: %FTD-6-302013: Built inbound TCP connection 4869 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80)

Oct 13 2019 13:57:36: %FTD-6-302014: Teardown TCP connection 4869 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE

Oct 13 2019 13:57:39: %FTD-6-302013: Built inbound TCP connection 4870 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80)

Oct 13 2019 13:57:39: %FTD-6-302014: Teardown TCP connection 4870 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE

Oct 13 2019 13:57:45: %FTD-6-302013: Built inbound TCP connection 4871 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80)

Oct 13 2019 13:57:45: %FTD-6-302014: Teardown TCP connection 4871 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE

Esses logs indicam que há um TCP RST que chega à interface INSIDE do firewall

Captura CAPI no Wireshark:

Siga o primeiro fluxo TCP, como mostrado na imagem.

Em Wireshark, navegue para Edit > Preferences > Protocols > TCP e desmarque a opção Relative sequence numbers como mostrado na imagem.

Esta imagem mostra o conteúdo do primeiro fluxo na captura CAPI:

Pontos principais:

1. O cliente envia um pacote TCP SYN.

2. O cliente envia um pacote TCP RST.

3. O pacote TCP SYN tem um valor de número de sequência igual a 4098574664.

O mesmo fluxo na captura CAPO contém:

Pontos principais:

1. O cliente envia um pacote TCP SYN. O firewall torna aleatório o ISN.

2. O cliente envia um pacote TCP RST.

Com base nas duas capturas, pode concluir-se que:

- Não há handshake triplo TCP entre o cliente e o servidor.

- Há um TCP RST que vem do cliente. O valor do número de sequência TCP RST na captura CAPI é 1386249853.

Ações recomendadas

As ações listadas nesta seção têm como objetivo restringir ainda mais o problema.

Ação 1. Capture o cliente.

Com base nas capturas coletadas no firewall, há uma forte indicação de um fluxo assimétrico. Isso se baseia no fato de que o cliente envia um TCP RST com um valor de 1386249853 (o ISN aleatório):

Pontos principais:

1. O cliente envia um pacote TCP SYN. O número de sequência é 4098574664 e é o mesmo que o visto na interface INTERNA do firewall (CAPI)

2. Há um TCP SYN/ACK com número ACK 1386249853 (esperado devido à aleatorização ISN). Este pacote não foi visto nas capturas de firewall

3. O cliente envia um TCP RST, pois esperava um SYN/ACK com o valor de número ACK de 4098574665, mas recebeu o valor de 1386249853

Isso pode ser visualizado da seguinte maneira:

Ação 2. Verifique o roteamento entre o cliente e o firewall.

Confirme se:

- Os endereços MAC vistos nas capturas são os esperados.

- Certifique-se de que o roteamento entre o firewall e o cliente seja simétrico.

Há situações em que o RST vem de um dispositivo que fica entre o firewall e o cliente enquanto há um roteamento assimétrico na rede interna. Um caso típico é mostrado na imagem:

Nesse caso, a captura tem esse conteúdo. Observe a diferença entre o endereço MAC origem do pacote TCP SYN e o endereço MAC origem do TCP RST e o endereço MAC destino do pacote TCP SYN/ACK:

firepower# show capture CAPI detail

1: 13:57:36.730217 4c4e.35fc.fcd8 00be.75f6.1dae 0x0800 Length: 66

192.168.0.100.47740 > 10.10.1.100.80: S [tcp sum ok] 3045001876:3045001876(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF) (ttl 127, id 25661)

2: 13:57:36.981104 4c4e.35fc.fcd8 00be.75f6.1dae 0x0800 Length: 66

192.168.0.100.47741 > 10.10.1.100.80: S [tcp sum ok] 3809380540:3809380540(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF) (ttl 127, id 25662)

3: 13:57:36.981776 00be.75f6.1dae a023.9f92.2a4d 0x0800 Length: 66

10.10.1.100.80 > 192.168.0.100.47741: S [tcp sum ok] 1304153587:1304153587(0) ack 3809380541 win 8192 <mss 1380,nop,wscale 8,nop,nop,sackOK> (DF) (ttl 127, id 23339)

4: 13:57:36.982126 a023.9f92.2a4d 00be.75f6.1dae 0x0800 Length: 54

192.168.0.100.47741 > 10.10.1.100.80: R [tcp sum ok] 3809380541:3809380541(0) ack 1304153588 win 8192 (ttl 255, id 48501)

...

Caso 5. Transferência TCP lenta (Cenário 1)

Descrição do problema:

A transferência SFTP entre os hosts 10.11.4.171 e 10.77.19.11 é lenta. Embora a largura de banda mínima (BW) entre os 2 hosts seja de 100 Mbps, a velocidade de transferência não vai além de 5 Mbps.

Ao mesmo tempo, a velocidade de transferência entre os hosts 10.11.2.124 e 172.25.18.134 é bem maior.

Material de Suporte:

A velocidade máxima de transferência para um único fluxo TCP é determinada pelo BDP (Bandwidth Delay Product). A fórmula usada é mostrada na imagem:

Para obter mais detalhes sobre o BDP, verifique os recursos aqui:

- Por que seu aplicativo usa apenas 10 Mbps, mesmo que o link seja de 1 Gbps?

- BRKSEC-3021 - Avançado - Maximizando o desempenho do firewall

Cenário 1. Transferência lenta

Esta imagem mostra a topologia:

Fluxo afetado:

IP orig.: 10.11.4.171

IP do Horário de Verão: 10.77.19.11

Protocolo: SFTP (FTP sobre SSH)

Capturar análise

Habilitar capturas no mecanismo LINA FTD:

firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11

firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11

Aviso: as capturas LINA em FP1xxx e FP21xx afetam a taxa de transferência de tráfego que passa pelo FTD. Não ative as capturas LINA nas plataformas FP1xxx e FP21xxx ao solucionar problemas de desempenho (transferência lenta através do FTD). Em vez disso, use o SPAN ou um dispositivo HW Tap além das capturas nos hosts origem e destino. O problema está documentado no bug da Cisco ID CSCvo30697 .

firepower# capture CAPI type raw-data trace interface inside match icmp any any

WARNING: Running packet capture can have an adverse impact on performance.

Ações recomendadas

As ações listadas nesta seção têm como objetivo restringir ainda mais o problema.

Cálculo do tempo de ida e volta (RTT)

Primeiro, identifique o fluxo de transferência e siga-o:

Altere a visualização do Wireshark para mostrar Seconds Since the Previous Displayed Packet. Isso facilita o cálculo do RTT:

O RTT pode ser calculado pela adição dos valores de tempo entre 2 trocas de pacotes (um para a origem e um para o destino). Nesse caso, o pacote #2 mostra o RTT entre o firewall e o dispositivo que enviou o pacote SYN/ACK (servidor). O Packet #3 mostra o RTT entre o firewall e o dispositivo que enviou o pacote ACK (cliente). A adição dos 2 números fornece uma boa estimativa sobre o RTT fim-a-fim:

RTT ≈ 80 ms

Cálculo do Tamanho da Janela TCP

Expanda um pacote TCP, expanda o cabeçalho TCP, selecione Tamanho de janela calculado e selecione Aplicar como coluna:

Verifique a coluna Valor do tamanho da janela calculado para ver qual foi o valor do tamanho máximo da janela durante a sessão TCP. Você também pode selecionar o nome da coluna e classificar os valores.

Se você testar um download de arquivo (servidor > cliente), deverá verificar os valores anunciados pelo servidor. O valor do tamanho máximo da janela anunciado pelo servidor determina a velocidade máxima de transferência alcançada.

Nesse caso, o tamanho da janela TCP é ≈ 50000 Bytes

Com base nesses valores e com o uso da fórmula Bandwidth Delay Product, você obtém a largura de banda teórica máxima que pode ser obtida nessas condições: 50000*8/0.08 = largura de banda teórica máxima de 5 Mbps.

Isso corresponde às experiências do cliente neste caso.

Verifique cuidadosamente o handshake triplo do TCP. Ambos os lados, e mais importante o servidor, anunciam um valor de escala de janela de 0, o que significa 2^0 = 1 (sem escala de janelas). Isso afeta negativamente a taxa de transferência:

Neste ponto, é necessário fazer uma captura no servidor, confirmar que é ele que anuncia a escala de janela = 0 e reconfigurá-la (verifique a documentação do servidor para saber como fazer isso).

Cenário 2. Transferência rápida

Agora, vamos examinar o bom cenário (transferência rápida pela mesma rede):

Topologia:

O fluxo de interesse:

IP orig.: 10.11.2.124

IP do Horário de Verão: 172.25.18.134

Protocolo: SFTP (FTP sobre SSH)

Habilitar Capturas no mecanismo LINA FTD

firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134

firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134

Cálculo do Tempo de Ida e Volta (RTT): Neste caso, o RTT é ≈ 300 ms.

Cálculo do Tamanho da Janela TCP: O servidor anuncia um fator de escala de janela TCP de 7.

O tamanho da janela TCP do servidor é ≈ 1600000 Bytes:

Com base nesses valores, a fórmula do Produto com Atraso de Largura de Banda fornece:

1600000*8/0.3 = velocidade de transferência teórica máxima de 43 Mbps

Caso 6. Transferência TCP lenta (Cenário 2)

Descrição do problema: a transferência de arquivos por FTP (download) pelo firewall está lenta.

Esta imagem mostra a topologia:

Fluxo afetado:

IP orig.: 192.168.2.220

IP do Horário de Verão: 192.168.1.220

Protocolo: FTP

Capturar análise

Habilitar capturas no mecanismo LINA do FTD.

firepower# capture CAPI type raw-data buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220

firepower# cap CAPO type raw-data buffer 33554432 interface OUTSIDE match tcp host 192.168.2.220 host 192.168.1.220

Selecione um pacote FTP-DATA e siga o FTP Data Channel na captura FTD INSIDE (CAPI):

O conteúdo do fluxo FTP-DATA:

O conteúdo de captura CAPO:

Pontos principais:

1. Há pacotes TCP fora de ordem (OOO).

2. Há uma retransmissão de TCP.

3. Há uma indicação de perda de pacotes (pacotes descartados).

Dica: salve as capturas enquanto navega para Arquivo > Exportar pacotes especificados. Em seguida, salve apenas o intervalo de pacotes Exibido.

Ações recomendadas

As ações listadas nesta seção têm como objetivo restringir ainda mais o problema.

Ação 1. Identifique o local de perda de pacotes.

Em casos como esse, você deve fazer capturas simultâneas e usar a metodologia divide and conquer para identificar os segmentos de rede que causam a perda de pacotes. Do ponto de vista do firewall, há três cenários principais:

1. A perda de pacotes é causada pelo próprio firewall.

2. A perda de pacotes é causada por downstream para o dispositivo de firewall (direção do servidor para o cliente).

3. A perda de pacotes é causada no upstream para o dispositivo de firewall (direção do cliente para o servidor).

Perda de pacotes causada pelo firewall: para identificar se a perda de pacotes é causada pelo firewall, é necessário comparar a captura de entrada com a captura de saída. Há muitas maneiras de comparar 2 capturas diferentes. Esta seção demonstra uma maneira de fazer essa tarefa.

Procedimento para Comparar 2 Capturas para Identificar a Perda de Pacotes

Etapa 1. Certifique-se de que as 2 capturas contenham pacotes da mesma janela de tempo. Isso significa que não deve haver pacotes em uma captura que foram capturados antes ou depois da outra captura. Há algumas maneiras de fazer isso:

- Verifique o primeiro e o último valores de identificação (ID) IP do pacote.

- Verifique o primeiro e o último valores de timestamp do pacote.

Neste exemplo, você pode ver que os primeiros pacotes de cada captura têm os mesmos valores de ID IP:

Caso não sejam os mesmos:

1. Compare os Timestamps do primeiro pacote de cada captura.

2. Na captura com o Timestamp mais recente, obtenha um filtro dele. Altere o filtro Timestamp de == para >= (o primeiro pacote) e <= (o último pacote), por exemplo:

(frame.time >= "16 de outubro de 2019 16:13:43.244692000") &&(frame.time <= "16 de outubro de 2019 16:20:21.785130000")

3. Exporte os pacotes especificados para uma nova captura, selecione Arquivo > Exportar Pacotes Especificados e salve os pacotes Exibidos. Nesse ponto, as duas capturas devem conter pacotes que cubram a mesma janela de tempo. Agora você pode iniciar a comparação das 2 capturas.

Etapa 2. Especifique qual campo de pacote é usado para a comparação entre as 2 capturas. Exemplo de campos que podem ser usados:

- Identificação IP

- Número de Sequência RTP

- Número de sequência ICMP

Crie uma versão de texto de cada captura que contenha o campo para cada pacote especificado na etapa 1. Para fazer isso, deixe apenas a coluna de interesse, por exemplo, se quiser comparar pacotes com base na identificação de IP, modifique a captura conforme mostrado na imagem.

O resultado:

Etapa 3. Crie uma versão de texto da captura (Arquivo > Exportar Disseções de Pacote > Como Texto sem Formatação...), conforme mostrado na imagem:

Desmarque as opções Incluir títulos de coluna e Detalhes do pacote para exportar apenas os valores do campo exibido, como mostrado na imagem:

Etapa 4. Classifique os pacotes nos arquivos. Você pode usar o comando Linux sort para fazer isso:

# sort CAPI_IDs > file1.sorted

# sort CAPO_IDs > file2.sorted

Etapa 5. Use uma ferramenta de comparação de texto (por exemplo, WinMerge) ou o comando Linux diff para encontrar as diferenças entre as 2 capturas.

Nesse caso, as capturas CAPI e CAPO para o tráfego de dados FTP são idênticas. Isso prova que a perda de pacotes não foi causada pelo firewall.

Identificar perda de pacotes upstream/downstream.

Pontos principais:

1. Este pacote é uma Retransmissão TCP. Especificamente, é um pacote TCP SYN enviado do cliente para o servidor para Dados FTP em Modo Passivo. Como o cliente reenvia o pacote e você pode ver o SYN inicial (#1 do pacote), o pacote foi perdido upstream para o firewall.

Nesse caso, existe a possibilidade de que o pacote SYN tenha chegado ao servidor, mas o pacote SYN/ACK tenha sido perdido no caminho de volta:

2. Há um pacote do servidor e o Wireshark identificou que o segmento anterior não foi visto/capturado. Como o pacote não capturado foi enviado do servidor para o cliente e não foi visto na captura do firewall, isso significa que o pacote foi perdido entre o servidor e o firewall.

Isso indica que há perda de pacotes entre o servidor FTP e o firewall.

Ação 2. Faça capturas adicionais.

Faça capturas adicionais junto com as capturas nos endpoints. Tente aplicar o método divide and conquer para isolar ainda mais o segmento problemático que causa a perda de pacotes.

Pontos principais:

1. O receptor (o cliente FTP, nesse caso) rastreia os números de sequência TCP recebidos. Se detectar que um pacote foi perdido (um número de sequência esperado foi ignorado), ele gerará um pacote ACK com o ACK='expected sequence number that was skipped'. Neste exemplo, Ack=2224386800.

2. O ACK Dup dispara uma retransmissão rápida de TCP (retransmissão dentro de 20 ms depois que um ACK Duplicado é recebido).

O que significam ACKs duplicados?

- Alguns ACKs duplicados, mas nenhuma retransmissão real, indicam que é mais provável que existam pacotes que cheguem fora de ordem.

- ACKs duplicados seguidos de retransmissões reais indicam que há alguma quantidade de perda de pacotes.

Ação 3. Calcule o tempo de processamento do firewall para pacotes de trânsito.

Aplique a mesma captura em 2 interfaces diferentes:

firepower# capture CAPI buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220

firepower# capture CAPI interface OUTSIDE

Exportar a captura verifica a diferença de tempo entre os pacotes de entrada vs de saída

Caso 7. Problema de conectividade de TCP (Corrupção de pacote)

Descrição do problema:

O cliente sem fio (192.168.21.193) tenta se conectar a um servidor de destino (192.168.14.250 - HTTP) e há dois cenários diferentes:

- Quando o cliente se conecta ao Ponto de Acesso (AP) 'A', a conexão HTTP não funciona.

- Quando o cliente se conecta ao Ponto de Acesso (AP) 'B', a conexão HTTP funciona.

Esta imagem mostra a topologia:

Fluxo afetado:

IP orig.: 192.168.21.193

IP do Horário de Verão: 192.168.14.250

Protocolo: TCP 80

Capturar análise

Habilitar capturas no mecanismo LINA FTD:

firepower# capture CAPI int INSIDE match ip host 192.168.21.193 host 192.168.14.250

firepower# capture CAPO int OUTSIDE match ip host 192.168.21.193 host 192.168.14.250

Capturas - Cenário Funcional:

Como parâmetro, é sempre muito útil ter capturas de um cenário em boas condições.

Esta imagem mostra a captura realizada na interface INSIDE do NGFW

Esta imagem mostra a captura realizada na interface NGFW OUTSIDE.

Pontos principais:

1. As duas capturas são quase idênticas (considere a aleatorização ISN).

2. Não há indicações de perda de pacotes.

3. Nenhum pacote fora de serviço (OOO)

4. Há 3 solicitações HTTP GET. O primeiro recebe uma mensagem de redirecionamento 404 ‘Não encontrado’, o segundo recebe uma mensagem de redirecionamento 200 ‘OK’ e o terceiro recebe uma mensagem de redirecionamento 304 ‘Não modificado’.

Capturas - Cenário de falha conhecida:

O conteúdo da captura de entrada (CAPI).

Pontos principais:

1. Há um handshake triplo do TCP.

2. Há retransmissões de TCP e indicações de perda de pacotes.

3. Há um pacote (TCP ACK) que é identificado pelo Wireshark como Malformado.

Esta imagem mostra o conteúdo da captura de saída (CAPO).

Pontos principais:

As duas capturas são quase idênticas (considere a aleatorização ISN):

1. Há um handshake triplo do TCP.

2. Há retransmissões de TCP e indicações de perda de pacotes.

3. Há um pacote (TCP ACK) que é identificado pelo Wireshark como Malformado.

Verifique o pacote malformado:

Pontos principais:

1. O pacote é identificado como Malformado pelo Wireshark.

2. Ele tem um comprimento de 2 bytes.

3. Há um payload TCP de 2 bytes.

4. O payload é de 4 zeros extras (00 00).

Ações recomendadas

As ações listadas nesta seção têm como objetivo restringir ainda mais o problema.

Ação 1. Faça capturas adicionais. Inclua capturas nos endpoints e, se possível, tente aplicar o método divide and conquer para isolar a origem da corrupção de pacotes, por exemplo:

Nesse caso, os 2 bytes extras foram adicionados pelo driver de interface do switch 'A' e a solução foi substituir o switch que causa a corrupção.

Caso 8. Problema de conectividade UDP (pacotes ausentes)

Descrição do problema: as mensagens Syslog (UDP 514) não são vistas no Servidor Syslog de destino.

Esta imagem mostra a topologia:

Fluxo afetado:

IP orig.: 192.168.1.81

IP do Horário de Verão: 10.10.1.73

Protocolo: UDP 514

Capturar análise

Habilitar capturas no mecanismo LINA FTD:

firepower# capture CAPI int INSIDE trace match udp host 192.168.1.81 host 10.10.1.73 eq 514

firepower# capture CAPO int OUTSIDE match udp host 192.168.1.81 host 10.10.1.73 eq 514

As capturas de FTD não mostram pacotes:

firepower# show capture

capture CAPI type raw-data trace interface INSIDE [Capturing - 0 bytes]

match udp host 192.168.1.81 host 10.10.1.73 eq syslog

capture CAPO type raw-data interface OUTSIDE [Capturing - 0 bytes]

match udp host 192.168.1.81 host 10.10.1.73 eq syslog

Ações recomendadas

As ações listadas nesta seção têm como objetivo restringir ainda mais o problema.

Ação 1. Verifique a tabela de conexão do FTD.

Para verificar uma conexão específica, use esta sintaxe:

firepower# show conn address 192.168.1.81 port 514

10 in use, 3627189 most used

Inspect Snort:

preserve-connection: 6 enabled, 0 in effect, 74 most enabled, 0 most in effect

UDP INSIDE  10.10.1.73:514 INSIDE  192.168.1.81:514, idle 0:00:00, bytes 480379697, flags -oN1

Pontos principais:

1. As interfaces de entrada e saída são as mesmas (curva-U).

2. O número de bytes tem um valor significativamente grande (~5 GBytes).

3. A marca "o" indica o descarregamento em fluxo (fluxo acelerado HW). Essa é a razão pela qual as capturas de FTD não mostram nenhum pacote. O descarregamento de fluxo é suportado apenas nas plataformas 41xx e 93xx. Nesse caso, o dispositivo é um 41xx.

Ação 2. Faça capturas no nível do chassi.

Conecte-se ao gerenciador de chassi do Firepower e habilite a captura na interface de entrada (E1/2 nesse caso) e nas interfaces do backplane (E1/9 e E1/10), conforme mostrado na imagem:

Depois de alguns segundos:

Dica: no Wireshark, exclua os pacotes marcados com VN para eliminar a duplicação de pacotes no nível da interface física

Antes:

Após:

Pontos principais:

1. Um filtro de exibição é aplicado para remover duplicatas de pacotes e mostrar apenas syslogs.

2. A diferença entre os pacotes está no nível de microssegundos. Isso indica uma taxa de pacotes muito alta.

3. O valor do Time to Live (TTL) diminui continuamente. Isso indica um loop de pacote.

Ação 3. Use o packet-tracer.

Como os pacotes não passam pelo mecanismo LINA do firewall, você não pode fazer um rastreamento ao vivo (captura com rastreamento), mas pode rastrear um pacote emulado com o packet-tracer:

firepower# packet-tracer input INSIDE udp 10.10.1.73 514 192.168.1.81 514

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 3

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found flow with id 25350892, using existing flow

Phase: 4

Type: SNORT

Subtype:

Result: ALLOW

Config:

Additional Information:

Snort Verdict: (fast-forward) fast forward this flow

Phase: 5

Type: ROUTE-LOOKUP

Subtype: Resolve Egress Interface

Result: ALLOW

Config:

Additional Information:

found next-hop 192.168.1.81 using egress ifc  INSIDE

Phase: 6

Type: ADJACENCY-LOOKUP

Subtype: next-hop and adjacency

Result: ALLOW

Config:

Additional Information:

adjacency Active

next-hop mac address a023.9f92.2a4d hits 1 reference 1

Phase: 7

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

Result:

input-interface: INSIDE

input-status: up

input-line-status: up

output-interface: INSIDE

output-status: up

output-line-status: up

Action: allow

Ação 4. Confirme o roteamento FTD.

Verifique a tabela de roteamento do firewall para ver se há algum problema de roteamento:

firepower# show route 10.10.1.73

Routing entry for 10.10.1.0 255.255.255.0

Known via "eigrp 1", distance 90, metric 3072, type internal

Redistributing via eigrp 1

Last update from 192.168.2.72 on OUTSIDE, 0:03:37 ago

Routing Descriptor Blocks:

* 192.168.2.72, from 192.168.2.72, 0:02:37 ago, via OUTSIDE

Route metric is 3072, traffic share count is 1

Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 29/255, Hops 1

Pontos principais:

1. A rota aponta para a interface de saída correta.

2. A rota foi aprendida há alguns minutos (0:02:37).

Ação 5. Confirme a disponibilidade da conexão.

Verifique o tempo de atividade da conexão para ver quando esta conexão foi estabelecida:

firepower# show conn address 192.168.1.81 port 514 detail

21 in use, 3627189 most used

Inspect Snort:

preserve-connection: 19 enabled, 0 in effect, 74 most enabled, 0 most in effect

Flags: A - awaiting responder ACK to SYN, a - awaiting initiator ACK to SYN,

b - TCP state-bypass or nailed,

C - CTIQBE media, c - cluster centralized,

D - DNS, d - dump, E - outside back connection, e - semi-distributed,

F - initiator FIN, f - responder FIN,

G - group, g - MGCP, H - H.323, h - H.225.0, I - initiator data,

i - incomplete, J - GTP, j - GTP data, K - GTP t3-response

k - Skinny media, L - decap tunnel, M - SMTP data, m - SIP media

N - inspected by Snort (1 - preserve-connection enabled, 2 - preserve-connection in effect)

n - GUP, O - responder data, o - offloaded,

P - inside back connection, p - passenger flow

q - SQL*Net data, R - initiator acknowledged FIN,

R - UDP SUNRPC, r - responder acknowledged FIN,

T - SIP, t - SIP transient, U - up,

V - VPN orphan, v - M3UA W - WAAS,

w - secondary domain backup,

X - inspected by service module,

x - per session, Y - director stub flow, y - backup stub flow,

Z - Scansafe redirection, z - forwarding stub flow

UDP INSIDE: 10.10.1.73/514 INSIDE: 192.168.1.81/514,

flags -oN1, idle 0s, uptime 3m49s, timeout 2m0s, bytes 4801148711

Ponto-chave:

1. A conexão foi estabelecida há aproximadamente 4 minutos (isso ocorre antes da instalação da rota EIGRP na tabela de roteamento)

Ação 6. Limpe a conexão estabelecida.

Nesse caso, os pacotes correspondem a uma conexão estabelecida e são roteados para uma interface de saída errada; isso causa um loop. Isso se deve à ordem de operações do firewall:

1. Pesquisa de conexão estabelecida (tem prioridade sobre a pesquisa da tabela de roteamento global).

2. Consulta de conversão de endereço de rede (NAT) - A fase UN-NAT (NAT de destino) tem precedência sobre a pesquisa de PBR e de rota.

3. Roteamento baseado em políticas (PBR)

4. Pesquisa de tabela de roteamento global

Como a conexão nunca atinge o tempo limite (o cliente Syslog envia continuamente pacotes enquanto o tempo limite de ociosidade de conexão UDP é de 2 minutos), é necessário limpar manualmente a conexão:

firepower# clear conn address 10.10.1.73 address 192.168.1.81 protocol udp port 514

1 connection(s) deleted.

Verifique se uma nova conexão foi estabelecida:

firepower# show conn address 192.168.1.81 port 514 detail | b 10.10.1.73.*192.168.1.81

UDP OUTSIDE: 10.10.1.73/514 INSIDE: 192.168.1.81/514,

flags -oN1, idle 1m15s, uptime 1m15s, timeout 2m0s, bytes 408

Ação 7. Configure o tempo limite de conexão flutuante.

Essa é a solução adequada para resolver o problema e evitar o roteamento não ideal, especialmente para fluxos UDP. Navegue até Devices > Platform Settings > Timeouts e defina o valor:

Você pode encontrar mais detalhes sobre o timeout de conexão flutuante na Referência de Comandos:

https://www.cisco.com/c/en/us/td/docs/security/asa/asa-command-reference/T-Z/cmdref4/t1.html#pgfId-1649892

Caso 9. Problema de conectividade HTTPS (Cenário 1)

Descrição do problema: a comunicação HTTPS entre o cliente 192.168.201.105 e o servidor 192.168.202.101 não pode ser estabelecida

Esta imagem mostra a topologia:

Fluxo afetado:

IP orig.: 192.168.201.111

IP do Horário de Verão: 192.168.202.111

Protocolo: TCP 443 (HTTPS)

Capturar análise

Habilitar capturas no mecanismo LINA FTD:

O IP usado na captura EXTERNA é diferente devido à configuração da conversão de endereço de porta.

firepower# capture CAPI int INSIDE match ip host 192.168.201.111 host 192.168.202.111

firepower# capture CAPO int OUTSIDE match ip host 192.168.202.11 host 192.168.202.111

Esta imagem mostra a captura realizada na interface INSIDE do NGFW:

Pontos principais:

1. Há um handshake triplo do TCP.

2. A negociação SSL é iniciada. O cliente envia uma mensagem Hello do cliente.

3. Há um TCP ACK enviado ao cliente.

4. Há um TCP RST enviado ao cliente.

Esta imagem mostra a captura realizada na interface NGFW OUTSIDE.

Pontos principais:

1. Há um handshake triplo do TCP.

2. A negociação SSL é iniciada. O cliente envia uma mensagem Hello do cliente.

3. Há retransmissões de TCP enviadas do firewall para o servidor.

4. Há um TCP RST enviado ao servidor.

Ações recomendadas

As ações listadas nesta seção têm como objetivo restringir ainda mais o problema.

Ação 1. Faça capturas adicionais.

Uma captura feita no servidor revela que o servidor recebeu o Hellos do cliente TLS com checksum TCP corrompido e o descarta silenciosamente (não há TCP RST ou qualquer outro pacote de resposta para o cliente):

Quando você junta tudo:

Nesse caso, para entender, há uma necessidade de ativar no Wireshark a opção Validate the TCP checksum if possible. Navegue até Edit > Preferences > Protocols > TCP, conforme mostrado na imagem.

Nesse caso, é útil colocar as capturas lado a lado para obter a imagem completa:

Pontos principais:

1. Há um handshake triplo do TCP. As IDs de IP são as mesmas. Isso significa que o fluxo não foi intermediado por proxy pelo firewall.

2. Um Hello do cliente TLS vem do cliente com o ID IP 12083. O pacote recebe proxy do firewall (o firewall, nesse caso, foi configurado com a Política de descriptografia TLS) e a ID IP é alterada para 52534. Além disso, a soma de verificação TCP do pacote é corrompida (devido a um defeito de software que depois foi corrigido).

3. O firewall está no modo Proxy TCP e envia um ACK ao cliente (que falsifica o servidor).

4. O firewall não recebe nenhum pacote TCP ACK do servidor e retransmite a mensagem Hello do cliente TLS. Isso ocorre novamente devido ao modo Proxy TCP ativado pelo firewall.

5. Após ~30 segundos, o firewall desiste e envia um TCP RST para o cliente.

6. O firewall envia um TCP RST para o servidor.

Referência:

Processamento de handshake TLS/SSL do Firepower

Caso 10. Problema de conectividade HTTPS (Cenário 2)

Descrição do problema: Falha no registro da licença inteligente do FMC.

Esta imagem mostra a topologia:

Fluxo afetado:

IP orig.: 192.168.0.100

Dst: tools.cisco.com

Protocolo: TCP 443 (HTTPS)

Capturar análise

Permitir a captura na interface de gestão do CVP:

Tente se registrar novamente. Quando a mensagem de erro for exibida, pressione CTRL-C para interromper a captura:

root@firepower:/Volume/home/admin# tcpdump -i eth0 port 443 -s 0 -w CAP.pcap

HS_PACKET_BUFFER_SIZE is set to 4.

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

^C264 packets captured <- CTRL-C

264 packets received by filter

0 packets dropped by kernel

root@firepower:/Volume/home/admin#

Colete a captura do FMC (System > Health > Monitor, selecione o dispositivo e selecione Advanced Troubleshooting), como mostrado na imagem:

A imagem mostra a captura FMC no Wireshark:

Dica: para verificar todas as novas sessões TCP que foram capturadas, use o filtro de exibição tcp.flags==0x2 no Wireshark. Isso filtra todos os pacotes TCP SYN que foram capturados.

Dica: aplique como coluna o campo Server Name do Hello do cliente SSL.

Dica: aplique este filtro de exibição para ver apenas as mensagens de Hello do cliente ssl.handshake.type == 1

Observação: no momento em que este documento foi escrito, o portal Smart Licensing (tools.cisco.com) usa estes IPs: 72.163.4.38, 173.37.145.8

Siga um dos fluxos TCP (Follow > TCP Stream), como mostrado na imagem.

Pontos principais:

1. Há um handshake triplo do TCP.

2. O cliente (FMC) envia uma mensagem de saudação do cliente SSL para o portal Smart Licensing.

3. A ID da Sessão SSL é 0. Isso significa que não é uma sessão retomada.

4. O servidor de destino responde com a mensagem Hello do servidor, Certificado e Hello do servidor concluída.

5. O cliente envia um alerta fatal SSL referente a uma "CA desconhecida".

6. O cliente envia um TCP RST para fechar a sessão.

7. A duração total da sessão TCP (do estabelecimento ao fechamento) foi de aproximadamente 0,5 s.

Selecione o certificado do servidor e expanda o campo emissor para ver o commonName. Nesse caso, o nome comum revela um dispositivo que faz MITM (Man-in-the-middle).

Isso é mostrado nesta imagem:

Ações recomendadas

As ações listadas nesta seção têm como objetivo restringir ainda mais o problema.

Ação 1. Faça capturas adicionais.

Faça capturas no dispositivo de firewall de trânsito:

A CAPI mostra:

O CAPO mostra:

Essas capturas comprovam que o firewall de trânsito modifica o certificado do servidor (MITM)

Ação 2. Verifique os logs do dispositivo.

Você pode coletar o pacote FMC TS conforme descrito neste documento:

https://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html

Nesse caso, o arquivo /dir-archives/var-log/process_stdout.log mostra mensagens como esta:

SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla[10068]: *Wed .967 UTC: CH-LIB-ERROR: ch_pf_curl_send_msg[494],

failed to perform, err code 60, err string "SSL peer certificate or SSH remote key was not OK"

...

SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla[10068]: *Wed .967 UTC: CH-LIB-TRACE: ch_pf_curl_is_cert_issue[514],

cert issue checking, ret 60, url "https://tools.cisco.com/its/

Solução recomendada

Desabilite o MITM para o fluxo específico para que o FMC possa se registrar com êxito na nuvem do Smart Licensing.

Caso 11. Problema de conectividade IPv6

Descrição do problema: os hosts internos (localizados atrás da interface INTERNA do firewall) não podem se comunicar com os hosts externos (hosts localizados atrás da interface EXTERNA do firewall).

Esta imagem mostra a topologia:

Fluxo afetado:

IP orig.: fc00:1:1:1::100

IP do Horário de Verão: fc00:1:1:2::2

Protocolo: qualquer

Capturar análise

Habilitar capturas no mecanismo LINA FTD.

firepower# capture CAPI int INSIDE match ip any6 any6

firepower# capture CAPO int OUTSIDE match ip any6 any6

Capturas - Cenário não funcional

Essas capturas foram feitas em paralelo com um teste de conectividade ICMP de IP fc00:1:1:1::100 (roteador interno) para IP fc00:1:1:2::2 (roteador upstream).

A captura na interface INSIDE do firewall contém:

Pontos principais:

1. O roteador envia uma mensagem de solicitação de vizinho IPv6 e solicita o endereço MAC do dispositivo upstream (IP fc00:1:1:1::1).

2. O firewall responde com um anúncio de vizinho IPv6.

3. O roteador envia uma solicitação de eco ICMP.

4. O firewall envia uma mensagem de solicitação de vizinho IPv6 e solicita o endereço MAC do dispositivo downstream (fc00:1:1:1::100).

5. O roteador responde com um anúncio de vizinho IPv6.

6. O roteador envia solicitações adicionais de eco ICMP IPv6.

A captura na interface EXTERNA do firewall contém:

Pontos principais:

1. O firewall envia uma mensagem de solicitação de vizinho IPv6 que solicita o endereço MAC do dispositivo upstream (IP fc00:1:1:2::2).

2. O roteador responde com um anúncio de vizinho IPv6.

3. O firewall envia uma solicitação de eco ICMP IPv6.

4. O dispositivo upstream (roteador fc00:1:1:2::2) envia uma mensagem de solicitação de vizinho IPv6 que solicita o endereço MAC do endereço IPv6 fc00:1:1:1::100.

5. O firewall envia uma solicitação de eco ICMP IPv6 adicional.

6. O roteador upstream envia uma mensagem adicional de solicitação de vizinhos IPv6 que solicita o endereço MAC do endereço IPv6 fc00:1:1:1::100.

O ponto 4 é muito interessante. Normalmente, o roteador upstream solicita o MAC da interface EXTERNA do firewall (fc00:1:1:2::2), mas, em vez disso, solicita o fc00:1:1:1::100. Essa é uma indicação de um erro de configuração.

Ações recomendadas

As ações listadas nesta seção têm como objetivo restringir ainda mais o problema.

Ação 1. Verifique a tabela de vizinhos IPv6.

A tabela de vizinhos IPv6 do firewall está preenchida corretamente.

firepower# show ipv6 neighbor | i fc00

fc00:1:1:2::2                              58 4c4e.35fc.fcd8  STALE OUTSIDE

fc00:1:1:1::100                            58 4c4e.35fc.fcd8  STALE INSIDE

Ação 2. Verifique a configuração do IPv6.

Essa é a configuração do firewall.

firewall# show run int e1/2

!

interface Ethernet1/2

nameif INSIDE

cts manual

propagate sgt preserve-untag

policy static sgt disabled trusted

security-level 0

ip address 192.168.0.1 255.255.255.0

ipv6 address fc00:1:1:1::1/64

ipv6 enable

firewall# show run int e1/3.202

!

interface Ethernet1/3.202

vlan 202

nameif OUTSIDE

cts manual

propagate sgt preserve-untag

policy static sgt disabled trusted

security-level 0

ip address 192.168.103.96 255.255.255.0

ipv6 address fc00:1:1:2::1/64

ipv6 enable

A configuração do dispositivo upstream revela o erro de configuração:

Router# show run interface g0/0.202

!

interface GigabitEthernet0/0.202

encapsulation dot1Q 202

vrf forwarding VRF202

ip address 192.168.2.72 255.255.255.0

ipv6 address FC00:1:1:2::2/48

Capturas - Cenário Funcional

A alteração da máscara de sub-rede (de /48 para /64) corrigiu o problema. Essa é a captura CAPI no cenário funcional.

Ponto-chave:

1. O roteador envia uma mensagem de solicitação de vizinho IPv6 que solicita o endereço MAC do dispositivo upstream (IP fc00:1:1:1::1).

2. O firewall responde com um anúncio de vizinho IPv6.

3. O roteador envia solicitações de eco ICMP e obtém respostas de eco.

Conteúdo do CAPO:

Pontos principais:

1. O firewall envia uma mensagem de solicitação de vizinho IPv6 que solicita o endereço MAC do dispositivo upstream (IP fc00:1:1:2::2).

2. O firewall responde com um anúncio de vizinho IPv6.

3. O firewall envia uma solicitação de eco ICMP.

4. O roteador envia uma mensagem de solicitação de vizinho IPv6 que solicita o endereço MAC do dispositivo downstream (IP fc00:1:1:1::1).

5. O firewall responde com um anúncio de vizinho IPv6.

6. O firewall envia solicitações de eco ICMP e obtém respostas de eco.

Caso 12. Problema de conectividade intermitente (envenenamento ARP)

Descrição do problema: os hosts internos (192.168.0.x/24) têm problemas de conectividade intermitentes com os hosts na mesma sub-rede

Esta imagem mostra a topologia:

Fluxo afetado:

IP orig.: 192.168.0.x/24

IP do Horário de Verão: 192.168.0.x/24

Protocolo: qualquer

O cache ARP de um host interno parece estar inviabilizado:

Capturar análise

Habilitar uma captura no mecanismo LINA do FTD

Essa captura só captura pacotes ARP na interface INSIDE:

firepower# capture CAPI_ARP interface INSIDE ethernet-type arp

Capturas - cenário não funcional:

A captura na interface INSIDE do firewall contém.

Pontos principais:

1. O firewall recebe várias solicitações ARP para IPs dentro da rede 192.168.0.x/24

2. O firewall responde a todos eles (proxy-ARP) com seu próprio endereço MAC

Ações recomendadas

As ações listadas nesta seção têm como objetivo restringir ainda mais o problema.

Ação 1. Verifique a configuração do NAT.

Com relação à configuração do NAT, há casos em que a palavra-chave no-proxy-arp pode impedir o comportamento anterior:

firepower# show run nat

nat (INSIDE,OUTSIDE) source static NET_1.1.1.0 NET_2.2.2.0 destination static NET_192.168.0.0 NET_4.4.4.0 no-proxy-arp

Ação 2. Desative a funcionalidade proxy-arp na interface do firewall.

Se a palavra-chave ‘no-proxy-arp’ não resolver o problema, tente desativar o proxy ARP na própria interface. No caso de FTD, no momento da elaboração deste documento, você precisa usar o FlexConfig e implantar o comando (especifique o nome da interface apropriada).

sysopt noproxyarp INSIDE

Caso 13. Identificar Identificadores de Objeto (OIDs - Object Identifiers) SNMP que causam problemas na CPU

Esse caso demonstra como determinados OIDs SNMP para polling de memória foram identificados como a causa raiz de hogs de CPU (problema de desempenho) com base na análise de capturas de pacotes SNMP versão 3 (SNMPv3).

Descrição do problema: as sobrecargas nas interfaces de dados aumentam continuamente. Pesquisas adicionais revelaram que também há monopolizadores de CPU (causados pelo processo SNMP) que são a causa raiz das sobrecargas da interface.

A próxima etapa no processo de identificação e solução de problemas foi identificar a causa raiz dos hogs de CPU causados pelo processo SNMP e, em particular, restringir o escopo do problema para identificar os Identificadores de Objetos (OID) SNMP que, quando interrogados, poderiam potencialmente resultar em hogs de CPU.

Atualmente, o mecanismo LINA do FTD não fornece um comando 'show' para OIDs SNMP que são pesquisados em tempo real.

A lista de OIDs de SNMP para polling pode ser recuperada da ferramenta de monitoramento de SNMP, no entanto, neste caso, houve estes fatores preventivos:

- O administrador do FTD não teve acesso à ferramenta de monitoramento SNMP

- O SNMP versão 3 com autenticação e criptografia de dados para privacidade foi configurado no FTD

Capturar análise

Como o administrador do FTD tinha as credenciais para a autenticação e a criptografia de dados do SNMP versão 3, este plano de ação foi proposto:

1. Tirar capturas de pacotes SNMP

2. Salve as capturas e use as preferências do protocolo SNMP Wireshark para especificar as credenciais da versão 3 do SNMP para descriptografar os pacotes da versão 3 do SNMP. As capturas descriptografadas são usadas para a análise e recuperação de OIDs SNMP

Configure as capturas de pacotes SNMP na interface usada na configuração do host do servidor SNMP:

firepower# show run snmp-server  | include host

snmp-server host management 192.168.10.10 version 3 netmonv3

firepower# show ip address management

System IP Address:

Interface                Name                   IP address      Subnet mask     Method

Management0/0            management             192.168.5.254   255.255.255.0   CONFIG

Current IP Address:

Interface                Name                   IP address      Subnet mask     Method

Management0/0            management             192.168.5.254   255.255.255.0   CONFIG

firepower# capture capsnmp interface management buffer 10000000 match udp host 192.168.10.10  host 192.168.5.254 eq snmp

firepower# show capture capsnmp

capture capsnmp type raw-data buffer 10000000 interface outside [Capturing - 9512 bytes]

match udp host 192.168.10.10  host 192.168.5.254 eq snmp

Pontos principais:

1. Endereços/portas SNMP de origem e destino.

2. Não foi possível decodificar a PDU do protocolo SNMP porque privKey é desconhecido para o Wireshark.

3. O valor da primitiva encryptedPDU.

Ações recomendadas

As ações listadas nesta seção têm como objetivo restringir ainda mais o problema.

Ação 1. Descriptografe as capturas SNMP.

Salve as capturas e edite as preferências do protocolo SNMP Wireshark para especificar as credenciais da versão 3 do SNMP para descriptografar os pacotes.

firepower# copy /pcap capture: tftp:

Source capture name [capsnmp]?

Address or name of remote host []? 192.168.10.253

Destination filename [capsnmp]? capsnmp.pcap

!!!!!!

64 packets copied in 0.40 secs

Abra o arquivo de captura no Wireshark, selecione um pacote SNMP e navegue para Protocol Preferences > Users Table, como mostrado na imagem:

Na tabela Usuários SNMP, foram especificados o nome de usuário, o modelo de autenticação, a senha de autenticação, o protocolo de privacidade e a senha de privacidade do SNMP versão 3 (as credenciais reais não são mostradas abaixo):

Quando as configurações dos usuários do SNMP foram aplicadas, o Wireshark mostrou PDUs SNMP descriptografadas:

Pontos principais:

1. As ferramentas de monitoramento do SNMP usaram o SNMP getBulkRequest para consultar e percorrer o OID pai 1.3.6.1.4.1.9.9.221.1 e os OIDs relacionados.

2. O FTD respondeu a cada getBulkRequest com get-response que contém OIDs relacionados a 1.3.6.1.4.1.9.9.221.1.

Ação 2. Identificar os OIDs SNMP.

O SNMP Object Navigator mostrou que o OID 1.3.6.1.4.1.9.9.221.1 pertence à base de informações de gerenciamento (MIB) chamada CISCO-ENHANCED-MEMPOOL-MIB, como mostrado na imagem:

Para exibir os OIDs em formato legível no Wireshark:

1. Baixe o MIB CISCO-ENHANCED-MEMPOOL-MIB e suas dependências, como mostrado na imagem:

2. No Wireshark, na janela Edit > Preferences > Name Resolution, a opção Enable OID Resolution está marcada. Na janela SMI (MIB e caminhos PIB), especifique a pasta com os MIBs baixados e em SMI (MIB e módulos PIB). O CISCO-ENHANCED-MEMPOOL-MIB é adicionado automaticamente à lista de módulos:

3. Quando o Wireshark for reiniciado, a resolução do OID será ativada:

Com base na saída descriptografada do arquivo de captura, a ferramenta de monitoramento SNMP pesquisava periodicamente (intervalo de 10 segundos) dados sobre a utilização de pools de memória no FTD. Conforme explicado no artigo da Nota Técnica ASA SNMP Polling for Memory-Related Statistics , a pesquisa da utilização do Global Shared Pool (GSP) com SNMP resulta em alto uso da CPU. Nesse caso, a partir das capturas, ficou claro que a utilização do Pool compartilhado global foi sondada periodicamente como parte do SNMP getBulkRequest primitivo.

Para minimizar os hogs de CPU causados pelo processo SNMP, foi recomendado seguir as etapas de mitigação para os Hogs de CPU para SNMP mencionados no artigo e evitar pesquisar os OIDs relacionados ao GSP. Sem a pesquisa de SNMP para os OIDs relacionados ao GSP, não foram observados hogs de CPU causados pelo processo SNMP e a taxa de saturação diminuiu significativamente.

Informações Relacionadas

- Guias de configuração do Cisco Firepower Management Center

- Esclarecer as ações da regra de política de controle de acesso do Firepower Threat Defense

- Trabalhe com capturas do Firepower Threat Defense e do Packet Tracer

- Aprenda o Wireshark