Fehlerbehebung für FirePOWER-Datenpfade Phase 1: Paketeingang

Einführung

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 wird die erste Phase der Fehlerbehebung für den FirePOWER-Datenpfad, die Phase des Paketeingangs beschrieben.

Plattform-Leitfaden

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 (nicht SSP und FPR-2100)	FirePOWER Threat Defense (FTD)-Image auf einer Adaptive Security Appliance (ASA) oder einer virtuellen Plattform installiert	ASA-5500-X-Serie, virtuelle NGFW-Plattformen	K/A
FTD (SSP)	FTD als logisches Gerät auf einem FXOS-basierten Chassis (FirePOWER eXtensible Operative System) installiert	FPR-9300, FPR-4100, FPR-2100	Die Serie 2100 verwendet den FXOS Chassis Manager nicht.

Fehlerbehebung in der Phase des Paketeingangs

Der erste Schritt zur Fehlerbehebung bei Datenpfaden besteht darin, sicherzustellen, dass es bei der Ein- oder Ausgangs-Paketverarbeitung keine Paketverluste gibt. Wenn ein Paket eingeht, aber nicht ausgeht, können Sie sicher sein, dass das Paket vom Gerät an einer Stelle im Datenpfad verworfen wird oder dass das Gerät das Ausgangspaket nicht erstellen kann (z. B. ein fehlender ARP-Eintrag).

Identifizieren des betreffenden Datenverkehrs

Der erste Schritt bei der Fehlerbehebung für die Phase des Paketeingangs besteht in der Isolierung des Datenflusses und der Schnittstellen, die am problematischen Datenverkehr beteiligt sind. Dazu gehören:

Flow-Informationen	Schnittstelleninformationen
Protokoll Quell-IP-Adresse Quell-Port Ziel-IP Zielport	Eingangsschnittstelle Ausgangsschnittstelle

Beispiel:

TCP inside 172.16.100.101:38974 outside 192.168.1.10:80

Tipp: Möglicherweise können Sie den genauen Quell-Port nicht identifizieren, da er in jedem Fluss oft unterschiedlich ist, aber der Ziel-Port (Server) sollte ausreichen.

Auf Verbindungsvereignisse prüfen

Nachdem Sie eine Vorstellung von der Eingangs- und Ausgangsschnittstelle erhalten haben, sollten der Datenverkehr und die Flussinformationen übereinstimmen. Der erste Schritt zu ermitteln, ob FirePOWER den Datenfluss blockiert, besteht darin, die Verbindungsereignisse für den betreffenden Datenverkehr zu überprüfen. Diese können im FirePOWER Management Center unter Analysis > Connections > Events angezeigt werden.

Hinweis: Stellen Sie vor der Überprüfung von Connection Events sicher, dass die Protokollierung in den Zugriffskontrollrichtlinien aktiviert ist. Die Protokollierung wird in jeder Zugriffskontrollrichtlinie auf der Registerkarte "Protokollierung" sowie auf der Registerkarte "Sicherheitsinformationen" konfiguriert. Stellen Sie sicher, dass die fehlerverdächtigen Regeln so konfiguriert sind, dass sie die Protokolle an die Ereignisanzeige senden.

Im obigen Beispiel wird auf "Suche bearbeiten" geklickt, und eine eindeutige Quelle (Initiator)-IP wird als Filter hinzugefügt, um die von FirePOWER erkannten Flows anzuzeigen. In der Spalte Aktion wird für diesen Hostverkehr "Zulassen" angezeigt.

Wenn FirePOWER Datenverkehr absichtlich blockiert, enthält die Aktion das Wort "Blockieren". Wenn Sie auf "Table View of Connection Events" (Tabellenansicht von Verbindungsereignissen) klicken, werden weitere Daten angezeigt. Die folgenden Felder in den Connection Events (Verbindungsereignisse) können bei Aktion "Block" (Blockieren) angezeigt werden:

- Grund

- Zugriffskontrollregel

Zusammen mit den anderen Feldern im betreffenden Fall kann dies dazu beitragen, die Komponente einzugrenzen, die den Datenverkehr blockiert.

Weitere Informationen zur Fehlerbehebung bei Zugriffskontrollregeln finden Sie hier.

Erfassen von Paketen auf den Eingangs- und Ausgangsschnittstellen

Wenn keine Ereignisse vorliegen oder die FirePOWER-Firewall trotz der Verbindungsereignisse, die eine Regelaktion mit "Zulassen" oder "Vertrauen" anzeigen, weiterhin blockiert wird, wird die Fehlerbehebung für den Datenpfad fortgesetzt.

Im Folgenden finden Sie Anweisungen zum Ausführen einer Paketerfassung für Ein- und Ausgang auf den oben genannten Plattformen:

SFR - Erfassung auf den ASA-Schnittstellen

Da es sich beim SFR-Modul lediglich um ein Modul handelt, das auf der ASA-Firewall ausgeführt wird, ist es am besten, zunächst die Eingangs- und Ausgangsschnittstellen der ASA zu erfassen, um sicherzustellen, dass dieselben eingehenden Pakete auch aussteigen.

Dieser Artikel enthält Anweisungen zur Durchführung der Erfassung auf der ASA.

Wenn festgestellt wurde, dass die Pakete, die die ASA empfangen, nicht abnehmen, fahren Sie mit der nächsten Phase der Fehlerbehebung fort (der DAQ-Phase).

Hinweis: Wenn Pakete auf der ASA-Eingangsschnittstelle angezeigt werden, lohnt es sich, die angeschlossenen Geräte zu überprüfen.

FTD (Nicht-SSP und FPR-2100) - Erfassung auf den Eingangs- und Ausgangsschnittstellen

Die Erfassung auf einem FTD-Gerät ohne SSP ähnelt der Erfassung auf der ASA. Sie können die Erfassungsbefehle jedoch direkt über die CLI-Eingabeaufforderung ausführen. Bei der Fehlerbehebung verworfener Pakete wird empfohlen, die Option "trace" zur Erfassung hinzuzufügen.

Im folgenden Beispiel wird eine Eingangserfassung für TCP-Datenverkehr an Port 22 konfiguriert:

Wenn Sie die Option "trace" (Nachverfolgung) hinzufügen, können Sie dann ein einzelnes Paket auswählen, das durch das System verfolgt werden soll, um zu sehen, wie es zum endgültigen Urteil gekommen ist. Außerdem wird sichergestellt, dass die richtigen Änderungen am Paket vorgenommen werden, z. B. die Änderung der Network Address Translation (NAT)-IP-Adresse, und dass die richtige Ausgangsschnittstelle gewählt wurde.

Im obigen Beispiel sehen wir, dass der Datenverkehr zu Snort Inspection führt und schließlich ein Zulassungsurteil erreicht hat und das Gerät insgesamt durchlaufen wurde. Da der Datenverkehr in beide Richtungen sichtbar ist, können Sie sicherstellen, dass der Datenverkehr für diese Sitzung durch das Gerät fließt. Eine Erfassung des Dateneingangs ist daher nicht erforderlich. Sie können jedoch auch einen Datenverkehr dorthin nehmen, um sicherzustellen, dass der Datenverkehr ordnungsgemäß ansteigt, wie in der Ablaufverfolgungsausgabe gezeigt. 

Hinweis: Wenn das Gerät das Ausgangspaket nicht erstellen kann, ist die Ablaufverfolgungsaktion weiterhin "zugelassen", aber das Paket wird nicht in der Erfassung der Ausgangsschnittstelle erstellt oder angezeigt. Dies ist ein sehr verbreitetes Szenario, bei dem die FTD keinen ARP-Eintrag für die nächste Hop- oder Ziel-IP-Adresse hat (wenn diese letzte direkt verbunden ist). 

FTD (SSP) - Erfassung auf den logischen FTD-Schnittstellen

Auf einer SSP-Plattform können die gleichen Schritte zur Erstellung einer Paketerfassung in FTD wie oben erwähnt ausgeführt werden. Sie können über SSH eine Verbindung mit der IP-Adresse der logischen FTD-Schnittstelle herstellen und den folgenden Befehl eingeben:

Firepower-module1> connect ftd
>

Mithilfe der folgenden Befehle können Sie auch über die FXOS-Eingabeaufforderung zur Shell für logische FTD-Geräte navigieren:

# connect module 1 console
Firepower-module1> connect ftd
>

Wenn eine FirePOWER 9300 verwendet wird, kann die Modulnummer variieren, je nachdem, welches Sicherheitsmodul verwendet wird. Diese Module können bis zu drei logische Geräte unterstützen.

Wenn mehrere Instanzen verwendet werden, muss die Instanz-ID im Befehl "connect" (Verbinden) enthalten sein. Der Telnet-Befehl kann verwendet werden, um gleichzeitig eine Verbindung zu verschiedenen Instanzen herzustellen.

# connect module 1 telnet
Firepower-module1>connect ftd ftd1 
Connecting to container ftd(ftd1) console... enter "exit" to return to Boot CLI
>

Auf Schnittstellenfehler prüfen

Probleme auf Schnittstellenebene können während dieser Phase ebenfalls überprüft werden. Dies ist besonders dann hilfreich, wenn bei der Erfassung der Eingangsschnittstellen Pakete fehlen. Wenn Schnittstellenfehler auftreten, kann es hilfreich sein, die angeschlossenen Geräte zu überprüfen.

SFR - ASA-Schnittstellen prüfen

Da das FirePOWER (SFR)-Modul im Grunde ein virtuelles System ist, das auf einer ASA ausgeführt wird, werden die ASA-Schnittstellen tatsächlich auf Fehler überprüft. Ausführliche Informationen zum Überprüfen der Schnittstellenstatistiken auf der ASA finden Sie in diesem Abschnitt der ASA-Serien-Befehlsreferenz.

FTD (Nicht-SSP und FPR-2100) - Auf Schnittstellenfehler prüfen

Auf FTD-Geräten ohne SSP kann der Befehl > show interface über die erste Eingabeaufforderung ausgeführt werden. Die interessante Ausgabe wird rot hervorgehoben.

FTD (SSP) - Navigieren im Datenpfad zur Suche nach Schnittstellenfehlern

Die SSP-Plattformen 9300 und 4100 verfügen über ein internes Fabric Interconnect, das die Pakete zuerst behandelt. 

Es lohnt sich zu überprüfen, ob beim ersten Paketeingang Schnittstellenprobleme auftreten. Dies sind die Befehle, die in der FXOS-System-CLI ausgeführt werden müssen, um diese Informationen abzurufen.

ssp# scope eth-uplink
ssp /et-uplink # show stats

Dies ist eine Beispielausgabe.

Nachdem das Fabric Interconnect das Paket beim Eingang behandelt, wird es an die Schnittstellen gesendet, die dem logischen Gerät zugewiesen sind, das das FTD-Gerät hostet.

Nachstehend finden Sie ein Referenzdiagramm:

Geben Sie die folgenden Befehle ein, um nach Problemen auf Schnittstellenebene zu suchen:

ssp# connect fxos
ssp(fxos)# show interface Ethernet 1/7

Dies ist ein Ausgabebeispiel (mögliche Probleme sind rot markiert):

Falls Fehler auftreten, kann die FTD-Software auch auf Schnittstellenfehler überprüft werden. 

Um zur FTD-Eingabeaufforderung zu gelangen, muss zuerst die CLI-Eingabeaufforderung FTD aufgerufen werden.

# connect module 1 console
Firepower-module1> connect ftd
> show interface

Für mehrere Instanzen:

# connect module 1 telnet
Firepower-module1>connect ftd ftd1  
Connecting to container ftd(ftd1) console... enter "exit" to return to Boot CLI 
>

Dies ist ein Ausgabebeispiel.

Daten für das Cisco Technical Assistance Center (TAC)

Daten	Anweisungen
Screenshots für Verbindungsereignisse	Anweisungen hierzu finden Sie in diesem Artikel
Ausgabe von 'show interface'	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/1180 Für FirePOWER: http://www.cisco.com/c/en/us/support/docs/security/sourcefire-firepower-8000-series-appliances/11777
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 show tech ein, und stellen Sie dann die Ausgabedatei der 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

Nächster Schritt: Fehlerbehebung für die FirePOWER-DAQ-Ebene

Wenn unklar ist, ob das FirePOWER-Gerät Pakete verwirft, kann das FirePOWER-Gerät selbst umgangen werden, um alle FirePOWER-Komponenten gleichzeitig auszuschließen. Dies ist besonders hilfreich, um ein Problem zu beheben, wenn der betreffende Datenverkehr das FirePOWER-Gerät empfängt, aber nicht absteigt.

Lesen Sie zum Fortfahren die nächste Phase der Fehlerbehebung für den FirePOWER-Datenpfad. Die FirePOWER-DAQ. Klicken Sie hier, um fortzufahren.