Proteggersi su una LAN

[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

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

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.

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

[jappilas]

Bello questo 3D !



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



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




_se_ non vuoi i dati in chiaro _allora_ devono uscire crittografati.....
_se_ vuoi fare a meno della crittografia, puoi provare con IPoverPigeon.....(ma attento ai cacciatori!!!)
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 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/doc...TO-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..... )
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.

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

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

[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

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!