PROJET DE GESTION DES

INTRUSIONS
Année 2025-2026

Thème du SI de gestion

CYBERSECURITY & DIGITAL

INFRASTRUCTURE

Réalisé par :

Abdelkaoui Abaouibida

Mustapha Gomi

Encadré par :

Pr. Mohamed El Ghazouani

1
Table des matières
1 Introduction 4

2 Objectifs du projet 4

3 Environnement du laboratoire 4
3.1 Installation et premier test de Suricata..................................................................... 4
3.2 Accès aux logs Suricata ...............................................................................................6

4 Configuration réseau du laboratoire 7

5 Détection IDS simple 8

6 Tuning pour réduire les faux positifs 9

6.1 Problème observé........................................................................................................ 9
6.2 Ajout d’un seuil avec threshold ................................................................................. 9

7 Détection d’un comportement suspect 12

7.1 Création d’une règle ICMP Flood ........................................................................... 12
7.2 Test avec de gros paquets ICMP ............................................................................. 15

8 Simulation d’une attaque ICMP Flood avec hping3 16

9 Extension vers le mode IPS 17

10 Résultats obtenus 18

11 Limites du laboratoire 19

12 Recommandations 19
13 Conclusion 19

2
Table des figures
1 Premier test Suricata avec erreur de règles manquantes ........................................ 5
2 Erreur de téléchargement des règles Suricata .......................................................... 6
3 Validation réussie de la configuration Suricata........................................................ 6
4 Erreur de permission lors de l’accès au dossier des logs ......................................... 6
5 Adresse IP de la machine virtuelle en mode NAT.................................................. 7
6 Échec du ping depuis Windows en mode NAT ....................................................... 8
7 Nouvelle adresse IP accessible depuis la machine hôte ........................................... 8
8 Détection du ping depuis Windows par Suricata .................................................... 9
9 Modification de la règle avec un seuil threshold .................................................... 10
10 Relancement de Suricata après modification de la règle...................................... 11
11 Test de ping continu après tuning .......................................................................... 12
12 Réduction des alertes après application du seuil .................................................. 12
13 Test avec 50 paquets ICMP depuis Windows ........................................................ 13
14 Présence d’anciennes alertes PING detected ......................................................... 13
15 Vérification de la règle ICMP Flood dans le fichier Suricata ............................... 14
16 Aucune alerte générée avec un ping normal .......................................................... 15
17 Envoi de gros paquets ICMP depuis Windows ...................................................... 15
18 Erreur DNS lors de l’installation de hping3 .......................................................... 16
19 Détection d’un ICMP Flood avec hping3 .............................................................. 17
20 Simulation IPS avec action drop et indication wDrop ......................................... 18

3
1 Introduction
Dans le domaine de la cybersécurité, les systèmes de détection et de prévention d’in-
trusion jouent un rôle essentiel dans la surveillance du trafic réseau. Cependant, un IDS
ou IPS mal configuré peut générer un grand nombre de fausses alertes, appelées faux
positifs. Ces alertes inutiles rendent l’analyse plus difficile et peuvent masquer les vraies
attaques.
L’objectif de ce mini-projet est de mettre en place un environnement de laboratoire
avec Suricata, de créer des règles personnalisées, de générer du trafic réseau, puis d’amé-
liorer ces règles afin de réduire les faux positifs.

2 Objectifs du projet
Les objectifs principaux de ce travail sont les suivants :
— Installer et configurer Suricata dans une machine virtuelle Ubuntu.
— Créer des règles personnalisées de détection.
— Générer du trafic normal et du trafic suspect.
— Observer les alertes dans les logs.
— Réduire les faux positifs à l’aide du tuning.
— Tester une extension vers un comportement IPS avec l’action drop.

3 Environnement du laboratoire
L’environnement utilisé est composé d’une machine hôte Windows et d’une machine
virtuelle Ubuntu Server exécutée avec Oracle VirtualBox. Suricata est installé dans la
machine virtuelle afin de surveiller le trafic réseau.

3.1 Installation et premier test de Suricata

Après l’installation de Suricata, un premier test de configuration a été réalisé avec la
commande suivante :

sudo suricata -T -c /etc/suricata/[Link]

Au début, Suricata indique que le fichier de règles est introuvable.

4
 FIGURE 1 – Premier test Suricata avec erreur de règles manquantes

Une tentative de mise à jour automatique des règles avec suricata-update a échoué
à cause d’un problème de timeout réseau.

5
 FIGURE 2 – Erreur de téléchargement des règles Suricata

Pour contourner ce problème, un fichier de règles personnalisé a été créé manuellement

dans :

/var/lib/suricata/rules/[Link]

Après cette configuration, Suricata valide correctement le fichier de configuration.

FIGURE 3 – Validation réussie de la configuration Suricata

3.2 Accès aux logs Suricata

Le dossier des logs Suricata est protégé par les permissions système. Une tentative
d’accès sans privilèges administrateur provoque une erreur de permission.

FIGURE 4 – Erreur de permission lors de l’accès au dossier des logs

Pour lire les alertes, la commande suivante est utilisée :

6
sudo tail -f /var/log/suricata/[Link]

4 Configuration réseau du laboratoire

Au départ, la machine virtuelle utilisait une adresse en NAT, ce qui empêchait la
machine hôte Windows de communiquer directement avec elle.

FIGURE 5 – Adresse IP de la machine virtuelle en mode NAT

Le ping depuis Windows vers la machine virtuelle échoue donc dans ce mode réseau.

7
 FIGURE 6 – Échec du ping depuis Windows en mode NAT

Après modification du mode réseau VirtualBox, la machine virtuelle obtient une

adresse accessible depuis Windows.

FIGURE 7 – Nouvelle adresse IP accessible depuis la machine hôte

5 Détection IDS simple

Une première règle simple a été créée afin de détecter les paquets ICMP :

alert icmp any any -> any any (msg:"PING detected"; sid:1000001; rev:1;)

Après lancement de Suricata sur l’interface enp0s3, un ping envoyé depuis Windows
est détecté dans les logs.

8
 FIGURE 8 – Détection du ping depuis Windows par Suricata

Cette étape valide le bon fonctionnement du mode IDS.

6 Tuning pour réduire les faux positifs

6.1 Problème observé
Avec la règle initiale, chaque paquet ICMP génère une alerte. Dans un réseau réel, les
requêtes ping peuvent être normales. Cette règle produit donc beaucoup de faux positifs.

6.2 Ajout d’un seuil avec threshold

Pour réduire le nombre d’alertes répétitives, la règle a été modifiée avec l’option
threshold :

alert icmp any any -> any any

(msg:"PING detected"; itype:8; threshold:type limit, track by_src,
count 1, seconds 20; sid:1000001; rev:2;)

9
 FIGURE 9 – Modification de la règle avec un seuil threshold

Suricata est ensuite relancé pour appliquer la nouvelle règle.

10
 FIGURE 10 – Relancement de Suricata après modification de la règle

Un ping continu est lancé depuis Windows afin d’observer la différence.

11
 FIGURE 11 – Test de ping continu après tuning

Après tuning, les alertes sont moins fréquentes. Cela montre que le seuil limite les
alertes répétitives.

FIGURE 12 – Réduction des alertes après application du seuil

7 Détection d’un comportement suspect

7.1 Création d’une règle ICMP Flood
Pour améliorer la précision de détection, une nouvelle règle a été utilisée avec detection_filter.
Cette règle ne déclenche une alerte que si plusieurs paquets ICMP sont envoyés dans une

12
courte période :

alert icmp any any -> any any

(msg:"ICMP Flood detected"; itype:8;
detection_filter:track by_src, count 10, seconds 5;
sid:1000002; rev:1;)

Un premier test avec ping -n 50 est effectué depuis Windows.

FIGURE 13 – Test avec 50 paquets ICMP depuis Windows

Cependant, les anciennes alertes apparaissent encore dans les logs, ce qui montre l’im-
portance de vérifier que l’ancienne règle n’est plus active.

FIGURE 14 – Présence d’anciennes alertes PING detected

13
 Le fichier de règles est ensuite vérifié afin de s’assurer qu’il contient uniquement la
règle ICMP Flood.

FIGURE 15 – Vérification de la règle ICMP Flood dans le fichier Suricata

Avec un ping normal, aucune alerte n’est générée. Cela prouve que le trafic normal est
ignoré, ce qui réduit les faux positifs.

14
 FIGURE 16 – Aucune alerte générée avec un ping normal

7.2 Test avec de gros paquets ICMP

Un test supplémentaire est réalisé depuis Windows avec des paquets ICMP de grande
taille :

ping [Link] -l 65000 -t

FIGURE 17 – Envoi de gros paquets ICMP depuis Windows

15
8 Simulation d’une attaque ICMP Flood avec hping3
Pour générer un vrai flood ICMP, l’outil hping3 a été utilisé. Une première tentative
d’installation a rencontré une erreur de résolution DNS.

FIGURE 18 – Erreur DNS lors de l’installation de hping3

Après correction, l’outil hping3 permet de générer un flood ICMP avec la commande :

sudo hping3 --icmp --flood [Link]

Suricata détecte alors correctement l’attaque avec le message :

ICMP Flood detected

16
 FIGURE 19 – Détection d’un ICMP Flood avec hping3

9 Extension vers le mode IPS

Après la détection IDS, une petite extension a été ajoutée afin de simuler le compor-
tement IPS. Pour cela, l’action alert a été remplacée par drop :

drop icmp any any -> any any

(msg:"ICMP Flood detected"; itype:8;
detection_filter:track by_src, count 10, seconds 5;
sid:1000002; rev:1;)

Dans les logs, Suricata affiche l’indication wDrop, ce qui signifie que le paquet est
marqué comme devant être bloqué.

17
 FIGURE 20 – Simulation IPS avec action drop et indication wDrop

Il est important de noter que le vrai blocage IPS complet nécessite normalement une
configuration en mode inline avec NFQUEUE et iptables. Dans ce laboratoire, l’objectif
est de montrer le principe du passage d’un mode IDS vers un comportement IPS.

10 Résultats obtenus
Les expérimentations réalisées ont permis d’obtenir les résultats suivants :
— Suricata a été installé et configuré correctement.
— Une règle simple a permis de détecter les requêtes ICMP.
— Le problème des faux positifs a été observé avec la règle initiale.
— L’utilisation de threshold a réduit les alertes répétitives.

18
 — L’utilisation de detection_filter a permis de détecter seulement les comporte-
ments suspects.
— Un ICMP Flood a été simulé avec hping3.
— Une extension IPS a été testée avec l’action drop.

11 Limites du laboratoire
Ce laboratoire reste limité car il est réalisé dans une machine virtuelle avec peu de
ressources. De plus, la configuration IPS complète avec NFQUEUE et iptables n’a pas été
totalement mise en place. Le blocage observé est donc principalement démontré à travers
les logs Suricata avec l’indication wDrop.
Malgré ces limites, le laboratoire permet de comprendre les principes essentiels du
tuning IDS/IPS et de la réduction des faux positifs.

12 Recommandations
Pour améliorer davantage ce projet, il serait possible de :
— Mettre en place Suricata en mode inline réel avec NFQUEUE.
— Ajouter d’autres types d’attaques comme le scan de ports.
— Tester des règles HTTP ou DNS.
— Utiliser un tableau de comparaison avant/après tuning.
— Automatiser la collecte des logs.

13 Conclusion
Ce mini-projet a permis de mettre en place un environnement de laboratoire repro-
ductible pour tester Suricata comme IDS/IPS. Les premières règles ont généré beaucoup
d’alertes, ce qui a permis d’identifier le problème des faux positifs.
Grâce au tuning avec threshold et detection_filter, les alertes inutiles ont été
réduites et seules les activités suspectes ont été détectées. Enfin, l’utilisation de l’action
drop a permis de montrer une extension vers un comportement IPS.
Ce travail démontre l’importance du réglage des règles de sécurité pour améliorer la
précision de détection et réduire le bruit dans les systèmes IDS/IPS.

19