← Retour au blog Disponibilité, SSL et domaines

Monitoring d'uptime bloqué par un pare-feu : le repérer et le corriger

Monitoring d'uptime bloqué par un pare-feu : le repérer et le corriger

Quand un outil de monitoring d'uptime est bloqué par un pare-feu, le site fonctionne en général pour les visiteurs, mais la couche de sécurité placée devant a jugé que l'outil ressemblait à un bot et a refusé la requête. Cette couche peut être un WAF, la protection anti-bots de Cloudflare ou une extension de sécurité WordPress. L'outil reçoit un 403, une page de challenge ou parfois un 503 au lieu de la vraie page. La solution est une règle d'autorisation ciblée, pas la désactivation de la protection.

Pourquoi les outils de sécurité bloquent le monitoring

Un outil de monitoring se comporte exactement comme les bots qu'un pare-feu doit arrêter. Il demande la même URL à intervalles fixes, depuis des IP de data center, sans exécuter de JavaScript ni garder de cookies. Les sources habituelles du blocage :

Reconnaître un blocage par pare-feu

Le schéma est toujours le même : l'outil signale un échec alors que le site s'ouvre normalement dans votre navigateur. Regardez ensuite la réponse :

Lancer curl -I depuis un serveur en data center, plutôt que depuis votre portable, reproduit souvent le blocage. Le journal du pare-feu indique quelle règle s'est déclenchée : Security Events dans Cloudflare, Live Traffic dans Wordfence ou le journal du WAF chez l'hébergeur. C'est cette règle qu'il faut ajuster.

Pourquoi « bloqué » n'est pas « hors ligne »

Hors ligne veut dire que personne n'atteint le site et que le client perd des visites. Bloqué veut dire que l'outil ne voit pas le site, alors que les visiteurs, eux, peut-être. Confondre les deux pose problème dans les deux sens. Les fausses alertes nocturnes vous habituent à ignorer les alertes. Pire, tant que l'outil est bloqué, il ne peut pas vous prévenir d'une vraie panne.

La même règle trop large peut aussi arrêter les robots d'exploration. Les fonctions anti-bots de Cloudflare laissent en général passer les bots vérifiés des moteurs de recherche, mais un blocage par pays ou une règle stricte peut ne pas le faire. En cas de doute, regardez dans le rapport Statistiques sur l'exploration de la Search Console si les réponses 403 ou 5xx augmentent, et lancez un test en direct dans l'outil d'inspection d'URL. Notre article sur l'impact des pannes sur le SEO détaille ce que des erreurs répétées changent pour l'exploration.

Autoriser un outil de monitoring sans risque

Partez de la documentation du fournisseur. La plupart publient les IP ou le user-agent de leurs vérifications.

  1. Préférez les règles par IP aux règles par user-agent, que n'importe qui peut falsifier.
  2. Gardez la règle étroite. Dans Cloudflare, une règle personnalisée sur les IP de l'outil avec l'action Skip peut ignorer uniquement les composants qui le bloquent. Super Bot Fight Mode peut être ignoré ainsi, alors que Bot Fight Mode sur l'offre gratuite ne se contourne pas avec des règles personnalisées.
  3. Dans Wordfence, ajoutez les IP à la liste d'adresses autorisées des options du pare-feu, en sachant qu'elles contournent toutes les règles.
  4. Notez le changement dans la fiche du client, avec la date et la raison, pour que personne ne le supprime lors d'un futur nettoyage.

Si l'autorisation est impossible, surveiller une URL légère exclue de la protection anti-bots reste une option, en acceptant qu'elle en dise moins sur les pages importantes. Sous WordPress, le monitoring SEO pour WordPress couvre les autres façons dont les extensions modifient un site sans prévenir.

Ce qu'affiche Deltio en cas de blocage

Deltio vérifie chaque site en HTTP toutes les 10 minutes et lui attribue l'un de trois états : online, offline ou firewall blocked. Comme firewall blocked est distinct d'offline, vous savez qu'il faut regarder les réglages de sécurité plutôt qu'appeler l'hébergeur. Pour les IP ou le user-agent à autoriser, consultez la documentation de Deltio ou le support plutôt que de deviner. Deltio ne vous dit pas si Googlebot est bloqué : la Search Console reste l'outil pour cela.

Les offres démarrent à £24 par mois, avec un essai gratuit de 14 jours.

Questions fréquentes

Est-il sûr d'autoriser un service de monitoring dans son pare-feu ?
Oui, si la règle est étroite. N'autorisez que les IP publiées par le fournisseur, n'ignorez que les protections qui le bloquent et évitez une autorisation basée uniquement sur le user-agent, facile à falsifier. Revoyez la règle quand le fournisseur met à jour sa liste d'IP.
Le mode « I'm Under Attack » de Cloudflare bloque-t-il le monitoring d'uptime ?
Très probablement. Ce mode affiche un challenge à chaque visiteur, et les outils de monitoring ne résolvent pas les challenges, donc les vérifications échouent tant qu'il est actif. Excluez l'outil avec une règle ou attendez-vous à des résultats bloqués jusqu'à sa désactivation.
Pourquoi le site s'ouvre dans mon navigateur alors que l'outil reçoit un 403 ?
Votre navigateur exécute du JavaScript, garde des cookies et se connecte depuis un réseau domestique ou de bureau, donc la protection anti-bots lui fait confiance. Un outil de monitoring se connecte depuis un data center sans aucun de ces signaux. Un 403 pour l'outil et un 200 pour vous est le signe typique d'un blocage par pare-feu.
Un pare-feu peut-il aussi bloquer Googlebot ?
Oui, en général via un blocage par pays, une limitation de débit ou une règle personnalisée trop stricte. Le rapport Statistiques sur l'exploration et le test en direct de l'inspection d'URL dans la Search Console sont les moyens fiables de le vérifier, car ils montrent ce que Google a réellement reçu.
Pourquoi ne pas simplement désactiver l'extension de sécurité ?
Parce que désactiver la protection pour satisfaire un outil de monitoring remplace un problème de signalement par un problème de sécurité. Une règle d'autorisation ciblée garde la protection pour le trafic réel et laisse passer l'outil.