Pregunta ¿Qué permisos deberían tener los archivos / carpetas de mi sitio web en un servidor web de Linux?


Esto es un Pregunta canónica sobre los permisos de archivo en un servidor web Linux.

Tengo un servidor web Linux que ejecuta Apache2 que aloja varios sitios web. Cada sitio web tiene su propia carpeta en / var / www /.

/var/www/contoso.com/
/var/www/contoso.net/
/var/www/fabrikam.com/

El directorio base / var / www / es propiedad de root: root. Apache se ejecuta como www-data: www-data. El sitio web de Fabrikam es mantenido por dos desarrolladores, Alice y Bob. Ambos sitios web de Contoso son mantenidos por un desarrollador, Eve. Todos los sitios web permiten a los usuarios subir imágenes. Si un sitio web está comprometido, el impacto debe ser lo más limitado posible.

Quiero saber la mejor manera de configurar los permisos para que Apache pueda servir el contenido, el sitio web esté a salvo de los ataques y los desarrolladores puedan realizar cambios. Uno de los sitios web está estructurado así:

/var/www/fabrikam.com
    /cache
    /modules
    /styles
    /uploads
    /index.php

¿Cómo se deben establecer los permisos en estos directorios y archivos? Leí en alguna parte que nunca debería usar los permisos 777 en un sitio web, pero no entiendo qué problemas podrían causar. Durante los períodos de mayor actividad, el sitio web almacena automáticamente algunas páginas y almacena los resultados en la carpeta de caché. Todo el contenido enviado por los visitantes del sitio web se guarda en la carpeta de subidas.


283
2018-02-06 01:50


origen


Esto pretende ser un canónico Responde a todas las preguntas que recibimos sobre los permisos del sitio web. - Nic
"Leí en alguna parte que nunca debería usar los permisos 777 en un sitio web, pero no entiendo ...". ¿Entonces el lector podrá entender o al menos podrá comparar los méritos de las respuestas aquí? Cualquier solución debe basarse en requisitos específicos; los requisitos aquí no son lo suficientemente específicos (¿cuál es el modelo de amenaza)? - symcbean
Me encanta que esté preguntando por Apache, pero está usando los dominios que Microsoft suele usar como ejemplos. - gWaldo
Ver también ¿Cuál es la mejor manera de manejar los permisos para el usuario www-data de apache2 en / var / www? - Gareth
Puede consultar aquí para obtener detalles completos sobre los permisos que se deben colocar en los archivos y carpetas del sitio web en Linux serverfault.com/questions/124800/…


Respuestas:


Al decidir qué permisos utilizar, debe 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 puede proporcionar privilegios específicos. Esto generalmente incluye administradores de sistemas, desarrolladores y cuentas de servicio. Por lo general, hacen cambios en el sistema utilizando 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 los 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. Utilizar 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 los permisos tradicionales de Unix. Hay un excelente artículo en Wikipedia sobre Permisos del sistema de archivos así que no repetiré todo aquí. Pero hay algunas cosas que debes tener en cuenta.

El bit de ejecucion
Los scripts interpretados (por ejemplo, Ruby, PHP) funcionan bien sin el permiso de ejecución. Solo los binarios y scripts de shell necesitan el bit de ejecución. Para atravesar (ingresar) un directorio, necesita 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.

Nuevos permisos de archivo predeterminados
Cuando se crea un archivo, normalmente hereda el ID 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 debería habilitar el bit SGID en la carpeta principal.

Los valores de permiso predeterminados dependen de su umask. Umask resta permisos a los archivos recién creados, por lo que el valor común de 022 hace 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 la umask para apache o ejecutar chmod después de que se haya cargado el archivo.


El problema con 777

Cuando tú chmod 777 Tu sitio web, no tienes seguridad alguna. Cualquier usuario en el sistema puede cambiar o eliminar cualquier archivo en su sitio web. Pero más seriamente, 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, pueden ser explotadas 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 una puerto conocido (lo que debería evitar que los usuarios que no son root generen servicios de escucha accesibles desde todo el mundo), eso significa que su servidor debe ser iniciado por root (aunque cualquier servidor sano pasará inmediatamente a una cuenta con menos privilegios una vez que el puerto esté vinculado) . En otras palabras, si está ejecutando un servidor web en el que el ejecutable principal forma parte del control de versión (por ejemplo, una aplicación CGI), deja sus permisos (o, para el caso, los permisos del directorio que contiene, ya que el usuario podría cambiar el nombre el ejecutable) en 777 permite alguna usuario para ejecutar alguna 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 que puedan navegar alrededor
  • 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 directorios para el contenido cargado

Mantenido por un solo usuario

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

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 que deben ser grabables por Apache, solo 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 que otros usuarios del sistema puedan husmear, ya que solo los usuarios y los propietarios de grupos 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í, es probable que los valores de los permisos tengan como valor predeterminado 755. Puede ejecutar umask 027para que los nuevos archivos por defecto a 640 (rw- r-- ---).


Mantenido por un grupo de usuarios.

Si más de un usuario es responsable de mantener el sitio, deberá crear un grupo para usarlo para asignar permisos. Es una buena práctica crear un grupo separado para cada sitio web y nombrar al 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 eso se usa para el grupo de desarrolladores. Dado que el propietario del usuario ya no nos es útil, establecerlo como root es una forma sencilla de garantizar que no se pierden privilegios. Apache aún necesita acceso, por lo que le damos 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 que deben ser grabables por Apache, 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 que sea el propietario del usuario para que los desarrolladores aún puedan explorar 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. Como todos los demás usuarios del sistema tienen los mismos privilegios para 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 puede mejorarse aún más. Es perfectamente legal que el propietario tenga menos privilegios que el grupo, por lo que, en lugar de desperdiciar al 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. Esto 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 que deben ser grabables por Apache, 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 que hay que tener cuidado con esta solución es que el usuario propietario de los nuevos archivos coincidirá con el creador en lugar de configurarse en www-data. Por lo tanto, cualquier archivo nuevo que cree no será legible por Apache hasta que los reproduzca.


* Apache separación de privilegios.

Anteriormente mencioné que en realidad es posible que otros usuarios busquen en su sitio web sin importar qué tipo de privilegios esté 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 otros 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, hay varios enfoques para 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 desde el contenido de un sistema de control de versiones. El enfoque de un solo mantenedor es probablemente ideal, pero en lugar de una persona, tiene un software automatizado.

Si su sitio web permite subidas que no necesitan ser distribuidas, esas cargas deben almacenarse en algún lugar fuera de la raíz de la web. De lo contrario, es posible que las personas estén descargando archivos que pretendían ser secretos. Por ejemplo, si permite que los estudiantes envíen tareas, deben guardarse en un directorio que no es atendido 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 examinar el uso de Listas de control de acceso. Esto permite un control de privilegios mucho más sofisticado.

Si su sitio web tiene requisitos complejos, puede escribir un script que configure todos los permisos. Pruébelo a fondo, luego manténgalo a salvo. Podría valer su peso en oro si alguna vez necesita reconstruir su sitio web.


316
2018-02-06 01:50



"chmod -R 775 fabrikam.com". Muy pocos archivos dentro de la mayoría de los sitios web tienen que ser ejecutables; Por ejemplo, PHP script puede ser 0640 siempre que el servidor web pueda leerlos. chmod -R a + X fabrikam.com otorgaría derechos ejecutables a todos solo en directorios.
bonita descripción! - RNA
Tenga en cuenta que Apache se ejecuta como usuario apache en los sistemas derivados de Red Hat. - Michael Hampton♦
Esto es excelente, pero había una cosa que no entendía: no entiendo el objetivo ni la ventaja de la estrategia de hacer que apache sea el usuario / propietario de un directorio de archivos si ya tiene propiedad de grupo sobre el archivo. - idiotprogrammer
Esta es una publicación excelente. Aquí está mi contribución: La desventaja de usar www-data como propietario y dev-fabrikam como grupo (mencionado en Puedes tener tu pastel y comértelo también. También se aplica (a la inversa) al escenario ofrecido en Mantenido por un solo usuario. En ese escenario, cada vez que Apache crea una carpeta o archivo, el usuario no tendrá acceso a la misma, por lo que los archivos deben devolverse al usuario original. No he actualizado la respuesta ya que no estoy 100% seguro de mi declaración. Prefiero que otros lo confirmen antes de parchear la respuesta.


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 más que "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 mover y bob-www.
  • mover tendrá plenos derechos (rwx en las carpetas, rw- en archivos), para que él / ella pueda leer y editar todo el sitio web.
  • El proceso PHP FastCGI necesita r-x derechos sobre carpetas y r-- Derechos sobre archivos, excepto carpetas muy específicas como cache/ o uploads/, donde también se necesita el permiso "escribir". Para dar a PHP FastCGI esta capacidad, se ejecutará como bob-wwwy bob-www Se agregará a la creación automática. mover grupo.
  • Ahora nos aseguramos de que el propietario y el grupo de todos los directorios y archivos estén Bob Bob.
  • Falta algo: incluso nosotros usamos FastCGI, pero Apache aún necesita acceso de lectura, para contenido estático, o archivos .htaccess que intentará leer si AllowOverride está configurado para algo más que None. Para evitar el uso del o Parte de los derechos, añado el www-data usuario al mover grupo.

Ahora:

  • Para controlar lo que el desarrollador puede hacer, podemos jugar con el tu Parte de los derechos (pero esta la nota a continuación).
  • Para controlar lo que Apache y PHP pueden hacer, podemos jugar con el sol Parte de los derechos.
  • los o La parte 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 mover el usuario crea nuevos archivos, ya que pertenecerá automáticamente a su grupo principal (mover).

Esto es un resumen, pero en esta situación, mover Se permite SSH. Si no debe permitirse a ningún usuario 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 conocimiento de Linux), cree dos usuarios de todos modos, pero proporcione /bin/falsecomo concha para mover también, y deshabilitar 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 tu Los derechos (de propietario) son la mayoría de las veces inútiles e inseguros, ya que el propietario de un archivo puede ejecutar el chmod comando, incluso los derechos son 000.

Dígame 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, subir), pertenecerá a bob-www: boby mover Sólo podrá leerlo. Tal vez setuid en el directorio puede resolver el problema.


13
2017-07-19 21:42



Linux ignora setuid. Los nuevos archivos siempre son propiedad del creador. - Paul
No entiendo algo Esto no parece incorporar la situación cuando más desarrolladores trabajan simultáneamente en el sitio web, ya que el único usuario es bob. ¿Cómo lidias con eso? P.ej. a través de ssh, ambos usuarios inician sesión como bob. bob (1) siente que no puede recordar la contraseña y la cambia por otra, pero que aún es segura. bob (2) intenta iniciar sesión la próxima vez, y él / ella no puede. - n611x007
@naxa Cualquier sistema marginalmente bueno nunca debe hacer que ninguno de los desarrolladores modifique directamente el sitio web. Idealmente, el sitio web está bajo control de versión, de modo que la cuenta de usuario 'bob' extrae y despliega cada versión (estable) automáticamente. Entonces, los desarrolladores realizan el desarrollo fuera del sitio y los cambios se implementan una vez que se envían al servidor de implementación. 'bob' es un usuario del sistema que debe tener permisos de red muy limitados, que no incluyen el inicio de sesión remoto; iptables en realidad te permite filtrar por UID para cosas como esta. - Parthian Shot
"Me pregunto por qué tanta gente usa (o recomienda) la" otra "(o) parte - entonces tal vez debería haber publicado esto como una pregunta en lugar de una respuesta. No es infrecuente ejecutar el servidor web deliberadamente (como la parte más expuesta del sistema) con el nivel más bajo de privilegios, mientras que las cuentas de administración, desarrollo y desarrollo también necesitan un acceso diferente - symcbean


Dado el rango 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, tendrá que 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 hasta que reinicié el servidor, lo que mágicamente solucionó el problema. Estaba perdiendo pelos a un ritmo cada vez mayor sobre ese problema aparentemente simple ...


9
2018-01-13 22:03



Deje que se realice una búsqueda en Google: en Raspbian (también conocido como raspberry pi), si desea cambiar la propiedad de / var / www en lighttpd (u otro navegador web), DEBE reiniciar. - gbronner
@gbronner Si ese es un problema difícil de encontrar para la resolución, puede considerar publicarlo como una pregunta y dar una respuesta a la pregunta. Sin embargo, es probable que sea más apropiado en un sitio diferente de SE Q&A. Mi suposicion es Unix y Linux Podría ser un buen lugar para hacer eso. - Paul
También hay raspberrypi.stackexchange.com; Parece que los sitios SE están fragmentando un poco el conocimiento. - gbronner
@gbronner lol. ¡No sabía de eso! La etiqueta Raspbian en U&L tiene algo así como 120 preguntas. - Paul


Voy con esta configuración:

  1. Todos los directorios excepto los subidas un conjunto al propietario root y grupo root, permisos para 0755.
  2. Todos los archivos configurados al propietario root y grupo root, permisos para 0644.
  3. Cargar directorio configurado al propietario rootgrupo 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 propietario usuario y grupo, y 0700 permisos para cada www-data Usuario que carga archivos.
  5. Configuración de apache:

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

<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, la www-data El usuario no podrá acceder 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 los archivos máximos para cargar en la misma solicitud.


3
2017-10-23 09:54





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

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

chown -R leo: apache example.com

Otro comando que asegura el permiso correcto y también cumple con las preocupaciones de seguridad.

chmod -R 2774 ejemplo.com

Aquí, el primer número 2 es para el directorio y asegura que cada nuevo archivo creado permanecerá en el mismo grupo y permisos de propietario. 77 es para propietario y grupo significa que tienen acceso completo. 4 es para otros significa que solo pueden leer en el canal.

Lo siguiente es útil para entender los números de permiso.

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

3
2017-08-09 07:15