Quelles permissions doivent avoir les fichiers/dossiers de mon site web sur un serveur web Linux ?

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 d'utilisateur sur le serveur et peuvent se voir attribuer des privilèges spécifiques. Il s'agit généralement des administrateurs système, des développeurs et des comptes de service. Ils apportent généralement des modifications au système en utilisant SSH ou SFTP.

Anonyme Les utilisateurs sont les visiteurs de votre site web. Bien qu'ils n'aient pas le droit d'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 programme www-data utilisateur mais il peut être différent. Utilisez ps aux | grep httpd o ps aux | grep apache pour voir quel utilisateur Apache utilise sur votre système.

Notes sur les permissions linux

Linux et les autres systèmes conformes à POSIX utilisent les permissions traditionnelles d'Unix. Il existe 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 éléments dont vous devez être conscient.

Le bit d'exécution
Les scripts interprétés (par exemple Ruby, PHP) fonctionnent très bien sans la permission d'exécution. Seuls les binaires et les scripts scripts ont besoin du bit execute. Pour pouvoir traverser (entrer) un répertoire, vous devez avoir la permission d'exécuter sur ce répertoire. Le serveur web a besoin de cette permission pour lister un répertoire ou servir les fichiers qu'il contient.

Permissions par défaut des 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'identifiant de groupe du dossier dans lequel ils ont été créés, et vous devez donc activer le bit SGID sur le dossier parent.

Les valeurs de permission par défaut dépendent de votre umask. L'umask soustrait les permissions des fichiers nouvellement créés. Ainsi, 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 voulez personnaliser les permissions des fichiers téléchargés, vous devez soit changer le umask d'apache, soit exécuter chmod après le téléchargement du fichier.

Le problème du 777

Quand vous chmod 777 votre site web, vous n'avez aucune sécurité. N'importe quel utilisateur du système peut modifier ou supprimer n'importe quel fichier de votre site Web. Mais plus sérieusement, n'oubliez pas que le serveur Web agit au nom des visiteurs de votre site Web et qu'il est désormais en mesure de modifier les fichiers qu'il exécute. S'il existe des vulnérabilités de programmation dans votre site Web, elles peuvent être exploitées pour défigurer votre site, lancer des attaques de phishing ou voler des informations sur votre serveur sans que vous le sachiez.

De plus, si votre serveur fonctionne sur un serveur port connu (ce qu'il doit faire pour empêcher les utilisateurs non root de créer des services d'écoute accessibles au monde entier), cela signifie que votre serveur doit être démarré par root (bien que tout serveur sain passe immédiatement à un compte moins privilégié une fois le port lié). En d'autres termes, si vous utilisez un serveur Web où l'exécutable principal fait partie du contrôle de version (par exemple, une application CGI), le fait de laisser ses permissions (ou, d'ailleurs, les permissions du répertoire contenant, puisque l'utilisateur pourrait renommer l'exécutable) à 777 permet à cualquier utilisateur pour exécuter cualquier exécutable en tant que root.

Définir les besoins

• 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 afin de pouvoir naviguer dans le système.
• 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 à servir.
• 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 donnez-lui les droits rwx complets. Apache a toujours besoin d'un accès pour pouvoir servir les fichiers, donc définissez www-data comme le groupe propriétaire et donnez au groupe des autorisations r-x.

Dans votre cas, Eve, dont le nom d'utilisateur pourrait être eve est le seul utilisateur qui maintient 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 de permission pour le groupe propriétaire 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, puisque seuls les propriétaires de l'utilisateur et du groupe 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 de permission seront probablement par défaut à 755. Vous pouvez exécuter umask 027 afin que les nouveaux fichiers soient par défaut en 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 l'attribution des autorisations. Une bonne pratique consiste à créer un groupe distinct pour chaque site Web, et à 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 groupe owner pour donner des privilèges à Apache, mais maintenant il est utilisé pour le groupe developers. Puisque l'utilisateur owner ne nous est plus utile, le définir comme root est un moyen simple de s'assurer qu'aucun privilège ne sera perdu. 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 en sorte qu'Apache soit l'utilisateur propriétaire ou le groupe propriétaire. Dans les deux cas, il aura tous les accès dont il a besoin. Personnellement, je préfère qu'il soit 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 que cette approche soit courante, elle présente un inconvénient. Étant donné que tous les autres utilisateurs du système ont les mêmes privilèges qu'Apache pour votre site web, il est facile pour les autres utilisateurs de naviguer sur votre site et de lire les fichiers qui peuvent contenir des données secrètes, comme 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 le propriétaire de l'utilisateur en l'assignant à 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 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 de permission 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 comme www-data. Ainsi, les nouveaux fichiers que vous créerez ne seront pas lisibles par Apache tant que vous ne les aurez pas chownés.

*Séparation de privilège d'Apache

J'ai mentionné précédemment qu'il est en fait possible pour d'autres utilisateurs de fouiner sur 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 tout processus Apache peut lire les fichiers de tous les autres sites web configurés sur le même serveur, et parfois même y apporter des modifications. Tout utilisateur qui peut faire en sorte qu'Apache exécute un script peut obtenir le même accès qu'Apache lui-même.

Pour combattre ce problème, il existe différentes approches pour séparation des privilèges dans Apache. Cependant, chaque approche présente des inconvénients en termes de performances et de sécurité. À mon avis, tout site ayant des exigences de sécurité plus élevées devrait être exécuté sur un serveur dédié plutôt que d'utiliser des 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 d'avoir des développeurs qui modifient directement le site Web. Pour les sites plus importants, 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 mainteneur unique est probablement idéale, mais au lieu d'une personne, vous avez un logiciel automatisé.

Si votre site Web autorise des téléchargements qui n'ont pas besoin d'être servis, ces téléchargements doivent être stockés quelque part en dehors de la racine Web. Sinon, vous risquez de constater que des personnes téléchargent des fichiers qui étaient censés être secrets. Par exemple, si vous autorisez les étudiants à soumettre des travaux, ceux-ci 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 dont les exigences sont plus complexes, vous pouvez envisager 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 pouvez écrire un script qui configure toutes les autorisations. Testez-le minutieusement, puis gardez-le en sécurité. Il pourrait valoir son pesant d'or si vous vous trouvez un jour dans l'obligation de reconstruire votre site Web pour une raison quelconque.