Clarifier les actions de règle de politique de contrôle d’accès de Firepower Threat Defense
Contenu
Introduction
Ce document décrit les différentes actions disponibles sur la politique de contrôle d’accès et la politique de préfiltre de Firepower Threat Defense (FTD).
Conditions préalables
Conditions requises
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Décharge de flux
- Captures de paquets sur les appliances Firepower Threat Defense
- Traceur de paquet et capture avec option de trace sur les appareils Firepower Threat Defense (FTD)
Components Used
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
- Cisco Firepower 4110 Threat Defense version 6.4.0 (build 113) et 6.6.0 (build 90)
- Centre de gestion Firepower Management Center (FMC) version 6.4.0 (build 113) et 6.6.0 (build 90)
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.
Produits connexes
Ce document peut également être utilisé avec les versions matérielles et logicielles suivantes :
- ASA5506-X, ASA5506W-X, ASA5506H-X, ASA5508-X, ASA5516-X
- ASA5512-X, ASA5515-X, ASA5525-X, ASA5545-X, ASA5555-X
- FPR1000, FPR2100, FPR4100, FPR9300
- VMware (ESXi), Amazon Web Services (AWS), machine virtuelle à base de noyau (KVM)
- Module de routeur à services intégrés (ISR)
- Logiciel Firepower Threat Defense (FTD) versions 6.1.x et ultérieures
Informations générales
Le fonctionnement en arrière-plan de chaque action est examiné, ainsi que son interaction avec d'autres fonctionnalités telles que le déchargement de flux et les protocoles qui ouvrent des connexions secondaires.
Cisco Firepower Threat Defense (FTD) est une image logicielle unifiée qui comprend deux moteurs principaux :
- Moteur LINA
- Moteur du renifleur
Cette figure montre comment les deux moteurs interagissent :
- Un paquet entre dans l’interface d’entrée et est géré par le moteur LINA
- Si cela est requis par la politique FTD, le paquet est inspecté par le moteur du renifleur
- Le moteur Snort renvoie un verdict (liste d'autorisation ou liste de blocage) pour le paquet
- Le moteur LINA abandonne ou transfère le paquet en fonction du verdict du renifleur
Mode de déploiement de la politique de contrôle d’accès
La politique FTD est configurée sur Cisco Firepower Management Center (FMC) lorsque la gestion par défaut (à distance) est utilisée ou sur Firepower Device Manager (FDM) lorsque la gestion locale est utilisée. Dans les deux cas, la politique de contrôle d’accès est déployée comme :
- Une liste de contrôle d'accès (ACL) globale nommée CSM_FW_ACL_ au moteur FTD LINA
- Des règles de contrôle d’accès dans le fichier /ngfw/var/sf/detection_engines/<UUID>/ngfw.rules du moteur FTD du renifleur
Configuration
Actions disponibles pour la politique de contrôle d’accès
La politique de contrôle d’accès FTD contient une ou plusieurs règles, et chaque règle peut avoir une de ces actions et comme le montre l’image :
AllowTrustMonitorBlockBlock with resetInteractive BlockInteractive Block with reset
De même, une politique de préfiltre peut contenir une ou plusieurs règles, et les actions possibles sont montrées dans l’image :
Interactions entre les politiques de contrôle d’accès et de préfiltre
La politique de préfiltrage a été introduite dans la version 6.1 et sert 2 objectifs principaux :
- Elle permet l’inspection du trafic en tunnel où le moteur FTD LINA vérifie l’en-tête IP externe tandis que le moteur du renifleur vérifie l’en-tête IP interne. Plus précisément, dans le cas du trafic tunnelisé (par exemple GRE), les règles de la stratégie de préfiltrage agissent toujours sur le
outer headers,tandis que les règles de l'ACP sont toujours applicables aux sessions internes(inner headers). Le trafic en tunnel se reporte à ces protocoles :
- GRE
- IP-en-IP
- IPv6-en-IP
- Port Teredo 3544
- Il fournit un contrôle d'accès anticipé (EAC) qui permet au flux de contourner complètement le moteur Snort comme le montre l'image.
Les règles de préfiltrage sont déployées sur FTD en tant qu'éléments de contrôle d'accès (ACE) de couche 3/4 et précèdent les ACE configurés de couche 3/4, comme illustré dans l'image :
Action Block (blocage) de la politique de contrôle d’accès
Examinez la topologie présentée dans cette image :
Scénario 1. Abandon LINA précoce
La politique de contrôle d’accès contient une règle de blocage qui utilise une condition L4 (port de destination TCP 80), comme le montre l’image :
La politique déployée dans le renifleur :
268435461 deny any 192.168.1.40 32 any any 192.168.2.40 32 80 any 6
La politique déployée dans LINA. Notez que la règle est poussée comme deny action :
firepower# show access-list … access-list CSM_FW_ACL_ line 9 remark rule-id 268435461: L4 RULE: Rule1 access-list CSM_FW_ACL_ line 10 advanced deny tcp host 192.168.1.40 host 192.168.2.40 eq www rule-id 268435461 event-log flow-start (hitcnt=0) 0x6149c43c
Vérifiez le comportement :
Lorsque l'hôte A (192.168.1.40) tente d'ouvrir une session HTTP vers l'hôte B (192.168.2.40), les paquets de synchronisation TCP (SYN) sont abandonnés par le moteur FTD LINA et n'atteignent pas le moteur Snort ou la destination :
firepower# show capture capture CAPI type raw-data buffer 33554432 trace trace-count 100 interface INSIDE [Capturing - 430 bytes] match ip host 192.168.1.40 any capture CAPO type raw-data buffer 33554432 trace trace-count 100 interface OUTSIDE [Capturing - 0 bytes] match ip host 192.168.1.40 any
firepower# show capture CAPI 1: 11:08:09.672801 192.168.1.40.32789 > 192.168.2.40.80: S 3249160620:3249160620(0) win 2920 <mss 1460,sackOK,timestamp 4060517 0> 2: 11:08:12.672435 192.168.1.40.32789 > 192.168.2.40.80: S 3249160620:3249160620(0) win 2920 <mss 1460,sackOK,timestamp 4063517 0> 3: 11:08:18.672847 192.168.1.40.32789 > 192.168.2.40.80: S 3249160620:3249160620(0) win 2920 <mss 1460,sackOK,timestamp 4069517 0> 4: 11:08:30.673610 192.168.1.40.32789 > 192.168.2.40.80: S 3249160620:3249160620(0) win 2920 <mss 1460,sackOK,timestamp 4081517 0>
firepower# show capture CAPI packet-number 1 trace
1: 11:08:09.672801 192.168.1.40.32789 > 192.168.2.40.80: S 3249160620:3249160620(0) win 2920 <mss 1460,sackOK,timestamp 4060517 0>
...
Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: DROP
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced deny tcp host 192.168.1.40 host 192.168.2.40 eq www rule-id 268435461 event-log flow-start
access-list CSM_FW_ACL_ remark rule-id 268435461: ACCESS POLICY: ACP1 - Mandatory
access-list CSM_FW_ACL_ remark rule-id 268435461: L4 RULE: Rule1
Additional Information:
<- No Additional Information = No Snort Inspection
Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: OUTSIDE
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
Scénario 2. Abandon en raison d'un verdict Snort
La politique de contrôle d’accès contient une règle de blocage qui utilise une condition L7 (Application HTTP), comme le montre l’image :
La politique déployée dans le renifleur :
268435461 deny any 192.168.1.40 32 any any 192.168.2.40 32 any any any (appid 676:1)
Appid 676:1 = HTTP
La politique déployée dans LINA.
firepower# show access-list … access-list CSM_FW_ACL_ line 9 remark rule-id 268435461: L7 RULE: Rule1 access-list CSM_FW_ACL_ line 10 advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435461 (hitcnt=0) 0xb788b786
Pour une règle de blocage qui utilise Application comme condition, la trace d'un paquet réel montre que la session est abandonnée par le LINA en raison du verdict du moteur Snort.
Vérifiez le comportement :
Lorsque l’hôte A (192.168.1.40) tente d’établir une session HTTP avec l’hôte B (192.168.2.40), la saisie d’entrée LINA indique :
firepower# show capture CAPI 8 packets captured 1: 11:31:19.825564 192.168.1.40.32790 > 192.168.2.40.80: S 357753151:357753151(0) win 2920 <mss 1460,sackOK,timestamp 5450579 0> 2: 11:31:19.826403 192.168.2.40.80 > 192.168.1.40.32790: S 1283931030:1283931030(0) ack 357753152 win 2896 <mss 1380,sackOK,timestamp 5449236 5450579> 3: 11:31:19.826556 192.168.1.40.32790 > 192.168.2.40.80: P 357753152:357753351(199) ack 1283931031 win 2920 <nop,nop,timestamp 5450580 5449236> 4: 11:31:20.026899 192.168.1.40.32790 > 192.168.2.40.80: P 357753152:357753351(199) ack 1283931031 win 2920 <nop,nop,timestamp 5450781 5449236> 5: 11:31:20.428887 192.168.1.40.32790 > 192.168.2.40.80: P 357753152:357753351(199) ack 1283931031 win 2920 <nop,nop,timestamp 5451183 5449236> ...
La saisie de sortie :
firepower# show capture CAPO 5 packets captured 1: 11:31:19.825869 192.168.1.40.32790 > 192.168.2.40.80: S 1163713179:1163713179(0) win 2920 <mss 1380,sackOK,timestamp 5450579 0> 2: 11:31:19.826312 192.168.2.40.80 > 192.168.1.40.32790: S 354801457:354801457(0) ack 1163713180 win 2896 <mss 1460,sackOK,timestamp 5449236 5450579> 3: 11:31:23.426049 192.168.2.40.80 > 192.168.1.40.32790: S 354801457:354801457(0) ack 1163713180 win 2896 <mss 1460,sackOK,timestamp 5452836 5450579> 4: 11:31:29.426430 192.168.2.40.80 > 192.168.1.40.32790: S 354801457:354801457(0) ack 1163713180 win 2896 <mss 1460,sackOK,timestamp 5458836 5450579> 5: 11:31:41.427208 192.168.2.40.80 > 192.168.1.40.32790: S 354801457:354801457(0) ack 1163713180 win 2896 <mss 1460,sackOK,timestamp 5470836 5450579>
La trace indique que le premier paquet (TCP SYN) est autorisé par le Snort puisque le verdict de détection d'application n'a pas encore été atteint :
firepower# show capture CAPI packet-number 1 trace 1: 11:31:19.825564 192.168.1.40.32790 > 192.168.2.40.80: S 357753151:357753151(0) win 2920 <mss 1460,sackOK,timestamp 5450579 0> ... Phase: 4 Type: ACCESS-LIST Subtype: log Result: ALLOW Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435461 access-list CSM_FW_ACL_ remark rule-id 268435461: ACCESS POLICY: ACP1 - Mandatory access-list CSM_FW_ACL_ remark rule-id 268435461: L7 RULE: Rule1 Additional Information: This packet will be sent to snort for additional processing where a verdict will be reached ... Phase: 10 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 23194, packet dispatched to next module … Phase: 12 Type: SNORT Subtype: Result: ALLOW Config: Additional Information: Snort Trace: Packet: TCP, SYN, seq 357753151 AppID: service unknown (0), application unknown (0) Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 0, icmpCode 0 Firewall: pending rule-matching, id 268435461, pending AppID NAP id 1, IPS id 0, Verdict PASS Snort Verdict: (pass-packet) allow this packet Result: input-interface: OUTSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: allow
De même pour le paquet TCP SYN/ACK :
firepower# show capture CAPO packet-number 2 trace 2: 11:31:19.826312 192.168.2.40.80 > 192.168.1.40.32790: S 354801457:354801457(0) ack 1163713180 win 2896 <mss 1460,sackOK,timestamp 5449236 5450579> … Phase: 3 Type: FLOW-LOOKUP Subtype: Result: ALLOW Config: Additional Information: Found flow with id 23194, using existing flow … Phase: 5 Type: SNORT Subtype: Result: ALLOW Config: Additional Information: Snort Trace: Packet: TCP, SYN, ACK, seq 1283931030, ack 357753152 AppID: service unknown (0), application unknown (0) Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 0, icmpCode 0 Firewall: pending rule-matching, id 268435461, pending AppID NAP id 1, IPS id 0, Verdict PASS Snort Verdict: (pass-packet) allow this packet Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: INSIDE output-status: up output-line-status: up Action: allow
Snort retourne un verdict DROP une fois qu'une inspection du troisième paquet est terminée :
firepower# show capture CAPI packet-number 3 trace 3: 11:31:19.826556 192.168.1.40.32790 > 192.168.2.40.80: P 357753152:357753351(199) ack 1283931031 win 2920 <nop,nop,timestamp 5450580 5449236> Phase: 3 Type: FLOW-LOOKUP Subtype: Result: ALLOW Config: Additional Information: Found flow with id 23194, using existing flow Phase: 5 Type: SNORT Subtype: Result: DROP Config: Additional Information: Snort Trace: Packet: TCP, ACK, seq 357753152, ack 1283931031 AppID: service HTTP (676), application unknown (0) Firewall: starting rule matching, zone -1 -> -1, geo 0(0) -> 0, vlan 0, sgt 65535, user 9999997, url http://192.168.2.40/128k.html Firewall: block rule, id 268435461, drop Snort: processed decoder alerts or actions queue, drop NAP id 1, IPS id 0, Verdict BLOCKLIST, Blocked by Firewall Snort Verdict: (block-list) block list this flow Result: input-interface: INSIDE input-status: up input-line-status: up Action: drop Drop-reason: (firewall) Blocked by the firewall preprocessor
Vous pouvez également exécuter la commande system support trace à partir du mode FTD CLISH. Cet outil offre deux fonctions :
- Affiche le verdict Snort pour chaque paquet lorsqu'il est envoyé à la bibliothèque d'acquisition de données (DAQ) et vu dans LINA. La bibliothèque est un composant situé entre le moteur FTD LINA et le moteur de renifleur
- Permet d'exécuter
system support firewall-engine-debugen même temps pour voir ce qui se passe dans le moteur Snort lui-même
Voici la sortie :
> system support trace Please specify an IP protocol: tcp Please specify a client IP address: 192.168.1.40 Please specify a client port: Please specify a server IP address: 192.168.2.40 Please specify a server port: Enable firewall-engine-debug too? [n]: y Monitoring packet tracer debug messages Tracing enabled by Lina 192.168.2.40-80 - 192.168.1.40-32791 6 Packet: TCP, SYN, seq 2620409313 192.168.2.40-80 - 192.168.1.40-32791 6 AppID: service unknown (0), application unknown (0) 192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 New session 192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 Starting with minimum 2, 'Rule1', and SrcZone first with zones -1 -> -1, geo 0 -> 0, vlan 0, inline sgt tag: untagged, ISE sgt id: 0, svc 0, payload 0, client 0, misc 0, user 9999997, icmpType 0, icmpCode 0 192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 0, icmpCode 0 192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 pending rule order 2, 'Rule1', AppID 192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: pending rule-matching, 'Rule1', pending AppID 192.168.1.40-32791 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict PASS Trace buffer and verdict reason are sent to DAQ's PDTS Tracing enabled by Lina 192.168.2.40-80 - 192.168.1.40-32791 6 Packet: TCP, SYN, ACK, seq 3700371680, ack 2620409314 192.168.2.40-80 - 192.168.1.40-32791 6 AppID: service unknown (0), application unknown (0) 192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 Starting with minimum 2, 'Rule1', and SrcZone first with zones -1 -> -1, geo 0 -> 0, vlan 0, inline sgt tag: untagged, ISE sgt id: 0, svc 0, payload 0, client 0, misc 0, user 9999997, icmpType 0, icmpCode 0 192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 0, icmpCode 0 192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 pending rule order 2, 'Rule1', AppID 192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: pending rule-matching, 'Rule1', pending AppID 192.168.1.40-32791 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict PASS Trace buffer and verdict reason are sent to DAQ's PDTS Tracing enabled by Lina 192.168.2.40-80 - 192.168.1.40-32791 6 Packet: TCP, ACK, seq 2620409314, ack 3700371681 192.168.2.40-80 - 192.168.1.40-32791 6 AppID: service HTTP (676), application unknown (0) 192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 Starting with minimum 2, 'Rule1', and SrcZone first with zones -1 -> -1, geo 0(0) -> 0, vlan 0, inline sgt tag: untagged, ISE sgt id: 0, svc 676, payload 0, client 686, misc 0, user 9999997, url http://192.168.2.40/128k.html, xff 192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: starting rule matching, zone -1 -> -1, geo 0(0) -> 0, vlan 0, sgt 65535, user 9999997, url http://192.168.2.40/128k.html 192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 match rule order 2, 'Rule1', action Block 192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 deny action 192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: block rule, 'Rule1', drop 192.168.1.40-32791 > 192.168.2.40-80 6 Snort: processed decoder alerts or actions queue, drop 192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 Deleting session 192.168.1.40-32791 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict BLOCKLIST 192.168.1.40-32791 > 192.168.2.40-80 6 ===> Blocked by Firewall
Résumé
- L’action de blocage de la politique de contrôle d’accès est déployée en tant que règle permit (permission) ou de deny (refus) dans LINA qui dépend des conditions de la règle
- Si les conditions sont L3/L4, alors le LINA bloque le paquet. Dans le cas du protocole TCP, le premier paquet (TCP SYN) est bloqué
- Si les conditions sont L7, le paquet est transmis au moteur du renifleur pour une inspection approfondie. Dans le cas d’un protocole TCP, quelques paquets sont autorisés par l’intermédiaire de Cisco FTD jusqu’à ce que le renifleur atteigne un verdict. Les paquets autorisés sont toujours soumis à la vérification de la stratégie d'intrusion basée sur
Access Policy > Advanced > 'Intrusion Policy used before Access Control rule is determined'option.
Action Block (blocage) de la politique de contrôle d’accès avec réinitialisation
Une règle Block (blocage) avec repos configurée sur l’interface utilisateur de Cisco Firepower Management Center (FMC) :
La règle Block with reset est déployée sur le moteur FTD LINA en tant que permit et au moteur Snort en tant que reset règle :
firepower# show access-list … access-list CSM_FW_ACL_ line 10 advanced permit tcp 192.168.10.0 255.255.255.0 host 192.168.11.50 eq www rule-id 268438864 (hitcnt=0) 0xba785fc0 access-list CSM_FW_ACL_ line 11 remark rule-id 268438865: ACCESS POLICY: ACP1 - Mandatory access-list CSM_FW_ACL_ line 12 remark rule-id 268438865: L7 RULE: Block-RST_Rule2 access-list CSM_FW_ACL_ line 13 advanced permit ip 192.168.10.0 255.255.255.0 host 192.168.11.51 rule-id 268438865 (hitcnt=0) 0x622350d0
Moteur du renifleur :
admin@firepower:~$ cat /var/sf/detection_engines/9e080e5c-adc3-11ea-9d37-44884cf7e9ba/ngfw.rules … # Start of AC rule. 268438864 reset any 192.168.10.0 24 any any 192.168.11.50 32 80 any 6 # End rule 268438864 268438865 reset any 192.168.10.0 24 any any 192.168.11.51 32 any any any (appid 676:1) (ip_protos 6, 17) # End rule 268438865
Lorsqu'un paquet correspond à Block with reset rule, FTD envoie un TCP Reset paquet ou un ICMP Type 3 Code 13 Message de destination inaccessible (filtrée administrativement) :
root@kali:~/tests# wget 192.168.11.50/file1.zip --2020-06-20 22:48:10-- http://192.168.11.50/file1.zip Connecting to 192.168.11.50:80... failed: Connection refused.
Voici une capture réalisée sur l’interface d’entrée de Cisco FTD :
firepower# show capture CAPI
2 packets captured
1: 21:01:00.977259 802.1Q vlan#202 P0 192.168.10.50.41986 > 192.168.11.50.80: S 3120295488:3120295488(0) win 29200 <mss 1460,sackOK,timestamp 3740873275 0,nop,wscale 7>
2: 21:01:00.978114 802.1Q vlan#202 P0 192.168.11.50.80 > 192.168.10.50.41986: R 0:0(0) ack 3120295489 win 0 2 packets shown
System support trace dans ce cas, indique que le paquet est abandonné en raison du verdict Snort :
> system support trace Enable firewall-engine-debug too? [n]: y Please specify an IP protocol: tcp Please specify a client IP address: 192.168.10.50 Please specify a client port: Please specify a server IP address: 192.168.11.50 Please specify a server port: Monitoring packet tracer and firewall debug messages 192.168.10.50-41984 - 192.168.11.50-80 6 AS 1-1 CID 0 Packet: TCP, SYN, seq 3387496622 192.168.10.50-41984 - 192.168.11.50-80 6 AS 1-1 CID 0 Session: new snort session 192.168.10.50-41984 - 192.168.11.50-80 6 AS 1-1 CID 0 AppID: service unknown (0), application unknown (0) 192.168.10.50-41984 > 192.168.11.50-80 6 AS 1-1 I 9 new firewall session 192.168.10.50-41984 > 192.168.11.50-80 6 AS 1-1 I 9 using HW or preset rule order 2, 'Block-RST-Rule1', action Reset and prefilter rule 0 192.168.10.50-41984 > 192.168.11.50-80 6 AS 1-1 I 9 HitCount data sent for rule id: 268438864, 192.168.10.50-41984 > 192.168.11.50-80 6 AS 1-1 I 9 reset action 192.168.10.50-41984 > 192.168.11.50-80 6 AS 1-1 I 9 deleting firewall session flags = 0x0, fwFlags = 0x0 192.168.10.50-41984 - 192.168.11.50-80 6 AS 1-1 CID 0 Firewall: block w/ reset rule, 'Block-RST-Rule1', drop 192.168.10.50-41984 - 192.168.11.50-80 6 AS 1-1 CID 0 Snort: processed decoder alerts or actions queue, drop 192.168.10.50-41984 - 192.168.11.50-80 6 AS 1-1 CID 0 Snort id 9, NAP id 1, IPS id 0, Verdict BLOCKLIST 192.168.10.50-41984 - 192.168.11.50-80 6 AS 1-1 CID 0 ===> Blocked by Firewall Verdict reason is sent to DAQ
Scénarios :
Identique à Block , mais met fin immédiatement à la connexion.
Action Allow (autorisation) de la politique de contrôle d’accès
Scénario 1. Action Autoriser ACP (conditions L3/L4)
Normalement, vous devez configurer une règle d’autorisation pour préciser des inspections supplémentaires comme une politique d’intrusion ou une politique de fichiers. Ce premier scénario illustre le fonctionnement d'une règle d'autorisation lorsqu'une condition L3/L4 est appliquée.
Considérez cette topologie comme le montre l’image :
Cette politique est appliquée comme le montre l’image :
La politique déployée dans le renifleur. Notez que la règle est déployée en tant que allow action :
# Start of AC rule. 268435461 allow any 192.168.1.40 32 any any 192.168.2.40 32 80 any 6
La politique de LINA.
firepower# show access-list … access-list CSM_FW_ACL_ line 9 remark rule-id 268435461: L7 RULE: Rule1 access-list CSM_FW_ACL_ line 10 advanced permit tcp host 192.168.1.40 host 192.168.2.40 eq www rule-id 268435461 (hitcnt=1) 0x641a20c3
Afin de voir comment FTD gère un flux qui correspond à une règle Allow, il y a quelques façons :
- Vérifier les statistiques du renifleur
- À l’aide de l’outil CLISH de prise en charge du système de trace
- À l’aide de l’utilisation de saisie avec l’option de trace dans LINA et possiblement à l’aide de la capture du trafic dans le moteur du renifleur
Capture LINA c. trafic du renifleur :
Vérifiez le comportement :
Effacer les statistiques Snort, activer system support trace from CLISH, and initiate an HTTP flow from host-A (192.168.1.40) to host-B (192.168.2.40). All the packets are forwarded to the Snort engine and get the PASS verdict by the Snort:
firepower# clear snort statistics
> system support trace Please specify an IP protocol: Please specify a client IP address: 192.168.1.40 Please specify a client port: Please specify a server IP address: 192.168.2.40 Please specify a server port: Enable firewall-engine-debug too? [n]: Monitoring packet tracer debug messages Tracing enabled by Lina 192.168.2.40-80 - 192.168.1.40-32797 6 Packet: TCP, SYN, seq 361134402 192.168.2.40-80 - 192.168.1.40-32797 6 AppID: service unknown (0), application unknown (0) 192.168.1.40-32797 > 192.168.2.40-80 6 Firewall: allow rule, 'Rule1', allow 192.168.1.40-32797 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict PASS Trace buffer and verdict reason are sent to DAQ's PDTS Tracing enabled by Lina 192.168.2.40-80 - 192.168.1.40-32797 6 Packet: TCP, SYN, ACK, seq 1591434735, ack 361134403 192.168.2.40-80 - 192.168.1.40-32797 6 AppID: service unknown (0), application unknown (0) 192.168.1.40-32797 > 192.168.2.40-80 6 Firewall: allow rule, 'Rule1', allow 192.168.1.40-32797 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict PASS Trace buffer and verdict reason are sent to DAQ's PDTS Tracing enabled by Lina 192.168.2.40-80 - 192.168.1.40-32797 6 Packet: TCP, ACK, seq 361134403, ack 1591434736 192.168.2.40-80 - 192.168.1.40-32797 6 AppID: service HTTP (676), application unknown (0) 192.168.1.40-32797 > 192.168.2.40-80 6 Firewall: allow rule, 'Rule1', allow 192.168.1.40-32797 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict PASS
Les compteurs de paquets Pass augmentent :
> show snort statistics Packet Counters: Passed Packets 54 Blocked Packets 0 Injected Packets 0 Packets bypassed (Snort Down) 0 Packets bypassed (Snort Busy) 0 Flow Counters: Fast-Forwarded Flows 0 Blocklisted Flows 0 ...
Paquets réussis = inspectés par le moteur de renifleur
Scénario 2. Action Autoriser ACP (conditions L3-7)
Un comportement similaire se produit lorsque la règle Allow (autorisation) est déployée comme suit.
Seule une condition L3/L4, comme illustré dans l'image :
Une condition L7 (par exemple, Intrusion Policy, File Policy, Application, etc.) est affichée dans l'image :
Résumé
En résumé, voici comment un flux est géré par Cisco FTD déployé sur un FP4100/9300 lorsqu’une règle Allow (autorisation) est mise en correspondance, comme le montre l’image :
Scénario 3. Arrêt du verdict Fast-Forward avec Allow
Il existe des scénarios spécifiques où le moteur FTD Snort donne un verdict PERMITLIST (avance rapide) et le reste du flux est déchargé vers le moteur LINA (dans certains cas, il est déchargé vers l'accélérateur matériel - SmartNIC). Ces scénarios sont les suivants :
- Trafic SSL sans politique SSL configurée
- Contournement intelligent des applications
Voici la représentation visuelle du chemin du paquet :
Ou dans certains cas :
Points principaux
- La règle d'autorisation est déployée en tant que
allowdans Snort etpermitDans LINA - Dans la plupart des cas, tous les paquets d'une session sont transférés au moteur Snort pour une inspection supplémentaire
Scénarios :
Vous devez configurer une règle Allow (autorisation) lorsque vous avez besoin d’une inspection L7 par le moteur du renifleur, par exemple :
- Politique d’intrusion
- Politique de fichiers
Action Trust (confiance) de la politique de contrôle d’accès
Scénario 1. Action de confiance ACP
Si vous ne souhaitez pas appliquer l'inspection avancée de couche 7 au niveau Snort (par exemple, la stratégie d'intrusion, la stratégie de fichiers, la découverte de réseau), mais que vous souhaitez tout de même utiliser des fonctionnalités telles que Security Intelligence (SI), Identity Policy, QoS, etc., il est recommandé d'utiliser l'action Trust dans votre règle.
Topologie:
La politique configurée :
La règle Trust (confiance) telle qu’elle est déployée dans le moteur FTD de renifleur :
# Start of AC rule. 268438858 fastpath any 192.168.10.50 31 any any 192.168.11.50 31 80 any 6 (log dcforward flowend)
La règle dans FTD LINA :
firepower# show access-list | i 268438858 access-list CSM_FW_ACL_ line 17 remark rule-id 268438858: ACCESS POLICY: ACP1 - Mandatory access-list CSM_FW_ACL_ line 18 remark rule-id 268438858: L7 RULE: trust_L3-L4 access-list CSM_FW_ACL_ line 19 advanced permit tcp object-group FMC_INLINE_src_rule_268438858 object-group FMC_INLINE_dst_rule_268438858 eq www rule-id 268438858 (hitcnt=19) 0x29588b4f access-list CSM_FW_ACL_ line 19 advanced permit tcp host 192.168.10.50 host 192.168.11.50 eq www rule-id 268438858 (hitcnt=19) 0x9d442895 access-list CSM_FW_ACL_ line 19 advanced permit tcp host 192.168.10.50 host 192.168.11.51 eq www rule-id 268438858 (hitcnt=0) 0xd026252b access-list CSM_FW_ACL_ line 19 advanced permit tcp host 192.168.10.51 host 192.168.11.50 eq www rule-id 268438858 (hitcnt=0) 0x0d785cc4 access-list CSM_FW_ACL_ line 19 advanced permit tcp host 192.168.10.51 host 192.168.11.51 eq www rule-id 268438858 (hitcnt=0) 0x3b3234f1
Vérification :
Activer system support trace et lancez une session HTTP de l'hôte A (192.168.10.50) vers l'hôte B (192.168.11.50). Trois paquets sont transférés au moteur du renifleur. Snort engine envoie à LINA le verdict PERMITLIST qui décharge essentiellement le reste du flux vers le moteur LINA :
> system support trace Enable firewall-engine-debug too? [n]: y Please specify an IP protocol: tcp Please specify a client IP address: 192.168.10.50 Please specify a client port: Please specify a server IP address: 192.168.11.50 Please specify a server port: 80 Monitoring packet tracer and firewall debug messages 192.168.10.50-42126 - 192.168.11.50-80 6 AS 1-1 CID 0 Packet: TCP, SYN, seq 453426648 192.168.10.50-42126 - 192.168.11.50-80 6 AS 1-1 CID 0 Session: new snort session 192.168.10.50-42126 - 192.168.11.50-80 6 AS 1-1 CID 0 AppID: service unknown (0), application unknown (0) 192.168.10.50-42126 > 192.168.11.50-80 6 AS 1-1 I 2 new firewall session 192.168.10.50-42126 > 192.168.11.50-80 6 AS 1-1 I 2 using HW or preset rule order 5, 'trust_L3-L4', action Trust and prefilter rule 0 192.168.10.50-42126 > 192.168.11.50-80 6 AS 1-1 I 2 HitCount data sent for rule id: 268438858, 192.168.10.50-42126 - 192.168.11.50-80 6 AS 1-1 CID 0 Firewall: trust/fastpath rule, 'trust_L3-L4', allow 192.168.10.50-42126 - 192.168.11.50-80 6 AS 1-1 CID 0 Snort id 2, NAP id 2, IPS id 0, Verdict PASS 192.168.11.50-80 - 192.168.10.50-42126 6 AS 1-1 CID 0 Packet: TCP, SYN, ACK, seq 2820426532, ack 453426649 192.168.11.50-80 - 192.168.10.50-42126 6 AS 1-1 CID 0 AppID: service unknown (0), application unknown (0) 192.168.11.50-80 - 192.168.10.50-42126 6 AS 1-1 CID 0 Firewall: trust/fastpath rule, 'trust_L3-L4', allow 192.168.11.50-80 - 192.168.10.50-42126 6 AS 1-1 CID 0 Snort id 2, NAP id 2, IPS id 0, Verdict PASS 192.168.10.50-42126 - 192.168.11.50-80 6 AS 1-1 CID 0 Packet: TCP, ACK, seq 453426649, ack 2820426533 192.168.10.50-42126 - 192.168.11.50-80 6 AS 1-1 CID 0 AppID: service unknown (0), application unknown (0) 192.168.10.50-42126 - 192.168.11.50-80 6 AS 1-1 CID 0 Firewall: trust/fastpath rule, 'trust_L3-L4', allow 192.168.10.50-42126 - 192.168.11.50-80 6 AS 1-1 CID 0 Snort id 2, NAP id 2, IPS id 0, Verdict PERMITLIST
Une fois la connexion terminée, le moteur du renifleur obtient les informations de métadonnées du moteur LINA et supprime la session :
192.168.10.50-42126 > 192.168.11.50-80 6 AS 1-1 I 2 Got end of flow event from hardware with flags 00010001. Rule Match Data: rule_id 0, rule_action 0 rev_id 0, rule_flags 3 192.168.10.50-42126 > 192.168.11.50-80 6 AS 1-1 I 2 Logging EOF for event from hardware with rule_id = 268438858 ruleAction = 3 ruleReason = 0 192.168.10.50-42126 > 192.168.11.50-80 6 AS 1-1 I 2 : Received EOF, deleting the snort session. 192.168.10.50-42126 - 192.168.11.50-80 6 AS 1-1 CID 0 Session: deleting snort session, reason: timeout 192.168.10.50-42126 > 192.168.11.50-80 6 AS 1-1 I 2 deleting firewall session flags = 0x10003, fwFlags = 0x1115 192.168.10.50-42126 - 192.168.11.50-80 6 AS 1-1 CID 0 Session: deleted snort session using 0 bytes; protocol id:(-1) : LWstate 0xf LWFlags 0x6007
La capture Snort montre les 3 paquets qui vont au moteur Snort :
> capture-traffic Please choose domain to capture traffic from: 0 - management0 1 - management1 2 - Global Selection? 2 Please specify tcpdump options desired. (or enter '?' for a list of supported options) Options: -n vlan and (host 192.168.10.50 and host 192.168.11.50) 10:26:16.525928 IP 192.168.10.50.42144 > 192.168.11.50.80: Flags [S], seq 3065553465, win 29200, options [mss 1380,sackOK,TS val 3789188468 ecr 0,nop,wscale 7], length 0 10:26:16.525928 IP 192.168.11.50.80 > 192.168.10.50.42144: Flags [S.], seq 3581351172, ack 3065553466, win 8192, options [mss 1380,nop,wscale 8,sackOK,TS val 57650410 ecr 3789188468], length 0 10:26:16.525928 IP 192.168.10.50.42144 > 192.168.11.50.80: Flags [.], ack 1, win 229, options [nop,nop,TS val 3789188470 ecr 57650410], length 0
La capture LINA montre le flux qui la traverse :
firepower# show capture CAPI 437 packets captured 1: 09:51:19.431007 802.1Q vlan#202 P0 192.168.10.50.42118 > 192.168.11.50.80: S 2459891187:2459891187(0) win 29200 <mss 1460,sackOK,timestamp 3787091387 0,nop,wscale 7> 2: 09:51:19.431648 802.1Q vlan#202 P0 192.168.11.50.80 > 192.168.10.50.42118: S 2860907367:2860907367(0) ack 2459891188 win 8192 <mss 1380,nop,wscale 8,sackOK,timestamp 57440579 3787091387> 3: 09:51:19.431847 802.1Q vlan#202 P0 192.168.10.50.42118 > 192.168.11.50.80: . ack 2860907368 win 229 <nop,nop,timestamp 3787091388 57440579> 4: 09:51:19.431953 802.1Q vlan#202 P0 192.168.10.50.42118 > 192.168.11.50.80: P 2459891188:2459891337(149) ack 2860907368 win 229 <nop,nop,timestamp 3787091388 57440579> 5: 09:51:19.444816 802.1Q vlan#202 P0 192.168.11.50.80 > 192.168.10.50.42118: . 2860907368:2860908736(1368) ack 2459891337 win 256 <nop,nop,timestamp 57440580 3787091388> 6: 09:51:19.444831 802.1Q vlan#202 P0 192.168.11.50.80 > 192.168.10.50.42118: . 2860908736:2860910104(1368) ack 2459891337 win 256 <nop,nop,timestamp 57440580 3787091388> …
La trace des paquets de LINA est une autre façon de voir les verdicts du renifleur. Le premier paquet a obtenu le verdict PASS (réussite) :
firepower# show capture CAPI packet-number 1 trace | i Type|Verdict Type: CAPTURE Type: ACCESS-LIST Type: ROUTE-LOOKUP Type: ACCESS-LIST Type: CONN-SETTINGS Type: NAT Type: NAT Type: IP-OPTIONS Type: CAPTURE Type: CAPTURE Type: NAT Type: CAPTURE Type: NAT Type: IP-OPTIONS Type: CAPTURE Type: FLOW-CREATION Type: EXTERNAL-INSPECT Type: SNORT Snort id 22, NAP id 2, IPS id 0, Verdict PASS Snort Verdict: (pass-packet) allow this packet Type: INPUT-ROUTE-LOOKUP-FROM-OUTPUT-ROUTE-LOOKUP Type: ADJACENCY-LOOKUP Type: CAPTURE
Trace du paquet TCP SYN/ACK sur l’interface OUTSIDE :
firepower# show capture CAPO packet-number 2 trace | i Type|Verdict Type: CAPTURE Type: ACCESS-LIST Type: FLOW-LOOKUP Type: EXTERNAL-INSPECT Type: SNORT Snort id 22, NAP id 2, IPS id 0, Verdict PASS Snort Verdict: (pass-packet) allow this packet Type: INPUT-ROUTE-LOOKUP-FROM-OUTPUT-ROUTE-LOOKUP Type: ADJACENCY-LOOKUP Type: CAPTURE
L'ACK TCP obtient le verdict PERMITLIST :
firepower# show capture CAPI packet-number 3 trace | i Type|Verdict Type: CAPTURE Type: ACCESS-LIST Type: FLOW-LOOKUP Type: EXTERNAL-INSPECT Type: SNORT Snort id 22, NAP id 2, IPS id 0, Verdict PERMITLIST Snort Verdict: (fast-forward) fast forward this flow Type: CAPTURE
Ceci est la sortie complète du verdict du renifleur (paquet n° 3)
firepower# show capture CAPI packet-number 3 trace | b Type: SNORT Type: SNORT Subtype: Result: ALLOW Config: Additional Information: Snort Trace: Packet: TCP, ACK, seq 687485179, ack 1029625865 AppID: service unknown (0), application unknown (0) Firewall: trust/fastpath rule, id 268438858, allow Snort id 31, NAP id 2, IPS id 0, Verdict PERMITLIST Snort Verdict: (fast-forward) fast forward this flow
Le 4e paquet n'est pas transféré au moteur Snort car le verdict est mis en cache par le moteur LINA :
firepower# show capture CAPI packet-number 4 trace 441 packets captured 4: 10:34:02.741523 802.1Q vlan#202 P0 192.168.10.50.42158 > 192.168.11.50.80: P 164375589:164375738(149) ack 3008397532 win 229 <nop,nop,timestamp 3789654678 57697031> 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 1254, using existing flow Phase: 4 Type: SNORT Subtype: Result: ALLOW Config: Additional Information: Snort Verdict: (fast-forward) fast forward this flow Result: input-interface: INSIDE(vrfid:0) input-status: up input-line-status: up Action: allow 1 packet shown
Les statistiques du renifleur confirment ceci :
firepower# show snort statistics Packet Counters: Passed Packets 2 Blocked Packets 0 Injected Packets 0 Packets bypassed (Snort Down) 0 Packets bypassed (Snort Busy) 0 Flow Counters: Fast-Forwarded Flows 1 Blacklisted Flows 0 Miscellaneous Counters: Start-of-Flow events 0 End-of-Flow events 1 Denied flow events 0 Frames forwarded to Snort before drop 0 Inject packets dropped 0
Flux de paquets avec la règle Trust (confiance). Quelques paquets sont inspectés par le renifleur et le reste par LINA :
Scénario 2. Action de confiance ACP (sans SI, QoS et politique d'identité)
Si vous souhaitez que le FTD applique des contrôles de sécurité adaptative (SI) à tous les flux, SI est déjà activé au niveau ACP et vous pouvez spécifier les sources SI (TALOS, flux, listes, etc.). D’un autre côté, si vous souhaitez les désactiver, vous désactivez Security Intelligence pour les réseaux dans le monde conformément à la politique de contrôle d’accès, Security Intelligence pour l’URL et Security Intelligence pour le DNS. Security Intelligence pour les réseaux et l’URL sont désactivés, comme le montre l’image :
Dans ce cas, la règle Trust (confiance) est déployée dans LINA en tant que trust :
> show access-list
... access-list CSM_FW_ACL_ line 9 remark rule-id 268435461: L4 RULE: Rule1 access-list CSM_FW_ACL_ line 10 advanced trust ip host 192.168.1.40 host 192.168.2.40 rule-id 268435461 event-log flow-end (hitcnt=0) 0x5c1346d6
Vérifiez le comportement
Lancez une session HTTP de l’hôte-A (192.168.1.40) à l’hôte-B (192.168.2.40). Comme il s'agit d'un FP4100 et qu'il prend en charge le déchargement de flux dans le matériel, ces choses se produisent :
- Quelques paquets sont acheminés par le moteur FTD LINA, et le reste du flux est transféré vers SmartNIC (accélérateur matériel)
- Aucun paquet n'est transféré au moteur Snort
La table de connexion FTD LINA affiche l'indicateur ‘o’ ce qui signifie que le flux a été déchargé vers le matériel. En outre, notez l'absence de la mention «N’. Cela signifie essentiellement « no Snort redirection » (pas de redirection vers le renifleur) :
firepower# show conn 1 in use, 15 most used TCP OUTSIDE 192.168.2.40:80 INSIDE 192.168.1.40:32809, idle 0:00:00, bytes 949584, flags UIOo
Les statistiques du renifleur affichent uniquement les événements de journalisation au début et à la fin de la session :
firepower# show snort statistics Packet Counters: Passed Packets 0 Blocked Packets 0 Injected Packets 0 Packets bypassed (Snort Down) 0 Packets bypassed (Snort Busy) 0 Flow Counters: Fast-Forwarded Flows 0 Blacklisted Flows 0 Miscellaneous Counters: Start-of-Flow events 1 End-of-Flow events 1
Les journaux FTD LINA montrent que pour chaque session, deux flux (un par direction) ont été transférés vers le matériel :
Sep 27 2017 20:16:05: %ASA-7-609001: Built local-host INSIDE:192.168.1.40 Sep 27 2017 20:16:05: %ASA-6-302013: Built inbound TCP connection 25384 for INSIDE:192.168.1.40/32809 (192.168.1.40/32809) to OUTSIDE:192.168.2.40/80 (192.168.2.40/80) Sep 27 2017 20:16:05: %ASA-6-805001: Offloaded TCP Flow for connection 25384 from INSIDE:192.168.1.40/32809 (192.168.1.40/32809) to OUTSIDE:192.168.2.40/80 (192.168.2.40/80) Sep 27 2017 20:16:05: %ASA-6-805001: Offloaded TCP Flow for connection 25384 from OUTSIDE:192.168.2.40/80 (192.168.2.40/80) to INSIDE:192.168.1.40/32809 (192.168.1.40/32809) Sep 27 2017 20:16:05: %ASA-6-805002: TCP Flow is no longer offloaded for connection 25384 from OUTSIDE:192.168.2.40/80 (192.168.2.40/80) to INSIDE:192.168.1.40/32809 (192.168.1.40/32809) Sep 27 2017 20:16:05: %ASA-6-805002: TCP Flow is no longer offloaded for connection 25384 from INSIDE:192.168.1.40/32809 (192.168.1.40/32809) to OUTSIDE:192.168.2.40/80 (192.168.2.40/80) Sep 27 2017 20:16:05: %ASA-6-302014: Teardown TCP connection 25384 for INSIDE:192.168.1.40/32809 to OUTSIDE:192.168.2.40/80 duration 0:00:00 bytes 1055048 TCP FINs Sep 27 2017 20:16:05: %ASA-7-609002: Teardown local-host INSIDE:192.168.1.40 duration 0:00:00
Flux de paquets avec la règle de confiance déployée comme trust dans LINA. Quelques paquets sont inspectés par LINA, le reste est déchargé sur SmartNIC (FP4100/FP9300) :
Scénarios :
- Vous devez utiliser
Trustlorsque vous souhaitez que seuls quelques paquets soient vérifiés par le moteur Snort (par exemple, détection d'application, vérification SI) et que le reste du flux soit déchargé vers le moteur LINA - Si vous utilisez FTD sur FP4100/9300 et que vous voulez que le flux contourne complètement l'inspection Snort, alors considérez la règle de préfiltrage avec
Fastpathaction (voir la section associée dans ce document)
Action Prefilter Policy Block (blocage de la politique de préfiltre)
Considérez la topologie comme le montre l’image :
Tenez également compte de la politique, comme le montre l’image :
Voici la stratégie déployée dans le moteur FTD Snort (fichier ngfw.rules) :
# Start of tunnel and priority rules. # These rules are evaluated by LINA. Only tunnel tags are used from the matched rule id. 268437506 deny any 192.168.1.40 32 any any 192.168.2.40 32 any any any (tunnel -1
Dans LINA :
access-list CSM_FW_ACL_ line 1 remark rule-id 268437506: PREFILTER POLICY: FTD_Prefilter access-list CSM_FW_ACL_ line 2 remark rule-id 268437506: RULE: Prefilter1 access-list CSM_FW_ACL_ line 3 advanced deny ip host 192.168.1.40 host 192.168.2.40 rule-id 268437506 event-log flow-start (hitcnt=0) 0x76476240
Lorsque vous tracez un paquet virtuel, cela indique que le paquet est abandonné par LINA et n’est jamais transmis au renifleur :
firepower# packet-tracer input INSIDE icmp 192.168.1.40 8 0 192.168.2.40 … Phase: 4 Type: ACCESS-LIST Subtype: log Result: DROP Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced deny ip host 192.168.1.40 host 192.168.2.40 rule-id 268437506 event-log flow-start access-list CSM_FW_ACL_ remark rule-id 268437506: PREFILTER POLICY: FTD_Prefilter access-list CSM_FW_ACL_ remark rule-id 268437506: RULE: Prefilter1 Additional Information: Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule
Les statistiques du renifleur montrent :
firepower# show snort statistics Packet Counters: Passed Packets 0 Blocked Packets 0 Injected Packets 0 Packets bypassed (Snort Down) 0 Packets bypassed (Snort Busy) 0 Flow Counters: Fast-Forwarded Flows 0 Blacklisted Flows 0 Miscellaneous Counters: Start-of-Flow events 0 End-of-Flow events 0 Denied flow events 1
La politique de contrôle d’accès de LINA affiche :
firepower# show asp drop Frame drop: Flow is denied by configured rule (acl-drop) 1
Scénarios :
Vous pouvez utiliser une règle de blocage de préfiltre lorsque vous souhaitez bloquer le trafic en fonction des conditions L3/L4 et sans avoir à effectuer d'inspection Snort du trafic.
Action Prefilter Policy Fastpath (Fastpath pour la politique de préfiltre)
Tenez compte de la règle de politique de préfiltre, comme le montre l’image :
Voici la stratégie déployée dans le moteur FTD Snort :
268437506 fastpath any any any any any any any any (log dcforward flowend) (tunnel -1)
Dans FTD LINA :
access-list CSM_FW_ACL_ line 1 remark rule-id 268437506: PREFILTER POLICY: FTD_Prefilter access-list CSM_FW_ACL_ line 2 remark rule-id 268437506: RULE: Prefilter1 access-list CSM_FW_ACL_ line 3 advanced trust tcp host 192.168.1.40 host 192.168.2.40 eq www rule-id 268437506 event-log flow-end (hitcnt=0) 0xf3410b6f
Vérifiez le comportement
Lorsque l’hôte A (192.168.1.40) tente d’ouvrir une session HTTP vers l’hôte B (192.168.2.40), quelques paquets passent par LINA, et le reste est déchargé vers SmartNIC. In this case system support trace avec firewall-engine-debug affiche les résultats activés :
> system support trace Please specify an IP protocol: tcp Please specify a client IP address: 192.168.1.40 Please specify a client port: Please specify a server IP address: 192.168.2.40 Please specify a server port: Enable firewall-engine-debug too? [n]: y Monitoring packet tracer debug messages 192.168.1.40-32840 > 192.168.2.40-80 6 AS 1 I 8 Got end of flow event from hardware with flags 04000000
Les journaux LINA indiquent le flux déchargé :
Oct 01 2017 14:36:51: %ASA-7-609001: Built local-host INSIDE:192.168.1.40 Oct 01 2017 14:36:51: %ASA-7-609001: Built local-host OUTSIDE:192.168.2.40 Oct 01 2017 14:36:51: %ASA-6-302013: Built inbound TCP connection 966 for INSIDE:192.168.1.40/32840 (192.168.1.40/32840) to OUTSIDE:192.168.2.40/80 (192.168.2.40/80) Oct 01 2017 14:36:51: %ASA-6-805001: Offloaded TCP Flow for connection 966 from INSIDE:192.168.1.40/32840 (192.168.1.40/32840) to OUTSIDE:192.168.2.40/80 (192.168.2.40/80) Oct 01 2017 14:36:51: %ASA-6-805001: Offloaded TCP Flow for connection 966 from OUTSIDE:192.168.2.40/80 (192.168.2.40/80) to INSIDE:192.168.1.40/32840 (192.168.1.40/32840)
Les captures LINA indiquent que 8 paquets transitent par :
firepower# show capture capture CAPI type raw-data buffer 33554432 trace trace-count 100 interface INSIDE [Capturing - 3908 bytes] match ip host 192.168.1.40 host 192.168.2.40 capture CAPO type raw-data buffer 33554432 trace trace-count 100 interface OUTSIDE [Capturing - 3908 bytes] match ip host 192.168.1.40 host 192.168.2.40
firepower# show capture CAPI 8 packets captured 1: 14:45:32.700021 192.168.1.40.32842 > 192.168.2.40.80: S 3195173118:3195173118(0) win 2920 <mss 1460,sackOK,timestamp 332569060 0> 2: 14:45:32.700372 192.168.2.40.80 > 192.168.1.40.32842: S 184794124:184794124(0) ack 3195173119 win 2896 <mss 1380,sackOK,timestamp 332567732 332569060> 3: 14:45:32.700540 192.168.1.40.32842 > 192.168.2.40.80: P 3195173119:3195173317(198) ack 184794125 win 2920 <nop,nop,timestamp 332569060 332567732> 4: 14:45:32.700876 192.168.2.40.80 > 192.168.1.40.32842: . 184794125:184795493(1368) ack 3195173317 win 2698 <nop,nop,timestamp 332567733 332569060> 5: 14:45:32.700922 192.168.2.40.80 > 192.168.1.40.32842: P 184795493:184796861(1368) ack 3195173317 win 2698 <nop,nop,timestamp 332567733 332569060> 6: 14:45:32.701425 192.168.2.40.80 > 192.168.1.40.32842: FP 184810541:184810851(310) ack 3195173317 win 2698 <nop,nop,timestamp 332567733 332569061> 7: 14:45:32.701532 192.168.1.40.32842 > 192.168.2.40.80: F 3195173317:3195173317(0) ack 184810852 win 2736 <nop,nop,timestamp 332569061 332567733> 8: 14:45:32.701639 192.168.2.40.80 > 192.168.1.40.32842: . ack 3195173318 win 2697 <nop,nop,timestamp 332567734 332569061>
Les statistiques de flux de déchargement de Cisco FTD indiquent 22 paquets déchargés sur le matériel :
firepower# show flow-offload statistics
Packet stats of port : 0
Tx Packet count : 22
Rx Packet count : 22
Dropped Packet count : 0
VNIC transmitted packet : 22
VNIC transmitted bytes : 15308
VNIC Dropped packets : 0
VNIC erroneous received : 0
VNIC CRC errors : 0
VNIC transmit failed : 0
VNIC multicast received : 0
Vous pouvez également utiliser la show flow-offload flow pour afficher des informations supplémentaires relatives aux flux déchargés. Voici un exemple :
firepower# show flow-offload flow
Total offloaded flow stats: 2 in use, 4 most used, 20% offloaded, 0 collisions
TCP intfc 103 src 192.168.1.40:39301 dest 192.168.2.40:20, static, timestamp 616063741, packets 33240, bytes 2326800
TCP intfc 104 src 192.168.2.40:20 dest 192.168.1.40:39301, static, timestamp 616063760, packets 249140, bytes 358263320
firepower# show conn
5 in use, 5 most used
Inspect Snort:
preserve-connection: 1 enabled, 0 in effect, 4 most enabled, 0 most in effect
TCP OUTSIDE 192.168.2.40:21 INSIDE 192.168.1.40:40988, idle 0:00:00, bytes 723, flags UIO
TCP OUTSIDE 192.168.2.40:21 INSIDE 192.168.1.40:40980, idle 0:02:40, bytes 1086, flags UIO
TCP OUTSIDE 192.168.2.40:80 INSIDE 192.168.1.40:49442, idle 0:00:00, bytes 86348310, flags UIO N1
TCP OUTSIDE 192.168.2.40:20 INSIDE 192.168.1.40:39301, idle 0:00:00, bytes 485268628, flags Uo <- offloaded flow
TCP OUTSIDE 192.168.2.40:20 INSIDE 192.168.1.40:34713, idle 0:02:40, bytes 821799360, flags UFRIO
- Le pourcentage est basé sur le '
show conn' résultat. Par exemple, si 5 cons au total passent par le moteur FTD LINA et que 1 d'entre eux est déchargé, alors 20 % est déclaré comme déchargé - La limite maximale de sessions déchargées dépend de la version du logiciel (par exemple, ASA 9.8.3 et FTD 6.2.3 prennent en charge 4 millions de flux déchargés bidirectionnels (ou 8 millions de flux unidirectionnels))
- Si le nombre de flux déchargés atteint la limite (par exemple 4 millions de flux bidirectionnels), aucune nouvelle connexion n'est déchargée tant que les connexions en cours ne sont pas supprimées de la table déchargée
Afin de voir tous les paquets sur FP4100/9300 qui passent par Cisco FTD (déchargé + LINA), il est nécessaire d’activer la capture au niveau du châssis, comme le montre l’image :
La capture du fond de panier du châssis indique les deux directions. En raison de l’architecture de capture FXOS (deux points par direction), chaque paquet est présenté deux fois, comme le montre l’image :
Statistiques sur les paquets :
- Total des paquets passant par Cisco FTD : 30
- Paquets passant par FTD LINA : 8
- Paquets déchargés vers l’accélérateur SmartNIC HW : 22
Dans le cas d'une plate-forme différente de FP4100/FP9300, tous les paquets sont traités par le moteur LINA puisque le déchargement de flux n'est pas pris en charge (notez l'absence de l'indicateur o) :
FP2100-6# show conn addr 192.168.1.40
33 in use, 123 most used
Inspect Snort:
preserve-connection: 0 enabled, 0 in effect, 2 most enabled, 0 most in effect
TCP OUTSIDE 192.168.2.40:80 INSIDE 192.168.1.40:50890, idle 0:00:09, bytes 175, flags UxIO
Les syslogs LINA affichent uniquement les événements de mise à disposition et de fin de connexion :
FP2100-6# show log | i 192.168.2.40 Jun 21 2020 14:29:44: %FTD-6-302013: Built inbound TCP connection 6914 for INSIDE:192.168.1.40/50900 (192.168.11.101/50900) to OUTSIDE:192.168.2.40/80 (192.168.2.40/80) Jun 21 2020 14:30:30: %FTD-6-302014: Teardown TCP connection 6914 for INSIDE:192.168.1.40/50900 to OUTSIDE:192.168.2.40/80 duration 0:00:46 bytes 565 TCP FINs from OUTSIDE
Scénarios :
- Utilisation
Prefilter Fastpathlorsque vous souhaitez contourner complètement l'inspection Snort. Vous devez généralement faire cela pour les gros flux de confiance, comme les sauvegardes, les transferts de base de données, etc. - Sur les appliances FP4100/9300,
Fastpathdéclenche le déchargement de flux et seuls quelques paquets passent par le moteur FTD LINA. Le reste est géré par SmartNIC, ce qui réduit la latence
Action Prefilter Policy Fastpath (Fastpath pour la politique de préfiltre) (ensemble en ligne)
Dans le cas où une action FastPath de stratégie de préfiltrage est appliquée au trafic qui passe par un ensemble en ligne (interfaces NGIPS), ces points doivent être pris en considération :
- La règle est appliquée au moteur LINA en tant que
trustaction - Le flux n’est pas contrôlé par le moteur du renifleur
- Le déchargement de flux (accélération matérielle) ne se produit pas, car le déchargement de flux ne s’applique pas aux interfaces NGIPS
Voici un exemple de suivi de paquet dans le cas d'une action de préfiltrage FastPath appliquée à un jeu en ligne :
firepower# packet-tracer input inside tcp 192.168.1.40 12345 192.168.1.50 80 detailed Phase: 1 Type: NGIPS-MODE Subtype: ngips-mode Result: ALLOW Config: Additional Information: The flow ingressed an interface configured for NGIPS mode and NGIPS services will be applied Forward Flow based lookup yields rule: in id=0x2ad7ac48b330, priority=501, domain=ips-mode, deny=false hits=2, user_data=0x2ad80d54abd0, cs_id=0x0, flags=0x0, protocol=0 src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0 input_ifc=inside, output_ifc=any Phase: 2 Type: ACCESS-LIST Subtype: log Result: ALLOW Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced trust ip object 192.168.1.0 object 192.168.1.0 rule-id 268438531 event-log flow-end access-list CSM_FW_ACL_ remark rule-id 268438531: PREFILTER POLICY: PF1 access-list CSM_FW_ACL_ remark rule-id 268438531: RULE: 1 Additional Information: Forward Flow based lookup yields rule: in id=0x2ad9f9f8a7f0, priority=12, domain=permit, trust hits=1, user_data=0x2ad9b23c5d40, cs_id=0x0, use_real_addr, flags=0x0, protocol=0 src ip/id=192.168.1.0, mask=255.255.255.0, port=0, tag=any, ifc=any dst ip/id=192.168.1.0, mask=255.255.255.0, port=0, tag=any, ifc=any, vlan=0, dscp=0x0 input_ifc=any, output_ifc=any Phase: 3 Type: NGIPS-EGRESS-INTERFACE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: Ingress interface inside is in NGIPS inline mode. Egress interface outside is determined by inline-set configuration Phase: 4 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 7, packet dispatched to next module Module information for forward flow ... snp_fp_ips_tcp_state_track_lite snp_fp_ips_mode_adj snp_fp_tracer_drop snp_ifc_stat Module information for reverse flow ... snp_fp_ips_tcp_state_track_lite snp_fp_ips_mode_adj snp_fp_tracer_drop snp_ifc_stat Result: input-interface: inside input-status: up input-line-status: up Action: allow
Voici la représentation visuelle du chemin du paquet :
Action Prefilter Policy Fastpath (Fastpath pour la politique de préfiltre) (ensemble en ligne avec dérivateur)
Identique au cas d’ensemble en ligne
Action Prefilter Policy Analyze (analyse de la politique de préfiltre)
Scénario 1. Préfiltrer l'analyse avec la règle de blocage ACP
Tenez compte de la règle Prefilter Policy (politique de préfiltre) qui contient une règle Analyze (analyse), comme le montre l’image :
L'ACP contient uniquement la règle par défaut définie sur Block All Traffic comme le montre l'image :
Voici la stratégie déployée dans le moteur FTD Snort (fichier ngfw.rules) :
# Start of tunnel and priority rules. # These rules are evaluated by LINA. Only tunnel tags are used from the matched rule id. 268435460 allow any 192.168.1.40 32 any any 192.168.2.40 32 any any any (tunnel -1) 268435459 allow any any 1025-65535 any any 3544 any 17 (tunnel -1) 268435459 allow any any 3544 any any 1025-65535 any 17 (tunnel -1) 268435459 allow any any any any any any any 47 (tunnel -1) 268435459 allow any any any any any any any 41 (tunnel -1) 268435459 allow any any any any any any any 4 (tunnel -1) # End of tunnel and priority rules. # Start of AC rule. 268435458 deny any any any any any any any any (log dcforward flowstart) # End of AC rule.
Voici la politique déployée dans le moteur FTD LINA :
access-list CSM_FW_ACL_ line 3 advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460 (hitcnt=0) 0xb788b786
Vérifiez le comportement
Packet-Tracer indique que le paquet est autorisé par LINA, est transféré au moteur Snort (en raison de permit ) et Snort Engine renvoie une Block verdict, car l'action par défaut d'AC correspond.
Lorsque vous tracez un paquet, il révèle la même chose :
firepower# packet-tracer input INSIDE icmp 192.168.1.40 8 0 192.168.2.40 ... Phase: 4 Type: ACCESS-LIST Subtype: log Result: ALLOW Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460 access-list CSM_FW_ACL_ remark rule-id 268435460: PREFILTER POLICY: Prefilter_Policy1 access-list CSM_FW_ACL_ remark rule-id 268435460: RULE: Prefilter_Rule1 Additional Information: This packet will be sent to snort for additional processing where a verdict will be reached … Phase: 14 Type: SNORT Subtype: Result: DROP Config: Additional Information: Snort Trace: Packet: ICMP AppID: service ICMP (3501), application unknown (0) Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 8, icmpCode 0 Firewall: block rule, id 268435458, drop Snort: processed decoder alerts or actions queue, drop NAP id 1, IPS id 0, Verdict BLOCKLIST, Blocked by Firewall Snort Verdict: (block-list) block list this flow Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (firewall) Blocked by the firewall preprocessor
Scénario 2. Préfiltrer l'analyse avec la règle d'autorisation ACP
Si l’objectif est de permettre au paquet de traverser Cisco FTD, il est nécessaire d’ajouter une règle dans la politique de contrôle d’accès. L'action peut être Autoriser ou Approuver selon l'objectif (par exemple, si vous souhaitez appliquer une inspection de couche 7, vous devez utiliser Allow action) comme l'illustre l'image :
La politique déployée dans le moteur FTD du renifleur :
# Start of AC rule. 268435461 allow any 192.168.1.40 32 any any 192.168.2.40 32 any any any 268435458 deny any any any any any any any any (log dcforward flowstart) # End of AC rule.
Dans le moteur LINA :
access-list CSM_FW_ACL_ line 3 advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460 (hitcnt=1) 0xb788b786
Vérifiez le comportement
Packet-Tracer indique que le paquet correspond à la règle 268435460 dans LINA et 268435461 dans le moteur Snort :
firepower# packet-tracer input INSIDE icmp 192.168.1.40 8 0 192.168.2.40 ... Phase: 4 Type: ACCESS-LIST Subtype: log Result: ALLOW Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460 access-list CSM_FW_ACL_ remark rule-id 268435460: PREFILTER POLICY: Prefilter_Policy1 access-list CSM_FW_ACL_ remark rule-id 268435460: RULE: Prefilter_Rule1 Additional Information: This packet will be sent to snort for additional processing where a verdict will be reached … Phase: 14 Type: SNORT Subtype: Result: ALLOW Config: Additional Information: Snort Trace: Packet: ICMP AppID: service ICMP (3501), application unknown (0) Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 8, icmpCode 0 Firewall: allow rule, id 268435461, allow NAP id 1, IPS id 0, Verdict PASS Snort Verdict: (pass-packet) allow this packet … Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: allow
Scénario 3. Préfiltrer l'analyse avec la règle d'approbation ACP
Dans le cas où la politique de contrôle d’accès contient une règle Trust (confiance), c’est ce que vous avez, comme le montre l’image :
Renifleur :
# Start of AC rule. 268435461 fastpath any 192.168.1.40 32 any any 192.168.2.40 32 any any any 268435458 deny any any any any any any any any (log dcforward flowstart) # End of AC rule.
LINA :
access-list CSM_FW_ACL_ line 3 advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460 (hitcnt=2) 0xb788b786
N'oubliez pas que puisque l'interface utilisateur est activée par défaut, la règle d'approbation est déployée en tant que permit sur LINA afin qu'au moins quelques paquets soient redirigés vers le moteur Snort pour inspection.
Vérifiez le comportement
Packet-tracer montre que le moteur Snort Autorise répertorie le paquet et décharge essentiellement le flux de repos vers LINA :
firepower# packet-tracer input INSIDE icmp 192.168.1.40 8 0 192.168.2.40 ... Phase: 4 Type: ACCESS-LIST Subtype: log Result: ALLOW Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460 access-list CSM_FW_ACL_ remark rule-id 268435460: PREFILTER POLICY: Prefilter_Policy1 access-list CSM_FW_ACL_ remark rule-id 268435460: RULE: Prefilter_Rule1 Additional Information: This packet will be sent to snort for additional processing where a verdict will be reached … Phase: 14 Type: SNORT Subtype: Result: ALLOW Config: Additional Information: Snort Trace: Packet: ICMP AppID: service ICMP (3501), application unknown (0) Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 8, icmpCode 0 Firewall: trust/fastpath rule, id 268435461, allow NAP id 1, IPS id 0, Verdict PERMITLIST Snort Verdict: (fast-forward) fast forward this flow … Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: allow
Scénario 4. Préfiltrer l'analyse avec la règle d'approbation ACP
Dans ce scénario, Security Intelligence a été désactivée manuellement.
La règle est déployée dans le renifleur comme suit :
# Start of AC rule. 268435461 fastpath any 192.168.1.40 32 any any 192.168.2.40 32 any any any 268435458 deny any any any any any any any any (log dcforward flowstart) # End of AC rule.
Dans LINA, la règle est déployée en tant que Trust (confiance). Un paquet qui correspond à la règle d'autorisation (voir le nombre de succès ACE) qui est déployé en raison de la règle Analyze Prefilter et le paquet est inspecté par le moteur Snort :
access-list CSM_FW_ACL_ line 3 advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460 (hitcnt=3) 0xb788b786 ... access-list CSM_FW_ACL_ line 13 advanced trust ip host 192.168.1.40 host 192.168.2.40 rule-id 268435461 event-log flow-end (hitcnt=0) 0x5c1346d6 ... access-list CSM_FW_ACL_ line 16 advanced deny ip any any rule-id 268435458 event-log flow-start (hitcnt=0) 0x97aa021a
Vérifiez le comportement
firepower# packet-tracer input INSIDE icmp 192.168.1.40 8 0 192.168.2.40 ... Phase: 4 Type: ACCESS-LIST Subtype: log Result: ALLOW Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460 access-list CSM_FW_ACL_ remark rule-id 268435460: PREFILTER POLICY: Prefilter_Policy1 access-list CSM_FW_ACL_ remark rule-id 268435460: RULE: Prefilter_Rule1 Additional Information: This packet will be sent to snort for additional processing where a verdict will be reached ... Phase: 14 Type: SNORT Subtype: Result: ALLOW Config: Additional Information: Snort Trace: Packet: ICMP AppID: service ICMP (3501), application unknown (0) Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 8, icmpCode 0 Firewall: trust/fastpath rule, id 268435461, allow NAP id 1, IPS id 0, Verdict PERMITLIST Snort Verdict: (fast-forward) fast forward this flow … Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: allow
Points principaux
- Les
AnalyzeL'action est déployée en tant que règle d'autorisation dans le moteur LINA. Cela a un effet sur le paquet à transmettre au moteur Snort pour inspection - Les
AnalyzeL'action ne déploie aucune règle dans le moteur Snort. Vous devez donc vous assurer de configurer une règle dans ACP correspondant dans Snort< - Cela dépend de la règle ACP qui est déployée dans le moteur Snort (
blockvsallowvsfastpath) aucun ou tous ou quelques paquets sont autorisés par Snort
Scénarios :
- Un exemple d'utilisation de
AnalyzeL'action est quand vous avez une règle Fastpath large dans la politique de préfiltrage et que vous voulez mettre quelques exceptions pour des flux spécifiques afin qu'ils soient inspectés par Snort
Action Monitor (surveillance) de la politique de contrôle d’accès
Une règle Monitor (surveillance) configurée sur l’interface utilisateur de Cisco FMC :
La règle de surveillance est déployée sur le moteur FTD LINA en tant que permit et au moteur Snort en tant que audit action.
firepower# show access-list … access-list CSM_FW_ACL_ line 10 advanced permit ip 192.168.10.0 255.255.255.0 192.168.11.0 255.255.255.0 rule-id 268438863 (hitcnt=0) 0x61bbaf0c
La règle du renifleur :
admin@firepower:~$ cat /var/sf/detection_engines/9e080e5c-adc3-11ea-9d37-44884cf7e9ba/ngfw.rules … # Start of AC rule. 268438863 audit any 192.168.10.0 24 any any 192.168.11.0 24 any any any (log dcforward flowend) # End rule 268438863
Points principaux
- La règle de surveillance ne supprime ni n'autorise le trafic, mais génère un événement de connexion. Le paquet est vérifié par rapport aux règles suivantes et il est soit autorisé, soit abandonné
- Les événements de connexion FMC montrent que le paquet correspond à 2 règles :
System support trace Le résultat montre que les paquets correspondent aux deux règles :
> system support trace Enable firewall-engine-debug too? [n]: y Please specify an IP protocol: tcp Please specify a client IP address: 192.168.10.50 Please specify a client port: Please specify a server IP address: 192.168.11.50 Please specify a server port: Monitoring packet tracer and firewall debug messages 192.168.10.50-41922 - 192.168.11.50-80 6 AS 1-1 CID 0 Packet: TCP, SYN, seq 419031630 192.168.10.50-41922 - 192.168.11.50-80 6 AS 1-1 CID 0 Session: new snort session 192.168.10.50-41922 - 192.168.11.50-80 6 AS 1-1 CID 0 AppID: service unknown (0), application unknown (0) 192.168.10.50-41922 > 192.168.11.50-80 6 AS 1-1 I 19 new firewall session 192.168.10.50-41922 > 192.168.11.50-80 6 AS 1-1 I 19 Starting AC with minimum 2, 'Monitor_Rule', and IPProto first with zone s -1 -> -1, geo 0 -> 0, vlan 0, source sgt type: 0, source sgt tag: 0, ISE sgt id: 0, dest sgt type: 0, ISE dest sgt tag: 0, svc 0, payload 0, client 0, misc 0, user 9999997, icmpType 0, icmpCode 0 192.168.10.50-41922 > 192.168.11.50-80 6 AS 1-1 I 19 match rule order 2, 'Monitor_Rule', action Audit 192.168.10.50-41922 > 192.168.11.50-80 6 AS 1-1 I 19 match rule order 3, 'trust_L3-L4', action Trust 192.168.10.50-41922 > 192.168.11.50-80 6 AS 1-1 I 19 MidRecovery data sent for rule id: 268438858,rule_action:3, rev id:1078 02206, rule_match flag:0x2
Scénarios :
Utilisé pour surveiller l’activité du réseau et générer un événement de connexion
Action Interactive Block (blocage interactif) de la politique de contrôle d’accès
Une règle Interactive Block (blocage interactif) configurée sur l’interface utilisateur de Cisco FMC :
La règle de blocage interactif est déployée sur le moteur FTD LINA en tant que permit et au moteur Snort en tant que règle de contournement :
firepower# show access-list … access-list CSM_FW_ACL_ line 9 remark rule-id 268438864: L7 RULE: Inter-Block-Rule1 access-list CSM_FW_ACL_ line 10 advanced permit tcp 192.168.10.0 255.255.255.0 host 192.168.11.50 eq www rule-id 268438864 (hitcnt=3) 0xba785fc0 access-list CSM_FW_ACL_ line 11 remark rule-id 268438865: ACCESS POLICY: ACP1 - Mandatory access-list CSM_FW_ACL_ line 12 remark rule-id 268438865: L7 RULE: Inter-Block_Rule2 access-list CSM_FW_ACL_ line 13 advanced permit ip 192.168.10.0 255.255.255.0 host 192.168.11.51 rule-id 268438865 (hitcnt=0) 0x622350d0
Moteur du renifleur :
admin@firepower:~$ cat /var/sf/detection_engines/9e080e5c-adc3-11ea-9d37-44884cf7e9ba/ngfw.rules … # Start of AC rule. 268438864 bypass any 192.168.10.0 24 any any 192.168.11.50 32 80 any 6 # End rule 268438864 268438865 bypass any 192.168.10.0 24 any any 192.168.11.51 32 any any any (appid 676:1) (ip_protos 6, 17) # End rule 268438865
La règle Interactive Block (blocage interactif) invite l’utilisateur à interdire la destination
Par défaut, le pare-feu permet de contourner le blocage pendant 600 secondes :
Dans la system support trace résultat vous pouvez voir que le pare-feu bloque initialement le trafic et affiche la page de blocage :
> system support trace … 192.168.10.52-58717 - 192.168.11.50-80 6 AS 1-1 CID 0 Packet: TCP, ACK, seq 983273680, ack 2014879580 192.168.10.52-58717 - 192.168.11.50-80 6 AS 1-1 CID 0 AppID: service HTTP (676), application unknown (0) 192.168.10.52-58717 > 192.168.11.50-80 6 AS 1-1 I 22 Starting AC with minimum 2, 'Inter-Block-Rule1', and IPProto first with zones -1 -> -1, geo 0(0) -> 0, vlan 0, source sgt type: 0, sgt tag: 0, ISE sgt id: 0, dest sgt type: 0, ISE dest_sgt_tag: 0, svc 676, payload 0, client 589, misc 0, user 9999997, min url-cat-list 0-0-0, url http://192.168.11.50/, xff 192.168.10.52-58717 > 192.168.11.50-80 6 AS 1-1 I 22 match rule order 2, 'Inter-Block-Rule1', action Interactive 192.168.10.52-58717 > 192.168.11.50-80 6 AS 1-1 I 22 bypass action sending HTTP interactive response of 1093 bytes 192.168.10.52-58717 - 192.168.11.50-80 6 AS 1-1 CID 0 Firewall: interactive block rule, 'Inter-Block-Rule1', drop 192.168.10.52-58717 - 192.168.11.50-80 6 AS 1-1 CID 0 Snort: processed decoder alerts or actions queue, drop 192.168.10.52-58717 > 192.168.11.50-80 6 AS 1-1 I 22 deleting firewall session flags = 0x800, fwFlags = 0x1002 192.168.10.52-58717 - 192.168.11.50-80 6 AS 1-1 CID 0 Snort id 22, NAP id 1, IPS id 0, Verdict BLACKLIST 192.168.10.52-58717 - 192.168.11.50-80 6 AS 1-1 CID 0 ===> Blocked by Firewall Verdict reason is sent to DAQ
Une fois que l'utilisateur sélectionne Continue (ou actualise la page du navigateur) le débogage montre que les paquets sont autorisés par la même règle qui imite et Allow action :
192.168.10.52-58718 - 192.168.11.50-80 6 AS 1-1 CID 0 Packet: TCP, ACK, seq 1357413630, ack 2607625293 192.168.10.52-58718 - 192.168.11.50-80 6 AS 1-1 CID 0 AppID: service HTTP (676), application unknown (0) 192.168.10.52-58718 > 192.168.11.50-80 6 AS 1-1 I 8 Starting AC with minimum 2, 'Inter-Block-Rule1', and IPProto first with zones -1 -> -1, geo 0(0) -> 0, vlan 0, source sgt type: 0, sgt tag: 0, ISE sgt id: 0, dest sgt type: 0, ISE dest_sgt_tag: 0, svc 676, payload 0, client 589, misc 0, user 9999997, min url-cat-list 0-0-0, url http://192.168.11.50/, xff 192.168.10.52-58718 > 192.168.11.50-80 6 AS 1-1 I 8 match rule order 2, 'Inter-Block-Rule1', action Interactive 192.168.10.52-58718 > 192.168.11.50-80 6 AS 1-1 I 8 bypass action interactive bypass 192.168.10.52-58718 > 192.168.11.50-80 6 AS 1-1 I 8 allow action 192.168.10.52-58718 - 192.168.11.50-80 6 AS 1-1 CID 0 Firewall: allow rule, 'Inter-Block-Rule1', allow 192.168.10.52-58718 - 192.168.11.50-80 6 AS 1-1 CID 0 Firewall: interactive bypass rule, 'Inter-Block-Rule1', allow 192.168.10.52-58718 - 192.168.11.50-80 6 AS 1-1 CID 0 Snort id 8, NAP id 1, IPS id 0, Verdict PASS
Scénarios :
Afficher une page d’avertissement aux utilisateurs Web et leur donner la possibilité de continuer.
Action Interactive Block (blocage interactif) de la politique de contrôle d’accès avec réinitialisation
Une règle Interactive Block (blocage interactif) avec réinitialisation configurée sur l’interface utilisateur de Cisco FMC :
Le bloc interactif avec règle de réinitialisation est déployé sur le moteur FTD LINA en tant que permit et au moteur Snort comme règle d'initialisation :
firepower# show access-list … access-list CSM_FW_ACL_ line 9 remark rule-id 268438864: L7 RULE: Inter-Block-Rule1 access-list CSM_FW_ACL_ line 10 advanced permit tcp 192.168.10.0 255.255.255.0 host 192.168.11.50 eq www rule-id 268438864 (hitcnt=13) 0xba785fc0 access-list CSM_FW_ACL_ line 11 remark rule-id 268438865: ACCESS POLICY: ACP1 - Mandatory access-list CSM_FW_ACL_ line 12 remark rule-id 268438865: L7 RULE: Inter-Block_Rule2 access-list CSM_FW_ACL_ line 13 advanced permit ip 192.168.10.0 255.255.255.0 host 192.168.11.51 rule-id 268438865 (hitcnt=0) 0x622350d0
Moteur du renifleur :
# Start of AC rule. 268438864 intreset any 192.168.10.0 24 any any 192.168.11.50 32 80 any 6 # End rule 268438864 268438865 intreset any 192.168.10.0 24 any any 192.168.11.51 32 any any any (appid 676:1) (ip_protos 6, 17) # End rule 268438865
Tout comme l'option Bloquer avec réinitialisation, l'utilisateur peut sélectionner Continue option :
Dans le débogage du renifleur, l’action est indiquée dans la réinitialisation interactive :
> system support trace Enable firewall-engine-debug too? [n]: y Please specify an IP protocol: tcp Please specify a client IP address: 192.168.10.52 Please specify a client port: Please specify a server IP address: 192.168.11.50 Please specify a server port: Monitoring packet tracer and firewall debug messages 192.168.10.52-58958 - 192.168.11.50-80 6 AS 1-1 CID 0 Packet: TCP, SYN, seq 3232128039 192.168.10.52-58958 - 192.168.11.50-80 6 AS 1-1 CID 0 Session: new snort session 192.168.10.52-58958 - 192.168.11.50-80 6 AS 1-1 CID 0 AppID: service unknown (0), application unknown (0) 192.168.10.52-58958 > 192.168.11.50-80 6 AS 1-1 I 24 new firewall session 192.168.10.52-58958 > 192.168.11.50-80 6 AS 1-1 I 24 Starting AC with minimum 2, 'Inter-Block-Rule1', and IPProto first with zones -1 -> -1, geo 0 -> 0, vlan 0, source sgt type: 0, source sgt tag: 0, ISE sgt id: 0, dest sgt type: 0, ISE dest sgt tag: 0, svc 0, payload 0, client 0, misc 0, user 9999997, icmpType 0, icmpCode 0 192.168.10.52-58958 > 192.168.11.50-80 6 AS 1-1 I 24 match rule order 2, 'Inter-Block-Rule1', action Interactive Reset 192.168.10.52-58958 > 192.168.11.50-80 6 AS 1-1 I 24 MidRecovery data sent for rule id: 268438864,rule_action:8, rev id:1099034206, rule_match flag:0x0 192.168.10.52-58958 > 192.168.11.50-80 6 AS 1-1 I 24 HitCount data sent for rule id: 268438864, 192.168.10.52-58958 - 192.168.11.50-80 6 AS 1-1 CID 0 Snort id 24, NAP id 1, IPS id 0, Verdict PASS 192.168.11.50-80 - 192.168.10.52-58958 6 AS 1-1 CID 0 Packet: TCP, SYN, ACK, seq 2228213518, ack 3232128040 192.168.11.50-80 - 192.168.10.52-58958 6 AS 1-1 CID 0 AppID: service unknown (0), application unknown (0) 192.168.11.50-80 - 192.168.10.52-58958 6 AS 1-1 CID 0 Snort id 24, NAP id 1, IPS id 0, Verdict PASS 192.168.10.52-58958 - 192.168.11.50-80 6 AS 1-1 CID 0 Packet: TCP, ACK, seq 3232128040, ack 2228213519 192.168.10.52-58958 - 192.168.11.50-80 6 AS 1-1 CID 0 AppID: service unknown (0), application unknown (0) 192.168.10.52-58958 - 192.168.11.50-80 6 AS 1-1 CID 0 Snort id 24, NAP id 1, IPS id 0, Verdict PASS 192.168.10.52-58958 - 192.168.11.50-80 6 AS 1-1 CID 0 Packet: TCP, ACK, seq 3232128040, ack 2228213519 192.168.10.52-58958 - 192.168.11.50-80 6 AS 1-1 CID 0 AppID: service HTTP (676), application unknown (0) 192.168.10.52-58958 > 192.168.11.50-80 6 AS 1-1 I 24 Starting AC with minimum 2, 'Inter-Block-Rule1', and IPProto first with zones -1 -> -1, geo 0(0) -> 0, vlan 0, source sgt type: 0, sgt tag: 0, ISE sgt id: 0, dest sgt type: 0, ISE dest_sgt_tag: 0, svc 676, payload 0, client 589, misc 0, user 9999997, min url-cat-list 0-0-0, url http://192.168.11.50/, xff 192.168.10.52-58958 > 192.168.11.50-80 6 AS 1-1 I 24 match rule order 2, 'Inter-Block-Rule1', action Interactive Reset 192.168.10.52-58958 > 192.168.11.50-80 6 AS 1-1 I 24 bypass action sending HTTP interactive response of 1093 bytes 192.168.10.52-58958 - 192.168.11.50-80 6 AS 1-1 CID 0 Firewall: interactive block rule, 'Inter-Block-Rule1', drop 192.168.10.52-58958 - 192.168.11.50-80 6 AS 1-1 CID 0 Snort: processed decoder alerts or actions queue, drop 192.168.10.52-58958 > 192.168.11.50-80 6 AS 1-1 I 24 deleting firewall session flags = 0x800, fwFlags = 0x1002 192.168.10.52-58958 - 192.168.11.50-80 6 AS 1-1 CID 0 Snort id 24, NAP id 1, IPS id 0, Verdict BLACKLIST 192.168.10.52-58958 - 192.168.11.50-80 6 AS 1-1 CID 0 ===> Blocked by Firewall Verdict reason is sent to DAQ
À ce stade, la page de blocage est affichée à l'utilisateur final. Si l'utilisateur sélectionne Continue (ou actualise la page web) la même règle que celle qui autorise cette fois le trafic :
192.168.10.52-58962 - 192.168.11.50-80 6 AS 1-1 CID 0 Packet: TCP, ACK, seq 1593478294, ack 3135589307 192.168.10.52-58962 - 192.168.11.50-80 6 AS 1-1 CID 0 AppID: service HTTP (676), application unknown (0) 192.168.10.52-58962 > 192.168.11.50-80 6 AS 1-1 I 14 Starting AC with minimum 2, 'Inter-Block-Rule1', and IPProto first with zones -1 -> -1, geo 0(0) -> 0, vlan 0, source sgt type: 0, sgt tag: 0, ISE sgt id: 0, dest sgt type: 0, ISE dest_sgt_tag: 0, svc 676, payload 0, client 589, misc 0, user 9999997, min url-cat-list 0-0-0, url http://192.168.11.50/, xff 192.168.10.52-58962 > 192.168.11.50-80 6 AS 1-1 I 14 match rule order 2, 'Inter-Block-Rule1', action Interactive Reset 192.168.10.52-58962 > 192.168.11.50-80 6 AS 1-1 I 14 bypass action interactive bypass 192.168.10.52-58962 > 192.168.11.50-80 6 AS 1-1 I 14 allow action 192.168.10.52-58962 - 192.168.11.50-80 6 AS 1-1 CID 0 Firewall: allow rule, 'Inter-Block-Rule1', allow 192.168.10.52-58962 - 192.168.11.50-80 6 AS 1-1 CID 0 Firewall: interactive bypass rule, 'Inter-Block-Rule1', allow 192.168.10.52-58962 - 192.168.11.50-80 6 AS 1-1 CID 0 Snort id 14, NAP id 1, IPS id 0, Verdict PASS 192.168.11.50-80 - 192.168.10.52-58962 6 AS 1-1 CID 0 Packet: TCP, ACK, seq 3135589307, ack 1593478786 192.168.11.50-80 - 192.168.10.52-58962 6 AS 1-1 CID 0 AppID: service HTTP (676), application unknown (0) 192.168.11.50-80 - 192.168.10.52-58962 6 AS 1-1 CID 0 Firewall: allow rule, 'Inter-Block-Rule1', allow 192.168.11.50-80 - 192.168.10.52-58962 6 AS 1-1 CID 0 Firewall: interactive bypass rule, 'Inter-Block-Rule1', allow 192.168.11.50-80 - 192.168.10.52-58962 6 AS 1-1 CID 0 Snort id 14, NAP id 1, IPS id 0, Verdict PASS
Interactive Block (blocage interactif) avec règle de réinitialisation envoie un message de réinitialisation du protocole TCP au trafic non Web :
firepower# show cap CAPI | i 11.50 2: 22:13:33.112954 802.1Q vlan#202 P0 192.168.10.50.40010 > 192.168.11.50.21: S 3109534920:3109534920(0) win 29200 <mss 1460,sackOK,timestamp 3745225378 0,nop,wscale 7> 3: 22:13:33.113626 802.1Q vlan#202 P0 192.168.11.50.21 > 192.168.10.50.40010: S 3422362500:3422362500(0) ack 3109534921 win 8192 <mss 1380,nop,wscale 8,sackOK,timestamp 53252448 3745225378> 4: 22:13:33.113824 802.1Q vlan#202 P0 192.168.10.50.40010 > 192.168.11.50.21: . ack 3422362501 win 229 <nop,nop,timestamp 3745225379 53252448> 5: 22:13:33.114953 802.1Q vlan#202 P0 192.168.11.50.21 > 192.168.10.50.40010: P 3422362501:3422362543(42) ack 3109534921 win 256 <nop,nop,timestamp 53252448 3745225379> 6: 22:13:33.114984 802.1Q vlan#202 P0 192.168.11.50.21 > 192.168.10.50.40010: P 3422362543:3422362549(6) ack 3109534921 win 256 <nop,nop,timestamp 53252448 3745225379> 7: 22:13:33.114984 802.1Q vlan#202 P0 192.168.11.50.21 > 192.168.10.50.40010: P 3422362549:3422362570(21) ack 3109534921 win 256 <nop,nop,timestamp 53252448 3745225379> 8: 22:13:33.115182 802.1Q vlan#202 P0 192.168.10.50.40010 > 192.168.11.50.21: . ack 3422362543 win 229 <nop,nop,timestamp 3745225381 53252448> 9: 22:13:33.115411 802.1Q vlan#202 P0 192.168.10.50.40010 > 192.168.11.50.21: . ack 3422362549 win 229 <nop,nop,timestamp 3745225381 53252448> 10: 22:13:33.115426 802.1Q vlan#202 P0 192.168.10.50.40010 > 192.168.11.50.21: . ack 3422362570 win 229 <nop,nop,timestamp 3745225381 53252448> 12: 22:13:34.803699 802.1Q vlan#202 P0 192.168.10.50.40010 > 192.168.11.50.21: P 3109534921:3109534931(10) ack 3422362570 win 229 <nop,nop,timestamp 3745227069 53252448> 13: 22:13:34.804523 802.1Q vlan#202 P0 192.168.11.50.21 > 192.168.10.50.40010: R 3422362570:3422362570(0) ack 3109534931 win 0
Connexions secondaires FTD et Trous D'Épingle
Dans les versions antérieures (par exemple 6.2.2, 6.2.3, etc.), le moteur Snort n'ouvre pas de trous d'épingle pour les connexions secondaires (par exemple FTD Data) si vous utilisez le Trust action. Dans les versions récentes, ce comportement est modifié et le moteur Snort ouvre des trous d'épingle même avec le Trust action.
Règles de Cisco Firepower Threat Defense (FTD)
- Utilisez les règles Prefilter Policy Fastpath (Fastpath pour la politique de préfiltre) pour les flux volumineux et pour réduire la latence à travers la boîte
- Utilisez les règles Prefilter Block (blocage du préfiltre) pour le trafic qui doit être bloqué en fonction des conditions L3/L4
- Utilisez les règles Trust (confiance) de la politique de contrôle d’accès si vous souhaitez contourner de nombreuses vérifications du renifleur, tout en profitant de fonctionnalités telles que la politique d’identité, la qualité du service, la fonction Security Intelligence, la détection d’applications et le filtre d’URL
- Placez les règles qui affectent moins les performances du pare-feu au sommet de la politique de contrôle d’accès avec l’utilisation de ces directives :
- Règles Block (blocage) (couches 1 à 4) – Blocage de préfiltre
- Règles Allow (autorisation) (couches 1 à 4) – Fastpath pour le préfiltre
- Règles Block (blocage) de la politique de contrôle d’accès (couches 1 à 4)
- Règles Trust (confiance) (couches 1 à 4)
- Règles Block (blocage) (couches 5 à 7 – détection des applications, filtrage des URL)
- Règles Allow (autorisation) (couches 1 à 7 – détection d’applications, filtrage d’URL, politique d’intrusion/politique de fichiers)
- Règle Block (blocage) (règle par défaut)
- Évitez les connexions excessives (connectez-vous au début ou à la fin et évitez les deux en même temps)
- Soyez conscient de l’extension des règles, pour vérifier le nombre de règles dans LINA
firepower# show access-list | include elements access-list CSM_FW_ACL_; 7 elements; name hash: 0x4a69e3f3
Résumé
Actions du préfiltre
Actions de la politique de contrôle d’accès
Informations connexes
- Règles de contrôle d’accès de Cisco FTD
- Préfiltres et politiques de préfiltre de Cisco FTD
- Analysez les captures de pare-feu Firepower pour résoudre efficacement les problèmes de réseau
- Utilisation des captures Cisco Firepower Threat Defense (FTD) et du traceur de paquet
- Configurez la connexion sur Cisco FTD à l’aide de Cisco FMC
- Support et documentation techniques - Cisco Systems
- Déchargement de connexions importantes
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
2.0 |
29-Sep-2022 |
Mise à jour pour la traduction automatique, exigences de style, géronds, SEO, langage biaisé et grammaire. |
1.0 |
19-Oct-2017 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)