Options d'hébergement
Les options d'hébergement d'un site Web sont généralement l'une des suivantes:
- serveur dédié
- serveur privé virtuel (VPS)
- Hébergement partagé
Avec un serveur dédié, un seul site est hébergé sur un ordinateur physique et la configuration est aussi sécurisée que l'ordinateur lui-même.
Avec un VPS, votre logiciel s'exécute sur le même ordinateur physique que les machines virtuelles des autres utilisateurs. Cependant, il est fonctionnellement équivalent à un serveur dédié. Plus important encore, un VPS a la confidentialité et la sécurité d'un serveur dédié.
Avec l'hébergement mutualisé, votre site Web réside sur un système de fichiers partagé avec d'autres utilisateurs. Malheureusement, cela le rend moins sûr que lorsqu'il s'exécute sur un serveur dédié ou un VPS. Le reste de cet article traite de la sécurité d'un WCMS dans un environnement d'hébergement partagé.
Environnement
Un environnement d'hébergement partagé peut être considéré comme composé d'un serveur Web, d'un système de fichiers, d'un fichier de paramètres, d'une base de données et de certains utilisateurs.
Dans les exemples suivants, il est supposé que le compte propriétaire est "tom" et que le fichier de paramètres (contenant les informations d'identification de la base de données) est nommé "settings.php".
Le processus du serveur Web peut s'exécuter avec les autorisations utilisateur du compte propriétaire "tom" ou avec les autorisations de groupe du groupe "www", selon la configuration.
En outre, un environnement Gnu / Linux ou Unix standard est supposé, et il est supposé que le lecteur comprend le système de contrôle d'accès Unix avec des autorisations distinctes de lecture (r), d'écriture (w) et d'exécution / accès au répertoire (x) divisées en trois blocs. (utilisateur, groupe, autre).
Avant de continuer pour discuter de paramètres spécifiques, il peut être utile d'énumérer les conditions que nous voulons remplir:
- Pour qu'un site Web soit opérationnel, le serveur Web doit avoir un accès en lecture à tous les fichiers qui composent le site et un accès au répertoire à tous les répertoires qui composent le site.
- Pour un fonctionnement sécurisé, le serveur Web ne doit avoir accès en écriture à aucun des fichiers qu'il gère.
- Pour un fonctionnement sécurisé, un script Web exécuté par un utilisateur non autorisé ne doit pas avoir accès en lecture aux fichiers appartenant à un autre utilisateur.
- Pour que le propriétaire travaille sur son propre site à l'aide de la CLI, l'utilisateur doit avoir accès en lecture et en écriture à ses propres fichiers.
- Pour protéger les fichiers contre tout accès par d'autres utilisateurs à l'aide de la CLI, le bloc "autre" ne doit pas avoir d' autorisations définies.
Malheureusement, sur un hôte partagé, vous ne pouvez en avoir que 4 sur 5. Je ne sais pas du tout comment vous pouvez satisfaire aux cinq conditions sur un hôte partagé.
Pour autant que je sache, deux configurations différentes sont utilisées par les fournisseurs d'hôtes partagés. Les deux sont abordés ci-dessous, ainsi que les autorisations à utiliser pour protéger au mieux les fichiers et les répertoires, et la condition que la configuration ne remplit pas.
Config 1: le serveur Web s'exécute en tant que propriétaire
C'est AFAIK la configuration la plus utilisée. Le serveur Web s'exécute en tant que propriétaire des fichiers. Cela signifie qu'un utilisateur non autorisé ne peut pas utiliser son utilisateur de serveur Web pour exécuter un script pour lire les fichiers d'un autre utilisateur. Ce type de configuration protège également les utilisateurs les uns des autres dans la CLI.
Cependant, cela signifie également que nous ne pouvons pas avoir d'autorisations distinctes pour le propriétaire et le serveur Web. Pour satisfaire la condition 2 avec ce type de configuration, vous devez restreindre les autorisations d'écriture pour le propriétaire afin d'empêcher l'accès en écriture pour le serveur Web à tout sauf au répertoire de téléchargement.
Autorisations:
Directories: 500 r-x --- --- tom.tom
Files: 400 r-- --- --- tom.tom
settings.php: 400 r-- --- --- tom.tom
Upload Dir.: 700 rwx --- --- tom.tom
Malheureusement, cela signifie que la condition 4 ne peut pas être satisfaite. C'est-à-dire que le site ne peut pas être maintenu via la CLI. Le propriétaire sera contraint d'utiliser une sorte de tableau de bord basé sur le Web pour accéder au site (ma recommandation est que le propriétaire conserve une copie sur un serveur de transfert où il a un accès illimité et reflète les modifications apportées sur le serveur de transfert à l'hôte partagé. ).
Config 2: le serveur Web s'exécute en tant que membre du groupe www
Cette configuration est utilisée par certains fournisseurs (à mon humble avis) moins professionnels d'une solution d'hôte partagé. Le serveur Web s'exécute en tant que membre du groupe www et bénéficie de l'accès en lecture requis via le bloc de groupe:
Autorisations:
Directories: 750 rwx r-x --- tom.www
Files: 640 rw- r-- --- tom.www
settings.php: 640 rw- r-- --- tom.www
Upload Dir.: 770 rwx rwx --- tom.www
Ces paramètres ont l'avantage de donner au propriétaire un accès complet à ses fichiers via la CLI, et restreignent le serveur Web à un accès en lecture uniquement.
Cependant, il ne remplit pas non plus la condition 3. C'est-à-dire qu'il permet à un utilisateur voyou sur l'hôte partagé (ou à un pirate qui a compromis le site d'un autre utilisateur partageant l'hôte) d'exécuter un script pour lire tout fichier pouvant être lu par le serveur Web. Cela permet au script escroc d'accéder au fichier settings.php avec les informations d'identification de la base de données, ce qui rend trivial la prise en charge complète du site.
Ma recommandation est d'éviter ce type de configuration.
Addendum: est-il dangereux d'utiliser un hôte partagé?
Je ne mettrais certainement rien de sensible, comme les numéros de carte de crédit ou les dossiers médicaux, sur un hôte partagé. Mais l'hébergement mutualisé est bon marché, et il y a une attraction à cela. J'utilise moi-même l'hébergement mutualisé pour plusieurs de mes sites. Je n'ai pas encore été piraté, mais je sais que le risque existe et je suis prêt pour le jour où il se produira. Si je suis piraté, je vais tout simplement supprimer tout sur l'hôte partagé et réinstaller le site à partir d'une copie miroir que je garde sur un serveur de transfert sécurisé.
Avec "config 2", le principal problème est les autres . Si un autre site Web avec lequel vous partagez l'hôte est compromis, votre site Web est également le déjeuner. Faire dépendre la sécurité d'une autre partie que vous ne connaissez pas et que vous n'avez aucun contrôle n'est pas une bonne idée. C'est pourquoi ma recommandation est d'éviter les arrangements d'hébergement de type "config 2".
Avec "config 1", vous contrôlez seul la sécurité de votre site Web. C'est mieux (en particulier si vous savez ce que vous faites). Mais ce n'est pas infaillible. Personne n'est parfait, et si vous vous trompez et que votre site est compromis, l'attaquant aura accès à tous les fichiers stockés sur cet hôte qui vous appartient. En d'autres termes, pour minimiser le damange lorsque vous êtes piraté, ne gardez rien sur cet hôte qui pourrait nuire si quelqu'un d'autre y accède. En particulier, ne conservez pas votre e-mail sur cet hôte partagé. Les e-mails contiennent généralement des tonnes de données sensibles, vous ne devez donc pas les placer à proximité d'un serveur Web qui s'exécute en tant que «vous».
Et si votre application Web gère des données sensibles, assurez-vous que votre budget autorise un hôte dédié ou un VPS.
Vous pouvez également consulter ce guide sur la sécurisation des autorisations et de la propriété des fichiers sur Drupal.org.