Une attaque par déni de service distribué (DDoS) cherche à rendre un service inaccessible en le noyant sous le trafic. Les serveurs de jeu, les boutiques et les sites communautaires en sont des cibles fréquentes, parfois pour quelques euros payés par un concurrent ou un joueur banni. Ce guide explique comment fonctionne la protection incluse sur nos services, et ce que vous pouvez faire de votre côté.
1. Les trois familles d'attaques
| Famille | Principe | Exemples |
|---|---|---|
| Volumétrique (couche 3) | Saturer la connexion avec un volume de trafic énorme | Inondations UDP, amplification DNS, NTP ou memcached |
| Protocolaire (couche 4) | Épuiser les ressources réseau du serveur ou des équipements | SYN flood, attaques sur l'établissement des connexions |
| Applicative (couche 7) | Imiter de vrais visiteurs pour épuiser l'application | Milliers de requêtes HTTP sur des pages coûteuses |
Les attaques volumétriques sont les plus spectaculaires, mais aussi les plus faciles à reconnaître. Les attaques applicatives sont plus discrètes : chaque requête ressemble à celle d'un visiteur ordinaire.
2. Comment fonctionne notre protection
La protection Anti-DDoS s'appuie sur l'infrastructure de GCore, d'une capacité de 200 Tbps, et fonctionne en trois niveaux, actifs par défaut sur chaque service :
- Absorption volumétrique : le trafic d'attaque est absorbé et filtré sur le réseau, avant d'atteindre votre serveur.
- Filtrage protocolaire : les sessions TCP et UDP anormales sont écartées, les SYN floods neutralisés et les amplifications bloquées en amont.
- Inspection applicative : pour le trafic web, les requêtes suspectes sont soumises à des vérifications qui distinguent les robots des vrais visiteurs.
La détection et l'application des filtres sont automatiques : vous n'avez rien à activer, et le trafic légitime continue de passer pendant l'attaque. Aucune configuration n'est nécessaire de votre côté pour bénéficier de la protection réseau.
3. Ce qu'une protection réseau ne peut pas faire
Soyons clairs sur les limites, pour que vous puissiez les compenser :
- Elle ne corrige pas une application lente. Si une page de votre site met deux secondes à se générer, il suffit de peu de requêtes, même légitimes, pour saturer le serveur. Le cache est votre meilleure défense : voir optimiser PHP-FPM et le cache Nginx.
- Elle ne remplace pas la sécurité du serveur. Une attaque par force brute sur SSH ou sur un formulaire de connexion n'est pas un DDoS : c'est le rôle de SSH sécurisé et de Fail2ban.
- Elle ne protège que l'adresse qu'elle couvre. Si votre application dépend d'un service hébergé ailleurs, comme une base de données externe ou une API, ce service reste vulnérable.
4. Limiter les abus côté Nginx
Contre les abus applicatifs, limitez le nombre de requêtes et de connexions par adresse. Déclarez les zones dans le bloc http, par exemple dans /etc/nginx/conf.d/limites.conf :
limit_req_zone $binary_remote_addr zone=pages:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
limit_conn_zone $binary_remote_addr zone=conn:10m;
limit_req_status 429;Puis appliquez-les dans le bloc server du site :
limit_conn conn 20;
location / {
limit_req zone=pages burst=20 nodelay;
try_files $uri $uri/ /index.php?$args;
}
location = /wp-login.php {
limit_req zone=login burst=3 nodelay;
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}Chaque adresse peut faire 10 requêtes par seconde avec une réserve de 20, et 5 tentatives de connexion par minute. Ajustez ces valeurs à votre trafic réel : trop strictes, elles gênent les visiteurs derrière une même adresse, comme un réseau d'entreprise ou d'école. Les dépassements sont journalisés, et la jail nginx-limit-req de Fail2ban peut bannir les récidivistes.
5. Ne pas exposer l'adresse d'origine
Si votre site passe par un proxy comme Cloudflare, son intérêt disparaît dès que l'adresse réelle du serveur est connue : l'attaquant vise alors directement le VPS. Cette adresse fuit souvent par un sous-domaine non protégé, les en-têtes des e-mails envoyés par le serveur ou l'historique DNS. Voir Cloudflare devant un VPS. La protection réseau de nos VPS, elle, couvre l'adresse d'origine dans tous les cas.
6. Le cas des serveurs de jeu
Les serveurs de jeu utilisent surtout l'UDP, que les proxys web ne relaient pas : c'est la protection réseau qui fait tout le travail. Quelques bonnes pratiques renforcent son efficacité :
- N'ouvrez que les ports réellement utilisés par le jeu, en précisant le protocole : voir configurer UFW.
- Réservez les consoles d'administration (RCON, txAdmin) à votre adresse IP ou à un VPN WireGuard.
- Ne publiez pas l'adresse IP brute du serveur dans votre Discord si vous pouvez utiliser un nom de domaine.
Pour un serveur de jeu clé en main, déjà protégé et optimisé, voir nos serveurs FiveM.
7. Pendant une attaque
Si votre service ralentit ou devient inaccessible, commencez par distinguer une attaque d'un problème de ressources :
uptime # charge du processeur
ss -s # nombre de connexions ouvertes
ss -tn state established | awk 'NR>1 {sub(/:[0-9]+$/, "", $4); print $4}' | sort | uniq -c | sort -rn | head # connexions par adresse distante
tail -n 200 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head # adresses les plus actives- Une poignée d'adresses qui concentrent les requêtes : c'est un abus applicatif, bloquez-les ou resserrez les limites Nginx.
- Le serveur est calme mais injoignable : le problème est en amont. Contactez le support en indiquant l'heure de début, le service touché et l'adresse IP concernée.
- Le processeur ou la mémoire sont saturés sans trafic anormal : ce n'est pas une attaque, voir surveiller son VPS.