Siccome stanno arrivando due nuove Grandi Paure, ovvero IS e Ebola , e quindi i governi con aspirazioni fasciste, come gli USA, ne approfitteranno di certo (noto anche una certa attenzione dei governi europei) , ho deciso di postare una breve guida per collegare il proprio cellulare Android a una openvpn che terrete a casa. Insomma, l' unico cloud di cui fidarvi e' il vostro cloud.
Quando vorrete usare i servizi google, tipo play, non dovrete fare altro che spegnere la VPN e navigare normalmente. In questo modo, quando siete in VPN non vi si raggiunge da internet, quando siete su internet non si raggiunge la rete di casa dal vostro cellulare.
La prima cosa da tener presente e' che quanto sto per scrivere richiede l'uso di un *BSD, ovvero di un sistema nel quale funzioni PF, Packet Filter, un firewall piuttosto potente e piuttosto ben scritto.
Le istruzioni che vi posto richiedono di leggere un minimo di documentazione. Se non riuscite a leggerla, NON dovreste provarci.Richiedono anche l'uso di un ddns server, come www.no-ip.org .
Attenzione, pero': usando le stesse chiavi e certificati da entrambi i lati, teoricamente uno spyware che vi ciuffi le chiavi e i certificati dal cellulare puo' compromettere definitivamente la cosa: chiunque potrebbe simulare il vostro server. Quindi, usatela come primo passo in openvpn, per avere una configurazione funzionante da implementare.
Personalmente vi consiglio OpenBSD, ma anche FreeBSD va bene.
Una volta installati e configurati:
- Per FreeBSD: https://www.freebsd.org/doc/handbook/firewalls-pf.html
- Per OpenBSD: http://www.openbsd.org/faq/pf/
dovrete installare sul vostro cellulare android un client per OpenVPN. Personalmente uso https://play.google.com/store/apps/details?id=it.colucciweb.free.openvpn , che non richiede diritti di ROOT e che vi stampa le tavole di routing , in modo da rendere piu' semplice capire che cosa non vada nella vostra rete.
Supponiamo per ipotesi che abbiate due interfacce, una che da' sulla rete pubblica e una che da' verso la vostra rete privata. Diciamo em0 e em1.
La rete che volete raggiungere sta dentro alla rete privata, che e' nattata verso la rete pubblica, ovvero il server ove mettiamo OpenVPN e' il default router della rete privata. E' fondamentale per via del routing.
la prima cosa da capire e' che quando avrete la vostra VPN (del tipo che vi sto raccontando) , avrete:
Allora, dopo aver installato OpenVPN sulla macchina che avete, immaginiamo che la sua directory di configurazione "naturale" sia /usr/local/etc/openvpn , e che il file di configurazione di atteso da OpenVPN sia chiamato openvpn.conf
Configurerete quindi lo script di startup
Adesso vediamo: esistono diversi tipi di criptazione e di meccanismi di autenticazione. Quello che espongo qui e' molto semplice, e si basa sul fatto che sia sul vostro cellulare che sul server ci siano gli stessi certificati.
Sono possibili altre configurazioni, ma se state iniziando , per prendere confidenza, potete iniziare cosi'. Chiaramente, potrete anche creare una directory "client" e creare i medesimi certificati per i client, e poi configurare ulteriormente OpenVPN. In ogni caso, gia' a questo punto ci avrete preso confidenza, per cui poi potrete svilupparvi da voi.
Creerete quindi una directory dentro /usr/local/etc/openvpn ,che chiamerete cert, e ci metterete dentro alcuni certificati, che dovremo creare.
Allora, dobbiamo creare quattro files:
Quindi , da dentro la directory certs:
La rete che volete raggiungere sta dentro alla rete privata, che e' nattata verso la rete pubblica, ovvero il server ove mettiamo OpenVPN e' il default router della rete privata. E' fondamentale per via del routing.
la prima cosa da capire e' che quando avrete la vostra VPN (del tipo che vi sto raccontando) , avrete:
- Una nuova sottorete, che deve essere diversa da quella esistente.
- Una nuova interfaccia di rete, che sara' una tun0 , come configuriamo.
Allora, dopo aver installato OpenVPN sulla macchina che avete, immaginiamo che la sua directory di configurazione "naturale" sia /usr/local/etc/openvpn , e che il file di configurazione di atteso da OpenVPN sia chiamato openvpn.conf
Configurerete quindi lo script di startup
- http://www.openbsd.org/cgi-bin/man.cgi?query=rc.conf.local&sektion=8
- https://www.freebsd.org/cgi/man.cgi?rc.conf%285%29
openvpn_enable="YES"fatto questo, alla partenza della macchina il demone verra' alzato.
openvpn_configfile="/usr/local/etc/openvpn/openvpn.conf"
Adesso vediamo: esistono diversi tipi di criptazione e di meccanismi di autenticazione. Quello che espongo qui e' molto semplice, e si basa sul fatto che sia sul vostro cellulare che sul server ci siano gli stessi certificati.
Sono possibili altre configurazioni, ma se state iniziando , per prendere confidenza, potete iniziare cosi'. Chiaramente, potrete anche creare una directory "client" e creare i medesimi certificati per i client, e poi configurare ulteriormente OpenVPN. In ogni caso, gia' a questo punto ci avrete preso confidenza, per cui poi potrete svilupparvi da voi.
Creerete quindi una directory dentro /usr/local/etc/openvpn ,che chiamerete cert, e ci metterete dentro alcuni certificati, che dovremo creare.
Allora, dobbiamo creare quattro files:
- ca certs/cacert.pem
- cert certs/cert.pem
- key certs/key.pem
- dh certs/dh.pem
Quindi , da dentro la directory certs:
- openssl genrsa -des3 -out key.pem 2048
- openssl req -new -x509 -key key.pem -out cacert.pem -days 365
- openssl req -new -key key.pem -out server.csr
- openssl x509 -req -days 365 -in server.csr -signkey key.pem -out cert.pem
- openssl dhparam -out dh.pem 2048
Adesso diamo un nome alle reti.
Diciamo che la rete privata fa 192.168.172.0/24 , e che la rete "pubblica", (diciamo che il vostro router gira al server la porta1194 443) sia 192.168.1.0/24 .
Detto questo, diciamo che il vostro server sia su una 192.168.1.54 . In quel caso, avrete una configurazione come questa:
Diciamo che la rete privata fa 192.168.172.0/24 , e che la rete "pubblica", (diciamo che il vostro router gira al server la porta
Detto questo, diciamo che il vostro server sia su una 192.168.1.54 . In quel caso, avrete una configurazione come questa:
local 192.168.1.54abbiamo diversa carne al fuoco. Ovviamente la prima riga dice quale sia l'interfaccia ove bindarsi in attesa. Segue la porta di ascolto, che ho settato come 443. La ragione e' che i firewall vi lascieranno passare. Certo, sarebbe riservata ad altri protocolli, ma d'altro canto la costituzione vieta di intercettarmi senza ragione. Anche io posso rompere le regole , darling.
port 443
proto tcp
dev tun0
ca certs/cacert.pem
cert certs/cert.pem
key certs/key.pem
dh certs/dh.pem
cipher AES-256-CBC
client-to-client
push "route 192.168.1.0 255.255.255.0"
push "route 192.168.172.0 255.255.255.0"
push "redirect-gateway"
comp-lzo
server 192.168.3.128 255.255.255.128
duplicate-cn
keepalive 10 120
max-clients 10
user nobody
group nobody
persist-key
persist-tun
log /var/log/openvpn-server.log
status /var/log/openvpn-server-status.log
verb 3
mute 20
Uso il protocollo TCP perche' voglio fingere di essere una connessione su https, in modo che i firewall mi lascino passare, e perche' dalla mia rete interna NON vanno pacchetti UDP verso internet. Se non avete gia' vietato questa possibilita' fatelo ora. Permetteteli solo verso il DNS, unico servizio che ne ha bisogno, e solo verso il DNS di fiducia. Il resto deve morire.
Dev tun0 sceglie la finta interfaccia di rete che andremo ad usare.
Seguono le chiavi ed i certificati che abbiamo creato.
Poi c'e' la scelta di un metodo di encryption per le prime fasi della negoziazione. AES-256-CBC e' abbastanza robusto , anche se alcuni attacchi per 8 e 9 passaggi 9x10^29 FLOP . Ritengo che spendere questo potere di calcolo per migliaia di persone sia tutt'ora fuori dai limiti della maggior parte degli spioni, nel 2014.
Poi specifichiamo che stiamo lavorando client-to-client, in modo da avere la modalita' di cui parlavo sopra, e
- push "route 192.168.1.0 255.255.255.0"
push "route 192.168.172.0 255.255.255.0"
push "redirect-gateway"
comp-lzo
server 192.168.3.128 255.255.255.128
La terza e' ridondante, ma dice che OGNI pacchetto debba passare per la vpn, da quel momento.LA metto perche' poi, sulla app per android , potrete verificare le tabelle di routing.
La parte con "server" dice che l'interfaccia tun0 occupera' un indirizzo disponibile a partire da 192.168.3.128 sino a 192.168.3.255 , e ogni cellulare che si connette avra' un numero successivo.
Adesso andate sul client android. La cosa che noterete subito e' che alla voce "remote server" permette piu' di un server. Cosi' potrete scrivere li' dentro SIA l' IP che il vostro server VPN ha dentro la wifi (quando siete in casa) che l'hostname dinamico che avete configurato da fuori (es: casamia.no-ip.org)
In questo modo la connessione potra' essere fatta identicamente quando siete in WIFI e quando siete fuori.
Quando andate in "Authentication", scegliete "Certificates (TLS)" . A quel punto dovrete aver messo sul vostro cellulare le chiavi che avete generato prima. Tutte tranne il dh.pem
A quel punto, caricate cacert.pem alla voce "Certification Authority", cert.pem alla voce Certificate, la chiave privata alla voce "Private Key.
Sotto c'e'"save private key password" e ci metterete la password per sbloccare la chiave privata.
Fatto questo, dovrete aprire il firewall di Open/FreeBSD e decidere cosa fare dei pacchetti. Io personalmente NON voglio che i pacchetti , arrivati a casa mia, escano da li' verso internet: quando sono in VPN, non devo essere su internet, perche' sto leggendo la mia posta, sincronizzando i miei file, whatever.
Normalmente sto collegato alla VPN H24, tranne quando mi serve usare google play. La posta aziendale viene scaricata da un fetchmail sul server di casa, come tutte le altre. Ma queste sono scelte vostre.
Allora, la prima parte importante di PF sara' come questa, ottimizzazioni a parte:
ext_if="em1"
int_if="em0"
vpn_if="tun0"
localnet = $int_if:network
homenet = $ext_if:network
vpnnet= $vpn_if:network
la parte in rosso e' quella che natta i pacchetti che arrivano dalla rete locale verso la rete che va verso internet. Quelle prima sono ottimizzazioni dello stack, potete usarle o meno. Bisogna capire che , vista la sintassi ESPLICITA di PF, con la parte in rosso state girando verso l'esterno SOLO i pachetti che arrivano da localnet , e NON quelli che potrebbero passare per l'interfaccia esterna.
icmp_types = "echoreq"
set loginterface $ext_if
set optimization aggressive
set timeout { tcp.closing 10, tcp.established 120, interval 2, tcp.tsdiff 5, tcp.first 5, tcp.closed 5, tcp.finwait 5}
set limit { states 512, src-nodes 512 }
scrub in all
nat on $ext_if from $localnet to !$ext_if -> ($ext_if)
Quindi, siccome i vostri pacchetti NON vengono da "localnet" ma da "vpnnet", non passeranno. Se anche passassero, del resto, il destinatario non saprebbe che farsene perche' non sa come raggiungere la rete "vpnnet".
Se volete ANCHE nattare la rete vpn, chiaramente dovrete aggiungere una seconda riga, come:
nat on $ext_if from $vpnnet to !$ext_if -> ($ext_if)ma da quel momento le applicazioni del vostro cellulare inizieranno a vedere internet. Non ha senso farlo, IMHO. Se volete che quando siete dentro la VPN allora siete SOLO dentro la VPN, NON aggiungete la riga blu.
A questo punto, dovrete far passare i pacchetti per la vostra openvpn:
pass proto tcp from any to $ext_if port 443poi dovremo evitare che eventuali pacchetti IP vadano verso internet, udp o tcp che siano. Alla prima regola:
block inet proto {udp} from $int_if:network to !$ext_if:networkche era gia' presente (1), aggiungete:
block inet proto {udp,udp} from $vpn_if:network to !$ext_if:network
adesso siete in una rete ove i vostri pacchetti appaiono sull'interfaccia tun0 con un indirizzo che inizia per 192.168.3.<qualcosa> , e:
- Se sono diretti alla rete interna (ove avete il mailserver, il repository dei files, etc) ci possono andare perche' il server VPN ha l'interfaccia di rete in quella rete, quindi li sa girare. A sua volta, siccome quei server usano il sistema ove gira la VPN come default router, sanno come inoltrare le risposte.
- Se il pacchetto e' diretto verso internet, viene bloccato, anche nel caso la macchina ove gira il servr VPN avesse una rotta di default verso il vostro router xDSL.
in questo modo, quando il vostro cellulare e' collegato alla VPN, e' CHIUSO dentro la vostra vpn di casa.
Se volete controllare cosa stia cercando di fare il vostro cellulare, in tempo reale, potete semplicemente installare trafshow sul computer ove gira openvpn, e vedrete coi vostri occhi, interfaccia per intercfaccia, chi cerca di fare cosa.
http://www.openbsd.org/4.5_packages/i386/trafshow-3.1.tgz-long.html
Questa e' ovviamente una configurazione semplice, se non avete mai configurato openvpn e non siete in grado di debuggarlo. Presa familiarita', DOVRETE aggiungere una directory "clients", e iniziare a giocare coi certificati costruiti ad hoc per i client.
Attenzione, pero': usando le stesse chiavi e certificati da entrambi i lati, teoricamente uno spyware che vi ciuffi le chiavi e i certificati dal cellulare puo' compromettere definitivamente la cosa: chiunque potrebbe simulare il vostro server. Quindi, usatela come primo passo in openvpn, per avere una configurazione funzionante da implementare.
Questa configurazione, cioe', oltre che per impratichirvi, vi serve a poter sniffare il traffico del vostro cellulare quando il cellulare crede di essere collegato via UMTS/HSDPA/LTE.
Da quel momento, cioe', avrete messo un VOSTRO firewall tra il cellulare ed internet. Potete anche nattare la rete vpn verso internet, per dire, e magari bloccare le CDN e/o Facebook , akamai, o chi vi pare. Una volta che voi gestite il traffico, potete decidere VOI cosa faccia il vostro cellulare quando e' su internet.
Insomma, usando questa configurazione NON siete al sicuro, ma potete esaminare, visto che vi siete messi in mezzo, il traffico che il vostro cellulare EFFETTIVAMENTE genera.
Al prossimo post, vediamo come configurare certificati e chiave per il client in modo da non dover duplicare quelli del server.
Insomma, usando questa configurazione NON siete al sicuro, ma potete esaminare, visto che vi siete messi in mezzo, il traffico che il vostro cellulare EFFETTIVAMENTE genera.
Al prossimo post, vediamo come configurare certificati e chiave per il client in modo da non dover duplicare quelli del server.