Aller au contenu principal

DoS et DDoS

Déni de service (DoS) et DDoS : Comprendre et se protéger

Notions théoriques​

Un déni de service (DoS) est une attaque informatique qui vise à rendre un service indisponible en le surchargeant de requêtes.

info

L'attaque par déni de service a pour objectif est d'empêcher les utilisateurs légitimes d'accéder à un site Web, une application ou un serveur.

Comment fonctionne une attaque DoS ?​

Une attaque DoS consiste à envoyer une grande quantité de requêtes vers une cible (serveur, site web, API) pour saturer ses ressources (processeur, mémoire, bande passante).

Résultat : le service devient lent ou totalement inaccessible.

Différence entre DoS et DDoS​

  • DoS (Denial of Service) : Une seule machine attaque une cible.

  • DDoS (Distributed Denial of Service) : Plusieurs machines attaquent une cible simultanément.

info

Les machines, qui attaquent une cible simultanément, sont souvent des ordinateurs infectés (botnets) contrôlés à distance par un attaquant.

Types d'attaques DoS/DDoS​

  • Saturation de la bande passante : Envoi massif de données pour épuiser la connexion réseau.
  • Saturation des ressources serveur : Envoi de requêtes complexes pour surcharger le CPU et la mémoire.
  • Exploitation de vulnérabilités : Utilisation de failles pour provoquer un crash du service.

Conséquences d'une attaque DoS/DDoS​

  • Indisponibilité du service : Impossible d’accéder au site ou à l’application.
  • Pertes financières : Une entreprise peut perdre des clients et de l’argent.
  • Atteinte à la réputation : Un site souvent indisponible perd la confiance de ses utilisateurs.

Comment se protéger ?​

  • Limiter le nombre de requêtes par utilisateur avec un pare-feu ou un proxy.
  • Utiliser un réseau de distribution de contenu (CDN) pour absorber le trafic.
  • Détecter les comportements suspects avec un système de détection d’intrusion (IDS).
  • Bloquer les adresses IP suspectes avec un pare-feu.
  • Utiliser des services anti-DDoS comme Cloudflare, Akamai ou AWS Shield.

Exemple pratique​

Cas concret : Une attaque DDoS sur un site web

Un site e-commerce est victime d’une attaque DDoS orchestrée par un groupe de hackers.

Déroulement de l’attaque :

  1. Les hackers infectent des milliers d’ordinateurs avec un malware, créant ainsi un botnet.
  2. À un moment précis, ils ordonnent à ces machines d’envoyer des millions de requêtes vers le site e-commerce.
  3. Le serveur du site, incapable de gérer autant de connexions, devient extrêmement lent puis cesse de répondre.
  4. Pendant plusieurs heures, les clients ne peuvent plus accéder au site, entraînant une perte de ventes importante.

Mesures de protection mises en place :

  • L’entreprise utilise un CDN pour filtrer le trafic et absorber la surcharge.
  • Un pare-feu est configuré pour bloquer les adresses IP suspectes.
  • Un système de détection d’intrusion analyse le trafic et bloque automatiquement les requêtes anormales.

Test de mémorisation/compréhension​


Quel est l’objectif principal d’une attaque DoS ?


Quelle est la différence entre DoS et DDoS ?


Quel type d’attaque consiste à envoyer un grand nombre de requêtes pour saturer un serveur ?


Qu’est-ce qu’un botnet ?


Quelle solution permet de répartir la charge d’un site Web pour résister à une attaque DDoS ?


Quel est l’effet principal d’une attaque DDoS sur un site Web ?


Quel outil est utilisé pour détecter un trafic anormal sur un réseau ?


Quelle entreprise propose un service de protection contre les attaques DDoS ?


Quelle action peut aider à limiter l’impact d’une attaque DoS ?


TP pour réfléchir et résoudre des problèmes​

Serveur sous Debian - Attaquant sous Windows

Nous allons utiliser 2 machines :

  • Serveur Web (Debian)

    • Héberge un serveur Web sur Debian.
    • Subira l’attaque DoS.

  • Attaquant (Windows)

    • Enverra un grand nombre de requêtes pour surcharger le serveur.

Mise en place du serveur​

astuce

Nous pouvons utiliser un serveur Web déjà disponible pour des tests, sinon voici comment lancer un serveur Web avec Python.

  1. Se connecter à la machine Debian et mettre à jour les paquets :
sudo apt update && sudo apt upgrade -y
  1. Installer Python (si ce n’est pas déjà fait) :
sudo apt install python3 -y
  1. Lancer un serveur Web sur le port 8080 :
python3 -m http.server 8080
  1. Vérifier que le serveur fonctionne :
    • Ouvrir un navigateur sur Windows et accéder à : 
      http://<IP_DU_SERVEUR>:8080
    • Remplacer <IP_DU_SERVEUR> par l’adresse IP de la machine Debian (ip a pour la trouver).
    • Si tout fonctionne, nous allons voir une liste des fichiers du répertoire courant.

Simulation d’une attaque DoS​

Récupérer l’IP du serveur Debian​

Sur la machine Debian, exécuter :

ip a

Noter l’adresse IP de l’interface réseau (ex. 192.168.1.100).

Lancer l’attaque depuis Windows​

  1. Ouvrir un terminal PowerShell sur Windows (Win + R → powershell)

  2. Exécuter la commande suivante pour envoyer des requêtes en boucle :

while ($true) { Invoke-WebRequest -Uri "http://192.168.1.100:8080" }

(Remplacer 192.168.1.100 par l’IP de notre serveur Debian.)

  1. Observer l’impact sur le serveur Debian :
    • Le terminal où tourne le serveur affichera une série de requêtes.
    • Le serveur peut ralentir ou cesser de répondre.
Afficher les requêtes

Comment afficher les requêtes HTTP/HTTPS qui sont faites vers ce serveur ?

Solution n°1. Afficher les log du serveur Web, avec la commande tail :​

sudo tail -f  /var/log/apache2/access-atedi.log

La commande sudo tail -f /var/log/apache2/access-atedi.log réalise plusieurs actions importantes :

Détails de la commande :​

  • sudo : Exécute la commande avec les privilèges root.

  • tail : C'est une commande qui affiche les dernières lignes d'un fichier. Par défaut, elle affiche les 10 dernières lignes, mais vous pouvez spécifier une autre quantité si besoin.

  • -f : Cette option signifie "follow" (suivre). Lorsqu'elle est utilisée, tail continuera à afficher les nouvelles lignes ajoutées au fichier en temps réel. Cela est particulièrement utile pour surveiller des fichiers journaux.

  • /var/log/apache2/access-atedi.log : C'est le chemin du fichier dont vous souhaitez afficher les contenu. Dans ce cas, il s'agit du fichier journal d'accès (access log) d'Apache pour un site ou un service spécifique nommé "atedi".

Cette commande surveille et affiche en temps réel les requêtes HTTP qui arrivent sur le serveur gérées par Apache, selon le fichier log spécifié. Cela permet de suivre l'activité du serveur et d'obtenir des informations sur le trafic entrant, comme les adresses IP des visiteurs, les pages consultées, et d'autres données utiles pour le diagnostic et l'analyse.

Solution n°2. Afficher le trafic TCP avec la commande tcpdump :​

Pour installer tcpdump, il suffit d'exécuter les commandes suivantes :

sudo apt update
sudo apt install tcpdump

Pour afficher les requêtes HHTP, il suffit d'exécuter la commande suivante :

sudo tcpdump 'tcp port 80'

Détails de la commande :​

  • sudo : Exécute la commande avec les privilèges root.
  • tcpdump : Outil de capture de paquets.
  • 'tcp port 80' : Filtre pour n'afficher que le trafic HTTP (port 80).

Si vous souhaitez afficher aussi les requêtes HTTPS, il suffit de remplacer 'tcp port 80' par 'tcp port 80 or tcp port 443'.

sudo tcpdump 'tcp port 80 or tcp port 443'
  1. Arrêter l’attaque avec Ctrl + C dans le terminal PowerShell.

Protection contre les attaques DoS​

Nous allons maintenant mettre en place des protections sur le serveur Debian.

1. Bloquer les IP suspectes avec fail2ban​

fail2ban permet de bloquer automatiquement les IP qui envoient trop de requêtes.

  1. Pour installer fail2ban, il suffit d'exécuter les commandes suivantes :

1.1. Installer Fail2Ban

sudo apt update
sudo apt install fail2ban

1.2. Créer un filtre apache-flood pour protéger Apache contre le flood HTTP/HTTPS

Que signifie flood ?

En anglais flood signifie inondation.

Un flood est souvent utilisé pour désigner les attaques où un grand nombre de requêtes sont envoyées à une cible afin de la rendre indisponible.
Ces attaques exploitent la capacité limitée des serveurs à traiter les demandes.

sudo nano /etc/fail2ban/filter.d/apache-flood.conf
[Definition]
failregex = ^<HOST> -.*"(GET|POST).*
sudo nano /etc/fail2ban/jail.local
[apache-flood]
enabled = true
port = http,https,8000,8080
filter = apache-flood
logpath = /var/log/apache2/access.log
findtime = 5
maxretry = 20
bantime = 600
Explication de notre filtre apache-flood

  • Le nom du fichier (apache-flood.conf) deviendra automatiquement le nom du filtre que tu pourras réutiliser dans tes jails.

  • Tous les fichiers .conf placés dans /etc/fail2ban/filter.d/ sont automatiquement lus par Fail2Ban au démarrage.

  • [Definition] → section obligatoire, c’est là que Fail2Ban lit les règles.

  • failregex = → c’est l’expression régulière qui va détecter une ligne suspecte dans les logs Apache.

Que fait exactement cette regex ? ^<HOST> -.*"(GET|POST).*​

Elle recherche dans chaque ligne du fichier access.log quelque chose qui ressemble à :

192.168.1.42 - - [02/Dec/2025:12:34:56 +0100] "GET /index.php HTTP/1.1" 200 1234
203.0.113.57 - - [02/Dec/2025:12:34:56 +0100] "POST /wp-login.php HTTP/1.1" 403 567

Ce filtre considère comme suspecte toute requête HTTP GET ou POST provenant d’une même IP.
Quand Fail2Ban verra plus de 20 requêtes (maxretry = 20) en moins de 5 secondes (findtime = 5), il bannira l’IP pendant 10 minutes (bantime = 600).

1.3. Vérifier que la syntaxe est bonne

sudo fail2ban-client -t

1.4. Appliquer la configuration

# Redémarrer Fail2Ban
sudo systemctl restart fail2ban
Si fail2ban ne démmarre pas automatiquement
sudo systemctl enable fail2ban

1.5. Vérifier que le filter est bien actif

sudo fail2ban-client status apache-flood

Nous devons voir les IP bannies en temps réel :

Status for the jail: apache-flood
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /var/log/apache2/access.log
`- Actions
  |- Currently banned: 0
  |- Total banned:     0
  `- Banned IP list:

1.6. Réaliser de nombreuses requêtes HTTP

Faites de nombreuses requêtes HTTP avec votre poste client, jusqu'à ce que le serveur ne réponde plus...

1.7. Vérifier que votre IP est bannie

sudo fail2ban-client status apache-flood

Nous devons voir les IP bannies en temps réel :

Status for the jail: apache-flood
|- Filter
|  |- Currently failed: 1
|  |- Total failed:     22
|  `- File list:        /var/log/apache2/access.log
`- Actions
  |- Currently banned: 1
  |- Total banned:     1
  `- Banned IP list:   10.138.126.32
Si ça ne marche pas

  • Pour analyser les actions réalisées, Fail2ban lit dans les fichiers .log .

    Pensez à vérifier le nom du fichier log de votre Virtualhost, par exemple : /var/log/apache2/access-atedi.log

  • Dans le fichier /etc/fail2ban/jail.local c'est le paramètre enabled = true qui active le filtre

    Pensez à saisir enabled et non pas enable

Cette configuration bloque très rapidement les bots, les scans, et les petites attaques par déni de service.

2. Utiliser un proxy inverse (NGINX) pour filtrer les requêtes​

Un proxy inverse comme NGINX peut être utilisé pour limiter le nombre de requêtes provenant d’une même IP.

Schéma de principe​

Avant de commencer, visualisons le résultat final :

Internet
    |
    v
[Port 80] NGINX (Reverse Proxy)
    |
    v
[Port 8080] Apache (Serveur Web)

NGINX deviendra la "porte d'entrée" de votre serveur web. Il est réputé pour sa grande efficacité pour gérer un grand nombre de connexions simultanées, ce qui en un excellent choix pour un reverse proxy.

Étape 1 : Mettre à jour le système et installer NGINX​

D'abord, assurons-nous que la liste des paquets est à jour et installons NGINX.

# Mettre à jour la liste des paquets
sudo apt update

# Installer NGINX
sudo apt install nginx

À ce stade, NGINX est installé, mais il ne peut pas démarrer car le port 80 est déjà occupé par Apache. C'est normal.

Étape 2 : Libérer le port 80 en changeant le port d'écoute d'Apache​

Pour que NGINX puisse écouter sur le port 80, nous devons déplacer Apache sur un autre port. Le port 8080 est un choix courant et de bon goût.

  1. Modifier le port d'écoute principal d'Apache : Ouvrez le fichier de configuration des ports d'Apache :

    sudo nano /etc/apache2/ports.conf

    Cherchez la ligne Listen 80 et modifiez-la pour qu'elle écoute sur le port 8080 :

    # Ancienne ligne à commenter ou supprimer
    # Listen 80

    # Nouvelle ligne
    Listen 8080

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

  2. Adapter les VirtualHosts d'Apache : Vos sites virtuels (VirtualHosts) sont probablement configurés pour écouter sur le port 80. Il faut les mettre à jour. Le plus souvent, le fichier par défaut est /etc/apache2/sites-available/000-default.conf.

    Ouvrez ce fichier (et les autres fichiers de site si vous en avez) :

    sudo nano /etc/apache2/sites-available/000-default.conf

    Modifiez la ligne <VirtualHost *:80> pour qu'elle devienne <VirtualHost *:8080> :

    <VirtualHost *:8080>
        # ... le reste de votre configuration
    </VirtualHost>

    Enregistrez et fermez le fichier.

  3. Redémarrer Apache pour appliquer les changements :

    sudo systemctl restart apache2

    Vérifiez qu'Apache écoute bien sur le nouveau port :

    sudo ss -tlnp | grep :8080

    Vous devriez voir une ligne montrant qu'Apache (apache2) écoute sur le port 8080. Le port 80 est maintenant libre.

Étape 3 : Configurer NGINX comme Reverse Proxy​

Maintenant, nous allons configurer NGINX pour qu'il écoute sur le port 80 et redirige toutes les requêtes vers Apache sur le port 8080.

  1. Créer un nouveau fichier de configuration pour notre site : La meilleure pratique est de ne pas modifier le fichier nginx.conf principal, mais de créer un fichier de configuration spécifique pour notre site dans /etc/nginx/sites-available/.

    Créons un fichier, par exemple reverse-proxy.conf :

    sudo nano /etc/nginx/sites-available/reverse-proxy.conf

  2. Coller la configuration de reverse proxy : Insérez le contenu suivant dans ce fichier. N'oubliez pas de remplacer votre_domaine.com par votre nom de domaine réel ou l'adresse IP de votre serveur.

    server {
        listen 80;
        server_name votre_domaine.com www.votre_domaine.com; # Ou *.votre_domaine.com ou l'IP de votre serveur

        location / {
            # Adresse du serveur Apache (en local sur le port 8080)
            proxy_pass http://127.0.0.1:8080;

            # En-têtes à transmettre à Apache pour qu'il ait les bonnes infos
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }

    Explication des directives importantes :

    • listen 80; : NGINX écoute sur le port 80, celui-ci étant maintenant libre.
    • proxy_pass http://127.0.0.1:8080; : C'est le cœur du reverse proxy. Toute demande arrivant sur ce server NGINX sera transférée à cette adresse (le serveur Apache sur le port 8080).
    • proxy_set_header ... : Ces lignes sont cruciales. Elles permettent à NGINX de transmettre à Apache des informations importantes sur la requête originale, comme l'adresse IP réelle du client (X-Real-IP) et le nom de domaine demandé (Host). Sans cela, vos logs Apache ne montreraient que l'IP locale (127.0.0.1) de NGINX.

  3. Activer le nouveau site : On crée un lien symbolique du fichier que nous venons de créer vers le répertoire sites-enabled, qui est lu par NGINX.

    sudo ln -s /etc/nginx/sites-available/reverse-proxy.conf /etc/nginx/sites-enabled/

  4. Désactiver le site par défaut de NGINX (recommandé) : Pour éviter les conflits, il est sage de supprimer le lien vers le site par défaut.

    sudo rm /etc/nginx/sites-enabled/default
Étape 4 : Tester et redémarrer NGINX​

Avant d'appliquer la nouvelle configuration, il est essentiel de la tester pour éviter de casser votre serveur web.

sudo nginx -t

Si tout est bon, vous devriez voir un message de succès :

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Si le test est réussi, redémarrez NGINX pour charger la nouvelle configuration :

sudo systemctl restart nginx

Assurez-vous également que NGINX est activé pour démarrer au boot :

sudo systemctl enable nginx
Étape 5 : Vérification​

Votre configuration est maintenant terminée ! Pour vérifier que tout fonctionne comme prévu :

  1. Ouvrez votre navigateur web et allez à l'adresse http://votre_domaine.com (ou l'IP de votre serveur).

  2. Vous devriez voir la page web servie par Apache.

  3. Pour être certain que NGINX est bien en face, vous pouvez vérifier les en-têtes de réponse du serveur :

    • Ouvrez les Outils de développement du navigateur (par exemple Edge)
    • Allez à l'onglet "Réseau" (Network)
    • Cliquez sur l'onglet "Réseau"
    • Actualisez la page
    • Sélectionnez la requête principale (la page HTML elle-même).
    • Cliquez dessus.
    • Cliquez sur l'onglet "En-têtes" (Headers).
    • Cochez l'option Raw
    • Voici un exemple de ce que vous devriez voir dans la section En-têtes de réponse : 
      > En-têtes de réponse
        connection: keep-alive
        content-type: text/html
        date: Wed, 23 Oct 2024 10:00:00 GMT
        etag: "abcd-1234"
        last-modified: Mon, 21 Oct 2024 15:00:00 GMT
        server: nginx/1.18.0 (Ubuntu)   <-- LA LIGNE IMPORTANTE !
        transfer-encoding: chunked
        vary: Accept-Encoding

    La ligne server: nginx/1.18.0 (Ubuntu) vous confirme que la réponse a bien été traitée et envoyée par NGINX, même si le contenu a été généré par Apache en arrière-plan.

    Cela prouve que c'est bien NGINX qui a répondu à votre requête, même si le contenu provient d'Apache.

Étape 6 : Renforcer la configuration NGINX pour mitiger les attaques​

Nous allons modifier la configuration que nous avons déjà créée.

6.1 : Ajouter les zones de limitation dans le contexte http​

Ces directives doivent être placées dans le bloc http de votre fichier de configuration principal NGINX, généralement /etc/nginx/nginx.conf. Cela permet de définir des zones de mémoire partagée que NGINX utilisera pour suivre les limites.

Ouvrez le fichier /etc/nginx/nginx.conf :

sudo nano /etc/nginx/nginx.conf

Trouvez le bloc http { ... } et ajoutez-y les lignes suivantes, juste après la ligne include /etc/nginx/conf.d/*.conf; par exemple.

http {
    # ... autres directives ...

    # === ZONES DE LIMITATION POUR LA SÉCURITÉ (DDoS) ===

    # 1. Limiter le taux de requêtes (Rate Limiting)
    # Crée une zone de 10MB nommée "req_limit_per_ip".
    # Elle suit l'adresse IP de chaque client ($binary_remote_addr est plus efficace que $remote_addr).
    # La limite est de 10 requêtes par seconde (10r/s).
    limit_req_zone $binary_remote_addr zone=req_limit_per_ip:10m rate=10r/s;

    # 2. Limiter le nombre de connexions simultanées (Connection Limiting)
    # Crée une zone de 10MB nommée "conn_limit_per_ip".
    # Elle suit le nombre de connexions simultanées par IP.
    limit_conn_zone $binary_remote_addr zone=conn_limit_per_ip:10m;

    # ... autres directives ...
}
  • limit_req_zone : C'est la défense la plus importante. Elle crée un "compteur" de requêtes par IP. Si une IP dépasse la limite (ici, 10 requêtes par seconde), NGINX retournera une erreur 503 Service Unavailable au lieu de faire suivre la requête à Apache.
  • limit_conn_zone : Empêche une seule IP d'ouvrir trop de connexions en même temps, ce qui est utile contre les attaques de type "slowloris".

Enregistrez et fermez le fichier.

6.2 : Appliquer les limitations à votre configuration de site​

Maintenant, nous allons utiliser les zones que nous venons de définir dans le fichier de configuration de votre site (mon_reverse_proxy.conf).

Ouvrez ce fichier :

sudo nano /etc/nginx/sites-available/mon_reverse_proxy.conf

Modifiez-le pour inclure les nouvelles directives de limitation.

server {
    listen 80;
    server_name votre_domaine.com www.votre_domaine.com;

    # === APPLICATION DES LIMITES DE SÉCURITÉ ===

    # Applique la limitation de connexions définie dans nginx.conf
    # Maximum 20 connexions simultanées par adresse IP.
    limit_conn conn_limit_per_ip 20;

    # Applique la limitation de taux de requêtes.
    # "burst=30" permet à l'IP de dépasser temporairement la limite
    # jusqu'à 30 requêtes supplémentaires. Utile pour les pages avec beaucoup de ressources (CSS, JS, images).
    # "nodelay" signifie que les requêtes dans le "burst" sont traitées sans délai,
    # tant que le burst n'est pas plein. Au-delà, les requêtes sont rejetées (erreur 503).
    limit_req zone=req_limit_per_ip burst=30 nodelay;


    # --- Autres recommandations de durcissement ---

    # Cacher la version de NGINX dans les en-têtes (sécurité par l'obscurcissement)
    server_tokens off;

    # Réduire les timeouts pour libérer les ressources plus rapidement
    client_body_timeout 10s;
    client_header_timeout 10s;
    keepalive_timeout 15s;
    send_timeout 10s;

    # Limiter la taille des requêtes pour éviter les attaques par buffer overflow
    client_body_buffer_size 1K;
    client_header_buffer_size 1k;
    large_client_header_buffers 2 1k;

    location / {
        proxy_pass http://127.0.0.1:8080;

        # En-têtes à transmettre à Apache
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Augmenter les timeouts pour le proxy si Apache est lent à répondre
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }

    # Optionnel : créer une page d'erreur personnalisée pour le 503
    error_page 503 /503.html;
    location = /503.html {
        root /usr/share/nginx/html;
    }
}
6.3 : Tester et recharger la configuration​

Comme toujours, avant d'appliquer les changements, testez la syntaxe de votre configuration :

sudo nginx -t

Si la commande vous indique que la syntaxe est correcte, rechargez NGINX pour appliquer les nouvelles règles sans couper les connexions existantes :

sudo systemctl reload nginx

Explication des techniques utilisées​

  1. Limitation du taux de requêtes (limit_req) : C'est votre meilleure défense. En limitant le nombre de requêtes par seconde par IP, vous vous assurez qu'un client (ou un bot) ne peut pas submerger votre serveur Apache. Le paramètre burst est crucial pour ne pas bloquer les utilisateurs légitimes qui chargent rapidement une page avec de nombreuses ressources.

  2. Limitation des connexions (limit_conn) : Empêche un attaquant de garder ouvertes des centaines de connexions inactives, ce qui épuiserait les ressources de NGINX.

  3. Réduction des timeouts : Des temps d'attente trop longs maintiennent des ressources (processus, mémoire) allouées à des clients qui ne répondent plus. En les raccourcissant, vous libérez ces ressources beaucoup plus vite.

  4. Cacher la version (server_tokens off) : Une mesure simple qui empêche les attaquants de connaître la version exacte de NGINX que vous utilisez, les empêchant ainsi d'exploiter des vulnérabilités spécifiques à cette version.

Fail2Ban avec NGINX (et pas Apache)​

Pour une protection robuste, il faut que Fail2Ban lise les log de NGINX mais plus ceux d'Apache .

Fail2Ban peut lire les logs d'accès de NGINX (à la place des log d'accès d'Apache) et bannir automatiquement certaines adresses IP.

Cela transforme votre défense "réactive" (NGINX bloque une requête) en une défense "proactive" (Fail2Ban bannit l'IP pour un certain temps).

En résumé, avec cette configuration, NGINX agit comme un garde du corps robuste pour votre serveur Apache. Il filtre le trafic abusif avant qu'il n'atteigne votre application, la protégeant ainsi de l'épuisement de ses ressources.

Vérification des protections​

  1. Tenter une attaque depuis Windows avec PowerShell.

    • Si fail2ban est activé, l’IP de Windows devrait être bloquée.
    • Si NGINX est activé, les requêtes devraient être filtrées.

  2. Vérifier les logs pour voir si les protections fonctionnent :

sudo fail2ban-client status http-server  # Vérifier les IP bloquées  
sudo tail -f /var/log/nginx/access.log  # Voir les requêtes filtrées par NGINX

Bonnes pratiques​

Pour protéger un serveur Web contre DoS/DDoS :

  • Utiliser un pare-feu pour limiter le trafic suspect.
  • Activer fail2ban pour bloquer les IP malveillantes.
  • Mettre en place un proxy inverse (NGINX, Cloudflare) pour filtrer les requêtes.
  • Surveiller les logs pour détecter les attaques en temps réel.
  • Utiliser un service anti-DDoS (Cloudflare, AWS Shield, etc.) pour les sites critiques.