Sécurisation WordPress : installer un moniteur d’intégrité (FIM)

Quand on parle de sécurisation WordPress, on pense tout de suite aux mots de passe, à l’authentification forte, aux pare-feu, et aux mises à jour. C’est normal, ce sont les leviers les plus visibles. Pourtant, il y a un autre angle mort qui revient très souvent sur le terrain : la détection tardive d’un changement dans les fichiers. Un plugin compromis, un script glissé dans le thème, une modification silencieuse de wp-config.php ou un fichier PHP ajouté dans un dossier inattendu. Si personne ne surveille l’intégrité, on finit par découvrir le problème au moment où les conséquences explosent, souvent bien après.

Le FIM, File Integrity Monitoring, sert précisément à ça : repérer les changements non attendus sur les fichiers. Installer un moniteur d’intégrité, ce n’est pas “une couche de plus” au hasard. C’est mettre en place une base opérationnelle pour savoir, rapidement, si un fichier a bougé, quoi, et si la modification ressemble à une mise à jour normale ou à une dérive.

Dans cet article, je vais te guider pas à pas pour installer un FIM dans un contexte WordPress, en m’appuyant sur une approche réaliste côté hébergement serveur. L’exemple concret sera celui de Wazuh, qui inclut un module FIM. Si tu utilises une autre stack (AIDE, OSSEC, Tripwire), la logique de fond reste la même, et tu pourras adapter.

Ce que fait vraiment un FIM (et ce qu’il ne fait pas)

Un FIM ne “désinfecte” pas. Il ne supprime pas un fichier malveillant, il ne neutralise pas un exploit en cours. Son rôle est plus simple, et plus précieux : constater des changements, les comparer à un état de référence, puis alerter.

Concrètement, tu obtiens des signaux du type :

un fichier PHP a été modifié, un nouveau fichier a été créé, les permissions ont changé, l’empreinte (hash) d’un fichier ne correspond plus au référentiel.

La partie délicate, et celle qui fait la différence entre un FIM utile et un FIM bruyant, c’est la définition de ce que tu considères comme “normal”. WordPress vit au rythme des mises à jour. Les plugins écrivent dans wp-content. Les cacheurs et optimisateurs génèrent des fichiers. Les systèmes de déploiement ajoutent des archives, puis les nettoient. Si tu surveilles trop large sans exclusions, tu vas recevoir des alertes à chaque routine.

Mon conseil issu des déploiements que j’ai accompagnés : pense le FIM comme un outil d’enquête, pas comme un système qui doit être parfait dès le premier jour. La qualité du paramétrage fait la moitié du succès.

Choisir l’outil : Wazuh, OSSEC, AIDE, et les compromis

Il existe plusieurs solutions FIM, souvent installées “côté serveur” (car c’est là que les fichiers sont réellement présents). Wazuh et OSSEC sont historiquement liés à l’approche agent. AIDE est plutôt un outil de comparaison périodique entre une base d’empreintes et l’état actuel.

Sur WordPress, la pratique change un peu selon ton environnement :

Si tu as accès au serveur, avec une machine ou un conteneur Linux, l’approche agent est très confortable, car tu peux remonter des alertes de manière centralisée. Si tu es en hébergement mutualisé, tu as parfois des accès limités, et le FIM peut être plus difficile à installer. Dans ce cas, la faisabilité dépend vraiment du panel et des possibilités de logs. Si tu gères déjà un SIEM, tu peux préférer un outil qui s’intègre naturellement à tes flux d’alertes.

Wazuh ressort souvent car il regroupe plusieurs fonctions de sécurité, dont le FIM. Mais je ne te vends pas une vérité universelle. Le bon choix dépend de ton contexte d’exploitation, du niveau d’automatisation souhaité, et du volume de fichiers à surveiller.

Dans la suite, je pars du principe que tu peux installer un agent sur la machine qui héberge WordPress ou sur un hôte qui voit les fichiers de ton site.

Préparer WordPress pour que le FIM soit fiable

Avant même d’installer l’agent, j’aime faire un petit “mise en ordre” côté WordPress et déploiement. Sinon, tu vas te retrouver à apprendre par douleur.

Le point central, c’est l’état de référence. Le FIM a besoin d’une base d’empreintes. Tu veux que cette base corresponde à un WordPress sain, ou au moins à un état acceptable pour démarrer.

Sur un site en production, la tentation est de lancer le FIM tout de suite. Parfois c’est OK. Souvent, je recommande plutôt une fenêtre de maintenance courte, le temps de :

confirmer que WordPress et les plugins actifs sont à jour, désactiver temporairement tout plugin qui écrit en masse dans wp-content pendant la fenêtre, s’il y a un risque de bruit, vérifier qu’il n’y a pas de fichiers “bizarres” récemment ajoutés.

Même si tu ne fais pas un audit complet, quelques contrôles rapides évitent des mois de chasse aux faux positifs.

Ce que je vérifie avant de démarrer (checklist)

https://gardewp.fr/securite-wordpress/

WordPress est à une version attendue, et les plugins critiques sont à jour wp-config.php est accessible mais pas “modifiable par hasard” (droits cohérents) Tu as un inventaire des chemins à surveiller, notamment wp-content et les fichiers PHP clés Tu sais comment se passe ton déploiement (FTP, CI/CD, rsync), pour éviter d’alerter sur chaque livraison Tu as une procédure simple pour gérer les alertes (qui regarde, comment confirmer, quoi faire ensuite)

Cette checklist ne prend pas dix minutes, mais elle te fait gagner beaucoup d’heures ensuite.

Installer un moniteur d’intégrité avec Wazuh (principe général)

Je ne peux pas te donner une commande unique parfaite pour chaque distro et chaque architecture, car les chemins, paquets, et méthode d’installation varient. L’idée est donc de décrire le processus de façon “opérationnelle”, et de te laisser adapter à ton système.

Tu as deux briques :

Le moteur Wazuh côté serveur (souvent appelé manager) L’agent Wazuh côté hôte où résident tes fichiers WordPress

Une fois l’agent installé, tu configures le module FIM pour surveiller des répertoires et des fichiers précis.

Sur le plan mental, pense à ça comme à un triptyque :

un référentiel d’état (la “base” initiale), une liste de chemins surveillés, une règle d’alertes qui déclenche quand un changement est détecté.

Où installer l’agent

Idéalement, l’agent doit tourner sur la machine où se trouvent réellement les fichiers que tu veux protéger. Si ton site tourne sur plusieurs nœuds, tu surveilles chaque nœud ou tu centralises au bon endroit.

Si tu utilises un reverse proxy devant des serveurs applicatifs, tu ne veux pas surveiller seulement le proxy si les fichiers WordPress sont ailleurs.

Configurer le FIM pour WordPress, sans noyer l’équipe

La configuration est le cœur du sujet. Sur WordPress, le piège, ce n’est pas “ne pas surveiller”, c’est “surveiller trop”.

Quels chemins surveiller en priorité

En général, les dossiers et fichiers suivants sont de bons candidats, car ils portent la logique et les points d’injection courants :

le code applicatif, en particulier wp-includes et les fichiers PHP à la racine, wp-content, qui contient thèmes, plugins, et souvent les fichiers modifiés, wp-config.php et toute configuration sensible.

Par contre, certains contenus de wp-content changent constamment. Le plus fréquent, ce sont les uploads et les fichiers générés, surtout si tu as des optimisateurs d’images ou des systèmes de cache qui produisent des artefacts.

Si tu surveilles absolument tout, tu verras apparaître :

des modifications d’empreintes après chaque traitement d’image, des créations de fichiers à cause des jobs planifiés, des changements liés au cache.

Tu peux surveiller les uploads de manière plus intelligente, ou au moins exclure les types de changements que tu considères comme “normaux”. C’est là que tu dois faire des choix en fonction de ton exploitation.

Un exemple de logique de ciblage

Sans entrer dans un fichier de configuration “copier-coller” qui pourrait être faux pour ton setup, je peux te décrire la logique qui marche bien :

Surveiller les fichiers PHP et les scripts dans les zones de code, y compris les thèmes et plugins. Surveiller les fichiers de configuration sensibles. Exclure les sous-dossiers qui ne devraient pas être modifiés “à l’attaque”, ou qui changent trop souvent (cache, uploads si tu veux éviter le bruit). Réserver les alertes les plus strictes aux chemins qui, en théorie, ne changent que lors d’une mise à jour ou d’un déploiement.

Dans l’expérience, le meilleur équilibre est souvent : alerter sur “code et config”, moins sur “contenu média” sauf si tu as une raison spécifique de le surveiller.

Faire cohabiter FIM et déploiement : éviter l’alerte à chaque release

Le FIM peut devenir ingérable si ton processus de déploiement n’est pas aligné. Une modification de plugin, une mise à jour automatique, un déploiement via CI, tout ça peut déclencher des alertes.

Il existe plusieurs stratégies, et tu choisis selon ton niveau d’automatisation.

Une approche fréquente consiste à :

lancer une “fenêtre d’événement” pendant laquelle les changements attendus sont connus et traités, puis vérifier les alertes qui tombent après coup, car certaines modifications ne sont pas censées apparaître.

Autre stratégie : mieux paramétrer les chemins. Si ton déploiement écrit uniquement dans wp-content/plugins et wp-content/themes, tu réduis la surface de surveillance au lieu de surveiller tout en permanence.

L’important, c’est de ne pas te retrouver dans une situation où l’équipe désactive le FIM parce que ça génère trop de bruit. Un FIM “calme” est plus utile qu’un FIM hyper bruyant.

Réception et exploitation des alertes : comment je m’y prends

Une alerte FIM doit être actionnable. Sinon, elle s’accumule et finit dans le même dossier que les rapports que personne n’ouvre.

Quand une alerte remonte, je cherche d’abord des informations simples :

quel fichier a changé, quel type de changement est indiqué (modification, création, changement de permissions), à quelle heure ça arrive, si ça colle à un événement attendu (mise à jour plugin, déploiement, job cron).

Sur un WordPress “normal”, tu peux souvent corréler avec :

l’horodatage de ton pipeline CI/CD, les logs de mise à jour WordPress, les activités planifiées (optimisation images, génération de cache).

Si la modification ne colle à rien, là tu bascules en mode enquête.

Conduite pratique en cas d’alerte

Je ne vais pas te donner une méthode universelle, mais voici une logique pragmatique qui fonctionne bien :

vérifier si le chemin concerné est un fichier réellement “code” ou une zone très volatile, comparer l’état actuel au référentiel attendu (ou à un hash stocké), regarder le contenu de la différence si possible, surtout pour les fichiers PHP, si tu suspectes un compromettement, isoler (désactiver plugin suspect, mettre le site en mode restreint, fermer l’accès admin si nécessaire), puis lancer une remédiation.

Le point crucial : ne pas tenter de “résoudre” à l’aveugle en écrasant un fichier sans comprendre d’où vient la modification. Dans certains cas, le fichier a changé parce que quelqu’un l’a mis à jour. Dans d’autres, il a changé parce que le site a été compromis, et écraser va masquer l’origine.

Latence, performance, et faux positifs : les limites à accepter

Le FIM consomme des ressources. Ça ne se traduit pas toujours par un “gros CPU”, mais tu peux voir :

des pics lors du scan initial, une hausse de consommation lors des événements, une augmentation du volume de logs si le périmètre est trop large.

Sur des sites à fort trafic, le risque est moins l’impact direct sur le CPU applicatif, car c’est l’agent qui observe les fichiers. Mais si l’agent et le stockage sont sur la même machine que le site et que ton système est déjà chargé, il faut surveiller la courbe.

Les faux positifs sont l’autre réalité. WordPress n’est pas immobile. Les caches, les optimiseurs d’images, les plugins SEO, certains plugins de sécurité eux-mêmes écrivent des fichiers. Résultat : l’objectif n’est pas “zéro alerte”, mais “moins d’alertes inutiles, plus d’alertes exploitables”.

Avec le temps, tu affines :

tu ajustes les exclusions, tu raffines les chemins ciblés, tu ajoutes des règles si l’outil le permet, par exemple pour des types de changements attendus.

Cette phase d’apprentissage est normale. Si tu essaies de viser la perfection du premier coup, tu te décourageras.

Cas particulier : WordPress sur containers, ou volumes partagés

Quand WordPress tourne dans des containers, la surveillance devient subtile.

Deux situations reviennent souvent :

Le code WordPress est dans un volume monté, et l’agent voit bien ces fichiers. Dans ce cas, la configuration est similaire, tu surveilles le volume. Le code est recréé à chaque déploiement, et tu as des “diffs” attendus à chaque restart. Là, tu dois soit surveiller seulement les éléments stables, soit corréler avec le cycle de déploiement.

Si tu as un orchestrateur, tu peux aussi décider d’intégrer le FIM dans l’approche “infrastructure”. Autrement dit, ton référentiel d’état peut être aligné avec l’image déployée plutôt qu’avec l’état dynamique du filesystem. C’est souvent plus propre, mais ça demande une discipline dans le build et le versioning.

Vérifier que le FIM marche vraiment : tester sans casser la prod

Un FIM qui n’a jamais déclenché d’alerte est un pari. Le bon réflexe est de tester en conditions maîtrisées.

Le test le plus simple, c’est de provoquer un changement “légitime” sur un fichier que tu surveilles. Par exemple, dans un environnement de staging identique, modifie un fichier PHP de thème non sensible, et vérifie que :

l’agent remonte un événement, l’alerte arrive dans la console prévue, tu peux tracer le chemin et l’horodatage.

Une fois que tu sais que l’enchaînement est bon, tu répètes sur un périmètre plus proche de la prod, avec des changements minimaux.

Je conseille aussi de vérifier le scan initial. C’est souvent là que se cache le vrai souci : si la base de référence n’est pas prise au bon moment, tes alertes futures peuvent devenir confuses.

Et si tu n’as pas accès au serveur ?

C’est une question fréquente. Sur certains hébergements mutualisés, l’installation d’un agent FIM n’est pas envisageable.

Dans ce contexte, tu peux quand même obtenir une partie de la valeur du FIM avec des approches alternatives :

des plugins qui comparent des empreintes côté WordPress, des tâches planifiées qui calculent des hashes sur certains fichiers, une vérification périodique des fichiers de code.

Je reste prudent sur ce point : plus tu es “dans WordPress”, plus tu dépends de l’état applicatif. Si le site est compromis, l’outil qui tourne dans WordPress peut être contourné. Un FIM au niveau serveur ou via un agent séparé a l’avantage d’être plus difficile à neutraliser de l’intérieur.

Autrement dit, si tu peux, privilégie un contrôle en dehors du runtime WordPress.

Exemple de paramétrage réfléchi, sans tomber dans l’overkill

Pour rendre la logique plus concrète, voici un exemple de choix de configuration que j’ai vu fonctionner, surtout sur des sites marketing avec quelques plugins, pas une usine à plugins :

Surveiller strictement les fichiers PHP des thèmes et plugins actifs. Surveiller wp-config.php et les fichiers de la racine. Exclure les dossiers d’uploads si ton besoin n’est pas de détecter des changements de médias. Conserver une surveillance sur wp-content mais en réduisant la granularité sur les zones très volatiles.

Ensuite, tu observes sur deux à quatre semaines. Si tu reçois des alertes sur des chemins qui correspondent à des actions attendues (optimisation images, cache, génération de fichiers), tu ajustes.

Ce pilotage progressif est ce qui rend un FIM durable. Un paramétrage trop agressif dès le départ finit souvent en “alerte fatigue”.

Mini check de qualité après déploiement

Les alertes arrivent dans un délai raisonnable après un changement Les changements attendus (mises à jour, déploiements) ne génèrent pas un flot d’alertes Les changements suspects dans les fichiers de code remontent bien Les exclusions réduisent le bruit, sans aveugler les zones critiques Tu as une procédure d’escalade claire (qui vérifie, qui confirme, quel temps de réponse)

Sécurisation WordPress : le FIM s’intègre à un dispositif, pas en solo

Un moniteur d’intégrité ne remplace pas :

la gestion des identifiants, MFA, et politiques d’accès, les mises à jour contrôlées, la durcification (permissions, désactivation des écrans inutiles, moindre privilège), la réduction de l’exposition (limiter les plugins, isoler l’admin, durcir la surface réseau).

Le FIM ajoute une couche de preuve et d’horodatage. C’est souvent ce qui te permet de répondre à des questions simples en incident : “quand”, “quoi”, “où”. Et quand tu as déjà ces réponses, les décisions de remédiation deviennent plus rationnelles.

Si tu dois retenir une idée : un FIM bien configuré te donne un avantage opérationnel. Tu ne te bases plus sur des suppositions, tu enquêtes à partir de faits.

Prochaines étapes concrètes

Si tu veux passer à l’action sans te perdre dans une installation abstraite, je te propose une trajectoire courte :

D’abord, définis précisément ton périmètre WordPress, code et configuration d’un côté, médias et caches de l’autre. Ensuite, installe un agent FIM au bon endroit, puis crée la référence initiale quand le site est sain. Enfin, observe, ajuste les exclusions, et teste sur staging.

C’est là que la sécurisation WordPress devient vraiment efficace. Pas parce que tu as ajouté une “tech” supplémentaire, mais parce que tu as rendu la détection de modification exploitable par des humains, avec du contexte.

Si tu me dis ton environnement (hébergement, distribution Linux, si c’est bare metal, VM ou container, et ta méthode de déploiement), je peux te proposer une configuration de chemins et d’exclusions plus adaptée à ton cas, sans chercher à tout surveiller au maximum.