¿Qué permisos deben tener los archivos/carpetas de mi sitio web en un servidor web Linux?

Solución 1:

Al decidir qué permisos usar, necesita saber exactamente quiénes son sus usuarios y qué necesitan. Un servidor web interactúa con dos tipos de usuarios.

Autenticado los usuarios tienen una cuenta de usuario en el servidor y se les pueden proporcionar privilegios específicos. Esto generalmente incluye administradores de sistemas, desarrolladores y cuentas de servicio. Por lo general, realizan cambios en el sistema mediante SSH o SFTP.

Anónimo Los usuarios son los visitantes de su sitio web. Aunque no tienen permisos para acceder a los archivos directamente, pueden solicitar una página web y el servidor web actúa en su nombre. Puede limitar el acceso de usuarios anónimos teniendo cuidado con los permisos que tiene el proceso del servidor web. En muchas distribuciones de Linux, Apache se ejecuta como www-data usuario pero puede ser diferente. Usa ps aux | grep httpd o ps aux | grep apache para ver qué usuario está utilizando Apache en su sistema.

Notas sobre los permisos de Linux

Linux y otros sistemas compatibles con POSIX utilizan permisos tradicionales de Unix. Hay un excelente artículo en Wikipedia sobre los permisos del sistema de archivos, así que no repetiré todo aquí. Pero hay algunas cosas que debe tener en cuenta.

El bit de ejecución
Los scripts interpretados (por ejemplo, Ruby, PHP) funcionan bien sin el permiso de ejecución. Solo los archivos binarios y los scripts de shell necesitan el bit de ejecución. Para atravesar (ingresar) un directorio, debe tener permiso de ejecución en ese directorio. El servidor web necesita este permiso para listar un directorio o servir cualquier archivo dentro de él.

Permisos de archivo nuevos predeterminados
Cuando se crea un archivo, normalmente hereda la identificación de grupo de quien lo creó. Pero a veces desea que los archivos nuevos hereden el ID de grupo de la carpeta donde se crean, por lo que habilitaría el bit SGID en la carpeta principal.

Los valores de permisos predeterminados dependen de su umask. El umask sustrae los permisos de los archivos recién creados, por lo que el valor común de 022 da como resultado que los archivos se creen con 755. Al colaborar con un grupo, es útil cambiar su umask a 002 para que los miembros del grupo puedan modificar los archivos que cree. Y si desea personalizar los permisos de los archivos cargados, debe cambiar el umask para apache o ejecutar chmod después de que se haya cargado el archivo.

El problema con el 777

Cuando chmod 777 su sitio web, no tiene ningún tipo de seguridad. Cualquier usuario del sistema puede cambiar o eliminar cualquier archivo de su sitio web. Pero más en serio, recuerde que el servidor web actúa en nombre de los visitantes de su sitio web, y ahora el servidor web puede cambiar los mismos archivos que está ejecutando. Si hay vulnerabilidades de programación en su sitio web, se pueden explotar para desfigurar su sitio web, insertar ataques de phishing o robar información de su servidor sin que usted lo sepa.

Además, si su servidor se ejecuta en un puerto conocido (que debería evitar que los usuarios que no son root generen servicios de escucha que sean accesibles para todo el mundo), eso significa que su servidor debe iniciarse como root (aunque cualquier servidor cuerdo caerá inmediatamente a una cuenta con menos privilegios una vez que el puerto esté vinculado). En otras palabras, si está ejecutando un servidor web donde el ejecutable principal es parte del control de versión (por ejemplo, una aplicación CGI), dejando sus permisos (o, para el caso, los permisos del directorio que lo contiene, ya que el usuario podría cambiar el nombre el ejecutable) en 777 permite cualquier usuario para ejecutar cualquiera ejecutable como root.

Definir los requisitos

• Los desarrolladores necesitan acceso de lectura/escritura a los archivos para poder actualizar el sitio web
• Los desarrolladores necesitan leer/escribir/ejecutar en directorios para poder navegar
• Apache necesita acceso de lectura a archivos y scripts interpretados
• Apache necesita acceso de lectura/ejecución a directorios útiles
• Apache necesita acceso de lectura/escritura/ejecución a los directorios para el contenido subido

Mantenido por un solo usuario

Si solo un usuario es responsable del mantenimiento del sitio, configúrelo como propietario del usuario en el directorio del sitio web y otorgue al usuario permisos rwx completos. Apache todavía necesita acceso para poder servir los archivos, así que configure www-data como el propietario del grupo y otorgue permisos r-x al grupo.

En tu caso, Eve, cuyo nombre de usuario podría ser eve , es el único usuario que mantiene contoso.com :

chown -R eve contoso.com/
chgrp -R www-data contoso.com/
chmod -R 750 contoso.com/
chmod g+s contoso.com/
ls -l
drwxr-s--- 2 eve      www-data   4096 Feb  5 22:52 contoso.com

Si tiene carpetas en las que Apache debe poder escribir, simplemente puede modificar los valores de permiso para el propietario del grupo para que www-data tenga acceso de escritura.

chmod g+w uploads
ls -l
drwxrws--- 2 eve      www-data   4096 Feb  5 22:52 uploads

El beneficio de esta configuración es que se vuelve más difícil (pero no imposible*) para otros usuarios en el sistema husmear, ya que solo los propietarios del usuario y del grupo pueden navegar por el directorio de su sitio web. Esto es útil si tiene datos secretos en sus archivos de configuración. ¡Cuidado con tu umask! Si crea un nuevo archivo aquí, los valores de permiso probablemente serán 755 por defecto. Puede ejecutar umask 027 para que los archivos nuevos tengan como valor predeterminado 640 (rw- r-- --- ).

Mantenido por un grupo de usuarios

Si más de un usuario es responsable del mantenimiento del sitio, deberá crear un grupo para asignar permisos. Es una buena práctica crear un grupo separado para cada sitio web y nombrar el grupo después de ese sitio web.

groupadd dev-fabrikam
usermod -a -G dev-fabrikam alice
usermod -a -G dev-fabrikam bob

En el ejemplo anterior, usamos el propietario del grupo para otorgar privilegios a Apache, pero ahora se usa para el grupo de desarrolladores. Dado que el propietario del usuario ya no nos es útil, configurarlo como root es una forma sencilla de garantizar que no se filtren privilegios. Apache aún necesita acceso, por lo que otorgamos acceso de lectura al resto del mundo.

chown -R root fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 775 fabrikam.com
chmod g+s fabrikam.com
ls -l
drwxrwxr-x 2 root     dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Si tiene carpetas en las que Apache debe poder escribir, puede hacer que Apache sea el propietario del usuario o el propietario del grupo. De cualquier manera, tendrá todo el acceso que necesita. Personalmente, prefiero convertirlo en el propietario del usuario para que los desarrolladores puedan navegar y modificar el contenido de las carpetas de carga.

chown -R www-data uploads
ls -l
drwxrwxr-x 2 www-data     dev-fabrikam   4096 Feb  5 22:52 uploads

Aunque este es un enfoque común, hay un inconveniente. Dado que todos los demás usuarios del sistema tienen los mismos privilegios en su sitio web que Apache, es fácil para otros usuarios navegar por su sitio y leer archivos que pueden contener datos secretos, como sus archivos de configuración.

Puedes tener tu pastel y comértelo también

Esto se puede mejorar aún más. Es perfectamente legal que el propietario tenga menos privilegios que el grupo, por lo que en lugar de desperdiciar el propietario del usuario asignándolo a la raíz, podemos hacer que Apache sea el propietario del usuario en los directorios y archivos de su sitio web. Esta es una inversión del escenario del mantenedor único, pero funciona igual de bien.

chown -R www-data fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 570 fabrikam.com
chmod g+s fabrikam.com
ls -l
dr-xrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Si tiene carpetas en las que Apache debe poder escribir, simplemente puede modificar los valores de permiso para el propietario del usuario para que www-data tenga acceso de escritura.

chmod u+w uploads
ls -l
drwxrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Una cosa a tener en cuenta con esta solución es que el propietario del usuario de los nuevos archivos coincidirá con el creador en lugar de establecerse en www-data. Por lo tanto, Apache no podrá leer los archivos nuevos que cree hasta que los elimine.

*Separación de privilegios de Apache

Mencioné anteriormente que en realidad es posible que otros usuarios husmeen en tu sitio web sin importar qué tipo de privilegios estés usando. De forma predeterminada, todos los procesos de Apache se ejecutan como el mismo usuario de www-data, por lo que cualquier proceso de Apache puede leer archivos de todos los demás sitios web configurados en el mismo servidor y, a veces, incluso realizar cambios. Cualquier usuario que pueda hacer que Apache ejecute un script puede obtener el mismo acceso que tiene Apache.

Para combatir este problema, existen varios enfoques para la separación de privilegios en Apache. Sin embargo, cada enfoque viene con varios inconvenientes de rendimiento y seguridad. En mi opinión, cualquier sitio con mayores requisitos de seguridad debe ejecutarse en un servidor dedicado en lugar de usar VirtualHosts en un servidor compartido.

Consideraciones adicionales

No lo mencioné antes, pero generalmente es una mala práctica que los desarrolladores editen el sitio web directamente. Para sitios más grandes, es mucho mejor tener algún tipo de sistema de lanzamiento que actualice el servidor web a partir del contenido de un sistema de control de versiones. El enfoque de mantenedor único es probablemente ideal, pero en lugar de una persona, tiene un software automatizado.

Si su sitio web permite cargas que no necesitan entregarse, esas cargas deben almacenarse en algún lugar fuera de la raíz web. De lo contrario, es posible que descubra que las personas están descargando archivos que estaban destinados a ser secretos. Por ejemplo, si permite que los estudiantes envíen tareas, deben guardarse en un directorio que no esté servido por Apache. Este también es un buen enfoque para los archivos de configuración que contienen secretos.

Para un sitio web con requisitos más complejos, es posible que desee considerar el uso de listas de control de acceso. Estos permiten un control de privilegios mucho más sofisticado.

Si su sitio web tiene requisitos complejos, es posible que desee escribir un script que configure todos los permisos. Pruébelo a fondo, luego manténgalo seguro. Podría valer su peso en oro si alguna vez necesita reconstruir su sitio web por algún motivo.

Solución 2:

Me pregunto por qué tanta gente usa (o recomienda) la "otra" (o) parte de los derechos de Linux para controlar lo que puede hacer Apache (y/o PHP). Al establecer esta parte derecha en algo diferente a "0", simplemente permite que todo el mundo haga algo en el archivo/directorio.

Mi enfoque es el siguiente:

• Creo dos usuarios separados. Uno para el acceso SSH/SFTP (si es necesario), que será el propietario de todos los archivos, y otro para el usuario de PHP FastCGI (el usuario con el que se ejecutará el sitio web). Llamemos a estos usuarios respectivamente bob y bob-www .
• bob tendrá todos los derechos (rwx en carpetas, rw- en archivos), para que pueda leer y editar todo el sitio web.
• El proceso PHP FastCGI necesita r-x derechos sobre carpetas y r-- derechos sobre los archivos, a excepción de carpetas muy específicas como cache/ o uploads/ , donde también se necesita el permiso de "escritura". Para darle a PHP FastCGI esta capacidad, se ejecutará como bob-www y bob-www se agregará al bob creado automáticamente grupo.
• Ahora nos aseguramos de que el propietario y el grupo de todos los directorios y archivos sean bob bob .
• Falta algo:incluso usamos FastCGI, pero Apache aún necesita acceso de lectura, para contenido estático o archivos .htaccess que intentará leer si AllowOverride está configurado en algo diferente a None . Para evitar el uso de la o parte de los derechos, agrego el www-data usuario al bob grupo.

Ahora:

• Para controlar lo que puede hacer el desarrollador, podemos jugar con la u parte de los derechos (pero esta es la nota a continuación).
• Para controlar lo que pueden hacer Apache y PHP, podemos jugar con la g parte de los derechos.
• La o part siempre se establece en 0, por lo que nadie más en el servidor puede leer o editar el sitio web.
• No hay problema cuando bob usuario crea nuevos archivos, ya que automáticamente pertenecerá a su grupo principal (bob ).

Este es un resumen, pero en esta situación, bob tiene permiso para SSH. Si no debería haber ningún usuario autorizado para modificar el sitio web (por ejemplo, el cliente solo modifica el sitio web a través de un panel de administración de CMS y no tiene conocimientos de Linux), cree dos usuarios de todos modos, pero asigne /bin/false como caparazón para bob también, y deshabilite su inicio de sesión.

    adduser --home /var/www/bobwebsite --shell /bin/bash bob
    adduser --no-create-home --shell /bin/false --disabled-login --ingroup bob bob-www
    adduser www-data bob
    cd /var/www/bobwebsite
    chown -R bob:bob .
    find -type d -exec chmod 750 {} \;
    find -type f -exec chmod 640 {} \;

Nota: la gente tiende a olvidar que limitar la u (propietario) los derechos son la mayor parte del tiempo inútiles e inseguros, ya que el propietario de un archivo puede ejecutar el chmod comando, incluso los derechos son 000.

Dime si mi enfoque tiene algunos problemas de seguridad, porque no estoy 100% seguro, pero es lo que estoy usando.

Creo que esta configuración tiene un problema:cuando PHP/Apache crea un nuevo archivo (por ejemplo, cargar), pertenecerá a bob-www:bob y bob sólo será capaz de leerlo. Tal vez setuid en el directorio pueda resolver el problema.

Solución 3:

Dada la clasificación de Google en la excelente respuesta anterior, creo que hay una cosa que debe tenerse en cuenta, y parece que no puedo dejar una nota después de la respuesta.

Continuando con el ejemplo, si planea usar www-data como propietario y dev-fabrikam como grupo con 570 permisos en el directorio (o archivo), es importante tener en cuenta que Linux ignora setuid , por lo que todos los archivos nuevos serán propiedad del usuario que los creó. Esto significa que después de crear nuevos directorios y archivos, deberá usar algo similar a:

chown -R www-data /newdirectory/
chmod -R 570 /newdirectory/

En Ubuntu 12.04 para Rackspace OpenStack, tuve un problema extraño en el que no podía obtener los permisos 570 para trabajar hasta que reinicié el servidor, lo que solucionó el problema mágicamente. Estaba perdiendo pelos a un ritmo cada vez mayor por ese problema aparentemente simple....

Solución 4:

Voy con esta configuración:

1. Todos los directorios excepto carga un conjunto para el propietario root y grupo root , permisos para 0755 .
2. Todos los archivos configurados para el propietario root y grupo root , permisos para 0644 .
3. Directorio de cargas configurado para el propietario root , grupo www-data , permisos para 1770 . El bit adhesivo no permite que el propietario del grupo elimine o cambie el nombre del directorio y los archivos que contiene.
4. Dentro de la carpeta de cargas un nuevo directorio con www-data usuario propietario y grupo, y 0700 permisos para cada www-data usuario que sube archivos.
5. Configuración de Apache:

Denegar AllowOverride y Index en el directorio de subidas, para que Apache no lea .htaccess archivos y el usuario de Apache no puede indexar el contenido de la carpeta de carga:

<Directory /siteDir>
   Options -Indexes
</Directory>

<Directory /siteDir/uploadDir>
   AllowOverride none
</Directory>

6. php.ini configuración:

open_basedir = /siteDir:/tmp:/usr/share/phpmyadmin
post_max_size = 5M
file_uploads = On
upload_max_filesize = 3M
max_file_uploads = 20

Con esta configuración, el www-data el usuario no podrá ingresar a directorios que no sean siteDir/ /tmp y /usr/share/phpmyadmin . También puede controlar el tamaño máximo de archivo, el tamaño máximo de publicación y la cantidad máxima de archivos para cargar en la misma solicitud.

Solución 5:

Cuando tiene un usuario de FTP llamado "leo", necesita cargar archivos en el directorio web example.com y también necesita que su usuario "apache" pueda crear archivos uploa-files/sessions/cache en el directorio de caché y luego haga lo siguiente:

Este comando asigna a leo como propietario y grupo como apache a example.com, el usuario de apache es parte del grupo apache por lo que heredará los permisos del grupo apache

Number  Octal Permission Representation
0   No permission
1   Execute permission
2   Write permission
3   Execute and write permission: 1 (execute) + 2 (write) = 3
4   Read permission
5   Read and execute permission: 4 (read) + 1 (execute) = 5
6   Read and write permission: 4 (read) + 2 (write) = 6
7   All permissions: 4 (read) + 2 (write) + 1 (execute) = 7