Discussion :

[DKreeK]

Salut à tous,

Je suis entrain de reconfigurer mon serveur de A à Z car j'ai eu des petits problème de piratage. Les attaques venaient de site hébergé avec des failles et je me suis retrouver avec des fichier PHP uploadé qui permettait de faire plein de truc pas trés cool !!!!

Je cherche donc a sécurisé un max mon serveur (contrairement à avant) et je suis sur la conf d'apache. Je suis sous Debian avec Apache2, PHP5 et MySQL5. L'arborescence est la suivante :

/var/www/domaine1.dtl/www/
/var/www/domaine2.dtl/www/
/var/www/domaine3.dtl/www/

Précédemment tout était sous l'user www-data:www-data ce qui m'a posé quelque petit problème de sécurité. J'ai donc pas mal parcouru le forum et j'ai trouvé deux solutions pour sécurisé tout ça :

1) Utiliser php en module tel que je l'ai aujourd'hui et limiter l'accès via le fichier de conf d'apache. Exemple :

Code :

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

1
2
3
4
5
<Directory /var/www/domaine1.dtl>
    php_admin_value upload_tmp_dir "/var/www/domaine1.dtl/tmp"
    php_admin_value session.save_path "/var/www/domaine1.dtl/sessions"
    php_admin_value open_basedir "/var/www/domaine1.dtl/"
</Directory>

2) Utiliser suPHP ou suExec+fastCGI. Cette solution permet de créer des user différents pour chaque site (mais appartenant tous au group www-data) et du coup personne ne peut accéder ailleurs que sur son site du fait des droits. Il faut passer php en CGI.


Mes questions maintenant :
1) La première solution semble être la plus simple à mettre en place. Par contre qu'en est-il exactement de la sécurité ? Un ls permet de remonter ou de lister les sites des voisins ? En supposant que l'on arrive à connaitre le site du voisin, peut-on faire quelque chose ?

2) La deuxième solution semble être la plus sécure. Peut-on y inclure la directive open_basedir pour faire croire que le répertoire /var/www/domaine1.dtl/ est le répertoire racine ? Quand est il des fichier htaccess avec apache en CGI (notamment pour l'URL Rewriting et les limitations d'accès avec login/pass) ?

3) J'ai lu que passé en CGI ralentissait l'affichage des page plutôt que l'utilisation de PHP en module. Quel est exactement ce ralentissage. J'héberge de tout petit site perso et 2 sites avec un peu plus de trafic (400 visites jour sur l'un et 5000 visites jour sur l'autre). Si le ralentissement n'est pas significatif sur ces sites, cella vaut le coup de passer en CGI.

4) J'ai lu également qu'il ne fallait plus utiliser le safe_mode (je ne l'utilisait pas avant, mais je pensais l'activer maintenant) et plutot suPHP ou suExec. Est exact ?

5) Enfin dernière question, j'ai lu que suPHP était une version de suExec adapté au PHP mais j'ai également lu que suExec + fastCGI était plus rapide. Que faut-il mieux mettre en place ?

Merci d'avance pour vos futures réponses

[julp]

1) La première solution semble être la plus simple à mettre en place. Par contre qu'en est-il exactement de la sécurité ? Un ls permet de remonter ou de lister les sites des voisins ? En supposant que l'on arrive à connaitre le site du voisin, peut-on faire quelque chose ?

Les autres solutions ne sont guère plus compliquées à mettre en place. Par contre que vient faire ls ici ? Il n'est pas question d'un chroot ici.

2) La deuxième solution semble être la plus sécure. Peut-on y inclure la directive open_basedir pour faire croire que le répertoire /var/www/domaine1.dtl/ est le répertoire racine ? Quand est il des fichier htaccess avec apache en CGI (notamment pour l'URL Rewriting et les limitations d'accès avec login/pass) ?

Plus "sécure" : erreur ! N'oublions pas que l'exécution du script fait intervenir un exécutable setuid root donc toute faille à ce niveau est critique.

open_basedir peut, effectivement, être employée en plus. Par contre, du fait de l'utilisation CGI de PHP (au lieu de module), toutes les directives (.htaccess ou non) php_(admin_)flag|value ne seront plus reconnues (ça conduirait à une erreur 500 à moins de développer/trouver/écrire un module dans le but de les ignorer). Il existe cependant une solution, un brin subtil, consistant à faire intervenir une extension PHP (htscanner).

3) J'ai lu que passé en CGI ralentissait l'affichage des page plutôt que l'utilisation de PHP en module. Quel est exactement ce ralentissage. J'héberge de tout petit site perso et 2 sites avec un peu plus de trafic (400 visites jour sur l'un et 5000 visites jour sur l'autre). Si le ralentissement n'est pas significatif sur ces sites, cella vaut le coup de passer en CGI.

C'est ce qu'on en dit mais paradoxalement la mémoire est mieux gérée en fonction des besoins de vos scripts. Et niveau sécurité, le jeu n'en vaut-il pas la chandelle ?

4) J'ai lu également qu'il ne fallait plus utiliser le safe_mode (je ne l'utilisait pas avant, mais je pensais l'activer maintenant) et plutot suPHP ou suExec. Est exact ?

Tout dépend de quel aspect du safe_mode, il est question ... Le safe_mode pose plus de problème qu'il n'en résout au niveau des fichiers justement. C'est d'ailleurs ce qui lui vaut la porte en PHP 6, contrairement à son "collègue" open_basedir qui perdure (et dont le fonctionnement est totalement différent).

5) Enfin dernière question, j'ai lu que suPHP était une version de suExec adapté au PHP mais j'ai également lu que suExec + fastCGI était plus rapide. Que faut-il mieux mettre en place ?

Il faut tout en prendre en compte, notamment l'aspect pratique du point de vue de l'administrateur. Documentez-vous et expérimentez (de toute façon vous serez bien obligés de passer par cette étape avant de toucher à votre serveur de prod).

[DKreeK]

1) La première solution semble être la plus simple à mettre en place. Par contre qu'en est-il exactement de la sécurité ? Un ls permet de remonter ou de lister les sites des voisins ? En supposant que l'on arrive à connaitre le site du voisin, peut-on faire quelque chose ?

Les autres solutions ne sont guère plus compliquées à mettre en place. Par contre que vient faire ls ici ? Il n'est pas question d'un chroot ici.

Je parlais de la fonction ls pour lister le contenu d'un dossier. Mais en PHP, j'utiliserais plus un script du genre :

Code :

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

1
2
3
4
5
6
7
8
9
<?php
if ($handle = opendir('/')) {
    echo "Files:\n";
    while (false !== ($file = readdir($handle))) {
        echo "$file\n";
    }
    closedir($handle);
}
?>

Par contre la mise en place de la directive open_basedir empechera ce script de fonctionner. De pus j'ai lu que les liens symboliques sont résolus, ce qui fait que cette restriction ne peut être contournée par un lien symbolique.

Je règle aussi les problèmes d'accés aux répertoires des sites voisins avec la configuration suivante, un script executé depuis le domaine1 ne pourra pas accéder aux fichiers dans le répertoire ou les sous répertoire de /var/www/domaine2.dtl/. Non ?

Code :

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

1
2
3
<Directory /var/www/domaine1.dtl>
    php_admin_value open_basedir "/var/www/domaine1.dtl/www/"
</Directory>

Pour revenir au chroot, j'ai lu plusieurs docs là dessus et bizarrement, tout le monde conseil de ne pas mettre en production ce genre de manip !!! Pour quel raison, je n'ai pas trouvé.

2) La deuxième solution semble être la plus sécure. Peut-on y inclure la directive open_basedir pour faire croire que le répertoire /var/www/domaine1.dtl/ est le répertoire racine ? Quand est il des fichier htaccess avec apache en CGI (notamment pour l'URL Rewriting et les limitations d'accès avec login/pass) ?

Plus "sécure" : erreur ! N'oublions pas que l'exécution du script fait intervenir un exécutable setuid root donc toute faille à ce niveau est critique.
Par contre, du fait de l'utilisation CGI de PHP (au lieu de module), toutes les directives (.htaccess ou non) php_(admin_)flag|value ne seront plus reconnues. Il existe cependant une solution, un brin subtil, consistant à faire intervenir une extension PHP (htscanner).

3) J'ai lu que passé en CGI ralentissait l'affichage des page plutôt que l'utilisation de PHP en module. Quel est exactement ce ralentissage. J'héberge de tout petit site perso et 2 sites avec un peu plus de trafic (400 visites jour sur l'un et 5000 visites jour sur l'autre). Si le ralentissement n'est pas significatif sur ces sites, cella vaut le coup de passer en CGI.

C'est ce qu'on en dit mais paradoxalement la mémoire est mieux gérée en fonction des besoins de vos scripts. Et niveau sécurité, le jeu n'en vaut-il pas la chandelle ?

Pour revenir sur ces deux questions concernant la mise en place de PHP en CGI. Perso je suis pour avoir une sécurité max par rapport aux différents problèmes que j'ai eu récemment. Je n'ai pas testé mais je pense que le ralentissement dont tout le monde parle avec PHP en CGI ne devrait pas trop m'impacter vu le traffic qui circule sur le serveur. Par contre la mise en place de htscanner me parrait indispensable car j'ai besoin de pouvoir définir des directives dans le virtualhost (open_basedir, upload_tmp_dir et session.save_path) mais aussi dans le htaccess (limitation d'accés à certains répertoire et URL Rewriting). L'extension PHP htscanner permet-elle de gérer tout cella ?

Coupler suExec ou suPHP semble être la meilleur solution question sécurité. Seulement j'ai un peu de mal à voir la différence (niveau sécurité) entre un répertoire /var/www/domaine1.dtl avec les droits www-user1:www-data et un répertoire /var/www/domaine2.dtl avec les droits www-user2:www-data si on met en place la directive open_basedir.

5) Enfin dernière question, j'ai lu que suPHP était une version de suExec adapté au PHP mais j'ai également lu que suExec + fastCGI était plus rapide. Que faut-il mieux mettre en place ?

Il faut tout en prendre en compte, notamment l'aspect pratique du point de vue de l'administrateur. Documentez-vous et expérimentez (de toute façon vous serez bien obligés de passer par cette étape avant de toucher à votre serveur de prod).

Je suis tout à fait d'accord, je suis d'ailleurs entrain de configurer un nouveau serveur pour ne pas toucher à celui qui est en production. Je migrerais les sites du 1er vers le 2ème serveur une fois que celui-ci sera pret (config, tests, etc...)

[julp]

Je parlais de la fonction ls pour lister le contenu d'un dossier. Mais en PHP, j'utiliserais plus un script du genre :

Code :

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

1
2
3
4
5
6
7
8
9
<?php
if ($handle = opendir('/')) {
    echo "Files:\n";
    while (false !== ($file = readdir($handle))) {
        echo "$file\n";
    }
    closedir($handle);
}
?>

Par contre la mise en place de la directive open_basedir empechera ce script de fonctionner. De pus j'ai lu que les liens symboliques sont résolus, ce qui fait que cette restriction ne peut être contournée par un lien symbolique.

Oui, mais on pourrait très bien envisager d'exécuter la commande ls (ou autre) via les fonctions système (exec et compagnie) que l'on peut bloquer (directive disable_functions).

Je règle aussi les problèmes d'accés aux répertoires des sites voisins avec la configuration suivante, un script executé depuis le domaine1 ne pourra pas accéder aux fichiers dans le répertoire ou les sous répertoire de /var/www/domaine2.dtl/. Non ?

Code :

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

1
2
3
<Directory /var/www/domaine1.dtl>
    php_admin_value open_basedir "/var/www/domaine1.dtl/www/"
</Directory>

Oui, c'est, selon moi, le minimum.

Pour revenir au chroot, j'ai lu plusieurs docs là dessus et bizarrement, tout le monde conseil de ne pas mettre en production ce genre de manip !!! Pour quel raison, je n'ai pas trouvé.

Il existe plusieurs manières de le faire (Apache seul contre une jail) mais ça peut être relativement complexe à mettre en place. Cela peut aussi ne pas convenir à certains cas (on peut avoir besoin d'accéder à des fichiers/répertoires "externes" - utilisation du module userdir par exemple).

Pour revenir sur ces deux questions concernant la mise en place de PHP en CGI. Perso je suis pour avoir une sécurité max par rapport aux différents problèmes que j'ai eu récemment. Je n'ai pas testé mais je pense que le ralentissement dont tout le monde parle avec PHP en CGI ne devrait pas trop m'impacter vu le traffic qui circule sur le serveur. Par contre la mise en place de htscanner me parrait indispensable car j'ai besoin de pouvoir définir des directives dans le virtualhost (open_basedir, upload_tmp_dir et session.save_path) mais aussi dans le htaccess (limitation d'accés à certains répertoire et URL Rewriting). L'extension PHP htscanner permet-elle de gérer tout cella ?

Oui htscanner peut s'y prêter mais, comme dit plus haut, il existe une ruse pour que vos utilisateurs ne soient pas impactés par les changements de votre environnement. Puisque sans un module ou patch pour Apache pour ignorer les directives PHP, elle conduirait inéluctablement à une erreur 500, c'est d'ailleurs pour cela qu'en temps normal il faudrait placer celles-ci dans des directives <IfModule> (ou semblable) pour qu'elles ne soient pas considérées par Apache. C'est l'extension htscanner, qui se chargera de celles-ci.

Coupler suExec ou suPHP semble être la meilleur solution question sécurité. Seulement j'ai un peu de mal à voir la différence (niveau sécurité) entre un répertoire /var/www/domaine1.dtl avec les droits www-user1:www-data et un répertoire /var/www/domaine2.dtl avec les droits www-user2:www-data si on met en place la directive open_basedir.

Les droits n'interviennent en rien dans la fonctionnalité open_basedir. open_basedir est une liste de répertoires (voir motifs) auxquels PHP peut accéder. Tout fichier en dehors de ceux-ci, ne peut, normalement, pas être manipulé (et même lu) par une quelconque fonction PHP.

[DKreeK]

Bonsoir,

Aprés pas mal de lecture et un peu de reflexion je pense que je vais opter pour la solution avec suPHP. Je devrais ensuite mettre en place l'astuce avec htscanner pour que cella paraisse invisible aux utilisateurs.
En plus des droits des utilisateurs, je resteindrais la directive disable_functions en y mettant les fonctions suivantes : exec,highlight_file,passthru,popen,proc_open,shell_exec,show_source,system. Je jouerais également sur les directives open_basedir, upload_tmp_dir et session.save_path

Je ne vais pas chroot le serveur Apache car je pense que cella devient un peu compliqué pour moi.

Ai je oublié quelque chose ? Bien sur les accés FTP ne permettrons pas à l'utilisateur de connaitre le chemin complet.

Par contre je me pose une question, ne devrais je pas aussi interdir des fonctions du genre chmod, chdir ou wget ? En fait je me demande ce que pourrais faire une personne ayant réussit à uploader son fichier PHP via une faille du site web ?

[julp]

Ai je oublié quelque chose ?

A priori, non (sauf ce que j'aurais moi aussi oublié )

Par contre je me pose une question, ne devrais je pas aussi interdir des fonctions du genre chmod, chdir ou wget ? En fait je me demande ce que pourrais faire une personne ayant réussit à uploader son fichier PHP via une faille du site web ?

chdir n'est pas (plus, plutôt) un problème, même en temps normal.
wget, si vous bloquez les fonctions exec & co, ne pourra alors plus être appelée (rien n'empêche cependant d'avoir un outil similaire en php).
Enfin, un chmod (par PHP), ne pourra affecter que les fichiers de l'utilisateur dont l'usage ne devrait plus être nécessaire puisque le script PHP serait exécuté sous l'identité de son propriétaire (à moins de forcer un fonctionnement différent). C'est tout l'intérêt d'une telle solution également.