Vous ouvrez le site web et il se charge. Le moniteur indique qu’il est hors service, et la raison qu’il a enregistrée est HTTP 403. Les deux sont vrais. Le site fonctionne pour vous, et il refuse le moniteur.

Un 403, c’est le serveur qui dit qu’il a compris la requête et qu’il ne la traitera pas. Contrairement à un 503 ou à un délai d’attente dépassé, ce n’est pas le signe que le site peine. Quelque chose a décidé que cette requête ne devait pas passer.

Pourquoi un moniteur est bloqué

Un moniteur est un robot. Il demande une page à intervalles réguliers, depuis des serveurs qui ne sont pas dans le pays du visiteur, sans navigateur derrière. De nombreuses protections sont conçues pour arrêter exactement ce type de trafic :

Ce qui bloque Comment cela se manifeste
Une protection contre les robots ou un défi géré sur un CDN ou un service de pare-feu (Cloudflare en est l’exemple courant) Un défi ou une page « vérification de votre navigateur » à la place de votre page ; une réponse 403
Une règle sur le pays ou le réseau Bloque les requêtes venant de centres de données ou de certains pays
Une limite de débit Commence à refuser après un certain nombre de requêtes depuis une même adresse
Un module de sécurité sur le serveur web ou le panneau d’hébergement Bloque les requêtes qui semblent automatiques, ou l’absence d’identification de navigateur
Une liste de blocage d’adresses, par exemple tenue par un outil de prévention d’intrusion Bloque l’adresse du moniteur après son signalement
L’authentification Un 401 ou un 403 sur une page qui demande une connexion. Le moniteur ne se connecte pas

Aucun de ces cas ne signifie que votre site est cassé. Ils signifient que la protection fonctionne un peu trop bien pour un moniteur légitime.

Confirmer la cause

Ne modifiez pas les règles du pare-feu au hasard. Regardez d’abord.

1. Lire ce que le moniteur a reçu

Si votre moniteur affiche la réponse, regardez le corps. Une page qui parle de contrôle de sécurité, de défi ou de requête bloquée pointe vers un pare-feu. Un simple « Forbidden » du serveur web pointe vers une règle du serveur. Une page de connexion pointe vers l’authentification.

2. Comparer depuis votre propre terminal

curl -sS -o /dev/null -D - https://example.com/

Si cela renvoie aussi un 403 alors que votre navigateur fonctionne, le blocage dépend de l’apparence de la requête, pas de l’endroit où vous êtes. Envoyez alors une requête qui ressemble à celle d’un navigateur :

curl -sS -o /dev/null -D - -A "Mozilla/5.0" https://example.com/

Si la seconde passe et pas la première, une règle examine l’identification envoyée par le client. Regardez aussi les en-têtes de la réponse. Un en-tête ou un cookie qui nomme un CDN ou un service de pare-feu vous indique quelle couche répond.

3. Lire le journal du pare-feu lui-même

C’est l’étape la plus fiable. Ces services conservent un journal des requêtes bloquées et soumises à un défi, avec la règle déclenchée. Repérez l’heure des vérifications échouées du moniteur et regardez quelle règle a correspondu. Le nom de la règle vous dit quoi modifier.

4. Tester dans l’autre sens

Autorisez le moniteur avec une règle étroite (voir ci-dessous), relancez la vérification et regardez si elle passe. Si oui, le blocage venait du pare-feu. Si elle échoue encore, regardez la couche suivante : les règles du serveur lui-même, puis l’application.

Corriger sans affaiblir le site

Le but est de laisser passer un visiteur connu, pas de désactiver la protection.

  • Autorisez les adresses du moniteur. La plupart des services de surveillance publient les adresses d’où partent leurs vérifications. Ajoutez-les à une règle d’autorisation, ou demandez au pare-feu d’ignorer la protection qui bloque le moniteur, pour ces adresses seulement. Si votre service ne publie pas de liste, demandez à son support. UptimeWire publie sa liste et les étapes pour les services courants : voir Comment laisser passer les vérifications UptimeWire à travers votre pare-feu.
  • Ne vous fiez pas à la seule chaîne d’identification. Une règle qui autorise tout ce qui se dit moniteur peut être utilisée par n’importe qui. Une règle sur la plage d’adresses est bien plus difficile à falsifier.
  • Restreignez le périmètre. Autorisez le moniteur à atteindre une seule adresse publique, comme la page d’accueil ou une page de santé, pas tout le site.
  • Utilisez une adresse de santé dédiée. Une petite page publique qui répond 200 et ne contient aucune donnée privée est ce qu’il y a de plus simple à autoriser et de moins coûteux à vérifier.
  • Surveillez les limites de débit. Si vous vérifiez souvent depuis plusieurs emplacements, les requêtes cumulées peuvent déclencher une limite de débit. Autorisez-y aussi les adresses du moniteur.
  • Notez la modification. Une règle d’autorisation dont personne ne se souvient est difficile à auditer plus tard.

Warning

Ne désactivez pas la protection contre les robots ou le pare-feu pour tout le site afin de faire passer un moniteur. Le risque est plus grand qu’un moniteur qui signale un 403.

Quand le 403 est réel

Parfois, le moniteur a raison. Un déploiement qui a changé des permissions de fichiers, un module de sécurité qui a été activé ou une adresse bloquée volontairement produisent un 403 que les visiteurs voient aussi. Si vos propres vérifications depuis un terminal et depuis un autre réseau échouent aussi, traitez-le comme un vrai problème et examinez les règles et les permissions sur le serveur.

Ce qu’un moniteur peut et ne peut pas faire ici

UptimeWire demande une adresse publique depuis l’extérieur et lit la réponse. Une réponse finale de 200 à 399 compte comme correcte. Tout le reste compte comme un échec, y compris 401 et 403. Une vérification échouée est répétée, et un incident s’ouvre après trois vérifications échouées de suite. La raison est enregistrée, vous pouvez donc voir « HTTP 403 » et le moment où cela a commencé.

Il ne se connecte pas, ne répond pas à un défi et ne contourne pas un pare-feu. Surveiller une page derrière une connexion demande une autre approche, ou une adresse de santé publique qui la remplace.

Liste de contrôle

  • La page s’ouvre-t-elle dans un navigateur et avec curl ?
  • Que dit le corps de la réponse : un défi, un simple Forbidden ou une connexion ?
  • Quelle règle s’est déclenchée, d’après le journal du pare-feu ?
  • Les adresses du moniteur sont-elles autorisées, et seulement pour l’adresse que vous surveillez ?
  • Avez-vous autorisé le moniteur sans désactiver la protection ?
  • Après la modification, le moniteur passe-t-il pendant une journée entière, heures de pointe comprises ?