345 votos

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

Este es un Pregunta canónica sobre los permisos de los archivos en un servidor web Linux.

Tengo un servidor web Linux con 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. Los dos 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 se ve comprometido, el impacto debería ser lo más limitado posible.

Quiero saber cuál es la mejor manera de configurar los permisos para que Apache pueda servir el contenido, el sitio web esté protegido de los ataques y los desarrolladores puedan seguir haciendo cambios. Uno de los sitios web está estructurado así:

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

¿Cómo deben establecerse los permisos en estos directorios y archivos? He leído en algún sitio que nunca se deben utilizar permisos 777 en un sitio web, pero no entiendo qué problemas podría causar. Durante los periodos de gran afluencia de público, el sitio web almacena automáticamente en la caché algunas páginas y los resultados en la carpeta de caché. Todo el contenido enviado por los visitantes del sitio web se guarda en la carpeta uploads.

7 votos

Esto pretende ser una canónico respuesta a todas las preguntas que recibimos sobre los permisos del sitio web.

1 votos

"He leído en algún sitio que nunca se deben utilizar los permisos 777 en un sitio web, pero no entiendo..." - entonces, ¿podrá el lector entender o al menos 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)

8 votos

Me encanta que preguntes por Apache, pero que uses como ejemplo los dominios que suele usar Microsoft.

376voto

DaRKoN_ Puntos 4098

A la hora de 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 pueden recibir privilegios específicos. Suelen ser administradores del sistema, desarrolladores y cuentas de servicio. Suelen realizar 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. Puedes 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 el www-data usuario pero puede ser diferente. Utilice ps aux | grep httpd o ps aux | grep apache para ver qué usuario está usando Apache en su sistema.


Notas sobre los permisos en 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 ejecución
Los scripts interpretados (por ejemplo, Ruby, PHP) funcionan bien sin el permiso de ejecución. Sólo los binarios y los scripts scripts necesitan el bit de ejecución. Para atravesar (entrar) un directorio, necesitas 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 los nuevos archivos por defecto
Cuando se crea un archivo, normalmente hereda el id de grupo de quien lo creó. Pero a veces quieres que los nuevos archivos hereden el id de grupo de la carpeta donde se crean, por lo que activarías el bit SGID en la carpeta padre.

Los valores de permiso por defecto dependen de su umask. La 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. Cuando colabores con un grupo, es útil cambiar tu umask a 002 para que los archivos que crees puedan ser modificados por los miembros del grupo. Y si quieres personalizar los permisos de los archivos subidos, tienes que cambiar la umask de apache o ejecutar chmod después de subir el archivo.


El problema del 777

Cuando chmod 777 su sitio web, no tiene ningún tipo de seguridad. Cualquier usuario del sistema puede cambiar o borrar cualquier archivo de su sitio web. Pero lo que es más grave, recuerde que el servidor web actúa en nombre de los visitantes de su sitio web, y ahora el servidor web es capaz de cambiar los mismos archivos que está ejecutando. Si hay alguna vulnerabilidad de programación en su sitio web, puede ser explotada 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 (lo que debería hacer para evitar que los usuarios que no son root generen servicios de escucha accesibles para 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 donde el ejecutable principal es parte del control de versiones (por ejemplo, una aplicación CGI), dejar sus permisos (o, para el caso, los permisos del directorio que contiene, ya que el usuario podría cambiar el nombre del ejecutable) en 777 permite cualquier usuario para ejecutar cualquier 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 los directorios para poder navegar por ellos
  • Apache necesita acceso de lectura a los archivos y a los scripts scripts.
  • Apache necesita acceso de lectura/ejecución a los directorios servibles
  • Apache necesita acceso de lectura/escritura/ejecución a los directorios para el contenido subido

Mantenida por un solo usuario

Si sólo un usuario es responsable de mantener el sitio, establézcalo como propietario del usuario en el directorio del sitio web y déle permisos rwx completos. Apache aún necesita acceso para poder servir los archivos, así que establece www-data como propietario del grupo y dale al grupo permisos r-x.

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 tienes carpetas que necesitan ser escritas por Apache, puedes simplemente 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

La ventaja de esta configuración es que se hace más difícil (pero no imposible*) que otros usuarios del sistema husmeen, ya que sólo los propietarios del usuario y del grupo pueden navegar por el directorio de su sitio web. Esto es útil si tienes datos secretos en tus archivos de configuración. ¡Tenga cuidado con su umask! Si crea un nuevo archivo aquí, los valores de permiso probablemente serán por defecto 755. Puedes ejecutar umask 027 para que los nuevos archivos sean por defecto de 640 ( rw- r-- --- ).


Mantenida por un grupo de usuarios

Si hay más de un usuario responsable del mantenimiento del sitio, deberá crear un grupo para asignar los permisos. Es una buena práctica crear un grupo separado para cada sitio web, y nombrar el grupo con el nombre 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 grupo owner para dar privilegios a Apache, pero ahora se usa para el grupo de desarrolladores. Como el usuario owner ya no nos es útil, ponerlo como root es una forma sencilla de asegurar que no se filtren privilegios. Apache todavía necesita acceso, así 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 necesitan ser escritas 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 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 se trata de un planteamiento habitual, tiene sus inconvenientes. Dado que todos los demás usuarios del sistema tienen los mismos privilegios para su sitio web que Apache, es fácil que otros usuarios naveguen por su sitio y lean archivos que puedan contener datos secretos, como sus archivos de configuración.

Puedes tener tu pastel y comerlo también

Esto se puede mejorar aún más. Es perfectamente legal que el propietario tenga menos privilegios que el grupo, así que en lugar de desperdiciar el propietario del usuario asignándolo a root, 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 de un solo mantenedor, pero funciona igualmente 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 necesitan ser escritas por Apache, puede simplemente modificar los valores de permiso para el usuario propietario de manera 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 con la que hay que tener cuidado con esta solución es que el propietario del usuario de los nuevos archivos coincidirá con el creador en lugar de ser establecido como www-data. Así que cualquier archivo nuevo que crees no será legible por Apache hasta que los hagas chown.


*Separación de privilegios de Apache

Ya he mencionado que es posible que otros usuarios husmeen en tu sitio web sin importar el tipo de privilegios que estés utilizando. Por defecto, todos los procesos de Apache se ejecutan como el mismo usuario www-data, por lo que cualquier proceso de Apache puede leer los archivos de todos los demás sitios web configurados en el mismo servidor, y a veces incluso hacer cambios. Cualquier usuario que pueda hacer que Apache ejecute un script</strkeep><strkeep> puede obtener el mismo acceso que tiene el propio Apache.

Para combatir este problema, existen varios enfoques para separación de privilegios en Apache. Sin embargo, cada uno de los enfoques tiene varios inconvenientes de rendimiento y seguridad. En mi opinión, cualquier sitio con mayores requisitos de seguridad debería ejecutarse en un servidor dedicado en lugar de utilizar VirtualHosts en un servidor compartido.


Consideraciones adicionales

No lo he mencionado antes, pero suele ser 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 publicación que actualice el servidor web a partir de los contenidos de un sistema de control de versiones. El enfoque de un solo mantenedor es probablemente ideal, pero en lugar de una persona tienes un software automatizado.

Si su sitio web permite cargas que no necesitan ser servidas, esas cargas deben ser almacenadas en algún lugar fuera de root de la web. De lo contrario, podría encontrar que la gente está descargando archivos que estaban destinados a ser secretos. Por ejemplo, si permite que los estudiantes envíen sus tareas, éstas deberían guardarse en un directorio que no sea servido por Apache. Este es también un buen método 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 mucho más sofisticado de los privilegios.

Si su sitio web tiene requisitos complejos, tal vez quiera escribir un script que configure todos los permisos. Pruébalo a fondo y guárdalo. Podría valer su peso en oro si alguna vez se ve en la necesidad de reconstruir su sitio web por alguna razón.

14 votos

"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 y cuando el servidor web pueda leerlos. chmod -R a+X fabrikam.com daría derechos de ejecución a todo el mundo sólo en los directorios.

8 votos

Tenga en cuenta que Apache se ejecuta como usuario apache en los sistemas derivados de Red Hat.

0 votos

Esto es excelente, pero hubo una cosa que no entendí: No entiendo el objetivo o la ventaja de la estrategia de hacer que apache sea el usuario/propietario de un directorio o archivo si ya tiene la propiedad del grupo sobre el archivo.

16voto

Fox Puntos 325

Me pregunto por qué tanta gente utiliza (o recomienda) la parte "other" (o) de los derechos de Linux para controlar lo que puede hacer Apache (y/o PHP). Al establecer esta parte de los derechos a algo más que "0", simplemente permites 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 PHP FastCGI (el usuario con el que se ejecutará el sitio web). Llamemos a estos usuarios respectivamente bob y bob-www .
  • bob tendrá plenos derechos ( rwx en las carpetas, rw- en los archivos), para que pueda leer y editar todo el sitio web.
  • El proceso PHP FastCGI necesita r-x derechos sobre las carpetas y r-- derechos sobre los archivos, excepto para carpetas muy específicas como cache/ o uploads/ donde también se necesita el permiso de "escritura". Para dar a PHP FastCGI esta capacidad, se ejecutará como bob-www y bob-www se agregará a la lista creada automáticamente bob grupo.
  • Ahora nos aseguramos de que el propietario y el grupo de todos los directorios y archivos son bob bob .
  • Falta algo : aunque usemos FastCGI, pero Apache sigue necesitando acceso de lectura, para contenido estático, o archivos .htaccess que intentará leer si AllowOverride se ajusta a algo más que None . Para evitar el uso del o parte de los derechos, añado el www-data usuario a la bob grupo.

Ahora:

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

Esto es una recapitulación, pero en esta situación, bob se permite el SSH. Si no debe haber ningún usuario con permiso para modificar el sitio web (por ejemplo, el cliente sólo 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 dé /bin/false como Shell para bob también, y desactivar 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 la limitación de la u (propietario) es la mayoría de las veces inútil e inseguro, ya que el propietario de un archivo puede ejecutar el chmod mando, 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, de subida), pertenecerá a bob-www:bob y bob sólo podrá leerlo. Tal vez setuid en el directorio puede resolver el problema.

0 votos

Linux ignora setuid . Los archivos nuevos son siempre propiedad del creador.

0 votos

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 se soluciona esto? Por ejemplo, a través de ssh, ambos usuarios se registran como bob. bob (1) siente que no puede recordar la contraseña y la cambia por otra pero todavía segura. bob (2) intenta registrarse la próxima vez, y no puede.

2 votos

@naxa Cualquier sistema mínimamente bueno nunca debería tener a ninguno de los desarrolladores modificando directamente la web. Idealmente, el sitio web está bajo control de versiones de tal manera que la cuenta de usuario 'bob' saca y despliega cada versión (estable) automáticamente. Así, los desarrolladores hacen el desarrollo fuera del sitio, y los cambios se despliegan una vez que son empujados al servidor de despliegue. 'bob' es un usuario del sistema que debería tener permisos de red muy limitados, que no incluyen el acceso remoto; iptables permite filtrar por UID para cosas como esta.

9voto

Paul Puntos 636

Teniendo en cuenta el rango de Google en la excelente respuesta anterior, creo que hay una cosa que debe ser observado, y me parece que no puede dejar una nota después de la respuesta.

Siguiendo con el ejemplo, si piensas utilizar www-data como propietario y dev-fabrikam como grupo con 570 permisos sobre 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 utilizar algo similar a:

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

En Ubuntu 12.04 para Rackspace OpenStack, tuve un extraño problema en el que no pude conseguir que los permisos 570 funcionaran hasta que reinicié el servidor, lo que mágicamente arregló el problema. Se me caían los pelos de punta por ese problema aparentemente sencillo ....

0 votos

Por favor, que esto se busque en Google: En Raspbian (aka en una raspberry pi, si quieres cambiar la propiedad de /var/www bajo lighttpd (u otro navegador web), DEBES reiniciar.

0 votos

@gbronner Si se trata de un problema difícil de resolver, podrías considerar la posibilidad de publicarlo como una pregunta y proporcionar una respuesta a la misma. Sin embargo, probablemente sea más apropiado en otro sitio de preguntas y respuestas de SE. Mi opinión es Unix y Linux podría ser un buen lugar para hacerlo.

1 votos

También está raspberrypi.stackexchange.com; parece que los sitios SE están fragmentando un poco el conocimiento.

3voto

Manolo Puntos 213

Voy con esta configuración:

  1. Todos los directorios, excepto el de subidas, se han puesto en manos del propietario root y el grupo root , permisos para 0755 .
  2. Todos los archivos establecidos para el propietario root y el grupo root , permisos para 0644 .
  3. El directorio de subidas se establece como propietario root , grupo www-data , permisos para 1770 . El bit adhesivo no permite al propietario del grupo eliminar o renombrar el directorio y los archivos que contiene.
  4. Dentro de la carpeta uploads un nuevo directorio con www-data usuario y grupo propietario, y 0700 permisos para cada www-data usuario que sube archivos.
  5. Configuración de Apache:

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

<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á entrar en otros directorios que no sean siteDir/ /tmp y /usr/share/phpmyadmin . También puedes controlar el tamaño máximo de los archivos, el tamaño máximo de la publicación y los archivos máximos a subir en la misma solicitud.

3voto

Dale Zak Puntos 16

Si tienes un usuario FTP llamado "leo" que necesita subir archivos al directorio web de example.com y además necesitas que tu usuario "apache" pueda crear archivos uploa/sessions/cache en el directorio cache entonces haz lo siguiente:

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

chown -R leo:apache ejemplo.com

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

chmod -R 2774 ejemplo.com

Aquí el primer número 2 es para el directorio y asegura que cada nuevo archivo creado permanecerá con los mismos permisos de grupo y propietario. 77 es para el propietario y el grupo significa que tienen acceso completo. 4 es para otros significa que sólo pueden leer a través.

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

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: