Écrire des règles Snort efficaces avec des exemples [Meilleures pratiques]

Ce post vous aidera à écrire des règles Snort efficaces pour améliorer matériellement votre posture de sécurité. Nous commencerons par une décomposition de la façon dont une règle est construite, puis nous explorerons les meilleures pratiques avec des exemples afin de capturer autant d’activités malveillantes que possible tout en utilisant le moins de règles possible.

Snort est un système de détection d’intrusion réseau (NIDS) open-source qui fournit une analyse des paquets en temps réel et fait partie de la solution Coralogix STA. Si vous êtes un client de Coralogix STA, n’oubliez pas de consulter également mon précédent billet sur la façon d’éditer les règles Snort dans STA.

Anatomie des règles Snort

Avant de plonger dans les différentes stratégies pour écrire vos meilleures règles Snort, commençons par disséquer un exemple de règle Snort:

alert : indique à Snort de signaler ce comportement comme une alerte (c’est obligatoire dans les règles créées pour le STA).

tcp : signifie que cette règle ne s’appliquera qu’au trafic en TCP.

any : dans ce contexte, cela signifie « de n’importe quel port source », puis il y a une flèche ‘->’ qui signifie « une connexion à » (il n’y a pas d’opérateur ‘<-‘, mais vous pouvez simplement inverser les arguments autour de l’opérateur. Vous pouvez utiliser l’opérateur ‘<>’ pour indiquer que la direction de la connexion n’est pas pertinente pour cette règle), puis une plage IP qui indique l’adresse IP de destination et enfin le port. Vous pouvez indiquer une plage de ports en utilisant les deux points comme 0:1024 qui signifie 0-1024. Dans la parenthèse ronde, il y a quelques directives pour définir le message d’alerte, les métadonnées sur la règle, ainsi que des contrôles supplémentaires.

msg : est une directive qui définit simplement le message qui sera envoyé (à Coralogix dans le cas de STA) dans le cas où un trafic correspondant sera détecté.

flow : est une directive qui indique si le contenu que nous allons définir comme notre signature doit apparaître dans la communication vers le serveur (« to_server ») ou vers le client (« to_client »). Cela peut être très utile si, par exemple, nous souhaitons détecter la réponse du serveur qui indique qu’il a fait l’objet d’une violation.

établi : est une directive qui fera en sorte que Snort limite sa recherche de paquets correspondant à cette signature aux paquets faisant partie de connexions établies uniquement. Ceci est utile pour minimiser la charge sur Snort.

uricontent : est une directive qui demande à Snort de rechercher un certain texte dans le contenu normalisé de l’URI HTTP. Dans cet exemple, nous recherchons une url qui correspond exactement au texte « /root.exe ».

nocase : est une directive qui indique que nous aimerions que Snort effectue une recherche insensible à la casse.

classtype : est une directive qui est un attribut de métadonnées indiquant quel type d’activité cette règle détecte.

reference : est une directive qui est un attribut de métadonnées qui renvoie à un autre système pour plus d’informations. Dans notre exemple, la valeur url,<https://….&gt ; renvoie à une URL sur Internet.

sid : est une directive qui est un attribut de métadonnées qui indique l’ID de la signature. Si vous créez votre propre signature (même si vous remplacez simplement une règle intégrée), utilisez une valeur supérieure à 9 000 000 pour éviter une collision avec une autre règle préexistante.

rev : est une directive qui indique la version de la règle.

Il y a beaucoup plus à apprendre sur les règles Snort qui prend en charge l’analyse RegEx, l’analyse spécifique au protocole (tout comme uricontent pour HTTP), la recherche de données binaires (non textuelles) en utilisant les valeurs hexadécimales des octets, et bien d’autres choses encore. Si vous souhaitez en savoir plus, vous pouvez commencer ici.

Bonnes pratiques pour écrire des règles Snort efficaces

1. Ciblez la vulnérabilité, pas l’exploit – Évitez d’écrire des règles pour détecter un kit d’exploitation spécifique, car il existe d’innombrables exploits pour la même vulnérabilité et nous pouvons être sûrs que de nouveaux sont écrits au moment où vous lisez ceci. Par exemple, bon nombre des premières signatures pour la détection des attaques par dépassement de tampon ressemblaient à ceci:

   alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (content:"AAAAAAAAAAAAAA", msg:"Buffer overrun detected.")

   La raison en est bien sûr que pour lancer une attaque par dépassement de tampon réussie, l’attaquant doit remplir le tampon d’une certaine variable et ajouter sa charge utile malveillante à la fin pour qu’elle devienne exécutable. Les caractères qu’il choisit d’utiliser pour remplir le tampon sont totalement insignifiants et, en effet, après l’apparition de ces signatures, de nombreuses boîtes à outils d’attaque ont simplement utilisé une ou plusieurs lettres différentes pour remplir le tampon et ont complètement échappé à la détection de ce type de signature. Un bien meilleur moyen serait de tenter de détecter ce type d’attaques en détectant les entrées incorrectes dans les champs en fonction de leur type et de leur longueur.

2. Votre particularité est votre meilleur atout, alors utilisez-la – Chaque organisation a des choses qui la rendent unique. Beaucoup d’entre elles peuvent être très utiles lorsque vous essayez d’attraper des activités malveillantes dans votre organisation – tant externes qu’internes. En utilisant ces connaissances internes approfondies à votre avantage, vous transformerez essentiellement le problème d’un problème technologique en un problème de renseignement à l’ancienne, obligeant les attaquants à avoir une compréhension beaucoup plus intime de votre organisation afin de pouvoir cacher leurs traces efficacement. Ces choses peuvent être de nature technologique ou basées sur les habitudes de travail particulières et les directives internes de votre organisation. Voici quelques exemples :
   • Heures de travail typiques : Certaines organisations dans lesquelles j’ai travaillé ne permettaient pas du tout aux employés de travailler à domicile et la majorité des employés auraient déjà quitté le bureau à 19h00. Pour des organisations similaires, il serait judicieux de définir une alerte pour vous avertir des connexions depuis le bureau après une certaine heure. Un attaquant qui installerait un logiciel malveillant dans votre organisation devrait connaître ce comportement et régler son logiciel malveillant pour qu’il communique avec ses serveurs de commande & de contrôle précisément à la même heure ; ces communications passeraient inaperçues.
   • Navigateur typique : Supposons que votre organisation ait décidé d’utiliser le navigateur Brave comme navigateur principal et qu’il soit installé automatiquement sur chaque nouveau portable d’entreprise et que vous ayez supprimé les raccourcis de bureau vers le navigateur IE/Edge de tous vos portables d’entreprise. Si c’est le cas, une connexion de l’organisation, aussi bien vers une adresse interne que vers une adresse externe qui utilise un navigateur différent tel que IE/Edge devrait être configurée pour lever une alerte.
   • Gammes d’IP basées sur les rôles : S’il vous est possible d’attribuer différentes plages IP pour différents serveurs en fonction de leur rôle, par exemple, d’avoir tous les serveurs de bases de données sur 192.168.0.0/24, les serveurs web sur 192.168.1.0/24, etc. alors il serait possible et même facile de mettre en place des règles intelligentes basées sur le comportement attendu de vos serveurs en fonction de leur rôle. Par exemple, les serveurs de base de données ne se connectent généralement pas à d’autres serveurs de leur propre chef, les imprimantes n’essaient pas de se connecter à vos contrôleurs de domaine, etc.
   • Tentatives de connexion inhabituelles : De nombreuses organisations utilisent un partage public sur un serveur de fichiers pour aider leurs utilisateurs à partager des fichiers entre eux et utilisent des imprimantes compatibles avec le réseau pour permettre à leurs utilisateurs d’imprimer directement depuis leurs ordinateurs. Cela signifie que les ordinateurs clients ne devraient pas se connecter les uns aux autres, même si vous avez (sagement) choisi de bloquer un tel accès dans un pare-feu ou au niveau du commutateur, la seule tentative de connexion d’un client à un autre ordinateur client devrait déclencher une alerte et faire l’objet d’une enquête approfondie.
   • Ports peu communs : Certaines organisations utilisent une bibliothèque spéciale pour optimiser la communication entre les services, de sorte que toutes les communications HTTP entre les serveurs utilisent un port différent des ports courants (tels que 80, 443, 8080, etc). Dans ce cas, c’est une bonne idée de créer une règle qui serait déclenchée par toute communication sur ces ports normalement communs.
3. Honeytokens – Dans un champ de bataille comme l’Internet où tout le monde peut être à peu près n’importe qui, la tromperie, fonctionne aussi bien pour les défenseurs que pour les attaquants, sinon mieux. Des astuces telles que renommer le compte administrateur intégré en un nom différent et moins attrayant, créer un nouveau compte nommé Administrateur que vous n’utiliserez jamais et créer une règle Snort pour détecter si ce nom d’utilisateur, cette adresse électronique ou ce mot de passe sont utilisés sur le réseau. Il serait pratiquement impossible pour les attaquants de remarquer que Snort a détecté leurs tentatives d’utilisation du faux utilisateur administrateur. Un autre exemple consiste à créer de faux produits, clients, utilisateurs et enregistrements de cartes de crédit dans la base de données, puis à faire correspondre les règles Snort pour les détecter dans le trafic réseau.

Nous espérons que vous avez trouvé ces informations utiles. Pour plus d’informations sur la STA de Coralogix, consultez les dernières fonctionnalités que nous avons récemment publiées.