Cet article décrit comment glaner de précieuses informations sur un serveur en interrogeant sa pile TCP/IP. Je présenterai d'abord les méthodes "classiques" pour déterminer l'OS d'un serveur sans utiliser "la prise d'empreinte de pile".

(** NDT : le terme original est "stack fingerprinting" **)

  Ensuite je décrirai "l'état de l'art" actuel en matière d'outils de prise d'empreinte de pile.

  Puis viendra une description de plusieurs techniques obligeant un serveur à divulguer des informations sur lui-même.

  Pour finir, je détaillerai mon (NMAP) implémentation de ces techniques, suivi par quelques instantanés obtenus avec NMAP informant quel OS tourne sur plusieurs sites Internet célèbres.

Objectifs

  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.

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 ...

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

Escape character is '^]'.

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

login:

  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 ...

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

playground

 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'.

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 estSD, 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.

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.*,MS, 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 parSD 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 majeurSD) 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,SD, 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. Par exemple Solaris retourne 'NNTNWME' qui veut dire:

  Quand Linux 2.1.122 retourne MENNTNW. Même options, même valeurs mais un ordre diffèrent !

  Je n'ai vu aucun autre outil de détection d'OS utiliser les options TCP, bien qu'elles soient très utiles.

Il y a quelques autres options que je pourrais tester à un moment, comme celles supportant T/TCP et accuse de réception sélectif (***NDT : 'selective acknowledgements')

   Chronologie des exploits -- Même avec tous les tests vus plus haut, nmap est incapable de distinguer les piles TCP de Win95, WinNT ou Win98.

C'est plutôt surprenant, particulièrement quand on sait que Win98 est sorti 4 ans après Win95. On pourrait penser qu'il se serait soucie d'améliorer un peu leur pile (comme par exemple en supportant plus d'options TCP) et cela nous aurais permis de détecter les changements et donc distinguer les OS. Malheureusement ce n'est pas le cas. La pile NT est apparemment la vieille pile merdique qu'ils ont mis dans '95'. Et ils ne sont pas embeter a l'améliorer pour '98'.

Mais ne perdons pas espoir, car il y a une solution. On peut simplement commencer avec les premières attaques de privations de services (**NDT : pour 'DOS attack'='Denial Of Services") contre Windows (Ping of Death, Winnuke, etc. )et évoluer vers des attaques plus avancées comme Teardrop et Land. Apres chaque attaque on les teste pour voir s'ils ont plante.

Quand vous les planterez finalement, vous serez à même de déterminer ce qu'ils utilisent au service pack ou patch prés.

  Je n'ai pas rajouté cette fonctionnalité a Nmap, cependant je dois admettre que c'est très tentant :).

   Résistance au SYN flood -- Certains systèmes d'exploitation arrêterons d'accepter de nouvelles connections si on leur envoi trop de paquet SYN contrefait( les paquets contrefaits évitent les ennuis tel que le noyau reinitialisant les connections). Beaucoup de systèmes d'exploitation géreront uniquement 8 paquets. Les noyaux Linux récents (parmi d'autres OS) autorisent plusieurs méthodes comme les cookies SYN empêchant cela de devenir un problème sérieux. Ainsi on peut apprendre quelquechose sur l'OS cible en envoyant 8 paquets d'une source modifiée (**NDT : C'est ma deuxième tentative pour traduire la notion de 'forged packet' traduit plus haut par 'paquet contrefait' apparemment il veut parler de paquet bricolé à la main avec une IP source modifiée) a un port ouvert et tester ensuite si on peut établir une connexion sur ce port. Cela n'a pas été implémenté dans Nmap car certaines personnes n'apprécient pas de subir un SYN flood. Même expliquer que vous essayer seulement de déterminer quel Os ils utilisent pourrait ne pas être suffisant pour les calmer.

IMPLEMENTATION DE NMAP ET RESULTATS

  J'ai créé une implémentation de référence pour les techniques de détection d'OS mentionnées plus haut (excepte celles que j'ai dit que j'excluais).

Je lai ajoute a mon scanner NMAP qui a l'avantage de déjà savoir quels ports sont ouverts ou fermes pour la prise d'empreinte (on a donc pas a lui dire).

Il est aussi portable sur Linux, *BSD, et Solaris 2.51 et 2.6 et quelques autres systèmes d'exploitation.

  La nouvelle version de Nmap lit un fichier contenant des types d'empreintes de pile qui suivent une grammaire simple. Voici un exemple :

FingerPrint  IRIX 6.2 - 6.4 # Merci a Lamont Granquist

TSeq(Class=i800)

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

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

T3(Resp=Y%DF=N%W=C000|EF2A%ACK=O%Flags=A%Ops=NNT)

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

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=)

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

Regardons la première ligne (J'ajoute '' comme marqueur de citation):

 FingerPrint  IRIX 6.2 - 6.3 # Merci a Lamont Granquist

  Cela dit simplement que l'empreinte de pile couvre la version IRIX version 6.2 a 6.4 et le commentaire précise que Lamont Grandquist m'a gentiment envoyé l'adresse IP ou l'empreinte de la machine IRIX testée.

    TSeq(Class=i800)

  Cela veut dire que l'ISN a été classe dans "la classe i800". Ce qui veut dire que chaque nouveau numéro de séquence est plus grand d'un multiple de 800 que le précédant.

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

  Le test est nomme T1 (pour test1, intelligent non ?). 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.

Ops = MNWNNT veut dire que les options de la réponse doivent être (dans cet ordre):

 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. Nous mettons le marqueur 'Resp' dans les tests 2 et 3 parce que certains OS ne répondent PAS !

 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 (**NDT : J'ai hésité a traduire 'this big sucker' littéralement ;) est le test du message 'port inaccessible'. Vous devriez reconnaître ld 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. Comme la plupart des implémentations (celle ci inclue) ne renvoient pas les données UDP, ils ont DAT=E par défaut.

  La version de Nmap avec cette fonctionnalité est actuellement dans son 6° cycle de bêta privée. Elle pourrait être disponible au moment ou vous lirez cet article dans Phrack. Mais encore une fois, elle pourrait ne pas être. Voyez http://www.insecure.org/nmap/ pour la dernière version. 

By Fyodor