Solución 1:
Como mencionó @Some Guy, hay que pensar en esto desde una perspectiva histórica.
La perspectiva histórica era que una sola pieza de hardware era una docena de servicios diferentes bajo un solo sistema operativo. Si un servicio se vio comprometido, todo en ese hardware se vio comprometido.
Con la virtualización, esto es un problema mucho menor. Si bien no es imposible escapar de una máquina virtual, está lejos de ser trivial. Sin duda, es más difícil salir de una VM que un proceso que se ejecuta con privilegios de root para salir de un chroot. Entonces mis servidores de enlace se ejecutan en su propia máquina virtual. Realmente no tiene mucho sentido para un chroot en ese caso ya que el daño ya está limitado simplemente por el hecho de que es una VM.
Un chroot es un intento muy débil de crear algo como una máquina virtual. Se puede escapar de los chroots mediante cualquier proceso con privilegios de root. Un chroot no está diseñado y no funciona como un mecanismo de seguridad. Un chroot con una cárcel BSD o LXC le brinda virtualización a nivel de sistema operativo y proporciona funciones de seguridad. Pero en estos días, dado que es tan fácil poner en marcha una nueva máquina virtual de una máquina completa, es posible que no valga la pena el esfuerzo de configurar o aprender a usar las herramientas de virtualización a nivel del sistema operativo para este propósito.
Las versiones anteriores de bind no eliminaban los privilegios. En Unix, solo la cuenta raíz puede abrir puertos por debajo de 1024 y Bind, como todos sabemos, necesita escuchar en udp/53 y tcp/53. Dado que Bind comienza como root y no pierde privilegios, cualquier compromiso significaría que todo el sistema podría verse comprometido. Casi cualquier software en estos días comenzará a abrir sus sockets y hará cualquier otra cosa que requiera privilegios de root, luego cambiará el usuario que está ejecutando a una cuenta sin privilegios. Una vez que se eliminan los privilegios, el impacto de verse comprometido es mucho menor para el sistema host.
Solución 2:
Las otras respuestas son bastante buenas pero no mencionan el concepto de seguridad en capas. Cada capa de seguridad que agrega a su sistema es otra capa que un adversario debe superar. Poner BIND en un chroot agrega un obstáculo más.
Digamos que hay una vulnerabilidad explotable en BIND y alguien puede ejecutar código arbitrario. Si están en un chroot, necesitan salir de eso antes de llegar a cualquier otra cosa en el sistema. Como se mencionó, se requieren privilegios de root para romper chroot. BIND no se ejecuta como root, y se supone que hay herramientas mínimas disponibles en chroot, lo que limita aún más las opciones y esencialmente deja solo las llamadas al sistema. Si no hay una llamada al sistema para escalar los privilegios, entonces el adversario está atascado mirando sus registros DNS.
La situación antes mencionada es algo improbable como menciona SomeGuy, BIND tiene muy pocas vulnerabilidades en estos días y en su mayoría están restringidas a escenarios de tipo DoS en lugar de ejecución remota. Dicho esto, la ejecución en un chroot es la configuración predeterminada en bastantes sistemas operativos, por lo que es poco probable que haga algún esfuerzo de su parte para mantener la seguridad ligeramente aumentada.
Solución 3:
preámbulo
Sigo escuchando a la gente reiterar conceptos erróneos de todo Internet... por lo tanto, intentaré dar algunas aclaraciones
primero; cuántos descubrimientos accidentales ha habido, que simplemente... debido a causa y efecto , terminó siendo utilizado para algo otro que su propósito previsto?
qué era y qué es una cárcel de Chroot
Chroot se diseñó inicialmente para cambiar el directorio raíz del proceso o usuario (excelente para compilar software de fuentes desconocidas). esto proporcionó seguridad al sistema base, así como un dispositivo de banco de pruebas rápido, que incluye una fácil limpieza. han pasado años desde entonces, y su concepto y usos implícitos ciertamente han cambiado, igualmente.
chroot se ha utilizado efectivamente , y está directamente en el código base de varios programas y bibliotecas (es decir, openSSHd, apache2 + mod_security2/mod_chroot, dovecot, sendmail, openVPN, pam_chroot, y mucho más ). asumir que todas estas aplicaciones principales han implementado soluciones de seguridad defectuosas es simplemente falso.
chroot es una solución para la virtualización del sistema de archivos:nada menos y nada más. la suposición de que puede escapar fácilmente de un chroot tampoco es cierta... siempre y cuando cumpla con las pautas de ejecución de procesos dentro de la cárcel chroot.
algunos pasos para proteger su chroot jail
es decir, NO ejecutar procesos como ROOT. esto podría abrir un vector de escalada raíz (que también es cierto dentro o fuera del chroot). no ejecute un proceso dentro el chroot, usando el mismo usuario que otro proceso fuera el chroot separe cada proceso y usuario en su propio Chroot para limitar las superficies de ataque y brindar privacidad. monte solo los archivos, bibliotecas y dispositivos necesarios. por último, chroot NO reemplaza la seguridad del sistema base. asegurar el sistema en su totalidad.
otra nota importante: mucha gente piensa que OpenVZ está roto o que no es igual en comparación con la virtualización completa del sistema. hacen esta suposición porque es esencialmente un Chroot, con una mesa de proceso que ha sido esterilizada. con medidas de seguridad implementadas en hardware y dispositivos. la mayoría de los cuales puede implementar en un chroot.
No todos los administradores tienen el nivel de conocimiento necesario para asegurar todos los parámetros necesarios del kernel en un servidor dedicado o bajo una virtualización completa del sistema. esto significa que implementar OpenVZ significa que sus clientes tendrán mucha menos superficie de ataque para tratar de cubrir y asegurar antes de implementar sus aplicaciones. un buen host hará un buen trabajo asegurando estos parámetros y, a su vez, esto es mejor no solo para todos en el nodo o en el centro de datos, sino también para Internet en general...
como se indicó, el chroot proporciona virtualización del sistema de archivos. debe asegurarse de que no haya ejecutables setuid, aplicaciones inseguras, bibliotecas, enlaces simbólicos colgantes sin propietario, etc. de alguna otra manera comprometer algo que reside dentro del chroot, escapando de la cárcel, generalmente a través de la escalada de privilegios o inyectando su carga útil en el sistema base.
si esto sucede, generalmente es el resultado de una mala actualización, un exploit de día cero o un error humano idiomático .
por qué todavía se usa chroot, en lugar de la virtualización completa del sistema
Considere este escenario:está ejecutando un servidor privado virtual, con el nodo host ejecutando OpenVZ. simplemente no puedes ejecutar cualquier cosa que funcione en el nivel del kernel. esto también significa que no puede usar la virtualización del sistema operativo para separar procesos y brindar seguridad adicional. por lo tanto, DEBES use chroot para este propósito.
además, chroot es sostenible en cualquier sistema, independientemente de los recursos disponibles. En pocas palabras, tiene la menor sobrecarga de cualquier tipo de virtualización. esto significa que sigue siendo importante en muchas cajas de gama baja.
Considere otro escenario:tiene apache ejecutándose dentro de un entorno virtualizado. desea separar cada usuario. proporcionar un sistema de archivos virtualizado a través de un complemento chroot en apache (mod_chroot, mod_security, etc.) sería la mejor opción para garantizar la máxima privacidad entre los usuarios finales. esto también ayuda a evitar la recopilación de información y ofrece otra capa de seguridad.
en pocas palabras, es importante implementar la seguridad en capas . Chroot podría ser uno de ellos. no todo el mundo y todos los sistemas pueden darse el lujo de tener acceso al Kernel, por lo tanto, chroot STILL tiene un propósito. hay una variedad de aplicaciones en las que la virtualización completa del sistema es esencialmente excesiva.
En respuesta a su pregunta
Particularmente no uso CentOS, pero sé que Bind ahora pierde sus privilegios antes de las operaciones. Sin embargo, asumiría que bind está chrooteado debido a su historial de vectores de ataque y vulnerabilidades potenciales.
también... tiene más sentido hacer chroot automáticamente en esta aplicación, que no hacerlo, porque no TODOS tienen acceso a la virtualización completa del sistema/sistema operativo. esto a su vez, y en teoría, ayuda a brindar seguridad a la base de usuarios de CentOS:
Los proveedores de sistemas operativos simplemente no dan por sentado que todos ejecutan el mismo sistema. de esta manera, pueden ayudar a proporcionar una capa adicional de seguridad en general...
hay una razón por la cual tantas aplicaciones usan esto , y por qué, obviamente, su sistema operativo lo hace de manera predeterminada:porque SE usa como una función de seguridad y SÍ funciona. con una preparación cuidadosa, como se indicó anteriormente, es otro obstáculo que el atacante potencial debe superar, la mayoría de las veces, restringiendo el daño solo a la cárcel chroot.
Solución 4:
Esto se debe en parte a razones históricas, cuando las versiones anteriores de Bind tenían vulnerabilidades de seguridad graves y frecuentes. Realmente no me he mantenido al día sobre el tema, pero apostaría a que ha mejorado mucho desde los viejos tiempos.
La otra razón, la más práctica, es que normalmente se implementa en una función orientada a Internet y, como tal, está abierta a más ataques, sondeos y daños en general.
Por lo tanto, como suele ser la regla general en materia de seguridad:más vale prevenir que curar, especialmente porque el esfuerzo de chroot es relativamente pequeño.