Quand on parle d’audit et sécurisation WordPress, on pense souvent aux mots de passe, aux règles de pare-feu et aux mises à jour. Tout ça compte. Mais il y a un angle qui finit par rattraper presque toutes les équipes, tôt ou tard: les fichiers. Un site WordPress peut être compromis sans que l’on voie immédiatement des changements visibles dans l’interface. À l’inverse, des modifications de fichiers peuvent sembler anodines, alors qu’elles ouvrent une porte discrète.
Surveiller les modifications de fichiers, c’est chercher des signaux avant que l’incident ne devienne un incident. Pas “par paranoïa”, plutôt par méthode. Sur un WordPress, le cœur du problème est simple: tout ce qui tourne en PHP peut changer, et beaucoup de points d’entrée existent, du thème aux dépendances en passant par les plugins, les fichiers de cache et certaines automatisations.
Je vais détailler une approche pragmatique, orientée audit, qui combine inventaire, intégrité, journaux, détection et réponse. L’objectif n’est pas de tout verrouiller au millimètre, mais de savoir exactement ce qui a bougé, quand, et ce qui est légitime.
Comprendre ce que vous surveillez vraiment
WordPress est un empilement: des fichiers “core”, des thèmes, des plugins, des uploads, parfois des mu-plugins, et des règles d’exécution côté serveur. La surveillance des modifications touche plusieurs familles de changements:
- La modification du code applicatif: fichiers PHP dans wp-content/plugins et wp-content/themes. Les ajouts ou altérations de chargeurs: scripts dans des répertoires inattendus, parfois déguisés. Les changements d’environnement: fichiers de configuration, parfois des variables serveur, mais aussi des fichiers dans le système de fichiers. Les modifications d’uploads: des webshells peuvent être déposés dans des répertoires gérés comme “documents”. Les changements liés au fonctionnement normal: mise à jour de plugin, compilation de front, génération de cache, optimisation par un outil.
Le piège classique, c’est de se focaliser sur “tous les fichiers”. Vous finissez alors noyé dans du bruit: caches, miniatures, .tmp, logs. À l’inverse, si vous ne surveillez que le core, vous risquez de rater un plugin compromis, ou un thème modifié.
Dans la pratique, je recommande de segmenter la surveillance selon le risque et la criticité. Les fichiers PHP qui exécutent du code doivent être traités comme “haut impact”. Les uploads sont “haut risque” mais pas forcément “haut exécution” selon la configuration, pourtant on y trouve des menaces concrètes. Les répertoires de cache et de logs produisent trop d’événements pour être utiles, sauf à les cibler finement.
L’audit commence par un inventaire exploitable
Avant de détecter des changements, il faut pouvoir comparer. Sur WordPress, la méthode la plus utile consiste à établir une référence d’intégrité. Cette référence, c’est une base de hachages (hash) et, souvent, un état attendu par répertoire.
Dans un contexte réel, j’ai vu des équipes activer un outil de monitoring de fichiers après coup, sans “baseline”. Le résultat était frustrant: trop d’alertes immédiatement, aucune confiance dans l’outil, puis désactivation pure et simple. Une baseline crédible change tout.
Une baseline peut venir de plusieurs sources:
Un état “propre” juste après déploiement ou après une mise à jour. Un état “contrôlé” après une procédure de livraison: site validé, plugins approuvés, thèmes figés. Une récupération à partir du paquet officiel (pour le core) et de dépôts contrôlés (pour thèmes et plugins propriétaires).La difficulté n’est pas technique uniquement, elle est organisationnelle. Qui valide qu’un plugin mis à jour est “bon”? Qui sait quels fichiers sont attendus après un build? Si personne ne sait, le monitoring de fichiers devient un sonar sans pilote: on entend, on ne sait pas interpréter.
Les trois couches de surveillance qui marchent en binôme
Dans une approche d’audit et sécurisation WordPress, je vois rarement une seule “technique” suffire. Le plus fiable, c’est de combiner:
1) Hachage et intégrité des fichiers “sensibles”
Le principe: calculer des hash (souvent SHA-256 ou équivalent) sur des fichiers ciblés, puis comparer à la base de référence.
Avantage: vous ne vous fiez pas à une heuristique, vous mesurez un écart réel. Limite: si l’environnement produit constamment des changements (minification dynamique, génération de fichiers), il faut filtrer ou reconstruire la baseline après chaque changement légitime.
2) Surveillance côté serveur avec journaux et événements
Selon votre hébergement, vous pouvez vous appuyer sur des mécanismes du système. Certains serveurs offrent des outils d’intégrité au niveau OS ou des logs d’accès détaillés. Sur Linux, on pense à des solutions de type auditd, ou à des contrôleurs d’intégrité, mais le niveau de granularité dépend du prestataire.
Avantage: indépendance de WordPress. Si l’attaquant modifie un plugin chargé côté PHP, vous voulez idéalement le détecter aussi depuis l’extérieur. Limite: configuration plus exigeante, et dépendance à l’infrastructure.
3) Journalisation applicative et corrélation
WordPress peut journaliser des événements: connexions, changements d’extensions, modifications d’options, activité admin. Ce n’est pas une garantie d’intégrité fichier, mais c’est une excellente couche de corrélation.
Par exemple, si vous voyez une modification d’un fichier PHP dans wp-content/plugins, et en parallèle une modification d’un plugin (upload d’un zip, activation, mise à jour) la même journée, le scénario devient clair. À l’inverse, une modification de fichier PHP sans aucun événement admin ou sans déploiement prévu est un signal fort.
Ciblage: quels répertoires méritent votre attention
Une fois la baseline posée, il faut décider quoi comparer. Le meilleur compromis que j’ai trouvé, c’est de surveiller de façon stricte les fichiers exécutables et les points d’entrée typiques, tout en excluant le “volatile” de façon raisonnable.
En règle générale, je surveille avec rigueur:
- wp-content/plugins (à l’exception d’éventuels dossiers de build très bruyants). wp-content/themes (surtout les fichiers PHP). Les fichiers racine qui portent un rôle critique. Les fichiers dans wp-content/uploads si, chez vous, les uploads sont autorisés pour des types potentiellement dangereux ou s’il y a des cas “user uploads”.
J’exclus presque toujours:
- Les répertoires de cache et de logs internes. Les fichiers de session, quand ils sont dans le même espace que le code. Les fichiers générés automatiquement en dehors de vos déploiements.
Le point important, c’est d’avoir des exclusions qui reflètent vos pratiques. Un site qui génère des fichiers de build côté serveur dans un thème, ce n’est pas pareil qu’un site qui n’écrit jamais dans wp-content/themes en production. Si vous exclusion trop large, vous aveuglez des changements.
Mettre en place la surveillance: logique de déploiement et de réponse
La surveillance des modifications de fichiers devient vraiment utile quand elle s’inscrit dans une procédure de travail. Sinon, elle reste une alarme de plus.
Je fonctionne souvent avec une boucle simple: baseline, détection, qualification, action, apprentissage.
D’abord, baseline après un déploiement validé. Ensuite, quand une alerte arrive, on qualifie sans paniquer: est-ce que c’est lié à un update planifié, une intégration en cours, un traitement de cache? Si oui, on met à jour la baseline après vérification. Si non, on traite comme un incident potentiel.
Le “après vérification” est crucial. Il ne suffit pas de dire “on a vu un fichier modifié”, il faut comprendre si la modification est une mise à jour attendue ou une altération. Dans WordPress, un plugin peut être mis à jour, mais une modification de fichier PHP n’est pas automatiquement légitime.
Une checklist courte pour cadrer l’audit
Voici une liste très pratique que j’utilise pour démarrer, sans s’embarquer dans une usine à gaz:
- Cibler les répertoires “code” (plugins, thèmes) et les points d’entrée critiques, puis définir des exclusions réalistes. Créer une baseline d’intégrité après un état validé (core, thèmes, plugins, selon votre gestion de versions). Définir qui reçoit les alertes et sous quel délai elles doivent être traitées. Établir une procédure de qualification: “déploiement prévu” ou “incident potentiel”. Tester la chaîne sur un changement contrôlé (un fichier de test ou une mise à jour de plugin programmée).
C’est court, mais ça force les bonnes décisions: périmètre, référence, responsabilité, processus, test.
Les outils WordPress et leurs angles morts
Il existe des plugins de monitoring d’intégrité qui tournent dans WordPress. Ils calculent des hash, comparent, et alertent.
C’est utile, mais il faut garder en tête un angle mort possible: si l’attaquant a suffisamment de contrôle pour modifier le plugin de surveillance ou altérer son exécution, la détection peut être contournée. Autrement dit, un outil dans WordPress est excellent pour surveiller WordPress, mais pas infaillible en cas de compromission profonde.
C’est pour ça que je préfère, quand c’est possible, une combinaison: une vérification au niveau serveur ou via un mécanisme externe, plus des journaux côté WordPress.
Sur le terrain, le choix https://gardewp.fr/securite-wordpress/ dépend aussi des contraintes d’hébergement. Certains environnements ne permettent pas les audits système. D’autres n’offrent pas un niveau de logs comparable. Dans ces cas, un plugin d’intégrité bien configuré, avec une baseline correcte, reste une défense utile, surtout si vous ajoutez des contrôles complémentaires (listes d’extensions autorisées, contrôle des updates, alertes sur nouveaux fichiers).
Détecter le “vrai changement”: réduire le bruit sans perdre la portée
Un monitoring efficace ne se contente pas de comparer, il doit être interprétable.
Deux scénarios créent énormément de faux positifs:
- Des build automatiques qui modifient des fichiers de thème à chaque requête (minification, compilation). Des plugins qui écrivent dans leur propre dossier ou génèrent des caches dans des répertoires “code”.
La solution n’est pas toujours technique. Parfois, il faut ajuster le pipeline: déplacer la génération en phase de build, réduire l’écriture en production, ou changer le répertoire de sortie vers un espace explicitement exclu.
Quand on ne peut pas changer le comportement, on peut renforcer la précision du monitoring: surveiller seulement certains extensions, ou seulement les fichiers PHP et les fichiers de configuration, plutôt que tous les fichiers texte. Cette approche dépend évidemment de ce que vous considérez comme menace.
Enfin, un détail pratique qui évite beaucoup de confusion: gérer les changements légitimes via un “fenêtre de maintenance”. Par exemple, pendant une mise à jour programmée, on peut accumuler les alertes mais ne pas déclencher une escalade immédiate, puis recalculer la baseline une fois le site stabilisé. Cela protège les équipes d’alert fatigue, tout en conservant une trace.
Qualification des alertes: comment ne pas se tromper de combat
Quand une alerte tombe, la première erreur consiste à agir trop vite sur des hypothèses. Les systèmes de monitoring sont excellents pour détecter un écart. Ils ne savent pas toujours si c’est un écart attendu.
Je m’appuie sur un principe de qualification: “preuve de légitimité” et “preuve d’absence de légitimité”.
Preuve de légitimité: déploiement planifié, ticket, CI/CD, changement documenté, modification effectuée par une personne habilitée. Absence de légitimité: pas de déploiement, accès admin inhabituel, activation d’un plugin non prévu, création de fichiers dans des répertoires inattendus, patterns d’écriture.
Voici une autre petite liste, plus opérationnelle, pour guider le triage:
- Vérifier si un update a eu lieu dans la fenêtre temporelle de l’alerte (plugins, thèmes, core). Consulter les logs WordPress pour repérer connexion admin, changements d’extensions, actions utilisateur élevées. Inspecter le contenu modifié: ajout de fonctions, lecture de fichiers, base64, appels réseau, “gadget” typique de webshell. Comparer la différence avec la version attendue (archive officielle, dépôt git, package du fournisseur). Décider: rétablissement et baseline mise à jour, ou investigation plus large si le fichier est suspect.
C’est volontairement pragmatique. L’objectif n’est pas de devenir analyste malware, mais de garder un standard: si vous ne pouvez pas justifier, vous traitez comme un incident potentiel.
Exemples concrets de ce que vous pouvez voir
Sur un WordPress compromis, les modifications de fichiers se manifestent souvent de manière reconnaissable, même si le détail exact varie.
Par exemple, on peut trouver un fichier PHP ajouté dans un répertoire non habituel, parfois avec des noms génériques ou des extensions trompeuses. La modification n’est pas toujours visible dans l’interface, parce que l’exécution peut être déclenchée par une requête particulière, une chaîne de paramètres, ou une condition liée à l’heure.
Autre cas: un plugin ou un thème modifié, mais uniquement sur quelques lignes, ajout d’un “hook” ou d’un code qui intercepte des événements WordPress. L’interface peut rester fonctionnelle, et l’attaque se contente d’exfiltrer des informations, ou de télécharger du code additionnel.
Il arrive aussi que des changements soient légitimes mais mal gérés: un plugin de compression qui écrit des fichiers dans son dossier, un thème qui exécute une génération de contenu. Les fichiers changent souvent, l’outil d’intégrité alerte tout le temps. Dans ce cas, le problème n’est pas la sécurité, c’est la configuration de surveillance.
C’est pour ça que la surveillance des modifications de fichiers doit être couplée à une connaissance de votre stack: quelles automatisations tournent, à quelle fréquence, et où elles écrivent.
Réponse à incident: restauration et reprise contrôlée
Supposons maintenant que vous ayez confirmé un fichier suspect. Quelle devrait être la séquence raisonnable?
D’abord, évitez de nettoyer “à la main” sans conserver un état reproductible. Si vous effacez trop vite, vous perdez des indices. En pratique, je recommande de garder une copie du fichier suspect et, si possible, de conserver aussi un diff.
Ensuite, vous restaurez à partir d’une source fiable. Pour le core, la référence est claire. Pour un plugin ou un thème, la meilleure source est le package ou le dépôt approuvé. Si votre organisation n’a pas de source fiable, vous vous retrouvez à dépendre d’une reconstruction à partir de ce que vous aviez, ce qui augmente le risque.
Après restauration, vous mettez à jour la baseline, et vous surveillez de nouveau. Un incident peut laisser une porte ouverte. Le fait de surveiller après correction est une protection, pas un simple détail.
Enfin, vous traitez la cause: mot de passe compromis, vulnérabilité non corrigée, plugin non approuvé, mauvaise configuration d’autorisations sur des répertoires, ou absence de contrôle des mises à jour. Sans cela, vous risquez de repasser par la même alerte.
Cas particuliers: uploads, fichiers “non PHP” et configuration serveur
Surveiller les modifications dans les uploads est délicat. D’un côté, des menaces passent par là. Un fichier peut être déposée, ou un fichier inoffensif au départ peut devenir dangereux selon la façon dont le serveur l’interprète.
D’un autre côté, les uploads changent en permanence. Si vous activez une surveillance trop large, vous obtenez un flux d’alertes ingérable.
La stratégie qui marche, c’est de surveiller les patterns de risque, par exemple la présence de types de fichiers qui ne devraient pas être déposés (en fonction de vos usages), ou la création de fichiers dans des sous-dossiers que les utilisateurs ne devraient pas toucher. Vous pouvez aussi limiter la surveillance au code exécutable, et garder un contrôle des fichiers déclencheurs typiques.
Côté serveur, les bonnes pratiques consistent à empêcher l’exécution de PHP dans les répertoires d’uploads, selon la configuration. Je ne décris pas une recette universelle, parce que l’implémentation dépend d’Apache, de Nginx, des directives, et parfois des wrappers d’hébergement. Mais la logique reste: réduire la surface où un dépôt de fichier devient une exécution.
Fréquence de scan et contraintes d’hébergement
Un point sous-estimé: à quelle fréquence calculer les hash.
Si c’est trop fréquent, vous chargez inutilement le serveur ou vous tombez sur des limites de performance. Si c’est trop rare, vous détectez tard.
Le bon réglage dépend du volume de fichiers, de la puissance du serveur, et de la latence acceptable côté incident. En pratique, beaucoup d’équipes préfèrent des scans planifiés, plus une surveillance renforcée lors des périodes de déploiement.
Le “lors des déploiements” est une nuance importante. Entre deux mises à jour, le site bouge peu si votre configuration est saine. Pendant un déploiement, il bouge beaucoup, et c’est exactement le moment où les compromis peuvent se cacher si un attaquant profite d’une fenêtre d’accès.
La valeur réelle: une sécurité qui se mesure dans le temps
Un bon audit et sécurisation WordPress n’est pas uniquement un état. C’est une capacité à répondre vite, et surtout à comprendre. La surveillance des modifications de fichiers vous donne un fil conducteur, mais elle n’est utile que si elle s’intègre à un cycle d’exploitation.
Quand elle est bien mise en place, vous réduisez trois choses:
- Le temps de détection, parce que vous recevez une alerte sur l’écart réel. Le temps de décision, parce que vous avez une baseline et des logs corrélés. Le temps de remédiation, parce que vous savez quoi restaurer et comment vérifier après correction.
Et surtout, elle améliore la qualité de votre déploiement. Vous apprenez progressivement quels changements sont normaux chez vous, et lesquels ne le sont pas. Cette connaissance locale bat n’importe quelle règle générique.
Points de vigilance avant de “tout activer”
Je termine avec des précautions issues de cas réels, quand la surveillance déraille:
Premièrement, ne confondez pas “alertes nombreuses” avec “bonne sécurité”. Si vous générez trop de bruit, l’outil perd sa valeur. Mieux vaut une alerte rare et justifiée, avec une procédure de triage, qu’un feu d’artifice qui finit en désactivation.
Deuxièmement, faites évoluer la baseline après des changements légitimes vérifiés, mais gardez une traçabilité. Sans ça, vous transformez la baseline en “mémoire floue”.
Troisièmement, vérifiez l’intégrité de votre propre chaîne de surveillance. Si le plugin de monitoring ou le système externe peut être modifié, le monitoring devient un maillon faible. D’où l’intérêt d’outils côté serveur ou au minimum de contrôles croisés.
Enfin, gardez en tête que l’audit des fichiers n’est pas un substitut à la gestion des vulnérabilités et aux mots de passe. C’est un filet supplémentaire, et un excellent outil de diagnostic. Sur un site vivant, il apporte une visibilité concrète sur ce qui change réellement.
Si vous voulez commencer simple, choisissez un périmètre restreint, établissez une baseline solide, et construisez la procédure de qualification. Ensuite seulement, élargissez. La surveillance des modifications de fichiers devient alors une compétence opérationnelle, pas un gadget.