Free Press

-sL(List Scan)

Le list scan est une forme dégénérée de découverte d’hôtes qui liste simplement chaque hôte du ou des réseaux spécifiés, sans envoyer de paquets aux hôtes cibles. Par défaut, Nmap effectue toujours une résolution reverse-DNS sur les hôtes pour apprendre leurs noms. Il est souvent surprenant de voir combien d’informations utiles de simples noms d’hôtes peuvent donner. Par exemple, fw.chi est le nom du pare-feu d’une entreprise à Chicago. Nmap indique également le nombre total d’adresses IP à la fin. Le scan de la liste est un bon moyen de s’assurer que vous avez les bonnes adresses IP pour vos cibles. Si les hôtes portent des noms de domaine que vous ne reconnaissez pas, cela vaut la peine d’enquêter davantage pour éviter de scanner le réseau de la mauvaise entreprise.

Puisque l’idée est simplement d’imprimer une liste d’hôtes cibles, les options pour des fonctionnalités de plus haut niveau telles que le scan de ports, la détection d’OS ou la découverte d’hôtes ne peuvent pas être combinées avec cela. Si vous souhaitez désactiver la découverte des hôtes tout en continuant à effectuer ces fonctionnalités de plus haut niveau, lisez l’option -Pn (skip host discovery).

-sn(No port scan)

Cette option indique à Nmap de ne pas effectuer de scan de port après la découverte des hôtes, et d’imprimer uniquement les hôtes disponibles qui ont répondu aux sondes de découverte des hôtes. Ceci est souvent connu sous le nom de « scan ping », mais vous pouvez également demander que les scripts traceroute et NSE host soient exécutés. Cette méthode est par défaut un peu plus intrusive que le scan de liste, et peut souvent être utilisée dans le même but. Il permet une reconnaissance légère d’un réseau cible sans attirer beaucoup d’attention. Savoir combien d’hôtes sont en place est plus précieux pour les attaquants que la liste fournie par le scan de liste de chaque IP et nom d’hôte.

Les administrateurs de systèmes trouvent souvent cette option précieuse également. Elle peut facilement être utilisée pour compter les machines disponibles sur un réseau ou surveiller la disponibilité des serveurs. Ceci est souvent appelé un balayage ping, et est plus fiable que le ping de l’adresse de diffusion parce que de nombreux hôtes ne répondent pas aux requêtes de diffusion.

La découverte d’hôte par défaut effectuée avec -sn consiste en une demande d’écho ICMP, un SYN TCP vers le port 443, un ACK TCP vers le port 80, et une demande d’horodatage ICMP par défaut. Lorsqu’il est exécuté par un utilisateur non privilégié, seuls les paquets SYN sont envoyés (à l’aide d’un appel connect) aux ports 80 et 443 sur la cible. Lorsqu’un utilisateur privilégié tente d’analyser des cibles sur un réseau ethernet local, des requêtes ARP sont utilisées, sauf si --send-ip a été spécifié. L’option -sn peut être combinée avec l’un des types de sondes de découverte (les options -P*) pour une plus grande flexibilité. Si l’une de ces options de type de sonde et de numéro de port est utilisée, les sondes par défaut sont remplacées. Lorsque des pare-feu stricts sont en place entre l’hôte source exécutant Nmap et le réseau cible, l’utilisation de ces techniques avancées est recommandée. Sinon, des hôtes pourraient être manqués lorsque le pare-feu laisse tomber les sondes ou leurs réponses.

Dans les versions précédentes de Nmap, -sn était connu sous le nom de -sP.

-Pn(No ping)

Cette option saute complètement l’étape de découverte des hôtes. Normalement, Nmap utilise cette étape pour déterminer les machines actives pour un scan plus lourd et pour jauger la vitesse du réseau. Par défaut, Nmap n’effectue que des sondages lourds tels que le balayage des ports, la détection des versions ou la détection du système d’exploitation contre les hôtes qui sont trouvés actifs. En désactivant la découverte des hôtes avec -Pn, Nmap tente d’effectuer les fonctions d’analyse demandées sur chaque adresse IP cible spécifiée. Ainsi, si un réseau de taille /16 est spécifié sur la ligne de commande, les 65’536 adresses IP seront scannées. La découverte des hôtes est ignorée comme pour le scan par liste, mais au lieu de s’arrêter et d’imprimer la liste des cibles, Nmap continue à exécuter les fonctions demandées comme si chaque adresse IP cible était active. Les paramètres de temporisation par défaut sont utilisés, ce qui peut entraîner des scans plus lents. Pour sauter la découverte des hôtes et le balayage des ports, tout en permettant à NSE de fonctionner, utilisez les deux options -Pn -sn ensemble.

Pour les machines sur un réseau ethernet local, le balayage ARP sera toujours effectué (à moins que --disable-arp-ping ou --send-ip ne soit spécifié) car Nmap a besoin des adresses MAC pour poursuivre le balayage des hôtes cibles. Dans les versions précédentes de Nmap, -Pn était -P0 et -PN.

-PS <port list>(Ping TCP SYN)

Cette option envoie un paquet TCP vide avec le drapeau SYN activé. Le port de destination par défaut est 80 (configurable à la compilation en modifiant DEFAULT_TCP_PROBE_PORT_SPEC dans nmap.h). Des ports alternatifs peuvent être spécifiés en tant que paramètre. La syntaxe est la même que pour le -p, sauf que les spécificateurs de type de port comme T: ne sont pas autorisés. Les exemples sont -PS22 et -PS22-25,80,113,1050,35000. Notez qu’il ne peut y avoir d’espace entre -PS et la liste de ports. Si plusieurs sondes sont spécifiées, elles seront envoyées en parallèle.

Le drapeau SYN suggère au système distant que vous tentez d’établir une connexion. Normalement, le port de destination sera fermé, et un paquet RST (reset) sera renvoyé. Si le port est ouvert, la cible effectuera la deuxième étape de la poignée de main TCP en répondant avec un paquet TCP SYN/ACK. La machine qui exécute Nmap rompt alors la connexion naissante en répondant avec un RST au lieu d’envoyer un paquet ACK qui aurait complété la poignée de main à trois et établi une connexion complète. Le paquet RST est envoyé par le noyau de la machine exécutant Nmap en réponse au SYN/ACK inattendu, et non par Nmap lui-même.

Nmap ne se soucie pas de savoir si le port est ouvert ou fermé. Soit la réponse RST ou SYN/ACK discutée précédemment indique à Nmap que l’hôte est disponible et réactif.

Sur les boîtes Unix, seul l’utilisateur privilégié root est généralement capable d’envoyer et de recevoir des paquets TCP bruts. Pour les utilisateurs non privilégiés, une solution de contournement est automatiquement employée par laquelle l’appel système connect est lancé contre chaque port cible. Ceci a pour effet d’envoyer un paquet SYN à l’hôte cible, dans une tentative d’établir une connexion. Si connect revient avec un succès rapide ou un échec ECONNREFUSED, la pile TCP sous-jacente doit avoir reçu un SYN/ACK ou un RST et l’hôte est marqué comme étant disponible. Si la tentative de connexion est laissée en suspens jusqu’à ce qu’un délai d’attente soit atteint, l’hôte est marqué comme down.

-PA <port list>(TCP ACK Ping)

Le TCP ACK ping est assez similaire au SYN ping dont on vient de parler. La différence, comme vous pouvez probablement le deviner, est que le drapeau TCP ACK est activé au lieu du drapeau SYN. Un tel paquet ACK prétend accuser réception de données sur une connexion TCP établie, mais cette connexion n’existe pas. Ainsi, les hôtes distants devraient toujours répondre avec un paquet RST, révélant leur existence dans le processus.

L’option -PA utilise le même port par défaut que la sonde SYN (80) et peut également prendre une liste de ports de destination dans le même format. Si un utilisateur non privilégié essaie ceci, la solution de contournement connect discutée précédemment est utilisée. Cette solution de contournement est imparfaite car connect envoie en fait un paquet SYN plutôt qu’un ACK.

La raison pour laquelle on propose des sondes ping SYN et ACK est de maximiser les chances de contourner les pare-feu. De nombreux administrateurs configurent les routeurs et autres pare-feu simples pour bloquer les paquets SYN entrants, à l’exception de ceux destinés à des services publics comme le site Web de l’entreprise ou le serveur de messagerie. Cela empêche les autres connexions entrantes vers l’organisation, tout en permettant aux utilisateurs d’établir des connexions sortantes sans entrave vers l’Internet. Cette approche non conditionnelle nécessite peu de ressources sur le pare-feu/routeur et est largement prise en charge par les filtres matériels et logiciels. Le logiciel de pare-feu Linux Netfilter/iptables offre l’option de commodité --syn pour mettre en œuvre cette approche sans état. Lorsque des règles de pare-feu sans état telles que celle-ci sont en place, les sondes ping SYN (-PS) sont susceptibles d’être bloquées lorsqu’elles sont envoyées à des ports cibles fermés. Dans de tels cas, la sonde ACK brille car elle passe directement à travers ces règles.

Un autre type commun de pare-feu utilise des règles stateful qui abandonnent les paquets inattendus. Cette fonctionnalité se trouvait initialement surtout sur les pare-feu haut de gamme, bien qu’elle soit devenue beaucoup plus courante au fil des ans. Le système Linux Netfilter/iptables la prend en charge par le biais de l’option --state, qui catégorise les paquets en fonction de l’état de la connexion. Une sonde SYN a plus de chances de fonctionner contre un tel système, car les paquets ACK inattendus sont généralement reconnus comme faux et abandonnés. Une solution à ce dilemme est d’envoyer à la fois des sondes SYN et ACK en spécifiant -PS et -PA.

-PU <port list>(UDP Ping)

Une autre option de découverte d’hôte est le ping UDP, qui envoie un paquet UDP aux ports donnés. Pour la plupart des ports, le paquet sera vide, bien que certains utilisent une charge utile spécifique au protocole qui est plus susceptible de susciter une réponse.Voir la section intitulée « Charges utiles UDP : nmap-payloads » pour une description de la base de données des charges utiles.Le contenu du paquet peut également être affecté avec les options --data,--data-string, et --data-length.

La liste des ports prend le même format qu’avec les options -PS et -PA discutées précédemment. Si aucun port n’est spécifié, la valeur par défaut est 40125. Ce défaut peut être configuré à la compilation en modifiant DEFAULT_UDP_PROBE_PORT_SPEC dans nmap.h. Un port très peu commun est utilisé par défaut parce que l’envoi vers des ports ouverts est souvent indésirable pour ce type de scan particulier.

Si elle touche un port fermé sur la machine cible, la sonde UDP devrait susciter un paquet ICMP port unreachable en retour. Cela signifie à Nmap que la machine est opérationnelle et disponible. De nombreux autres types d’erreurs ICMP, tels que host/network unreachables ou TTL exceeded, indiquent un hôte hors service ou inaccessible. Une absence de réponse est également interprétée de cette manière. Si un port ouvert est atteint, la plupart des services ignorent simplement le paquet vide et ne renvoient aucune réponse. C’est pourquoi le port de sonde par défaut est 40125, qui a très peu de chances d’être utilisé. Quelques services, comme le protocole Character Generator (chargen), répondront à un paquet UDP vide, et révéleront ainsi à Nmap que la machine est disponible.

Le principal avantage de ce type de scan est qu’il contourne les pare-feu et les filtres qui ne filtrent que le TCP. Par exemple, j’ai déjà possédé un routeur sans fil à large bande Linksys BEFW11S4. L’interface externe de ce périphérique filtrait tous les ports TCP par défaut, mais les sondes UDP suscitaient toujours des messages de port inaccessible et trahissaient ainsi le périphérique.

-PY <port list>(SCTP INIT Ping)

Cette option envoie un paquet SCTP contenant un chunk INIT minimal. Le port de destination par défaut est 80 (configurable à la compilation en modifiant DEFAULT_SCTP_PROBE_PORT_SPEC dans nmap.h). Des ports alternatifs peuvent être spécifiés en tant que paramètre. La syntaxe est la même que pour le -p, sauf que les spécificateurs de type de port comme S: ne sont pas autorisés. Les exemples sont -PY22 et -PY22,80,179,5060. Notez qu’il ne peut y avoir d’espace entre -PY et la liste de ports. Si plusieurs sondes sont spécifiées, elles seront envoyées en parallèle.

Le chunk INIT suggère au système distant que vous tentez d’établir une association. Normalement, le port de destination sera fermé, et un chunk ABORT sera renvoyé. Si le port est ouvert, la cible effectuera la deuxième étape d’un échange de mains SCTP en répondant avec un chunk INIT-ACK. Si la machine qui exécute Nmap a une pile SCTP fonctionnelle, alors elle détruit l’association naissante en répondant avec un paquet ABORT plutôt que d’envoyer un paquet COOKIE-ECHO qui serait l’étape suivante de la prise de contact à quatre. Le paquet ABORT est envoyé par le noyau de la machine exécutant Nmap en réponse à l’INIT-ACK inattendu, et non par Nmap lui-même.

Nmap ne se soucie pas de savoir si le port est ouvert ou fermé. Soit la réponse ABORT ou INIT-ACK discutée précédemment indique à Nmap que l’hôte est disponible et réactif.

Sur les boîtes Unix, seul l’utilisateur privilégié root est généralement capable d’envoyer et de recevoir des paquets SCTP bruts. L’utilisation de SCTP INIT Pings n’est actuellement pas possible pour les utilisateurs non privilégiés.

-PE;-PP;-PM(Types de ping ICMP)

En plus des types inhabituels de découverte d’hôte TCP, UDP et SCTP discutés précédemment, Nmap peut envoyer les paquets standards envoyés par l’omniprésent programme ping. Nmap envoie un paquet ICMP de type 8 (requête d’écho) aux adresses IP cibles, attendant en retour un type 0 (réponse d’écho) des hôtes disponibles. Malheureusement pour les explorateurs de réseaux, de nombreux hôtes et pare-feu bloquent maintenant ces paquets, plutôt que de répondre comme l’exige la RFC 1122. Pour cette raison, les analyses uniquement ICMP sont rarement assez fiables contre les cibles inconnues sur Internet. Mais pour les administrateurs système qui surveillent un réseau interne, ils peuvent constituer une approche pratique et efficace. Utilisez l’option -PE pour activer ce comportement de demande d’écho.

Bien que la demande d’écho soit la requête ping ICMP standard, Nmap ne s’arrête pas là. Les normes ICMP (RFC 792 et RFC 950 ) spécifient également les paquets de demande d’horodatage, de demande d’information et de demande de masque d’adresse sous les codes 13, 15 et 17, respectivement. Bien que le but apparent de ces requêtes soit d’obtenir des informations telles que les masques d’adresse et les heures actuelles, elles peuvent facilement être utilisées pour la découverte d’hôtes. Un système qui répond est opérationnel et disponible. Nmap n’implémente pas actuellement les paquets de demande d’information, car ils ne sont pas largement supportés. La RFC 1122 insiste sur le fait que « un hôte NE DEVRAIT PAS implémenter ces messages ». Les requêtes d’horodatage et de masque d’adresse peuvent être envoyées avec les options -PP et -PM, respectivement. Une réponse d’horodatage (code ICMP 14) ou une réponse de masque d’adresse (code 18) révèle que l’hôte est disponible. Ces deux requêtes peuvent être précieuses lorsque les administrateurs bloquent spécifiquement les paquets de demande d’écho en oubliant que d’autres requêtes ICMP peuvent être utilisées dans le même but.

-PO <protocol list>(IP Protocol Ping)

L’une des options de découverte d’hôte les plus récentes est l’IP protocol ping, qui envoie des paquets IP avec le numéro de protocole spécifié défini dans leur en-tête IP. La liste de protocole prend le même format que les listes de port dans les options de découverte d’hôte TCP, UDP et SCTP discutées précédemment. Si aucun protocole n’est spécifié, le défaut est d’envoyer plusieurs paquets IP pour ICMP (protocole 1), IGMP (protocole 2), et IP-in-IP (protocole 4). Les protocoles par défaut peuvent être configurés au moment de la compilation en modifiant DEFAULT_PROTO_PROBE_PORT_SPEC dans nmap.h. Notez que pour l’ICMP, l’IGMP, le TCP (protocole 6), l’UDP (protocole 17) et le SCTP (protocole 132), les paquets sont envoyés avec les en-têtes de protocole appropriés tandis que les autres protocoles sont envoyés sans données supplémentaires au-delà de l’en-tête IP (sauf si l’une des options --data, --data-string ou --data-length est spécifiée).

Cette méthode de découverte d’hôte recherche soit des réponses utilisant le même protocole qu’une sonde, soit des messages ICMP protocol unreachable qui signifient que le protocole donné n’est pas supporté sur l’hôte de destination. L’un ou l’autre type de réponse signifie que l’hôte cible est vivant.

--disable-arp-ping(Pas de ping ARP ou ND)

Nmap effectue normalement la découverte ARP ou IPv6 Neighbor Discovery (ND) des hôtes ethernet connectés localement, même si d’autres options de découverte d’hôte telles que -Pn ou -PE sont utilisées. Pour désactiver ce comportement implicite, utilisez l’option --disable-arp-ping.

Le comportement par défaut est normalement plus rapide, mais cette option est utile sur les réseaux utilisant le proxy ARP, dans lequel un routeur répond de manière spéculative à toutes les requêtes ARP, faisant en sorte que chaque cible semble être en marche selon le scan ARP.

--discovery-ignore-rst

Dans certains cas, les pare-feu peuvent usurper les réponses de réinitialisation TCP (RST) en réponse aux sondes vers des adresses inoccupées ou non autorisées. Puisque Nmap considère ordinairement les réponses RST comme une preuve que la cible est en place, cela peut conduire à une perte de temps pour scanner des cibles qui ne sont pas là. L’utilisation de --discovery-ignore-rst empêchera Nmap de prendre en compte ces réponses lors de la découverte des hôtes. Vous pouvez avoir besoin de sélectionner des options supplémentaires de découverte d’hôte pour vous assurer de ne pas manquer de cibles dans ce cas.

--traceroute(Tracer le chemin vers l’hôte)

Les traceroutes sont effectuées post-scan en utilisant les informations des résultats du scan pour déterminer le port et le protocole les plus susceptibles d’atteindre la cible. Il fonctionne avec tous les types de scans sauf les scans de connexion (-sT) et les scans d’inactivité (-sI). Toutes les traces utilisent le modèle de timing dynamique de Nmap et sont exécutées en parallèle.

Traceroute fonctionne en envoyant des paquets avec un TTL (time-to-live) faible pour tenter de susciter des messages ICMP Time Exceeded à partir de sauts intermédiaires entre le scanner et l’hôte cible. Les implémentations standard de traceroute commencent avec un TTL de 1 et incrémentent le TTL jusqu’à ce que l’hôte de destination soit atteint. Le traceroute de Nmap commence avec un TTL élevé et décrémente ensuite le TTL jusqu’à ce qu’il atteigne zéro. Le faire à l’envers permet à Nmap d’utiliser des algorithmes de cache intelligents pour accélérer les traces sur plusieurs hôtes. En moyenne, Nmap envoie 5 à 10 paquets de moins par hôte, selon les conditions du réseau. Si un seul sous-réseau est scanné (i.e. 192.168.0.0/24), Nmap peut n’avoir à envoyer que deux paquets à la plupart des hôtes.

-n(No DNS resolution)

Indique à Nmap de ne jamais faire de résolution DNS inverse sur les adresses IP actives qu’il trouve. Puisque le DNS peut être lent, même avec le résolveur parallèle intégré de Nmap, cette option peut réduire les temps d’analyse.

-R(Résolution DNS pour toutes les cibles)

Dit à Nmap de toujours faire une résolution DNS inverse sur les adresses IP cibles. Normalement, la résolution DNS inverse n’est effectuée que contre les hôtes réactifs (en ligne).

--resolve-all(Scan de chaque adresse résolue)

Si une cible de nom d’hôte se résout à plus d’une adresse, scannez-les toutes. Le comportement par défaut consiste à ne scanner que la première adresse résolue. Indépendamment, seules les adresses de la famille d’adresses appropriée seront analysées : IPv4 par défaut, IPv6 avec -6.

--system-dns(Utiliser le résolveur DNS du système)

Par défaut, Nmap effectue une résolution inverse des adresses IP en envoyant des requêtes directement aux serveurs de noms configurés sur votre hôte, puis en écoutant les réponses. De nombreuses requêtes (souvent des dizaines) sont effectuées en parallèle pour améliorer les performances. Spécifiez cette option pour utiliser votre résolveur système à la place (une IP à la fois via l’appel getnameinfo). C’est plus lent et rarement utile, à moins que vous ne trouviez un bug dans le résolveur parallèle de Nmap (merci de nous le faire savoir si c’est le cas). Le résolveur système est toujours utilisé pour les forward lookups (obtenir une adresse IP à partir d’un nom d’hôte).

--dns-servers <server1>] (Serveurs à utiliser pour les requêtes DNS inversées)

Par défaut, Nmap détermine vos serveurs DNS (pour la résolution rDNS) à partir de votre fichier resolv.conf (Unix) ou du Registre (Win32). Alternativement, vous pouvez utiliser cette option pour spécifier des serveurs alternatifs. Cette option n’est pas honorée si vous utilisez --system-dns. L’utilisation de plusieurs serveurs DNS est souvent plus rapide, surtout si vous choisissez des serveurs faisant autorité pour votre espace IP cible. Cette option peut également améliorer la furtivité, car vos requêtes peuvent être rebondies sur à peu près n’importe quel serveur DNS récursif sur Internet.

Cette option est également utile lors de l’analyse de réseaux privés. Parfois, seuls quelques serveurs de noms fournissent des informations rDNS correctes, et vous ne savez peut-être même pas où ils se trouvent. Vous pouvez scanner le réseau pour le port 53 (peut-être avec une détection de version), puis essayer des scans de liste Nmap (-sL) en spécifiant chaque serveur de noms un par un avec --dns-servers jusqu’à ce que vous en trouviez un qui fonctionne.

Cette option pourrait ne pas être honorée si la réponse DNS dépasse la taille d’un paquet UDP. Dans une telle situation, notre résolveur DNS fera le meilleur effort pour extraire une réponse du paquet tronqué, et en cas d’échec, il se rabattra sur l’utilisation du résolveur système. De même, les réponses qui contiennent des alias CNAME seront renvoyées au résolveur du système.