Note Du Traducteur : Cette traduction n'est pas parfaite (loin s'en faut) et
je suis ouvert à toute remarque/correction/encouragement (arhuman@francemel.fr...)
Vous pouvez modifier/distribuer cette traduction pour peu que vous citiez mon nom
ainsi que celui de Galaad pour la traduction.
Mais d'abord quelques Rappels :
en-tete IP (IP HEADER)
_______________________________________________________________
|version|long. en-tete|TOS | longueur totale | \
|4bit | 4bit | 8bit | 16bit | |
|_______________________________________________________________| |
| |flags| decalage de fragment | |
| 16bit |3bit | 13bit | |
|_______________________________________________________________| |
| TTL | protocol | somme de controle de l'entete | | 20 octets
| 8bit | 8bit | 16bit | |
|_______________________________________________________________| |
| adresse IP source | |
| 32bit | |
|_______________________________________________________________| |
| adresse IP destination | |
| 32bit | /
|_______________________________________________________________|
| options(s'il y en a) | taille variable
|_______________________________________________________________|
| donnees | taille variable
|_______________________________________________________________|
en-tete TCP
_______________________________________________________________
| port source | port destination | \
| 16bit | 16bit | |
|_______________________________________________________________| |
| numero de sequence | |
| 32bit | |
|_______________________________________________________________| |
| numero d'acquittement | |
| 32bit | |
|_______________________________________________________________| |
|long. entete| reserve| FLAG* | taille de fenetre | | 20 octets
| 4bit | 6bit | 6bit | 16bit | |
|_______________________________________________________________| |
| somme de controle TCP | pointeur urgent | |
| 16bit | 16bit | |
|_______________________________________________________________| /
| options(s'il y en a) | taille variable
|_______________________________________________________________|
| donnees('il y en a) | taille variable
|_______________________________________________________________|
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 par la poignee de main a 3 etapes(3-way handshake,
generalement traduit par la poignee de main a 3 voies...)
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 ca 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 dit je laisse la parole à fyodor :
----[ Résumé
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) 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 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 playground Hmmm ... Je me demande quel OS ces lamers utilisent. |
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 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.
----[ 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 (util
isent 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;
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
TSeq(Class=i800)
T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT)
|
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)
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=) |
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)
|
www.l0pht.com |
= OpenBSD 2.2 - 2.4 |
|
www.repsec.com |
= Linux 2.0.35 |
|
www.li.org |
= Linux 2.0.35 # Linux International |
|
www.harvard.edu |
= Solaris 2.6 |
|
# écoles semblent aimer SUN? |
|
|
= UNIX OSF1 V 4.0,4.0B,4.0D |
|
= IRIX 6.2 - 6.4 # On ne se demande plus pourquoi ils sont si insécurisés :) |
|
|
# Même l'OS le plus sur est |
|
www.lwn.net |
= Linux 2.0.31-34 # Ce nouveau site Linux est géant! |
Notes: Dans leur White paper sur la sécurité, Microsoft dit au sujet de sécurité laxiste : "Cet état de fait a change ces dernières années comme Windows NT gagnait en popularité largement à cause de ces possibilités en matière de sécurité.".
Hmm, d'où je suis, il ne me semble pas que windows soit très populaire dans la communauté de la sécurité :) .
Je vois seulement 2 machines Windows dans l'ensemble du groupe, et Windows est _Facile_ a distinguer pour Nmap à cause de ses défauts.
Et bien sur, il y a un site de plus que nous devons vérifier. C'est le site web de l'ultra-secrète société Transmeta. Il est intéressant de noter que cette compagnie a été fondée par Paul Allen de Microsoft, mais emploi Linus Torvalds.
Donc, sont ils plutôt Paul et utilisent NT ou sont ils du côté des rebelles et et rejoignent la révolution Linux ? Voyons voir :
Nous utilisons la commande :
nmap -sS -F -o transmeta.log -v -O www.transmeta.com/24
|
neon-best.transmeta.com (206.184.214.10) |
= Linux 2.0.33-34 |
Bon, je crois que ca répond à notre question plutôt clairement :) .
----[ REMERCIEMENTS
La seule raison pour laquelle Nmap est actuellement capable de détecter autant de systèmes d'exploitations est que beaucoup de personnes dans l'équipe de la bêta privée ont dépensé beaucoup d'effort a chercher de nouvelles et excitantes machines pour prendre leur empreinte ! En particulier Jan Koum, van Hauser, Dmess0r, David O'Brien, James W. Abendschan, Solar Designer, Chris Wilson, Stuart Stock, Mea Culpa, Lamont Granquist, Dr. Who, Jordan Ritter, Brett Eldridge, et Pluvius ont envoyés des tonnes d'adresses IP de machines et/ou d'empreintes de machines inaccessibles par Internet.
Merci a Richard Stallman d'avoir écrit GNU Emacs. Cet article n'aurait pas été si bien formaté si j'avais utilise vi ou cat et ^D.
(**NDT : Effectivement l'article était particulièrement bien présenté avant que je ne massacre la mise en page avec WordPad :( )
Questions et commentaires peuvent être envoyés à fyodor@DHP.com (si ca ne marche pas pour une raison quelconque, utiliser fyodor@insecure.org). Nmap peut être obtenu à http://www.insecure.org/nmap