Passer au contenu 
CloudLinux SecureLinks s'arrête Symlink- des attaques sur des serveurs partagés, en exploitant le suivi de liens symboliques non sécurisés vers Noyau-niveau. Cela me permet de protéger les fichiers sensibles, car les processus ne sont autorisés à suivre les liens que si le propriétaire du lien et celui du fichier cible sont identiques.
Points centraux
- Protection du noyau empêche le suivi des liens entre utilisateurs étrangers.
- Examen des propriétaires établit un lien étroit entre le lien symbolique et le fichier cible.
- Blocage des liens physiques Interdire les liens vers des fichiers externes.
- Hébergement partagé reste isolé et résistant.
- Simple Activation via les paramètres sysctl.
Ce qui rend les attaques par liens symboliques si dangereuses dans l'hébergement mutualisé
Une attaque par lien symbolique force Services comme Apache, PHP-FPM ou un gestionnaire de fichiers, d'ouvrir un fichier externe via un lien symbolique, ce qui a pour conséquence Comptes qui divulguent des informations à grande échelle. Dans les environnements hétérogènes comportant de nombreux comptes, j’observe souvent des structures de répertoires très denses, ce qui fait que des droits mal configurés peuvent rapidement exposer des données critiques. Les attaquants placent alors des liens vers des fichiers de configuration, des identifiants d’accès ou des éléments temporaires appartenant à d’autres utilisateurs. Sans protection, les processus suivent le chemin manipulé et lisent des contenus qu’ils ne devraient jamais voir. C’est précisément cette faille qu’une vérification rigoureuse des liens permet de combler, ce qui me permet de réduire considérablement le risque de fuite de données et de compromission involontaire des comptes.
Comment fonctionne CloudLinux SecureLinks au niveau du noyau ?
SecureLinks vérifie si système de fichiers-vérifie si le propriétaire d'un lien symbolique correspond au fichier cible et refuse l'accès si l'attribution ne correspond pas, ce qui me permet d'éviter des Sentiers un blocage fiable. Cette approche est plus profonde que les filtres d'application et complique les manœuvres malveillantes exécutées via PHP, WebDAV ou des clients FTP. Même si une application web présente des failles, le noyau conserve le contrôle sur le suivi des liens. Je tire particulièrement parti de cet avantage sur les serveurs partagés très sollicités, sur lesquels de nombreuses instances s’exécutent en parallèle. Pour une analyse plus approfondie, je renvoie à un aperçu détaillé, qui décrit la logique fondamentale et les limites de protection.
Configuration requise et compatibilité
Dans la pratique, ce qui compte avant tout pour moi, c'est la façon dont SecureLinks s'intègre aux configurations courantes. Sur les versions modernes de CloudLinux, le mécanisme fonctionne de manière stable avec ext4 et XFS; dans les environnements mixtes utilisant des systèmes de fichiers en réseau (par exemple NFS), je procède à des tests particulièrement approfondis, car les systèmes de fichiers distants présentent des sémantiques de propriété différentes selon les options d'exportation. Les couches de virtualisation telles que KVM ou VMware ne posent pas de problème, car la protection s’applique au niveau du noyau dans le système invité. Important : les anciens noyaux peuvent nommer différemment les commutateurs de liens protégés ou ne pas les prendre entièrement en charge. Je vérifie donc dès le début si les paramètres souhaités sont disponibles et si tous les services concernés (serveur web, PHP-FPM, Cron, scanner) fonctionnent sur des chemins locaux ou disposent de limites clairement définies via des options de montage.
Délimitation et interaction avec d'autres mesures de protection
SecureLinks ne fait pas concurrence à des mécanismes tels que SELinux ou AppArmor, mais vient les compléter. Alors que les politiques MAC limitent les accès en fonction du contexte, SecureLinks empêche de manière ciblée de suivre des liens „ étrangers “. Au niveau du serveur web, je mets également en place SymLinksIfOwnerMatch et désactive FollowSymLinks partout où cela s'avère pertinent. Ces politiques d'application bloquent déjà de nombreuses attaques, mais reposent sur une configuration correcte des applications. La vérification au niveau du noyau, en revanche, reste indépendante des règles vHost ou .htaccess. Au final, cela forme une chaîne robuste : CageFS isole les répertoires, SecureLinks bloque l’utilisation abusive des liens, le serveur web impose des résolutions de chemins correctes, et SELinux/AppArmor maintiennent les processus dans leurs limites.
Paramètres importants du noyau et valeurs par défaut recommandées
Dans la pratique, j'utilise des Sysctl- des commutateurs qui régulent la vérification de la propriété et la création de liens, ce qui me permet de Erreurs d'accès au niveau du système. Les paramètres fs.enforce_symlinksifowner et fs.symlinkown_gid sont particulièrement importants pour garantir strictement la correspondance des propriétaires. De plus, je limite la création de liens physiques et symboliques à l’aide d’options « protected » dédiées. Cette combinaison bloque les vecteurs d’attaque typiques dès les premières étapes du traitement des chemins d’accès. L’aperçu suivant présente les paramètres courants et leur impact au quotidien.
| Paramètres | Objectif | Valeur typique | Effet |
|---|---|---|---|
| fs.enforce_symlinksifowner | Forcer la vérification du propriétaire lors du suivi des liens symboliques | 1 | Le processus ne peut suivre les liens que si le propriétaire du lien et celui de la page de destination sont identiques. |
| fs.symlinkown_gid | Définir le GID qui contrôle le comportement strict | typique : GID du serveur web | Limitation des groupes concernés par le contrôle rigoureux |
| fs.protected_symlinks_create | Empêcher la création de liens symboliques par des utilisateurs externes | 1 | Les utilisateurs non privilégiés ne créent pas de liens symboliques vers des fichiers appartenant à d'autres propriétaires |
| fs.protected_hardlinks_create | Empêcher la création de liens physiques par des utilisateurs externes | 1 | Les contournements basés sur des liens physiques sont bloqués |
En pratique : chemins d'accès standard et sessions sécurisées
De nombreuses fuites se produisent dans les répertoires partagés. C'est pourquoi je sépare session.save_path, upload_tmp_dir et des répertoires de travail temporaires par compte. Je définis les emplacements accessibles en écriture à l'échelle mondiale avec le bit Sticky sur « strict » (chmod 1777) et installez-les si possible avec nosuid, nodev, noexec, afin qu'aucun code ne soit exécuté, même en cas d'utilisation abusive. Les applications qui utilisent des liens symboliques pour les versions (par exemple, un current -> versions/xyz), continuent de fonctionner tant que le lien et la cible appartiennent au même propriétaire. En revanche, les répertoires d’équipe, dans lesquels plusieurs utilisateurs écrivent via un groupe, posent problème ; dans ce cas, je prévois des GID dédiés et je précise pour quel GID SecureLinks effectue une vérification stricte. Je m’assure ainsi que les flux de travail légitimes ne soient pas bloqués par la vérification du propriétaire, sans pour autant compromettre la sécurité.
Étape par étape : activation et tests
Dans la pratique, je saisis les paramètres dans Sysctl- Configurez les paramètres, chargez-les avec sysctl -p et vérifiez immédiatement le Log-Comportement lors des tentatives d'accès de test. Une vérification rapide : deux utilisateurs, un fichier de test dans le compte cible, un lien symbolique dans le compte de l'attaquant – la lecture doit échouer. En parallèle, je vérifie que les workers du serveur web, les pools PHP-FPM et le gestionnaire de fichiers renvoient les refus attendus. En cas de fausses alertes, j’examine les affectations de GID et les identités de processus, car des groupes incorrects peuvent fausser la correspondance. Ce n’est que lorsque les tests s’avèrent reproductibles que j’étends le paramètre à plus grande échelle.
Stratégie de déploiement et plan de secours
Je n'active jamais SecureLinks d'un seul coup („ Big Bang “), mais de manière progressive : d'abord dans le Mode audit (uniquement analyse des journaux, si disponible) ou dans des environnements de test, puis sur certains nœuds de production sélectionnés, avec une surveillance étroite. En cas d'anomalies, je peux, via sysctl -w J'ajuste les commutateurs en temps réel et, si nécessaire, je reviens rapidement en arrière. En parallèle, je répertorie les chemins d'accès et les GID concernés afin de pouvoir définir des exceptions claires. La gestion de la configuration (par exemple via Ansible) garantit que les valeurs par défaut identiques sont appliquées partout et évite toute dérive. Pendant les fenêtres de maintenance, je prévois de brefs redémarrages de l’application afin d’assurer la prise en charge des changements de groupe au niveau des processus de travail.
Interaction avec CageFS et l'isolation des sites
SecureLinks empêche Utilisation abusive des liens, alors que CageFS isole les répertoires par compte, ce qui me permet d'avoir plusieurs Couches Assurer la sécurité. Cette combinaison réduit considérablement les mouvements latéraux dans les configurations multi-utilisateurs. Je mets d'abord l'isolation, puis la protection des liens, afin que les deux niveaux s'appliquent correctement. Pour plus de détails sur l'encapsulation du système de fichiers, consultez l'introduction concise sur la Isolation CageFS. Par ailleurs, je limite autant que possible les droits des utilisateurs et les gestionnaires PHP.
Erreurs de configuration courantes et comment les éviter
Les erreurs les plus fréquentes concernent des Groupes- les identifiants, les structures de propriété floues dans les déploiements et les incohérences Symlink-Cibles dans les scripts. Je vérifie donc avant l'activation si le serveur web et les pools PHP fonctionnent avec les GID attendus. Les processus de compilation ou de mise en production ne doivent pas créer de liens entre les comptes utilisateurs. De plus, je vérifie que les outils de sauvegarde et les scanners de logiciels malveillants sont autorisés à poursuivre leurs accès légitimes. Une stratégie claire de gestion des propriétaires de fichiers permet d'éviter des problèmes ultérieurs lors du dépannage.
Guide de dépannage et commandes de diagnostic
Quand je rencontre un problème, je m'appuie sur des vérifications reproductibles. Avec namei -lx /chemin/vers/le/lien j'ai une vue d'ensemble de toute la chaîne de liquidation, y compris les structures de propriété. stat me fournit le propriétaire et le mode du lien et de la cible. Via ps -o utilisateur,groupe,commande -p PID Je vérifie sous quelle identité un processus s'exécute réellement ; les divergences entre les processus parents et les processus enfants sont souvent source de surprises. Je repère les messages du noyau dans dmesg ou dans le journal ; les entrées « Deny » contiennent généralement le chemin d'accès et les identifiants UID/GID, ce qui facilite l'association avec le compte. Pour une analyse plus approfondie, j'intègre auditd et enregistre les appels système liés au système de fichiers concernant les chemins d'accès concernés, afin de distinguer les fausses alertes des véritables tentatives d'attaque.
Aspects liés aux performances et à la compatibilité
Le supplément Vérifier pour les propriétaires, cela n'entraîne que des coûts minimes, qui sont à peine perceptibles par rapport au gain en matière de sécurité dans Baisse de charge. Dans les environnements très fréquentés, j'observe des latences faiblement et régulièrement stables. Il reste toutefois important de tester les charges de travail spécifiques qui utilisent délibérément des répertoires partagés. Pour une sélectivité accrue, je m’appuie sur des concepts d’hôtes qui séparent encore plus clairement les instances du site ; l’article consacré à ce sujet rassemble des informations à ce sujet : Avantages de l'isolation des sites. Les problèmes de compatibilité sont généralement dus uniquement à d'anciens scripts qui s'appuient sur des liens non sécurisés.
Surveillance, journalisation et réponse aux incidents
Une fois le déploiement effectué, je vais relier Noyau- des journaux avec des règles SIEM, afin que les rejets lors du suivi des liens soient immédiatement visibles, ce qui Attaques permet de les détecter rapidement. Les indicateurs pertinents sont le nombre d'accès par lien rejetés par compte, la fréquence par processus et la plage horaire. Les valeurs aberrantes indiquent des tentatives d'exploitation ou des déploiements défectueux. Pour la réaction, les playbooks ont fait leurs preuves : bloquer brièvement le compte, sauvegarder les artefacts, analyser les chemins d’accès, corriger les droits. Enfin, je documente la cause et j’ajuste les configurations afin que ce schéma ne se reproduise pas.
Intégration dans cPanel, Plesk et les piles courantes
Dans le cadre de l'hébergement au quotidien, les serveurs Web, PHP et les services auxiliaires fonctionnent souvent avec leurs propres comptes utilisateurs (apache, nginx, lshttpd) et les identifiants de pool par groupe. Je définis les fs.symlinkown_gid à tel point que l'utilisateur du serveur web et les workers FPM des clients sont soumis à cette vérification stricte. Avec le PHP-FPM par utilisateur ou le LSAPI par compte, les conflits sont rares, car les workers s'exécutent de toute façon sous le compte client correspondant. Les scanners globaux, les sauvegardes ou les caches (Composer, NPM) qui écrivent de manière centralisée sont plus critiques ; dans ce cas, je prévois des exceptions de manière ciblée ou je déplace les artefacts vers des répertoires propres à chaque compte. Dans les panneaux de contrôle tels que cPanel ou Plesk, je vérifie également le choix du gestionnaire PHP (suEXEC, FPM, LSAPI) et je m’assure qu’aucun gestionnaire „ global “ ne puisse lire involontairement des fichiers n’appartenant pas à l’utilisateur concerné.
Questions fréquentes issues de la pratique
De nombreux administrateurs se demandent si SecureLinks tous Les liens symboliques sont bloqués – ce n'est pas vrai, car les liens partagés au sein d'un Comptes continuent de fonctionner. Il est essentiel que le propriétaire du lien et celui du fichier soient identiques. Autre question fréquente : un niveau « application » suffit-il ? Je réponds clairement « non », car les vérifications au niveau du noyau empêchent tout contournement via la logique Web ou les scripts. La combinaison de l’isolation, des droits minimaux et des SecureLinks rend la tâche nettement plus difficile pour les attaquants.
Cas particuliers et bonnes pratiques pour les équipes et les déploiements
Dans les équipes utilisant des dépôts et des systèmes de compilation partagés, je veille à ce que les versions soient publiées au sein d’un même compte. Les structures de liens symboliques de type Capistrano ne posent aucun problème tant qu’elles restent la propriété d’un seul utilisateur. J'interdis strictement les liens inter-comptes et je les remplace par des interfaces bien définies (API, HTTP, files d'attente de messages). Pour les répertoires de travail en groupe, j'utilise des GID de projet dédiés, clairs umask- et vérifiez si la vérification stricte SecureLinks doit s'appliquer ou non à ces GID. Cela permet de maintenir un équilibre entre collaboration et sécurité. Pour le stockage via NFS, je choisis des options d’exportation qui garantissent la cohérence des propriétaires (pas de mappages anonymisés pour les chemins de production) et je vérifie si les contrôles de liens fonctionnent comme prévu. Pour les charges de travail en conteneurs, je documente clairement les chemins de montage afin d’éviter tout raccourci indésirable entre les locataires.
Analyse et synthèse
CloudLinux SecureLinks me fournit un clair Protection contre les abus liés aux liens symboliques et aux liens physiques, car c'est le noyau qui prend la décision finale concernant les accès aux chemins d'accès, ce qui permet ainsi Voies d'attaque bloqués de manière fiable. Dans les environnements d’hébergement mutualisé comptant de nombreux comptes, ce contrôle porte immédiatement ses fruits. Des paramètres par défaut bien pensés, des stratégies de propriété claires et des tests garantissent un fonctionnement quotidien sans faille. Associé à CageFS, à des gestionnaires PHP stricts et à la surveillance des journaux, il en résulte une défense multicouche qui rend les pannes et les fuites de données nettement moins probables. Les responsables d’hébergement devraient idéalement considérer SecureLinks comme un élément incontournable de la sécurité de base, ce qui leur permettra d’améliorer durablement la confiance, la disponibilité et la réputation.
