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
• Centro di gestione FireSIGHT (FMC) con versione 6.1.0-195
• Due router 3925 Cisco IOS® con immagini 15.2

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 serve a 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:

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

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 come mostrato nell'immagine.

Se il firewall è un dispositivo ASA, controlla l'intestazione IP esterna come mostrato nell'immagine.

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 come mostrato nell'immagine.

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

Punto principale:

Caso di utilizzo 2 del criterio di pre-filtro

Un criterio di prefiltro può utilizzare un tipo di regola di prefiltro che fornisce un controllo di accesso anticipato e consente a un flusso di ignorare completamente il motore di snort, come mostrato nell'immagine.

Attività 1. Verifica criterio prefiltro predefinito

Attività richiesta:

Verificare i criteri di prefiltro predefiniti

Soluzione:

Passaggio 1. Passare a Criteri > Controllo d'accesso > Prefiltro. Esiste già un criterio di prefiltro predefinito, come mostrato nell'immagine.

Passaggio 2. Scegliere Modifica per visualizzare le impostazioni dei criteri come illustrato nell'immagine.

Passaggio 3. Il criterio di prefiltro è già associato al criterio di controllo dell'accesso come mostrato nell'immagine.

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:

Passaggio 1. Se si applicano questi punti ACP, il traffico ICMP (Internet Control Message Protocol) viene bloccato, a prescindere dal fatto che attraversi o meno il tunnel GRE, come mostrato nell'immagine.

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

1. È possibile assegnare tag a tutti i pacchetti incapsulati nel GRE.
2. È possibile 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 rispetto alle regole di pre-filtro LINA (Linux NAtively), quindi vengono applicate le regole di pre-filtro Snort e ACP e infine Snort indica a LINA di eliminare. Il primo pacchetto passa attraverso il dispositivo FTD.

Passaggio 1. Definire un tag per il traffico tunneling.

Passare a Criteri > Controllo d'accesso > Prefiltro e creare un nuovo criterio di prefiltro. Tenere presente che il criterio di prefiltro predefinito non può essere modificato come mostrato nell'immagine.

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

1. Regola tunnel
2. Regola prefiltro

Queste due funzionalità possono essere configurate in modo completamente diverso in un criterio di prefiltro.

Per questa operazione, è necessario definire una regola di tunnel come mostrato nell'immagine.

Per quanto riguarda le azioni:

Passaggio 2. Definire i criteri di controllo di accesso per il traffico con tag.

Anche se inizialmente non può essere molto intuitivo, il tag Tunnel può essere utilizzato da una regola dei criteri di controllo di accesso come zona di origine. Passare a Policy > Controllo di accesso e creare una regola che blocchi l'ICMP per il traffico con tag, come mostrato nell'immagine.

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 è passata attraverso l'FTD e 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 ed eseguire 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 che Snort ha scartato i pacchetti:

> 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 il criterio di filtro e la regola corrispondenti, come illustrato nell'immagine.

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:

Passaggio 1. I criteri di controllo dell'accesso che bloccano tutto il traffico sono quelli mostrati nell'immagine.

Passaggio 2. Aggiungere una regola di prefiltro con Fastpath come azione per la rete di origine 192.168.75.0/24, come mostrato nell'immagine.

Passaggio 3. Il risultato è quello mostrato nell'immagine.

Passaggio 4. Salvataggio e distribuzione.

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 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)

La funzione Capture 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 mostra 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

Passaggio 5. Aggiungere un'altra regola di prefiltro per il traffico di ritorno. Il risultato è quello mostrato nell'immagine.

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

Verifica

Fare riferimento a questa sezione per verificare che la configurazione funzioni correttamente.

La verifica è stata illustrata nelle sezioni corrispondenti delle attività.

Risoluzione dei problemi

Non sono attualmente disponibili informazioni specifiche per risolvere i problemi relativi a questa configurazione.

Informazioni correlate

• Tutte le versioni della guida alla configurazione di Cisco Firepower Management Center sono disponibili qui:

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:

Cisco Firepower Threat Defense (FTD)

• Note tecniche sulla configurazione e la risoluzione dei problemi:

Cisco Secure Firewall Management Center

• Documentazione e supporto tecnico – Cisco Systems