Por fin luego de tanto trabajar pudimos encontrar el resultado de esta incógnita que agunos lectores de esta web tienen. Si tienes alguna información que compartir puedes dejar tu conocimiento.

Solución:

Solución 1:

Al decidir qué permisos usar, necesita 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 pueden 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.

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 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. Usar ps aux | grep httpd o ps aux | grep apache para ver qué usuario Apache está usando en su sistema.

Notas sobre los permisos de linux

Linux y otros sistemas compatibles con POSIX utilizan permisos tradicionales de Unix. Hay un artículo excelente en Wikipedia sobre los permisos del sistema de archivos, así que no repetiré todo aquí. Pero hay algunas cosas que debe tener en cuenta.

El bit de ejecución

Los scripts interpretados (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, 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.

Permisos predeterminados de archivos nuevos

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 crearon, por lo que habilitaría el bit SGID en la carpeta principal.

Los valores de permiso predeterminados dependen de su umask. La umask resta permisos a los archivos recién creados, por lo que el valor común de 022 da como resultado que los archivos se creen con 755. Al colaborar con un grupo, es útil cambiar la umask a 002 para que los miembros del grupo puedan modificar los archivos que crea. Y si desea personalizar los permisos de los archivos cargados, debe cambiar umask para apache o ejecutar chmod después de que se haya cargado el archivo.

El problema con 777

Cuando usted chmod 777 su sitio web, no tiene seguridad alguna. Cualquier usuario del sistema puede cambiar o eliminar cualquier archivo de 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 alguna vulnerabilidad de programación en su sitio web, puede 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 que son accesibles en todo el mundo), eso significa que su servidor debe ser iniciado por root (aunque cualquier servidor en su sano juicio caerá 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), dejando sus permisos (o, para el caso, los permisos del directorio que lo contiene, ya que el usuario puede 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
Apache necesita acceso de lectura a archivos y scripts interpretados
Apache necesita acceso de lectura / ejecución a directorios servibles
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 del mantenimiento del sitio, configúrelo como propietario del usuario en el directorio del sitio web y otorgue al usuario los permisos rwx completos. Apache todavía necesita acceso para poder entregar los archivos, así que configure www-data como el propietario del grupo y otorgue permisos de rx al grupo.

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 grabadas por Apache, 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 otros usuarios en el sistema husmear, ya que solo el usuario y los propietarios del grupo pueden navegar por el directorio de su sitio web. Esto es útil si tiene datos secretos en sus archivos de configuración. ¡Tenga cuidado con su umask! Si crea un nuevo archivo aquí, los valores de permiso probablemente serán 755 por defecto. Puede ejecutar umask 027 de modo que los archivos nuevos se establezcan por defecto en 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 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, usamos el propietario del grupo para otorgar privilegios a Apache, pero ahora se usa para el grupo de desarrolladores. Dado que el propietario del usuario ya no nos es útil, configurarlo como root es una forma sencilla 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 grabadas 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 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 este es un enfoque común, hay una desventaja. 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 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 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. Esta es una inversión del escenario de un único 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 deben ser grabadas por Apache, 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 con la que hay que tener cuidado con esta solución es que el propietario del usuario de los archivos nuevos coincidirá con el creador en lugar de establecerlo en www-data. Por lo tanto, Apache no podrá leer los archivos nuevos que cree hasta que los utilice.

* Separación de privilegios de Apache

Mencioné anteriormente que en realidad es posible que otros usuarios husmeen 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 demás 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 el propio Apache.

Para combatir este problema, existen varios enfoques para la separación de privilegios en Apache. Sin embargo, cada enfoque 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 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 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 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 descubra que las personas están descargando archivos que debían ser secretos. Por ejemplo, si permite que los estudiantes envíen tareas, deben guardarse en un directorio que no esté disponible en 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 considerar el uso de Listas de control de acceso. Estos permiten un control de privilegios mucho más sofisticado.

Si su sitio web tiene requisitos complejos, es posible que desee escribir un script que configure todos los permisos. Pruébelo a fondo, luego guárdelo en un lugar seguro. Podría valer su peso en oro si alguna vez necesita reconstruir su sitio web por alguna razón.

Solucion 2:

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 diferente a “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 uno para el usuario PHP FastCGI (el usuario con el que se ejecutará el sitio web). Llamemos a estos usuarios respectivamente Beto y bob-www.
Beto tendrá plenos derechosrwx en carpetas, rw- en archivos), para que pueda leer y editar todo el sitio web.
El proceso PHP FastCGI necesita rx derechos sobre 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 darle a PHP FastCGI esta capacidad, se ejecutará como bob-www, y bob-www se agregará al creado automáticamente Beto 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 en algo más que None. Para evitar usar el o parte de los derechos, agrego el www-datos usuario al Beto grupo.

Ahora:

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

Esta es una recapitulación, pero en esta situación, Beto está permitido a SSH. Si no debería haber ningún usuario autorizado a 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 conocimientos de Linux), cree dos usuarios de todos modos, pero proporcione /bin/false como caparazón para Beto también, y deshabilite 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 (propietario) los derechos 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.

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, carga), pertenecerá a bob-www: bob, y Beto solo podrá leerlo. Quizás setuid en el directorio pueda resolver el problema.

Solución 3:

Dada la clasificación 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 ignorasetuid, 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 pude obtener los permisos 570 para que funcionaran hasta que reinicié el servidor, lo que mágicamente solucionó el problema. Estaba perdiendo pelos a un ritmo cada vez mayor por ese problema aparentemente simple …

Solución 4:

Voy con esta configuración:

Todos los directorios excepto cargan uno al propietario root y grupo root, permisos para 0755.
Todos los archivos configurados como propietario root y grupo root, permisos para 0644.
Directorio de subidas configurado como propietario root, grupo www-data, permisos para 1770. El bit pegajoso no permite que el propietario del grupo elimine o cambie el nombre del directorio y los archivos que contiene.
Dentro de la carpeta de cargas un nuevo directorio con www-data usuario propietario y grupo, y 0700 permisos para cada www-data usuario que carga archivos.
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 cargas:


   Options -Indexes



   AllowOverride none

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á 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 el tamaño máximo de archivos para cargar en la misma solicitud.

Solución 5:

Cuando tiene un usuario de FTP llamado “leo”, necesita cargar archivos en el directorio web example.com y también requiere que su usuario “apache” pueda crear archivos uploa-files / sesiones / archivos de caché en el directorio de caché, entonces haga lo siguiente:

Este comando asigna a leo como propietario y grupo como apache a example.com, el usuario de apache es parte del grupo apache, por lo que heredará los permisos del grupo 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 example.com

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

lo siguiente es útil para comprender 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

Nos puedes corroborar nuestra publicación fijando un comentario y dejando una valoración te damos la bienvenida.

¡Haz clic para puntuar esta entrada!

(Votos: 1 Promedio: 4)

Tags : Apache 2.2 / Linux / Permissions / Security / Web Server /

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