292 votos

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

Este es un Canónica Pregunta acerca de los Permisos de Archivos en Linux servidor web.

Tengo un Linux servidor web que ejecuta Apache2 que alberga 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/

La base directorio /var/www/ es propiedad de root:root. Apache se está ejecutando como www-data:www-data. El Fabrikam sitio web es mantenido por dos desarrolladores, Alice y Bob. Tanto Contoso sitios web que son mantenidos por un desarrollador, Eva. Todos los sitios web permiten a los usuarios subir imágenes. Si un sitio web está en peligro, el impacto debe ser tan limitado como sea posible.

Quiero saber la mejor manera de configurar los permisos para que Apache puede servir el contenido, el sitio web es seguro de los ataques, y los desarrolladores pueden hacer cambios. Uno de los sitios web está estructurado como este:

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

¿Cómo deben los permisos se establecen en estos directorios y archivos? Leí en alguna parte que usted nunca debe utilizar permisos 777 en un sitio web, pero no entiendo lo de los problemas que podría causar. Durante los períodos de disponibilidad, el sitio web automáticamente almacena en caché algunas páginas y almacena los resultados en la carpeta de caché. Todo el contenido presentado por los visitantes del sitio web se guarda en la carpeta cargas.

328voto

DaRKoN_ Puntos 4098

A la hora de decidir qué permisos para el uso, usted necesita saber exactamente lo que sus usuarios están y qué necesitan. Un servidor web interactúa con dos tipos de usuario.

Autentica a los usuarios tener una cuenta de usuario en el servidor y puede ser provisto con privilegios específicos. Generalmente, esto incluye los administradores de sistemas, desarrolladores, y las cuentas de servicio. Usualmente se hacen cambios en el sistema mediante SSH o SFTP.

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


Notas sobre los permisos de linux

Linux y otros compatibles con POSIX de uso de los sistemas tradicionales de permisos de unix. Hay un excelente artículo en la Wikipedia sobre el sistema de Ficheros permisos , así que no voy a repetir aquí todo. Pero hay algunas cosas que usted debe ser consciente de.

El bit de ejecución
Interpreta secuencias de comandos (por ejemplo. Ruby, PHP) funcionan bien sin el permiso de ejecución. Sólo los binarios y secuencias de comandos de shell necesita el bit de ejecución. Con el fin de atravesar (enter) un directorio, debe tener permiso de ejecución en ese directorio. El webserver de las necesidades de este permiso a la lista de un directorio o servir los archivos dentro de ella.

Por defecto los nuevos permisos de archivo
Cuando se crea un archivo, normalmente hereda el grupo de identificación de quien la creó. Pero a veces se desea que los nuevos archivos para heredar el id de grupo de la carpeta en la que se crearon, por lo que se debe activar el bit SGID en la carpeta principal.

Permiso por defecto, los valores dependerán de su umask. El umask resta permisos de archivos recién creados, por lo que el valor común de 022 resultados en la creación de archivos con 755. Cuando se colabora con un grupo, es útil para cambiar su umask a 002, de modo que los archivos que usted crea puede ser modificado por los miembros del grupo. Y si quieres personalizar los permisos de los archivos subidos, usted necesita para cambiar el umask para apache o ejecutar chmod después de que el archivo ha sido cargado.


El problema con 777

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

Además, si el servidor se ejecuta en un puerto conocido (que debería, para evitar que usuarios no root de desove de los servicios de escucha que son mundialmente accesible), significa que el servidor debe ser iniciado por la root (aunque cualquier cuerdo servidor inmediatamente caen a menos privilegios de cuenta de una vez que el puerto está enlazado). En otras palabras, si usted está ejecutando un servidor web donde el ejecutable principal es parte de la versión de control (por ejemplo, una aplicación CGI), dejando sus permisos (o, para el caso, los permisos del directorio, ya que el usuario puede cambiar el nombre del ejecutable) a 777 permite a cualquier usuario ejecutar cualquier archivo ejecutable de la root.


Definir los requisitos

  • Los desarrolladores necesitan acceso de lectura/escritura a los archivos para que puedan actualizar el sitio web
  • Los desarrolladores necesitan leer/escribir/ejecutar en directorios de manera que se puede navegar alrededor de
  • Apache necesita acceso de lectura a los archivos y a interpretar secuencias de comandos
  • Apache necesidades de lectura/ejecutar el acceso a directorios serveable
  • Apache necesita leer/escribir/ejecutar el acceso a los directorios para el contenido cargado

Mantenido por un solo usuario

Si sólo un usuario es responsable de mantener el sitio, conjunto de ellos, como el usuario propietario en el directorio del sitio web y dar al usuario una completa permisos rwx. Apache todavía necesita acceso para que pueda servir a los archivos, a fin de establecer www-data como el propietario del grupo y dar el grupo de r-x de permisos.

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 modificables por el Apache, usted puede modificar los valores de permisos para el propietario del grupo, de modo que www-data tiene 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*) para otros usuarios en el sistema para espiar a su alrededor, ya que sólo el usuario y grupo propietarios pueden navegar por el sitio web de directorio. Esto es útil si usted tiene secreto de los datos en sus archivos de configuración. Tenga cuidado acerca de su umask! Si se desea crear un nuevo archivo de aquí, los valores de permisos probablemente se pondrá por defecto a 755. Puede ejecutar umask 027 para que los nuevos archivos de forma predeterminada a los 640 (rw- r-- ---).


Mantenido por un grupo de usuarios

Si más de un usuario es responsable de mantener el sitio, usted tendrá que crear un grupo para la asignación de permisos. Es una buena práctica crear un grupo separado para cada sitio web, y el nombre del 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, hemos utilizado el propietario del grupo para dar privilegios a Apache, pero ahora que es utilizado por el grupo de desarrolladores. Dado que el usuario propietario no es útil para nosotros, la configuración de la root es una forma sencilla de asegurarse de que no son los privilegios que se filtró. Apache todavía necesita acceso, lo que le da acceso de lectura para el 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 modificables por el Apache, puede hacer que Apache el usuario propietario o el propietario del grupo. De cualquier manera, va a tener todo el acceso que necesita. Personalmente, yo prefiero que sea el propietario de usuario para que los desarrolladores todavía puede examinar 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. Ya que cada usuario en el sistema tiene los mismos privilegios a su sitio web como Apache, es fácil para los usuarios navegar por su sitio web y leer los archivos que pueden contener datos confidenciales, tales como los archivos de configuración.

Usted puede tener su pastel y comérselo también

Esto puede ser más mejorado. Es perfectamente legal que el propietario tiene menos privilegios que el grupo, así que en lugar de malgastar el propietario de usuario mediante su asignación a la root, podemos hacer que Apache el usuario propietario de los directorios y archivos en su sitio web. Esto es una inversión de la única mantenedor de escenario, 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 modificables por el Apache, usted puede modificar los valores de permisos para el usuario propietario para que www-data tiene 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 cuidado con esta solución es que el usuario propietario de los archivos nuevos coincidirá con el creador, en lugar de estar a www-data. Así que los nuevos archivos que cree no ser legible por Apache hasta que chown.


*Apache separación de privilegios

He mencionado anteriormente que es realmente posible para que los demás usuarios snoop alrededor de su sitio web, no importa qué tipo de privilegios que usted está utilizando. Por defecto, todos los Apache procesos se ejecuten en la misma www-data usuario, 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 hacer cambios. Cualquier usuario que se pueden obtener de Apache para ejecutar una secuencia de comandos puede obtener el mismo acceso que el Apache en sí tiene.

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


Consideraciones adicionales

No he mencionado esto antes, pero por lo general es una mala práctica que los desarrolladores de edición de la página web directamente. Para los sitios más grandes, es mucho mejor tener algún tipo de sistema de liberación que actualiza el webserver de los contenidos de un sistema de control de versiones. El único mantenedor de enfoque es probablemente lo ideal, pero en lugar de una persona a la que han de software automatizado.

Si su sitio web permite a las cargas que no necesita ser servido, los archivos deben ser almacenados en algún lugar fuera de la root del web. De lo contrario, usted podría encontrar que las personas son la descarga de los archivos que estaban destinados a ser secreto. Por ejemplo, si usted le permite a los estudiantes a presentar trabajos, deberán ser guardados en un directorio que no está servida 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, usted puede desear mirar en el uso de Listas de Control de Acceso. Estos permiten mucho más sofisticado control de privilegios.

Si su sitio web tiene complejo de requisitos, usted puede escribir un script que configura todos los permisos. Prueba a fondo, a continuación, mantenga a salvo. Podría ser que vale su peso en oro si alguna vez se encuentra con la necesidad de reconstruir su sitio web por alguna razón.

14voto

Fox Puntos 325

Me pregunto por qué tantas personas usan (o recomendar) el "otro" (o) de la parte de Linux, el derecho a controlar lo que se puede hacer Apache (y/o PHP). Mediante la configuración de este derecho de la parte a algo distinto a "0", sólo se permite que todo el mundo para hacer algo en el archivo/directorio.

Mi planteamiento es el siguiente:

  • Puedo crear dos separados de los usuarios. Uno para el SSH/SFTP de acceso (si es necesario), que será el propietario de todos los archivos, y uno para el PHP FastCGI usuario (el usuario del sitio web va a ejecutar como). Vamos a llamar a estos usuarios, respectivamente, bob y bob-www.
  • bob tendrá plenos derechos (rwx en carpetas, rw- en los archivos), de modo que él/ella puede leer y editar toda la web.
  • El PHP FastCGI las necesidades de los procesos de r-x de los derechos de las carpetas y r-- derechos sobre los archivos, con la excepción de carpetas específicas como cache/ o uploads/, donde el "escribir" permiso también es necesaria. Para dar PHP FastCGI esta capacidad, se ejecutará como bob-www, y bob-www , será añadido a la crea automáticamente bob grupo.
  • Ahora asegúrese de que el propietario y el grupo de todos los directorios y archivos bob bob.
  • Falta algo : incluso podemos usar FastCGI, pero Apache todavía necesita acceso de lectura, para el contenido estático, o .archivos htaccess que se va a tratar de leer si AllowOverride está ajustado a algo distinto a None. Para evitar el uso de la o parte de los derechos, añado la www-datos de usuario a la de bob grupo.

Ahora:

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

Este es un resumen, pero en esta situación, bob se permite a SSH. Si no hay ningún usuario puede modificar el sitio web (por ejemplo. el cliente sólo modifica el sitio web a través de un CMS panel de administración y no tiene conocimiento de Linux), crear dos usuarios de todos modos, pero dar /bin/false como shell por bob así, 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 : las personas tienden a olvidar que la limitación de la u (el propietario de los derechos de la mayoría de las veces inútil e insegura, ya que el propietario de un archivo se puede ejecutar el chmod comando, incluso los derechos 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. subir), pertenecen a bob-www:boby bob sólo será capaz de leerlo. Tal vez setuid en el directorio puede resolver el problema.

9voto

Paul Puntos 636

Dado el google rank en la anterior respuesta excelente, creo que hay una cosa que debería ser notado, y me parece que no puede dejar una nota después de la respuesta.

Continuando con el ejemplo, si usted planea usar a 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 nuevos archivos serán propiedad del usuario que los creó. Esto significa que después de la creación de nuevos archivos y directorios, usted tendrá que usar algo similar a:

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

En Ubuntu 12.04 por Rackspace OpenStack, tuve una extraña problema por el cual no pude conseguir los permisos de 570 a trabajar hasta que he reiniciado el servidor, que por arte de magia se ha solucionado el problema. Fue la pérdida de pelos en un aumento de la tasa sobre que aparentemente simple problema....

3voto

Manolo Puntos 213

Me voy con esta configuración:

  1. Todos los directorios, excepto cargas de un conjunto para el dueño root y el grupo root, permisos a 0755.
  2. Todos los archivos de configurar para el propietario root y el grupo root, permisos a 0644.
  3. Directorio de Uploads configurar para el propietario root, grupo www-data, permisos a 1770. El sticky bit no dejar que el propietario del grupo para eliminar o cambiar el nombre del directorio y los archivos que hay dentro.
  4. Dentro de las cargas en una carpeta nueva en el directorio www-data propietario de usuario y de grupo, y 0700 permisos para cada www-data de usuario que subir los archivos.
  5. Configuración de Apache:

Denegar AllowOverride y Index en las cargas de directorio, para que Apache no lee .htaccess archivos, y el usuario de Apache no puede indexar el contenido de la carpeta cargas:

<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 de usuario no será capaz de obtener dentro de los directorios de otros que siteDir/ /tmp y /usr/share/phpmyadmin. También puede controlar el tamaño máximo de archivo, el tamaño máximo post y el máximo de los archivos a subir en la misma solicitud.

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: