La mejor manera de sandbox Apache en Linux

Question

Tengo Apache ejecutándose en un servidor Debian de uso público, y estoy un poco preocupado por la seguridad de la instalación. Esta es una máquina que aloja varios proyectos de hobby de tiempo libre, por lo que ninguno de nosotros que usemos la máquina realmente tenemos tiempo para observar constantemente los parches, estar al tanto de los problemas de seguridad, etc. Pero me gustaría mantener alejados a los malos. , o si entran, mantenlos en una caja de arena.

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

Answer 1

Las cárceles de Chroot pueden ser realmente inseguras cuando se ejecuta un entorno de recinto de seguridad completo. Los atacantes tienen acceso completo a la funcionalidad del kernel y, por ejemplo, pueden montar unidades para acceder al sistema "host".

Le sugiero que utilice linux-vserver. Puedes ver linux-vserver como una cárcel chroot mejorada con una instalación Debian completa dentro. Es realmente rápido, ya que se ejecuta dentro de un kernel único, y la ejecución de todos los códigos es una forma nativa.

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

Eche un vistazo a linux-vserver wiki para obtener instrucciones de instalación.

respecto, Dennis

Answer 2

Siempre se puede configurar dentro de una máquina virtual y conservar una imagen de la misma, para que pueda volver a lanzarla si es necesario. De esta forma, 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 restaurar su estado anterior de manera bastante fácil.

Answer 3

Haga una máquina virtual. intente algo como vmware o qemu

Answer 4

para asegurarse de que se dice, CHROOT cárceles están rara vez es una buena idea es, a pesar de la intención, muy fácil de romper, de hecho lo he visto hecho por los usuarios accidentalmente!

Answer 5

Sin ánimo de ofender, pero si no tiene tiempo para controlar los parches de seguridad y mantenerse al tanto de los problemas de seguridad, debe preocuparse, independientemente de su configuración. Por otro lado, el mero hecho de que esté pensando en estos temas lo diferencia del otro 99.9% de los propietarios de dichas máquinas. ¡Estás en el camino correcto!

Answer 6

En segundo lugar lo que dice xardias, pero en su lugar, recomiende OpenVZ.

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

He configurado un servidor web con un proxy http server (nginx), que luego delega el tráfico a diferentes contenedores 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 forma, no tiene un Apache para todo, pero podría crear un contenedor para cualquier subconjunto de servicios (por ejemplo, por proyecto).

contenedores OpenVZ puede ser bastante fácil de actualizar por completo ("for i in $ (vzlist); hacer vzctl ejecutivo de apt-get upgrade; hecho")

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

Answer 7

¿Qué problema estás tratando de resolver realmente? Si le importa qué hay en ese servidor, debe evitar que entren los intrusos. Si te importa lo que los intrusos harían con tu servidor, debes restringir las capacidades del servidor.

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

1. ejecute un sistema operativo que le proporciona un mecanismo fácil para las actualizaciones del sistema operativo.
2. utilice el software suministrado por el proveedor.
3. copia de seguridad de todo a menudo.

Answer 8

Me resulta sorprendente que nadie mencionó mod_chroot y suEXEC, que son las cosas básicas que usted debe comenzar con, y, muy probablemente las únicas cosas que necesita.

Answer 9

Debe usar SELinux. No sé qué tan bien es compatible con Debian; si no es así, solo 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 aficionado al chrootismo, que no es tan seguro como la mayoría de la gente cree. SELinux tiene una reputación de ser difícil de administrar, pero si solo está ejecutando un servidor web, eso no debería ser un problema. Puede que tenga que hacer algunos "sebool" para permitir que httpd se conecte a la base de datos, pero eso es todo.

Answer 10

Si bien todas las anteriores son buenas sugerencias, 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 los exploits web automatizados es descargar el resto de su carga, evitando que la conexión de red pueda ralentizar al atacante.

Se pueden usar algunas reglas similares (Tenga cuidado, su servidor web puede necesitar acceso a otros protocolos): iptables --append OUTPUT -m owner --uid-owner apache -m state --state ESTABLECIDO, RELACIONADO - -jump ACEPTAR iptables --append OUTPUT -m propietario -uid-owner apache --protocol udp -destination-port 53 --jump ACEPTAR iptables --append OUTPUT -m owner --uid-owner apache --jump RECHAZAR

Answer 11

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