# nmap -A -T4 scanme.nmap.org
Nmap scan report for scanme.nmap.org (74.207.244.221)
Host is up (0.029s latency).
rDNS record for 74.207.244.221: li86-221.members.linode.com
Not shown: 995 closed ports
PORT     STATE    SERVICE     VERSION
22/tcp   open     ssh         OpenSSH 5.3p1 Debian 3ubuntu7 (protocol 2.0)
| ssh-hostkey: 1024 8d:60:f1:7c:ca:b7:3d:0a:d6:67:54:9d:69:d9:b9:dd (DSA)
|_2048 79:f8:09:ac:d4:e2:32:42:10:49:d3:bd:20:82:85:ec (RSA)
80/tcp   open     http        Apache httpd 2.2.14 ((Ubuntu))
|_http-title: Go ahead and ScanMe!
646/tcp  filtered ldp
1720/tcp filtered H.323/Q.931
9929/tcp open     nping-echo  Nping echo
Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:linux_kernel:2.6.39
OS details: Linux 2.6.39
Network Distance: 11 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel
TRACEROUTE (using port 53/tcp)
HOP RTT      ADDRESS
[Cut first 10 hops for brevity]
11  17.65 ms li86-221.members.linode.com (74.207.244.221)
Nmap done: 1 IP address (1 host up) scanned in 14.40 seconds

Nmap 6.47SVN ( https://nmap.org )
Usage: nmap [Scan Type(s)] [Options] {target specification}
TARGET SPECIFICATION:


  Can pass hostnames, IP addresses, networks, etc.


  Ex: scanme.nmap.org, microsoft.com/24, 192.168.0.1; 10.0.0-255.1-254


  -iL <inputfilename>: Input from list of hosts/networks


  -iR <num hosts>: Choose random targets


  --exclude <host1[,host2][,host3],...>: Exclude hosts/networks


  --excludefile <exclude_file>: Exclude list from file
HOST DISCOVERY:


  -sL: List Scan - simply list targets to scan


  -sn: Ping Scan - disable port scan


  -Pn: Treat all hosts as online -- skip host discovery


  -PS/PA/PU/PY[portlist]: TCP SYN/ACK, UDP or SCTP discovery to given ports


  -PE/PP/PM: ICMP echo, timestamp, and netmask request discovery probes


  -PO[protocol list]: IP Protocol Ping


  -n/-R: Never do DNS resolution/Always resolve [default: sometimes]


  --dns-servers <serv1[,serv2],...>: Specify custom DNS servers


  --system-dns: Use OS's DNS resolver


  --traceroute: Trace hop path to each host
SCAN TECHNIQUES:


  -sS/sT/sA/sW/sM: TCP SYN/Connect()/ACK/Window/Maimon scans


  -sU: UDP Scan


  -sN/sF/sX: TCP Null, FIN, and Xmas scans


  --scanflags <flags>: Customize TCP scan flags


  -sI <zombie host[:probeport]>: Idle scan


  -sY/sZ: SCTP INIT/COOKIE-ECHO scans


  -sO: IP protocol scan


  -b <FTP relay host>: FTP bounce scan
PORT SPECIFICATION AND SCAN ORDER:


  -p <port ranges>: Only scan specified ports


    Ex: -p22; -p1-65535; -p U:53,111,137,T:21-25,80,139,8080,S:9


  --exclude-ports <port ranges>: Exclude the specified ports from scanning


  -F: Fast mode - Scan fewer ports than the default scan


  -r: Scan ports sequentially - don't randomize


  --top-ports <number>: Scan <number> most common ports


  --port-ratio <ratio>: Scan ports more common than <ratio>
SERVICE/VERSION DETECTION:


  -sV: Probe open ports to determine service/version info


  --version-intensity <level>: Set from 0 (light) to 9 (try all probes)


  --version-light: Limit to most likely probes (intensity 2)


  --version-all: Try every single probe (intensity 9)


  --version-trace: Show detailed version scan activity (for debugging)
SCRIPT SCAN:


  -sC: equivalent to --script=default


  --script=<Lua scripts>: <Lua scripts> is a comma separated list of


           directories, script-files or script-categories


  --script-args=<n1=v1,[n2=v2,...]>: provide arguments to scripts


  --script-args-file=filename: provide NSE script args in a file


  --script-trace: Show all data sent and received


  --script-updatedb: Update the script database.


  --script-help=<Lua scripts>: Show help about scripts.


           <Lua scripts> is a comma-separated list of script-files or


           script-categories.
OS DETECTION:


  -O: Enable OS detection


  --osscan-limit: Limit OS detection to promising targets


  --osscan-guess: Guess OS more aggressively
TIMING AND PERFORMANCE:


  Options which take <time> are in seconds, or append 'ms' (milliseconds),


  's' (seconds), 'm' (minutes), or 'h' (hours) to the value (e.g. 30m).


  -T<0-5>: Set timing template (higher is faster)


  --min-hostgroup/max-hostgroup <size>: Parallel host scan group sizes


  --min-parallelism/max-parallelism <numprobes>: Probe parallelization


  --min-rtt-timeout/max-rtt-timeout/initial-rtt-timeout <time>: Specifies


      probe round trip time.


  --max-retries <tries>: Caps number of port scan probe retransmissions.


  --host-timeout <time>: Give up on target after this long


  --scan-delay/--max-scan-delay <time>: Adjust delay between probes


  --min-rate <number>: Send packets no slower than <number> per second


  --max-rate <number>: Send packets no faster than <number> per second
FIREWALL/IDS EVASION AND SPOOFING:


  -f; --mtu <val>: fragment packets (optionally w/given MTU)


  -D <decoy1,decoy2[,ME],...>: Cloak a scan with decoys


  -S <IP_Address>: Spoof source address


  -e <iface>: Use specified interface


  -g/--source-port <portnum>: Use given port number


  --proxies <url1,[url2],...>: Relay connections through HTTP/SOCKS4 proxies


  --data <hex string>: Append a custom payload to sent packets


  --data-string <string>: Append a custom ASCII string to sent packets


  --data-length <num>: Append random data to sent packets


  --ip-options <options>: Send packets with specified ip options


  --ttl <val>: Set IP time-to-live field


  --spoof-mac <mac address/prefix/vendor name>: Spoof your MAC address


  --badsum: Send packets with a bogus TCP/UDP/SCTP checksum
OUTPUT:


  -oN/-oX/-oS/-oG <file>: Output scan in normal, XML, s|<rIpt kIddi3,


     and Grepable format, respectively, to the given filename.


  -oA <basename>: Output in the three major formats at once


  -v: Increase verbosity level (use -vv or more for greater effect)


  -d: Increase debugging level (use -dd or more for greater effect)


  --reason: Display the reason a port is in a particular state


  --open: Only show open (or possibly open) ports


  --packet-trace: Show all packets sent and received


  --iflist: Print host interfaces and routes (for debugging)


  --log-errors: Log errors/warnings to the normal-format output file


  --append-output: Append to rather than clobber specified output files


  --resume <filename>: Resume an aborted scan


  --stylesheet <path/URL>: XSL stylesheet to transform XML output to HTML


  --webxml: Reference stylesheet from Nmap.Org for more portable XML


  --no-stylesheet: Prevent associating of XSL stylesheet w/XML output
MISC:


  -6: Enable IPv6 scanning


  -A: Enable OS detection, version detection, script scanning, and traceroute


  --datadir <dirname>: Specify custom Nmap data file location


  --send-eth/--send-ip: Send using raw ethernet frames or IP packets


  --privileged: Assume that the user is fully privileged


  --unprivileged: Assume the user lacks raw socket privileges


  -V: Print version number


  -h: Print this help summary page.
EXAMPLES:


  nmap -v -A scanme.nmap.org


  nmap -v -sn 192.168.0.0/16 10.0.0.0/8


  nmap -v -iR 10000 -Pn -p 80
SEE THE MAN PAGE (https://nmap.org/book/man.html) FOR MORE OPTIONS AND EXAMPLES

Legge gli obiettivi da inputfilename. Inserire una grossa lista di host è spesso scomodo sulla linea di comando, anche se spesso è una necessità comune. Ad esempio, un server DHCP potrebbe esportare un elenco di 10.000 leases che si potrebbero voler controllare. Oppure si vogliono controllare tutti gli indirizzi IP di una rete tranne quelli presenti nel DHCP per individuare eventuali IP statici non autorizzati. È sufficiente generare la lista di host da controllare e passarla a Nmap come argomento dell'opzione -iL. Ogni elemento può essere in uno qualsiasi dei formati accettati da Nmap sulla linea di comando (indirizzo IP, nome dell'host, notazione CIDR, IPv6 o intervalli di indirizzi). Ogni elemento dev'essere separato da uno o più spazi, indentazioni (tabulazioni) o caratteri di a-capo. Si può usare un trattino (-) come nome di file se si vuole che Nmap legga gli host dallo standard input piuttosto che da un file esistente.

L'inputfilename può contenere commenti. Ogni commento inizia con # e finisce con un carattere di a-capo.

Durante certe indagini su tutta Internet o altri tipi di ricerca, si potrebbe desiderare di scegliere gli obiettivi in maniera casuale. L'argomento num hosts indica a Nmap quanti indirizzi IP generare. Gli indirizzi privati, multicast o i pool di indirizzi non allocati vengono automaticamente saltati. Si può specificare l'argomento 0 per una scansione senza fine. Va ricordato che alcuni amministratori di rete non apprezzano scansioni non autorizzate delle loro reti e potrebbero lamentarsi. Usare questa opzione a proprio rischio e pericolo! Se in un pomeriggio piovoso ci si trova ad essere annoiati, si può provare questo comando nmap -sS -PS80 -iR 0 -p 80 per trovare in maniera casuale dei server web sui quali navigare.

Questa opzione specifica un elenco, separato da virgola, di obiettivi da escludere dalla scansione anche se sono parte dell'intervallo di rete specificato. La lista va specificata nella notazione usuale di Nmap, ovvero può includere nomi di host, blocchi di indirizzi specificati mediante notazione CIDR, intervalli di ottetti, etc. Questo può essere utile quando la rete che si vuole controllare include server intoccabili o di vitale importanza, sistemi che sono conosciuti per reagire in maniera negativa ad eventuali scansioni, o sottoreti amministrate da altri.

Questa opzione offre le stesse funzionalità dell'opzione--exclude, con la differenza che gli obiettivi da escludere dalla scansione sono elencate in un exclude_file (separate da spazi bianchi, a-capo o tabulazioni) anziché sulla linea di comando.

L'exclude_file può contenere commenti. Ogni commento inizia con # e finisce con un carattere di a-capo.

La List Scan è una forma banale di host discovery che semplicemente elenca ogni host delle reti specificate, senza inviare alcun pacchetto agli host obiettivo. Di default Nmap effettua una risoluzione inversa mediante DNS sugli host per ottenerne il nome completo. Spesso è sorprendente vedere quante informazioni utili possono fornire dei semplici hostname. Ad esempio, fw.chi è il nome del firewall di un'azienda di Chicago. Nmap mostra anche il numero totale di indirizzi IP alla fine della scansione. La lista scan è un buon controllo per essere sicuri di avere gli indirizzi IP corretti per la propria scansione. Se gli host mostrano nomi di dominio non conosciuti, vale la pena indagare oltre per evitare di scansionare la rete dell'azienda sbagliata.

Poiché l'idea è quella di stampare semplicemente una lista di obiettivi, le opzioni per funzionalità di livello più alto (come ad esempio il port scanning, le indagini sul tipo di sistema operativo in esecuzione o il ping scan) non possono essere combinate con questa. Se si vuole disabilitare il ping scan e mantenere allo stesso tempo la possibilità di utilizzare funzionalità di alto livello, si legga la sezione sull'opzione -Pn (No ping).

Questa opzione indica a Nmap di non effettuare un port scan dopo un host discovery e di mostrare gli host che hanno risposto. Quest'opzione è spesso conosciuta come «ping scan», ma si può anche richiedere il traceroute ed eseguire script host NSE. Quest'azione è un gradino più invadente della List Scan, e spesso può essere usata per lo stesso scopo. Essa permette una mappatura di una rete obiettivo senza attrarre molta attenzione. Sapere quanti host sono attivi è più utile ad un attaccante rispetto ad una semplice List Scan di ogni indirizzo IP e nome di host.

Gli amministratori di sistema trovano spesso questa opzione utile allo stesso modo. Può essere usata facilmente per enumerare le macchine disponibili in una rete o tenere sotto osservazione la disponibilità di un singolo server. Questo approccio viene anche chiamato «ping sweep», ed è più affidabile di un ping all'indirizzo broadcast poiché molti host non rispondono alle richieste di questa categoria.

L'opzione -sn invia di default un pacchetto ICMP di tipo "echo request", un pacchetto TCP SYN alla porta 443, un pacchetto TCP ACK alla porta 80 e un pacchetto ICMP di tipo "timestamp request". Quando viene eseguita da un utente non privilegiato, viene inviati solo i pacchetti SYN (usando la chiamata connect ) alle porte 80 e 443 dell'obiettivo. Quando invece un utente privilegiato prova ad effettuare una scansione all'interno di una rete locale, vengono usate richieste ARP a meno che non venga specificata l'opzione --send-ip. L'opzione -sn può essere usata in combinazione con qualsiasi tipo di discovery probe (ovvero la famiglia di opzioni -P*, tranne -Pn) per avere una migliore flessibilità. Se viene usato uno qualsiasi di questi probe con opzioni sul numero di porta, allora i probe di default vengono annullati. Si raccomanda di usare queste tecniche avanzate se ci sono dei firewall restrittivi tra l'host che lancia Nmap e le reti di destinazione, altrimenti le destinazioni potrebbero non essere raggiunte nel caso in cui il firewall dovesse bloccare i probe o le risposte a questi ultimi.

Nelle versioni precedenti di Nmap, l'opzione -sn era chiamata -sP.

Questa opzione evita del tutto il passaggio di ricerca degli host di Nmap. Normalmente Nmap usa questo passaggio per trovare le macchine attive da sottoporre ad una scansione più approfondita. Di default, Nmap esegue un probing approfondito (come ad esempio un port scan, una version detection dei servizi o un Operating System detection) solo sugli host che sono stati trovati attivi. Disabilitare l'host discovery attraverso l'opzione -Pn obbliga Nmap a tentare la scansione richiesta su tutti gli host destinazione specificati. Quindi se si specifica sulla linea di comando una rete di destinazione di classe B (in CIDR /16) verranno sottoposti a scansione tutti i 65.535 indirizzi IP. A differenza della List Scan (nel quale l'host discovery viene saltato) anziché interrompersi e mostrare la lista di destinazioni, Nmap continua ad eseguire le funzioni richieste come se ogni IP di destinazione fosse attivo. Per evitare sia un ping scan che un port scan, ma permettere l'esecuzione degli script NSE, utilizzare le due opzioni -Pn -sn insieme.

Per le macchine in una rete ethernet locale, la scansione ARP verrà ancora eseguita (a meno che siano specificate le opzioni --disable-arp-ping e --send-ip) in quanto Nmap necessita degli indirizzi fisici (MAC addresses) per ulteriori scansioni degli hosts. Nelle versioni precedenti di Nmap, -Pn era chiamata -P0 e -PN.

Questa opzione invia un pacchetto TCP vuoto con il flag SYN attivo. La porta di destinazione di default è la 80 (configurabile durante la compilazione cambiando il parametro di define DEFAULT_TCP_PROBE_PORT nel file nmap.h), ma si possono specificare altre porte come parametro. La sintassi è la stessa dell'opzione -p tranne che gli indicatori del tipo di porta T: non sono permessi. Da notare che non ci devono essere spazi tra -PS e il numero di porta, ad esempio -PS22. Nel caso di più porte specificate, separate da virgola (ad esempio -PS22-25,80,113,1050,35000), si tenterà un probe verso ogni porta in parallelo.

Il flag SYN indica al sistema remoto che si sta tentando di stabilire una connessione. Normalmente la porta di destinazione dovrebbe essere chiusa, e un pacchetto di RST (reset) viene mandato indietro. Se la porta fosse aperta, il destinatario effettuerà il secondo passo della connessione TCP a tre vie (3-way-handshake) rispondendo con un pacchetto TCP SYN/ACK. La macchina che sta eseguendo Nmap interromperà la connessione inviando un pacchetto RST al posto di mandare l'usuale pacchetto ACK che completerebbe l'handshake e stabilirebbe una connessione completa. Il pacchetto RST viene mandato dal kernel della macchina che sta eseguendo Nmap, non da Nmap stesso.

A Nmap non interessa se la porta è aperta o chiusa. In ogni caso l'RST o il SYN/ACK ricevuti indicano che l'host è disponibile e risponde alle connessioni.

Nelle macchine UNIX solo l'utente privilegiato root generalmente è abilitato all'invio e alla ricezione di pacchetti TCP "raw" (non formattati, grezzi). Per quanto riguarda gli utenti non privilegiati si deve ricorrere alla chiamata di sistema connect, la quale viene lanciata su ogni porta di destinazione. Questo ha l'effetto di inviare pacchetti SYN all'host di destinazione come per stabilire una connessione. Se la connect restituisce rapidamente un messaggio di successo o un messaggio di errore ECONNREFUSED significa che lo stack TCP sottostante deve aver ricevuto un SYN/ACK o un RST e l'host viene marcato come disponibile. Se il tentativo di connessione viene lasciato in sospeso fino al raggiungimento di un certo timeout l'host è marcato come down o non disponibile.

Il ping TCP ACK è molto simile al ping SYN appena discusso. La differenza, come si può facilmente indovinare, consiste nel fatto che viene sollevato il flag TCP ACK al posto del SYN. Un tale pacchetto ACK finge di confermare dei dati inviati in una connessione TCP già stabilita, anche se tale connessione non esiste. In questo modo un host remoto risponderà sempre con un pacchetto RST, svelando così la propria esistenza e il fatto che siano attivi.

L'opzione -PA usa la stessa porta di default del SYN probe (ovvero la porta 80) e può ricevere in input un elenco di porte di destinazione nello stesso formato. Se un utente non privilegiato tenta quest'approccio si usa la scorciatoia della connect spiegata in precedenza. Questa scorciatoia non è ottimale perché in ogni caso la connect invia un pacchetto SYN e non un ACK.

La ragione per offrire entrambi i tipi di probe (SYN e ACK) è quella di massimizzare le possibilità di bypassare firewall. Molti amministratori configurano router e semplici firewall per bloccare pacchetti SYN in arrivo tranne quelli destinati a servizi pubblici come il sito web aziendale o il mail server. Questo impedisce ogni altro tipo di connessione in entrata garantendo al tempo stesso agli utenti di effettuare connessioni verso l'esterno senza incontrare ostacoli. Questo approccio "non-stateful" (per "non-stateful" si intende in questo caso la capacità di un firewall di tenere traccia delle connessioni che lo attraversano, NdT) utilizza poche risorse sul firewall/router ed è largamente supportato da filtri software e hardware. Il firewall di Linux conosciuto come Netfilter/iptables offre l'opzione --syn per implementare questo approccio "stateless". Quando un firewall implementa regole di questo tipo, un probe SYN (-PS) viene facilmente bloccato quando viene mandato ad una porta chiusa. In questi casi un probe ACK passerebbe indisturbato, come se non vi fossero quelle regole.

Un altro tipo comune di firewall utilizza regole "stateful" che lasciano cadere (drop) pacchetti non attesi. Questa caratteristica era inizialmente disponibile solo su firewall di fascia alta, anche se è diventata sempre più comune nel corso degli anni. Il sistema Netfilter/iptables la supporta mediante l'opzione --state, la quale marca pacchetti a seconda dello stato della connessione. Un probe SYN funzionerà più facilmente verso un tale sistema, poiché pacchetti ACK non attesi sono generalmente riconosciuti come non validi e lasciati cadere. Una soluzione a questa situazione poco piacevole è quella di inviare entrambe le tipologie di probe specificando le opzioni -PS e -PA.

Un'altra opzione di host discovery è il ping UDP, la quale manda un pacchetto UDP alle porte indicate. Per molte porte, il pacchetto sarà vuoto, anche se utilizzare un payload specifico del protocollo aumentale probabilità di risposta. Vedi la sezione «UDP payloads: nmap-payloads» (https://nmap.org/book/nmap-payloads.html) per una descrizione del database dei payloads. Il contenuto del pacchetto può essere gestito con le opzioni --data, --data-string e --data-length.

L'elenco di porte va specificato nello stesso formato già discusso in precedenza nelle opzioni -PS e -PA. Se non si specifica alcuna porta viene usata la 40125 di default. Questo valore può essere impostato durante la compilazione cambiando il parametro DEFAULT_UDP_PROBE_PORT nel file nmap.h. Si usa di default una porta poco comune perché inviare dati ad una porta già aperta è spesso non desiderabile per questo tipo particolare di scansione.

Una volta raggiunta una porta UDP chiusa sulla macchina di destinazione, il probe UDP dovrebbe provocare un pacchetto ICMP di tipo "port unreachable" (porta irraggiungibile). Questo indica a Nmap che l'host è funzionante e disponibile. Altri tipi di pacchetti ICMP di errore, come ad esempio host o rete "unreachable" (non disponibile) o "TTL exceeded" (superato il tempo di vita del pacchetto) indicano un host non funzionante o irraggiungibile. Una mancanza di risposta viene interpretata alla stessa maniera. Se si raggiunge una porta aperta la maggior parte dei servizi semplicemente ignorano il pacchetto vuoto e non rimandano alcuna risposta. Questo spiega perché il probe di default è la porta 40125, la quale si usa molto raramente. Pochi servizi, tra i quali «chargen», rispondono a un pacchetto UDP vuoto, rivelando così a Nmap la disponibilità della macchina in questione.

Il vantaggio primario di questo tipo di scansione è che riesce a bypassare firewall e filtri che controllano solo pacchetti TCP. Ad esempio, una volta avevo un router a banda larga wireless Linksys BEFW11S4. L'interfaccia esterna di questa periferica filtrava tutte le porte TCP di default, ma i probe UDP provocavano messaggi di "Port unreachable" rivelando così l'esistenza del device.

Questa opzione invia un pacchetto SCTP contenente un INIT chunk minimale. La porta di destinazione di default è la 80 (configurabile durante la compilazione cambiando il valore di DEFAULT_SCTP_PROBE_PORT_SPEC nel file nmap.h). Altre porte possono essere specificate come parametro. La sintassi è la stessa dell'opzione -p tranne che gli indicatori del tipo di porta S: non sono permessi. Da notare che non ci devono essere spazi tra -PY e il numero di porta, ad esempio -PY22. Nel caso di più porte specificate, separate da virgola (ad esempio -PY22,80,179,5060), si tenterà un probe verso ogni porta in parallelo.

L'INIT chunk suggerisce al sistema remoto che stai tentando di stabilire un'associazione. Normalmente la porta di destinazione dovrebbe essere chiusa e un ABORT chunk verrà inviato come risposta. Se la porta invece dovesse essere aperta, l'obiettivo passerà al secondo step della connessione SCTP a quattro vie (four-way-handshake) rispondendo con un INIT-ACK chunk. Se la macchina che sta eseguendo Nmap ha la funzione di SCTP stack, abbatte l'associazione nascente rispondendo con un ABORT chunk invece che inviare un COOKIE-ECHO chunk, che sarebbe lo step successivo nel processo di associazione. Il pacchetto ABORT viene mandato dal kernel della macchina che sta eseguendo Nmap in risposta ad un INIT-ACK inaspettato, non da Nmap stesso.

Ad Nmap non interessa se la porta di destinazione risulta aperta o chiusa. Entrambi i pacchetti discussi in precedenza (ABORT e INIT-ACK) ricevuti in risposta, indicano ad Nmap che l'host è disponibile e risponde alle connessioni.

Sulle macchine Unix, solo l'utente privilegiato root generalmente è abilitato ad inviare e ricevere pacchetti SCTP "raw" (non formattati, grezzi). Usare SCTP INIT Pings (-PY) non è attualmente possibile per gli utenti non privilegiati.

In aggiunta ai meno comuni tipi di host discovery TCP, UDP e SCTP discussi in precedenza, Nmap può anche mandare i pacchetti standard come il famoso programma ping. Nmap manda un pacchetto ICMP type 8 ("echo request") all'indirizzo IP di destinazione, aspettandosi un type 0 ("echo reply") di ritorno dagli host disponibili. Sfortunatamente per chi deve scoprire la topologia di una rete, molti host e firewall ora bloccano questo tipo di pacchetti anziché rispondere come richiesto dall'RFC 1122[1]. Per questa ragione le scansioni basate solo su ICMP sono raramente abbastanza affidabili nei riguardi di destinazioni sconosciute su Internet. Tuttavia per i sistemisti di rete che devono tenere sotto controllo una rete interna, esse possono essere un approccio pratico ed efficiente. Si usi l'opzione -PE per abilitare questo comportamento di "echo request".

Mentre la "echo request" è la richiesta standard del ping ICMP, Nmap non si ferma qui. Gli standard ICMP (RFC 792[2] e RFC 950[3]) specificano inoltre i pacchetti "timestamp request", "information request" e "address mask request" (rispettivamente "richiesta di timestamp", ovvero data e ora, "richiesta di informazioni" e "richiesta della maschera di rete") mediante i codici ICMP 13, 15 e 17. Dato che lo scopo dichiarato di questo tipo di richieste è quello di avere informazioni quali la maschera di rete e l'ora corrente, essi possono facilmente essere usati per l'host discovery. Un sistema che risponde è funzionante e disponibile. Nmap non implementa allo stato attuale pacchetti di "information request", poiché in genere non sono supportati comunemente. L'RFC 1122 specifica che «un host NON DOVREBBE implementare questi messaggi» (il maiuscolo negli RFC indica comportamenti precisi). Il timestamp (data e ora) e le richieste di maschera di rete possono essere inviate rispettivamente mediante le opzioni -PP e -PM. Una risposta di tipo timestamp (codice ICMP 14) o di tipo address mask (codice 18) rivela che un host è disponibile. Queste due richieste possono essere utili qualora un amministratore dovesse bloccare i pacchetti di "echo request" ma dimenticarsi che altre query ICMP possono essere usate per lo stesso scopo.

Una delle nuove opzioni di host discovery è la IP Protocol Ping, la quale invia pacchetti IP con lo specifico numero di protocollo impostato nel loro IP header. La lista dei protocolli ha lo stesso formato della lista delle porte vista in precedenza nelle opzioni di host discovery TCP, UDP e SCTP. Se nessun protocollo viene specificato, di default vengono inviati pacchetti IP multipli per ICMP (protocollo 1), IGMP (protocollo 2) e IP-in-IP (protocollo 4). I protocolli di default possono essere configurati in fase di compilazione cambiando il valore di DEFAULT_PROTO_PROBE_PORT_SPEC nel file nmap.h. Si tenga presente che per i protocolli ICMP, IGMP, TCP (protocollo 6), UDP (protocollo 17) e SCTP (protocollo 132), i pacchetti vengono inviati con i loro opportuni headers mentre gli altri protocolli vengono inviati senza nessun dato aggiuntivo oltre all'IP header (a meno che non siano specificate le opzioni --data, --data-string o --data-length).

Questo metodo di host discovery cerca sia risposte utilizzando lo stesso protocollo di un probe, che messaggi "unreachable" utilizzando il protocollo ICMP, che significa che il protocollo non è supportato dall'host di destinazione. Entrambe le risposte indicano che l'obiettivo è attivo.

Una delle situazioni più comuni di utilizzo di Nmap è la scansione di una LAN ethernet. Nella maggior parte delle LAN, specialmente quelle in cui viene usato il benedetto intervallo di indirizzi privati specificato dall'RFC 1918, la maggior parte degli indirizzi IP è inutilizzato. Quando Nmap prova ad inviare pacchetti IP raw come le "echo request" ICMP, il sistema operativo deve determinare l'indirizzo hardware (ARP) corrispondente all'indirizzo IP di destinazione, in modo da poter indirizzare correttamente il frame ethernet. Questo è spesso lento e problematico, in quanto i sistemi operativi non sono stati scritti prevedendo di dover fare milioni di richieste ARP verso host inesistenti in un breve lasso di tempo.

L'ARP scan lascia a Nmap e ai suoi algoritmi ottimizzati l'incarico delle richieste ARP. Nel caso in cui si riceva una risposta, Nmap non si deve neanche preoccupare dei ping basati su IP perché a questo punto sa già che l'host è raggiungibile. Questo rende l'ARP scan molto veloce e molto più affidabile delle normali scansioni basate su IP. Infatti questo è il comportamento di default quando si deve effettuare uno scan su host che Nmap riconosce come presenti nella rete locale. Anche se vengono specificati differenti tipi di ping (come -PE o -PS), Nmap usa comunque ARP per ogni target che è sulla stessa LAN. Se non si vuole assolutamente un ARP scan, specificare l'opzione --disable-arp-ping.

Per IPv6 (opzione -6), -PR utilizza ICMPv6 Neighbor Discovery al posto di ARP. Neighbor Discovery, definito nell'RFC 4861, può essere visto come l'equivalente per IPv6 di ARP.

Nmap normalmente esegue un ARP o IPv6 Neighbor Discovery (ND) discovery degli host locali connessi ad una rete ethernet, anche se altre opzioni di host discovery, come -Pn o -PE, vengono utilizzate. Per disabilitare questo comportamento implicito, utilizzare l'opzione --disable-arp-ping.

Il comportamento di default è solitamente più veloce, ma quest'opzione è utile nelle reti che utilizzano un proxy ARP, nelle quali un router risponde in modo speculare a tutte le richieste ARP, facendo sembrare attivi tutti gli obiettivi di un ARP scan.

I traceroutes vengono eseguiti in fase di post-scan utilizzando informazioni provenienti dai risultati della scansione per determinare la porta e il protocollo che più probabilmente raggiungono l'obiettivo. Opera con tutte le tipologie di scansione tranne le connect scans (-sT) e le idle scans (-sI). Tutti i tracciamenti utilizzano il modello di timing dinamico ("dynamic timing model") di Nmap e vengono eseguiti in parallelo.

Traceroute lavora inviando pacchetti con un basso TTL (time-to-live) in attesa di ricevere un messaggio ICMP "Time Exceeded" dagli intermediari (hops) posti tra la macchina che esegue la scansione e l'host obiettivo. Le implementazioni standard di traceroute iniziano con un TTL settato a 1 e aumentano il TTL finché l'host di destinazione non viene raggiunto. I traceroute di Nmap iniziano con un alto TTL e lo diminuiscono fino ad arrivare a zero. Lavorare a ritroso consente ad Nmap di utilizzare intelligenti algoritmi di caching per velocizzare il tracciamento su più host. In media Nmap invia 5-10 pacchetti in meno per host, in base alle condizioni della rete. Se una singola subnet viene scansionate (ad esempio 192.168.0.0/24) Nmap potrebbe dover inviare solo due pacchetti per la maggior parte degli host.

Indica a Nmap di non effettuare mai una risoluzione inversa del nome mediante DNS sugli indirizzi IP rilevati. Poiché il DNS è spesso lento anche con il risolutore parallelo integrato di Nmap, questa opzione rende l'intero processo di scansione più veloce.

Indica a Nmap di effettuare sempre la risoluzione inversa dei nomi mediante DNS sugli indirizzi IP rilevati. Generalmente la risoluzione inversa viene effettuata solo quando un host viene rilevato come attivo.

Di default Nmap risolve gli indirizzi IP mandando richieste direttamente ai name servers (server dei nomi) configurati sulla macchina su cui è in esecuzione Nmap. Molte richieste (spesso nell'ordine delle dozzine) sono effettuate in parallelo per migliorare le performance. Si specifichi quest'opzione se si vuole usare il proprio DNS (richiedendo un indirizzo IP alla volta usando la system call getnameinfo). Questa operazione è più lenta e raramente utile a meno che non ci sia un bug nel codice di risoluzione dei nomi di Nmap (per favore si contattino gli sviluppatori se questo è il caso). Il resolver di sistema è sempre usato per le scansioni su IPv6.

Di default Nmap cercherà di determinare i server DNS da usare per le reverse query usando il file resolv.conf (UNIX) o il Registro (Win32) sulla macchina su cui viene eseguito. In alternativa si può usare quest'opzione per indicare server alternativi. Tuttavia quest'opzione viene ignorata nel caso si specifichi l'opzione --system-dns o se si sta eseguendo una scansione IPv6. L'uso di più server DNS è spesso più veloce specialmente se si specificano server DNS autoritari per lo spazio IP di destinazione. Quest'opzione inoltre attrae meno l'attenzione, dato che le tue richieste possono essere rimbalzate praticamente da ogni server DNS su Internet.

Quest'opzione torna utile anche quando si eseguono scansioni di reti private. Alle volte solo alcuni name server forniscono le correte informazioni di reverse e non sempre potresti sapere dove questi si trovano. Puoi scansionare la rete sulla porta 53 (magari con una version detection), quindi provare delle List Scan (-sL) di Nmap specificando ogni volta un name server diverso con l'opzione --dns-servers finché non si trova quello desiderato.

Un'applicazione accetta attivamente su questa porta connessioni TCP, datagrammi UDP o associazioni SCTP. La ricerca di questo tipo di porte è spesso l'obiettivo primario del port scanning. Chi si dedica alla sicurezza sa che ogni porta aperta è una strada verso un attacco. Gli attaccanti e i tester di sicurezza (penetration testers, conosciuti anche come "pen-testers", NdT) hanno come obiettivo quello di trovare e trarre vantaggio dalle porte aperte, mentre d'altro canto gli amministratori di rete e i sistemisti provano a chiuderle o a proteggerle con firewall senza limitare gli utenti autorizzati al loro uso. Le porte aperte sono anche interessanti per tutta una serie di scansioni non indirizzate unicamente alla sicurezza, perché mostrano che servizi sono disponibili in una rete.

Una porta chiusa è accessibile (riceve e risponde ai pacchetti di probe di Nmap) ma non vi è alcuna applicazione in ascolto su di essa. Esse possono rendersi utili nel mostrare che un host è attivo su un indirizzo IP (durante l'host discovery o il ping scanning) o in quanto parte integrante dell'Operating System discovery. Poiché una porta chiusa è raggiungibile, può essere interessante effettuare una scansione più tardi nel caso alcune vengano aperte. Chi amministra una macchina o una rete può voler bloccare tali porte con un firewall ed in questo caso esse apparirebbero come filtrate, come mostrato in seguito.

In questo caso Nmap non può determinare con esattezza se la porta sia aperta o meno, perché un filtro di pacchetti impedisce ai probe di raggiungere la porta. Questo filtro può esser dovuto a un firewall dedicato, alle regole di un router, o a un firewall software installato sulla macchina stessa. Queste porte forniscono poche informazioni e rendono frustrante il lavoro dell'attaccante. A volte esse rispondono con un messaggio ICMP del tipo 3, codice 13 ("destination unreachable: communication administratively prohibited", ovvero "destinazione non raggiungibile: comunicazione impedita da regole di gestione"), ma in genere sono molto più comuni i filtri di pacchetti che semplicemente ignorano i tentativi di connessione senza rispondere. Questo obbliga Nmap a riprovare diverse volte, semplicemente per essere sicuri che il pacchetto non sia stato perduto a causa di una congestione di rete o di problemi simili piuttosto che dal firewall o dal filtro stesso. Questo riduce drammaticamente la velocità della scansione.

Lo stato "unfiltered" indica che una porta è accessibile, ma che Nmap non è in grado di determinare se sia aperta o chiusa. Solo la scansione di tipo ACK, usata per trovare e classificare le regole di un firewall, posiziona una porta in questo stato. Una scansione di porte in questo stato ("non filtrate") mediante altri tipi di scansione come il Window scan (scan per finestre di connessione), il SYN scan o il FIN scan aiuta a determinare se la porta sia aperta o chiusa.

Nmap posiziona le porte in questo stato quando non è in grado di determinare se una porta sia aperta o filtrata. Questo accade in quelle scansioni per le quali una porta aperta non risponde in alcun modo. La mancanza di informazioni può significare inoltre che un filtro di pacchetti ha lasciato cadere ("drop") il probe o qualsiasi risposta sia stata generata in seguito a questo. Scansioni che classificano porte in questo stato sono le scansioni UDP, IP, FIN, NULL e Xmas.

Questo stato è usato quando Nmap non è in grado di determinare se una porta sia chiusa o filtrata. Viene usato solo per l'IP ID idle scan.

Il SYN scan è l'opzione di default ed è la più usata per buone ragioni. Può essere effettuato velocemente: effettua la scansione su migliaia di porte al secondo su una rete veloce non limitata da firewall restrittivi. Il SYN scan è relativamente nascosto e poco invasivo, poiché non completa mai le connessioni TCP. Funziona inoltre con ogni stack TCP compatibile e non dipende dalle idiosincrasie di piattaforme specifiche come fanno gli altri tipi di scan di Nmap quali FIN/NULL/Xmas, Maimon e Idle scan. Inoltre permette una differenziazione chiara ed affidabile tra le porte appartenenti agli stati open, closed e filtered.

Questa tecnica è spesso indicata come "scanning semi-aperto" (tradotto letteralmente per esigenze di comprensione, da "half-open scanning", NdT), perché non viene aperta una connessione TCP completa. Viene mandato un pacchetto SYN come se si fosse sul punto di aprire una connessione reale e si attende una risposta. Un SYN/ACK indica che la porta è in ascolto (aperta), mentre un RST (reset) indica che la porta non è in ascolto. Se non viene ricevuta nessuna risposta dopo diverse ritrasmissioni la porta viene marcata come filtrata. La porta viene marcata come tale anche se viene ricevuto un pacchetto di errore "ICMP unreachable" (tipo 3, codici 1, 2, 3, 9, 10, 13). La porta viene considerata aperta anche nel caso in cui un pacchetto SYN (senza il flag ACK) viene ricevuto in risposta. Questo in base ad una feature TCP estremamente rara conosciuta come "apertura simultanea" ("simultaneous open") o connessione "split handshake" (vedere https://nmap.org/misc/split-handshake.pdf).

La scansione di tipo TCP connect è la scansione TCP di default dove la scansione SYN non è un'opzione viabile. Questo è il caso in cui un utente non ha privilegi sull'invio di pacchetti "raw". Anziché scrivere pacchetti "raw" come in molti altri tipi di scansioni, Nmap richiede al sistema operativo sottostante di stabilire una connessione con la macchina di destinazione invocando la chiamata di sistema connect. Questa è la stessa chiamata di alto livello invocata per stabilire una connessione da browser web, client p2p e molte altre applicazioni orientate all'utilizzo in rete. Essa è parte dell'interfaccia di programmazione conosciuta come Berkeley Sockets API. Anziché leggere le risposte ai pacchetti "raw" inviati direttamente sul cavo, Nmap usa questa API per ottenere informazioni sullo stato di ogni tentativo di connessione.

Quand'è possibile, il SYN scan è generalmente una scelta migliore. Nmap ha meno controllo sulla syscall connect rispetto ai pacchetti "raw", rendendolo quindi meno efficiente. La syscall completa le connessioni alle porte aperte specificate anziché limitarsi al reset dovuto alla scansione semi-aperta del SYN scan. Non solo questo approccio richiede più tempo e numero maggiore di pacchetti per ottenere le stesse informazioni, ma le macchine obiettivo sono più propense a tenere traccia (log) della connessione. Inoltre un IDS ("Intrusion Detection System", sistema di controllo delle intrusioni) decente se ne accorgerà. Tuttavia la maggior parte delle macchine non hanno tali sistemi di allarme. Molti servizi sui propri sistemi UNIX standard aggiungeranno una nota al syslog, e alle volte un messaggio di errore criptico, quando Nmap si connette e chiude la connessione senza inviare dati di alcun tipo. Solo alcuni patetici servizi andranno in crash in queste condizioni, nonostante non sia comune. Un amministratore che dovesse vedere un insieme di tentativi di connessioni provenienti da un singolo sistema saprà infine che è vittima di un connect scan.

Così come i servizi più comuni su Internet girano attraverso il protocollo TCP, anche i servizi UDP[4] sono altrettanto diffusi. DNS, SNMP e DHCP (sulle porte registrate 53, 161/162 e 67/68) sono tre dei più comuni. Poiché lo scan su UDP è generalmente più lento e più difficoltoso di quello su TCP, alcuni esaminatori di sicurezza ("security auditors") ignorano questo tipo di porte. Ciò è un errore, poiché i servizi UDP vulnerabili sono abbastanza comuni e un attaccante sicuramente non ignorerà completamente questo protocollo. Fortunatamente Nmap può aiutare ad enumerare le porte UDP.

Lo scan UDP si attiva con l'opzione -sU. Può essere combinato con uno scan di tipo TCP come ad esempio un SYN scan (-sS) per controllare entrambi i protocolli nel corso della stessa sessione.

Lo scan UDP funziona inviando pacchetti UDP ad ogni porta di destinazione. Per alcune porte comuni, come la 53 e la 161, un carico dati viene aggiunto per aumentare le probabilità di risposta, ma per la maggior parte delle porte il pacchetto viene inviato vuoto, a meno che non vengano specificate le opzioni --data, --data-string o --data-length. Se viene restituito un errore ICMP "port unreachable" (tipo 3, codice 3) significa che la porta è closed (chiusa). Altri errori ICMP di tipo "unreachable" (irraggiungibile) come quelli del tipo 3, codici 1, 2, 9, 10 o 13 andranno ad identificare la porta come filtered (filtrata). Talvolta un servizio risponderà con un pacchetto UDP, dimostrando quindi che lo stato della porta è open (aperta). Se non viene ricevuta alcuna risposta dopo alcune ritrasmissioni, la porta viene classificata come open|filtered (aperta|filtrata). Questo significa che la porta può essere aperta o che probabilmente un filtro di pacchetti sta bloccando la comunicazione. Un version detection (-sV) può essere usato per aiutare a differenziare le porte veramente aperte da quelle che sono filtrate.

La sfida maggiore con l'UDP scan è la velocità. Le porte aperte e filtrate raramente inviano qualche risposta, lasciando Nmap in timeout e facendolo ritrasmettere per evitare il caso in cui il probe o la risposta siano andati perduti. Le porte chiuse sono spesso un problema ancora maggiore: esse generalmente rimandano un pacchetto ICMP "port unreachable error", ma a differenza dei pacchetti RST rimandati dalle porte chiuse TCP come risposta ad un SYN o connect scan, molti host limitano il tasso di invio di tali pacchetti di default. Linux e Solaris sono particolarmente restrittivi da questo punto di vista. Ad esempio, il kernel 2.4.20 limita i messaggi di "destination unreachable" a uno al secondo (definito in net/ipv4/icmp.c).

Nmap si accorge di questi limiti sulla frequenza di invio e rallenta l'invio dei probe in maniera dinamica, per evitare di intasare la rete con pacchetti inutili che la macchina di destinazione ignorerà comunque. Sfortunatamente, un limite come quello di Linux di un pacchetto al secondo rende una scansione su 65.535 porte di una durata teorica di più di 18 ore. Suggerimenti per rendere più veloce gli scan UDP sono quelli di effettuare scansioni su più host in parallelo, fare uno scan veloce preliminare sulle porte più usate, effettuare la scansione dall'interno del firewall ed infine usare l'opzione --host-timeout per evitare host troppo lenti nel rispondere.

SCTP[5] è un'alternativa relativamente nuova rispetto ai protocolli TCP ed UDP, il quale combina molte delle caratteristiche di entrambi aggiungendo nuove funzionalità come il multi-homing e il multi-streaming. Principalmente Viene utilizzato per i servizi collegati ai protocolli SS7/SIGTRAN, ma potenzialmente può essere utilizzato per altre applicazioni. Lo scan SCTP INIT scan è l'equivalente del TCP SYN scan: viene eseguito velocemente e scansiona migliaia di porte al secondo su una rete veloce non limitata da firewall restrittivi. Come il SYN scan, l'INIT scan è relativamente nascosto e poco invasivo, dato che non completa mai le connessioni SCTP. Consente inoltre una chiara ed affidabile differenziazione tra gli stati della porta open (aperta), closed (chiusa) e filtered (filtrata).

Questa tecnica è conosciuta come "half-open" (semi-aperta), in quanto non si completata l'associazione SCTP. Viene inviato un INIT chunk, esattamente come se si volesse iniziare una reale associazione. Se si riceve un INIT-ACK chunk in risposta, significa che la porta è in ascolto (aperta), mentre se si riceve un ABORT chunk significa che la porta non è in ascolto (chiusa). Se non si riceve nessuna risposta dopo alcune ritrasmissioni, la porta viene marcata come filtered. La porta viene anche considerata filtrata se viene ricevuto un messaggio ICMP "unreachable error" (tipo 3, codice 1, 2, 3, 9, 10 o 13).

Queste tre tipologie di scansione (e molte altre sono possibili con l'opzione --scanflags descritta nella prossima sezione) sfruttano una piccola vulnerabilità nell'RFC del protocollo TCP[6] per distinguere tra le porte open (aperte) e closed (chiuse). A pagina 65 si dice che «se lo stato della porta [di destinazione] è CHIUSO ... un segmento in arrivo che non contiene un RST causerà l'invio di un RST in risposta». La pagina successiva discute di pacchetti inviati a porte aperte senza i bit SYN, RST o ACK impostati, indicando che: «questa situazione è decisamente improbabile, ma se dovesse capitare i segmenti vanno ignorati e si deve ritornare [alla funzione chiamante, NdT]».

Quando si scansionano sistemi aderenti a questo testo RFC, qualunque pacchetto che non contenga i bit SYN, RST o ACK causerà un RST di ritorno se la porta è chiusa e nessuna risposta se la porta è aperta. Finché nessuno di questi tre bit è incluso, qualunque combinazione degli altri tre bit (FIN, PSH, e URG) va bene. Nmap sfrutta tutto ciò tramite questi tre tipi di scan:

NULL scan (-sN)

FIN scan (-sF)

Xmas scan (-sX)

Questi tre tipi di scan sono esattamente identici nel comportamento, ad eccezione delle attivazioni dei tre bit nei pacchetti TCP usati per la verifica delle porte. Se viene ricevuto un pacchetto RST, la porta è considerata closed, mentre l'assenza di risposta indica che la porta è open|filtered. La porta è marcata come filtered se viene ricevuto un pacchetto ICMP "unreachable" (tipo 3, codice 1, 2, 3, 9, 10 o 13).

Il vantaggio sostanziale di questi tipi di scan è che possono penetrare in certi non-stateful firewall e packet filtering router. Un altro vantaggio è che questi tipi di scansione sono un po più invisibili anche dei SYN scan. In ogni caso non è corretto fare cieco affidamento su questo, gran parte dei moderni prodotti IDS possono essere configurati in modo da rilevarli. Il grande svantaggio è che non tutti i sistemi seguono alla lettera la RFC 793. Un buon numero di sistemi manda risposte RST ai pacchetti di controllo indipendentemente dal fatto che le porte siano aperte o chiuse. Questo causa il fatto che tutte le porte appaiano come closed. I più diffusi sistemi operativi che fanno questo sono Microsoft Windows, molti apparati Cisco, BSDI e IBM OS/400. Questo scan funziona applicato alla maggior parte dei sistemi UNIX. Un altro svantaggio di questi scan è che non riescono a distinguere tra le porte open e quelle filtered, dando come risposta open|filtered.

Questo scan è diverso dagli altri discussi finora dal momento che non serve per determinare se le porte sono open (o open|filtered). Viene usato per mappare le regole di firewalling determinando se sono stateful o no e quali porte sono filtrate.

I pacchetti dell'ACK scan hanno soltanto il flag ACK abilitato (a meno che non si usi --scanflags). Mentre si scansionano sistemi non filtrati, sia le porte open che le porte closed manderanno pacchetti RST. Nmap poi le cataloga come unfiltered, nel senso che è possibile raggiungerle con un pacchetto ACK, ma che siano aperte o chiuse non è determinabile. Le porte che non rispondono, o mandano certi errori ICMP (tipo 3, codice 1, 2, 3, 9, 10 o 13), sono etichettate come filtered.

Il window scan è esattamente la stessa cosa di ACK scan, ad eccezione del fatto che sfrutta un dettaglio di implementazione di certi sistemi per differenziare le porte aperte e quelle chiuse, invece di scrivere sempre unfiltered quando restituisce un RST. Lo fa esaminando il campo TCP Window del pacchetto RST che ritorna. In alcuni sistemi le porte aperte usano una grandezza della finestra positiva (anche per i pacchetti RST), mentre nelle porte chiuse la grandezza della finestra è zero. Quindi, invece di catalogare sempre le porte come unfiltered quando si riceve un RST di ritorno, il Window scan lista le porte come open o closed a seconda che il valore in quel RST (reset) sia, rispettivamente, positivo o pari a zero.

Questo scan fa affidamento a un dettaglio implementativo di una minoranza di sistemi presenti in Internet, quindi ciò non è sempre affidabile. Nei sistemi in cui questo dettaglio implementativo non sussiste, di norma lo scan segnalerà tutte le porte closed. Ovviamente sarà possibile che la macchina non abbia realmente nessuna porta aperta. Se la maggior parte delle porte è closed, ma alcune porte comuni (come la 22, la 25 o la 53) appaiono filtered, il sistema è quasi sicuramente suscettibile a questo tipo di scan. Occasionalmente, alcuni altri sistemi presenteranno un comportamento esattamente opposto. Se lo scan riporta 1.000 porte aperte e 3 chiuse o filtrate, allora quelle 3 saranno con ogni probabilità proprio quelle aperte.

Il Maimon scan è stato nominato così in onore al suo scopritore, Uriel Maimon. Egli descrisse questa tecnica nell'articolo #49 della rivista Phrack (Novembre 1996). Nmap, che incluse questa tecnica, fu rilasciato due articoli dopo. Questa tecnica esattamente uguale ai NULL, FIN e Xmas scan, ad eccezione del fatto che i pacchetti di scansione sono FIN/ACK. In accordo con la RFC 793[6] (TCP), un pacchetto RST dovrebbe essere generato in risposta a tale stimolo. Ad ogni modo, Uriel notò che in molti sistemi derivati da BSD il pacchetto veniva scartato se la porta era aperta.

Gli utilizzatori molto avanzati di Nmap hanno necessità di non limitarsi semplicemente ad utilizzare le scansioni tipiche offerte. L'opzione --scanflags consente di designare una scansione personalizzata specificando arbitrariamente i flag TCP necessari. Liberate la vostra inventiva, ed evitate così che i vendor di Intrusion Detection Systems trovino nuove regole da aggiungere ai loro sistemi semplicemente sfogliando la "Man Page" di Nmap!

I parametri dell'opzione --scanflags possono essere un valore numerico indicante i flag TCP, come ad esempio 9 (PSH e FIN) anche se l'utilizzo di nomi simbolici risulta comunque più semplice. Basta mettere creare una qualsiasi combinazione di URG, ACK, PSH, RST, SYN e FIN. Per esempio, --scanflags URGACKPSHRSTSYNFIN imposta tutti i flag, anche se non risulta molto utile al fine della scansione. L'ordine con cui vengono specificati non è rilevante.

Oltre allo specificare i flag desiderati, è possibile indicare un tipo di scansione TCP (come -sA o -sF). Questo specifica come Nmap deve interpretare le risposte. Per esempio, un SYN scan considera la mancanza di risposta come una porta filtered, mentre un FIN scan interpreta lo stesso comportamento per identificare una porta open|filtered. Nmap si comporterà nello stesso modo che per la scansione normale, tranne che per il fatto di interpretare i flag TCP che sono stati specificati. Se non viene indicato un diverso tipo di scansione, viene automaticamente utilizzata la SYN scan.

L'SCTP COOKIE ECHO è più avanzato rispetto all'SCTP scan. Sfrutta il fatto che le implementazioni SCTP dovrebbero lasciar cadere (drop) in modo trasparente i pacchetti che contengono dei COOKIE ECHO chunk sulle porte aperte ed inviare un ABORT se la porta è chiusa. Il vantaggio di questo tipo di scansione sta nel fatto che è meno rilevabile rispetto all'INIT scan. Inoltre, ci possono essere firewall che utilizzano regole non-stateful che bloccano gli INIT chunk, ma non i COOKIE ECHO chunk. Non illudersi però che quest'opzione renda un port scan invisibile; un buon IDS riesce ad individuare anche le scansioni SCTP COOKIE ECHO. Lo svantaggio è che le scansioni SCTP COOKIE ECHO non differenziano le porte tra open e filtered lasciando come stato open|filtered in entrambi i casi.

Questo metodo di scansione avanzato permette di effettuare una scansione TCP completamente invisibile dell'obiettivo (ovvero nessun pacchetto viene inviato dall'indirizzo IP reale da cui si sta effettuando la scansione.) Viene diversamente utilizzato un unico attacco parallelo che utilizza la predicibilità dell'ID relativo alla sequenza di frammentazione generato dallo zombie host per ottenere informazioni sulle porte aperte dell'obiettivo. I sistemi IDS interpreteranno la scansione come se provenisse dalla macchina zombie specificata (che deve essere attiva e rispondere a certi criteri). Tutti i dettagli su questa affascinante tecnica di scansione si trovano al seguente link « TCP Idle Scan (-sI)[7]».

Oltre che essere straordinariamente nascosto (grazie alla sua natura "invisibile"), questo tipo di scansione permette di creare una mappa indicante le relazioni tra le macchine da un punto di vista dell'indirizzo IP. I risultati dalla scansione mostrano le porte aperte dalla prospettiva dell'indirizzo IP della macchina zombie. Risulta così possibile effettuare scansioni utilizzando diversi zombie che si ritiene possano attraversare router o sistemi con packet filter.

È possibile aggiungere i due punti (:) seguiti dal numero di porta per l'host zombie, se si vuole sondare una particolare porta per vedere i cambiamenti nell'IP ID. Diversamente Nmap utilizzerà the porta che utilizza di default per i ping TCP (80).

L'IP protocol scan permette di determinare che protocolli IP (TCP, ICMP, IGMP, ecc.) sono supportati dalle macchine obiettivo. Non è tecnicamente un port scan, dato che utilizza i numeri indicanti il protocollo IP e non i numeri di porta TCP o UDP. Utilizza comunque ancora l'opzione -p per scegliere il protocollo da scansionare, riporta i risultati nel normale formato della tabella delle porte ed utilizza lo stesso engine sottostante al port scanning reale. Per questo motivo è profondamente analogo ad un port scan e viene trattato in questa sezione.

Oltre che essere intrinsecamente utile, il protocol scan dimostra la potenza del software open-source. Per quanto l'idea fondamentale è abbastanza semplice, non immaginavo di aggiungerla fino a quando non avessi ricevuto richieste per questa funzionalità. Nell'estate del 2000, Gerhard Rieger concepì l'idea e scrisse un'eccellente patch che la implementasse, spedendola poi alla mailing list nmap-hackers. Io incorporai questa patch in Nmap e ne rilasciai una nuova versione il giorno seguente. Alcuni software commerciali ebbero clienti talmente soddisfatti da contribuire allo sviluppo di questa tecnica con i loro miglioramenti!

Il protocol scan funziona in modo simile all'UDP scan solo che invece di agire sul campo "port number" del pacchetto UDP, invia degli header di pacchetto IP e agisce sul campo di 8 bit relativo al protocollo. Questi headers sono tipicamente vuoti, non contengo dati e nemmeno l'header proprietario del protocollo dichiarato, ad eccezione di TCP, UDP, ICMP, SCTP e IGMP. Un header valido per queste eccezioni viene incluso perché, diversamente, alcuni sistemi non li invierebbero e perché Nmap è già provvisto di funzioni per crearli. Invece che cercare un messaggio ICMP "port unreachable", il protocol scan è alla ricerca di un messaggio ICMP "protocol unreachable". Se Nmap riceve una qualunque risposta di qualunque protocollo dall'host scansionato, Nmap indica tale protocollo come open. Un errore ICMP "protocol unreachable" (tipo 3, codice 2) fa sì che il protocollo sia indicato come closed. Altri errori ICMP "unreachable" (tipo 3, codice 1, 3, 9, 10 o 13) fanno classificare il protocollo come filtered (denotando, contestualmente, che il protocollo ICMP è open). Se non viene ricevuta alcuna risposta, il protocollo è identificato come open|filtered.

Un'interessante caratteristica del protocollo FTP (RFC 959[8]) è il supporto per le cosiddette "proxy FTP connections". Questa permette all'utente di connettersi ad un server FTP e richiedere che il file sia inviato ad un server FTP differente. Tale caratteristica si presta per varie tipologie di abuso, cosicché molti server hanno smesso di supportarla. Uno degli abusi nell'utilizzo di questa peculiarità è la possibilità di far effettuare al server FTP un port scan verso altri host, basta semplicemente richiedere al server FTP di inviare un file ad ognuna delle porte che vogliamo scansionare. Il messaggio di errore ci permetterà di dedurre se la porta è aperta o meno. Questo è un ottimo modo per aggirare i firewall in quanto i server FTP aziendali sono spesso posizionati nella rete così da poter accedere a più host interni di quanto sia possibile fare da Internet. Nmap supporta l'FTP bounce scan attraverso l'opzione -b. I parametri per tale opzione devono rispettare il formato: username:password@server:port dove Server è l'hostname o l'indirizzo IP di un server FTP vulnerabile a questo attacco. Come in una URL normale, è possibile omettere username:password, ed in tal caso verranno utilizzate credenziali anonime (user: anonymous password:-wwwuser@). Il numero di porta (ed i due punti che lo precedono) possono essere altresì omessi, in tal caso verrò utilizzata la porta FTP di default (21) per la connessione al server.

Questa vulnerabilità è stata diffusa nel 1997 quando Nmap è stato rilasciato, ma è stata risolta su gran parte dei sistemi. Esistono alcuni server ancora vulnerabili, ed ha senso provare ad utilizzarla quando ogni altra cosa fallisce. Se l'obiettivo è oltrepassare un firewall, è necessario effettuare una scansione sulla rete cercando di trovare la porta 21 aperta (o anche cercando un servizio FTP su di una qualsiasi porta, utilizzando la version detection) e provare quindi lo script NSE ftp-bounce. Nmap sarà in grado di evidenziare se un host è vulnerabile o meno a questa tecnica. Se si sta cercando semplicemente di nascondere le proprie tracce, non vi è bisogno (e di fatto non si dovrebbe) di limitare la scansione alla rete che realmente ci interessa. Prima di iniziare ad effettuare scansioni su indirizzi Internet casuali per trovare server FTP vulnerabili è bene tenere presente che gli amministratori di sistema potrebbero non apprezzare che i loro server siano soggetti a tali abusi.

Questa opzione permette di ignorare le impostazioni di default e di specificare quali porte si vogliono scansionare. È possibile indicare i singoli numeri delle porte, così come gli intervalli, separati da un trattino (ad esempio 1-1023). Il primo e/o l'ultimo valore di un intervallo possono essere omessi, facendo sì che Nmap utilizzi rispettivamente 1 e 65535 come limiti. È quindi possibile utilizzare l'opzione -p- per effettuare la scansione delle porte da 1 a 65535. È possibile effettuare scansioni sulla porta zero se viene espressamente specificato. Nel caso di un IP protocol scan (-sO), questa opzione indica il numero del protocollo che si desidera scansionare (0-255).

Quando si effettua una scansione combinata di protocolli (ad esempio TCP e UDP), è possibile specificare un protocollo particolare anteponendo al numero di porta T: per TCP, U: per UDP, S: per SCTP o P: per IP Protocol. Tale indicazione risulta valida sino a che non ne viene indicata un'altra. Per esempio, l'opzione -p U:53,111,137,T:21-25,80,139,8080 effettua una scansione UDP delle porte 53, 111 e 137, lo stesso per le porte TCP. Si noti che per effettuare una scansione su entrambi i protocolli UDP e TCP, è necessario specificare l'opzione -sU e almeno un metodo di TCP scan (come -sS, -sF o -sT). Se non viene indicato nulla, i numeri di porta vengono aggiunti a tutte le liste dei protocolli.

Le porte possono anche essere indicate tramite il loro nome, così come sono indicate nell'nmap-services. Si possono anche utilizzare i caratteri speciali * e ? con i nomi. Ad esempio, per scansionare l'FTP e tutte le porte il cui nome inizia con "http", si può usare -p ftp,http*. Si raccomanda di prestare attenzione alla "shell expansions" e di racchiudere tra apici (quote) l'argomento di -p se non si è sicuri.

I range di porte possono essere racchiusi da parentesi quadre per indicare le porte all'interno di quel range che appare in nmap-services. Ad esempio, ciò che segue eseguirà la scansione di tutte le porte in nmap-services uguali o minori di 1024: -p [-1024]. Si raccomanda di prestare attenzione alla "shell expansions" e di racchiudere tra apici (quote) l'argomento di -p se non si è sicuri.

Quest'opzione specifica quali porte Nmap deve escludere dalla scansione. I port ranges devono essere specificati in modo simile a -p. Per le scansioni IP protocol (-sO), questa opzione specifica il numero di protocolli che si vuole escludere (0–255).

Quando si richiede di escludere le porte, queste vengono escluse da tutti i tipi di scansione. Ciò include anche la fase di discovery.

Indica che si intende effettuare la scansione di un minor numero di porte rispetto al default. Normalmente Nmap scansione le 1.000 porte più comuni per ogni protocollo scansionato. Con l'opzione -F il numero si riduce a 100.

Nmap ha bisogno del file nmap-services che contiene le informazioni di frequenza, in modo da sapere quali sono le porte più comuni (vedi «Well Known Port List: nmap-services[9]» per maggiori informazioni sulle "port frequencies"). Se la "port frequency information" non è disponibile, forse perché si sta utilizzando un file nmap-services personalizzato, Nmap scansiona tutte le porte nominate più le porte nell'intervallo 1-1024. In questo caso, l'opzione -F indica di scansionare solo le porte che sono presenti nel file nmap-services.

Di default, Nmap effettua la scansione delle porte in ordine casuale (tranne che per alcune porte comuni che vengono controllate per prime per motivi di efficienza). La scansione delle porte in ordine casuale è tipicamente un vantaggio, ma è possibile utilizzare l'opzione -r così da effettuare i controlli in ordine sequenziale crescente.

Scansiona tutte le porte presenti nel file nmap-services con un rapporto maggiore di quello indicato. ratio deve essere compreso tra 0.0 e 1.1.

Scansiona le n porte presenti nel file nmap-services con il maggior rapporto, dopo aver escluso tutte le porte indicate in --exclude-ports. n deve essere maggiore o uguale a 1.

Abilita il version detection, come precedentemente illustrato. In alternativa, è possibile utilizzare l'opzione -A che attiva il version detection, tra le altre cose.

-sR è un alias -sV. Fino a Marzo 2011 era usata per attivare l'RPC separatamente dal version detection, ma ora queste opzioni sono sempre combinate.

Normalmente, il version detection di Nmap non invia pacchetti alla porta TCP 9100 poiché alcune stampanti accettano e stampano direttamente qualunque dato ricevuto su questa porta. Se tale porta fosse sottoposta a scansione, verrebbero stampate decine di pagine contenenti richieste HTTP GET puri, dati binari di sessioni SSL e via discorrendo. È possibile cambiare il comportamento del version detection di Nmap con la modifica o la rimozione della direttiva Exclude nel file nmap-service-probes oppure specificando l'opzione --allports, così da effettuare la scansione di tutte le porte, indipendentemente da quanto indicato nella direttiva Exclude.

Quando si effettua un version scan (-sV), Nmap invia una serie di probe, ognuno dei quali ha assegnato un valore compreso tra 1 e 9. I pacchetti con valore più basso sono in grado di riconoscere i servizi comunemente diffusi, mentre quelli con valori più alti sono raramente necessari. Il livello di accuratezza specifica quali probe devono essere impiegati; più alto è il livello, più è probabile che il servizio venga correttamente identificato. D'altro canto, più una scansione è accurata e più tempo sarà necessario. I valori devono essere compresi tra 0 e 9; il valore di default è 7. Quando viene assegnato direttamente un probe ad una porta utilizzando la direttiva ports nel file nmap-service-probes, esso viene utilizzato indipendentemente dal valore indicato per l'accuratezza del version scan. Questo garantisce, per esempio, che ogni volta che viene trovata la porta 53 aperta vengano effettuati i controlli specifici per il DNS; così come in caso di porta 443 vengano invece utilizzati quelli per l'SSL e così via.

Questa opzione è un alias di --version-intensity 2. Questa modalità rende il version scanning drasticamente più veloce, riducendone però la capacità di identificare accuratamente i servizi.

Questa opzione è equivalente a --version-intensity 9, assicurando che ogni singolo probe venga utilizzato su ogni singola porta.

Indica a Nmap di visualizzare informazioni di debug estese relative all'attività del version scanning. È un subset di quanto si ottiene con l'opzione --packet-trace.

Abilita l'OS detection, come descritto sopra. In alternativa, è possibile utilizzare l'opzione -A per attivare sia l'OS detection, tra le altre cose.

L'OS detection è molto più efficace se vengono rilevate almeno una porta TCP aperta ed una chiusa. Utilizzando questa opzione Nmap non cercherà di effettuare l'OS detection sugli host che non rispondo a questo criterio. È così possibile un sensibile risparmio di tempo, specialmente se si utilizza anche l'opzione -Pn su molti host. È importante unicamente quando l'OS detection è richiesto attraverso le opzioni -O o -A.

Quando Nmap non è in grado di rilevare una corrispondenza esatta dell'OS, propone come possibilità gli OS più vicini alla rilevazione. La corrispondenza però deve essere molto simile perché Nmap lo faccia di default. Entrambe queste opzioni (equivalenti) fanno si che Nmap proceda con il riconoscimento dell'OS in modo più aggressivo. Nmap farà comunque presente quando corrispondenze non perfette vengono mostrate e per ognuna ne indicherà il livello di approssimazione (in percentuale).

Quando Nmap esegue un OS detection su di un obiettivo e non riesce a trovare una corrispondenza perfetta, solitamente ripete il tentativo. Di default, Nmap prova cinque volte, se le condizioni sono favorevoli per l'invio del fingerprint, e due volte se invece non lo sono. Specificando un valore più piccolo (ad esempio 1) nell'opzione --max-os-tries, si aumentano le performance di Nmap a discapito di una potenziale identificazione del sistema operativo. Per contro, un valore più alto permette più tentativi, se le condizioni sono favorevoli. Questo raramente avviene, se non per creare migliori fingerprint da integrare nel database di Nmap.

Esegue uno script scan utilizzando il set di script di default. È l'equivalente di --script=default. Alcuni degli script in questa categoria vengono considerati intrusivi e potrebbero non essere eseguiti su di un obiettivo di rete senza permessi.

Esegue uno script scan utilizzando una lista, separata da virgole, di file, categorie di script e directory. Ogni elemento nella lista può anche essere un'espressione booleana che descrive un più complesso set di script. Gli elementi vengono interpretati prima come un'espressione, poi come una categoria e infine come il nome di file o di una directory.

Sono presenti due feature speciali dedicate agli utenti esperti. La prima consiste nell'aggiungere come prefisso al nome degli script e alle espressioni il carattere + per forzarne l'esecuzione anche quando non verrebbe fatta (ad esempio quando il relativo servizio non è stato trovato sulla porta dell'host). L'altra feature è l'argomento all che può essere utilizzato per specificare tutti gli script nel database di Nmap. Usare con cautela questa funzionalità dato che NSE contiene script pericolosi come exploit, "brute force authentication crackers" e attacchi "denial of service".

I percorsi dei file e delle directory possono essere sia relativi che assoluti. I percorsi assoluti sono diretti, mentre quelli relativi vengono ricercati nelle cartelle scripts presenti in ogni seguente locazione:

--datadir

$NMAPDIR

~/.nmap (non usato in Windows)

<HOME>\AppData\Roaming\nmap (usato solo in Windows)

la directory contenente l'eseguibile di Nmap

la directory contenente l'eseguibile di Nmap, seguita da ../share/nmap

NMAPDATADIR

La directory corrente

Quando viene specificata una directory, Nmap carica ogni file in quella directory che ha come estensione .nse. Tutti gli altri file verranno ignorati e la directory non verrà scansionata in modo ricorsivo. Quando viene specificato un file, bisogna omettere l'estensione .nse, verrà aggiunta automaticamente se necessario.

Gli script Nmap sono archiviati di default in una subdirectory scripts della directory principale di Nmap (vedi Chapter 14, Understanding and Customizing Nmap Data Files[16]). Per migliorare l'efficienza, gli script vengono indicizzati nel database scripts/script.db, che elenca le categorie cui ogni script appartiene.

Quando si usa il nome dagli script come riferimento dal file script.db, si può utilizzare come nella shell il carattere speciale «*».

nmap --script "http-*"

Selezioni più complesse di script possono essere eseguite utilizzando gli operatori and, or e not costruendo così espressioni booleane. Gli operatori hanno la stessa precedenza che hanno in Lua: not è il più alto, seguito dal and e quindi or. Si può modificare la precedenza utilizzando le parentesi. Dato che le espressioni contengono caratteri di spazio, è necessario racchiuderle tra apici (quote).

nmap --script "not intrusive"

nmap --script "default or safe"

nmap --script "default and safe"

nmap --script "(default or safe or intrusive) and not http-*"

Permette di fornire argomenti agli script NSE. Gli argomenti sono una lista, separati da virgola, di coppie name=value. I nomi e i valori possono essere stringhe senza spazi o i caratteri "{", "}", "=" e ",". Per includere uno di questi caratteri in una stringa, si deve racchiudere la stringa tra apici singoli o doppi. Il carattere "\" (backslash) in una stringa tra apici, annulla la funzionalità dell'apice. Il backslash viene interpretato in questo modo solo in questo caso particolare, negli altri casi viene considerato "letteralmente". I valori possono anche essere elenchi racchiusi tra parentesi graffe ("{}"), così come in Lua. Un elenco può contenere valori, nella forma di semplici stringhe, oppure altre coppie di nomi-valori; sono consentiti anche gli elenchi annidati. Alcuni script definiscono i loro argomenti con il nome dello script, ad esempio xmpp-info.server_name. Si può utilizzare questa identificazione per agire solo sullo script specificato, oppure utilizzare la versione non identificativa (server_name in questo caso) per agire su tutti gli script che utilizzano questo argomento. Uno script controllerà prima gli argomenti a lui identificati (il nome degli argomenti è specificato nella documentazione dello script) prima di accettare un argomento non qualificato. Un esempio complesso è --script-args 'user=foo,pass=",{}=bar",whois={whodb=nofollow+ripe},xmpp-info.server_name=localhost'. L'NSE Documentation Portal all'indirizzo https://nmap.org/nsedoc/ elenca gli argomenti che ogni script accetta.

Permette di passare gli argomenti agli script NSE tramite un file. Ogni argomento sulla riga di comando sostituisce quelli nel file. Il percorso del file può essere assoluto o relativo e, in quest'ultimo caso, farà riferimento al solito percorso di ricerca di Nmap (NMAPDIR, ecc.). Gli argomenti possono essere separati da virgola o da un carattere di a-capo, ma devono seguire le stesse regole di --script-args, senza però particolari apici dato che non vengono elaborati dalla shell.

Mostra l'help degli scripts. Per ogni script specificato, Nmap restituisce il nome, le categorie cui appartiene e la sua descrizione. La sintassi è la stessa dell'opzione --script; quindi per esempio se si volesse l'help dello script ftp-anon, si dovrà eseguire il comando nmap --script-help ftp-anon. Oltre all'help per gli script individuali, si potrà anche ottenere l'anteprima di cosa lo script eseguirà secondo una specifica, ad esempio nmap --script-help default.

Quest'opzione è come l'opzione --packet-trace, solo un livello ISO più in alto. Se viene specificata quest'opzione, tutte le comunicazioni in entrata ed in uscita eseguite da uno script vengono mostrate. Queste informazioni includono il protocollo di comunicazione, la sorgente, l'obiettivo e i dati trasmessi. Se più del 5% di tutti i dati trasmessi non sono stampabili a video, allora l'output sarà in esadecimale. Indicando l'opzione --packet-trace anche lo script tracing verrà abilitato.

Quest'opzione aggiorna il database degli script che si trova nel file scripts/script.db, il quale viene utilizzato da Nmap per determinare gli script e le categorie di default. È necessario aggiornare il database solo se vengono aggiunti o rimossi script NSE dalla directory di default o se sono state cambiate le categorie di qualche script. Quest'opzione viene generalmente utilizzata da sola: nmap --script-updatedb.

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»[17]. 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[18]» 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[19] 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.

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[20] originariamente definisce Adler32 come l'algoritmo di checksum per SCTP; L' RFC 4960[5] 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.

Richiede che il normal output venga rediretto al file specificato. Come sopra, quest'output diverge leggermente da interactive output.

Richiede che l'output XML sia rediretto al file specificato. Nmap contiene un document type definition (DTD) che permette agli interpreti XML di validare l'output XML di Nmap. Sebbene serva principalmente per l'uso programmatico, può essere d'aiuto anche agli utenti. Il DTD definisce gli elementi convenzionali del formato, e spesso enumera gli attributi e i valori che possono assumere. L'ultima versione è sempre disponibile al link https://svn.nmap.org/nmap/docs/nmap.dtd.

XML offre un formato stabile e facilmente interpretato dal software. Gli interpreti XML liberi (free) sono disponibili per la maggior parte dei linguaggi di programmazione, compresi C/C++, Perl, Python e Java. Qualcuno ha anche scritto dei bindings per gran parte di questi linguaggi per trattare in maniera specifica l'output e l'esecuzione di Nmap. Ne sono esempio: Nmap::Scanner[21] e Nmap::Parser[22] nel Perl CPAN. In quasi tutti i casi il formato preferito per interpretare i risultati di Nmap è stato XML.

L'output XML fa riferimento ad uno stylesheet XSL che può essere usato per formattare il risultato in HTML. La maniera più facile di usarlo è semplicemente aprire il file XML in un web browser, come Firefox o IE. Di norma questa procedura dovrebbe funzionare solo sulla macchina su cui si esegue Nmap (o su una configurata in maniera simile) dato che il percorso a nmap.xsl è quello scritto nel codice di Nmap. Si vedano le opzioni --webxml o --stylesheet per creare un file XML portabile che renderizza come HTML in ogni macchina connessa al web.

Lo script kiddie output è come l'interactive output, ad eccezione del post-processing che meglio adatta l'output ai l33t HaXXorZ che prima guardavano dall'alto in basso Nmap per la sua troppo corretta ortografia e per l'uso proprio delle maiuscole. Per le persone poco inclini allo humor, si noti che questa opzione prende in giro gli script kiddies, quindi non si critichi per un presunto "averli aiutati".

Questo formato di output viene descritto per ultimo perché il suo uso è deprecato. L'output XML è di gran lunga più potente ed in pratica ugualmente utile per gli utenti esperti. XML è uno standard per le dozzine di eccellenti parsers che sono disponibili, mentre il grepable output è un semplice hack. XML è estensibile al supporto di nuove features di Nmap man mano che queste vengono rilasciate, mentre spesso vengono omesse queste nuove feature per il formato grepable per mancanza di spazio dove aggiungerle.

Ad ogni modo, il grepable output è ancora discretamente usato. È un formato semplice che lista ogni host su una riga e può essere facilmente cercato e interpretato dai tool standard di UNIX, come grep, awk, cut, sed, diff e Perl. Viene utilizzato per test semplici da riga di comando: trovare tutti gli host che hanno la porta SSH aperta o che montano Solaris, è questione di un semplice grep per identificare gli host e un pipe verso awk o cut per visualizzare i campi desiderati.

Il grepable output contiene commenti (le righe che iniziano con il cancelletto (#)) e righe target. Una riga target include una combinazione di 6 campi etichettati, separati da tabulazioni e terminati da un due punti (:). I campi sono Host, Ports, Protocols, Ignored State, OS, Seq Index, IP ID e Status.

Il più importante tra questi campi è generalmente il campo Ports, che da dettagli su ogni porta interessante. È una lista di "port entries" separate da una virgola. Ogni "port entry" rappresenta una porta interessante e prende la forma di sette sotto-campi separati da uno slash (/). Questi sotto-campi sono: Port number, State, Protocol, Owner, Service, SunRPC info e Version info.

Così come nell'output XML, questa pagina di manuale non permette di documentare l'intero formato. È disponibile una descrizione più dettagliata del formato grepable output nella sezione «Grepable Output (-oG)[23]».

In caso di bisogno, si potrebbe specificare -oA basename per salvare i risultati dello scan nei formati normal, XML e grepable in una sola volta. Questi vengono salvati rispettivamente nei file basename.nmap, basename.xml e basename.gnmap. Come la maggior parte dei programmi, si può aggiungere un prefisso ai nomi dei file, come ad esempio un percorso ad una directory, ~/nmaplogs/foocorp/ su UNIX o c:\hacking\sco su Windows.

Aumenta il livello di verbosità, facendo in modo che Nmap stampi più informazioni riguardo lo scan in esecuzione. Le porte aperte sono mostrate man mano che Nmap le trova e il tempo rimanente stimato viene mostrato se Nmap ritiene che lo scan possa durare più di qualche minuto. Si può mettere l'opzione due o più volte per aumentare ulteriormente il livello di verbosità.

La maggior parte dei cambiamenti riguarda l'interactive output, e alcune cose anche il normal e lo script kiddie output. Gli altri tipi di output sono fatti per essere processati dalle macchine, quindi Nmap può dare un grosso livello di dettaglio di default, senza il problema di poter affaticare un utente umano. In ogni caso ci sono delle leggere differenze negli altri modi dove la dimensione dell'output può essere sostanzialmente ridotta omettendo alcuni dettagli. Per esempio solo in modalità verbosa viene stampata una linea di commento nel grepable output che fornisce una lista di tutte le porte scansionate, questo perché potrebbe essere abbastanza lunga.

Quando anche il verbose mode non fornisce dati a sufficienza, è disponibile la modalità debugging, che sommergerà l'utente di informazioni! Così come succede per l'opzione verbosity (-v), il debugging viene attivato da un'opzione di riga di comando (-d) e il livello di debug può essere aumentato ripetendo l'opzione diverse volte, ad esempio -dd, o si può settare il debug level dando come argomento di -d un numero. Ad esempio, -d9 setta il livello a nove. Questo è il livello più alto e produrrà migliaia di linee a meno che non si stia facendo uno scan molto semplice con pochi target e poche porte.

L'output di debugging è utile quando si sospetta un bug in Nmap, oppure se si rimane confusi su cosa stia facendo Nmap e perché. Siccome questa feature è stata pensata principalmente per gli sviluppatori, le linee di debug non sono granché autoesplicative. Si potrebbe incontrare qualcosa tipo: Timeout vals: srtt: -1 rttvar: -1 to: 1000000 delta 14987 ==> srtt: 14987 rttvar: 14987 to: 100000. Se non si capisce una linea, quello che si può fare è ignorarla, guardarla nel codice sorgente, o richiedere aiuto alla lista di sviluppo (nmap-dev). Alcune linee si spiegano bene da sé, ma i messaggi divengono sempre più oscuri man mano che il livello di debugging sale.

Mostra il motivo per cui ad ogni singola porta è stato assegnato quello stato e la ragione per cui ogni host è attivo o meno. Quest'opzione mostra il tipo di pacchetto che ha determinato lo stato di una porta o di un host. Per esempio, un pacchetto RST da una porta chiusa o un echo reply da un host attivo. L'informazione che Nmap restituisce dipende dal tipo di scansione o di ping. Il SYN scan e il SYN ping (-sS e -PS) sono molto dettagliati, mentre il TCP connect scan (-sT) è limitato all'implementazione della chiamata di sistema connect. Questa feature è automaticamente abilitata dall'opzione di debug (-d) e i suoi risultati vengono salvati in file log in formato XML anche se quest'opzione non viene specificata.

Periodicamente stampa un messaggio di timing status ogni intervallo di time. Il tempo è una specifica del tipo descritto nella sezione «Timing and Performance[24]» di questo manuale; quindi per esempio, si utilizzerà --stats-every 10s per avere un aggiornamento dello stato ogni 10 secondi. Gli aggiornamenti vengono stampati sull'interactive output (a schermo) e sull'XML output.

Fa in modo che Nmap stampi un riassunto di ogni pacchetto mandato o ricevuto. Viene usata spesso per il debugging, ma è anche un modo valido per gli utenti novizi per capire esattamente cosa sta facendo Nmap dietro le quinte. Per evitare che stampi migliaia di linee, si dovrebbe specificare una lista limitata di porte da controllare, come -p20-30. Se importa soltanto vedere come procede il version detection si può usare --version-trace. Se invece si è solo interessati allo script tracing, indicare --script-trace. Con --packet-trace, si avranno tutti quelli sopra.

Può succedere di essere interessati solamente alle porte cui ci si può connettere al momento (le open) e non si vuole mischiare i risultati con quelle closed, closed o closed|filtered. Si potrebbe personalizzare l'output dopo la scansione utilizzando tool come grep, awk e Perl, ma è stata aggiunta quest'opzione a causa di richieste travolgenti. Indicare --open per vedere solamente gli host con almeno una porta open, open|filtered o unfiltered, e vedere solamente le porte con questi stati. Questi tre stati vengono trattati normalmente, il che significa che open|filtered e unfiltered potrebbero essere raggruppate se ce ne dovessero essere troppe.

Stampa la lista delle interfacce e degli instradamenti di sistema rilevati da Nmap. Questo è utile per risolvere i problemi di routing o cattive caratterizzazioni delle interfacce (ad esempio quando Nmap scambia una connessione PPP per ethernet).

Quando si specifica un nome di file mediante un parametro di output come -oX o -oN, questo file viene sovrascritto di default. Se si preferisce mantenere il contenuto del file e aggiungerci i nuovi risultati, si deve usare l'opzione --append-output. Tutti i file di output specificati in quell'istanza di Nmap verranno usati in append mode anziché essere sovrascritti. Quest'opzione non è di grande aiuto (e non funziona molto bene) nel caso di output in formato XML (-oX), poiché il parsing del file risultante non sarà corretto fino a quando non si controllerà il file manualmente.

Alcune esecuzioni di Nmap possono richiedere molto tempo - dell'ordine di giorni. Tali scansioni non arrivano sempre alla fine; alcune restrizioni possono impedire a Nmap di funzionare durante le ore del giorno, la rete può diventare irraggiungibile, la macchina sulla quale Nmap sta girando può subire un riavvio pianificato o improvviso o Nmap stesso può andare in crash. L'amministratore che sta usando Nmap può interromperlo per qualsiasi ragione, premendo ctrl-C. Ricominciare l'intera scansione dall'inizio può diventare fastidioso. Fortunatamente se sono rimasti i log in formato "normal" (-oN) o "grepable" (-oG), l'utente può richiedere a Nmap di ricominciare la scansione dall'host sul quale stava lavorando quando l'esecuzione è stata interrotta. Semplicemente basta specificare l'opzione --resume e passargli il file di output in formato normal/grepable come argomento. Non è permesso nessun altro argomento, poiché Nmap farà il parsing del file di output per usare le stesse opzioni specificate in precedenza. È quindi sufficiente invocare Nmap come nmap --resume logfilename. Nmap aggiungerà i nuovi risultati ai file specificati nell'esecuzione precedente. La ripresa di un'esecuzione non supporta il formato di output XML poiché sarebbe troppo difficile combinare le due esecuzioni in un unico file XML valido.

Nmap viene fornito con un foglio di stile XSL chiamato nmap.xsl per vedere o tradurre l'output XML in HTML. L'output XML include una direttiva xml-stylesheet che punta al file nmap.xml dove è stato installato Nmap la prima volta. Processare il file XML con un XSLT processor come xsltproc[25] per produrre un file HTML. Aprire direttamente l'output XML in un browser non funziona più tanto bene in quanto i browser recenti limitano le location da cui può essere caricato un foglio di stile. Se si volesse usare un foglio di stile diverso, va specificato mediante l'opzione --stylesheet. Il file va indicato con il percorso completo o l'URL. Un esempio di invocazione con quest'opzione è --stylesheet https://nmap.org/svn/docs/nmap.xsl. Questo indica ad un XSLT processor di caricare l'ultima versione del foglio di stile da Nmap.Org. L'opzione --webxml fa la stessa cosa ma richiede meno digitazioni e meno cose da ricordare. Caricando l'XSL da Nmap.Org rende più semplice visualizzare i risultati su una macchina che non ha Nmap (e quindi il file nmap.xsl) installato. Quindi l'URL è spesso una scelta migliore, ma di default viene usato il file dal filesystem locale per ragioni di privacy.

Quest'opzione è semplicemente una comodità per l'opzione --stylesheet https://nmap.org/svn/docs/nmap.xsl.

Quest'opzione va specificata quando non si vuole che Nmap associ un qualsiasi foglio di stile XSL al proprio output XML. La direttiva xml-stylesheet viene omessa.

Nmap offre supporto IPv6 per le sue funzioni più comuni. Le funzioni ping scanning, port scanning, rivelazione di versione e l'NSE supportano tutti IPv6. La sintassi dei comandi è la stessa di sempre, ad eccezione dell'aggiunta dell'opzione -6. Ovviamente si dovrà utilizzare la sintassi IPv6 se si vuole specificare un indirizzo anziché un hostname. Un indirizzo sarà qualcosa del tipo 3ffe:7501:4819:2000:210:f3ff:fe03:14d0, ne consegue che è raccomandato l'uso degli hostname. L'output ha il solito aspetto, l'unica differenza è l'indirizzo IPv6 sulla linea delle "interesting ports".

Mentre IPv6 non ha esattamente preso il sopravvento nel mondo, trova un uso più significativo in alcuni Paesi (tipicamente Asiatici) e supporto nella maggior parte dei moderni sistemi operativi. Per usare Nmap con l'IPv6, sia l'obiettivo che la sorgente dello scan devono essere configurate per IPv6. Se il proprio l'ISP (come la maggior parte) non alloca indirizzi IPv6, c'è una vasta disponibilità di tunnel broker gratuiti e funzionano bene con Nmap. Uno dei migliori è fornito da http://www.tunnelbroker.net/. Altri tunnel broker si possono trovare su Wikipedia[26]. Un altro approccio free comune sono i tunnel 6to4.

Su Windows, gli scan IPv6 raw-socket sono supportati solo su dispositivi ethernet (non tunnel) e solo da Windows Vista in poi. Utilizzare l'opzione --unprivileged nelle altre situazioni.

Quest'opzione abilita altre opzioni addizionali avanzate ed aggressive. Al momento questa opzione attiva l'OS detection (-O), il version scanning (-sV), lo script scanning (-sC) e il traceroute (--traceroute). Ulteriori caratteristiche verranno aggiunte in futuro. Il punto è attivare un completo set di opzioni di scan senza che ci sia il bisogno di ricordarsi una lunga serie di flag. In ogni modo, dato che lo script scanning con il set di default è considerato intrusivo, si dovrebbe utilizzare -A contro le reti senza averne avuto autorizzazione. Quest'opzione attiva solo delle modalità di funzionamento, ma non le opzioni di timing (come -T4), né quelle di verbosity (-v) che si potrebbero comunque volere. Le opzione che richiedono privilegi speciali (ad esempio i permessi di root), come l'OS detection e il traceroute, saranno abilitate solo se si questi permessi sono attivi.

Nmap ottiene alcuni dati speciali in runtime dai files chiamati nmap-service-probes, nmap-services, nmap-protocols, nmap-rpc, nmap-mac-prefixes ed nmap-os-fingerprints. Se la location di uno questi file viene specificata(usando l'opzione --servicedb o l'opzione --versiondbNmap), questa location viene utilizzata per tutti quanti. Altrimenti, Nmap cerca i file nella directory specificata con l'opzione --datadir (qualora specificata). Qualunque file non trovato in questa locazione, verrà cercato nella directory specificata nella variabile d'ambiente NMAPDIR. Segue poi ~/.nmap per le vere e proprie UID (valido solo per i sistemi POSIX) o, su Windows, <HOME>\AppData\Roaming\nmap (dove <HOME> è la home directory dell'utente, tipo C:\Users\user). Seguono poi la directory dell'eseguibile di Nmap e le sue subdirectory ../usr/share/nmap. Infine vengono utilizzate le locazioni precompilate come /usr/local/share/nmap o /usr/share/nmap.

Chiede ad Nmap di utilizzare specifici file "services" invece che il file nmap-services che viene fornito con Nmap. Inoltre quest'opzione attiva l'opzione -F che esegue una scansione veloce. Vedere la descrizione di --datadir per avere più informazioni sui data files di Nmap.

Chiede ad Nmap di utilizzare specifici file "service probes" invece che il file nmap-service-probes che viene fornito con Nmap. Vedere la descrizione di --datadir per avere più informazioni sui data files di Nmap.

Chiede a Nmap di mandare pacchetti al livello ethernet (data link) piuttosto che al livello più alto IP (network). Di default, Nmap sceglie quello che è generalmente migliore per la piattaforma in cui sta venendo eseguito. I raw sockets (livello IP) solitamente sono i più efficienti per le macchine UNIX, mentre invece sono richieste trame ethernet per funzionare con Windows dal momento che Microsoft ha disabilitato il supporto per i raw socket. Nmap usa invece continua a usare i pacchetti raw sulle UNIX non ostante si specifichi questa opzione quando non c'è alternativa (ad esempio se si ha una connessione non ethernet)

Chiede a Nmap di mandare pacchetti via raw socket IP, piuttosto che mandare trame al livello inferiore, ethernet. È l'opzione complementare di --send-eth discussa precedentemente.

Dice semplicemente a Nmap di assumere che l'utente abbia privilegi sufficienti per effettuare trasmissioni sui raw socket, fare packet sniffing, e operazioni simili che di norma hanno bisogno dei privilegi di root sui sistemi UNIX. Di default Nmap termina l'esecuzione se si tentano di usare certe operazioni e geteuid non è zero. --privileged è utile con delle funzionalità del kernel Linux e altri sistemi operativi che possono essere configurati per permettere ad utenti non privilegiati di fare degli scan con i raw socket. Bisogna assicurarsi di posizionare questa opzione prima di qualunque flag che invochi funzionalità privilegiate (SYN scan, OS detection, ecc.). La variabile d'ambiente NMAP_PRIVILEGED può comunque essere settata e rappresenta un'equivalente alternativa all'opzione --privileged.

quest'opzione è l'opposta di --privilegerd. Dice ad Nmap di trattare l'utente come se non avesse i permessi necessari per i raw socket e lo sniffing. Può tornare utile in fase di test, debugging o quando le funzionalità di raw network del sistema operativo hanno qualche problema. La variabile d'ambiente NMAP_PRIVILEGED può comunque essere settata e rappresenta un'equivalente alternativa all'opzione --unprivileged.

Quest'opzione è utile solo per la risoluzione di problemi di perdita di memoria (memory-leak debugging). Obbliga infatti ad Nmap a liberare la memoria allocata appena prima di uscire così da individuare più facilmente le effettive perdite di memoria. Di solito Nmap salta questo passaggio come fa il sistema operativo in ogni caso al momento della chiusura del processo.

Stampa a video il numero di versione di Nmap ed esce.

Stampa a video una breve schermata di aiuto con le opzioni più comuni. Eseguire Nmap senza argomenti fa la stessa cosa.

Aumenta / diminuisce la quantità di informazioni

Aumenta / diminuisce il livello di debug

Attiva / disattiva il tracing dei pacchetti

Stampa una schermata di aiuto per le interazioni in tempo reale

Stampa un messaggio di stato come il seguente: