L'opzione -f obbliga la scansione (anche i ping scan) a usare pacchetti IP frammentati. L'idea di base è quella di frammentare l'header TCP su più pacchetti, in modo da rendere più difficile per un packet filter, per un IDS o per altri fastidiosi strumenti simili il compito di capire cosa sta succedendo. Si presti comunque la massima attenzione nell'uso di questa opzione! Alcuni programmi hanno difficoltà a gestire pacchetti di dimensione troppo piccola. Il vecchio tool "Sniffit" andava in segmentation fault non appena riceveva il primo frammento. Specificando quest'opzione una volta Nmap dividerà i pacchetti in piccoli insiemi di al più 8 byte ciascuno, inserendoli dopo l'header IP. In questo modo un header TCP di 20 byte verrà diviso in tre pacchetti: due con otto byte ciascuno e uno con i rimanenti quattro. E ovviamente ogni frammento avrà un header IP. Specificando di nuovo l'opzione -f si useranno insiemi di 16 byte (riducendo così il numero di frammenti). In alternativa si può indicare lo spiazzamento ("offset") desiderato mediante l'opzione --mtu. Non si usi l'opzione -f se si è usato --mtu. L'offset dev'essere un multiplo di 8. Nonostante i pacchetti frammentati non supereranno i packet filter e i firewall che mantengono una coda di tutti i frammenti IP (come ad esempio le macchine GNU/Linux che hanno l'opzione CONFIG_IP_ALWAYS_DEFRAG impostata nel kernel), alcune reti tuttavia non possono permettersi il calo di performance causato da troppi frammenti e pertanto non avranno quell'opzione abilitata. Altri ancora non possono abilitare quell'opzione perché i frammenti potrebbero prendere direzioni differenti una volta all'interno. Alcuni sistemi di origine dei dati deframmentano i pacchetti in uscita nel kernel. Linux con il modulo ip_conntrack ("connection tracking module") è uno di questi. Si raccomanda di effettuare la scansione mentre un packet sniffer (come Wireshark) sta girando, in modo da avere la certezza che i pacchetti inviati vengano effettivamente frammentati. Se il proprio sistema operativo dovesse causare problemi in questo, si usi l'opzione --send-eth per bypassare il livello IP ed inviare direttamente frame Ethernet sul cavo.

Quest'opzione invoca una "decoy scan" (ovvero una scansione utilizzando esche) che agli occhi dell'host di destinazione apparirà come se provenisse dagli host specificati come decoy. In questo modo l'IDS della rete bersaglio mostrerà 5-10 port scan provenienti da indirizzi IP singoli, e non potrà capire quale IP è veramente la sorgente dell'attacco e quale IP è usato solo come mascheramento. Nonostante quest'opzione possa essere resa inutile mediante il tracciamento del percorso fatto dai router ("router path tracing"), tecniche di response-dropping e altri meccanismi attivi sono generalmente una tecnica effettiva per nascondere il proprio indirizzo IP.

Gli host decoy vanno separati con una virgola; è inoltre possibile usare il parametro ME come uno dei decoy per rappresentare la posizione del proprio indirizzo IP. Se si pone il parametro ME nella sesta posizione o ancora oltre, alcuni sensori di port scan (come l'eccellente "Scanlogd" di Solar Designer) difficilmente mostreranno il vostro indirizzo IP. Se non si dovesse usare il parametro ME, Nmap metterà il vostro IP in una posizione a caso. Si può anche utilizzare RND per generare un numero casuale di indirizzi IP non riservati, oppure RND:<number> per generare <number> indirizzi.

Si noti che gli host che vengono usati come decoy dovrebbero essere attivi o si corre il rischio di creare un "SYN flood" verso il proprio obiettivo. Inoltre diventerebbe molto facile capire quale host è la causa della scansione, se solo uno è attivo in una rete. È consigliabile usare indirizzi IP al posto di nomi, per evitare che la rete dei decoy individui i propri tentativi di risoluzione dei nomi nei log dei propri DNS.

I decoy vengono usati sia nel "ping scan" iniziale (indipendentemente dal fatto che si usi ICMP, SYN, ACK, ecc.) sia durante la fase di port scanning effettiva. Infine i decoy vengono usati durante l'OS detection remoto (opzione -O). L'utilizzo dei decoy non è valido con scansioni di tipo version detection o scansioni di tipo TCP connect. Quando si hanno degli scan delay, il ritardo viene applicato ad ogni blocco di probe, non ad ogni singolo probe. Dato che i decoy vengono inviati tutti in una volta, potrebbero temporaneamente violare i limiti di controllo sulla congestione.

Inutile bisogna ricordare che l'uso di troppi decoy può rallentare la propria scansione e potenzialmente renderla meno accurata. Inoltre, alcuni ISP ("Internet Service Providers") potrebbero filtrare i pacchetti "spoofed" (falsificati), anche se molti non operano alcun tipo di azione su questi ultimi.

In talune circostanze Nmap potrebbe non essere in grado di determinare il proprio indirizzo sorgente (in questi casi Nmap avvertirà della problematica). Se così fosse si può usare l'opzione -S seguita dall'indirizzo IP dell'interfaccia che si vuole usare per inviare pacchetti.

Un altro possibile uso di quest'opzione potrebbe essere per falsificare (spoof) la scansione per far credere al bersaglio che qualcun altro li sta prendendo di mira e sta effettuando una scansione su di loro. Si immagini solo cosa potrebbe succedere se un'azienda si accorgesse di essere preda di port scan da parte dei propri concorrenti! L'opzione -e è in genere richiesta per questo particolare utilizzo, e si consiglia anche di usare -Pn. Da notare che così facendo solitamente non si ricevono i pacchetti di risposta, saranno infatti inviati all'indirizzo IP fasullo; Nmap di conseguenza produrrà dei report inutili.

Indica a Nmap quale interfaccia di rete usare per inviare e ricevere pacchetti. Nmap dovrebbe essere in grado di capire autonomamente quale usare, ma nel caso non sia possibile vi avvertirà.

Un errore di configurazione sorprendentemente comune è quello di fidarsi del traffico di rete basandosi solo sulla porta di origine. È facile capire come può succedere: un amministratore configura un firewall nuovo fiammante per poi ritrovarsi sommerso dalle lamentele degli utenti ingrati le cui applicazioni hanno smesso di funzionare. Ad esempio le query DNS possono non funzionare più perché le risposte (sotto forma di pacchetti UDP) provenienti da server esterni non possono più entrare nella rete. Anche l'FTP è un esempio piuttosto comune: nei trasferimenti di dati attivi (opposti a quelli di tipo "passive FTP") il server remoto cerca di stabilire una connessione diretta con il client per trasferire i file richiesti.

Esistono soluzioni sicure a questi problemi, spesso nella forma di proxy a livello di applicazione o moduli del firewall che fanno parsing del protocollo. Sfortunatamente ci sono anche soluzioni facili ma insicure. Ad esempio, notando che le risposte alle query DNS arrivano dalla porta 53 e i transfer FTP "active" provengono dalla porta 20, tanti amministratori fanno l'errore di lasciar passare il traffico proveniente da queste porte. Essi spesso danno per scontato che nessun attaccante potrebbe accorgersi di questi buchi di sicurezza e approfittarne. In altri casi un amministratore può considerare questa soluzione una misura temporanea fino a quando non implementerà una soluzione migliore e più sicura e poi si dimentica di farlo.

Gli amministratori di rete con troppe cose da fare non sono gli unici a commettere questi errori. Molti prodotti sono venduti con queste regole insicure; anche Microsoft è colpevole. I filtri IPSec, parte di Windows 2000 e Windows XP, contengono una regola implicita che permette il passaggio di tutto il traffico proveniente dalla porta 88 (Kerberos). Un altro caso ben conosciuto è quello di Zone Alarm Personal Firewall (fino alla versione 2.1.25): esso permetteva l'ingresso nel sistema a qualsiasi pacchetto UDP che avesse come porta di origine la 53 (DNS) o 67 (DHCP).

Nmap offre le opzioni (equivalenti) -g e --source-port per sfruttare queste debolezze. Basta fornire un numero di porta e Nmap manderà pacchetti da questa porta quando possibile. La maggior parte delle scansioni TCP, incluse le scansioni SYN e UDP, supportano quest'opzione. Tuttavia Nmap deve usare numeri di porta diversi per alcuni test di OS detection perché essi funzionino a dovere; anche le richieste DNS, i TCP connect scan, i version detection e gli script scanning ignorano l'opzione --source-port poiché Nmap si appoggia alle librerie di sistema per gestirle.

Quest'opzione permette di includere valori binari come dati nei pacchetti da inviare. <hex string> può avere uno dei seguenti formati: 0xAABBCCDDEEFF<...>, AABBCCDDEEFF<...> o \xAA\xBB\xCC\xDD\xEE\xFF<...>. Alcuni esempi sono --data 0xdeadbeef e --data \xCA\xFE\x09. Da notare che se si indica un valore come 0x00ff nessuna conversione dell'ordine dei byte viene effettuata. Fare in modo che l'informazione indicata arrivi al destinatario con l'ordine dei byte che si aspetta.

Quest'opzione permette di inviare una stringa come dati nei pacchetti da inviare. <string> può contenere qualsiasi stringa. Si noti comunque che alcuni caratteri dipendono dal sistema in uso e il ricevente potrebbe non ricevere la stessa informazione. Inoltre accertarsi di aver racchiuso la string tra apici doppi ("") e di marcare con il carattere di escape tutti i caratteri speciali interpretati dalla shell. Alcuni esempi: --data-string "Scan conducted by Security Ops, extension 7192" oppure --data-string "Ph34r my l33t skills". Tenere a mente che nessuno può effettivamente vedere i commenti lasciati da quest'opzione, a meno che non si stia monitorando attentamente la rete con uno sniffer o delle regole IDS personalizzate.

In genere Nmap invia pacchetti nella dimensione più piccola possibile, contenenti soltanto l'header. Quindi i pacchetti TCP sono in genere di 40 byte e le richieste ICMP echo di 28 byte. Alcuni porte UDP e protocolli IP danno un carico dati personalizzato di default. Quest'opzione indica a Nmap di aggiungere un certo numero di byte casuali a quasi tutti i pacchetti che invia e di non usare i valori specifici del protocollo (Usare --data-length 0 per nessun valore random e nessun valore specifico del protocollo). I pacchetti di OS detection (-O) tuttavia non vengono modificati, perché la precisione in essi richiede una certa consistenza nell'invio dei probe; in ogni modo quasi tutte le opzioni di ping e portscan supportano questa modalità. Essa rallenta leggermente le performance ma ne può risultare una scansione più accurata.

Imposta il campo time-to-live (tempo di vita del pacchetto IPv4) al valore richiesto.

Quest'opzione indica a Nmap di rimescolare l'ordine di scansione di ogni gruppo di host (fino a 16384) prima di iniziare la scansione. Questo può nascondere le scansioni a vari sistemi di network monitoring, specialmente quando è affiancato a opzioni di rallentamento ("slow timing"). Se si desidera un random su gruppi di dimensione maggiore, è necessario incrementare la direttiva PING_GROUP_SZ in nmap.h e ricompilare l'applicativo. Una soluzione alternativa potrebbe essere quella di generare una lista degli IP sui quali effettuare lo scan mediante un list scan (opzione -sL -n -oN <filename>), randomizzarla con uno script Perl e passare la lista a Nmap con l'opzione -iL.

Richiede ad Nmap di usare l'indirizzo hardware (MAC) per tutti i frame ethernet raw che invia. Quest'opzione implica --send-eth per garantire che Nmap invii di fatto pacchetti a livello ethernet. Il MAC può essere specificato in vari formati: nel caso in cui sia semplicemente il numero "0", Nmap sceglie un MAC completamente random per la sessione. Se la stringa è un numero pari di simboli esadecimali (con le coppie separate eventualmente dal simbolo di due punti), Nmap userà questo come MAC. Se dovessero essere specificate meno di 12 cifre decimali, Nmap riempirà il resto dei 6 byte con valori casuali. Se l'argomento non è ne uno zero ne una stringa esadecimale, Nmap cercherà nel file nmap-mac-prefixes per cercare il nome di un produttore contenente la stringa indicata (senza distinguere tra maiuscole e minuscole). Se trova una corrispondenza, Nmap userà la parte OUI del produttore (il prefisso di 3 byte) e riempirà i restanti 6 byte in maniera casuale. Esempi validi dell'uso di --spoof-mac sono Apple, 0, 01:02:03:04:05:06, deadbeefcafe, 0020F2, e Cisco. Quest'opzione ha effetto solo sui pacchetti raw, come nei SYN scan o negli OS detection, non sulle feature "connection-oriented", come i version detection o l'NSE.

Richiede ad Nmap ti stabilire connessioni TCP con l'obiettivo attraverso una catena di uno o più proxy HTTP o SOCKS4. I proxy possono aiutare a nascondere il sorgente reale di una scansione o evadere certe restrizioni dei firewall, ma fanno calare la performance della scansione aumentando la latenza. Si potrebbe, di conseguenza, dover modificare i timeout di Nmap o altri parametri di scansione; in particolar modo, un --max-parallelism più basso potrebbe aiutare dato che alcuni proxy non gestiscono diverse connessioni contemporanee, come invece fa Nmap di default.

Quest'opzione riceve una lista di proxy come argomento, espressa come URL nel formato proto://host:port. Utilizzare la virgola come separatore di URL in una catena. È anche supportata la non autenticazione. I protocolli sono HTTP e SOCKS4.

Attenzione: questa feature è ancora in fase di sviluppo ed ha alcune limitazioni. È implementata con la libreria nsock e quindi non ha effetto sui ping, i port scanning e la fase di OS detection di una scansione. Solo l'NSE e i version scan ne traggono beneficio finora, altre funzionalità potrebbero rivelare il proprio vero indirizzo. Le connessioni SSL non sono ancora supportate, così come la risoluzione DNS proxy-side (gli hostname vengono sempre risolti da Nmap).

Richiede ad Nmap di usare un checksum TCP o UDP non valido per i pacchetti inviati alla macchina di destinazione. Poiché teoricamente tutti gli stack IP degli host finiranno per ignorare questi pacchetti, qualunque risposta ricevuta dovrà per forza provenire da un firewall o da un Intrusion Detection System (IDS) che non si preoccupa di verificare il checksum. Per maggiori informazioni su questa tecnica, si consulti https://nmap.org/p60-12.txt.

Richiede ad Nmap di usare l'algoritmo deprecato Adler32 per calcolare il checksum SCTP. se --adler32 non viene impostato, viene usato CRC-32C (Castagnoli). L'RFC 2960 originariamente definisce Adler32 come l'algoritmo di checksum per SCTP; L' RFC 4960 successivamente ha ridefinito il checksum SCTP specificando l'uso di CRC-32C. Le implementazioni attuali SCTP dovrebbero utilizzare CRC-32C, ma allo scopo di suscitare risposta dalle più datate, è preferibile usare Adler32.