Bonjour. On Mon, 2014-07-28 at 10:14 +0200, Fernando Lagrange wrote: > h. je vais faire monter la réinstallation de ce serveur vers le haut > de la pile des choses à faire ;)
C'est _TOUJOURS_ une bonne idée si tu as le temps, de re-installer au propre une machine ayant été compromise. Le fait de maintenir des scripts php opensource a jour que tu ne déploies pas toi même a toujours été le gros soucis de notre métier. L'adminsys doit s'assurer que le serveur ne peut pas se faire trouer. (je prends wordpress en exemple, mais vous pouvez remplacer ca par n'importe quel projet opensource, ca peut être phpmyadmin, qui a la palme d'or du trouage) Les développeurs déploient un wordpress d'il y a 4 ans, (modifié par leurs petites mains) et donc ce wordpress n'est plus "mainline". On ne peut plus mettre ce wordpress a jour en suivant la méthode proposée par les développeurs du logiciel. Et la il va en résulter une bataille des responsabilités entre dev et sysadmin. Pour se prémunir de soucis plus grand et gros qu'un script php opensource hack via une requête POST a la con, nous avons en tant qu'adminsys une potion magique. Ca s'appelle chroot() + php-fpm + nginx. Le script php ne sera executé qu'avec les droits de l'utilisateur spécifique de ce vhost, et ne pourra pas sortir de sa prison. Ainsi si le site se fait trouer, tu es peinard, l'utilisateur est cloisonné. La seule responsabilité du hack est donc sur les épaules des déployeurs de scripts opensource troués non a jour ;) La, dans ton cas, tu vérifies si ton /etc a été modifié, ainsi que ton kernel afin de voir si tu as un rootkit, mais tu ne pourras jamais en être certain. Tu ne devrais jamais avoir a te mettre dans une telle position, si tu veux mon avis :) Avec la méthode cité ci-avant, tu es plus peinard. -- Alexandre Legrix <[email protected]> _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
