Protéger son site contre les attaques DDoS

En 2014, quand j’ai commencé ma carrière en agence web, les attaques DDoS visaient surtout les grandes entreprises. Aujourd’hui, après plus de 10 ans dans le métier, je constate que n’importe quel site, même un petit e-commerce ou un blog WordPress, peut devenir une cible. J’ai vu des sites clients tomber en quelques secondes sous des attaques qui auraient pu être évitées avec les bonnes protections.

Protéger son site contre les attaques DDoS n’est plus un luxe réservé aux grands comptes. C’est une nécessité pour tout propriétaire de site web. Dans ce guide, je partage les techniques concrètes que je déploie systématiquement sur les projets que je gère, du simple blog WordPress au site e-commerce à fort trafic.

Comprendre les attaques DDoS : types et mécanismes

Une attaque DDoS (Distributed Denial of Service) consiste à submerger un serveur avec un volume de requêtes tellement massif qu’il ne peut plus répondre aux visiteurs légitimes. Contrairement à une attaque DoS classique provenant d’une seule source, une attaque DDoS utilise des milliers de machines compromises (un botnet) pour envoyer simultanément des requêtes.

Il existe trois grandes catégories d’attaques DDoS, et chacune nécessite une stratégie de défense différente.

Les attaques volumétriques (couche 3/4) sont les plus connues. Elles saturent la bande passante de votre serveur avec un flux massif de données. Les techniques UDP Flood, ICMP Flood ou SYN Flood entrent dans cette catégorie. Elles peuvent générer des débits de plusieurs centaines de Gbps, ce qui dépasse largement la capacité de n’importe quel serveur individuel.

Les attaques protocolaires exploitent les faiblesses des protocoles réseau. Le SYN Flood, par exemple, envoie des millions de demandes de connexion TCP sans jamais les finaliser, épuisant ainsi la table de connexions du serveur. Ces attaques ne nécessitent pas forcément un débit énorme pour être efficaces.

Les attaques applicatives (couche 7) sont les plus sournoises. Elles ciblent directement votre application web en envoyant des requêtes HTTP qui semblent parfaitement légitimes. Un attaquant peut, par exemple, appeler en boucle votre page de recherche avec des requêtes complexes qui sollicitent intensément votre base de données. Ces attaques sont difficiles à distinguer du trafic normal, ce qui les rend particulièrement dangereuses.

Évaluer la vulnérabilité de votre site

Avant de déployer des protections, je commence toujours par un audit de vulnérabilité. Voici les points que je vérifie systématiquement sur chaque projet.

Premièrement, l’exposition de l’adresse IP du serveur. Si votre IP d’origine est accessible directement (sans passer par un proxy ou un CDN), un attaquant peut contourner toutes vos protections DNS. Pour vérifier, utilisez des outils comme dig ou nslookup pour voir si vos enregistrements DNS pointent directement vers votre serveur.

dig +short votre-domaine.fr
nslookup votre-domaine.fr

Deuxièmement, la capacité de votre hébergement. Un hébergement mutualisé offre une protection quasi nulle contre les DDoS, car les ressources sont partagées. Un VPS offre plus de contrôle, mais sa bande passante reste limitée. Je recommande de connaître précisément les limites de votre hébergement : bande passante maximale, nombre de connexions simultanées, capacité CPU et RAM.

Troisièmement, les points faibles applicatifs. Certaines pages de votre site consomment beaucoup plus de ressources que d’autres. Sur WordPress, les pages de recherche, les requêtes WP-JSON et la page xmlrpc.php sont des cibles privilégiées. Sur un site Symfony, les routes qui effectuent des requêtes lourdes en base de données sont particulièrement vulnérables.

Enfin, vérifiez vos enregistrements DNS. Des enregistrements mal configurés peuvent exposer votre IP d’origine même derrière un CDN. Les enregistrements MX, par exemple, pointent souvent directement vers le serveur. Pour bien comprendre la configuration DNS, je vous recommande mon guide sur les enregistrements DNS.

Protection au niveau DNS et CDN

La première ligne de défense, et souvent la plus efficace, consiste à placer votre site derrière un réseau de distribution de contenu (CDN). Le CDN agit comme un bouclier entre les attaquants et votre serveur d’origine.

Cloudflare est la solution que je déploie le plus souvent, et ce pour une raison simple : même en version gratuite, elle offre une protection anti-DDoS illimitée. J’ai détaillé la mise en place complète dans mon guide sur Cloudflare.

Le principe est le suivant : au lieu de pointer vos DNS directement vers votre serveur, vous les redirigez vers Cloudflare. Tout le trafic passe d’abord par leur réseau mondial de plus de 300 data centers, qui filtre les requêtes malveillantes avant qu’elles n’atteignent votre serveur.

Voici les réglages que j’applique systématiquement sur Cloudflare pour une protection optimale :

• Activer le mode « Under Attack » en cas de menace active (ajoute un interstitiel JavaScript de 5 secondes)
• Configurer le Security Level sur « High » pour les sites sensibles
• Activer le Bot Fight Mode pour bloquer les bots malveillants connus
• S’assurer que tous les sous-domaines passent par le proxy Cloudflare (icône orange active)
• Configurer des Page Rules pour protéger spécifiquement les zones sensibles comme /wp-admin/ ou /wp-login.php

Pour les sites à fort enjeu, les plans payants de Cloudflare (Pro à 20 $/mois, Business à 200 $/mois) ajoutent un WAF managé et des règles de filtrage plus avancées. Mais pour la majorité des sites que je gère, la version gratuite suffit amplement.

Une erreur que je vois souvent : oublier de masquer l’IP d’origine du serveur. Si un attaquant découvre votre IP réelle via un historique DNS (des services comme SecurityTrails conservent les anciens enregistrements), il peut attaquer directement votre serveur en contournant Cloudflare. Pour éviter cela, changez l’IP de votre serveur après avoir activé Cloudflare, ou configurez votre pare-feu serveur pour n’accepter que les connexions provenant des plages IP de Cloudflare.

Configurer un pare-feu applicatif (WAF)

Un WAF (Web Application Firewall) analyse chaque requête HTTP entrante et bloque celles qui correspondent à des signatures d’attaques connues. C’est votre deuxième ligne de défense, complémentaire au CDN.

Sur les serveurs que je configure moi-même, j’installe systématiquement ModSecurity avec le jeu de règles OWASP CRS (Core Rule Set). Voici la procédure sur un serveur Nginx sous Debian/Ubuntu :

# Installation de ModSecurity pour Nginx
sudo apt install libmodsecurity3 libmodsecurity-dev
sudo apt install libnginx-mod-security

# Activation dans la configuration Nginx
# Dans /etc/nginx/nginx.conf, ajouter :
modsecurity on;
modsecurity_rules_file /etc/nginx/modsecurity/main.conf;

Le jeu de règles OWASP CRS protège contre les attaques les plus courantes : injection SQL, XSS, inclusion de fichiers, et bien sûr les patterns d’attaques DDoS applicatives. Je configure le niveau de paranoïa à 2 (sur une échelle de 1 à 4) pour un bon équilibre entre sécurité et faux positifs.

Pour les sites WordPress, le plugin Wordfence offre un WAF applicatif efficace directement au niveau PHP. Ce n’est pas aussi performant qu’un WAF au niveau serveur (les requêtes atteignent quand même PHP), mais c’est une couche de protection supplémentaire appréciable. Sa fonctionnalité de rate limiting intégrée bloque automatiquement les IP qui effectuent trop de requêtes.

Sur les projets Symfony, j’utilise le composant RateLimiter natif du framework combiné à des règles personnalisées dans le firewall de l’application. L’avantage de Symfony est de pouvoir implémenter des stratégies de protection très fines, adaptées à la logique métier de chaque application.

Sécuriser son serveur Linux contre les DDoS

Quand vous gérez votre propre serveur VPS, plusieurs configurations système permettent de renforcer considérablement la résistance aux attaques DDoS. Voici les mesures que j’applique sur chaque serveur que je déploie.

Configuration du noyau Linux (sysctl) : ces paramètres optimisent la gestion des connexions réseau et limitent l’impact des attaques SYN Flood.

# /etc/sysctl.conf - Protection anti-DDoS

# Protection SYN Flood
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 65536
net.ipv4.tcp_synack_retries = 2

# Réduire le timeout des connexions
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 300

# Ignorer les paquets ICMP broadcast
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Protection contre le spoofing IP
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Augmenter les limites de connexion
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65536

Appliquez ces paramètres avec sudo sysctl -p.

Configuration iptables : des règles de filtrage ciblées bloquent les patterns d’attaques les plus courants.

# Limiter les nouvelles connexions par IP
iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j DROP
iptables -A INPUT -p tcp --dport 443 -m connlimit --connlimit-above 50 -j DROP

# Limiter le taux de nouvelles connexions SYN
iptables -A INPUT -p tcp --syn -m limit --limit 30/s --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

# Bloquer les paquets invalides
iptables -A INPUT -m state --state INVALID -j DROP

# Limiter les requêtes ICMP
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

Fail2ban complète le dispositif en bannissant automatiquement les IP qui montrent un comportement suspect. Je configure des jails spécifiques pour les attaques web :

# /etc/fail2ban/jail.local
[nginx-http-auth]
enabled = true
maxretry = 3
bantime = 3600

[nginx-botsearch]
enabled = true
maxretry = 5
bantime = 7200

[nginx-limit-req]
enabled = true
maxretry = 10
bantime = 3600

Ces configurations sont particulièrement importantes si vous êtes sur un VPS. Pour un guide complet de sécurisation serveur, consultez mon article sur la configuration d’un VPS Linux.

Rate limiting et filtrage des requêtes

Le rate limiting est l’une des protections les plus efficaces contre les attaques DDoS applicatives. Le principe est simple : limiter le nombre de requêtes qu’une même IP peut effectuer sur une période donnée.

Sur Nginx, je configure le rate limiting directement dans le fichier de configuration du serveur :

# Dans http {} de nginx.conf
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=1r/s;
limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s;

# Dans le bloc server {}
location / {
    limit_req zone=general burst=20 nodelay;
}

location /wp-login.php {
    limit_req zone=login burst=3 nodelay;
}

location /wp-json/ {
    limit_req zone=api burst=50 nodelay;
}

Le paramètre burst autorise des pics temporaires de trafic, tandis que nodelay traite immédiatement les requêtes du burst au lieu de les mettre en file d’attente. Je définis des zones différentes selon la sensibilité de chaque endpoint : les pages de connexion sont très limitées, tandis que l’API est plus permissive pour ne pas bloquer les usages légitimes.

Pour WordPress spécifiquement, je bloque ou limite systématiquement certains endpoints souvent ciblés :

# Bloquer xmlrpc.php (souvent utilisé pour les attaques)
location = /xmlrpc.php {
    deny all;
    return 403;
}

# Limiter l'accès à wp-cron.php
location = /wp-cron.php {
    limit_req zone=login burst=2 nodelay;
}

Sur Cloudflare, les Rate Limiting Rules offrent une protection supplémentaire au niveau du CDN, avant même que les requêtes n’atteignent votre serveur. En version gratuite, vous disposez d’une règle de rate limiting. Les plans payants en débloquent davantage.

Pour les sites e-commerce sous WooCommerce, portez une attention particulière aux endpoints de l’API REST et aux pages de checkout, qui sont des cibles fréquentes.

Monitoring et détection en temps réel

La meilleure protection ne sert à rien si vous ne détectez pas l’attaque à temps. Un système de monitoring efficace vous alerte dans les premières minutes d’une attaque, vous laissant le temps de réagir.

Voici les métriques que je surveille en priorité :

• Nombre de requêtes par seconde : une augmentation soudaine de 10x ou plus est un signal d’alerte fort
• Temps de réponse du serveur : un temps de réponse qui passe de 200 ms à plusieurs secondes indique une surcharge
• Utilisation CPU et RAM : des pics soudains sans raison apparente
• Bande passante sortante : une consommation anormale peut indiquer une attaque par amplification
• Nombre de connexions simultanées : un indicateur clé des attaques SYN Flood

Pour le monitoring, j’utilise une combinaison d’outils. Uptime Robot (gratuit) ou Better Uptime vérifient la disponibilité de votre site toutes les minutes et vous alertent par email, SMS ou Slack en cas d’indisponibilité. C’est le minimum vital.

Pour une surveillance plus poussée sur un VPS, Netdata offre un dashboard en temps réel de toutes les métriques système, avec des alertes configurables. L’installation est simple :

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

Sur Cloudflare, le dashboard Analytics > Security affiche en temps réel le nombre de requêtes bloquées, les pays d'origine du trafic suspect, et les types d'attaques détectées. C'est un outil précieux pour comprendre le profil d'une attaque en cours.

Je recommande également de configurer des alertes automatisées basées sur des seuils. Par exemple : si le nombre de requêtes dépasse 1 000 par seconde, ou si le temps de réponse moyen dépasse 2 secondes, une notification est envoyée immédiatement.

Plan de réaction en cas d'attaque

Même avec toutes les protections en place, vous devez avoir un plan de réaction prêt. Quand une attaque frappe, chaque minute compte. Voici le protocole que je suis systématiquement.

Étape 1 : identifier le type d'attaque. Vérifiez vos logs et votre monitoring pour déterminer s'il s'agit d'une attaque volumétrique, protocolaire ou applicative. La commande suivante sur votre serveur vous donne rapidement une vue d'ensemble :

# Top 20 des IP par nombre de connexions
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# Nombre total de connexions actives
netstat -an | wc -l

Étape 2 : activer les protections d'urgence. Si vous êtes derrière Cloudflare, activez immédiatement le mode "Under Attack". Cela ajoute une vérification JavaScript qui bloque la plupart des bots. Vous pouvez aussi temporairement bloquer des pays entiers si l'attaque provient principalement d'une zone géographique spécifique.

Étape 3 : bloquer les sources identifiées. Si certaines plages IP reviennent massivement, bloquez-les au niveau du pare-feu :

# Bloquer une plage IP spécifique
iptables -A INPUT -s 203.0.113.0/24 -j DROP

# Bloquer un pays entier via Cloudflare ou iptables avec GeoIP
# Préférez Cloudflare pour ne pas surcharger votre serveur

Étape 4 : contacter votre hébergeur. Les hébergeurs comme OVH disposent de protections anti-DDoS au niveau de leur infrastructure (OVH propose le VAC, son système de mitigation). Informez-les de l'attaque pour qu'ils puissent activer des protections supplémentaires si nécessaire.

Étape 5 : documenter et analyser. Après l'attaque, analysez les logs pour comprendre le vecteur utilisé et renforcer vos défenses en conséquence. Conservez les logs comme preuve si vous souhaitez porter plainte.

Pensez également à disposer de sauvegardes récentes de votre site. Certaines attaques DDoS servent de diversion pendant qu'une intrusion est tentée par ailleurs.

Comparatif des solutions anti-DDoS

Pour vous aider à choisir la solution adaptée à votre situation, voici un comparatif des principales options disponibles.

Ma recommandation pour la majorité des sites : Cloudflare Free + ModSecurity + fail2ban. Cette combinaison gratuite offre une protection solide contre la plupart des attaques. Pour les sites e-commerce ou les applications critiques, je monte sur Cloudflare Pro qui ajoute le WAF managé avec des règles mises à jour automatiquement.

Pour les sites hébergés chez OVH, la protection anti-DDoS infrastructure est déjà incluse. Combinée à Cloudflare en proxy DNS, c'est une double couche de protection très efficace. Les détails de choix entre hébergeurs sont dans mon comparatif OVH vs O2Switch.

Si votre site est hébergé sur un hébergement WordPress premium comme Kinsta ou WP Engine, sachez que ces hébergeurs intègrent nativement des protections anti-DDoS et un CDN. La couche de protection est déjà en place, ce qui simplifie considérablement la configuration.

N'oubliez pas que la protection anti-DDoS s'inscrit dans une stratégie de sécurité globale. Un certificat SSL correctement configuré est également indispensable pour sécuriser les échanges entre vos visiteurs et votre serveur.