• la longueur du datagramme IP ayant provoqué l'erreur: RIPTL
• le checksum de l'entête IP: RIPCK
au niveau UDP
• si l'ID du paquet UDP n'a pas été altéré: RID
• le checksum UDP: UCK
• la longueur du paquet UDP: ULEN.
• si les données UDP ont été altérées: DAT

PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

Octet TOS

L'octet TOS, Type Of Service , se découpe ainsi

Bits 0-2:  Precedence.
Bit    3:  0 = Normal Delay,      1 = Low Delay.
Bits   4:  0 = Normal Throughput, 1 = High Throughput.
Bits   5:  0 = Normal Relibility, 1 = High Relibility.
Bit  6-7:  Reserved for Future Use.

0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|                 |     |     |     |     |     |
|   PRECEDENCE    |  D  |  T  |  R  |  0  |  0  |
|                 |     |     |     |     |     |
+-----+-----+-----+-----+-----+-----+-----+-----+

Le RFC 791 indique que les routeurs doivent régler la précédence ou priorité d'un message d'erreur ICMP autre que ICMP source quench à 6 (Internetwork control) ou 7 (Network control). Les routeurs Cisco IOS 11.x ou 12.x et les Linux 2.x utilisent une priorité Internetwork control et l'octet TOS est donc à 0xC0.

ICMP Error Message Quoting Size

Tel que définis dans le RFC 1122, les messages d'erreurs ICMP inclus l'entête IP et au moins les 8 premiers octets du datagramme ayant provoqué l'erreur. La longueur du paquet, IPLEN, est donc de 56 octets minimum ( Entête IP:20, Entête ICMP:8, Entête IP:20 + 8). Windows et Mac OS X renvoient 8 octets, pas plus, la taille du paquet est donc de 56 (0x38 en hexadécimal). Le RFC 1812, plus récent, recommande d'inclure autant d'octets du datagramme d'origine sans excéder toutefois une taille maximale totale de 576 octets. Linux utilise cette limite mais comme le paquet UDP de Nmap est de 328 octets, la longueur du paquet ICMP est de 356 octets (0x164).

RIPTL

Le paquet UDP envoyé sur un port UDP fermé est de 328 octets (0x148). On devrait donc retrouver cette taille dans l'entête IP encapsulé dans le message ICMP d'erreur. Certains systèmes bogués indiquent une mauvaise taille. L'erreur classique est qu'ils ajoutent (IBM AIX) ou soustraient (OpenBSD) 20 octets correspondant à la taille de l'entête IP.

Checksum IP: RIPCK

Entre l'émission du paquet et sa réception, le TTL est décrémenté à chaque routeur, et en conséquence, le checksum est recalculé. Dans la copie du paquet, le checksum est parfois invalide (IBM AIX) ou mis à zéro (BSDI, HP, OpenBSD <= 2.3).

Recopie de l'ID: RID

L'ID est parfois mal recopié. Ce bug peut apparaître dû à une différence entre l'ordre des octets sur le réseau et au niveau de l'architecture processeur (big versus little endian).

Checksum UDP: UCK

Le checksum UDP peut être à zéro ou à une valeur incorrecte sur certains OS.

Intégrité

Tous les OS connus de Nmap renvoient la bonne longueur du paquet UDP, soit 0x134. Il semblerait qu'aucun OS n'est buggué au point d'altérer cette valeur mais quelques systèmes rares altéreraient les données.

Numéro de séquence, d'id et timestamp

Un moyen d'identifier le système d'exploitation est de déterminer l'algorithme utilisé pour générer les numéros de séquences. Pour cela, quelques paquets SYN sont envoyés sur un port ouvert et les numéros de séquences contenus dans les paquets SYN/ACK sont étudiés.

Les grandes familles de générateurs de numéro de séquence sont

• la classe constante: le numéro de séquence est constant ou change très lentement.
• 64k
• i800
• TD gcd SI
• RI gcd SI
• TR: truly random

De la même manière, on peut étudier la génération du numéro d'ID, numéros utilisés pour gérer la fragmentation TCP des paquets.

• C constant
• I incremental
• BI broken incremental. Typique d'un Windows, l'incrément est de 256.
• RPI
• RD
• Z toujours zéro

L'analyse de l'option TCP Timestamp permet de déterminer avec quelle fréquence d'horloge est gérée la couche réseau.

• 0
• 2Hz
• 100Hz
• 1000Hz
• U non supporté

En pratique

Dans la pratique, le scanner de port nmap parviendra dans la majorité des cas à identifier le système d'exploitation sans qu'il soit nécessaire de décortiquer les paquets à la main.

[root@christophe root]# nmap -O -sS -p 80,130-140 192.168.1.15 -n -vv

Starting nmap V. 3.10ALPHA9 ( www.insecure.org/nmap/ )
Host 192.168.1.15 appears to be up ... good.
Initiating SYN Stealth Scan against 192.168.1.15
Adding open port 139/tcp
Adding open port 135/tcp
The SYN Stealth Scan took 0 seconds to scan 12 ports.
For OSScan assuming that port 135 is open and port 80 is closed and neither are firewalled
Interesting ports on 192.168.1.15:
(The 10 ports scanned but not shown below are in state: closed)
Port       State       Service
135/tcp    open        loc-srv
139/tcp    open        netbios-ssn
Remote operating system guess: Windows Millennium Edition (Me), Win 2000, or WinXP
OS Fingerprint:
TSeq(Class=RI%gcd=1%SI=959%IPID=I%TS=0)
T1(Resp=Y%DF=Y%W=FC00%ACK=S++%Flags=AS%Ops=MNWNNT)
T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
T3(Resp=Y%DF=Y%W=FC00%ACK=S++%Flags=AS%Ops=MNWNNT)
T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

TCP Sequence Prediction: Class=random positive increments
                         Difficulty=2393 (Medium)
TCP ISN Seq. Numbers: 6B8F4294 6B90952C 6B91D4F5 6B9326DE 6B948356 6B95D04C
IPID Sequence Generation: Incremental

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

Tempo

La dernière méthode en date est de contacter avec un SYN un port TCP ouvert et de vérifier le délai entre les retransmissions des SYN/ACK et bien sûr leur nombre. Cette idée a donné lieu au programme Ring, http://www.intranode.com/pdf/techno/ring-0.0.1-Linux-2.4.tar.gz, dont voici quelques résultats:

Cette technique est très intéressante lorsqu'un firewall protége un serveur et que seul un port TCP est accessible.