Proteggersi su una LAN

[mjordan]

Salve a tutti. Avrei questo piccolo problema.
E' possibile proteggere i dati che escono dalla mia scheda di rete (magari con qualche tool di crittografia)? Il problema è che sulla LAN è possibile fare dell'ARP poisoning e del password collecting da cui vorrei proteggermi. Io stesso sono riuscito a violentare 13 account POP3 con una facilità enorme. Ho bisogno assolutamente di proteggermi... Come fare???

Grazie a tutti.

[V|RuS[X]]

Originariamente inviato da mjordan
Io stesso sono riuscito a violentare 13 account POP3 con una facilità enorme. Ho bisogno assolutamente di proteggermi... Come fare???

Condom

Non so come aiutarti sinceramente, perchè inanzitutto non hai detto di che rete si tratta, e se hai usato uno sniffer o qualcosa di simile per i pacchetti in uscita.

[V|RuS[X]]

Dopo averti risposto in maniera ironica ho fatto un pò un giro per il web, e se ho capito bene puoi solo controllare con ArpWatch o altri tool se la cosa accade, ma bloccare del tutto il problema non so se sia possibilie.
Aspettiamo persone del calibro di Il_sensine o Dr_Death per una risposta più accurata al problema.

Ps: sarà che non sono mai stato all'interno di grosse lan e quindi mai riguardato personalmente.. ma mi ha sorpreso ed appassionato

[mjordan]

Si tratta di una normalissima LAN su switch.

[mjordan]

Ah... Ho usato ethereal, quindi neanche chissà che ...

[maxithron]

Hai già provato con PGP?

[mjordan]

Ma con PGP è possibile cifrare anche user e pass quando controllo l'email con (per esempio) Mozilla???

[maxithron]

questo è tratto proprio dal sito: www.pgp.com

"PGP Universal moves security from the desktop to the network level, enabling automatic, transparent, two-way secure communications for inbound and outbound email messages for all users—even those outside the organization—without the need for ongoing IT or user involvement."

Per gli altri lettori di questo 3d:

Non è da confondere con un altro paio di 3d postati qualche giorno fa relativi alla crittografia.

Mi permetto di scriverlo solo per evitare qualche "guarda qui" o "guarda la"

[V|RuS[X]]

Originariamente inviato da mjordan
Ma con PGP è possibile cifrare anche user e pass quando controllo l'email con (per esempio) Mozilla???

http://www.mozilla.org/crypto-faq.html

[mjordan]

Come temevo

[VICIUS]

Se il server email è ben configurato è possibile proteggere l'invio e la ricezione delle mail, ma il server lo deve supportare. Quello che gestisce la mia mail per esempio usa TSL in invio e SSL per la ricezione e l'ultima volta che ho provato con ethereal tutto era fatto soto ssl. ovvio anche il client deve poi supportare queste cosine.

ciao

[mjordan]

SSL è solo una falsa illusione. Ethereal non vede i pacchetti solo perchè è un tool di diagnostica, nulla di +. Tool appositi per l'ARP sniffing supportano la decodifica SSL on the fly...(vedi prossima versione di ettercap) quindi non hai risolto niente.

[VICIUS]

Originariamente inviato da mjordan
SSL è solo una falsa illusione. Ethereal non vede i pacchetti solo perchè è un tool di diagnostica, nulla di +. Tool appositi per l'ARP sniffing supportano la decodifica SSL on the fly...(vedi prossima versione di ettercap) quindi non hai risolto niente.

non sapevo che esistessero questi affarini per la decodifica on-the-fly per ssl ... ora mi informo di piu su questo argomento che mi interessa molto.

ciao

[mjordan]

Aiuto

[Hell-VoyAgeR]

tunnel ssh?

ma come anche il dottor morte potrebbe confermare... la sicurezza e' un asintoto!

[HexDEF6]

Originariamente inviato da mjordan
SSL è solo una falsa illusione. Ethereal non vede i pacchetti solo perchè è un tool di diagnostica, nulla di +. Tool appositi per l'ARP sniffing supportano la decodifica SSL on the fly...(vedi prossima versione di ettercap) quindi non hai risolto niente.

ma sei proprio sicuro che le connessioni ssl siano cosi facili da decrittare?????
mi pare un po strambo..


Ciao

[peter_pan]

Prima di tutto mi scuso per le dimensioni del post....
Anche io consiglio l'uso di SSL.
Riguardo all'SSL come falsa illusione, il problema non stà tanto nel SSL stesso ma nel fatto che spesso vengono progettati sistemi in un certo modo eppoi qualcuno pensa bene di utilizzarli in altra maniera......
Mi spiego meglio. Al momento SSL viene utilizzato nel 99% così:
Alice vuole comunicare con Bob; Alice invia la propria chiave pubblica (tipicamente si usa RSA, in alcuni casi Elgamall) a Bob, Bob risponde con la propria chiave pubblica. Avviene un piccolo challenge-handshake per verificare che sia Alice che Bob posseggano realmente la corrispettiva chiave privata. A questo punto si genera una chiave des di sessione e tutta la comunicazione sarà criptata con des (o varianti, di solito si usa triplodes). Questo però _non_ è quello che prevedono le specifiche SSL (almeno la versione 3, le precedenti indicano come opzionale l'uso di certificati). Infatti che cosa può succedere? Tramite arp-poisoning un utente, chiamiamolo C, può redirezionare il traffico di Alice sul proprio computer.
Alice invia la propria chiave pubblica a C (credendo sia Bob). C invia la propria chiave pubblica a Bob; Bob risponde a C (credendo sia Alice) con la propria chiave pubblica. C invia quindi la propria chiave pubblica anche ad Alice.
A questo punto ogni comunicazione tra Alice e Bob avviene così:
Alice cripta con la chiave pubblica di C --> C decripta con la propria chiave privata, legge il messaggio e ricripta con la chiave pubblica di Bob -> Bob riceve il messaggio e lo decifra con la propria chiave privata.
La cosa vale anche nell'altro senso....(in realtà le cose vanno così solo all'inzio, poi si genera la chiave di sessione che è nota ad Alice, Bob e C e C non deve fare altro che decriptare i pacchetti con la chiave di sessione...)

Ora, SSL prevede l'uso di certificati (la frase corretta sarebbe "SSLv3, nell'autenticazione, prevede l'uso di certificati"). Il certificato "certifica" che Alice abbia una certa chiave pubblica e che Bob abbia una certa chiave pubblica.
Nell'esempio di sopra, Alice invia la propria chiave a C; se C inviasse a Bob non la chiave di Alice ma la sua, Bob rivelerebbe che gli è stata inviata una chiave che non corrisponde al certificato (la cosa vale anche in senso inverso). Del resto se C inviasse a Bob la vera chiave di Alice, egli non sarebbe poi più in grado di leggere nessun messaggio poichè i dati crittati con tale chiave sarebbero decriptabili solo con la chiave privata di Alice (che dovrebbe essere solo in suo possesso). Inoltre il certificato non è falsificabile, poichè è "chiuso" con la chiave privata di una certification autorithy ed è leggibile dagli host esclusivamente con la chiave pubblica della CA.

Ricapitolando: SSL si, ma con autenticazione basata sui certificati (altrimenti non serve a molto).
Altra cosa da fare è quella di settare le entrate della tabella ARP come statiche (tanto i Mac non cambiano frequentemente....), magari disabilitando pure la arp-cache. Se la stessa cosa la fai sul gateway, diventa mooolto dura poter ridirigere le connessioni e fare ssl-proxing (che in pratica è quanto ho descritto prima; ettercap fa questo (almeno, da quanto letto sulla documentazione)).

Infine per la crittografia dei contenuti: l'encoding di una email con PGP assicurerà il payload dagli occhi di un avversario ma User e Pass trotterelleranno in chiaro in rete....

[HexDEF6]

Originariamente inviato da peter_pan
Prima di tutto mi scuso per le dimensioni del post....

<--SNIP-->

Grande spiegazione!
da quello che aveva detto mjordan sembrava si riuscisse a decrittare ssl (e mi sembrava decisamente difficile!) in questo caso invece la situazione e' decisamente diversa!

Allora faccio alcune domande:
L'arp-poisoning puo succedere solo in LAN (visto che i mac address esistono solo per le schede di rete e non per modem) giusto??
ma su internet si puo fare qualcosa di simile??

Grazie e Ciao!

[peter_pan]

Originariamente inviato da HexDEF6
Grande spiegazione!

Mi conforti, pensavo di essere stato parecchio oscuro nella spiegazione...

[snip]
L'arp-poisoning puo succedere solo in LAN (visto che i mac address esistono solo per le schede di rete e non per modem) giusto??

Si, lo sniffing lo puoi fare solo per i pacchetti in transito sul tuo segmento di rete. Non tanto per il Mac address, quello è presente pure nei router (nelle varie interfacce; per precisione ogni interfaccia del router ha un indirizzo fisico, il Mac è solo di Ethernet), ma perchè "fisicamente" i pacchetti devono transitare sul tuo cavo. Questo avviene in Ethernet (a dire la verità _non_ avviene in Ethernet-switched; nel caso di mjordan _non_ dovrebbe capitare, poichè lo switch tiene separato ogni flusso di dati tra due host. Se capita probabilmente non è uno switch ma un hub) così come per diverse altre tecnologie di rete.

ma su internet si puo fare qualcosa di simile??

Ni. Non puoi farlo da casa ma lo puoi fare da dentro l'isp limitatamente al traffico dei clienti (ho un amico che ha lavorato in un isp e racconta di episodi divertenti...)

[VICIUS]

grazie per la spiegazione ultra chiara e precisa.

ciao