Nmap peut scanner des ports ou faire un scan de version sur de multiples hôtes en parallèle. Pour ce faire, Nmap divise la plage des adresses IP des cibles en groupe puis scanne ces groupes un à la fois. En général, scanner un grand nombre de groupes améliore l'efficacité de la procédure. En contrepartie, les résultats ne peuvent être fournis que lorsque tout le groupe d'hôtes a été scanné. Par conséquent, si Nmap a commencé avec un groupe de 50, l'utilisateur ne recevra aucun résultat tant que les premiers 50 hôtes ne seront pas terminés (exception faite des informations données en mode verbeux).

Par défaut, Nmap adopte un compromis dans son approche de ce conflit. Il commence avec une quantité aussi petite que 5 groupes de façon à obtenir rapidement les premiers résultats et augmente ensuite la quantité de groupes jusqu'à un maximum de1 024. Les valeurs exactes par défaut dépendent des options configurées. Par soucis d'efficacité, Nmap utilise une quantité de groupes plus grande lorsqu'il s'agit de scans UDP ou sur peu de ports en TCP.

Lorsqu'un maximum est spécifié en quantité de groupes avec l'option --max-hostgroup, Nmap ne va jamais dépasser cette valeur. Spécifiez une quantité minimale avec l'option --min-hostgroup et Nmap tentera de garder la quantité de groupes au-dessus de cette valeur. Nmap devra peut-être utiliser des groupes plus petits que ceux que vous demandez s'il n'y a plus assez d'hôtes cibles sur une interface donnée par rapport au minimum que vous avez spécifié Les deux valeurs doivent être déterminés pour de conserver la quantité de groupes dans une plage spécifique, quoique ceci ne soit que rarement souhaité.

Le premier usage de ces options est de spécifier un minimum assez grand pour que le scan entier se fasse plus vite. Un choix fréquent est 256 pour scanner un réseau de Classe C. S'il s'agit d'un scan incluanrt beaucoup de ports, dépasser cette valeur n'aidera pas à grand chose. S'il s'agit de scans sur peu de ports, une quantité de groupes de 2 048 ou plus peut faciliter la procédure.

Ces options permettent de contrôler le nombre total de probes idéal pour un groupe d'hôtes. Elles permettent de scanner des ports et de découvrir des hôtes (host discovery). Par défaut, Nmap calcule un parallélisme idéal et variable basé sur les performances du réseau. Si des paquets sont rejetés, Nmap ralentit sa cadence en permettant moins de probes simultanés. Le nombre idéal de probes augmente graduellement en même temps que le réseau démontre ses performances. Ces options fixent les limites maximales et minimales selon cette variable. Par défaut, le parallélisme idéal peut chuter à 1 si le réseau s'avère trop faible et monter à plusieurs centaines dans des conditions parfaites.

L'usage habituel consiste à régler l'option --min-parallelism à une valeur supérieure à 1 pour accélérer les scans sur des réseaux de faible performance. Il est risqué de trop modifier cette option puisqu'établir une valeur trop élevée peut affecter la précision des résultats. Modifier cette option réduit aussi la capacité de Nmap à contrôler le parallélisme de façon dynamique selon les conditions du réseau. Une valeur de 10 peut être raisonnable bien que je n'ajuste personnellement celle-ci qu'en dernier ressort.

L'option --max-parallelism est parfois réglée à 1 afin d'éviter d'envoyer plus d'un probe en même temps vers les hôtes. Ceci peut être intéressant en combinaison avec l'option --scan-delay (on verra plus tard), bien que cette option serve déjà elle-même à cet effet.

Nmap conserve une valeur de durée de vie qui détermine combien de temps il devra attendre avant d'envoyer une réponse à un probe avant de l'abandonner ou de le renvoyer. Cette valeur est calculée en fonction du temps de réponse des probes précédents. Si le temps de latence du réseau est significatif et variable, ce délai d'inactivité ou cette durée de vie, peut augmenter jusqu'à plusieurs secondes. Elle est également de niveau élevé et peut rester ainsi pendant un bon moment lorsque Nmap scanne des hôtes sans réponse.

Ces options acceptent des valeurs en millisecondes. Spécifier un --max-rtt-timeout et un --initial-rtt-timeout plus bas que ceux par défaut peuvent raccourcir le temps de scan de façon significative. C'est particulièrement vrai pour les scans sans ping préalable (-P0) et ceux contre des réseaux très filtrés. Toutefois, ne soyez pas trop agressif. Le scan peut se finir en un temps plus significatif si, au contraire, vous spécifiez des valeurs tellement basses que les durées de vie des probes sont terminées et ceux-ci renvoyés alors que leurs réponses sont en fait encore en transit.

Si tous les hôtes sont sur un réseau local, 100 millisecondes est une valeur de --max-rtt-timeout seront suffisantes. Si vous etes face a un routage, mesurez d'abord le temps de réponse d'un hôte sur le réseau \ l'aide du ping ICMP de Nmap ou d'un autre outil, comme hping2 qui est plus à même de passer un pare-feu si le paquet est spécialement forgé. Regardez les durées de transit sur 10 paquets ou plus. Vous pouvez doubler cette valeur pour --initial-rtt-timeout et tripler ou quadrupler le --max-rtt-timeout. Généralement, je ne règle pas le rtt maximum à moins de 100ms, et ce, quelles que soient les mesures de ping. De plus, je n'excède pas 1 000ms.

--min_rtt_timeout est une option rarement utilisée qui peut s'avérer utile lorsqu'un réseau est si lent que même les réglages par défaut de Nmap sont trop agressifs. Comme Nmap ne réduit le délai d'inactivité au minimum que lorsque le réseau semble suffisamment rapide, ce genre de besoin est inhabituel et devrait être rapporté en tant que procédure erronée à la liste de développement de nmap-dev.

Quand Nmap ne reçoit pas de réponse à un paquet de test sur un port, cela peut signifier que le port est filtré. Ou simplement que la réponse s'est perdue sur le réseau. Il est également possible que l'hôte cible ait limité son taux d'émission ce qui a temporairement bloqué la réponse. Pour ces raisons, Nmap recommence l'émission du paquet de test. Si Nmap détecte que le réseau est peu fiable, il peut essayer de re-émettre le paquet plus de fois encore avant de s'arrêter. Si cette technique améliore la fiabilité, elle ralonge la durée du scan. Quand la performance est un facteur critique, les scans peuvent être accélérés en limitant le nombre de retransmissions autorisé. Vous pouvez même spécifier --max-retries 0 pour éviter toute retransmission, bien que cela ne soit pas trop recommandé.

Le paramétrage par défaut (sans politique -T spécifiée) est d'autoriser jusqu'à dic retransmissions. Si le réseau a l'air fiable et que les hôtes cibles ne limitent pas leur taux d'émission, Nmap ne fait généralement qu'une seule retransmission. Ainsi, réduire --max-retries à une valeur basse comme trois n'affecte pas la plupart des scans. Une telle valeur peut accélérer significativement les scans pour des hôtes lents (qui limitent leurs émissions). Généralement, vous perdez des informations si Nmap cesse de scanner un port trop tôt, mais cela peut être préférable à laisser --host-timeout expirer et perdre alors toutes les informations concernant la cible.

Certains hôtes prennent du temps long à scanner, tout simplement. Ceci peut être dû à du matériel ou à des logiciels réseau peu performants ou inefficaces, à un taux de paquets limité ou à un pare-feu restrictif. Le faible pourcentage de hôtes lents scannés peut ralentir le temps de scan tout entier. Il est donc parfois préférable d'écarter temporairement ces hôtes du scan initial. Ceci peut être fait en spécifiant --host-timeout avec le nombre de millisecondes maximales que vous êtes prêt à attendre. Je choisis souvent 1 800 000 secondes pour m'assurer que Nmap ne perde pas plus d'une demi-heure sur un seul hôte. Notez que Nmap peut être en train de scanner d'autres hôtes en même temps durant cette demi-heure, ce n'est donc pas une perte complète. Un hôte qui dépasse cette valeur est abandonné. Pas de listage des ports, de détection d'OS ou de détection de version dans les résultats pour celui-ci.

Cette option force Nmap à attendre d'obtenir au moins la valeur donnée en millisecondes entre chaque probe qu'il envoie sur un hôte donné. C'est particulièrement utile en cas de limitation de nombre de paquets (taux limite). Les machines Solaris (parmi beaucoup d'autres) vont habituellement répondre à des paquets de test d'un scan UDP par seulement un message ICMP par seconde. Tout ce qui est envoyé au-delà par Nmap serait inutile. Un --scan-delay de 1 000 gardera Nmap à ce taux suffisamment lent. Nmap essaie de détecter le taux limite et d'ajuster le délai en conséquence, mais il ne fait pas de mal de le préciser si vous savez déjà quelle valeur est la meilleure.

Une autre utilisation de --scan-delay est d'éviter les détections éventuelles des systèmes de détection et de prévention d'intrusion (IDS/IPS) basées sur ce genre de règle.

Beaucoup d'hôtes utilisent depuis longtemps un filtrage pour réduire le nombre de messages d'erreur ICMP (comme les erreurs de ports inaccessibles) qu'ils envoient. Certains systèmes appliquent a présent des limitations similaires aux paquets RST (reset) qu'ils génèrent. Ceci peut ralentir Nmap dramaticalement étant donné qu'il ajuste son timing pour refléter ces limitations. Vous pouvez dire a Nmap d'ignorer ces limitations (pour les scans de ports comme le SYN scan qui ne traitent pas les ports muets comme étant ouverts) en spécifiant --defeat-rst-ratelimit.

Utiliser cette option peut réduire la précision, puisque certains ports apparaitront comme muets parcequ'Nmap n'attend alors pas assez longtemps une réponse RST qui serait limitée. Dans le cas d'un SYN scan, l'absence de réponse se traduit par un port marqué filtré plutot que fermé quand des paquets RST sont recus. Cette option est utile quand vous n'avez besoin que des ports ouverts, et que distinguer des fermés ou des filtrés ne vaut pas le temps supplémentaire que cela suppose.

Bien que les contrôles avancés et précis du délai dont il est fait mention dans les sections précédentes soient précis et efficaces, certains peuvent les trouver compliqués. Qui plus est, choisir les valeurs appropriées peut parfois prendre plus de temps que le scan que vous essayez d'optimiser. De ce fait, Nmap offre une approche plus simple, avec six profils de timing. Vous pouvez les spécifier grâce à l'option -T et aux numéros (0 à 5) ou aux noms correspondants. Les noms des profils sont paranoid (0), sneaky (1), polite (2), normal (3), agressive (4), et insane (5). Les deux premiers sont pour éviter les IDS. Le profile « Polite » ralentit le scan afin d'utiliser moins de bande passante et moins de ressources sur la machine cible. Le profil « Normal » est celui par défaut et donc -T3 ne fait rien. Le profil « Agressive » accélère les scans, partant du principe que vous travaillez sur un réseau suffisamment rapide et efficace. Enfin, le profil « Insane » suppose que vous êtes sur un réseau extraordinairement rapide ou que vous êtes prêt à sacrifier un peu de précision pour plus de vitesse.

Ces profils permettent à l'utilisateur de spécifier à quel point il souhaite être agressif tout en laissant Nmap choisir les valeur adéquates. Les profils effectuent aussi quelques ajustements que les options avancées ne permettent pas encore. Par exemple, -T4 empêche la variation dynamique du délai de dépasser 10ms pour les ports TCP et -T5 met cette valeur à 5 millisecondes. Les profils peuvent être utilisés en combinaison avec les options avancées en autant que le profil est précisé en premier. Dans le cas contraire, les valeurs normalisées pour le profil risquent d'écraser celles que vous spécifiez. Je vous recommande d'utiliser -T4 lorsque vous scannez des réseaux plus ou moins rapides, efficaces et modernes. Utilisez cette option (en début de ligne de commande) même si vous ajoutez des options avancées afin de bénéficier des petites améliorations liée à cette option.

Si vous travaillez sur une connexion large bande ou Ethernet, je vous recommande toujours d'utiliser -T4. Certains aiment utiliser -T5 quoique ce soit, à mon avis, trop agressif. Les gens utilisent parfois -T2 parce qu'ils pensent que le rsique que les hôtes tombent en panne soit moins grand ou parce qu'ils se considèrent comme respectueux d'une façon générale. Souvent ils ne réalisent pas à quel point l'option -T Polite est lente en réalité. Leur scan peut prendre dix fois plus de temps qu'un scan par défaut. Les machines qui tombent en panne et les problèmes liés à la bande passante sont rares avec les options de scan par défaut (-T3). C'est pourquoi je les recommande habituellement pour les scanneurs précautionneux. Le fait de ne pas faire de détection de version est bien plus efficace pour limiter ces problèmes que de jouer sur les valeurs de timing.

Bien que les options -T0 et -T1 puissent être utiles pour éviter les alertes des IDS, elles prendront un temps énorme pour scanner des milliers de machines ou de ports. Lorsqu'il s'agit de tels scans, vous devriez régler les valeurs exactes de timing dont vous avez besoin plutôt que de vous appuyer sur les options -T0 et -T1 et les valeurs qui y sont associées.

Les effets principaux de T0 sont de mettre les scans en série de façon à ce que seul un port ne soit scanné à la fois, puis d'attendre 5 minutes entre chaque envoi de probe. T1 et T2 sont semblables mais n'attendent que 15 secondes et 0,4 secondes, Respectivement, entre chaque probe. T3 est le profil par défaut de Nmap et comporte la mise en parallèle. T4 est l'équivalent de --max-rtt-timeout 1250 --initial-rtt-timeout 500 --max-retries 6 et met le délai maximum de scan TCP à 10 millisecondes. T5 fait la même chose que --max-rtt-timeout 300 --min_rtt_timeout 50 --initial-rtt-timeout 250 --max-retries 2 --host-timeout 900000 tout en mettant le délai maximum de scan TCP à 5 millisecondes.