Scan of the Month 23 - Analyse par Christophe GRENIER

Introduction

Depuis plus de deux ans, le projet Honeynet propose régulièrement d'étudier des outils, des tactiques utilisés par des pirates lors d'intrusion pour démontrer la réalité de ces attaques, pour apprendre comment un pirate agit pour s'en protéger et plus généralement pour améliorer les technologies et méthodes de collecte d'information. Chaque mois, le Scan of the Month challenge propose l'analyse de trames réseaux suspectes. Cet article est inspiré du Scan of the Month du mois de septembre Scan23. Il s'agit du premier challenge destiné aux débutants. Son but est d'analyser les captures réseaux produits par un scan de port afin de répondre aux questions suivantes

Qu'est-ce qu'un fichier de log ?
Qu'est-ce qu'une signature MD5 ?
Qu'est-ce qu'un scan de port ? Quelles techniques ont été utilisées ?
Quels sont les ports ouverts ?
Quel outil a été utilisé pour scanner ?
Quel est le système d'exploitation du hacker?

Les données à analyser

Pour collecter les paquets circulant sur un réseau, un sniffer est utilisé. La programmation de ces utilitaires de capture a été présentée dans un article de LinuxMag de septembre. Parmi les différentes méthodes, l'une d'entre elles est multiplateforme, il s'agit d'utiliser les fonctions de la librairie libpcap. Pcap est utilisé par des sniffers comme tcpdump, ethereal mais aussi des sondes de détection d'intrusion comme snort ou prelude. Ils ont tous la possibilité d'enregistré les événements réseaux dans un fichier de capture binaire.

Le fichier de capture de septembre est disponible à l'adresse http://old.honeynet.org/scans/scan23/. Afin de garantir l'intégrité de ce fichier, une signature éléctronique de ce fichier est aussi disponible sur le site. Cette signature a été effectuée avec l'algorithme MD5, Message Digest de la société RSA Data Security. Il ne reste plus qu'à comparer cette signature de référence à la signature que l'on calcule à partir du fichier récupéré avec la commande md5sum.

[kmaster@christophe sotm23]$ md5sum sotm23.tar.gz
9d28c5ee9ce7b77e3099a07ad303811f  sotm23.tar.gz

Attention, la somme MD5 garantie uniquement contre les corruptions accidentelles (par exemple, fichier tronqué). Si le serveur est piraté, l'archive peut être modifiée et le pirate n'a plus qu'à remplacer l'empreinte MD5 par la nouvelle valeur.

Snort

Un scan de port permet d'identifier les ports TCP ou UDP sur lesquelles une application réseau est à l'écoute. Un pirate utilise généralement un scanner de port dans la phase d'approche lorsqu'il prépare son attaque. C'est pourquoi les NIDS, sondes de détections d'intrusion réseau (cf dossier IDS: Détection d'intrusion de MISC 3), sont capables de les détecter. Soumettons la capture réseau au logiciel Snort http://www.snort.org, sans doute le NIDS le plus populaire, de plus sous licence GNU.

Configuration

Snort est configuré via son fichier /etc/snort.conf de la façon suivante:

var HOME_NET any
var EXTERNAL_NET any
var SMTP $HOME_NET
var HTTP_SERVERS $HOME_NET
var SQL_SERVERS $HOME_NET
var DNS_SERVERS $HOME_NET
var RULE_PATH /etc/snort
var SHELLCODE_PORTS !80
var HTTP_PORTS 80
var ORACLE_PORTS 1521
preprocessor frag2 
preprocessor stream4: detect_scans, detect_state_problems
preprocessor stream4_reassemble: both, ports all
preprocessor http_decode: 80 -unicode -cginull 
preprocessor rpc_decode: 111 32771
preprocessor bo
preprocessor telnet_decode 
preprocessor portscan: $HOME_NET 4 3 portscan.log 
output alert_syslog: LOG_AUTH LOG_ALERT
output alert_unified: filename snort.alert, limit 128
include classification.config

et la totalité des règles est active

include $RULE_PATH/bad-traffic.rules
...
include $RULE_PATH/info.rules
include $RULE_PATH/icmp-info.rules
include $RULE_PATH/virus.rules
include $RULE_PATH/local.rules

Dans cette configuration, le préprocesseur portscan va être utile pour détecter les scans TCP SYN et les scans UDP, l'option detect_scans du préprocesseur stream4 active l'identification des scans furtifs.

Utilisation

Demandons à Snort d'analyser le fichier de log et d'afficher sur la console les alertes. snort -A console -llog -r 0826\@19-snort.log -c /etc/snort.conf

-*> Snort! <*-
Version 1.8.7 (Build 128)
By Martin Roesch (roesch@sourcefire.com, www.snort.org)
1603 Snort rules read...
1603 Option Chains linked into 176 Chain Headers
0 Dynamic rules
+++++++++++++++++++++++++++++++++++++++++++++++++++

Rule application order: ->activation->dynamic->alert->pass->log
08/27-01:59:50.250759  [**] [1:469:1] ICMP PING NMAP [**] [Classification: Attempted Information Leak] [Priority: 2] {ICMP} 192.168.0.9 -> 192.168.0.99
08/27-01:59:50.250837  [**] [1:408:4] ICMP Echo Reply [**] [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.0.99 -> 192.168.0.9
09/14-15:40:03.499462  [**] [100:1:1] spp_portscan: PORTSCAN DETECTED from 192.168.0.9 (THRESHOLD 4 connections exceeded in 0 seconds) [**]
09/14-15:40:03.506090  [**] [100:2:1] spp_portscan: portscan status from 192.168.0.9: 170 connections across 1 hosts: TCP(170), UDP(0) [**]
...
09/14-16:39:52.690139  [**] [100:2:1] spp_portscan: portscan status from 192.168.0.9: 162 connections across 1 hosts: TCP(162), UDP(0) [**]

Demblé, les alertes nous apprennent que

le serveur 192.168.0.99 est scanné par la machine 192.168.0.9
la technique de scan est TCP SYN.
le scan est précédé d'un ping ICMP afin de vérifier si le serveur est opérationnel. Ce paquet ICMP est propre au logiciel de scan Nmap. Le scanner de port sous licence GPL Nmap,http://www.insecure.org/nmap, existe aussi bien sous Unix que sous Windows, il est l'un (le) des plus complet.

Attention, les alertes de spp_portscan utilisent la date actuelle!

Signature des scans de port

Ping sweep

Observons avec la commande tcpdump, les premiers paquets de la capture réseau. tcpdump, http://www.tcpdump.org, est le sniffer le plus répandu sous Unix. Il fonctionne en mode texte et est extrêmement rapide.

[kmaster@christophe sotm23]$ tcpdump -r 0826\@19-snort.log -n
01:59:50.250759 192.168.0.9 > 192.168.0.99: icmp: echo request
01:59:50.250837 192.168.0.99 > 192.168.0.9: icmp: echo reply
01:59:50.250803 192.168.0.9.52218 > 192.168.0.99.http: . ack 4094787819 win 2048
01:59:50.250878 192.168.0.99.http > 192.168.0.9.52218: R 4094787819:4094787819(0) win 0 (DF)

On peut réaliser la même chose avec tethereal, le sniffer en mode texte de ethereal: tethereal -r 0826\@19-snort.log -n
ethereal, http://www.ethereal.com, est un sniffer disponible aussi bien sous Unix que sous Windows, comme tcpdump d'ailleurs, qui a l'avantage de proposer une interface graphique permettant d'analyser les paquets sur plusieurs niveaux et connaissant de nombreux protocoles.

Remarque, tcpdump est bien plus rapide que ethereal car il applique un filtre de capture avec pcap. Tandis que ethereal "capture" la totalité des données puis applique un filtre de lecture ou d'affichage.

Nmap utilise deux méthodes pour vérifier que le serveur 192.168.0.99 est disponible: un ping ICMP et un ping TCP ACK sur le port 80 (http) par défaut. Recherchons les paquets ICMP echo-request, c'est à dire les paquets ICMP de type 8 et les paquets TCP avec le flag ACK, autrement dit flags=0x10.

[kmaster@christophe sotm23]$ tcpdump -r 0826\@19-snort.log -n "src ! 192.168.0.99 and (icmp[0]=8 or tcp[13]=0x10)"

01:59:50.250759 192.168.0.9 > 192.168.0.99: icmp: echo request
01:59:50.250803 192.168.0.9.52218 > 192.168.0.99.http: . ack 4094787819 win 2048

02:21:04.853059 192.168.0.9 > 192.168.0.99: icmp: echo request
02:21:04.853103 192.168.0.9.42314 > 192.168.0.99.http: . ack 2866936176 win 4096

02:21:38.723091 192.168.0.9.42304 > 192.168.0.99.ssh: . ack 0 win 4096 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol>
02:21:38.723304 192.168.0.9.42306 > 192.168.0.99.tcpmux: . ack 0 win 4096 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol>

02:23:17.506855 192.168.0.9 > 192.168.0.99: icmp: echo request
02:23:17.506900 192.168.0.9.58183 > 192.168.0.99.http: . ack 3623169759 win 1024

02:23:51.679297 192.168.0.9.58173 > 192.168.0.99.ssh: . ack 0 win 1024 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol>
02:23:51.679512 192.168.0.9.58175 > 192.168.0.99.tcpmux: . ack 0 win 1024 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol>

02:24:39.805309 192.168.0.9.40551 > 192.168.0.99.http: . ack 1401847552 win 1024

02:24:50.337389 192.168.0.9.34203 > 192.168.0.99.sunrpc: . ack 1288214714 win 5840 <nop,nop,timestamp 16917393 14921528> (DF)
02:24:51.037263 192.168.0.9.34398 > 192.168.0.99.http: . ack 1296081605 win 5840 <nop,nop,timestamp 16917463 14921598> (DF)
02:24:51.117254 192.168.0.9.34399 > 192.168.0.99.https: . ack 1296564949 win 5840 <nop,nop,timestamp 16917471 14921606> (DF)
02:24:52.417675 192.168.0.9.34800 > 192.168.0.99.ssh: . ack 1296230717 win 5840 <nop,nop,timestamp 16917601 14921736> (DF)
02:24:53.597612 192.168.0.9.35169 > 192.168.0.99.domain: . ack 1298205505 win 5840 <nop,nop,timestamp 16917719 14921854> (DF)
02:24:54.378018 192.168.0.9.40541 > 192.168.0.99.ssh: . ack 0 win 1024 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol>
02:24:54.378205 192.168.0.9.40543 > 192.168.0.99.tcpmux: . ack 0 win 1024 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol>

02:26:32.335638 192.168.0.1 > 192.168.0.99: icmp: echo request
02:26:32.335671 192.168.0.254 > 192.168.0.99: icmp: echo request
02:26:32.335700 192.168.0.199 > 192.168.0.99: icmp: echo request
02:26:32.335735 192.168.0.199 > 192.168.0.99: icmp: echo request
02:26:32.335785 192.168.0.1.35984 > 192.168.0.99.http: . ack 3438589941 win 3072
02:26:32.335790 192.168.0.254.35984 > 192.168.0.99.http: . ack 3438589941 win 3072
02:26:32.335840 192.168.0.9.35984 > 192.168.0.99.http: . ack 3438589941 win 3072
02:26:32.335870 192.168.0.199.35984 > 192.168.0.99.http: . ack 3438589941 win 3072

Syntaxe ethreal: tethereal -r 0826\@19-snort.log -n "! ip.src eq 192.168.0.99 and (icmp.type eq 8 or tcp.flags eq 0x10)"

A 01:59:50, 02:21:04 et 02:23:17, on observe des pings ICMP et TCP ACK, à 02:24:39, un ping TCP ACK et à 02:26:32, des pings ICMP et TCP ACK provenant de plusieurs sources.

tcpslice -w s1.log "0" "02h21m04s853059u" 0826\@19-snort.log tcpslice -w s2.log "02h21m04s853059u" "02h23m17s506855u" 0826\@19-snort.log tcpslice -w s3.log "02h23m17s506855u" "02h24m39s805309u" 0826\@19-snort.log tcpslice -w s4.log "02h24m39s805309u" "02h26m32s335638u" 0826\@19-snort.log tcpslice -w s5.log "02h26m32s335638u" "23h" 0826\@19-snort.log

Leurres

Nmap peut utiliser des leurres (option -g), ainsi la cible a l'impression de se faire scanner par plusieurs machines différentes.

08/27-02:26:42.655912  [**] [111:10:1] spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection [**] {TCP} 192.168.0.1:35964 -> 192.168.0.99:1542
08/27-02:26:42.655918  [**] [111:10:1] spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection [**] {TCP} 192.168.0.254:35964 -> 192.168.0.99:1542
08/27-02:26:42.655980  [**] [111:10:1] spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection [**] {TCP} 192.168.0.9:35964 -> 192.168.0.99:1542
08/27-02:26:42.655995  [**] [111:10:1] spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection [**] {TCP} 192.168.0.199:35964 -> 192.168.0.99:1542

TCP SYN et TCP connect scan

Le TCP SYN scan consiste en l'envoi de paquets SYN comme pour initialiser des connexions TCP. Si le port destination du serveur est ouvert, il renvoie un Syn/Ack et dans le cas contraire, un paquet avec l'indicateur RST (reset).

09/14-16:44:48.031067  [**] [100:1:1] spp_portscan: PORTSCAN DETECTED from 192.168.0.9 (THRESHOLD 4 connections exceeded in 0 seconds) [**]
09/14-16:44:48.037698  [**] [100:2:1] spp_portscan: portscan status from 192.168.0.9: 170 connections across 1 hosts: TCP(170), UDP(0) [**]
09/14-16:44:48.047311  [**] [100:2:1] spp_portscan: portscan status from 192.168.0.9: 205 connections across 1 hosts: TCP(205), UDP(0) [**]

Comment distinguer un TCP SYN scan d'un TCP connect scan ? Le TCP SYN scan se limite à l'envoi d'un paquet SYN forgé par le scanner tandis que le TCP connect scan utilise les fonctions de connections standard du système d'exploitation. De manière pratique, si on observe un paquet SYN suivi d'un paquet SYN/ACK, le scanner en mode SYN scan vient de détecter un port ouvert. Si un paquet ACK suit, il s'agit alors d'un scan TCP connect.

Pour repérer les TCP connect scan, sélectionnons les paquets TCP avec le flag ACK.

tcpdump -r ../sotm23/0826\@19-snort.log "tcp[13]=0x10" -n

01:59:50.250803 192.168.0.9.52218 > 192.168.0.99.http: . ack 4094787819 win 2048	TCP SYN Scan
02:21:04.853103 192.168.0.9.42314 > 192.168.0.99.http: . ack 2866936176 win 4096	NULL Scan
02:21:38.723091 192.168.0.9.42304 > 192.168.0.99.ssh: . ack 0 win 4096 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> OSfingerprinting
02:21:38.723304 192.168.0.9.42306 > 192.168.0.99.tcpmux: . ack 0 win 4096 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol>
02:23:17.506900 192.168.0.9.58183 > 192.168.0.99.http: . ack 3623169759 win 1024	XMAS Scan
02:23:51.679297 192.168.0.9.58173 > 192.168.0.99.ssh: . ack 0 win 1024 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> OSfingerprinting
02:23:51.679512 192.168.0.9.58175 > 192.168.0.99.tcpmux: . ack 0 win 1024 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol>
02:24:39.805309 192.168.0.9.40551 > 192.168.0.99.http: . ack 1401847552 win 1024	TCP connect Scan

02:24:50.337389 192.168.0.9.34203 > 192.168.0.99.sunrpc: . ack 1288214714 win 5840 <nop,nop,timestamp 16917393 14921528> (DF)
02:24:51.037263 192.168.0.9.34398 > 192.168.0.99.http: . ack 1296081605 win 5840 <nop,nop,timestamp 16917463 14921598> (DF)
02:24:51.117254 192.168.0.9.34399 > 192.168.0.99.https: . ack 1296564949 win 5840 <nop,nop,timestamp 16917471 14921606> (DF)
02:24:52.417675 192.168.0.9.34800 > 192.168.0.99.ssh: . ack 1296230717 win 5840 <nop,nop,timestamp 16917601 14921736> (DF)
02:24:53.597612 192.168.0.9.35169 > 192.168.0.99.domain: . ack 1298205505 win 5840 <nop,nop,timestamp 16917719 14921854> (DF)

02:24:54.378018 192.168.0.9.40541 > 192.168.0.99.ssh: . ack 0 win 1024 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> OSfingerprinting
02:24:54.378205 192.168.0.9.40543 > 192.168.0.99.tcpmux: . ack 0 win 1024 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol>
02:26:32.335785 192.168.0.1.35984 > 192.168.0.99.http: . ack 3438589941 win 3072	XMAS Scan
02:26:32.335790 192.168.0.254.35984 > 192.168.0.99.http: . ack 3438589941 win 3072
02:26:32.335840 192.168.0.9.35984 > 192.168.0.99.http: . ack 3438589941 win 3072
02:26:32.335870 192.168.0.199.35984 > 192.168.0.99.http: . ack 3438589941 win 3072

On distingue 5 paquets avec des options TCP et un numéro d'acknowledge non nul. Entre 02:24:50 et 02:24:53, un scan TCP connect a eu lieu.

TCP NULL scan

08/27-02:21:15.175153  [**] [111:9:1] spp_stream4: STEALTH ACTIVITY (NULL scan) detection [**] {TCP} 192.168.0.9:42294 -> 192.168.0.99:1393

Le scanner envoie un paquet qui ne comporte aucun indicateur. Le système distant ignore le paquet si le port est ouvert et renvoie un paquet Reset dans le cas contraire.

TCP Xmas scan

Le scanner envoie un paquet qui ne comporte aucun indicateur. Le système distant ignore le paquet si le port est ouvert et renvoie un paquet Reset dans le cas contraire.

08/27-02:23:27.821221  [**] [111:10:1] spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection [**] {TCP} 192.168.0.9:58163 -> 192.168.0.99:963

Résultats des scan de port

Lorsqu'un TCP SYN scan ou TCP connect scan a eu lieu, il suffit de sélectionner les paquets avec les indicateurs SYN/ACK pour obtenir les ports ouverts. Pour cela, utilisons plaçons un filtre sur tcpdump ou ethereal tethereal -r 0826\@19-snort.log -n "tcp.flags eq 0x12" tcpdump -r 0826\@19-snort.log -n "tcp[13]=0x12"

[kmaster@christophe sotm23]$ tcpdump -r 0826\@19-snort.log "tcp[13]=0x12" -n|cut -d' ' -f 2|sort -u
192.168.0.99.domain
192.168.0.99.http
192.168.0.99.https
192.168.0.99.ssh
192.168.0.99.sunrpc
192.168.0.99.32768

Il est à priori plus difficile de remarquer quels sont les ports ouverts lors d'un scan furtif (XMAS, NULL), car il faut rechercher les ports qui ne répondent pas! En réalité, ce n'est pas une difficulté car à la fin de son scan, Nmap vérifie les résultats en recommençant un scan sur les ports qui n'ont pas répondu.

OS Fingerprinting

Même si les protocoles IP/TCP/UDP/ICMP sont normalisés, leurs implémentations sont différentes selon les systèmes d'exploitation. Dès lors, ils peuvent réagir différemment à certains paquets. Nmap va envoyer plusieurs paquets avec plusieurs combinaisons d'indicateurs (SYN,ACK,FIN,URG,PSH...) et de paramètres IP pour identifier le système d'exploitation distant.

Fingerprinting de la victime

Pour identifier le système d'exploitation distant, Nmap envoie différents paquets sur un port TCP ouvert et sur un port TCP fermé.

08/27-02:21:38.723091  [**] [111:12:1] spp_stream4: NMAP FINGERPRINT (stateful) detection [**] {TCP} 192.168.0.9:42304 -> 192.168.0.99:22
08/27-02:21:38.723384  [**] [111:10:1] spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection [**] {TCP} 192.168.0.9:42307 -> 192.168.0.99:1
08/27-02:21:38.723549  [**] [1:402:4] ICMP Destination Unreachable (Port Unreachable) [**] [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.0.99 -> 192.168.0.9
08/27-02:21:40.522698  [**] [111:9:1] spp_stream4: STEALTH ACTIVITY (NULL scan) detection [**] {TCP} 192.168.0.9:42302 -> 192.168.0.99:22

Il constate s'il reçoit une réponse et si c'est le cas, il vérifie au niveau IP

l'indicateur DF, Don't Fragment.

et au niveau TCP

Window size
la valeur du numéro d'acknowledge par rapport au numéro de séquence du paquet envoyé
les flags: ACK, SYN, RST...
l'ordre des options

Avec ethereal, relevons ces valeurs et écrivons les résultats à la façon de Nmap

T1(DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW)
T4(DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(DF=Y%W=0%ACK=S++%Flags=AR%Ops=)

En recherchant dans le fichier nmap-os-fingerprints, la base de connaissance de Nmap, on trouve la signature suivante

Fingerprint Linux Kernel 2.4.0 - 2.5.20
TSeq(Class=RI%gcd=<8%SI=<2D870AA&>10000%IPID=Z|C|I|RD%TS=100HZ|U)
T1(DF=Y%W=5B4|F98|1140|11AC|12CC|16A0|1680|2D244000|7E18|7FFF%ACK=S++%Flags=AS%Ops=MNNTNW)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=5B4|F98|1140|11AC|12CC|16A0|1680|2D24|4000|7E18|7FFF%ACK=S++%Flags=AS%Ops=MNNTNW)
T4(DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
PU(DF=Y|N%TOS=14|C0|0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E|F%UCK=E|F%ULEN=134%DAT=E)

Elle correspond parfaitement. Le système scanné est un Linux Kernel 2.4.0 - 2.5.20. Remarque, Nmap effectue d'autres tests (TSeq et PU) dont je n'ai pas traduis les résultats.

Fingerprinting de l'attaquant

p0f, http://www.stearns.org/p0f/, a pour but d'identifier un système d'exploitation en observant les ouvertures de connexion réseaux. Il est passif, c'est à dire qu'il n'envoie aucun paquet, il se contente d'observer.

Le scan TCP connect utilise la fonction connect() du système d'exploitation, les paquets ne sont donc pas forgés ce qui laisse une chance d'identifier le système d'exploitation à l'origine du scan.

[kmaster@christophe sotm23]$ p0f -s 0826\@19-snort.log|sort -u
p0f: passive os fingerprinting utility, version 1.8.2
(C) Michal Zalewski <lcamtuf@gis.net>, William Stearns <wstearns@pobox.com>
p0f: file: '/etc/p0f.fp', 150 fprints, iface: 'eth0', rule: 'all'.
192.168.0.9 [12 hops]: NMAP scan (distance inaccurate) (7)
192.168.0.9 [17 hops]: NMAP scan (distance inaccurate) (2)
192.168.0.9 [1 hops]: Linux 2.4.2 - 2.4.14 (1)
192.168.0.9 [21 hops]: NMAP scan (distance inaccurate) (2)
192.168.0.9 [26 hops]: NMAP scan (distance inaccurate) (11)

Bingo, la signature permet d'identifier un Linux avec un noyau 2.4, probablement 2.4.2 ou supérieur.

Chronologie des événements

01:59:50	Ping ICMP et TCP ACK
02:00:00-02:20:35	SYN scan
02:21:04	Ping ICMP et TCP ACK
02:21:15-02:21:38	TCP NULL scan
02:21:38	Nmap Fingerprint
02:23:17	Ping ICMP et TCP ACK
02:23:27-02:23:51	TCP XMAS scan
02:23:51	Nmap Fingerprint
02:24:39	Ping TCP ACK
02:24:50-02:24:54	TCP connect scan
02:24:54	Nmap Fingerprint
02:26:32	Ping ICMP et TCP ACK, sources multiples
02:26:42-02:27:32	TCP XMAS scan, sources multiples

Les dix secondes entre le ping sweep et le début du scan sont dues à une tentative de résolution de nom infructueuse. Le premier scan est plus long que les autres car les 65000 ports ont été scannés. Aucun FIN scan, c'est dommage. Il s'agit d'une autre technique de scan à base de paquets avec l'indicateur FIN, indicateur servant à clore une connexion.

Christophe GRENIER, Consultant sécurité chez Global Secure grenier@cgsecurity.org