FTD-prefilterbeleid configureren en gebruiken

Inleiding

Dit document beschrijft de configuratie en werking van het beleid voor het voorfilteren van Firepower Threat Defense (FTD).

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

• ASA5506X met FTD-code 6.1.0-195
• Twee 3925 Cisco IOS®-routers met 15,2 images
• FireSIGHT Management Center (FMC) dat loopt van 6.1.0-195

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

Een prefilterbeleid is een functie die in versie 6.1 is geïntroduceerd en dient drie hoofddoelen:

1. Match verkeer op basis van zowel de binnen- als de buitenkant headers.
2. Zorg voor vroege toegangscontrole waarmee een stroom de Snort-engine volledig kan omzeilen.
3. Werk als plaatsaanduiding voor toegangscontrolevermeldingen (Access Control Entries, ACE's) die zijn gemigreerd vanuit het migratietool Adaptive Security Appliance (ASA).

Configureren

Voorfilter Beleidsgebruiksgeval 1

Een prefilterbeleid kan een type tunnelregel gebruiken waarmee FTD kan filteren op basis van zowel binnen als buiten het IP-header-tunnelverkeer. Op het moment dat dit artikel werd geschreven, verwijst tunnelverkeer naar:

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

Overweeg een GRE-tunnel zoals weergegeven in de afbeelding:

Wanneer u van R1 naar R2 pingt met behulp van een GRE-tunnel, gaat het verkeer door de firewall:

Als de firewall een ASA-apparaat is, wordt de buitenste IP-header gecontroleerd:

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

Als de firewall een FirePOWER-apparaat is, controleert deze de binnenste IP-header:

Met het voorfilterbeleid kan een FTD-apparaat verkeer matchen op basis van zowel binnen- als buitenheaders.

hoofdpunt

Voorfilter Beleidsgebruiksgeval 2

Een voorfilterbeleid kan een voorfilterregeltype gebruiken dat vroegtijdige toegangscontrole kan bieden en een stroom kan toestaan om de snortengine volledig te omzeilen:

Taak 1: Standaardvoorfilterbeleid verifiëren

Taakvereiste

Controleer het standaardbeleid voor het voorfilter.

Oplossing

1. Navigeer naar Beleid > Toegangsbeheer > Voorfilter. In dit voorbeeld bestaat er al een standaardvoorfilterbeleid:

2. Selecteer Bewerken om de beleidsinstellingen te bekijken:

3. Het Voorfilterbeleid is al aan het Toegangsbeheerbeleid gekoppeld:

CLI (LINA)-verificatie

Voorfilterregels worden toegevoegd bovenop ACL's:

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

Taak 2: Blokkeer tunnelverkeer met tag

Taakvereiste

Blokkeer het ICMP-verkeer dat in de GRE-tunnel wordt geleid.

Oplossing

1. Als u deze ACP's toepast, ziet u dat het verkeer van het Internet Control Message Protocol (ICMP) is geblokkeerd, zelfs als het door de GRE-tunnel gaat of niet:

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 dit voorbeeld kunt u een voorfilterbeleid gebruiken om aan de taakvereiste te voldoen. De logica is als volgt:

• Label alle pakketten die zijn ingekapseld in GRE.
• Maak een toegangsbeheerbeleid dat overeenkomt met de gelabelde pakketten en dat ICMP blokkeert. 

Vanuit het oogpunt van de architectuur worden de pakketten gecontroleerd aan de hand van de LInux Native (LINA) pre-filterregels, vervolgens worden de Snort-pre-filterregels en ACP gecontroleerd en tenslotte geeft Snort LINA de instructie om te laten vallen. Het eerste pakket maakt het via het FTD-apparaat.

1. Definieer een tag voor tunnelverkeer.

2. Navigeer naar Beleid > Toegangsbeheer > Voorfilter en maak een nieuw Voorfilterbeleid. Onthoud dat het standaardvoorfilterbeleid niet kan worden bewerkt:

Definieer in het voorfilterbeleid twee soorten regels:

• tunnelregel
• voorfilterregel

U kunt deze twee beschouwen als totaal verschillende functies die kunnen worden geconfigureerd in een voorfilterbeleid. Voor deze taak is het noodzakelijk om een tunnelregel te definiëren:.

Deze tabel definieert de acties met een korte beschrijving van elk:

2. Definieer het toegangscontrolebeleid voor het gecodeerde verkeer

• Hoewel het in eerste instantie niet erg intuïtief is, kan de Tunnel Tag worden gebruikt door een Access Control Policy Rule als bronzone. Navigeer naar Beleid > Toegangsbeheer en maak een regel die ICMP blokkeert voor het gecodeerde verkeer:

Opmerking: het nieuwe beleid voor prefilters is gekoppeld aan het beleid voor toegangsbeheer.

Verificatie

Opname op LINA en op CLISH inschakelen:

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

Probeer vanuit R1 het externe eindpunt van de GRE-tunnel te pingen; de ping mislukt:

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)

De CLISH-opname laat zien dat het eerste echo-verzoek via FTD ging en het antwoord werd geblokkeerd:

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

De LINA-vangst bevestigt dit:

> 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

Schakel CLISH firewall-engine-debug in, verwijder LINA ASP-valtellers en voltooi dezelfde test. De CLISH-foutopsporing laat zien dat u voor de Echo-Request de prefilterregel en voor de Echo-Reply de ACP-regel hebt gematcht:

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

De ASP-drop toont dat Snort de pakketten heeft laten vallen:

> 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

In de Verbindingsevenementen ziet u het beleid en de regel van het voorfilter die u hebt gematcht:

Taak 3: Snort-engine omzeilen met Fastpath Prefilter-regels

Netwerkdiagram

Taakvereiste

1. Verwijder de huidige regels voor het toegangscontrolebeleid en voeg een regel voor het toegangscontrolebeleid toe die al het verkeer blokkeert.
2. Configureer een voorfilterbeleidsregel die de Snort Engine omzeilt voor verkeer afkomstig van het 192.168.75.0/24-netwerk.

Oplossing

1. Toegangscontrolebeleid dat alle verkeer blokkeert:

2. Voeg een voorfilterregel toe met Fastpath als een actie voor bronnetwerk 192.168.75.0/24:

3. Het resultaat wordt weergegeven in de volgende afbeelding:

4. Opslaan en implementeren.

Opname met trace inschakelen op beide FTD-interfaces:

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

Probeer te pingen van R1 (192.168.75.39) naar R2 (192.168.76.39) via de FTD; ping mislukt:

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)

De opname aan de binnenkant interface toont:

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

Trace of first packet (echo-request) toont (belangrijke punten gemarkeerd):

Opname op de externe interface toont:

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

Trace van het retourpakket laat zien dat het overeenkomt met de huidige flow (52), maar wordt geblokkeerd door de ACL:

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. Voeg nog een voorfilterregel toe voor het retourverkeer, de volgende afbeelding geeft het resultaat weer

Traceer nu het retourpakket dat u ziet (belangrijke gemarkeerde punten):

Verifiëren

Gebruik dit gedeelte om te bevestigen dat de configuratie goed werkt. De verificatie is toegelicht in de desbetreffende takenrubrieken.

Problemen oplossen

Er is momenteel geen specifieke informatie beschikbaar om problemen met deze configuratie op te lossen.

Gerelateerde informatie

• Alle versies van de configuratiehandleiding van het Cisco Firepower Management Center zijn te vinden in de navigatiedocumentatie voor de Cisco Secure Firewall Threat Defense

• Cisco Global Technical Assistance Center (TAC) beveelt deze visuele gids ten zeerste aan voor diepgaande praktische kennis over Cisco Firepower Next Generation Security Technologies, inclusief de technologieën die in dit artikel worden genoemd onder Cisco Firepower Threat Defense (FTD)

• Raadpleeg Cisco Secure Firewall Management Center voor alle technische opmerkingen over configuratie en probleemoplossing

• Technische ondersteuning en documentatie – Cisco Systems