Protection DDoS de couche 7 pour un VPS avec Nginx

La plupart des offres d'hébergement promettent une protection DDoS. Cela signifie généralement le filtrage de gros flux de paquets inutiles (couches 3 et 4) avant qu'ils n'atteignent votre serveur. Cela n'empêche pas un millier de « vrais » navigateurs de charger en même temps votre page la plus lente. Ces attaques de la couche application (couche 7) ressemblent à des visiteurs ordinaires, et vous devez les gérer vous-même. Voir qu'est-ce que la protection DDoS pour le contexte.

Connaître la différence

• Attaques volumétriques : elles saturent le tuyau réseau. L'hébergeur ou le fournisseur en amont les filtre.
• Attaques de protocole : elles épuisent les tables de connexions. Surtout gérées par le réseau.
• Attaques de couche 7 : des requêtes HTTP d'apparence valide qui consomment le CPU, la base de données ou les workers. Elles atteignent votre application.

Étape 1 : limitez le débit dans Nginx

Plafonnez la vitesse à laquelle une adresse peut envoyer des requêtes. Définissez une zone dans le bloc http et appliquez-la à votre site.

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=connip:10m;

server {
    location / {
        limit_req zone=perip burst=20 nodelay;
        limit_conn connip 20;
    }
    location = /login {
        limit_req zone=perip burst=3 nodelay;
    }
}

Utilisez une limite beaucoup plus stricte pour les connexions et la recherche, car elles sont coûteuses.

Étape 2 : mettez en cache ce que vous pouvez

Une page en cache ne coûte presque rien à servir. Activez le cache FastCGI ou proxy pour le trafic anonyme, même pendant 30 à 60 secondes. Il transforme un déluge de requêtes identiques en une poignée de vraies requêtes.

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=site:50m inactive=10m;
fastcgi_cache site;
fastcgi_cache_valid 200 60s;
fastcgi_cache_use_stale updating error timeout;

Étape 3 : définissez des délais d'expiration raisonnables

Les attaques à connexion lente gardent les workers occupés. Raccourcissez les limites.

client_body_timeout 10s;
client_header_timeout 10s;
send_timeout 15s;
keepalive_timeout 15s;
client_max_body_size 5m;

Étape 4 : bannissez les récidivistes avec fail2ban

Bannissez les adresses qui déclenchent le limiteur de débit. Nginx consigne les requêtes rejetées dans le journal d'erreurs, et un filtre peut les repérer.

[nginx-limit-req]
enabled  = true
filter   = nginx-limit-req
logpath  = /var/log/nginx/error.log
maxretry = 10
findtime = 60
bantime  = 1h

Étape 5 : placez un proxy devant quand cela devient sérieux

Un reverse proxy ou un CDN avec des challenges anti-bots peut absorber des attaques qu'un seul VPS ne peut pas encaisser. N'oubliez pas de protéger l'origine comme décrit dans garder secrète l'IP de votre origine, sinon les attaquants la contourneront.

Soyez prêt avant que cela n'arrive

• Connaissez vos pages les plus lentes et corrigez-les ou mettez-les en cache.
• Gardez une supervision pour remarquer rapidement un pic.
• Ayez un plan : des limites plus strictes, une page de maintenance, un serveur plus grand.

Les bases décrites dans le guide UFW et fail2ban vont de pair avec celui-ci.