Stratégies de protection contre les attaques DDoS pour les infrastructures dédiées

Comprendre ce contre quoi tu te défends vraiment

Les attaques DDoS ne sont pas une menace unique. Cette catégorie comprend plusieurs types d'attaques qui demandent des stratégies de protection différentes :

Les attaques volumétriques inondent votre réseau de trafic : inondations UDP, inondations ICMP, attaques par amplification utilisant DNS ou NTP. Elles sont mesurées en Gbps et en Mpps (millions de paquets par seconde). Une attaque volumétrique de 100 Gbps contre un serveur avec une connectivité de 10 Gbps remplit tout simplement le réseau, peu importe la qualité de votre pare-feu au niveau du serveur. Pour atténuer ce problème, il faut nettoyer le trafic en amont avant qu'il n'atteigne votre centre de données.

Les attaques par protocole exploitent les faiblesses du TCP/IP, les inondations SYN étant les plus courantes. Elles épuisent la capacité de la table de connexion de votre serveur plutôt que la bande passante. Une inondation SYN soutenue peut mettre un serveur hors service sans saturer la liaison réseau.

Les attaques de couche 7 (application) visent directement ton application. Les attaques lentes et discrètes, comme Slowloris, gardent les connexions ouvertes pour toujours, épuisant les limites de connexion sans générer beaucoup de trafic. Les inondations HTTP envoient des requêtes qui ont l'air normales vers des points de terminaison d'applications coûteux : pages avec beaucoup de bases de données, téléchargements de gros fichiers, fonctions de recherche.

D'après le rapport 2024 Cloudflaresur les menaces DDoS, les attaques DDoS HTTP ont vraiment augmenté d'une année sur l'autre, et les attaques au niveau de la couche applicative représentent maintenant une bonne partie des incidents DDoS. Les attaques volumétriques existent toujours, mais les pirates sophistiqués visent de plus en plus la couche applicative, car le nettoyage volumétrique de base ne les arrête pas.

Couche 1 : Réduction en amont (centres de nettoyage)

Pour les attaques volumétriques, aucune configuration côté serveur ne sert à rien si ta connexion 10 Gbit/s est déjà saturée par 40 Gbit/s de trafic d'attaque. Il faut agir en amont, avant que le trafic n'atteigne ton serveur.

Magic TransitCloudflare et AWS Shield Advanced offrent tous les deux des services de nettoyage en amont qui filtrent le trafic avant qu'il n'arrive à ton centre de données. La capacité réseau Cloudflaredépasse les 250 Tbps, ce qui veut dire qu'ils peuvent gérer des attaques volumétriques qui submergeraient la capacité de transit d'un seul centre de données. Magic Transit annonce tes préfixes IP via BGP et achemine tout le trafic via l'infrastructure de nettoyage Cloudflare, ne laissant passer que le trafic propre vers ton serveur.

Cette couche est indispensable pour les infrastructures qui doivent garantir leur disponibilité pendant les attaques volumétriques. Les techniques côté serveur ci-dessous traitent les attaques de couche 7 et les attaques de protocole, mais elles ne résolvent pas le problème de l'épuisement de la bande passante.

Le réseau de serveurs dédiésInMotion Hosting offre une protection de base contre les attaques DDoS au niveau du centre de données. Si tu fais face à des menaces plus importantes, ajouter un CDN ou un service de nettoyage devant ton infrastructure InMotion te donnera la capacité en amont nécessaire pour gérer les grosses attaques.

Couche 2 : Limitation du débit au niveau du serveur web

Nginx Apache gèrent tous les deux la limitation du débit de connexion, ce qui empêche les inondations de couche 7 avant qu'elles ne prennent toutes les ressources du serveur d'applications.

Configuration de la limitation Nginx :

# Définir une zone de suivi des requêtes par adresse IP

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=30r/m;

serveur {

    emplacement /api/ {

        limit_req zone=api_limit burst=10 nodelay;

        limit_req_status 429 ;

    }

}

Cette configuration limite chaque adresse IP unique à 30 requêtes par minute vers les points de terminaison /api/, avec une autorisation de rafale de 10 requêtes avant que la limitation du débit ne s'active. La documentationNginxsur la limitation du débit couvre l'ensemble des paramètres. Définissez les débits en fonction du comportement légitime des utilisateurs : un utilisateur authentifié qui soumet un formulaire ne devrait pas déclencher de limite, contrairement à un script automatisé qui accède à un point de terminaison 500 fois par minute.

Limiter les connexions pour contrer les attaques de type Slowloris :

limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

serveur {

    limit_conn conn_limit 20 ;

    client_body_timeout 10s ;

    client_header_timeout 10s ;

    délai d'envoi 10 s ;

}

Les valeurs de délai d'attente sont super importantes. Slowloris envoie les en-têtes HTTP super lentement, ce qui maintient les connexions ouvertes. Des délais d'attente courts coupent ces connexions avant qu'elles ne s'accumulent.

Couche 3 : Règles de pare-feu pour limiter les attaques de protocole

La protection contre les attaques SYN flood commence par des réglages au niveau du noyau sous Linux :

# Activez les cookies SYN pour gérer les inondations SYN sans saturer les tables de connexion.

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

Réduire le nombre de fois où un SYN-ACK est renvoyé avant que le noyau ne coupe la connexion.

echo 2 > /proc/sys/net/ipv4/tcp_syn_retries

Réduire la durée de l'état TIME_WAIT pour recycler les connexions plus vite.

echo « 1 4 2 6 10 15 25 26 » > /proc/sys/net/ipv4/tcp_retries2

# Rendre permanent

sysctl -p

Pour limiter les risques au niveau du pare-feu, nftables (qui remplace iptables sur les distributions Linux récentes) permet de filtrer efficacement les paquets sans trop solliciter le processeur :

# Bloquer les paquets TCP pas valides (souvent utilisés dans les attaques par inondation SYN)

nft add rule inet filter input tcp flags ‘& (fin|syn|rst|psh|ack|urg) == fin|psh|urg’ drop

# Limiter le débit des nouvelles connexions

nft ajouter règle inet filtre entrée ct état nouvelle limite taux 100/seconde accepter

nft ajouter règle inet filtre entrée ct état nouveau abandonner

Fail2Ban bloque automatiquement les adresses IP en fonction des modèles de journaux, ce qui est super pratique quand il y a des tentatives d'authentification ratées à répétition ou des requêtes continues provenant d'une seule adresse IP qui passe à travers les limiteurs de débit. Fail2Ban lit tes journaux Nginx, Apache ou SSH et ajoute automatiquement des règles iptables/nftables quand les seuils sont dépassés.

Couche 4 : Réputation IP et filtrage géographique

Le filtrage par réputation IP bloque les adresses IP malveillantes connues avant qu'elles n'atteignent votre application. Des services comme AbuseIPDB gèrent des bases de données d'adresses IP ayant déjà été utilisées pour des abus. En ajoutant ces listes de blocage à votre pare-feu ou à votre WAF, vous éliminez le trafic provenant d'adresses IP déjà connues pour avoir participé à des attaques.

Le filtrage géographique, c'est un peu plus compliqué. Bloquer des pays entiers, ça peut sembler cool pendant une attaque, mais il faut bien réfléchir aux dégâts collatéraux. Les adresses IP résidentielles de n'importe quel pays peuvent être piratées et utilisées comme nœuds de botnet, donc le géoblocage offre rarement une protection parfaite. Pour les applis qui n'ont vraiment pas d'utilisateurs légitimes dans certaines régions, le filtrage géographique est une première couche de protection raisonnable.

Le niveau gratuit Cloudflarete permet de filtrer les adresses IP en fonction de leur réputation et de bloquer l'accès à partir de certains pays, sans avoir à bidouiller ton serveur.

Couche 5 : Protections au niveau des applications

Les attaques de couche 7 les plus ciblées visent délibérément les opérations applicatives coûteuses. Cibles courantes :

• Fonctions de recherche qui lancent des requêtes dans des bases de données en texte intégral
• Points de connexion qui ont besoin d'une comparaison de hachage bcrypt
• Points de terminaison pour le téléchargement de gros fichiers
• WordPress et points de terminaison d'administration s'ils sont accessibles à tout le monde

Protégez vos terminaux coûteux avec :

• Défis CAPTCHA via Cloudflare ou hCaptcha lors des connexions et inscriptions
• Clés API ou authentification sur n'importe quel point de terminaison qui exécute des requêtes de base de données
• RenforcementWordPress: désactive XML-RPC si tu n'en as pas besoin (refuse tout ; dans Nginx /xmlrpc.php), bloque l'accès à /wp-admin/ par liste blanche d'adresses IP si ton équipe est géographiquement cohérente.

Réaction aux incidents : quoi faire quand une attaque est en cours

Si t'es en train de te faire attaquer, voilà les priorités :

1. Identifie le type d'attaque: regarde netstat -an | grep SYN_RECV | wc -l pour les inondations SYN ; vérifie les journaux Nginx pour les modèles d'inondation HTTP ; vérifie iftop pour les attaques volumétriques.
2. Activez Cloudflare un proxy équivalent tout de suite: faites passer le trafic par un service de nettoyage si ce n'est pas déjà fait. C'est le moyen le plus rapide pour réduire le volume.
3. Temporary IP blocks for obvious attack sources: nft add rule inet filter input ip saddr <attack_ip> drop
4. Contactez le support InMotion: L'équipe APS peut vous aider à analyser le trafic et coordonner avec le centre d'exploitation du réseau pour le filtrage en amont.

Les équipes qui ont mis le moins de temps à se remettre des attaques DDoS sont celles qui ont testé leur plan d'action avant de se faire attaquer.