Structure d'une attaque, part III

Par 4n9e le 24-09-2004

---

Cette troisième partie aborde le sujet de la détermination des services présents sur une cible considérée. L'outil utilisé pour l'illustration pratiqu

Sommaire :

I. Pré-requis
II. Telechargements
III. Linux
IV. Exploitation
V. Commandes de base
VI. Liste des commandes
VII. Examples
VIII. Comment ca marche
IX. Comportement
X. La prise d'empreinte
XI. Techniques classiques
XII. Programmes actuels d'identification
XIII. Méthodologie de la prise d'empreinte
XIV. Nmap sous windows

Dans les parties précédentes, nous avons vu la collecte d'information sur une cible, puis abordé certaines options permettant de bypasser un eventuel firewall. Comme expliqué dans la deuxième partie, le préalable est donc de déterminer la présence des différents services présents sur la cible considérée.

Nous allons donc aujourd'hui essayer de nous plonger dans le monde du scan. Plus précisement, c'est le logiciel Nmap que nous allons étudier.

Cet article aura deux buts : présenter dans un premier temps toutes les actions qui se cachent derrière votre outil de scan favori (superscan, ipscan et autres), et dans un deuxième temps de vous faire lacher un peu ces outils "tout-en-un" simplistes et voyants pour faire adopter aux scanners exigeants ce logiciel complet en touts points qu'est Nmap.

Certaines choses seront directement reprises et traduites du manuel de Nmap, étant donné que je ne vais pas ré inventer ce logiciel. Vous pourrez donc les retrouver dans le dossier Nmap, ou sur le site Insecure.org.



I. Pré-requis


Tout au long de cet article, on fera de nombreuses références à des notions de protocoles, de réseau, de ports etc...
Pour mémoire, et ne pas reprendre dans chaque article des explications déja décrites ailleurs, je vous renvoie aux articles dédiés, ici ou sur le forum.

Toutefois, voici la description des en tetes principales :




les 6 bit de FLAG sont dans l'ordre :
URG (Urgent -> le pointeur urgent est valide)
ACK (Acknowledge)
PSH (Push -> transferer les donnees a l'application le plus rapidement possible)
RST (Reset)
SYN (SYNc ?)
FIN (FINish ?)

l'etablissement d'une connection TCP se fait en 3 etapes:


Emeteur_________________________________________Recepteur

SYN+ISN(initial sequence number)-------------->
.......<---------------------------------------SYN+ACK(ISN+1)
ACK(ISN+1)------------------------------------>


quand un emetteur reste a l'etape un (envoi du SYN) il remplit le serveur de demande de connection en cours : C'est le SYN-flood . Le serveur se retrouve avec sa file d'attente de connection remplie de connections en cours d'etablissement, ce qui empeche l'etablissement de nouvelles connections...

Ceci étant, il vous reste a vous préparer pour suivre les étapes suivantes de l'article:
l'installation de Nmap.



II. Telechargements


Windows
Il sera necessaire d'installer deux programmes : Nmap, et Winpcap qui assurera la capture des paquets réseau.

Nmap sur une plateforme Windows est disponible en deux versions : la version en lignes de commande (DOS), utilisant un moteur Nmap V3.50, le plus aboutit au moment où j'écrit ces lignes.
Une version GUI, interface graphique d'utilisateur (en fenetre sous windows), utilisant un moteur Nmap V3.00. Ces deux versions ont les memes fonctionnalités de base, mais de grandes differences de performances existent :

Detection de Versions d'OS et de services, dû a une base de données plus aboutie et de nouvelles techniques apparues a la version 3.45
IPv6
Supports Mac OS X
ping scans sur protocoles UDP
travail en parallèle sur les ports et les techniques employés simultanément
scan du port zero
controle du TTL (Time To Live)
packet tracing

Toutefois, pour les commandes de base et pour débuter, la version Interface Graphique sera suffisante, et affranchira le nouveau
d'entrées de lignes de commandes fastidieuses. Il sera toujours temps de passer à une version DOS plus serieuse.

Concernant WinPcap, notez qu'il est imperatif d'installer une version jusqu' à V3.01, celles ci étant les seules testées stables a ce jour.
Evitez absolument la derniere version 3.1 Beta 2, celle ci ne fonctionne plus avec Nmap (pour le moment).
A l'installation, enlever d'abord la version ancienne de WinPcap qui peut se trouver sur la machine (Ajout/Suppression de programmes).



III. Linux

Il est possible d'installer les RPM par ce biais :

rpm -vhU http://download.insecure.org/nmap/dist/nmap-3.50-1.i386.rpm
rpm -vhU http://download.insecure.org/nmap/dist/nmap-frontend-3.50-1.i386.rpm

Ou le faire a la main avec les fichiers RPM :

X86 Nmap RPM: nmap-3.50-1.i386.rpm
X86 NmapFE RPM: nmap-frontend-3.50-1.i386.rpm
Source RPM (comprend NmapFE): nmap-3.50-1.src.rpm


Le pack confort

Pour vous éviter de vous perdre dans les méandres des sites de telechargements d'insecure et de Polito, voici :

Pack Nmap Windows et Linux


IV. Exploitation

Ceci étant fait, verrifions l'installation. On verra surtout par la suite la version en lignes de commandes, plus complete et aussi plus
complexe a prendre en mains. Pour commencer, les utilisateurs de Windows devront executer le fichier .REG qui va modifier une clé de registre afin d'optimiser les scans.
Apres un redemarrage, tout le monde devrait etre pret a travailler correctement.

Avant de s'attaquer aux instructions de base, verrfions la présence de tous les éléments de l'installation.
Pour ceci, entrez la ligne de commande suivante (on detaillera ceci plus tard):

nmap -v -v -sT -d -P0 --version_trace insecure.org

Pour stopper le scan, utiliser [CTRL+C]. On doit obtenir les informations suivantes :


On voit ici la presence de tous les fichiers, et celle de WinPcap.


V. Commandes de base

L'usage de Nmap est le suivant :

nmap Type de scanOptionsRenvoyer les étapes du scan -oN enregistrer le compte rendu ici cible.com

Chaque argument est précédé d'un Hyphen ( - ). Tout argument non précédé d'un Hyphen est pris comme le nom de cible.
Prenons d'ors et deja l'habitude d'inclure systématiquement la commande de génération d'un fichier de résultats (commande -oN <nom du fichier a créer>.
En effet, sur une grosse cible, l'émulateur DOS ressemblera vite aux écrans de Matrix, avec un défilement pendant cinq bonnes minutes au mieux !
Comme le tampon DOS n'est pas illimité, les informations du debut seront écrasées, et donc perdues.

Comme tout scanner, Nmap permet les scans suivants, mais deja avec des options plus fouillées :

* scan d'une range d'Ip
Ip/mask
/24 = addresses de classe C
/16 = addresses de classe B
/0 = tout le Net
/32 = seulement l'ip spécifiée

Exemple : 192.168.0.0/16


toute la classe B : 192.168.*.*
ou encore 192.168.0-255.0-255
ou encore 192.168.1-50,56-255.1,4,5-25 ceci combiné aura pour effet de scanner :

toutes les addresses de 192.168.1.1 , 192.168.1.4 , 192.168.1.5 à 25, puis 192.168.2.1 , 192.168.2.4 , 192.168.2.5 à 25
jusqu'à 192.168.50.1 , 192.168.50.4 , 192.168.50.5 à 25 , et enfin reprendre de 192.168.56 à 192.168.255
D'accord, il faut être viscieux ! mais ceci est juste pour montrer la flexibilité des ranges de scan.

Autre option :
scanner la derniere partie des Ip : *.*.5.6-7 scannera toutes les addresses se terminant par .5.6 or .5.7

* scan de Host

usage : host.com


* scan de ports sur une ou plusieurs cibles :

c'est l'option -p <liste de ports>

Exemple : -p 20-30,139,60000-
Ceci scannera les ports de 20 à 30, le port 139, et tous les ports au dessus de 60000.

On peut utiliser comme alternative l'option -F. Celle ci scannera tous les ports listés dans le fichier Nmap dédié (1217 ports reconnus)
Enfin, ne pas spécifier d'option de port scannera les 1024 premiers ports de la cible.


VI. Liste des commandes

Taper nmap[Enter] vous donnera la liste des commandes les plus utilisées. En réalité, la liste complete des commandes est beaucoup plus conséquente :
En utilisant le même code couleur que plus haut, on peut les regrouper comme suit :


Types de Scan

-sS TCP SYN scan: Scan "demi ouvert", en ce sens qu'on initialise pas une connection TCP complete.
Un paquet SYN est envoyé. Si le serveur renvoie SYN|ACK , le port est en ecoute. Si il renvoie RST,
il ne l'est pas. SYN|ACK est envoyé afin de fermer cette tentaive de connexion. Tres peu de cibles peuvent logger ce type de scan.


-sT TCP connect() scan: Le scan classique de tous les scanneurs type Superscan. Si une connexion complete est ouverte, le port est OK, sinon...non !
Ce type de scan est tres facilement detectable (on y reviendra avec un exemple), parce que chaque connexion est immediatement fermée (ce qui peut paraitre étrange, n'est il pas ?).


-sF -sX -sN
Scans furtifs de types Stealth FIN, Xmas Tree, or Null scan.
Leurs principes évitent la detection des paquets SYN que peuvent faire certains firewalls. Ils envoient des paquets
innatendus. Un systeme Windows ne reconnait pas les paquets ainsi formés. De cette facon, un de ces scans ne fonctionnera pas sur une cible Windows.
On peut donc déduire la machine cible, si un scan SYN est probant, et un Xmas ne marche pas (par exemple).
Le meme probleme apparait sur les plateformes Cisco, BSDI, HP/UX, MVS, et IRIX.


-sP Ping scanning: Envoi de paquets ICMP. Ceux ci passent frequement les firewalls.
Cette technique est utilisé pour savoir uniquement quelles sont les machines connectées.
Toutefois, certaines cibles comme Windows.com bloquent les réponses à ces paquets.


-sV Detection de la version: Chaque port découvert est interrogé pour determiner son protocole, le service qui tourne, et sa version.

-sU UDP scans: Détermine quels sont les ports ouverts en UDP sur la cible.

-sO IP protocol scans: Détermine les protocoles IP sur la cible.

-sI <zombie host[:port de redirection]>
Méthode de scan via une autre machine. La cible, si elle detecte un scan, n'en verra pas la provenace réelle.

-sA ACK scan: Ce type de scan analyse le firewall. Il permet en autre de savoir si on a affaire a un vrai firewall,
ou a un simple filtrage de paquets SYN.
On saute donc l'étape SYN, et on attend la réaction. Un paquet RST ? => non filtré. ICMP unreachable ? => filtré
A noter que ce type de scan ne montrera jamais un port comme ouvert (normal !).

-sW Window scan: Comme le ACK scan, mais il peut determiner si le port est ouvert, a cause d'une erreur
dans le traitement des paquets sur les systemes AIX, Amiga, BeOS, BSDI, Cray,
Tru64 UNIX, DG/UX, OpenVMS, Digital UNIX, FreeBSD, HP-UX, OS/2,
IRIX, MacOS, NetBSD, OpenBSD, OpenStep, QNX, Rhapsody, SunOS
4.X, Ultrix, VAX, and VxWorks.

-sR RPC scan.

-sL List scan. liste de machines, avec determination DNS

-b <ftp relay host>
FTP bounce attack: scanner un FTP depuis une machine tierce (fonction de proxy), par exemple proxy.com
usage de la machine proxy : username:password@server:port.


OPTIONS

-P0 Ne ping pas la cible avant de la scanner. A utiliser systematiquement.

-PT [portlist]
permet de determiner si une cible est connectée sans la pinger, en envoyant un paquet ACK
C'est utile pour une cible protégée par un firewall qui n'autorise pas la reponse aux ICMP. Le
port par defaut est 80 (normalement non filtré).

-PS [portlist]
Identique, mais envoie un paquet SYN

-PU [portlist]
Pareil, en UDP

-PE Envoie un paquet ICMP pour trouver les cibles connectées et chercher les sous reseaux.
Les machines trouvées ainsi sont directement accessibles depuis le reseau exterieur, et donc sensibles aux attaques (montre un mauvais firewall).


-PP envoie un paquet requète ICMP pour determiner les machines connectées.

-PM Comme les precedentes, mais avec un paquet ICMP différent.

-PB Le ping par defaut. Utilise le paquet ACK et l'ICMP.
Determine si le firewall filtre l'un ou l'autre.

-O Active l'identification de la cible par prise d'empreinte TCP/IP.
Voir la description des techniques plus bas.
Si on utilise aussi le mode verbeux ( -v ), renvoie l' IPID Sequence Generation
La plupart des machines étant de type "incremental", elles incrémentent la partie ID de l'en tete de l'IP
a chaque paquet renvoyé. Ceci est la marque d'une vulnérabilité au spoofing, et aide a la collecte d'informations.

-A Cumule les options OS Detection (-O) et version scanning
(-sV).

-6 IPv6 support. La cible doit supporter l'IpV65. Supporte les scan TCP connect et Ping TCP connect.

-I Determine le propriétaire du service qui tourne sur chacun des ports. Ne marche qu'avec
les connexions établies (TCP connect, -sT).

-f Dans le ces des scans de type FIN, XMAS, or NULL scan , fragmente les paquets TCP
dans le but de dérouter les protections et autres firewalls. Peut causer des bugs sur certains systemes.

-v Verbose mode. Donne des information sur ce qui est en train de se passer.
Il est conseillé de l'entrer deux fois.

-h Help !

-oN <logfilename>
Crée le fichier de compte rendu du scan

-oX <logfilename>
Idem, en XML

-oG <logfilename>
Idem, en grep. Pour le devellopement de Nmap.

-oA <basefilename>
Idem, dans tous les formats (normal,
grepable, et XML).

-oS <logfilename>
Idem, écrit en cowboyZ L4(\/)3r Rul3Z !

--resume <logfilename>
Reprendre un scan apres l'avoir gelé par [control+c]

--append_output
Ajoute a la fin d'un fichier, plutot que l'écraser.

-iL <inputfilename>
Prend les commandes depuis le fichier specifié plutot que les re ecrire

-iR <num hosts>
Dit a Nmap de générer lui meme ses cibles au hasard...


-D <decoy1 [,decoy2][,ME],...>
Hologrammes. Ceci fait croire a la cible que le scan vient de plusieurs machines, la vraie étant
parmis elles. Séparer les mirroirs par des virgules, et spécifier ME a la place où on veut que s'insere la vraie machine.
Les mirroirs doivent être connectés. On peut utiliser des IP.

-S <IP_Address>
Donne votre IP a Nmap si celui ci ne peut le determiner (pour les reponses).
Utilisé aussi pour le spoofing, faire croire que le scan vient d'ailleurs...

-g <portnumber>
Donne le port que va utiliser Nmap pour travailler. Sinon, c'est au hasard.
Certains firewalls sont reglés pour laisser passer les connexions depuis certains ports. On utilisera alors cette option.

--data_length <number>
FIxer la taille des paquets de Nmap, pour qu'ils paraissent moins suspects.

-n ne pas faire de resolution DNS.

-R toujours faire la resolution DNS

-r Scanner les ports en ordre, et non au hasard

--ttl <value>
Regle le TTL des paquets (sur les cibles a nombreux rebonds)

--randomize_hosts
Sur les scans de nombreuses cibles, les prendre non pas dans l'ordre (suspect !) mais au hasard.

-M <max sockets>
Regle le nombre maximum de sockets utilisés en parallèle dans le cas d'un scan TCP connect (-sT).

--packet_trace
Montre tous les paquets envoyés par Nmap pendant le scan.
Aussi ceux recus. Utile pour apprendre !

--datadir [directoryname]
Donne le chamin du repertoire où sont les fichiers Nmap, si ceux ci ont été déplacés :
nmap-services, nmap-protocols, nmap-rpc, et nmap-os-fingerprints.


TIMING

-T <Paranoid|Sneaky|Polite|Normal|Aggressive|Insane>
La vitessse de Nmap, le temps entre chaque requete. De 5 minutes (!!!)
à 0.3 secondes. Utiliser le niveau Insane dans le cas des reseaux rapides, avec le risque de perdre des informations.
Aggressive est utile dans le cas des scans utilisant SYN sur des cibles fortement filtrées.
Usage : -T0 (paranoid) => -T5 (insane)

--host_timeout <milliseconds>
Donne le temps maximum que doit passer Nmap sur une cible. Par defaut, il est illimité.

--max_rtt_timeout <milliseconds>
Temps maximum a attendre une reponse a une requete de Nmap. Par defaut, 9000

--max_parallelism <number>
Nombre maximum de scans en parallèle.

--min_parallelism <number>
nombre minimum de scans en parallèle.

--scan_delay <milliseconds>
Temps minimum entre les requetes de Nmap.

--version_trace
montre toutes les activités connect/send/recv du scan.




VII. Examples

nmap -v target.example.com

Scanner les ports TCP classiques sur target.example.com. Dire tout ce qui se passe.

nmap -sS -O target.example.com/24

Scan furtif type SYN scan sur toutes les machines connectées
parmis toutes les machines de classe C où réside target.example.com resides.
Determine aussi les OS.

nmap -sX -p 22,53,110,143,4564 198.116.*.1-127

Xmas tree scan sur la premiere moitié des IP d'un reseau de classe B (192.116.)
Analyser si elles utilisent les services sshd, DNS, pop3d, imapd, ou le port 4564.

nmap -v --randomize_hosts -p 80 *.*.2.3-5

Trouve tous les serveurs dont l'Ip se termine par .2.3, .2.4, ou .2.5.


VIII. Comment ca marche

Voici un exemple de scan typique avec Nmap :


nmap -A -T4 -F www.insecure.org

Starting nmap 3.40PVT16 ( http://www.insecure.org/nmap/ ) at 2003-09-06 19:49 PDT
Interesting ports on www.insecure.org (205.217.153.53):
(The 1206 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 3.1p1 (protocol 1.99)
25/tcp open smtp Qmail smtpd
53/tcp open domain ISC Bind 9.2.1
80/tcp open http Apache httpd 2.0.39 ((Unix) mod_perl/1.99_07-dev Perl/v5.6.1)
113/tcp closed auth
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux Kernel 2.4.0 - 2.5.20
Uptime 108.307 days (since Wed May 21 12:27:44 2003)

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


Voici a present un resultat commenté du scan d'un serveur, comprenant une empreinte que Nmap n'a pas pu identifier :


# nmap 3.50 scan initiated Sun May 09 10:06:42 2004 as:

# Commentaire : nmap Type de scanOptionsRenvoyer les étapes du scan -oN enregistrer le compte rendu ici cible.com

nmap -sT -sV -O -P0 -v -v -d -F -T4--packet_trace --version_trace -oN scan.log cible.com

SENT (418.5310s) TCP xx.xxx.xxx.xx:44049 > yyy.yyy.yy.yy:22 SE ttl=44 id=39455 iplen=60 seq=1404505681 win=1024
SENT (418.5470s) TCP xx.xxx.xxx.xx:44050 > yyy.yyy.yy.yy:22 ttl=54 id=24907 iplen=60 seq=1404505681 win=3072
SENT (418.5630s) TCP xx.xxx.xxx.xx:44051 > yyy.yyy.yy.yy:22 SFPU ttl=53 id=36617 iplen=60 seq=1404505681 win=2048
SENT (418.5780s) TCP xx.xxx.xxx.xx:44052 > yyy.yyy.yy.yy:22 A ttl=52 id=15953 iplen=60 seq=1404505681 win=1024 ack=1404505681
SENT (418.5780s) TCP xx.xxx.xxx.xx:44053 > yyy.yyy.yy.yy:1 S ttl=44 id=37732 iplen=60 seq=1404505681 win=1024
SENT (418.5940s) TCP xx.xxx.xxx.xx:44055 > yyy.yyy.yy.yy:1 FPU ttl=41 id=27184 iplen=60 seq=1404505681 win=2048

# Les séquences de paquets envoyés pour déterminer l'OS sont inscrits dans le fichier log.
# Ils sont ici volontairement épurés, la liste est énorme sinon !

Interesting ports on cible.com (212.xx.xx.xxx):
(The 1210 ports scanned but not shown below are in state: closed)

PORT STATE SERVICE VERSION
21/tcp filtered ftp
22/tcp open ssh OpenSSH 3.8p1 (protocol 1.99)
25/tcp open smtp?
80/tcp open http?
110/tcp open pop3?
111/tcp open rpcbind 2 (rpc #100000)
135/tcp filtered msrpc

# Voici le resultat global du scan. On y voit la liste des ports ouverts, les protocoles associés,
# le service qui tourne sur ces ports, ainsi que la version de ces services.

1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi :

SF-Port80-TCP:V=3.50%D=5/9%Time=409DE7F7%P=i686-pc-windows-windows%r(RTSPR
SF:equest,24B,"HTTP/1\.1\x20400\x20Bad\x20Request\r\nDate:\x20Sun,\x2009\x
SF:20May\x202004\x2008:12:43\x20GMT\r\nServer:\x20Apache1\.3\.29\x20-\x20P
SF:roXad\x20\[Apr\x20\x201\x202004\x2016:04:23\]\r\nConnection:\x20close\r
SF:\nContent-Type:\x20text/html;\x20charset=iso-8859-1\r\n\r\n<!DOCTYPE\x2
SF:0HTML\x20PUBLIC\x20\"-//IETF//DTD\x20HTML\x202\.0//EN\">\n<HTML><HEAD>\
SF:n<TITLE>400\x20Bad\x20Request</TITLE>\n</HEAD><BODY>\n<H1>Bad\x20Reques
SF:t</H1>\nYour\x20browser\x20sent\x20a\x20request\x20that\x20this\x20serv
SF:er\x20could\x20not\x20understand\.<P>\nThe\x20request\x20line\x20contai
SF:ned\x20invalid\x20characters\x20following\x20the\x20protocol\x20string\
SF:.<P>\n<P>\n<HR>\n<ADDRESS><span style="font-weight: bold">Apache1\.3\.29</span>\x20-\x20ProXad\x20\[Apr\x20\x2
SF:01\x202004\x2016:04:22\]\x20Server\x20at\x20cible\.com\x20Port
SF:\x2080</ADDRESS>\n</BODY></HTML>\n");

# Un service lui est inconnu. Dans le cas où l'utilisateur connait ce service, il est
# proposé d'envoyer à la base de données de Insecure l'empreinte relevée par Nmap.
# L'analyse de cette empreinte indique toutefois que la cible utilise sur le port 80 une version HTTP 1.1,
# ainsi qu'un serveur Apache en version 1.3.29. Le probleme est survenu quand le serveur n'a pas pu
# interpreter les paquets qui lui ont été envoyés.

Too many fingerprints match this host to give specific OS details
TCP/IP fingerprint:
SInfo(V=3.50%P=i686-pc-windows-windows%D=5/9%Time=409DE883%O=22%C=1)
T1(Resp=N)
T2(Resp=N)
T3(Resp=N)
T4(Resp=N)
T5(Resp=N)
T6(Resp=N)
T7(Resp=N)
PU(Resp=N)

# Le scan renvoie enfin la prise d'empreinte qui tente de determiner l'OS.
# En fonction du succes ou non des différentes méthodes qu'a utilisé Nmap pour
# determiner cet OS, le resultat est plus ou moins précis.
# voici la description des tests :


# T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT)

# Dans ce test on envoi un paquet SYN avec un paquet d'options a un port ouvert.
# DF=N veut dire que le bit "Don't fragment" (**NDT : Ne pas fragmenter) de la réponse ne doit pas être positionne.
# W=C000|EF2A veut dire que la taille de fenêtre annoncée dans la réponse doit être 0xC000 ou EF2A.
# ACK=S++ veut dire que l'accuse de réception reçu doit être notre numéro de séquence initial plus 1.
# Flags = AS veut dire que les flags ACK et SYN doivent être positionnes dans la réponse.


# T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)

# Le Test 2 implique un NULL avec les mêmes options sur un port ouvert.
# Resp=Y veut dire que l'on doit avoir une réponse.
# Ops= veut dire qu'il ne doit y avoir aucune option inclue dans le paquet de réponse.
# Si on enlevait '%Ops=' alors n'importe quelle(s) option(s) conviendrai(en)t.


# T3(Resp=Y%DF=N%W=400%ACK=S++%Flags=AS%Ops=M)

# Le Test 3 est un SYN|FIN|URG|PSH sans options a un port ouvert.


# T4(DF=N%W=0%ACK=O%Flags=R%Ops=)

# C'est un ACK a un port ouvert. Notez qu'on a pas un Resp= ici. Ce qui signifie qu'une absence de réponse
# (due à une une perte de paquet sur le réseau ou un Firewall hostile) ne disqualifiera pas la reconnaissance
# aussi longtemps que tous les autres tests seront positifs. Nous faisons ca car virtuellement tous les OS enverront
# une réponse, donc une absence de réponse est généralement due aux conditions réseaux et non pas au système d'exploitation
# lui-même.


# T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)
# T6(DF=N%W=0%ACK=O%Flags=R%Ops=)
# T7(DF=N%W=0%ACK=S%Flags=AR%Ops=)

# Ces tests sont respectivement des paquets SYN, ACK, et FIN|PSH|URG sur un port ferme.
# Les mêmes options sont toujours positionnées. Bien sur c'est probablement évident étant donne
# les noms descriptifs 'T5', 'T6', et 'T7'



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

# Celui la est le test du message 'port inaccessible'. Vous devriez reconnaître DF=N maintenant.
# TOS=0 veut dire que le type de service IP a pour valeur 0.
# les 2 champs suivants donnent la valeur hexadécimale des champs IP 'longueur totale' de l'entête des messages
# émis et renvoyés.
# RID=E veut dire que la valeur RID que nous obtenons en retour dans la copie de notre message UDP original
# est celle attendue (c'est dire la même que celle envoyée).
# RPICK=E veut dire qu'on a pas massacre la somme de contrôle (si on voulait que ca soit le cas on aurait écrit RIPCK=F)
# UCK=E veut dire que la somme de contrôle UDP est aussi correcte.
# Ensuite vient la longueur UDP qui est 0x134 et DAT=E veut dire qu'ils ont reproduit les données UDP correctement.






# Nmap run completed at Sun May 09 10:14:59 2004 -- 1 IP address (1 host up) scanned in 496.938 seconds



Au sujet des services que Nmap est capable d'identifier lors de sa prise d'empreinte, ils sont les suivants :
chargen, cvspserver, daytime, domain, echo, exec, finger, font-service, ftp, ftp-proxy,
http, http-proxy, hylafax, ident, ident, imap, imaps, ipp, ircbot, ircd, irc-proxy, issrealsecure,
landesk-rc, ldap, meetingmaker, microsoft-ds, msrpc, mud, mysql, ncacn_http, ncp, netbios-ns, netbios-ssn,
netsaint, netwareip, nntp, nsclient, oracle-tns, pcanywheredata, pop3, pop3s, postgres, printer, qotd, redcarpet,
rlogind, rpc, rsync, rtsp, shell, smtp, snpp, spamd, ssc-agent, ssh, ssl, telnet, time, upnp, uucp, vnc,
vnc-http, webster, whois, winshell, X11 .

La grande différence entre Nmap et un scanner de ports classique, est qu'au lieu de se baser sur une base de données qui dit qu'a chque fois qu'on a affaire a un port 21, c'est du FTP, Nmap analyse réellement
le port en question pour déterminer le service, au cas où le port en question serait utilisé par un service "exotique".


IX. Comportement

Conformement aux lois sur les tentatives d'intrusion, les essais sont effectués sur une machine de test, ou une cible volontaire.



Scan TCP connect


Traffic reseau durant ce scan. Notez que 5 ports sont analysés par seconde, en parallèle.



scan de serveur effectué derriere un firewall. Notez l'optimisation qu'effectue Nmap.


X. La prise d'empreinte

Je pense que l'utilité de déterminer l'OS qui tourne sur un système est assez évidente, c'est pourquoi je ne m'étendrai pas sur ce point.
Un des exemples les plus fort de cette utilité, est que beaucoup de failles de sécurité sont dépendantes d'une version d'OS.
Supposons que vous faites un test de pénétration et que vous trouvez le port 53 ouvert.
Si c'est une version vulnérable de bind, vous avez une seule chance de l'exploiter car un essai infructueux crashera le démon.
Avec un bon "identificateur TCP/IP" (**NDT: traduction de "TCP/IP fingerprinter"), vous trouverez rapidement que cette machine fait tourner 'Solaris 2.51' ou 'Linux 2.0.35' et vous pourrez ajuster votre scriptshell en conséquence.

Encore pire, il est possible de scanner 500 000 machine par avance pour voir quel OS tourne et quels ports sont ouverts. Ensuite quand quelqun poste (par exemple) un exploit du démon comsat de sun pour devenir root, notre petit cracker pourrait faire un grep sur sa liste en cherchant 'UDP/512' et 'Solaris 2.6' et il trouvera immédiatement des pages et des pages de sites ou il pourra être root.
Il devrait être noté que ce comportement ne démontre aucun talent, c'est de l'exploitation pure et simple de scripts, et personne ne sera même légèrement impressionne par le fait que vous avez trouvé un site.edu vulnérable qui n'a pas patché la faille à temps.
De même, les gens seront encore moins impressionné, si vous utilisez votre nouvel accès pour détériorer un site web avec une longue vantardise expliquant comme vous êtes bon et comme l'administrateur système doit être stupide.

Un autre usage possible est l'enginierie social (**NDT : 'Social engineering').
Supposons que vous scannez votre compagnie cible et que NMAP rapporte un 'Datavoice TxPORT PRISM 3000 T1 CSU/DSU 6.22/2.06'.
Le Hacker peut maintenant appeler en se faisant passer pour quelqun du support Datavoice et discuter des particularités de leur PRISM 3000.
"Nous allons annoncer une faille de sécurité bientôt, mais nous voudrions avant que nos clients installent le patch -- Je viens juste de vous l'envoyer par email..."
Certains administrateurs naïfs pourraient croire que seul un ingénieur de Datavoice en connaît autant sur son CSU/DSU.

Un autre usage possible est l'utilisation de cette capacité pour l'évaluation des compagnies avec lesquelles vous souhaitez faire des affaires.
Avant de choisir un nouveau fournisseur de service Internet, scannez le et voyez quel équipement il utilise. Ces affaires à 599F/an ne sembleront plus aussi intéressantes si vous découvrez qu'ils utilisent des routeurs merdiques et offrent des services PPP à partir d'un paquet de machines Windows.


XI. Techniques classiques

L'empreinte de pile résout le problème de l'identification de l'OS d'une manière unique.
Je pense que cette technique est la plus prometteuse, mais il y a actuellement beaucoup d'autres solutions.
Malheureusement, c'est encore une des méthodes les plus efficaces:



playground~ telnet hpux.u-aizu.ac.jp

Trying 163.143.103.12...

Connected to hpux.u-aizu.ac.jp.

Escape character is '^]'.

HP-UX hpux B.10.01 A 9000/715 (ttyp2)

Il n'y a aucun intérêt à s'embarquer dans les complexités de la prise d'empreinte de pile si la machine annonce d'une manière aussi flagrante et précise quel OS tourne.
Malheureusement, beaucoup de vendeurs vendent les systèmes actuels avec ce genre de bannière et beaucoup d'administrateurs ne les désactivent pas.
Ce n'est pas parce que d'autres moyens existent pour deviner quel OS tourne (comme l'empreinte de pile par exemple), qu'il faut annoncer son OS et son architecture à chaque personne essayant de se connecter.

Le problème quand on compte sur ce genre de techniques est qu'un nombre croissant de personnes désactivent ces bannières, de plus beaucoup de systèmes fournissent peu d'information et il est facile de "mentir" dans ses bannières.
Néanmoins, la lecture des bannières est tout ce que vous avez pour vérifier l'OS et sa version si vous dépensez des dizaines de milliers de francs pour un ISS scanner commercial.
Telechargez queso ou nmap a la place et économisez votre argent.

Même si vous désactivez les bannières, beaucoup d'applications donneront gentiment ce genre d'information si on le leur demande. Par exemple regardons un serveur FTP :



payfonez telnet ftp.netscape.com 21

Trying 207.200.74.26...

Connected to ftp.netscape.com.

Escape character is '^]'.

220 ftp29 FTP server (UNIX(r) System V Release 4.0) ready.

SYST

215 UNIX Type: L8 Version: SUNOS




Premièrement, ca nous donne le détail du système dans sa bannière par défaut.
Ensuite si on tape la commande 'SYST' cela nous donnera encore plus d'informations.

Si le FTP anonyme est supporté, nous pourrons souvent télécharger /bin/ls ou un autre fichier binaire et déterminer pour quelle architecture il a été compilé/lié.

Beaucoup d'autres applications sont trop laxistes avec les informations. Prenez les serveurs Web par exemple :



playground echo 'GET / HTTP/1.0\n' | nc hotbot.com 80 | egrep '^Server:'

Server: Microsoft-IIS/4.0


D'autres techniques classiques incluent l'enregistrement d'info DNS (rarement efficace) et l'enginierie sociale.
Si la machine écoute sur le port 161/udp (snmp), vous êtes presque sur d'obtenir un paquet d'info détaillées en utilisant 'snmpwalk' de la distribution d'outils CMU SNMP et le nom de communauté 'public'.


XII. Programmes actuels d'identification

Nmap n'est pas le premier programme de reconnaissance d'OS a utiliser l'identification TCP/IP. Le spoofer IRC sirc de Johan incluait des techniques très rudimentaires d'identification depuis la version 3(ou plus ancienne). Il essaye de placer la machine dans les classes "Linux", "4.4BSD", "Win95", ou "Unknown" en utilisant quelques tests simples sur les flags TCP.

Un autre programme de ce type est checkos, rendu public en janvier de cette année par Shok du groupe CodeZero dans Confidence Remains High numéro 7. Les techniques d'identifications sont exactement les mêmes que dans SIRC, et même le code est identique en plusieurs point. Checkos est disponible en prive depuis un bon moment avant être rendu public, Je n'ai donc pas la moindre idée de qui a recopier le code de qui.
Mais aucun de semble reconnaître s'inspirer de l'autre.
Une chose que checkos ajoute, est la vérification de la bannière telnet, qui est utile mais qui possède les inconvénients décrits plus haut.

Su1d a aussi écrit un programme de vérification d'OS. Son programme s'appelle SS et la version 3.11 peut identifier 12 types d'OS différents. Je suis un peu partial envers ce programme car il me cite pour l'utilisation d'une partie du code réseau
Ensuite il y a queso. Ce programme est le plus récent et marque une grande évolution par rapport aux autres programmes. Non seulement il introduit des tests nouveaux, mais il est aussi le premier (a ma connaissance) a déplacer les empreintes d'OS hors du code.
Les autres scanners incluent du code comme :



/* provenance ss */

if ((flagsfour & TH_RST) && (flagsfour & TH_ACK) && (winfour == 0) &&

(flagsthree & TH_ACK))

reportos(argv[2],argv[3],"Livingston Portmaster ComOS");




A la place, queso déplace ceci dans un fichier de configuration qui convient évidemment mieux et qui rend l'ajout d'un nouvel OS aussi facile qu'ajouter quelques lignes a un fichier d'empreinte.

Queso a été écrit par Savage, qui est de ces gens biens d'Apostols.org.

Un problème est que tous les programmes décrits plus haut sont très limites dans le nombre de tests d'empreinte, ce qui limite la granularité des réponses.
Je voudrais savoir plus que 'Cette machine est OpenBSD, FeeBSD, ou NetBSD', je voudrais savoir quel est le système parmi ceux-la ainsi qu'avoir une idée des numéros de release et de version.
De la même manière, je préférerais voir 'Solaris 2.6' plutôt que simplement 'Solaris'. Pour obtenir cette granularité des réponses, j'ai travaille sur un nombre de techniques de prise d'empreinte qui sont décrites dans la section suivante.


XIII. Méthodologie de la prise d'empreinte

Il y a de nombreuses techniques qui peuvent être utilisées pour prendre une empreinte des piles réseau. A la base, on cherche juste des choses qui diffèrent parmi les OS et on écrit un test pour déterminer la différence.
Si vous combinez assez de ces techniques, vous pouvez déduire les OS d'une manière très fine. Par exemple nmap peut distinguer d'une manière fiable Solaris 2.4 par opposition a Solaris 2.5-2.51 ou Solaris 2.6.
Il peut aussi dire Linux kernel 2.0.30 plutôt que 2.0.31-34 ou 2.0.35.
Voici quelques techniques:

Le test FIN -- La nous envoyons un paquet FIN (ou n'importe quel paquet sans flag ACK ou SYN) a un port ouvert et attendons la réponse. Le comportement conforme à la RFC793 est de ne PAS répondre, mais beaucoup d'implémentations incorrectes comme MS Windows, BSDI, CISCO, HP/UX, MVS et IRIX répondent par un RST. La plupart des outils courants utilisent cette technique.

Le teste du flag BUG -- Queso est le premier scanner que j'ai vu utiliser ce test astucieux. Idée est de positionner un flag "TCP" indéfini '64 ou 128) dans l'en-tête TCP d'un paquet SYN. Les systèmes Linux antérieur au 2.0.35 conservent ce flag positionne dans leur réponse.
Je n'ai trouve aucun autre OS ayant ce bug. Cependant, certains systèmes semblent reseter la connexion quand ils reçoivent un paquet SYN+BUG.
Ce comportement pourrait être utile pour les identifier.

Echantillonnage TCP ISN -- L'idée est ici de trouver les types de nombres de séquence initial (Initial Séquence Number) choisis par les implémentations TCP quand ils répondent à une demande de connexion. Ils peuvent être ranger dans plusieurs groupes comme le traditionnel 64K(beaucoup de vieux Unix), incréments aléatoires (dernier Solaris, IRIX, FreeBSD, Digital UNIX, Cray, et beaucoup d'autres), vraiment aléatoires (Linux 2.0.*, OpenVMS, derniers AIX, etc.). Les systèmes Windows (et quelques autres) utilisent un modèle "dépendant du temps" ou l'ISN est incrémenté d'un petit montant d'une manière périodique. Inutile de dire que c'est aussi facilement "cassable" que la vieille méthode des 64K. Bien sur ma technique favorite est la "constante". la machine utilise TOUJOURS le même ISN. Je l'ai vu sur quelques hubs 3com (utilisent 0x803) et des imprimantes Apple LaserWriter (utilisent 0xC7001).

On peut aussi sous-classer les groupes tels qu'incrément variable par les variantes de calcul, PGCD, et autres fonctions sur l'ensemble des numéros de séquence et les différences entre ces numéros.

Il doit être note que la génération d'ISN a d'importantes implications sur la sécurité. Pour plus de détail sur ce sujet, contactez l"Expert Sécurité" Tsutomu "Shimmy" Shimomura au SDSC et demandez-lui comment il s'est fait hacker.
(**NDT : Référence à l'intrusion de MITNICK par IP spoofing )
Nmap est le premier programme de ma connaissance a utiliser cette technique pour identifier les OS.

Bit "ne pas fragmenter" -- Beaucoup de systèmes d'exploitation commencent par positionner le flag IP "Ne pas fragmenter" sur certains des paquet qu'ils envoient. Cela permet des gains de performance (Mais cela peut aussi être ennuyant -- C'est pourquoi le scan de la fragmentation de nmap ne marche pas à partir de systèmes Solaris). Dans tous les cas, tous les OS ne le font pas et certains le font dans d'autres situations, on peut donc en prêtant attention a ce bit glaner encore plus d'information sur l'OS cible. Je n'ai jamais vu ce test auparavant.

Fenêtre initiale TCP -- Il s'agit juste de vérifier la taille de la fenêtre sur les paquets retournes. Certains vieux scanners utilisent une taille non nulle de fenêtre dans un paquet RST comme identificateur pour un système "Dérivant de BSD 4.4". Les scanners plus récents comme queso et nmap conservent une trace de la taille exacte de la fenêtre car elle est relativement constante suivant les types d'OS. Ce test donne actuellement beaucoup d'informations, car certains OS peuvent être identifies par cette fenêtre seulement (par exemple, AIX est le seul OS de ma connaissance utilisant 0x3F25). Dans leur pile TCP/IP "complètement réécrite" pour NT5, Microsoft utilise 0x402E. Il est intéressant de noter que c'est le même nombre que celui utilise par OpenBSD et FreeBSD.

Valeur ACK -- Bien que vous puissiez penser que c'est complètement standard, les implémentations diffèrent par la valeur utilisée pour le champ ACK dans certains cas. Par exemple, supposons que vous envoyez un FIN|PSH|URG a un port TCP ferme. La plupart des implémentations affecteront au champ ACK la même valeur que votre ISN, cependant, Windows et quelques imprimantes stupides reverront seq+1. Si vous envoyez FIN|PSH|URG a un port ouvert, Windows est très inconsistant. Il renvoi parfois seq d'autres fois il renvoi S++, et d'autres fois il renvoi une valeur visiblement aléatoire.
On peut se demander quel type de code Microsoft écrit pour changer son comportement comme ca.

Extinction des messages erreurs ICMP -- Certains OS (astucieux) suivent la suggestion de la RFC 1812 limitant la vitesse a laquelle divers messages erreurs sont envoyés. Par exemple, le noyau Linux (dans net/ipv4/icmp.h) limite la génération des messages destination inaccessible a 80 par 4 secondes, avec 1/4 de seconde de pénalité en cas de dépassement.
Un moyen de tester ceci est envoyer un lot de paquet a un port haut UDP (choisi aléatoirement) et de compter le nombre de "destination inaccessible" reçus. Je n'ai jamais vu ce procédé utilise auparavant, et en fait je ne l'ai pas ajoute à nmap (excepter pour utilisation dans le scanning de port UDP ).
Ce test rendrait la détection d'OS un peu plus longue comme on doit envoyer un lot de paquets et attendre leur retour. De plus, gérer la possibilité que certains paquets n'arrivent pas serait difficile.

Citation de message ICMP -- Les RFC spécifient qu'un message d'erreur ICMP cite une partie du message ICMP ayant cause les erreurs.
Pour un message port inaccessible, presque toutes les implémentations renvoient seulement l'en-tête IP + 8 octets. Cependant, Solaris renvoi un peu plus et Linux encore un peu plus. La beauté de la chose est que ca autorise Nmap a reconnaître Linux et Solaris mais s'ils n'ont pas de ports à l'écoute.

Intégrité des messages d'erreur ICMP émis -- J'ai eu cette idée grâce à un message de Theo de Raadt (développeur majeur OpenBSD) poste au newsgroup comp.security.unix. Comme il a été dit précédemment, les machines doivent renvoyer une partie du message original avec un message port inaccessible. Actuellement certaines machines utilisent les en-têtes comme espace de travail pendant le traitement initial, et ces en-têtes sont donc un peu altérés quand ils les renvoient.
Par exemple AIX et BSDI renvoient un champ IP 'taille totale' trop grand de 20 octets. Certains BSDI, FreeBSD, OpenBSD, ULTRIX et VAX bousillent l'ID IP qu'on leur envoi. Alors que la somme de contrôle va changer a cause de la modification du champ TTL (**NDT : Champ Time To Live), il y a certaines machines (AIX, FreeBSD, etc.) qui renvoient une somme de contrôle inconsistante ou nulle. On constate la même chose avec les sommes de contrôles UDP. L'un dans l'autre, Nmap fait 9 tests différents sur les erreurs ICMP pour détecter les subtiles différences de ce type.

Type de service -- Pour les messages ICMP port inaccessible j'ai regarde la valeur du Type de service (TOS) du paquet retourne. Presque toutes les implémentations utilisent 0 pour les erreurs ICMP cependant Linux utilise 0xC0. Cela n'indique pas une des valeurs standards du TOS, mais est plutôt une partie du champ de préséance inutilisé (pour autant que je sache). Je ne sais pas pourquoi il est positionne, mais s'il change cette valeur en 0, nous serons capable d'identifier les vieilles versions ET nous serons capable de distinguer entre l'ancienne et la nouvelle.

Gestion de la fragmentation -- C'est la technique favorite de Thomas H. Ptacek de Secure Networks, Inc (maintenant détenue par un groupe d'utilisateurs de Windows au NAI). Elle prend avantage du fait que différentes implémentations gèrent souvent différemment les fragments IP se recouvrant. Certains recouvrent la vieille partie avec la nouvelle dans d'autres cas c'est la vieille partie qui prédomine.
Il y a beaucoup de tests différents qu'on peut utiliser pour déterminer comment le paquet a été réassemblé. Je n'ai pas ajoute cette capacité car je ne connais pas de manière portable d'envoyer des paquets fragmentes (C'est particulièrement dur sous Solaris). Pour plus d'information sur les fragments se recouvrant, vous pouvez lire leur article(www.secnet.com).

Options TCP -- Elles sont vraiment une mine d'or en terme de source d'information. CE qu'il y a de bien avec les options est :
1) Elles sont en général optionnelles ce qui fait que toutes
les machines ne les implémentent pas.
2) On sait si une machine les implémente en envoyant une demande
avec une option positionnée. La cible montre généralement qu'elle
supporte l'option en la positionnant dans sa réponse.
3) On peut positionner tout un tas d'options dans un paquet pour tout
tester en une seule fois.
Nmap envoi ces options avec quasiment tous les paquets de test:




Window Scale=10; NOP; Max Segment Size = 265; Timestamp; End of Ops;


Quand on obtient une réponse, on regarde quelles options sont retournées et donc supportées. Certains OS comme les machines BSD récentes supportent toutes celles positionnées plus haut, alors que d'autres comme Linux 2.0.x en supportent très peu. Les derniers noyaux Linux 2.1.x supportent tous ceux définis plus haut. En contrepartie ils sont plus vulnérables a la prédiction du numéro de séquence TCP.
Go figure.

Même si plusieurs OS supportent le même ensemble d'options, on peut parfois les distinguer par la VALEUR de ces options. Par exemple, si on envoi une petite valeur MSS a une machine Linux, elle répondra généralement par cette même valeur. d'autres machines retourneront des valeurs différentes.

Et même si on obtient le même ensemble d'options supportées ET les mêmes valeurs, on peut encore faire une différence via l'ORDRE dans lequel les options sont données

XIV. Nmap sous windows

Pour les irreductibles qui veulent absolument travailler sous windows,
avec une interface graphique, et le dernier moteur Nmap, et utiliser quand meme
un scanner rapide de type superscan (les casse pieds, quoi),
il existe une solution miracle !

Commencez par télécharger le scanner IPSCAN
Dans un deuxieme temps, il va falloir parametrer ce logiciel pour qu'il discute avec Nmap...

Ouvrez Command--Open Computer--Configure
Dans la fenetre qui s'affiche, donner un nom à cette nouvelle fonction,
le chemin d'acces complet de Nmap,la ligne de commande complete du scan a effectuer,
avec l'IP en variable notée %s




Exemple : c:\nmap\nmap -v -v -T4 -A -sT -F -P0 %s
Effectuera pour chaque Ip selectionnée sous IPSCAN un appel a Nmap qui lancera un scan
type TCP connect avec detection de services, sans ping sur la cible.

A vous d'essayer les commandes les plus efficaces selon les cibles, et de les programmer
sous IPSCAN, puis les appeler par un simple clic droit sur chaque résultat de scan lorsque
IPSCAN a fini son travail.

Exemple sur un serveur :

4N9e pour FutureZone, 2004