Analizar capturas de firewalls de Firepower para solucionar problemas de red
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 el registro y los rastreadores) 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.
- Un paquete ingresa a la interfaz de ingreso y es manejado por el switch interno del chasis.
- El paquete entra en el motor de línea FTD que realiza principalmente comprobaciones L3/L4.
- Si la política requiere que el paquete sea inspeccionado por el motor Snort (principalmente inspección L7).
- El motor Snort devuelve un veredicto para el paquete.
- El motor LINA descarta o reenvía el paquete en función del veredicto de Snort.
- 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:
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).
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:
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:
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:
- Protocolo de protocolo de enlace TCP de 3 vías.
- Intercambio de datos bidireccional.
- Sin retrasos entre los paquetes (según la diferencia de tiempo entre los paquetes).
- 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:
- Mismos datos que en la captura CAPI.
- 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:
- Sólo se ven los paquetes TCP SYN (sin protocolo de enlace TCP de 3 vías).
- 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.
- Las retransmisiones de TCP ocurren cada ~3 y luego cada 6 segundos, etc.
- 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:
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
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:
- Búsqueda de conexión establecida
- 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.
- Routing basado en políticas (PBR)
- 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í:
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
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. |
|
| El filtro de captura es incorrecto. |
|
| El paquete se envía a una interfaz de salida diferente. |
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. |
|
| No hay ninguna entrada ARP en la interfaz de salida. |
|
| 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:
Así es como se ven las capturas desde la CLI del dispositivo:
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:
- El origen envía un paquete TCP SYN.
- Se envía un TCP RST hacia el origen.
- El origen retransmite los paquetes TCP SYN.
- 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:
- El origen envía un paquete TCP SYN.
- Llega un TCP RST a la interfaz OUTSIDE.
- El origen retransmite los paquetes TCP SYN.
- 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:
- 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.
- La longitud de los paquetes difiere especialmente si hay un encabezado dot1Q agregado/eliminado por el firewall en un solo lado.
- Las direcciones MAC son diferentes.
- Un encabezado dot1Q puede estar en su lugar si la captura fue tomada en una subinterfaz.
- Las direcciones IP son diferentes en caso de que se aplique NAT o traducción de direcciones de puerto (PAT) al paquete.
- Los puertos de origen o de destino son diferentes en caso de que se aplique NAT o PAT al paquete.
- 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).
- 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:
- El protocolo de enlace de 3 vías TCP pasa a través del firewall.
- El servidor retransmite el SYN/ACK.
- El cliente retransmite el ACK.
- 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:
- El protocolo de enlace de 3 vías TCP pasa a través del firewall.
- Después de unos 5 segundos, el cliente envía un mensaje FIN/ACK.
- 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:
- El protocolo de enlace de 3 vías TCP pasa a través del firewall.
- 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:
- El protocolo de enlace de 3 vías TCP pasa a través del firewall.
- 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:
- El cliente envía un paquete TCP SYN.
- El cliente envía un paquete RST TCP.
- 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:
- El cliente envía un paquete TCP SYN. El firewall aleatoriza el ISN.
- 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:
- 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)
- 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
- 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
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:
- Hay paquetes TCP Out-Of-Order (OOO).
- Hay una retransmisión TCP.
- Hay una indicación de pérdida de paquetes (paquetes perdidos).
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:
- La pérdida de paquetes es causada por el propio firewall.
- La pérdida de paquetes se produce después del dispositivo de firewall (dirección del servidor al cliente).
- 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:
- Compare las marcas de tiempo del primer paquete de cada captura.
- 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:
- 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.
- 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:
- Las 2 capturas son casi idénticas (considere la aleatorización ISN).
- No hay indicios de pérdida de paquetes.
- Sin paquetes fuera de servicio (OOO)
- 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:
- Existe un protocolo de enlace TCP de 3 vías.
- Hay retransmisiones TCP e indicaciones de pérdida de paquetes.
- 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):
- Existe un protocolo de enlace TCP de 3 vías.
- Hay retransmisiones TCP e indicaciones de pérdida de paquetes.
- Wireshark identifica un paquete (TCP ACK) como Malformado.
Verifique el paquete mal formado:
Puntos clave:
- Wireshark identifica el paquete como Malformado.
- Tiene una longitud de 2 bytes.
- Hay una carga útil TCP de 2 bytes.
- 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:
- Las interfaces de entrada y salida son las mismas (giro en U).
- El número de bytes tiene un valor significativamente grande (~5 GBytes).
- 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:
Antes:
Después de:
Puntos clave:
- Se aplica un filtro de visualización para quitar duplicados de paquetes y mostrar sólo los registros del sistema.
- La diferencia entre los paquetes está en el nivel de microsegundos. Esto indica una velocidad de paquetes muy alta.
- 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:
- La ruta apunta hacia la interfaz de salida correcta.
- 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:
- 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:
- Búsqueda de conexión establecida (esto tiene prioridad sobre la búsqueda de tabla de ruteo global).
- 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.
- Routing basado en políticas (PBR)
- 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:
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:
- Existe un protocolo de enlace TCP de 3 vías.
- Se inicia la negociación SSL. El cliente envía un mensaje de saludo de cliente.
- Se ha enviado un ACK TCP al cliente.
- Hay un TCP RST enviado al cliente.
Esta imagen muestra la captura realizada en la interfaz EXTERNA de NGFW.
Puntos clave:
- Existe un protocolo de enlace TCP de 3 vías.
- Se inicia la negociación SSL. El cliente envía un mensaje de saludo de cliente.
- Hay retransmisiones TCP enviadas desde el firewall hacia el servidor.
- 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:
- 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.
- 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).
- El firewall se encuentra en el modo de proxy TCP y envía un ACK al cliente (que suplanta el servidor).
- 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.
- Después de ~30 segundos, el firewall se da por vencido y envía un TCP RST hacia el cliente.
- 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:
Siga uno de los flujos TCP (Follow > TCP Stream), como se muestra en la imagen.
Puntos clave:
- Existe un protocolo de enlace TCP de 3 vías.
- El cliente (FMC) envía un mensaje de saludo del cliente SSL al portal de Smart Licensing.
- El ID de sesión SSL es 0. Esto significa que no se ha reanudado el período de sesiones.
- El servidor de destino responde con los mensajes Hello de servidor, Certificate y Hello Done de servidor.
- El cliente envía una alerta de error SSL que se refiere a una "CA desconocida".
- El cliente envía un TCP RST para cerrar la sesión.
- 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:
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:
- 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).
- El firewall responde con un anuncio de vecino IPv6.
- El router envía una solicitud de eco ICMP.
- 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).
- El router responde con un anuncio de vecino IPv6.
- El router envía solicitudes de eco ICMP IPv6 adicionales.
La captura en la interfaz EXTERNA del firewall contiene:
Puntos clave:
- 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).
- El router responde con un anuncio de vecino IPv6.
- El firewall envía una solicitud de eco ICMP IPv6.
- 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.
- El firewall envía una solicitud de eco ICMP IPv6 adicional.
- 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:
- 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).
- El firewall responde con un anuncio de vecino IPv6.
- El router envía solicitudes de eco ICMP y obtiene respuestas de eco.
Contenido de CAPO:
Puntos clave:
- 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).
- El firewall responde con un anuncio de vecino IPv6.
- El firewall envía una solicitud de eco ICMP.
- 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).
- El firewall responde con un anuncio de vecino IPv6.
- 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:
- El firewall recibe varias solicitudes ARP para IP dentro de la red 192.168.0.x/24
- 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:
- Captura de paquetes SNMP
- 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:
- Direcciones/puertos de origen y destino SNMP.
- No se pudo descodificar la PDU del protocolo SNMP porque Wireshark desconoce privKey.
- 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:
- 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.
- 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:
- 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
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
3.0 |
31-Jul-2024 |
Recertificación, Texto alternativo, encabezados fijos, puntuación y optimización de SEO HTML. |
2.0 |
02-Jun-2023 |
Recertificación |
1.0 |
21-Nov-2019 |
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)