Protection DDoS
Les crues sont absorbées en périphérie, les attaques au niveau réseau sont filtrées en amont, et tout ce qui atteint le serveur est confiné dans l'enveloppe isolée au niveau du noyau du site cible. Plusieurs couches, chacune remplissant une fonction spécifique, de sorte qu'une attaque visant un site ne provoque pas de panne pour les sites voisins. C'est le modèle de défense que nous avons conçu pour une plateforme hébergeant plus de 650 000 sites dans le monde, et la configuration de base s'applique à tous les abonnements. Disponibilité : la limitation du débit des bases de données par site est en cours de développement actif et n'est pas encore disponible. Tout le reste est d'ores et déjà opérationnel.
Une inondation volumétrique, une inondation d'application L7 et une attaque lente par épuisement des connexions sont trois problèmes différents. Nous traitons chacun d'eux là où c'est le moins cher et le plus rapide de le faire — en amont de la flotte, à la périphérie et à l'intérieur de la cage.
La protection DDoS au niveau du fournisseur filtre les attaques par inondation de la couche réseau en amont de notre parc de serveurs, avant même que ce trafic ne consomme un port, une carte réseau ou un cycle CPU sur la machine qui héberge 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 edge managé se place en amont de chaque site. Il absorbe les attaques HTTP volumétriques par inondation, exécute un WAF de niveau 7, applique une limitation du taux de requêtes par site, et utilise la gestion des robots ainsi que des défis managés pour séparer les visiteurs légitimes du trafic automatisé — le tout avant qu'une requête n'atteigne l'origine.
LiteSpeed Enterprise applique une limitation des connexions et des requêtes avec des seuils de connexion par IP, Imunify360 exécute un pare-feu réseau doté d'une protection contre les attaques par force brute et d'un filtrage de la réputation des IP, et les limites de processus d'entrée CloudLinux LVE restreignent le nombre de requêtes simultanées qu'un même site peut maintenir ouvertes.
LVE limite le CPU, la RAM, les E/S, les IOPS, les processus et les processus d'entrée pour chaque site individuellement. Un trafic anormal qui parvient à traverser les couches supérieures est bridé au sein de la propre cage du site cible, de sorte que la pression générée reste cantonnée à ce site au lieu de se propager sur l'ensemble du serveur.
La plupart des pannes d'hébergement lors d'une attaque ne sont pas causées par l'atteinte de la cible, mais par la consommation des ressources de cette dernière qui prive tout le reste sur le serveur. C'est le mode de défaillance que cette architecture est conçue pour éliminer.
La requête la moins coûteuse à traiter est celle qui ne touche jamais à PHP ou MySQL. Notre cache à deux couches garantit qu'une grande partie d'un pic de trafic au niveau applicatif est répondue par des octets statiques plutôt que par le travail de votre serveur d'origine.
La mitigation n'est pas un ticket de support. Les signaux alimentent un moteur de règles qui associe chacun d'eux à une action d'application, une notification client et — lorsque c'est possible — une correction automatique, chaque transition étant enregistrée.
Lorsqu'un signal DDoS est déclenché, le moteur de règles applique la mitigation Cloudflare ainsi qu'une limitation du taux par site, et peut ajuster dynamiquement les limites LVE de ce site. Lorsque le signal disparaît, les limites se relâchent à nouveau. Gradué, réversible et consigné à chaque étape.
Si une attaque menace l'origine, le site passe en état « restreint » — les limites LVE et de débit sont resserrées, tout en restant en ligne et actif. Le mode restreint se rétablit automatiquement une fois la pression retombée ; il ne s'agit pas d'une suspension.
Sous le moteur de politiques, LVE régule nativement et automatiquement l'utilisation du processeur, des E/S et des processus par site. C'est la première ligne de défense toujours active, qui fonctionne que le trafic ait été ou non classé comme une attaque.
Chaque transition d'application des règles consigne son motif, qu'elle soit automatique ou initiée par le personnel, ainsi que les preuves associées. Vous êtes informé des modifications apportées et de la manière d'y remédier, et chaque action peut faire l'objet d'un appel.
La protection de base n'est pas facultative, car un site attaqué ou compromis menace ses voisins, la réputation de notre serveur et nos plages d'adresses IP. Une protection renforcée existe pour les sites dont le profil de risque l'exige.
Une hausse de trafic est souvent un symptôme. Le même pipeline de signaux qui absorbe les flux traite également les compromissions qui les provoquent, ce qui permet de qualifier correctement un incident plutôt que de simplement l'absorber.
L'objectif de conception est le cloisonnement. Chaque site s'exécute dans sa propre cage CloudLinux LVE avec des limites de CPU, RAM, IO, IOPS, processus et processus d'entrée, sa propre vue de système de fichiers CageFS, et une limitation des bases de données par site via MySQL Governor. Un site attaqué est bridé à son propre plafond au lieu 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 base est incluse dans chaque formule : isolation LVE et CageFS, limitation des connexions et des requêtes LiteSpeed, pare-feu réseau, WAF proactif et analyse des logiciels malveillants, avec l'absorption en périphérie par Cloudflare et le filtrage réseau au niveau du fournisseur en amont de l'infrastructure. Nous l'incluons parce que nous ne pouvons pas rendre la protection de notre propre infrastructure optionnelle. La gestion avancée des bots, les niveaux DDoS supérieurs, les règles WAF amélioré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 entraîne une atténuation par Cloudflare ainsi qu'une limitation du taux par site, et — uniquement si l'attaque menace l'origine — l'état « throttled » : des limites LVE plus strictes tout en maintenant le site en ligne et actif. L'état Throttled se rétablit automatiquement une fois la pression retombée. La suspension est réservée au non-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 plutôt qu'une page d'erreur.
Rien de tout cela ne s'applique aux éléments servis par le cache. LSCache répond aux requêtes de pages mises en cache sans appeler PHP ni MySQL, et un cache d'objets Redis par site délège les lectures pour les pages véritablement dynamiques. Ce qui reste est limité par les plafonds de processus LVE et 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 pression sur la base de données provenant d'un site ne peut pas se propager au serveur. Les pages de panier, de paiement, de mon compte et de session restent non mises en cache par défaut afin que le renforcement de la sécurité ne perturbe jamais une transaction.
Oui, au niveau de la couche réseau. La protection anti-DDoS au niveau du fournisseur filtre les attaques volumétriques L3/4 en amont de notre infrastructure, quel que soit le protocole, et pour les besoins avancés ou d'entreprise, Cloudflare Magic Transit et Spectrum étendent une atténuation de niveau Edge au trafic non HTTP.
Chaque transition d'application est enregistrée avec son motif, qu'elle soit automatique ou initiée par le personnel, ainsi que les preuves associées. Vous êtes informé des modifications et des mesures correctives, chaque action peut faire l'objet d'un appel, et les actions privilégiées sont consignées dans un journal d'audit pour assurer votre propre conformité. Les signaux sont regroupés au sein d'un Bureau des abus unique plutôt 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 informations de paiement ni engagement. Les abonnements bénéficient d'une garantie de remboursement sans discussion de 30 jours, de migrations gratuites et d'aucune dépendance vis-à-vis d'un fournisseur.
Le filtrage réseau, l'absorption en périphérie, la limitation du débit des serveurs et le confinement par site s'exécutent dès le moment du déploiement : rien à configurer, rien à activer en plein incident. Commencez par un essai de 14 jours sans carte bancaire, garanti satisfait ou remboursé pendant 30 jours et avec migrations gratuites.
Commencer gratuitement