Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Informations générales

Comment collecter et exporter des captures sur la gamme de produits NGFW ?

Collecter les captures FXOS

Activer et collecter les captures Lina FTD

Activer et collecter les captures FTD Snort

Dépannage

Cas 1 . Pas de SYN TCP sur l'interface de sortie

Analyse de capture

Actions recommandées

Synthèse des causes possibles et des actions recommandées

Cas 2 . TCP SYN du client, TCP RST du serveur

Analyse de capture

Actions recommandées

Cas 3 . Connexion TCP en trois étapes + RST à partir d'un terminal

Analyse de capture

3.1 - Connexion TCP en trois étapes + RST différé du client

Actions recommandées

3.2 - Connexion TCP en trois étapes + FIN/ACK retardé du client + RST retardé du serveur

Actions recommandées

3.3 - Connexion TCP en trois étapes + RST différé du client

Actions recommandées

3.4 - Connexion TCP en trois étapes + RST immédiat à partir du serveur

Actions recommandées

Cas 4 . TCP RST à partir du client

Analyse de capture

Actions recommandées

Cas 5 . Transfert TCP lent (scénario 1)

Scénario 1. Transfert lent

Analyse de capture

Actions recommandées

Scénario 2. Transfert rapide

Cas 6 . Transfert TCP lent (scénario 2)

Analyse de capture

Actions recommandées

Exportez la capture pour vérifier la différence de temps entre les paquets d'entrée et de sortieCas 7. Problème de connectivité TCP (corruption de paquet)

Analyse de capture

Actions recommandées

Cas 8 . Problème de connectivité UDP (paquets manquants)

Analyse de capture

Actions recommandées

Analyse de capture

Actions recommandées

Cas 10 . Problème de connectivité HTTPS (scénario 2)

Analyse de capture

Actions recommandées

Analyse de capture

Actions recommandées

Cas 12 . Problème de connectivité intermittent (empoisonnement ARP)

Analyse de capture

Actions recommandées

Cas 13 . Identifier les identificateurs d'objet SNMP (OID) qui provoquent des erreurs de CPU

Analyse de capture

Actions recommandées

Informations connexes

Introduction

Ce document décrit diverses techniques d’analyse de capture de paquets qui visent à dépanner efficacement les problèmes de réseau.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

- Architecture de plate-forme Firepower

- Journaux NGFW

- traceur de paquets de pare-feu de nouvelle génération

En outre, avant de commencer à analyser les captures de paquets, il est vivement conseillé de respecter les exigences suivantes :

- Connaître le fonctionnement du protocole - Ne commencez pas à vérifier une capture de paquets si vous ne comprenez pas le fonctionnement du protocole capturé.

- Connaître la topologie - Vous devez connaître les périphériques de transit de bout en bout. Si cela n'est pas possible, vous devez au moins connaître les périphériques en amont et en aval.

- Connaître l'appliance : vous devez savoir comment votre périphérique gère les paquets, quelles sont les interfaces impliquées (entrée/sortie), quelle est l'architecture du périphérique et quels sont les différents points de capture.

- Connaître la configuration - Vous devez savoir comment un flux de paquets est censé être géré par le périphérique en termes de :

- Interface de routage/sortie

- Stratégies appliquées

- Traduction d'adresses réseau (NAT)

- Connaître les outils disponibles - En plus des captures, il est recommandé d'être prêt à appliquer d'autres outils et techniques (comme la journalisation et les traceurs) et, si nécessaire, de les corréler avec les paquets capturés.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

- La plupart des scénarios sont basés sur FP4140 exécutant le logiciel FTD 6.5.x.

- FMC exécutant le logiciel 6.5.x.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

La capture de paquets est l’un des outils de dépannage les plus négligés actuellement disponibles. Le TAC Cisco résout quotidiennement de nombreux problèmes liés à l'analyse des données capturées.

L'objectif de ce document est d'aider les ingénieurs réseau et de sécurité à identifier et à dépanner les problèmes réseau courants, principalement en se basant sur l'analyse de capture de paquets.

Tous les scénarios présentés dans ce document sont basés sur des cas réels d'utilisateurs observés dans le centre d'assistance technique de Cisco (TAC).

Le document couvre les captures de paquets du point de vue du pare-feu de nouvelle génération Cisco (NGFW), mais les mêmes concepts s'appliquent également à d'autres types de périphériques.

Comment collecter et exporter des captures sur la gamme de produits NGFW ?

Dans le cas d'un appareil Firepower (1xxx, 21xx, 41xx, 93xx) et d'une application Firepower Threat Defense (FTD), un traitement de paquets peut être visualisé comme illustré dans l'image.

1. Un paquet entre dans l'interface d'entrée et est géré par le commutateur interne du châssis.

2. Le paquet entre dans le moteur Lina FTD qui effectue principalement des vérifications L3/L4.

3. Si la politique exige que le paquet soit inspecté par le moteur Snort (principalement inspection L7).

4. Le moteur Snort renvoie un verdict pour le paquet.

5. Le moteur LINA abandonne ou transfère le paquet en fonction du verdict du renifleur.

6. Le paquet sort du châssis par le commutateur interne du châssis.

Sur la base de l'architecture illustrée, les captures FTD peuvent être effectuées à trois (3) endroits différents :

- FXOS

- moteur FTD Lina

- Moteur FTD Snort

Collecter les captures FXOS

Le processus est décrit dans ce document :

https://www.cisco.com/c/en/us/td/docs/security/firepower/fxos/fxos271/web-guide/b_GUI_FXOS_ConfigGuide_271/troubleshooting.html#concept_E8823CC63C934A909BBC0DF12F301DED

Les captures FXOS ne peuvent être prises que dans la direction d'entrée à partir du point de vue du commutateur interne sont montrées dans l'image ici.

Dans le cas présent, il s'agit de deux points de capture par direction (en raison de l'architecture interne du commutateur).

Les paquets capturés aux points 2, 3 et 4 ont une étiquette de réseau virtuel (VNTag).

Remarque : les captures au niveau du châssis FXOS sont uniquement disponibles sur les plates-formes FP41xx et FP93xx. Les modèles FP1xxx et FP21xx n'offrent pas cette fonctionnalité.

Activer et collecter les captures Lina FTD

Principaux points de capture :

- Interface d'entrée

- Interface de sortie

- Chemin de sécurité accéléré (ASP)

Vous pouvez utiliser l'interface utilisateur FMC (Firepower Management Center User Interface) ou l'interface de ligne de commande FTD pour activer et collecter les captures FTD Lina.

Activez la capture à partir de l'interface CLI sur l'interface INSIDE :

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

Cette capture correspond au trafic entre les adresses IP 192.168.103.1 et 192.168.101.1 dans les deux directions.

Activez la capture ASP pour voir tous les paquets abandonnés par le moteur FTD Lina :

firepower# capture ASP type asp-drop all

Exporter une capture FTD Lina vers un serveur FTP :

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

Exportez une capture FTD Lina vers un serveur TFTP :

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

À partir de la version FMC 6.2.x, vous pouvez activer et collecter les captures FTD Lina à partir de l'interface utilisateur FMC.

Voici une autre façon de collecter des captures FTD à partir d'un pare-feu géré par FMC.

Étape 1

Dans le cas d'une capture LINA ou ASP, copiez la capture sur le disque FTD.

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

Source capture name [capin]?

Destination filename [capin.pcap]?

!!!!

Étape 2

Accédez au mode expert, localisez la capture enregistrée et copiez-la dans /ngfw/var/common :

firepower#

Console connection detached.

> expert

admin@firepower:~$ sudo su

Password:

root@firepower:/home/admin# cd /mnt/disk0

root@firepower:/mnt/disk0# ls -al | grep pcap

-rwxr-xr-x 1 root root     24 Apr 26 18:19 CAPI.pcap

-rwxr-xr-x 1 root root  30110 Apr  8 14:10 capin.pcap

-rwxr-xr-x 1 root root   6123 Apr  8 14:11 capin2.pcap

root@firepower:/mnt/disk0# cp capin.pcap /ngfw/var/common

Étape 3

Connectez-vous au FMC qui gère le FTD et accédez à Périphériques > Gestion des périphériques. Localisez le périphérique FTD et sélectionnez l'icône Troubleshoot :

Étape 4

Sélectionnez Dépannage avancé :

Spécifiez le nom du fichier de capture et sélectionnez Télécharger :

Pour plus d'exemples sur la façon d'activer/collecter des captures à partir de l'interface utilisateur FMC, consultez ce document :

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

Activer et collecter les captures FTD Snort

Le point de capture est illustré dans l'image ci-contre.

Activer la capture de niveau Snort :

> capture-traffic

Please choose domain to capture traffic from:

0 - br1

1 - Router

Selection? 1

Please specify tcpdump options desired.

(or enter '?' for a list of supported options)

Options: -n host 192.168.101.1

Pour écrire la capture dans un fichier nommé capture.pcap et la copier via FTP sur un serveur distant :

> capture-traffic

Please choose domain to capture traffic from:

0 - br1

1 - Router

Selection? 1

Please specify tcpdump options desired.

(or enter '?' for a list of supported options)

Options: -w capture.pcap host 192.168.101.1

CTRL + C <- to stop the capture

> file copy 10.229.22.136 ftp / capture.pcap

Enter password for ftp@10.229.22.136:

Copying capture.pcap

Copy successful.

>

Pour plus d'exemples de capture de niveau Snort qui incluent différents filtres de capture, consultez ce document :

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

Dépannage

Cas 1 . Pas de SYN TCP sur l'interface de sortie

La topologie est illustrée dans l'image ci-dessous :

Description du problème : HTTP ne fonctionne pas

Flux affecté :

Adresse IP source : 192.168.0.100

Adresse IP de destination : 10.10.1.100

Protocole : TCP 80

Analyse de capture

Activez les captures sur le moteur FTD LINA :

firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100

firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100

Captures - Scénario fonctionnel :

En tant que base, il est toujours très utile de disposer de captures à partir d'un scénario fonctionnel.

Capture prise sur l'interface INSIDE du pare-feu de nouvelle génération, comme illustré dans l'image :

Principaux points :

1. Connexion TCP en trois étapes.

2. Échange de données bidirectionnel.

3. Aucun délai entre les paquets (en fonction de la différence de temps entre les paquets).

4. L'adresse MAC source est le périphérique en aval correct.

Capture prise sur l'interface NGFW OUTSIDE, est montré dans l'image ici :

Principaux points :

1. Mêmes données que dans la capture CAPI.

2. L'adresse MAC de destination est le périphérique en amont correct.

Captures - Scénario non fonctionnel

À partir de l'interface de ligne de commande du périphérique, les captures ressemblent à ceci :

firepower# show capture

capture CAPI type raw-data interface INSIDE [Capturing - 484 bytes]

match ip host 192.168.0.100 host 10.10.1.100

capture CAPO type raw-data interface OUTSIDE [Capturing - 0 bytes]

match ip host 192.168.0.100 host 10.10.1.100

Contenu CAPI :

firepower# show capture CAPI

6 packets captured

1: 11:47:46.911482   192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

2: 11:47:47.161902   192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

3: 11:47:49.907683   192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

4: 11:47:50.162757   192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

5: 11:47:55.914640   192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,nop,sackOK>

6: 11:47:56.164710   192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,nop,sackOK>

firepower# show capture CAPO

0 packet captured

0 packet shown

Voici l'image de la capture CAPI dans Wireshark :

Principaux points :

1. Seuls les paquets TCP SYN sont visibles (pas de connexion TCP en trois étapes).

2. Il est impossible d’établir 2 sessions TCP (ports source 3171 et 3172). Le client source renvoie les paquets TCP SYN. Ces paquets retransmis sont identifiés par Wireshark comme des retransmissions TCP.

3. Les retransmissions TCP ont lieu toutes les ~3 puis 6 secondes, etc.

4. L'adresse MAC source provient du périphérique en aval correct.

Sur la base des deux captures, on peut conclure que :

- Un paquet d'un 5-tuple spécifique (IP src/dst, port src/dst, protocole) arrive sur le pare-feu sur l'interface attendue (INSIDE).

- Un paquet ne quitte pas le pare-feu sur l'interface attendue (OUTSIDE).

Actions recommandées

Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.

Action 1. Vérifiez la trace d'un paquet émulé.

Utilisez l'outil packet-tracer pour voir comment un paquet est censé être traité par le pare-feu. Si le paquet est abandonné par la politique d'accès du pare-feu, la trace du paquet émulé ressemble à ce résultat :

firepower# packet-tracer input INSIDE tcp 192.168.0.100 11111 10.10.1.100 80

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 3

Type: ROUTE-LOOKUP

Subtype: Resolve Egress Interface

Result: ALLOW

Config:

Additional Information:

found next-hop 192.168.2.72 using egress ifc  OUTSIDE

Phase: 4

Type: ACCESS-LIST

Subtype: log

Result: DROP

Config:

access-group CSM_FW_ACL_ global

access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268439946 event-log flow-start

access-list CSM_FW_ACL_ remark rule-id 268439946: ACCESS POLICY: FTD_Policy - Default

access-list CSM_FW_ACL_ remark rule-id 268439946: L4 RULE: DEFAULT ACTION RULE

Additional Information:

Result:

input-interface: INSIDE

input-status: up

input-line-status: up

output-interface: OUTSIDE

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x00005647a4f4b120 flow (NA)/NA

Action 2. Vérifiez les traces des paquets actifs.

Activez le suivi des paquets pour vérifier comment les paquets TCP SYN réels sont traités par le pare-feu. Par défaut, seuls les 50 premiers paquets entrants sont suivis :

firepower# capture CAPI trace

Effacez la mémoire tampon de capture :

firepower# clear capture /all

Si le paquet est abandonné par la politique d'accès du pare-feu, la trace ressemble à ce résultat :

firepower# show capture CAPI packet-number 1 trace

6 packets captured

1: 12:45:36.279740       192.168.0.100.3630 > 10.10.1.100.80: S 2322685377:2322685377(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 3

Type: ROUTE-LOOKUP

Subtype: Resolve Egress Interface

Result: ALLOW

Config:

Additional Information:

found next-hop 192.168.2.72 using egress ifc  OUTSIDE

Phase: 4

Type: ACCESS-LIST

Subtype: log

Result: DROP

Config:

access-group CSM_FW_ACL_ global

access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268439946 event-log flow-start

access-list CSM_FW_ACL_ remark rule-id 268439946: ACCESS POLICY: FTD_Policy - Default

access-list CSM_FW_ACL_ remark rule-id 268439946: L4 RULE: DEFAULT ACTION RULE

Additional Information:

Result:

input-interface: INSIDE

input-status: up

input-line-status: up

output-interface: OUTSIDE

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x00005647a4f4b120 flow (NA)/NA

1 packet shown

Action 3. Vérifiez les journaux FTD Lina.

Pour configurer Syslog sur FTD via FMC, consultez ce document :

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

Il est fortement recommandé de configurer un serveur Syslog externe pour les journaux FTD Lina. Si aucun serveur Syslog distant n'est configuré, activez les journaux de mémoire tampon locale sur le pare-feu pendant le dépannage. La configuration du journal présentée dans cet exemple est un bon point de départ :

firepower# show run logging

…

logging enable

logging timestamp

logging buffer-size 1000000

logging buffered informational

Réglez le pager terminal sur 24 lignes afin de contrôler le pager terminal :

firepower# terminal pager 24

Effacez la mémoire tampon de capture :

firepower# clear logging buffer

Testez la connexion et vérifiez les journaux avec un filtre d'analyse. Dans cet exemple, les paquets sont abandonnés par la politique d'accès du pare-feu :

firepower# show logging | include 10.10.1.100

Oct 09 2019 12:55:51: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3696 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]

Oct 09 2019 12:55:51: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3697 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]

Oct 09 2019 12:55:54: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3696 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]

Oct 09 2019 12:55:54: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3697 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]

Mesure 4. Vérifiez que le pare-feu ASP abandonne.

Si vous suspectez que le paquet est abandonné par le pare-feu, vous pouvez voir les compteurs de tous les paquets abandonnés par le pare-feu au niveau logiciel :

firepower# show asp drop

Frame drop:

No route to host (no-route)                                                234

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

Last clearing: 07:51:52 UTC Oct 10 2019 by enable_15

Flow drop:

Last clearing: 07:51:52 UTC Oct 10 2019 by enable_15

Vous pouvez activer les captures pour afficher toutes les pertes de niveau logiciel ASP :

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

Conseil : si vous n'êtes pas intéressé par le contenu du paquet, 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 la mémoire tampon de capture. En outre, vous pouvez augmenter la taille de la mémoire tampon de capture (par défaut, elle est de 500 Ko) jusqu'à une valeur de 32 Mo (option de mémoire tampon). Enfin, à partir de la version FTD 6.3, l'option file-size vous permet de configurer un fichier de capture jusqu'à 10 Go. Dans ce cas, vous ne pouvez voir le contenu de la capture qu'au 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 l'abandon n'est pas mentionnée dans la capture ASP. N’oubliez pas qu’un paquet ne peut être suivi qu’à un seul endroit (interface d’entrée ou abandon ASP). Dans ce cas, il est recommandé de prendre plusieurs abandons ASP et de définir une raison d'abandon ASP spécifique. Voici une approche recommandée :

1. Effacez les compteurs d'abandon ASP actuels :

firepower# clear asp drop

2. Envoyez le flux que vous dépannez via le pare-feu (exécutez un test).

3. Vérifiez à nouveau les compteurs de dépôt ASP et notez ceux qui ont augmenté.

firepower# show asp drop

Frame drop:

No route to host (no-route)                                                234

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

4. Activez la ou les captures ASP pour les abandons spécifiques affichés :

firepower# capture ASP_NO_ROUTE type asp-drop no-route

firepower# capture ASP_ACL_DROP type asp-drop acl-drop

5. Envoyez le flux que vous dépannez via le pare-feu (exécutez un test).

6. Vérifiez les captures ASP. Dans ce cas, les paquets ont été abandonnés en raison d'une route absente :

firepower# show capture ASP_NO_ROUTE | include 192.168.0.100.*10.10.1.100

93: 07:53:52.381663   192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

95: 07:53:52.632337   192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

101: 07:53:55.375392   192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

102: 07:53:55.626386   192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

116: 07:54:01.376231   192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,nop,sackOK>

117: 07:54:01.626310   192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,nop,sackOK>

Action 5. Vérifiez la table de connexion FTD Lina.

Il peut y avoir des cas où vous vous attendez à ce que le paquet sorte de l'interface 'X', mais pour quelque raison que ce soit, il sort de l'interface 'Y'. La détermination de l'interface de sortie du pare-feu est basée sur cet ordre de fonctionnement :

1. Recherche de connexion établie

2. Recherche NAT (Network Address Translation) : la phase UN-NAT (destination NAT) est prioritaire sur la recherche PBR et la recherche de route.

3. Routage basé sur des politiques (PBR)

4. Recherche dans la table de routage

Pour vérifier la table de connexion FTD :

firepower# show conn

2 in use, 4 most used

Inspect Snort:

preserve-connection: 2 enabled, 0 in effect, 4 most enabled, 0 most in effect

TCP DMZ  10.10.1.100:80 INSIDE  192.168.0.100:11694, idle 0:00:01, bytes 0, flags aA N1

TCP DMZ  10.10.1.100:80 INSIDE  192.168.0.100:11693, idle 0:00:01, bytes 0, flags aA N1

Principaux points :

- Selon les indicateurs (Aa), la connexion est embryonnaire (semi-ouverte - seul TCP SYN a été vu par le pare-feu).

- En fonction des ports source/de destination, l'interface d'entrée est INSIDE et l'interface de sortie est DMZ.

Ceci peut être visualisé dans l'image ici :

Remarque : comme toutes les interfaces FTD ont un niveau de sécurité de 0, l'ordre des interfaces dans la sortie de show conn est basé sur le numéro d'interface. Plus précisément, l'interface avec le numéro vpif-num supérieur (numéro d'interface de plate-forme virtuelle) est sélectionnée comme interne, tandis que l'interface avec le numéro vpif-num inférieur est sélectionnée comme externe. Vous pouvez voir la valeur vpif de l'interface avec la commande show interface detail. Amélioration connexe, ID de bogue Cisco CSCvi15290 ENH : FTD affiche 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

Remarque : à partir de la version 6.5 du logiciel Firepower, ASA version 9.13.x, les résultats des commandes show conn long et show conn detail fournissent des informations sur l'initiateur et le répondeur de la connexion

Résultat 1 :

firepower# show conn long

...

TCP OUTSIDE: 192.168.2.200/80 (192.168.2.200/80) INSIDE: 192.168.1.100/46050 (192.168.1.100/46050), flags aA N1, idle 3s, uptime 6s, timeout 30s, bytes 0

Initiator: 192.168.1.100, Responder: 192.168.2.200

Connection lookup keyid: 228982375

Résultat 2 :

firepower# show conn detail

...

TCP OUTSIDE: 192.168.2.200/80 INSIDE: 192.168.1.100/46050,

flags aA N1, idle 4s, uptime 11s, timeout 30s, bytes 0

Initiator: 192.168.1.100, Responder: 192.168.2.200

Connection lookup keyid: 228982375

En outre, la commande show conn long affiche les IP NATed entre parenthèses dans le cas d'une traduction d'adresses réseau :

firepower# show conn long

...

TCP OUTSIDE: 192.168.2.222/80 (192.168.2.222/80) INSIDE: 192.168.1.100/34792 (192.168.2.150/34792), flags aA N1, idle 0s, uptime 0s, timeout 30s, bytes 0, xlate id 0x2b5a8a4314c0

Initiator: 192.168.1.100, Responder: 192.168.2.222

Connection lookup keyid: 262895

Mesure no 6. Vérifiez le cache ARP (Address Resolution Protocol) du pare-feu.

Si le pare-feu ne peut pas résoudre le saut suivant, il abandonne silencieusement le paquet d'origine (TCP SYN dans ce cas) et envoie continuellement des requêtes ARP jusqu'à ce qu'il résolve le saut suivant.

Afin de voir le cache ARP du pare-feu, utilisez la commande :

firepower# show arp

En outre, pour vérifier s’il existe des hôtes non résolus, vous pouvez utiliser la commande suivante :

firepower# show arp statistics

Number of ARP entries in ASA: 0

Dropped blocks in ARP: 84

Maximum Queued blocks: 3

Queued blocks: 0

Interface collision ARPs Received: 0

ARP-defense Gratuitous ARPS sent: 0

Total ARP retries: 182 < indicates a possible issue for some hosts

Unresolved hosts: 1 < this is the current status

Maximum Unresolved hosts: 2

Si vous souhaitez vérifier davantage l'opération ARP, vous pouvez activer une capture spécifique à ARP :

firepower# capture ARP ethernet-type arp interface OUTSIDE

firepower# show capture ARP

...

4: 07:15:16.877914       802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50

5: 07:15:18.020033       802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50

Dans ce résultat, le pare-feu (192.168.2.50) tente de résoudre le tronçon suivant (192.168.2.72), mais il n'y a pas de réponse ARP

Le résultat ci-dessous montre un scénario fonctionnel avec une résolution ARP appropriée :

firepower# show capture ARP

2 packets captured

1: 07:17:19.495595       802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50

2: 07:17:19.495946       802.1Q vlan#202 P0 arp reply 192.168.2.72 is-at 4c:4e:35:fc:fc:d8

2 packets shown

firepower# show arp

INSIDE 192.168.1.71 4c4e.35fc.fcd8 9

OUTSIDE 192.168.2.72 4c4e.35fc.fcd8 9

Si aucune entrée ARP n'est en place, la trace d'un paquet SYN TCP actif indique :

firepower# show capture CAPI packet-number 1 trace

6 packets captured

1: 07:03:43.270585       192.168.0.100.11997 > 10.10.1.100.80: S 4023707145:4023707145(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 3

Type: ROUTE-LOOKUP

Subtype: Resolve Egress Interface

Result: ALLOW

Config:

Additional Information:

found next-hop 192.168.2.72 using egress ifc  OUTSIDE

…

Phase: 14

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 4814, packet dispatched to next module

…

Phase: 17

Type: ROUTE-LOOKUP

Subtype: Resolve Egress Interface

Result: ALLOW

Config:

Additional Information:

found next-hop 192.168.2.72 using egress ifc  OUTSIDE

Result:

input-interface: INSIDE

input-status: up

input-line-status: up

output-interface: OUTSIDE

output-status: up

output-line-status: up

Action: allow

Comme vous pouvez le voir dans le résultat, la trace montre Action : allow même lorsque le saut suivant n'est pas accessible et que le paquet est silencieusement abandonné par le pare-feu ! Dans ce cas, l'outil Packet Tracer doit également être vérifié car il fournit une sortie plus précise :

firepower# packet-tracer input INSIDE tcp 192.168.0.100 1111 10.10.1.100 80

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 3

Type: ROUTE-LOOKUP

Subtype: Resolve Egress Interface

Result: ALLOW

Config:

Additional Information:

found next-hop 192.168.2.72 using egress ifc  OUTSIDE

…

Phase: 14

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 4816, packet dispatched to next module

…

Phase: 17

Type: ROUTE-LOOKUP

Subtype: Resolve Egress Interface

Result: ALLOW

Config:

Additional Information:

found next-hop 192.168.2.72 using egress ifc  OUTSIDE

Result:

input-interface: INSIDE

input-status: up

input-line-status: up

output-interface: OUTSIDE

output-status: up

output-line-status: up

Action: drop

Drop-reason: (no-v4-adjacency) No valid V4 adjacency, Drop-location: frame 0x00005647a4e86109 flow (NA)/NA

Dans les versions récentes d'ASA/Firepower, le message précédent a été optimisé pour :

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

Synthèse des causes possibles et des actions recommandées

Si vous ne voyez qu'un paquet TCP SYN sur les interfaces d'entrée, mais qu'aucun paquet TCP SYN n'est envoyé à partir de l'interface de sortie attendue, certaines causes possibles sont :

Cause possible

Actions recommandées

Le paquet est abandonné par la politique d'accès du pare-feu.

- Utilisez packet-tracer ou capture w/trace pour voir comment le pare-feu gère le paquet.

- Vérifiez les journaux du pare-feu.

- Vérifiez les abandons ASP du pare-feu (show asp drop ou capture type asp-drop).

- Vérifiez les événements de connexion FMC. Cela suppose que la journalisation est activée pour la règle.

Le filtre de capture est incorrect.

- Utilisez packet-tracer ou capture w/trace pour voir s'il y a une traduction NAT qui modifie l'IP source ou de destination. Dans ce cas, réglez votre filtre de capture.

- La sortie de la commande show conn long affiche les adresses IP NATed.

Le paquet est envoyé à une autre interface de sortie.

- Utilisez packet-tracer ou capture w/trace pour voir comment le pare-feu gère le paquet. Souvenez-vous de l'ordre des opérations concernant la détermination de l'interface de sortie, la connexion actuelle, l'UN-NAT, le PBR et la recherche dans la table de routage.

- Vérifiez les journaux du pare-feu.

- Vérifiez la table de connexion du pare-feu (show conn).

Si le paquet est envoyé à une interface incorrecte parce qu'il correspond à une connexion actuelle, utilisez la commande clear conn address et spécifiez le 5-tuple de la connexion que vous voulez effacer.

Il n'y a pas de route vers la destination.

- Utilisez packet-tracer ou capture w/trace pour voir comment le pare-feu gère le paquet.

- Vérifiez les abandons ASP du pare-feu (show asp drop) pour la raison de non-abandon de route.

Il n'y a aucune entrée ARP sur l'interface de sortie.

- Vérifiez le cache ARP du pare-feu (show arp).

- Utilisez packet-tracer pour voir s'il y a une contiguïté valide.

L'interface de sortie est désactivée.

Vérifiez le résultat de la commande show interface ip brief sur le pare-feu et vérifiez l'état de l'interface.

Cas 2 . TCP SYN du client, TCP RST du serveur

Cette image présente la topologie :

Description du problème : HTTP ne fonctionne pas

Flux affecté :

Adresse IP source : 192.168.0.100

Adresse IP de destination : 10.10.1.100

Protocole : TCP 80

Analyse de capture

Activez les captures sur le moteur FTD LINA.

firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100

firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100

Captures - Scénario non fonctionnel :

Voici à quoi ressemblent les captures à partir de l'interface de ligne de commande du périphérique :

firepower# show capture

capture CAPI type raw-data trace interface INSIDE [Capturing - 834 bytes]

match ip host 192.168.0.100 host 10.10.1.100

capture CAPO type raw-data interface OUTSIDE [Capturing - 878 bytes]

match ip host 192.168.0.100 host 10.10.1.100

Contenu CAPI :

firepower# show capture CAPI

1: 05:20:36.654217   192.168.0.100.22195 > 10.10.1.100.80: S 1397289928:1397289928(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

2: 05:20:36.904311   192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

3: 05:20:36.905043   10.10.1.100.80 > 192.168.0.100.22196: R 1850052503:1850052503(0) ack 2171673259 win 0

4: 05:20:37.414132   192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

5: 05:20:37.414803   10.10.1.100.80 > 192.168.0.100.22196: R 31997177:31997177(0) ack 2171673259 win 0

6: 05:20:37.914183   192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,nop,sackOK>

...

Contenu CAPO :

firepower# show capture CAPO

1: 05:20:36.654507   802.1Q vlan#202 P0 192.168.0.100.22195 > 10.10.1.100.80: S 2866789268:2866789268(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>

2: 05:20:36.904478   802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4785344:4785344(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>

3: 05:20:36.904997   802.1Q vlan#202 P0 10.10.1.100.80 > 192.168.0.100.22196: R 0:0(0) ack 4785345 win 0

4: 05:20:37.414269   802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4235354730:4235354730(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>

5: 05:20:37.414758   802.1Q vlan#202 P0 10.10.1.100.80 > 192.168.0.100.22196: R 0:0(0) ack 4235354731 win 0

6: 05:20:37.914305   802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4118617832:4118617832(0) win 8192 <mss 1380,nop,nop,sackOK>

Cette image montre la capture de CAPI dans Wireshark.

Principaux points :

1. La source envoie un paquet TCP SYN.

2. Un RST TCP est envoyé vers la source.

3. La source retransmet les paquets TCP SYN.

4. Les adresses MAC sont correctes (sur les paquets entrants, l'adresse MAC source appartient au routeur en aval, l'adresse MAC de destination appartient à l'interface INSIDE du pare-feu).

Cette image montre la capture de CAPO dans Wireshark :

Principaux points :

1. La source envoie un paquet TCP SYN.

2. Un RST TCP arrive sur l'interface OUTSIDE.

3. La source retransmet les paquets TCP SYN.

4. Les adresses MAC sont correctes (sur les paquets de sortie, le pare-feu OUTSIDE est l'adresse MAC source, le routeur en amont est l'adresse MAC de destination).

Sur la base des deux captures, on peut conclure que :

- La connexion TCP en trois étapes entre le client et le serveur n'est pas terminée

- Il y a un TCP RST qui arrive sur l'interface de sortie du pare-feu

- Le pare-feu « communique » avec les périphériques en amont et en aval appropriés (en fonction des adresses MAC)

Actions recommandées

Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.

Action 1. Vérifiez l'adresse MAC source qui envoie la RST TCP.

Vérifiez que l'adresse MAC de destination vue dans le paquet TCP SYN est identique à l'adresse MAC source vue dans le paquet TCP RST.

Cette vérification a pour but de confirmer 2 choses :

- Vérifiez qu'il n'y a pas de flux asymétrique.

- Vérifiez que l'adresse MAC appartient au périphérique en amont attendu.

Action 2. Comparer les paquets entrants et sortants.

Comparez visuellement les 2 paquets sur Wireshark pour vérifier que le pare-feu ne modifie pas/ne corrompt pas les paquets. Certaines différences attendues sont mises en évidence.

Principaux points :

1. Les horodatages sont différents. D'un autre côté, la différence doit être faible et raisonnable. Cela dépend des fonctions et des contrôles de stratégie appliqués au paquet ainsi que de la charge sur le périphérique.

2. La longueur des paquets diffère en particulier si un en-tête dot1Q est ajouté/supprimé par le pare-feu sur un seul côté.

3. Les adresses MAC sont différentes.

4. Un en-tête dot1Q peut être en place si la capture a été effectuée sur une sous-interface.

5. Les adresses IP sont différentes si la traduction d'adresses de port (PAT) ou la traduction d'adresses de port (NAT) est appliquée au paquet.

6. Les ports source ou de destination sont différents si la fonction NAT ou PAT est appliquée au paquet.

7. Si vous désactivez l'option Wireshark Relative Sequence Number, vous voyez que les numéros de séquence TCP/les numéros d'accusé de réception sont modifiés par le pare-feu en raison de la randomisation ISN (Initial Sequence Number).

8. Certaines options TCP peuvent être remplacées. Par exemple, le pare-feu modifie par défaut la taille maximale de segment (MSS) TCP sur 1380 afin d'éviter la fragmentation des paquets dans le chemin de transit.

Action 3. Effectuez une capture à destination.

Si possible, effectuez une capture à la destination elle-même. Si ce n'est pas possible, effectuez une capture aussi près que possible de la destination. L’objectif ici est de vérifier qui envoie la RST TCP (le serveur de destination ou un autre périphérique se trouve-t-il sur le chemin ?).

Cas 3 . Connexion TCP en trois étapes + RST à partir d'un terminal

Cette image présente la topologie :

Description du problème : HTTP ne fonctionne pas

Flux affecté :

Adresse IP source : 192.168.0.100

Adresse IP de destination : 10.10.1.100

Protocole : TCP 80

Analyse de capture

Activez les captures sur le moteur FTD LINA.

firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100

firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100

Captures - Scénario non fonctionnel :

Ce problème peut se manifester de deux façons différentes dans les captures.

3.1 - Connexion TCP en trois étapes + RST différé du client

Les captures CAPI et CAPO du pare-feu contiennent les mêmes paquets, comme illustré dans l'image.

Principaux points :

1. La connexion TCP en trois étapes passe par le pare-feu.

2. Le serveur retransmet le message SYN/ACK.

3. Le client retransmet l'accusé de réception.

4. Après environ 20 secondes, le client abandonne et envoie un RST TCP.

Actions recommandées

Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.

Action 1. Effectuez des captures aussi près que possible des deux terminaux.

Les captures du pare-feu indiquent que le serveur n'a pas traité l'ACK du client. Ceci est basé sur les faits suivants :

- Le serveur retransmet le message SYN/ACK.

- Le client retransmet l'accusé de réception.

- Le client envoie un RST TCP ou un FIN/ACK avant toute donnée.

La capture sur le serveur montre le problème. Le client ACK de la connexion TCP en trois étapes n'est jamais arrivé :

3.2 - Connexion TCP en trois étapes + FIN/ACK retardé du client + RST retardé du serveur

Les captures CAPI et CAPO du pare-feu contiennent les mêmes paquets, comme illustré dans l'image.

Principaux points :

1. La connexion TCP en trois étapes passe par le pare-feu.

2. Après ~5 secondes, le client envoie un FIN/ACK.

3. Après ~20 secondes, le serveur abandonne et envoie un RST TCP.

Sur la base de cette capture, on peut conclure que bien qu'il y ait une connexion TCP en trois étapes à travers le pare-feu, il semble qu'elle ne soit jamais réellement terminée sur un point d'extrémité (les retransmissions l'indiquent).

Actions recommandées

Identique au cas 3.1

3.3 - Connexion TCP en trois étapes + RST différé du client

Les captures CAPI et CAPO du pare-feu contiennent les mêmes paquets, comme illustré dans l'image.

Principaux points :

1. La connexion TCP en trois étapes passe par le pare-feu.

2. Après environ 20 secondes, le client abandonne et envoie un RST TCP.

Sur la base de ces captures, on peut conclure que :

- Après 5 à 20 secondes, un terminal abandonne et décide de mettre fin à la connexion.

Actions recommandées

Identique au cas 3.1

3.4 - Connexion TCP en trois étapes + RST immédiat à partir du serveur

Les captures CAPI et CAPO du pare-feu contiennent ces paquets, comme illustré dans l'image.

Principaux points :

1. La connexion TCP en trois étapes passe par le pare-feu.

2. Il y a un RST TCP du serveur quelques millisecondes après le paquet ACK.

Actions recommandées

Action : effectuez des captures aussi près que possible du serveur.

Un RST TCP immédiat provenant du serveur peut indiquer un serveur défaillant ou un périphérique sur le chemin qui envoie le RST TCP. Effectuez une capture sur le serveur lui-même et déterminez la source du RST TCP.

Cas 4 . TCP RST à partir du client

Cette image présente la topologie :

Description du problème : HTTP ne fonctionne pas.

Flux affecté :

Adresse IP source : 192.168.0.100

Adresse IP de destination : 10.10.1.100

Protocole : TCP 80

Analyse de capture

Activer les captures sur le moteur FTD LINA.

firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100

firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100

Captures - Scénario non fonctionnel :

Il s'agit du contenu CAPI.

firepower# show capture CAPI

14 packets captured

1: 12:32:22.860627   192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

2: 12:32:23.111307   192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

3: 12:32:23.112390   192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0

4: 12:32:25.858109   192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

5: 12:32:25.868698   192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0

6: 12:32:26.108118   192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

7: 12:32:26.109079   192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0

8: 12:32:26.118295   192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0

9: 12:32:31.859925   192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,nop,sackOK>

10: 12:32:31.860902   192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0

11: 12:32:31.875229   192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0

12: 12:32:32.140632   192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0

13: 12:32:32.159995   192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,nop,sackOK>

14: 12:32:32.160956   192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0

14 packets shown

Voici le contenu du CAPO :

firepower# show capture CAPO

11 packets captured

1: 12:32:22.860780   802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 1386249852:1386249852(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>

2: 12:32:23.111429   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 3000518857:3000518857(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>

3: 12:32:23.112405   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 3514091874:3514091874(0) win 0

4: 12:32:25.858125   802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 1386249852:1386249852(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>

5: 12:32:25.868729   802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: R 2968892337:2968892337(0) win 0

6: 12:32:26.108240   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 3822259745:3822259745(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>

7: 12:32:26.109094   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 40865466:40865466(0) win 0

8: 12:32:31.860062   802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 4294058752:4294058752(0) win 8192 <mss 1380,nop,nop,sackOK>

9: 12:32:31.860917   802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: R 1581733941:1581733941(0) win 0

10: 12:32:32.160102   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 4284301197:4284301197(0) win 8192 <mss 1380,nop,nop,sackOK>

11: 12:32:32.160971   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 502906918:502906918(0) win 0

11 packets shown

Les journaux du pare-feu affichent :

firepower# show log | i 47741

Oct 13 2019 13:57:36: %FTD-6-302013: Built inbound TCP connection 4869 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80)

Oct 13 2019 13:57:36: %FTD-6-302014: Teardown TCP connection 4869 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE

Oct 13 2019 13:57:39: %FTD-6-302013: Built inbound TCP connection 4870 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80)

Oct 13 2019 13:57:39: %FTD-6-302014: Teardown TCP connection 4870 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE

Oct 13 2019 13:57:45: %FTD-6-302013: Built inbound TCP connection 4871 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80)

Oct 13 2019 13:57:45: %FTD-6-302014: Teardown TCP connection 4871 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE

Ces journaux indiquent qu'un TCP RST arrive sur l'interface INSIDE du pare-feu

Capture CAPI dans Wireshark :

Suivez le premier flux TCP, comme illustré dans l’image.

Sous Wireshark, accédez à Edit > Preferences > Protocols > TCP et désélectionnez l'option Relative sequence numbers comme indiqué dans l'image.

Cette image montre le contenu du premier flux dans la capture CAPI :

Principaux points :

1. Le client envoie un paquet TCP SYN.

2. Le client envoie un paquet TCP RST.

3. Le paquet TCP SYN a une valeur de numéro d’ordre égale à 4098574664.

Le même flux de capture CAPO contient :

Principaux points :

1. Le client envoie un paquet TCP SYN. Le pare-feu randomise l'ISN.

2. Le client envoie un paquet TCP RST.

Sur la base des deux captures, on peut conclure que :

- Il n'y a pas de connexion TCP en trois étapes entre le client et le serveur.

- Il y a un TCP RST qui vient du client. La valeur du numéro de séquence TCP RST dans la capture CAPI est 1386249853.

Actions recommandées

Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.

Action 1. Effectuez une capture du client.

Sur la base des captures collectées sur le pare-feu, il existe une forte indication d'un flux asymétrique. Ceci est basé sur le fait que le client envoie un TCP RST avec une valeur de 1386249853 (le RNIS aléatoire) :

Principaux points :

1. Le client envoie un paquet TCP SYN. Le numéro d'ordre est 4098574664 et est le même que celui vu sur l'interface INSIDE du pare-feu (CAPI)

2. Il existe un TCP SYN/ACK avec ACK numéro 1386249853 (ce qui est attendu en raison de la randomisation ISN). Ce paquet n’a pas été vu dans les captures du pare-feu

3. Le client envoie un RST TCP car il attendait un SYN/ACK avec une valeur de numéro ACK de 4098574665, mais il a reçu une valeur de 1386249853

Cela peut être visualisé comme suit :

Action 2. Vérifiez le routage entre le client et le pare-feu.

Confirmez que :

- Les adresses MAC visibles dans les captures sont les adresses attendues.

- Vérifiez que le routage entre le pare-feu et le client est symétrique.

Il existe des scénarios où la TVD provient d'un périphérique situé entre le pare-feu et le client alors qu'il existe un routage asymétrique dans le réseau interne. Un cas typique est montré dans l'image :

Dans ce cas, la capture a ce contenu. Notez la différence entre l'adresse MAC source du paquet TCP SYN et l'adresse MAC source du RST TCP et l'adresse MAC de destination du paquet TCP SYN/ACK :

firepower# show capture CAPI detail

1: 13:57:36.730217 4c4e.35fc.fcd8 00be.75f6.1dae 0x0800 Length: 66

192.168.0.100.47740 > 10.10.1.100.80: S [tcp sum ok] 3045001876:3045001876(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF) (ttl 127, id 25661)

2: 13:57:36.981104 4c4e.35fc.fcd8 00be.75f6.1dae 0x0800 Length: 66

192.168.0.100.47741 > 10.10.1.100.80: S [tcp sum ok] 3809380540:3809380540(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF) (ttl 127, id 25662)

3: 13:57:36.981776 00be.75f6.1dae a023.9f92.2a4d 0x0800 Length: 66

10.10.1.100.80 > 192.168.0.100.47741: S [tcp sum ok] 1304153587:1304153587(0) ack 3809380541 win 8192 <mss 1380,nop,wscale 8,nop,nop,sackOK> (DF) (ttl 127, id 23339)

4: 13:57:36.982126 a023.9f92.2a4d 00be.75f6.1dae 0x0800 Length: 54

192.168.0.100.47741 > 10.10.1.100.80: R [tcp sum ok] 3809380541:3809380541(0) ack 1304153588 win 8192 (ttl 255, id 48501)

...

Cas 5 . Transfert TCP lent (scénario 1)

Description du problème :

Le transfert SFTP entre les hôtes 10.11.4.171 et 10.77.19.11 est lent. Bien que la bande passante minimale entre les deux hôtes soit de 100 Mbits/s, la vitesse de transfert ne dépasse pas 5 Mbits/s.

Dans le même temps, la vitesse de transfert entre les hôtes 10.11.2.124 et 172.25.18.134 est nettement supérieure.

Théorie de fond :

La vitesse de transfert maximale pour un flux TCP unique est déterminée par le produit BDP (Bandwidth Delay Product). La formule utilisée est illustrée dans l'image :

Pour plus de détails sur le BDP, consultez les ressources ici :

- Pourquoi votre application utilise-t-elle uniquement 10 Mbit/s ? Même si la liaison est de 1 Gbit/s ?

- BRKSEC-3021 - Avancé - Optimisation des performances du pare-feu

Scénario 1. Transfert lent

Cette image présente la topologie :

Flux affecté :

IP source : 10.11.4.171

Adresse IP d'expédition : 10.77.19.11

Protocole : SFTP (FTP sur SSH)

Analyse de capture

Activer les captures sur le moteur FTD LINA :

firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11

firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11

Avertissement : les captures LINA sur 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). Utilisez plutôt SPAN ou un périphérique HW Tap en plus des captures sur les hôtes source et de destination. Le problème est documenté dans l'ID de bogue Cisco CSCvo30697.

firepower# capture CAPI type raw-data trace interface inside match icmp any any

WARNING: Running packet capture can have an adverse impact on performance.

Actions recommandées

Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.

Calcul du temps de parcours aller-retour (RTT)

Tout d'abord, identifiez le flux de transfert et suivez-le :

Modifiez la vue Wireshark pour afficher les secondes écoulées depuis le paquet affiché précédent. Ceci facilite le calcul de la RTT :

Le RTT peut être calculé par addition des valeurs de temps entre 2 échanges de paquets (un vers la source et un vers la destination). Dans ce cas, le paquet #2 affiche le RTT entre le pare-feu et le périphérique qui a envoyé le paquet SYN/ACK (serveur). Le paquet #3 indique le délai entre le pare-feu et le périphérique qui a envoyé le paquet ACK (client). L'ajout des 2 numéros donne une bonne estimation de la valeur de bout en bout de la valeur de transfert de l'appel :

RTT ≈ 80 ms

Calcul de la taille de fenêtre TCP

Développez un paquet TCP, développez l'en-tête TCP, sélectionnez Calculated window size et sélectionnez Apply as Column :

Vérifiez la colonne Valeur de taille de fenêtre calculée pour voir quelle était la valeur de taille de fenêtre maximale pendant la session TCP. Vous pouvez également sélectionner le nom de la colonne et trier les valeurs.

Si vous testez un téléchargement de fichier (serveur > client), vous devez vérifier les valeurs annoncées par le serveur. La valeur de taille de fenêtre maximale annoncée par le serveur détermine la vitesse de transfert maximale atteinte.

Dans ce cas, la taille de la fenêtre TCP est de ≈ 50000 octets

Sur la base de ces valeurs et en utilisant la formule Bandwidth Delay Product, vous obtenez la bande passante théorique maximale qui peut être atteinte dans les conditions suivantes : 50000*8/0,08 = 5 Mbits/s de bande passante théorique maximale.

Cela correspond à ce que le client ressent dans ce cas.

Vérifiez de près la connexion TCP en trois étapes. Les deux côtés, et plus important encore le serveur, annoncent une valeur d'échelle de fenêtre de 0, ce qui signifie 2^0 = 1 (aucune échelle de fenêtre). Cela affecte négativement le taux de transfert :

À ce stade, il est nécessaire de prendre une capture sur le serveur, de confirmer que c'est celui qui annonce l'échelle de fenêtre = 0 et de la reconfigurer (consultez la documentation du serveur pour savoir comment faire).

Scénario 2. Transfert rapide

Examinons maintenant le bon scénario (transfert rapide via le même réseau) :

Topologie:

Le flux d'intérêt :

IP source : 10.11.2.124

Adresse IP de destination : 172.25.18.134

Protocole : SFTP (FTP sur SSH)

Activer les captures sur le moteur LINA FTD

firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134

firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134

Calcul du temps de parcours aller-retour (RTT) : dans ce cas, le RTT est ≈ 300 ms.

Calcul de la taille de fenêtre TCP : le serveur annonce un facteur d'échelle de fenêtre TCP de 7.

La taille de la fenêtre TCP du serveur est de ≈ 1600000 octets :

Sur la base de ces valeurs, la formule de produit Délai de bande passante donne :

1600000*8/0,3 = vitesse de transfert théorique maximale de 43 Mbits/s

Cas 6 . Transfert TCP lent (scénario 2)

Description du problème : le transfert de fichiers FTP (téléchargement) via le pare-feu est lent.

Cette image présente la topologie :

Flux affecté :

Adresse IP source : 192.168.2.220

Adresse IP d'expédition : 192.168.1.220

Protocole : FTP

Analyse de capture

Activez les captures sur le moteur FTD LINA.

firepower# capture CAPI type raw-data buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220

firepower# cap CAPO type raw-data buffer 33554432 interface OUTSIDE match tcp host 192.168.2.220 host 192.168.1.220

Sélectionnez un paquet FTP-DATA et suivez le protocole FTP Data Channel sur la capture FTD INSIDE (CAPI) :

Le contenu du flux FTP-DATA :

Le contenu de capture CAPO :

Principaux points :

1. Il existe des paquets TCP hors ordre (OOO).

2. Il y a une retransmission TCP.

3. Il y a une indication de perte de paquets (paquets abandonnés).

Conseil : enregistrez les captures lorsque vous accédez à Fichier > Exporter les paquets spécifiés. Enregistrez ensuite uniquement la plage de paquets affichée

Actions recommandées

Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.

Action 1. Identifiez l'emplacement de perte de paquets.

Dans de tels cas, vous devez effectuer des captures simultanées et utiliser la méthode « diviser et conquérir » pour identifier le ou les segments de réseau à l’origine de la perte de paquets. Du point de vue du pare-feu, il existe 3 scénarios principaux :

1. La perte de paquets est causée par le pare-feu lui-même.

2. La perte de paquets est provoquée en aval vers le périphérique pare-feu (direction du serveur vers le client).

3. La perte de paquets est provoquée en amont vers le périphérique pare-feu (direction du client vers le serveur).

Perte de paquets causée par le pare-feu : afin d'identifier si la perte de paquets est causée par le pare-feu, il est nécessaire de comparer la capture d'entrée à la capture de sortie. Il existe de nombreuses façons de comparer deux captures différentes. Cette section présente une méthode d'exécution de cette tâche.

Procédure de comparaison de 2 captures afin d'identifier la perte de paquets

Étape 1. Assurez-vous que les 2 captures contiennent des paquets provenant de la même fenêtre temporelle. Cela signifie qu'il ne doit pas y avoir de paquets dans une capture qui ont été capturés avant ou après l'autre capture. Pour ce faire, vous pouvez procéder de plusieurs manières :

- Vérifiez les première et dernière valeurs d'identification IP (ID) de paquet.

- Vérifiez les valeurs d'horodatage du premier et du dernier paquet.

Dans cet exemple, vous pouvez voir que les premiers paquets de chaque capture ont les mêmes valeurs d'ID IP :

Dans le cas où ils ne sont pas les mêmes alors :

1. Comparez les horodatages du premier paquet de chaque capture.

2. À partir de la capture avec le dernier Timestamp, obtenez un filtre à partir de celui-ci, changez le filtre Timestamp de == à >= (le premier paquet) et <= (le dernier paquet), par exemple :

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

3. Exportez les paquets spécifiés vers une nouvelle capture, sélectionnez Fichier > Exporter les paquets spécifiés et enregistrez les paquets affichés. À ce stade, les deux captures doivent contenir des paquets qui couvrent la même période. Vous pouvez maintenant commencer la comparaison des 2 captures.

Étape 2. Spécifiez le champ de paquet utilisé pour la comparaison entre les 2 captures. Exemple de champs qui peuvent être utilisés :

- Identification IP

- Numéro de séquence RTP

- Numéro de séquence ICMP

Créez une version textuelle de chaque capture contenant le champ de chaque paquet que vous avez spécifié à l'étape 1. Pour ce faire, ne laissez que la colonne d'intérêt, par exemple, si vous voulez comparer des paquets basés sur l'identification IP puis modifier la capture comme indiqué dans l'image.

Le résultat :

Étape 3. Créez une version textuelle de la capture (Fichier > Exporter les dissections de paquets > En tant que texte brut...), comme illustré dans l'image :

Désactivez les options Inclure les en-têtes de colonne et Détails du paquet pour exporter uniquement les valeurs du champ affiché, comme illustré dans l'image :

Étape 4. Trier les paquets dans les fichiers. Pour ce faire, vous pouvez utiliser la commande sort de Linux :

# sort CAPI_IDs > file1.sorted

# sort CAPO_IDs > file2.sorted

Étape 5. Utilisez un outil de comparaison de texte (par exemple, WinMerge) ou la commande Linux diff pour trouver les différences entre les 2 captures.

Dans ce cas, les captures CAPI et CAPO pour le trafic de données FTP sont identiques. Cela prouve que la perte de paquets n'a pas été causée par le pare-feu.

Identifiez la perte de paquets en amont/en aval.

Principaux points :

1. Ce paquet est une retransmission TCP. Plus précisément, il s’agit d’un paquet SYN TCP envoyé du client au serveur pour les données FTP en mode passif. Puisque le client renvoie le paquet et que vous pouvez voir le SYN initial (paquet #1), le paquet a été perdu en amont du pare-feu.

Dans ce cas, il est possible que le paquet SYN soit arrivé au serveur, mais le paquet SYN/ACK a été perdu sur le chemin du retour :

2. Un paquet provenant du serveur et Wireshark a identifié que le segment précédent n’a pas été vu/capturé. Puisque le paquet non capturé a été envoyé du serveur au client et n'a pas été vu dans la capture du pare-feu, cela signifie que le paquet a été perdu entre le serveur et le pare-feu.

Cela indique une perte de paquets entre le serveur FTP et le pare-feu.

Action 2. Effectuez des captures supplémentaires.

Effectuez des captures supplémentaires avec les captures aux points d'extrémité. Essayez d’appliquer la méthode « diviser et conquérir » pour isoler plus précisément le segment problématique à l’origine de la perte de paquets.

Principaux points :

1. Le récepteur (le client FTP dans ce cas) effectue le suivi des numéros de séquence TCP entrants. S'il détecte qu'un paquet a été manqué (un numéro de séquence attendu a été ignoré), il génère un paquet ACK avec ACK='numéro de séquence attendu qui a été ignoré'. Dans cet exemple, Ack=2224386800.

2. Le Dup ACK déclenche une retransmission TCP rapide (retransmission dans les 20 ms suivant la réception d'un double ACK).

Que signifient les ACK dupliqués ?

- Quelques ACK dupliqués, mais aucune retransmission réelle, indiquent qu'il y a plus de chances que des paquets arrivent dans le désordre.

- Des ACK dupliqués suivis de retransmissions réelles indiquent une certaine perte de paquets.

Action 3. Calculez le temps de traitement du pare-feu pour les paquets en transit.

Appliquez la même capture sur 2 interfaces différentes :

firepower# capture CAPI buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220

firepower# capture CAPI interface OUTSIDE

Exporter la capture Vérifier la différence de temps entre les paquets entrants et sortants

Cas 7 . Problème de connectivité TCP (corruption de paquet)

Description du problème :

Le client sans fil (192.168.21.193) tente de se connecter à un serveur de destination (192.168.14.250 - HTTP) et il existe deux scénarios différents :

- Lorsque le client se connecte au point d'accès « A », la connexion HTTP ne fonctionne pas.

- Lorsque le client se connecte au point d'accès « B », la connexion HTTP fonctionne.

Cette image présente la topologie :

Flux affecté :

Adresse IP source : 192.168.21.193

Adresse IP d'expédition : 192.168.14.250

Protocole : TCP 80

Analyse de capture

Activer les captures sur le moteur FTD LINA :

firepower# capture CAPI int INSIDE match ip host 192.168.21.193 host 192.168.14.250

firepower# capture CAPO int OUTSIDE match ip host 192.168.21.193 host 192.168.14.250

Captures - Scénario fonctionnel :

Comme base de référence, il est toujours très utile de disposer de captures à partir d'un scénario dont le fonctionnement a été vérifié.

Cette image montre la capture effectuée sur l'interface NGFW INSIDE

Cette image montre la capture effectuée sur l'interface EXTERNE du pare-feu de nouvelle génération.

Principaux points :

1. Les deux captures sont presque identiques (considérez la randomisation ISN).

2. Il n'y a aucune indication de perte de paquets.

3. Pas de paquets hors d'ordre (OOO)

4. Il existe 3 requêtes HTTP GET. Le premier reçoit un 404 ‘Not Found’, le second un 200 ‘OK’ et le troisième un 304 ‘Not Modified’ message de redirection.

Captures - Scénario d'erreur connue :

Contenu de la capture d'entrée (CAPI).

Principaux points :

1. Il existe une connexion TCP en trois étapes.

2. Il existe des retransmissions TCP et des indications de perte de paquets.

3. Il y a un paquet (TCP ACK) qui est identifié par Wireshark comme Malformed.

Cette image présente le contenu de la capture de sortie (CAPO).

Principaux points :

Les deux captures sont presque identiques (considérez la randomisation ISN) :

1. Il existe une connexion TCP en trois étapes.

2. Il existe des retransmissions TCP et des indications de perte de paquets.

3. Il y a un paquet (TCP ACK) qui est identifié par Wireshark comme Malformed.

Vérifiez le paquet mal formé :

Principaux points :

1. Le paquet est identifié comme étant un paquet malformé par Wireshark.

2. Sa longueur est de 2 octets.

3. La charge utile TCP est de 2 octets.

4. La charge utile est de 4 zéros supplémentaires (00 00).

Actions recommandées

Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.

Action 1. Effectuez des captures supplémentaires. Incluez des captures au niveau des points d'extrémité et, si possible, essayez d'appliquer la méthode « diviser et conquérir » pour isoler la source de la corruption du paquet, par exemple :

Dans ce cas, les 2 octets supplémentaires ont été ajoutés par le pilote d'interface « A » du commutateur et la solution était de remplacer le commutateur qui cause la corruption.

Cas 8 . Problème de connectivité UDP (paquets manquants)

Description du problème : les messages Syslog (UDP 514) ne sont pas visibles sur le serveur Syslog de destination.

Cette image présente la topologie :

Flux affecté :

Adresse IP source : 192.168.1.81

Adresse IP du poste : 10.10.1.73

Protocole : UDP 514

Analyse de capture

Activer les captures sur le moteur FTD LINA :

firepower# capture CAPI int INSIDE trace match udp host 192.168.1.81 host 10.10.1.73 eq 514

firepower# capture CAPO int OUTSIDE match udp host 192.168.1.81 host 10.10.1.73 eq 514

Les captures FTD ne montrent aucun paquet :

firepower# show capture

capture CAPI type raw-data trace interface INSIDE [Capturing - 0 bytes]

match udp host 192.168.1.81 host 10.10.1.73 eq syslog

capture CAPO type raw-data interface OUTSIDE [Capturing - 0 bytes]

match udp host 192.168.1.81 host 10.10.1.73 eq syslog

Actions recommandées

Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.

Action 1. Vérifiez la table de connexion FTD.

Pour vérifier une connexion spécifique, vous pouvez utiliser cette syntaxe :

firepower# show conn address 192.168.1.81 port 514

10 in use, 3627189 most used

Inspect Snort:

preserve-connection: 6 enabled, 0 in effect, 74 most enabled, 0 most in effect

UDP INSIDE  10.10.1.73:514 INSIDE  192.168.1.81:514, idle 0:00:00, bytes 480379697, flags -oN1

Principaux points :

1. Les interfaces d'entrée et de sortie sont identiques (demi-tour).

2. Le nombre d'octets a une valeur importante (~5 GoYtes).

3. Le drapeau « o » indique le débit de déchargement (HW accéléré). C'est la raison pour laquelle les captures FTD n'affichent aucun paquet. Le déchargement de flux est uniquement pris en charge sur les plates-formes 41xx et 93xx. Dans ce cas, le périphérique est un 41xx.

Action 2. Effectuez des captures au niveau du châssis.

Connectez-vous au gestionnaire de châssis Firepower et activez la capture sur l'interface d'entrée (E1/2 dans ce cas) et les interfaces de fond de panier (E1/9 et E1/10), comme illustré dans l'image :

Au bout de quelques secondes :

Conseil : dans Wireshark, excluez les paquets étiquetés VN pour éliminer la duplication des paquets au niveau de l'interface physique

Avant :

Après :

Principaux points :

1. Un filtre d'affichage est appliqué pour supprimer les doublons de paquets et afficher uniquement les syslogs.

2. La différence entre les paquets se situe au niveau des microsecondes. Cela indique un débit de paquets très élevé.

3. La valeur de durée de vie (TTL) diminue continuellement. Cela indique une boucle de paquets.

Action 3. Utilisez Packet Tracer.

Comme les paquets ne traversent pas le moteur LINA du pare-feu, vous ne pouvez pas effectuer de trace en direct (capture avec trace), mais vous pouvez suivre un paquet émulé avec packet-tracer :

firepower# packet-tracer input INSIDE udp 10.10.1.73 514 192.168.1.81 514

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 3

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found flow with id 25350892, using existing flow

Phase: 4

Type: SNORT

Subtype:

Result: ALLOW

Config:

Additional Information:

Snort Verdict: (fast-forward) fast forward this flow

Phase: 5

Type: ROUTE-LOOKUP

Subtype: Resolve Egress Interface

Result: ALLOW

Config:

Additional Information:

found next-hop 192.168.1.81 using egress ifc  INSIDE

Phase: 6

Type: ADJACENCY-LOOKUP

Subtype: next-hop and adjacency

Result: ALLOW

Config:

Additional Information:

adjacency Active

next-hop mac address a023.9f92.2a4d hits 1 reference 1

Phase: 7

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

Result:

input-interface: INSIDE

input-status: up

input-line-status: up

output-interface: INSIDE

output-status: up

output-line-status: up

Action: allow

Mesure 4. Confirmez le routage FTD.

Vérifiez la table de routage du pare-feu pour voir s'il existe des problèmes de routage :

firepower# show route 10.10.1.73

Routing entry for 10.10.1.0 255.255.255.0

Known via "eigrp 1", distance 90, metric 3072, type internal

Redistributing via eigrp 1

Last update from 192.168.2.72 on OUTSIDE, 0:03:37 ago

Routing Descriptor Blocks:

* 192.168.2.72, from 192.168.2.72, 0:02:37 ago, via OUTSIDE

Route metric is 3072, traffic share count is 1

Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 29/255, Hops 1

Principaux points :

1. La route pointe vers l’interface de sortie correcte.

2. La route a été apprise il y a quelques minutes (0:02:37).

Action 5. Confirmez la disponibilité de la connexion.

Vérifiez la disponibilité de la connexion pour savoir quand cette connexion a été établie :

firepower# show conn address 192.168.1.81 port 514 detail

21 in use, 3627189 most used

Inspect Snort:

preserve-connection: 19 enabled, 0 in effect, 74 most enabled, 0 most in effect

Flags: A - awaiting responder ACK to SYN, a - awaiting initiator ACK to SYN,

b - TCP state-bypass or nailed,

C - CTIQBE media, c - cluster centralized,

D - DNS, d - dump, E - outside back connection, e - semi-distributed,

F - initiator FIN, f - responder FIN,

G - group, g - MGCP, H - H.323, h - H.225.0, I - initiator data,

i - incomplete, J - GTP, j - GTP data, K - GTP t3-response

k - Skinny media, L - decap tunnel, M - SMTP data, m - SIP media

N - inspected by Snort (1 - preserve-connection enabled, 2 - preserve-connection in effect)

n - GUP, O - responder data, o - offloaded,

P - inside back connection, p - passenger flow

q - SQL*Net data, R - initiator acknowledged FIN,

R - UDP SUNRPC, r - responder acknowledged FIN,

T - SIP, t - SIP transient, U - up,

V - VPN orphan, v - M3UA W - WAAS,

w - secondary domain backup,

X - inspected by service module,

x - per session, Y - director stub flow, y - backup stub flow,

Z - Scansafe redirection, z - forwarding stub flow

UDP INSIDE: 10.10.1.73/514 INSIDE: 192.168.1.81/514,

flags -oN1, idle 0s, uptime 3m49s, timeout 2m0s, bytes 4801148711

Point clé :

1. La connexion a été établie il y a environ 4 minutes (avant l’installation de la route EIGRP dans la table de routage)

Mesure no 6. Effacez la connexion établie.

Dans ce cas, les paquets correspondent à une connexion établie et sont routés vers une interface de sortie incorrecte ; cela provoque une boucle. Ceci est dû à l'ordre des opérations du pare-feu :

1. Recherche de connexion établie (priorité sur la recherche de table de routage globale).

2. Recherche NAT (Network Address Translation) : la phase UN-NAT (destination NAT) est prioritaire sur la recherche PBR et la recherche de route.

3. Routage basé sur des politiques (PBR)

4. Recherche de table de routage globale

Comme la connexion n'expire jamais (le client Syslog envoie continuellement des paquets pendant que le délai d'inactivité de la connexion UDP est de 2 minutes), il est nécessaire d'effacer manuellement la connexion :

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

1 connection(s) deleted.

Vérifiez qu'une nouvelle connexion est établie :

firepower# show conn address 192.168.1.81 port 514 detail | b 10.10.1.73.*192.168.1.81

UDP OUTSIDE: 10.10.1.73/514 INSIDE: 192.168.1.81/514,

flags -oN1, idle 1m15s, uptime 1m15s, timeout 2m0s, bytes 408

Mesure 7. Configurez le délai de conn flottant.

C'est la solution appropriée pour résoudre le problème et éviter un routage non optimal, en particulier pour les flux UDP. Accédez à Devices > Platform Settings > Timeouts et définissez la valeur :

Vous pouvez trouver plus de détails sur le délai d'attente du conn flottant dans le Guide de référence des commandes :

https://www.cisco.com/c/en/us/td/docs/security/asa/asa-cli-reference/T-Z/asa-command-ref-T-Z.html#pgfId-1649892

Cas 9 . Problème de connectivité HTTPS (scénario 1)

Description du problème : la communication HTTPS entre le client 192.168.201.105 et le serveur 192.168.202.101 ne peut pas être établie

Cette image présente la topologie :

Flux affecté :

Adresse IP source : 192.168.201.111

Adresse IP d'expédition : 192.168.202.111

Protocole : TCP 443 (HTTPS)

Analyse de capture

Activer les captures sur le moteur FTD LINA :

L'adresse IP utilisée dans la capture OUTSIDE est différente en raison de la configuration de la traduction d'adresses de port.

firepower# capture CAPI int INSIDE match ip host 192.168.201.111 host 192.168.202.111

firepower# capture CAPO int OUTSIDE match ip host 192.168.202.11 host 192.168.202.111

Cette image montre la capture effectuée sur l'interface INSIDE du pare-feu de nouvelle génération :

Principaux points :

1. Il existe une connexion TCP en trois étapes.

2. La négociation SSL commence. Le client envoie un message Hello Client.

3. Un accusé de réception TCP est envoyé au client.

4. Un RST TCP est envoyé au client.

Cette image montre la capture effectuée sur l'interface EXTERNE du pare-feu de nouvelle génération.

Principaux points :

1. Il existe une connexion TCP en trois étapes.

2. La négociation SSL commence. Le client envoie un message Hello Client.

3. Des retransmissions TCP sont envoyées du pare-feu vers le serveur.

4. Un RST TCP est envoyé au serveur.

Actions recommandées

Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.

Action 1. Effectuez des captures supplémentaires.

Une capture effectuée sur le serveur révèle que le serveur a reçu les Hello du client TLS avec la somme de contrôle TCP corrompue et les abandonne silencieusement (il n'y a pas de TCP RST ou tout autre paquet de réponse vers le client) :

Lorsque vous mettez tout ensemble :

Dans ce cas, pour comprendre, il est nécessaire d'activer sur Wireshark l'option Valider la somme de contrôle TCP si possible. Naviguez jusqu'à Edit > Preferences > Protocols > TCP, comme indiqué dans l'image.

Dans ce cas, il est utile de placer les captures côte à côte afin d'obtenir une image complète :

Principaux points :

1. Il existe une connexion TCP en trois étapes. Les ID IP sont identiques. Cela signifie que le flux n'a pas été mis en proxy par le pare-feu.

2. Un Hello de client TLS provient du client avec l'ID IP 12083. Le paquet est mis en proxy par le pare-feu (le pare-feu, dans ce cas, a été configuré avec la stratégie de déchiffrement TLS) et l'ID IP est modifié à 52534. En outre, la somme de contrôle TCP du paquet est corrompue (en raison d'un défaut logiciel qui a été réparé par la suite).

3. Le pare-feu est en mode Proxy TCP et envoie un ACK au client (qui usurpe le serveur).

4. Le pare-feu ne reçoit aucun paquet ACK TCP du serveur et retransmet le message Hello du client TLS. Cela est encore dû au mode Proxy TCP que le pare-feu a activé.

5. Après environ 30 secondes, le pare-feu abandonne et envoie un RST TCP au client.

6. Le pare-feu envoie un RST TCP au serveur.

Pour référence :

Traitement de la connexion TLS/SSL Firepower

Cas 10 . Problème de connectivité HTTPS (scénario 2)

Description du problème : l'enregistrement de la licence Smart FMC échoue.

Cette image présente la topologie :

Flux affecté :

Adresse IP source : 192.168.0.100

Dst : tools.cisco.com

Protocole : TCP 443 (HTTPS)

Analyse de capture

Activez la capture sur l'interface de gestion FMC :

Réessayez de vous inscrire. Lorsque le message d'erreur apparaît, appuyez sur CTRL-C pour arrêter la capture :

root@firepower:/Volume/home/admin# tcpdump -i eth0 port 443 -s 0 -w CAP.pcap

HS_PACKET_BUFFER_SIZE is set to 4.

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

^C264 packets captured <- CTRL-C

264 packets received by filter

0 packets dropped by kernel

root@firepower:/Volume/home/admin#

Collectez la capture à partir du FMC (System > Health > Monitor, sélectionnez le périphérique et sélectionnez Advanced Troubleshooting), comme illustré dans l'image :

L’image montre la capture FMC sur Wireshark :

Conseil : afin de vérifier toutes les nouvelles sessions TCP qui ont été capturées, utilisez le filtre d'affichage tcp.flags==0x2 sur Wireshark. Cela filtre tous les paquets TCP SYN qui ont été capturés.

Conseil : appliquez en tant que colonne le champ Server Name du paquet SSL Client Hello.

Conseil : appliquez ce filtre d'affichage pour afficher uniquement les messages Hello du client ssl.handshake.type == 1

Remarque : au moment de la rédaction de ce 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 (Follow > TCP Stream), comme illustré dans l'image.

Principaux points :

1. Il existe une connexion TCP en trois étapes.

2. Le client (FMC) envoie un message Hello de client SSL vers le portail Smart Licensing.

3. L'ID de session SSL est 0. Cela signifie qu'il ne s'agit pas d'une reprise de session.

4. Le serveur de destination répond avec le message Server Hello, Certificate et Server Hello Done.

5. Le client envoie une alerte SSL fatale qui concerne une « CA inconnue ».

6. Le client envoie un RST TCP pour fermer la session.

7. La durée totale de la session TCP (de l'établissement à la fermeture) était d'environ 0,5 seconde.

Sélectionnez le certificat de serveur et développez le champ de l'émetteur pour voir le commonName. Dans ce cas, le nom commun indique un périphérique qui fait de l'homme du milieu (MITM).

Ceci est montré dans cette image :

Actions recommandées

Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.

Action 1. Effectuez des captures supplémentaires.

Effectuez des captures sur le périphérique de pare-feu de transit :

CAPI montre :

CAPO montre :

Ces captures prouvent que le pare-feu de transit modifie le certificat de serveur (MITM)

Action 2. Vérifiez les journaux des périphériques.

Vous pouvez collecter l'offre groupée FMC TS comme décrit dans ce document :

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

Dans ce cas, le fichier /dir-archives/var-log/process_stdout.log affiche des messages comme ceci :

SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla[10068]: *Wed .967 UTC: CH-LIB-ERROR: ch_pf_curl_send_msg[494],

failed to perform, err code 60, err string "SSL peer certificate or SSH remote key was not OK"

...

SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla[10068]: *Wed .967 UTC: CH-LIB-TRACE: ch_pf_curl_is_cert_issue[514],

cert issue checking, ret 60, url "https://tools.cisco.com/its/

Solution recommandée

Désactivez le MITM pour le flux spécifique afin que FMC puisse s'enregistrer avec succès sur le cloud de licences Smart.

Cas 11 . Problème de connectivité IPv6

Description du problème : les hôtes internes (situés derrière l'interface INSIDE du pare-feu) ne peuvent pas communiquer avec les hôtes externes (hôtes situés derrière l'interface OUTSIDE du pare-feu).

Cette image présente la topologie :

Flux affecté :

Src IP: fc00:1:1:1::100

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

Protocole : tout

Analyse de capture

Activer les captures sur le moteur FTD LINA.

firepower# capture CAPI int INSIDE match ip any6 any6

firepower# capture CAPO int OUTSIDE match ip any6 any6

Captures - Scénario non fonctionnel

Ces captures ont été effectuées en parallèle avec un test de connectivité ICMP de l'IP fc00:1:1:1::100 (routeur interne) à l'IP fc00:1:1:2::2 (routeur en amont).

La capture sur l'interface INSIDE du pare-feu contient :

Principaux points :

1. Le routeur envoie un message de sollicitation de voisin IPv6 et demande l'adresse MAC du périphérique en amont (IP fc00:1:1::1).

2. Le pare-feu répond avec une annonce de voisin IPv6.

3. Le routeur envoie une requête d’écho ICMP.

4. Le pare-feu envoie un message de sollicitation de voisin IPv6 et demande l'adresse MAC du périphérique en aval (fc00:1:1:1::100).

5. Le routeur répond avec une annonce de voisin IPv6.

6. Le routeur envoie des requêtes d'écho ICMP IPv6 supplémentaires.

La capture sur l'interface EXTERNE du pare-feu contient :

Principaux points :

1. Le pare-feu envoie un message de sollicitation de voisin IPv6 qui demande l'adresse MAC du périphérique en amont (IP fc00:1:1:2::2).

2. Le routeur répond avec une annonce de voisin IPv6.

3. Le pare-feu envoie une requête d'écho ICMP IPv6.

4. Le périphérique en amont (routeur fc00:1:1:2::2) envoie un message de sollicitation de voisin IPv6 qui demande l'adresse MAC de l'adresse IPv6 fc00:1:1:1::100.

5. Le pare-feu envoie une requête d'écho ICMP IPv6 supplémentaire.

6. Le routeur en amont envoie un message de sollicitation de voisin IPv6 supplémentaire qui demande l'adresse MAC de l'adresse IPv6 fc00:1:1:1::100.

Le point 4 est très intéressant. Normalement, le routeur en amont demande l'adresse MAC de l'interface OUTSIDE du pare-feu (fc00:1:1:2::2), mais à la place, il demande l'adresse fc00:1:1:1::100. Ceci indique une erreur de configuration.

Actions recommandées

Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.

Action 1. Vérifiez la table de voisinage IPv6.

La table de voisinage IPv6 du pare-feu est correctement remplie.

firepower# show ipv6 neighbor | i fc00

fc00:1:1:2::2                              58 4c4e.35fc.fcd8  STALE OUTSIDE

fc00:1:1:1::100                            58 4c4e.35fc.fcd8  STALE INSIDE

Action 2. Vérifiez la configuration IPv6.

Voici la configuration du pare-feu.

firewall# show run int e1/2

!

interface Ethernet1/2

nameif INSIDE

cts manual

propagate sgt preserve-untag

policy static sgt disabled trusted

security-level 0

ip address 192.168.0.1 255.255.255.0

ipv6 address fc00:1:1:1::1/64

ipv6 enable

firewall# show run int e1/3.202

!

interface Ethernet1/3.202

vlan 202

nameif OUTSIDE

cts manual

propagate sgt preserve-untag

policy static sgt disabled trusted

security-level 0

ip address 192.168.103.96 255.255.255.0

ipv6 address fc00:1:1:2::1/64

ipv6 enable

La configuration du périphérique en amont révèle l'erreur de configuration :

Router# show run interface g0/0.202

!

interface GigabitEthernet0/0.202

encapsulation dot1Q 202

vrf forwarding VRF202

ip address 192.168.2.72 255.255.255.0

ipv6 address FC00:1:1:2::2/48

Captures - Scénario fonctionnel

La modification du masque de sous-réseau (de /48 à /64) a résolu le problème. Il s'agit de la capture CAPI dans le scénario fonctionnel.

Point clé :

1. Le routeur envoie un message de sollicitation de voisin IPv6 qui demande l'adresse MAC du périphérique en amont (IP fc00:1:1:1::1).

2. Le pare-feu répond avec une annonce de voisin IPv6.

3. Le routeur envoie des requêtes d’écho ICMP et obtient des réponses d’écho.

Contenu CAPO :

Principaux points :

1. Le pare-feu envoie un message de sollicitation de voisin IPv6 qui demande l'adresse MAC du périphérique en amont (IP fc00:1:1:2::2).

2. Le pare-feu répond avec une annonce de voisin IPv6.

3. Le pare-feu envoie une requête d’écho ICMP.

4. Le routeur envoie un message de sollicitation de voisin IPv6 qui demande l'adresse MAC du périphérique en aval (IP fc00:1:1:1::1).

5. Le pare-feu répond avec une annonce de voisin IPv6.

6. Le pare-feu envoie des requêtes d'écho ICMP et obtient des réponses d'écho.

Cas 12 . Problème de connectivité intermittent (empoisonnement ARP)

Description du problème : les hôtes internes (192.168.0.x/24) présentent des problèmes de connectivité intermittents avec les hôtes du même sous-réseau

Cette image présente la topologie :

Flux affecté :

Adresse IP source : 192.168.0.x/24

Adresse IP d'expédition : 192.168.0.x/24

Protocole : tout

Le cache ARP d'un hôte interne semble être empoisonné :

Analyse de capture

Activer une capture sur le moteur LINA FTD

Cette capture ne capture que les paquets ARP sur l'interface INSIDE :

firepower# capture CAPI_ARP interface INSIDE ethernet-type arp

Captures - Scénario non fonctionnel :

La capture sur l'interface INSIDE du pare-feu contient.

Principaux points :

1. Le pare-feu reçoit diverses requêtes ARP pour les adresses IP du réseau 192.168.0.x/24

2. Le pare-feu répond à tous ces paquets (proxy-ARP) avec sa propre adresse MAC

Actions recommandées

Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.

Action 1. Vérifiez la configuration NAT.

En ce qui concerne la configuration NAT, il y a des cas où le mot clé no-proxy-arp peut empêcher le comportement précédent :

firepower# show run nat

nat (INSIDE,OUTSIDE) source static NET_1.1.1.0 NET_2.2.2.0 destination static NET_192.168.0.0 NET_4.4.4.0 no-proxy-arp

Action 2. Désactivez la fonctionnalité proxy-arp sur l'interface du pare-feu.

Si le mot clé « no-proxy-arp » ne résout pas le problème, essayez de désactiver le proxy ARP sur l'interface elle-même. Dans le cas de FTD, au moment de la rédaction de ce document, vous devez utiliser FlexConfig et déployer la commande (spécifiez le nom d'interface approprié).

sysopt noproxyarp INSIDE

Cas 13 . Identifier les identificateurs d'objet SNMP (OID) qui provoquent des erreurs de CPU

Ce cas montre comment certains OID SNMP pour l'interrogation de la mémoire ont été identifiés comme la cause principale des erreurs de CPU (problème de performances) sur la base de l'analyse des captures de paquets SNMP version 3 (SNMPv3).

Description du problème : les dépassements sur les interfaces de données augmentent constamment. D'autres recherches ont révélé qu'il y a aussi des erreurs de CPU (causées par le processus SNMP) qui sont la cause première des dépassements d'interface.

L'étape suivante du processus de dépannage consistait à identifier la cause première des erreurs de CPU provoquées par le processus SNMP et, en particulier, à réduire l'étendue du problème pour identifier les identificateurs d'objet SNMP (OID) qui, lorsqu'ils sont interrogés, peuvent potentiellement entraîner des erreurs de CPU.

Actuellement, le moteur FTD LINA ne fournit pas de commande « show » pour les OID SNMP qui sont interrogés en temps réel.

La liste des OID SNMP pour l'interrogation peut être récupérée à partir de l'outil de surveillance SNMP, cependant, dans ce cas, il y avait ces facteurs préventifs :

- L'administrateur FTD n'a pas eu accès à l'outil de surveillance SNMP

- SNMP version 3 avec authentification et cryptage des données pour la confidentialité a été configuré sur FTD

Analyse de capture

Comme l'administrateur FTD disposait des informations d'identification pour l'authentification SNMP version 3 et le cryptage des données, ce plan d'action a été proposé :

1. Capture des paquets SNMP

2. Enregistrez les captures et utilisez les préférences de protocole SNMP de Wireshark pour spécifier les informations d'identification SNMP version 3 afin de déchiffrer les paquets SNMP version 3. Les captures décryptées sont utilisées pour l'analyse et la récupération des OID SNMP

Configurez les captures de paquets SNMP sur l'interface utilisée dans la configuration d'hôte snmp-server :

firepower# show run snmp-server  | include host

snmp-server host management 192.168.10.10 version 3 netmonv3

firepower# show ip address management

System IP Address:

Interface                Name                   IP address      Subnet mask     Method

Management0/0            management             192.168.5.254   255.255.255.0   CONFIG

Current IP Address:

Interface                Name                   IP address      Subnet mask     Method

Management0/0            management             192.168.5.254   255.255.255.0   CONFIG

firepower# capture capsnmp interface management buffer 10000000 match udp host 192.168.10.10  host 192.168.5.254 eq snmp

firepower# show capture capsnmp

capture capsnmp type raw-data buffer 10000000 interface outside [Capturing - 9512 bytes]

match udp host 192.168.10.10  host 192.168.5.254 eq snmp

Principaux points :

1. Adresses/ports source et de destination SNMP.

2. La PDU du protocole SNMP n'a pas pu être décodée car privKey est inconnu de Wireshark.

3. La valeur de la primitive encryptéePDU.

Actions recommandées

Les actions répertoriées dans cette section ont pour objectif de réduire davantage le problème.

Action 1. Déchiffrez les captures SNMP.

Enregistrez les captures et modifiez les préférences du protocole SNMP Wireshark pour spécifier les informations d'identification SNMP version 3 permettant de déchiffrer les paquets.

firepower# copy /pcap capture: tftp:

Source capture name [capsnmp]?

Address or name of remote host []? 192.168.10.253

Destination filename [capsnmp]? capsnmp.pcap

!!!!!!

64 packets copied in 0.40 secs

Ouvrez le fichier de capture sur Wireshark, sélectionnez un paquet SNMP et naviguez jusqu'à Protocol Preferences > Users Table, comme indiqué dans l'image :

Dans le tableau SNMP Users, le nom d'utilisateur, le modèle d'authentification, le mot de passe d'authentification, le protocole de confidentialité et le mot de passe de confidentialité SNMP version 3 ont été spécifiés (les informations d'identification réelles ne sont pas indiquées ci-dessous) :

Une fois que les paramètres SNMP Users ont été appliqués, Wireshark a montré les PDU SNMP déchiffrées :

Principaux points :

1. 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.

2. Le FTD a répondu à chaque getBulkRequest avec get-response qui contient des OID associés à 1.3.6.1.4.1.9.9.221.1.

Action 2. Identifiez les OID SNMP.

SNMP Object Navigator a montré que l'OID 1.3.6.1.4.1.9.9.221.1 appartient à la base d'informations de gestion (MIB) nommée CISCO-ENHANCED-MEMPOOL-MIB, comme indiqué dans l'image :

Pour afficher les OID dans un format lisible par l'utilisateur dans Wireshark :

1. Téléchargez la MIB CISCO-ENHANCED-MEMPOOL-MIB et ses dépendances, comme illustré dans l'image :

2. Dans Wireshark dans la fenêtre Edit > Preferences > Name Resolution, l'option Enable OID Resolution est cochée. Dans la fenêtre SMI (MIB and PIB paths), spécifiez le dossier avec les MIB téléchargées et dans SMI (MIB and PIB modules). La MIB CISCO-ENHANCED-MEMPOOL est ajoutée automatiquement à la liste des modules :

3. Une fois Wireshark redémarré, la résolution OID est activée :

Sur la base de la sortie déchiffrée du fichier de capture, l'outil de surveillance SNMP interrogeait régulièrement (10 secondes d'intervalle) les données relatives à l'utilisation des pools de mémoire sur le FTD. Comme expliqué dans l'article TechNote ASA SNMP Polling for Memory-Related Statistics , l'interrogation de l'utilisation du pool partagé global (GSP) avec SNMP entraîne une utilisation CPU élevée. Dans ce cas, à partir des captures, il était clair que l'utilisation du pool partagé global était régulièrement interrogée dans le cadre de la primitive getBulkRequest SNMP.

Afin de minimiser les problèmes de CPU causés par le processus SNMP, il a été recommandé de suivre les étapes de mitigation pour les problèmes de CPU pour SNMP mentionnés dans l'article et d'éviter d'interroger les OID liés à GSP. Sans l'interrogation SNMP pour les OID qui se rapportent à GSP, aucun bogue de CPU causé par le processus SNMP n'a été observé et le taux de dépassements a diminué de manière significative.

Informations connexes

- Guides de configuration de Cisco Firepower Management Center

- Clarifier les actions de règle de politique de contrôle d’accès de Firepower Threat Defense

- Utiliser les captures Firepower Threat Defense et Packet Tracer

- Découvrez Wireshark