Table des matières de l'article :
Introduction
Dans les systèmes UNIX et Linux, la sécurité et la séparation des privilèges représentent un élément clé pour garantir la protection des données et la bonne gestion de l'accès aux fichiers. Le cœur de ce système repose sur des identifiants d'utilisateur (UID) et des identifiants de groupe (GID), accompagnés d'un système d'autorisation qui régule les opérations de lecture, d'écriture et d'exécution sur les fichiers (rwx). Chaque processus exécuté sur le système d'exploitation est associé à un UID et un GID spécifiques, limitant l'accès aux fichiers et empêchant les exploits potentiels par des processus malveillants. Cette approche structurée garantit que les différents utilisateurs et processus n'ont pas accès aux fichiers des autres sauf s'ils disposent d'autorisations explicites, créant ainsi une ligne de défense critique contre de nombreuses vulnérabilités de sécurité.
Cependant, malgré ces principes solides qui sous-tendent UNIX et Linux, de nombreux panneaux de contrôle commerciaux tels que cPanel, Plesket DirectAdmin ils adoptent une gestion de troisièmes niveaux (sous-domaines) qui met en danger la sécurité des utilisateurs. Dans cet article, nous explorerons comment ces panels gèrent les sous-domaines, les problèmes liés au partage UID/GID et les vulnérabilités potentielles qui découlent de cette architecture, tout en proposant des solutions et des conseils sur la manière dont une gestion professionnelle peut assurer une plus grande sécurité.
Gestion des troisièmes niveaux dans les panneaux de contrôle : cPanel, Plesk, DirectAdmin
Panneaux de contrôle Linux comme cPanel, Plesk e DirectAdmin ils sont parmi les plus utilisés dans le secteur de l'hébergement Web en raison de leur interface intuitive et de leur capacité à simplifier des opérations techniques complexes. Cependant, lorsqu'il s'agit de gestion de sous-domaines, ces outils présentent des lacunes importantes du point de vue de la sécurité.
Lorsque vous créez un troisième niveau (un sous-domaine) comme par exemple blog.dominio.com, ces panneaux ont tendance à le placer comme un répertoire imbriqué dans le répertoire personnel du domaine racine. Par exemple, dans cPanel, un répertoire de sous-domaine peut être structuré comme suit :
/home/nom_utilisateur/public_html/blog
Même dans Plesk et DirectAdmin, la logique est similaire :
/var/www/vhosts/domain.com/blog
Cette organisation a des implications importantes : le sous-domaine n'a pas d'UID/GID distinct, mais s'exécute avec les mêmes autorisations (utilisateur et groupe) que le domaine principal. Cela signifie que tous les processus PHP (et autres processus Web) s'exécutent avec les mêmes privilèges que le domaine racine.
Le problème de sécurité : partager des UID et des GID
L’un des principaux enjeux liés à la gestion des sous-domaines dans ces panels est le partage des UID et GID entre le domaine principal et ses sous-domaines. Étant donné que les sous-domaines sont simplement des répertoires au sein du domaine principal et partagent les mêmes autorisations d'exécution, toute vulnérabilité découverte dans un sous-domaine peut compromettre l'intégralité de l'installation du domaine principal.
Pour mieux clarifier le concept, prenons un exemple pratique.
Étude de cas : examplestore.com
Imaginons le cas d'une entreprise qui gère le domaine principal esempiostore.com, où est hébergée une installation PrestaShop 8 moderne pour la vente en ligne. Cependant, pour des raisons historiques, comptables et fiscales, la même société conserve un ancien sous-domaine old.esempiostore.com qui héberge une version obsolète de PrestaShop 1.6.
Dans le panneau de configuration, ce sous-domaine est traité comme un simple répertoire au sein de l'installation principale, avec un chemin similaire à /home/esempiostore.com/public_html/old.
Scénario d'attaque
Un attaquant découvre une vulnérabilité dans un module obsolète de l'ancienne installation PrestaShop 1.6 dans le sous-domaine old.esempiostore.com. En exploitant cette vulnérabilité, l'attaquant parvient à obtenir un accès administratif à la plateforme et charge un shell PHP ou un gestionnaire de fichiers. À partir de ce moment, l’attaquant a la possibilité de lire et de modifier les fichiers du répertoire du sous-domaine.
Mais le vrai problème vient du fait que, puisque les sous-domaines partagent les mêmes autorisations que le domaine principal, l'attaquant peut librement naviguer vers le répertoire parent et accéder aux fichiers de configuration du domaine principal. esempiostore.com. Par exemple, l'attaquant pourrait accéder au fichier parameters.php de PrestaShop 8, qui contient les informations d'identification d'accès à la base de données.
À ce stade, l’attaquant dispose de tout ce dont il a besoin pour compromettre l’intégralité du domaine racine. Il pouvait accéder à la base de données, créer un nouveau compte administrateur et prendre le contrôle total de la nouvelle installation de PrestaShop 8, jusque-là considérée comme sûre et à jour.
L’importance de la séparation des privilèges
Dans un système d'exploitation UNIX/Linux, la séparation des privilèges est l'un des principes fondamentaux de sécurité. Chaque processus ou opération au sein du système est exécuté par un utilisateur avec un certain UID (User ID) et GID (Group ID), et ces identifiants contrôlent l'accès aux ressources telles que les fichiers, les répertoires et les processus. Ce modèle, connu sous le nom Contrôle d'accès discrétionnaire (DAC), vous permet de limiter strictement ce qu'un utilisateur ou un processus peut faire, créant ainsi un périmètre de sécurité autour des données et applications critiques. Dans les environnements multi-tenants, tels que ceux où plusieurs domaines et sous-domaines partagent des ressources, la séparation des privilèges devient essentielle pour garantir qu'une faille de sécurité dans une zone du système ne puisse pas se propager aux autres.
Comment la séparation des privilèges devrait fonctionner dans un environnement Web
Dans un contexte idéal, chaque domaine ou sous-domaine devrait avoir son propre environnement isolé, avec ses propres UID et GID distincts, de sorte qu'un processus démarré dans un domaine ne puisse pas accéder aux fichiers d'autres domaines. Cette isolation n'est pas seulement théorique, mais pratique courante dans des configurations plus sécurisées, par exemple avec l'utilisation de conteneurs comme Docker ou d'environnements isolés avec des outils comme CageFS (CloudLinux).
Chaque domaine, qu'il soit racine ou troisième niveau, doit être traité comme une entité distincte :
- Fichiers et répertoires: Chaque domaine doit avoir sa propre structure de répertoires, avec des autorisations distinctes qui empêchent un utilisateur du domaine A d'accéder aux fichiers du domaine B.
- Processus PHP/CGI: Idéalement, chaque domaine devrait exécuter ses propres scripts PHP ou CGI avec un utilisateur spécifique, empêchant ainsi un processus d'un domaine d'interférer ou d'intercepter les processus d'un autre domaine.
- Environnements virtuels et sandboxing: Des environnements isolés doivent être intégrés pour garantir qu'une vulnérabilité dans un domaine ne peut pas compromettre l'ensemble du serveur.
Que se passe-t-il dans les panneaux de contrôle comme cPanel, Plesk et DirectAdmin ?
Malheureusement, cPanel, Plesk et DirectAdmin utilisent une gestion centralisée des autorisations pour les domaines et sous-domaines, traitant ces derniers comme de simples répertoires imbriqués dans le système de fichiers de l'utilisateur principal. Cette approche peut sembler pratique, mais elle pose de sérieux problèmes de sécurité :
- Partage d'UID/GID entre domaines et sous-domaines: Comme souligné ci-dessus, le domaine principal et ses sous-domaines fonctionnent sous les mêmes UID et GID que l'utilisateur principal. Cela signifie que si un processus ou module PHP vulnérable est compromis sur un sous-domaine, l'attaquant a potentiellement accès à tous les fichiers et répertoires appartenant au domaine racine et aux autres sous-domaines.
- Exécuter des processus PHP sous le même utilisateur: Dans ces panneaux de contrôle, les scripts PHP s'exécutent en tant qu'utilisateur propriétaire du domaine. Cela implique qu'il n'y a pas de différence entre un processus PHP exécuté depuis le domaine principal et un processus PHP exécuté depuis un sous-domaine. Si un attaquant parvient à exploiter une vulnérabilité dans un sous-domaine, il a la même capacité à manipuler des fichiers ou des processus dans le domaine principal que s'il en était l'utilisateur propriétaire.
- Problèmes d'architecture obsolète et d'imbrication: L'approche de création de répertoires imbriqués pour les sous-domaines (par ex.
/home/nome_utente/public_html/sottodominio) augmente encore les risques, car il n'y a pas de séparation physique ou logique entre les données des sous-domaines et celles du domaine principal. Cela permet à un attaquant de passer facilement d'un sous-domaine compromis à des fichiers ou bases de données sensibles du domaine principal.
Les vrais risques de cette architecture
Reprenons le cas de l'exemple pratique évoqué précédemment : le domaine racine esempiostore.com avec un sous-domaine old.esempiostore.com, qui contient une ancienne version de PrestaShop 1.6. Cette situation n'est pas rare dans les environnements réels, où les anciennes versions de logiciels sont conservées sur des sous-domaines pour des raisons de comptabilité ou de transition. Même si le domaine principal esempiostore.com est à jour et sécurisé, la présence du sous-domaine existant avec un logiciel obsolète introduit un point d'entrée vulnérable.
Un attaquant pourrait exploiter une vulnérabilité dans un module PrestaShop 1.6 présent dans le sous-domaine. À partir du moment où l'attaquant parvient à compromettre le sous-domaine, il peut charger un gestionnaire de fichiers ou un shell PHP pour naviguer dans le système de fichiers du serveur, en exécutant des commandes avec le même UID que l'utilisateur propriétaire. Cela lui permet d'accéder aux fichiers de configuration de la version mise à jour de PrestaShop 8 sur le domaine principal, compromettant non seulement les données du sous-domaine, mais toute l'infrastructure du domaine principal.
La conséquence directe de ce scénario est dévastatrice :
- Perte de données: L'accès à la base de données via des fichiers de configuration insuffisamment protégés peut permettre à l'attaquant de manipuler ou de voler des données sensibles.
- Élévation de privilèges: L'attaquant peut obtenir un accès complet au système et créer de nouveaux utilisateurs administratifs dans la base de données principale du site.
- Compromission des informations financières: Si le site principal gère des transactions financières, celles-ci pourraient être interceptées ou manipulées, exposant l'entreprise à des fraudes ou à des violations de la vie privée.
- Dommage à la réputation: Toute compromission de sécurité peut causer des dommages irréparables à la réputation de votre entreprise, faisant fuir clients et partenaires.
Une solution professionnelle : séparation des UID/GID et des domaines isolés
Notre philosophie en tant que Managed Server Srl a toujours été celle de assurez-vous que chaque domaine, qu'il soit de deuxième, troisième ou quatrième niveau, fonctionne avec un UID et un GID différents, et que les privilèges sont complètement séparés. Cette approche garantit qu'aucun fichier d'un domaine ne peut être lu ou écrit par un autre domaine. Une solution qui devrait être standard dans tout environnement d'hébergement professionnel.
L'arborescence des répertoires doit également refléter cette séparation. Au lieu d'imbriquer les sous-domaines dans le répertoire du domaine racine, comme le font cPanel, Plesk et DirectAdmin, nous pensons que chaque domaine ou sous-domaine devrait avoir son propre répertoire dédié et distinct. Par exemple, dans le cas de old.esempiostore.com, le répertoire devrait ressembler à ceci :
/home/old.examplestore.com
Avec cette architecture, même si un sous-domaine est compromis, l'attaquant n'aurait pas accès aux fichiers du domaine principal, puisque les deux environnements seraient complètement séparés au niveau de l'utilisateur et du groupe.
Pourquoi nous ne recommandons pas les panneaux de contrôle commerciaux
Nous déconseillons souvent à nos clients d'utiliser des panneaux de contrôle commerciaux tels que cPanel, Plesk ou DirectAdmin pour la gestion des serveurs. Il ne s’agit pas d’une simple approche marketing visant à nous différencier, mais d’un choix conscient motivé par des années d’expérience dans le domaine.
Ces panneaux ont été créés dans le but de simplifier la gestion des serveurs pour ceux qui n'ont pas les compétences techniques ou les ressources économiques nécessaires pour s'appuyer sur un ingénieur système professionnel. Cependant, au fil du temps, les coûts de licence de ces panels ont augmenté, tandis que le coût de la gestion professionnelle par des ingénieurs systèmes experts a diminué.
Aujourd'hui, avec une différence de 20 ou 30 euros par mois - moins qu'un café par jour - il est possible d'éviter complètement les risques et les limites de ces panels, en s'appuyant plutôt sur une équipe de professionnels. avec des décennies d'expérience qui non seulement optimisent les performances, mais mettent en œuvre des solutions de sécurité avancées, une surveillance continue, une sauvegarde et une reprise après sinistre.
Évitez les risques inutiles, faites confiance à de vrais experts pour protéger votre site.
Si la sécurité de votre infrastructure Web est une priorité, il est temps d'abandonner les anciens panneaux de contrôle commerciaux et de passer à une gestion professionnelle sur mesure. Chez Managed Server Srl, nous proposons un service d'hébergement avancé, avec des systèmes de sécurité « by design » qui garantissent que chaque domaine, sous-domaine et application sont complètement isolés et protégés.
Ne laissez pas une vulnérabilité de sous-domaine compromettre l'ensemble de votre activité en ligne. Avec un petit investissement mensuel, vous pouvez vous assurer que votre plateforme est gérée par des experts capables de prévenir les problèmes de sécurité comme ceux décrits dans cet article. Contactez-nous aujourd'hui pour découvrir comment nous pouvons vous aider à protéger et optimiser votre site avec un niveau de sécurité et de professionnalisme que les panneaux de contrôle commerciaux ne pourront jamais garantir.
