**************************************************** Cet article a été traduit de l'anglais par OUAH (OUAH_@hotmail.com), http://www.multimania.com/ouah. La version originale est de Lance Spitzner (lspitz@ksni.net) et peut-être obtenue à http://www.enteract.net/~lsiptz. Pour tout commentaire, venez sur le channel de hacking français : #root sur irc.kewl.org **************************************************** Know Your Enemy II: Traquer leurs mouvements Cet article est le deuxième d'une série de trois articles. Dans le premier, Know Your Enemy, nous avons parlés des outils et des méthodes du Script Kiddie. Particulièrement, comment ils sondent à la recherches des vulnérabilités et puis passent à l'attaque. Le troisième article parle de ce que font les script kiddies une fois le statut root obtenu. En particulier comment ils dissimulent leurs traces et ce qu'ils font après. Cette article-ci, le deuxième, nous explique comment traquer leurs mouvements. Exactement comme les militaires, vous voulez traquer les méchants et savoir ce qu'ils font. Nous parlerons de ce que vous pourrez et ne pourrez pas apprendre avec vos logs systèmes. Vous devez être capable de voir que vous êtes en train d'êtres scanné, de savoir pourquoi vous l'êtes. Les exemples donnés s'intéresse à Linux mais peuvent s'appliquer à presque n'importe quelle autre déclinaison d'Unix. Gardez à l'esprit qu'il n'existe aucune méthode sure pour traquer tous les actes de votre ennemi. Cependant, cet article est un bon début. Sécuriser ses logs Cet article ne porte pas sur la détection d'intrusion (IDS), il existe déjà beaucoup de très bons articles qui parlent de cela. Si vous êtes intéressé par la détection d'intrusion, je recommande de jeter un coup d'oeil à "Network Flight Recorder" ou snort. Cet article s'intéresse aux recherches de l'intelligence. Particulièrement, comment savoir ce que fait l'ennemi en passant en revue vos logs système. Vous serez surpris de savoir toutes les informations que vous trouverez dans vos propres logs systèmes. Cependant, avant que nous puissions parler de passer en revue vos logs, nous devons d'abord parler de la manière de sécuriser vos logs. Vos fichiers logs sont sans valeur si vous ne pouvez pas avoir confiance en leur intégrité. La première chose que la plupart des hackers font sur un système qui vient d'être compromis est de modifier les fichiers log. Il existe plein de rootkits qui élimineront leur présence des fichiers logs (comme cloak) ou les modifient (comme l'exécutable de syslog trojaned). Donc la première chose à faire avant de passer en revue vos logs est de les sécuriser. Cela veut dire que vous devrez utiliser un serveur de log distant. Indépendamment de la façon de sécuriser votre système vous ne pouvez pas avoir confiance en vos logs dans un système compromis. Si vous ne faites rien le hacker pourra simplement faire un rm - rf / * sur votre système pour le formater complètement. Ceci rendra la récupération des logs un peu difficile. Pour vous protéger contre cela, vous aurez besoin que vos systèmes log le trafic à la fois localement et sur un serveur distant. Je vous recommande de faire de votre log server un système consacré, càd que la seule chose qu'il devrait faire serait de rassembler les logs des autres systèmes. Si l'argent est un problème vous pouvez installer un ordinateur Linux qui agisse en tant que log server. Ce serveur devra être hautement sécurisé, avec tous les services désactivés, permettant seulement un accès à la console. (voir mon article Armoring Linux pour un exemple). En outre, assurez-vous que le port UDP 514 soit bloqué ou filtré par un firewall de votre connexion au net. Ceci protège votre log server de la réception d'information mauvaise ou non autorisée de l'Internet. Pour ceux parmi vous qui aiment être plus malin, quelque chose que moi j'aime bien faire, c'est de recompiler syslogd pour qu'il lise un fichier de configuration différent comme /var/tmp/.conf. Ainsi le hacker ne se rendra pas compte de où se trouve le vrai fichier de configuration. Cela se fait simplement en changeant l'entrée "/etc/syslog.conf" dans le code source par le fichier que vous voulez. Nous configurons alors notre nouveau fichier de configuration pour logger à la fois localement et sur le log server (voir l'exemple). Assurez vous de garder une copie standard de /etc/syslog.conf qui log l'activité locale. Quoique ce fichier de configuration soit maintenant inutile, ceci enlèvera des soupçons du hacker sur l'existence de notre log distant. Une autre possibilité pour votre système est d'utiliser une méthode de log sécurisée. Une méthode est de remplacer votre exécutable syslogd par quelque chose qui a un contrôle d'intégrité et une plus grande palette d'options. Syslog-ng est une possibilité et vous pouvez le trouver à http://www.balabit.hu/products/syslog-ng.html La plupart des logs que nous utiliserons sont ceux qui sont stockés sur le log server distant. Comme on l'a dit plus haut, nous pouvons être assez confiants de l'intégrité de ces logs puisqu'ils sont sur un système sécurisé et distant. En outre, puisque tous les systèmes loggent depuis une source unique, on a ainsi une vue plus générale et donc plus claire. Nous pouvons rapidement passer en revue ce qui arrive à tous les systèmes depuis une seule source. Le seul cas où vous voudriez passer en revue les logs stockés localement sur un système serait pour les comparer avec les résultats du log server. Vous pouvez déterminer si les logs locaux ont été modifiés en les comparant aux logs distants. Identification En regardant les entrées de vos logs, vous pouvez normalement voir si vous êtes victimes d'un scanner de port. La plupart des Script Kiddies scannent un réseau pour une vulnérabilité donnée. Si vos logs montrent que la plupart de vos systèmes ont des connexions du même système distant, sur le même port, il y a beaucoup de chance que ce soit un scan pour un exploit. En fait l'ennemi a un exploit pour une certaine vulnérabilité et fait des scans en espérant la retrouver chez vous. Quand ils la trouvent, ils l'exploitent. Pour la plupart des systèmes Linux, TCP Wrappers est installé par défaut. Ainsi, nous trouverions la plupart de ces connexions dans /var/log/secure. Pour les autres systèmes Unix, nous pouvons logger toutes les connexions d'inetd en lançant inetd avec le flag "-f" ", démon de service. Un scan à la recherche d'exploit typique ressemblerait à ce qu'il y a ci-dessous. Ici nous avons un scannage source pour la vulnérabilité de wu-ftpd. /var/log/secure Apr 10 13:43:48 mozart in.ftpd[6613]: connect from 192.168.11.200 Apr 10 13:43:51 bach in.ftpd[6613]: connect from 192.168.11.200 Apr 10 13:43:54 hadyen in.ftpd[6613]: connect from 192.168.11.200 Apr 10 13:43:57 vivaldi in.ftpd[6613]: connect from 192.168.11.200 Apr 10 13:43:58 brahms in.ftpd[6613]: connect from 192.168.11.200 Ici nous voyons la source 192.168.11.200 scanner notre réseau. Remarquez comme cette source scanne séquentiellement chaque IP (cela n'est pas toujours le cas). C'est l'avantage d'avoir un serveur de log, vous pouvez plus facilement identifier des anomalies dans votre réseau puisque toutes les logs sont centralisés. Les connexions répétéss au port 21, ftp, ont indiqué qu'ils recherchaient particulièrement la vulnérabilité de wu-ftpd. Nous avons juste déterminé ce que le hacker recherchait. Souvent, les scans s'effectuent par phases. Quelqu'un publie le code pour un exploit sur imap et vous verrez soudainement un assaut de scan sur imap dans vos log. Le mois suivant vous serez frappés par le ftp. Une excellente source pour les exploits récents est http://www.cert.org/advisories/ Parfois, des outils scanneront pour plein d'exploits en même temps, ainsi vous verrez une source unique se connecter à plusieurs ports. Gardez à l'esprit que si vous ne loggez pas les connexions d'un service, vous ne saurez pas si vous êtes scanné pour celui-ci. Par exemple, la plupart des connexions rpc ne sont pas loggées. Cependant, beaucoup de services peuvent simplement être ajoutés à /etc/inetd.conf pour le logging avec TCP Wrappers. Par exemple, vous pouvez ajouter une entrée dans /etc/inetd.conf pour NetBus. Vous pouvez configurer TCP Wrapper pour simplement refuser le service et logger les connexions (voir "Intrusion Detection" pour plus d'information sur ce sujet). Quels ont les outils? Parfois vous pouvez vraiment déterminer les outils utilisés pour scanner votre réseau. Certains des outils les plus basiques scannent pour un certain exploit comme ftp-scan.c. Si un seul port ou une seule vulnérabilité est scannée par les hackers, c'est qu'ils utilisent probablement un de ces programmes "single mission". Mais il existe des outils qui scannent pour une variété de vulnérabilités ou de faiblesses, les deux outils très populaires sont sscan de jsbach et nmap de Fyodor. J'ai choisi ces deux outils parce qu'ils représentent les deux catégories d'outils de scan. Je vous recommande fortement d'utiliser ces outils contre votre propre réseau, vous pourrez êtres surpris des résultats:) sscan représente l'outil de scan "qui fait tout" des Script Kiddie et c'est probablement un des meilleurs qui existent. Il scanne rapidement un réseau pour une variété de vulnérabilité (dont les cgi-bin). Il est facilement configurable, vous permettant d'ajouter des scans pour de nouveaux exploits. Vous donner simplement au programme un réseau et un masque de réseau, et lui fait tout le reste pour vous. Cependant, l'utilisateur doit être root pour l'utiliser. Les résultats sont extrêmement faciles à interpréter (c'est pourquoi il est si populaire): il donne un résumé concis de beaucoup de services vulnérables. Tout que vous avez à faire est de lancer sscan contre un réseau et chercher le mot "VULN" dans la sortie et puis lancer l'"exploit du jour" (NdT: en français dans le texte). Ci-dessous un exemple de sscan contre le système mozart (172.17.6.30). otto #./sscan -o 172.17.6.30 --------------------------<[ * report for host mozart * <[ tcp port: 80 (http) ]> <[ tcp port: 23 (telnet) ]> <[ tcp port: 143 (imap) ]> <[ tcp port: 110 (pop-3) ]> <[ tcp port: 111 (sunrpc) ]> <[ tcp port: 79 (finger) ]> <[ tcp port: 53 (domain) ]> <[ tcp port: 25 (smtp) ]> <[ tcp port: 21 (ftp) ]> --