autenticazione e crittografia

[gabriele]

Carissimo Militanz e carissimi tutti dell'associazione Milk,

vi scrivo per un piccolo confronto riguardo al progetto "edera", che ritengo veramente molto interessante: assieme a alcuni amici vorremmo infatti implementarlo in una scuola pubblica qui del nostro paese, per permettere a tutti gli studenti di accedere liberamente alla rete.

Ho letto attentamente la documentazione e mi sono concentrato sulla fase iniziale di autenticazione, soprattutto sul momento in cui i dati di accesso transitano vua radio.

Se non ho capito male Edera non usa alcuna crittografia.... Mi chiedo e vi chiedo: non ci si espone ad un rischi di sniffing delle credenziali di accesso??

Avevo pensato a free-radius, ma non so se è la giusta soluzione.....

Inoltre, una volta autenticato l'utente, il problema sniffing non si ripresenta anche durante la navigazione?

Volendo inserire un livello di crittografia avanzato (WPA2), come potremmo operare??? Infatti volevamo evitare, per motivi di praticità, chiavi fisse condivise tra access-point e clients....

Quali possono essere le strategie??? Cosa potete dirmi al proposito????

Con i miei complimenti, invio un saluto a tutti.
Gabriele.

[militanz]

Ciao Gabriele,
nel campo dell'autenticazione le cose stanno così: all'aumentare della sicurezza aumenta la complessità.

La soluzione "rete aperta + captive portal" ha dei pregi (non richiede software o configurazioni particolari sui pc degli utenti) e dei difetti (niente crittografia). Una soluzione con pre-shared key (WEP, WPA o WPA2) sarebbe poco utile nella misura in cui tale chiave venga distribuita pubblicamente. Le soluzioni tipo "WPA/WPA2 enterprise", che fanno uso di EAP o similari, permettono crittografia e autenticazione "per utente", ma richiedono sistemi adatti e configurazioni lato client non così semplici! (freeradius si posizionerebbe in quest'ultimo scenario).

Una cosa semplice per proteggere la parte di autenticazione è l'utilizzo di https al posto di http: in questo modo la fase di inserimento di username e password risulterebbe protetta. Nota però che (1) o acquisti un certificato da una società fidata, tipo Verisign (e non costa pochissimo) oppure (2) gli utenti avranno l'errore "certificato non valido" ogni volta che cercano di accedere alla pagina di autenticazione (e quindi aumenti la complessità di utilizzo del sistema).

Il problema sniffing si pone anche dopo, questo è chiaro, ma per fortuna i servizi protetti da ssl (quindi https) sono sempre di più (un tempo erano solo le banche... e nemmeno tutte!).

Grazie per i complimenti e... a presto!

Matteo (militanz)

[gabriele]

Grazie delle risposte Matteo! E, visto che l'appetito vien mangiando...:

1) https
Per il certificato non valido, non mi sembra che sia un grosso problema: basta acquisirlo la prima volta, quando si presenta il messaggio! Potreste darmi per caso delle indicazioni su come fare per provare a passare da un'autenticazione via http a una tramite https?

2)
Ancora un'altra cosa: guardando bene come funziona l'autenticazione, ho visto che viene aggiunta una riga a iptables contenente il MAC della scheda wifi del client. Ma se un malintenzionato riuscisse a intercettarlo con un packet sniffer (dovrebbe essere possible quando l'utente naviga con protocolli non crittati), cambiando il proprio MAC con quello intercettato, anche il malintenzionato potrebbe bypassare i controlli e navigare...
Si potrebbe procedere a rinforzare il controllo aggiungendo l'IP o, meglio, aggiungendo un controllo di sessione nel popup gestito da connect.php, in modo da esser sicuri che l'utente stia navigando con un numero di sessione assegnato proprio dal server...

MAC (attuale)
MAC + IP (migliore, ma non soddisfacente)
MAC + IP + SESSSION_ID (buono)

3)
Che ne pensi di inserire in una prossima versione di Edera le funzionalità di caching? Avevo pensato, ovviamente, a squid (magari, poi, integrato con squidguard)... Anche qui, potresti comunque darmi delle indicazioni su come procedere?

Un saluto e te e a tutti.
Gabriele.

[militanz]

1) https
Per il certificato non valido, non mi sembra che sia un grosso problema: basta acquisirlo la prima volta, quando si presenta il messaggio! Potreste darmi per caso delle indicazioni su come fare per provare a passare da un'autenticazione via http a una tramite https?

Un po' di tempo fa giocammo con Apache2 e l'https... non fu così difficile, ma ammetto che non ricordo con precisione quale guida seguimmo! Questa ad esempio mi sembra sensata: http://server.html.it/articoli/leggi/24 ... oni-https/

2) Ancora un'altra cosa: guardando bene come funziona l'autenticazione, ho visto che viene aggiunta una riga a iptables contenente il MAC della scheda wifi del client. Ma se un malintenzionato riuscisse a intercettarlo con un packet sniffer (dovrebbe essere possible quando l'utente naviga con protocolli non crittati), cambiando il proprio MAC con quello intercettato, anche il malintenzionato potrebbe bypassare i controlli e navigare...
Si potrebbe procedere a rinforzare il controllo aggiungendo l'IP o, meglio, aggiungendo un controllo di sessione nel popup gestito da connect.php, in modo da esser sicuri che l'utente stia navigando con un numero di sessione assegnato proprio dal server...

MAC (attuale)
MAC + IP (migliore, ma non soddisfacente)
MAC + IP + SESSSION_ID (buono)

Ottima idea ma... serve? Un MAC address lo puoi ottenere sniffando, corretto, e lo puoi usare senza difficoltà. Ma due MAC addresses in una rete fanno a pugni, pertanto finché è attivo un device (con popup running) è inutile rubargli il MAC: finisce che non si naviga in due. Se invece uno "ruba" un MAC address per usarlo in un secondo momento... niente login -> niente popup -> niente di niente!

3) Che ne pensi di inserire in una prossima versione di Edera le funzionalità di caching? Avevo pensato, ovviamente, a squid (magari, poi, integrato con squidguard)... Anche qui, potresti comunque darmi delle indicazioni su come procedere?

Sai che ho sempre detestato i proxy?! Insomma, se uno deve valorizzare al massimo la sua connessione ISDN ben venga, ma dubito che un internet point non abbia banda a sufficienza... IMHO! Purtroppo di Squid so ben poco...

Ciao,
Matteo

[gabriele]

Veramente...
ho appena fatto questa prova con 2 clients (CLIENT1, utente onesto; CLIENT2 utente malintenzionato):

1. CLIENT1: si connette a Edera con username+password con MAC1+IPADDRESS1
2. CLIENT1: naviga tranquillamente
3. CLIENT2: controlla il traffico sul canale wifi e registra il MAC1 e l'IPADDRESS1
4. CLIENT2: sceglie un IPADDRESS2 diverso da IPADDRESS1 e se lo assegna
5. CLIENT2: sceglie un MAC uguale a MAC1 e se lo assegna
6. CLIENT2: naviga tranquillamente all'insaputa di CLIENT1.

Tutto ciò funziona ovviamamente fintanto che il MAC comune ai due clients è in iptables; ma in un contesto con N clients onesti, al malintenzionato ci vuol poco a passare ad un altro MAC nel momento che un utente onesto si disconnette.

Per questo motivo avevo pensato che sarebbe utile registrare MAC+IP+SESSIONE, al fine di evitare attacchi di questo tipo.

...

Proseguendo nella prova di Edera ho poi notato un'altro comportamento "strano":
1. CLIENT: si connette a Edera con username+password
2. CLIENT: apre un browser e naviga tranquillamente col pupup che scala i minuti da un assegnato valore iniziale, diciamo 60 minuti
3. CLIENT: poco prima che i minuti vadano a 0, il CLIENT termina (da task manager) tutti i processi relativi al browser, compreso, ovvimante, il popup
4. SERVER: dopo un po' interviene disaster.php che mette tutto a posto.
5. CLIENT: riesegue il login e i minuti sono tornati al valore iniziale di 60, così che egli può navigare ancora liberamente.

In questo modo, con un ticket da 60 minuti, un malintenzionato può navigare quanto vuole. Vi risulta questo comportamento?

Un (altro) saluto,
Gabriele.

[militanz]

Ciao Gabriele,
che meraviglia averti sul forum... sei preziosissimo!

Sul punto 1 rimango sorpreso e... non mi spiego molto bene come possa essere possibile. Probabilmente l'access-point non si preoccupa del fatto che due client hanno lo stesso mac address, e probabilmente manda le frame a tutti e due. Curiosità: se attivi Wireshark su CLIENT2 vedi arrivare frames dirette a CLIENT1? Mi aspetterei di si!

Sul punto 2... appena Whites torna dalle ferie sono sicuro che ti risponderà! Di base dovrebbe esserci il decremento del traffico ad ogni "giro" del popup, ma forse sto dicendo ca$$ate (come avrai capito il codice non lo curo io ).

Intanto grazie... a presto!

Matteo

[Pistaaa]

Confermo il comportamento segnalato, lo stesso accade anche se, per qualche ragione il browser si impalla, così come se il credito finisce viene restituito il valore -1 (come ho già segnalato) e quindi non c'è più la possibilità di ricaricare credito al cliente in questione, ma ogni tanto viene restituito -2 (questo quando ho segnalato il problema non mi era ancora successo) ed in questo caso posso ricaricare tranquillamente.
Ciao a tutti ed ancora grazie dell'ottimo lavoro svolto.

[gabriele]

Mi fa molto piacere partecipare...

Già che ci sono ve ne segnalo un'altra (probabilmente legata ai bug precedenti):

1. CLIENT1: si connette a Edera con USERNAME1+PASSWORD1 con MAC1+IPADDRESS1 e naviga
2. CLIENT1: passa USERNAME1 e PASSWORD1 a CLIENT2
3. CLIENT2: si connette a Edera con USERNAME1+PASSWORD1 con MAC2+IPADDRESS2 e naviga!

La situazione corrisponde, in poche parole, al caso in cui 2 utenti diversi acquistano ad esempio 1 unico ticket da 60 minuti e navigano entrambi contemporaneamente: Edera scala i minuti non dallo stesso contatore (come ci si potrebbe aspettare, ovvero 30 minuti a testa), ma riparte da 60 anche per CLIENT2. Il risultato è quello di aver navigato 120 minuti con un ticket da 60.

Gabriele.

[whites]

Ciao Gabriele e grazie anche da parte mia per la collaborazione.
Il motivo principale dei problemi relativi ai ticket a tempo sta nel fatto che lo sviluppo si è concentrato essenzialmente sulle credenziali illimitate, mentre i ticket a tempo limitato sono stati introdotti agli inizi dello sviluppo e un po' accantonati nel seguito.
Ciò non toglie che i problemi che hai segnalato vadano risolti.
Per la questione del mac address clonato io, da non esperto di networking, mi aspetto che la presenza simultanea di due mac address uguali in rete crei notevole confusione (come dice militanz). Tuttavia la questione richiede ulteriori approfondimenti in collaborazione con i colleghi del reparto networking.