Combien d’écritures disque un simple pingback peut-il générer, à lui seul, sur un site que plus personne ne surveille activement ? C’est la question posée après un diagnostic de charge disque qui s’annonçait, au départ, comme un problème réseau classique.
Ce billet détaille l’analyse d’I/O disque menée sur un site vieux de plusieurs années, resté actif sur un hébergement mutualisé sans qu’aucune évolution de contenu n’y ait été apportée depuis longtemps. Il ne traite pas de la désactivation du service XML-RPC lui-même, déjà couverte ailleurs sous l’angle du filtrage réseau ; il s’agit ici de comprendre pourquoi le disque, et non le réseau, était le premier facteur limitant sur ce cas précis.
Le protocole XML-RPC et le mécanisme de pingback
Le fichier xmlrpc.php, présent par défaut sur toute installation WordPress, expose une méthode pingback.ping permettant à un site tiers de notifier qu’il a créé un lien vers un article du site cible. WordPress vérifie alors, via une requête sortante, la présence effective de ce lien dans le contenu source déclaré, avant d’enregistrer le pingback comme commentaire en attente de modération.
Ce mécanisme, conçu à une époque où les blogs se citaient fréquemment entre eux, est aujourd’hui presque exclusivement utilisé à des fins malveillantes : sondage de vulnérabilités, tentatives de déni de service distribué en utilisant le site comme relais (le pingback servant alors de prétexte à une requête sortante vers une cible tierce), ou simple bruit de fond automatisé généré par des robots qui balaient le web à la recherche d’installations WordPress non protégées.
1 200 tentatives en une journée, un volume réseau presque anecdotique
Sur le site analysé, les journaux d’accès ont montré 1 200 requêtes vers xmlrpc.php en une seule journée, un volume qui, en bande passante brute, ne représentait qu’une fraction négligeable du trafic global du serveur mutualisé. Le diagnostic initial, focalisé sur la consommation réseau, n’avait donc rien détecté d’anormal à ce niveau.
C’est en croisant ces journaux avec l’activité disque du serveur, mesurée via iostat, que le lien est apparu. Chaque tentative de pingback traitée par WordPress, même rejetée, déclenche une écriture dans le journal d’erreurs PHP lorsque la méthode échoue de façon inattendue, une écriture dans le journal d’accès nginx, et dans plusieurs cas une tentative d’insertion en base de données avant rejet par les vérifications internes de WordPress. Sur un site à faible trafic par ailleurs, ce volume d’écritures devenait la première source réelle de sollicitation du disque.
Pourquoi un vieux site concentre ce trafic
Le site en question avait été indexé par de nombreux robots au fil de ses années d’existence, y compris des robots malveillants qui conservent en mémoire d’anciennes listes d’URL à tester. Un site jeune, peu référencé, reçoit statistiquement moins de ce type de sollicitation automatisée qu’un site ancien resté visible dans des index obsolètes depuis longtemps.
- L’ancienneté d’un nom de domaine et son historique d’indexation influencent directement le volume de trafic automatisé malveillant reçu, indépendamment de son trafic légitime réel.
- Un site à faible trafic humain rend ce bruit de fond automatisé proportionnellement plus visible dans les journaux, alors qu’il serait noyé dans le volume sur un site à fort trafic.
- L’écriture disque générée par ce trafic ne dépend pas du succès ou de l’échec du pingback : la tentative elle-même suffit à déclencher les écritures de journalisation.
Ce que révèle ce type de diagnostic à l’échelle d’un parc
Sur un parc mutualisé de plusieurs centaines de sites, ce phénomène reste généralement dilué et invisible. Il devient significatif précisément sur les sites les plus anciens et les moins actifs, ceux dont personne ne surveille plus l’activité au quotidien mais qui continuent de recevoir un trafic automatisé résiduel, parfois plus important en volume d’écritures que le trafic humain réel du site.
Un site inactif n’est jamais un site silencieux du point de vue du serveur ; il continue de solliciter des ressources précises, souvent différentes de celles d’un site actif.
Notion à retenir pour un diagnostic futur
Ce cas illustre un principe plus général de diagnostic serveur : une charge peut être disproportionnée entre plusieurs ressources. Un volume réseau négligeable ne garantit en rien un volume d’I/O disque tout aussi négligeable, dès lors que chaque requête, même minime en octets transférés, déclenche plusieurs écritures de journalisation ou de base de données en arrière-plan.
En résumé
L’analyse de charge disque de ce vieux site a montré qu’un trafic réseau anecdotique peut masquer une sollicitation disque bien plus significative, quand chaque requête déclenche plusieurs écritures de journalisation indépendantes de son volume en octets. Le protocole XML-RPC et son mécanisme de pingback en offrent un exemple concret : le coût réel ne se mesure pas en bande passante consommée, mais en nombre d’opérations d’écriture générées côté serveur.
