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.
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 http://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/
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:
- 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”
openvpn_configfile=”/usr/local/etc/openvpn/openvpn.conf”
fatto questo, alla partenza della macchina il demone verra’ alzato.
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
si tratta di una chiave privata, una chiave per la certification authority, un certificato per il server, e una chiave Diffie Hellman.
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
le chiavi cosi’ prodotte ovviamente scadranno tra un anno.
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 porta 1194 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:
local 192.168.1.54
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
abbiamo 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.
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 9×10^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
serve a portare alcune rotte sul vostro android. La prima regola dice ad android che per ogni destinazione nella vostra rete dal lato esterno, deve passare per la VPN. La seconda dice che da quel momento, per accedere alla rete privata, deve passare per la VPN.
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
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
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)
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.
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 443
poi 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:network
che 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.
http://www.openbsd.org/4.5_packages/i386/trafshow-3.1.tgz-long.html
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.
