Comment utiliser le mode "Under Attack" de Cloudflare sur un site sous attaque DDoS ?

Le mode "Under Attack" de Cloudflare est un paramètre de défense d'urgence qui filtre le trafic bot en montrant aux visiteurs une brève vérification de sécurité sur un site sous une attaque DDoS. En sélectionnant votre site dans le tableau de bord de Cloudflare et en activant la fonction "Under Attack Mode" dans la section Sécurité, vous pouvez ralentir les requêtes HTTP/HTTPS massives en quelques minutes, protéger l'accès des vrais utilisateurs à votre site et réduire la charge sur votre serveur. Cependant, ce mode ne doit pas être considéré comme une solution permanente ; il doit être utilisé conjointement avec une configuration correcte de proxy DNS, des règles WAF, de la limitation de débit, des réglages de cache, et la sécurité du serveur d'origine.

Dans ce guide, nous expliquerons étape par étape comment activer le mode "Under Attack" de Cloudflare, quand il doit être utilisé, quelles configurations le soutiennent et comment revenir en toute sécurité à la normale une fois l'attaque terminée. L'objectif est de fournir une liste de contrôle réalisable en cas de panique et de rétablir l'accessibilité de votre site le plus rapidement possible.

Qu'est-ce que le mode "Under Attack" de Cloudflare ?

Le mode "Under Attack" de Cloudflare est un niveau de sécurité d'urgence proposé par Cloudflare. Lorsqu'il est activé, Cloudflare soumet les visiteurs du site à une brève vérification via leur navigateur. Cette vérification dure généralement quelques secondes et complique la tâche des bots automatiques, des simple outils de flood HTTP ou des clients malveillants hors navigateur qui tenteraient d'inonder le site.

Le but principal de ce mode est de mitiger les attaques au niveau de la couche applicative, c'est-à-dire au niveau Layer 7. Par exemple, si votre page d'accueil reçoit des milliers de requêtes GET par seconde, si des tentatives massives de POST ciblaient la page de connexion WordPress, ou si des requêtes coûteuses étaient envoyées à votre page de recherche ou à la page de panier, le mode "Under Attack" fournit une réponse rapide initiale.

Il est important de comprendre ceci : bien que le mode "Under Attack" filtre les requêtes web, si l'adresse IP de votre serveur est directement ciblée, si vos services en dehors de Cloudflare sont exposés, ou si l'attaque est menée au niveau Layer 3/4, des mesures supplémentaires s'imposent. Il est donc crucial que les enregistrements DNS soient configurés pour passer par Cloudflare, que l'adresse IP d'origine soit masquée, et que des mesures de sécurité adéquates soient mises en place côté hébergement. Vous pouvez consulter Services d'hébergement web sécurisé et installation du certificat SSL pour des conseils supplémentaires.

Signes d'une attaque DDoS : Que vérifier avant d'activer le mode "Under Attack" ?

Toute lenteur n'est pas forcément due à une attaque DDoS. Parfois, un plugin défaillant, un blocage de base de données, un travail cron utilisant beaucoup de CPU, ou un mauvais paramètre de cache peuvent également entraîner des résultats similaires. C'est pourquoi il est utile de faire un diagnostique rapide avant d'activer le mode "Under Attack". Cependant, si le serveur a des difficultés à répondre, si les utilisateurs reçoivent des erreurs 502, 503 ou 504, et s'il y a une explosion de requêtes inhabituelles dans les logs, il ne faut pas retarder l'activation du mode d'urgence.

Symptômes typiques d'une attaque DDoS

• Augmentation du trafic de 5, 10 ou 50 fois la normale en peu de temps.
• Des centaines de requêtes par seconde sur une seule page ou un seul point d'extrémité.
• Du trafic provenant de différents pays avec des valeurs de user-agent similaires.
• Ciblage d'URL coûteuses comme admin, login, search, cart dans WordPress, WooCommerce, OpenCart ou logiciels personnalisés.
• Épuisement des limites de CPU, RAM, PHP-FPM worker ou connexions MySQL sur le serveur.
• augmentation soudaine des erreurs 4xx et 5xx sur l'écran d'analyse de Cloudflare.
• Les véritables utilisateurs peuvent accéder sporadiquement au site, tandis que le trafic bot envoie des requêtes de manière continue.

Par exemple, si un site e-commerce qui reçoit normalement 2 000 requêtes par minute passe à 80 000 requêtes en 10 minutes, avec 70 % des demandes allant vers le panier ou la page de recherche, cela indique clairement une attaque Layer 7. Dans ce scénario, le mode "Under Attack" doit être activé dans les 5 premières minutes, et des règles WAF et de limitation de débit spéciales devraient être ajoutées pour les URL ciblées.

Quand utiliser le mode "Under Attack" de Cloudflare ?

Le mode "Under Attack" de Cloudflare n'est pas une configuration de sécurité standard qui doit rester activée en permanence. En effet, il montre également un court écran d'attente aux véritables visiteurs. Cela peut nuire à l'expérience utilisateur, surtout sur les pages à fort taux de conversion, dans les étapes de paiement, ou dans les systèmes utilisant des API. La meilleure utilisation consiste à l'activer temporairement pendant une attaque, puis à réajuster les niveaux de sécurité une fois que le trafic est revenu à la normale.

Situations appropriées pour son utilisation

• Si le site subit un volume anormal d'appels HTTP/HTTPS.
• Si les ressources du serveur s'épuisent rapidement et que les erreurs 502/503 augmentent.
• Si le WAF de Cloudflare n'est pas encore configuré avec des règles personnalisées et qu'une protection rapide est nécessaire.
• Si le trafic bot dépasse nettement le trafic des vrais utilisateurs.
• Si les pages web, les formulaires, les écrans de connexion ou les points d'extrémité de recherche sont ciblés.

Situations à utiliser avec prudence

• Si une application mobile, un fournisseur de paiement, un Webhook ou une API ont un trafic élevé.
• Si vous êtes dans une période où les bots de moteur de recherche scannent de manière critique.
• Si vos utilisateurs d'entreprise accèdent à partir d'anciens navigateurs ou dans des environnements réseau restreints.
• Si votre site comprend des sous-domaines qui ne sont pas derrière le proxy Cloudflare.

Pour les sites avec du trafic API, appliquer le mode "Under Attack" à l'ensemble du domaine peut entraîner des échecs d'intégration. Par conséquent, si possible, une règle WAF spéciale, une liste blanche ou un niveau de sécurité alternatif devrait être prévu pour les sous-domaines API. Pour un guide détaillé sur la sécurité API, Guide de sécurité API et limitation de débit peut être recommandé.

Comment activer le mode "Under Attack" de Cloudflare ? Un guide étape par étape

Les étapes suivantes constituent une liste de contrôle pratique conçue pour agir rapidement lors d'une attaque. L'interface de Cloudflare peut présenter des changements au fil du temps ; cependant, le principe reste le même : sélectionner votre domaine, élever le niveau de sécurité et valider le trafic entrant via Cloudflare.

1. Connectez-vous à votre compte Cloudflare

Tout d'abord, connectez-vous à votre compte Cloudflare et sélectionnez le nom de domaine soumis à l'attaque. Si vous gérez plusieurs noms de domaine, assurez-vous de travailler sur le bon zone. Activer le mode "Under Attack" sur le mauvais domaine entraînerait une perte de temps et laisserait l'attaque se poursuivre.

2. Vérifiez que les enregistrements DNS sont configurés en mode proxied

Pour que le mode "Under Attack" soit efficace, le trafic web doit passer par Cloudflare. Dans la section DNS, vérifiez que les enregistrements A, AAAA et CNAME affichent un nuage orange, indiquant leur état de proxied. Les enregistrements DNS en mode nuage gris (DNS only) ne passeront pas par les couches de sécurité de Cloudflare. Les enregistrements pour www, le domaine racine et les sous-domaines utilisés doivent être vérifiés.

Si votre adresse IP d'origine est visible sur Internet, les attaquants pourraient contourner Cloudflare et cibler directement votre serveur. Par conséquent, une bonne pratique est de restreindre dans votre pare-feu de serveur l'accès HTTP/HTTPS aux plages d'IP de Cloudflare uniquement. Vous pouvez obtenir de l'aide de votre fournisseur d'hébergement à ce sujet ou vous orienter vers Comment configurer les paramètres DNS de Cloudflare.

3. Activez la fonction "Under Attack Mode" dans la section Sécurité

Après avoir ouvert le domaine concerné dans le tableau de bord Cloudflare, trouvez l'option "Under Attack Mode" dans l'écran Sécurité ou Aperçu. Lorsque vous activez cette option, Cloudflare commence à afficher une page de vérification courte pour les visiteurs du site. Dans certains tableaux de bord, ce paramètre est également visible sous Niveau de Sécurité avec l'intitulé "I am Under Attack".

Une fois activé, le changement prend généralement effet rapidement. Dans les premières minutes, il est important de surveiller ensemble les analyses Cloudflare, les événements de sécurité et la consommation des ressources du serveur. Si l'utilisation de CPU et le nombre de connexions commencent à diminuer, cela signifie que le mode fonctionne. Cependant, si le taux d'erreur persiste, des règles supplémentaires doivent être créées.

4. Testez l'expérience utilisateur réelle

Après avoir activé le mode, testez le site à partir de différents réseaux. Vérifiez la page d'accueil, la page produit, la page de connexion et le processus de paiement, si possible depuis l'accès mobile, le réseau de bureau et une localisation différente. Si vous parvenez à accéder au site après l'écran de validation utilisateur, c'est le comportement attendu. Si les utilisateurs se retrouvent dans une boucle de validation infinie, examinez les réglages bloquant les cookies, la compatibilité du navigateur ou les conflits avec les règles de sécurité Cloudflare.

5. Identifiez les URLs ciblées par l'attaque

Le mode "Under Attack" fournit une protection globale ; cependant, l'efficacité réelle est atteinte avec des règles spécifiques au cible. Utilisez Cloudflare Security Events, Web Analytics, les logs d'accès à l'hébergement et les logs d'application pour déterminer les chemins les plus sollicités. Par exemple, les URLs comme /wp-login.php, /xmlrpc.php, /search, /cart, /api/login ou /checkout pourraient être sous attaque.

Une fois l'URL ciblée identifiée, vous pouvez prendre des mesures via WAF Custom Rules en fonction de critères comme le pays, le user-agent, la méthode de requête, le chemin URI ou le score des bots. Par exemple, pour un point de connexion de connexion spécifique, vous pourriez appliquer un challenge géré aux IP envoyant un nombre de requêtes dépassant une limite raisonnable par minute. Pour les sites WordPress, le lien Mesures de sécurité WordPress représente une opportunité naturelle d'interconnexion.

Différences entre le mode "Under Attack" et d'autres options de sécurité Cloudflare

Les outils de sécurité de Cloudflare servent à des fins variées. Le mode "Under Attack" est un filtre d'urgence rapide et général ; tandis que le WAF et la limitation de débit offrent des solutions plus ciblées, durables et équilibrées en termes d'expérience utilisateur.

En pratique, une bonne approche de défense se déroule comme suit : d'abord, le mode "Under Attack" est activé pour réduire la pression d'urgence, ensuite le motif d'attaque est analysé, des règles WAF et de limitation de débit sont ajoutées, et enfin, des optimisations de cache et des réglages de pare-feu d'origine sont appliqués pour renforcer la structure de manière permanente.

Ajustements Cloudflare recomandés pendant une attaque

Bien que le mode "Under Attack" puisse être activé d'un simple clic, le succès de la défense DDoS dépend des réglages de soutien. Les recommandations suivantes représentent les applications les plus efficaces lors de véritables opérations.

Créez une protection ciblée avec les règles WAF

Le WAF de Cloudflare vous permet d'agir selon certaines conditions. Par exemple, vous pouvez appliquer un challenge aux requêtes POST provenant uniquement de certains pays sur la page /wp-login.php. Cela vous permet d'isoler l'objectif de l'attaque sans alourdir l'ensemble du site.

• Ouvrir les pages admin et de connexion uniquement à certains pays ou plages d'IP.
• Bloquer les points d'extrémité inutilisés comme XML-RPC.
• Appliquer un challenge géré sur des valeurs de user-agent suspectes.
• Limiter le débit des clients effectuant des requêtes très fréquentes sur un chemin URI spécifique avec limitation de débit.

Ajustez le niveau de cache correctement

Si le serveur d'origine doit répondre à chaque requête pendant une attaque DDoS, les ressources s'épuiseront rapidement. Les fichiers statiques, images, CSS, JavaScript et les pages pouvant être mises en cache doivent donc être servies via Cloudflare. Pour des plateformes dynamiques comme WordPress, un plugin de cache de page, les règles de cache de Cloudflare et des en-têtes cache-control appropriés peuvent être utilisés ensemble.

Par exemple, sur un site d'actualités ou de blogs, les pages montrées aux visiteurs anonymes peuvent être mises en cache de 5 à 30 minutes. Ce simple réglage réduit également les valeurs TTFB même pendant les périodes sans attaque et soulage les ressources d'hébergement. Du côté performance, le lien Guide d'accélération de site Web pourrait être pris en compte.

Fixez des seuils de limitation de débit réalistes

La limitation de débit est particulièrement efficace sur des points d'extrémité coûteux. Cependant, si les seuils sont fixés de manière aléatoire, des utilisateurs réels peuvent être bloqués. Par exemple, sur une page de recherche de produits, un utilisateur normal pourrait faire entre 5 et 15 recherches par minute ; 100 recherches par minute sont anormales. Sur une page de connexion, 10 tentatives infructueuses en 5 minutes sont suspectes dans de nombreux scénarios.

Une approche exemple : pour /wp-login.php, appliquez un challenge géré aux IP envoyant plus de 10 requêtes par minute, et appliquez un blocage temporaire aux IP envoyant plus de 50 requêtes en 5 minutes. Pour les points d'extrémité API, des limites plus précises basées sur l'ID de session utilisateur, l'IP, le token et la méthode doivent être envisagées.

Masquez l'adresse IP d'origine et limitez le pare-feu

Une des erreurs les plus critiques lorsqu'on utilise Cloudflare est de laisser l'adresse IP d'origine exposée. Les anciens enregistrements DNS, les sous-domaines qui fonctionnent directement avec l'IP, ou les services web confus avec des enregistrements de mail, peuvent permettre à un attaquant d'accéder à votre serveur en dehors de Cloudflare.

Du côté serveur, ouvrir les ports 80 et 443 uniquement aux plages d'IP de Cloudflare offre une protection solide. De plus, les ports SSH, de panneau, de base de données et d'administration ne doivent pas être laissés ouverts à Internet ; l'utilisation de restrictions d'IP, de mots de passe forts, de 2FA et, si possible, de VPN est recommandée. Pour la sécurité de l'hébergement, vous pouvez faire référence à Paramètres de sécurité cPanel et configuration du pare-feu VPS.

Points de vigilance spécifiques pour WordPress, WooCommerce et les sites d'entreprise

Tous les sites web n'ont pas la même structure de trafic. Un site de blog, un magasin WooCommerce et un panel SaaS peuvent donner des résultats différents avec le mode "Under Attack" de Cloudflare. Il est donc important de déterminer les chemins critiques en fonction du type de site.

Sites WordPress

Les fichiers les plus souvent ciblés dans WordPress sont les chemins /wp-login.php et /xmlrpc.php. Si vous n'utilisez pas XML-RPC, il est généralement sûr de le bloquer. Des restrictions de pays ou d'IP peuvent être appliquées pour le panneau admin. De plus, les règles de sécurité ne doivent pas entrer en conflit avec les plugins Cloudflare ; trop de mécanismes de challenge simultanés peuvent faire entrer l'utilisateur dans une boucle de validation.

Magasins WooCommerce

Dans WooCommerce, les pages de panier, de paiement et de compte nécessitent une attention particulière. Ces pages étant dynamiques, un cache agressif ne doit pas être appliqué. Lorsque le mode "Under Attack" est actif, assurez-vous que les URL de callback ou webhook du fournisseur de paiement fonctionnent correctement. Si nécessaire, les plages d'IP du fournisseur de paiement doivent être ajoutées à la liste blanche ou une règle spéciale pour le point d'extrémité concerné doit être établie.

Sites d'entreprise et utilisant des API

Les portails d'entreprise, les intégrations CRM et les API d'applications mobiles peuvent ne pas être en mesure de traiter l'écran de challenge JavaScript. Dans de tels cas, il peut être plus approprié de gérer séparément le sous-domaine API au lieu d'appliquer le mode "Under Attack" à l'ensemble du domaine. Par exemple, alors que le mode "Under Attack" est activé pour www.example.com, une sécurité basée sur un token, une limitation de débit et une liste blanche peuvent être appliquées pour api.example.com.

Métriques à suivre après l'activation du mode "Under Attack"

Pour déterminer si une mesure de sécurité fonctionne, un suivi numérique est nécessaire. Ce n'est pas suffisant de simplement que le site soit accessible ; les taux d'erreur, la charge du serveur et le comportement réel des utilisateurs doivent être évalués ensemble.

• Cloudflare Security Events : montre combien de requêtes ont été challengées ou bloquées par quelles règles.
• Codes d'état HTTP : surveillez les changements dans les erreurs 403, 429, 502, 503 et 504.
• Utilisation du CPU et de la RAM sur le serveur : une baisse est attendue après le mode "Under Attack".
• Connexions PHP-FPM et MySQL : montrent le soulagement au niveau de la couche applicative.
• Bande passante et nombre de requêtes : comparer le volume de trafic avec le taux de requêtes filtrées.
• Conversions réelles des utilisateurs : testez les soumissions de formulaires, les commandes, les connexions et les étapes de paiement.

Par exemple, si le nombre total de requêtes reste le même après l'activation du mode "Under Attack", mais que les requêtes atteignant l'origine diminuent de 60 %, cela signifie que la couche Cloudflare absorbe une charge importante. Toutefois, si l'utilisation de CPU MySQL reste élevée, l'attaque peut activer une requête dynamique spécifique ; dans ce cas, les logs de l'application doivent être examinés.

Comment désactiver le mode "Under Attack" après l'attaque ?

Une fois le trafic de l'attaque revenu à la normale, il n'est généralement pas recommandé de garder le mode "Under Attack" activé en permanence pour la plupart des sites. En effet, montrer une validation supplémentaire à chaque visiteur peut affecter le taux de conversion, l'efficacité de l'analyse et la satisfaction des utilisateurs. La désactivation doit être réalisée de manière contrôlée.

Étapes pour un retour sûr à la normale

• Attendez que les niveaux de trafic se normalisent pendant au moins 30 à 60 minutes.
• Vérifiez sur l'écran Cloudflare Security Events que les chiffres de challenges et de blocage ont diminué.
• Avant de désactiver le mode "Under Attack", assurez-vous que les règles WAF ciblées et de limitation de débit sont actives.
• Adaptez le niveau de sécurité à un niveau plus équilibré comme High ou Medium.
• Testez le site à partir de différents appareils et surveillez le taux d'erreur 5xx.
• Suivez les logs pendant 24 heures pour vérifier si l'attaque reprend.

Comme bonne pratique, un rapport d'incidents post-attaque devrait être créé. Ce rapport devrait contenir l'heure de début de l'attaque, les URLs ciblées, le nombre de requêtes le plus élevé, les actions prises, les règles efficaces et les améliorations durables. Ce document peut considérablement réduire le temps de réponse lors de la prochaine intervention.

Erreurs courantes et ce qu'il faut éviter

Il est crucial de prendre des décisions rapides lors d'une attaque DDoS ; cependant, des réglages incorrects peuvent également bloquer des utilisateurs réels. Les erreurs suivantes sont souvent observées sous forte pression.

• Penser que le mode "Under Attack" protégera sans configurer les enregistrements DNS en mode proxied.
• Laisser l'adresse IP d'origine exposée sans restreindre l'accès aux IP de Cloudflare via le pare-feu.
• Appliquer le challenge à l'ensemble du domaine sans tester les adresses API, webhook et callback de paiement.
• Écrire des règles de blocage WAF trop larges qui bloquent de vrais clients.
• Appliquer agressivement le cache à des pages comme le panier, le paiement ou le panneau utilisateur qui ne doivent pas être mises en cache.
• Maintenir le mode activé pendant des semaines après la fin d'une attaque.
• Prendre des décisions uniquement en se basant sur l'écran de Cloudflare sans examiner les logs du serveur.

En particulier, pour les sites e-commerce, le blocage des callbacks de paiement peut entraîner une perte de revenus significative. C'est pourquoi, lors de la rédaction des règles de sécurité, il est plus sûr de tester d'abord avec une action log ou un challenge géré, plutôt qu'un blocage. Une fois que l'effet de la règle a été observé, des actions plus strictes peuvent être mises en œuvre.

Comment planifier une défense plus robuste sur l'infrastructure d'Hostragons ?

Cloudflare offre une puissante couche de protection, cependant, une défense efficace contre les DDoS ne s'arrête pas au CDN. L'infrastructure d'hébergement, l'optimisation des logiciels, la configuration SSL, la gestion DNS et la stratégie de sauvegarde doivent être considérées ensemble. Pour un site hébergé sur Hostragons, l'approche de base devrait être : Cloudflare filtre le trafic, la couche d'hébergement ne gère que le trafic nettoyé, et l'application est optimisée pour ne pas générer une charge de base de données inutile.

Avant de lancer un nouveau projet, il est crucial que le nom de domaine soit géré avec les bons enregistrements DNS, que le certificat SSL soit installé sans souci, et que les ressources du serveur web soient choisies en fonction de votre profil de trafic. Aux points mentionnés, Vérification de domaine et enregistrement de nom de domaine, Paquets d'hébergement Web, solutions d'hébergement professionnel et Certificat SSL gratuit peuvent aider l'utilisateur.

Pour des projets à fort trafic ou à haut risque d'attaque, il peut être plus judicieux de considérer des options de VPS ou de serveur géré, plutôt que l'hébergement partagé standard. Cela permet de configurer le pare-feu, le serveur web, PHP-FPM, Redis, l'objet de cache et les réglages de base de données de manière plus flexible. Quel que soit le choix d'infrastructure, le mode "Under Attack" de Cloudflare doit être positionné uniquement comme un outil d'urgence ; l'architecture de sécurité permanente doit être soutenue par le WAF, l'analyse des logs et des mises à jour régulières.

Liste de contrôle rapide : Les 15 premières minutes pendant une DDoS

Le timing est critique lors d'une attaque. La liste suivante résume ce que l'équipe technique ou le propriétaire du site peuvent faire dans les 15 premières minutes.

• Accédez au tableau de bord de Cloudflare et sélectionnez le bon nom de domaine.
• Vérifiez que les enregistrements DNS sont en mode proxied (nuage orange).
• Activez le mode "Under Attack".
• Testez la page d'accueil, connexion, panier, paiement et les points d'extrémité API.
• Déterminez les URLs ciblées à partir de l'écran Cloudflare Security Events.
• Ajoutez des règles WAF ou de limitation de débit spécifiques pour les chemins soumis à l'attaque.
• Vérifiez l'état du CPU, RAM, PHP-FPM et MySQL sur votre serveur.
• Testez l'accès direct à l'adresse IP d'origine.
• Examinez si des listes blanches sont nécessaires pour les fournisseurs de paiement, les webhooks et les intégrations critiques.
• Notez toutes les actions chronologiquement.

Si cette liste est régulièrement pratiquée, la panique est réduite en cas d'attaque réelle et la qualité de l'intervention est améliorée. Sur de grands sites, il est recommandé de documenter ce processus sous la forme d'un plan d'intervention d'incident.

Questions Fréquemment Posées

Le mode "Under Attack" de Cloudflare protège-t-il complètement le site ?

Non. Le mode "Under Attack" de Cloudflare est efficace pour réduire principalement le trafic bot et le flood au niveau HTTP/HTTPS ; mais il ne fournit pas une protection complète à lui seul. Les enregistrements DNS doivent être configurés en mode proxied, l'IP d'origine doit être masquée, et il doit être utilisé en complément avec des règles WAF, limitation de débit, cache et réglages du pare-feu du serveur.

Le mode "Under Attack" nuit-il au SEO ?

Une utilisation à court terme n’entraîne généralement pas de dommages importants pour le SEO. Cependant, si le mode reste activé longtemps, cela peut affecter l'efficacité du crawl par les moteurs de recherche et l'expérience utilisateur. Par conséquent, il est préférable de désactiver le mode après une attaque et de continuer avec des règles de sécurité ciblées.

Combien de temps le mode "Under Attack" doit-il rester activé ?

Il peut rester activé tant que l'intensité de l'attaque demeure élevée ; en pratique, il est conseillé de surveiller pendant au moins 30 à 60 minutes après que le trafic soit redevenu normal, puis de le désactiver progressivement. Avant de le désactiver, il est essentiel que des règles permanentes comme le WAF et la limitation de débit soient prêtes.

Le mode "Under Attack" peut-il affecter les API ou les systèmes de paiement ?

Oui, cela peut affecter ces systèmes. En effet, certains clients API, services Webhook et systèmes de callback de paiement peuvent ne pas pouvoir accomplir la vérification de sécurité basée sur un navigateur. Il est donc crucial de tester les points d'extrémité critiques et, si nécessaire, d'appliquer des listes blanches ou des règles Cloudflare personnalisées.

Est-ce qu'il est nécessaire de prendre des mesures supplémentaires du côté hébergement lors de l'utilisation de Cloudflare ?

Oui. Cloudflare fournit une protection forte au niveau de la couche frontale, mais l'adresse IP du serveur d'origine doit être masquée, le pare-feu doit autoriser uniquement le trafic nécessaire, le logiciel doit être maintenu à jour et la configuration du cache doit être correctement réalisée. Une infrastructure d'hébergement sécurisée fait partie intégrante de la résistance DDoS.

Conclusion

Le mode "Under Attack" de Cloudflare est un outil d'urgence efficace qui fournit un soulagement rapide aux sites sous attaque DDoS. Lorsqu'il est activé avec des réglages de proxy DNS appropriés, il réduit le trafic bot, diminue la charge sur le serveur et augmente la probabilité que les vrais utilisateurs puissent accéder au site. Pour un meilleur résultat, ce mode doit être soutenu par des règles WAF, la limitation de débit, l'optimisation du cache, et la sécurité du pare-feu d'origine.

Si vous souhaitez que votre site soit plus résistant aux attaques, passez régulièrement en revue votre infrastructure, votre gestion DNS et votre configuration SSL. En examinant les solutions d'hébergement, de domaine et de SSL d'Hostragons, vous pouvez poser une base plus sécurisée et durable pour votre site.