Pourquoi exécuter named (bind) dans chroot est si important pour la sécurité? Ou peut-être que non?

Je joue avec bind et j'ai commencé à me demander pourquoi ce logiciel est, par exemple, dans CentOS fonctionnant en chroot. Ne vous méprenez pas, je sais ce qu'est le bind et à quoi sert le chroot (prison). Mais ma principale question est la suivante: est-ce que bind fonctionne sans chroot donc très peu sûr?

Est-il vraiment dangereux de le configurer sans prison (plus que tout autre service ou logiciel)? Dans les systèmes, il existe de nombreux processus fonctionnant sans chroot et je pense que la compromission de l'un d'eux est très dangereuse, mais qu'est-ce qui rend les logiciels nommés plus dangereux que les autres logiciels fonctionnant sans chroot?

Comme @Some Guy l'a mentionné, vous devez y penser dans une perspective historique.

La perspective historique était qu'une seule pièce de matériel était une douzaine de services différents sous un seul système d'exploitation. Si un service était compromis, tout sur ce matériel était compromis.

Avec la virtualisation, c'est beaucoup moins un problème. S'il n'est pas impossible de s'échapper d'une machine virtuelle, c'est loin d'être anodin. Il est certainement plus difficile de sortir d'une VM que pour un processus fonctionnant avec les privilèges root de sortir d'un chroot. Mes serveurs de liaison s'exécutent donc sur leur propre machine virtuelle. Dans ce cas, il n'y a vraiment pas grand intérêt à un chroot, car les dommages sont déjà limités simplement par le fait qu'il s'agit d'une machine virtuelle.

Un chroot est une tentative très faible de créer quelque chose comme une machine virtuelle. Les chroots peuvent être échappés cependant 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 de niveau OS et fournit des fonctionnalités de sécurité. Mais ces jours-ci, il est si facile de faire tourner une nouvelle machine virtuelle d'une machine entière qu'il 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, a besoin d'é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 le système entier pourrait être compromis. Presque tous les logiciels de nos jours commenceront à ouvrir leurs sockets et à effectuer d'autres tâches nécessitant des privilèges root, puis ils changeront l'utilisateur qu'ils exécutent en un compte non privilégié. Une fois les privilèges supprimés, l'impact de la compromission est beaucoup plus faible pour le système hôte.

Les autres réponses sont assez bonnes mais ne mentionnent pas le concept de sécurité dans les 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 de plus.

Supposons qu'il existe une vulnérabilité exploitable dans BIND et que quelqu'un puisse exécuter du code arbitraire. S'ils sont dans un chroot, ils doivent en sortir avant de passer à autre chose dans le système. Comme mentionné, les privilèges root sont requis pour briser 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 des appels système. S'il n'y a pas d'appel système pour augmenter 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 ces jours-ci et ils sont principalement limités 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 de nombreux systèmes d'exploitation, il est donc peu probable que vous fassiez un effort de votre part pour maintenir la sécurité toujours légèrement augmentée.

préambule

Je continue d'entendre les gens réitérer les idées fausses de partout sur Internet.

tout d'abord; Combien de découvertes accidentelles y a-t-il eu, qui simplement ... en raison de cause à effet , ont fini par être utilisées pour autre chose que sa destination?

ce qui était et ce qui est une prison Chroot

Chroot a été initialement conçu pour changer le répertoire racine du processus ou de l'utilisateur (idéal pour la compilation de logiciels à partir de sources inconnues). cela a assuré la sécurité du système de base, ainsi qu'un appareil de banc d'essai rapide, y compris un nettoyage facile. des années ont passé 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 de 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 pour 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 non plus vraie ... 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 PAS exécuter les processus comme ROOT. cela pourrait ouvrir un vecteur d'escalade racine (ce qui est également vrai à l'intérieur ou à l'extérieur du chroot). n'exécutez pas de processus à l' intérieur du chroot, en utilisant le même utilisateur qu'un autre processus en dehors du chroot. séparer chaque processus et utilisateur dans son propre Chroot afin de limiter les surfaces d'attaque et assurer la confidentialité. montez uniquement 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é.

une autre note 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 process qui a été stérilisée. avec des mesures de sécurité en place sur le matériel et les appareils. dont la plupart peuvent être implémentées dans un chroot.

tous les administrateurs n'ont pas le niveau de connaissances requis pour sécuriser tous les paramètres de noyau nécessaires sur un serveur dédié ou sous 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 pour essayer de couvrir et de 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, cela vaut 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, échappant à la prison, généralement par une escalade 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 de jour nul ou d' une erreur humaine idiomatique .

pourquoi 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 quoi que ce soit 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 utiliser chroot à cet effet.

de plus, chroot est durable sur n'importe quel système, quelles que soient les ressources disponibles. Autrement dit, il a le moins de frais généraux de tout type de virtualisation. cela signifie qu'il est toujours important sur de nombreuses boîtes bas de gamme.

considérez un autre scénario: vous avez apache exécuté dans un environnement virtualisé. vous souhaitez séparer chaque utilisateur. la fourniture d'un système de fichiers virtualisé via un chroot ajouté à apache (mod_chroot, mod_security, etc.) serait la meilleure option pour assurer la plus grande confidentialité entre les utilisateurs finaux. cela permet également d'éviter la collecte d'informations et offre une autre couche de sécurité.

Autrement dit, il est important de mettre en œuvre la sécurité dans les couches . Chroot étant potentiellement l'un d'entre eux. tout le monde et chaque système n'ont pas le luxe d'avoir accès au noyau, par conséquent, chroot STILL sert toujours un but. il existe une variété d'applications dans lesquelles la virtuaisation complète du système est essentiellement excessive.

En réponse à votre question

je n'utilise pas particulièrement CentOS, mais je sais que Bind abandonne désormais ses privilèges avant les opérations. je suppose cependant que la liaison est chrootée 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 non, car tout le monde n'a pas accès à la virtualisation complète au niveau du système / système d'exploitation. ceci, à 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 font tout simplement pas l'hypothèse que chacun exécute le même système. de cette façon, ils peuvent aider à fournir une couche de sécurité supplémentaire dans son ensemble ...

il y a une raison pour laquelle tant d'applications utilisent cela , et pourquoi évidemment votre système d'exploitation le fait par défaut: car il EST utilisé comme une fonction de sécurité, et cela 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, limitant les dommages à la seule prison chroot.

Cela est partiellement 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 du sujet, mais je parierais qu'il s'est beaucoup amélioré depuis les mauvais jours.

L'autre raison, la plus pratique, est simplement qu'elle est généralement déployée dans un rôle accessible sur Internet, et en tant que telle, elle est ouverte à plus d'attaques, de sondages et de méfaits généraux.

Par conséquent, comme c'est souvent la règle de base en matière de sécurité: mieux vaut prévenir que guérir, d'autant plus que l'effort de chrootage est relativement faible.