Solution 1 :
Comme @Some Guy l'a mentionné, vous devez penser à cela dans une perspective historique.
La perspective historique était qu'un seul matériel était une douzaine de services différents sous un seul système d'exploitation. Si un service était compromis, alors tout sur ce matériel était compromis.
Avec la virtualisation, c'est beaucoup moins un problème. S'il n'est pas impossible de sortir d'une VM, c'est loin d'être anodin. Il est certainement plus difficile de sortir d'une machine virtuelle que pour un processus exécuté avec des privilèges root de sortir d'un chroot. Ainsi, mes serveurs de liaison fonctionnent sur leur propre machine virtuelle. Il n'y a vraiment pas grand intérêt pour un chroot dans ce cas puisque les dommages sont déjà limités simplement par le fait qu'il s'agit d'une VM.
Un chroot est une tentative très faible de créer quelque chose comme une machine virtuelle. Les chroots peuvent être échappés par n'importe quel processus avec des privilèges root. Un chroot n'est pas prévu et ne fonctionne pas comme un mécanisme de sécurité. Un chroot avec une prison BSD, ou LXC, vous offre une virtualisation au niveau du système d'exploitation et fournit des fonctionnalités de sécurité. Mais de nos jours, il est si facile de créer une nouvelle machine virtuelle sur une machine entière que cela ne vaut peut-être pas la peine de l'installer ou d'apprendre à utiliser les outils de virtualisation au niveau du système d'exploitation à cette fin.
Les versions antérieures de bind ne supprimaient pas les privilèges. Sous Unix, seul le compte root peut ouvrir des ports inférieurs à 1024, et Bind, comme nous le savons tous, doit écouter sur udp/53 et tcp/53. Étant donné que Bind démarre en tant que root et ne supprime pas les privilèges, tout compromis signifierait que l'ensemble du système pourrait être compromis. Presque tous les logiciels de nos jours commenceront à ouvrir leurs sockets et à faire toute autre chose qui nécessite des privilèges root, puis ils changeront l'utilisateur qu'ils exécutent en tant que compte non privilégié. Une fois les privilèges abandonnés, l'impact d'être compromis est beaucoup plus faible pour le système hôte.
Solution 2 :
Les autres réponses sont plutôt bonnes mais ne mentionnent pas le concept de sécurité en couches. Chaque couche de sécurité que vous ajoutez à votre système est une autre couche qu'un adversaire doit surmonter. Mettre BIND dans un chroot ajoute un obstacle supplémentaire.
Supposons qu'il existe une vulnérabilité exploitable dans BIND et que quelqu'un soit capable d'exécuter du code arbitraire. S'ils sont dans un chroot, ils doivent en sortir avant d'accéder à quoi que ce soit d'autre dans le système. Comme mentionné, les privilèges root sont requis pour casser le chroot. BIND ne s'exécute pas en tant que root, et il est censé y avoir un minimum d'outils disponibles dans le chroot, limitant davantage les options et ne laissant essentiellement que les appels système. S'il n'y a pas d'appel système pour élever les privilèges, l'adversaire est bloqué en regardant vos enregistrements DNS.
La situation susmentionnée est quelque peu improbable, comme le mentionne SomeGuy, BIND a assez peu de vulnérabilités de nos jours et elles sont principalement limitées aux scénarios de type DoS plutôt qu'à l'exécution à distance. Cela dit, l'exécution dans un chroot est la configuration par défaut sur un certain nombre de systèmes d'exploitation, il est donc peu probable que vous fassiez des efforts pour maintenir la sécurité légèrement accrue.
Solution 3 :
préambule
Je n'arrête pas d'entendre des gens réitérer des idées fausses de partout sur Internet.. donc, je vais essayer de donner quelques éclaircissements
tout d'abord ; combien de découvertes accidentelles y a-t-il eu, qui simplement... en raison de cause et effet , a fini par être utilisé pour quelque chose autre que sa destination ?
qu'est-ce qu'était et qu'est-ce qu'une prison chroot
Chroot a été initialement conçu pour changer le répertoire racine du processus ou de l'utilisateur (idéal pour compiler des logiciels à partir de sources inconnues). cela a fourni la sécurité au système de base, ainsi qu'un appareil de banc d'essai rapide, y compris un nettoyage facile. des années se sont écoulées depuis, et son concept et ses utilisations implicites ont certainement changé, de même.
chroot a été utilisé efficacement , et se trouve directement dans la base de code pour plusieurs programmes et bibliothèques (c'est-à-dire openSSHd, apache2 + mod_security2/mod_chroot, dovecot, sendmail, openVPN, pam_chroot, et bien plus encore ). supposer que toutes ces applications grand public ont implémenté des solutions de sécurité défectueuses n'est tout simplement pas vrai
chroot est une solution à la virtualisation du système de fichiers :rien de moins, rien de plus. l'hypothèse selon laquelle vous pouvez facilement sortir d'un chroot n'est pas vraie non plus... tant que vous respectez les directives d'exécution des processus à l'intérieur de la prison chroot.
quelques étapes pour sécuriser votre prison chroot
c'est-à-dire ne faites PAS exécuter les processus en tant que ROOT. cela pourrait ouvrir un vecteur d'escalade racine (ce qui est également vrai à l'intérieur ou à l'extérieur du chroot). ne pas exécuter de processus à l'intérieur le chroot, en utilisant le même utilisateur qu'un autre processus extérieur le chroot. séparer chaque processus et utilisateur dans son propre Chroot afin de limiter les surfaces d'attaque et assurer la confidentialité. ne montez que les fichiers, bibliothèques et périphériques nécessaires. enfin, chroot ne remplace PAS la sécurité du système de base. sécuriser le système dans son intégralité.
autre remarque importante : beaucoup de gens pensent qu'OpenVZ est cassé, ou qu'il n'est pas égal par rapport à la virtualisation complète du système. ils font cette hypothèse car il s'agit essentiellement d'un Chroot, avec une table de processus qui a été stérilisée. avec des mesures de sécurité en place sur le matériel et les appareils. la plupart dont vous pouvez implémenter dans un chroot.
tous les administrateurs n'ont pas le niveau de connaissances nécessaires pour sécuriser tous les paramètres de noyau nécessaires sur un serveur dédié ou dans le cadre d'une virtualisation complète du système. cela signifie que le déploiement d'OpenVZ signifie que vos clients auront beaucoup moins de surface d'attaque à couvrir et à sécuriser avant de déployer leurs applications. un bon hôte fera un bon travail en sécurisant ces paramètres, et à son tour, c'est mieux non seulement pour tout le monde sur le nœud, ou dans le centre de données, mais pour Internet dans son ensemble...
comme indiqué, le chroot fournit la virtualisation du système de fichiers. vous devez vous assurer qu'il n'y a pas d'exécutables setuid, d'applications non sécurisées, de bibliothèques, de liens symboliques sans propriétaire, etc. d'une autre manière, compromettre quelque chose résidant à l'intérieur du chroot - en s'échappant de la prison, généralement par le biais d'une élévation de privilèges ou en injectant sa charge utile dans le système de base.
si cela se produit, c'est généralement le résultat d'une mauvaise mise à jour, d'un exploit zero-day ou d'une erreur humaine idiomatique .
pourquoi le chroot est toujours utilisé, par opposition à la virtualisation complète du système
considérez ce scénario :vous exécutez un serveur privé virtuel, avec le nœud hôte exécutant OpenVZ. vous ne pouvez tout simplement pas exécuter tout ce qui fonctionne au niveau du noyau. cela signifie également que vous ne pouvez pas utiliser la virtualisation du système d'exploitation pour séparer les processus et fournir une sécurité supplémentaire. ainsi, vous DEVEZ utilisez chroot à cette fin.
de plus, chroot est durable sur n'importe quel système, quelles que soient les ressources disponibles. en termes simples, il a le moins de frais généraux de tous les types de virtualisation. cela signifie qu'il est toujours important sur de nombreuses boîtes bas de gamme.
envisagez un autre scénario :vous avez apache qui s'exécute dans un environnement virtualisé. vous voulez séparer chaque utilisateur. fournir un système de fichiers virtualisé via un chroot ajouté à apache (mod_chroot, mod_security, etc.) serait la meilleure option pour garantir la plus grande confidentialité entre les utilisateurs finaux. cela permet également d'empêcher la collecte d'informations et offre une autre couche de sécurité.
en termes simples, il est important d'implémenter la sécurité dans les couches . Chroot étant potentiellement l'un d'entre eux. tout le monde et tous les systèmes n'ont pas le luxe d'avoir accès au noyau, par conséquent, chrootez STILL sert un but. il existe une variété d'applications dans lesquelles la virtualisation complète du système est essentiellement exagérée.
En réponse à votre question
Je n'utilise pas particulièrement CentOS, mais je sais que Bind supprime désormais ses privilèges avant les opérations. Je suppose cependant que bind est chrooté en raison de son historique de vecteurs d'attaque et de vulnérabilités potentielles.
aussi ... il est plus logique de chrooter automatiquement cette application que de ne pas le faire, car TOUT LE MONDE n'a pas accès à la virtualisation complète au niveau du système / système d'exploitation. cela à son tour, et en théorie, contribue à assurer la sécurité de la base d'utilisateurs CentOS :
les fournisseurs de systèmes d'exploitation ne se promènent tout simplement pas en supposant que chacun utilise le même système. de cette façon, ils peuvent aider à fournir une couche supplémentaire de sécurité au sens large...
il y a une raison pour laquelle tant d'applications l'utilisent , et pourquoi, évidemment, votre système d'exploitation le fait par défaut :parce qu'il EST utilisé comme fonction de sécurité et qu'il fonctionne. avec une préparation minutieuse, comme indiqué précédemment, c'est encore un autre obstacle que l'attaquant potentiel doit surmonter - la plupart du temps, en limitant les dommages à la seule prison chroot.
Solution 4 :
Cela est en partie dû à des raisons historiques, lorsque les anciennes versions de Bind présentaient des vulnérabilités de sécurité graves et fréquentes. Je ne me suis pas vraiment tenu au courant sur le sujet, mais je parierais que ça s'est beaucoup amélioré depuis le mauvais vieux temps.
L'autre raison, la plus pratique, est simplement qu'il est généralement déployé dans un rôle faisant face à Internet, et en tant que tel, il est ouvert à davantage d'attaques, de sondages et de méfaits généraux.
Par conséquent, comme c'est souvent la règle d'or en matière de sécurité :mieux vaut prévenir que guérir, d'autant plus que l'effort de chrootage est relativement faible.