Laissez passer les bots CoreDash sur votre CDN ou pare-feu

Laissez passer les deux bots CoreDash sur votre CDN ou pare-feu

Deux bots CoreDash visitent votre site : l'audit cRUM et le test d'uptime. Pour tirer le meilleur parti de CoreDash, le CDN ou le pare-feu doit laisser passer les deux. Parfois, un paramètre les bloque. Cette page vous montre comment régler le problème dans Cloudflare et AWS WAF, avec une seule règle qui couvre les deux bots.

Ce que font ces deux bots :

• L'audit cRUM. Lorsque vous choisissez une page sous cRUM (beta) dans le menu CoreDash, CoreDash ouvre cette page dans Chrome sur son serveur d'audit, comme le ferait un visiteur, et vous montre ce qui la ralentit. Son user agent est CoreDash/1.0 (audit; +https://www.coredash.app/bot).
• Le test d'uptime. Toutes les 30 minutes, CoreDash interroge chaque site surveillé depuis ses propres serveurs et vous alerte si l'un d'eux tombe. Il envoie CoreDash/1.0 (uptime; +https://www.coredash.app/bot).

Le user agent est le nom qu'un navigateur ou un bot transmet à chaque requête pour s'identifier. Ceux de CoreDash commencent tous deux par CoreDash/, et c'est ce que votre règle va cibler.

À quoi ressemble un audit ou un test d'uptime bloqué

Le pare-feu ou le CDN voit arriver un visiteur issu d'un centre de données dont le user agent n'est pas celui d'un navigateur. Il le prend pour un bot suspect et répond par un code d'erreur ou une page de challenge. Chaque bot le manifeste à sa façon.

Un audit cRUM bloqué s'arrête avec le message « Audit failed » et une erreur en dessous. Ou alors il s'exécute quand même, mais sur la page de blocage : le filmstrip Page load affiche alors une page de challenge ou d'erreur à la place de la vôtre, et tous les chiffres de l'audit se rapportent à cette page.

Le moniteur d'uptime indique « Blocked », et sa notification « A firewall blocks the checker » précise le code d'état reçu par les vérifications et depuis quand. CoreDash exclut les vérifications bloquées de votre temps d'indisponibilité : le blocage ne fait donc pas baisser votre uptime. En revanche, tant que chaque vérification est bloquée, aucune n'atteint le site, et le moniteur ne peut pas vous alerter si le site tombe.

La page du moniteur pour example-shop.com quand Cloudflare répond à chaque test d'uptime par un code 403.

Comment votre pare-feu identifie CoreDash

Pour autoriser CoreDash, vous créez une exception dans votre pare-feu ou CDN. La plupart des utilisateurs la basent sur le user agent : une seule règle sur CoreDash/ laisse passer l'audit et le test d'uptime. Le bot token de votre projet permet de durcir la règle, car seuls les bots de votre propre projet l'envoient. Quant aux adresses IP de CoreDash, réservez-les aux cas où rien d'autre ne passe. Elles changent dès que CoreDash ajoute ou déplace un serveur ; vous devez donc maintenir vous-même cette règle à jour.

Pour savoir quel paramètre nécessite une exception, consultez les journaux de votre pare-feu. La section suivante traite des logs Cloudflare. Pour AWS WAF, rendez-vous plus bas, à la section « Autoriser CoreDash dans AWS WAF, au-dessus de Bot Control ».

Identifier ce qui a bloqué CoreDash dans Cloudflare

Ouvrez votre domaine dans Cloudflare et allez dans Security › Analytics, onglet Events. Sous Sampled logs, repérez une requête avec un user agent CoreDash. Sur un site à fort trafic, cliquez sur Filter, choisissez User agent comme champ et collez le user agent complet comme valeur : CoreDash/1.0 (uptime; +https://www.coredash.app/bot) pour le test d'uptime ou CoreDash/1.0 (audit; +https://www.coredash.app/bot) pour l'audit.

Cliquez sur la requête pour l'ouvrir. Sa ligne Service indique la fonctionnalité Cloudflare qui l'a bloquée.

Browser Integrity Check a bloqué ce test d'uptime sur example-shop.com.

Cette ligne Service détermine la marche à suivre :

• Bot fight mode : c'est la protection contre les bots du forfait Cloudflare Free, et vos règles ne peuvent pas créer d'exception pour elle. Passez directement à la section sur Bot Fight Mode plus bas.
• Tout le reste, comme Browser integrity check sur la capture d'écran, une règle managée ou Super Bot Fight Mode : créez la règle Skip ci-dessous.

Laisser passer CoreDash dans Cloudflare avec une règle Skip

Une règle Skip indique à Cloudflare d'ignorer les fonctionnalités de votre choix pour chaque requête dotée d'un user agent CoreDash. Elle couvre à la fois l'audit et le test d'uptime, et vous pouvez en créer une sur n'importe quel forfait Cloudflare.

1. Allez dans Security › Security rules. Sous Custom rules, cliquez sur Create rule.

La page Security rules pour example-shop.com, avant la première règle personnalisée.

2. Nommez la règle CoreDash. Sous « When incoming requests match », cliquez sur « Edit expression » et collez cette ligne dans le champ texte qui s'ouvre.

   http.user_agent contains "CoreDash/"

Nom de la règle et expression, après le clic sur « Edit expression ». Le slash après CoreDash en fait bien partie.

3. Sous « Then take action », choisissez Skip, puis sélectionnez ce que Cloudflare doit ignorer pour CoreDash. Dans « WAF components to skip », cochez « All managed rules » et « All Super Bot Fight Mode Rules ». Cliquez sur « More components to skip » pour l'ouvrir, et cochez également « Browser Integrity Check ». Laissez « Log matching requests » activé pour vérifier plus tard dans Events que la règle fonctionne bien.

L'action Skip, avec les trois cases cochées.

4. Cliquez sur Deploy. Si votre domaine possède déjà d'autres règles personnalisées, Cloudflare demande où placer celle-ci : mettez-la en première position.

Sans autres règles personnalisées, il n'y a rien à ordonner : Deploy est le dernier clic.

5. Vérifiez que CoreDash passe bien. Dès l'arrivée du prochain audit ou test d'uptime, Events dans Cloudflare le liste avec l'action Skip. Dans CoreDash, vérifiez le bot que vous utilisez, ou les deux.

Pour l'audit cRUM, sélectionnez à nouveau la page sous cRUM (beta), ou rechargez l'onglet du navigateur dans lequel elle est ouverte : un nouvel audit démarre. Une fois qu'il passe, le filmstrip Page load affiche le chargement de votre propre page dans Chrome, image par image.

Un audit terminé, avec le TTFB, le FCP, le LCP et le CLS indiqués sur les images.

Le test d'uptime ne nécessite aucun clic : CoreDash vérifie à l'heure pile et à la demi-heure. En moins de 30 minutes, le moniteur repasse à Up et les nouvelles barres deviennent vertes.

example-shop.com est de nouveau Up : 38 tests ont reçu une erreur 403, et chaque test depuis la règle a reçu un code 200.

Une règle Cloudflare plus sûre avec le bot token CoreDash

N'importe qui peut envoyer un user agent commençant par CoreDash/ : un bot malveillant se faisant passer pour CoreDash passerait donc aussi à travers la règle Skip. Le bot token de votre projet est un secret : chaque audit et test d'uptime le transmet dans un en-tête nommé X-CoreDash-Bot. Une règle basée sur ce token ne laisse passer que les bots de votre propre projet.

Pour le récupérer, ouvrez Project settings dans CoreDash et allez sur l'onglet « CoreDash bot token ». Seul le propriétaire du projet peut y accéder. Tant qu'un moniteur indique Blocked, le lien « View your CoreDash bot token » dans sa notification vous y conduit également. Cliquez sur « Copy Cloudflare rule » : vous obtenez l'expression complète contenant votre token.

« Copy Cloudflare rule » place l'expression avec votre token dans le presse-papiers.

Si vous avez déjà créé la règle Skip, allez dans Security › Security rules et ouvrez la règle CoreDash. Dans son expression, remplacez la ligne du user agent par ce que vous avez copié, puis enregistrez la règle. L'action et les cases cochées restent inchangées. Si vous n'avez pas encore de règle, suivez les étapes de la règle Skip ci-dessus et collez la ligne du token à l'étape 2.

Le token est uniquement envoyé au site de votre projet et à ses sous-domaines. Le monitoring ou l'audit d'une page située sur un autre domaine ne transmet aucun token : ce domaine conserve donc la règle sur le user agent. Et si votre token se retrouve exposé, cliquez sur « Make a new token ». L'ancien token cesse aussitôt de fonctionner ; insérez donc le nouveau dans votre règle Cloudflare dans la foulée.

Bot Fight Mode sur le forfait Cloudflare Free

Cette section vous concerne si la ligne Service dans Events indiquait Bot fight mode.

Un test d'uptime CoreDash avec l'action Managed Challenge et le Service Bot fight mode.

Bot Fight Mode soumet à un challenge les bots basiques hébergés sur des serveurs cloud. Pour Cloudflare, les deux bots CoreDash entrent dans cette catégorie. La documentation de Cloudflare précise que les règles Skip et Allow n'ont aucun effet sur lui. Vous devez donc soit le désactiver, soit le garder activé et autoriser les adresses IP de CoreDash.

Désactiver Bot Fight Mode

Allez dans Security › Settings et filtrez sur Bot traffic. Repérez la ligne « Bot fight mode » et désactivez son interrupteur. Cloudflare cessera alors de bloquer ces bots basiques sur l'ensemble de votre site. Si vous préférez conserver ce type de protection, le forfait Pro propose Super Bot Fight Mode, qui lui prend bien en compte la règle Skip. Une fois l'interrupteur désactivé, créez également la règle Skip ci-dessus pour éviter que Browser Integrity Check ou une règle managée ne bloque CoreDash ensuite.

L'interrupteur de Bot fight mode se trouve dans la colonne Status. Sur cette capture, il est déjà désactivé.

Garder Bot Fight Mode activé et autoriser les adresses IP de CoreDash

Avant de commencer : ces adresses ne sont pas figées. Vos règles IP access rules restent exactement telles que vous les avez saisies, alors que la liste à jour est toujours disponible sur app.coredash.app/bot/ips.json. Si CoreDash se retrouve à nouveau bloqué un jour, comparez d'abord vos règles à cette liste.

Une règle IP access rule laisse passer une adresse IP à travers vos règles de pare-feu, et Bot Fight Mode ignore une requête si une telle règle a matché en premier. Rendez-vous dans Security › Security rules et cliquez sur Create rule sous IP access rules. Si Cloudflare propose de la créer sous forme de custom rule, choisissez « No, go to IP access rules ». Entrez 51.195.222.219, choisissez Allow et « This website », puis cliquez sur Create. Créez une règle par adresse : 51.195.222.219 et 51.195.222.220 pour le test d'uptime, 135.125.202.210 pour l'audit cRUM.

Une règle IP access rule par adresse CoreDash, configurée sur Allow pour « This website ».

Après l'un ou l'autre correctif, vérifiez que CoreDash passe bien, comme à l'étape 5 de la règle Skip.

Autoriser CoreDash dans AWS WAF, au-dessus de Bot Control

Dans AWS WAF, ce qui bloque CoreDash se trouve généralement dans Bot Control, le groupe de règles gérées proposé par AWS contre les bots. Pour régler le problème, créez une règle Allow pour le user agent CoreDash placée au-dessus de Bot Control. Cette seule règle laisse passer l'audit et le test d'uptime. Les captures d'écran AWS ci-dessous proviennent d'une configuration de démonstration pour acme-aws.com, créée pour cette page.

1. Dans la console AWS WAF, ouvrez la web ACL de votre site (l'ensemble de règles qui le protège) et allez sur l'onglet Sampled requests. Cliquez sur l'URI d'une requête pour voir ses en-têtes : celles de CoreDash ont un user agent commençant par CoreDash/. La colonne « Rule inside rule group » indique la règle qui les a bloquées.

La règle SignalNonBrowserUserAgent de Bot Control bloque les tests d'uptime CoreDash sur acme-aws.com.

2. Sur la web ACL, cliquez sur Add rules › « Add my own rules and rule groups » pour ouvrir le Rule builder (appelé Custom rule dans la nouvelle console AWS). Remplissez le formulaire comme sur la capture d'écran : une règle standard nommée CoreDash qui examine l'en-tête user-agent et autorise chaque requête où celui-ci commence par CoreDash/. Faites ensuite défiler la page sous le formulaire et cliquez sur « Add rule ».

La règle CoreDash : Single header user-agent, Starts with string CoreDash/, action Allow.

3. AWS ouvre alors « Set rule priority ». Sélectionnez CoreDash, cliquez sur « Move up » jusqu'à ce qu'elle soit tout en haut, puis cliquez sur Save. AWS évalue les règles de haut en bas ; une requête correspondant à une règle Allow s'arrête là, et Bot Control ne voit donc jamais passer les requêtes CoreDash.

CoreDash tout en haut, au-dessus du groupe de règles Bot Control.

4. Vérifiez que CoreDash passe bien. Dans Sampled requests, les requêtes CoreDash les plus récentes affichent désormais votre règle CoreDash avec l'action Allow.

Les tests CoreDash les plus récents sur acme-aws.com correspondent à la règle CoreDash et passent.

Dans CoreDash, vérifiez le bot que vous utilisez, comme à l'étape 5 de la règle Skip de Cloudflare : un nouvel audit affiche votre propre page dans le filmstrip Page load, et le moniteur repasse à Up après le test d'uptime suivant.

Comme sur Cloudflare, le bot token de votre projet rend cette règle plus sûre. Les raisons et les sites concernés sont détaillés dans la section sur le token Cloudflare plus haut. Pour basculer la règle AWS sur le token :

1. Dans CoreDash, ouvrez Project settings, allez sur l'onglet « CoreDash bot token » et cliquez sur « Copy token ».
2. Dans AWS WAF, rouvrez la règle CoreDash sur votre web ACL. C'est le formulaire de la capture du Rule builder ci-dessus.
3. Remplacez le nom du champ d'en-tête user-agent par x-coredash-bot. AWS lit les en-têtes sans tenir compte de la casse ; cela correspond donc bien à l'en-tête X-CoreDash-Bot.
4. Réglez le match type sur « Exactly matches string », collez votre token comme chaîne à faire correspondre, puis enregistrez la règle.

Le test de l'origin tombe en timeout derrière votre CDN

Cette section concerne uniquement le test d'uptime, et seulement si vous avez renseigné Origin IP sous Advanced lors de la création du moniteur. CoreDash teste alors aussi votre serveur directement, en contournant le CDN. Certains serveurs n'acceptent que les requêtes provenant des adresses du CDN. Le moniteur passe alors à Down avec « The origin check fails: Connect timeout », alors que les visiteurs reçoivent toujours les pages servies par le CDN.

Le CDN sert toujours les pages en cache, et le test sur le serveur lui-même tombe en timeout.

Une règle sur le user agent ou le token ne servira à rien ici : un tel serveur rejette le test en raison de sa provenance, avant même de lire le moindre en-tête. Il doit donc identifier CoreDash via ses adresses IP. Autorisez les deux adresses d'uptime, 51.195.222.219 et 51.195.222.220, dans le pare-feu de votre serveur, ou demandez à votre hébergeur de le faire. Si le test de l'origin se remet à tomber en timeout par la suite, consultez d'abord la liste à jour : les adresses ont pu changer.

CoreDash est toujours bloqué

Si le moniteur affiche toujours Blocked ou si l'audit échoue encore, rouvrez les logs et cliquez sur la requête CoreDash la plus récente : Events dans Cloudflare, Sampled requests dans AWS. L'élément mentionné est celui qui bloque CoreDash en ce moment. Voici les causes classiques :

• Une fonctionnalité différente de la précédente, comme Browser integrity check après avoir désactivé Bot Fight Mode. Créez également la règle Skip.
• La règle n'est pas active, ou dans AWS elle ne figure pas tout en haut. Dans Cloudflare, la règle CoreDash doit afficher Active sous Custom rules. AWS exige qu'elle soit en tête de « Set rule priority ».
• La règle est rédigée différemment des étapes. Cloudflare a besoin de contains et de CoreDash/ avec le slash ; AWS nécessite l'en-tête user-agent et « Starts with string ».
• L'une de vos propres règles Cloudflare, par exemple une règle bloquant certains pays. La règle Skip laisse vos règles personnalisées actives : modifiez cette règle pour en exclure CoreDash. Events indique de quel pays provient la requête.
• Le mode Under Attack. Il soumet chaque visiteur à un challenge, CoreDash inclus, tant que vous ne le désactivez pas.
• Une requête qui est bien passée, ou aucune requête CoreDash. Un autre pare-feu est alors placé en amont ou en aval de Cloudflare ou d'AWS, comme le pare-feu de votre hébergeur ou une règle sur votre serveur. Autorisez également le user agent CoreDash/ à cet endroit.

Toujours bloqué ? Contactez CoreDash avec l'URL du moniteur ou de la page auditée, et l'heure à laquelle le blocage s'est produit.

Pour savoir ce qu'envoient les deux bots et pourquoi, consultez la page dédiée au bot CoreDash. En savoir plus sur les moniteurs : monitoring d'uptime, et pour les scripts l'API Uptime.