¿Cuáles son los usuarios y niveles de permisos más adecuados para los sitios de Drupal en alojamiento compartido?

Aunque el sitio de Drupal entra en gran detalle sobre los permisos y la seguridad, solo hay referencias vagas / poco claras al alojamiento compartido . Desde el punto de vista de Drupal, ¿cuál es la configuración más segura (niveles de propiedad y permisos) para un sitio de alojamiento compartido?

Como ejemplo del tipo de información que estoy buscando, WordPress sugiere la siguiente configuración de alojamiento compartido:

• Todos los archivos deben ser propiedad de la cuenta del usuario real, no de la cuenta de usuario utilizada para el proceso httpd.
• La propiedad del grupo es irrelevante, a menos que haya requisitos de grupo específicos para la verificación de permisos del proceso del servidor web. Este no suele ser el caso.
• Todos los directorios deben ser 755 o 750.
• Todos los archivos deben ser 644 o 640. Excepción: wp-config.php debe ser 600 para evitar que otros usuarios del servidor lo lean.
• Ningún directorio debería recibir 777, incluso subir directorios. Dado que el proceso php se ejecuta como el propietario de los archivos, obtiene los permisos de los propietarios y puede escribir incluso en un directorio 755.

Opciones de alojamiento

Las opciones de alojamiento para un sitio web generalmente son una de las siguientes:

• servidor dedicado
• servidor privado virtual (VPS)
• alojamiento compartido

Con un servidor dedicado, solo un sitio está alojado en una computadora física, y la configuración es tan segura como la computadora misma.

Con un VPS, su software se ejecuta en la misma computadora física que las máquinas virtuales de otros usuarios. Sin embargo, es funcionalmente equivalente a un servidor dedicado. Lo más importante, un VPS tiene la privacidad y seguridad de un servidor dedicado.

Con el alojamiento compartido, su sitio web reside en un sistema de archivos compartido con otros usuarios. Esto, desafortunadamente, lo hace menos seguro que cuando se ejecuta en un servidor dedicado o VPS. El resto de este artículo analiza la seguridad de un WCMS en un entorno de alojamiento compartido.

Ambiente

Se puede considerar que un entorno de alojamiento compartido consta de un servidor web, un sistema de archivos, un archivo de configuración, una base de datos y algunos usuarios.

En los siguientes ejemplos, se supone que la cuenta del propietario es "tom" y que el archivo de configuración (que contiene las credenciales de la base de datos) se denomina "settings.php".

El proceso del servidor web puede ejecutarse con los permisos de usuario de la cuenta del propietario "tom", o con permisos de grupo del grupo "www", dependiendo de la configuración.

Además, se supone un entorno estándar de Gnu / Linux o Unix, y se supone que el lector comprende el sistema de control de acceso Unix con permisos de lectura (r), escritura (w) y directorio de ejecución / acceso separados (x) separados en tres bloques. (usuario, grupo, otro).

Antes de continuar discutiendo configuraciones específicas, puede ser útil enumerar las condiciones que queremos satisfacer:

1. Para que un sitio web esté operativo, el servidor web debe tener acceso de lectura a todos los archivos que componen el sitio, y acceder al directorio de acceso a todos los directorios que lo componen.
2. Para una operación segura, el servidor web no debe tener acceso de escritura a ninguno de los archivos que maneja.
3. Para una operación segura, un script web ejecutado por un usuario no autorizado no debe tener acceso de lectura a los archivos que son propiedad de otro usuario.
4. Para que el propietario trabaje en su propio sitio utilizando la CLI, el usuario debe tener acceso de lectura y escritura a sus propios archivos.
5. Para proteger los archivos contra el acceso de otros usuarios mediante la CLI, el "otro" bloque debe tener ningún conjunto de permisos.

Desafortunadamente, en un host compartido, solo puede tener 4 de 5. No sé de qué manera puede satisfacer las cinco condiciones en un host compartido.

Hasta donde yo sé, los proveedores de host compartidos utilizan dos configuraciones diferentes. Ambos se analizan a continuación, junto con los permisos para usar para proteger mejor los archivos y directorios, y qué condición no cumple la configuración.

Config 1: el servidor web se ejecuta como propietario

Esta es AFAIK la configuración más utilizada. El servidor web se ejecuta como propietario de los archivos. Esto significa que un usuario deshonesto no puede usar el usuario de su servidor web para ejecutar un script para leer los archivos de otro usuario. Este tipo de configuración también protege a los usuarios entre sí en la CLI.

Sin embargo, también significa que no podemos tener permisos separados para el propietario y el servidor web. Para satisfacer la condición 2 con este tipo de configuración, debe restringir los permisos de escritura para el propietario a fin de evitar el acceso de escritura para el servidor web a todo excepto el directorio de carga.

Permisos:

Directories:  500 r-x --- --- tom.tom
Files:        400 r-- --- --- tom.tom
settings.php: 400 r-- --- --- tom.tom
Upload Dir.:  700 rwx --- --- tom.tom

Desafortunadamente, esto significa que la condición 4 no puede cumplirse. Es decir, el sitio no se puede mantener a través de la CLI. El propietario estará obligado a utilizar algún tipo de panel de control basado en la web para acceder al sitio (mi recomendación es que el propietario mantenga una copia en algún servidor intermedio donde tenga acceso sin restricciones y refleje los cambios realizados en el servidor intermedio al host compartido )

Config 2: el servidor web se ejecuta como miembro del grupo www

Algunos proveedores menos profesionales (en mi humilde opinión) utilizan esta configuración de una solución de host compartida. El servidor web se está ejecutando como miembro del grupo www y se le otorga el acceso de lectura requerido a través del bloque de grupo:

Permisos:

Directories:  750 rwx r-x --- tom.www
Files:        640 rw- r-- --- tom.www
settings.php: 640 rw- r-- --- tom.www
Upload Dir.:  770 rwx rwx --- tom.www

Estas configuraciones tienen la ventaja de dar al propietario acceso completo a sus archivos a través de la CLI, y restringe el servidor web a solo acceso de lectura.

Sin embargo, tampoco cumple la condición 3. Es decir, permite que un usuario deshonesto en el host compartido (o un hacker que haya comprometido el sitio de otro usuario que comparte el host) ejecute un script para leer cualquier archivo que pueda leer el Servidor web. Esto le da al script falso acceso al archivo settings.php con las credenciales de la base de datos, lo que hace que sea trivial hacerse cargo del sitio por completo.

Mi recomendación es evitar este tipo de configuración.

Anexo: ¿Qué tan peligroso es usar un host compartido?

Ciertamente no pondría nada sensible, como números de tarjeta de crédito o registros médicos, en un host compartido. Pero el alojamiento compartido es barato, y hay una atracción en eso. Yo uso hosting compartido para varios de mis sitios. Todavía no he sido hackeado, pero sé que existe el riesgo y estoy preparado para el día en que ocurra. Si soy pirateado, simplemente eliminaré todo en el host compartido y reinstalaré el sitio desde una copia espejo que guardo en un servidor de almacenamiento seguro.

Con "config 2", el principal problema son los demás . Si algún otro sitio web con el que comparte el host se ve comprometido, su sitio web también es el almuerzo. Hacer que la seguridad dependa de otra parte que no conoces y que no tienes control no es una buena idea. Es por eso que mi recomendación es evitar los arreglos de alojamiento de tipo "config 2".

Con "config 1", usted solo controla la seguridad de su sitio web. Esto es mejor (en particular si sabes lo que estás haciendo). Pero no es infalible. Nadie es perfecto, y si te burlas y tu sitio se ve comprometido, el atacante tendrá acceso a todos los archivos almacenados en ese host que te pertenece. En otras palabras, para minimizar el daño cuando eres pirateado, no guardes nada en ese host que pueda causar daño si alguien más tiene acceso a él. En particular, no guarde su correo electrónico en ese host compartido. Por lo general, hay toneladas de datos confidenciales en el correo electrónico, por lo que no desea que esté cerca de un servidor web que se ejecute como "usted".

Y si su aplicación web maneja datos confidenciales, asegúrese de que su presupuesto permita un host dedicado o un VPS.

También puede consultar esta guía para asegurar los permisos y la propiedad de los archivos en Drupal.org.