FTD-Vorfilterrichtlinien konfigurieren und ausführen

Einleitung

Dieses Dokument beschreibt die Konfiguration und den Betrieb von Firepower Threat Defense (FTD) Prefilter Policies.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

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

• ASA5506X mit FTD-Code 6.1.0-195
• Zwei 3925 Cisco IOS® Router mit 15.2 Images
• FireSIGHT Management Center (FMC) mit 6.1.0-195

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

Eine Prefilter Policy ist eine Funktion, die in Version 6.1 eingeführt wurde und drei Hauptaufgaben erfüllt:

1. Übereinstimmung des Datenverkehrs auf Basis der inneren und äußeren Kopfzeilen
2. Stellen Sie eine frühe Zugriffskontrolle bereit, die es einem Fluss ermöglicht, die Snort-Engine vollständig zu umgehen.
3. Sie fungieren als Platzhalter für Zugriffskontrolleinträge (Access Control Entries, ACEs), die vom Migrationstool der Adaptive Security Appliance (ASA) migriert werden.

Konfigurieren

Anwendungsfall 1 der Prefilter-Richtlinie

Eine Prefilter-Richtlinie kann einen Tunnel-Regeltyp verwenden, mit dem FTD auf Basis des internen und/oder externen getunnelten IP-Header-Datenverkehrs filtern kann. Zum Zeitpunkt der Erstellung dieses Artikels bezieht sich der getunnelte Datenverkehr auf:

• IP-in-IP
• IPv6-in-IP
• Teredo-Port 3544
• Generic Routing Encapsulation (GRE)

Betrachten Sie einen GRE-Tunnel wie in der Abbildung dargestellt:

Wenn Sie unter Verwendung eines GRE-Tunnels einen Ping-Befehl von R1 an R2 senden, durchläuft der Datenverkehr die Firewall:

Wenn es sich bei der Firewall um ein ASA-Gerät handelt, wird der äußere IP-Header überprüft:

ASA# show conn
GRE OUTSIDE 192.168.76.39:0 INSIDE  192.168.75.39:0, idle 0:00:17, bytes 520, flags

Wenn es sich bei der Firewall um ein FirePOWER-Gerät handelt, wird der innere IP-Header überprüft:

Mit der Prefilter-Richtlinie kann ein FTD-Gerät den Datenverkehr auf Basis der inneren und äußeren Kopfzeilen abgleichen.

Hauptpunkt

Anwendungsfall 2: Prefilter-Richtlinie

Eine Prefilter-Richtlinie kann einen Prefilter-Regeltyp verwenden, der eine frühe Zugriffskontrolle ermöglicht und ermöglicht, dass der Fluss die Snort-Engine vollständig umgeht:

Aufgabe 1: Standard-Vorfilterrichtlinie überprüfen

Voraussetzung für diese Aufgabe

Überprüfen Sie die standardmäßige Vorfilterrichtlinie.

Lösung

1. Navigieren Sie zu Richtlinien > Zugriffskontrolle > Vorfilter. In diesem Beispiel ist bereits eine Standardvorfilterrichtlinie vorhanden:

2. Wählen Sie Bearbeiten, um die Richtlinieneinstellungen anzuzeigen:

3. Die Vorfilterrichtlinie ist bereits der Zugriffskontrollrichtlinie angefügt:

CLI (LINA)-Überprüfung

Vorfilterregeln werden zusätzlich zu den ACLs hinzugefügt:

firepower# show access-list
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)
            alert-interval 300
access-list CSM_FW_ACL_; 5 elements; name hash: 0x4a69e3f3
access-list CSM_FW_ACL_ line 1 remark rule-id 9998: PREFILTER POLICY: Default Tunnel and Priority Policy
access-list CSM_FW_ACL_ line 2 remark rule-id 9998: RULE: DEFAULT TUNNEL ACTION RULE
access-list CSM_FW_ACL_ line 3 advanced permit ipinip any any rule-id 9998 (hitcnt=0) 0xf5b597d6
access-list CSM_FW_ACL_ line 4 advanced permit 41 any any rule-id 9998 (hitcnt=0) 0x06095aba
access-list CSM_FW_ACL_ line 5 advanced permit gre any any rule-id 9998 (hitcnt=5) 0x52c7a066
access-list CSM_FW_ACL_ line 6 advanced permit udp any any eq 3544 rule-id 9998 (hitcnt=0) 0xcf6309bc

Aufgabe 2: Getunnelten Verkehr mit Tag blockieren

Voraussetzung für diese Aufgabe

Blockieren von ICMP-Datenverkehr, der innerhalb des GRE-Tunnels getunnelt wird

Lösung

1. Wenn Sie diese ACPs anwenden, können Sie sehen, dass der ICMP-Datenverkehr blockiert ist, auch wenn er den GRE-Tunnel durchquert oder nicht:

R1# ping 192.168.76.39
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.76.39, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R1# ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

In diesem Beispiel können Sie eine Vorfilterrichtlinie verwenden, um die Aufgabenanforderung zu erfüllen. Die Logik ist wie folgt:

• Kennzeichnen Sie alle Pakete, die in GRE eingekapselt sind.
• Erstellen Sie eine Zugriffskontrollrichtlinie, die mit den gekennzeichneten Paketen übereinstimmt und ICMP blockiert. 

Aus architektonischer Sicht werden die Pakete mit den LINA-Vorfilterregeln (LInux Native), dann mit den Snort-Vorfilterregeln und ACP verglichen, und schließlich weist Snort LINA an, das Paket zu löschen. Das erste Paket durchläuft das FTD-Gerät.

1. Definieren Sie ein Tag für getunnelten Datenverkehr.

2. Navigieren Sie zu Richtlinien > Zugriffskontrolle > Prefilter, und erstellen Sie eine neue Prefilter-Richtlinie. Beachten Sie, dass die Standardvorfilterrichtlinie nicht bearbeitet werden kann:

Definieren Sie innerhalb der Vorfilterrichtlinie zwei Regeltypen:

• Tunnelregel
• Vorfilterregel

Sie können sich diese beiden als völlig unterschiedliche Funktionen vorstellen, die in einer Vorfilterrichtlinie konfiguriert werden können. Für diese Aufgabe muss eine Tunnelregel definiert werden:.

In dieser Tabelle werden die Aktionen mit einer kurzen Beschreibung der einzelnen Aktionen definiert:

2. Definieren Sie die Zugriffskontrollrichtlinie für den getaggten Datenverkehr.

• Obwohl es zunächst nicht sehr intuitiv ist, kann das Tunnel-Tag von einer Zugriffskontrollrichtlinie als Quellzone verwendet werden. Navigieren Sie zu Richtlinien > Zugriffskontrolle, und erstellen Sie eine Regel, die ICMP für den getaggten Datenverkehr blockiert:

Anmerkung: Die neue Vorfilterrichtlinie ist der Zugriffskontrollrichtlinie angefügt.

Verifizierung

Aktivieren Sie die Erfassung für LINA und CLISH:

firepower# show capture
capture CAPI type raw-data trace interface inside [Capturing - 152 bytes]
capture CAPO type raw-data trace interface outside [Capturing - 152 bytes]

> 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

Versuchen Sie, von R1 aus einen Ping an den entfernten GRE-Tunnel-Endpunkt zu senden. Der Ping schlägt fehl:

R1# ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Die CLISH-Erfassung zeigt, dass die erste Echo-Anfrage über FTD gesendet wurde und die Antwort blockiert wurde:

Options: -n
18:21:07.759939 IP 192.168.75.39 > 192.168.76.39: GREv0, length 104: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 65, seq 0, length 80
18:21:07.759939 IP 192.168.76.39 > 192.168.75.39: GREv0, length 104: IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 65, seq 0, length 80
18:21:09.759939 IP 192.168.75.39 > 192.168.76.39: GREv0, length 104: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 65, seq 1, length 80
18:21:11.759939 IP 192.168.75.39 > 192.168.76.39: GREv0, length 104: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 65, seq 2, length 80
18:21:13.759939 IP 192.168.75.39 > 192.168.76.39: GREv0, length 104: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 65, seq 3, length 80
18:21:15.759939 IP 192.168.75.39 > 192.168.76.39: GREv0, length 104: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 65, seq 4, length 80

Die LINA-Aufzeichnung bestätigt dies:

> show capture CAPI | include ip-proto-47
 102: 18:21:07.767523  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
 107: 18:21:09.763739  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
 111: 18:21:11.763769  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
 115: 18:21:13.763784  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
 120: 18:21:15.763830  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
>
> show capture CAPO | include ip-proto-47
  93: 18:21:07.768133  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
  94: 18:21:07.768438  192.168.76.39 > 192.168.75.39:  ip-proto-47, length 104

Aktivieren Sie CLISH firewall-engine-debug, deaktivieren Sie LINA ASP-Ablagerungsindikatoren, und führen Sie den gleichen Test durch. Das CLISH-Debugging zeigt, dass Sie für die Echo-Anforderung die Vorfilterregel und für die Echo-Reply die ACP-Regel zugeordnet haben:

10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 New session
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 uses prefilter rule 268434441 with tunnel zone 1
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 Starting with minimum 0, id 0 and SrcZone first with zones 1 -> -1, geo 0 -> 0, vlan 0, sgt tag: 65535, svc 0, payload 0, client 0, misc 0, user 9999997, icmpType 8, icmpCode 0
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 pending rule order 3, 'Block ICMP', AppId
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 uses prefilter rule 268434441 with tunnel zone 1
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 Starting with minimum 0, id 0 and SrcZone first with zones 1 -> -1, geo 0 -> 0, vlan 0, sgt tag: 65535, svc 3501, payload 0, client 2000003501, misc 0, user 9999997, icmpType 0, icmpCode 0
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 match rule order 3, 'Block ICMP', action Block
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 deny action

ASP-Dropdown zeigt, dass Snort die Pakete verworfen hat:

> show asp drop

Frame drop:
  No route to host (no-route)                                     366
  Reverse-path verify failed (rpf-violated)                         2
  Flow is denied by configured rule (acl-drop)                      2
  Snort requested to drop the frame (snort-drop)                    5

Unter Connection Events (Verbindungsereignisse) können Sie die Prefilter Policy (Vorfilterrichtlinie) und Rule (Regel) sehen, die Sie zugeordnet haben:

Aufgabe 3: Snort Engine mit Fastpath-Vorfilterregeln umgehen

Netzwerkdiagramm

Voraussetzung für diese Aufgabe

1. Entfernen Sie die aktuellen Richtlinien für die Zugriffskontrolle, und fügen Sie eine Richtlinie für die Zugriffskontrolle hinzu, die den gesamten Datenverkehr blockiert.
2. Konfigurieren Sie eine Vorfilterrichtlinienregel, die die Snort Engine für Datenverkehr umgeht, der aus dem Netzwerk 192.168.75.0/24 stammt.

Lösung

1. Zugriffskontrollrichtlinie, die den gesamten Datenverkehr blockiert:

2. Fügen Sie eine Vorfilterregel mit Fastpath als Aktion für das Quellnetzwerk 192.168.75.0/24 hinzu:

3. Das Ergebnis wird im nächsten Bild angezeigt:

4. Speichern und Bereitstellen.

Aktivieren Sie die Erfassung mit Ablaufverfolgung auf beiden FTD-Schnittstellen:

firepower# capture CAPI int inside trace match icmp any any
firepower# capture CAPO int outsid trace match icmp any any

Versuchen Sie, einen Ping von R1 (192.168.75.39) an R2 (192.168.76.39) über die FTD zu senden. Ping schlägt fehl:

R1# ping 192.168.76.39
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.76.39, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Die Erfassung auf der internen Schnittstelle zeigt Folgendes:

firepower# show capture CAPI

5 packets captured

   1: 23:35:07.281738   192.168.75.39 > 192.168.76.39: icmp: echo request
   2: 23:35:09.278641   192.168.75.39 > 192.168.76.39: icmp: echo request
   3: 23:35:11.279251   192.168.75.39 > 192.168.76.39: icmp: echo request
   4: 23:35:13.278778   192.168.75.39 > 192.168.76.39: icmp: echo request
   5: 23:35:15.279282   192.168.75.39 > 192.168.76.39: icmp: echo request
5 packets shown

Nachverfolgung des ersten Pakets (Echoanfrage) zeigt an (wichtige Punkte hervorgehoben):

Erfassung auf der externen Schnittstelle zeigt:

firepower# show capture CAPO

10 packets captured

   1: 23:35:07.282044   192.168.75.39 > 192.168.76.39: icmp: echo request
   2: 23:35:07.282227   192.168.76.39 > 192.168.75.39: icmp: echo reply
   3: 23:35:09.278717   192.168.75.39 > 192.168.76.39: icmp: echo request
   4: 23:35:09.278962   192.168.76.39 > 192.168.75.39: icmp: echo reply
   5: 23:35:11.279343   192.168.75.39 > 192.168.76.39: icmp: echo request
   6: 23:35:11.279541   192.168.76.39 > 192.168.75.39: icmp: echo reply
   7: 23:35:13.278870   192.168.75.39 > 192.168.76.39: icmp: echo request
   8: 23:35:13.279023   192.168.76.39 > 192.168.75.39: icmp: echo reply
   9: 23:35:15.279373   192.168.75.39 > 192.168.76.39: icmp: echo request
  10: 23:35:15.279541   192.168.76.39 > 192.168.75.39: icmp: echo reply
10 packets shown

Die Ablaufverfolgung des Rückgabepakets gibt an, dass es mit dem aktuellen Fluss übereinstimmt (52), aber von der ACL blockiert wird:

firepower# show capture CAPO packet-number 2 trace

10 packets captured

   2: 23:35:07.282227       192.168.76.39 > 192.168.75.39: icmp: echo reply
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 52, uses current flow

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 268434432 event-log flow-start
access-list CSM_FW_ACL_ remark rule-id 268434432: ACCESS POLICY: ACP_5506-1 - Default/1
access-list CSM_FW_ACL_ remark rule-id 268434432: L4 RULE: DEFAULT ACTION RULE
Additional Information:

Result:
input-interface: outside
input-status: up
input-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

5. Fügen Sie eine weitere Vorfilterregel für den zurückfließenden Verkehr, das nächste Bild zeigt das Ergebnis

Verfolgen Sie jetzt das angezeigte Rücksendepaket (wichtige Punkte hervorgehoben):

Überprüfung

Verwenden Sie diesen Abschnitt, um zu bestätigen, dass Ihre Konfiguration ordnungsgemäß funktioniert. Die Überprüfung wurde in den entsprechenden Aufgabenabschnitten erläutert.

Fehlerbehebung

Es sind derzeit keine spezifischen Informationen zur Fehlerbehebung für diese Konfiguration verfügbar.

Zugehörige Informationen

• Alle Versionen des Konfigurationsleitfadens für das Cisco FirePOWER Management Center finden Sie in der Navigating the Cisco Secure Firewall Threat Defense Documentation.

• Das Cisco Global Technical Assistance Center (TAC) empfiehlt dringend diese visuelle Anleitung, um detailliertes praktisches Wissen über die Sicherheitstechnologien der nächsten Generation von Cisco Firepower zu erhalten, einschließlich der in diesem Artikel unter Cisco Firepower Threat Defense (FTD) erwähnten Technologien

• Weitere technische Hinweise zur Konfiguration und Fehlerbehebung finden Sie im Cisco Secure Firewall Management Center.

• Technischer Support und Dokumentation für Cisco Systeme