****************************************************
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 franais : #root sur irc.kewl.org
****************************************************

Know Your Enemy II: Traquer leurs mouvements

Cet article est le deuxime d'une srie de trois articles.  Dans le premier, Know Your Enemy,
nous avons parls des outils et des mthodes du Script Kiddie.  Particulirement, comment ils sondent  la recherches des vulnrabilits et puis passent  l'attaque. Le troisime 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 aprs. Cette article-ci, le deuxime, nous explique comment traquer leurs mouvements. Exactement comme les militaires, vous voulez traquer les mchants et savoir ce qu'ils font. Nous parlerons de ce que vous pourrez et ne pourrez apprendre pas avec vos logs systmes. Vous devez tre capable de voir que vous tes en train d'tres scann, de savoir pourquoi vous l'tes. Les exemples donns s'intresse  Linux mais peuvent s'appliquer  presque n'importe quelle autre dclinaison d'Unix. Gardez  l'esprit qu'il n'existe aucune mthode sure pour traquer tous les actes de votre ennemie. Cependant, cet article est un bon dbut.


Scuriser ses logs

Cet article ne porte pas sur la dtection d'intrusion (IDS), il existe dj beaucoup de trs bons
articles qui parlent de cela. Si vous tes intress par la dtection d'intrusion, je recommande de jeter un coup d'oeil  "Network Flight Recorder" ou snort. Cet article s'intresse aux recherches de l'intelligence. Particulirement, comment savoir ce que fait l'ennemi en passant en revue vos logs systme. Vous serez surpris de savoir toues les informations que vous trouverez dans vos propres logs systmes. Cependant, avant que nous puissions parler de passer en revue vos logs, nous devons d'abord parler de la manire de scuriser vos logs. Vos fichiers logs sont sans valeur si vous ne pouvez pas avoir confiance en leur intgrit. La premire chose que la plupart des hackers font sur un systme qui vient d'tre compromis est de modifier les fichiers log. Il existe plein de rootkits qui limineront leur prsence des fichiers logs (comme cloak) ou les modifient (comme l'excutable de syslog trojaned). Donc la premire chose  faire avant de passer en revue vos logs est de les scuriser.

Cela veut dire que vous devrez utiliser un serveur de log distant. Indpendamment de la faon de scuriser votre systme vous ne pouvez pas avoir confiance en vos logs dans un systme compromis. Si vous ne faites rien le hacker pourra simplement faire un rm - rf / * sur votre systme pour le formater compltement. Ceci rendra la rcupration des logs un peu difficile. Pour vous protger contre cela, vous aurez besoin que vos systmes log le trafic  la fois localement et sur un serveur distant. Je vous recommande de faire de votre log server un systme consacr, cd que la seule chose qu'il devrait faire serait de rassembler les logs des autres systmes. Si l'argent est un problme vous pouvez installer un ordinateur Linux qui agisse en tant que log server. Ce serveur devra tre hautement scuris, avec tous les services dsactivs, permettant seulement un accs  la console. (voir l'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 protge votre log server de la rception d'information mauvaise ou non autorise 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 diffrent 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'entre "/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 enlvera des soupons du hacker sur l'existence de notre log distant. Une autre possibilit pour votre systme est d'utiliser une mthode de log scurise. Une mthode est de remplacer votre excutable syslogd par quelque chose qui a un contrle d'intgrit 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 stocks sur le log server distant. Comme on l'a dit plus haut, nous pouvons tre assez confiants de l'intgrit de ces logs puisqu'ils sont sur un systme scuris et distant. En outre, puisque tous les systmes loggent depuis une source unique, on a ainsi une vue plus gnrale et donc plus claire. Nous pouvons rapidement passer en revue ce qui arrive  tous les systmes depuis une seule source. Le seul cas o vous voudriez passer en revue les logs stocks localement sur un systme serait pour les comparer avec les rsultats du log server. Vous pouvez dterminer si les logs locaux ont t modifis en les comparant aux logs distants.


Identification

En regardant les entres de vos logs, vous pouvez normalement voir si vous tes victimes d'un scanner de port. La plupart des Script Kiddies scannent un rseau pour une vulnrabilit donne.
Si vos logs montrent que la plupart de vos systmes ont des connexions du mme systme distant, sur le mme 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 vulnrabilit et fait des scans en esprant la retrouver chez vous. Quand ils la trouvent, ils l'exploitent. Pour la plupart des systmes Linux, TCP Wrappers est install par dfaut.  Ainsi, nous trouverions la plupart de ces connexions dans /var/log/secure. Pour les autres systmes Unix, nous pouvons logger toutes les connexions d'inetd en lanant inetd avec le flag "-f" ", dmon 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 vulnrabilit 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 rseau. Remarquez comme cette source
scanne squentiellement 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 choses dans votre rseau puisque toutes les logs sont centraliss. Les connexions rptss au port 21, ftp, ont indiqu qu'ils recherchaient particulirement la vulnrabilit de wu-ftpd. Nous avons juste dtermin 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 frapps par le ftp. Une excellente source pour les exploits rcents est http://www.cert.org/advisories/ Parfois, des outils scanneront pour plein d'exploits en mme 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 logges. Cependant, beaucoup de services peuvent simplement tre ajouts  /etc/inetd.conf pour le logging avec TCP Wrappers. Par exemple, vous pouvez ajouter une entre 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 dterminer les outils utiliss pour scanner votre rseau. Certains des outils les plus basiques scannent pour un certain exploit comme ftp-scan.c. Si un seul port ou une seule vulnrabilit est scanne par les hackers, c'est qu'ils utilisent probablement un de ces programmes "single mission". Mais il existe des outils qui scannent pour une varit de vulnrabilits ou de faiblesses, les deux outils trs populaires sont sscan de jsbach et nmap de Fyodor. J'ai choisi ces deux outils parce qu'ils reprsentent les deux catgories d'outils de scan. Je vous recommande fortement d'utiliser ces outils contre votre propre rseau, vous pourrez tres surpris des rsultats:)

	sscan reprsente l'outil de scan "qui fait tout"  des Script Kiddie et c'est probablement 	un des meilleurs qui existent. Il scanne rapidement un rseau pour une varit de 		vulnrabilit (dont les cgi-bin). Il est facilement configurable, vous permettant 		d'ajouter des scans pour de nouveaux exploits.  Vous donner simplement au programme un 		rseau et un masque de rseau, et lui fait tout le reste pour vous.  Cependant, 		l'utilisateur doit tre root pour l'utiliser. Les rsultats sont extrmement faciles  		interprter (c'est pourquoi il est si populaire): il donne un rsum concis de beaucoup 	de services vulnrables. Tout que vous avez  faire est de lancer sscan contre un rseau 	et chercher le mot "VULN" dans la sortie et puis lancer l'"exploit du jour" (NdT: en 		franais dans le texte). Ci-dessous un exemple de sscan contre le systme 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) ]> 
          --<[ *OS*: mozart: os detected: redhat linux 5.1 
          mozart: VULN: linux box vulnerable to named overflow. 
          -<[ *CGI*: 172.17.6.30: tried to redirect a /cgi-bin/phf request. 
          -<[ *FINGER*: mozart: root: account exists. 
          --<[ *VULN*: mozart: sendmail will 'expn' accounts for us 
          --<[ *VULN*: mozart: linux bind/iquery remote buffer overflow 
          --<[ *VULN*: mozart: linux mountd remote buffer overflow 
          ---------------------------<[ * scan of mozart completed *

	Nmap est un programme de "donnes brutes": il ne vous dit pas quelles vulnrabilits 		existent, il vous dit plutt quels ports sont ouverts, vous en dterminez les 			consquences. Nmap est rapidement devenu le scanner de ports de choix, et pour cause. Il 	prend le meilleur de plusieurs scanners de port et met toutes ces fonctionnalits dans un 	seul outil, dont la dtection de l'OS, plusieurs options d'assemblage de paquet, le scan 	 la fois de UDP et de TCP, randomization, etc. Cependant, vous avez besoin des 		qualifications de gestion de rseau pour utiliser ce programme et pour interprter les 		donnes. Ci-dessous, un exemple de nmap lanc contre le mme systme.

	  otto #nmap -sS -O 172.17.6.30 

          Starting nmap V. 2.08 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/) 
          Interesting ports on mozart (172.17.6.30): 
          Port    State       Protocol  Service 
          21      open        tcp        ftp 
          23      open        tcp        telnet 
          25      open        tcp        smtp 
          37      open        tcp        time 
          53      open        tcp        domain 
          70      open        tcp        gopher 
          79      open        tcp        finger 
          80      open        tcp        http 
          109     open        tcp        pop-2 
          110     open        tcp        pop-3 
          111     open        tcp        sunrpc 
          143     open        tcp        imap2 
          513     open        tcp        login 
          514     open        tcp        shell 
          635     open        tcp        unknown 
          2049    open        tcp        nfs 

          TCP Sequence Prediction: Class=truly random 
                                   Difficulty=9999999 (Good luck!) 
          Remote operating system guess: Linux 2.0.35-36 

          Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds

En passant en revue vos logs, vous pouvez dterminer lequels de ces outils ont t utiliss  contre vous. Pour faire cela, vous devez comprendre comment ces programmes fonctionnent. D'abord, un scan de sscan sera logg comme suit (c'est un scan normal avec aucune modification d'aucun fichier de configuration):

/var/log/secure 
Apr 14 19:18:56 mozart in.telnetd[11634]: connect from 192.168.11.200 
Apr 14 19:18:56 mozart imapd[11635]: connect from 192.168.11.200 
Apr 14 19:18:56 mozart in.fingerd[11637]: connect from 192.168.11.200 
Apr 14 19:18:56 mozart ipop3d[11638]: connect from 192.168.11.200 
Apr 14 19:18:56 mozart in.telnetd[11639]: connect from 192.168.11.200 
Apr 14 19:18:56 mozart in.ftpd[11640]: connect from 192.168.11.200 
Apr 14 19:19:03 mozart ipop3d[11642]: connect from 192.168.11.200 
Apr 14 19:19:03 mozart imapd[11643]: connect from 192.168.11.200 
Apr 14 19:19:04 mozart in.fingerd[11646]: connect from 192.168.11.200 
Apr 14 19:19:05 mozart in.fingerd[11648]: connect from 192.168.11.200 

/var/log/maillog 
Apr 14 21:01:58 mozart imapd[11667]: command stream end of file, while reading line user=???
host=[192.168.11.200] 
Apr 14 21:01:58 mozart ipop3d[11668]: No such file or directory while reading line user=???
host=[192.168.11.200] 
Apr 14 21:02:05 mozart sendmail[11675]: NOQUEUE: [192.168.11.200]: expn root 

/var/log/messages 
Apr 14 21:03:09 mozart telnetd[11682]: ttloop:  peer died: Invalid or incomplete multibyte or
wide character 
Apr 14 21:03:12 mozart ftpd[11688]: FTP session closed 

sscan fait aussi des scans  la recherche des bugs cgi-bin. Ces scans ne seront pas loggs par syslogd, vous les trouverez dans access_log. J'ai dcids de les inclure quand mme pour votre apprentissage:)

/var/log/httpd/access_log 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/phf HTTP/1.0" 302 192 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/Count.cgi HTTP/1.0" 404 170 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/test-cgi HTTP/1.0" 404 169 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/php.cgi HTTP/1.0" 404 168 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/handler HTTP/1.0" 404 168 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/webgais HTTP/1.0" 404 168 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/websendmail HTTP/1.0" 404 172 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/webdist.cgi HTTP/1.0" 404 172 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/faxsurvey HTTP/1.0" 404 170 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/htmlscript HTTP/1.0" 404 171 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/pfdisplay.cgi HTTP/1.0" 404 174 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/perl.exe HTTP/1.0" 404 169 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/wwwboard.pl HTTP/1.0" 404 172 
192.168.11.200 - - [14/Apr/1999:16:44:50 -0500] "GET /cgi-bin/ews/ews/architext_query.pl
HTTP/1.0" 404 187 
192.168.11.200 - - [14/Apr/1999:16:44:50 -0500] "GET /cgi-bin/jj HTTP/1.0" 404 163 

Notez comme la connexion a t faite en entier (SYN, SYN-ACK, ACK) pour tous les ports, puis ferme. C'est parce sscan veut dterminer ce qui se passe sur les services. Non seulement sscan veut savoir si votre port ftp est ouvert, mais aussi QUEL daemon ftp est actif. La mme chose
peut tre dite pour les ports imap, pop, etc.  Cela se remarque dans les traces de sniffing avec sniffit, un programme souvent utilis pour sniffer des mots de passe.

mozart $ cat 172.17.6.30.21-192.168.11.200.7238 
220 mozart.example.net FTP server (Version wu-2.4.2-academ[BETA-17](1) Tue Jun 9 10:43:14 EDT
1998) ready. 

Comme on l'a vue plus haut une connexion complte a t faite pour dterminer quelle version de wu-ftpd tait excute. Quand vous voyez des connexions compltes dans vos logs c'est que vous avez certainement t scann par un programme d'exploit. Ces programmes font des connexions compltes pour dterminer ce que vous tes en train d'excuter.

Nmap comme la plupart des scanners de port, s'en fout de savoir CE QUE vous excuter,  mais veut savoir SI vous excuter des services particuliers. Pour cela, nmap a un puissant ensemble d'options, vous laissant dterminer quelle sorte de connexion ouvrir, dont SYN, FIN, Xmas, Null, etc. Pour une description dtaille de ces options, jetez un coup d'oeil  http://www.insecure.org/nmap/nmap_doc.html. En raison de ces options, vos logs seront diffrents suivant les options choisies par l'utilisateur  distance. Une connexion faite avec le flag -sT est une connexion complte donc les logs seront similaires  sscan, toutefois par dfaut nmap
scan plus de ports.

/var/log/secure 
Apr 14 21:20:50 mozart in.rlogind[11706]: connect from 192.168.11.200 
Apr 14 21:20:51 mozart in.fingerd[11708]: connect from 192.168.11.200 
Apr 14 21:20:51 mozart ipop2d[11709]: connect from 192.168.11.200 
Apr 14 21:20:51 mozart in.rshd[11710]: connect from 192.168.11.200 
Apr 14 21:20:51 mozart gn[11711]: connect from 192.168.11.200 
Apr 14 21:20:51 mozart gn[11711]: error: cannot execute /usr/sbin/gn: No such file or directory

Apr 14 21:20:52 mozart in.timed[11712]: connect from 192.168.11.200 
Apr 14 21:20:52 mozart imapd[11713]: connect from 192.168.11.200 
Apr 14 21:20:52 mozart ipop3d[11714]: connect from 192.168.11.200 
Apr 14 21:20:52 mozart in.telnetd[11715]: connect from 192.168.11.200 
Apr 14 21:20:52 mozart in.ftpd[11716]: connect from 192.168.11.200 
 
Une chose  retenir est l'option -D (ou decoy). Cette option de nmap permet  l'utilisateur de spoofer son adresse source. Il est possible que vous voyez des scans  de 15 sources diffrentes en mme temps, mais que seulement une d'entre elles est la vraie. Il est extrmement difficile de dterminer laquelle des 15 tait la vraie adresse source. Mais le plus souvent, les utilisateurs choisiront le flag -sS pour le scannage. C'est une option de scan de port furtif car seulement un paquet SYN est envoy.  Si le systme disant rpond, la connexion est immdiatement stoppe avec un RST. Les logs de ce genre de scans ont l'apparence de ce qui est retranscrit plus bas (NOTE: seulement les cinq premires entres ont t notes ici).

/var/log/secure 
Apr 14 21:25:08 mozart in.rshd[11717]: warning: can't get client address: Connection reset by
peer 
Apr 14 21:25:08 mozart in.rshd[11717]: connect from unknown 
Apr 14 21:25:09 mozart in.timed[11718]: warning: can't get client address: Connection reset by
peer 
Apr 14 21:25:09 mozart in.timed[11718]: connect from unknown 
Apr 14 21:25:09 mozart imapd[11719]: warning: can't get client address: Connection reset by
peer 
Apr 14 21:25:09 mozart imapd[11719]: connect from unknown 
Apr 14 21:25:09 mozart ipop3d[11720]: warning: can't get client address: Connection reset by
peer 
Apr 14 21:25:09 mozart ipop3d[11720]: connect from unknown 
Apr 14 21:25:09 mozart in.rlogind[11722]: warning: can't get client address: Connection reset
by peer 
Apr 14 21:25:09 mozart in.rlogind[11722]: connect from unknown 

Remarquez toutes les erreurs dans les connexions. Puisque la squence SYN-ACK est stoppe avant qu'une connexion complte puisse tre tablie, le dmon ne peut pas dterminer le systme source. 
Les logs montrent que vous avez t scanns mais malheureusement vous ne savez pas par qui. Ce qui est bien plus alarmant, c'est que sur la plupart des autres systmes (y compris les nouveaux noyaux Linux) aucune de ces erreurs n'aurait t logge. Pour citer Fyodor "...bas sur tous les messages 'connection reset by peer'". C'est une singularit de Linux 2.0.XX -- pratiquement tous les autres systme (dont le noyau 2.2 et les plus rcent noyaux 2.1) ne montreront rien. Ce bug (accept() qui retourne une valeur avant l'accomplissement de la connexion en 3 temps (NdT: la fameuse 3-way handshake) a t rpar.

Nmap inclut d'autres options furtives, comme -sF, -sX, -sN o diffrents flags sont utiliss.
Ceci est ce  quoi ressemblent les logs pour de tels scans:

/var/log/secure 

Remaquez ici qu'il n'y a aucun logs! Hum effrayant, vous venez d'tre scann et ne pouvez mme pas le savoir. Chacun des trois types de scans donne les mmes rsultats, toutefois vous pouvez loggez entirement le scan seulement du premier type, -sT (connexion complte). Pour dtecter ces scans furtifs vous devrez utiliser un autre programme de log comme tcplogd ou ippl. Certains firewalls commerciaux dtecteront aussi et loggeront tous ces scans (J'ai confirm cela dans
"Checkpoint Firewall 1") 


Ont-ils eu l'accs?

Une fois que vous avez remarqu avoir t scann et dterminer ce qu'ils recherchaient, la grande question qui suit est "Sont ils entrs?". La plupart d'exploits  distance d'aujourd'hui sont
bases sur des buffer overflow (aussi connu sous crasement de pile). En gros un buffer overflow
arrive quand un programme (souvent un daemon) reoit plus d'entres qu'il ne l'avait prvu, de ce fait recouvrant des zones critiques de la mmoire. Un certain code est alors excut, qui normalement donne le statut root  l'utilisateur. Pour plus d'information sur les buffers overflows, lisez l'excellent article de Aleph1  ftp://ftp.technotronic.com/rfc/phrack49-14.txt. 

Vous pouvez normalement identifier des attaques par buffer overflows dans le fichier log 
/var/log/messages (ou /var/adm/messages pour d'autres systmes Unix) pour des attaques comme mountd. Vous verrez galement des logs similaires dans maillog pour de telles attaques contre
imapd. Une attaque par buffer overflow ressemblerait  ceci:

Apr 14 04:20:51 mozart mountd[6688]: Unauthorized access by NFS client 192.168.11.200. 
Apr 14 04:20:51 mozart syslogd: Cannot glue message parts together 
Apr 14 04:20:51 mozart mountd[6688]: Blocked attempt of 192.168.11.200 to mount 
~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ 
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ 
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ 
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ 
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ 
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ 
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ 
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ 
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ 
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ 
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ 
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ 
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ 
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ 
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ 
P~P~P33^[~@33~Kڰ^F~@u1^B~@~Eubb^V<t^Ft^K0~HF^^B~ 
I^F~IF^D^F~IF^Hf1~I~@~I^F^Bf~IF^L*f~IF^N~MF^L~IF^D1~IF^P^P~IF^H 
f~@^A~IF^Df^D~@^DLR1~IF^D~IF^Hf~@~Hð?1~@?~@?~@.bin@~ 
I^F.sh!@~IF^D1~HF^G~Iv^H~IF^L^K~I~MN^H~MV^L~@1^A1~@EPrivet 
ADMcrew~P(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(Apr 14 04:20:51 
mozart ^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^ 
E^H(-^E^H-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E 
^H(-^E^H-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^ H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E 
^H(-^E^H(-^E 

Si vous voyez quelque chose de la sorte dans vos fichiers logs, cela veut dire que quelqu'un a essay d'excuter un exploiter sur votre systme. Il est difficile de dterminer si l'excution de l'exploit a t courone de succs.  Une faon de savoir aprs la tentative d'exploit est de regarder s'il y a des connexions d'une source distante sur votre systme. S'ils se sont loggs sans problme depuis le systme distant, alors ils ont accs  votre systme. Un autre indice est 
de regarder s'il  y a des comptes "moof", "rewt", "crak0", ou "w0rm" qui ont t ajouts  votre fichier mot de passe /etc/passwd. Ces comptes, d'uid 0, sont ajouts par certains des scripts d'exploits les plus connus. Une fois qu'un hacker obtient un accs, normalement la premire chose qu'ils font est de nettoyer vos logs et de trojaner votre programme de log (syslogd), pour plus d'information allez voir Know Your Enemy III.  partir de ce moment, vous ne recevrez aucun log de votre systme vu que tout a t compromis. Ce que vous pouvez faire aprs est le sujet d'un autre article :). En attendant je vous recommande de lire: http://www.cert.org/nav/recovering.html

Pour m'aider  trouver des anomalies dans mes fichiers logs, j'ai dvelopp un shell script qui scan mes logs pour moi. Pour des information plus dtailles sur comment analyser des fichiers logs, lisez ceci envoy par Marcus Ranum (Bourne shell script ou Korn shell script)
 

Conclusion

Vos fichiers logs peuvent vous dire beaucoup au sujet de l'ennemi. Mais la premire chose  faire est de garantir l'intgrit de vos fichiers logs. Un des meilleurs moyens de faire cela est d'utiliser un serveur de log distant qui reoit et stocke le logs des autres systmes. Une fois scuris vous pourrez identifier les anomalies dans vos fichiers logs. En se basant sur les entres des logs vous pouvez dterminer ce que le hacker recherche et potentiellement quels outils ils utilisent. Avec cette connaissance vous pourrez mieux scuriser et protger votre rseau.