Table des matières de l'article :
Lorsqu'on aborde la sécurité des systèmes de gestion de contenu (CMS), on se concentre presque toujours sur les mises à jour, les plugins vulnérables, les mots de passe, les pare-feu applicatifs et les sauvegardes. Ce sont des aspects fondamentaux, mais il existe un niveau inférieur, souvent négligé, qui peut contribuer de manière significative à atténuer les attaques : le système de fichiers.
Cette discussion générale s'applique, avec quelques différences, aux CMS dynamiques tels que Magento , PrestaShop , Drupal , Joomla et, bien sûr, WordPress . Dans cet article, nous nous concentrerons sur WordPress en raison de son utilisation répandue et parce que, précisément pour cette raison, il est l'une des cibles les plus fréquentes des attaques automatisées, des bots et des campagnes de compromission massives.
Le principe de base est simple : un site dynamique doit pouvoir lire de nombreux fichiers, en écrire dans certains et parcourir les répertoires pour fonctionner correctement. Cela ne signifie pas pour autant que l’ensemble de l’installation doive être systématiquement modifiable. Tous les fichiers n’ont pas besoin d’être accessibles en écriture, tous les chemins d’accès n’ont pas besoin d’offrir le même niveau de liberté, et tous les répertoires n’ont pas besoin d’autoriser les modifications en dehors des périodes de maintenance.
Lorsqu'une faille de sécurité écrit dans WordPress
De nombreuses attaques WordPress ne se contentent pas d'exploiter temporairement une vulnérabilité. Elles visent souvent à assurer une présence durable : elles créent de nouveaux fichiers, modifient des fichiers existants, injectent du code dans un thème, altèrent un plugin ou placent un shell web dans un répertoire accessible via le web.
Cela se produit car de nombreuses installations sont laissées, par commodité, dans un état trop permissif. WordPress doit pouvoir mettre à jour les extensions et les thèmes, télécharger des images, générer du cache et parfois modifier des fichiers tels que… .htaccessDe ce besoin légitime naît cependant une habitude dangereuse : celle de traiter l’ensemble de l’installation comme si elle était toujours accessible en écriture.
Si une faille de sécurité peut exécuter du code dans le contexte de l'utilisateur ou du processus web, elle tentera d'exploiter cette capacité . Si elle découvre des répertoires modifiables et des fichiers pouvant être réécrits, elle peut installer des portes dérobées ou altérer des composants légitimes. Cependant, si certaines zones critiques sont protégées et inaltérables en fonctionnement normal, une part importante de l'attaque est considérablement complexifiée.
Tout n'a pas besoin d'être écrit
Un exemple flagrant est le répertoire des plugins. Un site WordPress n'en a pas besoin. wp-content/plugins Ce fichier doit être accessible en écriture en permanence. Cela doit être le cas lors de l'installation, de la mise à jour ou de la suppression d'un plugin. Mais entre deux mises à jour, notamment sur un site de production géré par des professionnels, ces fichiers peuvent rester statiques.
Le même raisonnement s'applique à de nombreux fichiers principaux, éléments du thème actif, fichiers de configuration et composants qui ne doivent pas être modifiés en dehors des opérations de maintenance planifiées. À l'inverse, des répertoires comme wp-content/uploads Leurs besoins sont différents : ils doivent permettre le chargement de médias, mais précisément parce qu'ils sont inscriptibles, ils doivent être traités avec précaution et ne pas devenir un lieu propice à l'exécution de code malveillant.
La sécurité ne doit donc pas être perçue simplement comme une distinction entre « autorisé » et « interdit », mais comme une séparation plus précise entre ce qui doit être lu, ce qui doit être écrit et ce qui doit rester intact.
Cette distinction concerne également la notion d'exécution. Sous Linux, le bit d'exécution sur les répertoires est aussi utilisé pour les parcourir ; il ne faut donc pas l'interpréter superficiellement. Cependant, du point de vue de l'application, tous les chemins contenant des fichiers téléchargés ou générés par le CMS ne devraient pas être autorisés à l'exécution de code. Une zone de téléchargement, par exemple, devrait être conçue pour stocker du contenu, et non pour héberger des scripts PHP prêts à être appelés par le navigateur.
Que fait chattr +i ?
Sous Linux, en plus des permissions classiques gérées avec chmod e chown, il existe des attributs du système de fichiers qui peuvent être gérés via chattrParmi ces attributs, le plus intéressant du point de vue du durcissement est : +i, c'est-à-dire l'attribut d'immuabilité.
Lorsqu'un fichier est marqué comme immuable, il ne peut être ni modifié, ni supprimé, ni renommé, ni ouvert en écriture tant que cet attribut n'est pas supprimé par une personne autorisée. Cela ne revient donc pas à simplement supprimer l'autorisation d'écriture. chmod: est une contrainte plus forte, appliquée au niveau du système de fichiers.
En substance, les commandes sont les suivantes :
chattr +i file-o-directory chattr -i file-o-directory lsattr file-o-directory
chattr +i appliquer l'immuabilité, chattr -i le supprime, tandis que lsattr Cela vous permet de vérifier les attributs existants. Bien entendu, ces commandes ne doivent pas être appliquées sans discernement à l'ensemble de l'installation. Un CMS doit pouvoir continuer à écrire là où c'est nécessaire : le cache, le chargement, les journaux et autres chemins dynamiques ne peuvent être bloqués sans une évaluation minutieuse.
Pourquoi est-il si peu utilisé ?
Bien qu'il s'agisse d'un outil puissant, chattr +i Cette pratique est rarement utilisée dans l'hébergement web traditionnel (voire jamais), et une simple recherche Google vous confirmera que nous sommes probablement les seuls à en parler. La première raison est d'ordre culturel : de nombreux guides de sécurité pour les CMS se limitent aux permissions standard, aux plugins de sécurité ou aux règles du serveur web. L'immuabilité des systèmes de fichiers est un sujet plus proche de l'architecture système Linux que de la gestion standard de WordPress.
La seconde raison est d'ordre opérationnel. Si vous rendez immuable un fichier nécessitant une mise à jour, celle-ci échouera. Si vous verrouillez le mauvais répertoire, le CMS risque de ne plus pouvoir générer de cache, téléverser de fichiers ou effectuer la maintenance. Cette technique requiert donc une méthode, une documentation et des procédures claires.
La troisième raison concerne les panneaux de contrôle. Plesk, cPanel et DirectAdmin simplifient la gestion des domaines, des fichiers, des bases de données, des e-mails et des certificats, mais ils n'ont pas fait de l'immuabilité du système de fichiers un modèle standard de sécurisation des applications pour les CMS. Certains documentent l'attribut immuable ou expliquent comment le désactiver en cas de problème, mais ils ne le proposent généralement pas comme une procédure standard pour sécuriser efficacement une installation WordPress.
La raison est compréhensible : un panneau de contrôle générique doit fonctionner dans de nombreux contextes, souvent avec des utilisateurs non spécialistes. Automatiser l’immuabilité sans connaître le site pourrait entraîner des interruptions. C’est précisément là qu’un hébergement géré par des professionnels apporte une réelle valeur ajoutée.
L'approche correcte : chirurgicale, et non indiscriminée
L'immuabilité ne doit pas servir de verrou universel. Le site ne doit pas être totalement figé. Au contraire, les chemins d'accès doivent être distingués selon leur fonction.
Les fichiers de configuration critiques peuvent nécessiter une protection supplémentaire. Les fichiers principaux peuvent être considérés comme statiques entre les mises à jour. Les plugins peuvent être rendus non modifiables jusqu'à la prochaine maintenance. Les répertoires de téléchargement doivent rester accessibles en écriture, mais l'exécution de code ne doit pas être autorisée. Les répertoires de cache doivent être régénérables, sans toutefois accorder une liberté excessive aux zones sensibles.
Un exemple purement conceptuel, et non une procédure universelle, pourrait être :
# Protezione di un percorso critico fuori manutenzione chattr +i percorso/critico # Sblocco controllato prima di un aggiornamento chattr -i percorso/critico # Verifica dello stato degli attributi lsattr percorso/critico
L'important n'est pas la commande elle-même, mais le processus : analyser le comportement du site, identifier ce qui doit être modifié et protéger ce qui ne doit pas l'être en fonctionnement normal.
Une couche de sécurité supplémentaire pour l'hébergement géré
En hébergement standard, le fournisseur propose un espace web, une base de données, un panneau de contrôle et des outils génériques. L'utilisateur installe le CMS, met à jour les extensions et gère son site. Dans ce modèle, il est difficile de mettre en œuvre un renforcement de sécurité véritablement ciblé, car le fournisseur ne connaît pas nécessairement le comportement spécifique du projet.
L'hébergement géré par des administrateurs système professionnels peut adopter une approche différente. Après une configuration initiale, il est possible d'identifier les chemins d'accès accessibles en écriture, ceux accessibles en lecture seule et ceux à protéger par des attributs plus restrictifs. Cela réduit la surface d'attaque et complique la tâche des logiciels malveillants souhaitant modifier les composants critiques.
La valeur ne réside pas seulement dans la performance. chattr +iMais il est essentiel de savoir où l'appliquer, quand la supprimer et comment la réintégrer aux processus de mise à jour. L'immuabilité doit coexister avec la maintenance : d'abord le déverrouillage, puis la mise à jour, la vérification du site et enfin le rétablissement de la protection.
Des limites à ne pas ignorer
L'attribut immuable n'est pas une solution miracle. Il ne remplace ni les mises à jour, ni les sauvegardes, ni l'isolation des utilisateurs, ni l'analyse antivirus, ni la surveillance, ni les pare-feu applicatifs web (WAF), ni les politiques d'accès robustes. De plus, si un attaquant obtient des privilèges élevés sur le serveur, il peut être en mesure de supprimer cet attribut, selon le contexte et les capacités disponibles.
Cependant, elle demeure une mesure très intéressante contre une catégorie courante d'attaques : celles qui, après avoir exploité une vulnérabilité du CMS ou d'un plugin, tentent d'écrire ou de modifier des fichiers au sein de l'installation web. Dans ces cas, limiter l'accès en écriture aux chemins critiques peut faire une réelle différence.
conclusion
Renforcer la sécurité d'un CMS implique également de ne plus considérer le système de fichiers comme un simple conteneur. Chaque fichier et répertoire a une fonction différente. Certains chemins doivent être dynamiques, d'autres doivent rester stables, et d'autres encore ne doivent être modifiés que lors de opérations de maintenance contrôlées.
Dans le cas de WordPress, mais aussi de Magento, PrestaShop, Drupal et Joomla, l'attribut d'immuabilité du système de fichiers peut constituer une protection supplémentaire. Il ne dispense pas de la mise à jour, de la surveillance et de la sécurisation de l'application, mais il réduit considérablement le champ d'application de nombreuses attaques visant à insérer des portes dérobées ou à modifier des fichiers existants.
chattr +i Son utilisation est rare car elle requiert une expertise système et que les panneaux de contrôle généralistes ne l'intègrent généralement pas comme modèle de sécurité applicative. C'est précisément pour cette raison qu'elle peut devenir un atout majeur des hébergements gérés par des professionnels : un paramétrage initial, le mappage des chemins d'accès et une séparation précise entre la lecture, l'écriture et l'exécution permettent de transformer une installation CMS standard en un environnement plus robuste, mieux contrôlé et moins vulnérable aux attaques automatisées.
