DoS et DDoS

Un DoS (Denial of Service) est une attaque par déni de service, soit une saturation des ressources pour rendre un service indisponible. C’est l’un des risques qui peut toucher votre serveur dédié, surtout si vous avez des services accessibles publiquement.

L’attaquant va faire de nombreuses requêtes vers votre serveur depuis une adresse IP.

On parle de DDoS (Distributed Denial of Service) dans le cas d’un DoS où l’attaquant utilise de multiples adresses IP.

Pour aller plus loin : le guide de l’ANSSI à propos des DDoS

Il existe différentes mesures plus ou moins agressives pour se défendre en cas d’attaque.

On parle de mitigation quand on réussit à supprimer ou réduire l’impact d’une attaque DoS ou DDoS.

Mesures anti-(D)DoS

Une attaque peut agir à plusieurs niveaux : au niveau applicatif (par exemple cibler une page ou plusieurs d’un site web), au niveau protocole (par exemple ouvrir un grand nombre de connexions TCP), au niveau réseau (par exemple saturer les états d’un firewall) ou encore niveau bande passante (saturer la connexion).

Il faut distinguer les mesures activées par défaut, et celles activables (manuellement ou automatiquement) en cas d’attaque. Une des raisons de ne pas activer certaines mesures est que cela peut provoquer du faux positif (des requêtes légitimes bloquées à tort).

Réduction maximale de la surface d’attaque

La plupart des attaques vont exploiter des services ouverts sans restriction. Nous nous efforçons donc de désactiver tout ce qui peut l’être, d’un point de vue système ou de restreindre l’accès au niveau firewall.

Pour le web, il faut également n’autoriser que ce qui est nécessaire. On va ainsi interdire par défaut l’accès à certains chemins au cas où : URL contenant .git par exemple. Dans certains cas, on pourra être amené à désactiver certains types de requêtes HTTP si elles sont inutilisées : TRACE, OPTIONS, DELETE, PATCH…

ModSecurity

ModSecurity est un WAF (Web Application Firewall) permettant de bloquer certaines requêtes HTTP (injections SQL, attaques XSS connues, etc.).

Nous l’activons en général par défaut si vous utilisez Apache, vous pouvez nous ouvrir un ticket pour vérifier qu’il est bien activé.

Nous utilisons ModSecurity avec OWASP ModSecurity Core Rule Set (CRS) qui est un ensemble de règles couvrant un large spectre d’attaques possibles.

Nous écrivons également des règles personnalisées.

Si vous n’utilisez pas Apache, il reste possible de mettre en place un reverse-proxy avec ModSecurity, soit avec Apache, soit avec HAProxy Entreprise.

Blocage des adresses IP

Lorsque nous observons une adresse IP qui fait trop de requêtes sur un service et provoque des alertes, nous vérifions l’origine et nous la bloquons temporairement.

Nous pouvons bloquer toutes les adresses IP d’un pays ou d’un opérateur, ce qui est parfois nécessaire lors d’un DDoS où l’attaquant utilise majoritairement des adresses IP de certains pays (cela vient souvent de la Russie, la Chine, la Corée du Sud et la Malaisie) ou de certains opérateurs (le plus souvent Amazon AWS, ChinaNet, etc.)

Nous pouvons écrire des scripts spécifiques pour bloquer des adresses IP en fonction de critères sur mesure (présence de motifs dans un fichier de logs, etc.).

Si besoin nous pouvons ajouter des « blocklists » dont certaines sont payantes (SpamHaus DROP, CrowdSec Blocklists, FireHOL etc.).

Fail2Ban

Fail2Ban permet d’automatiser le blocage d’adresses IP. Le blocage peut être réalisé à partir de messages d’erreur (erreurs d’authentification, accès à des pages web inexistantes ou protégées etc.) ou à partir d’un trop grand nombre de requêtes pendant une durée définie.

Si des services demandant un mot de passe sont accessibles publiquement (SSH, POP, IMAP, SMTP), cinq erreurs provoquent un blocage de l’adresse IP pendant 10 minutes. L’objectif premier est d’éviter du brute-force mais c’est également utile pour mitiger certaines attaques DDoS.

On peut aussi activer Fail2Ban pour des serveurs web, mais il est conseillé de séparer le contenu statique (CSS, JS, images etc.) pour que cela soit efficace. Ainsi on peut par exemple bloquer une adresse IP qui fait plus de 60 requêtes pendant 1 minute, ou qui obtient plus de 5 erreurs 403/404 pendant 30 secondes. On peut aussi bloquer les accès suivants différents critères selon ce qui est affiché dans les logs : URL, User-Agent… ce qui est pratique pour mitiger certaines attaques DDoS.

Évidemment tous les seuils sont personnalisables en fonction des besoins et des historiques d’attaques.

Bannir les bots nuisibles et inutiles

Nous bannissons par défaut les bots les plus connus pour être nuisibles et inutiles.

Et nous vous encourageons à bannir les bots inutiles pour vous.

Plus de détails sur la gestion des bots.

Firewall local

Par défaut votre serveur dédié a un firewall local “minifirewall” qui n’autorise que certains flux réseau en entrée et sortie.

Il bénéficie également de protections pour certaines attaques : activation des SYN cookies, ignorer certains paquets « bizarres » (requêtes ICMP ECHO/TIMESTAMP vers du broadcast/multicast, paquets IP avec l’option LSRR/SSRR, paquets ICMP de redirection) ou encore le filtrage de chemin inverse pour éliminer les paquets avec une adresse IP non conforme à la table de routage.

Firewalls en amont (infra Evolix)

Si vous êtes hébergés par Evolix, nous avons des firewalls en amont qui protègent d’un certain nombre d’attaques.

Nous bloquons par défaut un certain nombre d’adresses IP, fournies par des sources très fiables comme l’ANSSI ou collectées/vérifiées par nous-mêmes.

Nous bloquons par défaut tous les nouveaux paquets UDP venant de l’extérieur.

Nous bloquons par défaut tous les nouveaux paquets TCP venant de l’extérieur sauf ceux qui correspondant à des services communément publics : 22 (sera bien bloqué), 25, 80, 110, 143, 443, 465, 587, 993, 995, etc.

Cela constitue ainsi une double protection en complément du firewall local du serveur. Bien sûr, si besoin nous pouvons ajouter des règles exceptionnelles.

Les connexions inactives expirent assez rapidement pour éviter que trop d’états s’accumulent en cas d’attaque : de l’ordre de 5 à 30s pour l’établissement de connexions TCP, et plusieurs heures pour une connexion établie pour que cela ne perturbe pas le trafic légitime comme une connexion SSH par exemple.

Les paquets réseau qui arrivent sont ré-assemblés si ils étaient fragmentés, ils sont « normalisés » (suppression d’irrégularités) avant d’être transmis au serveur dédiés et ils sont bloqués si ils sont incorrects (combinaisons invalides de flags TCP, spoofing).

Au besoin nous activons directement les SYN cookies sur les firewalls ou nous pouvons mettre en place des limitations suivant certaines règles (nombre de nouvelles connexions par minute, ou nombre de paquets par minute). C’est par exemple le cas vers nos serveurs DNS et NTP publics, afin d’éviter une saturation.

Mise en place d’un reverse-proxy

Si vous avez un service critique, nous conseillons de mettre un ou plusieurs reverse-proxy en amont afin de mieux maîtriser d’éventuelles attaques.

Cela peut être “Boost Proxy” notre CDN-like basé sur HAProxy et Varnish, votre propre reverse-proxy dédié, ou encore l’utilisation d’un service externe comme CloudFlare dans certains cas particuliers.

IDS Suricata (infra Evolix)

Notre réseau à Marseille dispose d’un IDS (Intrusion detection System) permettant de détecter des activités suspectes sur notre réseau.

Cela nous permet de réagir rapidement en cas de trafic anormal et potentiellement d’anticiper de futures attaques.

Wanguard (infra Evolix)

L’un de nos fournisseurs de transit réseau a en place une solution Wanguard permettant une détection de DDoS et une mitigation en amont de notre réseau.

Conseils

L’attaque la plus simple est de solliciter votre applicatif pour qu’il sature les ressources. Il est donc important de mettre en œuvre des bonnes pratiques pour réduire les possibilités d’attaques au niveau applicatif.

Voici nos conseils dans le cas d’applications ou sites web.

Protégez vos interfaces d’administration et API

Vos interfaces d’administration peuvent être la cible d’attaques, nous vous conseillons d’ajouter en plus de vos mécanismes applicatifs d’identification une restriction d’accès par adresse IP ou par VPN.

Dans la mesure du possible, si vous exposez une API protégez là également avec une restriction par adresse IP.

Mettez du cache au maximum

Si une simple requête HTTP provoque à chaque fois l’exécution d’un language dynamique, des requêtes SQL, etc. il sera facile pour un attaquant de provoquer une saturation des ressources.

Mettez du cache pour limiter les requêtes SQL, mettez du cache pour limiter l’exécution coûteuse d’un language dynamique et mettez du cache HTTP pour limiter la sollicitation de vos serveurs.

Renvoyez une page 404 très légère

Parfois les attaques sont aveugles, elles essayent par exemple de trouver des interfaces d’admin en essayant /phpmyadmin/ puis /phpmyadmin-5-2-1/ etc. alors que votre site n’a pas de “phpMyAdmin”.

Vous devez donc vous assurez que pour de telles requêtes vous renvoyez une page “404 NOT FOUND” très légère, idéalement un fichier HTML « statique ».

Sécurisez vos inputs

Les attaquants raffolent des éléments « input » dans une page web : c’est une porte ouverte pour les attaques XSS (Cross-site scripting) mais c’est aussi souvent la possibilité de saturer vos ressources.

Vérifiez et limitez les valeurs possibles pour tous vos éléments « inputs ».

Pour les formulaires, ajoutez un CAPTCHA.

Pour les recherches, limitez le nombre de recherches possibles pour une même adresse IP. Par exemple, si il y a plus de 3 recherches en 30 secondes, demandez une confirmation à l’utilisateur voire un CAPTCHA. Si la demande vous paraît abusive, bloquez l’adresse IP temporairement.

Méfiez vous particulièrement si vous avez une « recherche à facettes », cela risque de générer une infinité d’URL accessibles facilement à n’importe que bot qui risque de saturer vos ressources si il parcourt toutes les URL sans restriction.

Générez des logs d’erreur pour Fail2Ban

En cas de comportement suspect, générez des logs où vous mettrez l’adresse IP qui a généré la requête. Cela peut être une erreur de mot de passe, l’envoi d’input invalide, ou même plus simplement l’envoi d’un formulaire ou l’exécution d’une recherche.

Grâce au logiciel Fail2Ban installé sur votre serveur, nous pourrons écrire des règles personnalisées pour bloquer temporairement une adresse IP si elle a provoqué trop de requêtes suspects ou lourdes sur un certain délai. Pour mettre en place ce type de protection, ouvrez-nous un ticket en nous donnant les messages et le chemin du log concerné.

Parcourez vos logs et stats

Même quand tout va bien, parcourez vos fichiers de logs d’erreur, de logs d’accès, etc. Regardez vos statistiques d’accès : les pages les plus sollicitées, les “User-Agent” qui parcourent vos pages… et demandez nous de bloquer le trafic que vous jugez illégitime.

WordPress

WordPress est l’application web la plus utilisée au monde, cela implique qu’elle est la cible de nombreuses attaques en tout genre.

Si vous utilisez WordPress, appliquez nos conseils de sécurité pour WordPress

FAQ

Si mon voisin subit une attaque DDoS, puis-je être impacté ?

Certaines attaques DDoS peuvent saturer les états ou la bande passante d’un firewall en amont et impacter les autres serveurs passant le même firewall. Dans ces cas, nous intervenons pour mettre en place des limitations sur le nombre de paquets par minute. Dans les cas les plus extrêmes, nous pouvons annoncer l’IP du serveur attaqué en « blackhole » à nos transits/peerings ce qui stoppera complètement l’attaque et nous mettrons en place un contournement.