Plusieurs machines de mon hebergeur (dont celle de mon entreprise) ont
été "hackées de manière soft" (selon l'expression du support) en
exploitant une faille dans un script php.
J'aimerai obtenir quelques informations sur ce qui s'est passé et
comment y remédier (je suis obligé de "soutirer" les infos au support de
mon hébergeur et les explications sont plus que succintes).
Le "hackeur" (toujours selon le support) a installé un backdoor sur les
machines. J'ai pu trouver le fichier responsable : il s'agissait d'un
fichier httpd dans le répertoire /var/spool/cron/ qui lançait le
backdoor.
J'aimerai savoir quelles sont les précautions à prendre pour éviter que
cela ne se reproduise.
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
Laurent Bruder
Pascal wrote:
Le "hackeur" (toujours selon le support) a installé un backdoor sur les machines. J'ai pu trouver le fichier responsable : il s'agissait d'un fichier httpd dans le répertoire /var/spool/cron/ qui lançait le backdoor.
déjà ca signifie que l'utilisateur sous lequel tourne apache (en supposant que ce soit ce serveur http qui est utilisé) a acces au cron.
Dans ma distribution, l'utilisateur "apache" n'a pas le droit d'écrire une crontab, puisqu'il n'est pas inclu dans le groupe "cron" (ni le groupe "at" d'ailleurs). Donc meme en cas de faille d'un script php, celui ci ne pourra pas placer un cron.
Autre précaution a prendre: interdire l'utilisation des commandes "system" par les scripts php, s'il n'y en a pas vraiment besoin. Ou alors les verrouiler pour qu'une entrée détournée sur un scipt ne puisse pas lancer une commande shell.
Bien entendu, tout ça implique de pouvoir configurer son serveur apache t son php.ini ......
Pascal wrote:
Le "hackeur" (toujours selon le support) a installé un backdoor sur les
machines. J'ai pu trouver le fichier responsable : il s'agissait d'un
fichier httpd dans le répertoire /var/spool/cron/ qui lançait le
backdoor.
déjà ca signifie que l'utilisateur sous lequel tourne apache (en
supposant que ce soit ce serveur http qui est utilisé) a acces au cron.
Dans ma distribution, l'utilisateur "apache" n'a pas le droit d'écrire
une crontab, puisqu'il n'est pas inclu dans le groupe "cron" (ni le
groupe "at" d'ailleurs). Donc meme en cas de faille d'un script php,
celui ci ne pourra pas placer un cron.
Autre précaution a prendre: interdire l'utilisation des commandes
"system" par les scripts php, s'il n'y en a pas vraiment besoin. Ou
alors les verrouiler pour qu'une entrée détournée sur un scipt ne puisse
pas lancer une commande shell.
Bien entendu, tout ça implique de pouvoir configurer son serveur apache
t son php.ini ......
Le "hackeur" (toujours selon le support) a installé un backdoor sur les machines. J'ai pu trouver le fichier responsable : il s'agissait d'un fichier httpd dans le répertoire /var/spool/cron/ qui lançait le backdoor.
déjà ca signifie que l'utilisateur sous lequel tourne apache (en supposant que ce soit ce serveur http qui est utilisé) a acces au cron.
Dans ma distribution, l'utilisateur "apache" n'a pas le droit d'écrire une crontab, puisqu'il n'est pas inclu dans le groupe "cron" (ni le groupe "at" d'ailleurs). Donc meme en cas de faille d'un script php, celui ci ne pourra pas placer un cron.
Autre précaution a prendre: interdire l'utilisation des commandes "system" par les scripts php, s'il n'y en a pas vraiment besoin. Ou alors les verrouiler pour qu'une entrée détournée sur un scipt ne puisse pas lancer une commande shell.
Bien entendu, tout ça implique de pouvoir configurer son serveur apache t son php.ini ......
Erwan Lerale
On 29 Sep 2004 16:07:28 GMT, Pascal wrote:
Bonjour,
Plusieurs machines de mon hebergeur (dont celle de mon entreprise) ont été "hackées de manière soft" (selon l'expression du support) en exploitant une faille dans un script php.
J'aimerai obtenir quelques informations sur ce qui s'est passé et comment y remédier (je suis obligé de "soutirer" les infos au support de mon hébergeur et les explications sont plus que succintes).
Le "hackeur" (toujours selon le support) a installé un backdoor sur les machines. J'ai pu trouver le fichier responsable : il s'agissait d'un fichier httpd dans le répertoire /var/spool/cron/ qui lançait le backdoor.
J'aimerai savoir quelles sont les précautions à prendre pour éviter que cela ne se reproduise.
Une solution serait de suivre les conseils suivants : http://www.devshed.com/c/a/PHP/PHP-Security-Mistakes/ http://fr2.php.net/register_globals
A+ r1
On 29 Sep 2004 16:07:28 GMT, Pascal <pascal-no-spam@zyzomys.com> wrote:
Bonjour,
Plusieurs machines de mon hebergeur (dont celle de mon entreprise) ont
été "hackées de manière soft" (selon l'expression du support) en
exploitant une faille dans un script php.
J'aimerai obtenir quelques informations sur ce qui s'est passé et
comment y remédier (je suis obligé de "soutirer" les infos au support de
mon hébergeur et les explications sont plus que succintes).
Le "hackeur" (toujours selon le support) a installé un backdoor sur les
machines. J'ai pu trouver le fichier responsable : il s'agissait d'un
fichier httpd dans le répertoire /var/spool/cron/ qui lançait le
backdoor.
J'aimerai savoir quelles sont les précautions à prendre pour éviter que
cela ne se reproduise.
Une solution serait de suivre les conseils suivants :
http://www.devshed.com/c/a/PHP/PHP-Security-Mistakes/
http://fr2.php.net/register_globals
Plusieurs machines de mon hebergeur (dont celle de mon entreprise) ont été "hackées de manière soft" (selon l'expression du support) en exploitant une faille dans un script php.
J'aimerai obtenir quelques informations sur ce qui s'est passé et comment y remédier (je suis obligé de "soutirer" les infos au support de mon hébergeur et les explications sont plus que succintes).
Le "hackeur" (toujours selon le support) a installé un backdoor sur les machines. J'ai pu trouver le fichier responsable : il s'agissait d'un fichier httpd dans le répertoire /var/spool/cron/ qui lançait le backdoor.
J'aimerai savoir quelles sont les précautions à prendre pour éviter que cela ne se reproduise.
Une solution serait de suivre les conseils suivants : http://www.devshed.com/c/a/PHP/PHP-Security-Mistakes/ http://fr2.php.net/register_globals
