Al decidir qué permisos usar, debe saber exactamente quiénes son sus usuarios y qué necesitan. Un servidor web interactúa con dos tipos de usuarios.
Los usuarios autenticados 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, realizan cambios en el sistema mediante SSH o SFTP.
Los usuarios anónimos 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 si tiene cuidado con los permisos que tiene el proceso del servidor web. En muchas distribuciones de Linux, Apache se ejecuta como el www-datausuario, pero puede ser diferente. Use ps aux | grep httpdo ps aux | grep apachepara ver qué usuario está usando Apache en su sistema.
Notas sobre permisos de Linux
Linux y otros sistemas compatibles con POSIX utilizan los permisos tradicionales de Unix. Hay un excelente artículo en Wikipedia sobre los permisos del sistema de archivos, por lo que no repetiré todo aquí. Pero hay algunas cosas que debe tener en cuenta.
Los
scripts interpretados de bit de ejecución (por ejemplo, Ruby, PHP) funcionan bien sin el permiso de ejecución. Solo los 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 enumerar un directorio o servir cualquier archivo dentro de él.
Permisos predeterminados de archivos nuevos
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 la identificación del grupo de la carpeta donde se crean, por lo que habilitaría el bit SGID en la carpeta principal.
Los valores de permiso predeterminados dependen de su umask. El umask resta los permisos de los archivos recién creados, por lo que el valor común de 022 da como resultado la creación de archivos con 755. Al colaborar con un grupo, es útil cambiar su umask a 002 para que los miembros del grupo puedan modificar sus archivos. Y si desea personalizar los permisos de los archivos cargados, debe cambiar la umask para apache o ejecutar chmod después de cargar el archivo.
El problema con 777
Cuando usted es chmod 777su sitio web, no tiene seguridad alguna. Cualquier usuario en el 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 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 explotarse 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 no root generen servicios de escucha accesibles desde el mundo), eso significa que su servidor debe ser iniciado por root (aunque cualquier servidor en su sano juicio caerá inmediatamente a una cuenta menos privilegiada 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, en realidad, los permisos del directorio que contiene, ya que el usuario podría cambiar el nombre el ejecutable) en 777 permite a cualquier usuario 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 directorios para poder navegar
- Apache necesita acceso de lectura a archivos y scripts interpretados
- Apache necesita acceso de lectura / ejecución a directorios que se pueden servir
- Apache necesita acceso de lectura / escritura / ejecución a los 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 otorgue al usuario permisos completos de rwx. Apache todavía necesita acceso para poder servir los archivos, así que configure www-data como el propietario del grupo y otorgue permisos al grupo rx.
En su 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 Apache puede escribir, 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 hace más difícil (pero no imposible *) que otros usuarios en el sistema espíen, 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. ¡Ten cuidado con tu umask! Si crea un nuevo archivo aquí, los valores de los permisos probablemente estarán predeterminados en 755. Puede ejecutar umask 027para que los nuevos archivos tengan un valor predeterminado de 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, utilizamos 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 es útil para nosotros, configurarlo como root es una forma simple de garantizar que no se filtren privilegios. Apache todavía 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 puedan seguir explorando y modificando el contenido de las carpetas cargadas.
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 para su sitio web que Apache, es fácil para otros usuarios explorar 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 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 de mantenedor único, 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 Apache debe poder escribir, 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 usuario propietario de los nuevos archivos coincidirá con el creador en lugar de configurarlo en www-data. Por lo tanto, Apache no podrá leer los archivos nuevos que cree hasta que los haya creado.
* Separación de privilegios de Apache
Mencioné anteriormente que en realidad es posible que otros usuarios husmeen su sitio web sin importar qué tipo de privilegios esté utilizando. De manera 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 hacer cambios. Cualquier usuario que pueda hacer que Apache ejecute un script puede obtener el mismo acceso que tiene el propio Apache.
Para combatir este problema, hay 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 requisitos de seguridad más altos 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 tener desarrolladores que 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 ser entregadas, esas cargas deben almacenarse en algún lugar fuera de la raíz web. De lo contrario, es posible que las personas estén descargando archivos destinados a ser secretos. Por ejemplo, si permite que los estudiantes envíen tareas, deben guardarse en un directorio que Apache no sirve. 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 las listas de control de acceso . Estos permiten un control mucho más sofisticado de los privilegios.
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 por alguna razón.