Un site WordPress peut être compromis sans que l’on voie grand-chose à l’écran. Parfois, la page d’accueil se charge, les formulaires fonctionnent, tout semble normal… jusqu’au moment où vous découvrez un ajout discret: un fichier PHP dans un répertoire oublié, un bout de code dans un thème enfant, une modification silencieuse de l’extension d’un plugin. Dans ces scénarios, la vérification de l’intégrité des fichiers n’est pas un gadget, c’est un réflexe de protection site WordPress.
L’idée est simple: comparer l’état actuel de vos fichiers à un état de référence fiable. Cette référence peut être un jeu de fichiers propre (WordPress de base), des sommes de contrôle calculées lors d’un déploiement maîtrisé, ou encore une base de référence conservée depuis une fenêtre “saine” du site. Ensuite, vous cherchez des écarts. Ce qui est rassurant, c’est que vous n’avez pas besoin d’être paranoïaque pour être efficace. Une bonne procédure d’intégrité réduit énormément le temps de réaction, surtout quand l’attaque vise la persistance.
Ce que “intégrité des fichiers” veut dire concrètement
Quand on parle d’intégrité, on parle généralement de “fichiers qui restent identiques”. Sur un serveur, l’identité d’un fichier se résume rarement à la seule taille. Deux approches reviennent sans cesse:
- La comparaison de contenu via des sommes de contrôle (hash) La comparaison d’attributs et de contenu via des listes attendues (fichiers attendus, permissions, propriétaires, dates)
Le piège, c’est de confondre “date de modification récente” et “compromission”. Un développeur met à jour un plugin, vous installez un correctif, ou votre outil de déploiement réécrit des fichiers. Dans tous ces cas, les timestamps bougent. La valeur d’un contrôle par hash, c’est qu’il détecte une modification réelle du contenu, pas juste un événement de système.
Dans une stratégie crédible, vous combinez deux niveaux d’observation: 1) ce qui est “normal” pour votre site (fichiers attendus, thèmes, plugins, uploads) 2) ce qui est “anormal” (un fichier exécuté qui n’a rien à faire là, un changement de code PHP dans le noyau ou dans vos composants)
Pourquoi c’est particulièrement important sur WordPress
WordPress a une particularité pratique: beaucoup de composants sont constitués de fichiers PHP et de contenu. Le noyau, les thèmes, les plugins, et même certains fichiers du cache ou des assets peuvent être modifiés. Une compromission exploite souvent cet écosystème pour conserver un accès, injecter du contenu ou préparer d’autres étapes.
Les signatures classiques d’une altération sont parfois visibles, parfois non. Un fichier ajouté dans un répertoire improbable peut être exécuté seulement dans certaines conditions. Un thème “légitime” peut être modifié à un endroit précis, par exemple une fonction chargée d’inclure une ressource distante. Sans vérification, vous pouvez passer à côté pendant des semaines.
Autre point sous-estimé: même si vous supprimez un fichier malveillant, un plugin déjà touché peut contenir une charge utile qui se réinstalle à partir d’un dépôt distant, ou qui s’active au prochain chargement. Vérifier l’intégrité, c’est aussi vérifier que la “surface” PHP revient bien à un état propre après nettoyage.
La qualité de votre référence compte plus que l’outil
Il existe des outils qui scannent, calculent, et comparent. Mais votre efficacité dépend surtout de la référence que vous utilisez.
Une référence médiocre, c’est par exemple:
- “Je pense que le site était sain avant” Une archive téléchargée au hasard sans correspondre exactement à votre version Un snapshot ancien où vous aviez déjà des modifications légitimes non documentées
Une référence solide, c’est par exemple:
- Un build ou un déploiement reproductible (même source, mêmes versions) Des sommes de contrôle calculées juste après une mise en production maîtrisée Une archive de production validée, conservée avec une trace claire (date, version WordPress, versions des plugins, thème actif)
Si vous avez déjà une routine de déploiement, vous êtes avantagé. Sinon, vous pouvez démarrer petit: choisissez une fenêtre de “confiance” et capturez l’état courant, puis mettez en place une discipline de comparaison.
Approche pratique: trois niveaux de vérification
Dans les environnements WordPress, je vois rarement une seule technique suffire. En revanche, une combinaison reste légère et robuste.
1) Vérifier le noyau WordPress
Le noyau est relativement standard. Si vous savez quelle version exacte tourne sur votre site, vous pouvez comparer vos fichiers du dossier WordPress (hors uploads) à une version de référence propre.
Le résultat le plus utile, c’est de détecter:
- des fichiers PHP qui auraient changé dans wp-includes ou wp-admin des ajouts de fichiers dans des sous-dossiers que vous n’utilisez pas des modifications de code dans des chemins attendus
Cette étape cible souvent les compromissions opportunistes. Quand un attaquant modifie le noyau, il laisse souvent des traces (même minimes).
2) Vérifier vos thèmes et plugins
Là, la difficulté augmente, parce que vous ne disposez pas d’un “noyau” standard. Vous avez:
- des thèmes personnalisés des thèmes enfants des plugins tiers parfois des plugins maison
Vous pouvez tout de même travailler par hash, mais il faut une référence adaptée à votre stack.
Dans le meilleur des cas, vos thèmes et plugins sont stockés dans un répertoire de production cohérent, et vous pouvez recalculer des sommes de contrôle à chaque déploiement. Dans un cas moins favorable, vous pouvez au minimum:
- exclure les éléments qui varient légitimement surveiller les fichiers PHP des thèmes et plugins garder une liste “attendue” de fichiers
3) Garder un œil sur les uploads et le contenu
Les fichiers dans wp-content/uploads sont censés varier. Mais la variation ne veut pas dire que tout est acceptable. Les attaques se servent parfois du contenu comme d’un canal de persistance ou d’exécution. Typiquement, on surveille plutôt:
- la présence de fichiers exécutables inattendus dans les dossiers d’uploads les extensions inhabituelles (fichiers PHP, fichiers masqués avec des extensions trompeuses) les changements soudains dans des répertoires où vous n’importez jamais
Pour les uploads, le contrôle par hash peut être utile, mais il faut accepter un bruit énorme. En pratique, on préfère une règle plus “qualitative”: repérer les catégories de fichiers anormales, et mesurer si de nouveaux fichiers apparaissent en dehors de vos processus habituels.
Mettre en place une vérification par sommes de contrôle (hash)
La méthode la plus directe est de calculer un hash pour chaque fichier surveillé, puis de comparer avec une référence.
Le principe: au moment où vous considérez le site comme sain, vous parcourez vos répertoires cibles et vous générez une liste du type “chemin -> hash”. Ensuite, à chaque scan, vous régénérez une liste et vous comparez.
Sur un serveur Linux, on utilise souvent SHA-256. La commande exacte dépend de votre environnement, mais l’idée reste la même.
Vous pouvez faire cela via votre outil d’administration, ou via des scripts. Sur un hosting standard, je recommande souvent une exécution à froid:
- lancer le calcul depuis une session SSH éviter de déclencher des charges énormes sur des milliers de fichiers limiter les répertoires si nécessaire
Une contrainte réelle: sur de gros sites, recalculer tous les hashes peut devenir coûteux. Dans ces cas, vous pouvez:
- surveiller les fichiers PHP des thèmes et plugins en priorité exclure les caches, les logs, et certains dossiers d’uploads fractionner en plusieurs fenêtres (par exemple noyau aujourd’hui, plugins demain)
Le bon compromis est celui que vous pouvez exécuter souvent. Un contrôle trop lourd que vous faites une fois par an perd son intérêt.
Un exemple de logique de script (conceptuel)
L’objectif n’est pas de vous imposer une commande unique, mais de comprendre la logique:
1) définir les dossiers surveillés (noyau, thèmes, plugins) 2) calculer pour chaque fichier un hash 3) enregistrer le résultat dans un fichier de référence horodaté 4) lors du scan, recalculer et comparer 5) en cas d’écart, ouvrir une investigation avec une procédure claire
Vous pouvez même stocker la référence dans un endroit non accessible en écriture par le serveur web, ou dans un stockage externe (selon vos contraintes de conformité et de sécurité).
Outils utiles, sans perdre la maîtrise
Il existe des utilitaires de “file integrity monitoring” (FIM) qui automatisent la surveillance. Mais même dans ce cas, la maîtrise du périmètre reste essentielle. Un outil peut scanner trop, générer trop d’alertes, et vous finissez par ignorer les alertes.
Voici comment j’aborderais les outils, en restant pragmatique:
- Si vous pouvez calculer des hashes de façon reproductible, vous n’avez pas besoin de magie. L’outil devient un “assistant”, pas une excuse. Si vous utilisez un plugin de sécurité WordPress qui propose une vérification, vérifiez ce qu’il calcule exactement. Certains se limitent à des signaux faibles, d’autres comparent une liste interne. Dans les deux cas, cela aide, mais ne remplace pas toujours un contrôle par hash adapté à votre référence. Si vous utilisez WP-CLI, vous pouvez intégrer la logique dans un processus de maintenance. L’intérêt, c’est la répétabilité, notamment après une mise à jour.
Je préfère toujours une approche où vous savez ce que l’outil surveille et ce qu’il exclut. En incident response, c’est crucial.
Mettre à l’épreuve votre méthode: que faire quand des fichiers changent ?
Le cœur du problème, ce n’est pas la détection, c’est le tri entre changement légitime et changement suspect.
Un changement peut être légitime si:
- vous avez fait une mise à jour de plugin ou de thème vous avez déployé une version différente (CI/CD, upload de fichiers) vous avez modifié un fichier de configuration prévu pour varier
Il devient suspect si:
- la modification touche le noyau un fichier PHP apparaît dans un répertoire où vous n’attendez aucune exécution des changements se produisent sans événement planifié (pas de mise à jour, pas de déploiement)
Voici une mini check-list de départ, simple, mais qui évite beaucoup d’erreurs:
- confirmer la version WordPress, thème actif, versions des plugins recouper la date des changements avec vos journaux (déploiement, mises à jour, accès) vérifier si les fichiers modifiés sont du noyau, du thème, ou d’un plugin comparer le contenu aux hashes de référence, pas seulement aux dates décider d’une action d’investigation avant de “nettoyer au hasard”
Quand vous trouvez des écarts, la première question à se poser est celle-ci: “Est-ce que je connais l’origine du changement?” Si la réponse est floue, vous partez du principe que c’est suspect, puis vous reconstruisez un état propre.
Une procédure d’investigation qui évite de casser le site
J’ai vu des équipes “corriger” trop vite, ce qui a supprimé des modifications légitimes (ajustements de thème, fichiers personnalisés) et rendu l’analyse plus compliquée.
Une procédure robuste ressemble à ceci, en pratique:
1) isoler le périmètre (ce qui a changé) 2) sauvegarder l’existant avant toute restauration 3) reconstruire un état propre pour les éléments concernés (noyau, thème, plugin) en utilisant une source fiable 4) supprimer ou réinstaller uniquement ce qui est corrompu, pas ce qui est “probablement” 5) vérifier que la régression n’apparaît pas (fonctionnalités dépendantes, hooks, styles, bibliothèques)
Le détail important: si un plugin compromis réintroduit une charge à la prochaine exécution, vous aurez l’impression de “nettoyer” mais la menace revient. D’où l’intérêt de coupler intégrité des fichiers et contrôle des accès (mots de passe, comptes, clés API, tâches planifiées).
Cas fréquents et comment les interpréter
Les écarts ne veulent pas tous dire “piratage”. Certains reflètent des comportements de développement ou d’outillage. D’autres racontent une histoire de compromission.
Voici un tableau mental utile, sans se transformer en paranoïa systématique. Quand vous voyez un changement, vous pouvez chercher la cause dans ces scénarios typiques:
- Un plugin a été mis à jour, et vos hashes changent sur wp-content/plugins/nom-plugin/... Un thème enfant a été mis à jour manuellement, et le fichier style.css ou functions.php change Une mise à jour WordPress a réécrit des fichiers du noyau, et c’est attendu Un fichier PHP apparaît dans un dossier d’uploads ou dans un répertoire de cache, et là, le doute devient fort Le propriétaire ou les permissions changent sur des fichiers PHP de base, et cela peut indiquer une action hors procédure (ou une mauvaise configuration)
Quand un comportement est incohérent avec vos habitudes, l’intégrité devient un signal d’enquête, pas une preuve absolue. La preuve arrive après analyse du contenu et recoupement.
Deux façons de comparer: brutale ou graduée
Vous pouvez comparer de façon totale, ou de façon graduée.
Comparaison totale: vous comparez tous les fichiers du périmètre. Avantage, vous ne manquez presque rien. Inconvénient, bruit et coût, surtout sur les sites riches en fichiers.
Comparaison graduée: vous priorisez les fichiers à risque, par exemple:
- PHP dans wp-admin, wp-includes PHP dans les thèmes et plugins actifs fichiers de configuration critiques fichiers nouveaux ou modifiés récemment (en appliquant une règle plus stricte)
Dans une approche mature, je combine les deux: une vérification régulière “graduée” plus légère, puis une vérification complète moins fréquente.
Le piège des exclusions: ce que vous ne surveillez pas vous protège, jusqu’au jour où ça ne protège plus
Une exclusion trop large, c’est tentant. Mais sur WordPress, l’attaque peut se cacher dans des chemins inattendus, ou utiliser des dossiers “habituellement ignorés”.
Par exemple, les caches et mini-fichiers générés peuvent changer et provoquer des alertes. Oui, il faut les exclure. Mais exclure le mauvais répertoire peut vous faire rater un fichier malveillant qui s’y cache.
Le bon réglage consiste à exclure ce qui est réellement généré par le site et qui ne doit jamais contenir de PHP “actif”. Et si vous excluez, vous devez savoir pourquoi.
Permissions et propriétaires: l’intégrité ne suffit pas
Une vérification par hash est très utile, mais elle n’explique pas tout. Deux sites peuvent avoir les mêmes hashes et être différents en sécurité à cause des permissions.
Si un attaquant obtient un certain niveau d’accès, il peut aussi modifier:
- les permissions (par exemple rendre des fichiers trop accessibles) le propriétaire du fichier (cas d’erreur de déploiement, ou action malveillante) la manière dont PHP exécute certains fichiers (selon configuration serveur)
Donc, dans votre procédure, vous gagnez à récupérer au moins un instantané des permissions et propriétaires pour les fichiers critiques. Cela ne remplace pas la comparaison, mais ça donne un contexte.
Mettre en place une routine sans devenir esclave des alertes
Une bonne routine a trois caractéristiques: elle est fréquente, reproductible, et actionnable.
- Fréquente: suffisamment pour que l’intervalle entre deux contrôles soit petit face à l’attaque (en pratique, plus vous surveillez souvent, plus vous réduisez le “temps de fenêtre”). Reproductible: vous pouvez relancer la même commande après un incident, sans inventer. Actionnable: chaque alerte mène à une décision, pas à une lecture interminable.
Une façon de démarrer: après chaque déploiement, vous recalculer la référence de ce qui a changé, ou vous stockez un nouveau “snapshot” de référence. Ensuite, à l’intervalle choisi, vous exécutez une comparaison graduée.
Quand l’alerte tombe, vous évitez la panique et vous appliquez un tri. Vous pouvez même classer les écarts en “probablement normal” et “à investiguer”.
Pour rester concret, voici une seconde liste courte, orientée décision, que j’utilise pour accélérer le traitement:
- changement uniquement sur wp-content/uploads avec fichiers attendus, investiguer surtout l’extension et la date changement sur wp-admin ou wp-includes, investiguer en priorité (souvent signe fort) changement sur un plugin actif sans mise à jour planifiée, investiguer et comparer avec la version déployée apparition de fichiers PHP dans un dossier non PHP, traiter comme incident jusqu’à preuve du contraire modification d’un thème enfant avec déploiement récent, vérifier le contenu exact et recouper avec votre repo
Comment restaurer proprement quand une altération est confirmée
La restauration est l’étape où l’on perd du temps si on n’a pas préparé.
La règle la plus saine: restaurer à partir d’une source fiable, alignée avec vos versions.
- Pour le noyau WordPress: réinstaller ou reconstruire depuis une source correspondant à la version Pour un plugin tiers: réinstaller depuis une version connue et correspondante Pour un thème: reconstruire depuis votre source (repo, build), pas depuis un fichier “au feeling” sur le serveur
Ensuite seulement, vous appliquez vos personnalisations restantes. Si vous avez https://gardewp.fr/securite-wordpress/ une stratégie de sauvegardes et de versionnement, la restauration devient une opération maîtrisée plutôt qu’une chirurgie.
Un détail utile, souvent oublié: garder un échantillon de l’état compromis “pour analyse” avant restauration. Si vous restaurez immédiatement, vous perdez parfois la trace de ce qui a été modifié et où se trouve la logique malveillante.
Vérification d’intégrité et sécurité globale: la connexion à ne pas rater
L’intégrité des fichiers est une brique. Elle se connecte à d’autres protections.
Un site peut détecter des modifications, mais rester vulnérable si:
- des comptes administrateurs ont des mots de passe faibles l’accès SSH ou FTP est ouvert sans durcissement des clés d’API sont compromises des tâches planifiées malveillantes existent des pages “cachées” sont injectées via base de données plutôt que via fichiers
En pratique, quand vous détectez des changements, vous gagnez à effectuer aussi une revue des éléments proches:
- utilisateurs WordPress et rôles cron WordPress et tâches planifiées paramètres de configuration sensibles activité inhabituelle côté serveur (selon vos logs)
Je le dis souvent aux équipes: l’intégrité vous dit “quelque chose a bougé”. La sécurité globale vous aide à répondre “pourquoi, et comment empêcher que ça recommence”.
Recommandations de départ, adaptées à une première mise en place
Si vous partez de zéro, il n’est pas nécessaire de viser une couverture parfaite le premier jour. Visez une première boucle utile, puis améliorez.
Commencez par:
- choisir un périmètre surveillé cohérent (noyau, thèmes et plugins actifs) créer une référence hash maintenant, en supposant que votre site est sain ou au moins contrôlé à ce moment lancer un scan régulier à une fréquence réaliste consigner les écarts avec une décision claire
Si vous gérez un site à plusieurs environnements (staging puis production), utilisez staging pour préparer vos références. Et surtout, gardez une relation propre entre “version déployée” et “référence d’intégrité”. C’est cette discipline qui transforme le scan en outil fiable, pas en bruit permanent.
Garder le cap sur le long terme
L’intégrité des fichiers n’est pas une opération ponctuelle. C’est un fil conducteur dans la maintenance WordPress. À chaque déploiement, vous pouvez:
- vérifier que les changements attendus sont ceux qui apparaissent mettre à jour votre référence de référence détecter des surprises, même quand tout “semble fonctionner”
Sur un site qui grandit, les menaces évoluent aussi. Un attaquant cherche des failles, mais aussi des angles morts dans vos processus. La vérification d’intégrité, bien réglée, transforme un angle mort en point de contrôle.
Et c’est là que ça devient vraiment utile: pas seulement pour trouver ce qui est déjà compromis, mais pour empêcher que la prochaine altération passe sous votre radar.