%20en%20chroot%20es%20tan%20importante%20para%20la%20seguridad%3F%20%C2%BFO%20tal%20vez%20no%20lo%20es%3F.png)
Estoy jugando con bind y comencé a preguntarme por qué este software, por ejemplo, se ejecuta en CentOS en chroot. No me malinterpretes, sé qué es bind y para qué sirve chroot (cárcel). Pero mi pregunta principal es: ¿Bind se ejecuta sin chroot de manera tan insegura?
¿Es realmente perjudicial configurarlo sin jail (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 name sea más peligroso que otro software que se ejecuta sin chroot?
Respuesta1
Como mencionó @Some Guy, debes pensar en esto desde una perspectiva histórica.
La perspectiva histórica era que una sola pieza de hardware constituía aproximadamente una docena de servicios diferentes bajo un único sistema operativo. Si un servicio se vio comprometido, todo lo que había 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. 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 ejecutan en su propia máquina virtual. Realmente no tiene mucho sentido 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, se puede escapar de los chroots mediante cualquier proceso con privilegios de root. Un chroot no está destinado ni funciona como mecanismo de seguridad. Un chroot con una cárcel BSD o LXC le brinda virtualización a nivel del sistema operativo y proporciona funciones de seguridad. Pero hoy en día, como 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 configurarla o aprender a utilizar las herramientas de virtualización a nivel del sistema operativo para este fin.
Las versiones anteriores de bind no eliminaban 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 privilegios, cualquier compromiso significaría que todo el sistema podría verse comprometido. Casi cualquier software hoy en día 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.
Respuesta2
Las otras respuestas son bastante buenas pero no mencionan el concepto de seguridad en capas. Cada capa de seguridad que agregue a su sistema es otra capa que un adversario debe superar. Poner BIND en un chroot añade 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 él antes de acceder 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, lo que limita aún más las opciones y esencialmente deja solo llamadas al sistema. Si no hay una llamada al sistema para escalar privilegios, entonces el adversario se quedará 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, ejecutar en un chroot es la configuración predeterminada en bastantes sistemas operativos, por lo que es poco probable que requiera algún esfuerzo de su parte para mantener la seguridad ligeramente aumentada.
Respuesta3
preámbulo
Sigo escuchando a personas 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 acausa y efecto, terminó siendo usado para algootroque su propósito previsto?
Qué fue y qué es una cárcel Chroot
Chroot fue diseñado inicialmente para cambiar el directorio raíz del proceso o usuario (ideal para compilar software de fuentes desconocidas). esto proporcionadoseguridadal sistema base, así como un aparato 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 también han cambiado.
Se ha utilizado chroot.efectivamente, y está directamente en la base del código paravariosprogramas 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 es simplementeno es verdad
chroot es una solución para la virtualización del sistema de archivos: nada menos, nada más. La suposición de que puedes salir fácilmente de un chroot tampoco es cierta... siempre y cuando cumplas con las pautas de ejecución de procesos dentro de la cárcel de chroot.
Algunos pasos para asegurar tu cárcel chroot
es decir, hacerNOejecutar procesos como ROOT. esto podría abrir un vector de escalada de raíz (que también es cierto dentro o fuera del chroot). no ejecutar un procesoadentroel chroot, usando el mismo usuario como otro procesoafuerael 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 básica del sistema. asegurar el sistema en su totalidad.
otra nota importante:Mucha gente piensa que OpenVZ está roto o que no es igual a 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.mayoríade los cuales puedes implementar en un chroot.
No todos los administradores tienen el nivel de conocimiento necesario para proteger 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 que 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 su conjunto...
Como se indicó, 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. Si el atacante PODRÍA comprometer el enlace, necesitaría explorar el sistema de archivos virtual en busca de algo que pueda desbordar el búfer, jugar con descriptores de archivos o de alguna otra manera comprometer algo que reside dentro del chroot, escapando de la cárcel generalmente mediante una 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 oerror humano idiomático.
¿Por qué todavía se utiliza 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. tu simplementeno puedoejecute cualquier cosa que funcione en el nivel del kernel. Esto también significa que no puede utilizar la virtualización del sistema operativo para separar procesos y proporcionar seguridad adicional. así, tuDEBEUtilice 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 a cada usuario. proporcionar un sistema de archivos virtualizado a través de un complemento chroot para 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 encapas. Chroot es potencialmente uno de ellos. no todos y todos los sistemas tienen el lujo de tener acceso al Kernel, por lo tanto, chrootAÚNtiene un propósito. Hay una variedad de aplicaciones en las que la virtualización completa del sistema es esencialmente excesiva.
En respuesta a tu pregunta
No uso particularmente CentOS, pero sé que Bind ahora pierde sus privilegios antes de las operaciones. Supongo, sin embargo, que bind tiene chroot debido a su historial de vectores de ataque y vulnerabilidades potenciales.
Además... tiene más sentido hacer chroot automáticamente a esta aplicación que no hacerlo, porque no TODOS tienen acceso a la virtualización completa a nivel de 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 cualMuchas aplicaciones usan esto., y por qué, obviamente, su sistema operativo lo hace de forma predeterminada: porque SE utiliza como característica de seguridad y SÍ funciona. Con una preparación cuidadosa, como se indicó anteriormente, es otro obstáculo más que el atacante potencial debe superar; la mayoría de las veces, restringiendo el daño solo a la cárcel chroot.
Respuesta4
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 actualizado sobre el tema, pero apuesto a que ha mejorado mucho desde los malos 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 travesuras en general.
Por lo tanto, como suele ser la regla general en cuestiones de seguridad: más vale prevenir que lamentar, sobre todo porque el esfuerzo de hacer chroot es relativamente pequeño.