DevThis

Domaine d’intervention : Supervision

  • Un site WordPress a-t-il été piraté ? Audit de compromission et détection d’intrusion

    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.

  • Superviser les sauvegardes d’une infrastructure Proxmox : huit jours d’échec silencieux

    DevThis a mis en place et exploite une infrastructure virtualisée sous Proxmox, sauvegardée par Proxmox Backup Server. Au cours de cette exploitation, une revue a révélé que les sauvegardes d’un service échouaient depuis huit jours sans que rien ne le signale. Ce cas d’école illustre une réalité simple : une sauvegarde que personne ne vérifie ne protège de rien.

    L’organisation accompagnée n’est pas identifiée ici.

    Contexte

    L’infrastructure repose sur deux serveurs de virtualisation Proxmox qui hébergent des machines virtuelles et des conteneurs, et sur un serveur de sauvegarde dédié. Les sauvegardes sont automatiques, nocturnes et couvrent l’ensemble des services.

    Sur le papier, tout était en place : les tâches étaient planifiées, le serveur de sauvegarde fonctionnait et aucune erreur n’apparaissait au quotidien.

    Ce que la revue a révélé

    Une revue complète de l’infrastructure a mis au jour trois problèmes qu’aucun utilisateur n’avait remarqués :

    • Huit jours de sauvegardes en échec : un instantané resté bloqué sur un conteneur empêchait toute nouvelle sauvegarde de ce service. L’échec se répétait chaque nuit, sans alerte. En cas de panne, la dernière copie exploitable aurait eu plus d’une semaine.
    • Un serveur saturé : l’espace de stockage de l’un des deux serveurs était plein à 100 %, ce qui menaçait la stabilité de tous les services qu’il hébergeait.
    • Un service arrêté par une mise à jour : un script de mise à jour tiers avait interrompu un service, sans que l’arrêt soit signalé.

    Aucun de ces problèmes n’était visible tant que tout continuait à fonctionner. C’est précisément le risque : on découvre qu’une sauvegarde manque le jour où l’on en a besoin.

    Interventions réalisées

    • Remise en état : suppression de l’instantané bloquant et relance des sauvegardes du service concerné ; libération de l’espace du serveur saturé, ramené de 100 % à 29 % d’occupation ; redémarrage et contrôle du service arrêté.
    • Orchestration des sauvegardes : un seul processus pilote les sauvegardes des deux serveurs et rend compte de chaque exécution, réussie ou non.
    • Stockage protégé : sauvegardes stockées en miroir sur deux disques, dédupliquées et soumises à une politique de rétention quotidienne, hebdomadaire et mensuelle.
    • Serveur de sauvegarde isolé dans le temps : la machine n’est allumée que le temps des sauvegardes, puis s’éteint ; le reste du temps, elle est hors d’atteinte.
    • Vérifications régulières : contrôle hebdomadaire de l’intégrité des sauvegardes, vérification mensuelle des disques et surveillance de leur état de santé.
    • Restauration testée : une restauration complète a été réalisée et datée, pour s’assurer que les sauvegardes sont réellement exploitables.
    • Alertes : notifications envoyées sur une messagerie d’équipe en cas d’échec de sauvegarde ou d’anomalie sur les disques.
    • État des lieux daté : chaque affirmation sur l’état de l’infrastructure porte la date de sa dernière vérification ; ce qui n’a pas été revérifié est signalé comme tel.

    Résultat

    Les sauvegardes couvrent à nouveau l’ensemble des services, leur restauration a été éprouvée et tout échec est désormais signalé dès la nuit où il se produit, au lieu d’être découvert par hasard une semaine plus tard.

    La leçon vaut pour toute organisation : mettre en place des sauvegardes ne suffit pas. Il faut aussi les superviser, vérifier qu’elles aboutissent et tester régulièrement qu’on sait les restaurer.

    Ce type de vérification fait partie des interventions DevThis pour faire le point sur vos outils et fiabiliser leur exploitation.

Propulsé par