Fehlerbehebung bei Bereitstellungen von Firepower Threat Defense-Richtlinien

Einleitung

Dieses Dokument beschreibt einen allgemeinen Überblick über den Richtlinienbereitstellungsprozess für FTD sowie grundlegende Fehlerbehebungstechniken. 

Hintergrundinformationen

Mit Cisco Firepower Threat Defense (FTD), den herkömmlichen Stateful-Firewall-Funktionen von Adaptive Security Appliances (ASA) Next-Gen Firewall-Funktionen (unterstützt durch Snort) werden nun zu einem Produkt zusammengefasst.

Aufgrund dieser Änderung Policy Deployment Infrastructure auf FTD verarbeitet jetzt Konfigurationsänderungen für ASA-Code (auch als LINA bezeichnet) und Snort in einem Paket. 

Voraussetzungen

Cisco empfiehlt, mit folgenden Produkten vertraut zu sein:

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

Verwendete Komponenten

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Übersicht über die Richtlinienbereitstellung

Cisco FTD nutzt Policy Deployments Sie dient zum Verwalten und Übertragen von Konfigurationen für Geräte, die beim Firepower Management Center (FMC) selbst.

Innerhalb der Bereitstellung gibt es eine Reihe von Schritten, die in "Phasen" unterteilt sind.

Die FMC-Phasen können in dieser Liste zusammengefasst werden.

Phase 0	Initialisierung der Bereitstellung
Phase 1	Datenbankobjektsammlung
Phase 2	Richtlinien- und Objektsammlung
Phase 3	NGFW - Befehlszeilenkonfiguration
Phase 4	Paketgenerierung für die Gerätebereitstellung
Phase 5	Senden und Empfangen des Bereitstellungspakets
Phase 6	Ausstehende Meldungen zu Bereitstellung, Bereitstellungsaktionen und erfolgreichen Bereitstellungen

Die Kenntnis der Phasen und des Standorts von Fehlern im Prozess kann bei der Fehlerbehebung helfen, wenn ein Firepower Systemseiten.

In einigen Fällen kann es sich um einen Konflikt aufgrund früherer Konfigurationen oder aufgrund eines Advanced Flex Configuration das kein Schlüsselwort hat, das Fehler verursachen kann, die im Gerätebericht nicht behandelt werden.

Beispielübersicht

Schritt 1: Klicken Sie auf Deployment, der das auszuwählende Gerät angibt.

Schritt 2: Wenn die Bereitstellung für ein Gerät bestätigt wird, beginnt das FMC mit der Erfassung aller für das Gerät relevanten Konfigurationen. 

Schritt 3: Wenn die Konfigurationen erfasst werden, erstellt das FMC das Paket und sendet es über seinen Kommunikationsmechanismus namens SFTunnel an den Sensor.

Schritt 4: Das FMC benachrichtigt den Sensor, den Bereitstellungsprozess mit der bereitgestellten Richtlinie zu starten, während es auf die einzelnen Antworten wartet.

Schritt 5: Das verwaltete Gerät entpackt das Archiv und beginnt mit der Anwendung der einzelnen Konfigurationen und Pakete.

Antwort: Die erste Hälfte der Bereitstellung besteht aus dem Snort Konfiguration, bei der Snort -Konfiguration lokal getestet, um ihre Gültigkeit zu gewährleisten.

Wenn sich herausstellt, dass die neue Konfiguration gültig ist, wird sie in das Produktionsverzeichnis verschoben für Snort. Wenn die Validierung fehlschlägt, schlägt die Richtlinienbereitstellung in diesem Schritt fehl.

B. Die zweite Hälfte der Bereitstellungspaketlast betrifft die LINA-Konfiguration, in der sie vom ngfwManager-Prozess direkt auf den LINA-Prozess angewendet wird.

Wenn ein Fehler auftritt, werden die Änderungen zurückgesetzt, und es tritt ein Fehler bei der Richtlinienbereitstellung auf.

Schritt 6: Wenn beide Snort und LINA-Pakete erfolgreich sind, signalisiert das verwaltete Gerät Snort , um die neue Konfiguration neu zu starten oder neu zu laden und alle aktuellen Konfigurationen zu speichern.

Schritt 7. Wenn alle Meldungen erfolgreich sind, sendet der Sensor eine Erfolgsmeldung und wartet darauf, dass diese vom Management Center bestätigt wird.

Schritt 8: Nach Erhalt markiert das FMC die Aufgabe als erfolgreich und ermöglicht das Fertigstellen des Richtlinienpakets.

Fehlerbehebung

Probleme während Policy Deployment Gründe hierfür sind u. U.:

1. Fehlkonfiguration
2. Kommunikation zwischen FMC und FTD
3. Datenbank- und Systemstatus
4. Softwarefehler und Hinweise
5. Andere spezielle Situationen

Einige dieser Probleme können leicht behoben werden, während andere die Unterstützung von Cisco erfordern. Technical Assistance Center (TAC).

In diesem Abschnitt sollen Verfahren zur Isolierung des Problems und zur Ermittlung der Ursache beschrieben werden. 

Grafische Benutzeroberfläche (GUI) von FMC 

Cisco empfiehlt für Bereitstellungsfehler, jede Fehlerbehebungssitzung auf der FMC-Appliance zu starten.

Im Fehlerbenachrichtigungsfenster gibt es für alle Versionen nach 6.2.3 zusätzliche Tools, die bei anderen möglichen Fehlern helfen können. 

Verwendung der Bereitstellungsprotokolle

Schritt 1: Ziehen Sie Deployments in der FMC-Webbenutzeroberfläche.

Schritt 2: Während die Deployments ist ausgewählt. Klicken Sie auf Show History.

Schritt 3: Innerhalb des Deployment History alle früheren Bereitstellungen von Ihrem FMC aus sehen. Wählen Sie die Bereitstellung aus, in der Sie weitere Daten anzeigen möchten.

Schritt 4: Sobald ein Bereitstellungselement ausgewählt wurde, Deployment Details zeigt eine Liste aller Geräte innerhalb des Transaction. Diese Einträge werden in folgende Spalten unterteilt: Device Number, Device Name, Status,und Transcript.

Schritt 5: Wählen Sie das betreffende Gerät aus, und klicken Sie auf die Transkriptionsoption, um das jeweilige Bereitstellungsprotokoll anzuzeigen, das Sie über Fehler und Konfigurationen auf den verwalteten Geräten informieren kann.

Schritt 6: Dieses Transkript kann bestimmte Fehlerbedingungen festlegen und eine sehr wichtige Zahl für den nächsten Schritt angeben: Transaction ID.

Schritt 7. In einem Firepower Deployment,Die Fehlermeldung Transaction ID kann verwendet werden, um die einzelnen Abschnitte einer Richtlinienbereitstellung zu verfolgen. Dadurch können Sie über die Befehlszeile des Geräts eine detailliertere Version dieser Daten für die Sanierung und Analyse abrufen.

Tipp: Falls Sie die Transaktions-ID nicht finden können oder sich in einer Version befinden, bevor diese gedruckt wurde, kann dieses Protokoll weiterhin zum Auffinden einzelner Fehlermeldungen verwendet werden.

Fehlerbehebung mit FMC-Protokollen

Obwohl es angemessen ist, das Cisco TAC für die Analyse der Protokolle zu beauftragen, kann eine Suche in den Protokollen bei der anfänglichen Problemisolierung und der schnelleren Behebung helfen. Es gibt mehrere Protokolldateien auf FMC, in denen die Details des Richtlinienbereitstellungsprozesses aufgezeigt werden.

Die beiden am häufigsten genannten Protokolle sind policy_deployment.log und usmsharedsvcs.log.

Alle in diesem Dokument erwähnten Dateien können mit mehreren Linux-Befehlen angezeigt werden, z. B. more, less und vi. Es muss jedoch unbedingt sichergestellt werden, dass nur read Aktionen ausgeführt werden. Alle Dateien benötigen Root-Zugriff, um sie anzeigen zu können.

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

Dieses Protokoll kennzeichnet den Beginn der Richtlinienbereitstellungsaufgabe auf dem FMC und den Abschluss jeder Phase. So kann festgestellt werden, in welcher Phase die Bereitstellung fehlschlug, und der Fehlercode angegeben werden.

Die Fehlermeldung transactionID -Wert, der im JSON-Teil des Protokolls enthalten ist, verwendet werden kann, um Protokolleinträge zu finden, die sich auf einen bestimmten Bereitstellungsversuch beziehen.

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

Diese Protokolldatei existiert bereits in 6.x Versionen, die bei 6.4 beginnen, aber ihre Abdeckung wurde erweitert.

Es beschreibt nun die detaillierten Schritte, die von FMC zur Erstellung der Bereitstellungspakete unternommen wurden. Daher wird es am besten für die Analyse von Ausfällen aus Phase 1 - 4 verwendet.

Der Beginn jeder Phase ist durch eine Zeile mit "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)
...

Fehlerbehebung für verwaltete Geräte

Es gibt weitere Phasen und Abschnitte, die vom Gerätepaket, der Hochverfügbarkeitskonfiguration und dem Ergebnis früherer Phasen für jedes verwaltete Gerät abhängen.

Wenn ein Bereitstellungsproblem auf einen Fehler auf dem verwalteten Gerät zurückgeführt wird, kann eine weitere Fehlerbehebung auf dem Gerät mit zwei Protokollen auf dem Gerät durchgeführt werden: policy_deployment.log und ngfwManager.log.

/ngfw/var/log/ngfwManager.log

Diese Protokolldatei enthält detaillierte Schritte, Config Communication Manager und Config Dispatcher um mit FMC zu kommunizieren, mit dem Bereitstellungspaket zu arbeiten und die Validierung und Anwendung von Snort- und LINA-Konfigurationen zu orchestrieren.

Dies sind einige Beispiele für ngfwManager.log, die den Beginn der Hauptphasen darstellen:

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

Dieses Protokoll enthält die Details der Richtlinie, auf die Snort. Obwohl der Inhalt des Protokolls größtenteils fortgeschritten ist und eine Analyse durch das TAC erfordert, ist es immer noch möglich, den Prozess mit einigen Schlüsseleinträgen zu verfolgen:

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)

Beispiel

Schritt 1: Eine Bereitstellung schlägt fehl

Schritt 2: Rufen Sie die Deploy Transcript und Transaction ID.

Schritt 3: SSH in Ihre Management Center und verwende das Linux-Dienstprogramm less , um die Datei wie auf Ihrem FMC angezeigt zu lesen:

Beispiel:"sudo less /var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log" (Das sudo-Kennwort ist Ihr Benutzerkennwort für SSH)

Schritt 4: Wenn Sie lessverwenden Sie einen Schrägstrich und geben Sie die Nachrichten-ID ein, um nach Protokollen zu suchen, die sich auf die Bereitstellungstransaktions-ID beziehen. 

Beispiel:"/60129547881" (Während in less, verwenden Sie n, um zum nächsten Ergebnis zu navigieren)

Beispiel für eine laufende Nachricht:

Beispiel einer Fehlermeldung:

5) Vergleichen Sie den ordnungsgemäßen Fehler mit der beigefügten Tabelle mit häufigen Fehlermeldungen.

 Das heißt, dass "failed_to_restore_running_configuration" bei Kommunikationsfehlern zwischen den beiden Geräten auftritt. 

Häufige Fehlermeldungen

Dies sind häufige Fehlermeldungen, die am Front-End des Management Center Task sowie den Fehlercode, der im Backend zu sehen ist.

Diese Botschaften können analysiert und mit den gängigen Gründen für mögliche Lösungen verglichen werden.

Falls diese nicht erkannt werden oder sich Ihre Situation nicht beheben lässt, wenden Sie sich bitte an das TAC. 

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

TAC-Unterstützung kontaktieren

Falls die vorherigen Informationen keine Fortsetzung der Richtlinienbereitstellung ermöglichen oder das Problem nicht mit einem bereits vorhandenen dokumentierten Verhalten zusammenhängt, verwenden Sie bitte die im nächsten Link aufgeführten Schritte, um eine Problembehebungsdatei zu erstellen und das TAC zur Analyse und zur Fehlererstellung zu kontaktieren.

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