OVH Community, votre nouvel espace communautaire.

Sécuriser shell Apache (shell_exec(), system(), ...) sur hébergement multi-clients


TBC_Ly0n
28/05/2015, 18h25
Chez OVH, j'ai pu voir :
- utilisateurs chrootés
- surveillance en temps réel des processus lancés
- certaines commandes interdites

On peut utiliser plein de modules : mpm ITK, suexec, mod_chroot pour sécuriser le tout, mais bon, c'est pas magique non plus.
Il faut être très fin sur les permissions du système et des autres dossiers.

janus57
22/05/2015, 03h43
Citation Envoyé par masterboy
@TBC_Ly0n : Du coup, comment font les hébergeurs qui autorise l'exécution de script, comme OVH ?.
Bonjour,

comme dit plus haut les OVH utilise un système bien particulier sur son mutualisé (de mémoire les instance php/apache sont dans des genre de docker et par utilisateur, après OVH doit surement coupler ça avec des scripts de contrôle pour couper un utilisateur si y a une action "dangereuse" détecté par un robot).

Sinon la plupart des hébergeur qui les autorise doivent surement très bien chrooter leurs utilisateurs et dans le chroot l'impossibilité d'utiliser des binaire ou autre pour faire une escalade de privilège (sinon un petit malin aurait déjà exploiter ce genre de failles chez OVH ou d'autres si y avait pas les protections nécessaire).

Après il faudrait savoir aussi si ces fonctions sont vraiment utile, perso je partirais du principe que ces fonctions ne sont pas utile en PHP sauf créer un énorme trou dans son serveur, ou alors les script qui execute ce genre de fonctions doivent être mis en dehors de apache et inaccessible pour un utilisateur "lamba".

Cordialement, janus57

masterboy
21/05/2015, 22h47
@TBC_Ly0n : Du coup, comment font les hébergeurs qui autorise l'exécution de script, comme OVH ?

@Janus : Je vais me renseigner pour un cloisonnement via selinux.

TBC_Ly0n
21/05/2015, 16h38
Permettre l'exécution d'un script quel qu'il soit est une faille de sécurité : il permet de charger un webshell, injecter tous les outils d'escalade de privilèges, les compiler et ensuite obtenir les droits root sur la machine. Et à partir de là, tu peux considérer que ton serveur est bon pour une réinstallation.

janus57
21/05/2015, 14h41
Citation Envoyé par masterboy
En ce qui concerne open basedir :

1. Il n'est pas actif sur l'ensemble des fonctions PHP.
2. Il n'est pas actif sur les fonctions que j'ai cité (fonctions spécifique au shell).
3. Il est déprécié.
Bonjour,

pour le 3. c'est faut open_basedir n'est pas déprécié, par contre effectivement cela ne touche pas au fonction exec(), shell_exec(), cat() etc...

Sinon pour répondre à cette question :
Je cherche sur le net et je trouve pas grand chose ... comment font les hébergeurs comme OVH ou autres ?
chez 80% des hébergeur ou j'étais ces fonctions était purement et simplement désactivé pour des raisons de sécurité.
Je ne sais pas si chez OVH c'est désactivé ou non mais de mémoire leur mutualisé les user sont chroot et/ou instanciés et/ou virtualisé.

Sinon il est peut être possible de faire un genre de cloisonnement via selinux, après je pourrais pas en dire plus j'ai vu ça sur le net et certains hébergeurs (présence d'un selinux si on fait un shell_exec('ls -alh /'))

Cordialement, janus57

masterboy
21/05/2015, 13h24
En ce qui concerne open basedir :

1. Il n'est pas actif sur l'ensemble des fonctions PHP.
2. Il n'est pas actif sur les fonctions que j'ai cité (fonctions spécifique au shell).
3. Il est déprécié.

sich
21/05/2015, 11h57
L'openbasedir empêche php d'accéder directement à certains fichiers. Mais pas certain que tu puisses bloquer l'execution dans un script via la fonction exec qui se trouverait dans l'environnement openbasedir. Tient un truc à tester.
Par exemple exec('un chemin dans l'openbasedir) et dans ce script qui exécute tu peux appeler d'autres fonctions qui seraient à l'extérieur de cette restriction.

Quelqu'un a testé ça ?

Niloo
21/05/2015, 09h56
http://php.net/manual/fr/ini.core.php#ini.open-basedir

masterboy
21/05/2015, 01h30
Bonsoir à tous,

Voici le contexte : Sécuriser un hébergement multi-clients. Chaque client dispose d'un espace web (/home/user/www) . Chaque VirtualHost est exécuté par son utilisateur unix respectif (userA:userA pour le site A; userB:userB pour le site B etc, ...) grâce à mpm-itk.

Je cherche désormais à sécuriser le shell accessible via les commandes PHP suivantes : shell_exex(), system(), exex(), ...
Bien entendu on ne peut pas simplement désactiver les fonctions dans la configuration du php.ini
Ce que j'entend par sécuriser, c'est empêcher l'affichage ou la modification de certains fichiers sensible (ex : /etc/passwd), l'idéal serait de cloisonner l'utilisateur dans son /home.

La grande question c'est comment faire, sans passer par un chroot de Apache ?

Je cherche sur le net et je trouve pas grand chose ... comment font les hébergeurs comme OVH ou autres ?

Je remercie d'avance les gens expérimentés qui prendrons le temps de me répondre.

Thomas.