Vserver: correos seguros de un Webservice hackeado

Planeo alquilar y configurar un vServer con Debian xor CentOS. Sé por mi anfitrión, que los vServers están virtualizados con linux-vserver.

Suponga que hay un lighthttpd y algún agente de transferencia de correo funcionando y tenemos que asegurar que si el lighthttpd será hackeado, los correos electrónicos almacenados no son fácilmente legibles.

Para mí, esto suena imposible, pero puede que me perdí algo o al less ustedes pueden validar la imposibilidad … 🙂

Creo que básicamente hay tres enfoques obvios.

La primera es cifrar todos los datos. Sin embargo, el server tendría que almacenar la key en algún sitio para que un atacante (w | c) supiera que fuera.

En segundo lugar uno podría aislar los services críticos como lighthttpd. Puesto que no se me permite hacer 'mknod' o remontar / dev en un server linux-vserver, no es posible configurar un vServer nested con lxc o técnicas similares.

El último enfoque sería hacer un chroot pero no estoy seguro de si proporcionaría suficiente security. Además no he probado todavía, si soy capaz de hacer un chroot en un linux-vserver …?

¡Gracias por adelantado!

No es trivialmente posible separar totalmente lighty y mta si funcionan en el mismo OS / espacio de process. Por supuesto, podría intentar evitar que lighty lea el correo a través de permissions de sistema de files, pero supongo que no es lo que tiene en mente. Cifrar los datos no es una opción, el MTA tendrá que leerlo; si alguien entra a través de lighttpd, es probable que también tengan raíz, también, ya que ha habido (y será) numerosas explotaciones locales de raíz para linux últimamente.

Yo recomendaría configurar el MTA en la caja y, además, configurar la virtualización para el service web. O incluso más agradable: poner ambos services en las máquinas virtuales: incluso si el MTA se hackeado (lo que no es totalmente improbable, consulte la vulnerabilidad de la raíz remota exim), su webservice todavía está bien.

BTW: Usted puede romper fácilmente de un chroot, si usted consigue privilegios de la raíz.

"Divide et impera" suele ser la respuesta. Chroot es más bien una herramienta débil comparado con una solución como OpenVZ, pero también hay http://grsecurity.net/ (sí, ambos necesitan que modifiques el kernel). Otros nombres a mencionar son AppArmor y SELinux. Éstos se encuentran bastante a menudo puesto que hay distromakers valiosos detrás de ellos.

Dado que sigue siendo imposible virtualizar en este entorno, seguí buscando y encontré una manera aceptable de aislar los services. Le agradecería que comentara sus dudas, en su caso. Sé que chroot no es una cárcel perfecta, pero debería estar bien.

  1. chroot la web y server de database (utilizando jailkit para networkingucir el dolor)
  2. para cada service chroot'ed, no ejecute el process maestro como root (como se explica aquí para apache)

Saludos.

(Esta es una respuesta tardía, lo sé.)

En Ubuntu (y probablemente en Debian), el package Postfix instalado desde apt ejecuta automáticamente con chroot .
En la mayoría de mis serveres, sólo ejecuto Apache y MySQL como un usuario además de root (que es el pnetworkingeterminado en Ubuntu).

Si observas tus permissions de sistema de files, eso debería ser todo lo que necesitas.