Dépannage des déploiements de politiques de défense Firepower

Introduction

Ce document décrit une présentation générale du processus de déploiement des stratégies sur le FTD et les techniques de dépannage de base. 

Informations générales

Avec Cisco Firepower Threat Defense (FTD), les fonctionnalités de pare-feu avec état classiques offertes par Adaptive Security Appliances (ASA) et Next-Gen fonctionnalités de pare-feu (optimisées par Snort) sont désormais regroupés en un seul produit.

En raison de ce changement, Policy Deployment Infrastructure sur FTD gère désormais les modifications de configuration pour le code ASA (également appelé LINA) et Snort dans une offre groupée. 

Conditions préalables

Cisco recommande de connaître ces produits :

• Firepower Management Center (FMC)
• Firepower Threat Defense (FTD)

Composants utilisés

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.

Présentation du déploiement des politiques

Utilisation de Cisco FTD Policy Deployments pour gérer et diffuser les configurations des périphériques enregistrés auprès de Firepower Management Center (FMC).

À l'intérieur du déploiement, une série d'étapes sont divisées en « phases ».

Les phases FMC peuvent être résumées dans cette liste.

Phase 0	Initialisation du déploiement
Phase 1	Database Object, collection
Phase 2	Collection Policy and Object
Phase 3	Génération de la configuration de ligne de commande NGFW
Phase 4	Génération de package de déploiement de périphérique
Phase 5	Envoi et réception du package de déploiement
Phase 6	Messages de déploiement, d'actions de déploiement et de réussite de déploiement en attente

La connaissance des phases et de l'emplacement des pannes dans le processus peut aider à dépanner les pannes qu'un Firepower faces du système.

Dans certaines situations, il peut s'agir d'un conflit dû à des configurations précédentes ou causé par un Advanced Flex Configuration qui ne contient pas de mot clé pouvant entraîner des défaillances auxquelles le rapport de périphérique ne répond pas.

Exemple de présentation

Étape 1. Cliquer Deployment, qui spécifie le périphérique à sélectionner.

Étape 2. Lorsque le déploiement d’un périphérique est validé, le FMC commence à collecter toutes les configurations pertinentes pour le périphérique. 

Étape 3. Lorsque les configurations sont collectées, le FMC crée le package et l'envoie au capteur via son mécanisme de communication appelé SFTunnel.

Étape 4. Le FMC avertit le capteur qu'il doit démarrer le processus de déploiement avec la stratégie fournie pendant qu'il écoute les réponses individuelles.

Étape 5. Le périphérique géré déballe l'archive et commence à appliquer les configurations et packages individuels.

R. La première moitié du déploiement est la Snort où la configuration Snort La configuration est testée localement pour garantir sa validité.

Une fois la validité établie, la nouvelle configuration est déplacée vers le répertoire de production pour Snort. Si la validation échoue, le déploiement de la stratégie échoue à cette étape.

B. La seconde moitié de la charge du package de déploiement concerne la configuration LINA, où elle est appliquée directement au processus LINA par le processus ngfwManager.

En cas d'échec, les modifications sont annulées et un échec du déploiement de la stratégie se produit.

Étape 6. Si les deux Snort et les packages LINA sont réussis, les périphériques gérés signalent Snort pour redémarrer ou recharger afin de charger la nouvelle configuration et enregistrer toutes les configurations actuelles.

Étape 7. Si tous les messages aboutissent, le capteur envoie un message de réussite et attend qu'un accusé de réception soit envoyé par le centre de gestion.

Étape 8. Une fois reçu, le FMC marque la tâche comme un succès et permet à l'ensemble de politiques de se terminer.

Dépannage

Problèmes rencontrés pendant Policy Deployment peut être due, sans s'y limiter :

1. Mauvaise Configuration
2. Communication entre le CSP et le DFT
3. Intégrité de la base de données et du système
4. Défauts logiciels et avertissements
5. Autres situations uniques

Certains de ces problèmes peuvent être facilement résolus, tandis que d'autres peuvent nécessiter l'assistance de Cisco Technical Assistance Center (TAC).

L'objectif de cette section est de fournir des techniques permettant d'isoler le problème ou de déterminer la cause première. 

Interface graphique utilisateur (GUI) FMC 

Cisco recommande que chaque session de dépannage pour les échecs de déploiement démarre sur l'appliance FMC.

Dans la fenêtre de notification de panne, sur toutes les versions au-delà de 6.2.3, il y a des outils supplémentaires qui peuvent aider avec d'autres pannes possibles. 

Utiliser Les Transcriptions De Déploiement

Étape 1. Relevez le Deployments dans l'interface utilisateur Web de FMC.

Étape 2. Alors que la Deployments est sélectionné, cliquez sur Show History.

Étape 3. À l'intérieur Deployment History , vous pouvez voir tous les déploiements précédents de votre FMC. Sélectionnez le déploiement dans lequel vous souhaitez afficher plus de données.

Étape 4. Une fois un élément de déploiement sélectionné, la Deployment Details La sélection affiche la liste de tous les périphériques du Transaction. Ces entrées sont réparties dans les colonnes suivantes : Device Number, Device Name, Status,et Transcript.

Étape 5. Sélectionnez le périphérique en question et cliquez sur l'option de transcription pour afficher la transcription de déploiement individuelle qui peut vous informer des défaillances ainsi que des configurations qui sont placées sur les périphériques gérés.

Étape 6. Cette transcription peut indiquer certaines conditions d'échec ainsi qu'un nombre très important pour l'étape suivante : Transaction ID.

Étape 7. Dans un Firepower Deployment,les Transaction ID est ce qui peut être utilisé pour suivre chaque section individuelle d'un déploiement de stratégie. Grâce à cela, sur la ligne de commande du périphérique, vous pouvez obtenir une version plus approfondie de ces données pour la correction et l'analyse.

Conseil : si vous ne parvenez pas à localiser l'ID de transaction ou si vous disposez d'une version antérieure à l'impression, ce journal peut toujours être utilisé pour localiser les messages d'échec individuels.

Dépannage avec les journaux FMC

Bien qu'il soit approprié de faire appel au centre d'assistance technique Cisco pour analyser les journaux, une recherche dans les journaux peut vous aider à identifier le problème initial et à accélérer sa résolution. Il existe plusieurs fichiers journaux sur FMC qui révèlent les détails du processus de déploiement de la stratégie.

Les deux journaux les plus souvent référencés sont : policy_deployment.log et usmsharedsvcs.log.

Tous les fichiers mentionnés dans ce document peuvent être visualisés avec plusieurs commandes Linux telles que more, less et vi. Toutefois, il est très important de veiller à ce que read des actions lui sont appliquées. Tous les fichiers nécessitent un accès racine pour pouvoir les afficher.

/var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log

Ce journal marque clairement le début de la tâche de déploiement de stratégie sur FMC et la fin de chaque phase, ce qui permet de déterminer la phase où le déploiement a rencontré une défaillance, ainsi que le code de défaillance.

Les transactionID La valeur incluse dans la partie JSON du journal peut être utilisée pour rechercher des entrées de journal associées à une tentative de déploiement particulière.

22-Nov-2019 01:28:52.844,[INFO],(DefenseCenterServiceImpl.java:1372)
com.cisco.nm.vms.api.dc.DefenseCenterServiceImpl, ajp-nio-127.0.0.1-9009-exec-4
** REST Request [ CSM ]
** ID : e1c84364-0966-42eb-9356-d2914be2b4a3
** URL: Broadcast message.send.deployment
{
  "body" : {
    "property" : "deployment:deployment_initiated_for_the_device",
    "argumentList" : [ {
      "key" : "PHASE",
      "value" : "Phase-0"
    } ]
  },
  "user" : "68d03c42-d9bd-11dc-89f2-b7961d42c462",
  "type" : "deployment",
  "status" : "running",
  "progress" : 5,
  "silent" : true,
  "restart" : true,
  "transactionId" : 12884916552,
  "devices" : [ "93a2089a-fa82-11e9-8219-e1abeec81dc9" ]
}

/var/log/sf/policy_deployment.log

Bien que ce fichier journal ait existé dans toutes les versions 6.x, qui commencent à la version 6.4, sa couverture a été étendue.

Il décrit maintenant les étapes détaillées effectuées sur FMC pour créer les packages de déploiement. Il est donc préférable de l'utiliser pour analyser les échecs des phases 1 à 4.

Le début de chaque phase est marqué par une ligne avec "INFO start. ":

Jul 18 17:20:03 firepower ActionQueueScrape.pl[17287]: INFO starting populateGlobalSnapshot - sqlite = /var/cisco/umpd/8589938337/DC_policy_deployment.db, transaction = 8589938337, time = 1563470402, running as (memory = 56.35 MB) (Framework 3950<196 <- CSMTasks 223<10 <- SF::ActionQueue 2457)
Jul 18 17:20:03 firepower ActionQueueScrape.pl[17287]: INFO deployment threading: disabled (Framework 198 <- CSMTasks 223<10 <- SF::ActionQueue 2457)
Jul 18 17:20:03 firepower ActionQueueScrape.pl[17287]: INFO -> calling SF::UMPD::Plugins::Correlation::Manager::getPluginDependencies (Plugin 298<90 <- Framework 3579<3566<216 <- CSMTasks 223)
...

Dépannage des périphériques gérés

D'autres phases et sections dépendent du package de périphériques, de la configuration de la haute disponibilité et du résultat des phases précédentes pour chaque périphérique géré.

Si un problème de déploiement est isolé en raison d'une défaillance sur le périphérique géré, un dépannage supplémentaire peut être effectué sur le périphérique avec deux journaux sur le périphérique : policy_deployment.log et ngfwManager.log.

/ngfw/var/log/ngfwManager.log

Ce fichier journal décrit en détail les étapes suivies par Config Communication Manager et Config Dispatcher pour communiquer avec FMC, travailler avec le package de déploiement et orchestrer la validation et l'application des configurations Snort et LINA.

Voici quelques exemples de ngfwManager.log qui représentent le début des phases principales :

FTD receives FMC's request for running configuration:

May 30 16:37:10 ccm[4293] Thread-10: INFO  com.cisco.ccm.ConfigCommunicationManager- Passing CD-Message-Request to Config Dispatcher...
May 30 16:37:10 ccm[4293] Thread-10: DEBUG com.cisco.ccm.ConfigCommunicationManager- <?xml version="1.0" encoding="UTF-8"?><cdMessagesList><timeStamp>1559234230012</timeStamp><cdMessage><name>LinaShowCommand</name><messageId>-753133537443151390</messageId><contentType>XML</contentType><msgContent><![CDATA[<?xml version="1.0" encoding="UTF-8"?><message><name>LinaShowCommand</name>...



FTD receives FMC's request to download the deployment package:

May 30 16:37:18 ccm[4293] Thread-9: INFO  com.cisco.ccm.ConfigCommunicationManager- Downloading database (transaction 8589938211, version 1559234236)
May 30 16:37:18 ccm[4293] Thread-9: DEBUG com.cisco.ccm.DownloadManager- handle record: 8589938211, status = PENDING
May 30 16:37:18 ccm[4293] Thread-9: DEBUG com.cisco.ccm.DownloadManager- begin downloading database



FTD begins the deployment of policy changes:

May 30 16:37:21 ccm[4293] Thread-9: INFO  com.cisco.ccm.ConfigCommunicationManager- Starting deployment
May 30 16:37:21 ccm[4293] Thread-11: INFO  com.cisco.ccm.ConfigCommunicationManager- Sending message: DEPLOYMENT_STATUS_CCM to Manager



FTD begins LINA deployment:

May 30 16:37:42 ccm[4293] Thread-19: DEBUG com.cisco.ngfw.configdispatcher.communicators.LinaCommunicatorImpl- Trying to send Start-Config-Sequencerequest to lina



FTD begins finalizing the deployment:

May 30 16:38:48 ccm[4293] Thread-19: DEBUG com.cisco.ngfw.configdispatcher.communicators.LinaCommunicatorImpl- Clustering Message sent out of ConfigDispatcher:
Name:Cluster-App-Conf-Finalize-Request

/ngfw/var/log/sf/policy_deployment.log

Ce journal contient les détails de la stratégie appliquée à Snort. Bien que le contenu du journal soit principalement avancé et nécessite une analyse par le TAC, il est toujours possible de tracer le processus avec quelques entrées clés :

Config Dispatcher begins extracting the packaged policies for validation:

Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO  -> calling SF::UMPD::Plugins::NGFWPolicy::Device::exportDeviceSnapshotToSandbox  (Plugin 230 <- Framework 611 <- Transaction 1085)
Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO  found NGFWPolicy =>   (NGFWPolicy::Util 32 <- NGFWPolicy::Device 43 <- Plugin 235)
...
Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO export FTD platform settings... (PlatformSettings::FTD::Device 29 <- Plugin 235<339 <- PlatformSettings::Device 13)



Config validation begins:

Jul 18 17:21:37 firepower policy_apply.pl[25122]: INFO  starting validateExportedFiles - sqlite = /var/cisco/deploy/sandbox/policy_deployment.db, sandbox = /var/cisco/deploy/sandbox/exported-files (memory = 229.99 MB)  (Framework 3950<687 <- Transaction 1101 <- main 194)



Validation has completed successfully:

Jul 18 17:21:49 firepower policy_apply.pl[25122]: INFO validateExportedFiles - sqlite = /var/cisco/deploy/sandbox/policy_deployment.db, sandbox = /var/cisco/deploy/sandbox/exported-files took 12 (memory = 238.50 MB, change = 8.51 MB) (Framework 3976<724 <- Transaction 1101 <- main 194) 



Config Dispatcher begins moving the validated configuration to the Snort directories in production:

Jul 18 17:21:54 firepower policy_apply.pl[26571]: INFO  -> calling SF::UMPD::Plugins::NGFWPolicy::Device::publishExportedFiles  (Plugin 230 <- Framework 822 <- Transaction 1662)



Snort processes will reload to apply the new configurations:

Jul 18 17:22:02 firepower policy_apply.pl[26571]: INFO  Reconfiguring DE a3bcd340-992f-11e9-a1f1-ac829f31a4f9...  (Snort::SnortNotifications 292<154 <- Snort::Device 343 <- Plugin 235)
Jul 18 17:22:02 firepower policy_apply.pl[26571]: INFO  sending SnortReload to a3bcd340-992f-11e9-a1f1-ac829f31a4f9  (Snort::SnortNotifications 298<154 <- Snort::Device 343 <- Plugin 235)



Snort reload has completed successfully:

Jul 18 17:22:14 firepower policy_apply.pl[26571]: INFO notifyProcesses - sandbox = /var/cisco/deploy/sandbox/exported-files took 16 (memory = 169.52 MB, change = 16.95 MB) (Framework 3976<964 <- Transaction 1680 <- main 200)



After LINA config apply finishes, Snort deployment is finalized:

Jul 18 17:23:32 firepower policy_apply.pl[26913]: INFO  starting finalizeDeviceDeployment - sandbox = /var/cisco/deploy/sandbox (memory = 101.14 MB)  (Framework 3950<980 <- Transaction 1740 <- main 206)

Exemple

Étape 1. Un déploiement échoue

Étape 2. Obtenir le Deploy Transcript et Transaction ID.

Étape 3. SSH dans votre Management Center et utiliser l'utilitaire Linux less pour lire le fichier comme indiqué sur votre FMC :

Exemple :"sudo less /var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log" (Le sudo password est le mot de passe de vos utilisateurs pour ssh)

Étape 4. Lorsque vous êtes dans less, utilisez la barre oblique et entrez l'ID du message pour rechercher les journaux associés à l'ID de transaction du déploiement. 

Exemple : "/60129547881" (en cours less, utilisez n pour passer au résultat suivant)

Exemple de message en cours d'exécution :

Exemple de message d'échec :

5) Comparez la défaillance appropriée à la table jointe des messages de défaillance courants.

 C'est-à-dire failed_to_recover_running_configuration se produit lors d'échecs de communication entre les deux périphériques. 

Messages d'échec courants

Il s'agit de messages d'échec courants, visibles à l'avant du Management Center Task ainsi que le code d'erreur qui peut être vu dans le back-end.

Ces messages peuvent être analysés et comparés avec les raisons communes des résolutions possibles.

Si vous ne les voyez pas ou si elles ne résolvent pas votre situation, veuillez contacter le TAC pour obtenir de l'aide. 

----------------------------------------------------------------------------------------

Contactez le TAC pour obtenir de l'aide

Si les informations précédentes ne permettent pas le déploiement d'une stratégie, ou si le problème ne semble pas être lié à un comportement documenté préexistant, veuillez suivre les étapes fournies dans le lien suivant pour générer un fichier de dépannage et contacter le TAC pour une analyse et la création de bogues.

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