Discussion :

[fred0655]

bonjour

j'ai fait un serveur web mutualisé (redhat apache 2 php5 mysql4)
Une personne a mis joomla et un composant xplorer
Avec ce composant (mais en fait simplement en php), il arrive à remonter plus haut que son repertoire et à allez chez les autres !

Comment peut on enpecher cela

Est ce que vous connaissez des tutos pour la création d'un serveur web mutualisé ?

Merci par avance

[julp]

Ça dépend comment est(sera) utilisé PHP (module Apache ou non). Dans certains cas, il est possible de compter sur les permissions instaurées sur les fichiers (avec un module comme suPHP qui ferait appel à PHP en CGI puisque le script serait ainsi exécuté sous l'identité de cet utilisateur). Dans tous les cas, vous pouvez au minimum jouer sur la directive open_basedir.

[fred0655]

merci pour la réponse

j'ai installé apache puis php avec un ./configure/make/make install

dans le point de montage /opt, j'ai le repertoire /static et dedans deux dossiers avec dedans chacun des repertoires de chacunes des personnes que j'heberge
dans /opt il y a aussi un dossier /peda dans lequel il y a d'autres sites

chacun des hebergés a un compte linux et appartiennent au meme groupe heberg

chacun des dossiers ou sous dossiers a un chmod de 770 et les fichiers de 660
ils sont la propriété de apache et du groupe heberg

j'ai proftp qui est "securisé" : ils ne peuvent pas remonter plus en avant que leur dossier. quand quelqu'un upload un fichier ou dossier une directive du proftp.conf "chown" avec apache et heberg

s'ils ont des cms joomla ... quand il y a création de dossier ou fichier ou upload de fichiers une directive du httpd.conf fait que le proprietaire devient apache et le groupe heberg

je ne sais pas si je suis clair, eventuellement demain, devant le fichier de config, je pourrais etre plus précis

Merci

[julp]

Oui mais justement le problème ici c'est que toute exécution de script se fait sous une seule et même identité : celle sous laquelle tourne le serveur web et qui a besoin de pouvoir lire les scripts notamment, donc problème. Un bon début serait de renseigner la directive open_basedir (et d'individualiser dans le même temps les répertoires temporaires pour l'upload et les sessions) de sorte à ce que chacun de vos utilisateurs ne puissent lire ou manipuler que les fichiers situés dans l'espace qui lui est attribué (c'est +/- ce qui est réalisé chez Free pour la version 4 de PHP).

[fred0655]

Bonjour et merci pour votre réponse

j'avais cru comprendre que open_basedir etait unique
donc comment je peux bloquer chaque "utilsateur" (et en fait on sait que c'est toujours le meme : apache) dans son repertoire

pour les dossiers upload et session, je mettais meme pas posé le pb puisque c'est du temporaire mais effectivement des personnes mal intentionnées ... (surtout pour les sessions je pense ...)

est ce qu'on trouve quelque part sur internet la configuration du serveur de free (ou autre hebergement mutualisé) parce que moi, je me fais tout à la main :creation des dossiers des comptes des bases mysql. D'un coté c'est à moi de reflechir et de faire des scripts ...

mais j'aimerai trouvé de l'aide pour blinder le serveur et j'ai pas assez de compétence pour le faire de moi meme

en fait, j'aimerai voir les fichiers de configuration de apache et php pour un serveur mutualisé

merci par avance

[julp]

Ça dépend une nouvelle fois de votre configuration Si PHP est utilisé comme module Apache, alors vous pouvez fixer cette limitation par rapport au répertoire (Directive Directory correspondant à la racine du site utilisateur voir plus bas) via la directive php_admin_value. Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<Directory /home/toto>
    # Répertoire pour l'upload
    php_admin_value upload_tmp_dir "/home/toto/tmp"
    # Répertoire pour les sessions
    php_admin_value session.save_path "/home/toto/sessions"
    # Seuls les fichiers situés dans cet espace lui seront accessibles
    php_admin_value open_basedir "/home/toto/:/usr/share/php/pear/"
</Directory>

Et il faut ensuite trouver le moyen de spécifier ces directives à chaque utilisateur (à la création de leur compte par exemple via un script). Notez que Apache propose une directive Include (améliorée sur les versions 2 car elle peut inclure plusieurs fichiers d'un coup par "motif") pour inclure des fichiers de configuration annexes. Ce procédé est très largement utilisé aujourd'hui (distribution GNU/Linux Debian - et ses dérivées - en est très bon exemple ).

De ce que j'ai lu, ovh, utilise (utilisait ?) l'approche que j'évoquais plus haut et qui consiste à faire exécuter le script sous l'identité de son propriétaire. Cependant, il reste exceptionnel que les hébergeurs communiquent leur configuration. Les seules informations que l'on peut obtenir sont généralement celles que l'on lit et peut déduire en tant qu'hébergé (phpinfo surtout si celle-ci n'est pas bloquée/réécrite). Chaque méthode a ses avantages et ses inconvénients (sécurité, performances, possibilité ou non d'utiliser les fichiers .htaccess pour redéfinir certains paramètres de configuration de PHP, etc).

Peut être trouverez-vous le tutoriel Installation complète d'un serveur web sous Debian intéressant : la configuration de PHP n'y est pas traitée mais vous trouverez à sa fin des scripts qui pourraient dans une certaine mesure vous aider ou inspirer du moins.

[fred0655]

merci

ds mon httpd.conf j'ai
LoadModule php5_module modules/libphp5.so
donc c'est un module !
j'avance..

donc votre solution doit marcher et à tester ...


pour le script, pour le moment ce sera du copier coller à la main !!!!
si déjà ça marche et que les utilisateurs peuvent pas aller ailleurs, c'est déjà une avancé

je vais voir ce que je trouve sur la directive Include (j'ai apache2)

je comprends que les hebergeurs ne dévoillent pas leur organisation, mais je pense qu'il doit y avoir des personnes dans le meme cas que moi
on trouve effectivement plein de tuto sur la creation d'un serveur web mais rien sur serveur web mutualisé (ou je m'y prend mal ce qui est possible)

en tout cas un grand merci pour ces pistes

Ca peut paraitre futile pour vous mais ça m'apporte beaucoup, ça m'oblige à trouver d'autres pistes, à pas me decourager

=> Merci

[Balashov]

J'interviens dans la discussion, car c'est un sujet qui à terme pourrait m'intéresser...

Pourquoi ne pas utiliser les UserDir public_html?
Chaque personne aurait ainsi ses propres pages et ne pourrait pas accéder aux scripts des autres hébergés?

Eventuellement, en créant un nouvel alias par user, avec un script d'inscription:
-> définition du $HOME à /opt/nom_user
-> création du répertoire public_html et définition des droits pour que apache puisse aller les lire
-> ajout de l'alias (ou virtual host, je ne maîtrise pas trop le concept) dans le httpd.conf

Bien entendu, la modification du httpd.conf entraine un restart du serveur, ce qui peut être gênant pour les autres utilisateurs...
Il faudrait prévoir un créneau horaire de création des comptes, ou éventuellement un second apache qui prendrait le relais, mais là, ça devient lourd à gérer...

Ensuite, peut-être que je me trompe totalement, auquel cas merci de m'en expliquer les raisons...

[julp]

Pourquoi ne pas utiliser les UserDir public_html?
Chaque personne aurait ainsi ses propres pages et ne pourrait pas accéder aux scripts des autres hébergés?

UserDir ou non : le problème est strictement le même dans la mesure où les scripts PHP sont exécutés sous un seul et même utilisateur, celui sous lequel tourne le serveur et Apache devant pouvoir lire ces scripts (et tout autre document).