Se vi capita spesso di viaggiare e di connettervi ad access point pubblici, vi sarà sicuramente balenata in mente almeno una volta una questione assai delicata: quanto è sicura la connessione che sto utilizzando?
In generale, infatti, la quasi totalità delle reti pubbliche è costituita da un segnale wireless aperto, senza alcun tipo di connessione o crittografia, e l’identificazione dell’utente avviene attraverso il cosiddetto captive portal, ovvero una pagina HTML iniziale che ha lo scopo di identificare l’utente.
Questa particolare tipologia di rete, sebbene molto pratica da gestire dal punto di vista amministrativo, presenta non pochi rischi per chi si collega. Infatti, essendo in chiaro, ogni singolo bit della connessione viene trasmesso senza alcuna contromisura rispetto a possibili intercettazioni, ed è sufficiente un notebook con un software di sniffing (qui non farò nomi) per catturare a livello fisico il traffico di chiunque sia connesso a quella specifica rete wireless. Qualunque sito, email, conversazione IM che non utilizzi protocolli sicuri (SSL, TLS, eccetera) può essere facilmente intercettata.
Come rimediare?
Una soluzione, decisamente molto semplice ma sostanzialmente efficace, è quella del tunneling SSH. Basta avere a disposizione un qualsiasi computer, da qualche parte nel mondo, che permette l’accesso SSH da remoto, e che sia connesso ad Internet attraverso una connessione ritenuta “affidabile” (o perlomeno più affidabile di quella wireless). Questo “server” può essere il vostro server di hosting, ma anche un qualsiasi serverino Linux che potete tranquillamente installarvi a casa riciclando un vecchio computer che per gli standard Microsoftiani sarebbe da buttare.
L’SSH tunneling non è altro che una specifica applicazione dell’SSH, ovvero di un protocollo nato oramai qualche anno fa per sostituire il Telnet, ed utilizzato in principio per connettersi a terminali remoti utilizzando la riga di comando. SSH in realtà permette molto più di questo, ed è sostanzialmente un protocollo di rete per il trasferimento di dati in modalità criptata che garantisce sia confidenzialità che integrità.
Il tunneling SSH consiste in un vero e proprio tunnel a livello applicativo, che può essere utilizzato per redirigere su di esso tutto il traffico della macchina, inoltrandolo in maniera criptata dal nostro laptop su connessione wireless insicura fino al nostro server SSH (il serverino casalingo), per poi da qui girarlo allo specifico host su internet (il sito che vogliamo visitare, il server mail, eccetera).
Come realizzare un tunnel SSH?
In realtà instaurare un tunnel SSH è molto più facile che spiegarne il funzionamento. Se avete un Mac o Linux basta un comando da shell per attivare un tunnell SSH verso una destinazione remota.
ssh -D 8080 -f -C -q -N nomeutente@serverssh
Se invece come me avete pochissima memoria per i comandi da shell, esistono alcune applicazioni gratuite, tra le quali spicca, se avete un Mac, iSSH. Una volta installato questo software, vi si presenterà la seguente finestra, che dovete compilare con il nome del vostro server SSH, l’username e la password, facendo attenzione a selezionare l’opzione SOCKS Proxy, porta 8080.
Ora, una volta cliccato su “Connect”, potete minimizzare la finestra e, attraverso il pannello delle preferenze di rete di Mac, andare ad attivare il “Proxy SOCKS”, che redirige il traffico sulla macchina locale alla porta 8080, sulla quale è in ascolto il nostro tunnel SSH. In pratica dovrete impostare le preferenze di Airport nel modo seguente.
A questo punto, potete tranquillamente navigare sul web, e il vostro traffico verrà criptato e rediretto alla macchina di vostra fiducia attraverso un tunnel sicuro via Internet, per poi da qui essere immesso sulla Internet “pubblica”.
Considerazioni
Questa tecnica risente fortemente dei “colli di bottiglia“: è ad esempio limitata dalla banda di upload del vostro server SSH. Se esso è un server Linux casalingo collegato ad una ADSL, la velocità teorica di picco che potrete raggiungere sarà di 384 kbps. E’ pertanto consigliabile, per ottenere velocità discrete, utilizzare un server SSH che gode di una elevata disponibilità di banda in upload.
Per darvi un esempio della navigazione attraverso un tunnel SSH, ecco due screenshot relativi all’IP con cui si viene “visti” da internet. Il primo è relativo alla mia connessione casalinga, dall’ADSL di Tiscali. Il secondo fa riferimento al mio IP quando è attivo il tunnel SSH, attivato tra il mio Macbook e il server su cui gira il blog.
In ogni caso è da tenere presente che il tunnel SSH va sempre abilitato dopo essersi collegati al captive portal e dopo aver effettuato l’autenticazione. In caso contrario, non riuscirete nè ad attivare il tunnel, nè ad effettuare la connessione SSH. Inoltre, è da considerare il fatto che il tunnelling SSH agisce a livello applicativo, pertanto qualsiasi servizio che non si immetta sullo stack protocollare a livello applicativo non godrà della protezione offerta da SSH (per fare un esempio banale, ping e traceroute). In questi casi, infatti, si rende necessario l’utilizzo di tecniche di livello più basso nello stack protocollare, come, ad esempio una VPN criptata.
Infine bisogna evidenziare che questa soluzione non è sempre attuabile: in molti casi le reti wireless pubbliche permettono solo alcune tipologie di traffico, e le connessioni SSH, come quelle VPN, sono bloccate intenzionalmente dai router di chi vi fornisce l’accesso wireless.
E voi? Quali contromisure prendete per salvaguardare la vostra connessione attraverso le reti WiFi pubbliche?
{ 5 comments… read them below or add one }
Il caro vecchio ssh tunneling è la miglior cosa per proteggersi e per poter utilizzare anche protocolli diversi dall’http (tramite un redirect di tutto il traffico sulla porta 80 e via dicendo).
Sinceramente non avevo mai provato il server di Dreamhost per il tunneling ma avevo un account via shell gratuito su un server Linux che utilizzo appositamente per questo genere di operazione. Prossimamente lo proverò.
@ Davide: io con Dreamhost l’ho provato solo per qualche minuto, per fare qualche test e un paio di screenshot per questo post. La mia sensazione è che ciò non sia previsto dal contratto, e in attesa di avere un po’ di tempo per spulciarmi nello specifico le clausole, ho deciso di evitare di utilizzarlo per il tunnelling SSH.
In ogni caso anche io in passato l’ho sempre usato con il mio serverino Linux :)
Molto molto interessante. Come hai fatto con DH? Ti sarei grato se mi volessi fornire qualche dettaglio in più. Io ho un piano di hosting condiviso. Tu cosa hai?
Ciao! Scusa se irrompo in questo post. Cerco da qualche giorno – senza successo – informazioni sulle reti wifi pubbliche, in particolare le connessioni di solito bloccate, come quelle cui alludi sopra. Alcuni programmi non mi si connettono più da quando mi collego alla wifi universitaria, ergo credo ci siano porte chiuse o comunque un proxy, un qualche filtro che neghi alcuni servizi. Puoi darmi qualche informazione precisa al riguardo per favore?
Con Dreamhost basta semplicemente inserire i dati del proprio account dreamhost, come se ci si collegasse normalmente con SSH. I dati dovrebbero essere gli stessi che usi per l’FTP, se non ricordo male.
Come server usi il nome del server FTP .
{ 1 trackback }