Comprendre les signatures Suricata

Introduction

Le premier tutoriel de cette série expliquait comment installer et configurer Suricata. Si vous avez suivi ce didacticiel, vous avez également appris à télécharger et à mettre à jour les ensembles de règles Suricata et à examiner les journaux à la recherche d'alertes concernant des activités suspectes. Cependant, les règles que vous avez téléchargées dans ce didacticiel sont nombreuses et couvrent de nombreux protocoles, applications et vecteurs d'attaque différents qui peuvent ne pas être pertinents pour votre réseau et vos serveurs.

Dans ce didacticiel, vous apprendrez comment les signatures Suricata sont structurées et certaines options importantes couramment utilisées dans la plupart des règles. Une fois que vous serez familiarisé avec la façon de comprendre la structure et les champs d'une signature, vous serez en mesure d'écrire vos propres signatures que vous pourrez combiner avec un pare-feu pour vous alerter du trafic le plus suspect vers vos serveurs, sans avoir besoin d'utiliser d'autres ensembles de règles.

Cette approche de l'écriture et de la gestion des règles signifie que vous pouvez utiliser Suricata plus efficacement, car il n'a besoin de traiter que les règles spécifiques que vous écrivez. Une fois que vous disposez d'un ensemble de règles décrivant la majorité du trafic légitime et suspect que vous vous attendez à rencontrer sur votre réseau, vous pouvez commencer à supprimer de manière sélective le trafic invalide à l'aide de Suricata dans son mode actif de prévention des intrusions (IPS). Le prochain didacticiel de cette série expliquera comment activer la fonctionnalité IPS de Suricata.

Conditions préalables

Pour les besoins de ce didacticiel, vous pouvez exécuter Suricata sur n'importe quel système, car les signatures ne nécessitent généralement aucun système d'exploitation particulier. Si vous suivez cette série de tutoriels, vous devriez déjà avoir :

• Suricata installé et exécuté sur un serveur Ubuntu 20.04, Debian 11 ou Rocky Linux 8.
• Le ET Open Ruleset téléchargé à l'aide de la commande suricata-update et inclus dans vos signatures Suricata.

Comprendre la structure des signatures Suricata

Les signatures Suricata peuvent sembler complexes au premier abord, mais une fois que vous aurez appris comment elles sont structurées et comment Suricata les traite, vous serez en mesure de créer vos propres règles en fonction des exigences de votre réseau.

À un niveau élevé, les signatures Suricata se composent de trois parties :

1. Une Action à effectuer lorsque le trafic correspond à la règle.
2. Un Header qui décrit les hôtes, les adresses IP, les ports, les protocoles et la direction du trafic (entrant ou sortant).
3. Options, qui spécifient des éléments tels que l'ID de signature (sid), le message de journal, les expressions régulières qui correspondent au contenu des paquets, le type de classification et d'autres modificateurs qui peuvent aider à identifier précisément les éléments légitimes et suspects Circulation.

La structure générale d'une signature est la suivante :

Structure de règle générique

ACTION HEADER OPTIONS

Les parties d'en-tête et d'options d'une signature comportent plusieurs sections. Par exemple, dans le tutoriel précédent, vous avez testé Suricata en utilisant la règle avec sid 2100498. Voici la règle complète pour référence :

sid:2100498

alert ip any any -> any any (msg:"GPL ATTACK_RESPONSE id check returned root"; content:"uid=0|28|root|29|"; classtype:bad-unknown; sid:2100498; rev:7; metadata:created_at 2010_09_23, updated_at 2010_09_23;)

La partie alert de la signature est l''action, la section ip any any -> any any est l'en-tête ' et le reste de la signature commençant par (msg:GPL ATTACK_RESPONSE... contient les options de la règle.

Dans les sections suivantes, vous examinerez en détail chaque partie d'une règle Suricata.

Actions

La première partie de la signature sid:2100498 est l'action, dans ce cas alert. La partie action d'une signature Suricata spécifie l'action à entreprendre lorsqu'un paquet correspond à la règle. Une action peut être l'une des suivantes selon que Suricata fonctionne en mode IDS ou IPS :

• Pass - Suricata arrêtera d'analyser le paquet et l'autorisera, sans générer d'alerte.
• Drop - Lorsque vous travaillez en mode IPS, Suricata arrête immédiatement de traiter le paquet et génère une alerte. Si la connexion qui a généré le paquet utilise TCP, il expirera.
• Reject - Lorsque Suricata exécute le mode IPS, un paquet de réinitialisation TCP sera envoyé et Suricata supprimera le paquet correspondant.
• Alerte - Suricata générera une alerte et l'enregistrera pour une analyse plus approfondie.

En-têtes

Chaque signature Suricata a une section d'en-tête qui décrit le protocole réseau, les adresses IP source et de destination, les ports et la direction du trafic. En se référant à l'exemple de signature sid:2100498, la section d'en-tête de la règle est la partie en surbrillance ip any any -> any any :

sid:2100498

alert ip any any -> any any (msg:"GPL ATTACK_RESPONSE id check returned root"; content:"uid=0|28|root|29|"; classtype:bad-unknown; sid:2100498; rev:7; metadata:created_at 2010_09_23, updated_at 2010_09_23;)

Le format général de la section d'en-tête d'une règle est :

Format de règle

<PROTOCOL> <SOURCE IP> <SOURCE PORT> -> <DESTINATION IP> <DESTINATION PORT>

Le Protocole peut être l'un des suivants :

• TCP
• UDP
• ICMP
• IP
• Un certain nombre d'autres protocoles d'application

Les champs Source et Destination peuvent être des adresses IP ou des plages de réseau, ou la valeur spéciale any, qui correspondra à toutes les adresses IP et tous les réseaux. La flèche -> indique le sens du trafic.

Remarque : Les signatures peuvent également utiliser un marqueur non directionnel <> qui correspond au trafic dans les deux sens. Cependant, la documentation Suricata sur les marqueurs directionnels note que la plupart des règles utiliseront la flèche correspondante droite ->.

Si vous vouliez alerter sur le trafic sortant malveillant (c'est-à-dire le trafic quittant votre réseau), le champ Source serait l'adresse IP ou la plage réseau de votre système. La Destination peut être l'adresse IP ou le réseau d'un système distant, ou la valeur spéciale any.

Inversement, si vous souhaitez générer une alerte pour le trafic entrant malveillant, le champ Source peut être défini sur any, et la Destination sur l'adresse IP ou le réseau de votre système Portée.

Vous pouvez également spécifier le port TCP ou UDP à examiner à l'aide des champs Port. Généralement, le trafic provenant d'un système se voit attribuer un port aléatoire, de sorte que la valeur any est appropriée pour le côté gauche de l'indicateur ->. Le port de destination peut également être any si vous prévoyez d'examiner le contenu de chaque paquet entrant, ou vous pouvez limiter une signature pour analyser uniquement les paquets sur des ports individuels, comme 22 pour le trafic SSH ou 443 pour HTTPS.

L'en-tête ip any any -> any any de sid:2100498 est un en-tête générique qui correspondra à tout le trafic, quel que soit le protocole, les adresses IP source ou de destination, ou les ports. Ce type d'en-tête fourre-tout est utile lorsque vous souhaitez vous assurer que le trafic entrant et sortant est contrôlé pour détecter tout contenu suspect.

Notez que les champs Source, Destination et Port peuvent également utiliser l'opérateur de négation spécial !, qui traitera le trafic qui ne correspond pas à la valeur du champ.

Par exemple, la signature suivante ferait en sorte que Suricata alerte sur tous les paquets SSH entrants du réseau any qui sont destinés à votre réseau (représenté par le bloc IP 203.0.113.0/24), qui ne sont pas[ X206X] destiné au port 22 :

Exemple d'en-tête

alert ssh any any -> 203.0.113.0/24 !22 (sid:1000000;)

Cette alerte ne serait pas très utile, car elle ne contient aucun message sur le paquet, ni un type de classification. Pour ajouter des informations supplémentaires à une alerte, ainsi qu'une correspondance sur des critères plus spécifiques, les règles Suricata ont une section Options où vous pouvez spécifier un certain nombre de paramètres supplémentaires pour une signature.

Choix

Les arguments entre parenthèses (. . .) dans une signature Suricata contiennent diverses options et modificateurs de mots clés que vous pouvez utiliser pour faire correspondre des parties spécifiques d'un paquet, classer une règle ou enregistrer des messages personnalisés. Alors que les arguments d'en-tête d'une règle fonctionnent sur les en-têtes de paquet au niveau de l'IP, du port et du protocole, les options correspondent aux données contenues dans un paquet.

Les options d'une règle Suricata doivent être séparées par un point-virgule ; et utilisent généralement un format clé:valeur. Certaines options n'ont pas de paramètres et seul le nom doit être spécifié dans une règle.

En utilisant l'exemple de signature de la section précédente, vous pouvez ajouter l'option msg avec une valeur de SSH traffic detected on non-SSH port expliquant en quoi consiste l'alerte :

Exemple d'en-tête

alert ssh any any -> 203.0.113.0/24 !22 (msg:"SSH TRAFFIC on non-SSH port"; sid:1000000;)

Une explication complète de la façon dont vous pouvez utiliser chaque option dans une règle Suricata dépasse le cadre de ce didacticiel. La documentation des règles Suricata commençant à la section 6.2 décrit chaque option de mot-clé en détail.

Cependant, il existe certaines options de base comme le mot-clé content et divers mots-clés Meta qui sont utilisés dans la plupart des signatures, que nous examinerons dans les sections suivantes.

Le mot-clé Content

L'une des options les plus importantes pour toute règle est le mot-clé content. Rappelez-vous l'exemple de signature sid:2100498 :

sid:2100498

alert ip any any -> any any (msg:"GPL ATTACK_RESPONSE id check returned root"; content:"uid=0|28|root|29|"; classtype:bad-unknown; sid:2100498; rev:7; metadata:created_at 2010_09_23, updated_at 2010_09_23;)

La partie content:"uid=0|28|root|29|"; en surbrillance contient le mot-clé content et la valeur que Suricata recherchera dans un paquet. Dans le cas de cet exemple de signature, tous les paquets de n'importe quelle adresse IP sur n'importe quel port seront vérifiés pour s'assurer qu'ils ne contiennent pas la valeur de chaîne uid=0|28|root|29| (qui dans le tutoriel précédent a été utilisé comme exemple indiquant un hôte compromis ).

Le mot-clé content peut être utilisé avec la plupart des autres mots-clés dans Suricata. Vous pouvez créer des signatures très spécifiques à l'aide de combinaisons d'en-têtes et d'options qui ciblent des protocoles d'application spécifiques, puis vérifier le contenu des paquets pour des octets individuels, des chaînes ou des correspondances à l'aide d'expressions régulières.

Par exemple, la signature suivante examine le trafic DNS à la recherche de tout paquet avec le contenu your_domain.com et génère une alerte :

dns.query Exemple

alert dns any any -> any any (msg:"DNS LOOKUP for your_domain.com"; dns.query; content:"your_domain.com"; sid:1000001;)

Cependant, cette règle ne correspondrait pas si la requête DNS utilisait le domaine YOUR_DOMAIN.COM, puisque Suricata utilise par défaut la correspondance de contenu sensible à la casse. Pour rendre les correspondances de contenu insensibles à la casse, ajoutez le mot-clé nocase; à la règle :

DNS.query insensible à la casse Exemple

alert dns any any -> any any (msg:"DNS LOOKUP for your_domain.com"; dns.query; content:"your_domain.com"; nocase; sid:1000001;)

Désormais, toute combinaison de lettres minuscules ou majuscules correspondra toujours au mot-clé content.

Le mot-clé msg

Les exemples de signatures de ce didacticiel contiennent tous des mots-clés msg avec des informations sur une signature. Bien que l'option msg ne soit pas requise, la laisser vide rend difficile de comprendre pourquoi une alerte ou une action de suppression s'est produite lors de l'examen des journaux de Suricata.

Une option msg est conçue pour être une description textuelle lisible d'une alerte. Il doit être descriptif et ajouter du contexte à une alerte afin que vous ou quelqu'un d'autre qui analyse les journaux comprenne pourquoi l'alerte a été déclenchée. Dans la section [reference Keyword](reference Keyword) de ce didacticiel, vous découvrirez l'option reference que vous pouvez utiliser pour créer un lien vers plus d'informations sur une signature et le problème qu'il est censé détecter.

Les mots clés sid et rev

Chaque signature Suricata nécessite un identifiant de signature unique (sid). Si deux règles ont le même sid (dans l'exemple de sortie suivant, il s'agit de sid:10000000), Suricata ne démarrera pas et générera à la place une erreur comme celle-ci :

Example Duplicate sid Error. . .
19/11/2021 -- 01:17:40 - <Error> - [ERRCODE: SC_ERR_DUPLICATE_SIG(176)] - Duplicate signature "drop ssh any any -> 127.0.0.0/8 !22 (msg:"blocked invalid ssh"; sid:10000000;)"
. . .

Lorsque vous créez vos propres signatures, la plage 1000000-1999999 est réservée aux règles personnalisées. Les règles intégrées de Suricata sont comprises entre 2200000-2299999. D'autres plages sid sont documentées sur la page Emerging Threats SID Allocation.

L'option sid est généralement la dernière partie d'une règle Suricata. Cependant, s'il y a eu plusieurs versions d'une signature avec des changements au fil du temps, il existe une option rev qui est utilisée pour spécifier la version d'une règle. Par exemple, l'alerte SSH du début de ce didacticiel pourrait être modifiée pour analyser uniquement le trafic SSH sur le port 2022 :

Exemple de signature SSH avec rev

alert ssh any any -> 203.0.113.0/24 2022 (msg:"SSH TRAFFIC on non-SSH port"; sid:1000000; rev:2;)

La signature mise à jour inclut désormais l'option rev:2, indiquant qu'elle a été mise à jour à partir d'une version précédente.

Le mot-clé reference

Le mot clé reference est utilisé dans les signatures pour décrire où trouver plus d'informations sur l'attaque ou le problème qu'une règle est censée détecter. Par exemple, si une signature est conçue pour détecter un nouveau type d'exploit ou de méthode d'attaque, le champ de référence peut être utilisé pour créer un lien vers un chercheur en sécurité ou le site Web d'une entreprise qui documente le problème.

La vulnérabilité Heartbleed dans OpenSSL est un exemple de bogue largement médiatisé et recherché. Suricata est livré avec une signature conçue pour vérifier les paquets TLS incorrects et inclut une référence à l'entrée principale Heartbleed CVE :

/etc/suricata/rules/tls-events.rules

alert tls any any -> any any (msg:"SURICATA TLS invalid heartbeat encountered, possible exploit attempt (heartbleed)"; flow:established; app-layer-event:tls.invalid_heartbeat_message; flowint:tls.anomaly.count,+,1; classtype:protocol-command-decode; reference:cve,2014-0160; sid:2230013; rev:1;)

Notez la partie reference:cve,2014-0160; en surbrillance de la signature. Cette option de référence vous indique, à vous ou à l'analyste qui examine les alertes de Suricata, où trouver plus d'informations sur le problème particulier.

L'option de référence peut utiliser n'importe lequel des préfixes du fichier /etc/suricata/reference.config. Par exemple, url pourrait être utilisé à la place de cve dans l'exemple précédent, avec un lien direct vers le site Heartbleed à la place de l'identifiant CVE 2014-0160.

Le mot-clé classtype

Suricata peut classer le trafic selon un ensemble préconfiguré de catégories qui sont incluses lorsque vous installez le package Suricata avec le gestionnaire de packages de votre distribution Linux. Le fichier de classification par défaut se trouve généralement dans /etc/suricata/classification.config et contient des entrées comme celles-ci :

/etc/suricata/classification.config

#
# config classification:shortname,short description,priority
#

config classification: not-suspicious,Not Suspicious Traffic,3
config classification: unknown,Unknown Traffic,3
config classification: bad-unknown,Potentially Bad Traffic, 2
. . .

Comme l'indique l'en-tête du fichier, chaque entrée de classification comporte trois champs :

• Un nom court lisible par machine, dans les exemples ci-dessus not-suspicious, unknown et bad-unknown respectivement.
• Description d'une classification à utiliser avec les alertes, par exemple Not Suspicious Traffic.
• Un champ prioritaire, qui détermine l'ordre dans lequel une signature sera traitée par Suricata. La priorité la plus élevée est la valeur 1. Les signatures qui utilisent un classificateur avec une priorité plus élevée seront vérifiées en premier lorsque Suricata traitera un paquet.

Dans l'exemple de signature sid:2100498, le type de classe est classtype:bad-unknown;, qui est mis en évidence dans l'exemple suivant :

sid:2100498

alert ip any any -> any any (msg:"GPL ATTACK_RESPONSE id check returned root"; content:"uid=0|28|root|29|"; classtype:bad-unknown; sid:2100498; rev:7; metadata:created_at 2010_09_23, updated_at 2010_09_23;)

La priorité implicite pour la signature est 2, puisque c'est la valeur qui est assignée au type de classe bad-unknown dans /etc/suricata/classification.config. Si vous souhaitez remplacer la priorité par défaut d'un type de classe, vous pouvez ajouter une option priority:n à une signature, où n est une valeur comprise entre 1 et 255.

Le mot-clé target

Une autre option utile dans les signatures Suricata est l'option target. Il peut être réglé sur l'une des deux valeurs suivantes : src_ip et dest_ip. Le but de cette option est d'identifier correctement les hôtes source et target dans les journaux d'alertes de Suricata.

Par exemple, la signature SSH du début de ce didacticiel peut être améliorée avec l'option target:dest_ip; :

Exemple de signature SSH avec champ cible

alert ssh any any -> 203.0.113.0/24 2022 (msg:"SSH TRAFFIC on non-SSH port"; target:dest_ip; sid:1000000; rev:3;)

Cet exemple utilise dest_ip car la règle est conçue pour vérifier le trafic SSH entrant dans notre exemple de réseau, c'est donc la destination. L'ajout de l'option target à une règle entraînera les champs supplémentaires suivants dans la partie alert d'une entrée de journal eve.json.

. . .
  "source": {
    "ip": "127.0.0.1",
    "port": 35272
  },
  "target": {
    "ip": "203.0.113.1",
    "port": 2022
  }
. . .

Avec ces entrées dans les journaux de Suricata, elles peuvent être envoyées à un outil de gestion des informations et des événements de sécurité (SIEM) pour faciliter la recherche d'alertes pouvant provenir d'un hôte commun ou d'attaques dirigées vers une cible spécifique sur votre réseau.

Conclusion

Dans ce didacticiel, vous avez examiné chacune des sections principales qui constituent une signature Suricata complète. Chacune des sections Actions, Header et Options d'une règle comporte plusieurs options et prend en charge l'analyse des paquets à l'aide de nombreux protocoles différents. Bien que ce didacticiel n'ait exploré aucune des sections en profondeur, la structure de la règle et les champs importants des exemples devraient suffire pour commencer à écrire vos propres règles.

Si vous souhaitez explorer des signatures complètes qui incluent beaucoup plus d'options que celles décrites dans ce didacticiel, explorez les fichiers du répertoire /etc/suricata/rules. S'il existe un champ dans une règle sur lequel vous souhaitez en savoir plus, la Suricata Rules Documentation est la ressource faisant autorité sur la signification de chaque option et de ses valeurs possibles.

Une fois que vous êtes à l'aise pour lire et tester les signatures, vous pouvez passer au didacticiel suivant de cette série. Vous y apprendrez comment activer le mode IPS de Suricata, qui est utilisé pour supprimer le trafic suspect, par opposition au mode IDS par défaut qui ne génère que des alertes.