Survol de la prévention des intrusions

Le moteur d’inspection Snort fait partie intégrale de Firewall Threat Defense. Dans la plupart des cas, les politiques fournies par le système sont tout ce dont vous avez besoin. Pour les utilisateurs avancés ayant des besoins spécifiques, vous pouvez créer des règles personnalisées.


Remarque

Pour configurer des règles Snort 2 personnalisées, voir Politiques de prévention des intrusions personnalisées pour Snort 2.

Prévention contre les intrusions

Les politiques d'analyse de réseau et de prévention des intrusions fonctionnent ensemble dans le cadre de la fonction de détection et de prévention des intrusions.

  • L’expression « détection des intrusions » fait généralement référence au processus de surveillance et d’analyse passives du trafic réseau à la recherche des intrusions potentielles et de stockage des données d’attaque pour l’analyse de la sécurité. Il est parfois appelé « système de détection d’intrusion (IDS) ».

  • Le terme « prévention des intrusions » comprend le concept de détection des intrusions, mais ajoute la possibilité de bloquer ou de modifier le trafic malveillant lorsqu’il traverse votre réseau. Il est parfois appelé « système de prévention des intrusions (IPS) ».

  • utilise des politiques d’analyse de réseau et de prévention des intrusions pour fournir une inspection complète des paquets et une protection contre les menaces.

Composants et fonctionnement de la prévention des intrusions

Dans un déploiement de prévention des intrusions, lorsque le système examine les paquets :

  • Une politique d’analyse de réseau régit la façon dont le trafic est décodé et prétraité afin qu'il puisse être évalué de manière plus approfondie, en particulier pour détecter un trafic anormal qui pourrait signaler une tentative d'intrusion.

  • Une politique de prévention des intrusions utilise des règles d’intrusion et de préprocesseur (parfois appelées collectivement règles de prévention des intrusions) pour examiner les paquets décodés à la recherche d’attaques basées sur des modèles. Les politiques de prévention des intrusions sont associées à des ensembles de variables, ce qui vous permet d’utiliser des valeurs nommées pour refléter avec précision votre environnement réseau.

Les politiques d’analyse de réseau et de prévention des intrusions sont toutes deux appelées par une politique de contrôle d’accès parente, mais à des moments différents. Pendant que le système analyse le trafic, la phase d’analyse de réseau (décodage et prétraitement) se produit avant et séparément de la phase de prévention des intrusions (prétraitement et règles de prévention des intrusions supplémentaires). Ensemble, les politiques d’analyse de réseau et de prévention des intrusions permettent une inspection large et approfondie des paquets. Elles peuvent vous aider à détecter le trafic réseau, à vous alerter et à vous protéger contre le trafic réseau qui pourrait menacer la disponibilité, l’intégrité et la confidentialité des hôtes et de leurs données.

Le système est livré avec plusieurs politiques d’analyse de réseau et de prévention des intrusions du même nom (par exemple, Sécurité et connectivité équilibrées) qui se complètent et fonctionnent ensemble. En utilisant des politiques fournies par le système, vous pouvez profiter de l’expérience de Cisco Talos Intelligence Group (Talos). Pour ces politiques, Talos définit les états des règles de prévention des intrusions et des inspecteurs, et fournit les configurations initiales pour les inspecteurs et d’autres paramètres avancés.

Vous pouvez également créer des politiques personnalisées d'analyse de réseau et de prévention des intrusions. Vous pouvez ajuster les paramètres des politiques personnalisées pour inspecter le trafic de la manière qui vous semble la plus importante, afin d'améliorer à la fois les performances de vos périphériques gérés et votre capacité à répondre efficacement aux événements qu'ils génèrent.

Vous créez, modifiez, enregistrez et gérez les politiques d’analyse de réseau et de prévention des intrusions à l’aide d’éditeurs de politiques similaires dans l’interface Web. Lorsque vous modifiez l'un ou l'autre de ces types de politique, un panneau de navigation s'affiche sur le côté gauche de l'interface Web; le côté droit affiche diverses pages de configuration.

Reportez-vous aux vidéos pour obtenir de l’aide et des renseignements supplémentaires :


Attention

Obsolescence du mode de détection : à partir de la version 7.4.0 du centre de gestion, pour une politique d’analyse de réseau (NAP), le mode d’inspection de détection est obsolète et sera supprimé dans une prochaine version.

Le mode de détection était destiné à être utilisé comme mode de test afin que vous puissiez activer les inspections et voir comment elles se comportent dans votre réseau avant de le configurer pour abandonner le trafic, c’est-à-dire pour afficher le trafic qui serait abandonné.

Ce comportement est amélioré lorsque tous les abandons de l’inspecteur sont contrôlés par l’état de la règle et que vous pouvez définir chacun d’eux pour générer des événements. Ceci est fait pour les tester avant de configurer l’état de la règle pour abandonner le trafic. Comme nous avons maintenant un contrôle fin des pertes de trafic dans Snort 3, le mode de détection ne fait qu’ajouter plus de complexité au produit et n’est pas nécessaire, le mode de détection est donc obsolète.

Si vous modifiez une Politique d’analyse de réseau (NAP) de détection à Prévention, la Politique d’analyse de réseau (NAP) qui traite le trafic des incidents d’intrusion qui « sera abandonnée » est « abandonnée », et le trafic correspondant abandonnera le trafic de ces événements. Cela s’applique aux règles dont les GID ne sont pas 1 ou 3. Les GID 1 et 3 sont des règles de texte ou compilées (généralement fournies par Talos ou à partir de vos règles personnalisées ou importées), et tous les autres GID sont des inspections pour détecter des anomalies. Il s'agit de règles moins courantes à déclencher dans un réseau. Il est peu probable que le passage en mode de prévention ait un impact sur le trafic. Il vous suffit de désactiver la règle de prévention des intrusions qui s’applique au trafic abandonné et de la régler sur généré ou désactivé.

Nous vous recommandons de choisir Prévention comme mode d'inspection, mais si vous choisissez Prévention, vous ne pouvez pas revenir au mode Détection.

Moteur d’inspection Snort

Un moteur d’inspection Snort est un composant intégré d’analyse du trafic qui

  • analyse le trafic en temps réel pour fournir une inspection approfondie des paquets,

  • fonctionne dans le cadre du périphérique Cisco Secure Firewall Threat Defense (anciennement Firepower Threat Defense), et

  • active les politiques d’analyse de réseau et de prévention des intrusions pour détecter les intrusions et les protéger.

Snort 3

Snort 3 est un moteur d’inspection de réseau qui

  • fournit de vastes améliorations par rapport à la version précédente de Snort,

  • offre un fonctionnement plus efficace avec de meilleures performances et une plus grande évolutivité, et

  • dont l’architecture a été repensée pour inspecter plus de trafic avec des ressources équivalentes par rapport à Snort 2.

Modifications et améliorations de Snort 3

L’ancienne version de Snort est Snort 2, qui n’est plus prise en charge. Snort 3 permet une insertion simplifiée et flexible des analyseurs de trafic. Snort 3 fournit également une nouvelle syntaxe de règles qui facilite l’écriture de règles et rend visibles les équivalents des règles d’objets partagés.

Les autres changements importants concernant Snort 3 sont les suivants :

  • Contrairement à Snort 2, qui utilise plusieurs instances de Snort, Snort 3 associe plusieurs threads à une seule instance de Snort. Cela utilise moins de mémoire, améliore les temps de rechargement Snort, prend en charge un plus grand nombre de règles de prévention des intrusions ainsi qu’une cartographie du réseau plus vaste. Le nombre de threads Snort varie selon la plateforme et est identique au nombre d’instances de Snort 2 pour chaque plateforme. L’utilisation est pratiquement transparente.

  • Version Snort par Firewall Threat Defense : le moteur d’inspection Snort est spécifique à Firewall Threat Defense et non au Cisco Secure Firewall Management Center (anciennement le centre de gestion Cisco Firepower Management Center). Firewall Management Center peut gérer plusieurs Firewall Threat Defense, chacun avec l’une ou l’autre des versions de Snort (Snort 2 et Snort 3). Bien que les politiques de prévention des intrusions de Firewall Management Centersoient uniques, le système applique la version Snort 2 ou Snort 3 d’une politique de prévention des intrusions pour la protection contre les intrusions en fonction du moteur d’inspection sélectionné du périphérique.

  • Règles de décodeur : les règles de décodeur de paquets se déclenchent uniquement dans la politique de prévention des intrusions par défaut. Le système ignore les règles de décodeur que vous activez dans d’autres politiques.

  • Règles d’objet partagé : Snort 3 prend en charge certaines des règles de prévention des intrusions d’objet partagé (SO), mais pas toutes (règles avec un ID de générateur (GID) égal à 3). Les règles d’objet partagé activées qui ne sont pas prises en charge ne se déclenchent pas.

  • Inspection multicouche pour les renseignements sur la sécurité – Snort 3 détecte l’adresse IP la plus à l’intérieur, quelle que soit la couche.

  • Prise en charge des plateformes—Snort 3 nécessite Firewall Threat Defense la version 7.0 ou ultérieure. Elle n’est pas prise en charge par ASA FirePOWER ou NGIPSv.

  • Périphériques gérés—Un Firewall Management Center avec la version 7.0 peut prendre en charge simultanément les versions 6.4, 6.5, 6.6, 6.7 et 7.0 de Snort 2 Firewall Threat Defenses, et la version 7.0 de Snort 3 Firewall Threat Defenses.

  • Interruption de trafic lors du changement de version Snort : le changement de version Snort interrompt l’inspection du trafic et quelques paquets peuvent être abandonnés pendant le déploiement.

  • Politiques unifiées : quelle que soit la version du moteur Snort sous-jacent qui est activée dans les Firewall Threat Defense gérés, les politiques de contrôle d’accès, les politiques de prévention des intrusions et les politiques d’analyse de réseau configurées dans les Firewall Management Center fonctionnent de manière transparente lors de l’application des politiques. Toutes les politiques de prévention des intrusions dans les versions 7.0 et ultérieures de Firewall Management Center comportent deux versions, la version Snort 2 et la version Snort 3. La politique de prévention des intrusions est unifiée, ce qui signifie qu’elle a un nom, une politique de base et un mode d’inspection communs, bien qu’il existe deux versions de la politique (version Snort 2 et version Snort 3). Les versions Snort 2 et Snort 3 de la politique de prévention des intrusions peuvent être différentes en termes de paramètres de règles. Cependant, lorsque la politique de prévention des intrusions est appliquée à un périphérique, le système identifie automatiquement la version Snort activée sur le périphérique et applique les paramètres de règle configurés pour cette version.

  • Lightweight Security Package (LSP) (Paquet de sécurité léger) : remplace les mises à jour des règles Snort (SRU) par les mises à jour des règles de prévention des intrusions et de configuration de nouvelle génération de Snort 3. Le téléchargement de mises à jour télécharge à la fois le LSP Snort 3 et la SRU Snort 2.

    Les mises à jour LSP fournissent des règles de prévention des intrusions et des règles d'inspecteurs nouvelles et mises à jour, des états modifiés pour les règles existantes et des paramètres de politique de prévention des intrusions par défaut modifiés pour Firewall Management Center et Firewall Threat Defense version 7.0 ou supérieure. Lorsque vous mettez à niveau un Firewall Management Center de la version 6.7 ou antérieure à la version 7.0, il prend en charge les LSP et les SRU. Les mises à jour de règles peuvent également supprimer des règles, fournir de nouvelles catégories de règles et variables par défaut, et modifier les valeurs des variables par défaut. Pour en savoir plus sur les mises à jour des LSP, consultez la rubrique Mettre à jour les règles de prévention des intrusions dans la dernière version du Guide de configuration du centre de gestion Cisco Firepower Management Center.

  • Mappage des règles et des présélections Snort 2 et Snort 3 : les règles Snort 2 et Snort 3 sont mappées et le mappage est fourni par le système. Cependant, il ne s’agit pas d’un mappage un à un. Les politiques de base en matière de prévention des intrusions fournies par le système sont préconfigurées pour Snort 2 et Snort 3 et fournissent la même prévention des intrusions, bien qu’avec des ensembles de règles différents. Les politiques de base fournies par le système pour Snort 2 et Snort 3 sont mappées entre elles pour les mêmes paramètres de prévention des intrusions.

  • Annulation des règles de remplacement Snort 2 et Snort 3 : lorsqu’un Firewall Threat Defense est mis à niveau vers la version 7.0, vous pouvez mettre à niveau la plateforme d’inspection de Firewall Threat Defense vers la version Snort 3. Firewall Management Center met en correspondance tous les remplacements dans les règles existantes de la version Snort 2 des politiques de prévention des intrusions avec les règles Snort 3 correspondantes en utilisant le mappage fourni par Talos. Cependant, si des remplacements supplémentaires sont effectués après la mise à niveau ou si vous avez installé un nouveau Firewall Threat Defense à la version 7.0, ils doivent être synchronisés manuellement.

  • Règles de prévention des intrusions personnalisées : vous pouvez créer des règles de prévention des intrusions personnalisées dans Snort 3. Vous pouvez également importer les règles de prévention des intrusions personnalisées qui existent pour Snort 2 dans Snort 3.

  • Groupes de règles : Firewall Management Center regroupe toutes les règles de Snort 3 en groupes de règles. Les groupes de règles sont des groupes logiques de règles qui fournissent une interface de gestion simple pour améliorer l’accessibilité des règles, la navigation dans les règles et un meilleur contrôle sur le niveau de sécurité des groupes de règles.

    À partir de Firewall Management Center 7.3.0, la navigation par les règles est prise en charge pour plusieurs niveaux de groupes de règles, ce qui offre plus de flexibilité et un ensemble logique des règles. Le cadre MITRE est ajouté et vous permet de naviguer dans les règles à l'aide du cadre MITRE. MITRE n’est qu’une autre catégorie de groupes de règles et fait partie des groupes de règles Talos.


    Remarque

    Consultez https://attack.mitre.org pour obtenir des renseignements sur MITRE.

    Une règle peut faire partie de plusieurs groupes de règles, p. ex., plusieurs groupes de règles MITRE ATT&CK, un groupe de règles de catégorie de règles, plusieurs groupes de règles de « type de ressource », une campagne contre des programmes malveillants, etc. Les groupes de règles disponibles sont répertoriés dans l’éditeur de politiques de prévention des intrusions et peuvent être sélectionnés pour améliorer les politiques.

    Grâce à cette structure hiérarchique à plusieurs niveaux, vous pouvez parcourir jusqu’au dernier élément, qui est le « groupe de règles descendant ». Ces groupes de règles contiennent des ensembles de règles liées les unes aux autres, comme un type de vulnérabilité spécifique, un système cible similaire ou une catégorie de menace similaire. Les groupes de règles sont associés à quatre niveaux de sécurité. Vous pouvez modifier le niveau de sécurité, ajouter ou supprimer des groupes de règles, et vous pouvez modifier l’action découlant d’une règle pour les règles qui correspondent au trafic observé sur le réseau. Cela est fait pour apporter un équilibre satisfaisant entre la sécurité, les performances et la résistance aux faux positifs.

Prise en charge de plusieurs processus Snort 3

Prise en charge de plusieurs processus Snort 3

  • Sur les périphériques Secure Firewall 6160 et 6170 exécutant la version 10.0 de Secure Firewall, par défaut, Snort 3 associe plusieurs threads à deux instances de Snort.

  • Lors du déploiement, chaque instance Snort 3 est automatiquement configurée avec les fils requis.

  • Il en résulte une charge de mémoire réduite, un conflit de verrouillage réduit et des temps de génération de cœur plus courts pour améliorer la résilience, les performances et l’évolutivité.

Architecture multiprocessus Snort 3

Les instances Snort 3 individuelles offrent plusieurs avantages. Toute défaillance d’instance Snort entraîne un impact minimal sur le trafic et vous pouvez également redémarrer un seul processus Snort, le cas échéant.

Les fils Snort sont distribués sur les nœuds NUMA où chaque nœud est considéré comme un processeur indépendant. Cela garantit que les limites de mémoire sont respectées. Par exemple, l’instance Snort 0 utilise la mémoire du nœud 0 et l’instance 1 utilise la mémoire du nœud 1.

Les sorties CLI de commandes telles que show coredump et show perfstats ont été améliorées pour afficher des informations sur les deux instances Snort. Dans le centre de gestion, accédez à Résolution de problèmes> Surveiller> Périphériques pour afficher les sections Aperçu> Processus critiques et Mémoire pour obtenir des renseignements sur les deux instances Snort. S’il y a des erreurs de profilage de règle, le numéro d’instance Snort s’affiche avec l’erreur.

Désactiver la prise en charge multiprocessus de Snort 3

Cette tâche désactive la prise en charge de plusieurs processus Snort 3.

La désactivation de la prise en charge de processus multiples est destinée à des fins de débogage uniquement et nécessite un déploiement manuel pour prendre effet.

Procédure

Étape 1

Utilisez la commande configure snort multi-process disable pour désactiver la prise en charge de plusieurs processus Snort 3.

Exemple:

> configure snort multi-process disable
-----------------------------------------------------------------------
Caution: this command is intended for debugging purposes only.
A deployment is required after enabling/disabling multi-process and will cause a Snort
restart and temporary traffic interruption.
-----------------------------------------------------------------------
Do you still want to continue?
Please enter 'YES' or 'NO': YES
Please perform a manual deployment to disable multi-process.

Remarque

Cette commande entraîne le redémarrage du moteur Snort et entraînera également une interruption du trafic lors du prochain déploiement, lorsque Snort passera de l’état multi-processus à un état de processus unique.

Étape 2

Redéployez la configuration pour vous assurer que la prise en charge multiprocessus de Snort 3 est désactivée.

Inspection multicouche

La fonctionnalité d’inspection multicouche dans Snort 3 vous permet d’inspecter le trafic sur plusieurs couches de protocole au cours d’une même session.

Snort 3 peut inspecter simultanément les couches suivantes :

  • Couche réseau (L3) : adresses IP, fragmentation

  • Couche de transport (L4) : ports TCP ou UDP, indicateurs, suivi de session

  • Couche d’application (L7) : HTTP, DNS, SMTP, TLS, SIP et autres.

  • Couche des fichiers et de charge utile : extraction des fichiers, signatures des programmes malveillants, contenu intégré

Snort 3 prend en charge le décodage pour un large éventail de protocoles. Il inspecte les protocoles encapsulés et évalue les en-têtes de paquets pour déterminer les actions des politiques lors de l’inspection avancée des menaces.

Inspection d’en-tête

Sur les versions antérieures à 7.6.4

Pour les protocoles d’encapsulation non pris en charge par Lina, le système fait correspondre initialement le trafic en fonction de l’en-tête IP externe. L’évaluation ultérieure dépend des critères de la règle :

  • Règles sans critères de couche 7 (L7) : si la règle en correspondance n’inclut pas de critères L7 (comme l’URL, l’ID d’application ou l’identité de l’utilisateur), le système applique la règle en fonction de l’en-tête IP externe.

  • Règles avec critères de couche 7 (L7) : si la règle comprend des critères L7, le système utilise la correspondance d’en-tête IP externe comme point de départ, puis effectue une évaluation supplémentaire à l’aide de l’en-tête le plus interne.

Ce comportement peut entraîner des résultats inattendus, comme une règle non L7 correspondant à l’en-tête de l’IP externe prenant le pas sur une règle correspondant à l’en-tête de l’IP interne situé plus bas dans l’ensemble de règles.

Sur la version 7.6.4 et les versions ultérieures

  • Snort 3 inspecte toujours l’en-tête le plus à l’intérieur pour détecter les protocoles non pris en charge par Lina, quelle que soit la présence de règles de couche 7.

  • Les règles basées sur l’en-tête externe ne sont pas suffisantes pour l’application des politiques pour des protocoles tels que VXLAN. Snort 3 ne tient pas compte des détails de la connexion pour l’action dans de tels cas, en utilisant plutôt le contenu réel du paquet.

  • Pour les protocoles pris en charge par Lina, l’action de la politique continue d’être basée sur l’en-tête le plus à l’intérieur.

  • Si vous gérez actuellement le trafic encapsulé pour des protocoles non pris en charge par Lina (comme VXLAN) en utilisant uniquement des règles d’IP externe, sachez que dans la version 7.6.4 ou une version ultérieure, ce trafic sera géré par la règle de contrôle d’accès par défaut. Dans un tel scénario, si votre action de politique par défaut est définie sur « Bloquer », cela peut entraîner l’abandon du trafic. Nous vous recommandons de passer en revue et de mettre à jour les politiques de contrôle d’accès pour qu’elles correspondent à l’en-tête IP interne pour ces protocoles, en plus de toute configuration d’en-tête IP externe existante.

Fonctionnalités de la couche 7

Pour le trafic encapsulé dans les fonctionnalités de couche 7, seul l’en-tête IP le plus à l’intérieur doit correspondre dans les règles. Les règles d’en-tête externe uniquement ne s’appliqueront pas.

Exemples de scénarios :

Le tableau suivant répertorie des exemples basés sur différents paramètres.

Protocole

Version

Règle IP externe

Règle IP interne

Règle L7 requise

Résultat

VXLAN (non pris en charge par LINA)

7.6.2

Oui

Non

Non

Trafic autorisé si l’en-tête externe correspond

VXLAN (non pris en charge par LINA)

7.6.4

Non

Oui

Non

Trafic autorisé si l’en-tête interne correspond

GRE (pris en charge par LINA)

7.6.2 et 7.6.4

Non

Oui

Non

Trafic autorisé si l’en-tête interne correspond

Fonctionnalité VXLAN + L7

7.6.2 et 7.6.4

Non

Oui

Oui

Règle d’en-tête interne requise

Remarque

Une règle d’IP externe fait correspondre le trafic en fonction des points d’extrémité du tunnel. Elle évalue :

  • L’adresse IP source du périphérique d’encapsulation

  • L’adresse IP de destination du périphérique d’encapsulation

Une règle d’IP interne fait correspondre le trafic en fonction du paquet IP d’origine dans le tunnel. Elle évalue :

  • L’adresse IP réelle du client

  • L’adresse IP réelle du serveur de destination

Limites de la couche d’encapsulation et comportement de l’inspection

Lors de la gestion du trafic encapsulé, il est important de comprendre les limites de traitement des deux principaux moteurs d’inspection du système, Lina et Snort.

  • LINA : prend en charge le décodage jusqu’à 2 couches d’encapsulation.

  • Snort : prend en charge le décodage jusqu’à 255 couches d’encapsulation (avec une limite par défaut de 40).

Protocoles pris en charge et capacités d’inspection de LINA et Snort 3

LINA

LINA prend en charge le décodage pour les protocoles suivants sur les couches de liaison de données (L2), de réseau (L3) et de transport (L4).

Couche

Protocoles et en-têtes pris en charge

couche 2

Cisco MetaData (CMD), IEEE 802.1Q, IEEE 802.1ad (DOT1AD) et Q-in-Q (EtherTypes 0x9100 et 0x9200). Prend en charge jusqu’à trois niveaux d’en-têtes de VLAN.

Couche 3

IPv4, IPv6

Couche 4

ICMP (v4/v6), ESP, VXLAN, Geneve, GRE, IP-en-IP et IPv6-en-IPv6. Prend en charge jusqu’à 1 niveau d’encapsulation.

Prise en charge spécifique de GRE

Pour le trafic GRE, le système prend en charge le décodage pour les types de protocoles suivants :

  • protocole PPTP (Point-to-Point Tunneling Protocol)

  • Protocole WCCP (Web Cache Communication Protocol)

Traitement ERSPAN

Le système décode GRE et ERSPAN (types 1, 2 et 3). Pour faciliter l’équilibrage de la charge de la couche de répartition, le système ignore en interne les en-têtes internes. Par conséquent, les autres modules ne peuvent pas inspecter les en-têtes ERSPAN.

Snort 3

Alors que Snort 3 prend en charge un vaste ensemble de protocoles, la liste suivante met en évidence les protocoles d’encapsulation et de tunnellisation courants pris en charge pour l’inspection :

  • VXLAN

  • GRE

  • Teredo

  • GTP

  • MPLS

  • Geneve

  • IP dans IP

    • IPv4-dans-IPv4

    • IPv6-dans-IPv4

    • IPv4-dans-IPv6

    • IPv6-dans-IPv6


Remarque

Cette liste n’est pas exhaustive. Snort 3 est conçu pour décoder un large éventail de protocoles standard de l’industrie.

Lignes directrices et limites relatives aux politiques d’analyse de réseau et de prévention des intrusions

Limites de la fonctionnalité Snort 3 pour Firewall Threat Defense géré par Firewall Management Center

Le tableau répertorie les fonctions prises en charge sur Snort 2 mais non sur Snort 3 pour les périphériques Firewall Management Center gérés Firewall Threat Defense.

Tableau 1. Limites des fonctionnalités de Snort 3

Politique/domaine

Fonctionnalités non prises en charge

Politique de contrôle d’accès

Les paramètres de l’application suivants :

  • Recherche sécuritaire

  • YouTube EDU

Politique de prévention des intrusions

  • Seuil de règle globale

  • Configuration de la journalisation :

    • SNMP

  • Mises à jour des règles SRU car Snort 3 prend uniquement en charge les mises à jour des règles LSP

Autres fonctionnalités

Nom de domaine complet (FQDN).

Conditions préalables pour l’analyse de réseau et les politiques de prévention des intrusions

Pour permettre au moteur d’inspection Snort de traiter le trafic pour l’analyse des intrusions et des programmes malveillants, la licence IPS doit être activée pour le périphérique Firewall Threat Defense.

Vous devez être un utilisateur administrateur pour gérer l’analyse de réseau et les politiques de prévention des intrusions et effectuer les tâches de migration.

Comment les politiques examinent le trafic à la recherche d’intrusions

Lorsque le système analyse le trafic dans le cadre de votre déploiement de contrôle d’accès, la phase d’analyse de réseau (décodage et prétraitement) se produit avant et séparément de la phase de prévention des intrusions (règles de prévention des intrusions et paramètres avancés).

Summary

Les composants clés concernés dans l’examen du trafic pour détecter les intrusions sont les suivants :

  • Security Intelligence : effectue le filtrage et le blocage initiaux du trafic

  • Politique SSL : gère l’inspection et le déchiffrement du trafic chiffré

  • Politiques d’analyse du réseau : effectuer le décodage et le prétraitement du trafic

  • Règles de contrôle d’accès : déterminez les politiques à appliquer au trafic

  • Politiques de prévention des intrusions : examiner le trafic pour détecter les menaces de sécurité et les intrusions

  • Politiques de fichiers : analyser les fichiers pour détecter les programmes malveillants et les menaces

  • Politique de découverte du réseau : inspecte passivement les paquets pour le mappage du réseau

Workflow


Diagramme du flux de trafic décrit ci-dessus, indiquant que le prétraitement par les politiques d’analyse de réseau a lieu après l’inspection SSL, mais avant que les règles de contrôle d’accès n’appellent les politiques de prévention des intrusions.

Ces étapes décrivent comment le système examine le trafic pour détecter les intrusions dans un déploiement en ligne :

  1. Le système traite le trafic à travers plusieurs couches de politique dans un ordre spécifique, les étapes d’analyse du réseau et de sélection de politique de prévention des intrusions étant mises en évidence dans le déploiement. Dans un déploiement en ligne (c’est-à-dire lorsque les configurations pertinentes sont déployées sur des périphériques utilisant des interfaces routées, commutées ou transparentes, ou des paires d’interfaces en ligne), le système peut bloquer le trafic sans autre inspection, à presque toutes les étapes du processus illustré. La solution Security Intelligence, la politique SSL, les politiques d’analyse de réseau, les politiques de fichiers et les politiques de prévention des intrusions peuvent toutes supprimer ou modifier le trafic. Seule la politique de découverte de réseau, qui inspecte passivement les paquets, ne peut pas affecter le flux de trafic.
  2. Á chaque étape du processus, un paquet peut entraîner la génération d’un incident par le système. Les intrusions et les événements de préprocesseur (parfois appelés collectivement incidents d'intrusion) sont des indications qu’un paquet ou son contenu peuvent présenter un risque pour la sécurité.

    Astuces

    Le diagramme ne reflète pas le fait que les règles de contrôle d'accès traitent le trafic chiffré lorsque votre configuration d'inspection SSL le laisse passer, ou si vous ne configurez pas l'inspection SSL. Par défaut, le système désactive la prévention des intrusions et l’inspection des fichiers des charges utiles chiffrées. Cela permet de réduire les faux positifs et d’améliorer les performances lorsqu’une connexion chiffrée correspond à une règle de contrôle d’accès qui a configuré l’inspection des intrusions et des fichiers.

  3. Notez que pour une connexion unique, bien que le système sélectionne une politique d'analyse de réseau avant une règle de contrôle d'accès comme le montre le diagramme, un certain prétraitement (notamment un prétraitement de la couche applicative) a lieu après la sélection de la règle de contrôle d'accès. Cela n’affecte pas la façon dont vous configurez le prétraitement dans les politiques d’analyse de réseau personnalisées.

Décodage, normalisation et prétraitement : politiques d’analyse de réseau

Sans décodage et prétraitement, le système ne pourrait pas évaluer correctement le trafic pour détecter les intrusions, car les différences de protocole rendraient impossible la mise en correspondance de modèles. Les politiques d’analyse de réseau régissent ces tâches de gestion du trafic :

  • une fois le trafic filtré par Security Intelligence

  • une fois le trafic chiffré déchiffré par une politique SSL facultative

  • avant que le trafic puisse être inspecté par des politiques de fichiers ou de prévention des intrusions

Une politique d’analyse de réseau régit le traitement des paquets par phases. Tout d’abord, le système décode les paquets qui passent par les trois premières couches TCP/IP, puis poursuit la normalisation, le prétraitement et la détection des anomalies de protocole :

  • Le décodeur de paquets convertit les en-têtes de paquets et les charges utiles dans un format qui peut être facilement utilisé par les inspecteurs et, ultérieurement, par les règles de prévention des intrusions. Chaque couche de la pile TCP/IP est décodée tour à tour, en commençant par la couche de liaison de données jusqu’aux couches de réseau et de transport. Le décodeur de paquets détecte également divers comportements anormaux dans les en-têtes de paquets.

  • Dans les déploiements en ligne, le préprocesseur de normalisation en ligne formate (normalise) le trafic pour minimiser les risques que les attaquants échappent à la détection. Il prépare les paquets pour l’examen par d’autres inspecteurs et prépare les règles de prévention des intrusions, et veille à ce que les paquets traités par le système soient les mêmes que les paquets reçus par les hôtes de votre réseau.

  • Divers inspecteurs des couches de réseau et de transport détectent les attaques qui exploitent la fragmentation IP, effectuent la validation de la somme de contrôle et le prétraitement de la session TCP et UDP.

    Notez que certains paramètres avancés de transport et de réseau de l’inspecteur s’appliquent globalement à tout le trafic géré par les périphériques cibles d’une politique de contrôle d’accès. Vous les configurez dans la politique de contrôle d’accès plutôt que dans une politique d’analyse de réseau.

  • Divers décodeurs de protocole de la couche d’application normalisent des types spécifiques de données de paquets dans des formats que le moteur de règles de prévention des intrusions peut analyser. La normalisation des codages de protocoles de la couche d’application permet au système d’appliquer efficacement les mêmes règles de prévention des intrusions liées au contenu aux paquets dont les données sont présentées différemment et d’obtenir des résultats significatifs.

  • Les inspecteurs Modbus, DNP3, CIP et SCADA s7commplus détectent les anomalies de trafic et fournissent des données aux règles de prévention des intrusions. Les protocoles de supervision, de contrôle et d’acquisition de données (SCADA) surveillent, contrôlent et acquièrent des données des processus industriels, des processus d’infrastructure et d’installation tels que la fabrication, la production, le traitement de l’eau, la distribution d’énergie électrique, les systèmes aéroportuaires et d’expédition.

  • Plusieurs inspecteurs vous permettent de détecter des menaces spécifiques, comme l’ouverture arrière, les analyses de ports, les inondations SYN et d’autres attaques basées sur le débit.

    Notez que vous configurez l’inspecteur de données sensibles, qui détecte les données sensibles telles que les numéros de carte de crédit et les numéros de sécurité sociale en texte ASCII, dans les politiques de prévention des intrusions.


Remarque

Lorsque l’identité du serveur TLS est désactivée, Snort 3 n’effectue pas de détection de non-concordance SNI. Il évalue uniquement le SNI dans le paquet Client Hello et contourne la validation du nom commun (CN) du certificat dans le paquet Server Hello.

Dans une politique de contrôle d’accès nouvellement créée, une politique d’analyse de réseau par défaut régit le prétraitement de tout le trafic pour toutes les politiques de prévention des intrusions appelées par la même politique parente de contrôle d’accès. Au départ, le système utilise la politique d’analyse de réseau Sécurité et connectivité équilibrées par défaut, mais vous pouvez la remplacer par une autre politique d’analyse de réseau fournie par le système ou personnalisée. Dans un déploiement plus complexe, les utilisateurs avancés peuvent adapter les options de prétraitement du trafic à des zones de sécurité, à des réseaux et à des VLAN spécifiques en attribuant différentes politiques d’analyse de réseau personnalisées pour prétraiter le trafic correspondant.


Remarque

Pour une stratégie de contrôle d’accès avec une action découlant d’une règle définie sur Trust et une règle de préfiltre avec une action définie sur Fastpath avec les options de journalisation désactivées, vous remarquerez que les incidents de fin de flux sont toujours générés dans le système. Les événements ne sont pas visibles sur les pages des événements du centre de gestion.

Règles de contrôle d’accès : sélection de la politique de prévention des intrusions

La sélection de la politique de prévention des intrusions est un processus d’évaluation du trafic qui :

  • évalue le trafic après le prétraitement initial

  • applique la règle de contrôle d’accès correspondante pour gérer le trafic par le biais des actions de supervision, de confiance, de blocage ou d’autorisation,

  • inspecte le trafic autorisé pour les données de découverte, les programmes malveillants, les fichiers interdits et les intrusions dans cet ordre, et

  • gère le trafic non correspondant à l’aide de l’action par défaut de la stratégie de contrôle d’accès.

Dans la plupart des cas, la première règle de contrôle d’accès à laquelle un paquet correspond est la règle qui gère ce trafic; vous pouvez surveiller, faire confiance, bloquer ou autoriser le trafic correspondant.

Processus d’évaluation du trafic

Lorsque vous autorisez le trafic avec une règle de contrôle d’accès, le système peut inspecter le trafic à la recherche de données de découverte, de programmes malveillants, de fichiers interdits et d'intrusions, dans cet ordre. Le trafic ne correspondant à aucune règle de contrôle d’accès est géré par l’action par défaut de la stratégie de contrôle d’accès, qui peut également inspecter les données de découverte et les intrusions.


Remarque

Tous les paquets, regardless (quelle que soit) la politique d’analyse de réseau qui les prétraite, correspondent aux règles de contrôle d’accès configurées, les rendant potentiellement sujets à une inspection par les politiques de prévention des intrusions, dans l’ordre descendant.

Le diagramme Comment les politiques examinent le trafic à la recherche d’intrusions montre le flux du trafic à travers un périphérique dans un déploiement en ligne de prévention des intrusions et AMP for Networks :

  • La règle de contrôle d’accès A permet au trafic correspondant de se poursuivre. La politique de découverte du réseau inspecte ensuite le trafic pour identifier des données de découverte, afin de détecter les fichiers interdits et les programmes malveillants par la politique A de fichiers, puis les intrusions sont repérées par la politique de prévention des intrusions A.

  • La règle de contrôle d’accès B permet également de mettre en correspondance le trafic. Cependant, dans ce scénario, le trafic n’est pas inspecté pour détecter les intrusions (ou les fichiers ou les programmes malveillants), donc aucune politique de prévention des intrusions ou de fichier n’est associée à la règle. Notez que par défaut, le trafic dont vous autorisez la poursuite est inspecté par la politique de découverte de réseau; vous n’avez pas besoin de configurer cela.

  • Dans ce scénario, l’action par défaut de la stratégie de contrôle d’accès autorise le trafic correspondant. Le trafic est ensuite inspecté par la politique de découverte de réseau, puis par une politique de prévention des intrusions. Vous pouvez (sans y être obligé) utiliser une politique de prévention des intrusions différente lorsque vous associez des politiques de prévention des intrusions aux règles de contrôle d’accès ou à l’action par défaut.

L’exemple du diagramme n’inclut aucune règle de blocage ou d’approbation, car le système n’inspecte pas le trafic bloqué ou de confiance.

Inspection d’intrusion : politiques, règles et ensembles de variables de prévention d’intrusion

L’inspection de prévention des intrusions est un mécanisme de sécurité qui

  • utilise des politiques d’intrusion pour régir la manière dont le système inspecte le trafic à la recherche de violations de la sécurité et, dans les déploiements en ligne, peut bloquer ou modifier le trafic malveillant.

  • emploie des règles de prévention des intrusions et de préprocesseur pour analyser le trafic réseau en fonction de critères spécifiés et détecter les tentatives d’exploit des vulnérabilités, et

  • utilise des ensembles de variables pour définir des valeurs couramment utilisées dans les règles d’intrusion pour identifier les adresses IP et les ports source et destination.

Règles de prévention des intrusions et de l’inspecteur

Une règle de prévention des intrusions est un ensemble précis de mots-clés et d’arguments qui détectent les tentatives d’exploitation des vulnérabilités de votre réseau. le système utilise une règle de prévention des intrusions pour analyser le trafic réseau et vérifier s’il correspond aux critères de la règle. Le système compare les paquets aux conditions spécifiées dans chaque règle et, si les données du paquet correspondent à toutes les conditions spécifiées dans une règle, la règle se déclenche.

Le système comprend les types de règles suivants, créées par Cisco Talos Intelligence Group (Talos) :

  • les règles de prévention des intrusions d’objets partagés, qui sont compilées et ne peuvent pas être modifiées (à l’exception des informations d’en-tête de règle telles que les ports source et de destination et les adresses IP)

  • les règles de prévention des intrusions en texte standard, qui peuvent être enregistrées et modifiées en tant que nouvelles instances personnalisées de la règle.

  • les règles de préprocesseur, qui sont des règles associées aux inspecteurs et aux options de détection des décodeurs de paquets dans la politique d’analyse de réseau. Vous ne pouvez pas copier ou modifier les règles de l’inspecteur. La plupart des règles de l’inspecteur sont désactivées par défaut; vous devez leur permettre d’utiliser les inspecteurs pour générer des événements et, dans un déploiement en ligne, abandonner les paquets fautifs.

Lorsque le système traite les paquets conformément à une politique de prévention des intrusions, un optimiseur de règles classe d’abord toutes les règles activées en sous-ensembles en fonction de critères tels que la couche de transport, le protocole d’application, la direction vers ou à partir du réseau protégé, etc. Ensuite, le moteur de règles de prévention des intrusions sélectionne les sous-ensembles de règles appropriés à appliquer à chaque paquet. Enfin, un moteur de recherche à règles multiples effectue trois types de recherches différents pour déterminer si le trafic correspond à la règle :

  • La recherche de champ de protocole recherche les correspondances dans des champs particuliers d’un protocole d’application.

  • La recherche de contenu générique recherche les correspondances d’octets ASCII ou binaires dans les données utiles du paquet.

  • La recherche d’anomalies de paquet recherche les en-têtes de paquet et les charges utiles qui, plutôt que de contenir un contenu spécifique, enfreignent des protocoles bien établis.

Dans une politique de prévention des intrusions personnalisée, vous pouvez ajuster la détection en activant et en désactivant les règles, ainsi qu’en écrivant et en ajoutant vos propres règles de texte standard. Vous pouvez également utiliser les recommandations de Cisco pour associer les systèmes d’exploitation, les serveurs et les protocoles d’applications clientes détectés sur votre réseau à des règles spécifiquement écrites pour protéger ces ressources.


Remarque

Lorsqu’il y a suffisamment de paquets pour traiter un trafic spécifique selon une règle de blocage, le système continue d’évaluer le trafic restant en fonction d’autres règles. Si du trafic restant correspond à une règle définie pour bloquer, la session est bloquée. Cependant, si le système analyse le trafic restant à transmettre, l’état du trafic indique en attente pour la règle qui est bloquée faute de paquets complets.

Ensembles de variables

Chaque fois que le système utilise une politique de prévention des intrusions pour évaluer le trafic, il utilise un ensemble de variables associé. La plupart des variables d'un ensemble représentent des valeurs couramment utilisées dans les règles d'intrusion pour identifier les adresses IP et les ports source et destination. Vous pouvez également utiliser des variables dans les politiques de prévention des intrusions pour représenter les adresses IP dans les états de suppressions de règles et de règles dynamiques.

Le système fournit un seul ensemble de variables par défaut, qui comprend des variables par défaut prédéfinies. La plupart des règles d’objet partagé et des règles de texte standard fournies par le système utilisent ces variables par défaut prédéfinies pour définir les réseaux et les numéros de port. Par exemple, la majorité des règles utilisent la variable $HOME_NET pour préciser le réseau protégé et la variable $EXTERNAL_NET pour préciser le réseau non protégé (ou externe). En outre, les règles spécialisées utilisent souvent d’autres variables prédéfinies. Par exemple, les règles qui détectent les exploits contre les serveurs Web utilisent les variables $HTTP_SERVERS et $HTTP_PORTS.


Astuces

Même si vous utilisez les politiques de prévention des intrusions fournies par le système, Cisco vous recommande fortement de modifier les variables clés par défaut de l’ensemble par défaut. Lorsque vous utilisez des variables qui reflètent avec précision votre environnement réseau, le traitement est optimisé et le système peut surveiller les systèmes concernés pour détecter toute activité suspecte. Les utilisateurs avancés peuvent créer et utiliser des ensembles de variables personnalisés pour les jumeler avec une ou plusieurs politiques de prévention des intrusions personnalisées.


Important

Si vous créez un ensemble de variables personnalisé, n’utilisez pas de chiffre comme premier caractère dans le nom d’un ensemble de variables personnalisées (par exemple, 3Snort). Cela entraînera l’échec de la validation du Snort 3 lorsque vous déployez une configuration sur le pare-feu Firewall Threat Defense sur Firewall Management Center.

Génération d’incidents de prévention des intrusions

La génération d’incidents d’intrusion est un mécanisme de sécurité qui :

  • détecte les intrusions possibles grâce au décodage des paquets, au prétraitement et à l’analyse du moteur de règles,

  • génère des incidents d’intrusion ou de préprocesseur (parfois appelés collectivement incidents d’intrusion) lorsque des menaces sont détectées, et

  • transmet les incidents des périphériques gérés à Firewall Management Center pour une analyse agrégée et une protection des ressources réseau.

Création d’incidents et collecte de données

Chaque incident d’intrusion dans la base de données comprend un en-tête d’incidents et contient des informations sur le nom et la classification de l’incident; les adresses IP de source et de destination; les ports; le processus qui a généré l’incident; et la date et l’heure de l’incident, ainsi que des informations contextuelles sur la source de l’attaque et sa cible. Pour les événements par paquets, le système enregistre également une copie de l’en-tête du paquet décodé et de la charge utile du ou des paquets qui ont déclenché l’événement.

Au fur et à mesure que la base de données accumule les incidents d'intrusion, vous pouvez commencer votre analyse des attaques potentielles. Le système vous fournit les outils dont vous avez besoin pour passer en revue les incidents d'intrusion et évaluer s’ils sont importants dans le contexte de votre environnement réseau et de vos politiques de sécurité.

Scénarios de génération d’incidents

Le décodeur de paquets, les préprocesseurs et le moteur de règles de prévention des intrusions peuvent tous forcer le système à générer un événement. Par exemple :

  • Si le décodeur de paquets (configuré dans la politique d’analyse de réseau) reçoit un paquet IP de moins de 20 octets, soit la taille d’un datagramme IP sans option ni charge utile, le décodeur interprète cela comme un trafic anormal. Si, ultérieurement, la règle de décodeur associée dans la politique de prévention des intrusions qui examine le paquet est activée, le système génère un événement d’inspection.

  • Si le préprocesseur de défragmentation IP rencontre une série de fragments IP qui se chevauchent, l’inspecteur interprète cela comme une attaque possible et, lorsque la règle d’inspecteur associée est activée, le système génère un événement d’inspecteur.

  • Dans le moteur de règles de prévention des intrusions, la plupart des règles de texte standard et des règles d’objets partagés sont écrites de manière à générer des incidents d'intrusion lorsqu’elles sont déclenchées par des paquets.

Politiques d’analyse de réseau et de prévention des intrusions fournies par le système et personnalisées

L’analyse du réseau et les politiques de prévention des intrusions sont des mécanismes de sécurité qui

  • examinent le trafic à travers les étapes de prétraitement et de prévention des intrusions,

  • fournissent des configurations par défaut fournies par le système pour un déploiement immédiat, et

  • permettent la création de politiques personnalisées pour les exigences de sécurité adaptées.

Comportement de la politique par défaut dans les déploiements de contrôle d’accès

Par défaut, une politique de contrôle d’accès nouvellement créée fait appel aux politiques d’analyse de réseau et de prévention des intrusions fournies par le système pour examiner le trafic.

Ce diagramme montre comment une nouvelle stratégie de contrôle d’accès dans un déploiement de prévention des intrusions en ligne gère initialement le trafic :


Diagramme illustrant comment une nouvelle politique de contrôle d’accès dans un déploiement de prévention des intrusions en ligne gère initialement le trafic. Dans l’ordre : renseignements sur la sécurité, prétraitement, action de contrôle d’accès par défaut, découverte de réseau et inspection de prévention des intrusions.

Le flux du trafic présente ces caractéristiques :

  • Une politique d’analyse de réseau par défaut régit le prétraitement de tout le trafic géré par la politique de contrôle d’accès. Au départ, la politique d'analyse du réseau de sécurité et de connectivité équilibrée fournie par le système est la politique par défaut.

  • L’action par défaut de la politique de contrôle d’accès autorise tout le trafic non malveillant, comme déterminé par la politique de prévention des intrusions, de sécurité et connectivité équilibrées fournie par le système. Comme l'action par défaut laisse passer le trafic, la fonction de découverte peut l'examiner à la recherche de données relatives à l'hôte, à l'application et à l'utilisateur avant que la politique de prévention des intrusions ne puisse examiner et éventuellement bloquer le trafic malveillant.

  • La politique utilise les options Security Intelligence par défaut (listes globales de blocage et Ne pas bloquer uniquement), ne déchiffre pas le trafic chiffré avec une politique SSL et n’effectue pas de traitement spécial ni d’inspection du trafic réseau à l’aide des règles de contrôle d’accès.

Une mesure simple à prendre pour optimiser le déploiement de la prévention des intrusions consiste à utiliser par défaut un ensemble différent de politiques d'analyse du réseau et de prévention des intrusions fournies par le système. Cisco fournit plusieurs paires de ces politiques avec le système.

Vous pouvez aussi adapter votre déploiement de prévention des intrusions en créant et en utilisant des politiques personnalisées. Vous constaterez peut-être que les options de l’inspecteur, la règle de prévention des intrusions et d’autres paramètres avancés configurés dans ces politiques ne répondent pas aux besoins de sécurité de votre réseau. En ajustant vos politiques d’analyse de réseau et de prévention des intrusions, vous pouvez configurer, à un niveau très fin, la façon dont le système traite et inspecte le trafic sur votre réseau pour détecter les intrusions.

Politiques d’analyse de réseau et de prévention des intrusions fournies par le système

Les politiques d’analyse de réseau et de prévention des intrusions fournies par le système sont des configurations de sécurité qui

  • tirent parti de l’expérience de Cisco Talos Intelligence Group (Talos) pour les états de règles de prévention des intrusions et d’inspection et les paramètres avancés,

  • fournissent des points de départ pour des politiques de défense bien réglées couvrant les configurations réseau courantes, et

  • reçoivent des mises à jour automatiques par le biais des versions du paquet de sécurité allégé (LSP) pour les nouvelles vulnérabilités.

Caractéristiques clés et utilisation

Aucune politique fournie par le système ne couvre tous les profils de réseau, toutes les combinaisons de trafic ou toutes les postures défensives. Chacune couvre des cas et des configurations réseau courants qui fournissent un point de départ pour une politique défensive bien réglée. Bien que vous puissiez utiliser les politiques fournies par le système telles quelles, Cisco vous recommande fortement de les utiliser comme base pour des politiques personnalisées que vous ajusterez en fonction de votre réseau.


Astuces

Même si vous utilisez les politiques d’analyse de réseau et de prévention des intrusions fournies par le système, vous devez configurer les variables de prévention des intrusions du système pour refléter avec précision votre environnement réseau. Modifiez au minimum les variables par défaut clés dans l’ensemble par défaut.

À mesure que de nouvelles vulnérabilités sont connues, Talos publie des mises à jour des règles de prévention des intrusions, également appelées Paquet léger de sécurité (LSP). Ces mises à jour de règles peuvent modifier toute analyse de réseau ou politique de prévention des intrusions fournie par le système, ainsi que des règles de prévention des intrusions et d’inspecteur nouvelles ou mises à jour, des états modifiés pour les règles existantes et des paramètres de politique par défaut modifiés. Les mises à jour de règles peuvent également supprimer des règles des politiques fournies par le système et fournir de nouvelles catégories de règles, ainsi que modifier l’ensemble de variables par défaut.

Si la mise à jour d’une règle affecte votre déploiement, l’interface Web marque comme obsolètes les politiques d’analyse de réseau et de prévention des intrusions affectées, ainsi que leurs politiques parentes de contrôle d’accès. Vous devez redéployer une politique mise à jour pour que ses modifications prennent effet.

Pour plus de commodité, vous pouvez configurer des mises à jour de règles pour qu’elles redéployent automatiquement les politiques de prévention des intrusions touchées, seules ou en combinaison avec les politiques de contrôle d’accès concernées. Cela vous permet de garder facilement et automatiquement votre déploiement à jour pour vous protéger contre les intrusions et les exploits découverts récemment.

Pour garantir la mise à jour des paramètres de prétraitement, vous devez redéployer les politiques de contrôle d’accès, ce qui déploie également tout SSL associé, ainsi que les politiques d’analyse de réseau et de fichiers différentes de celles en cours d’exécution, et peut également mettre à jour les valeurs par défaut pour le prétraitement avancé et les options de performance.

Cisco fournit les politiques d’analyse de réseau et de prévention des intrusions du système :

  • Politiques d’analyse de réseau et de prévention des intrusions de sécurité et de connectivité équilibrées : ces politiques sont conçues pour la vitesse et la détection. Utilisés ensemble, ils constituent un bon point de départ pour la plupart des organisations et des types de déploiement. Le système utilise les politiques et les paramètres de sécurité et de connectivité équilibrées par défaut dans la plupart des cas.

  • Politiques d’analyse de réseau et de prévention des intrusions pour la connectivité et la sécurité : ces politiques sont destinées aux entreprises où la connectivité (la possibilité d’accéder à toutes les ressources) prévaut sur la sécurité de l’infrastructure du réseau. La politique de prévention des intrusions active beaucoup moins de règles que celles activées dans la politique de sécurité avant la connectivité. Seules les règles les plus critiques qui bloquent le trafic sont activées.

  • Politiques d’analyse de réseau et de prévention des intrusions Security Over Connectivity (sécurité au-dessus de la connectivité) : ces politiques sont conçues pour les entreprises où la sécurité de l’infrastructure réseau prévaut sur la commodité de l’utilisateur. La politique de prévention des intrusions permet d'appliquer de nombreuses règles de prévention des anomalies du réseau qui peuvent alerter sur le trafic légitime ou l'interrompre.

  • Politiques d’analyse de réseau et de prévention des intrusions Détection maximale : ces politiques sont destinées aux organisations qui accordent à la sécurité de l'infrastructure du réseau une importance encore plus grande que celle accordée à la politique de sécurité sur la connectivité, avec un potentiel de répercussions opérationnelles encore plus important. Par exemple, la politique de prévention des intrusions active des règles dans un grand nombre de catégories de menaces, y compris les programmes malveillants, les trousses d’exploit, les vulnérabilités anciennes et courantes, et les exploits connus et répandus.

  • Politique de prévention des intrusions Aucune règle active : dans la politique de prévention des intrusions Aucune règle active, toutes les règles de prévention des intrusions et tous les paramètres avancés, à l’exception des seuils de règles de prévention des intrusions, sont désactivés. La présente politique fournit un point de départ si vous souhaitez créer votre propre politique de prévention des intrusions au lieu de la baser sur les règles activées dans l’une des autres politiques fournies par le système.


Remarque

Selon la politique de base sélectionnée, fournie par le système, les paramètres de la politique varient. Pour afficher les paramètres de la politique, cliquez sur l’icône Edit (Modifier) à côté de la politique, puis cliquez sur la liste déroulante Manage Base Policy (Gestion de la politique de base).

Avantages de l’analyse personnalisée du réseau et des politiques de prévention des intrusions

Les politiques d’analyse de réseau personnalisées et de prévention des intrusions sont des configurations de sécurité qui :

  • améliorent les performances du système dans votre environnement spécifique,

  • fournissent une vue axée sur le trafic malveillant et les violations des politiques qui se produisent sur votre réseau, et

  • permettent une configuration granulaire de la façon dont le système traite et inspecte le trafic réseau pour détecter les intrusions.

Structure de la politique personnalisée

Vous constaterez peut-être que les options de l’inspecteur, les règles de prévention des intrusions et d’autres paramètres avancés configurés dans les politiques d’analyse de réseau et de prévention des intrusions fournies par le système ne répondent pas entièrement aux besoins de sécurité de votre organisation.

Toutes les politiques personnalisées ont une politique de base, également appelée couche de base, qui définit les paramètres par défaut pour toutes les configurations de la politique. Une couche est un bloc de construction que vous pouvez utiliser pour gérer efficacement plusieurs politiques d’analyse de réseau ou de prévention des intrusions.

Dans la plupart des cas, vous fondez les politiques personnalisées sur les politiques fournies par le système, mais vous pouvez utiliser une autre politique personnalisée. Cependant, toutes les politiques personnalisées ont une politique fournie par le système comme base potentielle dans une chaîne de politiques. Étant donné que les mises à jour de règles peuvent modifier des politiques fournies par le système, l’importation d’une mise à jour de règle peut vous affecter même si vous utilisez une politique personnalisée comme base. Si la mise à jour d’une règle affecte votre déploiement, l’interface Web marque les politiques concernées comme obsolètes.

Avantages des politiques d’analyse de réseau personnalisées

Politiques d’analyse de réseau personnalisées :

  • permettre le prétraitement de réglage pour correspondre à des caractéristiques de trafic spécifiques et aux exigences de surveillance,

  • réduire le surdébit du traitement du système en désactivant les inspecteurs inutiles, et

  • permettre un prétraitement personnalisé pour différentes zones de sécurité, réseaux ou VLAN dans les déploiements complexes.

Par défaut, une politique d’analyse de réseau prétraite tout le trafic non chiffré géré par la politique de contrôle d’accès. Cela signifie que tous les paquets sont décodés et prétraités en fonction des mêmes paramètres, quelle que soit la politique de prévention des intrusions (et, par conséquent, l’ensemble de règles de prévention des intrusions) qui les examinera ultérieurement.

Au départ, la politique d’analyse de réseau Sécurité et connectivité équilibrées fournie par le système est la politique par défaut. Un moyen simple de régler le prétraitement consiste à créer et à utiliser une politique d’analyse de réseau personnalisée par défaut.

Les options de réglage disponibles varient d'un inspecteur à l'autre, mais il est possible de régler les inspecteurs et les décodeurs de plusieurs façons :

  • Vous pouvez désactiver les inspecteurs qui ne s’appliquent pas au trafic que vous surveillez. Par exemple, l’inspecteur HTTP Inspect normalise le trafic HTTP. Si vous êtes sûr que votre réseau n’inclut aucun serveur Web utilisant les services Internet Information Services (IIS de Microsoft), vous pouvez désactiver l’option de l’inspecteur qui recherche le trafic spécifique à IIS et ainsi réduire la surcharge de traitement du système.


    Remarque

    Si vous désactivez un inspecteur dans une politique d’analyse de réseau personnalisée, mais que le système doit utiliser cet inspecteur pour évaluer ultérieurement les paquets par rapport à une règle de prévention des intrusions ou à une règle d’inspecteur activée, le système active et utilise automatiquement l’inspecteur, bien que l’inspecteur reste désactivé dans la politique d’analyse de réseau interface Web.

  • Préciser les ports, le cas échéant, pour concentrer l’activité de certains inspecteurs. Par exemple, vous pouvez identifier des ports supplémentaires pour surveiller les réponses du serveur DNS, les sessions SSL chiffrées, ou des ports sur lesquels vous décodez le trafic Telnet, HTTP et RPC.

Si vous êtes un utilisateur avancé avec un déploiement complexe, vous pouvez créer plusieurs politiques d'analyse de réseau, chacune étant conçue pour prétraiter le trafic différemment. Ensuite, vous pouvez configurer le système pour utiliser ces politiques et régir le prétraitement du trafic en utilisant différentes zones de sécurité, réseaux ou VLAN. (Notez que les modules ASA FirePOWER ne peuvent pas restreindre le prétraitement par VLAN.)


Remarque

La personnalisation du prétraitement à l’aide de politiques d’analyse de réseau personnalisées, en particulier de plusieurs politiques d’analyse de réseau, est une tâche avancée. Le prétraitement et l’inspection de prévention des intrusions étant si étroitement liés, vous devez veiller à ne pas autoriser les politiques d’analyse de réseau et de prévention des intrusions examinant un seul paquet à se compléter.

Avantages des politiques de prévention des intrusions personnalisées

Les politiques de prévention des intrusions personnalisées sont des configurations de sécurité qui

  • permettent une inspection sur mesure du trafic au moyen de plusieurs politiques de prévention des intrusions spécialisées

  • gèrent les règles de prévention des intrusions et d’inspection qui sont activées et la manière dont elles sont configurées, et

  • permettent aux règles de contrôle d’accès de préciser quelle politique inspecte quel trafic en fonction de plusieurs critères.

Dans une nouvelle politique de contrôle d’accès configurée initialement pour effectuer la prévention des intrusions, l’action par défaut autorise tout le trafic, mais en l’inspectant d’abord à l’aide de la politique de prévention des intrusions de sécurité et de connectivité équilibrées fournie par le système. À moins que vous ajoutiez des règles de contrôle d’accès ou changiez l’action par défaut, tout le trafic est inspecté par cette politique de prévention des intrusions.

Pour personnaliser votre déploiement de prévention des intrusions, vous pouvez créer plusieurs politiques à cet effet, chacune étant conçue pour inspecter le trafic différemment. Configurez ensuite une politique de contrôle d’accès avec des règles qui précisent quelle politique inspecte quel trafic. Les règles de contrôle d’accès peuvent être simples ou complexes : les correspondances et l’inspection du trafic se font en fonction de plusieurs critères, notamment la zone de sécurité, l’emplacement réseau ou géographique, le VLAN, le port, l’application, l’URL demandée ou l’utilisateur.

La principale fonction des politiques de prévention des intrusions est de gérer les règles de prévention des intrusions et d'inspection qui sont activées et la manière dont elles sont configurées, comme suit :

  • Dans chaque politique de prévention des intrusions, vous devez vérifier que toutes les règles applicables à votre environnement sont activées et améliorer les performances en désactivant les règles qui ne sont pas applicables à ce dernier. Vous pouvez préciser les règles qui doivent abandonner ou modifier les paquets malveillants.

  • Les recommandations Cisco vous permettent d’associer les systèmes d’exploitation, les serveurs et les protocoles d’applications clientes détectés sur votre réseau à des règles spécifiquement écrites pour protéger ces ressources.

  • Vous pouvez modifier les règles existantes et écrire de nouvelles règles en texte standard au besoin pour détecter de nouveaux exploits ou appliquer vos politiques de sécurité.

Voici d’autres personnalisations que vous pourriez apporter à une politique de prévention des intrusions :

  • Le préprocesseur des données sensibles détecte les données sensibles telles que les numéros de cartes de crédit et les numéros de sécurité sociale dans le texte ASCII. Notez que d’autres inspecteurs qui détectent des menaces spécifiques (attaques par orifice arrière, plusieurs types de balayage de ports et attaques basées sur le débit qui tentent de submerger votre réseau avec un trafic excessif) sont configurés dans les politiques d’analyse de réseau.

  • Les seuils globaux obligent le système à générer des événements en fonction du nombre de fois que le trafic correspondant à une règle de prévention des intrusions provient d’une adresse ou d’une plage d’adresses spécifique au cours d’une période donnée ou est ciblé vers une adresse ou une plage d’adresses donnée. Cela permet d’éviter que le système ne soit submergé par un grand nombre d’événements.

  • La suppression des notifications d’incidents d’intrusion et la définition de seuils pour des règles individuelles ou des politiques complètes de prévention des intrusions peuvent également éviter que le système ne soit submergé par un grand nombre d’événements.

  • En plus des différents affichages des incidents d'intrusion dans l’interface Web, vous pouvez activer la journalisation dans les installations Syslog ou envoyer des données d’événements à un serveur de déroutement SNMP. Pour chaque politique, vous pouvez préciser les limites de notification d’incidents d’intrusion, configurer la notification d’incidents d’intrusion aux installations de journalisation externes et configurer les réponses externes aux incidents d’intrusion. Notez qu’en plus de ces configurations d’alertes par politique, vous pouvez activer ou désactiver globalement les alertes par courriel sur les incidents d'intrusion pour chaque règle ou groupe de règles. Les paramètres de vos alertes par courriel sont utilisés, quelles que soit la politique de prévention des intrusions qui traite un paquet.

Limites des politiques personnalisées

Le prétraitement et l’inspection de prévention des intrusions étant si étroitement liés, vous devez veiller à ce que votre configuration permette à l’analyse de réseau et à l’inspection de réseau, au traitement et à l’examen d’un seul paquet de se compléter.

Par défaut, le système utilise une politique d’analyse de réseau pour prétraiter tout le trafic géré par les périphériques gérés à l’aide d’une seule politique de contrôle d’accès. Ce diagramme montre comment une nouvelle stratégie de contrôle d’accès dans un déploiement de prévention des intrusions en ligne gère initialement le trafic. Les phases de prétraitement et de prévention des intrusions sont mises en surbrillance.


Diagramme illustrant comment une nouvelle politique de contrôle d’accès dans un déploiement de prévention des intrusions en ligne gère initialement le trafic. Dans l’ordre : renseignements sur la sécurité, prétraitement, action de contrôle d’accès par défaut, découverte de réseau et inspection de prévention des intrusions.

Remarquez comment une politique d’analyse de réseau par défaut régit le prétraitement de tout le trafic géré par la politique de contrôle d’accès. Au départ, la politique d’analyse de réseau Sécurité et connectivité équilibrées fournie par le système est la politique par défaut.

Vous pouvez régler le prétraitement en créant et en utilisant une politique d’analyse de réseau personnalisée comme politique par défaut. Toutefois, si vous désactivez un inspecteur dans une politique d’analyse de réseau personnalisée, mais que le système doit évaluer les paquets prétraités par rapport à une règle de prévention des intrusions ou d’inspecteur activée, le système active et utilise automatiquement l’inspecteur, même s’il reste désactivé dans l’interface Web de la politique d’analyse de réseau.


Remarque

Afin de profiter des avantages liés à la désactivation d’un inspecteur en matière de performances, vous devez vous assurer qu’aucune de vos politiques de prévention des intrusions ne comporte de règles activées nécessitant cet inspecteur.

Un défi supplémentaire survient si vous utilisez plusieurs politiques d’analyse de réseau personnalisées. Pour les utilisateurs avancés avec des déploiements complexes, vous pouvez adapter le prétraitement à des zones de sécurité, à des réseaux et à des VLAN spécifiques en attribuant des politiques d’analyse de réseau personnalisées pour prétraiter le trafic correspondant. (Notez qu’ASA FirePOWER ne peut pas restreindre le prétraitement par VLAN.) Pour ce faire, ajoutez des règles d’analyse de réseau personnalisées à votre politique de contrôle d’accès. Chaque règle est associée à une politique d’analyse de réseau qui régit le prétraitement du trafic correspondant à la règle.


Astuces

Vous configurez les règles d’analyse de réseau en tant que paramètre avancé dans une politique de contrôle d’accès. Contrairement à d’autres types de règles, les règles d’analyse de réseau font appel à des politiques d’analyse de réseau plutôt que d’être contenues par elles.

Le système fait correspondre les paquets à des règles d’analyse de réseau configurées en ordre descendant par numéro de règle. Le trafic qui ne correspond à aucune règle d’analyse de réseau est prétraité par la politique d’analyse de réseau par défaut. Bien que cela vous permette une grande souplesse dans le prétraitement du trafic, gardez à l’esprit que tous les paquets, quelle que soit la politique d’analyse de réseau qui les ont prétraités, sont par la suite mis en correspondance avec les règles de contrôle d’accès, et donc à l’inspection potentielle par les politiques de prévention des intrusions, dans leur propre processus. . En d’autres termes, le prétraitement d’un paquet avec une politique d’analyse de réseau particulière ne garantit pas que le paquet sera examiné avec une politique de prévention des intrusions particulière. Vous devez configurer avec soin votre politique de contrôle d’accès afin qu’elle fasse appel aux politiques d’analyse de réseau et de prévention des intrusions appropriées pour évaluer un paquet particulier.

Le diagramme suivant montre de manière très détaillée comment la phase de sélection de la politique d’analyse de réseau (prétraitement) se produit avant la phase de prévention des intrusions (règles) et séparément. Par souci de simplicité, le diagramme élimine les phases de découverte et d’inspection des fichiers et des programmes malveillants. Il met également en évidence les politiques d’analyse de réseau et d’action par défaut contre les intrusions par défaut.


Diagramme simplifié illustrant comment la phase de sélection de la politique d’analyse de réseau (prétraitement) se produit avant la phase de prévention des intrusions (règles) et séparément de celle-ci.

Dans ce scénario, une politique de contrôle d’accès est configurée avec deux règles d’analyse de réseau et une politique d’analyse de réseau par défaut :

  • La règle d’analyse de réseau A prétraite le trafic correspondant avec la politique d’analyse de réseau A. Vous souhaitez que ce trafic soit inspecté ultérieurement par la politique de prévention des intrusions A.

  • La règle d’analyse de réseau B prétraite le trafic correspondant avec la politique d’analyse de réseau B. Vous souhaitez que ce trafic soit inspecté ultérieurement par la politique de prévention des intrusions B.

  • Tout le trafic restant est prétraité avec la politique d’analyse de réseau par défaut. Plus tard, vous souhaitez que ce trafic soit inspecté par la politique de prévention des intrusions associée à l’action par défaut de la politique de contrôle d’accès.

Une fois que le système a prétraité le trafic, il peut examiner le trafic pour détecter des intrusions. Le diagramme montre une politique de contrôle d’accès avec deux règles de contrôle d’accès et une action par défaut :

  • La règle de contrôle d’accès A permet la mise en correspondance du trafic. Le trafic est ensuite inspecté par la politique de prévention des intrusions A.

  • La règle de contrôle d’accès B permet de mettre en correspondance le trafic. Le trafic est ensuite inspecté par la politique de prévention des intrusions B.

  • L’action par défaut de la politique de contrôle d’accès permet une mise en correspondance du trafic. Le trafic est ensuite inspecté par la politique de prévention des intrusions de l’action par défaut.

Le traitement de chaque paquet est régi par une paire de politiques d’analyse de réseau et de politiques de prévention des intrusions, mais le système ne coordonne pas la paire pour vous. Voici un scénario dans lequel vous configurez mal votre politique de contrôle d’accès de sorte que la règle d’analyse de réseau A et la règle de contrôle d’accès A ne traitent pas le même trafic. Par exemple, vous pouvez vouloir que les politiques jumelées régissent le traitement du trafic sur une zone de sécurité particulière, mais vous utilisez par erreur des zones différentes dans les conditions des deux règles. Cela pourrait entraîner un prétraitement incorrect du trafic. Pour cette raison, la personnalisation du prétraitement à l’aide de règles d’analyse de réseau et de politiques personnalisées est une tâche avancée.

Veuillez noter que pour une connexion unique, bien que le système sélectionne une politique d’analyse de réseau avant une règle de contrôle d’accès, un certain prétraitement (notamment le prétraitement de la couche d’application) a lieu après la sélection de la règle de contrôle d’accès. Cela n’affecte pas la façon dont vous configurez le prétraitement dans les politiques d’analyse de réseau personnalisées.