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.

[DKreeK]

Ok, merci beaucoup pour toutes ses informations. Je vais essayer de mettre tout ca en place ce week end.

[julp]

Je complète un brin mes précédentes réponses :

Voici le code source du module pour ignorer les directives PHP (pour Apache 2.X ici) :

Code mod_dummy_php.c :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
/**
 * 1. Compiler (en tant que module dynamique) : apxs(2) -i -a -c mod_dummy_php.c
 * 2. Redémarrer Apache
 **/
 
#include "ap_config.h"
#include "httpd.h"
#include "http_config.h"
#ifndef WITHOUT_ADMIN_CMDS
# include "http_log.h"
#endif /* WITHOUT_ADMIN_CMDS */
 
module AP_MODULE_DECLARE_DATA dummy_php_module;
 
#ifndef WITHOUT_ADMIN_CMDS
static const char *php_dummy_admin_handler(cmd_parms *cmd, void *dummy, const char *name, const char *value)
{
    ap_log_error(APLOG_MARK, LOG_NOTICE, 0, cmd->server, "dummy php: admin command '%s' ignored (value: '%s')", name, value);
    return NULL;
}
#endif /* WITHOUT_ADMIN_CMDS */
 
static const char *php_dummy_handler(cmd_parms *cmd, void *dummy, const char *name, const char *value)
{
    return NULL;
}
 
static const command_rec dummy_php_cmds[] =
{
#ifndef WITHOUT_ADMIN_CMDS
    AP_INIT_TAKE2("php_admin_value", php_dummy_admin_handler, NULL, ACCESS_CONF|RSRC_CONF, "Dummy PHP Value Modifier (Admin)"),
    AP_INIT_TAKE2("php_admin_flag", php_dummy_admin_handler, NULL, ACCESS_CONF|RSRC_CONF, "Dummy PHP Flag Modifier (Admin)"),
#endif /* WITHOUT_ADMIN_CMDS */
    AP_INIT_TAKE2("php_flag", php_dummy_handler, NULL, OR_OPTIONS, "Dummy PHP Flag Modifier"),
    AP_INIT_TAKE2("php_value", php_dummy_handler, NULL, OR_OPTIONS, "Dummy PHP Value Modifier"),
    { NULL }
};
 
module AP_MODULE_DECLARE_DATA dummy_php_module = {
    STANDARD20_MODULE_STUFF,
    NULL,           /* create per-directory config structure */
    NULL,           /* merge per-directory config structures */
    NULL,           /* create per-server config structure */
    NULL,           /* merge per-server config structures */
    dummy_php_cmds, /* command apr_table_t */
    NULL            /* register hooks */
};

Puis soit vous le compilez statiquement (en même temps qu'Apache à partir de ses sources) via l'option --with-module soit dynamiquement via apxs (voir commentaire en début de source). On pourrait aussi patcher Apache directement mais c'est une pure perte de temps (mises à jour obligent).

Sans cela, vos utilisateurs seraient obligés de glisser les directives php dans un bloc <IfModule> (comme souligné plus tôt). Exemple :

Code :

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

1
2
3
<IfModule mod_php5.c>
    php_flag magic_quotes_gpc Off
</IfModule>

L'extension htscanner ne présente pas de difficultés particulières et la configuration par défaut (qui cherche à lire les fichiers .htaccess) devrait être suffisante.

[DKreeK]

J'ai des petits problème pour le moment, j'arrive à faire tourner apache avec un utilisateur par virtualhost (avec suPHP). Par contre dés que je met un fichier htacces tout plante. Je n'ai pas accés au serveur pour le moment donc je ne peut post l'erreur.

Par contre j'utilise les packages debian, je n'ai rien compilé hormis htscanner. Par contre ce fichier "mod_dummy_php.c" ne me dit rien du tout. J'ai du louper une étape !!!

[DKreeK]

Bonsoir,

Je cherche, je cherche mais cella ne fonctionne toujours pas !!! Je vais essayer de mettre un maximun d'informations pour essayer de voir ce qui ne va pas dans ma config.

Mon VirtualHost :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
<VirtualHost *>
        ServerAdmin webmaster@domaine.tld
 
        ServerName www.domaine.tld
        ServerAlias domaine.tld
 
        #Ne fonctionne pas
        #suPHP_UserGroup www-domaine www-group
 
        #Ne fonctionne pas
        #php_admin_value open_basedir "/var/www/domaine.tld/www/"
 
        DocumentRoot /var/www/domaine.tld/www
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/domaine.tld/www/>
                Options -Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>
 
        ErrorLog /var/log/apache2/domaine.tld/error.log
 
        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn
 
        CustomLog /var/log/apache2/domaine.tld/access.log combined
        ServerSignature Off
</VirtualHost>

Voici la liste de mes modules pour Apache

Code :

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

1
2
3
4
5
(root - 1) cd /etc/apache2/mods-enabled
(root - 0) ls
alias.load       authz_default.load    authz_user.load  dir.conf  mime.load         setenvif.load  suphp.load
auth_basic.load  authz_groupfile.load  autoindex.load   dir.load  negotiation.load  status.load
authn_file.load  authz_host.load       cgi.load         env.load  rewrite.load      suphp.conf

Contenu du fichier suphp.conf :

Code :

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

1
2
3
4
5
6
7
8
9
<IfModule mod_suphp.c>
        AddHandler x-httpd-php .php .php3 .php4 .php5 .phtml
        suPHP_AddHandler x-httpd-php
        suPHP_Engine on
# # Use a specific php config file (a dir which contains a php.ini file)
#       suPHP_ConfigPath /etc/php4/cgi/suphp/
# # Tells mod_suphp NOT to handle requests with the type <mime-type>.
#       suPHP_RemoveHandler <mime-type>
</IfModule>

Contenu du fichier suphp.load :

Code :

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

LoadModule suphp_module /usr/lib/apache2/modules/mod_suphp.so

La config de mon fichier "/etc/suphp/suphp.conf" :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
[global]
;Path to logfile
logfile=/var/log/suphp/suphp.log
 
;Loglevel
loglevel=info
 
;User Apache is running as
webserver_user=www-data
 
;Path all scripts have to be in
;docroot=/var/www
docroot=/
 
;Path to chroot() to before executing script
;chroot=/mychroot
 
; Security options
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false
 
;Check wheter script is within DOCUMENT_ROOT
;check_vhost_docroot=true
check_vhost_docroot=false
 
;Send minor error messages to browser
errors_to_browser=false
 
;PATH environment variable
env_path=/bin:/usr/bin
 
;Umask to set, specify in octal notation
umask=0077
 
; Minimum UID
min_uid=100
 
; Minimum GID
min_gid=100
 
 
[handlers]
;Handler for php-scripts
x-httpd-php=php:/usr/bin/php-cgi
 
;Handler for CGI-scripts
x-suphp-cgi=execute:!self

Avec un PHPInfo, j'obtiens bien les infos suivante :

Code :

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

1
2
3
4
5
6
7
8
9
htscanner support : enabled  
Extension Version : $Id: htscanner.c,v 1.21 2007/03/21 00:00:05 pajoye Exp $  
htaccess version  : 0.8.1  
 
Directive                 Local Value   Master Value 
htscanner.config_file     .htaccess     .htaccess 
htscanner.default_docroot /             / 
htscanner.default_ttl     300           300 
htscanner.stop_on_error   0             0

Concernant mon fichier htaccess, j'ai essayer de mettre les informations suivantes :

Code :

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

ErrorDocument 404 error.php

Mais rien à faire, lorsque je saisi une URL invalide j'ai une erreur 404 et aucune redirection.

Je n'ai pas encore essayer du toucher au fichier "mod_dummy_php.c" et de le compiler.

Là je ne vois plus trop où chercher. J'arrive à faire fonctionner un script php avec un utilisateur dédié au site, par contre je n'arrive pas à faire fonctionner la directive php_admin_value pour les gérer les variables upload_tmp_dir, session.save_path, open_basedir. Je n'arrive pas notre plus à gérer les directives ErrorDocument et je n'ai pas encore testé mais je pense que n'y l'URL rewriting ni la protection par MDP d'un dossier ne fonctionne.

Un coup de pouce serait le bienvenue.
Merci d'avance.

[julp]

Toutes les directives PHP dont les php_admin_flag|value ne fonctionneront plus puisque PHP n'est plus utilisé comme module. L'extension htscanner ne fait que rechercher et lire les fichiers .htaccess (ou autres suivant configuration), donc elle ne vous permettra de prendre en compte que les directives php_flag|value mais certainement pas php_admin_flag|value qu'on trouverait dans le fichier de configuration d'Apache.

Pour l'authentification et la gestion d'erreur, il faut que la valeur d'AllowOverride soit adaptée pour commencer. Pour la réécriture, il faut en plus donner l'option (directive Options) FollowSymLinks.

[DKreeK]

Ok, cella veut sire que l'on ne peut pas atribuer une valeur différente par virtualhost pour les variables upload_tmp_dir, session.save_path ou open_basedir ?

Sinon j'ai bien la directive AllowOverride à All et ajouté l'option FollowSymLinks :

Code :

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

1
2
3
4
5
6
7
8
<VirtualHost *>
        <Directory /var/www/domaine.tld/www/>
                Options -Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>
</VirtualHost>

Mais cella ne fonctionne pas

[delcedo]

Bonjour !

Je suis aussi très intéressé par la solution de ce problème.

Quelle est l'autre méthode pour faire en sorte qu'un
php_admin_value open_basedir / exec_dir bref, n'importe quoi, puisse fonctionner dans la config des Vhosts ?

Merci !

(J'avais posté ce message sur yahoo answers, mais pas de réponses satisfaisantes)
Admettons que j'ai 2 utilisateurs sur mon serveur Debian : u1 et u2 ; le service apache2 qui tourne en démon et php5 d'installer et totalement fonctionnel.

J'ai deux virtuals hosts : le premier pour u1 et le deuxième pour le site de u2.
Les virtuals hosts sont définis ainsi :

http://u1.domain.tld/ => /home/web/u1/www
http://u2.domain.tld/ => /home/web/u2/www

Maintenant voilà le problème :
u2 crée un fichier /home/web/u2/www/mdp.php contenant :
<?php $mon_mdp_est = "coucou" ?>

u1 essaie d'accéder en faisant http://u2.domain.tld/mdp.php, et bien évidemment rien ne s'affiche.

u1 crée un fichier /home/web/u1/www/crack.php contenant :
<?php system("cat /home/web/u2/www/mdp.php ?>

Il exécute ensuite http://u1.domain.tld/crack.php, et le résultat affiché à l'écran est :
<?php $mon_mdp_est = "coucou" ?>

Ainsi, il a pu récupéré l'information cachée de u2.

Comment donc parer à ce problème ? Quelle est la configuration d'apache à adopter ?

[julp]

Ok, cella veut sire que l'on ne peut pas atribuer une valeur différente par virtualhost pour les variables upload_tmp_dir, session.save_path ou open_basedir ?

Non sauf pour certaines (celles qui le permettent) par .htaccess (se reporter au manuel de PHP : toutes les directives notées PHP_INI_SYSTEM uniquement sont concernées).

Sinon j'ai bien la directive AllowOverride à All et ajouté l'option FollowSymLinks :

Code :

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

1
2
3
4
5
6
7
8
<VirtualHost *>
        <Directory /var/www/domaine.tld/www/>
                Options -Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>
</VirtualHost>

Mais cella ne fonctionne pas

C'est hors contexte et il nous manque des informations pour répondre. Le journal d'erreur vous aidera éventuellement ...

[DKreeK]

u1 crée un fichier /home/web/u1/www/crack.php contenant :
<?php system("cat /home/web/u2/www/mdp.php ?>

Il exécute ensuite http://u1.domain.tld/crack.php, et le résultat affiché à l'écran est :
<?php $mon_mdp_est = "coucou" ?>

Ainsi, il a pu récupéré l'information cachée de u2.

Comment donc parer à ce problème ? Quelle est la configuration d'apache à adopter ?

Pour moi la solution est la directive open_basedir mais je pense qu'il faut que des gourou d'Apache te confirme cella.

[DKreeK]

Non sauf pour certaines (celles qui le permettent) par .htaccess (se reporter au manuel de PHP : toutes les directives notées PHP_INI_SYSTEM uniquement sont concernées).

Finalement je suis entrain de me dire que de remettre apache en module et pouvoir gérer les variables upload_tmp_dir, session.save_path et open_basedir sera beaucoup plus simple niveau configuration et niveau securité équivalent à un suPHP sans ces meme variables... Non ?

[delcedo]

Oui je pense aussi que l'open_basedir est une solution, mais je n'arrive pas à le faire fonctionner dans les virtuals hosts.
D'après ce que j'ai lu sur ce topic, cela serait parce que Apache n'est pas un module. Et à partir de là je coince, comment faire pour mettre Apache en module ?

[delcedo]

En fait si, l'open_basedir fonctionne correctement, il m'empêche bien d'ouvrir des fichiers qui ne se trouvent pas dans le répertoire défini.
Mais cela ne fonctionne qu'avec la commande fopen() et autres du même genre.
Si j'utilise la fonction system() ou du même genre, je ne suis pas restreint par l'open_basedir, et je peux donc exécuter mes commandes unix et voir le contenu du programme.

Apparemment quand on est en safe_mode on, il y a une variable : safe_mode_exec_dir qui permet de restreindre les dossiers d'exécutions des programmes.
Il me faudrait donc la même chose mais sans l'obligation d'avoir le safe_mode d'activé.
Sauriez-vous comment faire ?

[DKreeK]

Utilise :

Code :

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

disable_functions = exec,highlight_file,passthru,popen,proc_open,shell_exec,show_source,system