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

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 s'exécute en tant que www-data: www-data. Le site Web Fabrikam est mis à jour par deux développeurs, Alice et Bob. Les deux sites Web de 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 souhaite connaître le meilleur moyen de configurer des autorisations afin qu'Apache puisse diffuser le contenu, que le site Web soit protégé des attaques et que les développeurs puissent toujours y apporter des modifications. L'un des sites Web est structuré comme suit:

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

Comment les autorisations doivent-elles être définies 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 de pointe, le site Web met automatiquement en cache certaines pages et stocke les résultats dans le dossier de cache. Tout le contenu soumis par les visiteurs du site Web est enregistré dans le dossier des téléchargements.

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 se voir attribuer des 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.

Les utilisateurs anonymes 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 www-dataqu'utilisateur, mais cela peut être différent. Utilisez ps aux | grep httpdou ps aux | grep apachepour voir quel utilisateur Apache utilise sur votre système.

Notes sur les permissions linux

Linux et d’autres systèmes compatibles POSIX utilisent les autorisations Unix traditionnelles. Il existe un excellent article sur Wikipedia sur les autorisations de système de fichiers , je ne vais donc pas tout répéter ici. Mais il y a quelques choses que vous devriez être au courant.

Le bit d'exécution
Les scripts interprétés (par exemple, Ruby, PHP) fonctionnent parfaitement sans l'autorisation d'exécution. Seuls les fichiers binaires et les scripts de shell ont besoin du bit d'exécution. Pour parcourir (entrer) un répertoire, vous devez avoir une 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 du 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 ont été 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. Umask soustrait les autorisations des fichiers nouvellement créés. Ainsi, la valeur commune de 022 entraîne la création de fichiers avec 755. Lors de la collaboration avec un groupe, il est utile de modifier votre umask en 002 afin que les fichiers créés 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 umask pour apache ou exécuter chmod après le téléchargement du fichier.

Le problème avec 777

Lorsque vous utilisez chmod 777votre 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 pour le compte des visiteurs de votre site Web et qu'il peut désormais modifier les mêmes fichiers qu'il est en train d'exécuter. S'il existe des vulnérabilités en matière de programmation sur votre site Web, elles peuvent être exploitées pour altérer votre site Web, y insérer des attaques de phishing ou voler des informations à 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 du monde entier), cela signifie que votre serveur doit être démarré à l'aide de la racine (même si tout serveur sain perd immédiatement 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, en l’occurrence, les autorisations du répertoire contenant, car l’utilisateur peut renommer l'exécutable) en 777 permet à n'importe quel utilisateur d'exécuter un 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 des 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 à des répertoires réparables
• Apache a besoin d'un accès en lecture / écriture / exécution aux répertoires pour le contenu téléchargé

Maintenu par un utilisateur unique

Si un seul utilisateur est responsable de la maintenance du site, définissez-le en tant que propriétaire de l'utilisateur dans le répertoire du site Web et accordez à l'utilisateur toutes les autorisations rwx. Apache a toujours besoin d'un accès pour pouvoir traiter les fichiers. Définissez donc www-data en tant que propriétaire du groupe et accordez-lui les autorisations nécessaires.

Dans votre cas, Eve, dont le nom d'utilisateur est 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 des autorisations pour le propriétaire du groupe afin que www-data dispose d'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 surveiller de près, 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 des autorisations seront probablement par défaut à 755. Vous pouvez exécuter umask 027afin que les nouveaux fichiers par défaut à 640 ( rw- r-- ---).

Maintenu par un groupe d'utilisateurs

Si plusieurs utilisateurs sont responsables de la maintenance du site, vous devez créer un groupe à utiliser pour l'attribution d'autorisations. Il est recommandé de créer un groupe distinct pour chaque site Web et de nommer le groupe d'après ce site.

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 attribuer des privilèges à Apache, mais cette propriété est désormais utilisée pour le groupe des développeurs. Étant donné que l'utilisateur propriétaire ne nous est plus utile, sa configuration en tant que racine est un moyen simple de s'assurer qu'aucun privilège n'est protégé. 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 définir Apache comme propriétaire de l'utilisateur ou comme propriétaire du groupe. De toute façon, il aura tous les accès dont il a besoin. Personnellement, je préfère en faire le propriétaire de l'utilisateur pour 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 que ce soit une approche commune, 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 naviguer sur votre site et de lire les 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 être encore amélioré. Il est parfaitement légal pour le propriétaire d'avoir moins de privilèges que le groupe. Ainsi, au lieu de gaspiller le propriétaire de l'utilisateur en l'attribuant à root, nous pouvons confier Apache au propriétaire de l'utilisateur sur les répertoires et les fichiers de votre site Web. Il s’agit d’un renversement du scénario de responsable unique, mais il 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 dispose d'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 correspond 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 jusqu'à ce que vous les chowniez.

* Séparation des privilèges Apache

J'ai déjà mentionné qu'il était en fait possible pour d'autres utilisateurs de surveiller 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. Ainsi, tout processus Apache peut lire les fichiers de tous les autres sites Web configurés sur le même serveur et même parfois y apporter des modifications. Tout utilisateur pouvant faire exécuter un script à Apache peut obtenir le même accès qu’Apache.

Pour lutter contre ce problème, il existe différentes approches pour privilégier la séparation dans Apache. Cependant, chaque approche présente divers inconvénients en termes de performances et de sécurité. À mon avis, tout site ayant des exigences de sécurité élevées devrait être exécuté sur un serveur dédié plutôt que d'utiliser VirtualHosts sur un serveur partagé.

Considérations supplémentaires

Je n'en ai pas parlé auparavant, mais il est généralement déconseillé de demander aux développeurs de modifier directement le site Web. Pour les sites plus importants, il est beaucoup mieux d'avoir un système de publication qui met à jour le serveur Web à partir du contenu d'un système de contrôle de version. L’approche de responsable unique est probablement idéale, mais vous avez un logiciel automatisé au lieu d’une personne.

Si votre site Web autorise les téléchargements qui n'ont pas besoin d'être fournis, ces téléchargements doivent être stockés quelque part en dehors de la racine Web. Sinon, vous constaterez peut-être que des personnes téléchargent des fichiers censés être secrets. Par exemple, si vous autorisez les étudiants à soumettre des travaux, ils doivent être enregistrés dans un répertoire non desservi par Apache. C'est également une bonne approche pour les fichiers de configuration contenant des secrets.

Pour un site Web avec des exigences plus complexes, vous voudrez peut-être examiner l'utilisation des listes de contrôle d'accès . Celles-ci permettent un contrôle beaucoup plus sophistiqué des privilèges.

Si votre site Web a des besoins complexes, vous pouvez écrire un script qui configure toutes les autorisations. Testez-le soigneusement, puis conservez-le en toute sécurité. Cela pourrait valoir son pesant d'or si vous vous retrouvez parfois dans l'obligation de reconstruire votre site Web pour une raison quelconque.

Je me demande pourquoi tant de gens utilisent (ou recommandent) la partie "autre" (o) 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 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 possédera tous les fichiers, et un pour l’utilisateur PHP FastCGI (l’utilisateur sous lequel le site Web sera exécuté). Appelons ces utilisateurs respectivement bob et bob-www .
• bob aura tous les droits ( rwx sur les dossiers, les fichiers rw ), afin de pouvoir lire et éditer l’ensemble du site.
• Le processus PHP FastCGI a besoin de droits rx sur les dossiers et de droits r-- sur les fichiers, sauf pour des dossiers très spécifiques tels que cache/ou uploads/, où la permission "write" est également nécessaire. Pour donner cette possibilité à PHP FastCGI, il s'exécutera sous la forme bob-www , et bob-www sera ajouté au groupe bob créé automatiquement .
• Nous nous assurons maintenant que le propriétaire et le groupe de tous les répertoires et fichiers sont bob bob .
• Quelque chose manque: nous utilisons même FastCGI, mais Apache a toujours besoin d'un accès en lecture, pour le contenu statique, ou de fichiers .htaccess qu'il essaiera de lire si AllowOverrideest défini sur autre chose 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 u des droits (mais ceci est la note ci-dessous).
• Pour contrôler ce que Apache et PHP peuvent faire, nous pouvons jouer avec la partie g des droits.
• La partie o est toujours définie 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 lorsque Bob utilisateur crée de nouveaux fichiers, car il appartiendra automatiquement à son groupe principal ( bob ).

Ceci est une récapitulation, 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 modifie uniquement le site Web via un panneau d'administration CMS et n'a pas de connaissances en Linux), créez quand même deux utilisateurs, mais donnez /bin/falseégalement un shell pour bob , et désactiver son identifiant.

    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 utilisateurs ont tendance à oublier que la limitation des droits u (propriétaire) est généralement inutile et peu sûre, car le propriétaire d'un fichier peut exécuter la chmodcommande, 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: quand PHP / Apache crée un nouveau fichier (par exemple, 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.

Étant donné le classement Google sur l'excellente réponse ci-dessus, je pense qu'il y a une chose à noter, et il me semble impossible de laisser une note après la réponse.

Si vous continuez avec l’exemple, si vous envisagez d’utiliser www-data en tant que propriétaire et dev-fabrikam en tant que groupe disposant de 570 autorisations sur le répertoire (ou le fichier), il est important de noter que Linux ignore setuid , de sorte que tous les nouveaux fichiers seront la propriété du. utilisateur qui les a créés. Cela signifie qu'après la création 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'avais un problème étrange dans lequel je ne pouvais pas obtenir l'autorisation 570 de fonctionner tant que je n'avais pas redémarré le serveur, ce qui a résolu le problème de façon magique. La perte de cheveux à un rythme croissant par rapport à cette question apparemment simple ...

Je vais avec cette configuration:

1. Tous les répertoires, à l'exception des chargements uniques, vers le propriétaire rootet le groupe root, vers 0755.
2. Tous les fichiers définis sur le propriétaire rootet le groupe root, les autorisations sur 0644.
3. Télécharge le répertoire défini sur propriétaire root, groupe www-data, autorisations sur 1770. Le sticky bit ne permet pas au propriétaire du groupe de supprimer ou de renommer le répertoire et les fichiers qu'il contient.
4. Inside uploads folder un nouveau répertoire avec le www-datapropriétaire utilisateur et le groupe, ainsi que les 0700autorisations pour chaque www-datautilisateur téléchargeant des fichiers.
5. Configuration Apache:

Refuser AllowOverrideet Indexdans le répertoire de téléchargement, afin qu'Apache ne lise pas les .htaccessfichiers, et que l'utilisateur Apache ne puisse pas indexer le contenu du dossier de téléchargement:

<Directory /siteDir>
   Options -Indexes
</Directory>

<Directory /siteDir/uploadDir>
   AllowOverride none
</Directory>

6. php.iniconfiguration:

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, l' www-datautilisateur ne pourra plus accéder aux répertoires autres que siteDir/ /tmpet /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 demande.

Lorsque vous avez un utilisateur FTP appelé "leo", vous devez télécharger des fichiers dans le répertoire Web example.com et vous devez également permettre à votre utilisateur "apache" de pouvoir créer des fichiers uploa-files / sessions / cache dans le répertoire cache, puis procédez comme suit:

Cette commande assigne leo comme propriétaire et le groupe comme apache à example.com. L'utilisateur apache fait partie du groupe apache et hérite donc des autorisations du groupe apache.

chown -R leo: apache example.com

Une autre commande qui assure l’autorisation exacte et répond également aux préoccupations de sécurité.

chmod -R 2774 exemple.com

Ici, le premier numéro 2 concerne 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 signifie pour les autres qu’ils ne peuvent lire qu’auge.

ce qui suit est utile pour comprendre les numéros de permission

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

L'OMI doit prendre en compte:

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

Supposons que vous avez un serveur avec lequel diverses données sont testées par l'utilisateur.

L'utilisateur 'test' a là:

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

Maintenant réfléchissons à:

• une application Web s'exécute sous l' testutilisateur (PHP-FPM) - elle peut supprimer n'importe lequel de ses fichiers!
• une application Web s'exécute sous un testgroupe (PHP-FPM) - elle peut supprimer n'importe lequel de ses fichiers lorsque le répertoire a un «w» pour le groupe et modifier tout fichier comportant un «r» pour le groupe; et il pourrait toujours les lire - vos clés ssh par exemple!

Supposons que PHP est un buggy, et c'est le cas, avez-vous confiance en son open_basedir? Avez-vous chrootvotre processus PHP? Qu'est-ce que vous ne voulez 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 sous les droits d'utilisateur principal ou de groupe principal du propriétaire des données

Ainsi, vous pouvez faire:

• L'utilisateur test est: test:test
• l'utilisateur de test est dans un groupe secondaire, par exemple. test-www
• une application Web (PHP-FPM) s'exécute 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
• testez l'utilisateur s'il veut 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- elle aura le groupe test-www à cause de la setgid sur le répertoire!)

Ainsi, si le processus d'application Web était faux, il ne lirait que des fichiers spécifiques pour lesquels le groupe serait lu, et il ne pourrait écrire que dans uploaddir. Je recommande fortement d'avoir ce uploadrépertoire sur un système de fichiers avec des noexec,nodev,nosuid mountoptions et de surveiller en permanence tous les nouveaux fichiers Bizzare de ce répertoire, ainsi que de surveiller tous les nouveaux processus test-wwwexécutés sous uid.

Sous Linux, on pourrait utiliser ACL pour affiner les autorisations. Si plusieurs personnes doivent 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 des fichiers de données Web, c.-à-d. pour créer un nouveau compte, par exemple. test-upload, et l’utilisateur test gérera les clés ssh pour restreindre l’être humain qui pourrait ssh / sftp à cet endroit. sshd_configconnaît les ExposeAuthInfooptions et peut donc être configuré pour enregistrer la clé ssh 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, quand ils écrivent «sécurisé» sans aucune information sur ce que vous obtenez, je dirais qu’ils mentent.