Configuration et fonctionnement des stratégies de préfiltre FTD

Introduction

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

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

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 la version 6.1.0-195
• Deux routeurs Cisco IOS® 3925 qui exécutent 15,2 images

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 stratégie de préfiltre est une fonctionnalité introduite dans la version 6.1 et sert trois objectifs principaux :

1. Correspondance du trafic en fonction des en-têtes internes et externes
2. Fournir un contrôle d'accès précoce qui permet au flux de contourner complètement le moteur Snort
3. Travailler comme 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).

Configuration

Cas d'utilisation de la stratégie de préfiltre 1

Une stratégie de préfiltre peut utiliser un type de règle de tunnel qui permet à FTD de filtrer en fonction du trafic tunnel d'en-tête IP interne et/ou externe. Au moment de la rédaction de cet article, le trafic tunnelisé fait référence aux éléments suivants :

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

Considérez un tunnel GRE comme l'illustre l'image ici.

Lorsque vous envoyez une requête ping de R1 à R2 à l'aide d'un tunnel GRE, le trafic passe par le pare-feu comme indiqué 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é-filtre, un périphérique FTD peut correspondre au trafic en fonction des en-têtes internes et externes.

Point principal :

Cas d'utilisation de la stratégie de préfiltre 2

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

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

Exigence de la tâche :

Vérifier la stratégie de préfiltre par défaut

Solution :

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

Étape 2. Sélectionnez Modifier pour afficher les paramètres de stratégie comme indiqué dans l'image.

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

Vérification CLI (LINA)

Les règles de préfiltre 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 une balise

Exigence de la tâche :

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

Solution :

Étape 1. Si vous appliquez ces ACP, vous pouvez voir que le trafic ICMP (Internet Control Message Protocol) est bloqué, peu importe s'il traverse le tunnel GRE ou non, comme le montre 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éfiltre pour répondre à la condition de tâche. La logique est la suivante :

1. Vous marquez tous les paquets 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 ICMP. 

Du point de vue de l'architecture, les paquets sont vérifiés par rapport aux règles de pré-filtre LINA, puis aux règles de pré-filtre Snort et ACP et enfin Snort demande à LINA de tomber. Le premier paquet passe par le périphérique FTD.

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

Accédez à Politiques > Contrôle d'accès > Préfiltrer et créez une nouvelle stratégie de préfiltre. N'oubliez pas que la stratégie de préfiltre par défaut ne peut pas être modifiée comme le montre l'image.

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

• Règle de tunnel
• Règle de préfiltre

Vous pouvez considérer ces deux fonctionnalités comme totalement différentes pouvant être configurées dans une stratégie de préfiltre.

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

En ce qui concerne les actions :

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

Bien que ce ne soit pas très intuitif au début, la balise de tunnel peut être utilisée par une règle de stratégie de contrôle d'accès comme zone source. Accédez à Policies > Access Control et créez une règle qui bloque ICMP pour le trafic étiqueté comme illustré dans l'image.

Note: La nouvelle stratégie de préfiltre 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 été transmise 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 confirme ceci :

> 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, désactivez les compteurs de perte LINA ASP et effectuez le même test. Le débogage CLISH montre que pour la requête d'écho vous avez mis en correspondance 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 using 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 using 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

La suppression ASP montre 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éfiltre que vous avez appariées, comme l'illustre l'image.

Tâche 3. Ignorer 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 existantes 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éfiltre qui ignore le moteur Snort 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 comme illustré dans l'image.

Étape 2. Ajoutez une règle de préfiltre avec Fastpath en tant qu'action pour le réseau source 192.168.75.0/24 comme l'illustre l'image.

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

Étape 4. Enregistrer et déployer.

Activez la capture avec la 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

Le suivi du premier paquet (requête d’écho) indique (points importants 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

Le suivi du paquet de retour indique qu’il correspond au flux existant (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, using existing 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é dans l'image.

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

Vérification

Utilisez cette section pour confirmer que votre configuration fonctionne correctement.

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

Dépannage

Il n'existe actuellement aucune information de dépannage spécifique pour cette configuration.

Informations connexes

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

https://www.cisco.com/c/en/us/td/docs/security/firepower/roadmap/firepower-roadmap.html#id_47280

• 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, y compris celles mentionnées dans cet article :

http://www.ciscopress.com/title/9781587144806

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

https://www.cisco.com/c/en/us/support/security/defense-center/tsd-products-support-series-home.html

• Support et documentation techniques - Cisco Systems