Configurer et utiliser les stratégies de préfiltre FTD

Introduction

Ce document décrit la configuration et le fonctionnement des politiques de préfiltrage de Firepower Threat Defense (FTD).

Conditions préalables

Exigences

Aucune exigence spécifique n'est associée à ce document.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• ASA5506X qui exécute le code FTD 6.1.0-195
• FireSIGHT Management Center (FMC) qui exécute 6.1.0-195
• Deux routeurs Cisco IOS® 3925 exécutant des images 15.2

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Une politique de préfiltrage est une fonctionnalité introduite dans la version 6.1 et sert trois objectifs principaux :

1. Faire correspondre le trafic en fonction des en-têtes internes et externes
2. Fournir un contrôle d'accès anticipé qui permet à un flux de contourner complètement le moteur Snort
3. Servez-vous d'espace réservé pour les entrées de contrôle d'accès (ACE) migrées à partir de l'outil de migration Adaptive Security Appliance (ASA).

Configurer

Exemple d'utilisation de stratégie de préfiltre 1

Une politique de préfiltrage peut utiliser un type de règle de tunnel qui permet à FTD de filtrer en fonction du trafic tunnelisé d'en-tête IP interne et/ou externe. Au moment de la rédaction de cet article, le trafic tunnelisé se réfère à :

• Encapsulation de routage générique (GRE)
• IP-en-IP
• IPv6-en-IP
• Port Teredo 3544

Considérez un tunnel GRE comme illustré dans l'image.

Lorsque vous envoyez une requête ping de R1 à R2 à l'aide d'un tunnel GRE, le trafic passe par le pare-feu, comme illustré dans l'image.

Si le pare-feu est un périphérique ASA, il vérifie l'en-tête IP externe comme indiqué dans l'image.

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

Si le pare-feu est un périphérique FirePOWER, il vérifie l'en-tête IP interne comme indiqué dans l'image.

Avec la politique de préfiltrage, un périphérique FTD peut faire correspondre le trafic en fonction des en-têtes internes et externes.

Point principal :

Exemple d'utilisation de stratégie de pré-filtrage 2

Une stratégie de préfiltrage peut utiliser un type de règle de préfiltrage qui peut fournir un contrôle d'accès anticipé et permettre à un flux de contourner complètement le moteur Snort, comme illustré dans l'image.

Tâche 1. Vérifier la stratégie de préfiltrage par défaut

Exigence de la tâche :

Vérification de la stratégie de préfiltrage par défaut

Solution :

Étape 1. Accédez à Politiques > Contrôle d'accès > Préfiltre. Une stratégie de préfiltrage par défaut existe déjà, comme illustré dans l'image.

Étape 2. Choisissez Edit pour afficher les paramètres de stratégie tels qu'ils apparaissent dans l'image.

Étape 3. La stratégie de préfiltrage est déjà associée à la stratégie de contrôle d'accès, comme illustré dans l'image.

Vérification CLI (LINA)

Les règles de préfiltrage sont ajoutées en plus des listes de contrôle d’accè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

Tâche 2. Bloquer le trafic tunnelisé avec balise

Exigence de la tâche :

Bloquer le trafic ICMP qui est tunnellisé dans le tunnel GRE.

Solution :

Étape 1. Si vous appliquez ces ACP, vous pouvez voir que le trafic Internet Control Message Protocol (ICMP) est bloqué, peu importe s'il passe par le tunnel GRE ou non, comme montré dans l'image.

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)

Dans ce cas, vous pouvez utiliser une stratégie de préfiltrage pour répondre aux exigences de la tâche. La logique est la suivante :

1. Vous marquez tous les paquets qui sont encapsulés dans GRE.
2. Vous créez une stratégie de contrôle d’accès qui correspond aux paquets balisés et bloque le protocole ICMP. 

Du point de vue de l'architecture, les paquets sont vérifiés par rapport aux règles de pré-filtrage LINA (Linux NAtivity), puis aux règles de pré-filtrage Snort et à l'ACP, et enfin Snort ordonne à LINA d'abandonner. Le premier paquet passe par le périphérique FTD.

Étape 1. Définissez une balise pour le trafic tunnelisé.

Accédez à Policies > Access Control > Prefilter et créez une nouvelle stratégie de préfiltrage. N'oubliez pas que la stratégie de préfiltrage par défaut ne peut pas être modifiée comme indiqué dans l'image.

Dans la stratégie de préfiltrage, vous pouvez définir deux types de règles :

1. Règle du tunnel
2. Règle de préfiltrage

Vous pouvez les considérer comme des fonctionnalités totalement différentes pouvant être configurées dans une stratégie de préfiltrage.

Pour cette tâche, il est nécessaire de définir une règle de tunnel comme illustré dans l'image.

En ce qui concerne les actions :

Étape 2. Définissez la politique de contrôle d'accès pour le trafic étiqueté.

Bien qu'elle ne puisse pas être très intuitive au début, la balise de tunnel peut être utilisée par une règle de politique de contrôle d'accès comme zone source. Accédez à Policies > Access Control et créez une règle qui bloque le protocole ICMP pour le trafic étiqueté comme indiqué dans l'image.

Remarque : la nouvelle stratégie de préfiltrage est associée à la stratégie de contrôle d'accès.

Vérification :

Activez la capture sur LINA et sur 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

À partir de R1, essayez d'envoyer une requête ping au point de terminaison du tunnel GRE distant. La requête ping échoue :

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)

La capture CLISH montre que la première requête d’écho a transité par FTD et que la réponse a été bloquée :

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 capture LINA le confirme :

> 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

Activez CLISH firewall-engine-debug, effacez les compteurs d'abandon LINA ASP et effectuez le même test. Le débogage CLISH montre que pour la requête d'écho, vous avez fait correspondre la règle de préfiltre et pour la réponse d'écho, la règle 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

L'abandon ASP indique que Snort a abandonné les paquets :

> 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

Dans les événements de connexion, vous pouvez voir la stratégie et la règle de préfiltrage que vous avez mises en correspondance, comme illustré dans l'image.

Tâche 3. Contourner le moteur Snort avec les règles de préfiltre Fastpath

Diagramme du réseau

Exigence de la tâche :

1. Supprimez les règles de stratégie de contrôle d'accès actuelles et ajoutez une règle de stratégie de contrôle d'accès qui bloque tout le trafic.
2. Configurez une règle de stratégie de préfiltrage qui contourne le moteur de détection pour le trafic provenant du réseau 192.168.75.0/24.

Solution :

Étape 1. La politique de contrôle d'accès qui bloque tout le trafic est celle illustrée dans l'image.

Étape 2. Ajoutez une règle de préfiltrage avec Fastpath comme action pour le réseau source 192.168.75.0/24, comme illustré dans l’image.

Étape 3. Le résultat est tel qu'illustré sur l'image.

Étape 4. Enregistrer et déployer.

Activez la capture avec trace sur les deux interfaces FTD :

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

Essayez d’envoyer une requête ping de R1 (192.168.75.39) vers R2 (192.168.76.39) via le FTD. La requête ping échoue :

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 capture sur l'interface interne montre :

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 trace du premier paquet (demande d’écho) montre (les points importants sont mis en évidence) :

La capture sur l'interface externe montre :

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 trace du paquet de retour indique qu'il correspond au flux actuel (52), mais qu'il est bloqué par la liste de contrôle d'accès :

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

Étape 5. Ajoutez une règle de préfiltre supplémentaire pour le trafic de retour. Le résultat est tel qu'illustré sur l'image.

Maintenant, tracez le paquet de retour que vous voyez (points importants mis en évidence) :

Vérifier

Utilisez cette section pour confirmer que votre configuration fonctionne correctement.

La vérification a été expliquée dans les sections relatives aux tâches respectives.

Dépannage

Il n’y a actuellement aucune information spécifique disponible pour dépanner cette configuration.

Informations connexes

• Toutes les versions du guide de configuration de Cisco Firepower Management Center sont disponibles ici :

Navigation dans la documentation de Cisco Secure Firewall Threat Defense

• Le Centre d'assistance technique mondial (TAC) de Cisco recommande vivement ce guide visuel pour des connaissances pratiques approfondies sur les technologies de sécurité de nouvelle génération Cisco Firepower, notamment celles mentionnées dans cet article :

Cisco Firepower Threat Defense (FTD)

• Pour toutes les notes techniques de configuration et de dépannage :

Cisco Secure Firewall Management Center

• Assistance et documentation techniques - Cisco Systems