Détection de signatures malveillantes

Introduction

Les systèmes de détection d'intrusion (IDS) comme Snort reposent largement sur des règles pour identifier le trafic réseau malveillant. Une règle bien conçue agit comme une signature, permettant au système de déclencher une alerte lorsque des modèles spécifiques sont observés dans les paquets de données.

La détection basée sur les signatures fonctionne en reconnaissant des modèles connus, et non en comprenant directement l'intention de l'attaquant. Cela la rend rapide et utile, mais aussi imparfaite. Si le modèle est trop large, il génère des faux positifs. S'il est trop étroit, les attaquants peuvent le contourner avec de légères modifications. La rédaction de règles est donc un exercice d'équilibre entre précision et couverture.

Dans ce laboratoire, vous vous mettrez dans la peau d'un analyste en sécurité. Vous rédigerez des règles Snort capables de détecter les attaques de la couche application. Plus précisément, vous analyserez une charge utile d'attaque par injection SQL capturée dans un fichier PCAP (Packet Capture), et vous concevrez des règles Snort précises utilisant à la fois la correspondance de contenu de base et des expressions régulières avancées (PCRE) pour inspecter le trafic HTTP et alerter en cas de détection de cette chaîne malveillante.

Analyser la charge utile de l'attaque (PCAP)

Dans cette étape, vous analyserez un fichier de capture de paquets réseau pour comprendre à quoi ressemble une charge utile malveillante. Avant de rédiger une règle de détection, un analyste en sécurité doit d'abord savoir exactement ce qu'il cherche à détecter.

Cet ordre est important. Une erreur courante chez les débutants est de commencer à rédiger des signatures avant d'inspecter le trafic réel. En pratique, les défenseurs commencent généralement par des preuves : un fichier PCAP, un échantillon de journal ou une preuve de concept d'exploitation. Ce n'est qu'après avoir compris le modèle observable qu'ils le traduisent en règle.

Votre environnement a été préconfiguré avec un fichier nommé sqli_attack.pcap dans votre répertoire ~/project. Ce fichier contient un paquet réseau simulé où un attaquant tente une attaque par injection SQL contre un serveur web.

Pour inspecter le contenu de ce fichier PCAP, vous pouvez utiliser un outil appelé tcpdump. La commande tcpdump est un puissant analyseur de paquets en ligne de commande. En utilisant l'option -A, vous pouvez afficher le contenu des paquets en ASCII (texte brut), ce qui est idéal pour lire les requêtes HTTP. L'option -r indique à tcpdump de lire à partir d'un fichier plutôt que d'une interface réseau active.

Exécutez la commande suivante dans votre terminal pour analyser la charge utile :

tcpdump -A -r sqli_attack.pcap

Vous devriez obtenir un résultat similaire à celui-ci :

reading from file sqli_attack.pcap, link-type EN10MB (Ethernet), snapshot length 262144
10:23:45.123456 IP 192.168.1.100.12345 > 192.168.1.10.http: Flags [P.], seq 1:78, ack 1, win 8192, length 77: HTTP: GET /login.php?user=admin'%20UNION%20SELECT%201,2,3-- HTTP/1.1
E..u..@.@............9.P..P.P.......+......GET /login.php?user=admin'%20UNION%20SELECT%201,2,3-- HTTP/1.1
Host: example.com

Observez attentivement la partie en texte brut du résultat. Vous pouvez voir une requête HTTP GET adressée à /login.php. Notez le paramètre user : admin'%20UNION%20SELECT%201,2,3--.

Le %20 est la représentation encodée en URL d'un espace. L'expression UNION SELECT est une signature classique d'une attaque par injection SQL, où un attaquant tente de combiner les résultats de sa propre requête de base de données malveillante avec la requête originale. C'est exactement la signature que nous voulons détecter.

Rédiger des règles basées sur le contenu

Dans cette étape, vous rédigerez votre première règle Snort personnalisée pour détecter la signature d'injection SQL que vous avez découverte à l'étape précédente.

Le mot-clé content est la forme la plus simple d'inspection de charge utile. Il est rapide et facile à comprendre car il recherche une chaîne de caractères littérale. La correspondance littérale est souvent le premier jet idéal pour une signature, car elle rend la logique de détection transparente.

Les règles Snort sont écrites selon une syntaxe spécifique. Une règle de base se compose d'un en-tête de règle et d'options de règle.

L'en-tête définit l'action, le protocole, les adresses IP source/destination et les ports.
Les options définissent le contenu spécifique à rechercher et le message à afficher lorsqu'une alerte est déclenchée.

Nous allons créer une règle qui recherche la chaîne exacte UNION%20SELECT dans tout trafic TCP destiné au port 80 (le port HTTP standard).

Ouvrez le fichier de règles personnalisées à l'aide de l'éditeur de texte nano :

nano ~/project/rules/local.rules

Ajoutez la ligne suivante au fichier :

alert tcp any any -> any 80 (msg:"Basic SQL Injection Detected"; content:"UNION%20SELECT"; sid:1000001; rev:1;)

Analysons la signification de cette règle :

alert : L'action à effectuer lorsque la règle correspond (générer une alerte).
tcp : Le protocole à inspecter.
any any -> any 80 : IP et port source (n'importe lesquels) vers l'IP de destination (n'importe laquelle) sur le port 80.
msg:"..." : Le message d'alerte à afficher à l'analyste.
content:"UNION%20SELECT" : La chaîne exacte que Snort recherchera dans la charge utile du paquet.
sid:1000001 : L'identifiant Snort. Les règles personnalisées doivent avoir un ID de 1 000 000 ou plus.
rev:1 : Le numéro de révision de la règle.

Après avoir ajouté la ligne, enregistrez le fichier et quittez nano en appuyant sur Ctrl+O, Entrée, puis Ctrl+X.

Vous pouvez vérifier le contenu de votre fichier de règles en utilisant la commande cat :

cat ~/project/rules/local.rules

Configurer PCRE (Expressions régulières)

Dans cette étape, vous améliorerez vos capacités de détection en utilisant PCRE (Perl Compatible Regular Expressions).

Les expressions régulières augmentent la flexibilité car elles décrivent des familles de modèles plutôt qu'une séquence d'octets exacte. C'est puissant, mais cela augmente également le risque de sur-correspondance. Les défenseurs utilisent PCRE lorsque les attaquants sont susceptibles de varier le formatage tout en gardant le comportement sous-jacent reconnaissable.

Bien que le mot-clé content soit rapide et efficace, il est très rigide. Les attaquants tentent souvent de contourner la détection en modifiant légèrement leurs charges utiles. Par exemple, au lieu de %20 (espace encodé en URL), un attaquant pourrait utiliser un espace normal (``), plusieurs espaces ou un signe plus (+). Une simple correspondance content manquerait ces variations.

PCRE vous permet d'écrire des modèles flexibles. Nous allons rédiger une deuxième règle qui utilise une expression régulière pour détecter les variations de l'attaque UNION SELECT.

Ouvrez à nouveau votre fichier de règles :

nano ~/project/rules/local.rules

Ajoutez la nouvelle règle suivante sur une nouvelle ligne sous votre première règle :

alert tcp any any -> any 80 (msg:"Advanced SQL Injection Detected"; pcre:"/UNION(%20|\s|\+)SELECT/i"; sid:1000002; rev:1;)

Analysons l'option pcre :

pcre:"/ ... /i" : Les barres obliques indiquent le début et la fin de l'expression régulière. Le i à la fin rend la recherche insensible à la casse (elle correspondra à union, UNION, UnIoN, etc.).
UNION : Correspond au mot UNION.
(%20|\s|\+) : Il s'agit d'un groupe de capture avec une logique OU (|). Il correspond soit à %20, soit à un caractère d'espacement (\s), soit à un signe plus (\+).
SELECT : Correspond au mot SELECT.

Enregistrez le fichier et quittez nano (Ctrl+O, Entrée, Ctrl+X).

Votre fichier local.rules devrait maintenant contenir deux règles distinctes conçues pour détecter les tentatives d'injection SQL.

Valider la détection des règles

Dans cette dernière étape, vous mettrez vos règles personnalisées à l'épreuve. Vous exécuterez Snort en mode hors ligne, en lui demandant de lire le fichier sqli_attack.pcap et d'appliquer les règles que vous venez d'écrire dans local.rules.

Tester avec un échantillon connu est essentiel, car une règle qui semble correcte sur le papier peut échouer en opérationnel. La validation confirme que la règle se déclenche réellement sur le trafic prévu, ce qui est l'exigence minimale avant de lui faire confiance dans un environnement réel.

Snort peut être exécuté avec divers indicateurs. Voici ceux que nous utiliserons :

-q : Mode silencieux. Cela supprime la grande bannière et le texte d'initialisation, rendant la sortie plus facile à lire.
-c : Spécifie le fichier de configuration ou de règles à utiliser.
-r : Spécifie le fichier PCAP à lire.
-A console : Indique à Snort d'imprimer les alertes directement dans la console du terminal.

Exécutez la commande suivante pour tester vos règles contre la charge utile malveillante :

sudo snort -q -c rules/local.rules -r sqli_attack.pcap -A console

Si vos règles ont été rédigées correctement, vous devriez voir un résultat similaire à celui-ci :

10/23-10:23:45.123456  [**] [1:1000001:1] Basic SQL Injection Detected [**] [Priority: 0] {TCP} 192.168.1.100:12345 -> 192.168.1.10:80
10/23-10:23:45.123456  [**] [1:1000002:1] Advanced SQL Injection Detected [**] [Priority: 0] {TCP} 192.168.1.100:12345 -> 192.168.1.10:80

Félicitations ! Vos deux règles se sont déclenchées avec succès. La première règle a correspondu à la chaîne exacte, et la deuxième règle a correspondu au modèle en utilisant des expressions régulières. Vous avez agi avec succès en tant qu'analyste en sécurité, identifiant une menace et déployant une signature pour la détecter.

Résumé

Dans ce laboratoire, vous avez acquis une expérience pratique de la détection d'intrusion réseau en rédigeant des règles Snort personnalisées. Vous avez commencé par analyser une capture de paquets brute pour identifier la signature spécifique d'une attaque par injection SQL. Vous avez ensuite appris à traduire cette signature en une règle Snort de base basée sur la correspondance de contenu. Enfin, vous avez amélioré vos capacités de détection en implémentant des expressions régulières compatibles Perl (PCRE) pour détecter les variations de l'attaque, et vous avez validé avec succès vos règles en exécutant Snort sur le trafic malveillant. Ces compétences sont fondamentales pour tout professionnel de la cybersécurité chargé de défendre une infrastructure réseau.