3 000 sites hébergés, une moyenne de quelques liens externes publiés par semaine sur chacun : ce calcul, fait un jour sur un parc mutualisé d’hébergement associatif, a suffi à expliquer un volume de trafic sortant qui semblait, pris site par site, totalement anodin. Le mécanisme en cause, hérité de l’époque des blogs et resté actif par défaut sur d’innombrables installations WordPress anciennes, s’appelle le pingback.
Le pingback est un protocole de notification automatique entre blogs, intégré à XML-RPC depuis les débuts de WordPress. Quand un article publié contient un lien vers un autre site qui accepte les pingbacks, WordPress tente automatiquement d’envoyer une requête sortante pour signaler cette mention. Sur un site isolé, ce mécanisme passe inaperçu. À l’échelle d’un parc entier, il devient une source de trafic sortant qu’il vaut la peine de comprendre.
Le mécanisme technique du pingback
Dès qu’un article est publié ou modifié, WordPress analyse son contenu à la recherche de liens externes. Pour chaque lien détecté, une tâche différée est planifiée pour vérifier si le site cible accepte les pingbacks, généralement en interrogeant un en-tête X-Pingback ou une balise de découverte présente dans le code source de la page ciblée. Si la cible répond positivement, une requête XML-RPC est envoyée pour notifier la mention.
Ce comportement passe par la méthode pingback.ping du point d’entrée xmlrpc.php, présent sur toute installation WordPress qui n’a pas explicitement désactivé cette fonctionnalité via le filtre xmlrpc_methods ou une extension dédiée. La tâche s’exécute de façon asynchrone via le mécanisme de cron interne à WordPress, ce qui signifie qu’elle se déclenche au prochain chargement de page plutôt qu’instantanément.
Le coût réseau à l’échelle d’un parc
Pris isolément, un pingback représente une requête HTTP sortante de quelques centaines de millisecondes, négligeable pour un site unique. Mais un hébergeur qui héberge plusieurs milliers de sites WordPress voit ce mécanisme se répéter en continu, à chaque publication d’article contenant un lien externe, sur l’ensemble du parc. Ce trafic sortant cumulé consomme des connexions réseau, des processus PHP-FPM et, dans certains cas, ralentit la publication même de l’article concerné le temps que la vérification de la cible réponde.
Ce coût devient plus visible encore quand la cible du lien met un temps anormalement long à répondre, ou ne répond jamais. Le processus PHP qui gère la publication de l’article peut alors rester bloqué en attente de cette réponse, ce qui explique certains cas de lenteur à la sauvegarde d’un article, sans lien apparent avec le contenu lui-même.
Un mécanisme aussi détourné pour amplifier des attaques
Au-delà du coût réseau ordinaire, le mécanisme de pingback a été documenté comme vecteur d’amplification pour des attaques par déni de service distribué. Un attaquant peut envoyer à un site WordPress une requête XML-RPC lui demandant de vérifier un pingback vers une cible tierce, ce qui pousse le site à envoyer lui-même une requête vers cette cible, sans que l’attaquant n’ait besoin d’exposer directement son adresse d’origine.
Sur un parc de sites anciens, où XML-RPC reste actif par héritage plutôt que par choix délibéré, ce détournement peut multiplier artificiellement le nombre de requêtes sortantes générées par le mécanisme, bien au-delà de ce que l’activité éditoriale normale du parc justifierait.
- Chaque lien externe publié peut déclencher une vérification de pingback
- La vérification passe par une requête XML-RPC asynchrone
- Une cible lente à répondre peut ralentir la publication de l’article
- Le mécanisme peut être détourné pour amplifier une attaque vers un tiers
Observer ce trafic sur un parc mutualisé
Repérer ce trafic passe par l’analyse des journaux réseau sortants du serveur, en filtrant les requêtes initiées par le processus PHP-FPM vers des domaines externes autour du point d’entrée xmlrpc.php. Un pic récurrent de requêtes sortantes, corrélé aux heures de publication d’articles sur le parc, confirme la présence massive de ce mécanisme.
Sur le parc associatif que nous avons audité, ce trafic sortant représentait, une fois isolé, une part surprenante des connexions sortantes totales du serveur, pour un mécanisme dont la majorité des propriétaires de sites ignoraient jusqu’à l’existence.
Ce que cette observation n’implique pas encore
Constater ce volume de trafic ne tranche pas, à lui seul, la question de désactiver XML-RPC sur l’ensemble du parc. Cette décision relève d’un arbitrage plus large, qui touche également à la sécurité du point d’entrée et à d’éventuelles applications tierces qui en dépendent encore, un sujet traité séparément et plus en détail du côté sécurité.
En résumé
Le mécanisme de pingback XML-RPC, hérité des débuts de WordPress et resté actif sur de nombreux sites anciens, génère un trafic sortant dont le coût individuel reste faible mais qui s’additionne significativement à l’échelle d’un parc de sites. Ce même mécanisme peut également être détourné pour amplifier une attaque contre un tiers, ce qui en fait un point d’observation à ne pas négliger pour un hébergeur qui gère plusieurs milliers d’installations.
