Protection des Applications

Publié le : 01/12/2024 à 10:00 Mis à jour le : 11/06/2026 à 09:35 Vues : 527

1. Le Rate Limiting (Limitation de débit)

Le Rate Limiting consiste à limiter le nombre de requêtes qu'un utilisateur ou une IP peut effectuer dans un intervalle de temps donné.

Concept

Indispensable pour protéger les APIs, le Rate Limiting empêche un client unique de saturer vos ressources, qu'il s'agisse d'un bug dans un script client ou d'une tentative malveillante de déni de service (DoS).

Exemple HAProxy

HAProxy utilise des stick-tables pour mémoriser les compteurs de requêtes.

frontend http-in
    # Table de 100k entrées, expiration après 30s
    stick-table type ip size 100k expire 30s store http_req_rate(10s)
    
    # Suivre l'IP source
    http-request track-sc0 src
    
    # Refuser (429 Too Many Requests) si > 20 requêtes en 10s
    http-request deny deny_status 429 if { sc0_http_req_rate gt 20 }

Exemple Traefik

Traefik implémente cela via le middleware rateLimit.

# Configuration File (YAML)
http:
  middlewares:
    limit-api:
      rateLimit:
        average: 100
        period: 1m
        burst: 20

2. Les Stick Tables (HAProxy)

Une fonctionnalité avancée de HAProxy pour stocker des états en mémoire.

Pourquoi les utiliser ?

Les stick tables permettent de suivre bien plus que le simple débit. Elles peuvent stocker le nombre de connexions simultanées, le taux d'erreurs HTTP générées par un client, ou encore des informations de session.

Exemple : Blocage basé sur le taux d'erreurs

Si une IP génère trop d'erreurs 404 ou 403, elle est probablement en train de scanner votre application.

backend app-backend
    # Stocke le taux d'erreurs sur 10s
    stick-table type ip size 1m expire 1h store http_err_rate(10s)
    
    http-request track-sc1 src
    # Bloquer l'IP si elle génère plus de 10 erreurs en 10s
    http-request deny if { sc1_http_err_rate gt 10 }

3. Protection contre le Brute Force

Identifier les tentatives répétées de deviner des mots de passe.

Stratégie

La protection brute force cible généralement les points d'entrée sensibles comme /login ou /wp-login.php. On applique une limite beaucoup plus stricte sur ces URLs que sur le reste du trafic.

Exemple HAProxy

frontend https-in
    stick-table type ip size 100k expire 1m store http_req_rate(20s)
    
    acl is_login path_beg /login
    http-request track-sc2 src if is_login
    
    # Max 3 tentatives de login toutes les 20 secondes
    http-request deny if is_login { sc2_http_req_rate gt 3 }

Exemple Traefik

On crée un middleware spécifique pour le routeur gérant l'authentification.

http:
  middlewares:
    auth-bruteforce:
      rateLimit:
        average: 2
        period: 1m
        burst: 1

4. Anti-DDoS (Attaques par déni de service)

Prévenir la saturation de l'infrastructure par des flots de connexions.

Limitation des connexions simultanées

Une attaque DDoS classique consiste à ouvrir un maximum de connexions TCP sans jamais les fermer (Slowloris). Limiter le nombre de connexions simultanées par IP est une protection fondamentale.

Exemple HAProxy

Utilisation de conn_cur dans une stick table.

frontend http-in
    stick-table type ip size 100k expire 30s store conn_cur
    
    tcp-request connection track-sc0 src
    # Rejeter la connexion si l'IP a déjà 15 connexions ouvertes
    tcp-request connection reject if { sc0_conn_cur gt 15 }

Exemple Traefik

Traefik propose le middleware inFlightConn.

http:
  middlewares:
    limit-simultaneous-conn:
      inFlightConn:
        amount: 10
        sourceCriterion:
          ipStrategy:
            depth: 2

5. Web Application Firewall (WAF)

Le WAF analyse le trafic HTTP en profondeur pour bloquer les attaques applicatives (OWASP Top 10).

Concept

Contrairement au Rate Limiting qui s'appuie sur la quantité, le WAF inspecte la qualité des requêtes. Il cherche des motifs d'attaque (Payloads) comme l'injection SQL ou le Cross-Site Scripting (XSS).

Exemple HAProxy

L'intégration se fait souvent via SPOE (Stream Processing Offload Engine) pour déléguer l'analyse à un agent ModSecurity externe sans ralentir le processus principal.

frontend http-in
    # Appel de l'agent SPOE ModSecurity
    filter spoe engine modsecurity config /etc/haproxy/modsec.conf
    
    # Bloquer (403 Forbidden) si l'agent retourne un score d'attaque
    http-request deny deny_status 403 if { var(txn.modsec.code) -m int gt 0 }

Exemple Traefik

Traefik peut intégrer un WAF via des plugins (comme modsecurity) ou en utilisant un sidecar comme Coraza.

# Exemple via un plugin de middleware
http:
  middlewares:
    waf-modsec:
      plugin:
        modsecurity:
          modsecurityUrl: http://modsecurity-agent:8080

6. Fail2ban et CrowdSec (Analyse de logs)

Automatisez le bannissement des IPs malveillantes en analysant les logs en temps réel.

Concept

Fail2ban et CrowdSec agissent comme des systèmes de détection d'intrusion (IDS) basés sur l'analyse de logs. Leur rôle est d'identifier des comportements malveillants automatisés (brute force, scans de vulnérabilités, déni de service applicatif) qui auraient pu passer à travers les premières couches de défense, et d'appliquer une sanction automatique (le bannissement IP).

Comparatif : Fail2ban vs CrowdSec

Bien qu'ils partagent le même objectif, leur approche diffère radicalement :

• Fail2ban : L'outil historique. Il lit les fichiers de logs locaux et utilise des expressions régulières (regex) pour compter les échecs. S'il dépasse un seuil, il appelle une action (souvent iptables) pour bloquer l'IP.
  • Avantages : Très léger, stable, sans dépendance externe, simple à configurer pour des besoins basiques.
  • Inconvénients : Analyse uniquement locale (ne profite pas des attaques subies par les autres), les regex peuvent être gourmandes en CPU sur de très gros volumes de logs.
• CrowdSec : Une approche moderne et collaborative. Il utilise un moteur de scénarios pour détecter les comportements et repose sur deux composants clés :
  • LAPI (Local API) : Elle centralise les détections de vos agents locaux et instruit les bouncers (pare-feu, proxy) sur les actions de blocage à prendre au sein de votre infrastructure.
  • CAPI (Central API) : Elle reçoit vos signaux d'attaque anonymisés et vous renvoie en temps réel la base de réputation mondiale alimentée par la communauté.
  • Avantages : Protection proactive, bouncers multi-couches, idéal pour les architectures distribuées.
  • Inconvénients : Installation plus complexe et dépendance à Internet pour la CAPI.

Fail2ban (Exemple avec HAProxy)

Fail2ban surveille le fichier de log de HAProxy et bannit les IPs qui génèrent trop d'erreurs d'authentification.

# /etc/fail2ban/jail.local
[haproxy-http-auth]
enabled  = true
filter   = haproxy-http-auth
logpath  = /var/log/haproxy.log
maxretry = 3
bantime  = 3600

CrowdSec (Exemple avec HAProxy)

Pour HAProxy, CrowdSec utilise souvent un bouncer LUA qui vérifie l'IP en temps réel auprès de l'agent CrowdSec.

frontend http-in
    # Chargement du script LUA du bouncer CrowdSec
    lua-load /var/lib/crowdsec/lua/bouncer.lua

    # Appel du bouncer pour vérification avant traitement
    http-request lua.crowdsec_allow

CrowdSec (Exemple avec Traefik)

CrowdSec est une alternative moderne et collaborative. Pour Traefik, on utilise généralement un Bouncer sous forme de middleware pour bloquer les requêtes avant qu'elles n'atteignent le backend.

# Configuration Traefik (Middleware via Plugin)
http:
  middlewares:
    crowdsec-bouncer:
      plugin:
        crowdsec-bouncer:
          enabled: true
          crowdsecLapiHost: crowdsec-agent:8080
          crowdsecLapiKey: "votre_api_key"

Conclusion

L'importance d'une défense en profondeur.

Aller plus loin

En plus des protections applicatives locales, il est recommandé de coupler votre architecture à des services tiers (Cloudflare, AWS Shield) pour les attaques volumétriques massives au niveau réseau (Couche 3 et 4).