Configurez, vérifiez et dépannez l'enregistrement de périphérique de FirePOWER

(1)

Configurez, vérifiez et dépannez l'enregistrement de périphérique de FirePOWER

Contenu

Introduction

Conditions préalables Conditions requises Composants utilisés Informations générales Options de conception

Quelles informations sont permutées par le sftunnel ? Quel Protocol/port est utilisé par le sftunnel ?

Comment changer le port TCP de Sftunnel sur FTD ? Combien de connexions sont-elles établies par le sftunnel ? Quel périphérique initie chaque Manche ?

Configurer

Fondements d'enregistrement

Scénario 1. adresse IP statique FMC et FTD

Adresse IP DHCP du scénario 2. FTD - Adresse IP statique FMC Adresse IP statique du scénario 3. FTD - Adresse IP DHCP FMC Enregistrement du scénario 4. FTD à FMC ha

Scénario 5. FTD ha

Batterie du scénario 6. FTD

Dépannez les problèmes courants 1. Syntaxe non valide sur FTD CLI

2. Non-concordance principale d'enregistrement entre FTD - FMC 3. Problèmes de connectivité entre FTD - FMC

4. SW incompatible entre FTD – FMC 5. Différence de temps entre FTD et FMC

6. processus de sftunnel vers le bas ou désactivé

7. Enregistrement en attendant FTD sur FMC secondaire 8. L'enregistrement échoue en raison du MTU de chemin

9. FTD obtient des non enregistrés après qu'une modification de bootstrap du gestionnaire UI de châssis

10. FTD perd Access à FMC dû à l'ICMP réoriente des messages 11. L'adresse IP n'est pas accessible

Introduction

Ce document décrit l'exécution, la vérification, et les procédures de dépannage de la connexion (sftunnel) entre une défense contre des menaces gérée de FirePOWER (FTD) et le centre gérant de Gestion de FirePOWER (FMC). Les informations et les exemples sont basés sur FTD, mais la plupart des concepts s'appliquent également entièrement à NGIPS (appliances de gamme

(2)

7000/8000) ou à un module de FirePOWER sur ASA55xx.

Contribué par Mikis Zafeiroudis, Ilkin Gasimov, ingénieurs TAC Cisco.

Conditions préalables

Exigences

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

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

Logiciel 6.6.x et 6.5.x FTD

●

Logiciel 6.6.x FMC

●

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Un FTD prend en charge 2 modes principaux de Gestion :

Hors fonction-case par l'intermédiaire de FMC - également connu sous le nom de gestion à distance

●

Sur-case par l'intermédiaire du gestionnaire de périphériques de FirePOWER (FDM) et/ou de l'orchestrator de la défense de Cisco (CDO) – également connu sous le nom de Gestion locale

●

Dans le cas de la gestion à distance le FTD doit d'abord s'enregistrer au FMC utilisant un

processus connu sous le nom d'enregistrement de périphérique. Une fois que l'enregistrement est fait les FTD et les FMC établissent un tunnel sécurisé appelé le sftunnel (le nom dérive du tunnel de Sourcefire).

Options de conception

D'un point de vue de conception les FTD – FMC peut être dans le même sous-réseau L3 :

(3)

ou soyez séparé par différents réseaux :

Remarque: Le sftunnel peut également passer par le FTD lui-même. Cette conception n'est pas recommandée. La raison est une question de plan de données FTD peut perturber la transmission entre FTD et FMC.

Quelles informations sont permutées par le sftunnel ?

Cette liste contient la majeure partie des informations qui sont diffusées par le sftunnel : Pulsation d'appareils (Keepalives)

●

Synchronisation horaire (NTP)

●

Événements (connexion, Intrusion/IPS, fichier, SSL etc.)

●

Consultations de malware

●

(4)

Événements/alertes de santés

●

Utilisateur et information du groupe (pour des stratégies d'identité)

●

Les informations d'état FTD ha

●

Les informations d'état de batterie FTD

●

Les informations/événements intelligents de Sécurité (SI)

●

Les informations/événements du directeur de renseignement sur la menace (TID)

●

Fichiers capturés

●

Événements de détection de réseau

●

Paquet de stratégie (déploiement de stratégie)

●

Paquets de mise à niveau de logiciel

●

Paquets de correctif logiciel

●

VDBs

●

SRUs

●

Quel Protocol/port est utilisé par le sftunnel ?

Le sftunnel utilise le port TCP 8305. Dans le backend c'est un tunnel de TLS :

Comment changer le port TCP de Sftunnel sur FTD ?

> configure network management-port 8306 Management port changed to 8306.

Remarque: Dans ce cas vous devez également changer le port sur FMC (configuration >

interfaces de gestion > les configurations partagées). Ceci affecte tous autres périphériques qui sont déjà enregistrés au même FMC. Cisco recommande vivement que vous gardiez les valeurs par défaut pour le port de gestion à distance, mais si le port de gestion est en conflit avec d'autres transmissions sur votre réseau, vous pouvez choisir un port différent. Si vous changez le port de gestion, vous devez le changer pour tous les périphériques dans votre déploiement qui doivent communiquer ensemble.

(5)

Combien de connexions sont-elles établies par le sftunnel ?

Le sftunnel établit 2 connexions (canaux) : Canal de contrôle

●

Canal d'événement

●

Quel périphérique initie chaque Manche ?

Il dépend du scénario. Vérifiez les scénarios décrit dans le reste du document.

Configurer

Fondements d'enregistrement

FTD CLI

Sur FTD la syntaxe de base pour l'enregistrement de périphérique est :

>configurez le gestionnaire ajoutent le <Registration Key> <NAT ID> <FMC Host>

Valeur Description

Hôte FMC

Ceci peut être l'un ou l'autre : Nom de l'hôte

●

ipv4 addres

●

ipv6 addres

●

DONTRESOLVE

●

Clé d'enregistrement

C'est une chaîne alphanumérique secrète partagée (entre 2 et 36 cars) utilisée pour l'enregistrement de périphérique. Seulement des alphanumériques, le trait d'union (-), le trait de soulignement (_) et la période (.) sont donnés.

ID NAT

Une chaîne alphanumérique utilisée pendant la procédure d'enregistrement entre le FMC et le périphérique quand un côté ne spécifie pas une adresse IP. Spécifiez le même ID NAT sur le FMC.

(6)

Pour des détails supplémentaires vérifiez la référence de commandes de défense contre des menaces de Cisco FirePOWER

FMC UI

Sur FMC naviguez vers les périphériques > la Gestion de périphériques. Choisi ajoutez >

périphérique

Dans l'hôte spécifiez l'adresse IP FTD.

●

(7)

Dans le nom d'affichage spécifiez celui que vous vouliez.

●

La clé d'enregistrement doit apparier celui spécifié dans le FTD CLI.

●

Au cas où vous utiliseriez les plusieurs domaines spécifient le domaine sous lequel vous voulez ajouter le FTD.

●

Dans le groupe, spécifiez le groupe de périphériques sous lequel vous voulez ajouter le FTD.

●

Dans la stratégie de contrôle d'accès spécifiez la stratégie de sécurité que vous voulez se déployer sur FTD.

●

Autorisation intelligente : Spécifiez les permis nécessaires requis par les caractéristiques configurées.

●

ID NAT : Nécessaire dans les scénarios spécifiques décrits plus tard dans ce document.

●

Pour des détails supplémentaires vérifiez le guide de configuration de centre de Gestion de FirePOWER, ajoutent des périphériques au centre de Gestion de FirePOWER

Scénario 1. adresse IP statique FMC et FTD

FTD CLI

>configurez le gestionnaire ajoutent le <Registration statique Key> <FMC IP>

par exemple.

> configure manager add 10.62.148.75 Cisco-123 Manager successfully configured.

Please make note of reg_key as this will be required while adding Device in FMC.

Informations générales

Dès que vous sélectionnerez la commande FTD le FTD essaye de se connecter au FMC toutes les 20 secondes, mais puisque le FMC n'est pas encore configuré il répond avec le TCP RST :

> capture-traffic

Please choose domain to capture traffic from:

0 - eth0

(8)

1 - Global Selection? 0

Please specify tcpdump options desired.

(or enter '?' for a list of supported options) Options: -n host 10.62.148.75

HS_PACKET_BUFFER_SIZE is set to 4.

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

18:53:33.365513 IP 10.62.148.42.46946 > 10.62.148.75.8305: Flags [S], seq 2274592861, win 29200, options [mss 1460,sackOK,TS val 55808298 ecr 0,nop,wscale 7], length 0

18:53:33.365698 IP 10.62.148.75.8305 > 10.62.148.42.46946: Flags [R.], seq 0, ack 2274592862, win 0, length 0

L'état d'enregistrement de périphérique :

> show managers

Host : 10.62.148.75 Registration Key : ****

Registration : pending RPC Status :

Type : Manager Host : 10.62.148.75 Registration : Pending

Le FTD écoute sur le TCP 8305 de port :

admin@vFTD66:~$ netstat -na | grep 8305

tcp 0 0 10.62.148.42:8305 0.0.0.0:* LISTEN

FMC UI

Dans ce cas, spécifiez :

Hôte (adresse IP du FTD)

●

Nom d’affichage

●

Clé d'enregistrement (ceci doit apparier celui configuré sur FTD)

●

Stratégie de contrôle d'accès

●

Domaine

●

Les informations d'autorisation intelligentes

●

(9)

Sélectionnez le registre

Les débuts de procédure d'enregistrement :

(10)

Les débuts FMC à écouter sur le TCP 8305 de port :

admin@FMC2000-2:~$ netstat -na | grep 8305

tcp 0 0 10.62.148.75:8305 0.0.0.0:* LISTEN

Àl'arrière-plan le FMC initie une connexion TCP :

20:15:55.437434 IP 10.62.148.42.49396 > 10.62.148.75.8305: Flags [S], seq 655146775, win 29200, options [mss 1460,sackOK,TS val 56302505 ecr 0,nop,wscale 7], length 0

20:15:55.437685 IP 10.62.148.75.8305 > 10.62.148.42.49396: Flags [R.], seq 0, ack 655146776, win 0, length 0

20:16:00.463637 ARP, Request who-has 10.62.148.42 tell 10.62.148.75, length 46 20:16:00.463655 ARP, Reply 10.62.148.42 is-at 00:50:56:85:7b:1f, length 28

20:16:08.342144 IP 10.62.148.42.8305 > 10.62.148.75.50693: Flags [S.], seq 1829769842, ack 2704366386, win 28960, options [mss 1460,sackOK,TS val 56303795 ecr 1181294721,nop,wscale 7], length 0

20:16:08.342322 IP 10.62.148.75.50693 > 10.62.148.42.8305: Flags [.], ack 1, win 229, options [nop,nop,TS val 1181294722 ecr 56303795], length 0

20:16:08.342919 IP 10.62.148.75.50693 > 10.62.148.42.8305: Flags [P.], seq 1:164, ack 1, win 229, options [nop,nop,TS val 1181294722 ecr 56303795], length 163

20:16:08.342953 IP 10.62.148.42.8305 > 10.62.148.75.50693: Flags [.], ack 164, win 235, options [nop,nop,TS val 56303795 ecr 1181294722], length 0

Le canal de contrôle de sftunnel est établi :

admin@FMC2000-2:~$ netstat -na | grep 8305

tcp 0 0 10.62.148.75:8305 0.0.0.0:* LISTEN tcp 0 0 10.62.148.75:50693 10.62.148.42:8305 ESTABLISHED

> sftunnel-status

SFTUNNEL Start Time: Sat Apr 18 20:14:20 2020

Both IPv4 and IPv6 connectivity is supported Broadcast count = 4

Reserved SSL connections: 0 Management Interfaces: 1

eth0 (control events) 10.62.148.42,

***********************

**RUN STATUS****ksec-fs2k-2-mgmt.cisco.com*************

Cipher used = AES256-GCM-SHA384 (strength:256 bits) ChannelA Connected: Yes, Interface eth0

ChannelB Connected: No Registration: Completed.

IPv4 Connection to peer '10.62.148.75' Start Time: Sat Apr 18 20:16:08 2020

PEER INFO:

sw_version 6.6.0 sw_build 90

Management Interfaces: 1

Peer channel Channel-A is valid type (CONTROL), using 'eth0', connected to

(11)

'10.62.148.75' via '10.62.148.42'

Peer channel Channel-B is not valid

Après quelques minutes le canal d'événement est établi. Le demandeur du canal d'événement peut être l'un ou l'autre de côté. Dans cet exemple c'était le FMC :

20:21:15.347660 IP 10.62.148.42.8305 > 10.62.148.75.43957: Flags [S.], seq 2735864611, ack 3414498582, win 28960, options [mss 1460,sackOK,TS val 56334496 ecr 1181601702,nop,wscale 7], length 0

20:21:15.347825 IP 10.62.148.75.43957 > 10.62.148.42.8305: Flags [.], ack 1, win 229, options [nop,nop,TS val 1181601703 ecr 56334496], length 0

20:21:15.348415 IP 10.62.148.75.43957 > 10.62.148.42.8305: Flags [P.], seq 1:164, ack 1, win 229, options [nop,nop,TS val 1181601703 ecr 56334496], length 163

Le port aléatoire de source dénote le demandeur de connexion :

admin@FMC2000-2:~$ netstat -na | grep 10.62.148.42

tcp 0 0 10.62.148.75:50693 10.62.148.42:8305 ESTABLISHED tcp 0 0 10.62.148.75:43957 10.62.148.42:8305 ESTABLISHED

Au cas où le canal d'événement était initié par le FTD la sortie est :

admin@FMC2000-2:~$ netstat -na | grep 10.62.148.42

Du côté FTD :

> sftunnel-status

SFTUNNEL Start Time: Sat Apr 18 20:14:20 2020

Both IPv4 and IPv6 connectivity is supported Broadcast count = 6

Reserved SSL connections: 0 Management Interfaces: 1

***********************

**RUN STATUS****ksec-fs2k-2-mgmt.cisco.com*************

Cipher used = AES256-GCM-SHA384 (strength:256 bits) ChannelA Connected: Yes, Interface eth0

Cipher used = AES256-GCM-SHA384 (strength:256 bits) ChannelB Connected: Yes, Interface eth0

Registration: Completed.

IPv4 Connection to peer '10.62.148.75' Start Time: Sat Apr 18 20:16:08 2020

PEER INFO:

sw_version 6.6.0 sw_build 90

Management Interfaces: 1

(12)

Peer channel Channel-A is valid type (CONTROL), using 'eth0', connected to '10.62.148.75' via '10.62.148.42'

Peer channel Channel-B is valid type (EVENT), using 'eth0', connected to '10.62.148.75' via '10.62.148.42'

> show managers

Type : Manager Host : 10.62.148.75 Registration : Completed

>

Adresse IP DHCP du scénario 2. FTD - Adresse IP statique FMC

Dans ce scénario, l'interface de gestion FTD a obtenu son adresse IP d'un serveur DHCP :

FTD CLI

Vous devez spécifier l'ID NAT :

>configurez le gestionnaire ajoutent le <Registration statique Key> <NAT ID> <FMC IP>

par exemple.

> configure manager add 10.62.148.75 Cisco-123 nat123 Manager successfully configured.

>

L'état d'enregistrement FTD :

> show managers

Registration : pending RPC Status :

(13)

Type : Manager Host : 10.62.148.75 Registration : Pending

FMC UI

Dans ce cas, spécifiez : Nom d’affichage

●

Domaine

●

ID NAT (ceci est exigé quand l'hôte n'est pas spécifié. Il doit apparier celui configuré sur FTD)

●

(14)

Qui initie le sftunnel dans ce cas ?

Le FTD initie les deux connexions de canal :

ftd1:/home/admin# netstat -an | grep 148.75

Adresse IP statique du scénario 3. FTD - Adresse IP DHCP FMC

> configure manager add DONTRESOLVE Cisco-123 nat123 Manager successfully configured.

>

Remarque: Avec DONTRESOLVE l'ID NAT est exigé

FMC UI

Spécifiez dans ce cas : Adresse IP FTD

●

Nom d’affichage

●

Domaine

●

ID NAT (il doit apparier celui configuré sur FTD)

●

(15)

Le FTD après l'enregistrement est fait :

> show managers

Type : Manager

Host : 5a8454ea-8273-11ea-a7d3-d07d71db8f19DONTRESOLVE Registration : Completed

Qui initie le sftunnel dans ce cas ?

Le FMC initie le canal de contrôle.

●

Le canal d'événement peut être initié par l'un ou l'autre de côté.

●

root@FMC2000-2:/Volume/home/admin# netstat -an | grep 148.42

(16)

Enregistrement du scénario 4. FTD à FMC ha

Sur FTD configurez seulement le FMC actif :

> configure manager add 10.62.184.22 cisco123 Manager successfully configured.

Remarque: Assurez-vous qu'on permet le trafic du port TCP 8305 du FTD aux les deux FMCs

D'abord, le sftunnel au FMC actif est établi :

> show managers

Type : Manager Host : 10.62.184.22 Registration : Completed

Après quelques minutes le FTD commence l'enregistrement au standby FMC :

(17)

> show managers

Dans le backend FTD, 2 canaux de contrôle (un à chaque FMC) et 2 canaux d'événement (un à chaque FMC) sont établis :

ftd1:/home/admin# netstat -an | grep 8305

tcp 0 0 10.62.148.42:8305 10.62.184.22:36975 ESTABLISHED tcp 0 0 10.62.148.42:42197 10.62.184.22:8305 ESTABLISHED tcp 0 0 10.62.148.42:8305 10.62.148.249:45373 ESTABLISHED tcp 0 0 10.62.148.42:8305 10.62.148.249:51893 ESTABLISHED

Scénario 5. FTD ha

Dans le cas de FTD ha chaque unité a un tunnel distinct au FMC :

Vous enregistrez FTDs indépendamment et alors de FMC vous formez le FTD ha. Pour plus de contrôle de détails :

Configurez la Haute disponibilité FTD sur des appliances de FirePOWER

●

Haute disponibilité pour la défense contre des menaces de FirePOWER

●

Batterie du scénario 6. FTD

Dans le cas de la batterie FTD chaque unité a un tunnel distinct au FMC. Comme de la release 6.3 FMC vous devez enregistrer seulement le maître FTD à FMC. Alors le FMC prend soin du reste des unités et automatique-les découvre + enregistre.

(18)

Remarque: Nous recommandons d'ajouter l'unité principale pour la meilleure représentation, mais vous pouvez ajouter n'importe quelle unité de la batterie. Pour le contrôle de détails supplémentaires : Créez une batterie de défense contre des menaces de FirePOWER

Dépannez les problèmes courants

1. Syntaxe non valide sur FTD CLI

En cas de syntaxe non valide sur FTD et une tentative défectueuse d'enregistrement le FMC UI affiche un message d'erreur tout à fait générique :

Dans cette commande la clé de mot clé est la clé d'enregistrement tandis que le cisco123 est l'ID NAT. Il est tout à fait commun pour ajouter la clé de mot clé tandis que techniquement il n'y a aucun un tel mot clé :

(19)

> configure manager add 10.62.148.75 key cisco123 Manager successfully configured.

Action recommandée

Utilisez la syntaxe appropriée et n'utilisez pas les mots clé qui n'existent pas.

2. non-concordance principale d'enregistrement entre FTD - FMC

Les expositions FMC UI :

Action recommandée

Sur le contrôle FTD le fichier de /ngfw/var/log/messages pour l'authentification émet.

Manière 1 – Vérifiez les logs de passé

> system support view-files

(20)

Type a sub-dir name to list its contents: s

Type the name of the file to view ([b] to go back, [Ctrl+C] to exit)

> messages

Apr 19 04:02:05 vFTD66 syslog-ng[1440]: Configuration reload request received, reloading configuration;

Apr 19 04:02:07 vFTD66 SF-IMS[3116]: [3116] pm:control [INFO] ControlHandler auditing message-

>type 0x9017, from '', cmd '/ngf

w/usr/bin/perl /ngfw/usr/local/sf/bin/run_hm.pl --persistent', pid 19455 (uid 0, gid 0) /authenticate

Apr 19 20:17:14 vFTD66 SF-IMS[18974]: [19131] sftunneld:sf_ssl [WARN] Accept: Failed to authenticate peer '10.62.148.75' <- The problem

Manière 2 – Vérifiez les logs vivants

> expert

ftd1:~$ sudo su Password:

ftd1::/home/admin# tail -f /ngfw/var/log/messages

Sur le contrôle FTD le contenu du fichier de /etc/sf/sftunnel.conf pour s'assurer que la clé d'enregistrement est correcte :

ftd1:~$ cat /etc/sf/sftunnel.conf | grep reg_key reg_key cisco-123;

3. problèmes de connectivité entre FTD - FMC

(21)

Actions recommandées

Assurez qu'il n'y a aucun périphérique dans le chemin (par exemple un Pare-feu) ce des blocs le trafic (TCP 8305). Dans le cas de FMC ha, assurez que ce trafic au port TCP 8305 est permis vers des les deux FMCs.

●

Captures de prise pour vérifier la transmission bidirectionnelle. Sur l'utilisation FTD la

commande du capture-trafic. Assurez-vous qu'il y a une prise de contact à trois voies de TCP et aucun paquets de FIN ou RST de TCP.

●

> capture-traffic

Please choose domain to capture traffic from:

0 - eth0 1 - Global Selection? 0

Please specify tcpdump options desired.

(or enter '?' for a list of supported options) Options: -n host 10.62.148.75

HS_PACKET_BUFFER_SIZE is set to 4.

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

20:56:14.397412 ARP, Request who-has 10.62.148.75 tell 10.62.148.42, length 28 20:56:14.397602 ARP, Reply 10.62.148.75 is-at a4:6c:2a:9e:ea:10, length 46

De même, prenez une capture sur FMC pour assurer la transmission bidirectionnelle :

root@FMC2000-2:/var/common# tcpdump -i eth0 host 10.62.148.42 -n -w sftunnel.pcap

Il est également recommandé pour exporter la capture dans le format de pcap et pour vérifier le contenu de paquet :

ftd1:/home/admin# tcpdump -i eth0 host 10.62.148.75 -n -w tunnel.pcap HS_PACKET_BUFFER_SIZE is set to 4.

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

Causes possibles :

Le FMC n'a pas le périphérique FTD ajouté

●

Un périphérique dans le chemin (par exemple Pare-feu) bloque ou modifie le trafic

●

Les paquets ne sont pas conduits correctement dans le chemin

●

Le processus de sftunnel sur FTD ou FMC est en baisse (scénario de contrôle 6)

●

Il y a une question de MTU dans le chemin (scénario de contrôle 8)

●

Pour le contrôle d'analyse de capture ce document :

Analysez les captures de Pare-feu de FirePOWER pour dépanner efficacement des problèmes de réseau

(22)

4. SW incompatible entre FTD – FMC

Action recommandée

Vérifiez le fichier FTD /ngfw/var/log/messages :

Apr 19 22:08:09 mzafeiro_vFTD66 SF-IMS[12730]: [12830] sftunneld:sf_connections [INFO] Need to send SW version and Published Services to 10.62.148.247

Apr 19 22:08:09 mzafeiro_vFTD66 SF-IMS[12730]: [12830] sftunneld:sf_channel [INFO] >>

ChannelState do_dataio_for_heartbeat peer 10.62.148.247 / channelA / CONTROL [ msgSock &

ssl_context ] <<

Apr 19 22:08:09 mzafeiro_vFTD66 SF-IMS[12730]: [12830] sftunneld:sf_heartbeat [INFO] Saved SW VERSION from peer 10.62.148.247 (6.5.0.4)

Apr 19 22:08:09 mzafeiro_vFTD66 SF-IMS[12730]: [12830] sftunneld:ssl_mac [WARN] FMC(manager) 10.62.148.247 send unsupported version 6.5.0.4

Apr 19 22:08:09 mzafeiro_vFTD66 SF-IMS[12730]: [12830] sftunneld:sf_connections [INFO]

<<<<<<<<<<<<<<<<<<<<<< ShutDownPeer 10.62.148.247 >>>>>>>>>>>>>>>>>>>>>>>>

Apr 19 22:08:09 mzafeiro_vFTD66 SF-IMS[12730]: [12830] sftunneld:stream_file [INFO] Stream CTX destroyed for 10.62.148.247

Apr 19 22:08:09 mzafeiro_vFTD66 SF-IMS[12730]: [12830] sftunneld:sf_channel [INFO] >>

ChannelState ShutDownPeer peer 10.62.148.247 / channelA / CONTROL [ msgSock & ssl_context ] <<

Vérifiez la matrice de compatibilité de FirePOWER : Guide de compatibilité de Cisco FirePOWER

(23)

5. Différence de temps entre FTD et FMC

La transmission FTD-FMC est sensible aux différences de temps entre les 2 périphériques. C'est une condition requise de conception de faire synchroniser FTD et FMC par le même serveur de NTP.

Spécifiquement, quand le FTD est installé sur une plate-forme comme 41xx ou 93xx il prend ses paramètres horaires du châssis de parent (FXOS).

Action recommandée

Assurez-vous que le gestionnaire de châssis (FCM) et l'utilisation FMC la même source temporelle (serveur de NTP)

6. processus de sftunnel vers le bas ou désactivé

Sur FTD le processus de sftunnel effectue la procédure d'enregistrement. C'est le statut du processus avant la configuration du gestionnaire :

> pmtool status

…

sftunnel (system) - Waiting

Command: /ngfw/usr/local/sf/bin/sftunnel -d -f /etc/sf/sftunnel.conf PID File: /ngfw/var/sf/run/sftunnel.pid

Enable File: /ngfw/etc/sf/sftunnel.conf CPU Affinity:

Priority: 0

Next start: Mon Apr 20 06:12:06 2020 Required by: sfmgr,sfmbservice,sfipproxy CGroups: memory=System/ProcessHigh

L'état d'enregistrement :

> show managers

No managers configured.

Configurez le gestionnaire :

(24)

Maintenant le processus est EN HAUSSE :

> pmtool status

…

sftunnel (system) - Running 24386

Command: /ngfw/usr/local/sf/bin/sftunnel -d -f /etc/sf/sftunnel.conf PID File: /ngfw/var/sf/run/sftunnel.pid

Priority: 0

Next start: Mon Apr 20 07:12:35 2020 Required by: sfmgr,sfmbservice,sfipproxy CGroups: memory=System/ProcessHigh(enrolled)

Dans des quelques rares cas le processus peut être en baisse ou désactivé :

> pmtool status

…

sftunnel (system) - User Disabled

Command: /ngfw/usr/local/sf/bin/sftunnel -d -f /etc/sf/sftunnel.conf PID File: /ngfw/var/sf/run/sftunnel.pid

Priority: 0

Next start: Mon Apr 20 07:09:46 2020 Required by: sfmgr,sfmbservice,sfipproxy CGroups: memory=System/ProcessHigh

L'état de gestionnaire semble normal :

> show managers

Registration : pending RPC Status :

D'autre part, l'enregistrement de périphérique échoue :

(25)

Sur FTD il n'y a aucun message associé vu dans /ngfw/var/log/messages Action recommandée

Collectez le FTD dépannent le fichier et contactent Cisco TAC

7. Enregistrement en attendant FTD sur FMC secondaire

Il y a des scénarios où après que l'enregistrement de l'initiale FTD à un FMC ha ait installé le périphérique FTD n'est pas ajouté au FMC secondaire.

Action recommandée

Suivez la procédure décrite dans ce document :

Utilisant le CLI pour résoudre l'enregistrement de périphérique en Gestion de FirePOWER centrez la Haute disponibilité

Avertissement : Cette procédure est intrusive puisqu'elle contient un unregistration de périphérique. Ceci affecte la configuration de périphérique FTD (il est supprimé). Il est recommandé pour utiliser cette procédure seulement pendant l'enregistrement et

l'installation de l'initiale FTD. Dans le cas différent collectez FTD et FMC dépannent des fichiers et contactent Cisco TAC.

8. L'enregistrement échoue en raison du MTU de chemin

Il y a des scénarios vus à Cisco TAC où le trafic de sftunnel doit traverser un lien qui a le petit

(26)

MTU. On ne laisse pas les paquets de sftunnel ont ne fragmentent pas la fragmentation réglée ainsi par bit :

Supplémentaire, dans /ngfw/var/log/messages vous classe peut voir un message comme ceci : MSG : 10-09 14:41:11 ftd1 SF-IMS[7428] : sftunneld [6612] : le sf_ssl [ERREUR] se connectent : La prise de contact SSL a manqué

Action recommandée

Pour vérifier s'il y a perte de paquets due aux captures de prise de fragmentation sur FTD, FMC, et idéalement sur des périphériques dans le chemin. Vérifiez si vous voyez des paquets arriver sur les deux extrémités.

Sur FTD diminuez le MTU sur l'interface de gestion FTD. La valeur par défaut est de 1500 octets.

Le max est 1500 pour l'interface de gestion et 9000 pour l'interface de concours complet. La commande a été ajoutée dans la release FTD 6.6.

Référence de commandes de défense contre des menaces de Cisco FirePOWER Exemple

> configure network mtu 1300

MTU set successfully to 1300 from 1500 for eth0 Refreshing Network Config...

Interface eth0 speed is set to '10000baseT/Full'

Vérification

> show network

===============[ System Information ]===============

Hostname : ksec-sfvm-kali-3.cisco.com DNS Servers : 173.38.200.100

Management port : 8305 IPv4 Default route

Gateway : 10.62.148.1

(27)

Netmask : 0.0.0.0

======================[ eth0 ]======================

State : Enabled Link : Up

Channels : Management & Events Mode : Non-Autonegotiation MDI/MDIX : Auto/MDIX

MTU : 1300

MAC Address : 00:50:56:85:7B:1F

---[ IPv4 ]--- Configuration : Manual

Address : 10.62.148.42 Netmask : 255.255.255.128 Gateway : 10.62.148.1

---[ IPv6 ]---

Pour vérifier le MTU de chemin du FTD vous pouvez utiliser cette commande :

root@firepower:/home/admin# ping -M do -s 1500 10.62.148.75

Faites l'option place ne fragmentent pas le bit dans les paquets d'ICMP

Sur FMC diminuez la valeur de MTU sur l'interface de gestion FMC comme décrit dans ce document :

Configurez les interfaces de gestion de centre de Gestion de FirePOWER

9. FTD obtient des non enregistrés après qu'une modification de bootstrap du gestionnaire UI de châssis

Ce s'applique aux Plateformes FP41xx et FP93xx et documenté dans CSCvn45138 .

Généralement vous ne devez pas faire des modifications de bootstrap du gestionnaire de châssis (FCM) à moins que vous fassiez une Reprise sur sinistre.

Action recommandée

Au cas où vous une modification faisiez bootstrap et vous avez apparié la condition (la

transmission FTD-FMC est cassée tandis que le FTD monte après la modification de bootstrap) que vous devez supprimer et enregistrer de nouveau le FTD à FMC.

10. FTD perd Access à FMC dû à l'ICMP réoriente des messages

(28)

Cette question peut affecter la procédure d'enregistrement ou interrompre la transmission FTD- FMC après l'enregistrement.

Le problème est dans ce cas un périphérique de réseau qui envoie l'ICMP réorientent des messages à l'interface de gestion FTD et à la transmission des trous noirs FTD-FMC.

Comment identifier ce problème

Dans ce cas, 10.100.1.1 est l'adresse IP FMC. Sur FTD il y a une artère cachée due à l'ICMP réorientent le message qui a été reçu par le FTD sur l'interface de gestion :

ftd1:/ngfw/var/common# ip route get 10.100.1.1 10.100.1.1 via 10.10.1.1 dev br1 src 10.10.1.23 cache <redirected>

Action recommandée

Étape 1

Désactivez l'ICMP réorientent sur le périphérique qui l'envoie (par exemple commutateur L3 en amont, routeur, etc.)

Étape 2

Effacez le cache d'artère FTD. Du FTD CLI :

ftd1:/ngfw/var/common# ip route flush 10.100.1.1

Quand il n'est pas réorienté il ressemble à ceci :

ftd1:/ngfw/var/common# ip route get 10.100.1.1 10.100.1.1 via 10.62.148.1 dev eth0 src 10.10.1.23 cache mtu 1500 advmss 1460 hoplimit 64

Références

Les compréhensions de l'ICMP réorientent des messages

●

CSCvm53282 FTD : Les tables de routage ajoutées par ICMP réoriente est bloqué dans le cache de table de routage pour toujours

●

11. L'adresse IP n'est pas accessible

Dans ce cas, l'IP de capteur n'est pas accessible

(29)

Informations connexes

Guide de configuration de centre de Gestion de FirePOWER, version 6.6

●

BRKSEC-3455 Berlin 2017 - FirePOWER de dissection NGFW(FTD) et services « conception et dépannage » de FirePOWER

●