Nmap ha l'abilità di effettuare port scan o version scan su più host in parallelo. Lo spazio degli indirizzi IP di destinazione viene diviso in gruppi e viene scansionato un gruppo per volta. In genere gruppi di dimensioni maggiori portano ad una migliore efficienza. Il lato negativo di tutto ciò è che i risultati non possono essere mostrati all'utente fino a quando l'intero gruppo non è stato esplorato completamente. Quindi, se si lancia Nmap impostando la dimensione del gruppo a 50, l'utente non vedrà alcun risultato fino a quando i primi 50 host non sono stati completati (a meno che non si selezioni la modalità verbose).

Di default, Nmap usa un compromesso per ovviare a questa difficoltà. Inizialmente utilizza una dimensione di cinque host in modo da mostrare i primi risultati velocemente, dopodiché incrementa la dimensione fino ad un massimo di 1024. Il numero esatto dipende dalle opzioni che vengono passate. Per ragioni di efficienza Nmap usa gruppi di dimensione maggiore per UDP o per scansioni di porte TCP di piccole dimensioni.

Nel caso in cui una dimensione massima del gruppo sia specificata con --max-hostgroup, Nmap non oltrepasserà mai questo limite. Specificando invece una dimensione minima con --min-hostgroup obbligherà Nmap a usare dimensioni almeno equivalenti. Nmap potrebbe tuttavia dover usare gruppi più piccoli di quelli indicati se non ci dovessero essere abbastanza host di destinazione rimanenti per un'interfaccia per raggiungere la minima quota specificata. Entrambe le opzioni possono essere impostate per mantenere la dimensione del gruppo all'interno di un certo limite, anche se questo succede raramente.

Queste opzioni durante la fase di host discovery di una scansione non hanno effetto; ciò include anche il plain ping scan (-sn). L'host discovery lavora sempre su grandi gruppi di host per aumentare la velocità e l'accuratezza.

L'utilizzo principale di queste opzioni è quello di specificare una dimensione minima maggiore rispetto al default in modo da rendere più veloce la scansione globale. Una scelta piuttosto comune è 256 per una scansione di una rete di classe C. Per una scansione con molte porte, eccedere questo numero è improbabile che aiuti molto. Per una scansione con poche porte invece, una dimensione di 2048 o più può essere d'aiuto.

Queste opzioni controllano il numero totale di probe che possono uscire dalla macchina sorgente per un host group. Esse sono usate per port scanning e host discovery. Di default, Nmap calcola un parallelismo ideale in continuo cambiamento, a seconda delle performance della rete. Se c'è un elevato numero di pacchetti che viene scartato, Nmap rallenta e lavora su un numero minore di probe in uscita. Il numero ideale di probe in uscita incrementa poi gradualmente fino a quando la rete lo permette. Questa opzione limiti minimi o massimi alla variabile. Di default, il parallelismo può arrivare ad un minimo di 1 se la rete si dimostra essere poco affidabile; può invece aumentare a diverse centinaia per una rete in condizioni ottimali.

L'uso più comune consiste nell'impostare --min-parallelism ad un valore maggiore di 1 per accelerare le scansioni di reti o host che rispondono in maniera non adeguata. È abbastanza rischioso giocare con quest'opzione, in quanto impostandola ad un valore troppo alto può influire negativamente sull'accuratezza. Impostandola manualmente inoltre riduce l'abilità di Nmap di controllare dinamicamente il parallelismo basandosi sulle condizioni della rete. Un valore di 10 è abbastanza ragionevole, anche se in genere le modifiche a questo parametro vengono usate come ultima risorsa.

L'opzione --max-parallelism viene impostata a volte sul valore 1 per impedire a Nmap di inviare più di un probe alla volta verso un determinato host. L'opzione --scan-delay (discussa in seguito), è un altro modo per ottenere questo risultato.

Nmap mantiene un valore di timeout aggiornato per determinare quanto ci vorrà per un probe response prima di ritrasmettere il probe. Questo viene calcolato basandosi sui tempi di response degli ultimi probe inviati. La formula si trova al link «Idle Scan Implementation Algorithms». Se la latenza della rete dovesse oscillare troppo questo timeout può crescere fino ad un valore di diversi secondi. Inoltre esso è impostato inizialmente ad un valore abbastanza alto e potrebbe restare su quel valore per tutto il tempo in cui Nmap effettua la scansione su host che non rispondono.

Specificando limiti di --max-rtt-timeout e di --initial-rtt-timeout inferiori ai valori di default è possibile ridurre di molto i tempi di scansione. Questo è vero in particolare per scansioni di tipo "pingless" (opzione -Pn) e nei confronti di reti particolarmente protette. Tuttavia, è bene non esagerare; infatti la scansione può addirittura richiedere più tempo del previsto nel caso in cui si specifichi un valore talmente basso da resettare il timeout dei probe (e forzarne un nuovo invio) mentre la risposta sta ancora arrivando.

Se tutti gli host sono su una rete locale, 100 millisecondi (--max-rtt-timeout 100ms)è un valore ragionevolmente aggressivo. Se nella scansione è coinvolto qualche routing, sarebbe meglio effettuare un ping preliminare dell'host (con l'utility ICMP ping o con un generatore di pacchetti come Nping che può penetrare un firewall più facilmente), e osservare poi il valore massimo di andata/ritorno ("round trip") per un numero di pacchetti non inferiore a 10. È quindi consigliato raddoppiare questo valore per l'opzione --initial-rtt-timeout e triplicarlo o quadruplicarlo per l'opzione --max-rtt-timeout. In genere si preferisce non impostare il maximum RTT al di sotto di 100 millisecondi, indipendentemente dai tempi di ping. E nemmeno al di sopra di 1000 millisecondi.

L'opzione --min-rtt-timeout è usata molto raramente; essa può essere utile nel caso in cui una rete è talmente poco affidabile che anche il default di Nmap risulta essere troppo aggressivo. Poiché Nmap riduce il timeout fino al valore minimo quando la rete sembra affidabile, questa esigenza di solito non è necessaria e dovrebbe essere indicata come bug alla mailing list nmap-dev.

Quando Nmap non riceve risposta ad un port scan probe, potrebbe significare che la porte è filtrata. O forse che la risposta o il probe stesso si sono persi nella rete. È anche possibile che l'host obiettivo abbia attivato dei limiti sul traffico che bloccano la risposta. In questi questi, Nmap prova nuovamente a ritrasmettere il probe iniziale e, se ritiene che la rete sia poco affidabile, prova molte volte prima di passare alla porta successiva. Nonostante il vantaggio dell'accuratezza, tutto ciò prolunga i tempi di scansione. Quando le performance sono al primo posto, si può velocizzare le scansioni limitando il numero di ritrasmissioni consentite. Si può addirittura indicare --max-retries 0 per disabilitare ogni ritrasmissione, anche se è consigliato solo in quelle situazioni in cui la non risposta di alcune porte e alcuni host è accettabile (ad esempio sondaggi interni o test).

Di default (senza nessun template, opzione -T) vengono effettuate dieci ritrasmissioni. Se la rete risulta affidabile e gli host obiettivo non hanno limitazioni, Nmap solitamente effettua una ritrasmissione. Quindi la maggior parte degli obiettivi non viene coinvolta abbassando --max-retries ad un valore basso, ad esempio tre. Alcuni valori possono velocizzare sensibilmente le scansioni di host piuttosto lenti. Di solito vengono perse alcune informazioni quando Nmap scansiona le porte velocemente, però è sempre meglio che lasciar scadere --host-timeout e perdere tutte le informazioni dell'obiettivo.

Alcuni host a volte richiedono un tempo estremamente lungo per portare a termine una scansione. Questo può essere dovuto a hardware o software poco performante o inaffidabile, a limiti di traffico impostati o a firewall troppo restrittivi. La minoranza degli host sottoposti a scansione può richiedere la maggior parte del tempo di scansione. A volte è preferibile risparmiare sul tempo ed evitare questi host fin dal principio. Questo comportamento viene forzato dall'opzione --host-timeout seguito dal tempo dopo il quale non si vuole più aspettare. Ad esempio si specifica un valore di 30m per avere la garanzia che Nmap non sprechi più di mezz'ora su di un singolo host. Si noti che Nmap può nel frattempo effettuare la scansione su altri host durante quella mezz'ora, per cui non si tratta di tempo completamente sprecato. Un host che dovesse andare in timeout viene semplicemente saltato. Non vengono mostrati l'elenco delle porte, il detection del sistema operativo né risultati di version detection per quell'host.

Quest'opzione obbliga Nmap ad aspettare almeno il tempo indicato tra i probe inviati ad un determinato host. Questo risulta particolarmente utile nel caso di limitazioni sulla frequenza dell'invio ("rate limiting"). Tra gli altri, in particolare le macchine Solaris in genere rispondono a scansioni UDP con un solo messaggio ICMP al secondo. Qualsiasi altro probe inviato da Nmap durante questo intervallo di tempo sarebbe quindi sprecato. Un valore di --scan-delay di 1s manterrà Nmap al di sotto di questa particolare frequenza di invio di probe. Nmap comunque cercherà di capire eventuali limiti sulla frequenza e modificherà i ritardi sui probe di conseguenza, tuttavia non è cattiva abitudine specificarlo sulla linea di comando quando dovesse essere noto a priori il valore ottimale.

Quando Nmap aumenta lo scan delay in base al rate limiting, la scansione rallenta drammaticamente. L'opzione --max-scan-delay indica il valore massimo di delay che Nmap può adottare. Un valore basso di quest'opzione può velocizzare Nmap, ma ci sono dei rischi: settarlo troppo basso può portare a ritrasmissioni inutili e una possibile perdita di dati da porte che hanno rate limiting molto ridotti.

Un altro uso dell'opzione--scan-delay è quello in cui si desidera evitare sistemi anti-intrusione (IDS/IPS, "intrusion-detection" e "intrusion-prevention system"). Questa tecnica viene utilizzata nella sezione « A practical example: bypassing default Snort 2.2.0 rules» per vincere il port scanner detector di default in Snort IDS. Molti altri IDS possono essere sconfitti con questo sistema.

Il timing dinamico di Nmap fa un buon lavoro trovando una velocità adeguata a ciò che si sta scansionando. Alle volte, però, può succedere di conoscere uno scanning rate appropriato per quella determinata rete, oppure bisogna finire una scansione in un tempo preciso. O forse si vuole impedire ad Nmap di scansionare troppo velocemente. Le opzioni --min-rate e --max-rate sono state create proprio per queste situazioni.

Quando viene definita l'opzione --min-rate Nmap farà del suo meglio per inviare i pacchetti non al di sotto del limite di frequenza impostato. L'argomento è un numero reale positivo che rappresenta la frequenza di invio dei pacchetti in pacchetti/secondo. Per esempio, indicando --min-rate 300 significa che Nmap proverà a mantenere una frequenza di invio di almeno 300 pacchetti al secondo. Quest'opzione non impedisce ad Nmap di aumentare la frequenza se le condizioni lo permettono.

Viceversa, --max-rate forza la frequenza di invio dandogli un limite massimo. Utilizzare --max-rate 100, ad esempio, per limitare l'invio a 100 pacchetti al secondo su una rete veloce. Usare --max-rate 0.1 per una scansione lenta, un pacchetto ogni dieci secondi. Entrambe le opzioni --min-rate e --max-rate mantengono la frequenza all'interno del range specificato.

Queste due opzioni sono globali, hanno effetto cioè sull'intera scansione, non sugli host individuali. Vanno ad agire sui port scan e gli host discovery. Altre feature, come l'OS detection, hanno le loro opzioni di timing.

Ci sono due casi in cui la frequenza potrebbe scendere sotto il minimo richiesto. Il primo è impostare la frequenza minima più alta di quanto Nmap riesca ad inviare, il che dipende dall'hardware in uso. In questo casto Nmap invierà i pacchetti il più velocemente possibile, ma bisogna comunque essere consapevoli che ciò potrebbe causare un calo dell'affidabilità. Il secondo caso è quando Nmap non ha nulla da inviare, ad esempio alla fine di uno scan quando gli ultimi probe sono stati inviati ed Nmap sta aspettando una risposta o che vadano in time out. È normale che lo scanning rate cali alla fine di una scansione o tra hostgroups. La frequenza di invio potrebbe inoltre superare temporaneamente il massimo prefissato, per far fronte a delay improvvisi, ma nella media rimarrà comunque entro i limiti.

Specificare un rate minimo, è una cosa da fare con attenzione. Effettuare una scansione più velocemente di quanto una rete possa supportare potrebbe portare a risultati inaffidabili. In alcuni casi, una frequenza troppo alta può portare ad un scansione più lenta rispetto ad una scansione con un rate più basso. Questo perché l'algoritmo adaptive retransmission di Nmap potrebbe rilevare una congestione della rete causata da un eccessivo scanning rate e aumentare il numero di ritrasmissioni per mantenere una certa affidabilità. Quindi anche se i pacchetti verranno inviati velocemente, ne verranno comunque inviati di più. Limitare il numero massimo ritrasmissioni con l'opzione --max-retries se si deve rispettare un tempo massimo per la scansione totale.

Molti host usano da tempo delle funzionalità di "rate limiting" (limitazioni alla frequenza) per ridurre il numero di messaggi di errore ICMP che mandano (ad esempio gli errori "port-unreachable"). Alcuni sistemi hanno iniziato ad applicare le stesse tecniche all'invio di pacchetti RST (reset). Queste tecniche possono rallentare di molto Nmap poiché esso continuerà a calibrare la gestione dei timing per gestire queste limitazioni di frequenza. Si può quindi indicare a Nmap di ignorare questi rate limits (per i port scan come il SYN scan, che non considerano le porte silenziose come aperte) mediante l'opzione --defeat-rst-ratelimit.

L'utilizzo di quest'opzione può ridurre la precisione di uno scan, poiché alcune porte potrebbero restituire uno stato di non-risposta perché Nmap non è rimasto in attesa abbastanza a lungo a causa di meccanismi di rate-limiting dei pacchetti RST. Con una scansione di tipo SYN le porte "mute" (dalle quali non si è ricevuto un RST) in questo caso vengono indicate con filtered piuttosto che closed. Quest'opzione è utile solo quando si è interessati alle porte aperte, e la distinzione tra porte closed e filtered non è di alcun interesse rispetto al tempo che richiede.

Forza l'utilizzo di un determinato "nsock IO multiplexing engine". Solo per il "select(2)-based fallback engine" viene garantita la compatibilità con il sistema in uso. Gli engine vengono dichiarati dopo il nome del "IO management facility" cui fanno riferimento. Gli engine attualmente implementati sono epoll, kqueue, poll e select, ma non saranno tutti presenti su tutte le piattaforme. Utilizzare nmap -V per sapere quali engine sono supportati.

Mentre le opzioni mostrate nella precedente sezione sono molto utili ed efficaci alcuni potrebbero trovarle troppo complicate da usare. Inoltre, la scelta dei valori più appropriati può a volte richiedere più tempo della scansione stessa che si sta cercando di ottimizzare. Nmap offre quindi un approccio più semplice mediante sei "timing templates", ovvero opzioni pre-impostate per regolare l'aggressività della scansione. Esse si specificano mediante l'opzione -T seguita dal numero del template corrispondente o dal suo nome. Essi sono: paranoico (0), furtivo (1), educato (2), normale (3), aggressivo (4) e folle (5). I primi due vengono usati per evitare i sopracitati sistemi anti-intrusione (IDS). La modalità "gentile" rallenta la scansione in modo da usare meno banda e risorse sulla macchina bersaglio. La modalità "normale" è di default (e pertanto l'opzione -T3 non modifica nulla). La modalità "aggressiva" incrementa la velocità assumendo che si è su una rete veloce ed affidabile. Infine la modalità "folle" dà per scontato che si è su una rete estremamente veloce ed affidabile o che si vuole sacrificare l'accuratezza in nome della velocità.

Questi template consentono all'utente di specificare quanto aggressivi si desidera essere, lasciando al tempo stesso a Nmap il compito di scegliere i valori più appropriati. I template inoltre effettuano piccoli aggiustamenti sui timing per i quali non esistono opzioni che ne consentono il controllo. Ad esempio, l'opzione -T4 impedisce al ritardo dinamico per una scansione di andare al di sotto della soglia dei 10 millisecondi per le porte TCP, e l'opzione -T5 limita questo valore a 5 millisecondi. I template possono essere usati insieme a controlli più precisi a patto che il template venga specificato per primo. Altrimenti i valori impostati dal template potrebbero sovrascrivere quelli specificati dall'utente. Si raccomanda di usare l'opzione -T4 nel caso in cui si desideri effettuare scansioni di reti abbastanza recenti e affidabili; inoltre è consigliabile mantenere quell'opzione (intesa come inserita all'inizio dei comandi) anche qualora si dovessero aggiungere controlli più precisi in modo da beneficiare da tutti i piccoli miglioramenti che dovessero intervenire.

Se la propria connessione è a banda larga o di tipo ethernet, si raccomanda di usare sempre l'opzione -T4. Alcuni prediligono anche l'opzione -T5, nonostante per i più sia troppo aggressiva. Altri a volte usano l'opzione -T2 perché credono che sia meno propensa a mandare in crash un host o perché si considerano persone educate. Spesso essi non si rendono conto di quanto è lenta l'opzione -T polite; una scansione di questo tipo può impiegare anche dieci volte il tempo richiesto per una scansione di default. Crash di host e problemi di banda sono rari con le opzioni di timing di default (opzione -T3) e pertanto è l'opzione consigliata a chi deve effettuare scansioni senza dare troppo nell'occhio. Omettere una scansione di tipo version detection è molto più efficiente del giocare con i valori di timing per ridurre i problemi sopracitati.

Mentre le opzioni -T0 e -T1 potrebbero essere utili per evitare gli allarmi di un IDS, esse richiederanno un tempo estremamente lungo per portare a termine una scansione di migliaia di host o di porte. In una situazione di questo tipo si suggerisce di lavorare sui valori esatti di timing richiesti piuttosto che avvalersi delle opzioni preimpostate nelle opzioni -T0 e -T1.

Gli effetti principali dell'opzione T0 sono quello di serializzare la scansione in modo da affrontare una sola porta alla volta, e al tempo stesso quello di attendere cinque minuti tra l'invio di un probe e il successivo. Le opzioni T1 e T2 sono simili ma attendono rispettivamente 15 secondi e 0.4 secondi tra un probe e l'altro. L'opzione T3 è il comportamento di default di Nmap (che include il parallelismo). L'opzione T4 ha lo stesso risultato dell'impostare --max-rtt-timeout 1250ms --initial-rtt-timeout 500ms --max-retries 6 e di impostare il ritardo massimo per una scansione TCP a 10 millisecondi. Infine l'opzione T5 è equivalente a --max-rtt-timeout 300ms --min-rtt-timeout 50ms --initial-rtt-timeout 250ms --max-retries 2 --host-timeout 15m e ad impostare il massimo ritardo TCP (maximum delay) a 5 millisecondi.