Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
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.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
En outre, avant de commencer à analyser les captures de paquets, il est vivement conseillé de respecter ces exigences :
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
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.
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.
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.
Sur la base de l'architecture illustrée, les captures FTD peuvent être prises en 3 endroits différents :
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).
Note: Les captures au niveau du châssis FXOS sont uniquement disponibles sur les plates-formes FP41xx et FP93xx. FP1xxx et FP21xx ne fournissent pas cette fonctionnalité.
Principaux points de capture :
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 :
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 :
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
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 :
La capture prise sur l'interface externe du pare-feu de nouvelle génération est illustrée ici :
Points clés :
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 :
Sur la base des 2 captures, on peut conclure que :
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
Astuce : Si le contenu du paquet ne vous intéresse pas, vous pouvez capturer uniquement les en-têtes de paquet (option en-têtes uniquement). Cela vous permet de capturer beaucoup plus de paquets dans le tampon de capture. En outre, vous pouvez augmenter la taille du tampon de capture (par défaut 500 Ko) à une valeur maximale de 32 Mo (option de tampon). Enfin, à partir de la version 6.3 de FTD, l'option de taille de fichier vous permet de configurer un fichier de capture jusqu'à 10 Go d'octets. Dans ce cas, vous ne pouvez voir le contenu de capture que dans un format pcap.
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 :
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 :
Vous pouvez le visualiser sur l'image ici :
Note: Puisque toutes les interfaces FTD ont un niveau de sécurité de 0, l'ordre des interfaces dans la sortie show conn est basé sur le numéro d'interface. Plus précisément, l'interface avec vpif-num supérieur (numéro d'interface de la plate-forme virtuelle) est sélectionnée comme interne tandis que l'interface avec vpif-num inférieur est sélectionnée comme externe. Vous pouvez voir la valeur vpif de l'interface à l'aide de la commande show interface detail. Amélioration connexe, CSCvi15290 ENH : FTD doit afficher la directionnalité de connexion dans la sortie 'show conn' de FTD
firepower# show interface detail | i Interface number is|Interface [P|E].*is up ... Interface Ethernet1/2 "INSIDE", is up, line protocol is up Interface number is 19 Interface Ethernet1/3.202 "OUTSIDE", is up, line protocol is up Interface number is 20 Interface Ethernet1/3.203 "DMZ", is up, line protocol is up Interface number is 22
Note: Depuis la version 6.5 du logiciel Firepower, ASA version 9.13.x, les sorties de la commande show conn long et show conn detail fournissent des informations sur l'initiateur et le répondeur de connexion
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
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. |
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
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 :
Cette image montre la capture de CAPO dans Wireshark :
Points clés :
Sur la base des 2 captures, on peut conclure que :
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 :
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 :
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 ?).
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
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.
Le pare-feu capture CAPI et CAPO contenant les mêmes paquets, comme l'illustre l'image.
Points clés :
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 :
La capture sur le serveur montre le problème. L’ACK client de la connexion TCP en trois étapes n’est jamais arrivé :
Le pare-feu capture CAPI et CAPO contenant les mêmes paquets, comme l'illustre l'image.
Points clés :
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).
Identique au cas 3.1
Le pare-feu capture CAPI et CAPO contenant les mêmes paquets, comme l'illustre l'image.
Points clés :
Sur la base de ces captures, on peut conclure que :
Identique au cas 3.1
Les deux pare-feu capturent CAPI et CAPO contiennent ces paquets, comme le montre l'image.
Points clés :
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.
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
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 même flux dans la capture CAPO contient :
Points clés :
Sur la base des deux captures, on peut conclure que :
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 :
Vous pouvez le visualiser comme suit :
Action 2. Vérifiez le routage entre le client et le pare-feu.
Confirmez que :
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) ...
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 :
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)
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
Avertissement : Les captures LINA sur les captures FP1xxx et FP21xx affectent le taux de transfert du trafic qui passe par le FTD. N'activez pas les captures LINA sur les plates-formes FP1xxx et FP21xxx lorsque vous dépannez des problèmes de performances (transfert lent via le FTD). À la place, utilisez SPAN ou un périphérique de prise matérielle en plus des captures sur les hôtes source et de destination. Le problème est documenté dans CSCvo30697 .
firepower# capture CAPI type raw-data trace interface inside match icmp any any WARNING: Running packet capture can have an adverse impact on performance.
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).
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
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
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 :
Astuce : Enregistrez les captures lorsque vous naviguez jusqu'à Fichier > Exporter les paquets spécifiés. Ensuite, enregistrez uniquement la plage de paquets Affiché
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 :
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 :
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 :
(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 :
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 :
Que signifient les accusés de réception en double ?
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
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 :
Cette image montre la topologie :
Flux affecté :
IP Src : 192.168.21.193
Adresse IP de destination : 192.168.14.250
Protocole : TCP 80
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 :
Captures - Scénario non fonctionnel :
Le contenu de capture d'entrée (CAPI).
Points clés :
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) :
Vérifiez le paquet mal formé :
Points clés :
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.
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
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
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 :
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 :
Astuce : Dans Wireshark, excluez les paquets étiquetés VN pour éliminer la duplication des paquets au niveau de l’interface physique
Avant :
Après :
Points clés :
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 :
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é :
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 :
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 :
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)
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 :
Cette image montre la capture prise sur l'interface externe de NGFW.
Points clés :
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 :
Pour référence :
Traitement des échanges TLS/SSL Firepower
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)
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 :
Astuce : Afin de rechercher toutes les nouvelles sessions TCP capturées, utilisez le filtre d'affichage tcp.flags==0x2 sur Wireshark. Cela filtre tous les paquets SYN TCP capturés.
Astuce : Appliquer en tant que colonne le champ Nom du serveur à partir du client SSL Hello.
Astuce : Appliquer ce filtre d'affichage pour afficher uniquement les messages Hello du client ssl.handshake.type == 1
Note: Au moment de la rédaction du présent document, le portail Smart Licensing (tools.cisco.com) utilise les adresses IP suivantes : 72.163.4.38, 173.37.145.8
Suivez l'un des flux TCP (Suivre > Flux TCP), comme indiqué dans l'image.
Points clés :
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 :
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.
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
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 :
La capture sur l'interface OUTSIDE du pare-feu contient :
Points clés :
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.
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é :
Contenu CAPO :
Points clés :
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é :
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 :
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
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 :
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é :
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 :
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 :
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 :
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.