Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Antecedentes

¿Cómo se recopilan y exportan capturas en la familia de productos NGFW?

Recopilar capturas de FXOS

Habilitar y recopilar capturas de línea de FTD

Activar y recopilar capturas de Snort de FTD

Troubleshoot

Caso 1. Sin TCP SYN en la interfaz de salida

Análisis de captura

Acciones recomendadas

Resumen de posibles causas y acciones recomendadas

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

Análisis de captura

Acciones recomendadas

Caso 3. Protocolo de enlace TCP de 3 vías + RST desde un terminal

Análisis de captura

3.1 - Protocolo de enlace TCP de 3 vías + RST retrasado del cliente

Acciones recomendadas

3.2 - Protocolo de enlace TCP de 3 vías + FIN/ACK retrasado del cliente + RST retrasado del servidor

Acciones recomendadas

3.3 - Protocolo de enlace TCP de 3 vías + RST retrasado del cliente

Acciones recomendadas

3.4 - Protocolo de enlace TCP de 3 vías + RST inmediato desde el servidor

Acciones recomendadas

Caso 4. TCP RST desde el cliente

Análisis de captura

Acciones recomendadas

Caso 5. Transferencia TCP lenta (situación 1)

Escenario 1. Transferencia lenta

Análisis de captura

Acciones recomendadas

Situación hipotética 2. Transferencia rápida

Caso 6. Transferencia TCP lenta (situación 2)

Análisis de captura

Acciones recomendadas

Caso 7. Problema de conectividad TCP (corrupción de paquetes)

Análisis de captura

Acciones recomendadas

Caso 8. Problema de conectividad UDP (paquetes faltantes)

Análisis de captura

Acciones recomendadas

Caso 9. Problema de conectividad HTTPS (situación 1)

Análisis de captura

Acciones recomendadas

Caso 10. Problema de conectividad HTTPS (situación 2)

Análisis de captura

Acciones recomendadas

Caso 11. Problema de conectividad IPv6

Análisis de captura

Acciones recomendadas

Caso 12. Problema de conectividad intermitente (envenenamiento ARP)

Análisis de captura

Acciones recomendadas

Caso 13. Identificar identificadores de objeto SNMP (OID) que provocan bloqueos de CPU

Análisis de captura

Acciones recomendadas

Información Relacionada

Introducción

Este documento describe varias técnicas de análisis de captura de paquetes que tienen como objetivo resolver problemas de red de manera eficaz.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

- Arquitectura de la plataforma Firepower

- Registros de NGFW

- Rastreador de paquetes de NGFW

Además, antes de empezar a analizar las capturas de paquetes, es muy recomendable cumplir estos requisitos:

- Conozca la operación del protocolo - No comience a verificar una captura de paquetes si no entiende cómo funciona el protocolo capturado.

- Conozca la topología: debe conocer los dispositivos de tránsito de extremo a extremo. Si esto no es posible, debe conocer al menos los dispositivos de flujo ascendente y descendente.

- Conozca el dispositivo: debe saber cómo gestiona los paquetes su dispositivo, cuáles son las interfaces implicadas (entrada/salida), cuál es la arquitectura del dispositivo y cuáles son los distintos puntos de captura.

- Conozca la configuración - Debe saber cómo se supone que el flujo de paquetes debe ser manejado por el dispositivo en términos de:

- Interfaz de enrutamiento/salida

- Políticas aplicadas

- traducción de Dirección de Red (NAT)

- Conozca las herramientas disponibles - Junto con las capturas, se recomienda estar listo para aplicar otras herramientas y técnicas (como registro y trazadores) y, si es necesario, correlacionarlos con los paquetes capturados

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

- La mayoría de las situaciones se basan en FP4140 con software FTD 6.5.x.

- FMC con software 6.5.x.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

La captura de paquetes es una de las herramientas de solución de problemas más pasadas por alto disponibles en la actualidad. A diario, Cisco TAC resuelve muchos problemas con el análisis de los datos capturados.

El objetivo de este documento es ayudar a los ingenieros de red y seguridad a identificar y resolver problemas comunes de red basados principalmente en el análisis de captura de paquetes.

Todos los escenarios presentados en este documento se basan en casos reales de usuarios vistos en el centro de asistencia técnica Cisco Technical Assistance Center (TAC).

El documento trata sobre las capturas de paquetes desde el punto de vista del firewall de última generación (NGFW) de Cisco, pero los mismos conceptos también se aplican a otros tipos de dispositivos.

¿Cómo se recopilan y exportan capturas en la familia de productos NGFW?

En el caso de un appliance Firepower (1xxx, 21xx, 41xx, 93xx) y una aplicación Firepower Threat Defence (FTD), se puede visualizar el procesamiento de paquetes como se muestra en la imagen.

1. Un paquete ingresa a la interfaz de ingreso y es manejado por el switch interno del chasis.

2. El paquete entra en el motor de línea FTD que realiza principalmente comprobaciones L3/L4.

3. Si la política requiere que el paquete sea inspeccionado por el motor Snort (principalmente inspección L7).

4. El motor Snort devuelve un veredicto para el paquete.

5. El motor LINA descarta o reenvía el paquete en función del veredicto de Snort.

6. El paquete sale del chasis a través del switch de chasis interno.

Según la arquitectura mostrada, las capturas de FTD se pueden realizar en tres (3) lugares diferentes:

- FXOS

- Motor de línea FTD

- Motor FTD Snort

Recopilar capturas de FXOS

El proceso se describe en este 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

Las capturas de FXOS solo se pueden tomar en la dirección de ingreso desde el punto de vista del switch interno, se muestran en la imagen aquí.

Aquí se muestran dos puntos de captura por dirección (debido a la arquitectura interna del switch).

Los paquetes capturados en los puntos 2, 3 y 4 tienen una etiqueta de red virtual (VNTag).

Nota: las capturas a nivel de chasis FXOS solo están disponibles en las plataformas FP41xx y FP93xx. FP1xxx y FP21xx no proporcionan esta capacidad.

Habilitar y recopilar capturas de línea de FTD

Puntos de captura principales:

- Interfaz de entrada

- Interfaz de salida

- Ruta de seguridad acelerada (ASP)

Puede utilizar la interfaz de usuario de Firepower Management Center (FMC UI) o la CLI de FTD para habilitar y recopilar las capturas de línea de FTD.

Habilite la captura desde CLI en la interfaz INSIDE:

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

Esta captura coincide con el tráfico entre las IP 192.168.103.1 y 192.168.101.1 en ambas direcciones.

Habilite la captura ASP para ver todos los paquetes descartados por el motor de línea FTD:

firepower# capture ASP type asp-drop all

Exportar una captura de línea de FTD a un servidor FTP:

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

Exportar una captura de línea FTD a un servidor TFTP:

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

A partir de la versión FMC 6.2.x, puede habilitar y recopilar capturas de FTD Line desde la interfaz de usuario de FMC.

Otra forma de recopilar capturas de FTD de un firewall gestionado por FMC es la siguiente.

Paso 1

En el caso de una captura LINA o ASP, copie la captura en el disco FTD.

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

Source capture name [capin]?

Destination filename [capin.pcap]?

!!!!

Paso 2

Vaya al modo experto, localice la captura guardada y cópiela en la ubicación /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

Paso 3

Inicie sesión en el FMC que gestiona el FTD y navegue hasta Dispositivos > Gestión de dispositivos. Localice el dispositivo FTD y seleccione el icono Troubleshooting:

Paso 4

Seleccione Solución de problemas avanzada:

Especifique el nombre del archivo de captura y seleccione Descargar:

Para obtener más ejemplos sobre cómo habilitar/recopilar capturas de la interfaz de usuario de FMC, consulte este documento:

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

Activar y recopilar capturas de Snort de FTD

El punto de captura se muestra aquí en la imagen.

Habilitar captura de nivel 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 escribir la captura en un archivo con el nombre capture.pcap y copiarlo a través de FTP en un 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 obtener más ejemplos de capturas de nivel Snort que incluyan diferentes filtros de captura, consulte este documento:

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

Troubleshoot

Caso 1. Sin TCP SYN en la interfaz de salida

La topología se muestra en la siguiente imagen:

Descripción del problema: HTTP no funciona

Flujo afectado:

Src IP: 192.168.0.100

Dst IP: 10.10.1.100

Protocolo: TCP 80

Análisis de captura

Activar capturas en el motor LINA de 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 - Escenario funcional:

Como base, siempre es muy útil tener capturas de un escenario funcional.

La captura realizada en la interfaz NGFW INSIDE es la que se muestra en la imagen:

Puntos clave:

1. Protocolo de protocolo de enlace TCP de 3 vías.

2. Intercambio de datos bidireccional.

3. Sin retrasos entre los paquetes (según la diferencia de tiempo entre los paquetes)

4. El MAC de origen es el dispositivo de flujo descendente correcto.

La captura realizada en la interfaz exterior de NGFW se muestra en la imagen siguiente:

Puntos clave:

1. Mismos datos que en la captura CAPI.

2. El MAC de destino es el dispositivo ascendente correcto.

Capturas: escenario no funcional

Desde la CLI del dispositivo, las capturas son similares a las siguientes:

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

Contenido de 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 es la imagen de la captura de CAPI en Wireshark:

Puntos clave:

1. Sólo se ven los paquetes TCP SYN (sin protocolo de enlace TCP de 3 vías).

2. Hay 2 sesiones TCP (puerto de origen 3171 y 3172) que no se pueden establecer. El cliente de origen vuelve a enviar los paquetes SYN TCP. Wireshark identifica estos paquetes retransmitidos como retransmisiones TCP.

3. Las retransmisiones de TCP ocurren cada ~3 y luego cada 6 segundos, etc.

4. La dirección MAC de origen proviene del dispositivo de flujo descendente correcto.

Con base en las 2 capturas se puede concluir que:

- Un paquete de 5 tuplas específicas (IP src/dst, puerto src/dst, protocolo) llega al firewall en la interfaz esperada (INSIDE).

- Un paquete no sale del firewall en la interfaz esperada (OUTSIDE).

Acciones recomendadas

Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.

Acción 1. Verifique el Seguimiento de un Paquete Emulado.

Utilice la herramienta packet-tracer para ver cómo se supone que el firewall debe gestionar un paquete. En caso de que la política de acceso del firewall descarte el paquete, el seguimiento del paquete emulado se verá similar a esta salida:

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

Acción 2. Verifique los seguimientos de los paquetes activos.

Habilite el seguimiento de paquetes para verificar cómo el firewall maneja los paquetes SYN TCP reales. De forma predeterminada, sólo se realiza un seguimiento de los primeros 50 paquetes de ingreso:

firepower# capture CAPI trace

Borre el búfer de captura:

firepower# clear capture /all

En caso de que la política de acceso del firewall descarte el paquete, el seguimiento será similar a este resultado:

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

Acción 3. Compruebe los registros de FTD Line.

Para configurar Syslog en FTD a través de FMC, consulte este documento:

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

Se recomienda encarecidamente tener un servidor Syslog externo configurado para los registros de FTD Line. Si no hay ningún servidor Syslog remoto configurado, habilite los registros del búfer local en el firewall mientras resuelve problemas. La configuración de registro que se muestra en este ejemplo es un buen punto inicial:

firepower# show run logging

…

logging enable

logging timestamp

logging buffer-size 1000000

logging buffered informational

Establezca el localizador de terminal en 24 líneas para controlar el localizador de terminal:

firepower# terminal pager 24

Borre el búfer de captura:

firepower# clear logging buffer

Pruebe la conexión y compruebe los registros con un filtro de analizador. En este ejemplo, la política de acceso del firewall descarta los paquetes:

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]

Acción 4. Compruebe las caídas de ASP del firewall.

Si sospecha que el firewall ha descartado el paquete, puede ver los contadores de todos los paquetes descartados por el firewall a nivel de 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

Puede habilitar las capturas para ver todas las caídas de nivel de software ASP:

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

Consejo: Si no está interesado en el contenido del paquete, puede capturar solamente los encabezados del paquete (opción de sólo encabezados). Esto le permite capturar muchos más paquetes en el buffer de captura. Además, puede aumentar el tamaño del búfer de captura (el valor predeterminado es 500 Kbytes) hasta un valor de hasta 32 Mbytes (opción de búfer). Por último, a partir de la versión 6.3 de FTD, la opción de tamaño de archivo permite configurar un archivo de captura de hasta 10 GBytes. En ese caso, sólo podrá ver el contenido de la captura en formato pcap.

Para comprobar el contenido de la captura, puede utilizar un filtro para restringir la búsqueda:

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>

En este caso, dado que los paquetes ya están rastreados en el nivel de interfaz, la razón de la caída no se menciona en la captura ASP. Recuerde que un paquete sólo se puede rastrear en un lugar (interfaz de ingreso o caída de ASP). En ese caso, se recomienda tomar varias caídas de ASP y establecer un motivo de caída de ASP específico. Este es un enfoque recomendado:

1. Borre los contadores de caídas de ASP actuales:

firepower# clear asp drop

2. Envíe el flujo que soluciona problemas a través del firewall (realice una prueba).

3. Verifique nuevamente los contadores de caídas ASP y anote los que han aumentado.

firepower# show asp drop

Frame drop:

No route to host (no-route)                                                234

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

4. Habilite las capturas ASP para las caídas específicas observadas:

firepower# capture ASP_NO_ROUTE type asp-drop no-route

firepower# capture ASP_ACL_DROP type asp-drop acl-drop

5. Envíe el flujo que soluciona problemas a través del firewall (realice una prueba).

6. Compruebe las capturas de ASP. En este caso, los paquetes se descartaron debido a una ruta 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>

Acción 5. Compruebe la tabla de conexiones de línea FTD.

Puede haber casos en los que se espere que el paquete salga de la interfaz 'X', pero por cualquier motivo salga de la interfaz 'Y'. La determinación de la interfaz de salida del firewall se basa en este orden de funcionamiento:

1. Búsqueda de conexión establecida

2. Búsqueda de traducción de direcciones de red (NAT): la fase UN-NAT (NAT de destino) tiene prioridad sobre PBR y la búsqueda de rutas.

3. Routing basado en políticas (PBR)

4. Búsqueda de tabla de routing

Para comprobar la tabla de conexión 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

Puntos clave:

- En función de los indicadores (Aa), la conexión es embrionaria (semiabierta; el firewall solo ha visto TCP SYN).

- Según los puertos de origen/destino, la interfaz de entrada es INSIDE y la interfaz de salida es DMZ.

Esto se puede visualizar en la imagen aquí:

Nota: Dado que todas las interfaces FTD tienen un nivel de seguridad de 0, el orden de la interfaz en la salida show conn se basa en el número de interfaz. Específicamente, la interfaz con vpif-num más alto (número de interfaz de plataforma virtual) se selecciona como interna, mientras que la interfaz con vpif-num más bajo se selecciona como externa. Puede ver el valor de la interfaz vpif con el comando show interface detail. Mejora relacionada, ID de bug de Cisco CSCvi15290 ENH: FTD muestra la direccionalidad de conexión en la salida 'show conn' de 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

Nota: A partir de la versión 6.5 del software Firepower, la versión 9.13.x de ASA, las salidas de los comandos show conn long y show conn detail proporcionan información sobre el iniciador y el respondedor de la conexión

Resultado 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

Resultado 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

Además, el comando show conn long muestra las IPs NATed dentro de un paréntesis en el caso de una Traducción de Dirección de Red:

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

Acción 6. Compruebe la caché del protocolo de resolución de direcciones (ARP) del firewall.

Si el firewall no puede resolver el salto siguiente, el firewall descarta silenciosamente el paquete original (TCP SYN en este caso) y envía continuamente solicitudes ARP hasta que resuelve el salto siguiente.

Para ver la memoria caché ARP del firewall, utilice el comando:

firepower# show arp

Además, para verificar si hay hosts sin resolver, puede utilizar el 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

Si desea verificar más la operación ARP, puede habilitar una captura específica de 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

En esta salida, el firewall (192.168.2.50) intenta resolver el salto siguiente (192.168.2.72), pero no hay respuesta ARP

El resultado aquí muestra un escenario funcional con una resolución ARP adecuada:

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

En caso de que no haya ninguna entrada ARP en el lugar, un seguimiento de un paquete SYN TCP activo muestra:

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 se puede ver en el resultado, el seguimiento muestra Action: allow incluso cuando el salto siguiente no es alcanzable y el paquete es silenciosamente descartado por el firewall. En este caso, la herramienta packet-tracer también debe ser verificada ya que proporciona una salida más 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

En las últimas versiones de ASA/Firepower, el mensaje anterior se ha optimizado para:

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

Resumen de posibles causas y acciones recomendadas

Si sólo ve un paquete TCP SYN en las interfaces de ingreso, pero ningún paquete TCP SYN enviado desde la interfaz de egreso esperada, algunas causas posibles son:

Posible Causa

Acciones recomendadas

La política de acceso del firewall descarta el paquete.

- Utilice packet-tracer o capture w/trace para ver cómo el firewall maneja el paquete.

- Compruebe los registros del firewall.

- Verifique las caídas de ASP del firewall (show asp drop o capture type asp-drop).

- Compruebe los eventos de conexión FMC. Esto supone que la regla tiene el registro habilitado.

El filtro de captura es incorrecto.

- Utilice packet-tracer o capture w/trace para ver si hay traducción NAT que modifique la IP de origen o de destino. En ese caso, ajuste el filtro de captura.

- El resultado del comando show conn long muestra las IPs NATed.

El paquete se envía a una interfaz de salida diferente.

- Utilice packet-tracer o capture w/trace para ver cómo el firewall maneja el paquete. Recuerde el orden de las operaciones que se refieren a la determinación de la interfaz de egreso, la conexión actual, UN-NAT, PBR y la búsqueda de la tabla de ruteo.

- Compruebe los registros del firewall.

- Verifique la tabla de conexión del firewall (show conn).

Si el paquete se envía a una interfaz incorrecta porque coincide con una conexión actual, utilice el comando clear conn address y especifique la 5-tupla de la conexión que desea borrar.

No hay ruta hacia el destino.

- Utilice packet-tracer o capture w/trace para ver cómo el firewall maneja el paquete.

- Verifique las caídas de ASP del firewall (show asp drop) para ver el motivo de la caída sin ruta.

No hay ninguna entrada ARP en la interfaz de salida.

- Verifique la memoria caché ARP del firewall (show arp).

- Utilice packet-tracer para ver si hay una adyacencia válida.

La interfaz de salida está inactiva.

Verifique la salida del comando show interface ip brief en el firewall y verifique el estado de la interfaz.

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

Esta imagen muestra la topología:

Descripción del problema: HTTP no funciona

Flujo afectado:

Src IP: 192.168.0.100

Dst IP: 10.10.1.100

Protocolo: TCP 80

Análisis de captura

Activar capturas en el motor LINA de 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 - Escenario no funcional:

Desde la CLI del dispositivo, las capturas son las siguientes:

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

Contenido de 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>

...

Contenido de 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 imagen muestra la captura de CAPI en Wireshark.

Puntos clave:

1. El origen envía un paquete TCP SYN.

2. Se envía un TCP RST hacia el origen.

3. El origen retransmite los paquetes TCP SYN.

4. Las direcciones MAC son correctas (en los paquetes de entrada, la dirección MAC de origen pertenece al router de flujo descendente, la dirección MAC de destino pertenece a la interfaz interna del firewall).

Esta imagen muestra la captura de CAPO en Wireshark:

Puntos clave:

1. El origen envía un paquete TCP SYN.

2. Llega un TCP RST a la interfaz OUTSIDE.

3. El origen retransmite los paquetes TCP SYN.

4. Las direcciones MAC son correctas (en los paquetes de salida, el firewall OUTSIDE es el MAC de origen, el router ascendente es el MAC de destino).

Con base en las 2 capturas se puede concluir que:

- El intercambio de señales TCP de 3 vías entre el cliente y el servidor no se completa

- Hay un TCP RST que llega a la interfaz de salida del firewall

- El firewall "habla" con los dispositivos de flujo ascendente y descendente adecuados (según las direcciones MAC)

Acciones recomendadas

Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.

Acción 1. Verifique la dirección MAC de origen que envía el TCP RST.

Verifique que el MAC de destino visto en el paquete TCP SYN sea el mismo que el MAC de origen visto en el paquete TCP RST.

Esta comprobación tiene como objetivo confirmar 2 cosas:

- Verifique que no haya ningún flujo asimétrico.

- Verifique que el MAC pertenezca al dispositivo ascendente esperado.

Acción 2. Compare los paquetes de entrada y salida.

Compare visualmente los 2 paquetes de Wireshark para verificar que el firewall no modifique/dañe los paquetes. Se resaltan algunas diferencias esperadas.

Puntos clave:

1. Las marcas de tiempo son diferentes. Por otro lado, la diferencia debe ser pequeña y razonable. Esto depende de las funciones y las comprobaciones de políticas aplicadas al paquete, así como de la carga en el dispositivo.

2. La longitud de los paquetes puede diferir especialmente si hay un encabezado dot1Q agregado/eliminado por el firewall en un solo lado.

3. Las direcciones MAC son diferentes.

4. Un encabezado dot1Q puede estar en su lugar si la captura fue tomada en una subinterfaz.

5. Las direcciones IP son diferentes en caso de que se aplique NAT o traducción de direcciones de puerto (PAT) al paquete.

6. Los puertos de origen o de destino son diferentes en caso de que se aplique NAT o PAT al paquete.

7. Si inhabilita la opción Wireshark Relative Sequence Number, verá que los números de secuencia TCP/números de reconocimiento son modificados por el firewall debido a la aleatorización del Número de secuencia inicial (ISN).

8. Algunas opciones TCP se pueden sobrescribir. Por ejemplo, el firewall cambia de forma predeterminada el tamaño máximo de segmento (MSS) de TCP a 1380 para evitar la fragmentación de paquetes en la ruta de tránsito.

Acción 3. Toma una captura en el destino.

Si es posible, tome una captura en el propio destino. Si esto no es posible, tome una captura lo más cerca posible del destino. El objetivo aquí es verificar quién envía el TCP RST (¿es el servidor de destino o hay algún otro dispositivo en la trayectoria?).

Caso 3. Protocolo de enlace TCP de 3 vías + RST desde un terminal

Esta imagen muestra la topología:

Descripción del problema: HTTP no funciona

Flujo afectado:

Src IP: 192.168.0.100

Dst IP: 10.10.1.100

Protocolo: TCP 80

Análisis de captura

Activar capturas en el motor LINA de 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 - Escenario no funcional:

Hay un par de maneras diferentes en que este problema puede manifestarse en capturas.

3.1 - Protocolo de enlace TCP de 3 vías + RST retrasado del cliente

Tanto el firewall captura CAPI como CAPO contienen los mismos paquetes, como se muestra en la imagen.

Puntos clave:

1. El protocolo de enlace de 3 vías TCP pasa a través del firewall.

2. El servidor retransmite el SYN/ACK.

3. El cliente retransmite el ACK.

4. Después de ~20 segundos, el cliente se da por vencido y envía un TCP RST.

Acciones recomendadas

Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.

Acción 1. Realice las capturas lo más cerca posible de los dos terminales.

Las capturas del firewall indican que el servidor no procesó el ACK del cliente. Esto se basa en los siguientes hechos:

- El servidor retransmite el SYN/ACK.

- El cliente retransmite el ACK.

- El cliente envía un TCP RST o FIN/ACK antes de cualquier dato.

La captura en el servidor muestra el problema. El ACK del cliente del intercambio de señales TCP de 3 vías nunca llegó:

3.2 - Protocolo de enlace TCP de 3 vías + FIN/ACK retrasado del cliente + RST retrasado del servidor

Tanto el firewall captura CAPI como CAPO contienen los mismos paquetes, como se muestra en la imagen.

Puntos clave:

1. El protocolo de enlace de 3 vías TCP pasa a través del firewall.

2. Después de unos 5 segundos, el cliente envía un mensaje FIN/ACK.

3. Después de unos 20 segundos, el servidor se rinde y envía un TCP RST.

En base a esta captura, se puede concluir que aunque existe un protocolo de enlace TCP de 3 vías a través del firewall, parece que nunca se completa realmente en un terminal (las retransmisiones indican esto).

Acciones recomendadas

Igual que en el caso 3.1

3.3 - Protocolo de enlace TCP de 3 vías + RST retrasado del cliente

Tanto el firewall captura CAPI como CAPO contienen los mismos paquetes, como se muestra en la imagen.

Puntos clave:

1. El protocolo de enlace de 3 vías TCP pasa a través del firewall.

2. Después de ~20 segundos, el cliente se da por vencido y envía un TCP RST.

Sobre la base de estas capturas, se puede concluir que:

- Después de 5-20 segundos, un terminal se da por vencido y decide terminar la conexión.

Acciones recomendadas

Igual que en el caso 3.1

3.4 - Protocolo de enlace TCP de 3 vías + RST inmediato desde el servidor

Tanto las capturas de firewall CAPI como CAPO contienen estos paquetes, como se muestra en la imagen.

Puntos clave:

1. El protocolo de enlace de 3 vías TCP pasa a través del firewall.

2. Hay un TCP RST del servidor unos milisegundos después del paquete ACK.

Acciones recomendadas

Acción: realice las capturas lo más cerca posible del servidor.

Un TCP RST inmediato del servidor podría indicar un servidor que no funciona correctamente o un dispositivo en la trayectoria que envía el TCP RST. Realice una captura en el propio servidor y determine el origen del TCP RST.

Caso 4. TCP RST desde el cliente

Esta imagen muestra la topología:

Descripción del problema: HTTP no funciona.

Flujo afectado:

Src IP: 192.168.0.100

Dst IP: 10.10.1.100

Protocolo: TCP 80

Análisis de captura

Activar capturas en el motor LINA de 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 - Escenario no funcional:

Estos son los contenidos de 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

Estos son los contenidos de 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

Los registros del firewall muestran:

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

Estos registros indican que hay un TCP RST que llega a la interfaz de firewall INSIDE

Captura de CAPI en Wireshark:

Siga la primera secuencia TCP, como se muestra en la imagen.

En Wireshark, navegue hasta Edit > Preferences > Protocols > TCP y deseleccione la opción Relative sequence numbers como se muestra en la imagen.

Esta imagen muestra el contenido del primer flujo en la captura CAPI:

Puntos clave:

1. El cliente envía un paquete TCP SYN.

2. El cliente envía un paquete RST TCP.

3. El paquete TCP SYN tiene un valor de número de secuencia igual a 4098574664.

El mismo flujo en la captura de CAPO contiene:

Puntos clave:

1. El cliente envía un paquete TCP SYN. El firewall aleatoriza el ISN.

2. El cliente envía un paquete RST TCP.

Con base en las dos capturas se puede concluir que:

- No hay intercambio de señales TCP de 3 vías entre el cliente y el servidor.

- Hay un TCP RST que viene del cliente. El valor del número de secuencia RST TCP en la captura CAPI es 1386249853.

Acciones recomendadas

Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.

Acción 1. Tome una captura en el cliente.

En función de las capturas recopiladas en el firewall, existe un fuerte indicador de un flujo asimétrico. Esto se basa en el hecho de que el cliente envía un TCP RST con un valor de 1386249853 (el ISN aleatorizado):

Puntos clave:

1. El cliente envía un paquete TCP SYN. El número de secuencia es 4098574664 y es el mismo que se ve en la interfaz interna del firewall (CAPI)

2. Hay un TCP SYN/ACK con el número ACK 1386249853 (que se espera debido a la aleatorización ISN). Este paquete no se vio en las capturas del firewall

3. El cliente envía un TCP RST ya que esperaba un SYN/ACK con un valor de número ACK de 4098574665, pero recibió un valor de 1386249853

Esto se puede visualizar como:

Acción 2. Compruebe el enrutamiento entre el cliente y el firewall.

Confirme que:

- Las direcciones MAC vistas en las capturas son las esperadas.

- Asegúrese de que el routing entre el firewall y el cliente sea simétrico.

Hay escenarios donde el RST proviene de un dispositivo que se encuentra entre el firewall y el cliente mientras hay un ruteo asimétrico en la red interna. En la imagen se muestra un caso típico:

En este caso, la captura tiene este contenido. Observe la diferencia entre la dirección MAC de origen del paquete TCP SYN y la dirección MAC de origen del RST TCP y la dirección MAC de destino del paquete 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. Transferencia TCP lenta (situación 1)

Descripción de problemas:

La transferencia SFTP entre los hosts 10.11.4.171 y 10.77.19.11 es lenta. Aunque el ancho de banda mínimo (BW) entre los 2 hosts es de 100 Mbps, la velocidad de transferencia no supera los 5 Mbps.

Al mismo tiempo, la velocidad de transferencia entre los hosts 10.11.2.124 y 172.25.18.134 es bastante mayor.

Teoría Precedente:

La velocidad máxima de transferencia para un solo flujo TCP está determinada por el producto de retraso de ancho de banda (BDP). La fórmula utilizada se muestra en la imagen:

Para obtener más información sobre la BDP, consulte los recursos aquí:

- ¿Por qué su aplicación sólo utiliza 10 Mbps incluso si el enlace es de 1 Gbps?

- BRKSEC-3021 - Avanzado - Maximización del rendimiento del firewall

Escenario 1. Transferencia lenta

Esta imagen muestra la topología:

Flujo afectado:

Src IP: 10.11.4.171

Dst IP: 10.77.19.11

Protocolo: SFTP (FTP sobre SSH)

Análisis de captura

Habilitar capturas en el motor LINA de 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

Advertencia: las capturas de LINA en FP1xxx y FP21xx afectan a la velocidad de transferencia del tráfico que pasa a través del FTD. No habilite las capturas de LINA en las plataformas FP1xxx y FP21xxx cuando resuelva problemas de rendimiento (transferencia lenta a través del FTD). En su lugar, utilice SPAN o un dispositivo de toque de hardware además de las capturas en los hosts de origen y destino. El problema se documenta con el ID de bug de Cisco 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.

Acciones recomendadas

Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.

Cálculo del tiempo de ida y vuelta (RTT)

Primero, identifique el flujo de transferencia y sígalo:

Cambie la vista Wireshark para mostrar los segundos desde el paquete anterior mostrado. Esto facilita el cálculo del RTT:

El RTT se puede calcular agregando los valores de tiempo entre 2 intercambios de paquetes (uno hacia el origen y otro hacia el destino). En este caso, el paquete #2 muestra el RTT entre el firewall y el dispositivo que envió el paquete SYN/ACK (servidor). El paquete #3 muestra el RTT entre el firewall y el dispositivo que envió el paquete ACK (cliente). La suma de los 2 números proporciona una buena estimación sobre el RTT de extremo a extremo:

RTT ≈ 80 ms

Cálculo del Tamaño de Ventana TCP

Expanda un paquete TCP, expanda el encabezado TCP, seleccione Tamaño de ventana calculado y seleccione Aplicar como columna:

Verifique la columna Valor de tamaño de ventana calculado para ver cuál fue el valor de tamaño de ventana máximo durante la sesión TCP. También puede seleccionar el nombre de la columna y ordenar los valores.

Si prueba una descarga de archivos (servidor > cliente), debe comprobar los valores anunciados por el servidor. El valor del tamaño máximo de la ventana anunciado por el servidor determina la velocidad máxima de transferencia alcanzada.

En este caso, el tamaño de la ventana TCP es ≈ 50000 bytes

En función de estos valores y con el uso de la fórmula Bandwidth Delay Product, se obtiene el ancho de banda teórico máximo que se puede alcanzar en estas condiciones: 50000*8/0,08 = ancho de banda teórico máximo de 5 Mbps.

Esto coincide con lo que el cliente experimenta en este caso.

Verifique atentamente el protocolo de enlace TCP de 3 vías. Ambos lados, y más importante aún el servidor, anuncian un valor de escala de ventana de 0 que significa 2^0 = 1 (sin escala de ventanas). Esto afecta negativamente a la velocidad de transferencia:

En este punto, hay una necesidad de tomar una captura en el servidor, confirmar que es el que anuncia la escala de ventana = 0 y reconfigurarlo (consulte la documentación del servidor para ver cómo hacer esto).

Situación hipotética 2. Transferencia rápida

Ahora examinemos el buen escenario (transferencia rápida a través de la misma red):

Topología:

El flujo de interés:

Src IP: 10.11.2.124

Dst IP: 172.25.18.134

Protocolo: SFTP (FTP sobre SSH)

Activar capturas en el motor LINA de 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 del tiempo de ida y vuelta (RTT): en este caso, el RTT es ≈ 300 ms.

Cálculo de Tamaño de Ventana TCP: El servidor anuncia un factor de escala de ventana TCP de 7.

El tamaño de la ventana TCP del servidor es de ≈ 1600000 bytes:

En función de estos valores, la fórmula de producto de retraso de ancho de banda ofrece:

1600000*8/0,3 = velocidad máxima de transferencia teórica de 43 Mbps

Caso 6. Transferencia TCP lenta (situación 2)

Descripción del problema: La transferencia de archivos FTP (descarga) a través del firewall es lenta.

Esta imagen muestra la topología:

Flujo afectado:

Src IP: 192.168.2.220

Dst IP: 192.168.1.220

Protocolo: FTP

Análisis de captura

Activar capturas en el motor LINA de 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

Seleccione un paquete FTP-DATA y siga el canal de datos FTP en captura FTD INSIDE (CAPI):

El contenido de la secuencia FTP-DATA:

El contenido de captura de CAPO:

Puntos clave:

1. Hay paquetes TCP Out-Of-Order (OOO).

2. Hay una retransmisión TCP.

3. Hay una indicación de pérdida de paquetes (paquetes perdidos).

Sugerencia: guarde las capturas mientras navega hasta Archivo > Exportar paquetes especificados. A continuación, guarde sólo el intervalo de paquetes mostrado

Acciones recomendadas

Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.

Acción 1. Identifique la ubicación de pérdida de paquetes.

En casos como este, debe tomar capturas simultáneas y utilizar la metodología de dividir y conquistar para identificar los segmentos de red que causan la pérdida de paquetes. Desde el punto de vista del firewall, existen tres escenarios principales:

1. La pérdida de paquetes es causada por el propio firewall.

2. La pérdida de paquetes se produce después del dispositivo de firewall (dirección del servidor al cliente).

3. La pérdida de paquetes se produce en dirección ascendente al dispositivo de firewall (dirección del cliente al servidor).

Pérdida de paquetes causada por el firewall: para identificar si la pérdida de paquetes es causada por el firewall, es necesario comparar la captura de ingreso con la captura de egreso. Hay muchas maneras de comparar 2 capturas diferentes. En esta sección se muestra una forma de realizar esta tarea.

Procedimiento para comparar 2 capturas con el fin de identificar la pérdida de paquetes

Paso 1. Asegúrese de que las 2 capturas contengan paquetes de la misma ventana de tiempo. Esto significa que no debe haber paquetes en una captura que fueron capturados antes o después de la otra captura. Hay algunas formas de hacerlo:

- Verifique los valores de identificación IP (ID) del primer y último paquete.

- Verifique los valores de la marca de tiempo del primer y último paquete.

En este ejemplo puede ver que los primeros paquetes de cada captura tienen los mismos valores de ID de IP:

En caso de que no sean iguales, entonces:

1. Compare las marcas de tiempo del primer paquete de cada captura.

2. Desde la captura con la última marca de tiempo, obtenga un filtro de ella, cambie el filtro de marca de tiempo de == a >= (el primer paquete) y <= (el último paquete), p. ej.:

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

3. Exporte los paquetes especificados a una nueva captura, seleccione Archivo > Exportar paquetes especificados y guarde los paquetes mostrados. En este punto, ambas capturas deben contener paquetes que cubran la misma ventana de tiempo. Ahora puede iniciar la comparación de las 2 capturas.

Paso 2. Especifique qué campo de paquete se utiliza para la comparación entre las 2 capturas. Ejemplo de campos que se pueden utilizar:

- Identificación de IP

- Número de secuencia RTP

- Número de secuencia ICMP

Cree una versión de texto de cada captura que contenga el campo para cada paquete especificado en el paso 1. Para hacer esto, deje solamente la columna de interés, por ejemplo, si desea comparar paquetes basados en la identificación IP, modifique la captura como se muestra en la imagen.

El resultado:

Paso 3. Cree una versión de texto de la captura (Archivo > Exportar disecciones de paquetes > Como texto sin formato...), como se muestra en la imagen:

Desactive las opciones Incluir encabezados de columna y Detalles de paquete para exportar sólo los valores del campo mostrado, como se muestra en la imagen:

Paso 4. Ordene los paquetes de los archivos. Puede utilizar el comando sort de Linux para hacer esto:

# sort CAPI_IDs > file1.sorted

# sort CAPO_IDs > file2.sorted

Paso 5. Utilice una herramienta de comparación de texto (por ejemplo, WinMerge) o el comando Linux diff para encontrar las diferencias entre las 2 capturas.

En este caso, la captura de CAPI y CAPO para el tráfico de datos FTP es idéntica. Esto prueba que la pérdida de paquetes no fue causada por el firewall.

Identifique la pérdida de paquetes de flujo ascendente/descendente.

Puntos clave:

1. Este paquete es una retransmisión TCP. Específicamente, es un paquete TCP SYN enviado desde el cliente al servidor para datos FTP en modo pasivo. Dado que el cliente reenvía el paquete y puede ver el SYN (paquete #1) inicial, el paquete se perdió en dirección ascendente hacia el firewall.

En este caso, existe la posibilidad de que el paquete SYN llegara al servidor, pero el paquete SYN/ACK se perdió en el camino de regreso:

2. Hay un paquete del servidor y Wireshark identificó que el segmento anterior no fue visto/capturado. Dado que el paquete no capturado se envió desde el servidor al cliente y no se vio en la captura del firewall, esto significa que el paquete se perdió entre el servidor y el firewall.

Esto indica que hay pérdida de paquetes entre el servidor FTP y el firewall.

Acción 2. Tome Capturas Adicionales.

Realice capturas adicionales junto con capturas en los terminales. Intente aplicar el método divide y vencerás para aislar aún más el segmento problemático que causa la pérdida de paquetes.

Puntos clave:

1. El receptor (el cliente FTP en este caso) rastrea los números de secuencia TCP entrantes. Si detecta que se ha omitido un paquete (se omitió un número de secuencia esperado), genera un paquete ACK con el ACK='número de secuencia esperado que se omitió'. En este ejemplo, Ack=2224386800.

2. El ACK de duplicación activa una retransmisión rápida TCP (retransmisión dentro de los 20 mseg después de que se reciba un ACK duplicado).

¿Qué significan las ACK duplicadas?

- Algunos ACK duplicados, pero ninguna retransmisión real, indican que es más probable que haya paquetes que lleguen fuera de servicio.

- Las ACK duplicadas seguidas de retransmisiones reales indican que hay cierta cantidad de pérdida de paquetes.

Acción 3. Calcule el tiempo de procesamiento del firewall para los paquetes de tránsito.

Aplique la misma captura en 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

Exporte la verificación de captura para comprobar la diferencia de tiempo entre los paquetes de ingreso y egreso

Caso 7. Problema de conectividad TCP (corrupción de paquetes)

Descripción de problemas:

El cliente inalámbrico (192.168.21.193) intenta conectarse a un servidor de destino (192.168.14.250 - HTTP) y existen dos situaciones diferentes:

- Cuando el cliente se conecta al punto de acceso (AP) 'A', la conexión HTTP no funciona.

- Cuando el cliente se conecta al punto de acceso (AP) 'B', la conexión HTTP funciona.

Esta imagen muestra la topología:

Flujo afectado:

Src IP: 192.168.21.193

Dst IP: 192.168.14.250

Protocolo: TCP 80

Análisis de captura

Habilitar capturas en el motor LINA de 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 - Escenario funcional:

Como base, siempre es muy útil tener capturas de un escenario de funcionalidad comprobada.

Esta imagen muestra la captura realizada en la interfaz NGFW INSIDE

Esta imagen muestra la captura realizada en la interfaz EXTERNA de NGFW.

Puntos clave:

1. Las 2 capturas son casi idénticas (considere la aleatorización ISN).

2. No hay indicios de pérdida de paquetes.

3. Sin paquetes fuera de servicio (OOO)

4. Hay 3 solicitudes GET HTTP. El primero recibe un mensaje de redirección 404 ‘No encontrado’, el segundo obtiene un 200 ‘OK’ y el tercero recibe un mensaje de redirección 304 ‘No modificado’.

Capturas: situación de fallo conocido:

El contenido de captura de ingreso (CAPI).

Puntos clave:

1. Existe un protocolo de enlace TCP de 3 vías.

2. Hay retransmisiones TCP e indicaciones de pérdida de paquetes.

3. Wireshark identifica un paquete (TCP ACK) como Malformado.

Esta imagen muestra el contenido de captura de salida (CAPO).

Puntos clave:

Las 2 capturas son casi idénticas (considere la aleatorización ISN):

1. Existe un protocolo de enlace TCP de 3 vías.

2. Hay retransmisiones TCP e indicaciones de pérdida de paquetes.

3. Wireshark identifica un paquete (TCP ACK) como Malformado.

Verifique el paquete mal formado:

Puntos clave:

1. Wireshark identifica el paquete como Malformado.

2. Tiene una longitud de 2 bytes.

3. Hay una carga útil TCP de 2 bytes.

4. La carga útil es de 4 ceros adicionales (00 00).

Acciones recomendadas

Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.

Acción 1. Realice capturas adicionales. Incluya capturas en los puntos finales y, si es posible, intente aplicar el método de división y conquista para aislar el origen de la corrupción del paquete, por ejemplo:

En este caso, los 2 bytes adicionales fueron agregados por el controlador de interfaz 'A' del switch y la solución fue reemplazar el switch que causa la corrupción.

Caso 8. Problema de conectividad UDP (paquetes faltantes)

Descripción del problema: los mensajes de Syslog (UDP 514) no se ven en el servidor de Syslog de destino.

Esta imagen muestra la topología:

Flujo afectado:

Src IP: 192.168.1.81

Dst IP: 10.10.1.73

Protocolo: UDP 514

Análisis de captura

Habilitar capturas en el motor LINA de 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

Las capturas de FTD no muestran paquetes:

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

Acciones recomendadas

Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.

Acción 1. Compruebe la tabla de conexiones FTD.

Para comprobar una conexión específica, puede utilizar esta sintaxis:

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

Puntos clave:

1. Las interfaces de entrada y salida son las mismas (giro en U).

2. El número de bytes tiene un valor significativamente grande (~5 GBytes).

3. El indicador "o" indica descarga de flujo (flujo acelerado de hardware). Esta es la razón por la que las capturas de FTD no muestran ningún paquete. La descarga de flujo solo se admite en las plataformas 41xx y 93xx. En este caso, el dispositivo es un 41xx.

Acción 2. Realice capturas a nivel de chasis.

Conéctese al administrador del chasis Firepower y habilite la captura en la interfaz de ingreso (E1/2 en este caso) y en las interfaces de la placa posterior (E1/9 y E1/10), como se muestra en la imagen:

Después de unos segundos:

Sugerencia: en Wireshark, excluya los paquetes etiquetados con VN para eliminar la duplicación de paquetes en el nivel de interfaz física

Antes:

Después de:

Puntos clave:

1. Se aplica un filtro de visualización para quitar duplicados de paquetes y mostrar sólo los registros del sistema.

2. La diferencia entre los paquetes está en el nivel de microsegundos. Esto indica una velocidad de paquetes muy alta.

3. El valor de Tiempo de vida (TTL) disminuye de forma continua. Esto indica un loop de paquete.

Acción 3. Utilice packet-tracer.

Dado que los paquetes no atraviesan el motor LINA del firewall, no puede realizar un seguimiento activo (captura con seguimiento), pero puede rastrear un paquete emulado con 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

Acción 4. Confirme el enrutamiento de FTD.

Verifique la tabla de ruteo del firewall para ver si hay algún problema de ruteo:

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

Puntos clave:

1. La ruta apunta hacia la interfaz de salida correcta.

2. La ruta se aprendió hace unos minutos (0:02:37).

Acción 5. Confirme el tiempo de actividad de conexión.

Verifique el tiempo de actividad de la conexión para ver cuándo se estableció esta conexión:

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

Punto clave:

1. La conexión se estableció hace aproximadamente 4 minutos (esto es antes de la instalación de la ruta EIGRP en la tabla de ruteo)

Acción 6. Borre la conexión establecida.

En este caso, los paquetes coinciden con una conexión establecida y se rutean a una interfaz de salida incorrecta; esto provoca un loop. Esto se debe al orden de operaciones del firewall:

1. Búsqueda de conexión establecida (esto tiene prioridad sobre la búsqueda de tabla de ruteo global).

2. Búsqueda de traducción de direcciones de red (NAT): la fase UN-NAT (NAT de destino) tiene prioridad sobre PBR y la búsqueda de rutas.

3. Routing basado en políticas (PBR)

4. Búsqueda de tabla de routing global

Dado que la conexión nunca se agota (el cliente Syslog envía paquetes continuamente mientras el tiempo de espera inactivo de la conexión UDP es de 2 minutos), es necesario borrar manualmente la conexión:

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

1 connection(s) deleted.

Verifique que se haya establecido una nueva conexión:

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

Acción 7. Configure el tiempo de espera de conexión flotante.

Esta es la solución adecuada para abordar el problema y evitar un ruteo subóptimo, especialmente para los flujos UDP. Vaya a Devices > Platform Settings > Timeout y establezca el valor:

Puede encontrar más detalles sobre el tiempo de espera de conexión flotante en la Referencia 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 conectividad HTTPS (situación 1)

Descripción del problema: No se puede establecer la comunicación HTTPS entre el cliente 192.168.201.105 y el servidor 192.168.202.101

Esta imagen muestra la topología:

Flujo afectado:

Src IP: 192.168.201.111

Dst IP: 192.168.202.111

Protocolo: TCP 443 (HTTPS)

Análisis de captura

Habilitar capturas en el motor LINA de FTD:

La IP utilizada en la captura OUTSIDE es diferente debido a la configuración de Traducción de Dirección de Puerto .

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 imagen muestra la captura realizada en la interfaz NGFW INSIDE:

Puntos clave:

1. Existe un protocolo de enlace TCP de 3 vías.

2. Se inicia la negociación SSL. El cliente envía un mensaje de saludo de cliente.

3. Se ha enviado un ACK TCP al cliente.

4. Hay un TCP RST enviado al cliente.

Esta imagen muestra la captura realizada en la interfaz EXTERNA de NGFW.

Puntos clave:

1. Existe un protocolo de enlace TCP de 3 vías.

2. Se inicia la negociación SSL. El cliente envía un mensaje de saludo de cliente.

3. Hay retransmisiones TCP enviadas desde el firewall hacia el servidor.

4. Hay un TCP RST enviado al servidor.

Acciones recomendadas

Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.

Acción 1. Realice capturas adicionales.

Una captura tomada en el servidor revela que el servidor recibió los saludos del cliente TLS con una suma de comprobación TCP dañada y los descarta silenciosamente (no hay RST TCP ni ningún otro paquete de respuesta hacia el cliente):

Cuando se combinan todos los elementos:

En este caso, para entender, hay una necesidad de habilitar en Wireshark la opción Validar la suma de comprobación TCP si es posible. Vaya a Edit > Preferences > Protocols > TCP, como se muestra en la imagen.

En este caso, es útil poner las capturas lado a lado para obtener la imagen completa:

Puntos clave:

1. Existe un protocolo de enlace TCP de 3 vías. Los ID de IP son los mismos. Esto significa que el flujo no fue procesado como proxy por el firewall.

2. Un saludo de cliente TLS proviene del cliente con ID IP 12083. El paquete es proxy por el firewall (el firewall, en este caso, se configuró con la política de descifrado de TLS) y el ID de IP se cambia a 52534. Además, la suma de comprobación TCP del paquete se daña (debido a un defecto de software que luego se corrige).

3. El firewall se encuentra en el modo de proxy TCP y envía un ACK al cliente (que suplanta el servidor).

4. El firewall no recibe ningún paquete TCP ACK del servidor y retransmite el mensaje de saludo del cliente TLS. Esto se debe de nuevo al modo de proxy TCP que activó el firewall.

5. Después de ~30 segundos, el firewall se da por vencido y envía un TCP RST hacia el cliente.

6. El firewall envía un TCP RST hacia el servidor.

Para referencia:

Procesamiento de intercambio de señales Firepower TLS/SSL

Caso 10. Problema de conectividad HTTPS (situación 2)

Descripción del problema: el registro de FMC Smart License falla.

Esta imagen muestra la topología:

Flujo afectado:

Src IP: 192.168.0.100

Dst: tools.cisco.com

Protocolo: TCP 443 (HTTPS)

Análisis de captura

Habilite la captura en la interfaz de gestión de FMC:

Intente registrarse de nuevo. Cuando aparezca el mensaje de error, presione CTRL-C para detener la 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#

Recopile la captura del FMC (System > Health > Monitor, seleccione el dispositivo y seleccione Advanced Troubleshooting), como se muestra en la imagen:

La imagen muestra la captura de FMC en Wireshark:

Sugerencia: Para comprobar todas las sesiones TCP nuevas capturadas, utilice el filtro de visualización tcp.flags==0x2 en Wireshark. Esto filtra todos los paquetes SYN TCP que fueron capturados.

Sugerencia: Aplique como columna el campo Nombre del servidor del saludo de SSL Client.

Sugerencia: aplique este filtro de visualización para ver sólo los mensajes de saludo del cliente ssl.handshake.type == 1

Nota: En el momento de escribir este documento, el portal de licencias inteligentes (tools.cisco.com) utiliza las siguientes direcciones IP: 72.163.4.38, 173.37.145.8

Siga uno de los flujos TCP (Follow > TCP Stream), como se muestra en la imagen.

Puntos clave:

1. Existe un protocolo de enlace TCP de 3 vías.

2. El cliente (FMC) envía un mensaje de saludo del cliente SSL al portal de Smart Licensing.

3. El ID de sesión SSL es 0. Esto significa que no se ha reanudado el período de sesiones.

4. El servidor de destino responde con los mensajes Hello de servidor, Certificate y Hello Done de servidor.

5. El cliente envía una alerta de error SSL que se refiere a una "CA desconocida".

6. El cliente envía un TCP RST para cerrar la sesión.

7. La duración total de la sesión TCP (desde el establecimiento hasta el cierre) fue de ~0,5 s.

Seleccione el Certificado de servidor y expanda el campo emisor para ver commonName. En este caso, el nombre común revela un dispositivo que ejecuta la función Man-in-the-middle (MITM).

Esto se muestra en esta imagen:

Acciones recomendadas

Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.

Acción 1. Realice capturas adicionales.

Realizar capturas en el dispositivo de firewall de tránsito:

CAPI muestra:

CAPO muestra:

Estas capturas demuestran que el firewall de tránsito modifica el certificado de servidor (MITM)

Acción 2. Compruebe los registros del dispositivo.

Puede recopilar el paquete FMC TS como se describe en este documento:

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

En este caso, el archivo /dir-archives/var-log/process_stdout.log muestra mensajes como este:

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/

Solución recomendada

Inhabilite el MITM para el flujo específico de modo que FMC pueda registrarse correctamente en la nube de Smart Licensing.

Caso 11. Problema de conectividad IPv6

Descripción del problema: los hosts internos (situados detrás de la interfaz INTERNA del firewall) no pueden comunicarse con los hosts externos (hosts situados detrás de la interfaz EXTERNA del firewall).

Esta imagen muestra la topología:

Flujo afectado:

IP de origen: fc00:1:1:1::100

Dst IP: fc00:1:1:2::2

Protocolo: cualquiera

Análisis de captura

Activar capturas en el motor LINA de FTD.

firepower# capture CAPI int INSIDE match ip any6 any6

firepower# capture CAPO int OUTSIDE match ip any6 any6

Capturas: escenario no funcional

Estas capturas se realizaron en paralelo con una prueba de conectividad ICMP de IP fc00:1:1:1:1:100 (router interno) a IP fc00:1:1:2:2 (router ascendente).

La captura en la interfaz de firewall INSIDE contiene:

Puntos clave:

1. El router envía un mensaje de solicitud de vecino IPv6 y solicita la dirección MAC del dispositivo ascendente (IP fc00:1:1:1::1).

2. El firewall responde con un anuncio de vecino IPv6.

3. El router envía una solicitud de eco ICMP.

4. El firewall envía un mensaje de solicitud de vecino IPv6 y solicita la dirección MAC del dispositivo descendente (fc00:1:1:1::100).

5. El router responde con un anuncio de vecino IPv6.

6. El router envía solicitudes de eco ICMP IPv6 adicionales.

La captura en la interfaz EXTERNA del firewall contiene:

Puntos clave:

1. El firewall envía un mensaje de solicitud de vecino IPv6 que solicita la dirección MAC del dispositivo ascendente (IP fc00:1:1:2::2).

2. El router responde con un anuncio de vecino IPv6.

3. El firewall envía una solicitud de eco ICMP IPv6.

4. El dispositivo ascendente (router fc00:1:1:2:2) envía un mensaje de solicitud de vecino IPv6 que solicita la dirección MAC de la dirección IPv6 fc00:1:1:1::100.

5. El firewall envía una solicitud de eco ICMP IPv6 adicional.

6. El router ascendente envía un mensaje de solicitud de vecino IPv6 adicional que solicita la dirección MAC de la dirección IPv6 fc00:1:1:1::100.

El punto 4 es muy interesante. Normalmente, el router ascendente solicita la dirección MAC de la interfaz de firewall OUTSIDE (fc00:1:1:2::2), pero en su lugar, solicita la fc00:1:1:1::100. Esto es una indicación de un error de configuración.

Acciones recomendadas

Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.

Acción 1. Compruebe la tabla de vecinos IPv6.

La tabla de vecinos IPv6 del firewall se ha rellenado correctamente.

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

Acción 2. Compruebe la configuración de IPv6.

Esta es la configuración del 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

La configuración del dispositivo ascendente revela el error de configuración:

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 - Escenario funcional

El cambio de máscara de subred (de /48 a /64) solucionó el problema. Esta es la captura CAPI en el escenario funcional.

Punto clave:

1. El router envía un mensaje de solicitud de vecino IPv6 que solicita la dirección MAC del dispositivo ascendente (IP fc00:1:1:1::1).

2. El firewall responde con un anuncio de vecino IPv6.

3. El router envía solicitudes de eco ICMP y obtiene respuestas de eco.

Contenido de CAPO:

Puntos clave:

1. El firewall envía un mensaje de solicitud de vecino IPv6 que solicita la dirección MAC del dispositivo ascendente (IP fc00:1:1:2::2).

2. El firewall responde con un anuncio de vecino IPv6.

3. El firewall envía una solicitud de eco ICMP.

4. El router envía un mensaje de solicitud de vecino IPv6 que solicita la dirección MAC del dispositivo de flujo descendente (IP fc00:1:1:1::1).

5. El firewall responde con un anuncio de vecino IPv6.

6. El firewall envía solicitudes de eco ICMP y obtiene respuestas de eco.

Caso 12. Problema de conectividad intermitente (envenenamiento ARP)

Descripción del problema: los hosts internos (192.168.0.x/24) tienen problemas de conectividad intermitentes con los hosts de la misma subred

Esta imagen muestra la topología:

Flujo afectado:

IP de origen: 192.168.0.x/24

Dst IP: 192.168.0.x/24

Protocolo: cualquiera

La memoria caché ARP de un host interno parece estar contaminada:

Análisis de captura

Habilitar una captura en el motor FTD LINA

Esta captura solo captura paquetes ARP en la interfaz INSIDE:

firepower# capture CAPI_ARP interface INSIDE ethernet-type arp

Capturas - Escenario no funcional:

La captura en la interfaz interna del firewall contiene.

Puntos clave:

1. El firewall recibe varias solicitudes ARP para IP dentro de la red 192.168.0.x/24

2. El firewall responde a todos ellos (proxy-ARP) con su propia dirección MAC

Acciones recomendadas

Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.

Acción 1. Verifique la configuración de NAT.

Con respecto a la configuración de NAT, hay casos en los que la palabra clave no-proxy-arp puede evitar el comportamiento 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

Acción 2. Inhabilite la funcionalidad proxy-arp en la interfaz de firewall.

Si la palabra clave ‘no-proxy-arp’ no resuelve el problema, intente inhabilitar el ARP proxy en la interfaz misma. En el caso de FTD, en el momento de escribir este documento, debe utilizar FlexConfig e implementar el comando (especifique el nombre de interfaz adecuado).

sysopt noproxyarp INSIDE

Caso 13. Identificar identificadores de objeto SNMP (OID) que provocan bloqueos de CPU

Este caso demuestra cómo ciertos OID de SNMP para el sondeo de memoria fueron identificados como la causa raíz de acaparamiento de CPU (problema de rendimiento) basado en el análisis de capturas de paquetes de SNMP versión 3 (SNMPv3).

Descripción del problema: Los desbordamientos en las interfaces de datos aumentan continuamente. Investigaciones posteriores revelaron que también hay acaparamientos de CPU (causados por el proceso SNMP) que son la causa raíz de los desbordamientos de la interfaz.

El siguiente paso en el proceso de solución de problemas fue identificar la causa raíz de los acaparamientos de CPU causados por el proceso SNMP y, en particular, reducir el alcance del problema para identificar los identificadores de objeto SNMP (OID) que, cuando se sondea, podrían potencialmente dar lugar a acaparamientos de CPU.

Actualmente, el motor FTD LINA no proporciona un comando 'show' para los OID SNMP que se sondean en tiempo real.

La lista de OIDs SNMP para sondeo se puede recuperar desde la herramienta de monitoreo SNMP, sin embargo, en este caso, hubo estos factores preventivos:

- El administrador de FTD no tenía acceso a la herramienta de supervisión SNMP

- SNMP versión 3 con autenticación y cifrado de datos para la privacidad se configuró en FTD

Análisis de captura

Dado que el administrador de FTD tenía las credenciales para la autenticación SNMP versión 3 y el cifrado de datos, se propuso este plan de acción:

1. Captura de paquetes SNMP

2. Guarde las capturas y utilice las preferencias del protocolo SNMP de Wireshark para especificar las credenciales de SNMP versión 3 para descifrar los paquetes de SNMP versión 3. Las capturas descifradas se utilizan para el análisis y la recuperación de OID de SNMP

Configure las capturas de paquetes SNMP en la interfaz que se utiliza en la configuración de host del 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

Puntos clave:

1. Direcciones/puertos de origen y destino SNMP.

2. No se pudo descodificar la PDU del protocolo SNMP porque Wireshark desconoce privKey.

3. El valor de la primitiva de la PDU cifrada.

Acciones recomendadas

Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.

Acción 1. Descifre las capturas SNMP.

Guarde las capturas y edite las preferencias del protocolo SNMP de Wireshark para especificar las credenciales de SNMP versión 3 para descifrar los paquetes.

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 el archivo de captura en Wireshark, seleccione un paquete SNMP y navegue hasta Protocol Preferences > Users Table, como se muestra en la imagen:

En la tabla de usuarios SNMP se especificaron el nombre de usuario, el modelo de autenticación, la contraseña de autenticación, el protocolo de privacidad y la contraseña de privacidad de la versión 3 de SNMP (las credenciales reales no se muestran a continuación):

Una vez que se aplicó la configuración de usuarios SNMP, Wireshark mostró PDU de SNMP descifradas:

Puntos clave:

1. Las herramientas de monitoreo SNMP usaron SNMP getBulkRequest para consultar y recorrer el OID primario 1.3.6.1.4.1.9.9.221.1 y los OID relacionados.

2. El FTD respondió a cada getBulkRequest con get-response que contiene OID relacionados con 1.3.6.1.4.1.9.9.221.1.

Acción 2. Identifique los OID de SNMP.

SNMP Object Navigator mostró que OID 1.3.6.1.4.1.9.9.221.1 pertenece a la base de información de administración (MIB) denominada CISCO-ENHANCED-MEMPOOL-MIB, como se muestra en la imagen:

Para mostrar los OID en formato legible para humanos en Wireshark:

1. Descargue MIB CISCO-ENHANCED-MEMPOOL-MIB y sus dependencias, como se muestra en la imagen:

2. En Wireshark en Edit > Preferences > Name Resolution ventana, la opción Enable OID Resolution está marcada. En la ventana SMI (MIB and PIB paths) especifique la carpeta con los MIB descargados y en SMI (MIB and PIB modules). CISCO-ENHANCED-MEMPOOL-MIB se agrega automáticamente a la lista de módulos:

3. Una vez que se reinicia Wireshark, se activa la resolución OID:

Basándose en la salida descifrada del archivo de captura, la herramienta de supervisión SNMP consultaba periódicamente (con un intervalo de 10 segundos) los datos sobre la utilización de los grupos de memoria en el FTD. Como se explicó en el artículo de TechNote ASA SNMP Polling for Memory-Related Statistics , el sondeo de la utilización de Global Shared Pool (GSP) con SNMP da como resultado un uso elevado de la CPU. En este caso de las capturas, estaba claro que la utilización del conjunto compartido global se sondeaba periódicamente como parte de la primitiva getBulkRequest de SNMP.

Para minimizar los acaparamientos de CPU causados por el proceso SNMP, se recomendó seguir los pasos de mitigación para los acaparadores de CPU para SNMP mencionados en el artículo y evitar sondear los OID relacionados con GSP. Sin el sondeo SNMP para los OIDs que se relacionan con el GSP, no se observaron acaparamientos de CPU causados por el proceso SNMP y la tasa de desbordamientos disminuyó significativamente.

Información Relacionada

- Guías de configuración de Cisco Firepower Management Center

- Aclaración de acciones de reglas de políticas de control de acceso de defensa contra amenazas de Firepower

- Trabaje con capturas de Firepower Threat Defence y Packet Tracer

- Aprender Wireshark