English (UK)Morbegno, ore 04:12. Mi giro e mi rigiro nel comodo letto di casa mia, ma proprio non riesco a prendere sonno. Eppure è la notte ideale per fare un bel sonno ristoratore, né troppo caldo, né troppo freddo, ma proprio non riesco a dormire. Non so se sia colpa dei peperoni o del tarlo che mi rode la mente. Mi sa che forse è meglio che mi alzi e affronti quel tarlo chiamato VPN. Questa volta l’argomento è un po’ più serio. Vorrei affrontare il tema della sicurezza. Sì la sicurezza, se stessi lavorando ad una VPN aziendale, ma visto che la mia è una VPN domestica… lo ammetto, voglio solo placare la mia paranoia, altro che peperoni o tarlo della VPN. L’idea che mi ronza in testa da qualche settimana, è quella di creare una VPN basata su infrastruttura a chiave pubblica (PKI - public key infrastructure).
Ma partiamo dall’inizio. La VPN di partenza è la fantastica VPN di tipo client-to-gateway basata su chiave statica che vi ho raccontato il mese scorso, quella realizzata con il Raspberry Pi. Benché sia particolarmente semplice da implementare e perfettamente funzionante, questa soluzione è generalmente utilizzata in ambito SOHO (small office home office) e non è adatta ad ambiti enterprise. Il suo limite principale è la sicurezza.
Per spiegarmi come funziona una VPN basata su PKI, ho immaginato la VPN come una festa dove il client è un invitato e il server è l’addetto alla sicurezza che deve controllare chi può entrare e chi no alla festa. Nel sistema a chiave statica, l’addetto alla sicurezza si limita a verificare che chi si presenta alla porta sia dotato di invito (chiave statica). Nel caso della infrastruttura PKI c’è una lista degli invitati, ed alla porta c’è bisogno di presentare un documento di riconoscimento.
PKI – Public key infrasctructure
Mi collego subito al server VPN via SSH per la creazione dell’infrastruttura PKI. Per lo scopo utilizzerò easy-rsa, una serie di script che semplificano la procedura di creazione dell’infrastruttura. Per prima cosa copio i file, già presenti nella installazione di openvpn, sotto la cartella /etc/openvpn/easy-rsa/
$ sudo mkdir /etc/openvpn/easy-rsa/
$ sudo cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/* /etc/openvpn/easy-rsa/$ sudo chown -R $USER /etc/openvpn/easy-rsa/
Adesso devo impostare i parametri di base dell’infrastruttura:
$ vi /etc/openvpn/easy-rsa/vars
export KEY_COUNTRY="IT"
export KEY_PROVINCE="SO"
export KEY_CITY="Morbegno"
export KEY_ORG="eshiol.it"
export KEY_EMAIL="Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo."
export KEY_OU=home
Inizio la configurazione della PKI con la creazione delle chiavi Diffie-Hellman. Queste chiavi verranno utilizzate nel Diffie-Hellman key exchange, un protocollo crittografico che consente a due entità di stabilire una chiave condivisa e segreta utilizzando un canale di comunicazione insicuro (pubblico) senza la necessità che le due parti si siano scambiate informazioni o si siano incontrate in precedenza. Lo ammetto, ho fatto il copia ed incolla da Wikipedia; si parla di logaritmi discreti e di generatore del gruppo moltiplicativo degli interi modulo p, dove p è un numero primo; roba da informatici e matematici, ma di quelli veri, non da smanettoni come me. Non ho voglia di accampare scuse, non è colpa dell’ora tarda, é che proprio non ci ho capito niente. Ma non è un problema, perché sono sicuro che la mia VPN funzionerà anche se non ho capito come funziona il protocollo Diffie-Hellman key exchange. Però una cosa l’ho imparata, so a cosa serve, o almeno lo presumo: permetterà ai due endpoint della VPN di scambiarsi i messaggi necessari alla creazione della VPN in maniera sicura. Per tornare alla nostra festa è come se il nostro addetto alla sicurezza abbia gli occhialini da baro, quelli che fanno leggere i segni sulle carte truccate. Ecco questi occhialini gli permetteranno di leggere cosa c’è scritto sulla carta d’identità senza che occhi indiscreti possano fare alterttanto.
$ cd /etc/openvpn/easy-rsa
$ source vars
$ ./clean-all
$ ./build-dh
La creazione delle chiavi DH ha impiegato qualche minuto. A questo punto dovrei creare la certification autority mediante il comando ./build-ca, ma avendo già creato una mia PKI per altri scopi mi limito a copiare la chiave privata (ca.key) e il certificato (ca.crt) della Certification Authority nella cartella /etc/openvpn/easy-rsa/keys/.
Proseguo creando il certificato del server (Raspberry Pi):
$ ./build-key-server server
Il comando genera due file, la chiave privata (server.key) ed il certificato (server.crt).
OpenVPN lato server Linux
Completata la parte di generazione di chiavi e certificati, copio i file strettamente necessari nella cartella di OpenVPN, quindi il certificato della Certification Authority, la chiave Diffie-Hellman e la coppia chiave/certificato del server:
$ cd keys
$ sudo cp ca.crt dh1024.pem server.crt server.key /etc/openvpn
Tutto sembra pronto, non mi resta che modificare il file server.conf:
$ vi /etc/openvpn/server.conf
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
comp-lzo
user nobody
group nogroup
log /var/log/openvpn
verb 3
Riavvio OpenVPN e passo al client:
$ sudo /etc/init.d/openvpn restart
OpenVPN lato client Windows
Per quanto riguarda il client, molti sconsigliano l’uso di easy-rsa per la creazione della coppia chiave/certificato, adducendo motivi di sicurezza e suggerendo di creare le chiavi sul client, per poi inviare una richiesta di certificato al server. La cosa mi affascina, e non posso che dargli ragione, ma nel caso di rete domestica, dove lo scambio delle chiavi è fatto in locale, tutta questa premura è eccessiva anche per un tipo paranoico come me. Quindi procedo alla loro creazione come fatto con quelle del server, utilizzando l’apposito commando:
$ ./build-key client1
Apro WinSCP e copio la coppia chiave/certificate del client insieme al certificato della Certification Authority (ca.crt) nella cartella C:\Programmi\OpenVPN\easy-rsa\config\home\
Adesso passo a modificare il file home.ovpn sul client, dove lan.domain.tld è il nome dns o l’ip della mia rete di casa:
remote lan.domain.tld
dev tun
ca ca.crt
cert client1.crt
key client1.key
route 192.168.0.0 255.255.255.0
comp-lzo
remote-cert-tls server
Ho riavviato OpenVPN GUI 3 volte prima di farmene una ragione. Non ne vuol sapere di partire. Nel frattempo si sono fatte le 4:34, nel cortile di fronte già sento il gallo che fa i gargarismi, pronto a dare la sveglia a tutto il circondario. Non mi resta che dare uno sguardo ai log del client:
Options error: On Windows, --ifconfig is required when --dev tun is used
Sembra che abbia dimenticato la direttiva ifconfig. In realtà devo inserire la direttiva client, per indicare a OpenVPN che deve partire come client. Perfetto, funziona tutto, la mia VPN client-to-gateway basata su PKI è operativa, in barba a Diffie e Hellman.
Ottimizzazione
Adesso passo alle ottimizzazioni. Prima di tutto faccio in modo che la route venga passata dal server aggiungendo la seguente riga al file server.conf:
push “route 192.168.0.0 255.255.255.0”
e togliendo l’omologa dal file home.ovpn. Poi c’è da prevenire eventuali attacchi DoS dicendo al server di mettersi in ascolto sulla porta 1194 utilizzando il protocollo udp, ed utilizzando TLS handshake per bloccare le macchine non autorizzate. Mi collego al server è creo la chiave pi.key
$ openvpn --genkey --secret pi.key
e modifico il file di configurazione:
proto udp
tls-auth pi.key 0
Infine copio la chiave appena creata sul client e modifico il file di configurazione aggiungendo la seguente riga:
tls-auth pi.key 1
Ma torniamo alla festa. Per evitare congestione all’ingresso, prima che l’addetto alla sicurezza controlli se sei inserito nella lista degli invitati, devi presentare l’invito. Ecco la chiave pi.key è l’invito a partecipare alla VPN.
L’ultima modifica riguarda la possibilità di ridirigere tutto il traffico del client tramite la VPN. In pratica voglio presentare il client su Internet come se fosse fisicamente nella LAN di casa. Prima di riavviare la VPN mi collego ad un sito che mi dica qual è il mio attuale ip pubblico per vedere se realmente il traffico viene incanalato tramite la VPN. Aggiungo le seguenti righe al file di configurazione del server e riavvio la VPN.
push “redirect-gateway def1”
push “dhcp-option DNS 8.8.8.8”
push “dhcp-option DNS 8.8.4.4”keep-alive 10 60
ping-timer-rem
persist-tun
persist-key
Riavvio la connessione e verifico con quale indirizzo ip vengo visto. Bene è quello della lan di casa. Anche per questa notte ho concluso. Sento di aver appagato la mia sete di curiosità, peccato che non possa dire lo stesso della mia paranoia, ma adesso è proprio ora di andare a dormire.
