République de Côte d’Ivoire
Union – Discipline – Travail
Ministère de l’Enseignement Supérieur et de la Recherche
Scientifique
SECURITE DES SYSTEMES D’INFORMATION
THÈME
Simulation d'une attaque par déni de service et étude des mesures
de prévention
Groupe 4
Enseignant Réalisé par
Dr. Itachi Shikamaru Nara
Année académique : 2024 – 2025
Simulation d'une attaque par déni de service et étude des mesures de
prévention
SOMMAIRE
SOMMAIRE ............................................................................................................................... I
INTRODUCTION ...................................................................................................................... 1
1. Mise en place de l’environnement................................................................................... 2
2. Simulation de l’attaque DoS ........................................................................................... 4
3. Étude des mesures de prévention .................................................................................... 7
4. Résultats et analyse ....................................................................................................... 11
CONCLUSION ........................................................................................................................ 14
BIBLIOGRAPHIE ................................................................................................................... IX
WEBOGRAPHIE ...................................................................................................................... X
TABLE DES MATIÈRES ....................................................................................................... XI
I
Simulation d'une attaque par déni de service et étude des mesures de
prévention
INTRODUCTION
Les attaques par déni de service (DoS) constituent une menace majeure pour les systèmes
informatiques modernes. Elles visent à rendre un service ou une ressource indisponible en
saturant ses capacités. Ce travail pratique a pour objectif de simuler une attaque DoS dans un
environnement contrôlé afin de mieux comprendre ses mécanismes et d'étudier les mesures de
prévention adaptées. Ce rapport détaille la mise en œuvre de l’attaque, les résultats observés et
les solutions proposées pour y faire face.
1
Simulation d'une attaque par déni de service et étude des mesures de
prévention
1. Mise en place de l’environnement
Pour réaliser la simulation d’une attaque par déni de service (DoS) dans un cadre sécurisé, un
environnement virtuel a été mis en place. Cet environnement se compose de deux machines
virtuelles : une machine "cible" hébergeant un serveur web, et une machine "attaquante"
équipée d’outils pour générer l’attaque. Les étapes suivantes décrivent en détail les composants
et leur configuration.
1.1. Choix de l’environnement de virtualisation
Pour garantir un isolement complet du réseau et éviter tout impact sur des systèmes réels, l’outil
VirtualBox a été utilisé. Cet hyperviseur gratuit et open-source permet de créer et gérer
plusieurs machines virtuelles sur un hôte unique.
Les machines virtuelles ont été configurées avec les paramètres suivants :
• Réseau : Mode "Réseau interne" (Internal Network) pour permettre la communication
uniquement entre les VMs, sans accès à Internet.
• Ressources matérielles : Chaque machine dispose de 2 cœurs CPU et 2 Go de RAM,
suffisants pour le scénario du TP.
1.2. Configuration de la machine "cible"
La machine "cible" représente un serveur web exposé à une potentielle attaque. Elle a été
configurée comme suit :
• Système d’exploitation : Debian 11 (Bullseye).
• Logiciel serveur : Apache HTTP Server, version 2.4.
• Adresse IP : Une adresse statique de type privé a été assignée, par exemple
[Link].
• Rôle : Hébergement d’un site web minimaliste accessible via le protocole HTTP sur le
port 80.
2
Simulation d'une attaque par déni de service et étude des mesures de
prévention
Pour vérifier le bon fonctionnement du serveur, un fichier HTML basique a été déployé et testé
à l’aide d’un navigateur web depuis une autre VM (Fig. 1).
Capture d’écran suggérée : Interface de configuration réseau de la machine "cible" montrant
l’adresse IP et les paramètres réseau.
1.3. Configuration de la machine "attaquante"
La machine "attaquante" est utilisée pour générer des requêtes malveillantes et surcharger le
serveur cible. Voici sa configuration :
• Système d’exploitation : Ubuntu 22.04 (Jammy Jellyfish).
• Outils installés :
1. hping3 : Pour simuler des attaques de type SYN flood.
▪ Installation: sudo apt-get install hping3.
2. Nmap : Pour scanner et vérifier les ports ouverts sur le serveur cible avant
l’attaque.
▪ Installation: sudo apt-get install nmap.
• Adresse IP : Une adresse statique privée a été configurée, par exemple
[Link].
Capture d’écran suggérée : Terminal montrant les outils installés sur la machine attaquante.
1.4. Vérification de la connectivité réseau
Avant de lancer la simulation, la connectivité entre les deux machines virtuelles a été testée :
• Une commande ping a été envoyée depuis la machine attaquante vers la machine
cible
ping [Link]
Le retour des paquets (temps de réponse) a confirmé que les deux machines pouvaient
communiquer efficacement au sein du réseau interne (Fig. 2).
3
Simulation d'une attaque par déni de service et étude des mesures de
prévention
Capture d’écran suggérée : Résultat de la commande ping montrant une connectivité
réussie.
1.5. Diagramme de l’environnement
Pour mieux visualiser l’architecture mise en place, un diagramme simplifié est présenté ci-
dessous :
Machine Attaquante Machine Cible
Ubuntu 22.04 Debian 11
IP: [Link] IP: [Link]
hping3, Nmap Apache Web Server
Ce diagramme illustre les interactions entre les deux machines au sein du réseau interne.
Conclusion de la section
Cet environnement virtuel garantit une isolation totale des tests, tout en offrant une plateforme
réaliste pour simuler une attaque DoS et en analyser les impacts. La configuration rigoureuse
des deux machines permet de reproduire un scénario typique de vulnérabilité à une attaque DoS.
2. Simulation de l’attaque DoS
L’objectif de cette section est de simuler une attaque par déni de service (DoS) afin de saturer
les ressources du serveur cible. Une attaque de type SYN Flood a été choisie, car elle est
couramment utilisée pour provoquer une indisponibilité d’un service en surchargeant sa pile
réseau.
2.1. Principe de l’attaque SYN Flood
L’attaque SYN Flood consiste à exploiter la phase d’établissement de connexion TCP (le three-
way handshake). L’attaquant envoie un grand nombre de requêtes TCP avec le drapeau SYN
4
Simulation d'une attaque par déni de service et étude des mesures de
prévention
activé mais ne complète jamais la connexion. Cela force le serveur à maintenir des connexions
incomplètes, épuisant ainsi ses ressources.
2.2. Commandes utilisées avec hping3
Pour générer l’attaque SYN Flood, l’outil hping3 a été utilisé. Il permet de manipuler les
paquets réseau pour simuler des attaques. La commande suivante a été exécutée sur la machine
attaquante :
sudo hping3 -S -p 80 --flood --rand-source [Link]
• Explication des options :
o -S : Active le drapeau SYN dans les paquets TCP.
o -p 80 : Spécifie le port cible (port 80, utilisé par le serveur HTTP).
o --flood : Envoie des paquets en continu sans attendre de réponse.
o --rand-source : Génère des adresses IP source aléatoires pour rendre l’attaque
plus difficile à tracer.
o [Link] : Adresse IP de la machine cible.
Résultat attendu : Cette commande envoie un flot massif de requêtes SYN vers le serveur
web, forçant ce dernier à gérer un grand nombre de connexions incomplètes, ce qui épuise ses
ressources.
Capture d’écran suggérée : Terminal montrant la commande hping3 en cours d’exécution.
2.3. Monitoring des ressources du serveur cible
Pendant l’attaque, les performances du serveur cible ont été surveillées à l’aide de la commande
suivante sur la machine cible :
htop
• htop est un outil interactif qui affiche en temps réel l’utilisation du CPU, de la mémoire
et des processus actifs.
5
Simulation d'une attaque par déni de service et étude des mesures de
prévention
• Observations :
o Une augmentation significative de l’utilisation CPU (>90 %).
o Une saturation de la mémoire.
o Des connexions en attente dans la file d’attente du serveur.
Capture d’écran suggérée : Interface de htop montrant les ressources système
(CPU/mémoire) sous forte charge.
2.4. Résultat de l’attaque
Les conséquences de l’attaque SYN Flood sont les suivantes :
1. Indisponibilité du service : Le site hébergé sur le serveur cible devient inaccessible
(le navigateur affiche une erreur de délai d’attente).
2. Saturation des ressources : Les métriques CPU et mémoire du serveur atteignent des
niveaux critiques.
3. Analyse des logs : Une inspection des fichiers de log du serveur web
(/var/log/apache2/[Link]) montre un grand nombre de connexions non
abouties.
Exemple d’erreur dans les logs :
[error] server reached MaxClients setting, consider raising the MaxClients
setting
Capture d’écran suggérée :
1. Navigateur web affichant une erreur de connexion au serveur cible.
2. Contenu du fichier [Link] montrant les connexions massives.
2.5. Limites et précautions
• Impact limité au réseau virtuel : L’attaque a été menée dans un environnement isolé
pour éviter tout impact sur des systèmes réels.
6
Simulation d'une attaque par déni de service et étude des mesures de
prévention
• Simulation contrôlée : La durée de l’attaque a été volontairement limitée pour éviter
de provoquer un crash irréversible du serveur.
Conclusion de la section
Cette simulation a permis de démontrer l’impact d’une attaque SYN Flood sur un serveur web
mal protégé. L’utilisation de hping3 a facilité la génération d’un trafic malveillant massif, et le
monitoring des ressources a confirmé la saturation des capacités du serveur. Ces résultats
serviront de base pour l’étude des contre-mesures dans la section suivante.
3. Étude des mesures de prévention
Après avoir observé les effets d'une attaque par déni de service (DoS), il est crucial de mettre
en place des contre-mesures pour sécuriser le serveur cible contre de futures attaques. Cette
section présente les mesures de prévention testées, à savoir : la configuration du pare-feu avec
iptables, l’implémentation d’un Web Application Firewall (WAF), et l’utilisation d’un
Système de Détection d’Intrusion (IDS) pour détecter les attaques en temps réel.
3.1. Configuration du pare-feu avec iptables
Le premier moyen de défense contre une attaque DoS est d'utiliser un pare-feu pour bloquer
une partie du trafic malveillant avant qu'il atteigne le serveur. Iptables, un outil de filtrage
de paquets sous Linux, a été utilisé pour mettre en place des règles de filtrage afin de limiter
l'impact de l'attaque.
Règles appliquées :
Les règles suivantes ont été configurées pour empêcher les attaques SYN Flood :
1. Limiter le nombre de connexions simultanées par IP : Cela permet de réduire les
risques d’épuiser les ressources du serveur en limitant le nombre de connexions par
adresse IP.
7
Simulation d'une attaque par déni de service et étude des mesures de
prévention
sudo iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above
10 -j REJECT --reject-with tcp-reset
2. Activer la protection contre les attaques SYN Flood : Cela permet de limiter le
nombre de connexions incomplètes dans le backlog, réduisant ainsi la vulnérabilité
aux attaques SYN Flood.
sudo iptables -A INPUT -p tcp --syn --dport 80 -m state --state NEW -j ACCEPT
3. Bloquer les adresses IP source suspectes : Utiliser une règle pour bloquer les IPs qui
tentent d’envoyer un volume de paquets trop élevé.
sudo iptables -A INPUT -s [Link] -j DROP
Ces règles permettent de filtrer le trafic réseau entrant et d’atténuer les effets d'une attaque
DoS.
Capture d’écran suggérée :
Affiche une capture d’écran de la sortie de la commande iptables -L qui montre les règles
appliquées sur le serveur.
3.2. Mise en place d’un WAF
Un Web Application Firewall (WAF) est une autre couche de défense qui inspecte et filtre les
requêtes HTTP envoyées au serveur web pour bloquer le trafic malveillant avant qu’il
n’atteigne l'application. Pour cette simulation, un WAF basé sur ModSecurity, intégré à
Apache, a été utilisé.
Configuration du WAF :
1. Installation de ModSecurity sur le serveur cible :
sudo apt-get install libapache2-mod-security2
8
Simulation d'une attaque par déni de service et étude des mesures de
prévention
2. Activation et configuration de ModSecurity : ModSecurity est activé et configuré
pour utiliser un ensemble de règles de filtrage (OWASP ModSecurity Core Rule Set).
sudo a2enmod security2
sudo systemctl restart apache2
3. Création d’une règle personnalisée pour détecter et bloquer les requêtes anormales
(comme celles générées par l'attaque DoS). Exemple de règle dans le fichier
/etc/modsecurity/[Link] :
SecRule REQUEST_METHOD "^(GET|POST)$"
"id:1001,phase:1,deny,status:403,msg:'Potential DoS Attack Detected'"
Ces étapes ont permis d'ajouter une couche supplémentaire de protection au serveur cible, en
filtrant le trafic HTTP avant qu’il n'atteigne l'application.
Capture d’écran suggérée :
Affiche une capture d’écran des logs générés par ModSecurity, où l’on peut voir les requêtes
bloquées par le WAF.
3.3. Tests de détection avec un IDS
Un Système de Détection d’Intrusion (IDS) a été utilisé pour détecter en temps réel les
attaques réseau et alerter les administrateurs. Pour ce test, un IDS open-source comme Suricata
ou Snort a été installé sur la machine cible.
Configuration de l'IDS :
1. Installation de Suricata :
sudo apt-get install suricata
9
Simulation d'une attaque par déni de service et étude des mesures de
prévention
2. Configuration de Suricata pour la détection des attaques DoS : Les règles par défaut
de Suricata incluent déjà des signatures pour la détection des attaques DoS. Nous avons
spécifiquement surveillé les paquets SYN suspects générés par l'attaque SYN Flood.
3. Lancement de Suricata en mode IDS : Pour démarrer Suricata en mode IDS et générer
des alertes, la commande suivante a été exécutée :
sudo suricata -c /etc/suricata/[Link] -i eth0
Lors de l'attaque, Suricata a détecté un grand nombre de tentatives de connexions SYN sans
réponse et a généré des alertes correspondantes.
Capture d’écran suggérée :
Affiche une capture d’écran des logs générés par l'IDS, où l’on peut observer les alertes liées
à l'attaque DoS (par exemple, alertes SYN Flood).
3.4. Amélioration des performances après les ajustements
Une fois les mesures de prévention mises en place, des tests de performance ont été réalisés
pour observer l'impact de ces ajustements sur les performances du serveur.
1. Tests avant les ajustements : Avant l'application des règles de sécurité, le serveur était
complètement saturé et l’accès à l’application était impossible.
2. Tests après les ajustements : Après l’activation d'iptables, du WAF et de l'IDS, les
performances se sont améliorées. Le serveur a continué à répondre aux requêtes
légitimes, et l’attaque a été efficacement bloquée.
Les ressources CPU et mémoire ont été surveillées pendant et après l’attaque avec htop pour
mesurer les effets des contre-mesures.
Capture d’écran suggérée :
Affiche une capture d’écran de htop montrant une utilisation des ressources nettement plus
faible après l'activation des mesures de prévention. Cette mesure a permis de réduire la
10
Simulation d'une attaque par déni de service et étude des mesures de
prévention
surcharge sur le serveur cible, comme le montre la Fig. 4, où l'utilisation CPU est restée en
dessous de 30 %.
Conclusion de la section
Les contre-mesures mises en place ont montré leur efficacité dans la protection du serveur
contre l'attaque DoS. La configuration d'iptables a permis de filtrer le trafic malveillant, le WAF
a ajouté une couche de protection HTTP supplémentaire, et l'IDS a détecté l'attaque en temps
réel, permettant ainsi de réagir rapidement. Ces mesures combinées ont amélioré la résilience
du serveur face aux attaques de type DoS, tout en préservant ses performances et sa disponibilité
pour les utilisateurs légitimes.
4. Résultats et analyse
4.1. Impact de l’attaque sur le serveur cible
L'attaque par déni de service (DoS) a eu un impact significatif sur le serveur cible. Avant
l'application des mesures de prévention, le serveur était complètement submergé par le volume
massif de requêtes, entraînant une indisponibilité totale du service.
• Surcharge du serveur : L'attaque SYN Flood a saturé les ressources du serveur, en
particulier la capacité de traitement des connexions TCP. En conséquence, le serveur
n'a pas pu établir de nouvelles connexions, ce qui a entraîné des erreurs telles que "503
Service Unavailable" ou "502 Bad Gateway", visibles dans les logs et sur
l'interface utilisateur du serveur.
• Absence de réponse aux requêtes légitimes : Pendant l'attaque, les utilisateurs
légitimes ont rencontré des délais de connexion longs et, dans certains cas,
l’impossibilité d’accéder au serveur. Les logs du serveur ont montré des tentatives
répétées de connexions échouées, ce qui a confirmé la saturation des ressources
disponibles.
Les performances du serveur ont chuté de manière drastique, avec une utilisation élevée du
CPU et de la mémoire, indiquant que les ressources étaient épuisées par le trafic d'attaque.
11
Simulation d'une attaque par déni de service et étude des mesures de
prévention
4.2. Efficacité des mesures de prévention
Les mesures de prévention mises en place ont montré une efficacité notable pour atténuer les
effets de l'attaque DoS et restaurer la disponibilité du serveur.
1. Configuration du pare-feu avec iptables :
o Les règles définies ont permis de limiter le nombre de connexions par IP et
d'accepter uniquement les connexions légitimes. Après l'activation du pare-feu,
la saturation du serveur a été réduite, et une partie importante du trafic
malveillant a été bloquée avant qu'il ne parvienne au serveur.
o L'impact de l'attaque a été considérablement diminué, et les erreurs de connexion
ont été moins fréquentes, ce qui a montré que les connexions par IP malveillantes
ont été filtrées efficacement.
2. Mise en place du Web Application Firewall (WAF) :
o Le WAF (ModSecurity) a joué un rôle crucial dans la filtration du trafic HTTP.
Il a permis de bloquer les requêtes malveillantes à un niveau plus élevé, en
analysant les signatures d’attaque.
o Les logs générés ont montré que les requêtes provenant de l'attaque DoS ont été
interceptées, et le serveur a continué à répondre aux utilisateurs légitimes. Cela
a montré que le WAF a bien contribué à la défense contre l’attaque.
3. Utilisation d'un Système de Détection d'Intrusion (IDS) :
o Le système IDS (Suricata) a détecté les paquets SYN suspects générés par
l'attaque. Les alertes générées ont permis de visualiser l'ampleur de l'attaque en
temps réel, ce qui a aidé à réagir rapidement.
o Bien que l'IDS n’ait pas directement bloqué l'attaque, il a permis de fournir des
informations critiques sur la nature de l'attaque, facilitant la prise de décision
pour appliquer d’autres contre-mesures.
Dans l'ensemble, l’efficacité des mesures de prévention a été largement prouvée, avec un
blocage significatif du trafic malveillant et une amélioration de la disponibilité du serveur.
12
Simulation d'une attaque par déni de service et étude des mesures de
prévention
4.3. Comparaison des performances avant et après l’application des contre-
mesures
Une analyse comparative des performances du serveur avant et après l’application des contre-
mesures a permis de constater des améliorations significatives.
• Avant les contre-mesures :
o Le serveur était extrêmement lent et non réactif en raison de la surcharge générée
par l’attaque. L’utilisation du CPU et de la mémoire était élevée
o Le fichier [Link] a montré une multiplication des requêtes sans réponse
complète, illustrant l’incapacité du serveur à traiter les demandes.
o Le serveur ne répondait pas aux requêtes HTTP de manière fiable
• Après l’application des contre-mesures :
o L’impact de l’attaque a été significativement réduit. Le serveur est resté
accessible et fonctionnel, avec un temps de réponse plus rapide.
o L'utilisation des ressources (CPU et mémoire) est revenue à un niveau normal.
o Le nombre d’erreurs dans les logs a diminué
Capture d’écran suggérée :
• Avant les contre-mesures : Capture d'écran de htop ou top montrant une utilisation
CPU élevée et une mémoire saturée avant l'activation des mesures.
• Après les contre-mesures : Capture d'écran de htop montrant une réduction de
l’utilisation du CPU et de la mémoire après l'application des contre-mesures.
Conclusion de la section
Les mesures de prévention mises en place, incluant un pare-feu, un WAF et un IDS, ont
efficacement bloqué les connexions malveillantes tout en préservant les performances du
serveur pour les utilisateurs légitimes. L'impact de l'attaque a été atténué, et la disponibilité du
serveur a été restaurée. Cette analyse montre que des contre-mesures appropriées peuvent
renforcer la résilience d'un système face aux attaques DoS.
13
Simulation d'une attaque par déni de service et étude des mesures de
prévention
CONCLUSION
Ce travail pratique a permis de mieux comprendre les mécanismes d’une attaque par déni de
service et les moyens de s’en protéger. La simulation a mis en évidence l’impact significatif
d’un flux de trafic malveillant sur les ressources serveur. Les contre-mesures testées ont
démontré leur efficacité, bien que certaines, comme les règles iptables, nécessitent des
ajustements selon le contexte. Ce TP ouvre des perspectives pour l’étude de solutions plus
avancées, telles que les CDN et les systèmes d’intelligence artificielle pour la détection des
menaces.
14
Simulation d'une attaque par déni de service et étude des mesures de
prévention
BIBLIOGRAPHIE
➢ Livres
• Booch, G., Rumbaugh, J., & Jacobson, I. (2005). The Unified Modeling Language
User Guide (2nd ed.). Addison-Wesley.
• Fowler, M. (2004). UML Distilled: A Brief Guide to the Standard Object Modeling
Language (3rd ed.). Addison-Wesley.
• Davis, A. (2008). Distributed Systems: Principles and Paradigms. Prentice Hall.
IX
Simulation d'une attaque par déni de service et étude des mesures de
prévention
WEBOGRAPHIE
[1] " OMG UML. (n.d.). Retrieved from" [Link] Consulté le
30/10/2024
[2] "Cisco. (2021). The Internet of Things: How it Works and Why It Matters. Retrieved from
[Link] Consulté le
30/10/2024.
[3] Zigbee Alliance. (n.d.). Zigbee: The Internet of Things (IoT) Standard. Retrieved from
[Link] Consulté le 30/10/2024.
[4] IBM Cloud Learn Hub. (2022). What is a Distributed System?. Retrieved from
[Link] Consulté le 30/10/2024.
X
Simulation d'une attaque par déni de service et étude des mesures de
prévention
TABLE DES MATIÈRES
SOMMAIRE ............................................................................................................................... I
INTRODUCTION ...................................................................................................................... 1
1. Mise en place de l’environnement................................................................................... 2
1.1. Choix de l’environnement de virtualisation ............................................................. 2
1.2. Configuration de la machine "cible" ........................................................................ 2
1.3. Configuration de la machine "attaquante" ............................................................... 3
1.4. Vérification de la connectivité réseau ...................................................................... 3
1.5. Diagramme de l’environnement............................................................................... 4
Conclusion de la section ..................................................................................................... 4
2. Simulation de l’attaque DoS ........................................................................................... 4
2.1. Principe de l’attaque SYN Flood ............................................................................. 4
2.2. Commandes utilisées avec hping3 ........................................................................... 5
2.3. Monitoring des ressources du serveur cible ............................................................. 5
2.4. Résultat de l’attaque ................................................................................................. 6
2.5. Limites et précautions .............................................................................................. 6
Conclusion de la section ..................................................................................................... 7
3. Étude des mesures de prévention .................................................................................... 7
3.1. Configuration du pare-feu avec iptables .................................................................. 7
3.2. Mise en place d’un WAF ......................................................................................... 8
3.3. Tests de détection avec un IDS ................................................................................ 9
3.4. Amélioration des performances après les ajustements .......................................... 10
Conclusion de la section ................................................................................................... 11
4. Résultats et analyse ....................................................................................................... 11
4.1. Impact de l’attaque sur le serveur cible ................................................................. 11
4.2. Efficacité des mesures de prévention ..................................................................... 12
4.3. Comparaison des performances avant et après l’application des contre-mesures . 13
Conclusion de la section ................................................................................................... 13
CONCLUSION ........................................................................................................................ 14
BIBLIOGRAPHIE ................................................................................................................... IX
WEBOGRAPHIE ...................................................................................................................... X
TABLE DES MATIÈRES ....................................................................................................... XI
XI
