Estoy jugando con Bind y comencé a preguntarme por qué este software está, por ejemplo, en CentOS ejecutándose en chroot. No me malinterpreten, sé lo que es Bind y para qué sirve Chroot (cárcel). Pero mi pregunta principal es: ¿se está ejecutando bind sin chroot tan inseguro?
¿Es realmente perjudicial configurarlo sin una cárcel (más que cualquier otro servicio o software)? En los sistemas hay muchos procesos que se ejecutan sin chroot y creo que comprometer cualquiera de ellos es muy peligroso, pero ¿qué hace que los nombres sean más peligrosos que otros programas que se ejecutan sin chroot?
Respuestas:
Como @Some Guy mencionó, tienes 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, entonces todo en ese hardware se vio comprometido.
Con la virtualización esto es mucho menos un problema. Si bien no es imposible escapar de una VM, está lejos de ser trivial. Ciertamente, es más difícil salir de una máquina virtual que un proceso que se ejecuta con privilegios de root para salir de un chroot. Entonces mis servidores de enlace se están ejecutando en su propia VM. Realmente no hay 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 así como una VM. Sin embargo, cualquier proceso con privilegios de root puede escapar de los chroots. Un chroot no está destinado y no funciona como un mecanismo de seguridad. Un chroot con una cárcel BSD o LXC le brinda virtualización a nivel del sistema operativo y proporciona características 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, puede que no valga la pena el esfuerzo de configuración o aprender a usar las herramientas de virtualización de nivel de sistema operativo para este propósito.
Las versiones anteriores de bind no dejaban caer 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 elimina los 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 y luego cambiará el usuario que está ejecutando a una cuenta no privilegiada. Una vez que se eliminan los privilegios, el impacto de verse comprometido es mucho menor para el sistema host.
fuente
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 problema, 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 el chroot, limitando aún más las opciones y esencialmente dejando solo llamadas al sistema. Si no hay una llamada al sistema para escalar privilegios, entonces el adversario está atascado mirando sus registros DNS.
La situación mencionada es poco probable como SomeGuy menciona, BIND tiene muy pocas vulnerabilidades en estos días y están restringidas principalmente a escenarios de tipo DoS en lugar de ejecución remota. Dicho esto, ejecutar un chroot es la configuración predeterminada en bastantes sistemas operativos, por lo que es poco probable que tome algún esfuerzo de su parte para mantener la seguridad cada vez más leve.
fuente
preámbulo
sigo escuchando a la gente reiterar conceptos erróneos de todo Internet ... por lo tanto, intentaré dar algunas aclaraciones
antes que nada; ¿Cuántos descubrimientos accidentales ha habido, que simplemente ... debido a causa y efecto , terminaron siendo utilizados para otra cosa? al propósito previsto?
qué era y qué es una cárcel de Chroot
Chroot fue inicialmente diseñado para cambiar el directorio raíz del proceso o usuario (ideal para compilar software de fuentes desconocidas). esto proporcionó seguridad al sistema base, así como a un dispositivo de prueba rápida, que incluía una fácil limpieza. Han pasado años desde entonces, y su concepto y usos implícitos ciertamente también han cambiado.
chroot se ha utilizado de manera efectiva y está directamente en la base de código para 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 convencionales han implementado soluciones de seguridad defectuosas simplemente no es cierto
chroot es una solución para la virtualización del sistema de archivos: nada menos, nada más. la suposición de que puede salir 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 de chroot.
algunos pasos para asegurar su cárcel chroot
es decir, NO ejecute procesos como ROOT. esto podría abrir un vector de escalado de raíz (que también es cierto dentro o fuera del chroot). no ejecute un proceso dentro del chroot, utilizando el mismo usuario que otro proceso fuera del chroot. separe cada proceso y usuario en su propio Chroot para limitar las superficies de ataque y proporcionar privacidad. solo monte los archivos, bibliotecas y dispositivos necesarios. por último, chroot NO es un reemplazo para la seguridad del sistema base. Asegure 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 tabla de proceso que ha sido esterilizada. con medidas de seguridad 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 del núcleo necesarios en un servidor dedicado o bajo la virtualización completa del sistema. Esto significa que la implementación de OpenVZ significa que sus clientes tendrán mucho menos superficie de ataque para tratar de cubrir y proteger 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 para Internet en general ...
como se indicó, el chroot proporciona la virtualización del sistema de archivos. debes asegurarte de que no haya ejecutables setuid, aplicaciones inseguras, bibliotecas, enlaces simbólicos sin propietario colgantes, etc. de alguna otra manera comprometer algo que reside dentro del chroot: escapar 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 día cero explotar o un error humano idiomático .
por qué todavía se usa chroot, a diferencia de la virtualización completa del sistema
considere este escenario: está ejecutando un servidor privado virtual, con el nodo host ejecutando OpenVZ. simplemente no puede ejecutar nada que funcione en el nivel del núcleo. Esto también significa que no puede utilizar la virtualización del sistema operativo para separar procesos y proporcionar seguridad adicional. por lo tanto, DEBE usar 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 todavía es importante en muchas cajas de gama baja.
considere otro escenario: tiene apache ejecutándose dentro de un entorno virtualizado. Desea separar a cada usuario. proporcionar un sistema de archivos virtualizado mediante un complemento chroot a 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 es potencialmente uno de ellos. no todos y todos los sistemas tienen 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 exagerada.
En respuesta a tu pregunta
No uso particularmente CentOS, pero sé que Bind ahora deja caer sus privilegios antes de las operaciones. Supongo, sin embargo, que la vinculación se ve afectada debido a su historial de vectores de ataque y vulnerabilidades potenciales.
también ... tiene más sentido hacer chroot automáticamente esta aplicación, que no, porque NO TODOS tienen acceso a la virtualización completa del sistema / sistema operativo. Esto a su vez, y en teoría, ayuda a proporcionar seguridad a la base de usuarios de CentOS:
Los proveedores de sistemas operativos simplemente no andan suponiendo que todos estén ejecutando 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 característica de seguridad y sí funciona. Con una preparación cuidadosa, como se dijo anteriormente, es otro obstáculo que el atacante potencial debe superar, la mayoría de las veces, restringiendo el daño a la cárcel chroot.
fuente
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 apuesto a que ha mejorado mucho desde los viejos tiempos.
La otra razón, la más práctica, es que generalmente se implementa en un rol orientado a Internet y, como tal, está abierto a más ataques, sondeos y travesuras en general.
Por lo tanto, como suele ser la regla de oro en materia de seguridad: más vale prevenir que curar, sobre todo porque el esfuerzo de fragmentarlo es relativamente pequeño.
fuente