files – ¿Cuáles son los permisos del sistema más apropiados para sitios en alojamiento compartido?

Pregunta:

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 en 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 existan 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.
  • No se debería proporcionar ningún directorio 777, ni siquiera subir directorios. Dado que el proceso php se ejecuta como propietario de los archivos, obtiene los permisos de los propietarios y puede escribir incluso en un directorio 755.

Respuesta:

Opciones de hospedaje

Las opciones de alojamiento para un sitio web son generalmente 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 propia computadora.

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 es que 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 asume que la cuenta del propietario es "tom" y que el archivo de configuración (que contiene las credenciales de la base de datos) se llama "settings.php".

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

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

Antes de continuar con la discusión de 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 acceso al directorio de acceso a todos los directorios que componen el sitio.
  2. Para un funcionamiento seguro, el servidor web no debe tener acceso de escritura a ninguno de los archivos que maneja.
  3. Para un funcionamiento seguro, un script web ejecutado por un usuario malintencionado no debe tener acceso de lectura a los archivos propiedad de otro usuario.
  4. Para que el propietario pueda trabajar en su propio sitio utilizando la CLI, el usuario debe tener acceso de lectura y escritura a sus propios archivos.
  5. Para evitar que otros usuarios accedan a los archivos mediante la CLI, el bloque "otros" no debe tener ningún permiso establecido.

Desafortunadamente, en un host compartido, solo puede tener 4 de 5. No conozco ninguna forma de que pueda satisfacer las cinco condiciones en un host compartido.

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

Configuración 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 malintencionado no puede utilizar 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 para evitar el acceso de escritura del servidor web a todo excepto al 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 se puede satisfacer. Es decir, el sitio no se puede mantener a través de la CLI. El propietario se verá 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 de ensayo donde tenga acceso sin restricciones y refleje los cambios realizados en el servidor de ensayo en el host compartido ).

Configuración 2: el servidor web se está ejecutando como miembro del grupo www

Esta configuración es utilizada por algunos (en mi humilde opinión) proveedores menos profesionales de una solución de host compartido. El servidor web se ejecuta 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

Esta configuración tiene la ventaja de brindar al propietario acceso completo a sus archivos a través de la CLI y restringe el servidor web al acceso de solo lectura.

Sin embargo, tampoco cumple con la condición 3. Es decir, permite que un usuario deshonesto en el host compartido (o un pirata informático que haya comprometido el sitio de otro usuario que comparte el host) ejecute un script para leer cualquier archivo que pueda ser leído por 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 utilizar un host compartido?

Ciertamente no pondría nada sensible, como números de tarjetas de crédito o registros médicos, en un host compartido. Pero el alojamiento compartido es barato y hay un atractivo en eso. Yo mismo utilizo hosting compartido para varios de mis sitios. Todavía no me han pirateado, pero sé que el riesgo existe y estoy preparado para el día en que suceda. Si soy pirateado, simplemente eliminaré todo en el host compartido y reinstalaré el sitio desde una copia espejo que guardo en un servidor de prueba 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 un almuerzo. Hacer que la seguridad dependa de otra parte que no conoce y sobre la que no tiene control no es una buena idea. Es por eso que mi recomendación es evitar los arreglos de hospedaje del tipo "config 2".

Con "config 1", usted solo controla la seguridad de su sitio web. Esto es mejor (en particular si sabe lo que está haciendo). Pero no es infalible. Nadie es perfecto, y si comete un error y su sitio se ve comprometido, el atacante tendrá acceso a todos los archivos almacenados en ese host que le pertenece. En otras palabras, para minimizar el daño cuando es pirateado, no guarde nada en ese host que pueda causar daño si alguien más accede 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 los querrá cerca de un servidor web que se ejecute como "usted".

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

Es posible que también desee ver esta guía para proteger los permisos y la propiedad de los archivos en Drupal.org.

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım