Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Cet article fait partie d'une série d'articles qui expliquent comment dépanner systématiquement le chemin de données sur les systèmes Firepower pour déterminer si les composants de Firepower peuvent affecter le trafic. Reportez-vous à l'article Présentation pour obtenir des informations sur l'architecture des plates-formes Firepower et des liens vers les autres articles de dépannage du chemin de données.
Cet article couvre la quatrième étape du dépannage du chemin de données Firepower, la politique de contrôle d'accès (ACP). Ces informations s'appliquent à toutes les plates-formes et versions de Firepower actuellement prises en charge.
En règle générale, déterminer quelle règle ACP un flux correspond devrait être assez simple. Les événements de connexion peuvent être examinés pour voir quelle règle/action est appliquée. Si cela ne montre pas clairement ce que le PVA fait avec le trafic, le débogage peut être effectué sur l'interface de ligne de commande de Firepower (CLI).
Après avoir obtenu une idée de l'interface d'entrée et de sortie, le trafic doit correspondre ainsi que les informations de flux, la première étape pour identifier si Firepower bloque le flux serait de vérifier les événements de connexion pour le trafic en question. Vous pouvez les afficher dans Firepower Management Center sous Analysis > Connections > Events.
Note: Avant de vérifier les événements de connexion, assurez-vous que la journalisation est activée dans vos règles ACP. La journalisation est configurée dans l'onglet « Journalisation » de chaque règle de stratégie de contrôle d'accès ainsi que dans l'onglet Security Intelligence. Assurez-vous que les règles suspectes sont configurées pour envoyer les journaux à l'« Observateur d'événements ». Cela s'applique également à l'action par défaut.
En cliquant sur « Edit Search » et filtré par une adresse IP source unique (Initiator), vous pouvez voir les flux qui ont été détectés par Firepower. La colonne Action indique « Autoriser » pour le trafic de cet hôte.
Si Firepower bloque intentionnellement le trafic, l'action contiendra le mot « Bloquer ». Cliquer sur « Affichage table des événements de connexion » fournit plus de données. Les champs suivants des événements de connexion peuvent être examinés si l'action est Bloquer :
- Motif
- Règle de contrôle d'accès
Afin d'atténuer rapidement un problème qui est supposé être causé par les règles ACP, il est possible d'effectuer les opérations suivantes :
Note: Ces mesures d'atténuation rapides nécessitent des changements de politiques qui peuvent ne pas être possibles dans tous les environnements. Il est recommandé d'essayer d'abord d'utiliser le suivi de la prise en charge du système pour déterminer quelle règle le trafic correspond avant d'apporter des modifications à la stratégie.
Un dépannage supplémentaire peut être effectué pour les opérations ACP via l'utilitaire CLI > de support du système firewall-engine-debug.
Note: Sur les plates-formes Firepower 9300 et 4100, le shell en question est accessible via les commandes suivantes :
# connexion du module 1 console
Firepower-module1> connect ftd
>
Pour les instances multiples, l'interface de ligne de commande du périphérique logique est accessible à l'aide des commandes suivantes.
# connect module 1 telnet
Firepower-module1> connect ftd ftd1
Connexion à la console du conteneur ftd(ftd1)... Entrez « exit » pour revenir à l'interface de ligne de commande de démarrage.
>
L'utilitaire de débogage du moteur de pare-feu de prise en charge du système comporte une entrée pour chaque paquet évalué par le PVA. Il indique le processus d'évaluation des règles en cours, ainsi que les raisons pour lesquelles une règle est mise en correspondance ou non.
Note: Dans les versions 6.2 et ultérieures, l'outil de suivi du support système peut être exécuté. Il utilise les mêmes paramètres mais inclut plus de détails. Assurez-vous d'entrer « y » lorsque vous y êtes invité avec "Enable firewall-engine-debug ? ».
Dans l'exemple ci-dessous, l'établissement d'une session SSH est évalué à l'aide de la prise en charge du système firewall-engine-debug.
Il s'agit de l'ACP exécuté sur le périphérique Firepower.
Le PVA a trois règles.
Dans le scénario de dépannage, une connexion SSH de 192.168.62.3 à 10.123.175.22 est analysée.
On s'attend à ce que la session corresponde à la règle AC 3 « trust server backup ». La question est : combien de paquets faut-il pour que cette session corresponde à cette règle ? Toutes les informations nécessaires dans le premier paquet pour déterminer la règle CA ou plusieurs paquets sont-elles requises, et si c’est le cas, combien ?
Dans l'interface de ligne de commande Firepower, les éléments suivants sont entrés pour voir quel est le processus d'évaluation des règles ACP.
> system support firewall-engine-debug
Please specify an IP protocol: tcp
Please specify a client IP address: 192.168.62.3
Please specify a client port:
Please specify a server IP address: 10.123.175.22
Please specify a server port: 22
Monitoring firewall engine debug messages
Astuce : Il est préférable de remplir autant de paramètres que possible lors de l'exécution de firewall-engine-debug, de sorte que seuls les messages de débogage intéressants sont imprimés à l'écran.
Dans la sortie de débogage ci-dessous, vous voyez les quatre premiers paquets de la session en cours d'évaluation.
SYN
SYN,ACK
ACK
Premier paquet SSH (client à serveur)
Voici un graphique illustrant la logique de débogage.
Pour ce flux, il faut 4 paquets pour que le périphérique corresponde à la règle.
Ceci est une explication détaillée de la sortie de débogage.
En résumé, la connexion prend 4 paquets pour correspondre à la session, car elle doit attendre que le pare-feu identifie l'application car la règle 2 contient une contrainte d'application.
Si la règle 2 n'avait que des réseaux sources et qu'il ne s'agissait pas de XFF, il aurait fallu 1 paquet pour que la session corresponde.
Vous devez toujours placer les règles des couches 1 à 4 au-dessus de toutes les autres règles de la stratégie lorsque cela est possible, car ces règles nécessitent généralement un paquet pour prendre une décision. Cependant, vous remarquerez peut-être que même avec les seules règles des couches 1 à 4, il peut y avoir plus d'un paquet correspondant à une règle CA, et la raison en est l'intelligence de sécurité URL/DNS. Si l'une ou l'autre de ces options est activée, le pare-feu doit déterminer l'application pour toutes les sessions évaluées par la stratégie AC, car il doit déterminer si elles sont HTTP ou DNS. Ensuite, il doit déterminer s'il doit autoriser la session en fonction des listes noires.
Ci-dessous se trouve une sortie tronquée de la commande firewall-engine-debug, dont les champs pertinents sont surlignés en rouge. Notez la commande utilisée pour obtenir le nom de l'application identifiée.
Dans certains scénarios, le trafic peut être bloqué malgré la correspondance d'une règle d'approbation dans le ACP. L'exemple ci-dessous évalue le trafic avec la même politique de contrôle d'accès et les mêmes hôtes.
Comme indiqué ci-dessus, la sortie firewall-engine-debug montre que le trafic correspond à un « Trust », alors que les événements de connexion montrent l'action de Block en raison d'une règle de stratégie d'intrusion (déterminée parce que la colonne Reason affiche Intrusion Block).
La raison pour laquelle cela peut se produire est due à la stratégie d'intrusion utilisée avant que la règle de contrôle d'accès ne soit déterminée Paramètre dans l'onglet Avancé du ACP. Avant que le trafic puisse être approuvé par l'action de règle, la stratégie d'intrusion en question identifie une correspondance de modèle et abandonne le trafic. Cependant, l'évaluation de la règle ACP aboutit à une correspondance de la règle Trust, puisque les adresses IP correspondaient aux critères de la règle « trust server backup ».
Pour que le trafic ne soit pas soumis à l'inspection de la politique d'intrusion, la règle de confiance peut être placée au-dessus de la règle d'« inspection », ce qui serait une pratique recommandée dans les deux cas. Étant donné que l'identification de l'application est nécessaire pour une correspondance et une non-correspondance de la règle « inspect », la stratégie d'intrusion utilisée avant que la règle de contrôle d'accès ne soit déterminée est utilisée pour le trafic qui est évalué par la même règle. En plaçant la règle de sauvegarde du serveur d'approbation au-dessus de la règle d'inspection, le trafic correspond à la règle lorsque le premier paquet est vu, car la règle est basée sur l'adresse IP, qui peut être déterminée dans le premier paquet. Par conséquent, la stratégie d'intrusion utilisée avant que la règle de contrôle d'accès ne soit déterminée n'a pas besoin d'être utilisée.
Dans ce scénario, les utilisateurs signalent que cnn.com est bloqué. Cependant, il n'y a pas de règle spécifique qui bloque CNN. Les événements de connexion, associés à la sortie firewall-engine-debug, indiquent la raison du blocage.
Tout d'abord, Connection Events dispose d'une zone d'informations à côté des champs d'application qui affiche des informations sur l'application ainsi que la manière dont Firepower classe ladite application.
Avec ces informations en tête, firewall-engine-debug est exécuté. Dans la sortie de débogage, le trafic est bloqué en fonction de la balise d'application.
Même s'il n'existe pas de règle qui bloque explicitement http://cnn.com, l'affichage des annonces balisées est bloqué dans l'onglet Applications d'une règle ACP.
Données | Instructions |
Dépannage du fichier à partir du périphérique Firepower inspectant le trafic | http://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html |
prise en charge du système firewall-engine-debug et system-support-trace output | Reportez-vous à cet article pour obtenir des instructions. |
Exportation de la stratégie de contrôle d'accès | Accédez à System > Tools > Import / Export, sélectionnez Access Control Policy et cliquez sur le bouton Export |
Attention : Si l'ACP contient une stratégie SSL, supprimez la stratégie SSL de l'ACP avant d'exporter pour éviter de divulguer des informations PKI sensibles
Si une stratégie SSL est en cours d'utilisation et que le dépannage de la stratégie de contrôle d'accès n'a pas révélé le problème, l'étape suivante consiste à dépanner la stratégie SSL.