DevThis

Domaine d’intervention : Sécurisation

  • 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.

  • Conception d’une architecture réseau segmentée sur Omada

    DevThis a conçu, sécurisé et administre une architecture réseau segmentée sur l’écosystème TP-Link Omada : contrôleur centralisé, passerelle, switchs, bornes Wi-Fi et caméras de surveillance. Les équipements sont répartis dans des réseaux séparés selon leur niveau de confiance, avec des règles de filtrage entre zones et un accès à distance chiffré.

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

    Contexte

    Le réseau accueillait des usages très différents : postes de travail, appareils mobiles, caméras de surveillance, serveurs, sauvegardes et services en lien avec des machines hébergées à l’extérieur. Tant que tout partage le même réseau, la moindre faille sur un équipement secondaire ouvre un chemin vers les données les plus sensibles.

    Il fallait aussi pouvoir administrer l’ensemble à distance sans exposer d’interface sur Internet, et garder une configuration lisible, que l’on puisse vérifier et faire évoluer sans tout reprendre.

    Conception et sécurisation

    • Plan d’adressage et segmentation : découpage du réseau en plusieurs VLAN selon les usages et le niveau de confiance, avec un plan d’adressage pensé pour cohabiter avec les réseaux de virtualisation, de conteneurs et de VPN.
    • Isolement des services critiques : serveurs, sauvegardes et services sensibles regroupés dans une zone dédiée, injoignable depuis les autres segments sauf flux explicitement autorisés.
    • Cloisonnement des équipements connectés : caméras et appareils moins maîtrisés séparés des postes et des serveurs, sans accès au-delà de ce dont ils ont besoin.
    • Filtrage entre zones : règles ACL construites sur le principe du moindre privilège ; chaque flux autorisé correspond à un besoin identifié, le reste est refusé.
    • Traitement des services exposés : toute machine en relation avec un système accessible depuis Internet est considérée comme peu fiable et strictement limitée dans ce qu’elle peut atteindre.
    • Accès à distance maîtrisé : administration possible uniquement depuis le réseau local ou à travers un VPN chiffré ; aucune interface d’administration publiée sur Internet.
    • Contrôle de la frontière : tests documentés vérifiant que les zones sensibles restent effectivement inaccessibles, à rejouer après chaque modification.

    Administration du réseau

    • Gestion centralisée : passerelle, switchs, bornes Wi-Fi et caméras pilotés depuis le contrôleur Omada, pour une vue d’ensemble et une configuration cohérente.
    • Intégration des nouveaux équipements : chaque appareil ajouté est rattaché au contrôleur et placé dans la zone qui correspond à son usage.
    • Réseaux Wi-Fi : réseaux sans fil associés aux segments adaptés, pour que l’accès sans fil respecte le même cloisonnement que le filaire.
    • Maintien à jour : suivi et application des mises à jour des équipements, sauvegarde de la configuration du contrôleur.
    • Suivi et documentation : description des zones, des flux autorisés et des procédures d’accès, pour intervenir à partir d’un état connu.

    Résultat

    Le réseau est découpé en zones dont les échanges sont définis et contrôlés. Un équipement compromis reste cantonné à son segment, les services sensibles ne sont joignables que depuis les zones prévues, et l’administration à distance passe par un accès chiffré unique.

    La gestion centralisée dans Omada et la documentation associée permettent de faire évoluer l’architecture, par exemple pour accueillir un nouveau service ou de nouveaux équipements, sans remettre en cause l’ensemble.

    Ce type de conception fait partie des interventions DevThis pour faire évoluer et sécuriser l’environnement numérique d’une entreprise.

  • Conception et mise en production de Clarsend, un service d’analyse DMARC

    Clarsend est un service web conçu et exploité par DevThis, présenté sur clarsend.io. Il reçoit des rapports DMARC, les analyse et restitue par domaine les sources d’envoi observées ainsi que leur état d’authentification. Ce projet interne a réuni la conception de l’application, sa mise en production et l’organisation de son exploitation.

    Contexte

    Les rapports d’authentification de messagerie décrivent des éléments de l’infrastructure d’envoi d’une organisation. Le service devait donc être accessible à ses utilisateurs tout en séparant les données de chaque organisation et en limitant l’exposition de son administration.

    L’exploitation devait également rester compréhensible et maintenable par une équipe réduite : connaître l’état de la machine, pouvoir rejouer sa configuration et détecter les écarts entre la configuration prévue et celle effectivement appliquée.

    Interventions réalisées

    • Conception d’une application où les données sont séparées par organisation dès l’accès au stockage, à partir de la session authentifiée côté serveur.
    • Mise en place d’un traitement des rapports reçus avec contrôles de format et de taille, mise en quarantaine des fichiers concernés, plafonds lors de la décompression et analyse XML durcie.
    • Validation des cibles réseau renseignées par les utilisateurs afin d’éviter qu’une requête applicative ne soit dirigée vers une adresse non autorisée.
    • Organisation de la collecte par boîte mail avec reprise des traitements en échec et signalement des rapports nécessitant une intervention.
    • Ajout d’un export des données de compte, prévu comme une fonction accessible à tous les clients.
    • Description de la configuration permanente de la machine dans un dépôt Ansible, distinct de l’amorçage initial du serveur.
    • Mise en place d’accès d’administration contrôlés, d’un reverse proxy HTTPS et de mécanismes de détection des comportements abusifs.
    • Construction et transport de l’image applicative depuis le poste d’administration, avec identification de la version effectivement déployée.
    • Chiffrement des variables sensibles dans le dépôt et contrôles destinés à prévenir leur divulgation accidentelle.
    • Production d’archives de sauvegarde des bases, avec contrôle de leur lisibilité après écriture et alertes sur leur fraîcheur.
    • Ajout de contrôles internes sur les services, les accès, les ressources, les certificats et les sauvegardes, complétés par une surveillance externe d’un parcours utilisateur réel.
    • Rédaction et mise à jour de la documentation d’exploitation : accès, sauvegarde, vérifications et état des lieux daté.

    Résultat

    Clarsend est en production avec une application et un environnement d’exploitation suivis conjointement. La configuration est documentée et versionnée, ce qui permet d’intervenir à partir d’un état connu plutôt que de reprendre le serveur à l’aveugle.

    Le projet a aussi permis de formaliser des méthodes réutilisables pour d’autres environnements : gestion des accès, suivi de configuration, contrôles de sauvegarde, surveillance et documentation d’exploitation.

  • Remettre en état et sécuriser un site WordPress après une migration cloud

    Après une migration vers le cloud, un site WordPress rencontrait des dysfonctionnements visibles et reposait sur une configuration d’hébergement devenue fragile. DevThis est intervenu pour reprendre l’existant, corriger ce qui bloquait et remettre le socle technique sous contrôle.

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

    Contexte

    Le site avait été migré d’un hébergement mutualisé vers une machine virtuelle Azure. Le contenu et le thème avaient été transférés, sans reprise technique complète de l’environnement. Des dysfonctionnements visibles par les visiteurs coexistaient avec plusieurs fragilités de configuration serveur.

    Ce qui a été repris

    • Revue et nettoyage du thème : suppression de code devenu inutile et de fichiers de sauvegarde restés en production ; correction d’une incohérence de nommage qui empêchait l’affichage de certaines fiches ; retrait d’une dépendance à un plugin de cache absent.
    • Correction du filtrage de recherche : analyse du comportement d’Elementor Pro et tests en conditions réelles pour identifier la cause du dysfonctionnement, puis correction sans empiler de contournements fragiles.
    • Fermeture d’une exposition de fichiers techniques : suppression de l’accès public à un répertoire sensible issu de la migration, sans perturber le fonctionnement du site.
    • Stabilisation de l’hébergement : analyse des timeouts sous charge, correction d’une configuration web concurrente inutile et ajout d’une marge mémoire adaptée à la machine.
    • Durcissement de la machine Azure : pare-feu local à politique restrictive en complément des règles réseau Azure ; accès SSH par clé limité aux adresses autorisées ; mises à jour de sécurité automatisées, journalisation persistante et paramètres système renforcés.
    • Protection contre les attaques automatisées : déploiement de CrowdSec pour analyser les journaux Apache et WordPress, détecter les comportements malveillants et bloquer les adresses identifiées au niveau du pare-feu.
    • Supervision et contrôle de dérive : alertes et contrôles quotidiens sur les services critiques, le certificat TLS, l’espace disque et la configuration SSH. La configuration est versionnée et peut être rejouée par Ansible.

    Ce qui a été remis sous contrôle

    La recherche du site fonctionne de nouveau. L’hébergement est assaini, l’exposition aux risques a été réduite et la configuration peut désormais être maintenue et reprise dans la durée.

    Ce type de reprise fait partie des interventions DevThis pour faire évoluer, remettre en état et sécuriser les sites et outils numériques.

Propulsé par