Tweet
NMAP est la référence en matière de scanner.
LES BASES DU SCAN DE PORTS
Même si le nombre de fonctionnalités de Nmap a considérablement augmenté au fil des ans, il reste un scanner de ports efficace, et cela reste sa fonction principale. La commande de base nmap target scanne plus de 1 660 ports TCP de l'hôte target.
Alors que de nombreux autres scanners de ports ont partitionné les états des ports en ouverts ou fermés, Nmap a une granularité bien plus fine. Il divise les ports selon six états: ouvert (open), fermé (closed), filtré (filtered), non-filtré (unfiltered), ouvert|filtré (open|filtered), et fermé|filtré (closed|filtered).
Ces états ne font pas partie des propriétés intrinsèques des ports eux-mêmes, mais décrivent comment Nmap les perçoit. Par exemple, un scan Nmap depuis le même réseau que la cible pourrait voir le port 135/tcp comme ouvert alors qu'un scan au même instant avec les mêmes options au travers d'Internet pourrait voir ce même port comme filtré.
LES SIX ÉTATS DE PORT RECONNUS PAR NMAP
ouvert (open) :
Une application accepte des connexions TCP ou des paquets UDP sur ce port. Trouver de tels ports est souvent le but principal du scan de ports. Les gens soucieux de la sécurité savent pertinemment que chaque port ouvert est un boulevard pour une attaque. Les attaquants et les pen-testers veulent exploiter ces ports ouverts, tandis que les administrateurs essaient de les fermer ou de les protéger avec des pare-feux sans gêner leurs utilisateurs légitimes. Les ports ouverts sont également intéressants pour des scans autres que ceux orientés vers la sécurité car ils indiquent les services disponibles sur le réseau.
fermé (closed) :
Un port fermé est accessible (il reçoit et répond aux paquets émis par Nmap), mais il n'y a pas d'application en écoute. Ceci peut s'avérer utile pour montrer qu'un hôte est actif (découverte d'hôtes ou scan ping), ou pour la détection de l'OS. Comme un port fermé est accessible, il peut être intéressant de le scanner de nouveau plus tard au cas où il s'ouvrirait. Les administrateurs pourraient désirer bloquer de tels ports avec un pare-feu, mais ils apparaîtraient alors dans l'état filtré décrit dans la section suivante.
filtré (filtered) :
Nmap ne peut pas toujours déterminer si un port est ouvert car les dispositifs de filtrage des paquets empêchent les paquets de tests (probes) d'atteindre leur port cible. Le dispositif de filtrage peut être un pare-feu dédié, des règles de routeurs filtrants ou un pare-feu logiciel. Ces ports ennuient les attaquants car ils ne fournissent que très peu d'informations. Quelques fois ils répondent avec un message d'erreur ICMP de type 3 code 13 (« destination unreachable: communication administratively prohibited »), mais les dispositifs de filtrage qui rejettent les paquets sans rien répondre sont bien plus courants. Ceci oblige Nmap à essayer plusieurs fois au cas où ces paquets de tests seraient rejetés à cause d'une surcharge du réseau et pas du filtrage. Ceci ralenti terriblement les choses.
non-filtré (unfiltered) :
L'état non-filtré signifie qu'un port est accessible, mais que Nmap est incapable de déterminer s'il est ouvert ou fermé. Seul le scan ACK, qui est utilisé pour déterminer les règles des pare-feux, catégorise les ports dans cet état. Scanner des ports non-filtrés avec un autre type de scan, comme le scan Windows, SYN ou FIN peut aider à savoir si un port est ouvert ou pas.
ouvert|filtré (open|filtered) :
Nmap met dans cet état les ports dont il est incapable de déterminer l'état entre ouvert et filtré. Ceci arrive pour les types de scans où les ports ouverts ne renvoient pas de réponse. L'absence de réponse peut aussi signifier qu'un dispositif de filtrage des paquets a rejeté le test ou les réponses attendues. Ainsi, Nmap ne peut s'assurer ni que le port est ouvert, ni qu'il est filtré. Les scans UDP, protocole IP, FIN, Null et Xmas catégorisent les ports ainsi.
fermé|filtré (closed|filtered) :
Cet état est utilisé quand Nmap est incapable de déterminer si un port est fermé ou filtré. Cet état est seulement utilisé par le scan Idle basé sur les identifiants de paquets IP.
LES TECHNIQUES DU SCAN DE PORTS
La plupart des types de scans ne sont disponibles que pour les utilisateurs privilégiés. Ceci est dû au fait qu'ils émettent et reçoivent des paquets bruts (raw), qui nécessitent les droits root sur les systèmes UNIX. L'utilisation d'un compte administrateur est conseillé sous Windows, bien que Nmap puisse fonctionner avec des utilisateurs non-privilégiés si WinPcap est déjà chargé avec l'OS. Ce besoin des droits root était une sérieuse restriction quand Nmap a été diffusé en 1997, car beaucoup d'utilisateurs avaient seulement accès à des comptes Internet partagés. Maintenant, le monde est différent. Les ordinateurs sont moins chers, bien plus de gens disposent d'un accès 24/24 direct à Internet et les systèmes UNIX de bureau (comme Linux et Mac OS X) sont répandus. Une version Windows de Nmap est désormais disponible, permettant ainsi de le lancer sur encore plus de machines. Pour toutes ces raisons, les utilisateurs ont bien moins besoin de lancer Nmap depuis des comptes Internet limités. Ceci est heureux, car les options privilégiés rendent Nmap bien plus puissant et flexible.
Si Nmap essaie de produire des résultats précis, il faut garder à l'esprit que toute sa perspicacité est basée sur les paquets renvoyés par les machines cibles (ou les pare-feux qui les protègent). De tels hôtes ne sont pas toujours dignes de confiance et peuvent répondre dans le but de brouiller ou d'enduire Nmap d'erreurs. Les hôtes qui ne respectent pas les RFCs et ne répondent pas comme ils devraient sont encore plus courants. Les scans FIN, Null et Xmas sont les plus sensibles à ce problème. Ces points sont spécifiques à certains types de scan et sont donc abordés dans leur section propre de la documentation.
Cette section documente la douzaine de techniques de scan de ports gérées par Nmap. Les méthodes ne peuvent pas être utilisés simultanément, excepté le scan UDP (-sU) qui peut être combiné avec chacun des types de scan TCP. A titre d'aide mémoire, les options de type de scan sont de la forme -sC, où Cest un caractère prépondérant dans le nom du scan, souvent le premier. La seule exception est le désuet scan par rebond FTP (-b). Par défaut, Nmap effectue un scan SYN, bien qu'il y substitue un scan connect() si l'utilisateur ne dispose pas des droits suffisants pour envoyer des paquets bruts (qui requièrent les droits root sous UNIX) ou si des cibles IPv6 sont spécifiées. Des scans listés dans cette section, les utilisateurs non-privilégiés peuvent seulement exécuter les scans connect() et le scan par rebond FTP.
-sS (Scan TCP SYN)
Le scan SYN est celui par défaut et le plus populaire pour de bonnes raisons. Il peut être exécuté rapidement et scanner des milliers de ports par seconde sur un réseau rapide lorsqu'il n'est pas entravé par des pare-feux. Le scan SYN est relativement discret et furtif, vu qu'il ne termine jamais les connexions TCP. Il marche également contre toute pile respectant TCP, au lieu de dépendre des particularités environnementales spécifiques comme les scans Fin/Null/Xmas, Maimon ou Idle le sont. Il permet de plus une différentiation fiable entre les états ouvert, fermé et filtré.
Cette technique est souvent appelée le scan demi-ouvert (half-open scanning), car il n'établi pas pleinement la connexion TCP. Il envoie un paquet SYN et attend sa réponse, comme s'il voulait vraiment ouvrir une connexion. Une réponse SYN/ACK indique que le port est en écoute (ouvert), tandis qu'une RST (reset) indique le contraire. Si aucune réponse n'est reçue après plusieurs essais, le port est considéré comme étant filtré. Le port l'est également si un message d'erreur « unreachable ICMP (type 3, code 1,2, 3, 9, 10 ou 13) » est reçu.
-sT (Scan TCP connect())
Le scan TCP connect() est le type de scan par défaut quand le SYN n'est pas utilisable. Tel est le cas lorsque l'utilisateur n'a pas les privilèges pour les paquets bruts (raw packets) ou lors d'un scan de réseaux IPv6. Plutôt que d'écrire des paquets bruts comme le font la plupart des autres types de scan, Nmap demande au système d'exploitation qui l'exécute d'établir une connexion au port de la machine cible grâce à l'appel système connect(). C'est le même appel système haut-niveau qui est appelé par les navigateurs Web, les clients P2P et la plupart des applications réseaux qui veulent établir une connexion. Cet appel fait partie de l'interface d'application connue sous le nom de « Berkeley Sockets API ». Au lieu de lire les réponses brutes sur le support physique, Nmap utilise cette application API pour obtenir l'état de chaque tentative de connexion.
Si le scan SYN est disponible, il vaut mieux l'utiliser. Nmap a bien moins de contrôles sur l'appel système haut niveau connect() que sur les paquets bruts, ce qui le rend moins efficace. L'appel système complète les connexions ouvertes sur les ports cibles au lieu de les annuler lorsque la connexion est à demie ouverte, comme le fait le scan SYN. Non seulement c'est plus long et demande plus de paquets pour obtenir la même information, mais de plus la probabilité que les cibles activent la connexion est plus grande. Un IDS décent le fera, mais la plupart des machines ne disposent pas de ce système d'alarme. De nombreux services sur les systèmes UNIX standards noteront cette connexion dans le journal, accompagné d'un message d'erreur sibyllin si Nmap ouvre puis referme la connexion sans n'envoyer aucune donnée. Les services réseaux les plus piteux risquent même de tomber en panne, mais c'est assez rare. Un administrateur qui verrait un tas de tentatives de connexions dans ses journaux en provenance d'une seule machine devrait se rendre compte qu'il a été scanné.
-sU (Scan UDP)
Même si les services les plus connus d'Internet son basés sur le protocole TCP, les services UDP sont aussi largement utilisés. DNS, SNMP ou DHCP (ports 53, 161/162 et 67/68) sont les trois exemples les plus courants. Comme le scan UDP est généralement plus lent et plus difficile que TCP, certains auditeurs de sécurité les ignorent. C'est une erreur, car les services UDP exploitables sont courants et les attaquants eux ne les ignoreront pas. Par chance, Nmap peut aider à répertorier les ports UDP.
Le scan UDP est activé avec l'option-sU. Il peut être combiné avec un scan TCP, comme le scan SYN ( -sS), pour vérifier les deux protocoles lors de la même exécution de Nmap.
Le scan UDP envoie un en-tête UDP (sans données) à chaque port visé. Si un message ICMP « port unreachable (type 3, code 3) » est renvoyé, le port est alors fermé. Les autres messages d'erreur « unreachable ICMP (type 3, codes 1, 2, 9, 10, or 13) » rendront le port filtré. À l'occasion, il arrive qu'un service répond par un paquet UDP, prouvant que le port est dans l'état ouvert. Si aucune réponse n'est renvoyée après plusieurs essais, le port est considéré comme étant ouvert|filtré. Cela signifie que le port peut être soit ouvert, soit qu'un dispositif de filtrage bloque les communications. Le scan de versions ( -sV) peut être utilisé pour différencier les ports ouverts de ceux filtrés.
Une des grandes difficultés avec le scan UDP est de l'exécuter rapidement. Les ports ouverts et filtrés ne renvoient que rarement des réponses, laissant Nmap expirer son délai de retransmission au cas où les paquets se soient perdus. Les ports fermés posent encore un plus grand problème: ils renvoient normalement une erreur ICMP « port unreachable ». Mais à la différence des paquets RST renvoyés par les ports TCP fermés en réponse à un scan SYN ou à un connect(), de nombreux hôtes limitent par défaut la cadence d'émission de ces messages. Linux et Solaris étant particulièrement stricts à ce sujet. Par exemple, le kernel 2.4.20 limite cette cadence des destinations inaccessibles (« destination unreachable ») à un par seconde (cf.net/ipv4/icmp.c).
Nmap détecte cette limitation de fréquence et s'y ralenti conformément afin d'éviter de saturer le réseau avec des paquets inutiles que la machine cible rejettera. Malheureusement, une limitation à la Linux d'un paquet par seconde fera qu'un scan des 65 536 ports prendra plus de 18 heures. Les idées pour accélérer les scans UDP incluent le scan des cibles en parallèle, ne scanner que les ports les plus courants en premier, scanner derrière le pare-feu et utiliser l'option --host-timeoutpour éviter les hôtes les plus lents.
-sN -sF -sX (Scans TCP Null, FIN et Xmas)
Ces trois types de scans (d'autres sont possibles en utilisant l'option --scanflags décrite dans la section suivante) exploitent une subtile faille de la RFC TCP pour différencier les ports entre ouverts et fermés. La page 65 indique que si le port [de destination] est dans l'état fermé... un segment ne contenant pas le drapeau RST provoque l'émission d'un paquet RST comme réponse. La page suivante indique que pour les paquets envoyés à des ports sans aucun des drapeaux SYN, RST ou ACK activés: il est peut vraisemblable que cela arrive, mais si cela est le cas, il faut rejeter le segment.
Pour les systèmes respectant ce texte de la RFC, chaque paquet ne contenant ni SYN, ni RST, ni ACK se voit renvoyé un RST si le port est fermé et aucune réponse si le port est ouvert. Tant qu'aucun de ces drapeaux n'est utilisé, toute combinaison des trois autres (FIN, PSH et URG) son valides. Nmap exploite cela avec les trois types de scans:
Scan Null (-sN) : N'active aucun des bits (les drapeaux de l'en-tête TCP vaut 0).
Scan FIN (-sF) : N'active que le bit FIN.
Scan Xmas (-sX) : Active les drapeaux FIN, PSH et URG, illuminant le paquet comme un arbre de Noël (NDT: la fracture cognitive entre la culture anglo-saxonne et française se ressent fortement dans cette traduction...).
Ces trois types de scan ont exactement le même comportement, sauf pour les drapeaux TCP utilisés dans des paquets de tests (probes packets). Si un RST est reçu, le port est considéré comme étant fermé, tandis qu'une absence de réponse signifiera qu'il est dans l'état ouvert|filtré. Le port est marqué comme filtré si un message d'erreur ICMP « unreachable (type 3, code 1, 2, 3, 9, 10 ou 13) » est reçu.
L'avantage principal de ces types de scans est qu'ils peuvent furtivement traverser certains pare-feux ou routeurs filtrants sans état de connexion (non-statefull). Un autre avantage est qu'ils sont même un peu plus furtifs que le scan SYN. N'y comptez pas trop dessus cependant -- la plupart des IDS modernes sont configurés pour les détecter. L'inconvénient majeur est que tous les systèmes ne respectent pas la RFC 793 à la lettre. Plusieurs systèmes renvoient des RST aux paquets quelque soit l'état du port de destination, qu'il soit ouvert ou pas. Ceci fait que tous les ports sont considérés commefermé. Les plus connus des systèmes qui ont ce comportement sont Microsoft Windows, plusieurs équipements Cisco, BSDI et IBM OS/400. Ce type de scan fonctionne cependant très bien contre la plupart des systèmes basés sur UNIX. Un autre désagrément de ce type de scan et qu'ils ne peuvent pas distinguer les ports ouvertsde certains autres qui sont filtrés, vous laissant face à un laconique ouvert|filtré.
-sA (Scan TCP ACK)
Ce type de scan est différent des autres abordés jusqu'ici, dans le sens où ils ne peuvent pas déterminer si un port est ouvert(ni même ouvert|filtré). Il est utilisé pour établir les règles des pare-feux, déterminant s'ils sont avec ou sans états (statefull/stateless) et quels ports sont filtrés.
Le scan ACK n'active que le drapeau ACK des paquets (à moins que vous n'utilisiez l'option --scanflags). Les systèmes non-filtrés réagissent en retournant un paquet RST. Nmap considère alors le port comme non-filtré, signifiant qu'il est accessible avec un paquet ACK, mais sans savoir s'il est réellement ouvert ou fermé. Les ports qui ne répondent pas ou renvoient certains messages d'erreur ICMP (type 3, code 1, 2, 3, 9, 10, ou 13), sont considérés comme filtrés.
-sW (Scan de fenêtre TCP)
Le scan de fenêtre TCP est exactement le même que le scan ACK à la différence près qu'il exploite un détail de l'implémentation de certains systèmes pour identifier les ports fermés des autres, au lieu de toujours afficher non-filtrélorsqu'un RST est renvoyé. Sur certains systèmes, les ports ouverts utilisent une taille de fenêtre TCP positive (même pour les paquets RST), tandis que les ports fermés ont une fenêtre de taille nulle. Ainsi, au lieu de toujours afficher non-filtré lorsqu'un RST est reçu, le scan de fenêtre indique que le port est ouvert ou fermé selon que la taille de fenêtre TCP de ce paquet RST est respectivement positive ou nulle.
Ce scan repose sur un détail d'implémentation d'une minorité de systèmes Internet, vous ne pouvez donc pas toujours vous y fier. Les systèmes qui ne le supportent pas vont certainement se voir considérés leurs ports comme fermés. Bien sûr, il se peut que la machine n'ait effectivement aucun port ouvert. Si la plupart des ports scannés sont fermés mais que quelques-uns courants, comme le 22, 25 ou le 53, sont filtrés, le système est vraisemblablement prédisposé à ce type de scan. Quelquefois, les systèmes ont le comportement exactement inverse. Si votre scan indique que 1 000 ports sont ouverts et que 3 seulement sont fermés ou filtrés, ces trois derniers sont certainement ceux qui sont ouverts.
-sM (Scan TCP Maimon)
Le scan Maimon est nommé ainsi d'après celui qui l'a découvert, Uriel Maimon. Il a décrit cette technique dans le numéro 49 de Phrack Magazine (Novembre 1996). Nmap, qui inclut cette technique, a été publié deux numéros plus tard. Cette technique est la même que les scans NUll, FIN et Xmas, à la différence près que le paquet de test est ici un FIN/ACK. Conformément à la RFC 793 (TCP), un paquet RST devrait être renvoyé comme réponse à un tel paquet, et ce, que le port soit ouvert ou non. Uriel a cependant remarqué que de nombreux systèmes basés sur BSD rejettent tout bonnement le paquet si le port est ouvert.
--scanflags (Scan TCP personnalisé)
Les utilisateurs réellement experts de Nmap ne veulent pas se limiter aux seuls types de scans proposés. L'option --scanflagsvous permet de créer votre propre type de scan en spécifiant vos propres combinaisons de drapeaux TCP. Laisser courir votre imagination, tout en contournant les systèmes de détection d'intrusion dont les vendeurs n'ont fait qu'ajouter des règles spécifiques d'après la documentation Nmap!
L'argument de l'option --scanflags peut être soit un nombre comme 9 (PSH et FIN), mais l'utilisation des noms symboliques est plus facile. Mélanger simplement les drapeaux URG, ACK, PSH, RST, SYN et FIN. Par exemple, --scanflags URGACKPSHRSTSYNFIN les activent tous, bien que cela ne soit pas très utile pour effectuer un scan. L'ordre dans lequel les drapeaux sont spécifiés n'a pas d'importance.
En sus de la spécification des drapeaux désirés, vous pouvez spécifier également un type de scan TCP (comme -sA ou -sF). Ce type de scan de base indique à Nmap comment interpréter les réponses. Par exemple, un scan SYN considère que l'absence de réponse indique qu'un port est filtré, tandis qu'un scan FIN considèrera la même absence comme un port ouvert|filtré. Nmap se comportera de la même façon que le type de scan de base, à la différence près qu'il utilisera les drapeaux TCP que vous avez spécifié à la place. Si vous n'en spécifiez pas, le type de scan SYN par défaut sera utilisé.
-sI <zombie host[
robeport]> (Scan paresseux -- idlescan)
Cette méthode de scan avancé permet de faire un véritable scan de port TCP en aveugle, (dans le sens où aucun paquet n'est envoyé directement à la cible depuis votre vraie adresse IP). En effet, la technique employée consiste à récolter des informations sur les ports ouverts de la cible en utilisant un exploit basé sur la prédictibilité de la génération des identifiants de fragmentation IP de l'hôte relais (le zombie). Les systèmes IDS considéreront que le scan provient de la machine zombie que vous avez spécifié (qui doit remplir certains critères). Le mécanisme de cette incroyable technique est trop complexe pour être expliqué en détail dans ce guide; un papier informel a été posté pour rendre compte de tous ces détails : http://www.insecure.org/nmap/idlescan.html
En plus de son incroyable furtivité (en raison du caractère aveugle de la technique), ce type de scan permet de déterminer les relations de confiance entre les machines. La liste des ports ouverts est établie du point de vue de l'hôte zombie. Ainsi, vous pouvez essayer de scanner une cible en utilisant différents zombies pour lesquels vous pensez qu'il existe une relation de confiance entre eux et la cible (d'après les règles des dispositifs de filtrage).
Vous pouvez ajouter les deux points (
suivis d'un numéro de port de l'hôte zombie si vous souhaitez tester les changements d'identifiants IP sur un port particulier du zombie. Par défaut, Nmap utilisera le port utilisé pour les pings tcp (le port 80).
-sO (Scan du protocole IP)
Le scan du protocole IP permet de déterminer quels protocoles IP (TCP, ICMP, IGMP, etc.) sont supportés par les cibles. Ce n'est donc pas techniquement un scan de ports, car Nmap essaie les différents numéros de protocoles IP à la place des numéros de ports TCP ou UDP. Ce scan permet néanmoins d'utiliser l'option -p pour sélectionner les numéros de protocoles à scanner -- le rapport de Nmap étant toujours dans le style habituel des tables de ports -- et utilise le même moteur de scan utilisé pour le scan de ports. Ainsi, cette technique est suffisamment proche du scan de port pour être présenté ici.
Au delà de son intérêt propre, le scan de protocoles illustre la puissance des logiciels en libre accès. L'idée de base est assez simple: je n'avais même pas particulièrement pensé à l'ajouter ni reçu de requête me demandant une telle fonctionnalité. En fait, à l'été 2000, Gerhard Rieger a eu cette idée et a écrit un excellent programme de correction pour l'implanter; il l'a ensuite envoyé à la liste de distribution nmap-hackers. Je l'ai par la suite ajouté à l'arbre de développement de Nmap et j'ai publié la nouvelle version le lendemain même. Très peu de logiciels commerciaux peuvent se targuer d'avoir des utilisateurs si enthousiastes concevant et proposant leur propres améliorations!
Le scan de protocole fonctionne d'une façon similaire du scan UDP. Au lieu de parcourir les champs de numéro de port des paquets UDP, il envoie des paquets d'en-têtes IP et parcours les 8 bits du champ protocole IP. Les en-têtes son généralement vides, ne contenant pas de données ni même l'en-tête du protocole sollicité. Les trois seules exceptions étant TCP, UDP et ICMP. Un en-tête exact de ces protocoles est inclus, sinon certains systèmes refusent de les émettre et Nmap dispose déjà des fonctions permettant de construire ces en-têtes. Au lieu de scruter les messages ICMP « port unreachable », comme pour le scan UDP, le scan de protocole attend de recevoir les messages ICMP «protocolunreachable ». Dès que Nmap reçoit une réponse d'un protocole en provenance de la cible, Nmap considère ce protocole comme ouvert. Une erreur ICMP « protocol unreachable » (type 3, code 2) fait en sorte que le port est considéré comme étant fermé. Les autres messages d'erreur ICMP « unreachable (type 3, code 1, 3, 9, 10, or 13) » font en sorte que le port est considéré comme étant filtré (tout en prouvant que le protocole ICMP est quant à lui ouvert). Si aucune réponse n'est reçue après plusieurs transmissions, le protocole est considéré comme étant ouvert|filtré.
-b <ftp relay host> (Scan par rebond FTP)
Une caractéristique intéressante du protocole FTP (RFC 959) est qu'il supporte les connexions par proxy ftp (proxy ftp connections, ainsi nommées dans la RFC). Ceci permet à un utilisateur de se connecter à un serveur FTP, puis de demander qu'un fichier soit envoyé à un tiers serveur FTP. Une telle fonctionnalité est propre à être détournée à tous les niveaux, c'est pourquoi la plupart des serveurs ont cessé de la supporter. Un des détournements possible de cette caractéristique conduit le serveur FTP à scanner les ports d'autres hôtes. Demandez simplement au serveur FTP d'envoyer un fichier à chaque port intéressant de votre cible, et il se chargera d'effectuer le scan. Le message d'erreur permettra de savoir si le port est ouvert ou non. C'est un très bon moyen de contourner les pare-feux car les serveurs FTP des organisations sont souvent situés de telle façon à avoir plus d'accès aux hôtes du réseau internes que toute autre machine Internet. Nmap supporte le scan par rebond FTP avec l'option -b. Cette option prend un argument du type username[email protected]ort. Server est le nom ou l'adresse IP d'un serveur FTP vulnérable. Comme pour une adresse URL traditionnelle, vous pouvez omettre usernameassword, (user: anonymous, password: [email protected]) pour accéder de manière anonyme. Le numéro de port (et les deux points) peuvent être également omis si le port FTP par défaut (21) est utilisé par le serveur server.
Cette vulnérabilité était très répandue en 1997 quand Nmap a été publié mais a largement été corrigée depuis. Il existe encore quelques serveurs vulnérables qui traînent, autant les essayer si rien d'autre ne marche (!!!). Si votre but est de contourner un pare-feu, scannez le réseau cible pour trouver un port 21 ouvert (ou un serveur FTP sur tout autre port en activant la détection de version), essayez ensuite pour chacun d'entre eux le scan par rebond FTP. Nmap vous indiquera si chaque hôte y est vulnérable ou pas. Si vous voulez juste essayer de masquer vos attaques, vous n'avez pas besoin (et même en fait, vous ne devriez pas) vous limiter aux hôtes du réseau cible. Avant de vous lancer dans un scan sur des adresses Internet au hasard, à la recherche de serveurs FTP vulnérables, pensez bien que les gestionnaires des systèmes n'apprécieront pas trop que vous détourniez leurs serveurs à cet effet.
SPECIFICATIONS ET ORDRE DU SCAN
En plus de toutes les méthodes de scan abordées précédemment, Nmap propose des options permettant la spécification des ports à scanner ainsi que l'ordre (au hasard ou séquentiel) dans lequel le scan doit se faire. Par défaut, Nmap scanne tous les ports jusqu'au 1 024 inclusivement ainsi que les ports supérieurs listés dans le fichier nmap-servicespour le ou les protocoles demandés).
-p <port ranges> (Ne scanne que les ports spécifiés)
Cette option spécifie quels ports vous voulez scanner et remplace le comportement par défaut. Les ports peuvent être spécifiés un à un ou par plages (séparés par des tirets, notamment 1-1023). Les valeurs de début ou de fin des plages peuvent être omises, de sorte que Nmap utilisera les ports 1 et 65 535, respectivement. Ainsi, vous pouvez spécifier -p- pour scanner tous les ports de 1 à 65 535. Le scan du port 0 est autorisé si spécifié explicitement. Pour ce qui est du scan du protocole IP (-sO), cette option spécifie les numéros de protocoles que vous souhaitez scanner (0-255).
Lorsque vous scannez à la fois des ports TCP et UDP, vous pouvez spécifier un protocole particulier en préfixant les numéros de ports par T: (pour TCP) ou U: (pour UDP). Le qualificateur reste actif à moins que vous n'en indiquiez un autre.
Par exemple, l'argument -p U:53,111,137,T:21-25,80,139,8080 scannerait les ports UDP numéros 53 111 et 137 et les ports TCP de 21 à 25 inclusivement, 80, 139 et 8080.
Notez que si vous voulez à la fois scanner TCP et UDP, vous devez spécifier -sU et au moins un type de scan TCP (comme -sS, -sF ou -sT). Si aucun qualificateur de protocole n'est spécifié, les numéros de ports sont alors valables pour tous les protocoles.
-F (Scan rapide) (limité aux ports connus)
Cette option indique que vous souhaitez seulement scanner les ports listés dans le fichier nmap-services fourni avec Nmap (ou le fichier des protocoles avec l'option -sO). Ceci est bien plus rapide que de scanner les 65 535 ports d'un hôte. Comme cette liste contient beaucoup de ports TCP (plus de 1 200), la différence de vitesse avec le comportement par défaut (environ 1 650 ports) est relativement négligeable. Par contre, la différence peut être énorme si vous spécifiez votre propre mini-fichier nmap-services en utilisant l'option --datadir.
-r (Ne mélange pas les ports)
Par défaut, Nmap mélange au hasard l'ordre des ports (sauf que certains ports couramment accessibles sont placés vers le début de la liste pour des raisons d'efficacité). Ce mélange est normalement souhaitable, mais vous pouvez spécifier l'option -r pour effectuer un scan de port séquentiel.
DÉTECTION DE SERVICES ET DE VERSIONS
Supposons que Nmap vous ai signalé que les ports 25/tcp, 80/tcp et 53/udp d'une machine distante sont ouverts. En utilisant sa base de données nmap-services d'environ 2 200 services bien connus, Nmap indique que ces ports correspondent probablement à un serveur de messagerie (SMTP), un serveur Web (HTTP) et un serveur de noms (DNS), respectivement. Cette consultation est souvent pertinente -- une vaste majorité des démons écoutant sur le port 25, étant bien des serveurs de messagerie.
Cependant, en sécurité, il ne faudrait pas trop parier là-dessus ! Les gens peuvent lancer des services sur des ports bizarres et ils le font effectivement.
Même si Nmap a raison, et que les serveurs hypothétiques du dessus sont bien des serveurs SMTP, HTTP et DNS, ce n'est pas très utile. Lors d'audit de sécurité (ou bien lors de simples inventaires de réseau) de votre entreprise ou de clients, vous voulez réellement savoir de quels serveurs de messagerie et de noms il s'agit, ainsi que leurs versions.
Connaître avec précision le numéro de version aide considérablement à déterminer à quels exploits un serveur est vulnérable. La détection de version vous permet d'obtenir une telle information. Après avoir découvert les ports TCP ou UDP par une des méthodes de scan, la détection de version interroge ces ports pour savoir quelle version tourne actuellement. La base de données nmap-service-probes contient les tests à effectuer selon les services, ainsi que les chaînes de caractères auxquelles comparer les réponses.
Nmap essaie de déterminer le protocole (p. ex.: ftp, ssh, telnet, http), le nom de l'application (p. ex.: ISC Bind, Appache httpd, Solaris telnetd), le numéro de version, le nom d'hôte, le type d'équipement (p. ex.: imprimante, routeur), la famille d'OS (p. ex.: Windows, Linux) et quelquefois des détails divers (p. ex.: si un serveur X accepte ou non des connexions, la version du protocole SSH, le nom d'utilisateur KaZaA).
Bien sûr, la plupart des services ne fournissent pas autant d'informations. Si Nmap a été compilé avec le support de OpenSSL, il se connectera aux serveurs SSL pour déduire le service écoutant derrière la couche de cryptage. Quand des services RPC sont découverts, la moulinette RPC de Nmap (-sR) est automatiquement utilisée pour déterminer le programme RPC et sa version. Des ports peuvent rester dans l'état ouvert|filtré lorsqu'un scan de ports UDP a été incapable de déterminer si le port était ouvert ou fermé.
La détection de version tentera d'obtenir une réponse de ces ports (comme s'ils étaient ouverts), et changera l'état à ouvert si elle y parvient. Les ports TCP ouverts|filtré sont traités de la même façon. Notez que l'option-Ade Nmap active notamment la détection de version. Un papier documentant le fonctionnement, l'utilisation et la personnalisation de la détection de version est disponible à http://www.insecure.org/nmap/vscan/
Lorsque Nmap reçoit une réponse d'un service mais ne parvient pas à le faire correspondre à un service de sa base de données, il affiche une empreinte et une adresse URL où vous pouvez l'envoyer si vous êtes sûr de ce qui tourne sur ce port. Prendre quelques minutes pour faire cette soumission permettra à tout le monde de bénéficier de votre découverte. Grâce à ces soumissions, Nmap dispose d'environ 3 000 empreintes de référence liées à plus de 350 protocoles, comme smtp, ftp et http.
LA DÉTECTION DE VERSION EST ACTIVÉE ET CONTRÔLÉE GRÂCE AUX OPTIONS SUIVANTES:
-sV (Détection de version) :
Active la détection de version, tel que discuté ci-dessus. Autrement, vous pouvez utiliser l'option -A pour activer à la fois la détection de version et celle du système d'exploitation.
--allports (tous les ports) (N'exclut aucun port de la détection de version) :
Par défaut, la détection de version de Nmap évite le port TCP 9100 car certaines imprimantes impriment tout bonnement tout ce qui est envoyé sur ce port, ce qui conduit à l'impression de douzaines de pages de requêtes HTTP, des requêtes de sessions SSL en binaire, etc. (ce qui est particulièrement furtif). Ce comportement peut être changé en modifiant ou en supprimant la directive Exclude du fichier nmap-service-probes, ou en spécifiant l'option --allports pour scanner tous les ports sans tenir compte d'aucune directive Exclude.
--version-intensity (Sélectionne l'intensité du scan de version) :
Lors d'un scan de version (-sV), Nmap envoie une série de paquets de tests, à chacun duquel est associé une valeur de rareté allant de 1 à 9. Les tests aux basses valeurs sont efficaces pour une grande variété de services courants, tandis que les hautes valeurs indiquent ceux qui ne sont que rarement utiles. Le niveau d'intensité spécifie quels tests doivent être effectués. Plus la valeur est haute, plus le service a de chances d'être correctement identifié. Cependant, ces scans-ci sont plus longs. La valeur d'intensité doit être comprise entre 0 et 9, la valeur par défaut étant le 7. Quand un test est inscrit sur le port cible par le biais de la directive nmap-service-probes ports, ce test est tenté quelque soit le niveau d'intensité. Cela permet de s'assurer que les tests DNS seront toujours tentés sur chaque port 53 ouvert, les tests SSL sur chaque 443, etc.
--version-light (Active le mode léger) :
Il s'agit d'un raccourci pour --version-intensity 2. Ce mode léger rend le scan de version bien plus rapide, mais il est un peu moins susceptible d'identifier les services.
--version-all (Essaie chaque test possible) :
Il s'agit d'un raccourci pour--version-intensity 9forçant chaque test unitaire à être testé contre chaque port.
--version-trace (Trace l'activité du scan de version) :
Ceci force Nmap à afficher un nombre considérable d'informations de débogage à propos de ce que fait le scan de version. Il s'agit d'un sous-ensemble de ce que vous obtenez avec l'option --packet-trace.
-sR (Scan RPC) :
Cette méthode fonctionne conjointement avec les différentes méthodes de scan de Nmap. Il prend tous les ports TCP/UDP ouverts et les submerge avec les commandes NULL du programme SunRPC dans le but de déterminer s'il s'agit de ports RPC, et le cas échéant, de quel programme et quel numéro de version il s'agit. Vous pouvez aussi obtenir les mêmes informations avec rpcinfo -p, et ce, même si le mapper de port (portmapper) de la cible se trouve derrière un pare-feu (ou protégé par des wrappers TCP). Les leurres ne fonctionnent pas avec le scan RPC. Cette option est automatiquement activée par le scan de version (-sV). Comme la détection de version inclus le scan RPC, et est bien plus complète, on a rarement besoin de l'option -sR.
DÉTECTION DE SYSTÈMES D'EXPLOITATION
L'une des fonctions les plus connues de Nmap est la détection de systèmes d'exploitation utilisant la prise d'empreinte de la pile TCP/IP. Nmap envoie une série de paquets TCP et UDP à l'hôte distant puis examine presque chaque bit des réponses. Après quelques douzaines de tests comme l'échantillonnage des séquences TCP (ISN sampling), l'ordonnancement et le support d'options TCP, l'échantillonnage IPID et la vérification de la taille initiale de fenêtre, Nmap compare les résultats avec sa base de données d'empreintes,nmap-os-fingerprints contenant plus de 1 500 empreintes de systèmes d'exploitation connus afin d'afficher finalement ses conclusions s'il trouve correspondance.
Chaque empreinte contient une description en texte libre du système d'exploitation ainsi qu'une classification qui fournit le nom du développeur (p. ex. : Sun), le système proprement dit (p. ex. : Solaris), sa génération (p. ex. : 10) et le type d'interface (généraliste, routeur, switch, console de jeu, etc.).
Si Nmap n'est pas capable de déterminer le système d'exploitation d'une machine et si les conditions sont acceptables (p. ex. : au moins un port ouvert et un port fermé ont été trouvés), Nmap fournira une adresse URL que vous pouvez utiliser afin de transmettre cette empreinte si vous connaissez avec certitude le système d'exploitation qui tourne sur cette machine. Ce faisant, vous contribuez grandement au panel de systèmes d'exploitation reconnus par Nmap et lui permettez d'être plus performant pour chacun.
La détection du système d'exploitation met en oeuvre un certain nombre de tests annexes utilisés de toute façon durant le processus global. L'un d'eux est la mesure de l'uptime, qui utilise l'option TCP timestamp (RFC 1323) afin de déterminer si une machine a été redémarrée récemment. Il n'en est fait mention que dans le cas où cette machine fournie cette information. Un autre test consiste en la Classification de la Prédictabilité de Séquence TCP (TCP Sequence Predictability Classification) qui mesure approximativement la difficulté d'établir une connexion en TCP forgée préalablement en direction de l'hôte distant. Ce test est utile dans le cas d'exploitation de la relation de confiance basée sur l'IP (cas du rlogin, des filtres de pare-feux, etc.) ou dans le but de cacher la source d'une attaque. Ce genre de mystification (spoofing) est rarement effectué quoi qu'il en soit, mais beaucoup de machines y sont toujours sensibles. La valeur indiquant la difficulté est basée sur un échantillonnage statistique et peut ainsi varier. Il est préférable d'employer une classification anglo-saxonne telle que "worthy challenge" , vraiment difficile, ou "trivial joke", qui est très facile. Ceci n'est indiqué dans une sortie de type normale qu'en mode verbeux (verbose mode, -v). Lorsque le mode verbeux est utilisé avec l'option -O, la génération de séquence IPID est aussi précisée. La plupart des machines sont de classe incrémentielle, "incremental", ce qui signifie qu'elles incrémentent le champ ID de l'en-tête IP pour chaque paquet qu'elles envoient. Ceci les rend vulnérables à différentes techniques avancées de collecte d'informations et de mystification (usurpation d'identité).
Un article décrivant l'usage, le réglage et le fonctionnement de la détection de version est disponible dans plus d'une douzaine de langues sur le site http://www.insecure.org/nmap/osdetect/
LA DÉTECTION DE SYSTÈMES D'EXPLOITATION EST ACTIVÉE ET CONTRÔLÉE AVEC LES OPTIONS SUIVANTES :
-O (Active la détection du système d'exploitation) :
Active la détection du système d'exploitation, tel que discuté ci-dessus. Vous pouvez aussi utiliser l'option -A pour activer à la fois la détection du système d'exploitation et la détection de la version.
--osscan-limit (Limite la détection du système d'exploitation aux cibles potentielles) :
La détection du système d'exploitation est bien plus efficace si au moins un port ouvert et un port fermé sont trouvés. Utilisez cette option et Nmap ne tentera pas d'effectuer la détection contre des hôtes qui ne remplissent pas cette condition. Ceci peut faire gagner pas mal de temps, particulièrement dans le cas de scans -P0 contre de nombreux hôtes. C'est évidemment seulement important lorsque la détection du système d'exploitation est demandée au moyen de l'option -O ou -A.
--osscan-guess ou --fuzzy (Prédire un résultat de détection du système d'exploitation) :
Lorsque Nmap est incapable de trouver une correspondance parfaite pour le système d'exploitation, il propose souvent les correspondances les plus proches. La correspondance doit être très proche afin que Nmap puisse effectuer cette procédure par défaut. L'une ou l'autre de ces options (équivalentes) force Nmap à être plus agressif dans sa prédiction.
Exemple : nmap --osscan_guess -sS -O -p 19-26 -n -P0 89.219.XXX.XX
A noter, nmap est en ligne de commande et est multi-plateforme. Il est aussi disponible en GUI (interface graphique), il s'appelle alors Zenmap (également multi-plateforme).
Vous pouvez le télécharger directement sur le site officiel de NMAP :
http://nmap.org/download.html
LES BASES DU SCAN DE PORTS
Même si le nombre de fonctionnalités de Nmap a considérablement augmenté au fil des ans, il reste un scanner de ports efficace, et cela reste sa fonction principale. La commande de base nmap target scanne plus de 1 660 ports TCP de l'hôte target.
Alors que de nombreux autres scanners de ports ont partitionné les états des ports en ouverts ou fermés, Nmap a une granularité bien plus fine. Il divise les ports selon six états: ouvert (open), fermé (closed), filtré (filtered), non-filtré (unfiltered), ouvert|filtré (open|filtered), et fermé|filtré (closed|filtered).
Ces états ne font pas partie des propriétés intrinsèques des ports eux-mêmes, mais décrivent comment Nmap les perçoit. Par exemple, un scan Nmap depuis le même réseau que la cible pourrait voir le port 135/tcp comme ouvert alors qu'un scan au même instant avec les mêmes options au travers d'Internet pourrait voir ce même port comme filtré.
LES SIX ÉTATS DE PORT RECONNUS PAR NMAP
ouvert (open) :
Une application accepte des connexions TCP ou des paquets UDP sur ce port. Trouver de tels ports est souvent le but principal du scan de ports. Les gens soucieux de la sécurité savent pertinemment que chaque port ouvert est un boulevard pour une attaque. Les attaquants et les pen-testers veulent exploiter ces ports ouverts, tandis que les administrateurs essaient de les fermer ou de les protéger avec des pare-feux sans gêner leurs utilisateurs légitimes. Les ports ouverts sont également intéressants pour des scans autres que ceux orientés vers la sécurité car ils indiquent les services disponibles sur le réseau.
fermé (closed) :
Un port fermé est accessible (il reçoit et répond aux paquets émis par Nmap), mais il n'y a pas d'application en écoute. Ceci peut s'avérer utile pour montrer qu'un hôte est actif (découverte d'hôtes ou scan ping), ou pour la détection de l'OS. Comme un port fermé est accessible, il peut être intéressant de le scanner de nouveau plus tard au cas où il s'ouvrirait. Les administrateurs pourraient désirer bloquer de tels ports avec un pare-feu, mais ils apparaîtraient alors dans l'état filtré décrit dans la section suivante.
filtré (filtered) :
Nmap ne peut pas toujours déterminer si un port est ouvert car les dispositifs de filtrage des paquets empêchent les paquets de tests (probes) d'atteindre leur port cible. Le dispositif de filtrage peut être un pare-feu dédié, des règles de routeurs filtrants ou un pare-feu logiciel. Ces ports ennuient les attaquants car ils ne fournissent que très peu d'informations. Quelques fois ils répondent avec un message d'erreur ICMP de type 3 code 13 (« destination unreachable: communication administratively prohibited »), mais les dispositifs de filtrage qui rejettent les paquets sans rien répondre sont bien plus courants. Ceci oblige Nmap à essayer plusieurs fois au cas où ces paquets de tests seraient rejetés à cause d'une surcharge du réseau et pas du filtrage. Ceci ralenti terriblement les choses.
non-filtré (unfiltered) :
L'état non-filtré signifie qu'un port est accessible, mais que Nmap est incapable de déterminer s'il est ouvert ou fermé. Seul le scan ACK, qui est utilisé pour déterminer les règles des pare-feux, catégorise les ports dans cet état. Scanner des ports non-filtrés avec un autre type de scan, comme le scan Windows, SYN ou FIN peut aider à savoir si un port est ouvert ou pas.
ouvert|filtré (open|filtered) :
Nmap met dans cet état les ports dont il est incapable de déterminer l'état entre ouvert et filtré. Ceci arrive pour les types de scans où les ports ouverts ne renvoient pas de réponse. L'absence de réponse peut aussi signifier qu'un dispositif de filtrage des paquets a rejeté le test ou les réponses attendues. Ainsi, Nmap ne peut s'assurer ni que le port est ouvert, ni qu'il est filtré. Les scans UDP, protocole IP, FIN, Null et Xmas catégorisent les ports ainsi.
fermé|filtré (closed|filtered) :
Cet état est utilisé quand Nmap est incapable de déterminer si un port est fermé ou filtré. Cet état est seulement utilisé par le scan Idle basé sur les identifiants de paquets IP.
LES TECHNIQUES DU SCAN DE PORTS
La plupart des types de scans ne sont disponibles que pour les utilisateurs privilégiés. Ceci est dû au fait qu'ils émettent et reçoivent des paquets bruts (raw), qui nécessitent les droits root sur les systèmes UNIX. L'utilisation d'un compte administrateur est conseillé sous Windows, bien que Nmap puisse fonctionner avec des utilisateurs non-privilégiés si WinPcap est déjà chargé avec l'OS. Ce besoin des droits root était une sérieuse restriction quand Nmap a été diffusé en 1997, car beaucoup d'utilisateurs avaient seulement accès à des comptes Internet partagés. Maintenant, le monde est différent. Les ordinateurs sont moins chers, bien plus de gens disposent d'un accès 24/24 direct à Internet et les systèmes UNIX de bureau (comme Linux et Mac OS X) sont répandus. Une version Windows de Nmap est désormais disponible, permettant ainsi de le lancer sur encore plus de machines. Pour toutes ces raisons, les utilisateurs ont bien moins besoin de lancer Nmap depuis des comptes Internet limités. Ceci est heureux, car les options privilégiés rendent Nmap bien plus puissant et flexible.
Si Nmap essaie de produire des résultats précis, il faut garder à l'esprit que toute sa perspicacité est basée sur les paquets renvoyés par les machines cibles (ou les pare-feux qui les protègent). De tels hôtes ne sont pas toujours dignes de confiance et peuvent répondre dans le but de brouiller ou d'enduire Nmap d'erreurs. Les hôtes qui ne respectent pas les RFCs et ne répondent pas comme ils devraient sont encore plus courants. Les scans FIN, Null et Xmas sont les plus sensibles à ce problème. Ces points sont spécifiques à certains types de scan et sont donc abordés dans leur section propre de la documentation.
Cette section documente la douzaine de techniques de scan de ports gérées par Nmap. Les méthodes ne peuvent pas être utilisés simultanément, excepté le scan UDP (-sU) qui peut être combiné avec chacun des types de scan TCP. A titre d'aide mémoire, les options de type de scan sont de la forme -sC, où Cest un caractère prépondérant dans le nom du scan, souvent le premier. La seule exception est le désuet scan par rebond FTP (-b). Par défaut, Nmap effectue un scan SYN, bien qu'il y substitue un scan connect() si l'utilisateur ne dispose pas des droits suffisants pour envoyer des paquets bruts (qui requièrent les droits root sous UNIX) ou si des cibles IPv6 sont spécifiées. Des scans listés dans cette section, les utilisateurs non-privilégiés peuvent seulement exécuter les scans connect() et le scan par rebond FTP.
-sS (Scan TCP SYN)
Le scan SYN est celui par défaut et le plus populaire pour de bonnes raisons. Il peut être exécuté rapidement et scanner des milliers de ports par seconde sur un réseau rapide lorsqu'il n'est pas entravé par des pare-feux. Le scan SYN est relativement discret et furtif, vu qu'il ne termine jamais les connexions TCP. Il marche également contre toute pile respectant TCP, au lieu de dépendre des particularités environnementales spécifiques comme les scans Fin/Null/Xmas, Maimon ou Idle le sont. Il permet de plus une différentiation fiable entre les états ouvert, fermé et filtré.
Cette technique est souvent appelée le scan demi-ouvert (half-open scanning), car il n'établi pas pleinement la connexion TCP. Il envoie un paquet SYN et attend sa réponse, comme s'il voulait vraiment ouvrir une connexion. Une réponse SYN/ACK indique que le port est en écoute (ouvert), tandis qu'une RST (reset) indique le contraire. Si aucune réponse n'est reçue après plusieurs essais, le port est considéré comme étant filtré. Le port l'est également si un message d'erreur « unreachable ICMP (type 3, code 1,2, 3, 9, 10 ou 13) » est reçu.
-sT (Scan TCP connect())
Le scan TCP connect() est le type de scan par défaut quand le SYN n'est pas utilisable. Tel est le cas lorsque l'utilisateur n'a pas les privilèges pour les paquets bruts (raw packets) ou lors d'un scan de réseaux IPv6. Plutôt que d'écrire des paquets bruts comme le font la plupart des autres types de scan, Nmap demande au système d'exploitation qui l'exécute d'établir une connexion au port de la machine cible grâce à l'appel système connect(). C'est le même appel système haut-niveau qui est appelé par les navigateurs Web, les clients P2P et la plupart des applications réseaux qui veulent établir une connexion. Cet appel fait partie de l'interface d'application connue sous le nom de « Berkeley Sockets API ». Au lieu de lire les réponses brutes sur le support physique, Nmap utilise cette application API pour obtenir l'état de chaque tentative de connexion.
Si le scan SYN est disponible, il vaut mieux l'utiliser. Nmap a bien moins de contrôles sur l'appel système haut niveau connect() que sur les paquets bruts, ce qui le rend moins efficace. L'appel système complète les connexions ouvertes sur les ports cibles au lieu de les annuler lorsque la connexion est à demie ouverte, comme le fait le scan SYN. Non seulement c'est plus long et demande plus de paquets pour obtenir la même information, mais de plus la probabilité que les cibles activent la connexion est plus grande. Un IDS décent le fera, mais la plupart des machines ne disposent pas de ce système d'alarme. De nombreux services sur les systèmes UNIX standards noteront cette connexion dans le journal, accompagné d'un message d'erreur sibyllin si Nmap ouvre puis referme la connexion sans n'envoyer aucune donnée. Les services réseaux les plus piteux risquent même de tomber en panne, mais c'est assez rare. Un administrateur qui verrait un tas de tentatives de connexions dans ses journaux en provenance d'une seule machine devrait se rendre compte qu'il a été scanné.
-sU (Scan UDP)
Même si les services les plus connus d'Internet son basés sur le protocole TCP, les services UDP sont aussi largement utilisés. DNS, SNMP ou DHCP (ports 53, 161/162 et 67/68) sont les trois exemples les plus courants. Comme le scan UDP est généralement plus lent et plus difficile que TCP, certains auditeurs de sécurité les ignorent. C'est une erreur, car les services UDP exploitables sont courants et les attaquants eux ne les ignoreront pas. Par chance, Nmap peut aider à répertorier les ports UDP.
Le scan UDP est activé avec l'option-sU. Il peut être combiné avec un scan TCP, comme le scan SYN ( -sS), pour vérifier les deux protocoles lors de la même exécution de Nmap.
Le scan UDP envoie un en-tête UDP (sans données) à chaque port visé. Si un message ICMP « port unreachable (type 3, code 3) » est renvoyé, le port est alors fermé. Les autres messages d'erreur « unreachable ICMP (type 3, codes 1, 2, 9, 10, or 13) » rendront le port filtré. À l'occasion, il arrive qu'un service répond par un paquet UDP, prouvant que le port est dans l'état ouvert. Si aucune réponse n'est renvoyée après plusieurs essais, le port est considéré comme étant ouvert|filtré. Cela signifie que le port peut être soit ouvert, soit qu'un dispositif de filtrage bloque les communications. Le scan de versions ( -sV) peut être utilisé pour différencier les ports ouverts de ceux filtrés.
Une des grandes difficultés avec le scan UDP est de l'exécuter rapidement. Les ports ouverts et filtrés ne renvoient que rarement des réponses, laissant Nmap expirer son délai de retransmission au cas où les paquets se soient perdus. Les ports fermés posent encore un plus grand problème: ils renvoient normalement une erreur ICMP « port unreachable ». Mais à la différence des paquets RST renvoyés par les ports TCP fermés en réponse à un scan SYN ou à un connect(), de nombreux hôtes limitent par défaut la cadence d'émission de ces messages. Linux et Solaris étant particulièrement stricts à ce sujet. Par exemple, le kernel 2.4.20 limite cette cadence des destinations inaccessibles (« destination unreachable ») à un par seconde (cf.net/ipv4/icmp.c).
Nmap détecte cette limitation de fréquence et s'y ralenti conformément afin d'éviter de saturer le réseau avec des paquets inutiles que la machine cible rejettera. Malheureusement, une limitation à la Linux d'un paquet par seconde fera qu'un scan des 65 536 ports prendra plus de 18 heures. Les idées pour accélérer les scans UDP incluent le scan des cibles en parallèle, ne scanner que les ports les plus courants en premier, scanner derrière le pare-feu et utiliser l'option --host-timeoutpour éviter les hôtes les plus lents.
-sN -sF -sX (Scans TCP Null, FIN et Xmas)
Ces trois types de scans (d'autres sont possibles en utilisant l'option --scanflags décrite dans la section suivante) exploitent une subtile faille de la RFC TCP pour différencier les ports entre ouverts et fermés. La page 65 indique que si le port [de destination] est dans l'état fermé... un segment ne contenant pas le drapeau RST provoque l'émission d'un paquet RST comme réponse. La page suivante indique que pour les paquets envoyés à des ports sans aucun des drapeaux SYN, RST ou ACK activés: il est peut vraisemblable que cela arrive, mais si cela est le cas, il faut rejeter le segment.
Pour les systèmes respectant ce texte de la RFC, chaque paquet ne contenant ni SYN, ni RST, ni ACK se voit renvoyé un RST si le port est fermé et aucune réponse si le port est ouvert. Tant qu'aucun de ces drapeaux n'est utilisé, toute combinaison des trois autres (FIN, PSH et URG) son valides. Nmap exploite cela avec les trois types de scans:
Scan Null (-sN) : N'active aucun des bits (les drapeaux de l'en-tête TCP vaut 0).
Scan FIN (-sF) : N'active que le bit FIN.
Scan Xmas (-sX) : Active les drapeaux FIN, PSH et URG, illuminant le paquet comme un arbre de Noël (NDT: la fracture cognitive entre la culture anglo-saxonne et française se ressent fortement dans cette traduction...).
Ces trois types de scan ont exactement le même comportement, sauf pour les drapeaux TCP utilisés dans des paquets de tests (probes packets). Si un RST est reçu, le port est considéré comme étant fermé, tandis qu'une absence de réponse signifiera qu'il est dans l'état ouvert|filtré. Le port est marqué comme filtré si un message d'erreur ICMP « unreachable (type 3, code 1, 2, 3, 9, 10 ou 13) » est reçu.
L'avantage principal de ces types de scans est qu'ils peuvent furtivement traverser certains pare-feux ou routeurs filtrants sans état de connexion (non-statefull). Un autre avantage est qu'ils sont même un peu plus furtifs que le scan SYN. N'y comptez pas trop dessus cependant -- la plupart des IDS modernes sont configurés pour les détecter. L'inconvénient majeur est que tous les systèmes ne respectent pas la RFC 793 à la lettre. Plusieurs systèmes renvoient des RST aux paquets quelque soit l'état du port de destination, qu'il soit ouvert ou pas. Ceci fait que tous les ports sont considérés commefermé. Les plus connus des systèmes qui ont ce comportement sont Microsoft Windows, plusieurs équipements Cisco, BSDI et IBM OS/400. Ce type de scan fonctionne cependant très bien contre la plupart des systèmes basés sur UNIX. Un autre désagrément de ce type de scan et qu'ils ne peuvent pas distinguer les ports ouvertsde certains autres qui sont filtrés, vous laissant face à un laconique ouvert|filtré.
-sA (Scan TCP ACK)
Ce type de scan est différent des autres abordés jusqu'ici, dans le sens où ils ne peuvent pas déterminer si un port est ouvert(ni même ouvert|filtré). Il est utilisé pour établir les règles des pare-feux, déterminant s'ils sont avec ou sans états (statefull/stateless) et quels ports sont filtrés.
Le scan ACK n'active que le drapeau ACK des paquets (à moins que vous n'utilisiez l'option --scanflags). Les systèmes non-filtrés réagissent en retournant un paquet RST. Nmap considère alors le port comme non-filtré, signifiant qu'il est accessible avec un paquet ACK, mais sans savoir s'il est réellement ouvert ou fermé. Les ports qui ne répondent pas ou renvoient certains messages d'erreur ICMP (type 3, code 1, 2, 3, 9, 10, ou 13), sont considérés comme filtrés.
-sW (Scan de fenêtre TCP)
Le scan de fenêtre TCP est exactement le même que le scan ACK à la différence près qu'il exploite un détail de l'implémentation de certains systèmes pour identifier les ports fermés des autres, au lieu de toujours afficher non-filtrélorsqu'un RST est renvoyé. Sur certains systèmes, les ports ouverts utilisent une taille de fenêtre TCP positive (même pour les paquets RST), tandis que les ports fermés ont une fenêtre de taille nulle. Ainsi, au lieu de toujours afficher non-filtré lorsqu'un RST est reçu, le scan de fenêtre indique que le port est ouvert ou fermé selon que la taille de fenêtre TCP de ce paquet RST est respectivement positive ou nulle.
Ce scan repose sur un détail d'implémentation d'une minorité de systèmes Internet, vous ne pouvez donc pas toujours vous y fier. Les systèmes qui ne le supportent pas vont certainement se voir considérés leurs ports comme fermés. Bien sûr, il se peut que la machine n'ait effectivement aucun port ouvert. Si la plupart des ports scannés sont fermés mais que quelques-uns courants, comme le 22, 25 ou le 53, sont filtrés, le système est vraisemblablement prédisposé à ce type de scan. Quelquefois, les systèmes ont le comportement exactement inverse. Si votre scan indique que 1 000 ports sont ouverts et que 3 seulement sont fermés ou filtrés, ces trois derniers sont certainement ceux qui sont ouverts.
-sM (Scan TCP Maimon)
Le scan Maimon est nommé ainsi d'après celui qui l'a découvert, Uriel Maimon. Il a décrit cette technique dans le numéro 49 de Phrack Magazine (Novembre 1996). Nmap, qui inclut cette technique, a été publié deux numéros plus tard. Cette technique est la même que les scans NUll, FIN et Xmas, à la différence près que le paquet de test est ici un FIN/ACK. Conformément à la RFC 793 (TCP), un paquet RST devrait être renvoyé comme réponse à un tel paquet, et ce, que le port soit ouvert ou non. Uriel a cependant remarqué que de nombreux systèmes basés sur BSD rejettent tout bonnement le paquet si le port est ouvert.
--scanflags (Scan TCP personnalisé)
Les utilisateurs réellement experts de Nmap ne veulent pas se limiter aux seuls types de scans proposés. L'option --scanflagsvous permet de créer votre propre type de scan en spécifiant vos propres combinaisons de drapeaux TCP. Laisser courir votre imagination, tout en contournant les systèmes de détection d'intrusion dont les vendeurs n'ont fait qu'ajouter des règles spécifiques d'après la documentation Nmap!
L'argument de l'option --scanflags peut être soit un nombre comme 9 (PSH et FIN), mais l'utilisation des noms symboliques est plus facile. Mélanger simplement les drapeaux URG, ACK, PSH, RST, SYN et FIN. Par exemple, --scanflags URGACKPSHRSTSYNFIN les activent tous, bien que cela ne soit pas très utile pour effectuer un scan. L'ordre dans lequel les drapeaux sont spécifiés n'a pas d'importance.
En sus de la spécification des drapeaux désirés, vous pouvez spécifier également un type de scan TCP (comme -sA ou -sF). Ce type de scan de base indique à Nmap comment interpréter les réponses. Par exemple, un scan SYN considère que l'absence de réponse indique qu'un port est filtré, tandis qu'un scan FIN considèrera la même absence comme un port ouvert|filtré. Nmap se comportera de la même façon que le type de scan de base, à la différence près qu'il utilisera les drapeaux TCP que vous avez spécifié à la place. Si vous n'en spécifiez pas, le type de scan SYN par défaut sera utilisé.
-sI <zombie host[
robeport]> (Scan paresseux -- idlescan)Cette méthode de scan avancé permet de faire un véritable scan de port TCP en aveugle, (dans le sens où aucun paquet n'est envoyé directement à la cible depuis votre vraie adresse IP). En effet, la technique employée consiste à récolter des informations sur les ports ouverts de la cible en utilisant un exploit basé sur la prédictibilité de la génération des identifiants de fragmentation IP de l'hôte relais (le zombie). Les systèmes IDS considéreront que le scan provient de la machine zombie que vous avez spécifié (qui doit remplir certains critères). Le mécanisme de cette incroyable technique est trop complexe pour être expliqué en détail dans ce guide; un papier informel a été posté pour rendre compte de tous ces détails : http://www.insecure.org/nmap/idlescan.html
En plus de son incroyable furtivité (en raison du caractère aveugle de la technique), ce type de scan permet de déterminer les relations de confiance entre les machines. La liste des ports ouverts est établie du point de vue de l'hôte zombie. Ainsi, vous pouvez essayer de scanner une cible en utilisant différents zombies pour lesquels vous pensez qu'il existe une relation de confiance entre eux et la cible (d'après les règles des dispositifs de filtrage).
Vous pouvez ajouter les deux points (
suivis d'un numéro de port de l'hôte zombie si vous souhaitez tester les changements d'identifiants IP sur un port particulier du zombie. Par défaut, Nmap utilisera le port utilisé pour les pings tcp (le port 80).-sO (Scan du protocole IP)
Le scan du protocole IP permet de déterminer quels protocoles IP (TCP, ICMP, IGMP, etc.) sont supportés par les cibles. Ce n'est donc pas techniquement un scan de ports, car Nmap essaie les différents numéros de protocoles IP à la place des numéros de ports TCP ou UDP. Ce scan permet néanmoins d'utiliser l'option -p pour sélectionner les numéros de protocoles à scanner -- le rapport de Nmap étant toujours dans le style habituel des tables de ports -- et utilise le même moteur de scan utilisé pour le scan de ports. Ainsi, cette technique est suffisamment proche du scan de port pour être présenté ici.
Au delà de son intérêt propre, le scan de protocoles illustre la puissance des logiciels en libre accès. L'idée de base est assez simple: je n'avais même pas particulièrement pensé à l'ajouter ni reçu de requête me demandant une telle fonctionnalité. En fait, à l'été 2000, Gerhard Rieger a eu cette idée et a écrit un excellent programme de correction pour l'implanter; il l'a ensuite envoyé à la liste de distribution nmap-hackers. Je l'ai par la suite ajouté à l'arbre de développement de Nmap et j'ai publié la nouvelle version le lendemain même. Très peu de logiciels commerciaux peuvent se targuer d'avoir des utilisateurs si enthousiastes concevant et proposant leur propres améliorations!
Le scan de protocole fonctionne d'une façon similaire du scan UDP. Au lieu de parcourir les champs de numéro de port des paquets UDP, il envoie des paquets d'en-têtes IP et parcours les 8 bits du champ protocole IP. Les en-têtes son généralement vides, ne contenant pas de données ni même l'en-tête du protocole sollicité. Les trois seules exceptions étant TCP, UDP et ICMP. Un en-tête exact de ces protocoles est inclus, sinon certains systèmes refusent de les émettre et Nmap dispose déjà des fonctions permettant de construire ces en-têtes. Au lieu de scruter les messages ICMP « port unreachable », comme pour le scan UDP, le scan de protocole attend de recevoir les messages ICMP «protocolunreachable ». Dès que Nmap reçoit une réponse d'un protocole en provenance de la cible, Nmap considère ce protocole comme ouvert. Une erreur ICMP « protocol unreachable » (type 3, code 2) fait en sorte que le port est considéré comme étant fermé. Les autres messages d'erreur ICMP « unreachable (type 3, code 1, 3, 9, 10, or 13) » font en sorte que le port est considéré comme étant filtré (tout en prouvant que le protocole ICMP est quant à lui ouvert). Si aucune réponse n'est reçue après plusieurs transmissions, le protocole est considéré comme étant ouvert|filtré.
-b <ftp relay host> (Scan par rebond FTP)
Une caractéristique intéressante du protocole FTP (RFC 959) est qu'il supporte les connexions par proxy ftp (proxy ftp connections, ainsi nommées dans la RFC). Ceci permet à un utilisateur de se connecter à un serveur FTP, puis de demander qu'un fichier soit envoyé à un tiers serveur FTP. Une telle fonctionnalité est propre à être détournée à tous les niveaux, c'est pourquoi la plupart des serveurs ont cessé de la supporter. Un des détournements possible de cette caractéristique conduit le serveur FTP à scanner les ports d'autres hôtes. Demandez simplement au serveur FTP d'envoyer un fichier à chaque port intéressant de votre cible, et il se chargera d'effectuer le scan. Le message d'erreur permettra de savoir si le port est ouvert ou non. C'est un très bon moyen de contourner les pare-feux car les serveurs FTP des organisations sont souvent situés de telle façon à avoir plus d'accès aux hôtes du réseau internes que toute autre machine Internet. Nmap supporte le scan par rebond FTP avec l'option -b. Cette option prend un argument du type username
[email protected]ort. Server est le nom ou l'adresse IP d'un serveur FTP vulnérable. Comme pour une adresse URL traditionnelle, vous pouvez omettre usernameassword, (user: anonymous, password: [email protected]) pour accéder de manière anonyme. Le numéro de port (et les deux points) peuvent être également omis si le port FTP par défaut (21) est utilisé par le serveur server.Cette vulnérabilité était très répandue en 1997 quand Nmap a été publié mais a largement été corrigée depuis. Il existe encore quelques serveurs vulnérables qui traînent, autant les essayer si rien d'autre ne marche (!!!). Si votre but est de contourner un pare-feu, scannez le réseau cible pour trouver un port 21 ouvert (ou un serveur FTP sur tout autre port en activant la détection de version), essayez ensuite pour chacun d'entre eux le scan par rebond FTP. Nmap vous indiquera si chaque hôte y est vulnérable ou pas. Si vous voulez juste essayer de masquer vos attaques, vous n'avez pas besoin (et même en fait, vous ne devriez pas) vous limiter aux hôtes du réseau cible. Avant de vous lancer dans un scan sur des adresses Internet au hasard, à la recherche de serveurs FTP vulnérables, pensez bien que les gestionnaires des systèmes n'apprécieront pas trop que vous détourniez leurs serveurs à cet effet.
SPECIFICATIONS ET ORDRE DU SCAN
En plus de toutes les méthodes de scan abordées précédemment, Nmap propose des options permettant la spécification des ports à scanner ainsi que l'ordre (au hasard ou séquentiel) dans lequel le scan doit se faire. Par défaut, Nmap scanne tous les ports jusqu'au 1 024 inclusivement ainsi que les ports supérieurs listés dans le fichier nmap-servicespour le ou les protocoles demandés).
-p <port ranges> (Ne scanne que les ports spécifiés)
Cette option spécifie quels ports vous voulez scanner et remplace le comportement par défaut. Les ports peuvent être spécifiés un à un ou par plages (séparés par des tirets, notamment 1-1023). Les valeurs de début ou de fin des plages peuvent être omises, de sorte que Nmap utilisera les ports 1 et 65 535, respectivement. Ainsi, vous pouvez spécifier -p- pour scanner tous les ports de 1 à 65 535. Le scan du port 0 est autorisé si spécifié explicitement. Pour ce qui est du scan du protocole IP (-sO), cette option spécifie les numéros de protocoles que vous souhaitez scanner (0-255).
Lorsque vous scannez à la fois des ports TCP et UDP, vous pouvez spécifier un protocole particulier en préfixant les numéros de ports par T: (pour TCP) ou U: (pour UDP). Le qualificateur reste actif à moins que vous n'en indiquiez un autre.
Par exemple, l'argument -p U:53,111,137,T:21-25,80,139,8080 scannerait les ports UDP numéros 53 111 et 137 et les ports TCP de 21 à 25 inclusivement, 80, 139 et 8080.
Notez que si vous voulez à la fois scanner TCP et UDP, vous devez spécifier -sU et au moins un type de scan TCP (comme -sS, -sF ou -sT). Si aucun qualificateur de protocole n'est spécifié, les numéros de ports sont alors valables pour tous les protocoles.
-F (Scan rapide) (limité aux ports connus)
Cette option indique que vous souhaitez seulement scanner les ports listés dans le fichier nmap-services fourni avec Nmap (ou le fichier des protocoles avec l'option -sO). Ceci est bien plus rapide que de scanner les 65 535 ports d'un hôte. Comme cette liste contient beaucoup de ports TCP (plus de 1 200), la différence de vitesse avec le comportement par défaut (environ 1 650 ports) est relativement négligeable. Par contre, la différence peut être énorme si vous spécifiez votre propre mini-fichier nmap-services en utilisant l'option --datadir.
-r (Ne mélange pas les ports)
Par défaut, Nmap mélange au hasard l'ordre des ports (sauf que certains ports couramment accessibles sont placés vers le début de la liste pour des raisons d'efficacité). Ce mélange est normalement souhaitable, mais vous pouvez spécifier l'option -r pour effectuer un scan de port séquentiel.
DÉTECTION DE SERVICES ET DE VERSIONS
Supposons que Nmap vous ai signalé que les ports 25/tcp, 80/tcp et 53/udp d'une machine distante sont ouverts. En utilisant sa base de données nmap-services d'environ 2 200 services bien connus, Nmap indique que ces ports correspondent probablement à un serveur de messagerie (SMTP), un serveur Web (HTTP) et un serveur de noms (DNS), respectivement. Cette consultation est souvent pertinente -- une vaste majorité des démons écoutant sur le port 25, étant bien des serveurs de messagerie.
Cependant, en sécurité, il ne faudrait pas trop parier là-dessus ! Les gens peuvent lancer des services sur des ports bizarres et ils le font effectivement.
Même si Nmap a raison, et que les serveurs hypothétiques du dessus sont bien des serveurs SMTP, HTTP et DNS, ce n'est pas très utile. Lors d'audit de sécurité (ou bien lors de simples inventaires de réseau) de votre entreprise ou de clients, vous voulez réellement savoir de quels serveurs de messagerie et de noms il s'agit, ainsi que leurs versions.
Connaître avec précision le numéro de version aide considérablement à déterminer à quels exploits un serveur est vulnérable. La détection de version vous permet d'obtenir une telle information. Après avoir découvert les ports TCP ou UDP par une des méthodes de scan, la détection de version interroge ces ports pour savoir quelle version tourne actuellement. La base de données nmap-service-probes contient les tests à effectuer selon les services, ainsi que les chaînes de caractères auxquelles comparer les réponses.
Nmap essaie de déterminer le protocole (p. ex.: ftp, ssh, telnet, http), le nom de l'application (p. ex.: ISC Bind, Appache httpd, Solaris telnetd), le numéro de version, le nom d'hôte, le type d'équipement (p. ex.: imprimante, routeur), la famille d'OS (p. ex.: Windows, Linux) et quelquefois des détails divers (p. ex.: si un serveur X accepte ou non des connexions, la version du protocole SSH, le nom d'utilisateur KaZaA).
Bien sûr, la plupart des services ne fournissent pas autant d'informations. Si Nmap a été compilé avec le support de OpenSSL, il se connectera aux serveurs SSL pour déduire le service écoutant derrière la couche de cryptage. Quand des services RPC sont découverts, la moulinette RPC de Nmap (-sR) est automatiquement utilisée pour déterminer le programme RPC et sa version. Des ports peuvent rester dans l'état ouvert|filtré lorsqu'un scan de ports UDP a été incapable de déterminer si le port était ouvert ou fermé.
La détection de version tentera d'obtenir une réponse de ces ports (comme s'ils étaient ouverts), et changera l'état à ouvert si elle y parvient. Les ports TCP ouverts|filtré sont traités de la même façon. Notez que l'option-Ade Nmap active notamment la détection de version. Un papier documentant le fonctionnement, l'utilisation et la personnalisation de la détection de version est disponible à http://www.insecure.org/nmap/vscan/
Lorsque Nmap reçoit une réponse d'un service mais ne parvient pas à le faire correspondre à un service de sa base de données, il affiche une empreinte et une adresse URL où vous pouvez l'envoyer si vous êtes sûr de ce qui tourne sur ce port. Prendre quelques minutes pour faire cette soumission permettra à tout le monde de bénéficier de votre découverte. Grâce à ces soumissions, Nmap dispose d'environ 3 000 empreintes de référence liées à plus de 350 protocoles, comme smtp, ftp et http.
LA DÉTECTION DE VERSION EST ACTIVÉE ET CONTRÔLÉE GRÂCE AUX OPTIONS SUIVANTES:
-sV (Détection de version) :
Active la détection de version, tel que discuté ci-dessus. Autrement, vous pouvez utiliser l'option -A pour activer à la fois la détection de version et celle du système d'exploitation.
--allports (tous les ports) (N'exclut aucun port de la détection de version) :
Par défaut, la détection de version de Nmap évite le port TCP 9100 car certaines imprimantes impriment tout bonnement tout ce qui est envoyé sur ce port, ce qui conduit à l'impression de douzaines de pages de requêtes HTTP, des requêtes de sessions SSL en binaire, etc. (ce qui est particulièrement furtif). Ce comportement peut être changé en modifiant ou en supprimant la directive Exclude du fichier nmap-service-probes, ou en spécifiant l'option --allports pour scanner tous les ports sans tenir compte d'aucune directive Exclude.
--version-intensity (Sélectionne l'intensité du scan de version) :
Lors d'un scan de version (-sV), Nmap envoie une série de paquets de tests, à chacun duquel est associé une valeur de rareté allant de 1 à 9. Les tests aux basses valeurs sont efficaces pour une grande variété de services courants, tandis que les hautes valeurs indiquent ceux qui ne sont que rarement utiles. Le niveau d'intensité spécifie quels tests doivent être effectués. Plus la valeur est haute, plus le service a de chances d'être correctement identifié. Cependant, ces scans-ci sont plus longs. La valeur d'intensité doit être comprise entre 0 et 9, la valeur par défaut étant le 7. Quand un test est inscrit sur le port cible par le biais de la directive nmap-service-probes ports, ce test est tenté quelque soit le niveau d'intensité. Cela permet de s'assurer que les tests DNS seront toujours tentés sur chaque port 53 ouvert, les tests SSL sur chaque 443, etc.
--version-light (Active le mode léger) :
Il s'agit d'un raccourci pour --version-intensity 2. Ce mode léger rend le scan de version bien plus rapide, mais il est un peu moins susceptible d'identifier les services.
--version-all (Essaie chaque test possible) :
Il s'agit d'un raccourci pour--version-intensity 9forçant chaque test unitaire à être testé contre chaque port.
--version-trace (Trace l'activité du scan de version) :
Ceci force Nmap à afficher un nombre considérable d'informations de débogage à propos de ce que fait le scan de version. Il s'agit d'un sous-ensemble de ce que vous obtenez avec l'option --packet-trace.
-sR (Scan RPC) :
Cette méthode fonctionne conjointement avec les différentes méthodes de scan de Nmap. Il prend tous les ports TCP/UDP ouverts et les submerge avec les commandes NULL du programme SunRPC dans le but de déterminer s'il s'agit de ports RPC, et le cas échéant, de quel programme et quel numéro de version il s'agit. Vous pouvez aussi obtenir les mêmes informations avec rpcinfo -p, et ce, même si le mapper de port (portmapper) de la cible se trouve derrière un pare-feu (ou protégé par des wrappers TCP). Les leurres ne fonctionnent pas avec le scan RPC. Cette option est automatiquement activée par le scan de version (-sV). Comme la détection de version inclus le scan RPC, et est bien plus complète, on a rarement besoin de l'option -sR.
DÉTECTION DE SYSTÈMES D'EXPLOITATION
L'une des fonctions les plus connues de Nmap est la détection de systèmes d'exploitation utilisant la prise d'empreinte de la pile TCP/IP. Nmap envoie une série de paquets TCP et UDP à l'hôte distant puis examine presque chaque bit des réponses. Après quelques douzaines de tests comme l'échantillonnage des séquences TCP (ISN sampling), l'ordonnancement et le support d'options TCP, l'échantillonnage IPID et la vérification de la taille initiale de fenêtre, Nmap compare les résultats avec sa base de données d'empreintes,nmap-os-fingerprints contenant plus de 1 500 empreintes de systèmes d'exploitation connus afin d'afficher finalement ses conclusions s'il trouve correspondance.
Chaque empreinte contient une description en texte libre du système d'exploitation ainsi qu'une classification qui fournit le nom du développeur (p. ex. : Sun), le système proprement dit (p. ex. : Solaris), sa génération (p. ex. : 10) et le type d'interface (généraliste, routeur, switch, console de jeu, etc.).
Si Nmap n'est pas capable de déterminer le système d'exploitation d'une machine et si les conditions sont acceptables (p. ex. : au moins un port ouvert et un port fermé ont été trouvés), Nmap fournira une adresse URL que vous pouvez utiliser afin de transmettre cette empreinte si vous connaissez avec certitude le système d'exploitation qui tourne sur cette machine. Ce faisant, vous contribuez grandement au panel de systèmes d'exploitation reconnus par Nmap et lui permettez d'être plus performant pour chacun.
La détection du système d'exploitation met en oeuvre un certain nombre de tests annexes utilisés de toute façon durant le processus global. L'un d'eux est la mesure de l'uptime, qui utilise l'option TCP timestamp (RFC 1323) afin de déterminer si une machine a été redémarrée récemment. Il n'en est fait mention que dans le cas où cette machine fournie cette information. Un autre test consiste en la Classification de la Prédictabilité de Séquence TCP (TCP Sequence Predictability Classification) qui mesure approximativement la difficulté d'établir une connexion en TCP forgée préalablement en direction de l'hôte distant. Ce test est utile dans le cas d'exploitation de la relation de confiance basée sur l'IP (cas du rlogin, des filtres de pare-feux, etc.) ou dans le but de cacher la source d'une attaque. Ce genre de mystification (spoofing) est rarement effectué quoi qu'il en soit, mais beaucoup de machines y sont toujours sensibles. La valeur indiquant la difficulté est basée sur un échantillonnage statistique et peut ainsi varier. Il est préférable d'employer une classification anglo-saxonne telle que "worthy challenge" , vraiment difficile, ou "trivial joke", qui est très facile. Ceci n'est indiqué dans une sortie de type normale qu'en mode verbeux (verbose mode, -v). Lorsque le mode verbeux est utilisé avec l'option -O, la génération de séquence IPID est aussi précisée. La plupart des machines sont de classe incrémentielle, "incremental", ce qui signifie qu'elles incrémentent le champ ID de l'en-tête IP pour chaque paquet qu'elles envoient. Ceci les rend vulnérables à différentes techniques avancées de collecte d'informations et de mystification (usurpation d'identité).
Un article décrivant l'usage, le réglage et le fonctionnement de la détection de version est disponible dans plus d'une douzaine de langues sur le site http://www.insecure.org/nmap/osdetect/
LA DÉTECTION DE SYSTÈMES D'EXPLOITATION EST ACTIVÉE ET CONTRÔLÉE AVEC LES OPTIONS SUIVANTES :
-O (Active la détection du système d'exploitation) :
Active la détection du système d'exploitation, tel que discuté ci-dessus. Vous pouvez aussi utiliser l'option -A pour activer à la fois la détection du système d'exploitation et la détection de la version.
--osscan-limit (Limite la détection du système d'exploitation aux cibles potentielles) :
La détection du système d'exploitation est bien plus efficace si au moins un port ouvert et un port fermé sont trouvés. Utilisez cette option et Nmap ne tentera pas d'effectuer la détection contre des hôtes qui ne remplissent pas cette condition. Ceci peut faire gagner pas mal de temps, particulièrement dans le cas de scans -P0 contre de nombreux hôtes. C'est évidemment seulement important lorsque la détection du système d'exploitation est demandée au moyen de l'option -O ou -A.
--osscan-guess ou --fuzzy (Prédire un résultat de détection du système d'exploitation) :
Lorsque Nmap est incapable de trouver une correspondance parfaite pour le système d'exploitation, il propose souvent les correspondances les plus proches. La correspondance doit être très proche afin que Nmap puisse effectuer cette procédure par défaut. L'une ou l'autre de ces options (équivalentes) force Nmap à être plus agressif dans sa prédiction.
Exemple : nmap --osscan_guess -sS -O -p 19-26 -n -P0 89.219.XXX.XX
A noter, nmap est en ligne de commande et est multi-plateforme. Il est aussi disponible en GUI (interface graphique), il s'appelle alors Zenmap (également multi-plateforme).
Vous pouvez le télécharger directement sur le site officiel de NMAP :
http://nmap.org/download.html