La mejor manera de sandbox Apache en Linux

Tengo Apache ejecutándose en un servidor de Debian público y estoy un poco preocupado por la seguridad de la instalación. Esta es una máquina que aloja varios proyectos de tiempo libre, por lo que ninguno de los que usamos la máquina realmente tiene el tiempo para observar constantemente los parches ascendentes, estar al tanto de los problemas de seguridad, etc. Pero me gustaría mantener a los malos fuera , o si entran, guárdalos en un arenero.

Entonces, ¿cuál es la mejor solución fácil de configurar y fácil de mantener aquí? ¿Es fácil configurar un sandbox de Linux en modo usuario en Debian? O tal vez una cárcel chroot? Me gustaría tener un acceso fácil a los archivos dentro del sadbox desde el exterior. Este es uno de esos momentos en los que me queda muy claro que soy un programador, no un administrador de sistemas. Cualquier ayuda sería muy apreciada!

Respuestas a la pregunta(10)

pero si no tiene tiempo para vigilar los parches de seguridad y estar al tanto de los problemas de seguridad, debe preocuparse, sin importar cuál sea su configuración. Por otro lado, el simple hecho de que esté pensando en estos problemas lo diferencia del otro 99.9% de los propietarios de dichas máquinas. Estás en el camino correcto!

debootstrap es su amigo junto con QEMU, Xen, OpenVZ, Lguest o una plétora de otros.

también sugiero agregar una regla de iptables para no permitir conexiones de red salientes inesperadas. Dado que lo primero que hacen la mayoría de las explotaciones web automatizadas es descargar el resto de su carga útil, evitar que la conexión de red pueda ralentizar al atacante.

Se pueden usar algunas reglas similares a estas (tenga cuidado, su servidor web puede necesitar acceso a otros protocolos): iptables --append OUTPUT -m owner --uid-owner apache -m state ESTABLECIDO, RELACIONADO --jump ACEPTAR iptables - -apagar SALIDA -m propietario - apache -uid-propietario --protocolo udp --destination-port 53 - saltar ACEPTAR iptables --apagar SALIDA -m propietario - usuario-apache-propietario --jump

mod_chroot ysuEXEC, que son las cosas básicas con las que debes comenzar y, probablemente, las únicas cosas que necesitas.

 Alexander29 sept. 2008 11:36
Corríjame si me equivoco, pero nunca fue la intención de chroot ser una característica de seguridad. Las jaulas chroot no son seguras.
 Terminus29 sept. 2008 14:46
Cuando se utiliza mod_chroot, Apache se ejecuta en un entorno sin nada que pueda modificar el mundo exterior. Luego, suexec permite una forma en la que puede ejecutar cualquier VirtualHost con un usuario diferente, para que no puedan meterse entre ellos.
 Terminus29 sept. 2008 14:43
El programa chroot (8) de UNIX esno diseñado como un software de seguridad: tienes razón, pero Apache mod_chroot no tiene nada que ver con ese programa. Simplemente utiliza la llamada al sistema chroot (2) para aislar a Apache del resto del sistema.

an; si no lo está, simplemente instale un Centos 5.2 con SELinux habilitado en una máquina virtual. No debería ser demasiado trabajo, y mucho más seguro que cualquier chrooting aficionado, que no es tan seguro como la mayoría de la gente cree. SELinux tiene la reputación de ser difícil de administrar, pero si solo está ejecutando un servidor web, eso no debería ser un problema. Es posible que tenga que hacer algunos "sebool" para permitir que httpd se conecte a la base de datos, pero eso es todo.

 Tim Post30 dic. 2008 12:17
Los ganchos LSM están bastante muertos y no se aplican aquí.

CHRoot Jails rara vez es una buena idea ya que, a pesar de la intención, es muy fácil de romper, ¡de hecho lo he visto hecho por usuarios accidentalmente!

a imagen de la misma, por lo que puede re-rodar si es necesario. De esa manera, el servidor se abstrae de su computadora real, y cualquier virus, etc., está contenido dentro de la máquina virtual. Como dije antes, si mantiene una imagen como copia de seguridad, puede restaurarla a su estado anterior con bastante facilidad.

¿Qué problema estás realmente tratando de resolver? Si te importa lo que hay en ese servidor, necesitas evitar que entren intrusos. debe restringir las capacidades del servidor en sí.

Ninguno de estos problemas podría resolverse con la virtualización, sin dañar gravemente el servidor en sí. Creo que la verdadera respuesta a tu problema es esta:

ejecute un sistema operativo que le brinde un mecanismo sencillo para las actualizaciones del sistema operativo.Utilice el software suministrado por el proveedor.copia de seguridad de todo a menudo.
 Mark Baker29 sept. 2008 10:54
Si bien todo esto es básicamente cierto, algún tipo de caja de arena proporciona una capa adicional de seguridad útil. Si vale la pena hacer esto depende de cuánto más haya en el servidor: si el único uso de la máquina es ser un servidor web, no tiene mucho sentido colocar el servidor web en una caja de arena.
Solución de preguntas

ando un entorno completo de espacio aislado. Los atacantes tienen acceso completo a la funcionalidad del kernel y, por ejemplo, pueden montar unidades para acceder al sistema "host".

Le sugiero que use linux-vserver. Puede ver linux-vserver como una jaula chroot mejorada con una instalación completa de Debian en su interior. Es realmente rápido, ya que se ejecuta dentro de un solo kernel, y todo el código se ejecuta de forma nativa.

Personalmente uso linux-vserver para la separación de todos mis servicios y solo hay diferencias de rendimiento apenas perceptibles.

Echa un vistazo a lalinux-vserver wiki para las instrucciones de instalación.

Saludos, Dennis

OpenVZ en lugar.

Es similar a Linux-Vserver, por lo que es posible que desee comparar esos dos cuando vaya por esta ruta.

He configurado un servidor web con un servidor proxy http (nginx), que luego delega el tráfico a diferentes contenedores de OpenVZ (según el nombre de host o la ruta solicitada). Dentro de cada contenedor puede configurar Apache o cualquier otro servidor web (por ejemplo, nginx, lighttpd, ..). De esta manera, no tiene un Apache para todo, pero podría crear un contenedor para cualquier subconjunto de servicios (por ejemplo, por proyecto).

Los contenedores OpenVZ pueden actualizarse con bastante facilidad ("for i in $ (vzlist); realice la actualización de apt-get de vzctl; listo")

Los archivos de los diferentes contenedores se almacenan en el nodo de hardware y, por lo tanto, puede acceder a ellos fácilmente mediante SFTP en el nodo de hardware. Aparte de eso tupodría agregue una dirección IP pública a algunos de sus contenedores, instale SSH allí y luego acceda a ellos directamente desde el contenedor. Incluso he escuchado de los proxy SSH, por lo que la dirección IP pública adicional puede ser innecesaria incluso en ese caso.

Su respuesta a la pregunta