Comment protéger un serveur contre les attaques DDoS avec un proxy : configuration en 15 minutes

Les attaques DDoS peuvent paralyser le fonctionnement de n'importe quel service web en quelques minutes. Les attaquants envoient des milliers de requêtes depuis différentes adresses IP, surchargeant le serveur et le rendant inaccessible aux utilisateurs réels. Les serveurs proxy sont l'un des outils de protection efficaces, permettant de filtrer le trafic malveillant, de répartir la charge et de masquer l'adresse IP réelle de votre serveur.

Dans ce guide, nous allons examiner comment configurer un proxy pour se protéger contre les DDoS, quels types de proxies utiliser et comment construire un système de sécurité multicouche. Le matériel est destiné aux administrateurs systèmes, aux propriétaires de services web et aux spécialistes DevOps.

Comment fonctionnent les attaques DDoS et pourquoi les proxies aident

DDoS (Distributed Denial of Service) est une attaque distribuée par déni de service. L'attaquant utilise un botnet composé de milliers de dispositifs infectés qui envoient simultanément des requêtes à votre serveur. L'objectif est d'épuiser les ressources du serveur (processeur, mémoire, bande passante) et de le rendre inaccessible aux utilisateurs légitimes.

Les principaux types d'attaques DDoS :

• Attaques volumétriques — remplissent la bande passante avec une énorme quantité de trafic (amplification DNS, inondation UDP)
• Attaques par protocole — exploitent des vulnérabilités dans les protocoles réseau (inondation SYN, Ping of Death)
• Attaques de couche applicative — imitent des requêtes légitimes à une application web (inondation HTTP, Slowloris)

Les serveurs proxy aident à se protéger contre les DDoS de plusieurs manières :

• Masquage de l'adresse IP réelle du serveur — les attaquants ne voient que l'IP du proxy, et non celle de votre serveur principal
• Filtrage du trafic malveillant — le proxy analyse les requêtes et bloque celles qui sont suspectes
• Répartition de la charge — plusieurs serveurs proxy répartissent le trafic entre les serveurs backend
• Limitation de débit — restriction du nombre de requêtes provenant d'une seule adresse IP
• Mise en cache du contenu statique — réduit la charge sur le serveur principal

Il est important de comprendre que les proxies ne sont pas une panacée contre tous les types de DDoS. Des attaques volumétriques puissantes peuvent saturer la bande passante jusqu'au serveur proxy. Par conséquent, les proxies sont efficaces en combinaison avec d'autres méthodes de protection : CDN, services anti-DDoS dans le cloud (Cloudflare, AWS Shield), pare-feu.

Types de proxies pour se protéger contre les DDoS : inverses vs directs

Pour se protéger contre les DDoS, deux principaux types de serveurs proxy sont utilisés :

Proxies inverses

Un proxy inverse se trouve devant votre serveur web et accepte toutes les requêtes entrantes des clients. Les clients n'interagissent qu'avec le proxy, sans connaître l'adresse IP réelle de votre serveur. C'est l'outil principal pour se protéger contre les DDoS.

Solutions populaires pour les proxies inverses :

• Nginx — serveur web rapide et léger avec des fonctionnalités de proxy inverse
• HAProxy — équilibreur de charge spécialisé avec de puissantes capacités de filtrage
• Apache mod_proxy — module pour Apache, moins performant que Nginx
• Varnish — accélérateur HTTP axé sur la mise en cache

Proxies directs

Les proxies directs sont utilisés du côté client pour les requêtes sortantes. Dans le contexte de la protection contre les DDoS, ils sont moins souvent utilisés, mais peuvent être utiles pour :

• Masquer les adresses IP de vos serveurs lors de l'accès à des API externes
• Répartir le trafic sortant à travers de nombreuses adresses IP
• Contourner les blocages lors de la collecte d'informations sur les attaques potentielles

Pour ces tâches, les proxies résidentiels sont adaptés — ils ont de vraies adresses IP d'utilisateurs domestiques et ressemblent à un trafic normal, ce qui rend leur détection et leur blocage plus difficiles.

Configuration d'un proxy inverse sur Nginx pour protéger le serveur

Nginx est l'un des outils les plus populaires pour créer un proxy inverse. Il traite rapidement les requêtes entrantes, prend en charge la limitation de débit et peut filtrer le trafic suspect.

Configuration de base d'un proxy inverse

Installez Nginx sur un serveur distinct qui recevra tout le trafic entrant. Le véritable serveur web doit être masqué derrière le proxy et ne recevoir des requêtes que de celui-ci.

# /etc/nginx/nginx.conf

http {
    # Limitation du nombre de connexions depuis une seule IP
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
    limit_conn conn_limit 10;

    # Limitation du nombre de requêtes (limitation de débit)
    limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;
    limit_req zone=req_limit burst=20 nodelay;

    # Timeouts pour se protéger contre Slowloris
    client_body_timeout 10s;
    client_header_timeout 10s;
    keepalive_timeout 5s 5s;
    send_timeout 10s;

    upstream backend {
        # IP de votre véritable serveur web
        server 192.168.1.100:80;
        # Vous pouvez ajouter plusieurs serveurs pour l'équilibrage
        # server 192.168.1.101:80;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            # Transmission des requêtes au backend
            proxy_pass http://backend;
            
            # Transmission de l'IP originale du client
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $host;
            
            # Timeouts pour le proxy
            proxy_connect_timeout 5s;
            proxy_send_timeout 10s;
            proxy_read_timeout 10s;
        }
    }
}

Blocage des User-Agent suspects

De nombreuses attaques DDoS utilisent des bots avec des User-Agent caractéristiques. Ajoutez des règles pour les bloquer :

# Blocage des bots connus
map $http_user_agent $bad_bot {
    default 0;
    ~*bot 1;
    ~*crawler 1;
    ~*spider 1;
    ~*scraper 1;
    "" 1; # User-Agent vide
}

server {
    listen 80;
    server_name example.com;

    if ($bad_bot) {
        return 403;
    }

    location / {
        proxy_pass http://backend;
    }
}

Geo-blocage des pays indésirables

Si votre service fonctionne uniquement pour certains pays, vous pouvez bloquer le trafic en provenance d'autres régions à l'aide du module GeoIP :

# Installation du module GeoIP
# apt-get install nginx-module-geoip

load_module modules/ngx_http_geoip_module.so;

http {
    geoip_country /usr/share/GeoIP/GeoIP.dat;

    # Autoriser uniquement le trafic en provenance de la Russie et de l'Ukraine
    map $geoip_country_code $allowed_country {
        default no;
        RU yes;
        UA yes;
    }

    server {
        listen 80;
        server_name example.com;

        if ($allowed_country = no) {
            return 403;
        }

        location / {
            proxy_pass http://backend;
        }
    }
}

HAProxy pour la répartition de la charge et le filtrage du trafic

HAProxy est un puissant équilibreur de charge avec des capacités avancées de filtrage du trafic. Il prend en charge des ACL (Listes de Contrôle d'Accès) complexes pour bloquer les attaques au niveau des applications.

Configuration de base de HAProxy

# /etc/haproxy/haproxy.cfg

global
    maxconn 50000
    # Journalisation
    log /dev/log local0
    log /dev/log local1 notice

defaults
    mode http
    log global
    option httplog
    option dontlognull
    
    # Timeouts
    timeout connect 5s
    timeout client 30s
    timeout server 30s
    
    # Limitation de la taille de la requête (protection contre les inondations POST)
    maxconn 3000

frontend http_front
    bind *:80
    
    # Limitation de débit : maximum 100 requêtes en 10 secondes depuis une seule IP
    stick-table type ip size 100k expire 30s store http_req_rate(10s)
    http-request track-sc0 src
    http-request deny if { sc_http_req_rate(0) gt 100 }
    
    # Blocage des requêtes sans en-tête Host
    acl has_host hdr(host) -m found
    http-request deny if !has_host
    
    # Blocage des User-Agent suspects
    acl bad_bot hdr_sub(User-Agent) -i bot crawler spider scraper
    http-request deny if bad_bot
    
    # Transmission au backend
    default_backend web_servers

backend web_servers
    balance roundrobin
    option httpchk GET /health
    
    # Liste des serveurs backend
    server web1 192.168.1.100:80 check
    server web2 192.168.1.101:80 check
    server web3 192.168.1.102:80 check

Protection contre l'inondation HTTP avec des ACL

L'inondation HTTP est une attaque où l'attaquant envoie de nombreuses requêtes HTTP légitimes. HAProxy permet de créer des règles complexes pour les détecter :

frontend http_front
    bind *:80
    
    # Suivi du nombre de requêtes depuis une seule IP
    stick-table type ip size 100k expire 30s store http_req_rate(10s),conn_cur
    http-request track-sc0 src
    
    # Blocage en cas de dépassement des limites
    acl too_many_requests sc_http_req_rate(0) gt 50
    acl too_many_connections sc_conn_cur(0) gt 10
    
    http-request deny deny_status 429 if too_many_requests
    http-request deny deny_status 429 if too_many_connections
    
    # Blocage des requêtes vers des chemins inexistants (scan)
    acl valid_path path_beg /api /static /login /
    http-request deny if !valid_path
    
    default_backend web_servers

Liste blanche des adresses IP de confiance

Créez une liste blanche pour les adresses IP de confiance (par exemple, vos adresses de bureau ou de partenaires) qui ne seront pas soumises à la limitation de débit :

frontend http_front
    bind *:80
    
    # Liste blanche des adresses IP de confiance
    acl whitelist src 203.0.113.0/24 198.51.100.50
    
    # Limitation de débit uniquement pour les IP non dans la liste blanche
    stick-table type ip size 100k expire 30s store http_req_rate(10s)
    http-request track-sc0 src if !whitelist
    http-request deny if { sc_http_req_rate(0) gt 100 } !whitelist
    
    default_backend web_servers

Utilisation de proxies résidentiels pour masquer l'infrastructure

En plus des proxies inverses devant votre serveur, vous pouvez utiliser des proxies résidentiels pour une protection supplémentaire de l'infrastructure. Cela est particulièrement pertinent si vous devez :

• Masquer les adresses IP de vos serveurs de surveillance — si vous suivez les attaques DDoS ou collectez des informations sur les menaces, les proxies résidentiels aideront à masquer vos actions
• Accéder à des API externes sans révéler l'infrastructure — vos serveurs peuvent faire des requêtes via des proxies résidentiels, ce qui rend leur détection plus difficile
• Tester la protection contre les DDoS — simuler des attaques depuis différentes adresses IP pour vérifier l'efficacité de vos filtres

Les proxies résidentiels ont des adresses IP réelles d'utilisateurs domestiques, ce qui les rend indiscernables du trafic normal. Cela rend leur blocage difficile et permet de contourner les restrictions géographiques.

Exemple : Surveillance des menaces via des proxies résidentiels

Supposons que vous souhaitiez suivre l'activité des botnets qui pourraient attaquer votre service. En utilisant des proxies résidentiels, vous pouvez collecter des informations sans révéler les adresses IP de vos serveurs :

import requests

# Configuration du proxy résidentiel
proxies = {
    'http': 'http://username:password@residential-proxy.com:8080',
    'https': 'http://username:password@residential-proxy.com:8080'
}

# Collecte d'informations sur les menaces potentielles
threat_sources = [
    'http://suspicious-site1.com',
    'http://suspicious-site2.com'
]

for source in threat_sources:
    try:
        response = requests.get(source, proxies=proxies, timeout=5)
        # Analyse de la réponse pour identifier les modèles d'attaques
        print(f"Statut : {response.status_code}, IP : {response.headers.get('X-Your-IP')}")
    except Exception as e:
        print(f"Erreur lors de l'accès à {source} : {e}")

Règles de filtrage : comment distinguer une attaque d'un trafic légitime

La principale difficulté de la protection contre les DDoS au niveau des applications (L7) est de distinguer le trafic malveillant du trafic légitime. Les attaques modernes imitent le comportement des utilisateurs réels, ce qui rend leur détection difficile.

Signes d'une attaque DDoS

• Augmentation soudaine du nombre de requêtes — 2 à 10 fois plus que d'habitude sur une courte période
• Requêtes avec le même User-Agent — les bots utilisent souvent le même User-Agent
• Absence de Referer — requêtes directes sans passage par d'autres pages
• Requêtes similaires — appels au même URL avec des variations minimales
• Absence de JavaScript — les bots n'exécutent pas le code JS sur la page
• Temps de présence bas sur la page — les bots ferment immédiatement la connexion après avoir reçu une réponse
• Plages IP suspectes — requêtes massives provenant d'un même sous-réseau

Filtrage multicouche

Une protection efficace utilise plusieurs niveaux de filtrage :

Exemple : Défi JavaScript dans Nginx

Un moyen simple de filtrer les bots consiste à exiger l'exécution de JavaScript pour définir un cookie :

server {
    listen 80;
    server_name example.com;

    # Vérification de la présence du cookie
    set $has_cookie 0;
    if ($http_cookie ~* "verified=true") {
        set $has_cookie 1;
    }

    # Si le cookie n'est pas présent, affichons le défi JS
    location / {
        if ($has_cookie = 0) {
            return 200 '
                <html>
                <head><title>Vérification</title></head>
                <body>
                <script>
                    document.cookie = "verified=true; path=/";
                    window.location.reload();
                </script>
                <noscript>Veuillez activer JavaScript</noscript>
                </body>
                </html>
            ';
        }

        proxy_pass http://backend;
    }
}

Surveillance et réponse aux DDoS en temps réel

Une protection efficace contre les DDoS nécessite une surveillance constante du trafic et une réponse rapide aux anomalies. Configurez un système de surveillance qui suivra les métriques clés :

• Nombre de requêtes par seconde — une augmentation soudaine peut indiquer une attaque
• Nombre d'adresses IP uniques — les DDoS proviennent souvent de nombreuses IP
• Pourcentage d'erreurs 4xx/5xx — une augmentation des erreurs peut être un signe de surcharge
• Temps de réponse du serveur — une augmentation de la latence indique des problèmes
• Consommation des ressources — CPU, mémoire, trafic réseau

Outils de surveillance

Configuration des alertes dans Prometheus

Créez des règles pour alerter automatiquement en cas d'anomalies détectées :

# prometheus_alerts.yml

groups:
  - name: ddos_detection
    interval: 10s
    rules:
      # Alerte en cas d'augmentation soudaine des requêtes
      - alert: HighRequestRate
        expr: rate(nginx_http_requests_total[1m]) > 1000
        for: 1m
        labels:
          severity: warning
        annotations:
          summary: "Taux de requêtes élevé détecté"
          description: "Le taux de requêtes est de {{ $value }} req/s"

      # Alerte en cas d'augmentation des erreurs 5xx
      - alert: HighErrorRate
        expr: rate(nginx_http_requests_total{status=~"5.."}[5m]) > 10
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Taux d'erreurs 5xx élevé"
          description: "Erreurs 5xx : {{ $value }} req/s"

      # Alerte en cas d'utilisation élevée du CPU
      - alert: HighCPUUsage
        expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Utilisation élevée du CPU"
          description: "L'utilisation du CPU est de {{ $value }}%"

Réaction automatique avec Fail2ban

Fail2ban analyse les logs et bloque automatiquement les adresses IP qui dépassent les limites de requêtes :

# /etc/fail2ban/jail.local

[nginx-req-limit]
enabled = true
filter = nginx-req-limit
logpath = /var/log/nginx/access.log
maxretry = 100
findtime = 60
bantime = 3600
action = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]

# /etc/fail2ban/filter.d/nginx-req-limit.conf
[Definition]
failregex = ^<HOST> -.*"(GET|POST).*HTTP.*"
ignoreregex =

Protection multicouche : combinaison de proxies avec d'autres méthodes

Les serveurs proxy sont un élément important de la protection contre les DDoS, mais ils sont les plus efficaces en combinaison avec d'autres méthodes. Examinons l'architecture d'une protection multicouche :

Niveau 1 : Protection réseau (L3/L4)

• Services anti-DDoS dans le cloud — Cloudflare, AWS Shield, Google Cloud Armor filtrent le trafic avant qu'il n'atteigne vos serveurs
• Pare-feu matériels — équipements spécialisés pour filtrer le trafic réseau
• BGP blackholing — redirection du trafic malveillant vers un "trou noir" au niveau du fournisseur

Niveau 2 : CDN et mise en cache

• CDN (Content Delivery Network) — répartit le contenu statique sur de nombreux serveurs, réduisant la charge sur l'origine
• Mise en cache sur le proxy — Varnish, Nginx mettent en cache les pages populaires et les livrent sans appel au backend
• Optimisation du contenu — minification CSS/JS, compression des images réduisent le volume de trafic

Niveau 3 : Proxies et équilibrage (L7)

• Proxies inverses — Nginx, HAProxy filtrent les requêtes au niveau des applications
• Équilibrage de charge — répartition de la charge entre plusieurs serveurs backend
• Limitation de débit — restriction du nombre de requêtes provenant d'une seule IP
• WAF (Web Application Firewall) — ModSecurity, AWS WAF bloquent les attaques sur les applications web

Niveau 4 : Optimisation backend

• Optimisation de la base de données — index, mise en cache des requêtes, répliques de lecture
• Traitement asynchrone — les tâches lourdes sont exécutées en arrière-plan via des files d'attente (RabbitMQ, Redis)
• Scalabilité horizontale — ajout de nouveaux serveurs lors de l'augmentation de la charge

Exemple d'architecture

Client
  ↓
Cloudflare (anti-DDoS L3/L4, CDN)
  ↓
Nginx proxy inverse (limitation de débit, filtrage)
  ↓
HAProxy (répartition de la charge)
  ↓
Serveurs backend (application web)
  ↓
Base de données (avec réplication)

Une telle architecture assure une protection à tous les niveaux : réseau, transport, application. Même si une attaque passe un niveau, le suivant l'arrêtera.

Utilisation de proxies de centre de données pour une couche supplémentaire

Dans certains cas, il peut être judicieux d'ajouter des proxies de centre de données comme couche intermédiaire entre le CDN et vos serveurs. Ils offrent une vitesse de traitement élevée et peuvent effectuer un filtrage supplémentaire du trafic. Les proxies de centre de données sont moins chers que les résidentiels et mobiles, ce qui en fait une solution économiquement viable pour traiter de grands volumes de trafic.

Conclusion

La protection contre les attaques DDoS à l'aide de serveurs proxy est une méthode efficace qui permet de filtrer le trafic malveillant, de masquer les adresses IP réelles des serveurs et de répartir la charge. Les proxies inverses basés sur Nginx ou HAProxy offrent une configuration flexible des règles de filtrage, de limitation de débit et de blocage des requêtes suspectes.

Points clés que nous avons abordés :

• Proxies inverses (Nginx, HAProxy) — outil principal de protection au niveau des applications (L7)
• Limitation de débit et filtrage par User-Agent, réputation IP aident à filtrer la plupart des attaques
• Proxies résidentiels utiles pour masquer l'infrastructure de surveillance et collecter des informations sur les menaces
• Protection multicouche (CDN + proxies + WAF + optimisation backend) assure une résilience maximale
• Surveillance et réponse automatique sont cruciales pour une détection rapide et un blocage des attaques

N'oubliez pas que les attaques DDoS évoluent constamment, donc le système de protection nécessite des mises à jour et des tests réguliers. Effectuez des tests de charge, analysez les logs, mettez à jour les règles de filtrage et restez informé des nouvelles méthodes d'attaques.

Si vous prévoyez de construire un système de protection multicouche utilisant des proxies, nous vous recommandons d'envisager des proxies résidentiels pour masquer l'infrastructure critique et des proxies de centre de données pour un traitement à haute vitesse de grands volumes de trafic. La combinaison de différents types de proxies assure un équilibre optimal entre sécurité, performance et coût.