Home page logo
/
Intro Reference Guide Book Install Guide
Download Changelog Zenmap GUI Docs
Bug Reports OS Detection Propaganda Related Projects
In the Movies In the News

Sponsors


Nmap Network Scanning

Tecniche di Port Scanning

Un neofita inesperto che cerca di aggiustarsi l'automobile puo` arrovellarsi per ore cercando di usare i pochi strumenti che ha (martello, nastro isolante, pinza, eccetera) per cio` che deve fare. Una volta che si e` arreso dopo l'ennesimo fallimento e si e` deciso a portare il proprio veicolo da un vero meccanico, ecco che questi inevitabilmente si mette a cercare in una gigantesca cassetta degli attrezzi estraendone il "coso" perfetto per fare quel lavoro senza alcuno sforzo. L'arte del port scanning e` molto simile. Chi e` esperto capisce e conosce tutte le tecniche e sceglie quella appropriata (o una combinazione appropriata) per un certo lavoro. Utenti inesperti o script kiddes, d'altro canto, provano a risolvere ogni problema con la scansione SYN di default. Poiche` Nmap e` free (in lingua inglese significa sia "libero" che "gratuito", e per questo e` lasciato inalterato, NdT) l'unico limite alla capacita` di fare port scanning e` solo la conoscenza. Questo lo rende sicuramente piu` accessibile del mondo delle automobili, dov'e` richiesta non solo una notevole abilita` per sapere che serve uno specifico strumento, ma e` anche necessario andarselo a comprare.

La maggior parte delle scansioni e` disponibile solo per gli utenti privilegiati. Questo e` dovuto al fatto che esse inviano e ricevono pacchetti "raw" (non formattati o "grezzi", ovvero semplici stringhe di bit), i quali richiedono accesso di root su sistemi UNIX. L'uso di un account di amministrazione su Windows e` raccomandato, nonostante Nmap a volte funzioni anche per gli utenti non privilegiati quando WinPcap e` gia` stato caricato nel sistema operativo. Nel 1997, quando Nmap venne rilasciato, la necessita` di avere privilegi di root era una seria limitazione perche` molti utenti avevano solo accesso ad account su macchine che davano semplici shell non privilegiate. Ora il mondo e` cambiato: i computer sono piu` economici, molta piu` gente ha una connessione a Internet diretta e sempre attiva, e i sistemi UNIX per desktop (includendo tra questi macchine Linux o OS X) sono ormai la maggioranza tra gli UNIX. Per tutte queste ragioni gli utenti hanno sempre meno necessita` di usare Nmap da account limitati - il che non fa che migliorare la situazione, poiche` le opzioni privilegiate fanno di Nmap uno strumento molto piu` potente e flessibile.

Nonostante Nmap faccia del proprio meglio per produrre risultati accurati, si tenga in mente che tutte le sue conclusioni sono basate su pacchetti che tornano indietro dalle macchine di destinazione (o dai firewall che le proteggono). Tali host possono essere inaffidabili o restituire risposte mirate proprio a confondere e sviare Nmap. Sono molto piu` comuni inoltre host che non rispettano gli RFC e che non rispondono come dovrebbero ai tentativi di connessione di Nmap. Scansioni come FIN, Null e Xmas sono particolarmente suscettibili a questo problema. Tali problematiche sono specifiche a certi tipi di scansione ed in quanto tali vengono discusse nelle sezioni individuali ad esse dedicate.

Questa sezione documenta le molteplici tecniche di port scanning supportate da Nmap. Si puo` usare solo un metodo per volta, a parte l'UDP scan (-sU) che puo` essere combinato con con uno qualsiasi dei TCP scan. Per ricordarsi le varie opzioni di port scan, esse sono della forma -s<C>, dove <C> e` un carattere significativo del nome della scansione - in genere il primo. L'unica eccezione a questa regola generale e` il cosiddetto "FTP bounce scan" che viene tuttavia sconsigliato (opzione -b). Di default Nmap effettua un SYN scan, usando la syscall connect() se l'utente non ha privilegi sufficienti per mandare pacchetti raw (che richiede accesso di root su UNIX), o se e` stato richiesto uno scan su obbiettivi su IPv6. Di tutte le scansioni elencate di seguito, gli utenti non privilegiati possono solo effettuare scansioni mediante connect() e "FTP bounce".

-sS (TCP SYN scan)

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

-sT (TCP connect() scan)

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.

-sU (UDP scans)

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 destinazione. Se viene restituito 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 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 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.

-sN; -sF; -sX (TCP Null, FIN, and Xmas scans)

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:

Null scan (-sN)

Non manda nessun bit (il tcp flag header e` 0)

FIN scan (-sF)

Setta solo il FIN.

Xmas scan (-sX)

setta FIN, PSH, e URG, accendendo il pacchetto come un albero di natale.

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.

-sA (TCP ACK scan)

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). Mentre si 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.

-sW (TCP Window scan)

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

-sM (TCP Maimon scan)

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.

--scanflags (Custom TCP scan)

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 flag desiderati, 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 scansione, viene automaticamente utilizzata la "SYN scan".

-sI <zombie host[:probeport]> (Idlescan)

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

-sO (IP protocol scan)

"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.

-b <ftp relay host> (FTP bounce scan)

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 aggirare 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'opzione -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. Esistono 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.

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]