Protection contre les DDoS et les bots malveillants : guide
Comment une attaque DDoS et le trafic de bots malveillants ralentissent un site, quelles couches de protection existent et quel niveau choisir.
Équipe rabbitclipPublié: 8 min de lecture
En bref
Une attaque DDoS envoie à un site un nombre écrasant de requêtes, depuis de nombreuses sources en même temps, si bien que le serveur ne peut plus répondre ; le but n'est pas de voler des données, mais d'empêcher les vrais visiteurs d'entrer. Le trafic de bots malveillants est plus discret : des logiciels automatiques copient le contenu, remplissent des formulaires, testent des pages de connexion ou consomment simplement les ressources du serveur. La protection ne repose pas sur un seul produit, mais sur des couches qui filtrent les requêtes avant qu'elles n'atteignent le serveur : un filtre en périphérie du réseau, un pare-feu applicatif web, des limites de débit et les réglages du serveur lui-même.
La question pratique d'un propriétaire est le plus souvent la suivante : mon site est devenu lent ou ne s'affiche plus, s'agit-il d'une attaque ou d'une véritable affluence ? La réponse se trouve dans l'origine du trafic et dans son comportement. Un afflux après une campagne est dispersé mais se comporte comme des humains ; une attaque frappe en général la même page, de la même manière, à une vitesse inhabituelle.
Cet article distingue les deux menaces, énumère les couches de protection et explique pourquoi toutes les entreprises n'ont pas besoin des mêmes mesures.
Quelle différence entre DDoS et trafic de bots malveillants ?
Le DDoS est bruyant et agit vite. Il arrive plus de requêtes que le serveur ou sa connexion réseau ne peut en porter, et le site ralentit ou ne s'ouvre plus du tout. L'attaque est le plus souvent répartie sur de nombreuses machines, c'est pourquoi bloquer une seule adresse ne sert à rien.
Le trafic de bots malveillants est constant et de faible volume. Un bot parcourt votre liste de prix, un autre inonde le formulaire de commentaires de liens, un troisième devine des mots de passe sur la connexion d'administration. Aucun ne met le site à terre en un instant, mais ensemble ils usent les ressources du serveur, le budget publicitaire (par de faux clics) et la fiabilité de vos statistiques. On répond aux deux menaces avec des outils différents.
Comment savoir qu'un site est attaqué ?
Le premier signe est un ralentissement qui ne correspond pas au nombre de visiteurs. Si le site est lent alors qu'il n'y a ni soldes ni poussée publicitaire, et que les graphiques de ressources du serveur touchent le plafond, le soupçon est justifié. Le deuxième signe, ce sont des requêtes anormalement fréquentes dans les journaux du serveur, venant de la même plage d'adresses ou visant la même page ; un trafic qui culmine à des heures étranges est aussi un indice.
Pour un diagnostic ferme, il faut lire les journaux du serveur, ce que nous avons décrit ailleurs en langage simple. Les signes typiques sont les suivants.
- Trafic et lenteur soudains sans campagne ni annonce
- Requêtes qui s'accumulent sur une page ou sur l'adresse de connexion
- Fort trafic venant de pays d'où ne viennent pas vos vrais clients
- Entrées absurdes ou répétées qui arrivent par les formulaires
- Alertes de limite de ressources de la part de votre hébergeur
De quelles couches se compose la protection ?
La première couche est la périphérie du réseau. Placer un service de protection et de diffusion devant le site absorbe la plus grande partie du trafic d'attaque avant qu'il n'atteigne votre serveur. Si l'adresse réelle du serveur principal reste cachée, un attaquant ne peut pas la viser directement. Les avantages de vitesse de cette approche au quotidien font l'objet d'un article distinct.
La deuxième couche se situe au niveau de l'application. Un pare-feu applicatif web (WAF) coupe les schémas malveillants connus et les requêtes suspectes, tandis qu'une limite de débit restreint le nombre de requêtes qu'une adresse peut faire en un temps donné. La troisième couche est le site lui-même : limiter les tentatives de connexion, ajouter un contrôle invisible aux formulaires et mettre en cache les pages lourdes rendent le serveur plus résistant à la même attaque.
Chaque couche est incomplète seule. Un filtre réseau ne corrige pas une faille applicative, et un WAF n'arrête pas une inondation au niveau du réseau ; ensemble, elles répartissent le risque.
Quelle entreprise a besoin de quelles mesures ?
Choisissez les mesures selon le risque réel du site. Pour un petit site vitrine, une protection de base en périphérie du réseau, des logiciels à jour et une limite de tentatives de connexion suffisent en général. Si être hors ligne ne vous coûte aucun revenu direct, une installation chère et compliquée est disproportionnée.
Les boutiques en ligne, les systèmes de réservation et les sites qui encaissent des paiements sont différents : chaque heure hors ligne, ce sont des ventes perdues et de la confiance perdue. Pour ceux-là, un WAF, des limites de débit, une gestion des bots malveillants et un plan de contact pour le moment d'une attaque doivent être envisagés ensemble. Tester la charge et la résistance avant une période de campagne est également judicieux.
Quand acheter une protection est-il un mauvais choix ?
Il existe des cas où acheter une protection n'est pas la réponse. Si le problème n'est pas une attaque mais un hébergement faible (un site qui atteint la limite de ressources sur un serveur mutualisé, par exemple), un service de protection ne le résoudra pas ; la vraie solution est une infrastructure plus grande ou un site plus léger. Commencez par diagnostiquer si le trafic est réellement une attaque.
De même, se reposer sur une liste de blocage en disant « nous avons exclu tous les bots » est une erreur. Les robots d'exploration des moteurs de recherche et les services de paiement ou de surveillance sont aussi des bots, et les bloquer tous peut retirer votre site des résultats de recherche. Le but n'est pas de détruire les bots, mais de distinguer les mauvais des bons.
Quelles erreurs sont fréquentes ?
L'erreur la plus courante est de chercher une protection une fois l'attaque commencée. Modifier le DNS et mettre en place un nouveau service en plein incident prend du temps et ajoute le risque de nouvelles erreurs. Mettre en place à l'avance une protection simple en périphérie demande bien moins de travail que de le faire en pleine crise.
Une autre erreur est de laisser exposée l'adresse réelle du serveur principal ; même avec un service de protection, un attaquant peut trouver l'adresse par un autre enregistrement et frapper directement. Voici des erreurs fréquentes.
- Mettre en place une protection mais laisser exposées l'adresse réelle du serveur ou d'anciens enregistrements
- Ne prévoir ni limite de tentatives ni seconde vérification sur la page de connexion
- Croire que le fichier robots arrêtera les bots malveillants ; il ne s'adresse qu'aux bots qui choisissent de lui obéir
- Ne pas décider à l'avance qui fait quoi pendant une attaque
- Ne pas mettre à jour les logiciels et les extensions ; les attaques exploitent souvent une faille connue
Que faire pendant une attaque ?
Restez d'abord calme et déterminez ce qui est touché : tout le site, une seule page, uniquement la connexion ? Contactez ensuite votre hébergeur et l'éventuel service de protection ; beaucoup de fournisseurs peuvent ajouter des mesures de filtrage du trafic pendant une attaque. Avoir cette conversation à l'avance plutôt qu'en pleine crise change beaucoup de choses.
Après l'attaque, examinez les journaux : quelle page était visée, quelle faiblesse a été exploitée, quelle mesure a fonctionné. Ce savoir façonne la prochaine installation. Pour un aperçu rapide de la sécurité générale de votre site, vous pouvez utiliser notre outil de vérification de la sécurité et du SSL.
La protection contre les DDoS et le trafic de bots malveillants n'est pas un outil unique, mais des couches posées à la périphérie du réseau, dans l'application et sur le site ; ce qu'il vous en faut dépend de ce que coûterait une interruption. Un petit site vitrine se contente d'une protection de base, tandis qu'un site qui génère des revenus demande une organisation en couches et planifiée. Si vous souhaitez évaluer ensemble le risque réel de votre site, rabbitclip se fera un plaisir d'organiser un échange de découverte, dans le calme.
Questions fréquentes
Une attaque DDoS vole-t-elle des données ?
En général non ; son but est de rendre le site inaccessible. Une attaque sert parfois de diversion, il vaut donc la peine de vérifier toute autre faiblesse pendant et après un incident.
Pourquoi un petit site serait-il attaqué ?
Les attaquants ne choisissent souvent pas un site en particulier ; des logiciels automatiques balaient le web à la recherche de sites ouverts et vulnérables. Chaque site a donc besoin de logiciels à jour et d'une couche de protection de base.
Est-il juste de bloquer tous les bots ?
Non. Les robots des moteurs de recherche et certains services de surveillance sont aussi des bots, et les bloquer nuit à la visibilité du site dans les recherches. Le but est de séparer les bots malveillants de ceux qui se comportent bien.
Mon hébergeur ne me protège-t-il pas déjà ?
Certains fournisseurs offrent une protection de base au niveau du réseau, mais l'étendue diffère. Le plus sûr est de demander par écrit à votre fournisseur quels types d'attaque il couvre et jusqu'à quelle taille.
Une limite de débit bloquera-t-elle de vrais clients ?
Pas si le seuil est raisonnable. Il est fixé au-dessus de l'usage normal d'un vrai visiteur mais en dessous de la vitesse d'une attaque, et ajusté durant les premières semaines en observant les journaux.
