Audit et sécurisation WordPress : analyser l’intégrité via checksums

Quand on parle de sécurisation WordPress, on pense souvent à la pile classique, correctifs, mots de passe robustes, plugins de sécurité, durcissement du thème. Tout ça compte, mais il existe une étape plus « mécanique », presque comptable, qui rassure parce qu’elle ne dépend pas de l’intuition: vérifier l’intégrité des fichiers à l’aide de sommes de contrôle, aussi appelées checksums.

L’idée est simple, et c’est pour ça qu’elle fonctionne: on calcule une empreinte cryptographique d’un fichier, puis on compare cette empreinte à une référence. Si le contenu change, l’empreinte change aussi. Si la référence est fiable, un écart devient un signal d’alerte sérieux.

Dans la vraie vie, l’analyse par checksums n’est pas un bouton unique. On doit décider quoi vérifier, comment gérer les fichiers légitimes qui changent, et comment interpréter les différences sans tomber dans le faux positif permanent. C’est précisément ce que je vais détailler, avec des choix concrets et des pièges récurrents que j’ai vus sur des audits.
Pourquoi les checksums sont un bon levier dans un audit
Les attaques sur WordPress finissent très souvent par modifier du contenu dans le dossier d’installation: un fichier PHP injecté dans un thème, un plugin modifié, un petit dropper dans un répertoire peu surveillé, parfois un changement “propre” mais inattendu.

Les logs peuvent aider, mais ils sont variables, incomplets, parfois déjà effacés ou noyés dans le bruit. Les notifications de sécurité, elles aussi, dépendent de règles externes. Les checksums, à l’inverse, reposent sur une comparaison de réalité: qu’est ce qui est réellement sur le disque par rapport à une version attendue.

En audit, j’utilise les checksums pour répondre à deux questions différentes.

La première concerne l’intégrité “statique”. Est-ce que le cœur WordPress, les fichiers de plugins et les fichiers de thème sont identiques à ce qu’ils devraient être? Si non, quels fichiers ont changé?

La seconde concerne l’intégrité “évolutive”. Est-ce que l’ensemble des fichiers qui changent le fait à un rythme normal, avec des zones attendues, ou est-ce qu’on observe des modifications sporadiques dans des emplacements qui n’ont aucune raison d’être modifiés?

Cette distinction est importante, car un site vivant génère toujours des changements: caches, uploads, éventuellement des fichiers de configuration. Les checksums servent à cadrer le https://gardewp.fr/securite-wordpress/ https://gardewp.fr/securite-wordpress/ périmètre pour ne pas confondre un changement légitime et une altération.
Le principe, sans magie: empreinte et référence
Une checksum est une empreinte calculée à partir du contenu d’un fichier. Les algorithmes modernes utilisent typiquement SHA-256 ou équivalents. L’algorithme choisit conditionne la robustesse et la compatibilité avec vos outils.

Le point clé, c’est la référence. Une checksum n’a de valeur que si vous comparez à une base cohérente, obtenue avant l’incident, ou depuis une source maîtrisée. En pratique, vous aurez trois familles de références.

Première famille: un état connu “bon”. Vous avez une sauvegarde prise juste avant un événement, ou après une installation réputée saine. On calcule les checksums sur cette base, puis on compare.

Deuxième famille: les distributions officielles. WordPress et beaucoup d’éditeurs publient des sommes de contrôle associées aux versions téléchargeables. On peut alors recalculer sur la machine et vérifier que les fichiers du package correspondent.

Troisième famille: une baseline créée lors de la mise en production. On calcule et on enregistre une première fois dès que l’installation est stabilisée, puis on surveille l’évolution.

Sur le papier, la baseline paraît la plus simple. Sur le terrain, elle peut être trompeuse si le site est déjà compromis au moment où vous “figez” les références. C’est pour ça que, dans un audit sérieux, je commence par déterminer quel niveau de confiance on peut accorder aux références. Si vous n’avez aucune période “propre” crédible, il faut combiner d’autres signaux, sinon vous ne saurez jamais si vous surveillez un état déjà altéré.
Choisir ce qu’il faut calculer, et ce qu’il faut exclure
Le piège classique, c’est de prendre “tout le dossier” et d’obtenir un océan d’écarts. Un site WordPress n’est pas immuable. La bibliothèque d’uploads grossit, les caches changent, certains fichiers évoluent selon votre configuration.

Dans mes audits, je vise un objectif simple: calculer les checksums des fichiers que l’on considère comme “code” ou “configuration” et exclure les données attendues comme variables.

Concrètement, j’ai tendance à inclure:
le code PHP du noyau WordPress, et les fichiers qui ne devraient pas changer hors mises à jour les fichiers PHP des thèmes et des plugins installés les fichiers de configuration qui portent une logique d’exécution (par exemple wp-config.php, selon le niveau de sensibilité et vos règles internes)
J’exclus généralement:
les répertoires d’uploads et médias, car leur contenu change en continu les caches applicatifs, dossiers de compilation, fichiers temporaires les logs, traces et fichiers générés par le serveur ou des modules annexes
La frontière dépend de votre politique. Certains équipes veulent aussi surveiller les changements dans les fichiers de configuration, mais elles acceptent alors d’organiser un processus d’approbation clair. D’autres préfèrent se limiter aux fichiers de code, pour réduire la friction.

Une règle pragmatique: si un fichier change souvent sans que personne ne lance une procédure connue, il est probablement un mauvais candidat pour un contrôle d’intégrité strict. Il peut rester utile en surveillance “large”, mais pas comme point de validation au quotidien.
Structurer une baseline fiable
Une baseline, ce n’est pas seulement un fichier de sortie avec des checksums. C’est un ensemble de décisions sur le périmètre, l’algorithme, la période de création, et la manière de versionner.

Sur un audit, je recommande de stocker les résultats dans un endroit qui ne dépend pas du même niveau de compromission que le serveur web. Si un attaquant a déjà les droits pour modifier les fichiers, il cherchera souvent aussi à modifier vos preuves. Le stockage hors serveur, ou du moins hors du périmètre web, rend la comparaison plus crédible.

Pour le périmètre, je prépare souvent une liste d’inclusion et d’exclusion, puis je la rends explicite. Sans ça, à la prochaine analyse, on se retrouve à recalculer avec des paramètres différents et on perd la comparabilité.

Il y a un autre détail qui paraît mineur mais qui aide beaucoup: enregistrer aussi la taille des fichiers et, si possible, le type de fichier. Une checksum suffit pour détecter une altération, mais la taille clarifie parfois le comportement (un fichier minifié remplacé par une version plus longue, ou un script injecté avec quelques lignes en plus).

Enfin, choisissez votre cadence. Une comparaison quotidienne sur un grand site peut devenir lourde. Dans la plupart des cas, une vérification périodique est plus utile si elle est associée à des événements: déploiement, installation de plugin, changement de thème, ou signal de suspicion.
Comment calculer les checksums côté serveur (options réalistes)
Il y a plusieurs manières de calculer des checksums. Le choix dépend de votre environnement, accès shell, contraintes de performance, et politiques de sécurité.

Sur un hébergement standard, vous pouvez utiliser un utilitaire checksum du système, puis exporter les résultats dans un fichier. Sur des environnements où vous avez accès à une console d’administration, vous pouvez automatiser via script, en parcourant le répertoire et en générant une liste.

Si vous utilisez un outil d’administration comme WP-CLI, il existe des façons d’orchestrer des scripts au bon niveau. L’intérêt de WP-CLI ici n’est pas de “calculer” la checksum à lui seul, mais de faciliter l’exécution et la cohérence dans votre procédure d’exploitation.

Je garde une approche simple dans les audits: un script qui parcourt un périmètre maîtrisé, calcule SHA-256, écrit une ligne par fichier avec le chemin relatif, la taille et la checksum, puis je compare avec une baseline précédente.

Le point sensible, c’est le respect des permissions et du contexte. Si un fichier n’est pas lisible au moment du calcul, vous obtenez un trou dans vos résultats. Sur un site compromis, l’attaquant peut aussi viser à casser la lecture ou modifier les permissions pour perturber l’audit. Dans ce cas, l’absence de checksum est déjà une information, mais elle mérite une mention explicite dans le rapport.
Comparer et interpréter les écarts sans sur-réagir
Une comparaison de checksums vous donne une liste de fichiers modifiés, supprimés, ou non retrouvés. C’est là que l’analyse devient utile, parce que tous les écarts ne signifient pas “compromission”.

Par exemple, après une mise à jour WordPress, vous attendriez un grand nombre de changements sur le dossier du noyau. Après un déploiement de plugin, vous en attendez sur le plugin concerné. Si vous avez une pratique de changement formalisée, vos écarts “normaux” deviennent prévisibles.

Ce qui m’intéresse en priorité, ce sont les écarts sur des fichiers qui ne devraient pas avoir de raison de bouger, notamment:
les fichiers PHP du noyau en dehors d’un cycle de mise à jour planifié des fichiers PHP ajoutés dans des répertoires atypiques des fichiers qui changent sans que l’équipe ait documenté une action des modifications partielles qui ressemblent à une injection, par exemple un ajout de quelques lignes et le reste inchangé
Dans les audits, je fais souvent une lecture logique avant de me lancer dans la forensique lourde. Je prends les fichiers changés, je regarde leur contexte: chemin, type de fichier, date de modification, taille, et ce qu’il y a dans le contenu. Une diff entre l’ancien et le nouveau fichier aide énormément. Même sans être expert du code, on repère des patterns: appels à des fonctions inattendues, récupération distante, obfuscation, base64 en masse, ou routines d’exécution conditionnelle.

Voici un repère utile pour classer les écarts, sans prétendre que c’est une vérité absolue.
si l’écart concerne uniquement les fichiers que vous avez réellement mis à jour, c’est probablement normal si l’écart concerne des fichiers de code dans des zones inattendues, c’est une alerte forte si l’écart concerne des fichiers qui contiennent peu de logique mais beaucoup d’encodage ou de chargement dynamique, c’est très suspect si l’écart touche des fichiers de configuration critiques, même sans code obfusqué, c’est à traiter en priorité
Le but n’est pas de “condamner” automatiquement. Le but est de trier, accélérer l’investigation, et éviter de passer des heures sur un faux positif.
Cas concrets: ce que j’ai vu en pratique
Sur des sites d’équipe, le premier scénario fréquent est la dérive opérationnelle. Personne ne “met à jour souvent” mais on installe un plugin ou on change un thème sans procédure, juste avant une campagne. Le lendemain, une vérification checksums remonte des alertes. En recoupant, on confirme que la mise à jour n’était pas enregistrée, pas que le site est compromis. Ici, le checksum ne se trompe pas, c’est le processus qui manque.

Le deuxième scénario est plus parlant. Un audit montre une modification d’un fichier PHP dans un dossier inattendu, par exemple à la frontière entre thèmes et uploads, ou dans un répertoire qui n’exécute pas normalement de PHP. Souvent, le fichier contient une logique qui n’a pas de sens pour le thème, et une exécution conditionnelle basée sur une requête ou un paramètre. Le checksum sert alors de pointeur, pas de preuve unique. Une fois localisé, on fait la diff et on établit le mécanisme.

Le troisième scénario concerne les exclusions. Une équipe exclut “trop large” des répertoires pour réduire le bruit. Résultat, des fichiers malicieux sont placés dans un répertoire que vous avez choisi d’ignorer. C’est moins fréquent si vos exclusions sont bien ciblées, mais ça arrive, surtout quand on “simplifie” à la hâte.

Ces histoires racontent une règle simple: les checksums sont excellents pour détecter les changements, mais la qualité du résultat dépend de la discipline sur le périmètre et la référence.
Bonnes pratiques de sécurisation autour des checksums
Les checksums ne remplacent pas la sécurisation, ils la renforcent. Ils améliorent votre capacité à détecter, à trier, et à restaurer.

Première bonne pratique: coupler la détection à une procédure de réponse. Quand une alerte remonte, vous devez savoir quoi faire, dans quel ordre. Sinon, l’alerte devient une source de stress qui s’accumule. Une procédure efficace inclut, au minimum, une conservation des preuves (ne pas modifier le serveur avant d’avoir copié l’état), une vérification des modifications, puis une restauration.

Deuxième bonne pratique: limiter ce qui peut écrire dans le périmètre. Les attaques réussissent souvent parce que l’environnement permet l’écriture au mauvais endroit. Un durcissement des permissions et une séparation stricte entre répertoire exécutable et données peuvent réduire la surface. Les checksums alors deviennent plus faciles à interpréter, car les modifications légitimes sont plus rares.

Troisième bonne pratique: tracer les déploiements. Si vous associez “changement de code” à une date, une ticket, un nom de version, vous éliminez une grosse part du bruit. Dans les audits, j’ai vu des environnements où les checksums fonctionnent, mais l’équipe ne sait pas quoi faire quand ils sonnent, parce qu’aucune chronologie opérationnelle n’existe.

Enfin, évitez l’overconfidence. Si vous comparez uniquement quelques fichiers ou une baseline jamais validée, l’absence d’écart ne prouve pas l’absence de compromission. Elle prouve seulement que ce que vous avez surveillé ne diffère pas de votre référence.
Procéder à un audit complet: méthode pragmatique
Pour un audit utile, je traite les checksums comme une boussole, puis j’aligne le reste. Voici une façon d’organiser le travail sans transformer l’analyse en projet interminable.

D’abord, je clarifie le périmètre: WordPress installé, thèmes actifs, plugins actifs, et ce que vous tenez comme “code” à surveiller. Je vérifie aussi si des mises à jour sont prévues à court terme, sinon vous aurez une vague d’écarts et vous perdrez le fil.

Ensuite, je sélectionne la référence. Si vous avez une sauvegarde “saine”, c’est idéal. Sinon, on part d’une version contrôlée issue d’un package de déploiement, et on accepte que la confiance soit moins forte qu’une sauvegarde d’état bon.

Puis, je calcule les checksums sur le serveur, en excluant ce qui change naturellement. Je génère un état horodaté et je le conserve dans un emplacement non exposé.

Ensuite, je compare et je trie par chemin. Les fichiers modifiés qui touchent le code des thèmes et plugins, ou le noyau, deviennent une priorité. Je fais ensuite une diff pour comprendre la nature de l’altération, pas seulement constater qu’elle existe.

Enfin, je décide d’une réponse: restauration depuis une référence propre, nettoyage ciblé, ou analyse plus profonde si la nature de l’attaque dépasse l’hypothèse initiale.

Quand on a besoin d’aller plus loin, les checksums jouent un rôle de “filtre”. Ils indiquent où regarder, et ils évitent de se perdre à auditer tout le site au même niveau d’attention.
Checklist rapide avant de lancer l’analyse vérifier l’existence d’une baseline acceptable (sauvegarde propre ou source de package maîtrisée) définir clairement ce qui est inclus et ce qui est exclu (code, configuration, données variables) choisir un algorithme cohérent (typiquement SHA-256) et un format de sortie stable stocker les résultats et les preuves hors du périmètre web planifier la réponse aux alertes pour éviter de laisser un incident sans action Gérer les faux positifs et les cas limites
Il y a des cas qui provoquent des écarts même quand personne n’a “cassé” le site. Les plus fréquents sont liés à la gestion du cycle de vie du site.

Un exemple simple: un fichier de cache généré par un plugin ou par la configuration serveur ne devrait pas être dans votre baseline, sinon vous aurez des alertes à répétition. Je préfère exclure ce type de contenu, ou à minima ne pas l’utiliser comme critère d’alerte, même si vous pouvez le surveiller en mode “observation”.

Autre cas: les fichiers de langues, caches de traduction, ou assets construits par un pipeline. Si vous avez un processus de build côté serveur, la checksum changera sans qu’on soit dans un incident. Là, il faut aligner la baseline sur l’état après build.

Cas plus subtil: les mises à jour de sécurité et les modifications automatiques. Si WordPress ou un plugin met à jour automatiquement, votre référence devient obsolète. La comparaison redeviendra utile seulement après avoir mis à jour la baseline ou documenté la fenêtre de changement.

Le dernier cas, plus inquiétant, est l’écart qui ne correspond à aucune action. Dans ce cas, je classe l’incident selon le type de fichier et la nature des modifications. Cela mène à une décision, parfois rapide.

Voici comment je traite les scénarios typiques lors de la phase de tri.
modification d’un plugin ou thème qui vient juste d’être mis à jour: vérifier la traçabilité du déploiement, sinon investiguer modification d’un fichier du noyau sans mise à jour planifiée: traiter comme alerte haute priorité ajout de fichiers PHP dans un répertoire inattendu: investiguer le contenu et la chaîne d’exécution impossibilité de lire certains fichiers pendant le calcul: vérifier permissions, redirections, ou sabotage possible Ce que la checksum ne dit pas (et comment compléter)
Il est important d’être honnête sur les limites. Une checksum ne vous dit pas pourquoi le fichier a changé, ni si le changement est malveillant ou bénin. Elle vous donne une preuve de différence de contenu.

Pour dépasser cette limite, vous avez besoin d’outils complémentaires:
la diff entre l’ancien et le nouveau fichier, pour comprendre la nature du changement l’examen du contexte d’exécution, comment et quand le fichier est appelé l’analyse des logs web et des événements applicatifs quand ils existent encore la vérification des permissions et des modifications sur les fichiers voisins une inspection des mécanismes de persistance possibles (plans cron, variations de hooks, fichiers de configuration modifiés)
Dans un audit mené correctement, les checksums ne sont pas une fin. Ils accélèrent la partie la plus coûteuse: localiser une modification suspecte sans regarder chaque recoin.
Automatiser la surveillance sans se tuer à la tâche
La surveillance de l’intégrité peut devenir un travail constant si elle n’est pas calibrée. Le bon compromis consiste à automatiser les calculs, mais à déclencher une analyse profonde seulement sur des changements “critiques”.

Une approche réaliste consiste à:

1) calculer régulièrement les checksums sur le périmètre code 2) comparer automatiquement avec la baseline 3) envoyer une alerte quand il y a des écarts dans des chemins prioritaires 4) laisser à l’équipe la décision sur la restauration ou l’investigation

Le calibration est tout. Si vous alertez sur des fichiers trop larges, vous créez une lassitude. Si vous n’alertez sur rien, vous perdez l’intérêt. L’objectif est d’obtenir des alertes peu fréquentes, mais significatives.

À mon sens, une surveillance utile se mesure au comportement de l’équipe, pas au nombre d’alertes. Si vous constatez que l’équipe commence à ignorer les notifications parce qu’elles arrivent “trop souvent”, c’est un signal de mauvais périmètre ou de baseline trop fragile.
Restaurer après détection: l’étape la plus importante
Quand vous identifiez des fichiers modifiés, la restauration est souvent la meilleure option, surtout si la compromission est plausible. Là aussi, les checksums guident la restauration, parce qu’ils vous indiquent précisément quels fichiers sont différents.

Le risque, c’est de “nettoyer au feeling” sans revenir à une source saine. Sur un site déjà compromis, nettoyer un fichier isolé peut ne pas suffire si l’attaque a déposé d’autres éléments, ou si une persistance existe ailleurs.

La restauration propre implique souvent de reprendre le noyau, les thèmes et les plugins depuis une source fiable, puis de réappliquer une configuration contrôlée. Ensuite, on recalcule les checksums pour confirmer que l’état correspond à la référence.

Les bases de restauration peuvent être:
une sauvegarde prise avant l’incident un package de déploiement maîtrisé une source officielle pour les composants qui doivent être identiques
Le bon réflexe en audit est de considérer la base de référence comme une pièce à conviction, et non comme une simple donnée. La revalidation après restauration rassure, et réduit le risque de rester avec une compromission résiduelle.
En pratique: construire votre stratégie d’intégrité
Si je devais résumer la logique, elle tient en une phrase: les checksums transforment un doute en comparaison, et une comparaison en décision.

Mais la décision dépend de votre maturité opérationnelle. Un site bien documenté, avec une baseline fiable et une discipline de déploiement, transformera les checksums en outil de maîtrise. Un site sans chronologie, avec des exclusions floues et des références incertaines, les verra surtout comme une machine à signaler.

Le bon plan consiste à démarrer petit mais solide. Choisissez un périmètre réaliste, calculez une baseline crédible, mettez en place une comparaison périodique, et utilisez le résultat pour déclencher une procédure d’action. Une fois que le processus “fonctionne” côté équipe, vous élargissez graduellement, pour inclure plus de chemins et plus de catégories de fichiers.

C’est souvent ce qui sépare un audit ponctuel d’une sécurisation durable. Les checksums ne font pas tout, mais ils donnent un langage commun entre sécurité, exploitation et maintenance, un langage basé sur ce qui est réellement sur le disque. Et quand l’objectif est de sécuriser WordPress, cette précision change vraiment la donne.

Si vous voulez, décrivez votre configuration (hébergement, taille du site, méthode de déploiement, accès serveur ou non) et le périmètre que vous souhaitez surveiller, je peux vous proposer une stratégie d’inclusion et d’exclusion cohérente, avec une cadence réaliste et des critères d’alerte adaptés.