Analyse der FirePOWER-Firewall-Erfassung zur Behebung von Netzwerkproblemen

Einleitung

In diesem Dokument werden verschiedene Verfahren zur Analyse von Paketerfassungen beschrieben, die der effektiven Fehlersuche bei Netzwerkproblemen dienen.  

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• FirePOWER Plattformarchitektur
• NGFW-Protokolle
• NGFW Packet-Tracer

Bevor Sie mit der Analyse der Paketerfassung beginnen, sollten Sie außerdem folgende Anforderungen erfüllen:

• Protokollvorgang kennen - Beginnen Sie nicht mit der Überprüfung einer Paketerfassung, wenn Sie nicht wissen, wie das erfasste Protokoll funktioniert.
• Kenne die Topologie - Du musst die End-to-End-Transitgeräte kennen. Wenn dies nicht möglich ist, müssen Sie zumindest die vor- und nachgeschalteten Geräte kennen.
• Kennen Sie die Appliance - Sie müssen wissen, wie Ihr Gerät mit Paketen umgeht, welche Schnittstellen beteiligt sind (Eingang/Ausgang), welche Gerätearchitektur verwendet wird und welche Erfassungspunkte vorhanden sind.
• Konfiguration kennen - Sie müssen wissen, wie ein Paketfluss vom Gerät behandelt werden soll, und zwar in Bezug auf:
  • Routing-/Ausgangsschnittstelle
  • Anwendung von Richtlinien
  • Network Address Translation (NAT)
• Kenntnis der verfügbaren Tools - Neben den Erfassungen wird empfohlen, andere Tools und Techniken (wie Protokollierung und Tracer) anzuwenden und diese bei Bedarf mit den erfassten Paketen zu korrelieren.

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• Die meisten Szenarien basieren auf FP4140 mit FTD-Software 6.5.x.
• FMC mit Software 6.5.x

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.

Hintergrundinformationen

Die Paketerfassung zählt zu den am häufigsten übersehenen Tools zur Fehlerbehebung, die derzeit verfügbar sind. Das Cisco TAC löst täglich viele Probleme durch die Analyse der erfassten Daten.

Das vorliegende Dokument soll Netzwerk- und Sicherheitstechniker dabei unterstützen, gängige Netzwerkprobleme zu identifizieren und zu beheben, die hauptsächlich auf einer Paketerfassungsanalyse basieren.

Alle in diesem Dokument vorgestellten Szenarien basieren auf tatsächlichen Benutzerfällen aus dem Cisco Technical Assistance Center (TAC).

Das Dokument behandelt die Paketerfassung aus der Sicht der Cisco Next-Generation Firewall (NGFW). Die gleichen Konzepte gelten jedoch auch für andere Gerätetypen.

Sammeln und Exportieren von Aufzeichnungen aus der NGFW-Produktfamilie

Bei einer FirePOWER-Appliance (1xxx, 21xx, 41xx, 93xx) und einer FirePOWER Threat Defense (FTD)-Anwendung kann eine Paketverarbeitung wie im Bild dargestellt dargestellt dargestellt dargestellt werden.

1. Ein Paket gelangt an die Eingangsschnittstelle, und es wird vom internen Chassis-Switch verarbeitet.
2. Das Paket gelangt in die FTD Lina-Engine, die hauptsächlich L3/L4-Prüfungen durchführt.
3. Wenn die Richtlinie erfordert, wird das Paket von der Snort-Engine geprüft (hauptsächlich L7-Inspektion).
4. Die Snort-Engine gibt ein Urteil für das Paket zurück.
5. Die LINA-Engine verwirft oder leitet das Paket basierend auf dem Urteil von Snort weiter.
6. Das Paket gelangt über den internen Chassis-Switch aus dem Chassis.

Basierend auf der gezeigten Architektur können die FTD-Aufnahmen an drei (3) verschiedenen Orten gemacht werden:

• FXOS
• FTD Lina-Engine
• FTD Snort-Engine

FXOS-Erfassungen erfassen

Der Prozess wird in diesem Dokument beschrieben:

https://www.cisco.com/c/en/us/td/docs/security/firepower/fxos/fxos271/web-guide/b_GUI_FXOS_ConfigGuide_271/troubleshooting.html#concept_E8823CC63C934A909BBC0DF12F301DED

FXOS-Aufnahmen können aus Sicht des internen Switches nur in Eingangsrichtung gemacht werden.

Hier sind zwei Erfassungspunkte pro Richtung dargestellt (aufgrund der internen Switch-Architektur).

Die in den Punkten 2, 3 und 4 erfassten Pakete weisen ein Virtual Network Tag (VNTag) auf.

Hinweis: FXOS-Aufnahmen auf Chassis-Ebene sind nur auf den Plattformen FP41xx und FP93xx verfügbar. FP1xxx und FP21xx bieten diese Funktion nicht.

FTD-Lina-Erfassungen aktivieren und erfassen

Wichtigste Punkte:

• Eingangsschnittstelle
• Ausgangs-Schnittstelle
• Accelerated Security Path (ASP)

Sie können entweder die Firepower Management Center-Benutzeroberfläche (FMC UI) oder FTD CLI verwenden, um die FTD-Lina-Aufnahmen zu aktivieren und zu sammeln.

Aktivieren Sie die Erfassung über die CLI auf der INSIDE-Schnittstelle:

firepower# capture CAPI interface INSIDE match icmp host 192.168.103.1 host 192.168.101.1

Diese Erfassung gleicht den Datenverkehr zwischen den IP-Adressen 192.168.103.1 und 192.168.101.1 in beide Richtungen ab.

Aktivieren Sie die ASP-Erfassung, um alle Pakete anzuzeigen, die vom FTD Lina-Modul verworfen wurden:

firepower# capture ASP type asp-drop all

FTD-Lina-Aufzeichnung auf einen FTP-Server exportieren:

firepower# copy /pcap capture:CAPI ftp://ftp_username:ftp_password@192.168.78.73/CAPI.pcap

FTD-Lina-Aufzeichnung auf einen TFTP-Server exportieren:

firepower# copy /pcap capture:CAPI tftp://192.168.78.73

Ab der Version FMC 6.2.x können Sie FTD Lina Captures von der FMC UI aus aktivieren und sammeln.

Eine andere Möglichkeit, FTD-Aufnahmen von einer FMC-verwalteten Firewall zu sammeln, ist diese.

Schritt 1

Bei LINA- oder ASP-Erfassung kopieren Sie die Erfassung auf die FTD-Diskette.

firepower# copy /pcap capture:capin disk0:capin.pcap

Source capture name [capin]?

Destination filename [capin.pcap]?
!!!!

Schritt 2

Navigieren Sie in den Expertenmodus, suchen Sie die gespeicherte Aufzeichnung, und kopieren Sie sie in den Speicherort /ngfw/var/common:

firepower#

Console connection detached.

> expert
admin@firepower:~$ sudo su
Password:
root@firepower:/home/admin# cd /mnt/disk0
root@firepower:/mnt/disk0# ls -al | grep pcap
-rwxr-xr-x 1 root root     24 Apr 26 18:19 CAPI.pcap
-rwxr-xr-x 1 root root  30110 Apr  8 14:10 capin.pcap
-rwxr-xr-x 1 root root   6123 Apr  8 14:11 capin2.pcap
root@firepower:/mnt/disk0# cp capin.pcap /ngfw/var/common

Schritt 3

Melden Sie sich beim FMC an, das die FTD verwaltet, und navigieren Sie zu Devices (Geräte) > Device Management (Geräteverwaltung). Suchen Sie das FTD-Gerät, und wählen Sie das Symbol Fehlerbehebung:

Schritt 4

Erweiterte Fehlerbehebung auswählen:

Geben Sie den Namen der Erfassungsdatei an, und wählen Sie Herunterladen:

Weitere Beispiele zum Aktivieren/Sammeln von Erfassungen über die FMC-Benutzeroberfläche finden Sie in diesem Dokument:

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212474-working-with-firepower-threat-defense-f.html

Aktivieren und Sammeln von FTD Snort-Erfassungen

Der Fangpunkt ist hier im Bild dargestellt.

Snapshot-Erfassung aktivieren:

> capture-traffic

Please choose domain to capture traffic from:
  0 - br1
  1 - Router

Selection? 1

Please specify tcpdump options desired.
(or enter '?' for a list of supported options)
Options: -n host 192.168.101.1

So schreiben Sie die Aufzeichnung in eine Datei mit dem Namen "capture.pcap" und kopieren sie per FTP auf einen Remote-Server:

> capture-traffic

Please choose domain to capture traffic from:
  0 - br1
  1 - Router

Selection? 1

Please specify tcpdump options desired.
(or enter '?' for a list of supported options)
Options: -w capture.pcap host 192.168.101.1
CTRL + C <- to stop the capture

> file copy 10.229.22.136 ftp / capture.pcap
Enter password for ftp@10.229.22.136:
Copying capture.pcap
Copy successful.

> 

Weitere Erfassungsbeispiele auf Snort-Ebene mit verschiedenen Erfassungsfiltern finden Sie in diesem Dokument:

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212474-working-with-firepower-threat-defense-f.html

Fehlerbehebung

Fall 1: Kein TCP-SYN an der Ausgangsschnittstelle

Die Topologie ist im folgenden Bild dargestellt:

Problembeschreibung: HTTP funktioniert nicht

Betroffener Datenfluss:

Quelle IP: 192.168.0.100

Ziel-IP: 10.10.1.100

Protokoll: TCP 80

Erfassungsanalyse

Aktivieren Sie Aufnahmen auf der FTD LINA-Engine:

firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100
firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100

Erfassungen - Funktionsszenario:

Als Basis ist es immer sehr nützlich, Aufzeichnungen aus einem funktionalen Szenario zu haben.

Erfassung auf NGFW INSIDE-Schnittstelle, wie in der Abbildung dargestellt:

Wichtigste Punkte:

1. TCP-3-Wege-Handshake
2. Bidirektionaler Datenaustausch.
3. Keine Verzögerungen zwischen den Paketen (basierend auf der Zeitdifferenz zwischen den Paketen).
4. Quell-MAC ist das richtige Downstream-Gerät.

Die Erfassung, die über die NGFW OUTSIDE-Schnittstelle erfolgt, wird im folgenden Bild dargestellt:

Wichtigste Punkte:

1. Die gleichen Daten wie bei der CAPI-Erfassung.
2. Die Ziel-MAC ist das richtige Upstream-Gerät.

Erfassungen - Szenario ohne Funktion

Aus der Geräte-CLI sehen die Aufnahmen wie folgt aus:

firepower# show capture
capture CAPI type raw-data interface INSIDE [Capturing - 484 bytes]
  match ip host 192.168.0.100 host 10.10.1.100
capture CAPO type raw-data interface OUTSIDE [Capturing - 0 bytes]
  match ip host 192.168.0.100 host 10.10.1.100

CAPI-Inhalt:

firepower# show capture CAPI

6 packets captured

   1: 11:47:46.911482   192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   2: 11:47:47.161902   192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   3: 11:47:49.907683   192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   4: 11:47:50.162757   192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   5: 11:47:55.914640   192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,nop,sackOK>
   6: 11:47:56.164710   192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,nop,sackOK>

firepower# show capture CAPO

0 packet captured

0 packet shown

Dies ist das Bild der CAPI-Erfassung in Wireshark:

Wichtigste Punkte:

1. Es werden nur TCP-SYN-Pakete angezeigt (kein TCP-3-Wege-Handshake).
2. Es gibt 2 TCP-Sitzungen (Quellport 3171 und 3172), die nicht eingerichtet werden können. Der Quell-Client sendet die TCP-SYN-Pakete erneut. Diese neu übertragenen Pakete werden von Wireshark als TCP-Neuübertragungen identifiziert.
3. Die TCP-Neuübertragungen erfolgen alle ~3, dann 6 usw. Sekunden.
4. Die Quell-MAC-Adresse stammt vom korrekten Downstream-Gerät.

Auf der Grundlage der beiden Aufzeichnungen kann der Schluss gezogen werden, dass

• Ein Paket eines bestimmten 5-Tupels (src/dst IP, src/dst Port, Protokoll) kommt an der Firewall an der erwarteten Schnittstelle (INSIDE) an.
• Ein Paket verlässt die Firewall nicht auf der erwarteten Schnittstelle (AUSSEN).

Empfohlene Maßnahmen

Mit den in diesem Abschnitt aufgeführten Maßnahmen soll das Problem weiter eingegrenzt werden.

Maßnahme 1: Überprüfen der Ablaufverfolgung eines emulierten Pakets

Verwenden Sie das Tool zur Paketverfolgung, um festzustellen, wie ein Paket von der Firewall behandelt werden soll. Wenn das Paket von der Firewall-Zugriffsrichtlinie verworfen wird, sieht die Ablaufverfolgung des emulierten Pakets ähnlich wie diese Ausgabe aus:

firepower# packet-tracer input INSIDE tcp 192.168.0.100 11111 10.10.1.100 80

Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 192.168.2.72 using egress ifc  OUTSIDE

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: DROP
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268439946 event-log flow-start
access-list CSM_FW_ACL_ remark rule-id 268439946: ACCESS POLICY: FTD_Policy - Default
access-list CSM_FW_ACL_ remark rule-id 268439946: L4 RULE: DEFAULT ACTION RULE
Additional Information:

Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: OUTSIDE
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x00005647a4f4b120 flow (NA)/NA

Maßnahme 2: Überprüfen Sie die Spuren von aktiven Paketen.

Aktivieren Sie die Paketverfolgung, um zu überprüfen, wie die echten TCP-SYN-Pakete von der Firewall verarbeitet werden. Standardmäßig werden nur die ersten 50 eingehenden Pakete verfolgt:

firepower# capture CAPI trace

Löschen Sie den Erfassungspuffer:

firepower# clear capture /all

Falls das Paket von der Firewall-Zugriffsrichtlinie verworfen wird, sieht die Ablaufverfolgung ähnlich wie diese Ausgabe aus:

firepower# show capture CAPI packet-number 1 trace

6 packets captured

   1: 12:45:36.279740       192.168.0.100.3630 > 10.10.1.100.80: S 2322685377:2322685377(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 192.168.2.72 using egress ifc  OUTSIDE

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: DROP
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268439946 event-log flow-start
access-list CSM_FW_ACL_ remark rule-id 268439946: ACCESS POLICY: FTD_Policy - Default
access-list CSM_FW_ACL_ remark rule-id 268439946: L4 RULE: DEFAULT ACTION RULE
Additional Information:

Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: OUTSIDE
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x00005647a4f4b120 flow (NA)/NA

1 packet shown

Maßnahme 3: FTD-Lina-Protokolle überprüfen.

Um Syslog auf FTD über FMC zu konfigurieren, lesen Sie dieses Dokument:

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/200479-Configure-Logging-on-FTD-via-FMC.html

Es wird dringend empfohlen, einen externen Syslog-Server für FTD-Lina-Protokolle zu konfigurieren. Wenn kein entfernter Syslog-Server konfiguriert ist, aktivieren Sie während der Fehlerbehebung lokale Pufferprotokolle in der Firewall. Die in diesem Beispiel gezeigte Protokollkonfiguration ist ein guter Ausgangspunkt:

firepower# show run logging
…
logging enable
logging timestamp
logging buffer-size 1000000
logging buffered informational

Stellen Sie den Terminal-Pager auf 24 Leitungen ein, um den Terminal-Pager zu steuern:

firepower# terminal pager 24

Löschen Sie den Erfassungspuffer:

firepower# clear logging buffer

Testen Sie die Verbindung, und überprüfen Sie die Protokolle mit einem Parserfilter. In diesem Beispiel werden die Pakete von der Firewall-Zugriffsrichtlinie verworfen:

firepower# show logging | include 10.10.1.100
Oct 09 2019 12:55:51: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3696 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]
Oct 09 2019 12:55:51: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3697 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]
Oct 09 2019 12:55:54: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3696 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]
Oct 09 2019 12:55:54: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3697 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]

Maßnahme 4: Überprüfen Sie die Firewall-ASP-Drops.

Wenn Sie vermuten, dass das Paket von der Firewall verworfen wird, können Sie die Zähler aller Pakete sehen, die von der Firewall auf Softwareebene verworfen wurden:

firepower# show asp drop

Frame drop:
  No route to host (no-route)                                                234
  Flow is denied by configured rule (acl-drop)                                71

Last clearing: 07:51:52 UTC Oct 10 2019 by enable_15

Flow drop:

Last clearing: 07:51:52 UTC Oct 10 2019 by enable_15

Sie können Aufnahmen aktivieren, um alle ASP-Verwerfungen auf Softwareebene anzuzeigen:

firepower# capture ASP type asp-drop all buffer 33554432 headers-only

Tipp: Wenn Sie sich nicht für den Paketinhalt interessieren, können Sie nur die Paket-Header erfassen (nur Header-Option). Dadurch können Sie viel mehr Pakete im Capture-Puffer erfassen. Zusätzlich können Sie die Größe des Capture-Puffers (standardmäßig 500 KB) auf einen Wert von bis zu 32 MB (Pufferoption) erhöhen. Ab FTD Version 6.3 können Sie mit der Dateigrößenoption eine Erfassungsdatei von bis zu 10 GByte konfigurieren. In diesem Fall können Sie den Inhalt der Aufnahme nur im pcap-Format sehen.

Um den Inhalt der Erfassung zu überprüfen, können Sie die Suche mithilfe eines Filters eingrenzen:

firepower# show capture ASP | include 10.10.1.100
  18: 07:51:57.823672   192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
  19: 07:51:58.074291   192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
  26: 07:52:00.830370   192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
  29: 07:52:01.080394   192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
  45: 07:52:06.824282   192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,nop,sackOK>
  46: 07:52:07.074230   192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,nop,sackOK>

Da die Pakete in diesem Fall bereits auf Schnittstellenebene verfolgt werden, wird der Grund für den Verfall in der ASP-Erfassung nicht erwähnt. Denken Sie daran, dass ein Paket nur an einem Ort verfolgt werden kann (Eingangsschnittstelle oder ASP-Drop). In diesem Fall wird empfohlen, mehrere ASP-Drops durchzuführen und einen bestimmten ASP-Dropgrund festzulegen. Dies ist ein empfohlener Ansatz:

1. Löschen Sie die aktuellen ASP-Zähler zum Ablegen:

firepower# clear asp drop

2. Senden Sie den Fluss, den Sie bei der Fehlerbehebung verwenden, über die Firewall (führen Sie einen Test aus).

3. Überprüfen Sie erneut die ASP-Zähler für das Ablegen, und notieren Sie die erhöhten Zähler.

firepower# show asp drop
Frame drop:
  No route to host (no-route)                                                234
  Flow is denied by configured rule (acl-drop)                                71

4. Aktivieren Sie ASP-Erfassung(en) für die bestimmten erkannten Drops:

firepower# capture ASP_NO_ROUTE type asp-drop no-route
firepower# capture ASP_ACL_DROP type asp-drop acl-drop

5. Senden Sie den Fluss, den Sie bei der Fehlerbehebung verwenden, über die Firewall (führen Sie einen Test aus).

6. Überprüfen Sie die ASP-Aufnahmen. In diesem Fall wurden die Pakete aufgrund einer fehlenden Route verworfen:

firepower# show capture ASP_NO_ROUTE | include 192.168.0.100.*10.10.1.100
  93: 07:53:52.381663   192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
  95: 07:53:52.632337   192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
 101: 07:53:55.375392   192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
 102: 07:53:55.626386   192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
 116: 07:54:01.376231   192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,nop,sackOK>
 117: 07:54:01.626310   192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,nop,sackOK>

Maßnahme 5: Überprüfen Sie die FTD Lina-Verbindungstabelle.

Es kann Fälle geben, in denen Sie erwarten, dass das Paket die Schnittstelle 'X' verlässt, aber aus welchen Gründen auch immer, es verlässt die Schnittstelle 'Y'. Die Bestimmung der Firewall-Ausgangsschnittstelle basiert auf der folgenden Reihenfolge:

1. Suche nach Verbindung wurde eingerichtet
2. NAT-Suche (Network Address Translation) - Die UN-NAT-Phase (Ziel-NAT) hat Vorrang vor der PBR- und Routensuche.
3. Richtlinienbasiertes Routing
4. Routingtabellen-Suche

So überprüfen Sie die FTD-Verbindungstabelle:

firepower# show conn
2 in use, 4 most used
Inspect Snort:
        preserve-connection: 2 enabled, 0 in effect, 4 most enabled, 0 most in effect

TCP DMZ  10.10.1.100:80 INSIDE  192.168.0.100:11694, idle 0:00:01, bytes 0, flags aA N1
TCP DMZ  10.10.1.100:80 INSIDE  192.168.0.100:11693, idle 0:00:01, bytes 0, flags aA N1

Wichtigste Punkte:

• Basierend auf den Flaggen (Aa) ist die Verbindung embryonal (halb geöffnet - nur TCP SYN wurde von der Firewall gesehen).
• Auf Basis der Quell-/Ziel-Ports ist die Eingangsschnittstelle INSIDE, und die Ausgangsschnittstelle ist DMZ.

Dies kann im Bild hier visualisiert werden:

Hinweis: Da alle FTD-Schnittstellen die Sicherheitsstufe 0 haben, basiert die Schnittstellenreihenfolge in der angezeigten Verbindungsausgabe auf der Schnittstellennummer. Insbesondere wird die Schnittstelle mit höherer vpif-num (Virtual Platform Interface Number) als inside und die Schnittstelle mit niedrigerer vpif-num als outside ausgewählt. Der Wert für interface vpif wird mit dem Befehl show interface detail angezeigt. Zugehörige Erweiterung, Cisco Bug-ID CSCvi15290 ENH: FTD zeigt die Verbindungsrichtung in FTD-"show conn"-Ausgabe an

firepower# show interface detail | i Interface number is|Interface [P|E].*is up
...
Interface Ethernet1/2 "INSIDE", is up, line protocol is up
        Interface number is 19
Interface Ethernet1/3.202 "OUTSIDE", is up, line protocol is up
        Interface number is 20
Interface Ethernet1/3.203 "DMZ", is up, line protocol is up
        Interface number is 22

Hinweis: Ab Firepower Software 6.5, ASA Version 9.13.x liefern die Befehlsausgaben show conn long und show conn detail Informationen über den Verbindungsinitiator und den Responder

Ausgabe 1:

firepower# show conn long
...
TCP OUTSIDE: 192.168.2.200/80 (192.168.2.200/80) INSIDE: 192.168.1.100/46050 (192.168.1.100/46050), flags aA N1, idle 3s, uptime 6s, timeout 30s, bytes 0
  Initiator: 192.168.1.100, Responder: 192.168.2.200
  Connection lookup keyid: 228982375

Ausgabe 2:

firepower# show conn detail
...
TCP OUTSIDE: 192.168.2.200/80 INSIDE: 192.168.1.100/46050,
    flags aA N1, idle 4s, uptime 11s, timeout 30s, bytes 0
  Initiator: 192.168.1.100, Responder: 192.168.2.200
  Connection lookup keyid: 228982375

Zusätzlich zeigt show conn long die NATed-IPs in einer Klammer an, wenn es sich um eine Network Address Translation handelt:

firepower# show conn long
...
TCP OUTSIDE: 192.168.2.222/80 (192.168.2.222/80) INSIDE: 192.168.1.100/34792 (192.168.2.150/34792), flags aA N1, idle 0s, uptime 0s, timeout 30s, bytes 0, xlate id 0x2b5a8a4314c0
  Initiator: 192.168.1.100, Responder: 192.168.2.222
  Connection lookup keyid: 262895

Maßnahme 6. Überprüfen Sie den ARP-Cache (Address Resolution Protocol) der Firewall.

Wenn die Firewall den nächsten Hop nicht auflösen kann, verwirft die Firewall unbeaufsichtigt das ursprüngliche Paket (in diesem Fall TCP SYN) und sendet kontinuierlich ARP-Anforderungen, bis der nächste Hop aufgelöst ist.

Um den ARP-Cache der Firewall anzuzeigen, verwenden Sie den folgenden Befehl:

firepower# show arp

Um zu überprüfen, ob es nicht aufgelöste Hosts gibt, können Sie den folgenden Befehl verwenden:

firepower# show arp statistics
        Number of ARP entries in ASA: 0

        Dropped blocks in ARP: 84
        Maximum Queued blocks: 3
        Queued blocks: 0
        Interface collision ARPs Received: 0
        ARP-defense Gratuitous ARPS sent: 0
        Total ARP retries: 182			< indicates a possible issue for some hosts
        Unresolved hosts: 1			< this is the current status
        Maximum Unresolved hosts: 2

Wenn Sie den ARP-Vorgang weiter überprüfen möchten, können Sie eine ARP-spezifische Erfassung aktivieren:

firepower# capture ARP ethernet-type arp interface OUTSIDE
firepower# show capture ARP
...
   4: 07:15:16.877914       802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50
   5: 07:15:18.020033       802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50

In dieser Ausgabe versucht die Firewall (192.168.2.50), den nächsten Hop (192.168.2.72) aufzulösen, es gibt jedoch keine ARP-Antwort.

Die Ausgabe hier zeigt ein funktionelles Szenario mit der richtigen ARP-Auflösung:

firepower# show capture ARP

2 packets captured

   1: 07:17:19.495595       802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50
   2: 07:17:19.495946       802.1Q vlan#202 P0 arp reply 192.168.2.72 is-at 4c:4e:35:fc:fc:d8
2 packets shown

firepower# show arp
        INSIDE 192.168.1.71 4c4e.35fc.fcd8 9
        OUTSIDE 192.168.2.72 4c4e.35fc.fcd8 9

Falls kein ARP-Eintrag vorhanden ist, zeigt die Ablaufverfolgung eines aktiven TCP-SYN-Pakets Folgendes an:

firepower# show capture CAPI packet-number 1 trace

6 packets captured

   1: 07:03:43.270585       192.168.0.100.11997 > 10.10.1.100.80: S 4023707145:4023707145(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 192.168.2.72 using egress ifc  OUTSIDE
…
Phase: 14
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 4814, packet dispatched to next module
…
Phase: 17
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 192.168.2.72 using egress ifc  OUTSIDE

Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: OUTSIDE
output-status: up
output-line-status: up
Action: allow

Wie in der Ausgabe zu sehen ist, zeigt die Ablaufverfolgung "Action: allow" an, selbst wenn der nächste Hop nicht erreichbar ist und das Paket stumm von der Firewall verworfen wird! In diesem Fall muss auch das Paket-Tracer-Tool überprüft werden, da es eine genauere Ausgabe ermöglicht:

firepower# packet-tracer input INSIDE tcp 192.168.0.100 1111 10.10.1.100 80

Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 192.168.2.72 using egress ifc  OUTSIDE
…

Phase: 14
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 4816, packet dispatched to next module
…
Phase: 17
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 192.168.2.72 using egress ifc  OUTSIDE

Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: OUTSIDE
output-status: up
output-line-status: up
Action: drop
Drop-reason: (no-v4-adjacency) No valid V4 adjacency, Drop-location: frame 0x00005647a4e86109 flow (NA)/NA

Bei den aktuellen ASA/Firepower-Versionen wurde die vorherige Meldung optimiert, um:

Drop-reason: (no-v4-adjacency) No valid V4 adjacency. Check ARP table (show arp) has entry for nexthop., Drop-location: f

Mögliche Ursachen und empfohlene Aktionen - Zusammenfassung

Wenn Sie nur ein TCP-SYN-Paket an den Eingangsschnittstellen sehen, aber kein TCP-SYN-Paket von der erwarteten Ausgangsschnittstelle gesendet wird, gibt es einige mögliche Ursachen:

Mögliche Ursache	Empfohlene Maßnahmen
Das Paket wird von der Firewall-Zugriffsrichtlinie verworfen.	Verwenden Sie Packet-Tracer oder capture w/trace, um zu sehen, wie die Firewall mit dem Paket umgeht. Firewall-Protokolle überprüfen. Überprüfen Sie die Firewall-ASP-Drops (show asp drop oder capture type asp-drop). FMC-Verbindungsereignisse überprüfen. Dabei wird davon ausgegangen, dass für die Regel die Protokollierung aktiviert ist.
Der Erfassungsfilter ist falsch.	Verwenden Sie die Paketverfolgung oder Erfassung mit Trace, um festzustellen, ob eine NAT-Übersetzung vorliegt, die die Quell- oder Ziel-IP-Adresse ändert. Passen Sie in diesem Fall den Erfassungsfilter an. show conn long zeigt die NATed-IPs an.
Das Paket wird an eine andere Ausgangsschnittstelle gesendet.	Verwenden Sie die Paketverfolgung oder Erfassung mit Ablaufverfolgung, um zu sehen, wie die Firewall mit dem Paket umgeht. Denken Sie an die Reihenfolge der Vorgänge, die die Ermittlung der Ausgangsschnittstelle, die aktuelle Verbindung, UN-NAT, PBR und die Suche in der Routing-Tabelle betreffen. Firewall-Protokolle überprüfen. Überprüfen Sie die Firewall-Verbindungstabelle (show conn). Wenn das Paket an eine falsche Schnittstelle gesendet wird, weil es mit einer aktuellen Verbindung übereinstimmt, verwenden Sie den Befehl clear conn address, und geben Sie das 5-Tupel der Verbindung an, die gelöscht werden soll.
Es gibt keine Route zum Ziel.	Verwenden Sie Packet-Tracer oder capture w/trace, um zu sehen, wie die Firewall mit dem Paket umgeht. Überprüfen Sie die Firewall-ASP-Drops (show asp drop) auf Gründe für ein nicht rotierendes Dropdown.
Es gibt keinen ARP-Eintrag auf der Ausgangsschnittstelle.	Überprüfen Sie den Firewall-ARP-Cache (show arp). Verwenden Sie die Paketverfolgung, um festzustellen, ob eine gültige Adjacency vorhanden ist.
Die Ausgangsschnittstelle ist ausgefallen.	Überprüfen Sie die Ausgabe des Befehls show interface ip brief auf der Firewall, und überprüfen Sie den Schnittstellenstatus.

Fall 2: TCP SYN vom Client, TCP RST vom Server

Dieses Bild zeigt die Topologie:

Problembeschreibung: HTTP funktioniert nicht

Betroffener Datenfluss:

Quelle IP: 192.168.0.100

Ziel-IP: 10.10.1.100

Protokoll: TCP 80

Erfassungsanalyse

Aktivieren Sie Aufnahmen auf der FTD LINA-Engine.

firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100
firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100

Erfassungen - Nicht-funktionales Szenario:

So sehen die Aufnahmen in der Geräte-CLI aus:

firepower# show capture
capture CAPI type raw-data trace interface INSIDE [Capturing - 834 bytes]
  match ip host 192.168.0.100 host 10.10.1.100
capture CAPO type raw-data interface OUTSIDE [Capturing - 878 bytes]
  match ip host 192.168.0.100 host 10.10.1.100

CAPI-Inhalt:

firepower# show capture CAPI
   1: 05:20:36.654217   192.168.0.100.22195 > 10.10.1.100.80: S 1397289928:1397289928(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   2: 05:20:36.904311   192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   3: 05:20:36.905043   10.10.1.100.80 > 192.168.0.100.22196: R 1850052503:1850052503(0) ack 2171673259 win 0
   4: 05:20:37.414132   192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   5: 05:20:37.414803   10.10.1.100.80 > 192.168.0.100.22196: R 31997177:31997177(0) ack 2171673259 win 0
   6: 05:20:37.914183   192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,nop,sackOK>
...

CAPO-Inhalt:

firepower# show capture CAPO
   1: 05:20:36.654507   802.1Q vlan#202 P0 192.168.0.100.22195 > 10.10.1.100.80: S 2866789268:2866789268(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>
   2: 05:20:36.904478   802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4785344:4785344(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>
   3: 05:20:36.904997   802.1Q vlan#202 P0 10.10.1.100.80 > 192.168.0.100.22196: R 0:0(0) ack 4785345 win 0
   4: 05:20:37.414269   802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4235354730:4235354730(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>
   5: 05:20:37.414758   802.1Q vlan#202 P0 10.10.1.100.80 > 192.168.0.100.22196: R 0:0(0) ack 4235354731 win 0
   6: 05:20:37.914305   802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4118617832:4118617832(0) win 8192 <mss 1380,nop,nop,sackOK>

Dieses Bild zeigt die Erfassung von CAPI in Wireshark.

Wichtigste Punkte:

1. Die Quelle sendet ein TCP SYN-Paket.
2. Eine TCP-RST wird an die Quelle gesendet.
3. Die Quelle überträgt die TCP-SYN-Pakete erneut.
4. Die MAC-Adressen sind korrekt (bei eingehenden Paketen gehört die Quell-MAC-Adresse zum Downstream-Router, die Ziel-MAC-Adresse zur INSIDE-Schnittstelle der Firewall).

Dieses Bild zeigt die Aufnahme von CAPO in Wireshark:

Wichtigste Punkte:

1. Die Quelle sendet ein TCP SYN-Paket.
2. Eine TCP-RST kommt über die OUTSIDE-Schnittstelle an.
3. Die Quelle überträgt die TCP-SYN-Pakete erneut.
4. Die MAC-Adressen sind richtig (bei Ausgangspaketen ist die Firewall AUSSERHALB die Quell-MAC, der Upstream-Router die Ziel-MAC).

Auf der Grundlage der beiden Aufzeichnungen kann der Schluss gezogen werden, dass

• Der TCP-3-Wege-Handshake zwischen Client und Server wird nicht abgeschlossen
• Es gibt eine TCP-RST, die an der Firewall-Ausgangsschnittstelle eingeht.
• Die Firewall kommuniziert mit den entsprechenden Upstream- und Downstream-Geräten (basierend auf den MAC-Adressen).

Empfohlene Maßnahmen

Mit den in diesem Abschnitt aufgeführten Maßnahmen soll das Problem weiter eingegrenzt werden.

Maßnahme 1: Überprüfen Sie die Quell-MAC-Adresse, die die TCP-RST sendet.

Überprüfen Sie, ob die Ziel-MAC im TCP-SYN-Paket mit der Quell-MAC im TCP-RST-Paket übereinstimmt.

Diese Prüfung hat zum Ziel, 2 Dinge zu bestätigen:

• Stellen Sie sicher, dass kein asymmetrischer Fluss vorhanden ist.
• Überprüfen Sie, ob die MAC-Adresse zum erwarteten Upstream-Gerät gehört.

Maßnahme 2: Vergleich von ein- und ausgehenden Paketen

Vergleichen Sie visuell die beiden Pakete in Wireshark, um sicherzustellen, dass die Firewall die Pakete nicht verändert/beschädigt. Einige erwartete Unterschiede werden hervorgehoben.

Wichtigste Punkte:

1. Die Zeitstempel sind unterschiedlich. Auf der anderen Seite muss der Unterschied gering und vernünftig sein. Dies hängt von den Funktionen und Richtlinienprüfungen ab, die auf das Paket angewendet werden, sowie von der Last auf dem Gerät.
2. Die Länge der Pakete unterscheidet sich insbesondere dann, wenn ein dot1Q-Header von der Firewall nur auf einer Seite hinzugefügt/entfernt wird.
3. Die MAC-Adressen sind unterschiedlich.
4. Ein dot1Q-Header kann vorhanden sein, wenn die Erfassung auf einer Subschnittstelle durchgeführt wurde.
5. Die IP-Adresse(n) ist/sind unterschiedlich, wenn NAT oder Port Address Translation (PAT) auf das Paket angewendet wird.
6. Die Quell- oder Ziel-Ports unterscheiden sich, wenn NAT oder PAT auf das Paket angewendet wird.
7. Wenn Sie die Wireshark Relative Sequence Number-Option deaktivieren, stellen Sie fest, dass die TCP-Sequenznummern/Bestätigungsnummern durch die Firewall aufgrund der ISN-Randomisierung (Initial Sequence Number) geändert werden.
8. Einige TCP-Optionen können überschrieben werden. Beispielsweise ändert die Firewall standardmäßig die maximale TCP-Segmentgröße (Maximum Segment Size, MSS) auf 1380, um eine Paketfragmentierung im Transportpfad zu vermeiden.

Maßnahme 3: Nehmen Sie eine Aufnahme am Ziel.

Wenn möglich, machen Sie eine Erfassung am Ziel selbst. Wenn dies nicht möglich ist, nehmen Sie eine Erfassung so nahe wie möglich am Ziel vor. Ziel hierbei ist es zu überprüfen, wer die TCP-RST sendet (handelt es sich um den Zielserver oder ein anderes Gerät im Pfad?).

Fall 3: TCP 3-Wege-Handshake + RST von einem Endgerät

Dieses Bild zeigt die Topologie:

Problembeschreibung: HTTP funktioniert nicht

Betroffener Datenfluss:

Quelle IP: 192.168.0.100

Ziel-IP: 10.10.1.100

Protokoll: TCP 80

Erfassungsanalyse

Aktivieren Sie Aufnahmen auf der FTD LINA-Engine.

firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100
firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100

Erfassungen - Nicht-funktionales Szenario:

Es gibt verschiedene Möglichkeiten, wie dieses Problem in Aufnahmen manifestiert werden kann.

3.1 - TCP-3-Wege-Handshake + verzögerte RST vom Client

Sowohl die Firewall als auch der CAPI enthalten die gleichen Pakete, wie im Bild gezeigt.

Wichtigste Punkte:

1. Der TCP 3-Wege Handshake geht durch die Firewall.
2. Der Server sendet erneut SYN/ACK.
3. Der Client sendet die ACK erneut.
4. Nach ~20 Sekunden gibt der Client auf und sendet eine TCP-RST.

Empfohlene Maßnahmen

Mit den in diesem Abschnitt aufgeführten Maßnahmen soll das Problem weiter eingegrenzt werden.

Maßnahme 1: Nehmen Sie Aufnahmen so nah wie möglich an den beiden Endpunkten vor.

Die Firewall-Erfassungen zeigen an, dass die Client-ACK nicht vom Server verarbeitet wurde. Dies beruht auf folgenden Tatsachen:

• Der Server sendet erneut SYN/ACK.
• Der Client sendet die ACK erneut.
• Der Client sendet eine TCP-RST oder eine FIN/ACK-Nachricht vor allen Daten.

Erfassung auf dem Server zeigt das Problem. Der Client ACK vom TCP 3-Wege-Handshake kam nie an:

3.2 - TCP-3-Wege-Handshake + verzögerte FIN/ACK vom Client + verzögerte RST vom Server

Sowohl die Firewall als auch der CAPI enthalten die gleichen Pakete, wie im Bild gezeigt.

Wichtigste Punkte:

1. Der TCP 3-Wege Handshake geht durch die Firewall.
2. Nach ca. 5 Sekunden sendet der Client eine FIN/ACK.
3. Nach ~20 Sekunden gibt der Server auf und sendet eine TCP-RST.

Auf Basis dieser Erfassung kann geschlossen werden, dass es zwar einen TCP 3-Wege-Handshake durch die Firewall gibt, es aber so aussieht, als würde er nie an einem Endpunkt abgeschlossen (die Neuübertragungen deuten darauf hin).

Empfohlene Maßnahmen

Wie in Fall 3.1

3.3 - TCP-3-Wege-Handshake + verzögerte RST vom Client

Sowohl die Firewall als auch der CAPI enthalten die gleichen Pakete, wie im Bild gezeigt.

Wichtigste Punkte:

1. Der TCP 3-Wege Handshake geht durch die Firewall.
2. Nach ~20 Sekunden gibt der Client auf und sendet eine TCP-RST.

Auf der Grundlage dieser Aufzeichnungen kann der Schluss gezogen werden, dass:

• Nach 5-20 Sekunden gibt ein Endpunkt auf und beschließt, die Verbindung zu beenden.
  
  

Empfohlene Maßnahmen

Wie in Fall 3.1

3.4 - TCP-3-Wege-Handshake + sofortige RST vom Server

Sowohl die Firewall als auch der CAPI enthalten diese Pakete, wie im Bild gezeigt.

Wichtigste Punkte:

1. Der TCP 3-Wege Handshake geht durch die Firewall.
2. Ein paar Millisekunden nach dem ACK-Paket erfolgt eine TCP-RST vom Server.

Empfohlene Maßnahmen

Aktion: Nehmen Sie Aufnahmen so nah wie möglich am Server vor.

Eine sofortige TCP-RST vom Server kann auf einen fehlerhaften Server oder ein fehlerhaftes Gerät im Pfad hinweisen, von dem die TCP-RST gesendet wird. Erfassen Sie den Server selbst, und bestimmen Sie die Quelle der TCP-RST.

Fall 4: TCP RST vom Client

Dieses Bild zeigt die Topologie:

Problembeschreibung: HTTP funktioniert nicht.

Betroffener Datenfluss:

Quelle IP: 192.168.0.100

Ziel-IP: 10.10.1.100

Protokoll: TCP 80

Erfassungsanalyse

Aktivieren Sie Aufnahmen auf FTD LINA-Engine.

firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100
firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100

Erfassungen - Nicht-funktionales Szenario:

Dies sind die CAPI-Inhalte.

firepower# show capture CAPI

14 packets captured

   1: 12:32:22.860627   192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   2: 12:32:23.111307   192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   3: 12:32:23.112390   192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0
   4: 12:32:25.858109   192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   5: 12:32:25.868698   192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0
   6: 12:32:26.108118   192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   7: 12:32:26.109079   192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0
   8: 12:32:26.118295   192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0
   9: 12:32:31.859925   192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,nop,sackOK>
  10: 12:32:31.860902   192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0
  11: 12:32:31.875229   192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0
  12: 12:32:32.140632   192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0
  13: 12:32:32.159995   192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,nop,sackOK>
  14: 12:32:32.160956   192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0
14 packets shown

Dies sind die CAPO-Inhalte:

firepower# show capture CAPO

11 packets captured

   1: 12:32:22.860780   802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 1386249852:1386249852(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>
   2: 12:32:23.111429   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 3000518857:3000518857(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>
   3: 12:32:23.112405   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 3514091874:3514091874(0) win 0
   4: 12:32:25.858125   802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 1386249852:1386249852(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>
   5: 12:32:25.868729   802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: R 2968892337:2968892337(0) win 0
   6: 12:32:26.108240   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 3822259745:3822259745(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>
   7: 12:32:26.109094   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 40865466:40865466(0) win 0
   8: 12:32:31.860062   802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 4294058752:4294058752(0) win 8192 <mss 1380,nop,nop,sackOK>
   9: 12:32:31.860917   802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: R 1581733941:1581733941(0) win 0
  10: 12:32:32.160102   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 4284301197:4284301197(0) win 8192 <mss 1380,nop,nop,sackOK>
  11: 12:32:32.160971   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 502906918:502906918(0) win 0
11 packets shown

Die Firewall-Protokolle zeigen Folgendes an:

firepower# show log | i 47741
Oct 13 2019 13:57:36: %FTD-6-302013: Built inbound TCP connection 4869 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80)
Oct 13 2019 13:57:36: %FTD-6-302014: Teardown TCP connection 4869 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE
Oct 13 2019 13:57:39: %FTD-6-302013: Built inbound TCP connection 4870 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80)
Oct 13 2019 13:57:39: %FTD-6-302014: Teardown TCP connection 4870 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE
Oct 13 2019 13:57:45: %FTD-6-302013: Built inbound TCP connection 4871 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80)
Oct 13 2019 13:57:45: %FTD-6-302014: Teardown TCP connection 4871 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE

Diese Protokolle zeigen an, dass eine TCP-RST-Nachricht an der Firewall INSIDE-Schnittstelle eingeht.

CAPI-Erfassung in Wireshark:

Folgen Sie dem ersten TCP-Stream, wie in der Abbildung dargestellt.

Navigieren Sie unter Wireshark zu Edit > Preferences > Protocols > TCP, und deaktivieren Sie die Option Relative Sequenznummern wie im Bild dargestellt.

Dieses Bild zeigt den Inhalt des ersten Flusses bei der CAPI-Erfassung:

Wichtigste Punkte:

1. Der Client sendet ein TCP-SYN-Paket.
2. Der Client sendet ein TCP-RST-Paket.
3. Das TCP-SYN-Paket hat einen Sequenznummernwert gleich 4098574664.

Derselbe Fluss in der CAPO-Erfassung enthält:

Wichtigste Punkte:

1. Der Client sendet ein TCP-SYN-Paket. Die Firewall setzt den ISN nach dem Zufallsprinzip um.
2. Der Client sendet ein TCP-RST-Paket.

Auf der Grundlage der beiden Aufzeichnungen kann der Schluss gezogen werden, dass

• Es gibt keinen TCP-Drei-Wege-Handshake zwischen Client und Server.
• Es gibt eine TCP-RST, die vom Client stammt. Der Wert für die TCP-RST-Sequenznummer bei der CAPI-Erfassung ist 1386249853.

Empfohlene Maßnahmen

Mit den in diesem Abschnitt aufgeführten Maßnahmen soll das Problem weiter eingegrenzt werden.

Maßnahme 1: Erfassen Sie den Client.

Basierend auf den Aufnahmen, die über die Firewall gesammelt wurden, gibt es deutliche Hinweise auf einen asymmetrischen Datenfluss. Dies basiert darauf, dass der Client eine TCP-RST mit dem Wert 1386249853 (das randomisierte ISN) sendet:

Wichtigste Punkte:

1. Der Client sendet ein TCP-SYN-Paket. Die Sequenznummer lautet 4098574664 und ist mit der Sequenznummer auf der Firewall INSIDE-Schnittstelle (CAPI) identisch.
2. Es gibt ein TCP SYN/ACK mit der ACK-Nummer 1386249853 (dies wird aufgrund der ISN-Randomisierung erwartet). Dieses Paket wurde bei der Firewall-Erfassung nicht erkannt.
3. Der Client sendet eine TCP-RST, da er eine SYN/ACK mit dem ACK-Zahlenwert 4098574665 erwartet hat, aber den Wert 1386249853 erhalten hat.

Dies kann wie folgt visualisiert werden:

Maßnahme 2: Überprüfen Sie das Routing zwischen Client und Firewall.

Bestätigen Sie Folgendes:

• Die bei den Erfassungen angezeigten MAC-Adressen sind die erwarteten.
• Stellen Sie sicher, dass das Routing zwischen der Firewall und dem Client symmetrisch ist.

Es gibt Szenarien, in denen die RST von einem Gerät stammt, das sich zwischen der Firewall und dem Client befindet, während im internen Netzwerk ein asymmetrisches Routing stattfindet. Ein typischer Fall ist in der Abbildung dargestellt:

In diesem Fall hat die Erfassung diesen Inhalt. Beachten Sie den Unterschied zwischen der Quell-MAC-Adresse des TCP-SYN-Pakets und der Quell-MAC-Adresse der TCP-RST und der Ziel-MAC-Adresse des TCP-SYN/ACK-Pakets:

firepower# show capture CAPI detail
   1: 13:57:36.730217 4c4e.35fc.fcd8 00be.75f6.1dae 0x0800 Length: 66
      192.168.0.100.47740 > 10.10.1.100.80: S [tcp sum ok] 3045001876:3045001876(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF) (ttl 127, id 25661)
   2: 13:57:36.981104 4c4e.35fc.fcd8 00be.75f6.1dae 0x0800 Length: 66
      192.168.0.100.47741 > 10.10.1.100.80: S [tcp sum ok] 3809380540:3809380540(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF) (ttl 127, id 25662)
   3: 13:57:36.981776 00be.75f6.1dae a023.9f92.2a4d 0x0800 Length: 66
      10.10.1.100.80 > 192.168.0.100.47741: S [tcp sum ok] 1304153587:1304153587(0) ack 3809380541 win 8192 <mss 1380,nop,wscale 8,nop,nop,sackOK> (DF) (ttl 127, id 23339)
   4: 13:57:36.982126 a023.9f92.2a4d 00be.75f6.1dae 0x0800 Length: 54
      192.168.0.100.47741 > 10.10.1.100.80: R [tcp sum ok] 3809380541:3809380541(0) ack 1304153588 win 8192 (ttl 255, id 48501)
...

Fall 5: Langsame TCP-Übertragung (Szenario 1)

Problembeschreibung:

Die SFTP-Übertragung zwischen den Hosts 10.11.4.171 und 10.77.19.11 ist langsam. Obwohl die minimale Bandbreite (BW) zwischen den beiden Hosts 100 Mbit/s beträgt, geht die Übertragungsgeschwindigkeit nicht über 5 Mbit/s hinaus.

Gleichzeitig ist die Übertragungsgeschwindigkeit zwischen den Hosts 10.11.2.124 und 172.25.18.134 deutlich höher.

Hintergrundtheorie:

Die maximale Übertragungsgeschwindigkeit für einen einzelnen TCP-Datenstrom wird durch das Bandwidth Delay Product (BDP) bestimmt. Die verwendete Formel wird im Bild angezeigt:

Weitere Informationen zum BDP finden Sie in den Ressourcen unter:

• Warum nutzt Ihre Anwendung nur 10 Mbit/s Auch wenn die Verbindung 1 Gbit/s beträgt?
• BRKSEC-3021 - Advanced - Maximierung der Firewall-Leistung

Szenario 1. Langsame Übertragung

Dieses Bild zeigt die Topologie:

Betroffener Datenfluss:

Quelle IP: 10.11.4.171

Ziel-IP: 10.77.19.11

Protokoll: SFTP (FTP über SSH)

Erfassungsanalyse

Erfassung auf FTD LINA-Engine aktivieren:

firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11
firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11

Warnung: LINA-Erfassungen bei FP1xxx- und FP21xx-Erfassungen wirken sich auf die Übertragungsrate des Datenverkehrs aus, der über die FTD übertragen wird. Aktivieren Sie LINA-Aufzeichnungen auf FP1xxx- und FP21xxx-Plattformen nicht, wenn Sie Leistungsprobleme beheben (langsame Übertragung durch FTD). Verwenden Sie stattdessen SPAN oder ein HW-Tap-Gerät, zusätzlich zu den Erfassungen auf dem Quell- und Zielhost. Das Problem ist in der Cisco Bug-ID CSCvo30697 dokumentiert.

firepower# capture CAPI type raw-data trace interface inside match icmp any any
WARNING: Running packet capture can have an adverse impact on performance.

Empfohlene Maßnahmen

Mit den in diesem Abschnitt aufgeführten Maßnahmen soll das Problem weiter eingegrenzt werden.

Berechnung der Round-Trip-Zeit (RTT)

Identifizieren Sie zunächst den Übergabestrom, und folgen Sie ihm:

Ändern Sie die Wireshark-Ansicht, um die Sekunden seit dem zuvor angezeigten Paket anzuzeigen. Dies erleichtert die Berechnung der RTT:

Die RTT kann durch Addition der Zeitwerte zwischen 2 Paketvermittlungsstellen (einer zur Quelle und einer zum Ziel) berechnet werden. In diesem Fall zeigt Paket #2 den RTT zwischen der Firewall und dem Gerät an, das das SYN/ACK-Paket (Server) gesendet hat. Paket #3 zeigt die RTT zwischen der Firewall und dem Gerät, das das ACK-Paket gesendet hat (Client). Durch Hinzufügen der beiden Zahlen ergibt sich eine gute Schätzung des End-to-End-RTTs:

RTT ≈ 80 ms

Berechnung der TCP-Fenstergröße

Erweitern Sie ein TCP-Paket, erweitern Sie den TCP-Header, wählen Sie Berechnete Fenstergröße aus, und wählen Sie Als Spalte übernehmen:

Überprüfen Sie in der Spalte Berechneter Fenstergrößenwert, um den maximalen Fenstergrößenwert während der TCP-Sitzung anzuzeigen. Sie können auch den Spaltennamen auswählen und die Werte sortieren.

Wenn Sie einen Dateidownload testen (Server > Client), müssen Sie die vom Server angegebenen Werte überprüfen. Der vom Server angegebene Wert für die maximale Fenstergröße bestimmt die erreichte maximale Übertragungsgeschwindigkeit.

In diesem Fall beträgt die TCP-Fenstergröße ≈ 50000 Byte

Basierend auf diesen Werten und unter Verwendung der Formel Bandwidth Delay Product erhalten Sie die maximale theoretische Bandbreite, die unter diesen Bedingungen erreicht werden kann: 50000*8/0,08 = 5 Mbit/s maximale theoretische Bandbreite.

Dies entspricht dem, was der Client in diesem Fall erlebt.

Überprüfen Sie den Drei-Wege-TCP-Handshake genau. Beide Seiten, und noch wichtiger der Server, kündigen einen Fensterskalierungswert von 0 an, was 2^0 = 1 bedeutet (keine Fensterskalierung). Dies wirkt sich negativ auf die Übertragungsrate aus:

An dieser Stelle muss eine Erfassung auf dem Server durchgeführt werden, es muss überprüft werden, ob es derjenige ist, der Fensterskala = 0 ankündigt, und diese neu konfiguriert werden (weitere Informationen hierzu finden Sie in der Serverdokumentation).

Szenario 2. Schnelle Weiterleitung

Betrachten wir nun das gute Szenario (schnelle Übertragung über dasselbe Netzwerk):

Topologie:

Der Fluss des Interesses:

Quelle IP: 10.11.2.124

Ziel: 172.25.18.134

Protokoll: SFTP (FTP über SSH)

Erfassung auf FTD LINA-Engine aktivieren

firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134
firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134

Berechnung der Round Trip Time (RTT): In diesem Fall beträgt die RTT ≈ 300 ms.

Berechnung der TCP-Fenstergröße: Der Server kündigt einen TCP-Fensterskalierungsfaktor von 7 an.

Die TCP-Fenstergröße des Servers beträgt ≈ 1600000 Byte:

Basierend auf diesen Werten ergibt die Formel für die Bandbreitenverzögerung:

1600000 x 8/0,3 = 43 Mbit/s theoretische maximale Übertragungsgeschwindigkeit

Fall 6: Langsame TCP-Übertragung (Szenario 2)

Problembeschreibung: Die FTP-Dateiübertragung (Download) durch die Firewall ist langsam.

Dieses Bild zeigt die Topologie:

Betroffener Datenfluss:

Quelle IP: 192.168.2.220

Ziel: 192.168.1.220

Protokoll: FTP

Erfassungsanalyse

Aktivieren Sie Aufnahmen auf der FTD LINA-Engine.

firepower# capture CAPI type raw-data buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220
firepower# cap CAPO type raw-data buffer 33554432 interface OUTSIDE match tcp host 192.168.2.220 host 192.168.1.220

Wählen Sie ein FTP-DATA-Paket aus, und folgen Sie dem FTP Data Channel auf FTD INSIDE Capture (CAPI):

Inhalt des FTP-DATA-Streams:

Der CAPO-Inhalt:

Wichtigste Punkte:

1. Es gibt TCP Out-Of-Order (OOO)-Pakete.
2. Es findet eine TCP-Neuübertragung statt.
3. Es gibt einen Hinweis auf einen Paketverlust (verlorene Pakete).

Tipp: Speichern Sie die Aufzeichnungen, während Sie zu Datei > Angegebene Pakete exportieren navigieren. Speichern Sie dann nur den angezeigten Paketbereich.

Empfohlene Maßnahmen

Mit den in diesem Abschnitt aufgeführten Maßnahmen soll das Problem weiter eingegrenzt werden.

Maßnahme 1: Identifizieren Sie den Ort für den Paketverlust.

In Fällen wie diesem müssen Sie gleichzeitig aufzeichnen und die divide-and-conquer-Methode verwenden, um die Netzwerksegmente zu identifizieren, die einen Paketverlust verursachen. Aus Sicht der Firewall gibt es drei Hauptszenarien:

1. Der Paketverlust wird durch die Firewall selbst verursacht.
2. Der Paketverlust wird Downstream zum Firewall-Gerät verursacht (Richtung vom Server zum Client).
3. Der Paketverlust wird Upstream zum Firewall-Gerät verursacht (Richtung vom Client zum Server).

Paketverlust durch die Firewall: Um festzustellen, ob der Paketverlust durch die Firewall verursacht wird, muss die Eingangserfassung mit der Ausgangserfassung verglichen werden. Es gibt viele Möglichkeiten, zwei verschiedene Aufnahmen zu vergleichen. Dieser Abschnitt zeigt eine Möglichkeit, diese Aufgabe durchzuführen.

Verfahren zum Vergleichen von 2 Erfassungen zur Identifizierung des Paketverlusts

Schritt 1: Stellen Sie sicher, dass die beiden Erfassungen Pakete aus demselben Zeitfenster enthalten. Das bedeutet, dass bei einer Erfassung keine Pakete erfasst werden dürfen, die vor oder nach der anderen Erfassung erfasst wurden. Es gibt mehrere Möglichkeiten, dies zu tun:

• Überprüfen Sie den ersten und letzten Wert der Paket-IP-Identifikation (ID).
• Überprüfen Sie den ersten und letzten Paketzeitstempelwert.

In diesem Beispiel können Sie sehen, dass die ersten Pakete jeder Erfassung die gleichen IP-ID-Werte haben:

Falls sie nicht identisch sind:

1. Vergleichen Sie die Zeitstempel des ersten Pakets jeder Erfassung.
2. Von der Erfassung mit dem neuesten Zeitstempel einen Filter abrufen und den Zeitstempelfilter von == auf >= (das erste Paket) und <= (das letzte Paket) ändern, z.B.:

 (frame.time >= "Oct 16, 2019 16:13:43.244692000") &&(frame.time <= "Oct 16, 2019 16:20:21.785130000")

  3. Exportieren Sie die angegebenen Pakete in eine neue Erfassung, wählen Sie Datei > Angegebene Pakete exportieren, und speichern Sie dann die angezeigten Pakete. An diesem Punkt müssen beide Erfassungen Pakete enthalten, die dasselbe Zeitfenster abdecken. Sie können nun den Vergleich der 2 Aufnahmen starten.

Schritt 2: Geben Sie an, welches Paketfeld für den Vergleich zwischen den beiden Erfassungen verwendet wird. Beispiel für verwendbare Felder:

• IP-Identifizierung
• RTP-Sequenznummer
• ICMP-Sequenznummer

Erstellen Sie eine Textversion jeder Erfassung, die das Feld für jedes Paket enthält, das Sie in Schritt 1 angegeben haben. Um dies zu tun, lassen Sie nur die Spalte von Interesse, zum Beispiel, wenn Sie Pakete basierend auf IP-Identifizierung vergleichen wollen dann ändern Sie die Erfassung wie im Bild dargestellt.

Ergebnis:

Schritt 3: Erstellen Sie eine Textversion der Erfassung (Datei > Paketdissektionen exportieren > Als Klartext...), wie im Bild gezeigt:

Deaktivieren Sie die Optionen Spaltenüberschriften und Paketdetails einschließen, um nur die Werte des angezeigten Felds zu exportieren, wie in der Abbildung dargestellt:

Schritt 4: Sortieren Sie die Pakete in den Dateien. Dazu können Sie den Linux-Befehl sort verwenden:

# sort CAPI_IDs > file1.sorted
# sort CAPO_IDs > file2.sorted

Schritt 5: Verwenden Sie ein Textvergleichstool (z. B. WinMerge) oder den Linux-Befehl diff, um die Unterschiede zwischen den beiden Aufnahmen zu ermitteln.

In diesem Fall sind die CAPI- und CAPO-Erfassung für den FTP-Datenverkehr identisch. Dies beweist, dass der Paketverlust nicht durch die Firewall verursacht wurde.

Identifizieren von Upstream-/Downstream-Paketverlusten

Wichtigste Punkte:

1. Dieses Paket ist eine TCP-Neuübertragung. Dabei handelt es sich insbesondere um ein TCP-SYN-Paket, das vom Client für passive FTP-Daten an den Server gesendet wird. Da der Client das Paket erneut sendet und Sie die anfängliche SYN (Paket #1) sehen können, ging das Paket Upstream zur Firewall verloren.

In diesem Fall besteht die Möglichkeit, dass das SYN-Paket den Server erreicht hat, das SYN/ACK-Paket jedoch auf dem Rückweg verloren ging:

2. Es liegt ein Paket vom Server vor, und Wireshark hat festgestellt, dass das vorherige Segment nicht gesehen/erfasst wurde. Da das nicht erfasste Paket vom Server an den Client gesendet wurde und nicht in der Firewall-Erfassung zu sehen war, ging das Paket zwischen dem Server und der Firewall verloren.

Dies weist auf einen Paketverlust zwischen dem FTP-Server und der Firewall hin.

Maßnahme 2: Nehmen Sie zusätzliche Aufzeichnungen vor.

Nehmen Sie zusätzliche Aufnahmen zusammen mit Aufnahmen an den Endpunkten. Versuchen Sie, die divide-and-conquer-Methode anzuwenden, um das problematische Segment, das den Paketverlust verursacht, weiter zu isolieren.

Wichtigste Punkte:

1. Der Empfänger (in diesem Fall der FTP-Client) verfolgt die eingehenden TCP-Sequenznummern. Wenn ein Paket nicht erkannt wurde (eine erwartete Sequenznummer wurde übersprungen), wird ein ACK-Paket mit der ACK='erwarteten Sequenznummer, die übersprungen wurde' generiert. In diesem Beispiel ist Ack=2224386800.
2. Die Dup ACK löst eine schnelle TCP-Neuübertragung aus (Neuübertragung innerhalb von 20 ms nach Empfang einer Duplikat-ACK).

Was bedeuten doppelte ACKs?

• Ein paar doppelte ACKs, aber keine tatsächlichen Neuübertragungen deuten darauf hin, dass es wahrscheinlicher ist, dass Pakete nicht in der richtigen Reihenfolge ankommen.
• Doppelte ACKs und anschließende erneute Übertragungen weisen auf einen gewissen Paketverlust hin.

Maßnahme 3: Berechnen Sie die Verarbeitungszeit der Firewall für übertragene Pakete.

Wenden Sie die gleiche Erfassung auf zwei verschiedene Schnittstellen an:

firepower# capture CAPI buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220 
firepower# capture CAPI interface OUTSIDE

Exportieren der Erfassungsüberprüfung der Zeitdifferenz zwischen Eingangs- und Ausgangspaketen


Fall 7: TCP-Verbindungsproblem (Paketbeschädigung)

Problembeschreibung:

Der Wireless-Client (192.168.21.193) versucht, eine Verbindung zu einem Zielserver herzustellen (192.168.14.250 - HTTP). Es gibt zwei verschiedene Szenarien:

• Wenn der Client eine Verbindung mit Access Point (AP) 'A' herstellt, funktioniert die HTTP-Verbindung nicht.
• Wenn der Client eine Verbindung mit Access Point (AP) 'B' herstellt, funktioniert die HTTP-Verbindung.

Dieses Bild zeigt die Topologie:

Betroffener Datenfluss:

Quelle IP: 192.168.21.193

Ziel: 192.168.14.250

Protokoll: TCP 80

Erfassungsanalyse

Erfassung auf FTD LINA-Engine aktivieren:

firepower# capture CAPI int INSIDE match ip host 192.168.21.193 host 192.168.14.250
firepower# capture CAPO int OUTSIDE match ip host 192.168.21.193 host 192.168.14.250

Erfassungen - Funktionsszenario:

Als Basislinie ist es immer sehr nützlich, Aufzeichnungen aus einem zweifelsfrei funktionierenden Szenario zu haben.

Dieses Bild zeigt die Erfassung der NGFW INSIDE-Schnittstelle.

Dieses Bild zeigt die Erfassung der NGFW-OUTSIDE-Schnittstelle.

Wichtigste Punkte:

1. Die beiden Aufnahmen sind fast identisch (man denke an die ISN-Randomisierung).
2. Es gibt keine Anzeichen für einen Paketverlust.
3. Keine Out-of-Order (OOB)-Pakete
4. Es gibt 3 HTTP GET-Anforderungen. Die erste erhält die Nummer 404 "Nicht gefunden", die zweite die Nummer 200 "OK" und die dritte die Nummer 304 "Nicht geändert".

Aufnahmen - Szenario mit bekannter Störung:

Der CAPI-Inhalt (Ingress Capture).

Wichtigste Punkte:

1. Es gibt einen Drei-Wege-TCP-Handshake.
2. Es gibt TCP-Neuübertragungen und Hinweise auf einen Paketverlust.
3. Es gibt ein Paket (TCP ACK), das von Wireshark als fehlerhaft identifiziert wird.

Dieses Bild zeigt den CAPO-Inhalt (Egress Capture).

Wichtigste Punkte:

Die beiden Aufnahmen sind fast identisch (man denke an die ISN-Randomisierung):

1. Es gibt einen Drei-Wege-TCP-Handshake.
2. Es gibt TCP-Neuübertragungen und Hinweise auf einen Paketverlust.
3. Es gibt ein Paket (TCP ACK), das von Wireshark als fehlerhaft identifiziert wird.

Überprüfen Sie das fehlerhafte Paket:

Wichtigste Punkte:

1. Das Paket wird von Wireshark als fehlerhaft identifiziert.
2. Er hat eine Länge von 2 Byte.
3. Es gibt eine TCP-Nutzlast von 2 Byte.
4. Die Nutzlast beträgt 4 zusätzliche Nullen (00 00).
   
   

Empfohlene Maßnahmen

Mit den in diesem Abschnitt aufgeführten Maßnahmen soll das Problem weiter eingegrenzt werden.

Maßnahme 1: Machen Sie zusätzliche Aufnahmen. Integrieren Sie Erfassungen an den Endpunkten, und versuchen Sie nach Möglichkeit, die divide-and-conquer-Methode anzuwenden, um die Quelle der Paketbeschädigung zu isolieren. Beispiel:

In diesem Fall wurden die 2 zusätzlichen Byte durch den Switch-Schnittstellentreiber "A" hinzugefügt, und die Lösung bestand darin, den Switch zu ersetzen, der die Beschädigung verursacht.

Fall 8: UDP-Verbindungsproblem (fehlende Pakete)

Problembeschreibung: Syslog-Meldungen (UDP 514) werden auf dem Ziel-Syslog-Server nicht erkannt.

Dieses Bild zeigt die Topologie:

Betroffener Datenfluss:

Quelle IP: 192.168.1.81

Ziel-IP: 10.10.1.73

Protokoll: UDP 514

Erfassungsanalyse

Erfassung auf FTD LINA-Engine aktivieren:

firepower# capture CAPI int INSIDE trace match udp host 192.168.1.81 host 10.10.1.73 eq 514
firepower# capture CAPO int OUTSIDE match udp host 192.168.1.81 host 10.10.1.73 eq 514

FTD-Erfassungen zeigen keine Pakete an:

firepower# show capture
capture CAPI type raw-data trace interface INSIDE [Capturing - 0 bytes]
  match udp host 192.168.1.81 host 10.10.1.73 eq syslog
capture CAPO type raw-data interface OUTSIDE [Capturing - 0 bytes]
  match udp host 192.168.1.81 host 10.10.1.73 eq syslog

Empfohlene Maßnahmen

Mit den in diesem Abschnitt aufgeführten Maßnahmen soll das Problem weiter eingegrenzt werden.

Maßnahme 1: Überprüfen Sie die FTD-Verbindungstabelle.

Um eine bestimmte Verbindung zu überprüfen, können Sie folgende Syntax verwenden:

firepower# show conn address 192.168.1.81 port 514
10 in use, 3627189 most used
Inspect Snort:
        preserve-connection: 6 enabled, 0 in effect, 74 most enabled, 0 most in effect

UDP INSIDE  10.10.1.73:514 INSIDE  192.168.1.81:514, idle 0:00:00, bytes 480379697, flags -oN1

Wichtigste Punkte:

1. Die Eingangs- und Ausgangsschnittstellen sind identisch (umgekehrt).
2. Die Anzahl der Bytes hat einen signifikant großen Wert (~5 GB).
3. Die Markierung "o" steht für Flow Offload (HW Accelerated Flow). Aus diesem Grund werden bei der FTD-Erfassung keine Pakete angezeigt. Flow Offload wird nur auf 41xx- und 93xx-Plattformen unterstützt. In diesem Fall ist das Gerät ein 41xx.

Maßnahme 2: Nehmen Sie Aufnahmen auf Chassis-Ebene.

Stellen Sie eine Verbindung zum FirePOWER-Chassis-Manager her, und aktivieren Sie die Erfassung an der Eingangsschnittstelle (in diesem Fall E1/2) und an den Backplane-Schnittstellen (E1/9 und E1/10), wie im Bild gezeigt:

Nach einigen Sekunden:

Tipp: Schließen Sie in Wireshark die mit VN gekennzeichneten Pakete aus, um die Paketduplizierung auf Ebene der physischen Schnittstelle zu vermeiden.

Vorher:

Nachher:

Wichtigste Punkte:

1. Ein Anzeigefilter wird angewendet, um Paketduplikate zu entfernen und nur Syslogs anzuzeigen.
2. Der Unterschied zwischen den Paketen liegt auf der Mikrosekundenebene. Dies weist auf eine sehr hohe Paketrate hin.
3. Der TTL-Wert (Time to Live) nimmt kontinuierlich ab. Zeigt eine Paketschleife an.

Maßnahme 3: Packet-Tracer verwenden.

Da die Pakete die LINA-Engine der Firewall nicht passieren, können Sie keine Live-Verfolgung (Erfassung mit Trace) durchführen. Sie können jedoch ein emuliertes Paket mit Packet Tracer verfolgen:

firepower# packet-tracer input INSIDE udp 10.10.1.73 514 192.168.1.81 514

Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found flow with id 25350892, using existing flow

Phase: 4
Type: SNORT
Subtype:
Result: ALLOW
Config:
Additional Information:
Snort Verdict: (fast-forward) fast forward this flow

Phase: 5
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 192.168.1.81 using egress ifc  INSIDE

Phase: 6
Type: ADJACENCY-LOOKUP
Subtype: next-hop and adjacency
Result: ALLOW
Config:
Additional Information:
adjacency Active
next-hop mac address a023.9f92.2a4d hits 1 reference 1

Phase: 7
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: INSIDE
output-status: up
output-line-status: up
Action: allow

Maßnahme 4: Bestätigen Sie die FTD-Weiterleitung.

Prüfen Sie die Routing-Tabelle der Firewall, um festzustellen, ob Routing-Probleme vorliegen:

firepower# show route 10.10.1.73

Routing entry for 10.10.1.0 255.255.255.0
  Known via "eigrp 1", distance 90, metric 3072, type internal
  Redistributing via eigrp 1
  Last update from 192.168.2.72 on OUTSIDE, 0:03:37 ago
  Routing Descriptor Blocks:
  * 192.168.2.72, from 192.168.2.72, 0:02:37 ago, via OUTSIDE
      Route metric is 3072, traffic share count is 1
      Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 29/255, Hops 1

Wichtigste Punkte:

1. Die Route verweist auf die richtige Ausgangsschnittstelle.
2. Die Route wurde vor wenigen Minuten (0:02:37) gelernt.

Maßnahme 5: Bestätigen Sie die Verfügbarkeit der Verbindung.

Überprüfen Sie die Verbindungsverfügbarkeit, um zu sehen, wann diese Verbindung hergestellt wurde:

firepower# show conn address 192.168.1.81 port 514 detail
21 in use, 3627189 most used
Inspect Snort:
        preserve-connection: 19 enabled, 0 in effect, 74 most enabled, 0 most in effect
Flags: A - awaiting responder ACK to SYN, a - awaiting initiator ACK to SYN,
       b - TCP state-bypass or nailed,
       C - CTIQBE media, c - cluster centralized,
       D - DNS, d - dump, E - outside back connection, e - semi-distributed,
       F - initiator FIN, f - responder FIN,
       G - group, g - MGCP, H - H.323, h - H.225.0, I - initiator data,
       i - incomplete, J - GTP, j - GTP data, K - GTP t3-response
       k - Skinny media, L - decap tunnel, M - SMTP data, m - SIP media
       N - inspected by Snort (1 - preserve-connection enabled, 2 - preserve-connection in effect)
       n - GUP, O - responder data, o - offloaded,
       P - inside back connection, p - passenger flow
       q - SQL*Net data, R - initiator acknowledged FIN,
       R - UDP SUNRPC, r - responder acknowledged FIN,
       T - SIP, t - SIP transient, U - up,
       V - VPN orphan, v - M3UA W - WAAS,
       w - secondary domain backup,
       X - inspected by service module,
       x - per session, Y - director stub flow, y - backup stub flow,
       Z - Scansafe redirection, z - forwarding stub flow

UDP INSIDE: 10.10.1.73/514 INSIDE: 192.168.1.81/514,
    flags -oN1, idle 0s, uptime 3m49s, timeout 2m0s, bytes 4801148711

Kernaussage:

1. Die Verbindung wurde vor ca. 4 Minuten hergestellt (dies ist vor der EIGRP-Routeninstallation in der Routing-Tabelle)

Maßnahme 6. Löscht die hergestellte Verbindung.

In diesem Fall stimmen die Pakete mit einer bestehenden Verbindung überein und werden an eine falsche Ausgangsschnittstelle weitergeleitet. Dies führt zu einer Schleife. Der Grund hierfür ist die Firewall-Betriebsreihenfolge:

1. Suche nach bestehender Verbindung (hat Vorrang vor der globalen Suche in der Routing-Tabelle).
2. NAT-Suche (Network Address Translation) - Die UN-NAT-Phase (Ziel-NAT) hat Vorrang vor der PBR- und Routensuche.
3. Richtlinienbasiertes Routing
4. Globale Routingtabellen-Suche

Da die Verbindung niemals zu einem Timeout führt (der Syslog-Client sendet fortlaufend Pakete, während die UDP-Konnektivitäts-Zeitüberschreitung 2 Minuten beträgt), muss die Verbindung manuell geleert werden:

firepower# clear conn address 10.10.1.73 address 192.168.1.81 protocol udp port 514
1 connection(s) deleted.

Überprüfen Sie, ob eine neue Verbindung hergestellt wurde:

firepower# show conn address 192.168.1.81 port 514 detail | b 10.10.1.73.*192.168.1.81
UDP OUTSIDE: 10.10.1.73/514 INSIDE: 192.168.1.81/514,
    flags -oN1, idle 1m15s, uptime 1m15s, timeout 2m0s, bytes 408

Maßnahme 7. Timeout für Floating-Verbindung konfigurieren

Dies ist die richtige Lösung, um das Problem zu beheben und suboptimales Routing zu vermeiden, insbesondere bei UDP-Datenflüssen. Navigieren Sie zu Devices (Geräte) > Platform Settings (Plattformeinstellungen) > Timeouts, und legen Sie den Wert fest:

Weitere Details zum Timeout für Floating Conn finden Sie in der Befehlsreferenz:

https://www.cisco.com/c/en/us/td/docs/security/asa/asa-cli-reference/T-Z/asa-command-ref-T-Z.html#pgfId-1649892

Fall 9: HTTPS-Verbindungsproblem (Szenario 1)

Problembeschreibung: HTTPS-Kommunikation zwischen Client 192.168.201.105 und Server 192.168.202.101 nicht möglich

Dieses Bild zeigt die Topologie:

Betroffener Datenfluss:

Quelle IP: 192.168.201.111

Ziel: 192.168.202.111

Protokoll: TCP 443 (HTTPS)

Erfassungsanalyse

Erfassung auf FTD LINA-Engine aktivieren:

Die bei der OUTSIDE-Erfassung verwendete IP unterscheidet sich aufgrund der Konfiguration für die Port-Adressenumwandlung.

firepower# capture CAPI int INSIDE match ip host 192.168.201.111 host 192.168.202.111
firepower# capture CAPO int OUTSIDE match ip host 192.168.202.11 host 192.168.202.111

Dieses Bild zeigt die Erfassung der NGFW INSIDE-Schnittstelle:

Wichtigste Punkte:

1. Es gibt einen Drei-Wege-TCP-Handshake.
2. SSL-Aushandlung wird gestartet. Der Client sendet eine Client-Hello-Nachricht.
3. An den Client wird ein TCP-ACK gesendet.
4. Es wird eine TCP-RST an den Client gesendet.

Dieses Bild zeigt die Erfassung der NGFW-OUTSIDE-Schnittstelle.

Wichtigste Punkte:

1. Es gibt einen Drei-Wege-TCP-Handshake.
2. SSL-Aushandlung wird gestartet. Der Client sendet eine Client-Hello-Nachricht.
3. Es werden TCP-Neuübertragungen von der Firewall an den Server gesendet.
4. Es wird eine TCP-RST an den Server gesendet.

Empfohlene Maßnahmen

Mit den in diesem Abschnitt aufgeführten Maßnahmen soll das Problem weiter eingegrenzt werden.

Maßnahme 1: Machen Sie zusätzliche Aufnahmen.

Eine vom Server durchgeführte Erfassung zeigt, dass der Server die TLS-Client-Hellos mit einer beschädigten TCP-Prüfsumme empfangen hat und diese automatisch verwirft (es gibt keine TCP-RST oder andere Antwortpakete an den Client):

Wenn Sie alles zusammenstellen:

In diesem Fall muss, um zu verstehen, in Wireshark die Option TCP-Prüfsumme validieren, wenn möglich, aktiviert werden. Navigieren Sie zu Bearbeiten > Voreinstellungen > Protokolle > TCP, wie im Bild dargestellt.

In diesem Fall ist es hilfreich, die Aufnahmen nebeneinander zu platzieren, um das vollständige Bild zu erhalten:

Wichtigste Punkte:

1. Es gibt einen Drei-Wege-TCP-Handshake. Die IP-IDs sind identisch. Dies bedeutet, dass der Datenfluss nicht von der Firewall bereitgestellt wurde.
2. Ein TLS-Client Hello stammt vom Client mit der IP-ID 12083. Das Paket wird von der Firewall als Proxy weitergeleitet (in diesem Fall wurde die Firewall mit einer TLS-Entschlüsselungsrichtlinie konfiguriert), und die IP-ID wird in 52534 geändert. Außerdem wird die Paket-TCP-Prüfsumme beschädigt (aufgrund eines Softwarefehlers, der später behoben wurde).
3. Die Firewall befindet sich im TCP-Proxy-Modus und sendet eine ACK an den Client (wodurch der Server getäuscht wird).
   
   
   
   
4. Die Firewall empfängt kein TCP-ACK-Paket vom Server und sendet die TLS-Client-Hello-Nachricht erneut. Dies ist wiederum auf den TCP Proxy Modus zurückzuführen, den die Firewall aktiviert hat.
5. Nach ca. 30 Sekunden gibt die Firewall auf und sendet eine TCP-RST an den Client.
6. Die Firewall sendet eine TCP-RST an den Server.

Zur Referenz:

FirePOWER TLS/SSL-Handshake-Verarbeitung

Fall 10: HTTPS-Verbindungsproblem (Szenario 2)

Problembeschreibung: FMC Smart License Registrierung fehlgeschlagen.

Dieses Bild zeigt die Topologie:

Betroffener Datenfluss:

Quelle IP: 192.168.0.100

Ziel: tools.cisco.com

Protokoll: TCP 443 (HTTPS)

Erfassungsanalyse

Aktivieren Sie die Erfassung auf der FMC-Management-Schnittstelle:

Registrieren Sie sich erneut. Sobald die Fehlermeldung angezeigt wird, drücken Sie STRG + C, um die Erfassung zu beenden:

root@firepower:/Volume/home/admin# tcpdump -i eth0 port 443 -s 0 -w CAP.pcap
HS_PACKET_BUFFER_SIZE is set to 4.
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C264 packets captured				<- CTRL-C
264 packets received by filter
0 packets dropped by kernel
root@firepower:/Volume/home/admin#

Erfassen Sie die Aufzeichnung vom FMC (System > Health > Monitor (System > Zustand > Monitor), wählen Sie das Gerät aus, und wählen Sie Advanced Troubleshooting (Erweiterte Fehlerbehebung)) aus, wie im Bild gezeigt:

Das Bild zeigt die FMC-Erfassung in Wireshark:

Tipp: Um zu überprüfen, ob alle neuen TCP-Sitzungen erfasst wurden, verwenden Sie den tcp.flags==0x2-Anzeigefilter in Wireshark. Dadurch werden alle erfassten TCP-SYN-Pakete gefiltert.

Tipp: Wenden Sie das Feld Servername aus dem SSL Client Hello als Spalte an.

Tipp: Wenden Sie diesen Anzeigefilter an, um nur die Client Hello-Nachrichten ssl.handshake.type == 1 anzuzeigen.

Hinweis: Zum Zeitpunkt der Erstellung dieses Dokuments nutzt das Smart Licensing-Portal (tools.cisco.com) die folgenden IP-Adressen: 72.163.4.38, 173.37.145.8

Folgen Sie einem der TCP-Flows (Folgen > TCP-Stream), wie im Bild gezeigt.

Wichtigste Punkte:

1. Es gibt einen Drei-Wege-TCP-Handshake.
2. Der Client (FMC) sendet eine SSL Client Hello-Nachricht an das Smart Licensing-Portal.
3. Die SSL-Sitzungs-ID lautet 0. Dies bedeutet, dass es sich nicht um eine wiederaufgenommene Sitzung handelt.
4. Der Zielserver antwortet mit der "Server Hello"-, "Certificate"- und "Server Hello Done"-Nachricht.
5. Der Client sendet eine schwerwiegende SSL-Warnung, die eine "unbekannte Zertifizierungsstelle" betrifft.
6. Der Client sendet eine TCP-RST, um die Sitzung zu schließen.
7. Die gesamte TCP-Sitzungsdauer (von der Einrichtung bis zum Abschluss) betrug ca. 0,5 Sekunden.

Wählen Sie das Serverzertifikat aus, und erweitern Sie das Ausstellerfeld, um den commonName anzuzeigen. In diesem Fall zeigt der Common Name ein Gerät, das Man-in-the-Middle (MITM) unterstützt.

Dies wird in der folgenden Abbildung dargestellt:

Empfohlene Maßnahmen

Mit den in diesem Abschnitt aufgeführten Maßnahmen soll das Problem weiter eingegrenzt werden.

Maßnahme 1: Machen Sie zusätzliche Aufnahmen.

Erfassung auf dem Transport-Firewall-Gerät:

CAPI zeigt:

CAPO zeigt an:

Diese Erfassungen belegen, dass die Transit-Firewall das Serverzertifikat (MITM) ändert.

Maßnahme 2: Überprüfen der Geräteprotokolle

Sie können das FMC TS-Paket wie in diesem Dokument beschrieben sammeln:

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

In diesem Fall zeigt die Datei /dir-archives/var-log/process_stdout.log folgende Meldungen an:

SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla[10068]: *Wed .967 UTC: CH-LIB-ERROR: ch_pf_curl_send_msg[494], 
failed to perform, err code 60, err string "SSL peer certificate or SSH remote key was not OK"
...
SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla[10068]: *Wed .967 UTC: CH-LIB-TRACE: ch_pf_curl_is_cert_issue[514], 
cert issue checking, ret 60, url "https://tools.cisco.com/its/

Empfohlene Lösung

Deaktivieren Sie den MITM für den jeweiligen Fluss, damit FMC sich erfolgreich bei der Smart Licensing-Cloud registrieren kann.

Fall 11: IPv6-Verbindungsproblem

Problembeschreibung: Interne Hosts (die sich hinter der INSIDE-Schnittstelle der Firewall befinden) können nicht mit externen Hosts (Hosts, die sich hinter der OUTSIDE-Schnittstelle der Firewall befinden) kommunizieren.

Dieses Bild zeigt die Topologie:

Betroffener Datenfluss:

Src-IP: fc00:1:1:1::100

Ziel-IP: fc00:1:1:2::2

Protokoll: Beliebig

Erfassungsanalyse

Aktivieren Sie Aufnahmen auf FTD LINA-Engine.

firepower# capture CAPI int INSIDE match ip any6 any6
firepower# capture CAPO int OUTSIDE match ip any6 any6

Erfassungen - Nicht-Funktionsszenario

Diese Erfassungen wurden parallel zu einem ICMP-Verbindungstest von IP fc00:1:1:1::100 (interner Router) zu IP fc00:1:1:2::2 (Upstream-Router) durchgeführt.

Die Erfassung auf der Firewall INSIDE-Schnittstelle umfasst:

Wichtigste Punkte:

1. Der Router sendet eine IPv6 Neighbor Solicitation-Nachricht und fragt nach der MAC-Adresse des Upstream-Geräts (IP fc00:1:1:1::1).
2. Die Firewall antwortet mit einer IPv6 Neighbor Advertisement.
3. Der Router sendet eine ICMP-Echoanfrage.
4. Die Firewall sendet eine IPv6 Neighbor Solicitation-Nachricht und fragt die MAC-Adresse des Downstream-Geräts ab (fc00:1:1:1::100).
5. Der Router antwortet mit einer IPv6 Neighbor Advertisement.
6. Der Router sendet zusätzliche IPv6-ICMP-Echoanfragen.

Die Erfassung auf der OUTSIDE-Schnittstelle der Firewall umfasst:

Wichtigste Punkte:

1. Die Firewall sendet eine IPv6 Neighbor Solicitation-Nachricht, in der die MAC-Adresse des Upstream-Geräts angefordert wird (IP fc00:1:1:2::2).
2. Der Router antwortet mit einer IPv6 Neighbor Advertisement.
3. Die Firewall sendet eine IPv6-ICMP-Echoanfrage.
4. Das Upstream-Gerät (Router fc00:1:1:2::2) sendet eine IPv6 Neighbor Solicitation-Nachricht, in der die MAC-Adresse der IPv6-Adresse fc00:1:1:1::100 angefordert wird.
5. Die Firewall sendet eine zusätzliche IPv6-ICMP-Echoanfrage.
6. Der Upstream-Router sendet eine zusätzliche IPv6 Neighbor Solicitation-Nachricht, in der die MAC-Adresse der IPv6-Adresse fc00:1:1:1::100 angefordert wird.

Punkt 4 ist sehr interessant. Normalerweise fragt der Upstream-Router nach der MAC-Adresse der OUTSIDE-Schnittstelle der Firewall (fc00:1:1:2::2), aber stattdessen nach der fc00:1:1:1::100. Dies ist ein Hinweis auf eine fehlerhafte Konfiguration.

Empfohlene Maßnahmen

Mit den in diesem Abschnitt aufgeführten Maßnahmen soll das Problem weiter eingegrenzt werden.

Maßnahme 1: Überprüfen Sie die IPv6 Neighbor Table.

Die IPv6-Nachbartabelle für die Firewall ist ordnungsgemäß ausgefüllt.

firepower# show ipv6 neighbor | i fc00
fc00:1:1:2::2                              58 4c4e.35fc.fcd8  STALE OUTSIDE
fc00:1:1:1::100                            58 4c4e.35fc.fcd8  STALE INSIDE

Maßnahme 2: Überprüfen der IPv6-Konfiguration

Dies ist die Firewall-Konfiguration.

firewall# show run int e1/2
!
interface Ethernet1/2
 nameif INSIDE
 cts manual
  propagate sgt preserve-untag
  policy static sgt disabled trusted
 security-level 0
 ip address 192.168.0.1 255.255.255.0
 ipv6 address fc00:1:1:1::1/64
 ipv6 enable

firewall# show run int e1/3.202
!
interface Ethernet1/3.202
 vlan 202
 nameif OUTSIDE
 cts manual
  propagate sgt preserve-untag
  policy static sgt disabled trusted
 security-level 0
 ip address 192.168.103.96 255.255.255.0
 ipv6 address fc00:1:1:2::1/64
 ipv6 enable

Die Konfiguration des Upstream-Geräts zeigt die fehlerhafte Konfiguration:

Router# show run interface g0/0.202
!
interface GigabitEthernet0/0.202
 encapsulation dot1Q 202
 vrf forwarding VRF202
 ip address 192.168.2.72 255.255.255.0
 ipv6 address FC00:1:1:2::2/48

Erfassungen - Funktionsszenario

Durch die Änderung der Subnetzmaske (von /48 auf /64) wurde das Problem behoben. Dies ist die CAPI-Erfassung im funktionalen Szenario.

Kernaussage:

1. Der Router sendet eine IPv6 Neighbor Solicitation-Nachricht, in der er nach der MAC-Adresse des Upstream-Geräts fragt (IP fc00:1:1:1::1).
2. Die Firewall antwortet mit einer IPv6 Neighbor Advertisement.
3. Der Router sendet ICMP-Echoanfragen und erhält Echoantworten.

CAPO-Inhalt:

Wichtigste Punkte:

1. Die Firewall sendet eine IPv6 Neighbor Solicitation-Nachricht, in der die MAC-Adresse des Upstream-Geräts angefordert wird (IP fc00:1:1:2::2).
2. Die Firewall antwortet mit einer IPv6 Neighbor Advertisement.
3. Die Firewall sendet eine ICMP-Echoanfrage.
4. Der Router sendet eine IPv6 Neighbor Solicitation-Nachricht, in der er nach der MAC-Adresse des Downstream-Geräts fragt (IP fc00:1:1:1::1).
5. Die Firewall antwortet mit einer IPv6 Neighbor Advertisement.
6. Die Firewall sendet ICMP-Echoanfragen und erhält Echoantworten.

Fall 12: Intermittierendes Verbindungsproblem (ARP Poisoning)

Problembeschreibung: Interne Hosts (192.168.0.x/24) haben zeitweilige Verbindungsprobleme mit Hosts im gleichen Subnetz

Dieses Bild zeigt die Topologie:

Betroffener Datenfluss:

Quelle IP: 192.168.0.x/24

Ziel-IP: 192.168.0.x/24

Protokoll: Beliebig

Der ARP-Cache eines internen Hosts ist anscheinend beschädigt:

Erfassungsanalyse

Erfassung auf FTD LINA-Engine aktivieren

Diese Erfassung erfasst nur ARP-Pakete an der INSIDE-Schnittstelle:

firepower# capture CAPI_ARP interface INSIDE ethernet-type arp

Erfassungen - Nicht-Funktionsszenario:

Die Erfassung auf der Firewall INSIDE-Schnittstelle enthält

Wichtigste Punkte:

1. Die Firewall empfängt verschiedene ARP-Anfragen für IPs innerhalb des Netzwerks 192.168.0.x/24
2. Die Firewall beantwortet alle Anfragen (Proxy-ARP) mit einer eigenen MAC-Adresse

Empfohlene Maßnahmen

Mit den in diesem Abschnitt aufgeführten Maßnahmen soll das Problem weiter eingegrenzt werden.

Maßnahme 1: Überprüfen der NAT-Konfiguration

In Bezug auf die NAT-Konfiguration gibt es Fälle, in denen das no-proxy-arp-Schlüsselwort das frühere Verhalten verhindern kann:

firepower# show run nat
nat (INSIDE,OUTSIDE) source static NET_1.1.1.0 NET_2.2.2.0 destination static NET_192.168.0.0 NET_4.4.4.0 no-proxy-arp

Maßnahme 2: Deaktivieren Sie die Proxy-ARP-Funktion an der Firewall-Schnittstelle.

Wenn das Schlüsselwort "no-proxy-arp" das Problem nicht löst, versuchen Sie, den Proxy-ARP auf der Schnittstelle selbst zu deaktivieren. Bei FTD müssen Sie zum Zeitpunkt der Erstellung dieses Dokuments FlexConfig verwenden und den Befehl bereitstellen (geben Sie den entsprechenden Schnittstellennamen an).

sysopt noproxyarp INSIDE

Fall 13: Identifizieren von SNMP-Objektbezeichnern (OIDs), die CPU-Hogs verursachen

Dieser Fall zeigt, wie bestimmte SNMP OIDs für das Speicher-Polling auf Basis der Analyse von SNMP-Paketerfassungen der Version 3 (SNMPv3) als Ursache von CPU-Hogs (Leistungsproblemen) identifiziert wurden.

Problembeschreibung: Die Überlastung der Datenschnittstellen nimmt stetig zu. Weitere Untersuchungen haben ergeben, dass es auch CPU-Hogs gibt (verursacht durch den SNMP-Prozess), die die Ursache für die Schnittstellenüberläufe sind.

Der nächste Schritt beim Fehlerbehebungsprozess bestand darin, die Ursache der CPU-Probleme zu identifizieren, die durch den SNMP-Prozess verursacht wurden. Insbesondere sollte der Umfang des Problems eingegrenzt werden, um die SNMP-Objektbezeichner (OID) zu identifizieren, die beim Abfragen möglicherweise zu CPU-Problemen führen können.

Derzeit bietet die FTD LINA-Engine keinen "show"-Befehl für SNMP-OIDs, die in Echtzeit abgefragt werden.

Die Liste der SNMP OIDs für das Polling kann vom SNMP-Überwachungstool abgerufen werden. In diesem Fall gab es jedoch die folgenden vorbeugenden Faktoren:

• Der FTD-Administrator hatte keinen Zugriff auf das SNMP-Überwachungstool.
• SNMP-Version 3 mit Authentifizierung und Datenverschlüsselung wurde auf FTD konfiguriert.

Erfassungsanalyse

Da der FTD-Administrator über die Anmeldeinformationen für die SNMP-Authentifizierung Version 3 und die Datenverschlüsselung verfügte, wurde dieser Aktionsplan vorgeschlagen:

1. SNMP-Paketerfassung übernehmen
2. Speichern Sie die Aufzeichnungen, und verwenden Sie die Wireshark SNMP-Protokolleinstellungen, um die SNMP-Anmeldeinformationen der Version 3 zum Entschlüsseln der SNMP-Pakete der Version 3 anzugeben. Die entschlüsselten Erfassungen werden für die Analyse und den Abruf von SNMP OIDs verwendet.

Konfigurieren Sie die SNMP-Paketerfassung auf der Schnittstelle, die in der snmp-server-Hostkonfiguration verwendet wird:

firepower# show run snmp-server  | include host
snmp-server host management 192.168.10.10 version 3 netmonv3


firepower# show ip address management
System IP Address:
Interface                Name                   IP address      Subnet mask     Method
Management0/0            management             192.168.5.254   255.255.255.0   CONFIG
Current IP Address:
Interface                Name                   IP address      Subnet mask     Method
Management0/0            management             192.168.5.254   255.255.255.0   CONFIG

firepower# capture capsnmp interface management buffer 10000000 match udp host 192.168.10.10  host 192.168.5.254 eq snmp

firepower# show capture capsnmp

capture capsnmp type raw-data buffer 10000000 interface outside [Capturing - 9512 bytes]
  match udp host 192.168.10.10  host 192.168.5.254 eq snmp

Wichtigste Punkte:

1. SNMP-Quell- und Zieladressen/-ports.
2. Die SNMP-Protokoll-PDU konnte nicht dekodiert werden, da der privKey für Wireshark unbekannt ist.
3. Der Wert der verschlüsselten PDU-Grundeinheit.

Empfohlene Maßnahmen

Mit den in diesem Abschnitt aufgeführten Maßnahmen soll das Problem weiter eingegrenzt werden.

Maßnahme 1: Entschlüsseln der SNMP-Aufzeichnungen

Speichern Sie die Aufzeichnungen, und bearbeiten Sie die Einstellungen des Wireshark-SNMP-Protokolls, um die SNMP-Anmeldeinformationen der Version 3 zum Entschlüsseln der Pakete anzugeben.

firepower# copy /pcap capture: tftp: 
Source capture name [capsnmp]?

Address or name of remote host []? 192.168.10.253

Destination filename [capsnmp]? capsnmp.pcap
!!!!!!
64 packets copied in 0.40 secs

Öffnen Sie die Erfassungsdatei in Wireshark, wählen Sie ein SNMP-Paket aus, und navigieren Sie zu Protokolleinstellungen > Benutzertabelle, wie im Bild gezeigt:

In der Tabelle "SNMP-Benutzer" wurden der SNMP-Benutzername Version 3, das Authentifizierungsmodell, das Authentifizierungskennwort, das Datenschutzprotokoll und das Datenschutzkennwort angegeben (die tatsächlichen Anmeldeinformationen werden unten nicht angezeigt):

Nachdem die SNMP-Benutzereinstellungen übernommen wurden, zeigte Wireshark entschlüsselte SNMP-PDUs an:

Wichtigste Punkte:

1. Die SNMP-Überwachungstools verwendeten SNMP getBulkRequest, um die übergeordnete OID 1.3.6.1.4.1.9.9.221.1 und die zugehörigen OIDs abzufragen und zu durchlaufen.
2. Die FTD antwortete auf jede getBulkRequest mit get-response, die OIDs im Zusammenhang mit 1.3.6.1.4.1.9.9.221.1 enthielt.

Maßnahme 2: Identifizieren der SNMP OIDs

SNMP Object Navigator hat gezeigt, dass die OID 1.3.6.1.4.1.9.9.221.1 zur Management Information Base (MIB) mit dem Namen CISCO-ENHANCED-MEMPOOL-MIB gehört, wie im Bild gezeigt:

So zeigen Sie die OIDs in einem für Menschen lesbaren Format in Wireshark an:

1. Laden Sie MIB CISCO-ENHANCED-MEMPOOL-MIB und die dazugehörigen Abhängigkeiten herunter, wie im Bild gezeigt:

2. In Wireshark im Fenster Bearbeiten > Voreinstellungen > Namensauflösung ist OID-Auflösung aktivieren aktiviert. Geben Sie im Fenster SMI (MIB- und PIB-Pfade) den Ordner mit den heruntergeladenen MIBs und in SMI (MIB- und PIB-Module) an. Die CISCO-ENHANCED-MEMPOOL-MIB wird automatisch zur Modulliste hinzugefügt:

 3. Nach dem Neustart von Wireshark wird die OID-Auflösung aktiviert:

Basierend auf der entschlüsselten Ausgabe der Erfassungsdatei wurden vom SNMP-Überwachungstool in regelmäßigen Abständen (10-Sekunden-Intervall) Daten zur Nutzung von Speicherpools auf dem FTD abgefragt. Wie im TechNote-Artikel ASA SNMP Polling for Memory-Related Statistics erläutert, führt das Polling der Nutzung des globalen gemeinsamen Pools (GSP) mit SNMP zu einer hohen CPU-Auslastung. In diesem Fall wurde aus den Erfassungen deutlich, dass die Nutzung des globalen gemeinsamen Pools regelmäßig als Teil von SNMP getBulkRequest primitive abgefragt wurde.

Um die durch den SNMP-Prozess verursachten CPU-Hogs zu minimieren, wurde empfohlen, die im Artikel genannten Schritte zur Risikominimierung für CPU-Hogs für SNMP zu befolgen und ein Abfragen der OIDs in Bezug auf GSP zu vermeiden. Ohne die SNMP-Abfrage für die OIDs, die sich auf GSP beziehen, wurden keine CPU-Hogs beobachtet, die durch den SNMP-Prozess verursacht wurden, und die Rate der Überläufe hat sich deutlich verringert.

Zugehörige Informationen

• Cisco FirePOWER Management Center - Konfigurationsleitfäden
• Klären der Regelaktionen der Firepower Threat Defense-Richtlinien zur Zugriffskontrolle
• Arbeiten mit Firepower Threat Defense Captures und Packet Tracer
• Wireshark lernen