Votre site web s’ouvre dans le navigateur, mais UptimeWire indique qu’il est hors service, avec comme raison un code d’état 403, 429 ou une page de contrôle de sécurité. Dans la plupart des cas, le site va bien. Quelque chose placé devant lui, comme Cloudflare, une extension de sécurité ou le pare-feu de l’hébergeur, prend nos vérifications pour des robots indésirables et les refuse.

Ce n’est pas un défaut de la protection. Nos vérifications viennent de serveurs installés dans des centres de données, n’ont aucun navigateur derrière elles et arrivent à heures fixes : c’est exactement ce que la protection contre les robots est conçue pour arrêter. La solution consiste à indiquer à la protection que ces quelques adresses appartiennent à votre moniteur.

Les signes que la protection bloque nos vérifications

Ce que vous voyez dans UptimeWire Ce que cela signifie en général
Code d’état 403 alors que le site s’ouvre chez vous Un pare-feu ou une protection contre les robots refuse les robots
Une page « vérification de votre navigateur » ou « Just a moment », parfois avec le code d’état 503 Une page de défi. Nos vérifications n’exécutent pas de scripts et ne peuvent pas la franchir
Code d’état 429 Une limite de débit : trop de requêtes depuis une même adresse
Code d’état 401 La page demande un mot de passe. Nos vérifications ne se connectent pas
Les vérifications n’échouent que depuis certains emplacements Une règle bloque certains pays ou réseaux

Lorsqu’un test dans le formulaire du site web ou une vérification récente reçoit l’une de ces réponses, l’espace client affiche un lien : « Un problème ? Voici comment laisser passer nos vérifications ». Il ouvre une version courte de ce guide avec nos adresses actuelles.

Étape 1. Récupérez nos adresses

Nos vérifications partent d’une liste courte et fixe de serveurs. La liste actuelle, une adresse par ligne, se trouve toujours sur app.uptimewire.com/ips.txt. La même liste, avec l’emplacement de chaque adresse, se trouve sur app.uptimewire.com/ips.json, pour les scripts.

Quand nous ajoutons un emplacement de vérification, son adresse apparaît dans la liste le jour même. Si vous avez copié les adresses à la main, consultez de nouveau la liste lorsque les vérifications depuis un nouvel emplacement commencent à échouer.

Nos vérifications se présentent aussi sous le nom UptimeWireBot/1.0 (+https://uptimewire.com). Vous pouvez l’utiliser pour retrouver nos requêtes dans un journal. N’autorisez pas les requêtes sur ce seul nom : n’importe qui peut envoyer le même, et une règle d’autorisation fondée sur lui est une porte ouverte. Autorisez par adresse.

Warning

N’autorisez que nos adresses. Ne désactivez pas la protection contre les robots ou le pare-feu pour tout le site afin de faire passer le moniteur.

Étape 2. Autorisez les adresses

Trouvez ci-dessous la protection qu’utilise votre site. Les noms des menus changent de temps en temps : les vôtres peuvent donc être un peu différents de ceux indiqués ici.

Cloudflare, offre gratuite

Avec l’offre gratuite, Bot Fight Mode est la cause habituelle du blocage. D’après la documentation de Cloudflare, il ne peut pas être contourné par une règle personnalisée. Il ne se déclenche pas, en revanche, lorsqu’une règle d’accès IP correspond d’abord à la requête. Vous avez donc deux possibilités :

  1. Ajoutez une règle d’accès IP pour chaque adresse. Dans le tableau de bord Cloudflare, ouvrez votre site, allez dans Security rules, puis Create rule → IP access rules. Dans l’ancien tableau de bord, le même outil se trouve sous Security → WAF → Tools. Saisissez l’une de nos adresses, choisissez l’action Allow, appliquez-la à ce site web et ajoutez une note, par exemple « Vérifications UptimeWire ». Recommencez pour chaque adresse de la liste.
  2. Ou désactivez Bot Fight Mode. Allez dans Security → Settings, filtrez sur Bot traffic et désactivez Bot Fight Mode. Cela laisse aussi entrer d’autres robots, la première possibilité est donc préférable.

Une règle d’accès IP avec l’action Allow permet aussi à nos vérifications de passer vos règles personnalisées, vos règles de limitation de débit et vos règles gérées.

Cloudflare, offres Pro, Business et Enterprise

Les offres payantes utilisent Super Bot Fight Mode, et une règle personnalisée avec l’action Skip peut le contourner :

  1. Allez dans Security rules → Create rule → Custom rules.
  2. Donnez un nom à la règle, par exemple « Vérifications UptimeWire ».
  3. Dans les conditions, choisissez le champ IP Source Address, l’opérateur is in, et saisissez nos adresses.
  4. Choisissez l’action Skip. Cochez All remaining custom rules, All rate limiting rules, All managed rules et All Super Bot Fight Mode rules. Parmi les produits, cochez Browser Integrity Check et Security Level.
  5. Déployez la règle et placez-la en tête de la liste.

Si le site est en mode Under Attack, chaque visiteur reçoit un contrôle du navigateur que nos vérifications ne peuvent pas franchir. Autorisez nos adresses comme décrit ici et, si les vérifications échouent encore, ajoutez aussi des règles d’accès IP pour elles.

Extensions de sécurité WordPress

Ajoutez nos adresses à la liste d’autorisation de l’extension :

  • Wordfence : Wordfence → Firewall → All Firewall Options, puis le champ des adresses IP autorisées (allowlisted ; les anciennes versions disent whitelisted). Une adresse par ligne.
  • Solid Security : le réglage Authorized IPs dans les réglages généraux.
  • All-In-One Security : la liste d’autorisation dans les réglages du pare-feu.
  • Shield Security : IP Rules → créez une nouvelle règle IP → ajoutez-la à la liste de contournement (bypass).

Si votre site WordPress est aussi derrière Cloudflare, autorisez les adresses aux deux endroits.

Pare-feu des hébergeurs

Sur un hébergement mutualisé, vous ne pouvez généralement pas modifier le pare-feu vous-même. Envoyez la liste au support de l’hébergeur et demandez-lui d’autoriser ces adresses pour votre site. Si vous gérez le serveur, utilisez l’outil dont il dispose :

  • Imunify360 (cPanel, WHM, Plesk) : ouvrez le pare-feu Imunify360, ajoutez chaque adresse et choisissez la liste blanche.
  • CSF : ajoutez chaque adresse avec un commentaire, par exemple csf -a 203.0.113.10 UptimeWire.
  • fail2ban : ajoutez les adresses à ignoreip dans jail.local, séparées par des espaces, puis rechargez fail2ban.
  • ModSecurity : ajoutez, au-dessus des autres, une règle qui désactive le moteur de règles pour nos adresses, par exemple :
SecRule REMOTE_ADDR "@ipMatch 203.0.113.10,203.0.113.11" "id:1000100,phase:1,pass,nolog,ctl:ruleEngine=Off"

Remplacez les adresses d’exemple par celles de notre liste.

Sucuri, AWS WAF, Akamai et Imperva

  • Sucuri : dans le tableau de bord du pare-feu Sucuri, ouvrez votre site, puis Access Control, saisissez une adresse sous Allow IP Addresses et sélectionnez Allow.
  • AWS WAF : créez un IP set avec nos adresses, les IPv4 en /32 et les IPv6 en /128, et ajoutez une règle avec l’action Allow au-dessus de Bot Control et de vos limites de débit.
  • Akamai et Imperva : ajoutez les adresses à la liste d’autorisation de votre politique de sécurité ou de votre protection contre les robots. Si vous ne la gérez pas vous-même, envoyez la liste à la personne qui s’en occupe.

Pays et centres de données bloqués

Nos vérifications viennent de plusieurs pays. Si une règle bloque des pays, des continents ou des réseaux de centres de données, placez la règle d’autorisation de nos adresses au-dessus d’elle. Sinon, seuls certains emplacements passent, et les résultats semblent aléatoires.

Autres réponses qui ne sont pas un blocage

  • 429, trop de requêtes : autorisez aussi nos adresses dans la limite de débit, ou choisissez un intervalle plus long entre les vérifications.
  • 401, un mot de passe : nos vérifications ne se connectent pas. Surveillez plutôt une page publique, comme la page d’accueil ou une petite page de santé.
  • 503, une page de maintenance : le moniteur a raison, le site ne sert pas les visiteurs. Pour les travaux que vous prévoyez, indiquez des travaux planifiés pour le site web, afin qu’il n’envoie pas d’alertes.

Étape 3. Vérifiez que cela fonctionne

  1. Dans UptimeWire, ouvrez le site web, choisissez de le modifier et appuyez sur Tester l’adresse. Une réponse de 200 à 399 signifie que nos vérifications passent.
  2. Surveillez les dernières vérifications pendant quelques heures. Chaque emplacement doit afficher un code d’état de 200 à 399.
  3. Ouvrez le journal de la protection. Nos requêtes doivent maintenant y apparaître comme autorisées. Si elles sont encore bloquées, le journal indique la règle qui les a bloquées : autorisez aussi nos adresses dans cette règle.

Si le site vous refuse aussi, depuis un autre réseau ou un téléphone, le blocage est réel et les visiteurs le voient aussi. Le problème se trouve alors dans les règles ou dans les permissions de fichiers sur le serveur. Pour en savoir plus, lisez Pourquoi votre moniteur affiche 403 alors que le site fonctionne.

Liste de contrôle

  • La raison est-elle un 403, un 429, un 401 ou une page de défi, alors que le site s’ouvre chez vous ?
  • Avez-vous pris la liste actuelle sur app.uptimewire.com/ips.txt ?
  • Les adresses sont-elles autorisées à chaque niveau : Cloudflare, l’extension, le pare-feu de l’hébergeur ?
  • Avec l’offre gratuite de Cloudflare, avez-vous utilisé des règles d’accès IP plutôt qu’une règle personnalisée ?
  • Avez-vous autorisé par adresse, et non par le nom du robot, en laissant la protection active pour tous les autres ?
  • Le test dans le formulaire du site web répond-il maintenant de 200 à 399 ?