Configurazione e funzionamento dei criteri di prefiltro FTD

Introduzione

Questo documento descrive la configurazione e il funzionamento dei criteri di prefiltro Firepower Threat Defense (FTD).

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• ASA5506X con codice FTD 6.1.0-195
• Due router 3925 Cisco IOS® con immagini da 15.2
• Centro di gestione FireSIGHT (FMC) con versione 6.1.0-195

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Un criterio di prefiltro è una funzione introdotta nella versione 6.1 e ha tre scopi principali:

1. Trova la corrispondenza del traffico in base alle intestazioni sia interne che esterne.
2. Fornire un controllo dell'accesso anticipato che consente a un flusso di ignorare completamente il motore Snort.
3. Fungere da segnaposto per le voci di controllo di accesso (ACE) di cui viene eseguita la migrazione dallo strumento di migrazione Adaptive Security Appliance (ASA).

Configurazione

Usa caso 1 criterio di prefiltro

Un criterio di prefiltro può utilizzare un tipo di regola tunnel che consente a FTD di filtrare in base al traffico di tunneling dell'intestazione IP sia all'interno che all'esterno. Al momento in cui è stato scritto questo articolo, il traffico di tunneling si riferisce a:

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

Considerare un tunnel GRE come mostrato nell'immagine:

Quando si esegue il ping da R1 a R2 con l'uso di un tunnel GRE, il traffico attraversa il firewall:

Se il firewall è un dispositivo ASA, controlla l'intestazione IP esterna:

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

Se il firewall è un dispositivo FirePOWER, controlla l'intestazione IP interna:

Con i criteri di prefiltro, un dispositivo FTD può abbinare il traffico in base alle intestazioni interne ed esterne.

Punto principale

Caso di utilizzo criteri di prefiltro 2

Un criterio di prefiltro può utilizzare un tipo di regola di prefiltro in grado di fornire un controllo di accesso anticipato e consentire a un flusso di ignorare completamente il motore di snort:

Attività 1: Verifica criterio prefiltro predefinito

Attività richiesta

Verificare i criteri di prefiltro predefiniti.

Soluzione

1. Passare a Criteri > Controllo accesso > Prefiltro. In questo esempio esiste già un criterio di prefiltro predefinito:

2. Selezionare Modifica per visualizzare le impostazioni dei criteri:

3. Il criterio di prefiltro è già associato al criterio di controllo dell'accesso:

Verifica CLI (LINA)

Le regole di prefiltro vengono aggiunte sugli ACL:

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

Attività 2: Blocca traffico tunneling con tag

Attività richiesta

Blocca il traffico ICMP tunneling all'interno del tunnel GRE.

Soluzione

1. Se si applicano questi ACP, è possibile verificare che il traffico ICMP (Internet Control Message Protocol) è bloccato, anche se attraversa o meno il tunnel GRE:

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 questo esempio è possibile utilizzare un criterio di filtro preliminare per soddisfare il requisito dell'attività. La logica è la seguente:

• Assegna tag a tutti i pacchetti incapsulati nel GRE.
• Creare un criterio di controllo dell'accesso che corrisponda ai pacchetti con tag e blocchi l'ICMP. 

Dal punto di vista dell'architettura, i pacchetti vengono controllati in base alle regole di pre-filtro LINA (Linux Native), quindi le regole di pre-filtro Snort e ACP e infine Snort indica a LINA di eliminarli. Il primo pacchetto passa attraverso il dispositivo FTD.

1. Definire un tag per il traffico tunneling.

2. Passare a Criteri > Controllo d'accesso > Prefiltro e creare un nuovo criterio di prefiltro. Non è possibile modificare i criteri di prefiltro predefiniti:

All'interno dei criteri di prefiltro, definire due tipi di regole:

• Regola tunnel
• Regola prefiltro

Queste due funzionalità possono essere configurate in modo completamente diverso in un criterio di prefiltro. Per questa operazione, è necessario definire una regola tunnel:.

Nella tabella riportata di seguito sono definite le azioni con una breve descrizione di ciascuna di esse.

2. Definire i criteri di controllo dell'accesso per il traffico contrassegnato

• Benché inizialmente non sia molto intuitivo, il tag Tunnel può essere utilizzato come zona di origine da una regola dei criteri di controllo di accesso. Passare a Policy > Controllo di accesso e creare una regola che blocchi l'ICMP per il traffico con tag:

Nota: Il nuovo criterio di prefiltro è associato al criterio di controllo dell'accesso.

Verifica

Abilitare l'acquisizione su LINA e su 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

Da R1, provare a eseguire il ping dell'endpoint del tunnel GRE remoto; il ping ha esito negativo:

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)

L'acquisizione CLISH mostra che la prima richiesta echo è stata sottoposta a FTD e che la risposta è stata bloccata:

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

La cattura di LINA conferma quanto segue:

> 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

Abilitare CLISH firewall-engine-debug, cancellare i contatori di rilascio ASP LINA e completare lo stesso test. Il debug CLISH mostra che per la richiesta echo è stata trovata una corrispondenza con la regola di prefiltro e per la regola Echo-Reply è stata trovata la corrispondenza con la regola ACP:

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

Il drop ASP mostra i pacchetti ignorati da Snort:

> 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 Eventi connessione è possibile visualizzare i criteri di prefiltro e la regola corrispondenti:

Attività 3: Ignora motore di snort con regole di prefiltro Fastpath

Esempio di rete

Attività richiesta

1. Rimuovere le regole dei criteri di controllo di accesso correnti e aggiungere una regola dei criteri di controllo di accesso che blocchi tutto il traffico.
2. Configurare una regola dei criteri di prefiltro che ignori il motore di snort per il traffico proveniente dalla rete 192.168.75.0/24.

Soluzione

1. Criteri di controllo di accesso che bloccano tutto il traffico:

2. Aggiungere una regola di prefiltro con Fastpath come azione per la rete di origine 192.168.75.0/24:

3. Il risultato viene visualizzato nell'immagine seguente:

4. Salvare e distribuire.

Abilita acquisizione con traccia su entrambe le interfacce FTD:

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

Provare a eseguire il ping tra R1 (192.168.75.39) e R2 (192.168.76.39) tramite l'FTD; ping non riuscito:

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)

L'acquisizione sull'interfaccia interna mostra:

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

La traccia del primo pacchetto (richiesta echo) mostra (punti importanti evidenziati):

L'acquisizione sull'interfaccia esterna mostra:

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

La traccia del pacchetto restituito indica che corrisponde al flusso corrente (52), ma è bloccato dall'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. Aggiungere un'altra regola di prefiltro per il traffico di ritorno. Nell'immagine successiva viene visualizzato il risultato

Tracciare il pacchetto di ritorno visualizzato (punti importanti evidenziati):

Verifica

Utilizzare questa sezione per verificare che la configurazione funzioni correttamente. La verifica è stata spiegata nelle rispettive sezioni delle attività.

Risoluzione dei problemi

Al momento non sono disponibili informazioni specifiche per la risoluzione dei problemi di questa configurazione.

Informazioni correlate

• Tutte le versioni della guida alla configurazione di Cisco Firepower Management Center sono disponibili nella sezione Navigazione nella documentazione di Cisco Secure Firewall Threat Defense

• Cisco Global Technical Assistance Center (TAC) consiglia vivamente questa guida visiva per una conoscenza pratica e approfondita delle tecnologie di sicurezza di nuova generazione di Cisco Firepower, incluse quelle menzionate in questo articolo in Cisco Firepower Threat Defense (FTD)

• Per tutte le note tecniche sulla configurazione e la risoluzione dei problemi, fare riferimento a Cisco Secure Firewall Management Center

• Documentazione e supporto tecnico – Cisco Systems