Serveur Apache et hebergement massif : limiter utilisateurs
5 réponses
oliv
Bonjour,
Dans le but d'améliorer la sécurité de mon serveur Apache sous debian,
je fais tourner PHP en CGI et j'utilise le module suPHP pour faire
tourner chaque script PHP avec les droits de son propriétaire.
Cette solution semble combler certain problèmes de sécurité grâce aux
droits restrictifs qu'elle impose à chaque utilisateurs virtuels qui
sont crées lors de l'éxécution d'un script. Mais j'ai remarqué qu'il
était toujours possible pour un script PHP de lire les autres
répertoires de la racine comme /etc par exemple, ce qui pourrait
apporter de précieuse informations concernant les logiciels installés
pour un utilisateur malveillant.
J'ai donc étudier la possibilité de CHrooter les utilisateurs dans leur
repertoire racine mais cela demande de recopier les éxécutables et les
librairies PHP pour chaque repertoire utilisateurs, étant donné que ce
serveur est destiné à de l'hébergement massif (environ 400 virtualhost)
cette solution est inenvisageable.
Existe t-il une solution pour empecher ces utilisateur de lire le
contenu des répertoires du serveur ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fabien LE LEZ
On 15 Feb 2006 10:49:07 GMT, oliv :
Mais j'ai remarqué qu'il était toujours possible pour un script PHP de lire les autres répertoires de la racine comme /etc par exemple
PHP a des systèmes de sécurité (safe_mode et compagnie). <http://www.php.net/manual/en/features.safe-mode.php>
Note : une recompilation sera peut-être nécessaire, en plus d'une modification de php.ini. J'ai déjà vu un hébergeur activer safe_mode dans php.ini, mais en pure perte, car PHP n'avait pas été compilé (./configure) avec les bonnes options.
On 15 Feb 2006 10:49:07 GMT, oliv <olivier.l@soprane.fr>:
Mais j'ai remarqué qu'il
était toujours possible pour un script PHP de lire les autres
répertoires de la racine comme /etc par exemple
PHP a des systèmes de sécurité (safe_mode et compagnie).
<http://www.php.net/manual/en/features.safe-mode.php>
Note : une recompilation sera peut-être nécessaire, en plus d'une
modification de php.ini.
J'ai déjà vu un hébergeur activer safe_mode dans php.ini, mais en pure
perte, car PHP n'avait pas été compilé (./configure) avec les bonnes
options.
Mais j'ai remarqué qu'il était toujours possible pour un script PHP de lire les autres répertoires de la racine comme /etc par exemple
PHP a des systèmes de sécurité (safe_mode et compagnie). <http://www.php.net/manual/en/features.safe-mode.php>
Note : une recompilation sera peut-être nécessaire, en plus d'une modification de php.ini. J'ai déjà vu un hébergeur activer safe_mode dans php.ini, mais en pure perte, car PHP n'avait pas été compilé (./configure) avec les bonnes options.
Eric Razny
Le Wed, 15 Feb 2006 10:49:07 +0000, oliv a écrit :
[ volonté de limiter l'accès à des fichier pour des scripts PHP ] [ Utilisation su suPHP, volonté de ne pas chrooter]
Existe t-il une solution pour empecher ces utilisateur de lire le contenu des répertoires du serveur ?
Bonjour. As tu simplement essayé les acl du filesystem?
Puisque tu es sur une debian je te suggère : apt-get install acl man acl
Je suis toujours assez surpris que ce ne soit pas plus employé. rwxrwxrwx et les ogo suid c'est bien gentil mais on est au 21ème siècle :)
Attention quand même c'est casse-geule[1] :
- penser à compiler ce qu'il faut dans le noyau, monter le fs correctement - en cas de sauvegarde/restauration penser aux acl - difficultés en cas de migration vers d'autres systèmes (une copie de bande ne marchera pas)
Eric
[1] et donc malheureusement contraire à la sécu :(
Le Wed, 15 Feb 2006 10:49:07 +0000, oliv a écrit :
[ volonté de limiter l'accès à des fichier pour des scripts PHP ]
[ Utilisation su suPHP, volonté de ne pas chrooter]
Existe t-il une solution pour empecher ces utilisateur de lire le contenu
des répertoires du serveur ?
Bonjour.
As tu simplement essayé les acl du filesystem?
Puisque tu es sur une debian je te suggère :
apt-get install acl
man acl
Je suis toujours assez surpris que ce ne soit pas plus employé.
rwxrwxrwx et les ogo suid c'est bien gentil mais on est au 21ème siècle :)
Attention quand même c'est casse-geule[1] :
- penser à compiler ce qu'il faut dans le noyau, monter le fs correctement
- en cas de sauvegarde/restauration penser aux acl
- difficultés en cas de migration vers d'autres systèmes (une copie de bande
ne marchera pas)
Eric
[1] et donc malheureusement contraire à la sécu :(
Le Wed, 15 Feb 2006 10:49:07 +0000, oliv a écrit :
[ volonté de limiter l'accès à des fichier pour des scripts PHP ] [ Utilisation su suPHP, volonté de ne pas chrooter]
Existe t-il une solution pour empecher ces utilisateur de lire le contenu des répertoires du serveur ?
Bonjour. As tu simplement essayé les acl du filesystem?
Puisque tu es sur une debian je te suggère : apt-get install acl man acl
Je suis toujours assez surpris que ce ne soit pas plus employé. rwxrwxrwx et les ogo suid c'est bien gentil mais on est au 21ème siècle :)
Attention quand même c'est casse-geule[1] :
- penser à compiler ce qu'il faut dans le noyau, monter le fs correctement - en cas de sauvegarde/restauration penser aux acl - difficultés en cas de migration vers d'autres systèmes (une copie de bande ne marchera pas)
Eric
[1] et donc malheureusement contraire à la sécu :(
Eric Razny
Le Wed, 15 Feb 2006 10:49:07 +0000, oliv a écrit :
[ volonté de limiter l'accès à des fichier pour des scripts PHP ] [ Utilisation su suPHP, volonté de ne pas chrooter]
Existe t-il une solution pour empecher ces utilisateur de lire le contenu des répertoires du serveur ?
Bonjour. As tu simplement essayé les acl du filesystem?
Puisque tu es sur une debian je te suggère : apt-get install acl man acl
Je suis toujours assez surpris que ce ne soit pas plus employé. rwxrwxrwx et les ugo suid c'est bien gentil mais on est au 21ème siècle :)
Attention quand même c'est casse-geule[1] :
- penser à compiler ce qu'il faut dans le noyau, monter le fs correctement - en cas de sauvegarde/restauration penser aux acl - difficultés en cas de migration vers d'autres systèmes (une copie de bande ne marchera pas)
Eric
[1] et donc malheureusement contraire à la sécu :(
Le Wed, 15 Feb 2006 10:49:07 +0000, oliv a écrit :
[ volonté de limiter l'accès à des fichier pour des scripts PHP ]
[ Utilisation su suPHP, volonté de ne pas chrooter]
Existe t-il une solution pour empecher ces utilisateur de lire le contenu
des répertoires du serveur ?
Bonjour.
As tu simplement essayé les acl du filesystem?
Puisque tu es sur une debian je te suggère :
apt-get install acl
man acl
Je suis toujours assez surpris que ce ne soit pas plus employé.
rwxrwxrwx et les ugo suid c'est bien gentil mais on est au 21ème siècle :)
Attention quand même c'est casse-geule[1] :
- penser à compiler ce qu'il faut dans le noyau, monter le fs correctement
- en cas de sauvegarde/restauration penser aux acl
- difficultés en cas de migration vers d'autres systèmes (une copie de bande
ne marchera pas)
Eric
[1] et donc malheureusement contraire à la sécu :(
Le Wed, 15 Feb 2006 10:49:07 +0000, oliv a écrit :
[ volonté de limiter l'accès à des fichier pour des scripts PHP ] [ Utilisation su suPHP, volonté de ne pas chrooter]
Existe t-il une solution pour empecher ces utilisateur de lire le contenu des répertoires du serveur ?
Bonjour. As tu simplement essayé les acl du filesystem?
Puisque tu es sur une debian je te suggère : apt-get install acl man acl
Je suis toujours assez surpris que ce ne soit pas plus employé. rwxrwxrwx et les ugo suid c'est bien gentil mais on est au 21ème siècle :)
Attention quand même c'est casse-geule[1] :
- penser à compiler ce qu'il faut dans le noyau, monter le fs correctement - en cas de sauvegarde/restauration penser aux acl - difficultés en cas de migration vers d'autres systèmes (une copie de bande ne marchera pas)
Eric
[1] et donc malheureusement contraire à la sécu :(
Benjamin Pineau
Le 15 Feb 2006 10:49:07 GMT, oliv écrivait:
Bonjour,
J'ai donc étudier la possibilité de CHrooter les utilisateurs dans leur repertoire racine mais cela demande de recopier les éxécutables et les librairies PHP pour chaque repertoire utilisateurs, étant donné que ce serveur est destiné à de l'hébergement massif (environ 400 virtualhost) cette solution est inenvisageable.
De façon plus "économe", vous pouvez mettre l'ensemble des homes dans une même chroot (donc ne recopier qu'une fois les fichiers nécéssaires).
Existe t-il une solution pour empecher ces utilisateur de lire le contenu des répertoires du serveur ?
Outre l'utilisation d'une chroot, vérifiez le bon positionnement des droits unix (ne pas donner trop de droits aux utilisateurs et à leurs groupes), et fixez le paramètre "open_basedir" dans le fichier de configuration de php (php.ini). Activer le safe_mode n'est pas une mauvaise chose. Bien entendu, ces diverses mesure ne sont pas exclusive, au contraire.
Le 15 Feb 2006 10:49:07 GMT,
oliv <olivier.l@soprane.fr> écrivait:
Bonjour,
J'ai donc étudier la possibilité de CHrooter les utilisateurs dans leur
repertoire racine mais cela demande de recopier les éxécutables et les
librairies PHP pour chaque repertoire utilisateurs, étant donné que ce
serveur est destiné à de l'hébergement massif (environ 400 virtualhost)
cette solution est inenvisageable.
De façon plus "économe", vous pouvez mettre l'ensemble des homes
dans une même chroot (donc ne recopier qu'une fois les fichiers nécéssaires).
Existe t-il une solution pour empecher ces utilisateur de lire le
contenu des répertoires du serveur ?
Outre l'utilisation d'une chroot, vérifiez le bon positionnement des droits
unix (ne pas donner trop de droits aux utilisateurs et à leurs groupes), et
fixez le paramètre "open_basedir" dans le fichier de configuration de php
(php.ini). Activer le safe_mode n'est pas une mauvaise chose.
Bien entendu, ces diverses mesure ne sont pas exclusive, au contraire.
J'ai donc étudier la possibilité de CHrooter les utilisateurs dans leur repertoire racine mais cela demande de recopier les éxécutables et les librairies PHP pour chaque repertoire utilisateurs, étant donné que ce serveur est destiné à de l'hébergement massif (environ 400 virtualhost) cette solution est inenvisageable.
De façon plus "économe", vous pouvez mettre l'ensemble des homes dans une même chroot (donc ne recopier qu'une fois les fichiers nécéssaires).
Existe t-il une solution pour empecher ces utilisateur de lire le contenu des répertoires du serveur ?
Outre l'utilisation d'une chroot, vérifiez le bon positionnement des droits unix (ne pas donner trop de droits aux utilisateurs et à leurs groupes), et fixez le paramètre "open_basedir" dans le fichier de configuration de php (php.ini). Activer le safe_mode n'est pas une mauvaise chose. Bien entendu, ces diverses mesure ne sont pas exclusive, au contraire.
Patrick Mevzek
J'ai donc étudier la possibilité de CHrooter les utilisateurs dans leur repertoire racine mais cela demande de recopier les éxécutables et les librairies PHP pour chaque repertoire utilisateurs, étant donné que ce serveur est destiné à de l'hébergement massif (environ 400 virtualhost) cette solution est inenvisageable.
De façon plus "économe", vous pouvez mettre l'ensemble des homes dans une même chroot (donc ne recopier qu'une fois les fichiers nécéssaires).
Ou avec mod_security qui fait un chroot après le chargement des bibliothèques (donc aucunes copies nécessaires)
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
J'ai donc étudier la possibilité de CHrooter les utilisateurs dans leur
repertoire racine mais cela demande de recopier les éxécutables et les
librairies PHP pour chaque repertoire utilisateurs, étant donné que ce
serveur est destiné à de l'hébergement massif (environ 400 virtualhost)
cette solution est inenvisageable.
De façon plus "économe", vous pouvez mettre l'ensemble des homes
dans une même chroot (donc ne recopier qu'une fois les fichiers nécéssaires).
Ou avec mod_security qui fait un chroot après le chargement des
bibliothèques (donc aucunes copies nécessaires)
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
J'ai donc étudier la possibilité de CHrooter les utilisateurs dans leur repertoire racine mais cela demande de recopier les éxécutables et les librairies PHP pour chaque repertoire utilisateurs, étant donné que ce serveur est destiné à de l'hébergement massif (environ 400 virtualhost) cette solution est inenvisageable.
De façon plus "économe", vous pouvez mettre l'ensemble des homes dans une même chroot (donc ne recopier qu'une fois les fichiers nécéssaires).
Ou avec mod_security qui fait un chroot après le chargement des bibliothèques (donc aucunes copies nécessaires)
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
