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 :D

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" :D

[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 :D

[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 :cry:

[Hell-VoyAgeR]

tunnel ssh?

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

[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 ;)

[HexDEF6]

Originariamente inviato da peter_pan
Mi conforti, pensavo di essere stato parecchio oscuro nella spiegazione...


Tuttaltro... chiara e precisa!


Originariamente inviato da peter_pan
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 un modem ADSL (tipo il mio speddtouch usb) non dovrebbe avere mac address o invece lo ha anche lui???

Credo che comunque si possa fregare uno switch non serio.... con un hub e' troppo facile (e' come essere su una vecchia ethernet!!)

Originariamente inviato da peter_pan
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...) ;)

ovviamente "l'uomo in mezzo" ha sempre piu' possibilita degli altri!....

Ciao

[peter_pan]

Originariamente inviato da HexDEF6
ma un modem ADSL (tipo il mio speddtouch usb) non dovrebbe avere mac address o invece lo ha anche lui???

Il modem si connette al computer tramite seriale e viene visto come collegamento punto-punto (non ha indirizzo fisico, nel senso networking del termine...). Essendo punto-punto non necessita di indirizzo hw.


Credo che comunque si possa fregare uno switch non serio.... con un hub e' troppo facile (e' come essere su una vecchia ethernet!!)

Lo switch "vero" ha n porte e, in assenza di traffico, queste risultano "disconnesse" tra loro. Quando un host inizia uno scambio dati con un altro host lo switch provvede a effettuare il bridge della porta sorgente con quella di destinazione: il traffico fluisce esclusivamente tra le due porte e le rimanenti n-2 porte restano sconnesse (ovvero da una di queste porte non è possibile fisicamente vedere il traffico delle 2 porte suddette). L'hub è diverso in quanto non è un dispositivo intelligente ma provvede passivamente a connettere tutte le n porte tra di loro (non a caso, su uno switch è possibile avere in contemporanea n/2 connessioni, l'hub supporta al più un'unico flusso dati)

[LukeHack]

o si una uno switch oppure, in caso di hub,l'unica soluzione è la criptazione con doppia chiave,vedi SSL

[mjordan]

Originariamente inviato da HexDEF6
Tuttaltro... chiara e precisa!


Ripresa dal Kurose / Ross - Internet e Reti di Calcolatori :D

Scherzi a parte. Stiamo andando un po off topic. E crittografia a parte, i dati user e pass escono in chiaro dalla mia scheda di rete. E devo assolutamente trovare una soluzione anti sniffing.

[peter_pan]

Originariamente inviato da mjordan
Ripresa dal Kurose / Ross - Internet e Reti di Calcolatori :D

Spiacente, non conosco il libro di cui parli.
Per conoscenza, Alice e Bob sono i nomi che vengono utilizzati in letteratura informatica quando si parla di crittografia (lettere A e B dell'alfabeto...) e sono riportati in almeno 2000 libri diversi......(provare per credere....) ;)


Scherzi a parte. Stiamo andando un po off topic. E crittografia a parte, i dati user e pass escono in chiaro dalla mia scheda di rete. E devo assolutamente trovare una soluzione anti sniffing.

:what:
_se_ non vuoi i dati in chiaro _allora_ devono uscire crittografati..... :D
_se_ vuoi fare a meno della crittografia, puoi provare con IPoverPigeon.....(ma attento ai cacciatori!!!):D
In conclusione SSL è la soluzione _de facto_, poi esistono n altre alternative ma basate tutte sulla crittografia

[jappilas]

Bello questo 3D ! :cool: :)



... riprendo la domanda di Hexdef6 sul modem adsl...

col modem ADSL , però su ETHERNET (Speed touch HOME), cambia qualcosa, tutto, niente...?

[VICIUS]

Originariamente inviato da jappilas
Bello questo 3D ! :cool: :)



... riprendo la domanda di Hexdef6 sul modem adsl...

col modem ADSL , però su ETHERNET (Speed touch HOME), cambia qualcosa, tutto, niente...?

se il collegamento tra modem e computer è diretto e non passa atraverso un hub non dovrebbe esserci alcun problema.

ciao ;)

[mjordan]

Originariamente inviato da peter_pan
Spiacente, non conosco il libro di cui parli.
Per conoscenza, Alice e Bob sono i nomi che vengono utilizzati in letteratura informatica quando si parla di crittografia (lettere A e B dell'alfabeto...) e sono riportati in almeno 2000 libri diversi......(provare per credere....) ;)



:what:
_se_ non vuoi i dati in chiaro _allora_ devono uscire crittografati..... :D
_se_ vuoi fare a meno della crittografia, puoi provare con IPoverPigeon.....(ma attento ai cacciatori!!!):D
In conclusione SSL è la soluzione _de facto_, poi esistono n altre alternative ma basate tutte sulla crittografia


Ok... Dove posso cominciare a leggere un po di documentazione a riguardo?
Su google pare tutto molto frammentato. A me piacerebbe criptare TUTTO, a cominciare dalle richieste GET dei webserver. Odio sapere che qualcuno potrebbe vedere i fatti miei.

[HexDEF6]

Originariamente inviato da mjordan
Ok... Dove posso cominciare a leggere un po di documentazione a riguardo?
Su google pare tutto molto frammentato. A me piacerebbe criptare TUTTO, a cominciare dalle richieste GET dei webserver. Odio sapere che qualcuno potrebbe vedere i fatti miei.

Basta che ti colleghi solo a web server su https!!!!

Scherzo!

Ma credo sia dura!

Ciao

[peter_pan]

Originariamente inviato da jappilas
col modem ADSL , però su ETHERNET (Speed touch HOME), cambia qualcosa, tutto, niente...?

Rispondo, anche se ormai siamo palesemente OT. :)
Il modem normale (56k) lavora a livello fisico (nella pila dei protocolli). Il suo compito è solo quello di modulare/demodulare il segnale elettrico perchè questo possa essere trasmesso su linea PSTN.
Il modem ADSL ethernet lavora sicuramente a livelli superiori (questo comunque a seconda dei modem...). Le cose certe sono:
1) Essendo Ethernet deve avere un Mac Address. Come tale, è passibile degli attacchi disponibili, allo stato attuale dell'arte, per i dispositivi che supportano il livello datalink (questo nell'ipotesi che il modem sia collegato alla Ethernet, ovvero ad un hub o switch. Se collegato ad una scheda di rete privata di un host, il modem sarà visibile al livello fisico solo dall'host cui è connesso)
2) Il modem avrà un proprio IP. Il modem provvede quindi anche alla gestione del livello IP (con quello che ne consegue)
3) Diversi modem hanno features superiori, quali NAT o PAT. Questo implica che il modem sale su fino a livello TCP smanettando nei campi dell'header per modificare porte/etc. La complessità sale, i rischi pure
(n.d.a.: stiamo comunque parlando di rischi __ipotetici__ e/o paranoie...)

In molti ambienti si dice che una stima approssimativa dell'indice di sicurezza di un dispositivo di networking è pari al rapporto tra costo del dispositivo e funzionalità offerte....;)

[peter_pan]

Originariamente inviato da mjordan
Ok... Dove posso cominciare a leggere un po di documentazione a riguardo?
Su google pare tutto molto frammentato. A me piacerebbe criptare TUTTO, a cominciare dalle richieste GET dei webserver. Odio sapere che qualcuno potrebbe vedere i fatti miei.

Uhm.... dare una risposta molto precisa è difficile perchè non sono a conoscenza della tipologia di rete, delle disponibilità hw/sw, dei diritti che tu hai sulla rete (possibilità di accedere come amministratore al gateway, etc.). Ci provo.
Ricapitolando: tu sei su una Ethernet, i tuoi vicini leggono i tuoi pacchetti, vuoi adottare contromisure. La premessa da fare è: se tu cripti il traffico, _qualcun altro_ deve decriptarlo. Il gioco si basa tutto sull'identificare questo _qualcun'altro_ (che deve esistere, perchè il traffico è intellegibile solo quando è in chiaro).

Soluzione 1) I server sono _qualcun altro_. In pratica fai uso di soli servizi shttp o https, pop3overSSL, etc.etc.
Vantaggi: la configurazione è semplicissima, spesso assente. Per il web non devi fare nulla (il browser è già abilitato, di solito, per gestire connessioni ssl), per la posta devi settare la porta del pop3 server e i parametri per l'autenticazione (anche il programma di posta deve supportare ssl). Esistono svariate applicazioni già pronte per l'utilizzo di SSL.
Svantaggi: puoi visitare _solo_ siti predisposti (di solito solo alcuni per l'e-commerce o l'e-banking), il 99,9% dei siti rimarrà in chiaro. Devi avere un gran :ciapet: nel trovare un server di posta SSL. Pochissimi sono i server di protocolli vari che supportano SSL.
La soluzione è talmente banale che non necessita di documentazione....

Soluzione 2) Installi un demone ssh sul gateway della tua lan. Devi poi provvedere ad installare sul gateway un proxy per ogni applicazione che intenderai usare (posta, web,etc.). A questo punto devi creare un tunnel virtuale basato su ssh tra te e il gateway (una vpn crittata con ssl).
Imposti quindi tutte le tue applicazioni affinchè non usino direttamente la rete, ma provvedano a effettuare le richieste ai corrispettivi proxy.
Le comunicazioni avvengono così:
Tuo programma -> cripto SSL -> tunnel SSL fino al gateway -> decripto SSL -> redirezione al proxy corretto che gira sullo stesso gateway -> Internet
In ricezione avviene il viceversa.
Vantaggi: chiunque faccia lo sniffing dei pacchetti sulla Ethernet vede passare pacchetti SSL che non riuscirà a decodificare (nelle ipotesi dette nei precedenti post...). E' di semplice realizzazione (il server si tira su in poco tempo, di proxy ne esistono di tutti i gusti, dal lato client si settano i programmi in un attimo)
Svantaggi: Devi avere la possibilità di mettere le mani sul gateway (questo vale anche in molti altri casi, dall'uso di IPsec al sistema basato su redirezioni virtuali). Devi potere installare applicazioni sul gateway (se è un router diventa dura...). Il gateway diventa quello che viene definito "punto singolare di fallimento" (ovvero il gateway deve essere blindato. Sul gateway infatti avviene la decodifica e da li in poi le informazioni viaggiano in chiaro: se qualcuno installasse tcpdump sul gw saresti nuovamente punto a capo. Devi in pratica essere _l'unico_ admin della rete).
Per dettagli tecnici ti rimando a :
http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html/VPN-HOWTO-html.tar.gz

Soluzione 3) [per inciso è la soluzione che uso io. Ho un portatile e spesso mi ritrovo ad attaccarmi a reti ethernet non fidate e non mi piace che il mio traffico sia visibile su una rete foreign...]
Hai bisogno di un server che giri su una rete esterna alla LAN su cui ti trovi. Ad esempio, io ho una macchina (P133) collegata ad internet 24/24, da me sempre raggiungibile, che mi fa questo servizio....(nota: se hai un IP dinamico non importa, esistono 1000 modi per conoscere in remoto qual'è l'IP attuale del tuo server)
Sul server installi il solito demone ssh e i soliti proxy (che però non devono essere accessibili da internet, ma solo dal demone ssh; questo affinchè chiunque non possa sfruttare i tuoi proxy.....:D )
A questo punto crei un tunnel IP (IP Tunneling) tra la tua macchina sulla Lan e il demone ssh che gira sul server esterno. Le impostazioni avvengono come alla soluzione precedente, solo che ora non hai più bisogno di mettere mano al gateway ma ti basta una macchina online che ti dia il servizio....
Le comunicazioni avvengono così

Tuo programma -> critto SSL -> gateway (che non capisce cosa ha tra le mani poichè i pacchetti sono criptati) -> internet ->tunnel SSL fino al tuo server remoto -> decripto SSL -> passaggio della richiesta all'opportuno proxy che gira sulla macchina -> internet
Ovviamente vale il viceversa per le ricezioni delle risposte.
Vantaggi: tutto il traffico viaggia in SSL. Chounque sulla tua rete (administrator compreso) non ha idea di quello che tu stai facendo perchè non è in grado
1) di vedere i tuoi pacchetti
2) capire che url stai visitando, poichè tu contatti sempre e solo il solito IP (il tuo server remoto).
La VPN è il top per la sicurezza. Un maggior grado di sicurezza si può ottenere solo con tecniche molto specializzate (sulla base dell'applicazione o delle risorse hw).
Svantaggi: Disponibilità di un server remoto. Inefficienza (ogni connessione va criptata e ogni connessione richiede due indirezioni per ogni direzione); la connessione sarà quindi decisamente più lenta!!! (la sicurezza si paga....)
Inoltre le configurazioni si complicano (per documentazione ti consiglio il documento sopra citato o qualsiasi manuale che spieghi come effettuare VPN).
Il server remoto va protetto adeguatamente con firewall e tecniche (possibilmente raffinate) di autenticazione onde evitare gente a spasso sul tuo server (un anello che crolla comporta la caduta dell'intera catena)


Sono ovviamente possibili migliaia di varianti o aggiustamenti (ad esempio, una variante della 3° soluzione consiste, per aumentare l'efficienza, di non ridirigere sul server remoto tutto il tuo traffico ma solo quello "sensibile" come posta o accesso a siti in cui si richiede identificazione (sempre per inciso, è quello che faccio io quando mi ritrovo su reti foreign))

[mjordan]

Tutte soluzioni non realizzabili per me perchè la LAN non è amministrata. Ho un comunissimo accesso con HUB e non dispongo di una macchina perennemente connessa a Internet. Amen. :mad:

[peter_pan]

Originariamente inviato da mjordan
Tutte soluzioni non realizzabili per me perchè la LAN non è amministrata. Ho un comunissimo accesso con HUB e non dispongo di una macchina perennemente connessa a Internet. Amen. :mad:

Ma per "Lan non amministrata" intendi proprio che è abbandonata a se stessa, o che non è amministrata da te? Nel secondo caso potresti provare a contattare l'admin, sollevando i problemi di sicurezza che ci hai segnalato (sniffing,etc.) consigliandogli l'adozione di proxy e contromisure varie (penso che avresti l'appoggio degli altri utenti con cui condividi il segmento Ethernet)

[peter_pan]

Mi sono dimenticato un pezzo. Esistono altre svariate soluzioni, ma implicano tutte dei costi più o meno alti (acquisto di apparecchiature, affitto di spazi su server virtuali esterni,etc.). Le soluzioni prima indicate si riferiscono a costi 0.

[mjordan]

Bhè mica tanto 0. Un comune mortale come se lo mette un computer collegato a Internet 30/7/24 per un eventuale tunnelling :p

[peter_pan]

Originariamente inviato da mjordan
Bhè mica tanto 0. Un comune mortale come se lo mette un computer collegato a Internet 30/7/24 per un eventuale tunnelling :p

Oramai le ADSL vanno forti... :) :) :)

[HexDEF6]

Originariamente inviato da peter_pan
Lo switch "vero" ha n porte e, in assenza di traffico, queste risultano "disconnesse" tra loro. Quando un host inizia uno scambio dati con un altro host lo switch provvede a effettuare il bridge della porta sorgente con quella di destinazione: il traffico fluisce esclusivamente tra le due porte e le rimanenti n-2 porte restano sconnesse (ovvero da una di queste porte non è possibile fisicamente vedere il traffico delle 2 porte suddette). L'hub è diverso in quanto non è un dispositivo intelligente ma provvede passivamente a connettere tutte le n porte tra di loro (non a caso, su uno switch è possibile avere in contemporanea n/2 connessioni, l'hub supporta al più un'unico flusso dati)

Ciao!
Riesumo questa thread dopo aver smanettato un po con ettercap....
direi che se una LAN e' su switch e' tutto tranne sicura!
In effetti con ettercap si possono monitorizzare le connessioni che avvengono fra 2 pc della stessa LAN (anche se sono su switch!) e si riesce perfino a killare una qualsiasi connessione o mettere in pratica un qualsiasi attacco MITM.....

Ciao!

P.S. e per giunta ettercap e' di una facilita' impressionante da usare!

[peter_pan]

Originariamente inviato da HexDEF6
direi che se una LAN e' su switch e' tutto tranne sicura!

_SE_ la rete è _realmente_ switchata le cose non sono così semplici perchè lo switch, in quanto componente attivo, permette la connessione solo tra coppie di host (ovvero mette in comunicazione gli host solo quando si trova tra le mani un pacchetto). In questo modo la scheda di rete in modalità promiscua può raccogliere solo i pacchetti in transito sul proprio segmento di rete. In una ethernet switched il "proprio segmento di rete" è quello che va dall'host allo switch. Pertanto le comunicazioni tra due host della rete non possono essere intercettate perchè, fisicamente, lo switch non effettua il flooding dei pacchetti su porte che non siano quelle destinatarie dei pacchetti.
Il fatto è come vengono implementati gli switch di fascia bassa (uno switch "reale" costa diverse centinaia di euro). In pratica uno switch di fascia bassa non è altro che un hub un po' più intelligente (è un multihub con semplice circuiteria che smista le comunicazioni su hub differenti) e quest'implementazione risente dei problemi tipici di un hub,
Un hub non è altro che uno scatolotto con n porte; se un host A invia un pacchetto su una porta dell'hub, l'hub non fa altro che reinviare il pacchetto su tutte le n-1 porte rimanenti. In questo modo lo sniffing funziona perchè A invia un pacchetto all'HUB indirizzandolo a B, mentre l'hub lo reinvia su tutte le porte (ovvero a B ma anche alla tua macchina con scheda di rete in mod. promiscua). Ed ecco che sorgono i problemi di sniffing dei pacchetti, uomo nel mezzo, etc.


In effetti con ettercap si possono monitorizzare le connessioni che avvengono fra 2 pc della stessa LAN


_SE_ le connessioni avvengono in chiaro.... :)


(anche se sono su switch!)


Tempo fa ho posto (indirettamente) la domanda ad uno degli autori del BSDpacket-filtering:
"perchè riesco a sniffare i pacchetti su una ethernet-switched?"
Lui:"e quanto l'hai pagato lo switch?"
Io:"30-40Euro"
Lui:"Seeee vabbeh, e per 30-40 euro pensi davvero che sia uno switch???"
(seguì la spiegazione di come le case produttrici vendono switch che in realtà non fanno bridging ma semplice relay su tutte le porte e che i veri switch costano in realtà almeno 8 volte tanto)

[HexDEF6]

Originariamente inviato da peter_pan
_SE_ la rete è _realmente_ switchata le cose non sono così semplici perchè lo switch.....
<--SNIPPONE-->



Si....
quello che volevo dire (se noti anche il mio precedente post) era che per gli switch che si trovano normalmente in piccoli uffici/casa (ma a volte anche in posizioni piu' rischiose) sono sfigati e soffrono di certi problemi (arp poisoning?) (come funzionano gli switch seri?? dove trovo qualche info?)

Ovviamente mi riferifo a connessioni in chiaro....
E comunque a volte anche se normalmente le connessioni sono crittate molte persone cadono in tranelli (sniffavo uno che si collegava ad una macchina tramite ssh, gli facevo cadere la connessione SEMPRE dopo circa 1 minuto, alla quarta volta ha usato telnet!!!... password beccata!... ovviamente non si e' chiesto perche' ssh funzionava per solo un minuto)

Ciao!

[Hell-VoyAgeR]

Originariamente inviato da HexDEF6
Si....
quello che volevo dire (se noti anche il mio precedente post) era che per gli switch che si trovano normalmente in piccoli uffici/casa (ma a volte anche in posizioni piu' rischiose) sono sfigati e soffrono di certi problemi (arp poisoning?) (come funzionano gli switch seri?? dove trovo qualche info?)

Ovviamente mi riferifo a connessioni in chiaro....
E comunque a volte anche se normalmente le connessioni sono crittate molte persone cadono in tranelli (sniffavo uno che si collegava ad una macchina tramite ssh, gli facevo cadere la connessione SEMPRE dopo circa 1 minuto, alla quarta volta ha usato telnet!!!... password beccata!... ovviamente non si e' chiesto perche' ssh funzionava per solo un minuto)

Ciao!

noi due non potremmo lavorare nello stesso posto! :D :asd:

[peter_pan]

Originariamente inviato da HexDEF6
quello che volevo dire (se noti anche il mio precedente post) era che per gli switch che si trovano normalmente in piccoli uffici/casa (ma a volte anche in posizioni piu' rischiose)

si, il sysadmin dovrebbe curare aspetti di sicurezza come la creazione di tunnel sicuri/trasparenti con il gateway, eliminare per le comunicazioni locali ogni tipo di autenticazione basata su password e sostituirla con quella basata su certificati, etc.


come funzionano gli switch seri?? dove trovo qualche info?

A livello logico in uno switch è presente un bridge per ogni coppia di porte (questo a livello logico, per l'implementazione si tende al risparmio... :D)
ovvero in uno switch n-porte, alla porta X sono collegati n-1 bridge verso le restanti n-1 porte.
Lo switch si suppone auto-learning: appena una scheda di rete (collegata allo switch) trasmette un frame, lo switch si segna in una propria tabella la coppia

MacAddress_della scheda_di_rete --- porta_dello_switch_a_cui_è_collegata.

Trascorso un po' di tempo, lo switch è in grado di sapere per ogni sua porta chi (in termini di mac address) c'è connesso.
Fatto il periodo di auto-learning, quando si tramette un frame....
-) il frame giunge tramite una porta X allo switch
-) lo switch controlla il destination mac address presente nel frame, consulta la tabella che si è costruito stabilendo su che porta re-inviare il frame (supponiamo porta Z)
-) Invia il frame _solo_ sulla porta Z

Con questo meccanismo i frame vengono "smistati" su rete locale solo tra mittente e destinatario; terze entità, a meno che non si facciano appositi gioconi (che si possono tuttavia fare) non vedono passare fisicamente i pacchetti.


Per ulteriori info....uhm.....su google ho trovato questo
http://www.ccontrols.com/pdf/Issue%209.pdf
non è il massimo ma è qualcosa ;)

[LukeHack]

fammi un esempio di "giocone" che si puo fare collo switch
tipo mitm?

[peter_pan]

Originariamente inviato da LukeHack
fammi un esempio di "giocone" che si puo fare collo switch
tipo mitm?

Diciamo che il mitm è qualcosa di più di alto livello (nel senso che è una tipologia di attacco, qualcosa più di concettuale che fisico; io mi riferivo a cose più di basso livello/livello fisico che, a seconda di come vengono sfruttate, possono dare libero campo ad attacchi di alto livello come il mitm).
Uhm...esempi....molti switch sono completamente configurabili, a volte troppo.... una delle feature, spesso presente, è quella di poter settare una delle porte dello switch in modalità promiscua (in realtà è una modalità leggermente differente dalla promiscua; in pratica lo switch non accetterà traffico in ingresso dalla suddetta porta ma effettuerà una copia di tutto il traffico passante per lo switch _sulla_ suddetta porta). Questa feature viene tipicamente impiegata dai sysadmin per loggare tutto il traffico che passa sulla rete (in pratica si setta la porta sullo switch, si collega la porta ad una interfaccia ethernet in mod.prom., si fa girare sull'host il sempreverde tcpdump $interfacciausata $lungalistadifiltri, etc.etc.)
Il fatto è che questa feature può essere usata da $tiziosimpatico che passa la sua giornata a sniffare tutto il traffico della rete :D
(sull'altro lato del cavo potrebbe esserci sniffer, keylogger, etc.etc.)
Altra falla: gli host comunicano tra loro mediante visibilità IP
(A sà che l'indirizzo di B è 192.168.X.Y mentre B sà che A ha indirizzo 192.168.X.Z). Con un po' di arp-poisoning fatto ad arte si può riuscire a scombinare le arp-cache dei due host così che:
ArpCachediA
192.168.X.Y ---> MacAddressditerzapersona
ArpCachediB
192.168.X.Z ---> MacAddressditerzapersona

Quando A invia messaggio a B lo spedisce su MacAddressditerzapersona e lo switch non farà altro che inviarlo sulla porta di terzapersona; terzapersona si prende il pacchetto, ne fa quello che vuole, indi lo rinvia a MacdiB (e lo switch lo rigirerà sulla porta di B). La cosa avviene simmetricamente quando B invia ad A.
Altra falla: lo switch fa auto-learning. Ma se uno degli host fa il simpaticone e continuamente immette pacchetti su una certa porta con MacAddress sempre diversi..... :D

Nota conclusiva: fare 'sti gioconi non è sempre facile, anzi. Specialmente quando si va a smanettare nei macaddress le cose si fanno difficili sebbene pur sempre possibili (di solito grazie al solito arp). Sicuramente il livello di sicurezza di uno switch è un gradino up rispetto ad un hub, ma questo non deve significare "occhebbello ho uno switch, da domani password in chiaro per tutti!" ;)
Continuo comunque a sostenere che l'accoppiata tunnelSSL+autenticazione basata su certificati sia un binomio molto forte per una grossa fetta di applicativi :)

[LukeHack]

grazie,molto chiaro:):oink:

[HexDEF6]

Originariamente inviato da Hell-VoyAgeR
noi due non potremmo lavorare nello stesso posto! :D :asd:

???????
Perche' ???

[Hell-VoyAgeR]

Originariamente inviato da HexDEF6
???????
Perche' ???

beh... perche' passeremmo tutto il giorno a litigarci gli utOnti da seviziare! :D :ahahah: :eheh:

[A-ha]

Originariamente inviato da Hell-VoyAgeR
beh... perche' passeremmo tutto il giorno a litigarci gli utOnti da seviziare! :D :ahahah: :eheh:

Sei il solito maniaco... :D :D

[Hell-VoyAgeR]

Originariamente inviato da A-ha
Sei il solito maniaco... :D :D

ma buongiorno!!

eh mi conosci bene tu! (pero' quando si lavorava insieme non c'era da litigare per gli utonti... vero?) :D :ciapet:

[A-ha]

Originariamente inviato da Hell-VoyAgeR
ma buongiorno!!

eh mi conosci bene tu! (pero' quando si lavorava insieme non c'era da litigare per gli utonti... vero?) :D :ciapet:

Erano tanti... un pò a ciascuno e via... :D :D

[HexDEF6]

Originariamente inviato da Hell-VoyAgeR
beh... perche' passeremmo tutto il giorno a litigarci gli utOnti da seviziare! :D :ahahah: :eheh:

:D :D :D :D