Quelle est la façon la plus simple de tester Snort IDS après l'installation? Est-ce que l'utilisation et l'écriture d'une règle qui capture tout le trafic fonctionne?
alert ip any any -> any any ( msg: "ICMP packet detected!"; sid: 1; )
Autrement dit, en utilisant ses propres règles.
Une façon que je connais pour tester Snort est d'utiliser certains programmes tels que Nmap
, Metasploit
, et autre chose, mais comment le faire?
Il y a deux choses subtilement différentes que vous voudrez peut-être tester.
Pour tester le cas 1, vous créez une règle facile à appliquer, comme votre exemple, et vous la déclenchez. Pour tester le cas 2, vous devez tenter une intrusion de type X et confirmer qu'elle est détectée.
Vous semblez vouloir tester le cas 1 (que l'installation a été effectuée correctement) en utilisant la méthode du cas 2, mais vous n'avez pas besoin de le faire. L'utilisation d'une "fausse" règle est un test parfaitement valide que Snort travaille dans le premier sens. Et c'est plus simple. Les tests faciles sont bons. Vous ne voulez pas jouer avec Metasploit lorsque vous vérifiez simplement que les e-mails d'alerte sont envoyés à la bonne personne. Surtout si vous n'êtes pas qualifié pour exécuter des intrusions - que faire si vous faites une intrusion incorrecte et obtenez un faux résultat de test? Que faire si la tentative d'intrusion plante la cible (ce qui est très probable sur de nombreux types d'intrusions).
Vous n'avez vraiment besoin que de tester le cas 2, qu'une règle spécifique fonctionne contre une véritable tentative d'intrusion, si vous ne faites pas confiance à votre ensemble de règles (dans ce cas - pourquoi l'utilisez-vous?) Ou si vous développez de nouvelles règles.
Il pourrait également être utile de jeter un œil à IDSWakeUp [avril 2019: le lien est mort].
IDSwakeup est une collection d'outils qui permet de tester des systèmes de détection d'intrusion réseau.
Le principal objectif d'IDSwakeup est de générer de fausses attaques qui imitent celles bien connues, afin de voir si NIDS les détecte et génère des faux positifs.
Comme nidsbench, IDSwakeup est publié dans l'espoir qu'une méthodologie de test plus précise puisse être appliquée à la détection d'intrusion réseau, ce qui est toujours un art noir au mieux.
Pour tester le fonctionnement de vos règles par défaut, en supposant que vous les ayez supprimées avec pullpork, oinkmaster ou autre chose, vous pouvez simplement accéder à http://testmyids.com/ à partir d'un client dont le trafic sera vu par l'IDS, à travers votre appareil IDS étant en ligne ou comme une portée de port.
La réponse http contient le texte suivant:
uid=0(root) gid=0(root) groups=0(root)
qui correspondra à l'une des règles de snort par défaut qui recherchent le "contenu" contenant la racine. Il s'agit d'une ancienne règle pour vérifier l'escalade de privilèges réussie lorsqu'un attaquant exécute les commandes de type id
ou whoami
pour vérifier qu'il dispose d'un accès root.
Voici un (ancien) blog qui explique également comment tester Snort: Comment savoir si mon implémentation Snort fonctionne? .
Je sais que c'est vieux mais je vais le jeter de toute façon ...
Check-out snort -T
Ce commutateur est conçu exactement pour la question qui a été posée. Il est intégré, vous n'avez pas besoin de simuler des règles, vous n'avez pas besoin d'envoyer du trafic malveillant (même s'il est "contrôlé"), vous n'avez pas besoin d'envoyer tout du trafic. Vous dira même où sont vos problèmes.
En 2019, le test Suricata/Snort le plus robuste que j'ai trouvé est:
Dig a 3wzn5p2yiumh7akj.onion
Ce qui déclenche la règle suivante à partir de Emerging-trojan.rules :
alert dns $HOME_NET any -> any any (msg:"ET TROJAN Cryptowall .onion Proxy Domain";
dns_query; content:"3wzn5p2yiumh7akj"; depth:16; nocase;
reference:url,www.bleepingcomputer.com/news/security/cryptowall-4-0-released-with-new-features-such-as-encrypted-file-names;
classtype:trojan-activity; sid:2022048; rev:2; metadata:created_at 2015_11_09,
updated_at 2015_11_09;)
Contexte: les signatures mentionnées ci-dessus sont obsolètes et la plupart d'entre elles ne contiennent pas de spécification de flux appropriée, ce qui rendra Snort ou Suricata aveugle pour elles. Également pour atteindre testmyids.com
vous avez besoin d'un proxy fonctionnel et cela ajoute à la complexité. Le .onion
L'alerte de résolution DNS ne nécessite cependant pas de connexion Internet fonctionnelle car elle est déclenchée par une simple tentative de résolution du nom par le client.