Analysez les captures de pare-feu Firepower pour résoudre efficacement les problèmes de réseau
Contenu
Introduction
Ce document décrit diverses techniques d'analyse de capture de paquets qui visent à résoudre efficacement les problèmes de réseau. Tous les scénarios présentés dans ce document sont basés sur des cas réels d'utilisation observés dans le centre d'assistance technique 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.
Conditions préalables
Conditions requises
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Architecture de plate-forme Firepower
- Journaux NGFW
- traceur de paquets NGFW
En outre, avant de commencer à analyser les captures de paquets, il est vivement conseillé de respecter ces exigences :
- Connaître le fonctionnement du protocole - Il est inutile de commencer à 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. Idéalement, 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 également prêt à appliquer d'autres outils et techniques de dépannage tels que la journalisation et les traceurs et, si nécessaire, à les corréler avec les paquets capturés
Components Used
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 aujourd’hui. Chaque jour, le TAC Cisco résout de nombreux problèmes client en analysant les 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 en se basant principalement sur l'analyse de la capture de paquets.
Comment collecter et exporter des captures sur la gamme de produits NGFW ?
Dans le cas d'un dispositif 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 de la liaison FTD qui effectue principalement des contrôles L3/L4.
- Si la stratégie requiert que le paquet soit inspecté par le moteur Snort (inspection L7 principalement).
- 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 le châssis par le biais du commutateur interne du châssis.
Sur la base de l'architecture illustrée, les captures FTD peuvent être prises en 3 endroits différents :
- FXOS
- Moteur Lina FTD
- 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 du point de vue du commutateur interne sont affichées dans l'image ici.
Comme l'illustre l'image, 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 de la licence 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 de la Lina FTD.
Activez la capture à partir de l'interface de ligne de commande 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 Lina FTD :
firepower# capture ASP type asp-drop all
Exporter une capture de la liaison FTD vers un serveur FTP :
firepower# copy /pcap capture:CAPI ftp://ftp_username:ftp_password@192.168.78.73/CAPI.pcap
Exporter une capture de liaison FTD 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 des captures de Lina FTD à partir de l'interface FMC.
Voici une autre façon de collecter les 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, p.ex.
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 à l'emplacement /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 à Devices > Device Management. Localisez le périphérique FTD et sélectionnez l'icône Dépannage :
É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/de collecter des captures à partir de l'interface utilisateur FMC, consultez ce document :
Activer et collecter les captures de nort FTD
Le point de capture est affiché dans l'image ici.
Activer la capture au niveau du noeud :
> 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 portant le nom 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 au 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 ici :
Description du problème : HTTP ne fonctionne pas
Flux affecté :
IP Src : 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 :
Comme base de référence, il est toujours très utile d'avoir des captures à partir d'un scénario fonctionnel.
La capture effectuée sur l'interface INSIDE du pare-feu de nouvelle génération est illustrée sur l'image :
Points clés :
- 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 aval correct.
La capture prise sur l'interface externe du pare-feu de nouvelle génération est illustrée ici :
Points clés :
- Les mêmes données que dans la capture CAPI.
- L'adresse MAC de destination est le périphérique 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 :
Points clés :
- Seuls les paquets SYN TCP sont vus (pas de connexion TCP en 3 étapes).
- Deux sessions TCP (port source 3171 et 3172) ne peuvent pas être établies. Le client source renvoie les paquets SYN TCP. Ces paquets retransmis sont identifiés par Wireshark comme étant des retransmissions TCP.
- Les retransmissions TCP ont lieu toutes les ~3, 6, etc secondes
- L’adresse MAC source provient du périphérique aval approprié.
Sur la base des 2 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 énumérées dans cette section ont pour but de mieux cerner le problème.
Action 1. Vérifiez le suivi d’un paquet émulé.
Utilisez l’outil packet-tracer pour voir comment un paquet est censé être géré par le pare-feu. Dans le cas où le paquet est abandonné par la stratégie 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 de paquets actifs.
Activez le suivi des paquets pour vérifier comment les vrais paquets SYN TCP sont gérés par le pare-feu. Par défaut, seuls les 50 premiers paquets d'entrée sont suivis :
firepower# capture CAPI trace
Effacez la mémoire tampon de capture :
firepower# clear capture /all
Si le paquet est abandonné par la stratégie 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 de la Lina FTD.
Pour configurer Syslog sur FTD via FMC, vérifiez ce document :
Il est fortement recommandé de configurer un serveur Syslog externe pour les journaux de la Lina FTD. Si aucun serveur Syslog distant n'est configuré, activez les journaux de tampon locaux 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 téléavertisseur de terminal sur 24 lignes afin de contrôler le téléavertisseur de terminal :
firepower# terminal pager 24
Effacez la mémoire tampon de capture :
firepower# clear logging buffer
Testez la connexion et vérifiez les journaux à l'aide d'un filtre d'analyseur. Dans cet exemple, les paquets sont abandonnés par la stratégie 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]
Action 4. Vérifiez les pertes ASP du pare-feu.
Si vous soupçonnez 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 du 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 au niveau du 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 la perte 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 de rejet ASP spécifique. Voici une approche recommandée :
1. Effacer les compteurs de dépôt 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é, par exemple.
firepower# show asp drop Frame drop: No route to host (no-route) 234 Flow is denied by configured rule (acl-drop) 71
4. Activez les captures ASP pour les pertes spécifiques vues :
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>
Mesure 5. Vérifiez la table de connexion de la liaison FTD.
Il peut y avoir des cas où vous attendez que le paquet quitte l'interface 'X', mais pour toutes les raisons, il quitte 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 NAT ONU (destination NAT) a priorité sur 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
Points clés :
- Basée sur les indicateurs (Aa), la connexion est embryonnaire (semi-ouverte - seul TCP SYN a été vu par le pare-feu).
- En fonction des ports source/destination, l'interface d'entrée est INSIDE et l'interface de sortie est DMZ.
Vous pouvez le visualiser sur 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
Produit 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
Produit 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 adresses IP NATed entre parenthèses en cas de traduction d'adresses de 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 6. Vérifiez le cache ARP (Address Resolution Protocol) du pare-feu.
Si le pare-feu ne parvient pas à résoudre le tronçon suivant, le pare-feu 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 tronçon 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 voulez vérifier plus avant 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 ici montre un scénario fonctionnel avec une résolution ARP correcte :
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, une trace d’un paquet TCP SYN 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 le montre le résultat, la trace affiche Action : autoriser même lorsque le saut suivant n'est pas accessible et que le paquet est abandonné en silence 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 ci-dessus 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
Causes possibles et actions recommandées Résumé
Si vous ne voyez qu’un paquet SYN TCP sur les interfaces d’entrée, mais qu’aucun paquet SYN TCP n’est envoyé hors de l’interface de sortie attendue, certaines causes possibles sont les suivantes :
| 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 existante, 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 montre la topologie :
Description du problème : HTTP ne fonctionne pas
Flux affecté :
IP Src : 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 :
À partir de l'interface de ligne de commande du périphérique, les captures sont présentées comme suit :
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.
Points clés :
- La source envoie un paquet SYN TCP.
- Une TVD TCP est envoyée vers la source.
- La source retransmet les paquets SYN TCP.
- Les adresses MAC sont correctes (sur les paquets d'entrée, 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 :
Points clés :
- La source envoie un paquet SYN TCP.
- Une TVD TCP arrive sur l'interface OUTSIDE.
- La source retransmet les paquets SYN TCP.
- 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 2 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 amont et aval appropriés (en fonction des adresses MAC)
Actions recommandées
Les actions énumérées dans cette section ont pour but de mieux cerner le problème.
Action 1. Vérifiez l'adresse MAC source qui envoie la TVD TCP.
Vérifiez que l’adresse MAC de destination vue dans le paquet SYN TCP est identique à celle que l’adresse MAC source a vue dans le paquet RST TCP.
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 d'entrée et de sortie.
Comparez visuellement les 2 paquets sur Wireshark pour vérifier que le pare-feu ne modifie pas/corrompt les paquets. Certaines différences attendues sont mises en évidence.
Points clés :
- Les délais sont différents. D'un autre côté, la différence doit être faible et raisonnable. Cela dépend des fonctionnalités 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 peut être différente, en particulier s'il y a un en-tête dot1Q ajouté/supprimé par le pare-feu d'un côté seulement.
- Les adresses MAC sont différentes.
- Un en-tête dot1Q peut être en place si la capture a été prise sur une sous-interface.
- Les adresses IP sont différentes dans le cas où la traduction d’adresses de port (PAT) ou NAT est appliquée au paquet.
- Les ports source ou de destination sont différents dans le cas où la NAT ou la PAT est appliquée au paquet.
- Si vous désactivez l'option Numéro de séquence relatif Wireshark, vous constatez que les numéros de séquence/d'accusé de réception TCP sont modifiés par le pare-feu en raison de la randomisation du numéro de séquence initial (ISN).
- Certaines options TCP peuvent être remplacées. Par exemple, le pare-feu modifie par défaut la taille maximale de segment TCP (MSS) en 1380 afin d'éviter la fragmentation des paquets dans le chemin de transit.
Action 3. Effectuez une capture à la destination.
Si possible, prenez une capture à la destination elle-même. Si cela n'est pas possible, prenez une capture aussi proche que possible de la destination. L'objectif ici est de vérifier qui envoie le TCP RST (est-ce le serveur de destination ou un autre périphérique sur le chemin ?).
Cas 3 . Connexion TCP en trois étapes + RST à partir d'un point d'extrémité
Cette image montre la topologie :
Description du problème : HTTP ne fonctionne pas
Flux affecté :
IP Src : 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 :
Il y a deux ou trois façons différentes dont ce problème peut se manifester dans les captures.
3.1 - Connexion TCP en trois étapes + TVD différée du client
Le pare-feu capture CAPI et CAPO contenant les mêmes paquets, comme l'illustre l'image.
Points clés :
- La connexion TCP en trois étapes passe par le pare-feu.
- Le serveur retransmet le SYN/ACK.
- Le client retransmet l’ACK.
- Après ~20 secondes, le client abandonne et envoie une TVD TCP.
Actions recommandées
Les actions énumérées dans cette section ont pour but de mieux cerner le problème.
Action 1. Prenez des captures aussi près que possible des deux points d'extrémité.
Les captures de pare-feu indiquent que l'ACK client n'a pas été traité par le serveur. Ces faits sont à l'origine :
- Le serveur retransmet le SYN/ACK.
- Le client retransmet l’ACK.
- Le client envoie un RST TCP ou FIN/ACK avant toute donnée.
La capture sur le serveur montre le problème. L’ACK client de la connexion TCP en trois étapes n’est jamais arrivé :
3.2 - Connexion TCP en trois étapes + FIN/ACK retardé du client + TVD différée du serveur
Le pare-feu capture CAPI et CAPO contenant les mêmes paquets, comme l'illustre l'image.
Points clés :
- 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 une TVD TCP.
Sur la base de cette capture, il est possible de conclure que, bien qu’il y ait une connexion TCP en trois étapes via 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 + TVD différée du client
Le pare-feu capture CAPI et CAPO contenant les mêmes paquets, comme l'illustre l'image.
Points clés :
- La connexion TCP en trois étapes passe par le pare-feu.
- Après ~20 secondes, le client abandonne et envoie une TVD TCP.
Sur la base de ces captures, on peut conclure que :
- Après 5 à 20 secondes, un point d'extrémité 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 deux pare-feu capturent CAPI et CAPO contiennent ces paquets, comme le montre l'image.
Points clés :
- La connexion TCP en trois étapes passe par le pare-feu.
- Il y a une TVD TCP du serveur quelques millisecondes après le paquet ACK.
Actions recommandées
Action : Prenez des captures aussi près que possible du serveur.
Une TVD TCP immédiate du serveur peut indiquer un serveur défaillant ou un périphérique dans le chemin qui envoie la TVD TCP. Prenez une capture sur le serveur lui-même et déterminez la source de la TVD TCP.
Cas 4 . TCP RST du client
Cette image montre la topologie :
Description du problème : HTTP ne fonctionne pas.
Flux affecté :
IP Src : 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 :
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 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 indiquent :
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'il existe une taxe TCP RST qui 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 à Edition > Préférences > Protocoles > TCP et désélectionnez l'option Numéros de séquence relatifs comme indiqué dans l'image.
Cette image montre le contenu du premier flux dans la capture CAPI :
Points clés :
- Le client envoie un paquet SYN TCP.
- Le client envoie un paquet TCP RST.
- Le paquet SYN TCP a une valeur de numéro de séquence égale à 4098574664.
Le même flux dans la capture CAPO contient :
Points clés :
- Le client envoie un paquet SYN TCP. 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 une TVD TCP qui vient du client. La valeur du numéro de séquence RST TCP dans la capture CAPI est 1386249853.
Actions recommandées
Les actions énumérées dans cette section ont pour but de mieux cerner le problème.
Action 1. Capturez le client.
D'après les 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 une TVD TCP avec une valeur de 1386249853 (le numéro ISN aléatoire) :
Points clés :
- Le client envoie un paquet SYN TCP. Le numéro de séquence est 4098574664 et est identique à celui de l'interface INSIDE du pare-feu (CAPI)
- Il existe un SYN/ACK TCP portant le numéro ACK 1386249853 (qui est attendu en raison de la randomisation ISN). Ce paquet n'a pas été vu dans les captures de pare-feu
- Le client envoie un RST TCP car il attendait un SYN/ACK avec un numéro ACK de 4098574665, mais il a reçu une valeur de 1386249853
Vous pouvez le visualiser comme suit :
Action 2. Vérifiez le routage entre le client et le pare-feu.
Confirmez que :
- Les adresses MAC affichées dans les captures sont les adresses attendues.
- Assurez-vous que le routage entre le pare-feu et le client est symétrique.
Il existe des scénarios dans lesquels 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 illustré dans l'image :
Dans ce cas, la capture a ce contenu. Notez la différence entre l'adresse MAC source du paquet SYN TCP et l'adresse MAC source du TCP RST et l'adresse MAC de destination du paquet SYN/ACK TCP :
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 (BW) entre les 2 hôtes soit de 100 Mbits/s, la vitesse de transfert ne dépasse pas 5 Mbits/s.
Parallèlement, la vitesse de transfert entre les hôtes 10.11.2.124 et 172.25.18.134 est beaucoup plus élevée.
Théorie générale :
La vitesse de transfert maximale pour un seul flux TCP est déterminée par le BDP (Bandwidth Delay Product). La formule utilisée est affichée dans l'image :
Pour plus d'informations sur le protocole BDP, consultez les ressources ici :
- Pourquoi votre application utilise-t-elle uniquement 10 Mbits/s ? Même la liaison est de 1 Gbits/s ?
- BRKSEC-3021 - Avancé - Optimisation des performances des pare-feu
Scénario 1. Transfert lent
Cette image montre la topologie :
Flux affecté :
IP Src : 10.11.4.171
Adresse IP de destination : 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 énumérées dans cette section ont pour but de mieux cerner le problème.
Calcul du temps de trajet aller-retour (RTT)
Identifiez d'abord le flux de transfert et suivez-le :
Modifiez la vue Wireshark pour afficher les secondes depuis le paquet affiché précédent. Cela facilite le calcul du TTR :
Le RTT peut être calculé en ajoutant les valeurs de temps entre 2 échanges de paquets (un vers la source et un vers la destination). Dans ce cas, le paquet n° 2 affiche le RTT entre le pare-feu et le périphérique qui a envoyé le paquet SYN/ACK (serveur). Le paquet n° 3 indique le RTT entre le pare-feu et le périphérique qui a envoyé le paquet ACK (client). L'ajout des 2 chiffres fournit une bonne estimation du RTT de bout en bout :
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 Taille de fenêtre calculée et sélectionnez Appliquer en tant que colonne :
Vérifiez la colonne Valeur de taille de fenêtre calculée pour voir quelle était la valeur de taille de fenêtre maximale au cours de 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 fichiers (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 fenêtre TCP est ±50 000 octets
En vous basant sur ces valeurs et avec l'utilisation de la formule de produit Bandwidth Delay, vous obtenez la bande passante théorique maximale qui peut être atteinte dans les conditions suivantes : 50000*8/0.08 = bande passante théorique maximale de 5 Mbits/s.
Cela correspond à l'expérience du client dans ce cas.
Vérifiez attentivement 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 mise à l'échelle de fenêtres). 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 (vous devrez peut-être vérifier la documentation du serveur pour faire ceci).
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 Src : 10.11.2.124
Adresse IP de destination : 172.25.18.134
Protocole : SFTP (FTP sur SSH)
Activer les captures sur le moteur FTD LINA
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 trajet 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 fenêtre TCP du serveur est ±1600000 octets :
Sur la base de ces valeurs, la formule 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 montre la topologie :
Flux affecté :
IP Src : 192.168.2.220
Adresse IP de destination : 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 canal de données FTP sur la capture INSIDE FTD (CAPI) :
Contenu du flux FTP-DATA :
Le contenu de capture CAPO :
Points clés :
- Il existe des paquets TCP hors commande (OOO).
- Il existe une retransmission TCP.
- Il y a une indication de perte de paquets (paquets abandonnés).
Actions recommandées
Les actions énumérées dans cette section ont pour but de mieux cerner le problème.
Action 1. Identifiez l'emplacement de perte de paquets.
Dans de tels cas, vous devez prendre des captures simultanées et utiliser la méthodologie diviser et conquérir pour identifier le ou les segments de réseau qui causent la perte de paquets. Du point de vue du pare-feu, il existe trois 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 du périphérique de pare-feu (direction du serveur au client).
- La perte de paquets est provoquée en amont sur le périphérique du pare-feu (direction du client au 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 y a beaucoup de façons de comparer 2 captures différentes. Cette section illustre une façon d'effectuer 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 de la même fenêtre de temps. 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. Il existe plusieurs façons de procéder :
- Vérifiez les valeurs d'identification IP du premier et du dernier paquet.
- Vérifiez les valeurs d'horodatage des premiers et derniers paquets.
Dans cet exemple, vous pouvez voir que les premiers paquets de chaque capture ont les mêmes valeurs d'ID IP :
Au cas où ils ne seraient pas les mêmes :
- 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.78513000 0 »)
3. Exportez les paquets spécifiés vers une nouvelle capture, sélectionnez Fichier > Exporter les paquets spécifiés, puis enregistrez les paquets affichés. À ce stade, les deux captures doivent contenir des paquets qui couvrent la même fenêtre de temps. 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 pouvant être utilisés :
- Identification IP
- Numéro de séquence RTP
- Numéro de séquence ICMP
Créez une version texte de chaque capture qui contient le champ de chaque paquet que vous avez spécifié à l'étape 1. Pour ce faire, laissez uniquement la colonne d'intérêt, par exemple si vous voulez comparer des paquets basés sur l'identification IP, puis modifiez la capture comme indiqué dans l'image.
Résultat :
Étape 3. Créez une version texte de la capture (Fichier > Exporter les dissections de paquets > En texte brut...), comme illustré dans l'image :
Désélectionnez 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. Triez les paquets dans les fichiers. Vous pouvez utiliser la commande de tri Linux pour ceci :
# 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 diff Linux pour trouver les différences entre les 2 captures.
Dans ce cas, la capture CAPI et CAPO pour le trafic de données FTP sont identiques. Ceci prouve que la perte de paquet n'a pas été causée par le pare-feu.
Identifier la perte de paquets en amont/en aval.
Points clés :
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 n°1), le paquet a été perdu en amont du pare-feu.
Dans ce cas, il peut même y avoir la possibilité que le paquet SYN soit parvenu au serveur, mais le paquet SYN/ACK a été perdu lors du retour :
2. Un paquet provient 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. Prendre Des Captures Supplémentaires.
Prendre des captures supplémentaires avec des captures aux points d'extrémité. Essayez d'appliquer la méthode diviser et conquérir pour isoler davantage le segment problématique qui cause la perte de paquets.
Points clés :
- Le récepteur (le client FTP dans ce cas) suit les 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 le numéro de séquence attendu ACK='ignoré'. Dans cet exemple, Ack=2224386800.
- L'ACK Dup déclenche une retransmission rapide TCP (retransmission dans les 20 ms suivant la réception d'un ACK en double).
Que signifient les accusés de réception en double ?
- Quelques ACK dupliqués mais aucune retransmission réelle indiquent qu'il est plus probable qu'il y ait des paquets qui arrivent dans le désordre.
- Les ACK dupliqués suivis de retransmissions réelles indiquent qu'il y a une certaine perte de paquets.
Action 3. Calculez le temps de traitement du pare-feu pour les paquets de 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 d'entrée et les paquets de sortie
Cas 7 . Problème de connectivité TCP (corruption de paquets)
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 (AP) 'B', la connexion HTTP fonctionne.
Cette image montre la topologie :
Flux affecté :
IP Src : 192.168.21.193
Adresse IP de destination : 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 d'avoir des captures à partir d'un scénario de travail.
Cette image montre la capture prise sur l'interface INSIDE du pare-feu de nouvelle génération
Cette image montre la capture prise sur l'interface externe de NGFW.
Points clés :
- Les 2 captures sont presque identiques (considérez l'aléisation ISN).
- Il n'y a aucune indication de perte de paquet.
- Pas de paquets OOO (Out-Of-Order)
- 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 non fonctionnel :
Le contenu de capture d'entrée (CAPI).
Points clés :
- Il existe une connexion TCP en trois étapes.
- Il existe des retransmissions TCP et des indications de perte de paquets.
- Il existe un paquet (TCP ACK) identifié par Wireshark comme mal formé.
Cette image montre le contenu de la capture de sortie (CAPO).
Points clés :
Les 2 captures sont presque identiques (considérez l'aléisation ISN) :
- Il existe une connexion TCP en trois étapes.
- Il existe des retransmissions TCP et des indications de perte de paquets.
- Il existe un paquet (TCP ACK) identifié par Wireshark comme mal formé.
Vérifiez le paquet mal formé :
Points clés :
- Le paquet est identifié comme étant mal formé par Wireshark.
- Il a une longueur de 2 octets.
- Il existe une charge utile TCP de 2 octets.
- La charge utile est de 4 zéros supplémentaires (00 00).
Actions recommandées
Les actions énumérées dans cette section ont pour but de mieux cerner le problème.
Action 1. Prendre des captures supplémentaires, y compris des captures aux points d'extrémité, et si possible, essayer d'appliquer la méthode diviser et conquérir pour isoler la source de la corruption de paquets, 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 montre la topologie :
Flux affecté :
IP Src : 192.168.1.81
Adresse IP de destination : 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 énumérées dans cette section ont pour but de mieux cerner le problème.
Action 1. Vérifiez la table de connexion FTD.
Pour vérifier une connexion spécifique, vous pouvez utiliser la syntaxe suivante :
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
Points clés :
- Les interfaces d'entrée et de sortie sont identiques (en U).
- Le nombre d'octets a une valeur significativement élevée (~5 Goytes).
- L'indicateur o indique le délestage de flux (débit accéléré matériel). C'est la raison pour laquelle les captures FTD n'affichent aucun paquet. Le délestage de flux n'est pris en charge que sur les plates-formes 41xx et 93xx. Dans ce cas, le périphérique est un 41xx.
Action 2. Prenez 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é sur l'image :
Après quelques secondes :
Avant :
Après :
Points clés :
- 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 de la microseconde. Cela indique un débit de paquets très élevé.
- La valeur TTL (Time to Live) diminue continuellement. Ceci indique une boucle de paquet.
Action 3. Utilisez packet-tracer.
Puisque les paquets ne traversent pas le moteur LINA du pare-feu, vous ne pouvez pas effectuer de trace en direct (capture w/trace), mais vous pouvez tracer 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
Action 4. Confirmez le routage FTD.
Vérifiez la table de routage du pare-feu pour voir s’il y a 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
Points clés :
- La route pointe vers l’interface de sortie correcte.
- La route a été apprise il y a quelques minutes (0:02:37).
Mesure 5. Confirmez la disponibilité de la connexion.
Vérifiez le temps de disponibilité de la connexion pour voir 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 6. Effacez la connexion existante.
Dans ce cas, les paquets correspondent à une connexion établie et sont acheminés vers une interface de sortie incorrecte, ce qui entraîne 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 NAT ONU (destination NAT) a priorité sur 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 console UDP est de 2 minutes), il est nécessaire de supprimer 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 no 7. Configurez le délai d'attente conn flottant.
Il s'agit de la solution appropriée pour résoudre le problème et éviter le routage sous-optimal, en particulier pour les flux UDP. Accédez à Périphériques > Paramètres de la plate-forme > Délais d'attente et définissez la valeur :
Pour plus d'informations sur le délai d'attente conn flottant, reportez-vous à la référence des commandes :
Cas 9 . Problème de connectivité HTTPS (scénario 1)
Description du problème : Impossible d'établir la communication HTTPS entre le client 192.168.201.105 et le serveur 192.168.202.101
Cette image montre la topologie :
Flux affecté :
IP Src : 192.168.201.111
Adresse IP de destination : 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 prise sur l'interface INSIDE du pare-feu de nouvelle génération :
Points clés :
- Il existe une connexion TCP en trois étapes.
- La négociation SSL commence. Le client envoie un message Hello client.
- Un ACK TCP est envoyé au client.
- Une taxe TCP RST est envoyée au client.
Cette image montre la capture prise sur l'interface externe de NGFW.
Points clés :
- 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.
- Une taxe TCP RST est envoyée au serveur.
Actions recommandées
Les actions énumérées dans cette section ont pour but de mieux cerner le problème.
Action 1. Prendre des captures supplémentaires.
Une capture prise sur le serveur révèle que le serveur a reçu les paquets Hello du client TLS avec une somme de contrôle TCP corrompue et les abandonne silencieusement (il n'y a pas de paquet de réponse TCP RST ou autre vers le client) :
Lorsque vous mettez tout ensemble :
Dans ce cas, pour comprendre ce qui se passe, il est nécessaire d'activer sur Wireshark l'option Valider la somme de contrôle TCP si possible. Accédez à Edition > Préférences > Protocoles > TCP, comme illustré dans l'image.
Dans ce cas, il est utile de mettre les captures côte à côte afin d'obtenir la vue d'ensemble :
Points clés :
- Il existe une connexion TCP en trois étapes. Les ID IP sont identiques. Cela signifie que le flux n'a pas été propagé par le pare-feu.
- Un Hello client TLS provient du client avec l'ID IP 12083. Le paquet est 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 remplacé par 52534. En outre, la somme de contrôle TCP du paquet est corrompue (en raison d'un défaut logiciel qui a ensuite été corrigé).
- Le pare-feu est en mode Proxy TCP et envoie un ACK au client (usurpation du serveur).
- Le pare-feu ne reçoit aucun paquet TCP ACK du serveur et retransmet le message Hello du client TLS. Ceci est à nouveau dû au mode Proxy TCP activé par le pare-feu.
- Après environ 30 secondes, le pare-feu abandonne et envoie une taxe TCP RST au client.
- Le pare-feu envoie un TCP RST vers le serveur.
Pour référence :
Traitement des échanges 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 montre la topologie :
Flux affecté :
IP Src : 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. Une fois le message d'erreur affiché, 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 (Suivre > Flux TCP), comme indiqué dans l'image.
Points clés :
- Il existe une connexion TCP en trois étapes.
- Le client (FMC) envoie un message Hello du client SSL vers le portail de gestion des licences Smart.
- 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 Hello, Certificate and Server Hello Done du serveur.
- Le client envoie une alerte fatale SSL se plaignant d'une 'CA inconnue'.
- Le client envoie une requête RST TCP pour fermer la session.
- La durée totale de la session TCP (de l'établissement à la fermeture) était de ~0,5 sec.
Sélectionnez le certificat du serveur et développez le champ émetteur pour afficher le commonName. Dans ce cas, le Common Name (Nom commun) indique un périphérique qui fait appel à la technologie Man-in-the-Middle (MITM).
Ceci est illustré dans cette image :
Actions recommandées
Les actions énumérées dans cette section ont pour but de mieux cerner le problème.
Action 1. Prendre des captures supplémentaires.
Prendre des captures sur le périphérique de pare-feu de transit :
CAPI affiche :
CAPO montre :
Ces captures prouvent que le pare-feu de transit modifie le certificat de serveur (MITM)
Action 2. Vérifiez les journaux du périphérique.
Vous pouvez collecter le bundle 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 correctement dans le cloud Smart Licensing.
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 (les hôtes situés derrière l'interface OUTSIDE du pare-feu).
Cette image montre la topologie :
Flux affecté :
IP Src : fc00:1:1:1::100
Adresse IP de destination : fc00:1:1:2::2
Protocole : tous les modèles
Analyse de capture
Activez 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é prises 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 :
Points clés :
- Le routeur envoie un message de sollicitation de voisin IPv6 demandant l'adresse MAC du périphérique en amont (IP fc00:1:1:1::1).
- Le pare-feu répond par 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 demandant l'adresse MAC du périphérique en aval (fc00:1:1:1::100).
- Le routeur répond par une annonce de voisin IPv6.
- Le routeur envoie des requêtes d'écho IPv6 supplémentaires.
La capture sur l'interface OUTSIDE du pare-feu contient :
Points clés :
- Le pare-feu envoie un message de sollicitation de voisin IPv6 demandant l'adresse MAC du périphérique en amont (IP fc00:1:1:2::2).
- Le routeur répond par 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 demandant l'adresse MAC de l'adresse IPv6 fc00:1:1:1::100.
- Le pare-feu envoie une requête d'écho IPv6 supplémentaire.
- Le routeur en amont envoie un message supplémentaire de sollicitation de voisin IPv6 demandant 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 il demande plutôt l'adresse fc00:1:1:1::100. Ceci indique une mauvaise configuration.
Actions recommandées
Les actions énumérées dans cette section ont pour but de mieux cerner le problème.
Action 1. Vérifiez la table de voisinage IPv6.
La table de voisinage IPv6 du pare-feu est correctement renseignée.
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.
Il s'agit de 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 une mauvaise 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
Le changement de 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 demandant l'adresse MAC du périphérique en amont (IP fc00:1:1:1::1).
- Le pare-feu répond par une annonce de voisin IPv6.
- Le routeur envoie des requêtes d’écho ICMP et reçoit des réponses d’écho.
Contenu CAPO :
Points clés :
- Le pare-feu envoie un message de sollicitation de voisin IPv6 demandant l'adresse MAC du périphérique en amont (IP fc00:1:1:2::2).
- Le pare-feu répond par 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 demandant l'adresse MAC du périphérique en aval (IP fc00:1:1:1::1).
- Le pare-feu répond par 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é intermittente (Empoisonnement ARP)
Description du problème : Les hôtes internes (192.168.0.x/24) ont des problèmes de connectivité intermittents avec les hôtes du même sous-réseau
Cette image montre la topologie :
Flux affecté :
IP Src : 192.168.0.x/24
Adresse IP de destination : 192.168.0.x/24
Protocole : tous les modèles
Le cache ARP d’un hôte interne semble empoisonné :
Analyse de capture
Activer la capture sur le moteur FTD LINA
Cette capture capture capture uniquement 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.
Points clés :
- Le pare-feu reçoit différentes requêtes ARP pour les adresses IP dans le réseau 192.168.0.x/24
- Le pare-feu répond à tous (proxy-ARP) avec sa propre adresse MAC
Actions recommandées
Les actions énumérées dans cette section ont pour but de mieux cerner le problème.
Action 1. Vérifiez la configuration NAT.
Selon la configuration NAT, il y a des cas où le mot clé no-proxy-arp peut empêcher le comportement ci-dessus :
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, pensez à désactiver le proxy ARP sur l'interface elle-même. En cas de FTD, au moment de la rédaction de cet article, vous devrez utiliser FlexConfig et déployer la commande suivante (spécifiez le nom d'interface approprié).
sysopt noproxyarp INSIDE
Cas 13 . Identifier les identificateurs d'objet SNMP (OID) qui provoquent des bogues de CPU
Ce cas montre comment certains OID SNMP pour l'interrogation de la mémoire ont été identifiés comme la cause première des problèmes de performances du processeur (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 ne cessent d'augmenter. Un dépannage plus approfondi a révélé qu'il existe également des bogues de CPU (causés par le processus SNMP) qui sont la cause première des dépassements d'interface.
L'étape suivante du processus de dépannage a consisté à identifier la cause première des bogues du processeur causés par le processus SNMP et, en particulier, à réduire la portée du problème pour identifier les identificateurs d'objet SNMP (OID) qui, une fois interrogés, pourraient potentiellement entraîner des bogues du processeur.
Actuellement, le moteur FTD LINA ne fournit pas de commande show pour les OID SNMP 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 a eu les facteurs de limitation suivants :
- L'administrateur FTD n'avait pas accès à l'outil de surveillance SNMP
- SNMP version 3 avec authentification et chiffrement 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 chiffrement des données, ce plan d'action a été proposé :
- Prendre des captures de 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échiffré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
Points clés :
- Adresses/ports source et de destination SNMP.
- Impossible de décoder l'unité de données de protocole SNMP, car le paramètre privKey est inconnu de Wireshark.
- Valeur de la primitive de cryptagePDU.
Actions recommandées
Les actions énumérées dans cette section ont pour but de mieux cerner le problème.
Action 1 : déchiffrement des captures SNMP
Enregistrez les captures et modifiez 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.
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 accédez à Protocol Preferences > Users Table, comme illustré dans l'image :
Dans le tableau Utilisateurs SNMP, le nom d'utilisateur SNMP version 3, le modèle d'authentification, le mot de passe d'authentification, le protocole de confidentialité et le mot de passe de confidentialité 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é des PDU SNMP déchiffrées :
Points clés :
- 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 par une réponse get contenant des OID liés au 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 illustré sur l'image :
Afin d'afficher les OID au format lisible par l'homme dans Wireshark, procédez comme suit :
- Téléchargez la MIB CISCO-ENHANCED-MEMPOOL-MIB et ses dépendances, comme illustré sur l'image :
2. Dans Wireshark dans Edit > Preferences > Name Resolution la case Enable OID Resolution est cochée. Dans la fenêtre SMI (chemins MIB et PIB), spécifiez le dossier contenant les MIB téléchargés et dans SMI (modules MIB et PIB). 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 du résultat décrypté du fichier de capture, l'outil de surveillance SNMP a été interrogé périodiquement (intervalle de 10 secondes) sur l'utilisation des pools de mémoire sur le FTD. Comme expliqué dans l'article TechNote, l'interrogation SNMP ASA pour les statistiques liées à la mémoire interroge l'utilisation du pool partagé global (GSP) à l'aide de SNMP donne des résultats de bogues CPU. Dans ce cas, à partir des captures, il était clair que l'utilisation du pool partagé global a été interrogée périodiquement dans le cadre de la primitive getBulkRequest SNMP.
Afin de réduire au minimum les bogues du processeur causés par le processus SNMP, il a été recommandé de suivre les étapes d'atténuation pour les bogues du processeur pour SNMP mentionnés dans l'article et d'éviter d'interroger les OID liés au GSP. Sans l'interrogation SNMP pour les OID qui se rapportent au GSP, aucun bogue CPU causé par le processus SNMP n'a été observé et le taux de dépassements a diminué de manière significative.
Informations connexes
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)