Analyser les captures du pare-feu Firepower pour résoudre les problèmes réseau
Table des matières
Introduction
Ce document décrit diverses techniques d’analyse de capture de paquets qui visent à dépanner efficacement les problèmes de réseau.
Conditions préalables
Exigences
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Architecture de plate-forme Firepower
- Journaux NGFW
- traceur de paquets de pare-feu de nouvelle génération
En outre, avant de commencer à analyser les captures de paquets, il est vivement conseillé de respecter les exigences suivantes :
- Connaître le fonctionnement du protocole - Ne commencez pas à vérifier une capture de paquets si vous ne comprenez pas le fonctionnement du protocole capturé.
- Connaître la topologie - Vous devez connaître les périphériques de transit de bout en bout. Si cela n'est pas possible, vous devez au moins connaître les périphériques en amont et en aval.
- Connaître l'appliance : vous devez savoir comment votre périphérique gère les paquets, quelles sont les interfaces impliquées (entrée/sortie), quelle est l'architecture du périphérique et quels sont les différents points de capture.
- Connaître la configuration - Vous devez savoir comment un flux de paquets est censé être géré par le périphérique en termes de :
- Interface de routage/sortie
- Stratégies appliquées
- Traduction d'adresses réseau (NAT)
- Connaître les outils disponibles - En plus des captures, il est recommandé d'être prêt à appliquer d'autres outils et techniques (comme la journalisation et les traceurs) et, si nécessaire, de les corréler avec les paquets capturés.
Composants utilisés
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
- La plupart des scénarios sont basés sur FP4140 exécutant le logiciel FTD 6.5.x.
- FMC exécutant le logiciel 6.5.x.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Informations générales
La capture de paquets est l’un des outils de dépannage les plus négligés actuellement disponibles. Le TAC Cisco résout quotidiennement de nombreux problèmes liés à l'analyse des données capturées.
L'objectif de ce document est d'aider les ingénieurs réseau et de sécurité à identifier et à dépanner les problèmes réseau courants, principalement en se basant sur l'analyse de capture de paquets.
Tous les scénarios présentés dans ce document sont basés sur des cas réels d'utilisateurs observés dans le centre d'assistance technique de Cisco (TAC).
Le document couvre les captures de paquets du point de vue du pare-feu de nouvelle génération Cisco (NGFW), mais les mêmes concepts s'appliquent également à d'autres types de périphériques.
Comment collecter et exporter des captures sur la gamme de produits NGFW ?
Dans le cas d'un appareil Firepower (1xxx, 21xx, 41xx, 93xx) et d'une application Firepower Threat Defense (FTD), un traitement de paquets peut être visualisé comme illustré dans l'image.
- Un paquet entre dans l'interface d'entrée et est géré par le commutateur interne du châssis.
- Le paquet entre dans le moteur Lina FTD qui effectue principalement des vérifications L3/L4.
- Si la politique exige que le paquet soit inspecté par le moteur Snort (principalement inspection L7).
- Le moteur Snort renvoie un verdict pour le paquet.
- Le moteur LINA abandonne ou transfère le paquet en fonction du verdict du renifleur.
- Le paquet sort du châssis par le commutateur interne du châssis.
Sur la base de l'architecture illustrée, les captures FTD peuvent être effectuées à trois (3) endroits différents :
- FXOS
- moteur FTD Lina
- Moteur FTD Snort
Collecter les captures FXOS
Le processus est décrit dans ce document :
Les captures FXOS ne peuvent être prises que dans la direction d'entrée à partir du point de vue du commutateur interne sont montrées dans l'image ici.
Dans le cas présent, il s'agit de deux points de capture par direction (en raison de l'architecture interne du commutateur).
Les paquets capturés aux points 2, 3 et 4 ont une étiquette de réseau virtuel (VNTag).
Activer et collecter les captures Lina FTD
Principaux points de capture :
- Interface d'entrée
- Interface de sortie
- Chemin de sécurité accéléré (ASP)
Vous pouvez utiliser l'interface utilisateur FMC (Firepower Management Center User Interface) ou l'interface de ligne de commande FTD pour activer et collecter les captures FTD Lina.
Activez la capture à partir de l'interface CLI sur l'interface INSIDE :
firepower# capture CAPI interface INSIDE match icmp host 192.168.103.1 host 192.168.101.1
Cette capture correspond au trafic entre les adresses IP 192.168.103.1 et 192.168.101.1 dans les deux directions.
Activez la capture ASP pour voir tous les paquets abandonnés par le moteur FTD Lina :
firepower# capture ASP type asp-drop all
Exporter une capture FTD Lina vers un serveur FTP :
firepower# copy /pcap capture:CAPI ftp://ftp_username:ftp_password@192.168.78.73/CAPI.pcap
Exportez une capture FTD Lina vers un serveur TFTP :
firepower# copy /pcap capture:CAPI tftp://192.168.78.73
À partir de la version FMC 6.2.x, vous pouvez activer et collecter les captures FTD Lina à partir de l'interface utilisateur FMC.
Voici une autre façon de collecter des captures FTD à partir d'un pare-feu géré par FMC.
Étape 1
Dans le cas d'une capture LINA ou ASP, copiez la capture sur le disque FTD.
firepower# copy /pcap capture:capin disk0:capin.pcap Source capture name [capin]? Destination filename [capin.pcap]? !!!!
Étape 2
Accédez au mode expert, localisez la capture enregistrée et copiez-la dans /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
Étape 3
Connectez-vous au FMC qui gère le FTD et accédez à Périphériques > Gestion des périphériques. Localisez le périphérique FTD et sélectionnez l'icône Troubleshoot :
Étape 4
Sélectionnez Dépannage avancé :
Spécifiez le nom du fichier de capture et sélectionnez Télécharger :
Pour plus d'exemples sur la façon d'activer/collecter des captures à partir de l'interface utilisateur FMC, consultez ce document :
Activer et collecter les captures FTD Snort
Le point de capture est illustré dans l'image ci-contre.
Activer la capture de niveau 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
Pour écrire la capture dans un fichier nommé capture.pcap et la copier via FTP sur un serveur distant :
> 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. >
Pour plus d'exemples de capture de niveau Snort qui incluent différents filtres de capture, consultez ce document :
Dépannage
Cas 1 . Pas de SYN TCP sur l'interface de sortie
La topologie est illustrée dans l'image ci-dessous :
Description du problème : HTTP ne fonctionne pas
Flux affecté :
Adresse IP source : 192.168.0.100
Adresse IP de destination : 10.10.1.100
Protocole : TCP 80
Analyse de capture
Activez les captures sur le moteur FTD LINA :
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
Captures - Scénario fonctionnel :
En tant que base, il est toujours très utile de disposer de captures à partir d'un scénario fonctionnel.
Capture prise sur l'interface INSIDE du pare-feu de nouvelle génération, comme illustré dans l'image :
Principaux points :
- Connexion TCP en trois étapes.
- Échange de données bidirectionnel.
- Aucun délai entre les paquets (en fonction de la différence de temps entre les paquets).
- L'adresse MAC source est le périphérique en aval correct.
Capture prise sur l'interface NGFW OUTSIDE, est montré dans l'image ici :
Principaux points :
- Mêmes données que dans la capture CAPI.
- L'adresse MAC de destination est le périphérique en amont correct.
Captures - Scénario non fonctionnel
À partir de l'interface de ligne de commande du périphérique, les captures ressemblent à ceci :
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
Contenu 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
Voici l'image de la capture CAPI dans Wireshark :
Principaux points :
- Seuls les paquets TCP SYN sont visibles (pas de connexion TCP en trois étapes).
- Il est impossible d’établir 2 sessions TCP (ports source 3171 et 3172). Le client source renvoie les paquets TCP SYN. Ces paquets retransmis sont identifiés par Wireshark comme des retransmissions TCP.
- Les retransmissions TCP ont lieu toutes les ~3 puis 6 secondes, etc.
- L'adresse MAC source provient du périphérique en aval correct.
Sur la base des deux captures, on peut conclure que :
- Un paquet d'un 5-tuple spécifique (IP src/dst, port src/dst, protocole) arrive sur le pare-feu sur l'interface attendue (INSIDE).
- Un paquet ne quitte pas le pare-feu sur l'interface attendue (OUTSIDE).
Actions recommandées
Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.
Action 1. Vérifiez la trace d'un paquet émulé.
Utilisez l'outil packet-tracer pour voir comment un paquet est censé être traité par le pare-feu. Si le paquet est abandonné par la politique d'accès du pare-feu, la trace du paquet émulé ressemble à ce résultat :
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
Action 2. Vérifiez les traces des paquets actifs.
Activez le suivi des paquets pour vérifier comment les paquets TCP SYN réels sont traités par le pare-feu. Par défaut, seuls les 50 premiers paquets entrants sont suivis :
firepower# capture CAPI trace
Effacez la mémoire tampon de capture :
firepower# clear capture /all
Si le paquet est abandonné par la politique d'accès du pare-feu, la trace ressemble à ce résultat :
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
Action 3. Vérifiez les journaux FTD Lina.
Pour configurer Syslog sur FTD via FMC, consultez ce document :
Il est fortement recommandé de configurer un serveur Syslog externe pour les journaux FTD Lina. Si aucun serveur Syslog distant n'est configuré, activez les journaux de mémoire tampon locale sur le pare-feu pendant le dépannage. La configuration du journal présentée dans cet exemple est un bon point de départ :
firepower# show run logging … logging enable logging timestamp logging buffer-size 1000000 logging buffered informational
Réglez le pager terminal sur 24 lignes afin de contrôler le pager terminal :
firepower# terminal pager 24
Effacez la mémoire tampon de capture :
firepower# clear logging buffer
Testez la connexion et vérifiez les journaux avec un filtre d'analyse. Dans cet exemple, les paquets sont abandonnés par la politique d'accès du pare-feu :
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]
Mesure 4. Vérifiez que le pare-feu ASP abandonne.
Si vous suspectez que le paquet est abandonné par le pare-feu, vous pouvez voir les compteurs de tous les paquets abandonnés par le pare-feu au niveau logiciel :
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
Vous pouvez activer les captures pour afficher toutes les pertes de niveau logiciel ASP :
firepower# capture ASP type asp-drop all buffer 33554432 headers-only
Pour vérifier le contenu de la capture, vous pouvez utiliser un filtre pour affiner votre recherche :
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>
Dans ce cas, puisque les paquets sont déjà tracés au niveau de l'interface, la raison de l'abandon n'est pas mentionnée dans la capture ASP. N’oubliez pas qu’un paquet ne peut être suivi qu’à un seul endroit (interface d’entrée ou abandon ASP). Dans ce cas, il est recommandé de prendre plusieurs abandons ASP et de définir une raison d'abandon ASP spécifique. Voici une approche recommandée :
1. Effacez les compteurs d'abandon ASP actuels :
firepower# clear asp drop
2. Envoyez le flux que vous dépannez via le pare-feu (exécutez un test).
3. Vérifiez à nouveau les compteurs de dépôt ASP et notez ceux qui ont augmenté.
firepower# show asp drop Frame drop: No route to host (no-route) 234 Flow is denied by configured rule (acl-drop) 71
4. Activez la ou les captures ASP pour les abandons spécifiques affichés :
firepower# capture ASP_NO_ROUTE type asp-drop no-route firepower# capture ASP_ACL_DROP type asp-drop acl-drop
5. Envoyez le flux que vous dépannez via le pare-feu (exécutez un test).
6. Vérifiez les captures ASP. Dans ce cas, les paquets ont été abandonnés en raison d'une route absente :
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>
Action 5. Vérifiez la table de connexion FTD Lina.
Il peut y avoir des cas où vous vous attendez à ce que le paquet sorte de l'interface 'X', mais pour quelque raison que ce soit, il sort de l'interface 'Y'. La détermination de l'interface de sortie du pare-feu est basée sur cet ordre de fonctionnement :
- Recherche de connexion établie
- Recherche NAT (Network Address Translation) : la phase UN-NAT (destination NAT) est prioritaire sur la recherche PBR et la recherche de route.
- Routage basé sur des politiques (PBR)
- Recherche dans la table de routage
Pour vérifier la table de connexion 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
Principaux points :
- Selon les indicateurs (Aa), la connexion est embryonnaire (semi-ouverte - seul TCP SYN a été vu par le pare-feu).
- En fonction des ports source/de destination, l'interface d'entrée est INSIDE et l'interface de sortie est DMZ.
Ceci peut être visualisé dans l'image ici :
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
Résultat 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
Résultat 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
En outre, la commande show conn long affiche les IP NATed entre parenthèses dans le cas d'une traduction d'adresses réseau :
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
Mesure no 6. Vérifiez le cache ARP (Address Resolution Protocol) du pare-feu.
Si le pare-feu ne peut pas résoudre le saut suivant, il abandonne silencieusement le paquet d'origine (TCP SYN dans ce cas) et envoie continuellement des requêtes ARP jusqu'à ce qu'il résolve le saut suivant.
Afin de voir le cache ARP du pare-feu, utilisez la commande :
firepower# show arp
En outre, pour vérifier s’il existe des hôtes non résolus, vous pouvez utiliser la commande suivante :
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 vous souhaitez vérifier davantage l'opération ARP, vous pouvez activer une capture spécifique à 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
Dans ce résultat, le pare-feu (192.168.2.50) tente de résoudre le tronçon suivant (192.168.2.72), mais il n'y a pas de réponse ARP
Le résultat ci-dessous montre un scénario fonctionnel avec une résolution ARP appropriée :
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
Si aucune entrée ARP n'est en place, la trace d'un paquet SYN TCP actif indique :
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
Comme vous pouvez le voir dans le résultat, la trace montre Action : allow même lorsque le saut suivant n'est pas accessible et que le paquet est silencieusement abandonné par le pare-feu ! Dans ce cas, l'outil Packet Tracer doit également être vérifié car il fournit une sortie plus précise :
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
Dans les versions récentes d'ASA/Firepower, le message précédent a été optimisé pour :
Drop-reason: (no-v4-adjacency) No valid V4 adjacency. Check ARP table (show arp) has entry for nexthop., Drop-location: f
Synthèse des causes possibles et des actions recommandées
Si vous ne voyez qu'un paquet TCP SYN sur les interfaces d'entrée, mais qu'aucun paquet TCP SYN n'est envoyé à partir de l'interface de sortie attendue, certaines causes possibles sont :
| Cause possible |
Actions recommandées |
| Le paquet est abandonné par la politique d'accès du pare-feu. |
|
| Le filtre de capture est incorrect. |
|
| Le paquet est envoyé à une autre interface de sortie. |
Si le paquet est envoyé à une interface incorrecte parce qu'il correspond à une connexion actuelle, utilisez la commande clear conn address et spécifiez le 5-tuple de la connexion que vous voulez effacer. |
| Il n'y a pas de route vers la destination. |
|
| Il n'y a aucune entrée ARP sur l'interface de sortie. |
|
| L'interface de sortie est désactivée. |
Vérifiez le résultat de la commande show interface ip brief sur le pare-feu et vérifiez l'état de l'interface. |
Cas 2 . TCP SYN du client, TCP RST du serveur
Cette image présente la topologie :
Description du problème : HTTP ne fonctionne pas
Flux affecté :
Adresse IP source : 192.168.0.100
Adresse IP de destination : 10.10.1.100
Protocole : TCP 80
Analyse de capture
Activez les captures sur le moteur FTD LINA.
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
Captures - Scénario non fonctionnel :
Voici à quoi ressemblent les captures à partir de l'interface de ligne de commande du périphérique :
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
Contenu 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> ...
Contenu 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>
Cette image montre la capture de CAPI dans Wireshark.
Principaux points :
- La source envoie un paquet TCP SYN.
- Un RST TCP est envoyé vers la source.
- La source retransmet les paquets TCP SYN.
- Les adresses MAC sont correctes (sur les paquets entrants, l'adresse MAC source appartient au routeur en aval, l'adresse MAC de destination appartient à l'interface INSIDE du pare-feu).
Cette image montre la capture de CAPO dans Wireshark :
Principaux points :
- La source envoie un paquet TCP SYN.
- Un RST TCP arrive sur l'interface OUTSIDE.
- La source retransmet les paquets TCP SYN.
- Les adresses MAC sont correctes (sur les paquets de sortie, le pare-feu OUTSIDE est l'adresse MAC source, le routeur en amont est l'adresse MAC de destination).
Sur la base des deux captures, on peut conclure que :
- La connexion TCP en trois étapes entre le client et le serveur n'est pas terminée
- Il y a un TCP RST qui arrive sur l'interface de sortie du pare-feu
- Le pare-feu « communique » avec les périphériques en amont et en aval appropriés (en fonction des adresses MAC)
Actions recommandées
Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.
Action 1. Vérifiez l'adresse MAC source qui envoie la RST TCP.
Vérifiez que l'adresse MAC de destination vue dans le paquet TCP SYN est identique à l'adresse MAC source vue dans le paquet TCP RST.
Cette vérification a pour but de confirmer 2 choses :
- Vérifiez qu'il n'y a pas de flux asymétrique.
- Vérifiez que l'adresse MAC appartient au périphérique en amont attendu.
Action 2. Comparer les paquets entrants et sortants.
Comparez visuellement les 2 paquets sur Wireshark pour vérifier que le pare-feu ne modifie pas/ne corrompt pas les paquets. Certaines différences attendues sont mises en évidence.
Principaux points :
- Les horodatages sont différents. D'un autre côté, la différence doit être faible et raisonnable. Cela dépend des fonctions et des contrôles de stratégie appliqués au paquet ainsi que de la charge sur le périphérique.
- La longueur des paquets diffère en particulier si un en-tête dot1Q est ajouté/supprimé par le pare-feu sur un seul côté.
- Les adresses MAC sont différentes.
- Un en-tête dot1Q peut être en place si la capture a été effectuée sur une sous-interface.
- Les adresses IP sont différentes si la traduction d'adresses de port (PAT) ou la traduction d'adresses de port (NAT) est appliquée au paquet.
- Les ports source ou de destination sont différents si la fonction NAT ou PAT est appliquée au paquet.
- Si vous désactivez l'option Wireshark Relative Sequence Number, vous voyez que les numéros de séquence TCP/les numéros d'accusé de réception sont modifiés par le pare-feu en raison de la randomisation ISN (Initial Sequence Number).
- Certaines options TCP peuvent être remplacées. Par exemple, le pare-feu modifie par défaut la taille maximale de segment (MSS) TCP sur 1380 afin d'éviter la fragmentation des paquets dans le chemin de transit.
Action 3. Effectuez une capture à destination.
Si possible, effectuez une capture à la destination elle-même. Si ce n'est pas possible, effectuez une capture aussi près que possible de la destination. L’objectif ici est de vérifier qui envoie la RST TCP (le serveur de destination ou un autre périphérique se trouve-t-il sur le chemin ?).
Cas 3 . Connexion TCP en trois étapes + RST à partir d'un terminal
Cette image présente la topologie :
Description du problème : HTTP ne fonctionne pas
Flux affecté :
Adresse IP source : 192.168.0.100
Adresse IP de destination : 10.10.1.100
Protocole : TCP 80
Analyse de capture
Activez les captures sur le moteur FTD LINA.
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
Captures - Scénario non fonctionnel :
Ce problème peut se manifester de deux façons différentes dans les captures.
3.1 - Connexion TCP en trois étapes + RST différé du client
Les captures CAPI et CAPO du pare-feu contiennent les mêmes paquets, comme illustré dans l'image.
Principaux points :
- La connexion TCP en trois étapes passe par le pare-feu.
- Le serveur retransmet le message SYN/ACK.
- Le client retransmet l'accusé de réception.
- Après environ 20 secondes, le client abandonne et envoie un RST TCP.
Actions recommandées
Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.
Action 1. Effectuez des captures aussi près que possible des deux terminaux.
Les captures du pare-feu indiquent que le serveur n'a pas traité l'ACK du client. Ceci est basé sur les faits suivants :
- Le serveur retransmet le message SYN/ACK.
- Le client retransmet l'accusé de réception.
- Le client envoie un RST TCP ou un FIN/ACK avant toute donnée.
La capture sur le serveur montre le problème. Le client ACK de la connexion TCP en trois étapes n'est jamais arrivé :
3.2 - Connexion TCP en trois étapes + FIN/ACK retardé du client + RST retardé du serveur
Les captures CAPI et CAPO du pare-feu contiennent les mêmes paquets, comme illustré dans l'image.
Principaux points :
- La connexion TCP en trois étapes passe par le pare-feu.
- Après ~5 secondes, le client envoie un FIN/ACK.
- Après ~20 secondes, le serveur abandonne et envoie un RST TCP.
Sur la base de cette capture, on peut conclure que bien qu'il y ait une connexion TCP en trois étapes à travers le pare-feu, il semble qu'elle ne soit jamais réellement terminée sur un point d'extrémité (les retransmissions l'indiquent).
Actions recommandées
Identique au cas 3.1
3.3 - Connexion TCP en trois étapes + RST différé du client
Les captures CAPI et CAPO du pare-feu contiennent les mêmes paquets, comme illustré dans l'image.
Principaux points :
- La connexion TCP en trois étapes passe par le pare-feu.
- Après environ 20 secondes, le client abandonne et envoie un RST TCP.
Sur la base de ces captures, on peut conclure que :
- Après 5 à 20 secondes, un terminal abandonne et décide de mettre fin à la connexion.
Actions recommandées
Identique au cas 3.1
3.4 - Connexion TCP en trois étapes + RST immédiat à partir du serveur
Les captures CAPI et CAPO du pare-feu contiennent ces paquets, comme illustré dans l'image.
Principaux points :
- La connexion TCP en trois étapes passe par le pare-feu.
- Il y a un RST TCP du serveur quelques millisecondes après le paquet ACK.
Actions recommandées
Action : effectuez des captures aussi près que possible du serveur.
Un RST TCP immédiat provenant du serveur peut indiquer un serveur défaillant ou un périphérique sur le chemin qui envoie le RST TCP. Effectuez une capture sur le serveur lui-même et déterminez la source du RST TCP.
Cas 4 . TCP RST à partir du client
Cette image présente la topologie :
Description du problème : HTTP ne fonctionne pas.
Flux affecté :
Adresse IP source : 192.168.0.100
Adresse IP de destination : 10.10.1.100
Protocole : TCP 80
Analyse de capture
Activer les captures sur le moteur FTD LINA.
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
Captures - Scénario non fonctionnel :
Il s'agit du contenu 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
Voici le contenu du 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
Les journaux du pare-feu affichent :
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
Ces journaux indiquent qu'un TCP RST arrive sur l'interface INSIDE du pare-feu
Capture CAPI dans Wireshark :
Suivez le premier flux TCP, comme illustré dans l’image.
Sous Wireshark, accédez à Edit > Preferences > Protocols > TCP et désélectionnez l'option Relative sequence numbers comme indiqué dans l'image.
Cette image montre le contenu du premier flux dans la capture CAPI :
Principaux points :
- Le client envoie un paquet TCP SYN.
- Le client envoie un paquet TCP RST.
- Le paquet TCP SYN a une valeur de numéro d’ordre égale à 4098574664.
Le même flux de capture CAPO contient :
Principaux points :
- Le client envoie un paquet TCP SYN. Le pare-feu randomise l'ISN.
- Le client envoie un paquet TCP RST.
Sur la base des deux captures, on peut conclure que :
- Il n'y a pas de connexion TCP en trois étapes entre le client et le serveur.
- Il y a un TCP RST qui vient du client. La valeur du numéro de séquence TCP RST dans la capture CAPI est 1386249853.
Actions recommandées
Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.
Action 1. Effectuez une capture du client.
Sur la base des captures collectées sur le pare-feu, il existe une forte indication d'un flux asymétrique. Ceci est basé sur le fait que le client envoie un TCP RST avec une valeur de 1386249853 (le RNIS aléatoire) :
Principaux points :
- Le client envoie un paquet TCP SYN. Le numéro d'ordre est 4098574664 et est le même que celui vu sur l'interface INSIDE du pare-feu (CAPI)
- Il existe un TCP SYN/ACK avec ACK numéro 1386249853 (ce qui est attendu en raison de la randomisation ISN). Ce paquet n’a pas été vu dans les captures du pare-feu
- Le client envoie un RST TCP car il attendait un SYN/ACK avec une valeur de numéro ACK de 4098574665, mais il a reçu une valeur de 1386249853
Cela peut être visualisé comme suit :
Action 2. Vérifiez le routage entre le client et le pare-feu.
Confirmez que :
- Les adresses MAC visibles dans les captures sont les adresses attendues.
- Vérifiez que le routage entre le pare-feu et le client est symétrique.
Il existe des scénarios où la TVD provient d'un périphérique situé entre le pare-feu et le client alors qu'il existe un routage asymétrique dans le réseau interne. Un cas typique est montré dans l'image :
Dans ce cas, la capture a ce contenu. Notez la différence entre l'adresse MAC source du paquet TCP SYN et l'adresse MAC source du RST TCP et l'adresse MAC de destination du paquet 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)
...
Cas 5 . Transfert TCP lent (scénario 1)
Description du problème :
Le transfert SFTP entre les hôtes 10.11.4.171 et 10.77.19.11 est lent. Bien que la bande passante minimale entre les deux hôtes soit de 100 Mbits/s, la vitesse de transfert ne dépasse pas 5 Mbits/s.
Dans le même temps, la vitesse de transfert entre les hôtes 10.11.2.124 et 172.25.18.134 est nettement supérieure.
Théorie de fond :
La vitesse de transfert maximale pour un flux TCP unique est déterminée par le produit BDP (Bandwidth Delay Product). La formule utilisée est illustrée dans l'image :
Pour plus de détails sur le BDP, consultez les ressources ici :
- Pourquoi votre application utilise-t-elle uniquement 10 Mbit/s ? Même si la liaison est de 1 Gbit/s ?
- BRKSEC-3021 - Avancé - Optimisation des performances du pare-feu
Scénario 1. Transfert lent
Cette image présente la topologie :
Flux affecté :
IP source : 10.11.4.171
Adresse IP d'expédition : 10.77.19.11
Protocole : SFTP (FTP sur SSH)
Analyse de capture
Activer les captures sur le moteur FTD LINA :
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.
Actions recommandées
Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.
Calcul du temps de parcours aller-retour (RTT)
Tout d'abord, identifiez le flux de transfert et suivez-le :
Modifiez la vue Wireshark pour afficher les secondes écoulées depuis le paquet affiché précédent. Ceci facilite le calcul de la RTT :
Le RTT peut être calculé par addition des valeurs de temps entre 2 échanges de paquets (un vers la source et un vers la destination). Dans ce cas, le paquet #2 affiche le RTT entre le pare-feu et le périphérique qui a envoyé le paquet SYN/ACK (serveur). Le paquet #3 indique le délai entre le pare-feu et le périphérique qui a envoyé le paquet ACK (client). L'ajout des 2 numéros donne une bonne estimation de la valeur de bout en bout de la valeur de transfert de l'appel :
RTT ≈ 80 ms
Calcul de la taille de fenêtre TCP
Développez un paquet TCP, développez l'en-tête TCP, sélectionnez Calculated window size et sélectionnez Apply as Column :
Vérifiez la colonne Valeur de taille de fenêtre calculée pour voir quelle était la valeur de taille de fenêtre maximale pendant la session TCP. Vous pouvez également sélectionner le nom de la colonne et trier les valeurs.
Si vous testez un téléchargement de fichier (serveur > client), vous devez vérifier les valeurs annoncées par le serveur. La valeur de taille de fenêtre maximale annoncée par le serveur détermine la vitesse de transfert maximale atteinte.
Dans ce cas, la taille de la fenêtre TCP est de ≈ 50000 octets
Sur la base de ces valeurs et en utilisant la formule Bandwidth Delay Product, vous obtenez la bande passante théorique maximale qui peut être atteinte dans les conditions suivantes : 50000*8/0,08 = 5 Mbits/s de bande passante théorique maximale.
Cela correspond à ce que le client ressent dans ce cas.
Vérifiez de près la connexion TCP en trois étapes. Les deux côtés, et plus important encore le serveur, annoncent une valeur d'échelle de fenêtre de 0, ce qui signifie 2^0 = 1 (aucune échelle de fenêtre). Cela affecte négativement le taux de transfert :
À ce stade, il est nécessaire de prendre une capture sur le serveur, de confirmer que c'est celui qui annonce l'échelle de fenêtre = 0 et de la reconfigurer (consultez la documentation du serveur pour savoir comment faire).
Scénario 2. Transfert rapide
Examinons maintenant le bon scénario (transfert rapide via le même réseau) :
Topologie:
Le flux d'intérêt :
IP source : 10.11.2.124
Adresse IP de destination : 172.25.18.134
Protocole : SFTP (FTP sur SSH)
Activer les captures sur le moteur LINA FTD
firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134 firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134
Calcul du temps de parcours aller-retour (RTT) : dans ce cas, le RTT est ≈ 300 ms.
Calcul de la taille de fenêtre TCP : le serveur annonce un facteur d'échelle de fenêtre TCP de 7.
La taille de la fenêtre TCP du serveur est de ≈ 1600000 octets :
Sur la base de ces valeurs, la formule de produit Délai de bande passante donne :
1600000*8/0,3 = vitesse de transfert théorique maximale de 43 Mbits/s
Cas 6 . Transfert TCP lent (scénario 2)
Description du problème : le transfert de fichiers FTP (téléchargement) via le pare-feu est lent.
Cette image présente la topologie :
Flux affecté :
Adresse IP source : 192.168.2.220
Adresse IP d'expédition : 192.168.1.220
Protocole : FTP
Analyse de capture
Activez les captures sur le moteur FTD LINA.
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
Sélectionnez un paquet FTP-DATA et suivez le protocole FTP Data Channel sur la capture FTD INSIDE (CAPI) :
Le contenu du flux FTP-DATA :
Le contenu de capture CAPO :
Principaux points :
- Il existe des paquets TCP hors ordre (OOO).
- Il y a une retransmission TCP.
- Il y a une indication de perte de paquets (paquets abandonnés).
Actions recommandées
Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.
Action 1. Identifiez l'emplacement de perte de paquets.
Dans de tels cas, vous devez effectuer des captures simultanées et utiliser la méthode « diviser et conquérir » pour identifier le ou les segments de réseau à l’origine de la perte de paquets. Du point de vue du pare-feu, il existe 3 scénarios principaux :
- La perte de paquets est causée par le pare-feu lui-même.
- La perte de paquets est provoquée en aval vers le périphérique pare-feu (direction du serveur vers le client).
- La perte de paquets est provoquée en amont vers le périphérique pare-feu (direction du client vers le serveur).
Perte de paquets causée par le pare-feu : afin d'identifier si la perte de paquets est causée par le pare-feu, il est nécessaire de comparer la capture d'entrée à la capture de sortie. Il existe de nombreuses façons de comparer deux captures différentes. Cette section présente une méthode d'exécution de cette tâche.
Procédure de comparaison de 2 captures afin d'identifier la perte de paquets
Étape 1. Assurez-vous que les 2 captures contiennent des paquets provenant de la même fenêtre temporelle. Cela signifie qu'il ne doit pas y avoir de paquets dans une capture qui ont été capturés avant ou après l'autre capture. Pour ce faire, vous pouvez procéder de plusieurs manières :
- Vérifiez les première et dernière valeurs d'identification IP (ID) de paquet.
- Vérifiez les valeurs d'horodatage du premier et du dernier paquet.
Dans cet exemple, vous pouvez voir que les premiers paquets de chaque capture ont les mêmes valeurs d'ID IP :
Dans le cas où ils ne sont pas les mêmes alors :
- Comparez les horodatages du premier paquet de chaque capture.
- À partir de la capture avec le dernier Timestamp, obtenez un filtre à partir de celui-ci, changez le filtre Timestamp de == à >= (le premier paquet) et <= (le dernier paquet), par exemple :
(frame.time >= "16 octobre 2019 16:13:43.244692000") &&(frame.time <= "16 octobre 2019 16:20:21.785130000")
3. Exportez les paquets spécifiés vers une nouvelle capture, sélectionnez Fichier > Exporter les paquets spécifiés et enregistrez les paquets affichés. À ce stade, les deux captures doivent contenir des paquets qui couvrent la même période. Vous pouvez maintenant commencer la comparaison des 2 captures.
Étape 2. Spécifiez le champ de paquet utilisé pour la comparaison entre les 2 captures. Exemple de champs qui peuvent être utilisés :
- Identification IP
- Numéro de séquence RTP
- Numéro de séquence ICMP
Créez une version textuelle de chaque capture contenant le champ de chaque paquet que vous avez spécifié à l'étape 1. Pour ce faire, ne laissez que la colonne d'intérêt, par exemple, si vous voulez comparer des paquets basés sur l'identification IP puis modifier la capture comme indiqué dans l'image.
Le résultat :
Étape 3. Créez une version textuelle de la capture (Fichier > Exporter les dissections de paquets > En tant que texte brut...), comme illustré dans l'image :
Désactivez les options Inclure les en-têtes de colonne et Détails du paquet pour exporter uniquement les valeurs du champ affiché, comme illustré dans l'image :
Étape 4. Trier les paquets dans les fichiers. Pour ce faire, vous pouvez utiliser la commande sort de Linux :
# sort CAPI_IDs > file1.sorted # sort CAPO_IDs > file2.sorted
Étape 5. Utilisez un outil de comparaison de texte (par exemple, WinMerge) ou la commande Linux diff pour trouver les différences entre les 2 captures.
Dans ce cas, les captures CAPI et CAPO pour le trafic de données FTP sont identiques. Cela prouve que la perte de paquets n'a pas été causée par le pare-feu.
Identifiez la perte de paquets en amont/en aval.
Principaux points :
1. Ce paquet est une retransmission TCP. Plus précisément, il s’agit d’un paquet SYN TCP envoyé du client au serveur pour les données FTP en mode passif. Puisque le client renvoie le paquet et que vous pouvez voir le SYN initial (paquet #1), le paquet a été perdu en amont du pare-feu.
Dans ce cas, il est possible que le paquet SYN soit arrivé au serveur, mais le paquet SYN/ACK a été perdu sur le chemin du retour :
2. Un paquet provenant du serveur et Wireshark a identifié que le segment précédent n’a pas été vu/capturé. Puisque le paquet non capturé a été envoyé du serveur au client et n'a pas été vu dans la capture du pare-feu, cela signifie que le paquet a été perdu entre le serveur et le pare-feu.
Cela indique une perte de paquets entre le serveur FTP et le pare-feu.
Action 2. Effectuez des captures supplémentaires.
Effectuez des captures supplémentaires avec les captures aux points d'extrémité. Essayez d’appliquer la méthode « diviser et conquérir » pour isoler plus précisément le segment problématique à l’origine de la perte de paquets.
Principaux points :
- Le récepteur (le client FTP dans ce cas) effectue le suivi des numéros de séquence TCP entrants. S'il détecte qu'un paquet a été manqué (un numéro de séquence attendu a été ignoré), il génère un paquet ACK avec ACK='numéro de séquence attendu qui a été ignoré'. Dans cet exemple, Ack=2224386800.
- Le Dup ACK déclenche une retransmission TCP rapide (retransmission dans les 20 ms suivant la réception d'un double ACK).
Que signifient les ACK dupliqués ?
- Quelques ACK dupliqués, mais aucune retransmission réelle, indiquent qu'il y a plus de chances que des paquets arrivent dans le désordre.
- Des ACK dupliqués suivis de retransmissions réelles indiquent une certaine perte de paquets.
Action 3. Calculez le temps de traitement du pare-feu pour les paquets en transit.
Appliquez la même capture sur 2 interfaces différentes :
firepower# capture CAPI buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220 firepower# capture CAPI interface OUTSIDE
Exporter la capture Vérifier la différence de temps entre les paquets entrants et sortants
Cas 7 . Problème de connectivité TCP (corruption de paquet)
Description du problème :
Le client sans fil (192.168.21.193) tente de se connecter à un serveur de destination (192.168.14.250 - HTTP) et il existe deux scénarios différents :
- Lorsque le client se connecte au point d'accès « A », la connexion HTTP ne fonctionne pas.
- Lorsque le client se connecte au point d'accès « B », la connexion HTTP fonctionne.
Cette image présente la topologie :
Flux affecté :
Adresse IP source : 192.168.21.193
Adresse IP d'expédition : 192.168.14.250
Protocole : TCP 80
Analyse de capture
Activer les captures sur le moteur FTD LINA :
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
Captures - Scénario fonctionnel :
Comme base de référence, il est toujours très utile de disposer de captures à partir d'un scénario dont le fonctionnement a été vérifié.
Cette image montre la capture effectuée sur l'interface NGFW INSIDE
Cette image montre la capture effectuée sur l'interface EXTERNE du pare-feu de nouvelle génération.
Principaux points :
- Les deux captures sont presque identiques (considérez la randomisation ISN).
- Il n'y a aucune indication de perte de paquets.
- Pas de paquets hors d'ordre (OOO)
- Il existe 3 requêtes HTTP GET. Le premier reçoit un 404 ‘Not Found’, le second un 200 ‘OK’ et le troisième un 304 ‘Not Modified’ message de redirection.
Captures - Scénario d'erreur connue :
Contenu de la capture d'entrée (CAPI).
Principaux points :
- Il existe une connexion TCP en trois étapes.
- Il existe des retransmissions TCP et des indications de perte de paquets.
- Il y a un paquet (TCP ACK) qui est identifié par Wireshark comme Malformed.
Cette image présente le contenu de la capture de sortie (CAPO).
Principaux points :
Les deux captures sont presque identiques (considérez la randomisation ISN) :
- Il existe une connexion TCP en trois étapes.
- Il existe des retransmissions TCP et des indications de perte de paquets.
- Il y a un paquet (TCP ACK) qui est identifié par Wireshark comme Malformed.
Vérifiez le paquet mal formé :
Principaux points :
- Le paquet est identifié comme étant un paquet malformé par Wireshark.
- Sa longueur est de 2 octets.
- La charge utile TCP est de 2 octets.
- La charge utile est de 4 zéros supplémentaires (00 00).
Actions recommandées
Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.
Action 1. Effectuez des captures supplémentaires. Incluez des captures au niveau des points d'extrémité et, si possible, essayez d'appliquer la méthode « diviser et conquérir » pour isoler la source de la corruption du paquet, par exemple :
Dans ce cas, les 2 octets supplémentaires ont été ajoutés par le pilote d'interface « A » du commutateur et la solution était de remplacer le commutateur qui cause la corruption.
Cas 8 . Problème de connectivité UDP (paquets manquants)
Description du problème : les messages Syslog (UDP 514) ne sont pas visibles sur le serveur Syslog de destination.
Cette image présente la topologie :
Flux affecté :
Adresse IP source : 192.168.1.81
Adresse IP du poste : 10.10.1.73
Protocole : UDP 514
Analyse de capture
Activer les captures sur le moteur FTD LINA :
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
Les captures FTD ne montrent aucun paquet :
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
Actions recommandées
Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.
Action 1. Vérifiez la table de connexion FTD.
Pour vérifier une connexion spécifique, vous pouvez utiliser cette syntaxe :
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
Principaux points :
- Les interfaces d'entrée et de sortie sont identiques (demi-tour).
- Le nombre d'octets a une valeur importante (~5 GoYtes).
- Le drapeau « o » indique le débit de déchargement (HW accéléré). C'est la raison pour laquelle les captures FTD n'affichent aucun paquet. Le déchargement de flux est uniquement pris en charge sur les plates-formes 41xx et 93xx. Dans ce cas, le périphérique est un 41xx.
Action 2. Effectuez des captures au niveau du châssis.
Connectez-vous au gestionnaire de châssis Firepower et activez la capture sur l'interface d'entrée (E1/2 dans ce cas) et les interfaces de fond de panier (E1/9 et E1/10), comme illustré dans l'image :
Au bout de quelques secondes :
Avant :
Après :
Principaux points :
- Un filtre d'affichage est appliqué pour supprimer les doublons de paquets et afficher uniquement les syslogs.
- La différence entre les paquets se situe au niveau des microsecondes. Cela indique un débit de paquets très élevé.
- La valeur de durée de vie (TTL) diminue continuellement. Cela indique une boucle de paquets.
Action 3. Utilisez Packet Tracer.
Comme les paquets ne traversent pas le moteur LINA du pare-feu, vous ne pouvez pas effectuer de trace en direct (capture avec trace), mais vous pouvez suivre un paquet émulé avec 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
Mesure 4. Confirmez le routage FTD.
Vérifiez la table de routage du pare-feu pour voir s'il existe des problèmes de routage :
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
Principaux points :
- La route pointe vers l’interface de sortie correcte.
- La route a été apprise il y a quelques minutes (0:02:37).
Action 5. Confirmez la disponibilité de la connexion.
Vérifiez la disponibilité de la connexion pour savoir quand cette connexion a été établie :
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
Point clé :
- La connexion a été établie il y a environ 4 minutes (avant l’installation de la route EIGRP dans la table de routage)
Mesure no 6. Effacez la connexion établie.
Dans ce cas, les paquets correspondent à une connexion établie et sont routés vers une interface de sortie incorrecte ; cela provoque une boucle. Ceci est dû à l'ordre des opérations du pare-feu :
- Recherche de connexion établie (priorité sur la recherche de table de routage globale).
- Recherche NAT (Network Address Translation) : la phase UN-NAT (destination NAT) est prioritaire sur la recherche PBR et la recherche de route.
- Routage basé sur des politiques (PBR)
- Recherche de table de routage globale
Comme la connexion n'expire jamais (le client Syslog envoie continuellement des paquets pendant que le délai d'inactivité de la connexion UDP est de 2 minutes), il est nécessaire d'effacer manuellement la connexion :
firepower# clear conn address 10.10.1.73 address 192.168.1.81 protocol udp port 514 1 connection(s) deleted.
Vérifiez qu'une nouvelle connexion est établie :
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
Mesure 7. Configurez le délai de conn flottant.
C'est la solution appropriée pour résoudre le problème et éviter un routage non optimal, en particulier pour les flux UDP. Accédez à Devices > Platform Settings > Timeouts et définissez la valeur :
Vous pouvez trouver plus de détails sur le délai d'attente du conn flottant dans le Guide de référence des commandes :
Cas 9 . Problème de connectivité HTTPS (scénario 1)
Description du problème : la communication HTTPS entre le client 192.168.201.105 et le serveur 192.168.202.101 ne peut pas être établie
Cette image présente la topologie :
Flux affecté :
Adresse IP source : 192.168.201.111
Adresse IP d'expédition : 192.168.202.111
Protocole : TCP 443 (HTTPS)
Analyse de capture
Activer les captures sur le moteur FTD LINA :
L'adresse IP utilisée dans la capture OUTSIDE est différente en raison de la configuration de la traduction d'adresses de port.
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
Cette image montre la capture effectuée sur l'interface INSIDE du pare-feu de nouvelle génération :
Principaux points :
- Il existe une connexion TCP en trois étapes.
- La négociation SSL commence. Le client envoie un message Hello Client.
- Un accusé de réception TCP est envoyé au client.
- Un RST TCP est envoyé au client.
Cette image montre la capture effectuée sur l'interface EXTERNE du pare-feu de nouvelle génération.
Principaux points :
- Il existe une connexion TCP en trois étapes.
- La négociation SSL commence. Le client envoie un message Hello Client.
- Des retransmissions TCP sont envoyées du pare-feu vers le serveur.
- Un RST TCP est envoyé au serveur.
Actions recommandées
Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.
Action 1. Effectuez des captures supplémentaires.
Une capture effectuée sur le serveur révèle que le serveur a reçu les Hello du client TLS avec la somme de contrôle TCP corrompue et les abandonne silencieusement (il n'y a pas de TCP RST ou tout autre paquet de réponse vers le client) :
Lorsque vous mettez tout ensemble :
Dans ce cas, pour comprendre, il est nécessaire d'activer sur Wireshark l'option Valider la somme de contrôle TCP si possible. Naviguez jusqu'à Edit > Preferences > Protocols > TCP, comme indiqué dans l'image.
Dans ce cas, il est utile de placer les captures côte à côte afin d'obtenir une image complète :
Principaux points :
- Il existe une connexion TCP en trois étapes. Les ID IP sont identiques. Cela signifie que le flux n'a pas été mis en proxy par le pare-feu.
- Un Hello de client TLS provient du client avec l'ID IP 12083. Le paquet est mis en proxy par le pare-feu (le pare-feu, dans ce cas, a été configuré avec la stratégie de déchiffrement TLS) et l'ID IP est modifié à 52534. En outre, la somme de contrôle TCP du paquet est corrompue (en raison d'un défaut logiciel qui a été réparé par la suite).
- Le pare-feu est en mode Proxy TCP et envoie un ACK au client (qui usurpe le serveur).
- Le pare-feu ne reçoit aucun paquet ACK TCP du serveur et retransmet le message Hello du client TLS. Cela est encore dû au mode Proxy TCP que le pare-feu a activé.
- Après environ 30 secondes, le pare-feu abandonne et envoie un RST TCP au client.
- Le pare-feu envoie un RST TCP au serveur.
Pour référence :
Traitement de la connexion TLS/SSL Firepower
Cas 10 . Problème de connectivité HTTPS (scénario 2)
Description du problème : l'enregistrement de la licence Smart FMC échoue.
Cette image présente la topologie :
Flux affecté :
Adresse IP source : 192.168.0.100
Dst : tools.cisco.com
Protocole : TCP 443 (HTTPS)
Analyse de capture
Activez la capture sur l'interface de gestion FMC :
Réessayez de vous inscrire. Lorsque le message d'erreur apparaît, appuyez sur CTRL-C pour arrêter la capture :
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#
Collectez la capture à partir du FMC (System > Health > Monitor, sélectionnez le périphérique et sélectionnez Advanced Troubleshooting), comme illustré dans l'image :
L’image montre la capture FMC sur Wireshark :
Suivez l'un des flux TCP (Follow > TCP Stream), comme illustré dans l'image.
Principaux points :
- Il existe une connexion TCP en trois étapes.
- Le client (FMC) envoie un message Hello de client SSL vers le portail Smart Licensing.
- L'ID de session SSL est 0. Cela signifie qu'il ne s'agit pas d'une reprise de session.
- Le serveur de destination répond avec le message Server Hello, Certificate et Server Hello Done.
- Le client envoie une alerte SSL fatale qui concerne une « CA inconnue ».
- Le client envoie un RST TCP pour fermer la session.
- La durée totale de la session TCP (de l'établissement à la fermeture) était d'environ 0,5 seconde.
Sélectionnez le certificat de serveur et développez le champ de l'émetteur pour voir le commonName. Dans ce cas, le nom commun indique un périphérique qui fait de l'homme du milieu (MITM).
Ceci est montré dans cette image :
Actions recommandées
Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.
Action 1. Effectuez des captures supplémentaires.
Effectuez des captures sur le périphérique de pare-feu de transit :
CAPI montre :
CAPO montre :
Ces captures prouvent que le pare-feu de transit modifie le certificat de serveur (MITM)
Action 2. Vérifiez les journaux des périphériques.
Vous pouvez collecter l'offre groupée FMC TS comme décrit dans ce document :
Dans ce cas, le fichier /dir-archives/var-log/process_stdout.log affiche des messages comme ceci :
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/
Solution recommandée
Désactivez le MITM pour le flux spécifique afin que FMC puisse s'enregistrer avec succès sur le cloud de licences Smart.
Cas 11 . Problème de connectivité IPv6
Description du problème : les hôtes internes (situés derrière l'interface INSIDE du pare-feu) ne peuvent pas communiquer avec les hôtes externes (hôtes situés derrière l'interface OUTSIDE du pare-feu).
Cette image présente la topologie :
Flux affecté :
Src IP: fc00:1:1:1::100
Dst IP: fc00:1:1:2::2
Protocole : tout
Analyse de capture
Activer les captures sur le moteur FTD LINA.
firepower# capture CAPI int INSIDE match ip any6 any6 firepower# capture CAPO int OUTSIDE match ip any6 any6
Captures - Scénario non fonctionnel
Ces captures ont été effectuées en parallèle avec un test de connectivité ICMP de l'IP fc00:1:1:1::100 (routeur interne) à l'IP fc00:1:1:2::2 (routeur en amont).
La capture sur l'interface INSIDE du pare-feu contient :
Principaux points :
- Le routeur envoie un message de sollicitation de voisin IPv6 et demande l'adresse MAC du périphérique en amont (IP fc00:1:1::1).
- Le pare-feu répond avec une annonce de voisin IPv6.
- Le routeur envoie une requête d’écho ICMP.
- Le pare-feu envoie un message de sollicitation de voisin IPv6 et demande l'adresse MAC du périphérique en aval (fc00:1:1:1::100).
- Le routeur répond avec une annonce de voisin IPv6.
- Le routeur envoie des requêtes d'écho ICMP IPv6 supplémentaires.
La capture sur l'interface EXTERNE du pare-feu contient :
Principaux points :
- Le pare-feu envoie un message de sollicitation de voisin IPv6 qui demande l'adresse MAC du périphérique en amont (IP fc00:1:1:2::2).
- Le routeur répond avec une annonce de voisin IPv6.
- Le pare-feu envoie une requête d'écho ICMP IPv6.
- Le périphérique en amont (routeur fc00:1:1:2::2) envoie un message de sollicitation de voisin IPv6 qui demande l'adresse MAC de l'adresse IPv6 fc00:1:1:1::100.
- Le pare-feu envoie une requête d'écho ICMP IPv6 supplémentaire.
- Le routeur en amont envoie un message de sollicitation de voisin IPv6 supplémentaire qui demande l'adresse MAC de l'adresse IPv6 fc00:1:1:1::100.
Le point 4 est très intéressant. Normalement, le routeur en amont demande l'adresse MAC de l'interface OUTSIDE du pare-feu (fc00:1:1:2::2), mais à la place, il demande l'adresse fc00:1:1:1::100. Ceci indique une erreur de configuration.
Actions recommandées
Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.
Action 1. Vérifiez la table de voisinage IPv6.
La table de voisinage IPv6 du pare-feu est correctement remplie.
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
Action 2. Vérifiez la configuration IPv6.
Voici la configuration du pare-feu.
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 configuration du périphérique en amont révèle l'erreur de configuration :
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
Captures - Scénario fonctionnel
La modification du masque de sous-réseau (de /48 à /64) a résolu le problème. Il s'agit de la capture CAPI dans le scénario fonctionnel.
Point clé :
- Le routeur envoie un message de sollicitation de voisin IPv6 qui demande l'adresse MAC du périphérique en amont (IP fc00:1:1:1::1).
- Le pare-feu répond avec une annonce de voisin IPv6.
- Le routeur envoie des requêtes d’écho ICMP et obtient des réponses d’écho.
Contenu CAPO :
Principaux points :
- Le pare-feu envoie un message de sollicitation de voisin IPv6 qui demande l'adresse MAC du périphérique en amont (IP fc00:1:1:2::2).
- Le pare-feu répond avec une annonce de voisin IPv6.
- Le pare-feu envoie une requête d’écho ICMP.
- Le routeur envoie un message de sollicitation de voisin IPv6 qui demande l'adresse MAC du périphérique en aval (IP fc00:1:1:1::1).
- Le pare-feu répond avec une annonce de voisin IPv6.
- Le pare-feu envoie des requêtes d'écho ICMP et obtient des réponses d'écho.
Cas 12 . Problème de connectivité intermittent (empoisonnement ARP)
Description du problème : les hôtes internes (192.168.0.x/24) présentent des problèmes de connectivité intermittents avec les hôtes du même sous-réseau
Cette image présente la topologie :
Flux affecté :
Adresse IP source : 192.168.0.x/24
Adresse IP d'expédition : 192.168.0.x/24
Protocole : tout
Le cache ARP d'un hôte interne semble être empoisonné :
Analyse de capture
Activer une capture sur le moteur LINA FTD
Cette capture ne capture que les paquets ARP sur l'interface INSIDE :
firepower# capture CAPI_ARP interface INSIDE ethernet-type arp
Captures - Scénario non fonctionnel :
La capture sur l'interface INSIDE du pare-feu contient.
Principaux points :
- Le pare-feu reçoit diverses requêtes ARP pour les adresses IP du réseau 192.168.0.x/24
- Le pare-feu répond à tous ces paquets (proxy-ARP) avec sa propre adresse MAC
Actions recommandées
Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.
Action 1. Vérifiez la configuration NAT.
En ce qui concerne la configuration NAT, il y a des cas où le mot clé no-proxy-arp peut empêcher le comportement précédent :
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
Action 2. Désactivez la fonctionnalité proxy-arp sur l'interface du pare-feu.
Si le mot clé « no-proxy-arp » ne résout pas le problème, essayez de désactiver le proxy ARP sur l'interface elle-même. Dans le cas de FTD, au moment de la rédaction de ce document, vous devez utiliser FlexConfig et déployer la commande (spécifiez le nom d'interface approprié).
sysopt noproxyarp INSIDE
Cas 13 . Identifier les identificateurs d'objet SNMP (OID) qui provoquent des erreurs de CPU
Ce cas montre comment certains OID SNMP pour l'interrogation de la mémoire ont été identifiés comme la cause principale des erreurs de CPU (problème de performances) sur la base de l'analyse des captures de paquets SNMP version 3 (SNMPv3).
Description du problème : les dépassements sur les interfaces de données augmentent constamment. D'autres recherches ont révélé qu'il y a aussi des erreurs de CPU (causées par le processus SNMP) qui sont la cause première des dépassements d'interface.
L'étape suivante du processus de dépannage consistait à identifier la cause première des erreurs de CPU provoquées par le processus SNMP et, en particulier, à réduire l'étendue du problème pour identifier les identificateurs d'objet SNMP (OID) qui, lorsqu'ils sont interrogés, peuvent potentiellement entraîner des erreurs de CPU.
Actuellement, le moteur FTD LINA ne fournit pas de commande « show » pour les OID SNMP qui sont interrogés en temps réel.
La liste des OID SNMP pour l'interrogation peut être récupérée à partir de l'outil de surveillance SNMP, cependant, dans ce cas, il y avait ces facteurs préventifs :
- L'administrateur FTD n'a pas eu accès à l'outil de surveillance SNMP
- SNMP version 3 avec authentification et cryptage des données pour la confidentialité a été configuré sur FTD
Analyse de capture
Comme l'administrateur FTD disposait des informations d'identification pour l'authentification SNMP version 3 et le cryptage des données, ce plan d'action a été proposé :
- Capture des paquets SNMP
- Enregistrez les captures et utilisez les préférences de protocole SNMP de Wireshark pour spécifier les informations d'identification SNMP version 3 afin de déchiffrer les paquets SNMP version 3. Les captures décryptées sont utilisées pour l'analyse et la récupération des OID SNMP
Configurez les captures de paquets SNMP sur l'interface utilisée dans la configuration d'hôte snmp-server :
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
Principaux points :
- Adresses/ports source et de destination SNMP.
- La PDU du protocole SNMP n'a pas pu être décodée car privKey est inconnu de Wireshark.
- La valeur de la primitive encryptéePDU.
Actions recommandées
Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.
Action 1. Déchiffrez les captures SNMP.
Enregistrez les captures et modifiez les préférences du protocole SNMP Wireshark pour spécifier les informations d'identification SNMP version 3 permettant de déchiffrer les paquets.
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
Ouvrez le fichier de capture sur Wireshark, sélectionnez un paquet SNMP et naviguez jusqu'à Protocol Preferences > Users Table, comme indiqué dans l'image :
Dans le tableau SNMP Users, le nom d'utilisateur, le modèle d'authentification, le mot de passe d'authentification, le protocole de confidentialité et le mot de passe de confidentialité SNMP version 3 ont été spécifiés (les informations d'identification réelles ne sont pas indiquées ci-dessous) :
Une fois que les paramètres SNMP Users ont été appliqués, Wireshark a montré les PDU SNMP déchiffrées :
Principaux points :
- Les outils de surveillance SNMP ont utilisé SNMP getBulkRequest pour interroger et parcourir l'OID parent 1.3.6.1.4.1.9.9.221.1 et les OID associés.
- Le FTD a répondu à chaque getBulkRequest avec get-response qui contient des OID associés à 1.3.6.1.4.1.9.9.221.1.
Action 2. Identifiez les OID SNMP.
SNMP Object Navigator a montré que l'OID 1.3.6.1.4.1.9.9.221.1 appartient à la base d'informations de gestion (MIB) nommée CISCO-ENHANCED-MEMPOOL-MIB, comme indiqué dans l'image :
Pour afficher les OID dans un format lisible par l'utilisateur dans Wireshark :
- Téléchargez la MIB CISCO-ENHANCED-MEMPOOL-MIB et ses dépendances, comme illustré dans l'image :
2. Dans Wireshark dans la fenêtre Edit > Preferences > Name Resolution, l'option Enable OID Resolution est cochée. Dans la fenêtre SMI (MIB and PIB paths), spécifiez le dossier avec les MIB téléchargées et dans SMI (MIB and PIB modules). La MIB CISCO-ENHANCED-MEMPOOL est ajoutée automatiquement à la liste des modules :
3. Une fois Wireshark redémarré, la résolution OID est activée :
Sur la base de la sortie déchiffrée du fichier de capture, l'outil de surveillance SNMP interrogeait régulièrement (10 secondes d'intervalle) les données relatives à l'utilisation des pools de mémoire sur le FTD. Comme expliqué dans l'article TechNote ASA SNMP Polling for Memory-Related Statistics , l'interrogation de l'utilisation du pool partagé global (GSP) avec SNMP entraîne une utilisation CPU élevée. Dans ce cas, à partir des captures, il était clair que l'utilisation du pool partagé global était régulièrement interrogée dans le cadre de la primitive getBulkRequest SNMP.
Afin de minimiser les problèmes de CPU causés par le processus SNMP, il a été recommandé de suivre les étapes de mitigation pour les problèmes de CPU pour SNMP mentionnés dans l'article et d'éviter d'interroger les OID liés à GSP. Sans l'interrogation SNMP pour les OID qui se rapportent à GSP, aucun bogue de CPU causé par le processus SNMP n'a été observé et le taux de dépassements a diminué de manière significative.
Informations connexes
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
3.0 |
31-Jul-2024 |
Recertification, texte de remplacement, en-têtes fixes, ponctuation et optimisation du référencement html. |
2.0 |
02-Jun-2023 |
Recertification |
1.0 |
21-Nov-2019 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)