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 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 è 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 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:

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 (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)».

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) è 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.