(petite précision, je suis pas -encore?- un CHATONS, mais sur la courbe d’apprentissage depuis 2-3 ans, voir ma bio)
Question : comment configurer un hébergement mutualisé de façon à peu près sécurisée ?
Objectif : proposer à des tiers de confiance (asso, amis, famille…) à avoir une petite place sur mon serveur dédié y déposer leur site (site statique ou type Wordpress).
Je souhaiterais donner un peu d’autonomie à certains pour lesquels je ne fais pas le boulot sur le site : qu’ils puissent téléverser et mettre à jour le code de leur site, uploader des images, des plugins, etc…
Donc, configurer mon Apache avec les bons modules et permissions de façon à peu près secure ! que les uns et les autres puissent pas se promener n’importe où dans le serveur ou dans les sites des uns des autres en sommes ou n’aient pas la possibilité de péter autre chose que leur propre install’.
Aujourd’hui : j’héberge mes propres sites en mode virtual host Apache très très classique mais qui marche, avec en parallèle Docker qui fait tourner certains autres petites choses (surtout un outil de messagerie ROcketChat et Nextcloud).
J’ai fait un essai pour que mon frère puisse gérer son site sur mon serveur mais on se frotte toujours à des problèmes de permissions mal configurées donc c’est assez pénible et bon… je veux éviter qu’il puisse manipuler les fichiers comme un admin du serveur, lui n’y connais rien hormis vaguement faire un site statique / WP.
Ce que j’ai cherché pour le moment : j’ai lu et appris pas mal de choses dans le process de comprendre les options qui pouvaient s’offrir à moi.
J’ai appris l’existence du concept de chroot jail mais si je ne suis pas certain de savoir le mettre en place
j’ai découvert le concept de umask ce qui pourrait être utile
j’ai découvert après moult recherches l’existence d’un module Apache "mpm-itk" (source) qui permettrait de faire exécuter chaque virtual host par un utilisateur différent et ça me parait une voie possible.
Cela dit l’auteur du billet m’a dit sur twitter que c’est pas si secure que ça non plus et que s’il devait le faire aujourd’hui il utiliserais Rancher (version light de Kubernetes) mais je suis pas certain d’avoir le niveau
Conclusion : Je voulais savoir un peu si certains ici avaient des conseils, ou des ressources à recommander, tout au moins une direction dans laquelle je devrais creuser plutôt qu’une autre pour mettre en place cela.
Je commence à être assez à l’aise sur plusieurs sujets même si je tâtonne souvent et ne suit clairement pas ingé système. Mes exigences de sécurité sont disons de 7/10 sachant que je ne pense pas avoir le niveau pour proposer à des inconnus mon serveur et que ce serait pour des gens de confiance
Je suis curieux de vous lire. Merci à tous et désolé pour le pavé.
Tu devrais peut être regarder du côté de ispconfig , c’est un OS dédié pour mettre en place un hébergement mutualisé. Après ça suppose que tu as une VM (ou peut être un lxc, je ne sais pas si ispconfig tourne sur lxc).
Alternativement tu peux aussi mettre ispconfig sur ton serveur physique et utiliser le mutu pour mettre tes sites et voir si tu peux bricoler pour mettre ton docker nextcloud et roketchat.
Sinon, en mode plus artisanal pour un mutu, yunohost a une app qui s’appelle « my_webapp » qui configure un chroot + PHP fpm avec un user dédié + un accès sftp + une BDD si besoin. Et d’ailleurs même sans utiliser yunohost le script peut aider à configurer la même chose…
Ouais le truc un peu chiant dans la problématique que je décris c’est qu’à l’heure actuelle j’ai un petit panel de services et applis qui tournent sur une seule machine.
Ce que tu me décris me fait piger un truc : si j’avais une machine dédiée à y consacrer (ou une VM) ce serait quand même moins le bazar. Compris !
Après je vais regarder le script de Yunohost il y’a moyen que ça m’apporte quelques billes aussi en effet !
Merci pour ta réponses et tes différentes suggestions, je vais aller investiguer tout ça !
Un utlisateur linux dédié pour chaque site web, un groupe « webgroup » pour les regrouper
Utilisation de PHP-FPM pour les gérer les permissions de PHP (un socket / par site web exécuté sur son propre port avec les permission utilisateur:webgroup
home directories en 0750 (webmachin:www-data)
Ça tourne très bien et j’ai déjà eu un wordpress éclaté sur le serveur et ça n’est pas aller plus loins que le dit wordpress.
d’ailleurs je pige pas que les /home/user soient en rw-r–r-- … (avec le umask 022 par défaut)
En gros si tu chroot pas le mec peut lire les home des autres … sur un serveur ?
En gros si tu chroot pas le mec peut lire les home des autres … sur un serveur ?
Un reliquat de la conf des Unices originels je pense et de la façon dont ça
a été pensé, conçu. Je ne sais plus où j’ai lu l’anecdote (dans une bio de
RMS je crois) mais au début, il n’y avait pas de mdp sur les ordis du MIT
(le concept n’existait même pas)
Je crois bien que c’est ça. C’est justement pour ça que je cherche à modifier tout ça et trouver une méthode ou quoi pour rendre le tout un peu plus solide. Il faut vraiment que j’apprenne comment « chrooter » quelqu’un parce qu’en effet, en tout cas sur un serveur Ubuntu (c’est ce que j’ai) un utilisateur, même s’il ne peut modifier que son dossier, peut visiter non seulement le dossier des autres utilisateurs mais tout le serveur en fait.
Comme je le disais tout n’est pas encore parfaitement clair pour moi.
Par exemple si je définis le chmod en 0750 pour le dossier utilisateur, il me dit qu’il ne peut plus utiliser bash (ce qui parait logique) mais du coup ce n’est pas ce que je planifiais ^^
Bonjour,
À mon avis pour faire ça, proposer un simple accès SFTP est le plus pratique et le plus sûr.
sftp est présent à partir du moment où il y a un serveur ssh, et le premier « s » dans ssh veut dire « secure ».
C’est possible de chrooter les utilisateurs : comme ça t’es tranquille. C’est d’ailleurs plus pratique à chrooter qu’un accès SSH ou ftp classique où il faudrait copier aussi quelques éxécutables et bibliothèques.
Enfin, proposer un accès par authentification avec un jeu de clé est ce qu’il y a de mieux en terme de sécurité à mon humble avis.
Quelques détails à ce propos
Il y a tout de me une petite limitation, le dossier racine du chroot doit être accessible uniquement par l’utilisateur root. Donc il faut un sous dossier www pour que les usagers puissent écrire dedans. Ils ne pourront pas manipuler la racine.
Si une personne a une solution à ce soucis,ne pas hésiter à la partager…
Je ne comprends pas le souci. On peut très bien configurer le serveur pour que sa racine soit le dossier de l’utilisateur dans le chroot.
Exemple:
chroot : /var/www/htdocs/sftpchroot
dossier dans lequel l’user peut écrire : /var/www/htdocs/sftpchroot/batman
Et le serveur sert par défaut /var/www/htdocs/sftpchroot/batman
Sinon, on peut configurer un chroot non pa pour 1 utilisateur mais carrément pour tout un groupe d’utilisateur. C’est alors nettement plus facile, et on remplacerait « batman » par un dossier d’un autre nom où tous les utilisateurs ayant un accès SFTP peuvent pousser des fichiers à la racine du site.
De plus, si les utilisateurs le souhaitent, ils peuvent changer les permissions sur leurs fichiers pour éviter que les autres écrasent leur contenu. Exemple
sftp toto@domain.tld
sftp > cd www
sftp > put fichier.txt
Uploading fichier.txt to www/fichier.txt
sftp > chmod 644 fichier.txt
Ainsi, seul l’utilisateur peut écrire sur ce fichier et tout le monde peut le lire (indispensable pour que le serveur http/gmi/gopher puisse publier le fichier)
