venerdì 10 ottobre 2014

Cellulari Android e OpenVPN

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:

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:

  • 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



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.

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

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

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: 
  1. 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.
  2. 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.



Discussioni & Commenti (Il Salotto Buono di KEIN PFUSCH®).

Per postare nel gruppo, semplicemente cliccate sul tasto rosso a sinistra se l'argomento e' nuovo, oppure cliccate sugli argomenti per rispondere. In caso non siate iscritti il sistema vi guidera' all'accesso. In ogni caso il vostro indirizzo email non sara' pubblicato dal forum.

So che e' seccante, ma l'aumento del traffico sul sito mi obbliga ad usare un sistema piu' adatto alle mie disponibilita' di tempo, cioe' un sistema ove la quantita' di commenti da moderare NON cresca con la quantita' di traffico. Inoltre adesso gli argomenti non sono piu' legati al post, cosi' se volete iniziare un OT non c'e' problema come prima. Inizialmente i vostri messaggi verranno moderati, poi verrete sbloccati appena sara' chiaro che non siete troll. Una volta iscritti e' possibile postare sia attraverso il web (come prima) che via email (scegliendo di ricevere i messaggi via email). Quando vi iscrivete, per favore scrivete due righe di presentazione.Altrimenti non vi iscrivo.