Apache2 et HAProxy + Simulation d’attaque

Environnement

Nous aurons pour ce TP 3 VM 2 serveurs web apache2 et un serveur HAProxy

Serveur Web 1 : 10.0.0.101/24

Serveur Web 2 : 10.0.0.102/24

Serveur HAProxy : 10.0.0.1/24

• Les adresses IP du schéma seront remplacées par celles indiquées dans la section ‘Environnement’. »

2. HAProxy : qu’est-ce que c’est ?

HAProxy (abréviation de High Availability Proxy) est un logiciel libre principalement utilisé pour deux fonctions essentielles :

1. La répartition de charge (load balancing) entre plusieurs serveurs.
2. Le rôle de proxy inverse (reverse proxy).

Plus concrètement :

• Lorsqu’un grand nombre d’utilisateurs accède à un site web, HAProxy peut distribuer leurs requêtes entre plusieurs serveurs web placés derrière lui.
• Il permet d’améliorer les performances, d’assurer une haute disponibilité (si un serveur tombe en panne, HAProxy redirige les requêtes vers les serveurs encore disponibles) et de gérer un trafic important de manière efficace.
• Il prend en charge principalement les protocoles HTTP (web) et TCP (bas niveau).

HAProxy fonctionne à l’aide de deux éléments clés : le frontend et le backend.

---

🔵 Frontend (interface d’entrée)

• C’est l’entrée principale de HAProxy.
• Il reçoit les requêtes des clients (HTTP, TCP, etc.).
• Il analyse la requête : son origine, le port cible, le nom de domaine, etc.
• En fonction de règles (ACL, SNI…), il détermine vers quel backend rediriger la requête.

📷 Image mentale : « C’est le réceptionniste qui accueille les visiteurs et les oriente vers la bonne salle. »

---

🔵 Backend (groupe de serveurs)

• C’est la destination où HAProxy envoie les requêtes après leur traitement par le frontend.
• Un backend regroupe un ou plusieurs serveurs réels (serveurs web, base de données, etc.).
• HAProxy choisit le serveur à utiliser en fonction d’une stratégie de répartition : round-robin, poids attribués, état de santé du serveur, etc.

📷 Image mentale : « C’est la salle où les experts répondent aux visiteurs selon le sujet de leur demande. »

3. Installation des serveurs Apache2 et de HAProxy

🖥️ Création des machines virtuelles

On commence par créer trois machines virtuelles Parrot OS.
Sur deux d’entre elles, nous allons installer Apache2, et sur la troisième, HAProxy.

sudo apt install apache2

Pour qu’apache ce lance en même temps que l’OS on va saisir la commande :

sudo systemctl enable apache2

Ensuite on va démarrer apache2 :

sudo systemctl start apache2

Puis on vérifie l’état du service : :

sudo systemctl status apache2

Définition du nom de serveur :

subl /etc/apache2/apache2.conf

Et on finit sur un petit restart de serveur pour que la modification soit prise en compte :

sudo systemctl restart apache2

Ensuite nous activons quelques mods : pour activer des mobs on utilisera : a2enmod et pour désactiver des mobs: a2dismodsudo

sudo a2enmod rewrite : module utilisé pour la réécriture d’URL

Sudo a2enmod deflate : pour la gestion de la compression, notamment en gzip, pour utiliser la mise en cache des pages sur votre site

Sudo a2enmod headers : afin de pouvoir agir sur les en-têtes HTTP

Sudo a2enmod ssl : pour gérer les certificats SSL et donc l’utilisation du protocole HTTPS

Pour déclarer les hôtes virtuels, en anglais « Virtual hosts », ce qui correspond aux différents sites hébergés par Apache (oui, un serveur Apache peut gérer plusieurs sites indépendamment), il faudra s’intéresser à ces deux dossiers :

Dossier qui contient les fichiers de configuration des sites disponibles : /etc/apache2/sites-available/

Dossier qui contient les fichiers de configuration (via un lien symbolique), des sites actifs : /etc/apache2/sites-enabled

Création des hôtes virtuels sur les serveurs Apache2

Sur chaque serveur Apache2, nous allons créer deux hôtes virtuels (par exemple site1.com et site2.com). Ces fichiers permettent de gérer plusieurs sites web sur un même serveur Apache.

Pour créer les deux Host virtuels sur chaque serveur Apache2.

Subl /etc/apache2/sites-available/site1.com.conf

Subl /etc/apache2/sites-available/site2.com.conf

Configuration des dossiers root et activation des sites Apache

1. Définir les dossiers racines et noms de domaine

Une fois les fichiers de configuration des hôtes virtuels créés (site1.com.conf et site2.com.conf), il est nécessaire de :

• Spécifier le répertoire racine (DocumentRoot)
• Indiquer le nom de domaine (ServerName)

💡 Adaptez ces informations dans chaque fichier en remplaçant site1.com et site2.com selon le serveur concerné.

Création des dossiers racines

Créez maintenant les dossiers que vous avez définis comme DocumentRoot :

Sudo mkdir -p /var/www/site1 /var/www/site1

Faites les même procédures pour les deux virtuals Host et sur chaque serveur apache bien sur. (Au total 4 VH)

Création des pages d’accueil (index)

Ajoutez une page simple dans chaque dossier pour tester les sites :

Echo « Bienvenue sur Site1-Web1 » | sudo tee /var/www/site1/index.html

Echo « Bienvenue sur Site2-Web1 » | sudo tee /var/www/site2/index.html

Activation des sites Apache

Activez les deux sites pour les passer du dossier sites-available vers sites-enabled

Sudo a2ensite site1.com.conf

Sudo a2ensite site2.com.conf

Rechargement de la configuration Apache

Rechargez Apache pour appliquer les modifications :

Sudo systemctl reload apache2

Configuration du fichier /etc/hosts

Pour que les noms de domaine (site1.com, site2.com, etc.) soient correctement résolus, ajoutez une entrée dans le fichier /etc/hosts sur les trois serveurs (les deux Apache et HAProxy) en pointant vers l’adresse IP du serveur HAProxy :

Ensuite sur la troisième VM on va installer haproxy :

Sudo apt install haproxy -y

On oublie pas le « enable » et le « start » pour démarrer le service.

On ce rend sur le fichier de configuration HAProxy pour le configurer /etc/haproxy/haproxy.cfg.

Explication de la configuration :

1. Section global

Paramètres globaux qui s’appliquent à tout le processus HAProxy.

log /dev/log local0
log /dev/log local1 notice


• log /dev/log localX : Définit où les logs seront envoyés (ici au syslog local).
• local0 et local1 notice sont des niveaux de journalisation (info, notice, debug…).

chroot /var/lib/haproxy

• Sécurité : restreint HAProxy à ce répertoire, limitant les dégâts potentiels en cas de faille.

stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s

• Socket admin : permet un contrôle/monitoring via une socket Unix.
• timeout : durée maximale d’inactivité sur cette socket.

user haproxy
group haproxy
daemon

• user/group : exécution sous l’utilisateur haproxy (meilleure sécurité).
• daemon : exécution en tâche de fond.

ca-base /etc/ssl/certs
crt-base /etc/ssl/private

• Répertoires par défaut des certificats SSL (utile pour HTTPS).

ssl-default-bind-ciphers ...
ssl-default-bind-ciphersuites ...
ssl-default-bind-options ...

• Définit les algorithmes SSL/TLS autorisés (meilleure sécurité).
• TLSv1.2 minimum + désactivation des tickets TLS pour éviter la réutilisation de sessions compromises.

---

2. Section defaults

Valeurs par défaut utilisées pour tous les frontends et backends sauf indication contraire.


log global
mode http


• log global : hérite des paramètres de log de la section global.
• mode http : indique que HAProxy manipule des connexions HTTP.

option httplog
option dontlognull

• httplog : logs détaillés du trafic HTTP.
• dontlognull : évite de logguer les connexions sans données (utile pour ne pas surcharger les logs).

timeout connect 5
timeout client 50
timeout server 50

• timeouts : délai (en secondes) d’attente pour établir une connexion (connect), recevoir une requête (client), et répondre à une requête (server).

errorfile 400 /etc/haproxy/errors/400.http
...

• Fichiers personnalisés pour les erreurs HTTP (400, 403, 408, 500, etc.).

---

3. Section frontend http_front

Point d’entrée HTTP (port 80), où HAProxy reçoit les requêtes.

frontend http_front
bind *:80

• Écoute sur toutes les interfaces au port 80 (HTTP).

acl site1_acl hdr(host) -i site1.com
acl site2_acl hdr(host) -i site2.com

• ACL (Access Control Lists) : conditions pour diriger le trafic en fonction du nom de domaine demandé (Host HTTP header).

use_backend site1_back if site1_acl
use_backend site2_back if site2_acl
use_backend site1_back

• Redirige le trafic vers le backend approprié en fonction des ACL.
• La dernière ligne est une valeur par défaut si aucune ACL ne correspond.

---

4. Section backend site1_back et site2_back

Serveurs vers lesquels HAProxy redirige les requêtes.

site1_back :

backend site1_back
option httpchk
balance roundrobin
server web1_site1a 10.0.0.101:80 check weight 50
server web2_site1b 10.0.0.102:80 check weight 50

• httpchk : vérifie que les serveurs HTTP répondent.
• balance roundrobin : répartit les requêtes de manière équitable (tour à tour).
• check : active le health-check (vérifie que le serveur est disponible).
• weight : pondération de la répartition (ici équilibrée : 50/50).

site2_back :

backend site2_back
option httpchk
balance roundrobin
server web1_site2a 10.0.0.101:80 check weight 80
server web2_site2b 10.0.0.102:80 check weight 20

• Même principe que ci-dessus, mais avec une répartition 80/20, donc web1 reçoit 4 fois plus de trafic que web2.

A partir de là. Si dans mon navigateur je saisie site1.com je vais avoir le site1 du serveur web apache2 (n°1) qui va apparaitre et si je refresh 1fois la page j’ai le site1 du serveur web apacha2 (n°2) qui s’affiche en répartition donc 50/50.

Donc cela me permet de repartir la charge entre les deux serveurs et si un de mes serveurs tombe l’autre me permettra tout de même d’accéder à mon site1. Il en va de même pour le site2 mais avec une répartition 80/20 donc 4 requêtes sur le apache2 (n°1) et 1 sur le apache2 (n°2).

On va finir la configuration du fichier HAProxy avec une partie particulièrement importante c’est à dire les statistiques : Dans le fichier de configuration nous allons ajouter un paragraphe :

Crée une interface web disponible sur le port 8404.

Donc il nous faudra simplement saisir dans le navigateur le site1.com par exemple et d’y ajouter le port d’écoute :8404 pour être redirigé sur :

On va finir par une petite simulation d’attaque sur nos serveurs :

Simulation d’attaque

Qu’est-ce que Slowloris ?

Slowloris est une attaque de type DoS (Denial of Service) qui fonctionne de manière lente et discrète. Elle consiste à ouvrir de nombreuses connexions HTTP vers un serveur web, sans jamais les terminer complètement.
Le serveur garde ces connexions ouvertes en attente, ce qui sature ses ressources. Au bout d’un certain nombre, il devient incapable de traiter les requêtes des utilisateurs légitimes, provoquant ainsi une indisponibilité du service.

---

Se protéger avec Fail2Ban

Fail2Ban est un outil de sécurité permettant de détecter les comportements suspects dans les fichiers de logs et de bannir automatiquement les adresses IP concernées.
Il est donc capable d’atténuer certaines attaques DoS comme Slowloris, en bloquant les IP à l’origine de connexions anormales.

Nous allons donc installer une nouvelle VM (kali) pour ma part.

Ensuite nous allons télécharger Slowloris :

sudo git clone https://github.com/gkbrk/slowloris.git.

Ensuite accédez au répertoire de ce dernier :

cd slowloris

Puis nous allons lancer l’attaque :

Sudo python3 slowloris.py 10.0.0.101 -p 80 -s 15.

On constate que c’est un scrip python, on le lance sur l’IP du serveur apache2 (n°1) sur le port 80 et on lance 15sockets (requêtes).

Pendant l’attaque, vous pouvez surveiller les connexions entrantes sur le port 80 avec la commande suivante

netstat -ant | grep ‘:80’ 

Avec un nombre plus important de sockets on pourrait facilement faire tomber le serveur.

Nous allons donc mettre en place fail2ban pour protéger nos serveurs :

Mise en place de Fail2Ban pour protéger les serveurs web

Installation de Fail2Ban

Sur chacun des serveurs web, commencez par installer Fail2Ban avec la commande suivante :

Sudo apt update && sudo apt install fail2ban -y

Fail2Ban c’est quoi ? C’est un outil de sécurité pour les serveurs Linux.
Il protège automatiquement les services (comme SSH, Apache, FTP…) contre les attaques malveillantes.

1. Surveillance des logs

Fail2Ban lit en temps réel les fichiers de logs, comme par exemple :

• /var/log/auth.log (pour SSH),
• /var/log/apache2/error.log (pour Apache).

2. Détection de comportements suspects

Fail2Ban repère des schémas d’erreurs ou de comportements anormaux, comme :

• Trop de tentatives de connexion SSH échouées (brute force),
• Requêtes HTTP suspectes ou en trop grand nombre (ex. attaque DoS, Slowloris).

3. Réaction automatique

Lorsqu’une IP dépasse un seuil défini :

• Elle est bannie (souvent via iptables, ou nftables selon le système),
• Le bannissement est temporaire (par défaut : 10 minutes, mais configurable).

Structure de Fail2Ban

• Filtres : Définissent quoi détecter dans les logs (ex : sshd, apache-auth, etc.).
• Jails : Ce sont les règles de protection : un filtre + une action (ex : bannir via iptables).
• Actions : Ce que Fail2Ban fait quand une menace est détectée (bannir, envoyer un mail, etc.).

Configuration de base

Pour configurer Fail2Ban, on modifie le fichier : /etc/fail2ban/jail.local

Dans ce fichier, on peut définir des protections spécifiques.
Exemple de configuration à ajouter pour :

• SSH
• Apache avec protection contre Slowloris (via un filtre personnalisé que nous verrons ensuite)

Ensuite, on redémarre le service Fail2Ban et on vérifie son statut pour s’assurer que tout fonctionne correctement :

sudo systemctl restart fail2ban

sudo systemctl status fail2ban

Ajout d’un filtre pour détecter Slowloris

Nous allons maintenant créer un filtre personnalisé pour détecter une attaque de type Slowloris.

sudo subl /etc/fail2ban/filter.d/slowloris.conf

Ajoutez le contenu suivant dans le fichier :

[Definition]

failregex = ^<HOST> -.* »(GET|POST).*HTTP.*$

ignoreregex =

Ce filtre détecte les requêtes HTTP incomplètes ou répétitives issues d’une même IP, typiques d’une attaque Slowloris.

Vérification avec Fail2Ban-client

Pour vérifier si le filtre est bien pris en compte et actif, utilisez la commande suivante :

Vérification avec Fail2Ban-client

Pour vérifier si le filtre est bien pris en compte et actif, utilisez la commande suivante :

sudo Fail2Ban-client status slowloris

Et pendant l’attaque à présent :

L’IP de l’attaquant a bien été bannie.

Limites de Fail2Ban face aux attaques DDoS

Fail2Ban est un outil très utile pour se protéger contre les petites et moyennes attaques, comme les tentatives de brute force ou certains types de DoS.
Cependant, il montre rapidement ses limites face à des attaques DDoS plus complexes et massives.

❌ Pourquoi Fail2Ban ne suffit pas contre une attaque DDoS :

• Une attaque DDoS peut générer des millions de requêtes par seconde.
• Elle utilise souvent des milliers d’adresses IP différentes (botnet).
• Fail2Ban analyse les logs : c’est un processus trop lent pour suivre le rythme d’une DDoS.
• Certaines attaques utilisent la rotation d’IP, rendant Fail2Ban quasiment inutile dans ce contexte.
• Il n’est pas conçu pour le traitement en temps réel à grande échelle.

✅ Alternatives ou compléments à Fail2Ban :

• HAProxy avec des règles de limitation de connexion.
• iptables avec des règles de limitation de débit (rate limiting).
• Pare-feux matériels ou services cloud anti-DDoS (Cloudflare, AWS Shield…).