La SYN scan e` l'opzione di default ed e` la piu` usata per buone ragioni. Puo` essere effettuata velocemente: effettua la scansione su migliaia di porte al secondo su una rete veloce non limitata da firewall intrisivi. La SYN scan e` relativamente poco invasiva e nascosta, poiche` non completa mai connessioni TCP complete. Funziona inoltre con ogni stack TCP compatibile e non dipende sulle 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 (aperta) , closed, e filtered (filtrata).

Questa tecnica e` spesso indicata come "scanning semi-aperto" (tradotto letteralmente per esigenze di comprensione, da "half-open scanning", NdT), perche` 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 e` in ascolto (aperta), mentre un RST (reset) indica che la porta non e` 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 scansione di tipo TCP connect() e` la scansione TCP di default dove la scansione SYN non e` un'opzione viabile. Questo e` il caso in cui un utente non ha privilegi sull'invio di pacchetti "raw" o se si sta lavorando su reti IPv6. Anziche` 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 chiamat di sistema connect(). Questo e` 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 e` parte dell'interfaccia di programmazione conosciuta come Berkeley Sockets API. Anziche` inviare pacchetti "raw" direttamente sul cavo, Nmap usa questa API per ottenere informazioni sullo stato di ogni tentativo di connessione.

Quand'e` possibile il SYN scan e` generalmente una scelta migliore. Nmap ha meno controllo sulla syscall connect() rispetto ai pacchetti "raw", rendendolo quindi piu` efficiente in quest'ultimo caso. La syscall completa le connessioni alle porte aperte specificate anziche` limitarsi al reset dovuto alla scansione semi-aperta del SYN scan. Non solo questo approccio mediante connect() richiede un tempo maggiore e piu` pacchetti per ottenere le stesse informazioni, ma le macchine obbiettivo sono piu` propense a memorizzare la traccia (log) della connessione. Inoltre un IDS (Intrusion Detection System, sistema di controllo delle intrusioni) decente se ne accorgera`. 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 a 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 sapra` infine che e` vittima di un connect scan.

Mentre i servizi piu` comuni su Internet girano attraverso il protocollo TCP, i servizi UDP sono altrettanto diffusi. DNS, SNMP e DHCP (sulle porte registrate 53, 161/162 e 67/68) sono tre dei piu` comuni. Poiche` lo scan su UDP e` generalmente piu` lento e piu` difficoltoso di quello su TCP, alcuni esaminatori di sicurezza ("security auditors") ignorano questo tipo di porte. Cio` e` un errore, poiche` i servizi UDP vulnerabili sono abbastanza comuni e un attaccante sicuramente non ignorera` completamente questo protocollo. Fortunatamente Nmap puo` aiutare ad enumerare le porte UDP.

Lo scan UDP si attiva con l'opzione -sU. Esso puo` 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 vuoti (senza dati ma formati solo dall'intestazione) ad ogni porta di destinazioe. Se viene ritornato un errore ICMP di "port unreachable" (tipo 3, codice 3) significa che la porta e` 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 rispondera` con un pacchetto UDP, dimostrando quindi che lo stato della porta e` 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 puo` essere aperta o che probabilmente un filtro di pacchetti sta bloccando la comunicazione. I version scan (-sV) possono essere usati per aiutare a differenziare le porte veramente aperte da quelle che sono filtrate.

La sfida maggiore con l'UDP scan e` la velocita`. 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 sia andato perduto. Le porte chiuse sono spesso un problema ancora maggiore: esse generalmente rimandano un pacchetto ICMP di "port unreachable error", ma a differenza dei pacchetti RST rimandati dalle porte chiuse TCP come rispota 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 ignorera` 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 piu` di 18 ore. Suggerimenti per rendere piu` veloce gli UDP scan sono quelli di effettuare scansioni su piu` host in parallelo, o di fare uno scan veloce preliminare sulle porte piu` usate, o ancora di effettuare la scansione dall'interno del firewall, e infine di usare l'opzione --host_timeout per evitare host troppo lenti nel rispondere.

Queste tre tipologie di scansione (e molte altre sono possibili con l'opzione --scanflags descritta nella prossima sezione) sfruttano una piccola vulnerabilita` 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] e` CHIUSO ... un segmento in arrivo che non contiene un RST causera` l'invio di un RST in risposta. ” La pagina successiva discute di pacchetti inviati a porte aperte senza i bit di SYN, RST o ACK impostati, indicando che: “questa situazione e` 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 di SYN, RST, o ACK causera` un RST di ritorno se la porta e` chiusa e nessuna risposta se la porta e` aperta. Finche` questi tre bit sono inclusi, qualunque combinazione di questi tre bit (FIN, PSH, e URG) va bene. Nmap sfrutta 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 e` considerata chiusa, mentre l'assenza di risposta indica che la porta e` aperta o filtrata. La porta e` marcata come filtrata 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 e` che possono penetrare in certi non-stateful firewalls e packet filtering routers. Un altro vantaggio e` che questi tipi di scansione sono un po` piu' invisibili anche dei SYN scan. In ogni caso non e` corretto fare cieco affidamento su questo, gran parte dei moderni prodotti IDS possono essere configurati in modo da rilevarli. Il grande svantaggio e` 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 chiuse. I piu' 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 e` che non riescono a distinguere una porta aperta da quelle filtrate, dando la risposta di open|filtered.

Questo scan e` diverso dagli altri scan discussi fino ad ora dal momento che non serve per determinare se le porte sono aperte (o aperte|filtrate). E' 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 la flag ACK abilitata (a meno che non si usi --scanflags). Mentresi scansionano sistemi non filtrati, sia le porte aperte che le porte chiuse manderanno pacchetti RST. Nmap poi le cataloga come non filtrate, nel senso che e` possibile raggiungerle con un pacchetto ACK, ma che siano aperte o chiuse non e` determinabile. Le porte che non rispondono, o mandano certi errori ICMP (tipo 3, codice 1, 2, 3, 9, 10, o 13), sono etichettate come filtrate.

Il window scan e` 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 non filtrata quando ritorna un RST. Lo fa esaminando il campo TCP Windowdel 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 e` zero. Quindi, invece di catalogare sempre le porte come non filtrate quando si riceve un RST di ritorno, il Window scan lista le porte come aperte o chiuse a seconda che il valore in quel RST (reset) e` positivo o pari a zero rispettivamente.

Questo scan fa affidamento a un dettaglio implementativo di una minoranza di sistemi presenti in internet, segue che questo non e` sempre affidabile. Nei sistemi in cui questo dettaglio implementativo non sussiste, di norma lo scan segnalera` tutte le porte chiuse. Sicuramente sara` possibile che la macchina non abbia realmente nessuna porta aperta. Se la maggior parte delle porte e` chiusa, e alcune porte comuni appaiono filtrate, il sistema e` quasi sicuramente suscettibile a questo tipo di scan. Occasionalmente, alcuni altri sistemi presenteranno un comportamento esattamente opposto. Se lo scan risulta in 1000 porte aperte e 3 chiuse, allora quelle saranno con ogni probabilita` proprio quelle aperte.

Il Maimon scan e` stato nominato cosi` 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 venir generato in risposta a tale stimolo. Ad ogni modo, Uriel noto` che in molti sistemi derivati da BSD il pacchetto veniva scartato se la porta era aperta.

Gli utilizzattori molto avanzati di Nmap hanno necessita` di non limitarsi semplicemente ad utiulizzare le scansioni tipiche offete. L'opzione --scanflags consente di designare una scansione personalizzata specificando arbitrariamente i flag TCP necessari. Liberate la vostra inventiva, ed evitate cosi` 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 falg TCP, come ad esepio 9 (PSH e FIN). L'utilizzo di nomi simbolici risulta comunque piu` semplice. Una combinazione di URG, ACK, PSH, RST, SYN, e FIN. Per esempio, --scanflags URGACKPSHRSTSYNFIN imposta tutti i flag, anche se non risulta multo utilie al fine della scansione. L'ordine con cui vengono specificati non e` rilevante.

Oltre allo specificare i falg desidearti, e` possibile indicare uno 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 ad indicare la porta filtered, mentre un "FIN scan" interpreta lo stesso comportamento per identificare una porta open|filtered. Nmap si comportera` nello stesso modo che per la scansione normale, tranne che per il fatto di interpretare i flag TCP che sono stati diveramente specificarti. Se non viene indicata una diverso tipo di cansione, viene automaticamente utilizzata la "SYN scan".

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 predicibilita` dell'ID relativo alla sequanza di frammentazione generato dallo "Zombie" per ottenere informazioni sulle porte aperte. I sistemi IDS intrepreteranno la scansione come se provenisse dalla macchina "Zombie" specificata (e che deve rispondere a certi criteri). Questa affascinante tecnica di scansione e` troppo complessa per essere descritta a fondo in questa guida, per questa ragione ho scritto e reso pubblico un documento informale contenente tutti i dettagli al seguente url: http://nmap.org/book/idlescan.html.

Oltre che essere straodrinariamente 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 cosi` possibile effettuare scansioni utilizzando diversi "Zombie" che si ritiene possano attraversare router o sistemi con packet filter.

E' 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'IPID. Diversamente Nmap utilizzera` the porta che utilizza di default per i ping TCP (80).

"IP Protocol" permette di determinare che protocolli IP (TCP, ICMP, IGMP, etc.) sono supportati dalla macchine su cui viene effettuata la scansione. Non e` "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 e riporta i risultati nel normale formato della tabella delle porte, ed utilizza lo stesso engine sottostante al port scanning reale. Per questo motivo e` profondamente analogo ad un port scan e viene trattato in questa sezione.

Oltre che essere intrinsicamente utile, il protocol scan dimostra la potenza del software open source. Per quanto l'idea fondamentale e` abbastanza semplice, non immaginavo di aggiungerla fino a quando non avessi ricevuto richieste per questa funzionalita`, Nell'estate del 2000, Gerhard Rieger concepi` 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!

La "Protocol Scan" funziona in modo simile all'UDP Scan. Invece di agire sul campo "port number" del pacchetto UDP, invia un pacchetto contenente negli 8 bit dell'header IP relativi al protocollo. Questi headers sono tipicamente vuoti, non contengo dati e nemmeno l'header proprietario del protocollo dichiarato. Le tre eccezioni sono: TCP, UDP e ICMP. Un header valido per queste eccezioni viene incluso perche`, diversamente, alcuni sistemi non li invierebbero e perche` Nmap e` gia` provvisto di funzioni per crearli. Invece che cercare un messaggio di "ICMP port unreachable", la "Protocol Scan" e` alla ricerca di un messaggio "ICMP protocol unreachable". Se Nmap riceve una qualunque risposta di qualunque protocollo dall'Host scansionato, Nmap lo indica tale protocollo come open. Un errore "ICMP protocol unreachable" (tipo 3, codice 2) fa si` che il protocollo sia indicato come closed. Altri errori di tipo "ICMP unreachable" (tipo 3, codice 1, 3, 9, 10, or 13) fanno classificare il protocollo come filtered (Denotando, contestualmente, che il protocollo ICMP e` open). Se non viene ricevuta alcuna risposta, il protocollo e` identificato come open|filtered.

Un'interessante caratteristica del protocollo FTP (RFC 959) e` il supporto per le cosi` chiamate "proxy ftp connections". Cio` permette all'utente di connettersi al server FTP e richiedere che il file sia inviato ad un differente FTP server. Tale caratteristica si presta per vare tipologie di abuso, cosicche` molti server hanno smesso di supportarla. Uno degli abusi nell'utilizzo di questa peculiarita` e` la possibilita` 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 permettera` di dedurre se la porta e` aperta o meno. Questo e` un'ottimo modo per aggiare i firewall in quanto gli FTP aziendali sono spesso posizionati nella rete cosi` da poter accedere a piu` host interni di quanto sia possibile fare da Internet. Nmap supporta la "ftp bounce scan" attraverso l'optione -b. I parametri per tale opzione devono rispettare il formato: <username>:<password>@<server>:<port>. Dove: <Server> e` l'hostname o l'indirizzo IP di un FTP server vulnerabile a questo attacco. Come in una URL normale, e` possibile omettere <username>:<password>, ed in tal caso verranno utilizzate credinziali anonime (user: anonymous password:-wwwuser@). Il numero di porta (ed i due punti che lo precedono) possono essere altresi` omessi, in tal caso viene utilizzata la porta FTP di default (21) per la connessione al <server>.

Questa vulnerabilita` e` stata diffusa nel 1997 quando Nmap e` stato rilasciato, ma e` stata risolta su gran parte dei sistemi. Esistno alcuni server ancora vulnerabili, ed ha senso provare ad utilizzarla quando ogni altra cosa fallisce. Se l'obiettivo e` oltrepassare un firewall, e` 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 un "FTP Bounce Scan" su ognuno dei server individuati. Nmap sara` in grado di evidenziare se un host e` vulnerabile o meno a questa tecnica. Se si sta cercando semplicemente di nascondere le tracce, non vi e` 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 e` bene tenere presente che gli amministratori di sistema potrebbero non apprezzare che i loro server siano soggetti a tali abusi.