Un site WordPress hébergé sur une machine virtuelle Azure subissait depuis plusieurs semaines des milliers de tentatives de connexion automatisées. Une question se posait : le site avait-il été compromis ? DevThis a mené un audit méthodique pour y répondre, corrigé les points d’entrée relevés, puis mis en place la surveillance qui permet désormais de le savoir chaque jour.
L’organisation accompagnée n’est pas identifiée ici.
Contexte
Le site repose sur une infrastructure Azure décrite par du code avec Terraform : réseau virtuel, machine virtuelle, base de données MySQL managée, cache Redis et règles de sécurité réseau. La machine elle-même est configurée par Ansible, ce qui permet de la reconstruire à l’identique.
L’analyse des journaux a montré environ 66 700 tentatives de connexion par un point d’accès ancien de WordPress en deux semaines, ainsi que plusieurs milliers d’essais sur la page de connexion. Or ce type d’attaque ne laisse aucune trace exploitable en cas de réussite : le serveur répond de la même façon qu’elle échoue ou qu’elle aboutisse.
L’audit de compromission
Faute de pouvoir prouver directement qu’aucune tentative n’avait réussi, l’audit a vérifié tout ce qu’un intrus aurait vraisemblablement laissé derrière lui. Les relevés ont été faits en lecture seule, avant toute correction.
- Système : connexions à distance acceptées et refusées, comptes disposant d’un accès au serveur, clés autorisées, droits d’administration, tâches planifiées, ports ouverts et connexions sortantes.
- Intégrité de WordPress : comparaison du cœur et des extensions avec les sommes de contrôle officielles publiées par wordpress.org, et comparaison du thème avec sa version de référence.
- Recherche de code malveillant : fichiers PHP inattendus dans les dossiers de médias et motifs de code dissimulé dans le thème et les extensions.
- Comptes et sessions : liste et ancienneté des administrateurs, sessions ouvertes, accès par mots de passe d’application et inscriptions publiques.
- Activité récente : derniers contenus modifiés et tâches planifiées de WordPress, chacune rattachée à une extension connue.
- Lecture critique des indices : un indicateur qui semblait exploitable, la taille des réponses du serveur, a été testé puis écarté parce qu’il ne permettait de conclure ni dans un sens ni dans l’autre.
Conclusion : aucune trace de compromission. L’audit a toutefois mis au jour des points d’entrée inutiles, et surtout l’absence de tout moyen de détecter une intrusion si elle se produisait.
Corrections apportées
- Fermeture du point d’accès visé : l’ancienne interface de WordPress, utilisée par aucun service légitime, a été bloquée.
- Fin du listage de répertoires : le serveur web n’affiche plus le contenu des dossiers techniques que des robots parcouraient.
- Bannissement automatique : la protection contre les attaques automatisées a été complétée pour reconnaître ce type d’attaque et bloquer ses auteurs au niveau du pare-feu.
- Vérification depuis l’extérieur : chaque correction a été contrôlée en conditions réelles, en s’assurant que les pages du site, la connexion et les tâches planifiées continuaient de fonctionner.
Détection d’intrusion en trois couches
Pour ne plus avoir à se reposer la question, la surveillance a été répartie entre trois outils complémentaires. Chacun voit ce que les autres ne peuvent pas voir.
- Intégrité du système (AIDE) : empreinte des fichiers système, des programmes et des accès, comparée chaque jour à une référence. Toute modification inattendue est signalée.
- Traçabilité des actions sensibles (auditd) : journalisation de l’identité réelle de la personne qui modifie les accès, les comptes ou la configuration de WordPress, même après un changement d’utilisateur.
- Intégrité de WordPress : contrôle quotidien du cœur et des extensions par rapport aux versions officielles, du thème par rapport à sa version de référence, et des comptes administrateurs par rapport à une liste connue.
- Disponibilité du site : vérification toutes les cinq minutes que la page d’accueil répond correctement et complètement, avec une alerte dès le deuxième échec puis un message de rétablissement.
- Alertes utiles : un message n’est envoyé qu’en cas d’écart. Quand tout est conforme, rien ne vient noyer les vraies alertes.
- Référence protégée : la référence d’intégrité n’est jamais mise à jour automatiquement. Seule une personne qui vient d’intervenir et sait pourquoi le système a changé peut la valider, après avoir vu l’écart.
- Chemins d’échec testés : chaque alerte a été déclenchée volontairement (fichier suspect, administrateur ajouté, site indisponible) pour vérifier qu’elle arrive bien.
Résultat
L’organisation sait que son site n’a pas été compromis et sur quelles vérifications repose cette conclusion. Les points d’entrée inutiles sont fermés et les attaques automatisées sont bloquées à la source.
Surtout, la question ne se pose plus à l’aveugle : une modification inattendue du système, de WordPress ou des comptes administrateurs est signalée le lendemain matin, et une indisponibilité du site en quelques minutes. Auparavant, une interruption de plus d’une journée était passée inaperçue.
Ce type d’audit et de surveillance fait partie des interventions DevThis pour faire le point sur vos outils et fiabiliser leur exploitation.