Alojamiento de sitios múltiples: ¿se pierde una vulnerabilidad importante para proteger los sitios entre sí?

EDITAR # 2 23 de julio de 2015: en busca de una nueva respuesta que identifique un elemento de seguridad importante que se perdió en la configuración a continuación o puede dar razones para creer que todo está cubierto.

EDITAR # 3 29 de julio de 2015: Estoy buscando especialmente una posible configuración incorrecta, como permitir involuntariamente algo que podría explotarse para eludir las restricciones de seguridad o, peor aún, dejar algo abierto.

Esta es una configuración de alojamiento compartido / multi-sitio y queremos usar una instancia de Apache compartida (es decir, se ejecuta bajo una cuenta de usuario) pero con PHP / CGI ejecutándose como usuario de cada sitio web para garantizar que ningún sitio pueda acceder a los archivos de otro sitio, y queremos asegúrese de que no se pierda nada (por ejemplo, si no supiéramos sobre la prevención de ataques de enlace simbólico)

Esto es lo que tengo hasta ahora:

• Asegúrese de que los scripts PHP se ejecuten como la cuenta y el grupo de usuarios de Linux del sitio web, y que estén encarcelados (como el uso de CageFS) o al menos correctamente restringidos con los permisos del sistema de archivos de Linux.
• Use suexec para asegurarse de que los scripts CGI no se puedan ejecutar como usuario de Apache.
• Si necesita soporte del lado del servidor (como en archivos shtml), úselo Options IncludesNOEXECpara evitar que se pueda ejecutar CGI cuando no lo espera (aunque esto no debería ser una gran preocupación si usa suexec).
• Tenga una protección contra ataques de enlace simbólico para que un hacker no pueda engañar a Apache para que sirva los archivos de otro sitio web como texto sin formato y revele información explotable como contraseñas de DB.
• Configure AllowOverride/ AllowOverrideListpara permitir solo cualquier directiva que un hacker no pueda explotar. Creo que esto es menos preocupante si los elementos anteriores se realizan correctamente.

Me gustaría usar MPM ITK si no fuera tan lento y no se ejecutara como root, pero queremos usar un Apache compartido y asegurarnos de que se haga de forma segura.

Encontré http://httpd.apache.org/docs/2.4/misc/security_tips.html , pero no fue exhaustivo sobre este tema.

Si es útil saberlo, estamos planeando usar CloudLinux con CageFS y mod_lsapi.

¿Hay algo más que hacer o saber?

EDITAR el 20 de julio de 2015: la gente ha presentado algunas buenas soluciones alternativas que son valiosas en general, pero tenga en cuenta que esta pregunta está dirigida solo con respecto a la seguridad de una configuración de Apache compartida. Específicamente, ¿hay algo no cubierto anteriormente que podría permitir que un sitio acceda a los archivos de otro sitio o comprometer a otros sitios de alguna manera?

¡Gracias!

Estoy completamente de acuerdo con los artículos que tienes hasta ahora.

Solía ​​ejecutar una configuración multiusuario hace unos años y básicamente encontré la misma compensación: mod_php es rápido (en parte porque todo se ejecuta dentro del mismo proceso) y suexec es lento pero seguro (porque cada solicitud bifurca un nuevo proceso). Fui con suexec, porque se requería el aislamiento del usuario.

Actualmente hay una tercera opción que podría considerar: dar a cada usuario su propio demonio php-fpm. Si esto es factible depende de la cantidad de usuarios, porque cada uno de ellos tiene que obtener al menos un proceso php-fpm utilizando su cuenta de usuario (el demonio luego usa un mecanismo similar a prefork para escalar las solicitudes, por lo que la cantidad de procesos y su uso de memoria puede ser factores limitantes). También necesitará una generación de configuración automatizada, pero eso debería ser posible con algunos scripts de shell.

No he usado ese método en entornos grandes, pero en mi humilde opinión, es una buena solución para proporcionar un buen rendimiento del sitio web de PHP sin dejar de aislar a los usuarios en el nivel de proceso.

Todo lo que tienes hasta ahora parece bien pensado. Lo único que pude ver como un problema es el hecho de que la mayoría de los exploits buscan obtener acceso root de una forma u otra. Entonces, incluso si cada sitio y sus procesos y scripts correspondientes están encarcelados correctamente y todo tiene su propio usuario y los permisos que un pirata informático con root no podría importarle menos, simplemente eludirán todo lo que haya configurado.

Mi sugerencia sería usar algún tipo de software de VM (VMware, VirtualBox, Qemu, etc.) para dar a cada sitio su propia cárcel del sistema operativo. Esto le permite, como administrador del sistema, no preocuparse por un solo sitio comprometido. Si un hacker obtiene root al explotar php (o cualquier otro software) en la VM de un sitio, simplemente detenga la VM y diseccione más tarde, aplique correcciones o regrese a un estado ininterrumpido. Esto también permite que los administradores del sitio apliquen un software específico o una configuración de seguridad a su entorno de sitio específico (que podría romper otro sitio).

La única limitación a esto es su hardware, pero con un servidor decente y las extensiones de kernel correctas es fácil de manejar. Ejecuté con éxito este tipo de configuración en un Linode, siempre y cuando el Anfitrión y el Invitado fueran muy escasos. Si te sientes cómodo con la línea de comando que supongo que no deberías tener ningún problema.

Este tipo de configuración reduce la cantidad de vectores de ataque que debe monitorear y le permite concentrarse en la seguridad de las máquinas host y tratar con todo lo demás sitio por sitio.

Sugeriría que cada sitio se ejecute bajo su propio demonio Apache y apache Apache. Toda la función php del sistema fallará ya que el entorno chroot de Apache no tendrá acceso a / bin / sh. Esto también significa que la función php (mail) no funcionará, pero si está utilizando un proveedor de correo externo para enviar correo desde su aplicación de correo electrónico, entonces esto no debería ser un problema para usted.

SELinux puede ser útil con mod_selinux. Aquí se presenta un tutorial rápido:

¿Cómo puedo usar SELinux para limitar los scripts PHP?

Como las instrucciones están un poco anticuadas, verifiqué si esto funciona en RHEL 7.1:

Utilicé la versión de Fedora 19 y compilé con simulacro contra RHEL 7.1 + EPEL.

YMMV si utiliza la simulación básica de configuración de epel se envía con:

[mockbuild@fedora mod_selinux]$ mock -r rhel-7-x86_64 --rebuild \
    mod_selinux-2.4.3-2.fc19.src.rpm

Actualice su sistema de destino primero para asegurarse de que selinux-policyesté actualizado.

Instale en el cuadro de destino (o colóquelo primero en su espejo local):

yum localinstall mod_selinux-2.4.3-2.el7.x86_64.rpm

Ahora, debe asignar a cada host virtual en Apache una categoría. Esto se hace agregando una línea como en el ejemplo a continuación llamado selinuxDomainVal.

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host1
    ServerName host1.virtual
    selinuxDomainVal *:s0:c0
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host2
    ServerName host2.virtual
    selinuxDomainVal *:s0:c1 
</VirtualHost>

A continuación, en la raíz del documento para cada host, vuelva a etiquetar sus raíces del documento en la misma categoría que las etiquetadas en la configuración httpd.

chcon -R -l s0:c0 /var/www/vhosts/host1
chcon -R -l s0:c1 /var/www/vhosts/host2

Si desea que se respete el etiquetado si realiza un cambio de etiqueta del sistema, ¡es mejor que también actualice la política local!

semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c0 '/var/www/vhosts/host1(/.*)?' 
semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c1 '/var/www/vhosts/host2(/.*)?'

Ya hay muchas buenas respuestas técnicas proporcionadas (también eche un vistazo aquí: https://security.stackexchange.com/q/77/52572 y Consejos para asegurar un servidor LAMP ), pero aún me gustaría mencionar aquí Un punto importante (desde otra perspectiva) sobre la seguridad: la seguridad es un proceso . Estoy seguro de que ya ha considerado esto, pero todavía espero que pueda ser útil (también para otros lectores) a veces repensarlo.

Por ejemplo, en su pregunta, usted se concentra principalmente en las medidas técnicas: "esta pregunta está dirigida solo con respecto a la seguridad de una configuración de Apache compartida. Específicamente, ¿hay pasos de seguridad que sean importantes para tomar pero que faltan en la lista anterior cuando se ejecuta compartido Apache y PHP ".

Casi todas las respuestas aquí y en otras 2 preguntas que mencioné también parecen ser puramente técnicas (excepto la recomendación de mantenerse actualizado). Y desde mi punto de vista, esto podría hacer que algunos lectores tengan una impresión engañosa, que si configura su servidor de acuerdo con las mejores prácticas una vez, entonces se mantendrá seguro para siempre. Así que por favor no te olvides de los puntos que pierdo en las respuestas:

1. En primer lugar, no olvide que la seguridad es un proceso y, en particular, sobre el ciclo "Plan-Do-Check-Act", como recomiendan muchas normas, incluida la ISO 27001 ( http://www.isaca.org/ Journal / archives / 2011 / Volume-4 / Pages / Planning-for-and-Implementing-ISO27001.aspx ). Básicamente, esto significa que necesita revisar periódicamente sus medidas de seguridad, actualizarlas y probarlas .

2. Actualice regularmente su sistema. Esto no ayudará contra ataques dirigidos utilizando vulnerabilidades de día cero, pero ayudará contra casi todos los ataques automatizados.

3. Monitoree su sistema. Realmente extraño este punto en las respuestas. Desde mi punto de vista, es extremadamente importante que se le notifique lo antes posible sobre algún problema con su sistema.

   Esto es lo que las estadísticas dicen al respecto: "El tiempo promedio desde la infiltración hasta el descubrimiento es de 173.5 días" ( http://www.triumfant.com/detection.html ), "205 mediana de días antes de la detección" ( https: // www2 .fireeye.com / rs / fireye / images / rpt-m-trends-2015.pdf ). Y espero que estos números no sean lo que todos queremos tener.

   Existen muchas soluciones (incluidas las gratuitas) no solo para monitorear el estado del servicio (como Nagios), sino también para los sistemas de detección de intrusos (OSSEC, Snort) y los sistemas SIEM (OSSIM, Splunk). Si se vuelve demasiado complicado, al menos podría habilitar algo como 'fail2ban' y / o reenviar sus registros para separar el servidor syslog y recibir notificaciones por correo electrónico sobre eventos importantes.

   Nuevamente, el punto más importante aquí no es el sistema de monitoreo que elija, lo más importante es que tenga un poco de monitoreo y lo revise regularmente de acuerdo con su ciclo "Plan-Do-Check-Act" .

4. Tenga en cuenta las vulnerabilidades. Igual que el monitoreo. Simplemente suscríbase a alguna lista de vulnerabilidades para recibir una notificación, cuando se descubra alguna vulnerabilidad crítica para Apache u otro servicio importante para su configuración. El objetivo es recibir notificaciones sobre las cosas más importantes que aparecen antes de su próxima actualización planificada.

5. Tenga un plan de qué hacer en caso de un incidente (y actualícelo y revíselo regularmente de acuerdo con su ciclo "Planificar-Hacer-Verificar-Actuar"). Si hace preguntas sobre la configuración segura, significa que la seguridad de su sistema se vuelve importante para usted. Sin embargo, ¿qué debe hacer en caso de que su sistema sea pirateado a pesar de todas las medidas de seguridad? Una vez más, no me refiero solo a medidas técnicas aquí como "reinstalar el sistema operativo": ¿Dónde debe informar un accidente de acuerdo con la ley aplicable? ¿Se le permite apagar / desconectar su servidor de inmediato (cuánto cuesta para su empresa)? ¿A quién se debe contactar si la persona responsable principal está de vacaciones / enferma?

6. Tener un servidor de respaldo, archivo y / o reemplazo / replicación. La seguridad también significa la disponibilidad de su servicio. Verifique su copia de seguridad / archivo / replicación regularmente y también pruebe los procedimientos de restauración regularmente.

7. ¿Pruebas de penetración? (de nuevo, vea el ciclo "Planificar-Hacer-Verificar-Actuar" :) Si parece demasiado, al menos podría probar algunas herramientas en línea gratuitas, que escanean sus servicios web en busca de malware y problemas de seguridad.

Su caso de uso es ideal para contenedores acoplables.

Cada contenedor puede representar a un cliente o cliente, con identificaciones de usuario únicas asignadas a cada grupo de contenedores de Apache como seguridad adicional. La clave sería soltar los privilegios de root al iniciar el contenedor, antes de comenzar su pila de apache. Cada cliente obtiene su propio servicio de base de datos con sus propias contraseñas únicas, sin el dolor de cabeza de poner de pie docenas de máquinas virtuales, cada una de las cuales requiere sus propios núcleos especiales de copos de nieve y otros gastos generales. Después de todo, en el corazón de Docker está el chroot. Bien administrado, lo tomaría sobre un clúster virtual típico cualquier día.

Muchas buenas sugerencias aquí ya. Sin embargo, hay cosas que se han perdido en la discusión hasta ahora.

Preste atención a los procesos externos a los que se ejecutan como parte de las páginas web de servicio. es decir, asegúrese de que todos sus trabajos cron que toquen datos no confiables se ejecuten como el usuario apropiado y en la cárcel apropiada, ya sea que dichos trabajos sean definidos por el usuario o no.

En mi experiencia, cosas como el análisis de registros, cuando son proporcionadas por el servicio de alojamiento, se ejecutan como root casi tan a menudo como no, y el software de análisis de registros no recibe tanta auditoría de seguridad como nos gustaría. Hacer esto bien es un poco complicado y depende de la configuración. Por un lado, no desea que su proceso de apache propiedad de la raíz (es decir, el proceso principal) se escriba en ningún directorio que el usuario pueda comprometer. Eso probablemente significa no escribir directamente en la cárcel. Por otro lado, debe hacer que esos archivos estén disponibles para los procesos en la cárcel para su análisis, y le gustaría que esté lo más cerca posible del tiempo real. Si puede dar a sus cárceles acceso a un montaje de solo lectura de un sistema de archivos con los registros, eso debería ser bueno.

Las aplicaciones PHP generalmente no sirven sus propios archivos estáticos, y si tiene un proceso de apache compartido, ¿supongo que su proceso de apache está leyendo cosas directamente de las cárceles del entorno host? Si es así, eso abre una variedad de preocupaciones.

.htaccesslos archivos son obvios, donde deberías tener mucho cuidado con lo que permites. Muchas, si no la mayoría, de las aplicaciones php más importantes dependen mucho de los arreglos de archivos .htaccess que probablemente no puedas permitir sin subvertir tu esquema planificado.

Menos obvio es cómo apache decide qué es un archivo estático de todos modos. por ejemplo, ¿qué hacer con una *.php.gifo *.php.enarchivo? Si este mecanismo u otro engaña la discriminación en cuanto a qué es un archivo estático, ¿es posible que apache ejecute php desde fuera de la cárcel? Instalaría un servidor web liviano separado para contenido estático, que no está configurado con ningún módulo para ejecutar contenido dinámico, y tengo un equilibrador de carga que decide qué solicitudes enviar al servidor estático y cuáles al dinámico.

Con respecto a la sugerencia de Stefan Docker, es posible tener un único servidor web que se encuentre fuera del contenedor y que hable con los demonios php en cada contenedor para el contenido dinámico, mientras que también tenga un segundo servidor web, que se encuentra en un contenedor docker, y que comparte los volúmenes que cada uno usa para su contenido y, por lo tanto, puede servir el contenido estático, que es muy similar al del párrafo anterior. Recomiendo Docker entre los diversos enfoques de tipo de cárcel, pero con este u otros enfoques de tipo de cárcel, tendrá un montón de otros problemas para resolver. ¿Cómo funciona la carga de archivos? ¿Pones demonios de transferencia de archivos en cada contenedor? ¿Adoptas un enfoque basado en git estilo PAAS? ¿Cómo hacer que los registros generados dentro del contenedor sean accesibles? y darles la vuelta? ¿Cómo gestiona y ejecuta trabajos cron? ¿Vas a dar a los usuarios algún tipo de acceso de shell, y si es así, es ese otro demonio dentro del contenedor? etcétera etcétera.

Lo primero que no veo es la gestión de procesos, por lo que un proceso no puede privar a otro proceso de CPU o RAM (o E / S para el caso, aunque su sistema de archivos puede estar diseñado para evitar eso). Una ventaja importante de un enfoque de "contenedores" para sus instancias de PHP en lugar de intentar ejecutarlas todas en una imagen de "SO" es que puede restringir mejor la utilización de los recursos de esa manera. Sé que ese no es tu diseño, pero eso es algo a considerar.

De todos modos, volviendo al caso de uso de PHP que se ejecuta detrás de Apache, básicamente funciona como un proxy. suexec no evita que algo se ejecute como usuario de apache, sino que brinda la capacidad de ejecutarse como otro usuario. Entonces, una preocupación es asegurarse de que todo se haga correctamente: la página del documento indica ese peligro potencial: https://httpd.apache.org/docs/2.2/suexec.html . Entonces, ya sabes, grano de sal y todo eso.

Desde un punto de vista de la seguridad, puede ser útil contar con un conjunto restringido de los binarios de usuario para trabajar con (que cagefs suministros), sobre todo si se compilan de manera diferente o en contra de una biblioteca diferente (por ejemplo, uno que no incluye capacidades que no son deseados) , pero la El peligro es que en ese momento ya no siga una distribución conocida de actualizaciones, siga una distribución diferente (cagefs) para sus instalaciones de PHP (al menos con respecto a las herramientas de espacio de usuario). Sin embargo, dado que probablemente ya esté siguiendo una distribución específica con cloudlinux, es un riesgo incremental, no necesariamente interesante por sí solo.

Dejaría AllowOverride en el lugar donde podría haberlo pensado. La idea central detrás de la defensa en profundidad es no confiar en una sola capa para proteger toda su pila. Siempre asuma que algo puede salir mal. Mitigar cuando eso suceda. Repita hasta que haya mitigado lo mejor posible, incluso si solo tiene una cerca frente a sus sitios.

La gestión de registros será clave. Con múltiples servicios ejecutándose en sistemas de archivos aislados, la integración de actividades para correlacionar cuando hay un problema podría ser un problema menor si no lo ha configurado desde el principio.

Ese es mi cerebro volcado. Espero que haya algo vagamente útil allí. :)