Cette forme dégénérée de découverte d'hôtes liste simplement chaque hôte du(des) réseau(x) spécifié(s), sans envoyer aucun paquet aux cibles. Par défaut, Nmap utilise toujours la résolution DNS inverse des hôtes pour connaître leurs noms. Il est souvent étonnant de constater combien ces simples informations peuvent être utiles. Par exemple, fw.chi.playboy.com est le pare-feu du bureau de Chicago de Playboy Enterprises. Nmap rend également compte du nombre total d'adresses IP à la fin de son rapport. Cette simple liste est un bon test pour vous assurer que vos adresses IP cibles sont les bonnes. Si jamais ces noms de domaines ne vous disent rien, il vaudrait mieux s'arrêter là afin d'éviter de scanner le réseau de la mauvaise entreprise.

Comme l'idée est de simplement afficher une liste des cibles, les options de fonctionnalités plus haut niveau comme le scan de ports, la détection du système d'exploitation ou la découverte des hôtes ne peuvent pas être combinées avec la liste simple. Si vous voulez juste désactiver la découverte des hôtes mais quand même effectuer des opérations de plus haut niveau, lisez sur l'option -P0.

Cette option indique à Nmap de n'effectuer que le scan ping (la découverte des hôtes), puis d'afficher la liste des hôtes disponibles qui ont répondu au scan. Aucun autre test (comme le scan des ports ou la détection d'OS) n'est effectué. Ce scan est légèrement plus intrusif que la simple liste, et peut souvent être utilisé dans le même but. Il permet un survol d'un réseau cible sans trop attirer l'attention. Savoir combien d'hôtes sont actifs est plus précieux pour un attaquant que la simple liste de chaque IP avec son nom d'hôte.

Les gestionnaires des systèmes apprécient également cette option. Elle peut facilement être utilisée pour compter le nombre de machines disponibles sur un réseau ou pour contrôler la disponibilité d'un serveur. Cette option est souvent appelée « balayage ping » (ping sweep). Elle est plus fiable que sonder par ping l'adresse de diffusion (broadcast) car beaucoup d'hôtes ne répondent pas à ces requêtes.

L'option -sP envoie une requête d'echo ICMP et un paquet TCP sur le port par défaut (80). Lorsqu'exécutée par un utilisateur non-privilégié, un paquet SYN est envoyé (en utilisant l'appel système connect()) sur le port 80 de la cible. Lorsqu'un utilisateur privilégié essaie de scanner des cibles sur un réseau local Ethernet, des requêtes ARP (-PR) sont utilisées à moins que l'option --send-ipsoit spécifiée. L'option -sP peut être combinée avec chacun des tests de découverte des hôtes (les options -P*, sauf -P0) pour une plus grand flexibilité. Dès qu'un test de ce type est utilisé avec un numéro de port, il est prépondérante sur les tests par défaut (ACK et requête echo). Quand des pare-feux restrictifs sont présents entre la machine exécutant Nmap et le réseau cible, il est recommandé d'utiliser ces techniques avancées. Sinon des hôtes peuvent être oubliés quand le pare-feu rejète les paquets ou leurs réponses.

Cette option évite complètement l'étape de découverte des hôtes de Nmap. En temps normal, Nmap utilise cette étape pour déterminer quelles sont les machines actives pour effectuer un scan approfondi. Par défaut, Nmap n'examine en profondeur, avec le scan des ports ou la détection de version, que les machines qui sont actives. Désactiver la détection des hôtes avec l'option -P0conduit Nmap à effectuer les scans demandés sur toutes les adresses IP cibles spécifiées. Ainsi, si une adresse IP de classe B (/16) est spécifiée à la ligne de commande, toutes les 65 536 adresses IP seront scannées. Le deuxième caractère dans l'option -P0 est bien un zéro et non pas la lettre O. La découverte des hôtes est évitée comme avec la liste simple, mais au lieu de s'arrêter et d'afficher la liste des cibles, Nmap continue et effectue les fonctions demandées comme si chaque adresse IP était active. Pour les machines sur un reseau local en ethernet, un scan ARP scan sera quand même effectué (à moins que --send-ip ne soit spécifié) parceque Nmap a besoin de l'adresse MAC pour les scans ulterieurs. Cette option s'appelait P0 (avec un zéro) auparavant, mais a été renommée afin d'éviter la confusion avec le Ping par protocoles PO (lettre O).

Cette option envoie un paquet TCP vide avec le drapeau (flag) SYN activé. La destination par défaut de ce paquet est le port 80 (configurable à la compilation en changeant la définition DEFAULT_TCP_PROBE_PORT dans nmap.h  ), mais un autre port peut être spécifié en paramètre (ex.:  -PS22,23,25,80,113,1050,35000), auquel cas les paquets de tests (probes) seront envoyés en parallèle sur chaque port cible.

Le drapeau SYN fait croire que vous voulez établir une connexion sur le système distant. Si le port de destination est fermé, un paquet RST (reset) est renvoyé. Si le port s'avère être ouvert, la cible va entamer la seconde étape de l'établissement de connexion TCP en 3 temps (TCP 3-way-handshake) en répondant par un paquet TCP SYN/ACK. La machine exécutant Nmap avortera alors la connexion en cours d'établissement en répondant avec un paquet RST au lieu d'un paquet ACK qui finaliserait normalement l'établissement de la connexion. Le paquet RST est envoyé par le noyau (kernel) de la machine exécutant Nmap en réponse au paquet SYN/ACK inattendu; ce n'est pas Nmap lui-même qui l'émet.

Nmap ne tient pas compte si le port est réellement ouvert ou fermé. Les paquets RST ou SYN/ACK évoqués précédemment indiquent tout deux que l'hôte est disponible et réceptif.

Sur les systèmes UNIX, seuls les utilisateurs privilégiés root sont généralement capables d'envoyer et de recevoir des paquets TCP bruts (raw packets). Pour les utilisateurs non-privilégiés, Nmap contourne cette restriction avec l'appel système connect() utilisé sur chaque port de la cible. Ceci revient à envoyer un paquet SYN sur l'hôte cible pour établir une connexion. Si connect() réussi ou échoue avec ECONNREFUSED, la pile TCP/IP sous-jacente doit avoir reçu soit un SYN/ACK soit un RST et l'hôte est alors considéré comme étant actif. Si la tentative de connexion est toujours en cours jusqu'à l'expiration du délai d'établissement, l'hôte est considéré comme étant inactif. Cette technique est aussi utilisée pour les connexions IPv6, du fait que les paquets bruts IPv6 ne sont pas encore supportés par Nmap.

Le ping TCP ACK ressemble fortement aux tests SYN précédemment évoqués. À la différence que, comme on l'imagine bien, le drapeau TCP ACK est utilisé à la place du drapeau SYN. Un tel paquet ACK acquitte normalement la réception de données dans une connexion TCP précédemment établie, or ici cette connexion n'existe pas. Ainsi, l'hôte distant devrait systématiquement répondre par un paquet RST qui trahirait son existence.

L'option -PA utilise le même port par défaut que le test SYN (80), mais peut aussi prendre une liste de ports de destination dans le même format. Si un utilisateur non-privilégié essaie cette option, ou si une cible IPv6 est spécifiée, la technique connect() précédemment évoquée est utilisée. Cette technique est imparfaite car connect() envoie un paquet SYN et pas un ACK.

La raison pour laquelle Nmap offre à la fois les tests SYN et ACK est de maximiser les chances de contourner les pare-feux. De nombreux administrateurs configurent leurs routeurs et leurs pare-feux pour bloquer les paquets entrants SYN sauf ceux destinés aux services publics comme les sites Web de l'entreprise ou le serveur de messagerie. Ceci empêche les autres connexions entrantes dans l'organisation, tout en permettant un accès complet en sortie à l'Internet. Cette approche sans état de connexion est peu consommatrice des ressources des pare-feux/routeurs et est largement supportée dans les dispositifs de filtrage matériels ou logiciels. Le pare-feu logiciel Linux Netfilter/iptables par exemple propose l'option --syn qui implante cette approche sans état (stateless). Quand de telles règles de pare-feu sont mises en place, les paquets de tests SYN ( -PS) seront certainement bloqués lorsqu'envoyés sur des ports fermés. Dans ces cas là, les tests ACK contournent ces règles, prenant ainsi toute leur saveur.

Un autre type courant de pare-feux utilise des règles avec état de connexion (statefull) qui jettent les paquets inattendus. Cette fonctionnalité était à la base fréquente sur les pare-feux haut-de-gamme, mais elle s'est répandue avec le temps. Le pare-feu Linux Netfilter/iptables supporte ce mécanisme grâce à l'option --state qui catégorise les paquets selon les états de connexion. Un test SYN marchera certainement mieux contre ces systèmes, car les paquets ACK sont généralement considérés comme inattendus ou bogués et rejetés. Une solution à ce dilemme est d'envoyer à la fois des paquets de tests SYN et ACK en utilisant conjointement les options -PS et -PA.

Une autre option de découverte des hôtes est le ping UDP, qui envoie un paquet UDP vide (à moins que l'option   --data-length ne soit utilisée) aux ports spécifiés. La liste des ports est écrite dans le même format que les options -PS et -PA précédemment évoquées. Si aucun port n'est spécifié, le port par défaut est le 31338. Cette valeur par défaut peut être modifiée à la compilation en changeant la définition DEFAULT_UDP_PROBE_PORT dans le fichier nmap.h. Un numéro de port très peu courant est utilisé par défaut, car envoyer des paquets sur un port ouvert n'est que peu souhaitable pour ce type de scan particulier.

Lorsqu'on atteint un port fermé sur la cible, le test UDP s'attend à recevoir un paquet ICMP « port unreachable » en retour. Ceci indique à Nmap que la machine est active et disponible. De nombreuses autres erreurs ICMP, comme « host/network unreachable » ou « TTL exceeded » indiquent un hôte inactif ou inaccessible. Une absence de réponse est également interprétée de la sorte. Si un port ouvert est atteint, la majorité des services ignorent simplement ce paquet vide et ne répondent rien. Ceci est la raison pour laquelle le port par défaut du test est le 31338, qui n'a que très peu de chances d'être utilisé. Très peu de services, comme chargen, répondront à un paquet UDP vide, dévoilant ainsi à Nmap leur présence.

L'avantage principal de ce type de scan est qu'il permet de contourner les pare-feux et dispositifs de filtrage qui n'observent que TCP. Les routeurs sans-fil Linksys BEFW11S4 par exemple sont de ce type. L'interface externe de cet équipement filtre tous les ports TCP par défaut, mais les paquets de tests UDP se voient toujours répondre par des messages ICMP « port unreachable », rendant ainsi l'équipement désuet.

En plus des inhabituels types de découverte des hôtes TCP et UDP précédemment évoqués, Nmap peut également envoyer les paquets standard émis par l'éternel programme ping. Nmap envoie un paquet ICMP type 8 (echo request) aux adresses IP cibles, attendant un type 0 (echo reply) en provenance des hôtes disponibles. Malheureusement pour les explorateurs de réseaux, de nombreux hôtes et pare-feux bloquent désormais ces paquets, au lieu d'y répondre comme indiqué par la RFC 1122. Pour cette raison, les scans « purs ICMP » sont rarement fiables contre des cibles inconnues d'Internet. Cependant, pour les administrateurs surveillants un réseau local cette approche peut être pratique et efficace. Utilisez l'option -PE pour activer ce comportement de requête echo.

Même si la requête echo est le standard de la requête ICMP, Nmap ne s'arrête pas là, Le standard ICMP (RFC 792) spécifie également les requêtes « timestamp », « information » et « adress mask », dont les codes sont respectivement 13, 15 et 17. Si le but avoué de ces requêtes est d'obtenir des informations comme le masque réseau ou l'heure courante, elles peuvent facilement être utilisées pour la découverte des hôtes: un système qui y répond est actif et disponible. Nmap n'implante actuellement pas les requêtes d'informations, car elles ne sont que rarement supportées. La RFC 1122 insiste sur le fait « qu'un hôte ne DEVRAIT PAS implanter ces messages ». Les requêtes timestamp et masque d'adresse peuvent être émises avec les options -PP et -PM, respectivement. Une réponse timestamp (code ICMP 14) ou masque d'adresse (code ICMP 18) révèle que l'hôte est disponible. Ces deux requêtes peuvent être très utiles quand les administrateurs bloquent spécifiquement les requêtes echo mais oublient que les autres requêtes ICMP peuvent être utilisées dans le même but.

Un des usages les plus courant de Nmap est de scanner un LAN Ethernet. Sur la plupart des LANS, particulièrement ceux qui utilisent les plages d'adresses privées de la RFC 1918, la grande majorité des adresses IP sont inutilisées à un instant donné. Quand Nmap essaie d'envoyer un paquet IP brut (raw packet) comme une requête ICMP echo, le système d'exploitation doit déterminer l'adresse matérielle (ARP) correspondant à la cible IP pour correctement adresser la trame Ethernet. Ceci est souvent lent et problématique, car les systèmes d'exploitation n'ont pas été écrits pour gérer des millions de requêtes ARP contre des hôtes indisponibles en un court intervalle de temps.

Les requêtes ARP sont prises en charge par Nmap qui dispose d'algorithmes optimisés pour gérer le scan ARP. Si Nmap reçoit une réponse à ces requêtes, il n'a pas besoin de poursuivre avec les ping basés sur IP car il sait déjà que l'hôte est actif. Ceci rend le scan ARP bien plus rapide et fiable que les scans basés sur IP. Ainsi, c'est le comportement adopté par défaut par Nmap quand il remarque que les hôtes scannés sont sur le réseau local. Même si d'autres types de ping (comme -PE ou -PS) sont spécifiés, Nmap utilise ARP pour chaque cible qui sont sur le même sous-réseau que la machine exécutant Nmap. Si vous ne souhaitez vraiment pas utiliser le scan ARP, utilisez l'option --send-ip

Une autre otpion de découverte d'hôtes est le Ping IPProto, qui envoie des paquets IP avec les numéros de protocole(s) spécifiés dans le champ Protocol de l'en-tête IP. La liste des protocoles prend le même format qu'avec la liste des ports dans les options de découverte en TCP et UDP présentées précédement. Si aucun protocole n'est précisé, par défaut ce sont des paquets IP multiples ICMP (protocol 1), IGMP (protocol 2), et IP-in-IP (protocol 4) qui sont envoyés. Les protocoles par défaut peuvent être configurés à la compilation en changeant DEFAULT_PROTO_PROBE_PORT_SPEC dans nmap.h. Notez que pour ICMP, IGMP, TCP (protocol 6), et UDP (protocol 17), les paquets sont envoyés avec l'en-tête supplémentaire cependant que les autres protocoles sont envoyés sans données supplémentaires en sus de l'en-tête IP (à moins que l'option --data-length ne soit spécifiée).

Cette méthode de découverte des hôtes recherche les réponses dans le même protocole que la requète, ou le message ICMP Protocol Unreachable qui signifie que le protocole spécifié n'est pas supporté par l'hôte (ce qui implique indirectement qu'il est connecté).

Montre les raisons pour lesquelles chaque port est désigné par un état spécifique et un hôte connecté ou non. Cette option affiche le type de paquet qui à déterminé l'état du port ou de l'hôte. Par exemple, un paquet RST en provenance d'un port fermé ou un echo relpy pour un hôte connecté. L'information que Nmap peut fournir est déterminée par le type de scan ou de ping. Le scan SYN et le ping SYN (-sS et -PT) sont très détaillés, mais les TCP connect scan et ping (-sT) sont limités par l'implémentation de l'appel système connect. Cette fonctionnalité est automatiquement activée par le mode de deboguage (-d) et les résultats sont enregistrés dans la sortie XML même si cette option n'est pas spécifiée.

Indique à Nmap de ne jamais faire la résolution DNS inverse des hôtes actifs qu'il a trouvé. Comme la résolution DNS est souvent lente, ceci accélère les choses.

Indique à Nmap de toujoursfaire la résolution DNS inverse des adresses IP cibles. Normalement, ceci n'est effectué que si une machine est considérée comme active.

Par defaut Nmap va essayer de déterminer vos serveurs DNS (pour le résolution rDNS) depuis votre fichier resolv.conf (UNIX) ou le registre (Win32). En alternative, vous pouvez utiliser cette option pour spécifier des serveurs alternatifs. Cette option n'est pas honorée si vous utilisez --system-dns ou un scan IPv6 . Utiliser plusieurs serveurs DNS est souvent plus rapide, spécialement si vous utilisez les serveurs dédiés pour votre espace d'adresses cible. Cette option peut aussi améliorer la discretion, comme vos requètes peuvent être relayées par n'importe quel serveur DNS récursif sur Internet.

Cette option est aussi utile lors du scan de reseaux privés. Parfois seuls quelques serveurs de noms fournissent des informations rDNS propres, et vous pouvez même ne pas savoir où ils sont. Vous pouvez scanner le reseau sur le port 53 (peut être avec une détection de version), puis essayer un list scan (-sL) spécifiant chaque serveur de nom un a la fois avec --dns-servers jusqu'a en trouver un qui fonctionne.

Par défaut, Nmap résout les adresses IP en envoyant directement les requêtes aux serveurs de noms configurés sur votre machine et attend leurs réponses. De nombreuses requêtes (souvent des douzaines) sont effectuées en parallèle pour améliorer la performance. Spécifiez cette option si vous souhaitez utiliser la résolution de noms de votre système (une adresse IP à la fois par le biais de l'appel getnameinfo()). Ceci est plus lent est rarement utile à moins qu'il n'y ait une procédure erronée dans le code de Nmap concernant le DNS -- nous contacter s'il vous plaît dans cette éventualité. La résolution système est toujours utilisée pour les scans IPv6.