![[Valid RSS]](http://www.shishii.com/dummy/fileadmin/template/mio/img/valid-rss.png "Validate my RSS feed"){kind=small}
8 Appendice
8.1 Connessione TCP - Three-way Handshake
Internet si basa sull'accoppiata di due protocolli fondamentali IP e TCP, non è questa la sede per fare lunghe disquisizioni teoriche su questi due pilastri dell'informatica, per lo scopo di questo articolo mi limiterò a descrivere il meccanismo della ``connessione TCP'', soprattutto sotto il punto di vista della prevedibilità del ISN.
Nel momento che il computer ``HOST1'' si vuole collegare a ``HOST2'' su una rete che usa il protocollo TCP invierà un pacchetto con il flag SYN attivo (cioè posto ad 1), con allegato un numero x compreso tra 0 e 2^32-1 chiamato ISN (Identification Sequence Number), HOST2 risponderà inviando un pacchetto con i flag SYN e ACK attivi allegando un ISN proprio y e x+1 (ISN di Host1 aumentato di 1), HOST1 ricevuto questo pacchetto, se verificherà la correttezza del numero allegato, risponderà con un pacchetto con il solo ACK attivo e contenente i due numeri x e y incrementati di 1. Una figura chiarirà il concetto:
Alla fine del terzo passaggio la connessione sarà stabilita e entrerà in stato ``ESTABILISHED''. Tutto ciò è necessario per potere gestire più connessioni tra due host e per assicurare l'intergrità dei dati, infatti i successivi incrementi degli ISN non saranno più di 1, ma del numero di byte di dati inviati.
Tutto ciò andò bene fino all'avvento di Kevin Mitnick che dimostrò l'intrinseca debolezza del fatto che i numeri ISN venivano generati in sequenza fissa e quindi facilmente prevedibile. Lui sfruttò questa vulnerabilità per attaccare direttamente la macchina che ne era affetta.
8.2 Idle Scan
Approfondiamo ora il meccanismo dell'idle scan.
Abbiamo visto sopra come avviene una connessione TCP, e abbiamo detto che la prevedibilità del ISN è una debolezza sfruttabile, in questo caso per effettuare uno scan completamente anonimo.
I protagonisti della vicenda sono i seguenti:
- L'host ``Attacker'' A con IP 10.0.0.1 cioè il computer di colui che deve fare lo scan e su cui sta Nmap.
- L'host ``Zombie'' Z con IP 10.0.0.2 cioè il computer che ha la vulnerabilità della prevedibilità del ISN.
- L'host ``Target'' T con IP 10.0.0.100 cioè il computer bersaglio dello scan.
8.2.1 Step 1 - comune
Iniziamo inviando un pacchetto SYN|ACK dal host A a Z (1.1), come abbiamo detto sopra ciò non è regolare poichè una connessione dovrebbe sempre iniziare con un pacchetto SYN, comunque Z risponde chiudendo la connessione con un pacchetto RST (1.2) che contiene il numero ISN, in questo caso 21000.
A questo punto conosciamo l'ISN di Z e sappiamo come verrà incrementato... in maniera lineare.
8.2.2 Step 2
Ora inviamo da A a T un pacchetto SYN ``spoofato'', cioè con l'IP del mittente alterato (2.1). Impersoniamo il povero Z in modo da dare a lui la colpa di tutto attribuendoci l'IP 10.0.0.2. A questo punto le cose si differenziano a seconda che la porta sotto controllo, la 80, sia open o closed.
8.2.3 Step 2 e 3 - Porta 80 di Target open
Se la porta 80 di T è open questi risponderà a Z (ricordiamoci che A ha impersonato Z) con un pacchetto SYN|ACK (2.2) , ma siccome Z non aveva chiesto nulla per lui si tratta di un pacchetto irregolare e chiude la connessione (2.3) inviando un pacchetto RST, che causa l'incremento dell'ISN a 21001.
Infine A invia un pacchetto SYN|ACK a Z (3.1), il quale come fatto durante lo step 1 risponde con un RST contenente l'ISN che sarà incrementato di 2, cioè 21002. Quindi A avrà conferma del fatto che la porta 80 di T è open.
8.2.4 Step 2 e 3 - Porta 80 di Target closed
Se, invece, la porta 80 di T è close, questi risponderà a Z (ricordiamoci che A ha impersonato Z) con un pacchetto RST, che non comporta un ulteriore risposta per cui l'ISN di Z non cambierà
Di conseguenza quando subito dopo A interrogherà di nuovo Z con un pacchetto SYN|ACK e riceverà un RST vedrà che l'ISN sarà aumenteto solo di 1, 21001, e ne dedurrà che la porta 80 di T era closed.
8.2.5 Trovare lo zombie
Concludendo risulta chiaro il motivo per cui questo scan è completamente anonimo. Rimane il problema di trovare un computer adatto a fare lo zombie, ma è molto più facile di quanto non si pensi, infatti, oltre a parecchi computer con sistemi operativi arcaici, la rete è piena di macchine dedicate, tipo router, printserver, modem ADSL, ecc. che spesso trascurano questi aspetti, in quanto nei loro confronti un attacco tramite spoofing, spesso, non ha senso.
Per rintracciarle è utile Nmap stesso che, come abbiamo visto è in grado di analizzare fasce di indirizzi IP e dirci se sono soggette a questa vulnerabilità (vedi appendice 8.3), Per cui dopo qualche ora di ``caccia'' si trova sempre qualche report che ci dice:
TCP Sequence Prediction: Class=64K rule Difficulty=1 (Trivial joke) TCP ISN Seq. Numbers: 81E6F5BD 81E9E3BD 81EADDBD 81EBD7BD 81ECD1BD 81EFBFBD IPID Sequence Generation: Incremental
ma potrebbe essere sufficiente anche:
TCP Sequence Prediction: Class=random positive increments Difficulty=55053 (Worthy challenge) TCP ISN Seq. Numbers: 6F4C2078 6F4F4609 6F539513 6F5550D7 6F58607A 6F5BF10C IPID Sequence Generation: Incremental
trovato lo zombie e individuata una sua porta aperta basterà dare il comando:
> nmap -sI <indirizzo zombie>:<porta open> -P0 -vv <indirizzo target>
8.3 Nmap e la prevedibilità dell'I.S.N.
Come abbiamo visto Nmap è in grado di rilevare il metodo di generazione dell'ISN di un sistema e quindi di emettere un giudizio sulla sua robustezza. Ovviamente non si tratta di scienza esatta, ma è comunque piuttosto affidabile in condizioni normali. Il test potrebbe essere alterato dalla presenza di un'intenso traffico di rete e da singolarità del sistema analizzato. Infatti se da una parte si può dire che analizzato un host con una certa versione di Windows il risultato al 90% lo ritroveremo su altri host con lo stesso sistema, altrettanto non si può dire di Linux, infatti penso che i kernel (al cui interno è implementato lo stack TCP/IP) che girano in rete, tra quelli ufficiali, quelli diffusi dalle varie distro, quelli patchati e quelli modificati e ricompilati da singoli utenti siano svariate migliaia (non penso di esagerare, io stesso ne avrò maneggiato almeno una trentina). E' evidente che intabellare questa specie di brodo primordiale creativo è cosa impossibile. Per cui i risultati ottenuti con le opzioni -O e -v vanno tenuti in considerazione critica.
Quelli che seguono sono una piccola raccolta di risultati raccolti in rete che serve a farsi un'idea del problema. Dove utile inserirò qualche commento.
TCP Sequence Prediction: Class=random positive increments Difficulty=2401409 (Good luck!) Remote operating system guess: Linux 2.1.122 - 2.2.16
TCP Sequence Prediction: Class=random positive increments Difficulty=55800 (Worthy challenge) Remote operating system guess: Sun Solaris 8 early acces beta through actual release
TCP Sequence Prediction: Class=random positive increments Difficulty=42816 (Worthy challenge) Remote operating system guess: Sun Solaris 8 early acces beta through actual release
-----
TCP Sequence Prediction: Class=random positive increments Difficulty=42396 (Worthy challenge) Remote operating system guess: Solaris 2.6 - 2.7
Era in effetti un Solaris 7.
TCP Sequence Prediction: Class=random positive increments Difficulty=26896 (Worthy challenge) Remote operating system guess: Solaris 2.6 - 2.7
Era in effetti un Solaris 6.
TCP Sequence Prediction: Class=random positive increments Difficulty=37482 (Worthy challenge) Remote operating system guess: Solaris 2.5, 2.5.1
Era in effetti un Solaris 2.5.1.
-----
TCP Sequence Prediction: Class=64K rule Difficulty=1 (Trivial joke) Remote operating system guess: HP-UX 9.01 - 9.07
-----
TCP Sequence Prediction: Class=random positive increments Difficulty=13944 (Worthy challenge) Remote OS guesses: Windows 2000 RC1 through final release, Windows Millenium Edition v4.90.3000
TCP Sequence Prediction: Class=trivial time dependency Difficulty=4 (Trivial joke) Remote operating system guess: Windows NT4 / Win95 / Win98
I due scan sopra fanno vedere come la situazione con l'avvento di windows 2000 sia un pò migliorata, per i sistemi Microsoft, ma non è che ci sia da stappare bottiglie di champagne!!!
----
TCP Sequence Prediction: Class=truly random Difficulty=9999999 (Good luck!) Remote operating system guess: AIX 4.3.2.0 on an IBM RS/*
Eeehhh... Non c'è niente da dire... IBM si distingue.
----
TCP Sequence Prediction: Class=trivial time dependency Difficulty=0 (Trivial joke) Remote OS Guess: Sega Dreamcast
TCP Sequence Prediction: Class=64K rule Difficulty=1 (Trivial joke) Remote OS Guess: AmigaOS AmiTCP/IP 4.3
TCP Sequence Prediction: Class=random positive increments Difficulty=1558 (Medium) Remote OS Guess: FreeBSD 2.2.1 - 3.2
In questi tre scan Nmap ha preso solo granchi... in effetti si tratta di tre scan effettuati in tempi diversi su un host con Linux 2.4.2 patchato. Questi dimostra il fatto che in certe condizioni Nmap ha molte difficoltà.
-----
TCP Sequence Prediction: Class=random positive increments Difficulty=26574 (Worthy challenge) Remote OS guesses: MacOS 9 on a Power Macintosh 7200/75, HP-UX B.11.00
-----
TCP Sequence Prediction: Class=trivial time dependency Difficulty=0 (Trivial joke) Remote operating system guess: HP LaserJet Printer
TCP Sequence Prediction: Class=trivial time dependency Difficulty=1 (Trivial joke) Remote operating system guess: Cisco Catalyst 1900 switch or Netopia DSL/ISDN router or Bay 450
Come si diceva molto spesso gli host più vulnerabili sono le macchine dedicate come router, print server, ecc.
-----
TCP Sequence Prediction: Class=64K rule Difficulty=1 (Trivial joke) Remote operating system guess: MacOS 7.5.5 - 9
TCP Sequence Prediction: Class=64K rule Difficulty=1 (Trivial joke) Remote operating system guess: HP-UX 10.20 E 9000/777 or A 712/60 with tcp_random_seq = 0
TCP Sequence Prediction: Class=64K rule Difficulty=1 (Trivial joke) Remote operating system guess: SunOS 4.1.1 - 4.1.4 (or derivative)
Da quanto sopra si può dedurre che in rete ci sono molte macchine insicure, soprattutto quelle con servizi particolari (print server, router, modem, ecc.), le quali molto probabilmente non hanno neanche un sistema di logging, per cui sono ideali come base di attacco.
Ma entriamo un pò più approfonditamente nella lettura dei report di Nmap, riprendendo i due esempi fatti all'inizio di questo articolo, aggiungendone altri due:
- Esempio 1
-
-
TCP Sequence Prediction: Class=64K rule Difficulty=1 (Trivial joke) TCP ISN Seq. Numbers: 81E6F5BD 81E9E3BD 81EADDBD 81EBD7BD 81ECD1BD 81EFBFBD IPID Sequence Generation: Incremental
-
In questo esempio vediamo che il tipo di ``TCP Sequence Prediction''
è ``64K rule'', ed è classificato di difficoltà ``1''
(Uno stupido gioco), in quanto come si può dedurre dalla ``TCP
ISN Seq. Numbers'' i numeri ISN generati (in numerazione esadecimale)
sono dovuti a incrementi di 64000 (in numerazione decimale) o multipli.
Infatti proviamo a sottrarre l'ultimo e il penultimo:
81EFBFBD-81ECD1BD=2EE00 che in decimale è:
192000
192000/64000=3
se facciamo lo stesso calcolo tra il penultmo e il terzultimo avremo:
81ECD1BD-81EBD7BD=FA00 che in decimale è:
64000
e così via...
Risulta quindi chiara la assoluta prevedibilità dell'ISN di questo
sistema.
- Esempio 2
-
-
TCP Sequence Prediction: Class=random positive increments Difficulty=55053 (Worthy challenge) TCP ISN Seq. Numbers: 6F4C2078 6F4F4609 6F539513 6F5550D7 6F58607A 6F5BF10C IPID Sequence Generation: Incremental
-
In questo esempio invece il tipo di ``TCP Sequence Prediction'' è ``random positive increment'', ed è classificato di difficoltà ``55053'' (Un bello scontro), ed in effetti la ``TCP ISN Seq. Numbers'' non ci da elementi certi per determinare l'algoritmo di previsione, ma non è neanche completamente casuale, per cui rimane la possibilità di forzarlo.
- Esempio 3
-
-
TCP Sequence Prediction: Class=trivial time dependency Difficulty=2 (Trivial joke) IPID Sequence Generation: Broken little-endian incremental
-
- Esempio 4
-
-
TCP Sequence Prediction: Class=trivial time dependency Difficulty=1 (Trivial joke) Sequence numbers: 7A140000 7A208000 7A2D0000 7A398000 7A474000 7A528000
-
Nei due esempi sopra abbiamo il tipo di ``TCP Sequence Prediction''
``trivial time dependency'' questo significa che il sistema determina
l'ISN utilizzando i clock del timer in maniera diretta, infatti vediamo,
anche in questo caso, che il metodo delle differenze ci da il seme
utilizzato:
7A474000-7A398000=DC000 che in decimale corrisponde a
901120
7A398000-7A2D0000=C8000 che in decimale corrisponde a
819200
7A528000-7A474000=B4000 che in decimale corrisponde a
737280
se proviamo a fare la differenza tra i tre risultati:
901120-819200=81920
819200-737280=81920
troviamo il seme utilizzato per gli incrementi.
In realtà tutti questi calcoli vengono fatti da Nmap direttamente, ma conoscere il meccanismo è sempre utile.
8.4 Visualizzare i report XML
Per molti motivi spesso può essere utile conservare i report di Nmap e analizzarli in seguito. A tale scopo, probabilmente, il formato migliore che si può scegliere per l'output di Nmap è quello XML, che si ottiene con l'opzione -oX <file>. Il formato XML consente, con molta facilità di utilizzare questi dati in molti modi. Si possono stoccare in un database in maniera molto facile, grazie alle funzioni di parsing dei file XML che tutti i linguaggi di programmazione hanno, o si possono visualizzare immediatamente in una forma molto migliore che non quella che abbiamo visto sopra in questo articolo. Ad esempio questa:
Molto più leggibile e gradevole... vero? Ottenere questa schermata è molto semplice.
Si deve utilizzare l'opzione -oX
> nmap -sS -O -sV -sR -vv -oX scan.xml
Se non si specifica l'opzione --stylesheet
> nmap -sS -O -sV -sR -vv -oX scan.xml --stylesheet http://www.insecure.org/nmap/data/nmap.xsl scan.xml
in modo da utilizzare sempre la versione più aggiornata del file XSL e, in più, il file di report XML sarà utilizzabile anche su computer su cui non è istallato Nmap.
8.5 --packet_trace
Come detto questa opzione di Nmap inserisce nell'output anche i dati relativi ai singoli pacchetti inviati e ricevuti nel corso dello scan e questo può essere molto utile sia per capire in maniera più precisa come risponde l'host bersaglio, sia come funzionano certi meccanismi di rete. Questa parte di output è formattata sullo standard di ``tcpdump'', che è una delle formattazioni più semplici (in relazione alla complessità della materia).
La sintassi di questa formattazione è la seguente:
azione (time) proto IP_sorgente:porta direzione \ IP_destinazione:porta flag ttl id iplen seq win ack
dove:
- azione
- indica il tipo di azione del pacchetto, ad esempio SEND (inviato), RCVD (ricevuto).
- time
- il tempo impiegato in decimillesimi di secondo.
- proto
- il protocollo utilizzato, TCP, UDP, ecc.
- IP_sorgente:porta
- l'IP e la porta da cui partono i pacchetti.
- direzione
- la direzione seguita dal pacchetto espressa con le frecce > e <
- IP_destinazione:porta
- l'IP e la porta a cui sono destinati i pacchetti.
- flag
- indica quali flag dei pacchetti TCP sono attivi possono essere: syncronize S, acknowledgement A, urgent U, push P, reset R, fin F.
- ttl
- tempo di vita del pacchetto espresso in numero di ``salti'' che gli rimangono, cioè di passaggi attraverso router o gateway.
- seq
- questo è il famigerato ISN.
- ack
- il numero di verifica per la connessione.
# nmap 3.55 scan initiated Sat Aug 28 17:33:15 2004 as: \ nmap -sS -O -sV -P0 -p80,81,2082 -v -packet_trace \ -max_parallelism 1 -oN ./packet_trace1.txt www.xyz.com
avviata la scansione con i flag di cui sopra abbiamo il seguente log:
SENT (0.1210s) TCP 10.0.0.7:54592 > 123.321.123.1:2082 S \ ttl=54 id=45784 iplen=40 seq=3688819974 win=3072
Nmap invia un pacchetto TCP con flag SYN attivo all'host bersaglio sulla porta 2082
RCVD (0.6690s) TCP 123.321.123.1:2082 > 10.0.0.7:54592 SA \ ttl=45 id=0 iplen=44 seq=1043425898 win=5840 ack=1043425898
riceve in risposta un pacchetto con flag SYN e ACK attivi, come normale quando la porta è open e non è filtrata da un firewall. Notate i tempi molto stretti.
SENT (0.9270s) TCP 10.0.0.7:54592 > 123.321.123.1:81 S \ ttl=41 id=24453 iplen=40 seq=3688819974 win=2048
Nmap invia un pacchetto TCP con flag SYN attivo all'host bersaglio sulla porta 81. Notate come usa lo stesso numero ISN dell'esempio precedente, il che è sintomo di pacchetto costruito ad arte.
SENT (3.3910s) TCP 10.0.0.7:54593 > 123.321.123.1:81 S \ ttl=49 id=29015 iplen=40 seq=2666369567 win=2048
Siccome non riceve risposta (ha aspettato più di 3 secondi) invia un altro pacchetto SYN cambiando ISN. Anche ora non riceverà risposta in quanto la porta 81 è chiusa.
SENT (0.6700s) TCP 10.0.0.7:54592 > 123.321.123.1:80 S \ ttl=48 id=29346 iplen=40 seq=3688819974 win=1024
Verifica la porta 80 tramite un pacchetto SYN.
RCVD (0.9270s) TCP 123.321.123.1:80 > 10.0.0.7:54592 SA \ ttl=45 id=0 iplen=44 seq=1037335857 win=5840 ack=1037335857
Riceve risposta tramite un pacchetto SYN|ACK quindi la porta è aperta.
SENT (118.6790s) TCP 10.0.0.7:54602 > 123.321.123.1:80 A \ ttl=38 id=3627 iplen=60 seq=374979866 win=3072 ack=374979866
Invia un pacchetto ACK all'host bersaglio, ma ciò non stabilisce la connessione poichè l'invio avviene da una porta diversa da quella che aveva mandato il pacchetto SYN e il numero di verifica è sbagliato.
RCVD (119.2380s) TCP 123.321.123.1:80 > 10.0.0.7:54602 R \ ttl=45 id=0 iplen=40 seq=0 win=0
Per cui l'host bersaglio chiude la connessione tramite un pacchetto RST. Questo tipo di manovra è voluto in quanto consente di studiarne le reazioni e determinare le regole del firewall e il sistema operativo.
8.6 lsof
I sistemi UNIX hanno a disposizione un utility potentissima per determinare quale applicativo è in ascolto, o sta utilizzando una porta, questa utility può anche determinare quale applicativo sta usando un device e molto altro. L'utility in questione si attiva con il comando lsof. L'utilizzo di base è il seguente:
> lsof -i @127.0.0.1
dove -i è l'opzione che indica l'argomento network, è possibile specificare anche la versione del protocollo IP, quindi -i4 per una ricerca solo per la versione IPv4, -i6 per una ricerca solo per la versione IPv6. @indirizzo è l'interfaccia per la quale si fa la ricerca. E' possibile anche specificare la porta @indirizzo:<numero porta>.
Su un sistema dotato di un'interfaccia di rete esterna (scheda di rete, modem, ecc.) per avere l'elenco di tutte le applicazioni che utilizzano una porta si dovrà fare la ricerca sia con l'indirizzo IP dell'interfaccia che con l'indirizzo di loopack 127.0.0.1.
Se vogliamo avere la situazione ad intervalli di tempo basta inserire il flag r <secondi>, preceduto da + se si vuole che lsof continui a ascoltare fino a che ha delle entry, preceduto da - se si vuole che continui senza limiti. Ad esempio:
> lsof +r 10 -i @10.0.0.7:80
Questo è uno dei comandi fondamentali per un amministratore di sistema, infatti non è un caso che è uno dei primi che viene sostituito da un attaccante che riesce a penetrare un sistema.
8.7 Introduction Detection System
Gli Introduction Detection System (IDS) sono software che consentono di captare dei tentativi di intrusione in un sistema o in un segmento di rete. Captato qualcosa di sospetto possono loggare l'evento e/o comunicarlo a chi di dovere. Non svolgono compiti di difesa attiva, a differenza dei firewall. Possiamo dire che il firewall serve a tenere fuori eventuali intrusi, e che l'IDS ne controlla attività e tentativi. Anche i firewall hanno capacità di logging, ma gli IDS sono molto più raffinati e precisi.
Uno dei più famosi è senz'altro ``Snort'' sul quale trovate un tutorial di base in Italiano su Shishii.com.
Snort è estremamente flessibile e performante, e si può interfacciare a molti altri strumenti, come ad esempio un database tipo MySQL, e a strumenti di consultazione come Acid.
8.8 Protocollo FTP
Per comprendere il meccanismo dell'attacco bounce FTP eseguito da Nmap, bisogna conoscere i meccanismi di base di questo protocollo.
Il protocollo FTP è descritto nel documento RFC 959, ed è uno dei protocolli storici della rete. Come dice il nome (File Trasfert Protocol) è dedicato al trasferimento di file in rete. Svolge molto bene questo ruolo, tanto che è ampiamente utilizzato anche oggi. Presenta la particolarità di utilizzare 2 connessioni contemporanee, una la Control Connection è sempre attiva, la seconda la Data Connection si stabilisce solo al momento in cui vengono trasferiti i files. Lo schema riassuntivo può essere il seguente:
L'utente tramite la User Interface impartisce al Client Protocol Interpreter l'ordine di stabilire la connessione con il server, e la porta standard su cui è in ascolto il Server Protocol Interpreter è la 21, mentre il client utilizza una porta qualunque superiore alla 1024, per esempio la 1234. Si tratta della connessione su cui transiteranno i comandi e le risposte in modalità Telnet, quindi puro testo.
Quando l'utente individua un file da scaricare invia un comando GET, a quel punto il server attiva la Server Data Trasfer Process che, per stabilire la Data Connection, si pone sulla porta immediatamente inferiore a quella del Server Protocol Interpreter, quindi la 20 e chiede la connessione al Client Data Trasfer Process (in questo senso c'è un'inversione di ruolo) sulla stessa porta utilizzata dal Client Protocol Interpreter 1234.
Ottenuta la connessione il Server preleva il file dall'hard disk e lo invia in rete al client il quale una volta ricevuto lo salva e ne da conferma al server.
Siccome per iniziare il trasferimento dati è il server a chiedere la connessione al client, se questo è protetto da un firewall, la stessa potrebbe essere bloccata. Per evitare ciò i client più diffusi inviano al server tramite la Control Connection il comando ``PASV 21'', che dice al server di utilizzare la porta 21 anche per la Data Connection, in modo da utilizzare una connessione già stabilita.
Un'altra possibilità, ed quella che viene sfruttata per effettuare lo scan ``bounce ftp'', è data dal comando ``PORT'' tramite cui si può dire al server di stabilire la Data Connection con un IP ed una porta diversi da quelli del client. Ad esempio: ``PORT 123.123.123.123:80''.
A questo punto il server invierà una richiesta di connessione per stabilire la Data Connection alla macchina 123.123.123.123, che è il nostro bersaglio, sulla porta 80, se questa è aperta il server tramite la Control Connection ci comunicherà un messaggio di successo, altrimenti ci comunicherà un messaggio negativo. Inviando lo stesso comando per le varie porte che ci interessano potremo fare effettuare lo scan al server FTP, il cui IP verrà registrato nei log dell'host bersaglio, lasciandoci anonimi.
Questo tipo di attacco è effettuabile solo se si trova un server FTP che consente al comando PORT di modificare, oltre alla porta, anche l'IP per la Data Connection.
Precedente - Indice - Successiva
| Indice del sito |
