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-data
qu'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.
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 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 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 027
afin 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.