--------------------------------------------------------------- VI.: SECURITE SOUS *NIX && IDS Par groslameur --------------------------------------------------------------- [ Le systeme de logs sous unix ] Un log est en fait un fichier qui enregistre toute activité sur un système en veille, sur un système Unix, on pourrait répartir les fichiers logs en trois grandes catégories: a) les logs gérés par le démon syslogd, son fichier de confi- -guration est /etc/syslog.conf, il contient l'endroit ou se- -ront entreposés des logs relatifs aux messages du noyau (généralement /var/log). Et voici la structure de ce fichier: type.priorité chemin_de_destination Le type définit l'émetteur du message, en général cela sera KERN pour les messages du noyau, USER pour les messages émis par les utilisateurs ou les processus hors système. Il existe plusieurs autres types, DAEMON pour les messages émis par d'autres démons, AUTH pour les messages émis par des comman- -des d'authentification (pour la suite, "man syslogd"). La priorité définit la priorité du message, EMERG (0), pour un éventuel plantage du système, ALERT (1) pour une erreur jugée grave par le système, CRIT (2), pour une erreur devant être corrigée, ERR (3) pour des messages d'erreurs sans gra- -vité, WARNING (4) pour des avertissements d'éventuelles err- -eurs, NOTICE (5), pour des remarques concernant un mauvais fonctionnement du système, INFO (6), pour des messages d'in- -formations, ou DEBUG (7) pour le débogage de programmes. Le chemin de destination est tout simplement le chemin ou sera placé le fichier log (certainement dans un des sous repertoires de /var/log). A noter que le fichier /etc/syslog. conf peut très bien contenir des caractères génériques tels que "*" ou "?". Ces logs sont donc consultables à travers des fichiers, pour les lires faites donc un petit "less" ou "more" pour les plus puristes d'entre vous... b) les logs gérés par le système d'exploitation, c'est a dire wtmp, utmp et lastlog. Les commandes pour afficher ces logs sont "last" (wtmp) pour regarder les dernières connexions/dé- -connexions au système, "w" (utmp) pour regarder les connex- -ions actives sur le système et enfin "lastlog" (lastlog) pour consulter un historique des dernières deconnexions. c) Les logs gérés par l'utilisateur, plus souvent apellés les historiques, en fait un fichier garde des traces de votre pas- -sage, c'est à dire la liste de toutes les commandes que vous avez tapé sur le shell d'un utilisateur. Ce fichier est stocké dans le repertoire de cet utilisateur, il s'agit de ~/.bash_history, qui contient la liste de toutes les dernières commandes effectuées (sur un shell bash en l'occ- -urence). 2 - Indécelables intrusions... Cependant, si un pirate jouit des droits root sur votre système et si il a un minimum de cervelle, il pensera à modifier ou a corrompre ces fichiers logs (que je n'entende pas de "rm -r /var/log" !) Pour un pirate, les opérations courantes seront de rediriger les fichiers logs gérés par le démon syslog vers /dev/null, d'effacer les traces de connexion en faisant un r- -login sur le système cible, d'effacer les historiques du shell à la déconnexion (echo "rm .history" > .logout ; echo "rm .logout" >> .logout), voir de changer la date et l'heure des fichiers modi- -fiés. Si cette dernière opération n'a pas été mise en oeuvre, une simple commande vous permettra de vous montrer les derniers éléments modifiés: $ find / -ctime 0 Bon, le résultat dépendera de l'habilité du pirate... Autre point à surveiller: les lkms (linux kernel modules). Expliquer ce qu'est un lkm nécessiterait d'abord de comprendre le fonctionnement géné- -ral du système d'exploitation linux. En fait, ce système se décompose en plusieurs partie: Le noyau, qui est le coeur princi- -pal, celui-ci va gérer les périphériques, les processus, etc... Mais aussi les lkms, ou modules, ceux-ci peuvent réaliser des tâ- -ches indépendantes (ou non) du noyau. Un module que vous connai- -ssez et que vous utiliser sûrement est l'interpréteur de comman- -des (shell), qui permet d'offrir l'interface utilisateur simple, puissante et conviviale que nous connaissons tous. Le problème (si cela en est un), c'est que les lkms peuvent tout faire. De ce fait, j'ai deux nouvelles à vous annoncer, une bonne et une mau- vaise... La bonne est que vous pouvez facilement lister et supprimer les modules présents sur votre système, et cela au moyen des comm- -andes "lsmod" et "rmmod". La mauvaise est que certains lkms détournent des syscall pour pouvoir se cacher sur le système, et même un lsmod ne vous permettra pas de voir qu'un vil lkm utilise vos syscall pour dissimuler une bien grosse backdoor root dans votre système de fichiers... [ Les systèmes de détection d'intrusion (IDS) ] Après avoir observé de plus de près la facilité qu'à un pirate à se cacher sur votre machine, on pourrait penser à établir un système qui nous permettrait de nous alerter en cas de tentative ou de compromission. C'est le rôle des IDS, ce sont des outils indispensables pour l'administrateur car ils permettent de sign- -aler une anormalité dans les données du système (dans ce cas on utilisera un HIDS, Host based Intrusion Detection System) ou dans le trafic de données, c'est à dire des paquets tran- -sitant d'une machine extérieure à la votre (on parlera alors de NIDS, Network based Intrusion Detection System, un des plus connus et des plus sophistiqués est snort, http://www.snort.org). D'un point de vue algorythmique, les IDS se basent sur trois grands types d'approches, comportementale, scénaristique, ou holistique. Dans le cas d'une approche comportementale, un pro- -fil est établi en fonction des habitudes de l'utilisateur, si il arrive un jour que ce profil soit "contesté", comprennez par là que le profil d'un autre utilisateur ne corresponde pas au profil défini, alors une alerte est immédiatement remontée. Ca peut poser problème, d'une part parce qu'une norme d'utilisation est longue et compliquée à mettre en place, et d'autre part parce que vous pourrez très bien effectuer des commandes jugées anorma- -les sans vous en rendre compte, ce qui fausserait le comporte- -ment de l'IDS. L'approche scénaristique, quant à elle, se base sur des scénarios (aussi apellés patterns). Dans ce cas précis l'IDS stocke une série de possibilitées dans une base de données, ainsi si une commande tapée dans un shell correspond a un de ces scénarios entreposés dans la base de données, il y'aura un message d'alerte. Là encore ce type d'approche présente des problèmes, car elle est (assez) facile à contourner. Par exemple, nous pourrons penser à utiliser une méthode de contournement par insertion en executant une commande en arrière plan (dans le cas d'un HIDS), ou à jouer avec des caractères ascii/unicode pour exploiter sans danger une faille de script kiddie sur un serveur web (dans le cas d'un NIDS). Enfin, plus récente, l'approche holistique, pas encore tout à fait au point, pourra consister dans un futur proche à prévoir l'objectif du pirate afin de déduire les attaques qui en décou- -lent, et ainsi instaurer un plan de défense efficace. Comme je l'ai mentionné plus haut, ce type d'approche n'est pas encore opérationelle et ne verra le jour que dans quelques années. On devra s'en tenir là pour le moment. Tout à l'heure je vous ais parlé d'un NIDS très utilisé, il s'agit de snort. Snort fonctionne sur l'approche scénaristique, c'est à dire qu'il analyse le trafic IP entrant et essaye de voir si les paquets échangés lors de ce trafic sont bien dans la régularité la plus élémentaire, si ils ne correspondent pas à un des exploits dis- -tants connus de snort, à un scan nmap, si ils ne sont pas err- -onés, etc... En général snort fait bien son travail et devr- -ait vous permettre de repérer aisément une tentative d'intr- -usion sur votre système. Et en sécurité réseau, un admini- -strateur averti en vaut quatre... Préférez la prévention à la guérison. [-EOF]