Chapitre 14.2 — Rate limiting, WAF & fail2ban

⏱️ TL;DR — Trois défenses contre l’abus et le volume. Rate limiting : limiter le nombre de requêtes par IP/utilisateur/endpoint sur une fenêtre de temps — indispensable sur les points sensibles (login, reset, API, envoi d’emails) contre bruteforce, credential stuffing (Partie 4) et scraping. WAF (Web Application Firewall) : un filtre en amont qui bloque des motifs d’attaque connus (payloads d’injection, scanners) — utile comme couche supplémentaire, jamais comme substitut au code sécurisé. fail2ban : surveille les logs et bannit temporairement les IP au comportement hostile (échecs SSH/HTTP répétés). Ces protections d’infra amortissent le volume et gagnent du temps ; elles complètent — sans remplacer — les défenses applicatives.

🎯 Objectifs

• Mettre en place du rate limiting sur les endpoints sensibles.
• Comprendre le rôle et les limites d’un WAF (couche complémentaire).
• Utiliser fail2ban pour bannir les IP hostiles à partir des logs.
• Situer ces défenses comme des couches d’infra en complément du code.

Rate limiting : borner le volume

Le rate limiting (limitation de débit) restreint le nombre de requêtes qu’un client (IP, utilisateur, clé d’API) peut envoyer sur une fenêtre de temps. C’est une défense essentielle contre tout ce qui repose sur le volume :

• Bruteforce et credential stuffing sur le login (Partie 4) : limiter les tentatives par IP et par compte.
• Abus d’endpoints coûteux : reset de mot de passe (spam/harcèlement), envoi d’emails/SMS, recherche, upload, génération.
• Scraping et énumération (Partie 5) : ralentir l’aspiration de données.
• Déni de service applicatif (DoS) : amortir les pics.

Le rate limiting se pose à plusieurs niveaux : au reverse proxy (Nginx limit_req), dans un service dédié (API gateway), ou dans l’appli (par utilisateur authentifié, plus précis). Souvent, on combine.

# Nginx : limiter les requetes vers /login (ex. quelques req/s par IP, avec rafale)
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/s;
location /login {
    limit_req zone=login burst=10 nodelay;
    proxy_pass http://app;
}

Points de conception : appliquer des limites plus strictes sur les endpoints sensibles (login, reset) que sur le reste ; limiter par IP ET par compte (une seule dimension se contourne — le stuffing distribue sur beaucoup d’IP, une IP partagée pénalise des innocents) ; répondre proprement (429 Too Many Requests) ; et loguer les dépassements (signal de détection, Partie 15).

💡 Réflexe — Identifie tes endpoints sensibles ou coûteux (login, reset de mot de passe, création de compte, envoi d’emails, API publique, recherche) et mets-y un rate limiting adapté dès le départ. C’est une défense peu coûteuse qui neutralise une large classe d’abus automatisés (bruteforce, stuffing, scraping, spam). Un login sans rate limiting est une invitation au bruteforce (Partie 4) — c’est souvent le premier manque qu’un attaquant exploite.

WAF : un filtre en amont (complémentaire)

Un WAF (Web Application Firewall) inspecte les requêtes HTTP avant qu’elles n’atteignent l’appli et bloque celles qui correspondent à des motifs d’attaque connus : payloads d’injection SQL, tentatives de XSS, chemins de scanners, exploits de CVE connues. Il existe en module (ModSecurity avec des règles type OWASP CRS), en service cloud (WAF managé), ou intégré à un CDN.

Ce qu’un WAF apporte :

• Une couche supplémentaire (defense in depth) qui bloque des attaques génériques et le bruit des scanners.
• Une protection d’urgence (« virtual patching ») : bloquer un exploit connu le temps de patcher l’appli.
• De la visibilité sur les tentatives (alimente la détection).

Mais un WAF a des limites cruciales :

⚠️ Piège — Un WAF n’est pas un substitut au code sécurisé. Il fonctionne largement par détection de motifs (deny-list) : il peut être contourné (encodages, obfuscation, payloads inédits) et il ne connaît pas ta logique métier (il ne détectera pas un IDOR, un défaut d’autorisation, une faille de logique — les failles spécifiques à ton appli, souvent les plus graves). Considère le WAF comme un filtre de bruit et une couche d’urgence, jamais comme « la sécurité ». Une appli qui « compte sur le WAF » au lieu de paramétrer ses requêtes, encoder ses sorties et vérifier ses accès reste vulnérable.

fail2ban : bannir les IP hostiles

fail2ban (cours Serveur Linux) surveille les logs (SSH, serveur web, appli) et bannit temporairement (via le pare-feu) les IP qui présentent un comportement hostile : trop d’échecs de connexion SSH, trop de 401/403/404 (scan), motifs d’attaque répétés.

• SSH : bannir les IP qui bruteforcent le port SSH (rappel : SSH est attaqué en continu — Serveur Linux).
• HTTP : bannir les IP au comportement de scanner (rafales de 404 sur des chemins connus, tentatives de login massives) via des filtres personnalisés.

C’est une défense réactive et économique qui réduit le bruit et ralentit les attaquants persistants. Elle complète le rate limiting (qui borne le débit) et le durcissement SSH (clés, root off — Partie 4 et Serveur Linux).

Ces défenses amortissent, elles ne remplacent pas

Le message transversal : rate limiting, WAF et fail2ban sont des couches d’infra qui amortissent le volume, ralentissent les attaquants et gagnent du temps — mais elles ne corrigent pas les failles applicatives. Un login rate-limité reste bruteforçable lentement si les mots de passe sont faibles ; un WAF est contournable ; fail2ban ne voit pas une faille de logique. Elles sont précieuses en plus des défenses des Parties 4-13, jamais à la place.

🎯 Côté attaquant — Face à ces protections, l’attaquant s’adapte : contre le rate limiting par IP, il distribue l’attaque sur de nombreuses IP (botnet, proxies) — d’où l’intérêt de limiter aussi par compte et d’ajouter MFA (Partie 4) ; contre un WAF, il obfusque ses payloads (encodages, casse, fragmentation) ou vise les failles métier que le WAF ignore (IDOR, logique) ; contre fail2ban, il ralentit sous le seuil de bannissement ou change d’IP. Ces défenses augmentent son coût sans le stopper — c’est leur but (amortir, ralentir, détecter), à condition que le code derrière soit solide.

🧭 Sur FormaCampus — FormaCampus applique un rate limiting ciblé : strict sur /login, /reset, la création de compte et l’envoi d’emails (par IP et par compte), plus modéré sur l’API et la recherche, avec réponses 429 et journalisation des dépassements (détection). Un WAF (règles OWASP CRS au proxy/CDN) filtre le bruit des scanners et sert de virtual patching en cas de CVE, sans être considéré comme une protection suffisante (le code reste paramétré/encodé/autorisé — Parties 6-8). fail2ban bannit les IP qui bruteforcent SSH et celles au comportement de scanner HTTP. Ces couches d’infra amortissent le volume ; les vraies défenses restent dans le code et l’authentification.

✏️ Exercices

Exercice 1 — Dimensionne le rate limiting. Un attaquant fait du credential stuffing : il teste un couple email/mot de passe par compte, mais sur des millions de comptes, depuis des milliers d’IP différentes. Un rate limiting « 5 tentatives/minute par IP » suffit-il ? Que faut-il ajouter ?

Exercice 2 — WAF suffisant ? Un manager veut « installer un WAF et arrêter de se soucier des injections SQL dans le code ». Réponds.

🧠 Quiz de révision

Chapitre suivant : Isolation & moindre privilège — borner l’impact d’une compromission par le cloisonnement et le moindre privilège au niveau système.