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.
8 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.
0 votos
Ver también ¿Cuál es la mejor manera de manejar los permisos para el usuario www-data de apache2 en /var/www?
0 votos
Usted puede referirse aquí para los detalles completos sobre el permiso que se requiere para ser puesto en los archivos del sitio web y las carpetas en linux serverfault.com/questions/124800/