Protection anti-DDoS
Les saturations de trafic sont absorbées en périphérie, les attaques de couche réseau sont filtrées en amont et tout ce qui atteint le serveur est confiné dans une cage au niveau du noyau propre au site ciblé. Plusieurs couches, chacune accomplissant une tâche différente, garantissent qu’une attaque visant un site n’entraîne pas d’interruption pour les sites voisins. Il s’agit du modèle de défense que nous avons conçu pour une plateforme hébergeant plus de 700 000 sites à travers le monde, et le socle de base fonctionne sur chaque forfait. Disponibilité : la régulation de base de données par site est en cours de développement actif et n’est pas encore disponible. Tout le reste décrit ici est opérationnel dès aujourd’hui.
Une attaque volumétrique, une attaque applicative de niveau L7 et une attaque lente par épuisement des connexions constituent trois problèmes distincts. Nous traitons chacun d’eux là où cela s’avère le plus économique et le plus rapide : en amont du parc de serveurs, à la périphérie et au sein de la baie.
La protection DDoS au niveau du fournisseur filtre les saturations de la couche réseau en amont de notre parc de workers, avant que ce trafic ne consomme un port, une carte réseau ou un cycle de processeur sur la machine hébergeant votre site. Pour les profils de risque avancés et d’entreprise, Cloudflare Magic Transit et Spectrum étendent ce même filtrage au trafic non-HTTP.
Un réseau périphérique géré est placé devant chaque site. Il absorbe les attaques volumétriques HTTP flood, exécute un WAF L7, applique une limitation de débit par site et utilise la gestion des bots ainsi que des défis gérés pour distinguer les véritables visiteurs du trafic automatisé, le tout avant qu’une requête n’atteigne le serveur d’origine.
LiteSpeed Enterprise applique une régulation des connexions et des requêtes avec des limites de connexion par IP, Imunify360 exécute un pare-feu réseau avec une protection contre les attaques par force brute et un filtrage de réputation IP, et les plafonds de processus d’entrée de CloudLinux LVE limitent le nombre de requêtes simultanées qu’un seul site peut maintenir ouvertes.
LVE plafonne individuellement pour chaque site le processeur, la mémoire vive, les E/S, les IOPS, les processus et les processus d’entrée. Un afflux qui traverse les couches supérieures est bridé à l’intérieur de l’espace isolé du site cible, de sorte que la pression qu’il engendre reste confinée à ce site plutôt que de se propager à l’ensemble du serveur.
La plupart des interruptions d’hébergement lors d’une attaque ne sont pas causées par le fait que l’attaque atteint sa cible. Elles sont causées par la consommation de ressources de la cible qui prive tout le reste sur le serveur. C’est ce mode de défaillance que cette architecture est conçue pour éliminer.
La requête la plus économique à traiter est celle qui n’atteint jamais PHP ou MySQL. Grâce à notre cache à deux niveaux, une grande partie des saturations au niveau applicatif est servie par des octets statiques sans solliciter votre serveur d’origine.
L’atténuation n’est pas un ticket d’assistance. Les signaux alimentent un moteur de politiques qui associe chacun d’eux à une mesure d’application, une notification au client et — dans la mesure du possible — une correction automatique, chaque transition étant journalisée.
Lorsqu’un signal DDoS se déclenche, le moteur de règles applique l’atténuation Cloudflare et la limitation de débit par site, et peut durcir dynamiquement les limites LVE de ce site. Lorsque le signal disparaît, les limites s’assouplissent à nouveau. Gradué, réversible et consigné à chaque étape.
Si une attaque menace le serveur d’origine, le site passe à l’état « bridé » (throttled) : des limites LVE plus strictes et une limitation du débit sont appliquées, tandis que le site reste en ligne et fonctionnel. L’état bridé se rétablit automatiquement une fois la pression retombée ; il ne s’agit pas d’une suspension.
Sous le moteur de stratégies, LVE régule nativement et automatiquement l’utilisation du processeur, des entrées/sorties et des processus par site. Il s’agit de la première ligne de défense toujours active, qui fonctionne que le trafic ait déjà été classé comme une attaque ou non.
Chaque transition d’application enregistre son motif, qu’elle ait été automatique ou initiée par le personnel, ainsi que les preuves associées. Vous êtes informé de ce qui a changé et de la manière de le résoudre, et chaque action peut faire l’objet d’un recours.
La protection de base n’est pas facultative, car un site attaqué ou compromis menace ses voisins, la réputation de nos serveurs et nos plages d’adresses IP. Une protection plus renforcée existe pour les sites dont le profil de risque l’exige.
Un pic de trafic est souvent un symptôme. Le pipeline de signaux qui gère les flux massifs détecte également les compromissions qui en sont à l’origine, ce qui permet de classifier l’incident avec précision plutôt que de simplement l’absorber.
L’objectif de conception est le cloisonnement. Chaque site fonctionne au sein de sa propre cage CloudLinux LVE avec des plafonds de CPU, RAM, IO, IOPS, processus et processus d’entrée, sa propre vue du système de fichiers CageFS, et une régulation de la base de données par site via MySQL Governor. Un site attaqué est bridé à son propre plafond plutôt que de consommer toute la machine, et les limites de connexion par IP de LiteSpeed restreignent la part du serveur web qu’il peut mobiliser. Le cloisonnement est conçu au niveau du noyau, et non configuré par client.
La protection de base est incluse dans chaque forfait : isolation LVE et CageFS, régulation des connexions et des requêtes LiteSpeed, pare-feu réseau, WAF proactif et analyse des logiciels malveillants, avec absorption en périphérie Cloudflare et filtrage réseau au niveau du fournisseur en amont de l’infrastructure. Nous l’incluons car nous ne pouvons pas laisser la protection de notre propre infrastructure facultative. La gestion avancée des bots, les niveaux DDoS supérieurs, les règles WAF renforcées et les règles de pare-feu dédiées sont des modules complémentaires pour les sites qui en ont besoin.
Être la cible d’une attaque DDoS se traduit par une atténuation Cloudflare et une limitation du débit par site, et — uniquement si l’attaque menace le serveur d’origine — par l’état « throttled » : des limites LVE plus strictes, le site restant actif et opérationnel. L’état bridé se rétablit automatiquement dès que la charge diminue. La suspension est réservée aux défauts de paiement ou aux abus avérés, et même dans ce cas, le site affiche une page d’attente personnalisée indiquant le motif précis plutôt qu’une page d’erreur.
Pas pour ce qui est servi depuis le cache. LSCache répond aux requêtes de pages mises en cache sans solliciter PHP ni MySQL, et un cache d’objets Redis par site soulage les lectures pour les pages véritablement dynamiques. Ce qui reste est limité par les plafonds de processus LVE et de processus d’entrée de votre site ainsi que par la régulation de base de données par site de MySQL Governor, de sorte que la charge de base de données d’un site ne peut pas déborder sur le serveur. Les pages Cart, checkout, my-account et de session restent non mises en cache par défaut afin que le durcissement n’interrompe jamais une transaction.
Oui, au niveau de la couche réseau. La protection DDoS au niveau du fournisseur filtre les saturations L3/4 en amont de notre parc, quel que soit le protocole, et pour les exigences avancées ou d’entreprise, Cloudflare Magic Transit et Spectrum étendent l’atténuation de niveau edge au trafic non-HTTP.
Chaque transition d’application est consignée avec son motif, qu’elle soit automatique ou initiée par le personnel, ainsi que les preuves associées. Vous êtes informé de ce qui a changé et de ce qui permet de le résoudre, chaque action peut faire l’objet d’un recours, et les actions privilégiées sont consignées dans un journal d’audit pour votre propre suivi de conformité. Les signaux sont centralisés au sein d’un seul Abuse Desk plutôt que d’être dispersés entre plusieurs outils.
Oui. L’hébergement Footprint-Free commence par un essai de 14 jours sans carte bancaire couvrant jusqu’à 5 sites — sans coordonnées de paiement, sans engagement. Les forfaits sont assortis d’une garantie satisfait ou remboursé de 30 jours sans discussion, de migrations gratuites et sans verrouillage fournisseur.
Le filtrage réseau, l’absorption en périphérie, la régulation du serveur et le confinement par site fonctionnent dès le déploiement — rien à configurer, rien à activer en plein incident. Commencez par un essai de 14 jours sans carte bancaire, assorti d’une garantie satisfait ou remboursé de 30 jours et de migrations gratuites.
Commencer gratuitement