Faire tourner un serveur sur sa machine est certes très intéressant, mais il faut avoir conscience des risques que l'on encourt.
Et en général, c'est là que le lecteur commence à pâlir et à se dire "M.... c'est ce que j'ai fait. Ca craint....".
- L'utilisateur : Faire tourner un serveur, c'est bien. Mais ce programme là tourne avec quels droits ? Je m'explique : Sous Linux, nous avons différents utilisateurs (par exemple "olivier"), qui ont leur propre compte, et qui utilisent des logiciels. Si l'utilisateur fait un erreur en utilisant un logiciel (ou que celui-ci fasse une erreur), les conséquences ne pourront avoir lieu qu'avec les droits de l'utilisateur.
Par exemple, la commande "rm -rf /" va avoir pour conséquence de supprimer tous les fichiers et tous les répertoires accessibles par la machine (Non, je ne ferais pas un exemple de cette commande, même pour vous faire plaisir... 
). Tout les fichiers vont être détruits ? Non, en fait seul ceux dont l'utilisateur "olivier" a les droits d'écriture y passerons, à commencer par les fichiers de "/home/olivier". Mais les principaux fichiers de la machines (les exécutables, les fichiers de configuration, etc...), et les fichiers des autres utilisateurs seront épargnés. Ouf...
Oui, mais si la commande "rm -rf /" avait été lancé par l'utilisateur root, que ce serait t'il passé ? Et bien, je n'aurais eu plus qu'à m'arracher les cheveux, et tout réinstaller.
Ce petit exemple a pour but de vous faire prendre conscience des problèmes de droits d'accès. Imaginez maintenant qu'un programme serveur soit lancé avec les droits root, et que d'une manière ou d'une autre un logiciel client puisse arriver à faire exécuter une commande par le logiciel serveur, de type "rm -rf /"... Vous avez compris, ou il faut que je vous fasse un dessin ?
Cet exemple est malheureusement très représentatif de la situation d'Internet actuellement. Et si des milliers de machines se font pirater tout les jours par le dernier virus-vers à la mode ("nimda", "kournikova", etc...), c'est souvent parce que le serveur web qui a été touché était lancé avec les droits les plus élevés.
Heureusement il y a une solution. C'est de lancer le serveur avec les droits d'un utilisateur particulier, qui n'a pas accès à grand chose. Si on reprend les commandes "netstat" ou "lsof" vues plus haut, on voit par exemple que :
- Le programme qui tourne sur "localhost.sky.:webcache" a été lancé avec l'utilisateur "privoxy".
- Les différents programmes de type ":domain" sont lancés avec l'utilisateur "named".
Évidement, ces programmes n'ont que des droits très limités, donc les risques sont faibles. En cas d'attaque un peu sévère, ces programmes ne pourraient supprimer qu'une poignée de fichiers.
Certains autres programmes ("httpd2", "ftp", etc...) sont lancés avec des droits root. Horreur ?!?!?! En fait non, car ceux-là peuvent être capable de changer d'utilisateur à la volé, juste avant de commencer à analyser les données venant du client. On le voit bien avec le logiciel "http2", qui :
- Selon "netstat" tourne sous le compte de root ("root 829583 17979/httpd2").
- Par contre, "lsof" indique que la connexion IP est ouverte par l'utilisateur "apache" ("httpd2 17987 apache").
Conclusion : Avant de lancer un serveur, bien faire attention à l'utilisateur qui le lance. Cela se paramètre soit dans les fichiers de configuration du serveur (répertoire "/etc/"), ou carrément dans le script qui lance le démon (répertoire "/etc/init.d/").
- La prison : Même si on a bien fait attention à lancer un serveur avec les droits d'un utilisateur non root, il peut arriver 2 choses :
- Il existe quelque part sur la machine, des fichiers ou des répertoires qui sont en écriture pour tout le monde (Et cela, C'est Mal). Auquel cas cet utilisateur, même si il n'a que des droits limités, pourra quand même supprimer des fichiers.
- Mais le but d'un pirate n'est pas que de détruire. Il peut aussi vouloir récupérer des informations sur votre machine. Par exemple, l'état de votre compte saisit dans gnucash, vos mots de passe pour vos comptes email (exemple : "~/.fetcmailrc"), ou pire encore... Êtes vous sûr que tous vos fichiers et vos répertoires sont tous interdit en lecture / exécution ("rwxr-x--") ? Nannn, pas sur du tout, hein ? Bon, alors vous êtes mûre pour le chroot, "the jail", bref la prison.
L'idée de la technique du "chroot", est de faire exécuter une commande en lui faisant croire que le "/" est à un autre endroit. Pour les utilisateurs de Windows®, cela reviendrait à lancer par exemple le "notepad.exe" depuis le "C:\JAIL\WINDOWS\notepad.exe", en lui faisant croire qu'il est en fait en "C:\WINDOWS\notepad.exe". Mais la technique du "chroot" n'existe pas du tout sous Windows®.
L'intérêt de cette technique est évidente. Le programme s'exécute dans un vrai - faux "/", dans lequel il n'y a rien d'important. Ainsi, si le programme passe sous l'influence de l'intrus, il ne pourra pas sortir de ce faux "/", qui sera donc sa prison...
Pour mettre en oeuvre un "chroot", il faut que le programme en question ait été conçu un minimum pour cela (afin d'éviter d'avoir besoin d'une grande quantité de programmes externes, de devices, etc...), et que surtout la technique de mise en place du "chroot" soit bien documentée ! Cela ne se voit pas dans les exemples ci-dessus, mais sur la configuration de Phoenix, le démon "named" (c'est un "DNS", un Serveur de Nom de Domaine, quoi !) est lancé depuis un "chroot". Je passerai les détails de la configuration, mais voici le résultat.
Les fichiers dont "named" à besoin sont ici :
[root@phoenix /]# find /var/named/
/var/named/
/var/named/dev
/var/named/dev/log
/var/named/dev/null
/var/named/dev/random
/var/named/dev/zero
/var/named/etc
/var/named/etc/localtime
/var/named/etc/named.conf
/var/named/etc/rndc.conf
/var/named/etc/rndc.key
/var/named/var
/var/named/var/named
/var/named/var/named/localhost
/var/named/var/named/10.0.0
/var/named/var/named/internet.net
/var/named/var/named/192.168.0
/var/named/var/named/127.0.0
/var/named/var/named/sky.net
/var/named/var/run
/var/named/var/run/named.pid
Mais en fait, ce que voit "named" lorsqu'il est lancé c'est :
/
/dev
/dev/log
/dev/null
/dev/random
/dev/zero
/etc
/etc/localtime
/etc/named.conf
/etc/rndc.conf
/etc/rndc.key
/var
/var/named
/var/named/localhost
/var/named/10.0.0
/var/named/internet.net
/var/named/192.168.0
/var/named/127.0.0
/var/named/sky.net
/var/run
/var/run/named.pid
Bilan : La technique du chroot est une option intéressante qui permet de limiter grandement les indiscrétions d'un démon qui "serait passé entre les mains" de l'intrus. Malheureusement, cette technique n'est pas fiable à 100%, et si l'intrus est assez fort, il arrivera quand même à sortir de sa prison... C'est dingue, non ?
- Le User-Mode kernel : Bon, là on s'accroche car c'est du costaud ! C'est une nouvelle (*) fonctionnalité du kernel Linux 2.5.x, qui permet de faire fonctionner un kernel Linux dans un autre kernel Linux. Les performances sont clairement réduites, mais c'est l'équivalent à un "chroot" sur le kernel lui-même. Et à priori, on ne peut pas sortir d'une prison comme celle là. Même si cela doit marcher (je ne sais pas, je n'ai pas testé. Un jour peut-être...), c'est quand même sacrément lourd comme technique. Et à moins d'être complètement paranoïaque, ce n'est pas vraiment utilisable pour un particulier. En fait, cette technique a principalement été développée afin de faciliter l'écriture des pilotes de périphériques pour le kernel Linux.
(*) : Disponible à la fin 2002 (kernel 2.5.35). Il m'est d'avis que dans quelques mois, cela paraîtra excessivement moins nouveau comme fonctionnalité...
Bon, arrêtons nous là pour les risques encourus. Comme on l'a vu, une fois que l'intrus a pu prendre la main sur le serveur, il peut arriver à faire des dégâts. Donc il faut l'arrêter avant qu'il ne dialogue avec le serveur. Comment ? En interdisant tout simplement au serveur de lui répondre, pardi ! Et c'est ce que l'on va voir tout de suite...
|
