Vous pouvez configurer des états de règles et d’autres paramètres pour les règles d’objets partagés, les règles de texte standard et les règles d’inspecteur.

Vous activez une règle en réglant son état à Alerte ou à Bloquer. L’activation d’une règle permet au système de générer des événements sur le trafic correspondant à la règle. La désactivation d’une règle arrête le traitement de la règle. Vous pouvez également définir votre politique de prévention des intrusions de sorte qu’un ensemble de règles comme Block (Bloquer) génère des événements et abandonne le trafic correspondant.

Vous pouvez filtrer les règles pour afficher un sous-ensemble de règles, ce qui vous permet de sélectionner l’ensemble de règles exact pour lequel vous souhaitez modifier l’état ou les paramètres des règles.

Lorsqu’une règle de prévention des intrusions ou un arguments de règle nécessite un inspecteur désactivé, le système l’utilise automatiquement avec sa configuration actuelle, même s’il reste désactivé dans l’interface Web de la politique d’analyse de réseau.

Remarque

Nous vous recommandons de ne pas modifier les règles d’objets partagés et d’activer ou de désactiver ces règles pour votre périphérique Threat Defense. Pour créer des règles Snort personnalisées, contactez le service d’assistance Cisco.

Une règle de prévention des intrusions est un ensemble précis de mots-clés et d’arguments que le système utilise pour détecter les tentatives d’exploitation des vulnérabilités de votre réseau. Lorsque le système analyse le trafic réseau, il compare les paquets aux conditions spécifiées dans chaque règle et déclenche la règle si le paquet de données répond à toutes les conditions spécifiées dans cette dernière.

Une politique de prévention des intrusions contient :

• les règles de prévention des intrusions, qui sont subdivisées en règles d’objets partagés et en règles de texte standard.

• les règles de l’ inspecteur, qui sont associées à une option de détection du décodeur de paquets ou à l’un des inspecteurs inclus avec le système

Le tableau suivant résume les attributs de ces types de règles :

Vous ne pouvez pas enregistrer les modifications d’une règle créée par Talos, mais vous pouvez enregistrer une copie d’une règle modifiée en tant que règle personnalisée. Vous pouvez modifier les variables utilisées dans la règle ou les informations d’en-tête de règle (comme les ports source et de destination et les adresses IP). Dans un déploiement multidomaine, les règles créées par Talos appartiennent au domaine global. Les administrateurs des domaines descendants peuvent enregistrer des copies locales des règles, qu’ils peuvent ensuite modifier.

Pour les règles qu’il crée, Talos attribue des états de règles par défaut dans chaque politique de prévention des intrusions par défaut. La plupart des règles de préprocesseur sont désactivées par défaut et doivent être activées si vous souhaitez que le système génère des événements pour les règles de préprocesseur et, dans un déploiement en ligne, abandonne les paquets fautifs.

Vous pouvez créer une règle de prévention des intrusions personnalisée en important un fichier de règle local. Le fichier de règles peut avoir une extension .txt ou .rules. Le système enregistre la règle personnalisée dans la catégorie de règle locale, quelle que soit la méthode que vous avez utilisée pour la créer. Une règle personnalisée doit appartenir à un groupe de règles. Cependant, une règle personnalisée peut également faire partie de deux groupes ou plus.

Lorsque vous créez une règle de prévention des intrusions personnalisée, le système lui attribue un numéro de règle unique, qui a le format GID:SID:Rev. Les éléments composant ce numéro sont les suivants :

• GID : ID de générateur. Pour les règles personnalisées, il n’est pas nécessaire de préciser le GID. Le système génère automatiquement le GID lors du chargement des règles selon que vous vous trouvez dans le domaine global ou dans un sous-domaine. Pour toutes les règles de texte standard, cette valeur est de 2 000 pour un domaine global.

• SID : ID Snort. Indique s’il s’agit d’une règle locale d’une règle système. Lorsque vous créez une règle, attribuez-lui un SID unique.

  Les numéros SID des règles locales commencent à 1000000 et le SID de chaque nouvelle règle locale est incrémenté de un.

• Rev : le numéro de la révision. Pour une nouvelle règle, le numéro de révision est de 1. Chaque fois que vous modifiez une règle personnalisée, le numéro de révision doit être incrémenté de un.

Dans une règle de texte standard personnalisée, vous définissez les paramètres d’en-tête de règle ainsi que les mots-clés et les arguments de la règle. Vous pouvez utiliser les paramètres d’en-tête de règle pour axer la règle de manière à ce qu’elle ne corresponde qu’au trafic utilisant un protocole spécifique et circulant vers ou à partir d’adresses IP ou de ports spécifiques.

Pour vérifier si un SID est activé ou désactivé, consultez les entrées du fichier snort.lua situé dans le répertoire ./file-contents/ngfw/var/sf/detection_engines/<id>/ips/<id>.

• Si le SID est désactivé par défaut, aucune entrée n’est présente dans le fichier.

• Si le SID est activé manuellement, vous noterez la présence d’une entrée enable:yes.

• Si le SID est désactivé après avoir été activé manuellement, l’entrée reste dans le fichier et affiche enable:no.

Remarque

Les règles personnalisées Snort 3 ne peuvent pas être modifiées. Assurez-vous que les règles personnalisées comportent un message de classification valide pour classtype dans le texte de la règle. Si vous importez une règle sans classification ou avec une mauvaise classification, supprimez et recréez la règle. Vous pouvez créer des règles de prévention des intrusions personnalisées dans Snort 3. Cependant, la prise en charge du réglage et de la résolution de problèmes liés à ces règles n’est pas disponible pour le moment.

Intrusion Rule action (action de règle de prévention des intrusions) vous permet d’activer ou de désactiver la règle dans une politique de prévention des intrusions individuelle, ainsi que de spécifier l’action que le système entreprend si des conditions surveillées déclenchent l’application de la règle.

Le groupe Intelligence Cisco Talos (Talos) définit l’action par défaut de chaque règle de prévention des intrusions et d’inspecteur dans chaque politique par défaut. Par exemple, une règle peut être activée dans la politique par défaut de Sécurité avant la connectivité et désactivée dans la politique par défaut de Connectivité avant la sécurité. Talos utilise parfois une mise à jour de règle pour modifier l’action par défaut d’une ou plusieurs règles dans une politique par défaut. Si vous autorisez les mises à jour de règles à mettre à jour votre politique de base, vous autorisez également la mise à jour de règles à modifier l'action par défaut d'une règle de votre politique lorsque l'action par défaut change dans la politique par défaut que vous avez utilisée pour créer votre politique (ou dans la politique par défaut sur laquelle elle est basée). Notez, cependant, que si vous avez modifié l’action de règle, la mise à jour de la règle ne remplace pas votre modification.

Lorsque vous créez une règle de prévention des intrusions, elle hérite des actions par défaut des règles de la politique par défaut que vous utilisez pour créer votre politique.

L’importance d’un incident d'intrusion peut être fonction de sa fréquence ou de l’adresse IP source ou de destination. Dans certains cas, vous pouvez ne pas vous soucier d’un événement tant qu’il ne se produit pas un certain nombre de fois. Par exemple, vous pourriez ne pas être concerné si quelqu’un tente de se connecter à un serveur avant d’échouer un certain nombre de fois. Dans d’autres cas, vous n’aurez peut-être besoin que de quelques occurrences pour savoir qu’il y a un problème généralisé. Par exemple, si une attaque DoS est lancée contre votre serveur Web, vous n’aurez peut-être besoin de voir que quelques occurrences d’un incident d'intrusion pour savoir que vous devez corriger la situation. Le fait de constater des centaines d'événements identiques ne fait que submerger votre système.

Si vous utilisez des règles personnalisées, assurez-vous que vous êtes prêt à gérer cet ensemble de règles pour Snort 3 avant la conversion de Snort 2 vers Snort 3. Si vous utilisez un ensemble de règles d’un fournisseur tiers, communiquez avec ce fournisseur pour confirmer que ses règles seront converties avec succès vers Snort 3 ou pour obtenir un ensemble de règles de remplacement écrit de manière native pour Snort 3. Si vous avez des règles personnalisées que vous avez écrites vous-même, familiarisez-vous avec la rédaction des règles de Snort 3 avant la conversion, afin de pouvoir mettre à jour vos règles et optimiser la détection de Snort 3 après la conversion. Consultez les liens ci-dessous pour en savoir plus sur l’écriture de règles dans Snort 3.

• https://blog.snort.org/2020/08/how-rules-are-improving-in-snort-3.html

• https://blog.snort.org/2020/10/talos-transition-to-snort-3.html

Vous pouvez consulter d’autres blogs à l’adresse https: // blog.snort.org/ pour en savoir plus sur les règles Snort 3.

Important

Les paramètres de politique d’analyse de réseau (NAP) de Snort 2 ne peuvent pas être copiés dans Snort 3 automatiquement. Les paramètres de Politique d'analyse de réseau (NAP) doivent être répliqués manuellement dans Snort 3.