In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
Dieser Artikel ist Teil einer Reihe von Artikeln, in denen erläutert wird, wie der Datenpfad auf FirePOWER-Systemen systematisch behoben wird, um festzustellen, ob Komponenten von FirePOWER den Datenverkehr beeinträchtigen können. Weitere Informationen zur Architektur von FirePOWER-Plattformen und Links zu anderen Artikeln zur Fehlerbehebung für Datenpfade finden Sie im Übersichtsartikel.
In diesem Artikel betrachten wir die zweite Phase der Fehlerbehebung für den FirePOWER-Datenpfad: die Datenerfassungs-Schicht (DAQ).
Die folgende Tabelle beschreibt die in diesem Artikel behandelten Plattformen.
Plattformcode-Name | Beschreibung | Anwendbar Hardware Plattformen | Hinweise |
SFR | Installiertes ASA mit FirePOWER Services (SFR)-Modul. | Serie ASA-5500-X | K/A |
FTD (alle) | Gilt für alle Firepower Threat Defense (FTD)-Plattformen | ASA-5500-X-Serie, virtuelle NGFW-Plattformen, FPR-2100, FPR-9300, FPR-4100 | K/A |
FTD (nicht SSP und FPR-2100) | FTD-Image auf einer ASA oder virtuellen Plattform installiert | ASA-5500-X-Serie, virtuelle NGFW-Plattformen, FPR-2100 | K/A |
FTD (SSP) | FTD als logisches Gerät auf einem FXOS-basierten Chassis (FirePOWER eXtensible Operative System) installiert | FPR-9300, FPR-4100 | Die Serie 2100 verwendet den FXOS Chassis Manager nicht. |
Die Datenerfassungs-Schicht (DAQ) ist eine Komponente von FirePOWER, die Pakete in eine Form übersetzt, die leicht verständlich ist. Es behandelt das Paket zunächst, wenn es an Snort gesendet wird. Wenn die Pakete die FirePOWER-Appliance empfangen, aber nicht auslaufen, oder die Fehlerbehebung für den Paketeingang keine nützlichen Ergebnisse erbracht hat, kann die Fehlerbehebung für die Datenerfassung nützlich sein.
Um eine Eingabeaufforderung zu erhalten, von der aus die Erfassung ausgeführt werden soll, müssen Sie zuerst über SSH eine Verbindung zur SFR- oder FTD-IP-Adresse herstellen.
Hinweis: Geben Sie auf den FPR-9300- und 4100-Geräten connect ftd zuerst ein, um an der zweiten > Eingabeaufforderung zu enden. Sie können auch SSH in die IP-Adresse des FXOS-Chassis-Managers eingeben und dann die Konsole des Verbindungsmoduls 1 eingeben, gefolgt von Verbinden mit ftd.
In diesem Artikel wird beschrieben, wie Paketerfassungen auf der FirePOWER-DAQ-Ebene erfasst werden.
Beachten Sie, dass die Syntax nicht mit dem auf ASA verwendeten Capture-Befehl identisch ist, ebenso wie mit dem LINA-Teil der FTD-Plattform. Hier ein Beispiel für eine Datenerfassung über ein FTD-Gerät:
Wie im obigen Screenshot gezeigt, wurde eine Aufnahme im PCAP-Format namens ct.pcap in das /ngfw/var/common Verzeichnis (/var/common auf der SFR-Plattform) geschrieben. Diese Erfassungsdateien können aus dem FirePOWER-Gerät von der Eingabeaufforderung > kopiert werden, indem Sie die Anweisungen in dem oben genannten Artikel verwenden.
Alternativ können Sie im FirePOWER Management Center (FMC) in FirePOWER 6.2.0 und höher zu Devices > Device Management (Geräte > Gerätemanagement) navigieren. Klicken Sie anschließend auf die Schaltfläche neben dem betreffenden Gerät, gefolgt von Advanced Troubleshooting > File Download.
Sie können dann den Namen der Erfassungsdatei eingeben und auf Herunterladen klicken.
Wenn FirePOWER den Datenverkehr sieht, aber festgestellt wurde, dass die Pakete das Gerät nicht aussenden oder ein anderes Problem mit dem Datenverkehr besteht, besteht der nächste Schritt darin, die FirePOWER-Prüfphase zu umgehen, um zu bestätigen, dass eine der FirePOWER-Komponenten den Datenverkehr verwirft. Im Folgenden wird die schnellste Methode zur Umgehung der FirePOWER-Datenverkehr auf den verschiedenen Plattformen dargestellt.
Auf der ASA, die das SFR hostet, können Sie das SFR-Modul über die ASA Command Line Interface (CLI) oder den Cisco Adaptive Security Device Manager (ASDM) im Modus "Monitor Only" platzieren. Dadurch wird nur eine Kopie der Live-Pakete an das SFR-Modul gesendet.
Um das SFR-Modul über die ASA CLI in den Modus "Monitor Only" (Nur Überwachung) zu versetzen, müssen die für die SFR-Umleitung verwendete Klassenzuordnung und Richtlinienzuordnung zunächst mithilfe des Befehls show service-policy sfr bestimmt werden.
# show service-policy sfr
Global policy:
Service-policy: global_policy
Class-map: sfr
SFR: card status Up, mode fail-open
packet input 10000, packet output 9900, drop 100, reset-drop 0
Die Ausgabe zeigt, dass die global_policy-Map die sfr fail-open-Aktion in der "sfr"-Klassenzuordnung erzwingt.
Hinweis: "Fail-Close" ist auch ein Modus, in dem die SFR ausgeführt werden kann. Er wird jedoch nicht so häufig verwendet, da er den gesamten Datenverkehr blockiert, wenn das SFR-Modul ausgefallen ist oder nicht reagiert.
Um das SFR-Modul in den Nur-Monitor-Modus zu versetzen, können Sie die folgenden Befehle ausführen, um die aktuelle SFR-Konfiguration zu vernachlässigen und die Konfiguration nur für den Monitor einzugeben:
# configure terminal
(config)# policy-map global_policy
(config-pmap)# class sfr
(config-pmap-c)# no sfr fail-open
(config-pmap-c)# sfr fail-open monitor-only
INFO: The monitor-only mode prevents SFR from denying or altering traffic.
(config-pmap-c)# write memory
Building configuration...
Nachdem das Modul in den Modus "Monitor-only" (Nur Monitor) versetzt wurde, kann es in der Ausgabe "show service-policy sfr" überprüft werden.
# sh service-policy sfr
Global policy:
Service-policy: global_policy
Class-map: sfr
SFR: card status Up, mode fail-open monitor-only
packet input 0, packet output 100, drop 0, reset-drop 0
Hinweis: Um das SFR-Modul wieder in den Inline-Modus zu versetzen, führen Sie den Befehl no sfr fail-open monitor-only über die oben dargestellte (config-pmap-c)#-Eingabeaufforderung aus, gefolgt vom Befehl sfr {fail-open | fail-close}-Befehl, der ursprünglich vorhanden war.
Alternativ können Sie das Modul auch über das ASDM nur auf Monitor aufstellen, indem Sie zu Configuration > Firewall > Service Policy Rules (Konfiguration > Firewall > Service Policy Rules) navigieren. Klicken Sie dann auf die entsprechende Regel. Wechseln Sie anschließend zur Seite Regelaktionen, und klicken Sie auf die Registerkarte ASA FirePOWER-Inspektion. Danach kann Monitor only (Nur Monitor) ausgewählt werden.
Wenn das Datenverkehrsproblem auch dann besteht, wenn bestätigt wurde, dass sich das SFR-Modul nur im Überwachungsmodus befindet, verursacht das FirePOWER-Modul das Problem nicht. Der Packet Tracer kann dann ausgeführt werden, um weitere Probleme auf ASA-Ebene zu diagnostizieren.
Wenn das Problem nicht mehr besteht, besteht der nächste Schritt in der Fehlerbehebung für die FirePOWER-Softwarekomponenten.
Wenn der Datenverkehr durch Schnittstellenpaare geleitet wird, die in Inline-Sets konfiguriert wurden, kann der Inline-Satz in den TAP-Modus versetzt werden. Dies bewirkt im Wesentlichen, dass FirePOWER keine Maßnahmen für das Live-Paket ergreift. Sie gilt nicht für den Router- oder transparenten Modus ohne Inline-Sätze, da das Gerät die Pakete ändern muss, bevor sie an den nächsten Hop gesendet werden, und nicht in einen Umgehungsmodus versetzt werden kann, ohne den Datenverkehr zu verwerfen. Bei Routing- und transparentem Modus ohne Inline-Sätze fahren Sie mit dem Schritt Packet Tracer fort.
Um den TAP-Modus über die FMC-Benutzeroberfläche zu konfigurieren, navigieren Sie zu Devices > Device Management (Geräte > Gerätemanagement), und bearbeiten Sie dann das betreffende Gerät. Deaktivieren Sie auf der Registerkarte Inline Sets die Option für TAP Mode.
Wenn der TAP-Modus das Problem löst, besteht der nächste Schritt in der Fehlerbehebung für die FirePOWER-Softwarekomponenten.
Wenn der TAP-Modus das Problem nicht behebt, liegt das Problem außerhalb der FirePOWER-Software. Der Packet Tracer kann dann zur weiteren Diagnose des Problems verwendet werden.
Packet Tracer ist ein Dienstprogramm, mit dem der Speicherort eines Paketverlusts ermittelt werden kann. Es ist ein Simulator, also führt er eine Spur eines künstlichen Pakets durch.
Nachfolgend finden Sie ein Beispiel für die Ausführung von Packet-Tracer auf der ASA-CLI für SSH-Datenverkehr. Ausführlichere Informationen zur Syntax des Befehls Packet Tracer finden Sie in diesem Abschnitt im Leitfaden zur ASA-Serie.
Im obigen Beispiel sehen wir sowohl das ASA- als auch das SFR-Modul, das die Pakete erlaubt, als auch nützliche Informationen darüber, wie die ASA den Paketfluss handhaben würde.
Auf allen FTD-Plattformen kann der Befehl Packet Tracer über die FTD-CLI ausgeführt werden.
In diesem Beispiel zeigt Packet Tracer den Grund für das Verwerfen an. In diesem Fall ist es die IP-Blacklist innerhalb der Security Intelligence-Funktion in Firepower, die das Paket blockiert. Der nächste Schritt wäre die Fehlerbehebung für die einzelne FirePOWER-Softwarekomponente, die den Ausfall verursacht.
Der Live-Datenverkehr kann auch über die Trace-Funktion verfolgt werden, die auf allen Plattformen über die CLI verfügbar ist. Im Folgenden finden Sie ein Beispiel für das Ausführen einer Erfassung mit Ablaufverfolgung für SSH-Datenverkehr.
In diesem Beispiel wurde das vierte Paket in der Erfassung verfolgt, da es das erste Paket mit definierten Anwendungsdaten ist. Wie gezeigt, wird das Paket schließlich durch Snort Whitelist dargestellt, d. h., für den Fluss ist keine weitere Snort-Überprüfung erforderlich und insgesamt zulässig.
Weitere Informationen zur Erfassung mit Ablaufverfolgungssyntax finden Sie in diesem Abschnitt im Leitfaden zur ASA-Serie-Befehlsreferenz.
Auf den FTD-Plattformen kann die Erfassung mit Trace auf der FMC-Benutzeroberfläche ausgeführt werden. Um auf das Dienstprogramm zuzugreifen, wählen Sie Geräte > Gerätemanagement aus.
Klicken Sie anschließend auf die Schaltfläche neben dem betreffenden Gerät, gefolgt von Advanced Troubleshooting > Capture with Trace.
Im Folgenden finden Sie ein Beispiel, wie eine Erfassung mit trace über die GUI ausgeführt wird.
Wenn die Erfassung mit Ablaufverfolgung die Ursache für den Paketverlust anzeigt, besteht der nächste Schritt darin, die Fehler für die einzelnen Softwarekomponenten zu beheben.
Wenn die Ursache des Problems nicht eindeutig angezeigt wird, besteht der nächste Schritt darin, den Datenverkehr schnell zu leiten.
Auf allen FTD-Plattformen gibt es eine Richtlinie vor dem Filtern, mit der der Datenverkehr von der FirePOWER-(Snort-)Inspektion umgeleitet werden kann.
Im FMC finden Sie diese Informationen unter Richtlinien > Zugriffskontrolle > Vorfilter. Die Standard-Policy vor dem Filter kann nicht bearbeitet werden. Daher muss eine benutzerdefinierte Richtlinie erstellt werden.
Danach muss die neu erstellte Vorfilterrichtlinie der Zugriffskontrollrichtlinie zugeordnet werden. Dies wird auf der Registerkarte Erweitert der Zugriffskontrollrichtlinie im Abschnitt Voreingestellte Richtlinieneinstellungen konfiguriert.
Im Folgenden finden Sie ein Beispiel für das Erstellen einer Fastpath-Regel in einer Vorfilterrichtlinie und das Überprüfen der Trefferanzahl.
Klicken Sie hier, um weitere Informationen über den Betrieb und die Konfiguration von Prefilter Policies zu erhalten.
Wenn das Problem mit dem Datenverkehr durch Hinzufügen einer PreFilter Policy gelöst wird, kann die Regel bei Bedarf an der richtigen Stelle belassen werden. Dieser Fluss wird jedoch nicht erneut überprüft. Weitere Fehlerbehebungen für die FirePOWER-Software müssen durchgeführt werden.
Wenn das Problem durch Hinzufügen der Vorfilterrichtlinie nicht behoben wird, kann das Paket mit dem Ablaufverfolgungsschritt erneut ausgeführt werden, um den neuen Pfad des Pakets zu verfolgen.
Daten | Anweisungen |
Befehlsausgaben | Anweisungen hierzu finden Sie in diesem Artikel |
Paketerfassung | Für ASA/LINA: https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/118097-configure-asa-00.html Für FirePOWER: http://www.cisco.com/c/en/us/support/docs/security/sourcefire-firepower-8000-series-appliances/117778-technote-sourcefire-00.html |
ASA-Ausgabe "show tech" | Melden Sie sich bei der ASA CLI an, und lassen Sie die Terminalsitzung in einem Protokoll speichern. Geben Sie den Befehl how techcommand ein, und stellen Sie dann die Ausgabedatei für die Terminalsitzung für das TAC bereit. Diese Datei kann mit diesem Befehl auf der Festplatte oder einem externen Speichersystem gespeichert werden. Showtechnik | Redirect disk0:/show_tech.log |
Fehlerbehebungsdatei vom FirePOWER-Gerät, die den Datenverkehr prüft | http://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html |
Wenn festgestellt wurde, dass eine FirePOWER-Softwarekomponente die Ursache des Problems ist, besteht der nächste Schritt darin, jede Komponente systematisch auszuschließen, angefangen mit Security Intelligence.
Klicken Sie hier, um mit dem nächsten Leitfaden fortzufahren.