Solution 1 :
Lorsque vous décidez des autorisations à utiliser, vous devez savoir exactement qui sont vos utilisateurs et ce dont ils ont besoin. Un serveur Web interagit avec deux types d'utilisateurs.
Authentifié les utilisateurs disposent d'un compte utilisateur sur le serveur et peuvent bénéficier de privilèges spécifiques. Cela inclut généralement les administrateurs système, les développeurs et les comptes de service. Ils apportent généralement des modifications au système à l'aide de SSH ou de SFTP.
Anonyme les utilisateurs sont les visiteurs de votre site Web. Bien qu'ils ne disposent pas des autorisations nécessaires pour accéder directement aux fichiers, ils peuvent demander une page Web et le serveur Web agit en leur nom. Vous pouvez limiter l'accès des utilisateurs anonymes en faisant attention aux autorisations dont dispose le processus du serveur Web. Sur de nombreuses distributions Linux, Apache s'exécute en tant que www-data utilisateur, mais cela peut être différent. Utilisez ps aux | grep httpd ou ps aux | grep apache pour voir quel utilisateur Apache utilise sur votre système.
Remarques sur les autorisations Linux
Linux et d'autres systèmes compatibles POSIX utilisent les autorisations Unix traditionnelles. Il existe un excellent article sur Wikipedia sur les autorisations du système de fichiers, je ne vais donc pas tout répéter ici. Mais il y a certaines choses que vous devez savoir.
Le bit d'exécution
Les scripts interprétés (par exemple Ruby, PHP) fonctionnent très bien sans l'autorisation d'exécution. Seuls les binaires et les scripts shell ont besoin du bit d'exécution. Pour parcourir (entrer) un répertoire, vous devez avoir l'autorisation d'exécution sur ce répertoire. Le serveur Web a besoin de cette autorisation pour répertorier un répertoire ou servir les fichiers qu'il contient.
Autorisations par défaut pour les nouveaux fichiers
Lorsqu'un fichier est créé, il hérite normalement de l'identifiant de groupe de celui qui l'a créé. Mais parfois, vous souhaitez que les nouveaux fichiers héritent de l'ID de groupe du dossier dans lequel ils sont créés. Vous devez donc activer le bit SGID sur le dossier parent.
Les valeurs d'autorisation par défaut dépendent de votre umask. L'umask soustrait les autorisations des fichiers nouvellement créés, de sorte que la valeur commune de 022 entraîne la création de fichiers avec 755. Lorsque vous collaborez avec un groupe, il est utile de changer votre umask en 002 afin que les fichiers que vous créez puissent être modifiés par les membres du groupe. Et si vous souhaitez personnaliser les autorisations des fichiers téléchargés, vous devez soit modifier le umask pour apache, soit exécuter chmod après le téléchargement du fichier.
Le problème avec 777
Quand tu chmod 777 votre site Web, vous n'avez aucune sécurité. Tout utilisateur du système peut modifier ou supprimer n'importe quel fichier de votre site Web. Mais plus sérieusement, rappelez-vous que le serveur Web agit au nom des visiteurs de votre site Web, et maintenant le serveur Web est capable de modifier les mêmes fichiers qu'il exécute. S'il existe des vulnérabilités de programmation sur votre site Web, elles peuvent être exploitées pour défigurer votre site Web, insérer des attaques de phishing ou voler des informations sur votre serveur sans que vous le sachiez.
De plus, si votre serveur fonctionne sur un port bien connu (ce qui devrait empêcher les utilisateurs non root de générer des services d'écoute accessibles au monde entier), cela signifie que votre serveur doit être démarré par root (bien que tout serveur sain tombera immédiatement vers un compte moins privilégié une fois le port lié). En d'autres termes, si vous exécutez un serveur Web où l'exécutable principal fait partie du contrôle de version (par exemple, une application CGI), en laissant ses autorisations (ou, d'ailleurs, les autorisations du répertoire contenant, puisque l'utilisateur peut renommer l'exécutable) à 777 autorise tout utilisateur pour exécuter tout exécutable en tant que root.
Définir les exigences
- Les développeurs ont besoin d'un accès en lecture/écriture aux fichiers pour pouvoir mettre à jour le site Web
- Les développeurs doivent lire/écrire/exécuter sur les répertoires pour pouvoir naviguer
- Apache a besoin d'un accès en lecture aux fichiers et aux scripts interprétés
- Apache a besoin d'un accès en lecture/exécution aux répertoires utilisables
- Apache a besoin d'un accès en lecture/écriture/exécution aux répertoires pour le contenu téléchargé
Géré par un seul utilisateur
Si un seul utilisateur est responsable de la maintenance du site, définissez-le comme propriétaire de l'utilisateur dans le répertoire du site Web et accordez à l'utilisateur les autorisations rwx complètes. Apache a toujours besoin d'un accès pour pouvoir servir les fichiers, alors définissez www-data comme propriétaire du groupe et donnez au groupe les autorisations r-x.
Dans votre cas, Eve, dont le nom d'utilisateur pourrait être eve , est le seul utilisateur qui gère 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 vous avez des dossiers qui doivent être accessibles en écriture par Apache, vous pouvez simplement modifier les valeurs d'autorisation pour le propriétaire du groupe afin que www-data ait un accès en écriture.
chmod g+w uploads
ls -l
drwxrws--- 2 eve www-data 4096 Feb 5 22:52 uploads
L'avantage de cette configuration est qu'il devient plus difficile (mais pas impossible*) pour les autres utilisateurs du système d'espionner, car seuls les propriétaires d'utilisateurs et de groupes peuvent parcourir votre répertoire de sites Web. Ceci est utile si vous avez des données secrètes dans vos fichiers de configuration. Faites attention à votre umask ! Si vous créez un nouveau fichier ici, les valeurs d'autorisation seront probablement par défaut à 755. Vous pouvez exécuter umask 027 pour que les nouveaux fichiers soient par défaut à 640 (rw- r-- --- ).
Géré par un groupe d'utilisateurs
Si plusieurs utilisateurs sont responsables de la maintenance du site, vous devrez créer un groupe à utiliser pour attribuer des autorisations. Il est recommandé de créer un groupe distinct pour chaque site Web et de nommer le groupe d'après ce site Web.
groupadd dev-fabrikam
usermod -a -G dev-fabrikam alice
usermod -a -G dev-fabrikam bob
Dans l'exemple précédent, nous avons utilisé le propriétaire du groupe pour donner des privilèges à Apache, mais il est maintenant utilisé pour le groupe des développeurs. Étant donné que l'utilisateur propriétaire ne nous est plus utile, le définir sur root est un moyen simple de s'assurer qu'aucun privilège n'est divulgué. Apache a toujours besoin d'un accès, nous accordons donc un accès en lecture au reste du monde.
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 vous avez des dossiers qui doivent être accessibles en écriture par Apache, vous pouvez faire d'Apache soit le propriétaire de l'utilisateur, soit le propriétaire du groupe. Dans tous les cas, il aura tous les accès dont il a besoin. Personnellement, je préfère en faire l'utilisateur propriétaire afin que les développeurs puissent toujours parcourir et modifier le contenu des dossiers de téléchargement.
chown -R www-data uploads
ls -l
drwxrwxr-x 2 www-data dev-fabrikam 4096 Feb 5 22:52 uploads
Bien qu'il s'agisse d'une approche courante, il y a un inconvénient. Étant donné que tous les autres utilisateurs du système disposent des mêmes privilèges sur votre site Web qu'Apache, il est facile pour les autres utilisateurs de parcourir votre site et de lire des fichiers pouvant contenir des données secrètes, tels que vos fichiers de configuration.
Vous pouvez avoir votre gâteau et le manger aussi
Cela peut encore être amélioré. Il est parfaitement légal pour le propriétaire d'avoir moins de privilèges que le groupe, donc au lieu de gaspiller l'utilisateur propriétaire en l'attribuant à root, nous pouvons faire d'Apache l'utilisateur propriétaire des répertoires et des fichiers de votre site Web. C'est une inversion du scénario du mainteneur unique, mais cela fonctionne tout aussi 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 vous avez des dossiers qui doivent être accessibles en écriture par Apache, vous pouvez simplement modifier les valeurs d'autorisation pour l'utilisateur propriétaire afin que www-data ait un accès en écriture.
chmod u+w uploads
ls -l
drwxrwx--- 2 www-data dev-fabrikam 4096 Feb 5 22:52 fabrikam.com
Une chose à laquelle il faut faire attention avec cette solution est que l'utilisateur propriétaire des nouveaux fichiers correspondra au créateur au lieu d'être défini sur www-data. Ainsi, tous les nouveaux fichiers que vous créez ne seront pas lisibles par Apache tant que vous ne les aurez pas chown.
*Séparation des privilèges Apache
J'ai mentionné plus tôt qu'il est en fait possible pour d'autres utilisateurs d'espionner votre site Web, quel que soit le type de privilèges que vous utilisez. Par défaut, tous les processus Apache s'exécutent sous le même utilisateur www-data, de sorte que n'importe quel processus Apache peut lire les fichiers de tous les autres sites Web configurés sur le même serveur, et parfois même apporter des modifications. Tout utilisateur qui peut demander à Apache d'exécuter un script peut obtenir le même accès qu'Apache lui-même.
Pour lutter contre ce problème, il existe différentes approches de la séparation des privilèges dans Apache. Cependant, chaque approche présente divers inconvénients en termes de performances et de sécurité. À mon avis, tout site avec des exigences de sécurité plus élevées devrait être exécuté sur un serveur dédié au lieu d'utiliser VirtualHosts sur un serveur partagé.
Considérations supplémentaires
Je ne l'ai pas mentionné auparavant, mais c'est généralement une mauvaise pratique que les développeurs modifient directement le site Web. Pour les sites plus volumineux, il est préférable d'avoir une sorte de système de publication qui met à jour le serveur Web à partir du contenu d'un système de contrôle de version. L'approche du responsable unique est probablement idéale, mais au lieu d'une personne, vous avez un logiciel automatisé.
Si votre site Web autorise les téléchargements qui n'ont pas besoin d'être diffusés, ces téléchargements doivent être stockés quelque part en dehors de la racine Web. Sinon, vous pourriez constater que des personnes téléchargent des fichiers qui devaient rester secrets. Par exemple, si vous autorisez les étudiants à soumettre des devoirs, ils doivent être enregistrés dans un répertoire qui n'est pas servi par Apache. C'est également une bonne approche pour les fichiers de configuration qui contiennent des secrets.
Pour un site Web avec des exigences plus complexes, vous voudrez peut-être vous pencher sur l'utilisation des listes de contrôle d'accès. Ceux-ci permettent un contrôle beaucoup plus sophistiqué des privilèges.
Si votre site Web a des exigences complexes, vous pouvez écrire un script qui configure toutes les autorisations. Testez-le soigneusement, puis conservez-le en lieu sûr. Cela pourrait valoir son pesant d'or si jamais vous deviez reconstruire votre site Web pour une raison quelconque.
Solution 2 :
Je me demande pourquoi tant de gens utilisent (ou recommandent) "l'autre" (o) partie des droits Linux pour contrôler ce que peut faire Apache (et/ou PHP). En définissant cette partie droite sur autre chose que "0", vous autorisez simplement le monde entier à faire quelque chose sur le fichier/répertoire.
Mon approche est la suivante :
- Je crée deux utilisateurs séparés. Un pour l'accès SSH/SFTP (si nécessaire), qui possédera tous les fichiers, et un pour l'utilisateur PHP FastCGI (l'utilisateur sous lequel le site Web fonctionnera). Appelons ces utilisateurs respectivement bob et bob-www .
- bob aura tous les droits (rwx sur les dossiers, rw- sur des fichiers), afin qu'il puisse lire et modifier l'ensemble du site.
- Le processus PHP FastCGI nécessite r-x droits sur les dossiers et r-- droits sur les fichiers, sauf pour des dossiers très spécifiques comme
cache/ouuploads/, où l'autorisation "écrire" est également nécessaire. Pour donner cette capacité à PHP FastCGI, il s'exécutera en tant que bob-www , et bob-www sera ajouté au bob créé automatiquement groupe. - Nous nous assurons désormais que le propriétaire et le groupe de tous les répertoires et fichiers sont bob bob .
- Il manque quelque chose :même nous utilisons FastCGI, mais Apache a toujours besoin d'un accès en lecture, pour le contenu statique, ou les fichiers .htaccess qu'il essaiera de lire si
AllowOverrideest défini sur autre chose queNone. Pour éviter d'utiliser le o partie des droits, j'ajoute le www-data utilisateur au bob groupe.
Maintenant :
- Pour contrôler ce que le développeur peut faire, nous pouvons jouer avec le u une partie des droits (mais c'est la note ci-dessous).
- Pour contrôler ce que Apache et PHP peuvent faire, nous pouvons jouer avec le g une partie des droits.
- Le o part est toujours défini sur 0, afin que personne d'autre sur le serveur ne puisse lire ou modifier le site Web.
- Il n'y a pas de problème quand bob l'utilisateur crée de nouveaux fichiers, puisqu'il appartiendra automatiquement à son groupe principal (bob ).
Ceci est un récapitulatif, mais dans cette situation, bob est autorisé à SSH. S'il ne devrait y avoir aucun utilisateur autorisé à modifier le site Web (par exemple, le client ne modifie le site Web que via un panneau d'administration CMS et n'a pas de connaissances Linux), créez quand même deux utilisateurs, mais donnez /bin/false comme coque pour bob ainsi, et désactivez sa connexion.
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 {} \;
Remarque : les gens ont tendance à oublier que limiter le u (propriétaire) est la plupart du temps inutile et peu sûr, puisque le propriétaire d'un fichier peut exécuter le chmod commande, même les droits sont 000.
Dites-moi si mon approche présente des problèmes de sécurité, car je ne suis pas sûr à 100 %, mais c'est ce que j'utilise.
Je pense que cette config a un problème :quand PHP/Apache crée un nouveau fichier (ex. upload), il appartiendra à bob-www:bob , et bob ne pourra que le lire. Peut-être que setuid sur le répertoire peut résoudre le problème.
Solution 3 :
Compte tenu du classement Google sur l'excellente réponse ci-dessus, je pense qu'il y a une chose à noter, et je n'arrive pas à laisser une note après la réponse.
En continuant avec l'exemple, si vous prévoyez d'utiliser www-data en tant que propriétaire et dev-fabrikam en tant que groupe avec 570 autorisations sur le répertoire (ou fichier), il est important de noter que Linux ignore setuid , ainsi tous les nouveaux fichiers appartiendront à l'utilisateur qui les a créés. Cela signifie qu'après avoir créé de nouveaux répertoires et fichiers, vous devrez utiliser quelque chose de similaire à :
chown -R www-data /newdirectory/
chmod -R 570 /newdirectory/
Dans Ubuntu 12.04 pour Rackspace OpenStack, j'ai eu un problème étrange où je ne pouvais pas obtenir les autorisations 570 pour fonctionner jusqu'à ce que j'aie redémarré le serveur, ce qui a résolu le problème comme par magie. Perdait des cheveux à un rythme croissant sur ce problème apparemment simple...
Solution 4 :
Je vais avec cette configuration :
- Tous les répertoires, à l'exception des téléchargements d'un ensemble au propriétaire
rootet grouperoot, autorisations à0755. - Tous les fichiers sont définis sur le propriétaire
rootet grouperoot, autorisations pour0644. - Répertoire de téléchargement défini sur le propriétaire
root, groupewww-data, autorisations sur1770. Le sticky bit ne permet pas au propriétaire du groupe de supprimer ou de renommer le répertoire et les fichiers à l'intérieur. - À l'intérieur du dossier de téléchargement, un nouveau répertoire avec
www-datautilisateur et groupe propriétaire, et0700autorisations pour chaquewww-datautilisateur qui télécharge des fichiers. - Configuration Apache :
Refuser AllowOverride et Index dans le répertoire des téléchargements, afin qu'Apache ne lise pas .htaccess fichiers et l'utilisateur Apache ne peut pas indexer le contenu du dossier de téléchargement :
<Directory /siteDir>
Options -Indexes
</Directory>
<Directory /siteDir/uploadDir>
AllowOverride none
</Directory>
6. php.ini configuration :
open_basedir = /siteDir:/tmp:/usr/share/phpmyadmin
post_max_size = 5M
file_uploads = On
upload_max_filesize = 3M
max_file_uploads = 20
Avec cette configuration, le www-data l'utilisateur ne pourra pas accéder à des répertoires autres que siteDir/ /tmp et /usr/share/phpmyadmin . Vous pouvez également contrôler la taille de fichier maximale, la taille de publication maximale et le nombre maximal de fichiers à télécharger dans la même requête.
Solution 5 :
Lorsque vous avez un utilisateur FTP appelé "leo" qui doit télécharger des fichiers dans le répertoire Web example.com et que vous avez également besoin que votre utilisateur "apache" puisse créer des fichiers uploa-files/sessions/cache dans le répertoire cache, procédez comme suit :
Cette commande attribue leo en tant que propriétaire et groupe en tant qu'apache à example.com, l'utilisateur apache fait partie du groupe apache, il héritera donc des autorisations du groupe apache
chown -R leo:exemple apache.com
Une autre commande qui assure la bonne autorisation et répond également aux problèmes de sécurité.
chmod -R 2774 exemple.com
Ici, le premier numéro 2 est pour le répertoire et garantit que chaque nouveau fichier créé restera dans les mêmes autorisations de groupe et de propriétaire. 77 est pour le propriétaire et le groupe signifie qu'ils ont un accès complet. 4 est pour les autres signifie qu'ils ne peuvent lire qu'à travers.
ce qui suit est utile pour comprendre les numéros d'autorisation
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