Quelles autorisations doivent avoir les fichiers / dossiers de mon site Web sur un serveur Web Linux?

Question

Il s'agit d'une question canonique sur les autorisations de fichiers sur un serveur Web Linux.

J'ai un serveur Web Linux exécutant Apache2 qui héberge plusieurs sites Web. Chaque site Web a son propre dossier dans/var/www /.

/var/www/contoso.com/ /var/www/contoso.net/ /var/www/fabrikam.com/

Le répertoire de base/var/www/appartient à root: root. Apache fonctionne en tant que www-data: www-data. Le site Web Fabrikam est géré par deux développeurs, Alice et Bob. Les deux sites Web Contoso sont gérés par un développeur, Eve. Tous les sites Web permettent aux utilisateurs de télécharger des images. Si un site Web est compromis, l'impact doit être aussi limité que possible.

Je veux connaître la meilleure façon de configurer les autorisations afin qu'Apache puisse diffuser le contenu, que le site Web soit protégé contre les attaques et que les développeurs puissent toujours apporter des modifications. L'un des sites Web est structuré comme suit:

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

Comment définir les autorisations sur ces répertoires et fichiers? J'ai lu quelque part que vous ne devriez jamais utiliser les autorisations 777 sur un site Web, mais je ne comprends pas quels problèmes cela pourrait causer. Pendant les périodes chargées, le site Web met automatiquement en cache certaines pages et stocke les résultats dans le dossier cache. Tout le contenu soumis par les visiteurs du site Web est enregistré dans le dossier de téléchargement.

Nic · Accepted Answer

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.

Les utilisateurs authentifiés ont 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 modifient généralement le système à l'aide de SSH ou SFTP.

Les utilisateurs anonymes sont les visiteurs de votre site Web. Bien qu'ils ne soient pas autorisés à 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. Utilisation 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 des autorisations Unix traditionnelles. Il y a un excellent article sur Wikipedia à propos de Permissions du système de fichiers donc je ne vais pas tout répéter ici. Mais il y a quelques 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 disposer de 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 tous les fichiers qu'il contient.

Autorisations de nouveau fichier par défaut
Lorsqu'un fichier est créé, il hérite normalement de l'ID 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 courante 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 modifier le umask pour Apache ou exécuter chmod après le téléchargement du fichier.

Le problème avec 777

Quand vous 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 que le serveur Web peut désormais 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 endommager votre site Web, insérer des attaques de phishing ou voler des informations à partir de votre serveur sans que vous le sachiez.

De plus, si votre serveur fonctionne sur un port bien conn (ce qui devrait empêcher les utilisateurs non root de générer des services d'écoute accessibles au monde), cela signifie que votre serveur doit être démarré par root ( bien que tout serveur sain d'esprit tombe immédiatement sur un compte moins privilégié une fois le port lié). En d'autres termes, si vous exécutez un serveur Web dont 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, car l'utilisateur pourrait renommer l'exécutable) en 777 permet à tout utilisateur d'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 ont besoin de lire/écrire/exécuter sur les répertoires pour pouvoir parcourir
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é

Maintenu 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 accordez au groupe r-x les autorisations.

Dans votre cas, Eve, dont le nom d'utilisateur peut ê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 de fouiner, car seuls les propriétaires d'utilisateurs et de groupes peuvent parcourir le répertoire de votre site 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 par défaut soient 640 (rw- r-- ---).

Maintenu 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 accorder des privilèges à Apache, mais maintenant cela est utilisé pour le groupe de développeurs. Étant donné que le propriétaire de l'utilisateur ne nous est plus utile, le définir sur root est un moyen simple de garantir qu'aucun privilège ne soit divulgué. Apache a toujours besoin d'un accès, nous donnons 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 le propriétaire de l'utilisateur ou le propriétaire du groupe. De toute façon, il aura tout l'accès dont il a besoin. Personnellement, je préfère en faire le propriétaire de l'utilisateur 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 ont les 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 qui peuvent contenir des données secrètes, telles 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 que le propriétaire ait moins de privilèges que le groupe, donc au lieu de gaspiller le propriétaire de l'utilisateur en l'attribuant à root, nous pouvons faire d'Apache le propriétaire de l'utilisateur sur les répertoires et les fichiers de votre site Web. Il s'agit d'une inversion du scénario du responsable 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 le propriétaire de l'utilisateur 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 montrés.

* Séparation des privilèges Apache

J'ai mentionné plus tôt qu'il était en fait possible pour d'autres utilisateurs de fouiner votre site Web, quel que soit le type de privilèges que vous utilisez. Par défaut, tous les processus Apache s'exécutent comme le même utilisateur www-data, de sorte que tout 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 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 grands sites, il vaut mieux avoir une sorte de système de mise à jour 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 disposez d'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 étaient censés être 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 examiner l'utilisation de 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 souhaiterez peut-être écrire un script qui configure toutes les autorisations. Testez-le soigneusement, puis conservez-le en lieu sûr. Il pourrait valoir son pesant d'or si vous vous retrouvez jamais besoin de reconstruire votre site Web pour une raison quelconque.

Fox · Answer

Je me demande pourquoi tant de gens utilisent (ou recommandent) la partie "autre" (o) des droits Linux pour contrôler ce qui peut faire Apache (et/ou PHP). En définissant cette partie droite sur autre chose que "0", vous permettez simplement au monde entier de 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 détiendra 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 les fichiers), afin qu'il/elle puisse lire et éditer 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/ ou uploads/, où l'autorisation "d'écriture" est également nécessaire. Pour donner PHP FastCGI cette capacité, il fonctionnera comme bob-www, et bob-www sera ajouté à la création automatique - bob groupe.
Nous nous assurons maintenant 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 tentera de lire si AllowOverride est défini sur autre chose que None. Pour éviter d'utiliser la partie o des droits, j'ajoute l'utilisateur www-data au groupe bob.

Maintenant:

Pour contrôler ce que le développeur peut faire, nous pouvons jouer avec la partie des droits (mais ceci la note ci-dessous).
Pour contrôler ce qu'Apache et PHP peuvent faire, nous pouvons jouer avec la partie g des droits.
La partie o est toujours définie sur 0, donc personne d'autre sur le serveur ne peut lire ou modifier le site Web.
Il n'y a pas de problème lorsque bob l'utilisateur crée de nouveaux fichiers, car il appartiendra automatiquement à son groupe principal (bob).

Ceci est un récapitulatif, mais dans cette situation, bob est autorisé à SSH. Si aucun utilisateur ne doit être autorisé à modifier le site Web (par exemple, le client modifie uniquement le site Web 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 Shell pour bob également, 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 les droits (propriétaire) est la plupart du temps inutile et peu sûr, car 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 configuration a un problème: lorsque PHP/Apache crée un nouveau fichier (par exemple, upload), il appartiendra à bob-www: bob, et bob ne fera que pouvoir le lire. Peut-être que setuid sur le répertoire peut résoudre le problème.

Paul · Answer

Étant donné le classement de 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.

Poursuivant 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, donc 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 je redémarre le serveur, ce qui a corrigé comme par magie le problème. Perdait des cheveux à un rythme croissant par rapport à ce problème apparemment simple ...

Krishan Gopal · Answer

Lorsque vous avez un utilisateur FTP appelé "leo", vous devez 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, puis procédez comme suit:

Cette commande attribue Leo comme propriétaire et le groupe Apache à example.com, l'utilisateur Apache fait partie du groupe Apache, donc il héritera des autorisations du groupe Apache

chown -R leo: Apache example.com

Une autre commande qui assure la bonne autorisation et répond également aux préoccupations de sécurité.

chmod -R 2774 example.com

Ici, le premier numéro 2 est pour le répertoire et assure 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 signifient qu'ils ne peuvent que lire en creux.

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

Manolo · Answer

Je vais avec cette configuration:

Tous les répertoires sauf le téléchargement d'un ensemble vers le propriétaire root et le groupe root, les autorisations vers 0755.
Tous les fichiers définis sur le propriétaire root et le groupe root, les autorisations sur 0644.
Télécharge le répertoire défini sur le propriétaire root, groupe www-data, autorisations pour 1770. Le bit collant ne permet pas au propriétaire du groupe de supprimer ou de renommer le répertoire et les fichiers à l'intérieur.
Dans le dossier de téléchargement, un nouveau répertoire avec www-data utilisateur et groupe propriétaires et 0700 autorisations pour chaque www-data utilisateur qui télécharge des fichiers.
Configuration d'Apache:

Refuser AllowOverride et Index dans le répertoire de téléchargement, 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 aux répertoires autres que siteDir/ /tmp et /usr/share/phpmyadmin. Vous pouvez également contrôler la taille maximale du fichier, la taille maximale du message et le nombre maximal de fichiers à télécharger dans la même demande.

Jiri B · Answer

L'OMI doit prendre en compte:

faites-vous confiance à un processus qui lit vos fichiers? par exemple. PHP?

Supposons que vous ayez un serveur dont diverses données sont testées par l'utilisateur.

L'utilisateur "test" a là:

ses données dans $HOMEDIR
son courrier dans $MAIL
ses données pour le web dans /var/www/test

Réfléchissons maintenant à:

une application web fonctionne sous test utilisateur (PHP-FPM) - elle peut supprimer n'importe lequel de ses fichiers!
une application web fonctionne sous test group (PHP-FPM) - elle peut supprimer n'importe lequel de ses fichiers où le répertoire a 'w' pour le groupe et peut modifier n'importe quel fichier qui a 'r' pour le groupe; et il pourrait encore les lire - vos clés ssh par exemple!

Supposons que PHP est bogué, et c'est le cas, faites-vous confiance à son open_basedir? Avez-vous chroot votre PHP? Qu'est-ce que vous ne faites pas, voulez-vous qu'il explore tout le système de fichiers?

Votre processus d'application Web, par exemple. PHP-FPM, devrait alors:

être limité à un chemin spécifique via chroot
ne doit pas s'exécuter avec l'autorisation de l'utilisateur principal ou du groupe principal du propriétaire des données

Ainsi vous pouvez faire:

l'utilisateur de test est: test:test
l'utilisateur de test est dans un groupe secondaire, par exemple. test-www
une application web (PHP-FPM) fonctionne sous test-www:test-www
tester l'utilisateur s'il veut que l'application web puisse lire ses fichiers fera: chmod u=rwX,g=rX,o= /var/www/test/public
teste l'utilisateur s'il souhaite que l'application Web puisse écrire dans son chemin de données Web: chmod u=rwX,g=rwXs,o= /var/www/test/public/upload (ainsi l'application créera de nouveaux fichiers comme: test-www:test-www - il aura un groupe test-www à cause de setgid sur le répertoire!)

Ainsi, si le processus de l'application Web était faux, il ne ferait que lire des fichiers spécifiques qui auraient un groupe lu, et il ne pourrait écrire que dans le répertoire upload dir. Je recommanderais fortement d'avoir ce répertoire upload sur un système de fichiers avec noexec,nodev,nosuid mount options et surveillent en permanence tout nouveau fichier bizzare dans ce répertoire, et surveille également tout nouveau processus sous test-www uid.

Sur Linux, on pourrait utiliser ACL pour mieux régler les autorisations. Si plus d'un humain devait télécharger des données Web, il serait préférable de séparer le compte humain du compte utilisé pour télécharger les fichiers de données Web, c'est-à-dire. pour créer un nouveau compte par exemple. test-upload, et l'utilisateur de test gérerait les clés ssh pour restreindre les humains qui pourraient y utiliser ssh/sftp. sshd_config connaît ExposeAuthInfo options donc il peut être configuré pour enregistrer quelle clé ssh a été utilisée pour télécharger les données.

Je doute vraiment que la plupart des services d'hébergement Web se soucient de la séparation des privilèges, lorsqu'ils écrivent "sécurisé" sans aucune information sur ce que vous obtenez, je dirais qu'ils mentent.