Openvpn 2.4

AEAD (GCM)

Openvpn 2.4 è l’ultima versione del software per tunnel criptati.
Con la nuova versione molte sono le novita’:

  • IP e porta mobile
  • Negoziazione della cifratura del canale dati
  • Supporto per la crittografia del canale dati con AEAD (GCM)
  • Scambio di chiavi ECDH
  • Connette ai clients DNS Dualstack round-robin
  • Supporto per la fornitura di server DNS IPv6
  • redirect-gateway ipv6
  • Compressione e supporto LZ4
  • Http proxy password all’interno del file di configurazione
  • Token di autenticazione
  • Client di gestione portachiavi per Mac OS X.
  • Supporto per piattaforma Android
  • Supporto piattaforma AIX
  • Controllo della crittografia del canale

E’ da un po che aspetto Openvpn 2.4 .
Le precedenti versioni non supportavano propriamente il concetto di Perfect Forward Secrecy.

Il cifrario di default era AES-256-CBC in modalita’ CBC appunto.
Infatti GCM fornisce sia criptografia che controllo di integrita’, mentre CBC solo criptografia.

Per questo in modalita’ GCMnon vedrai mai crittografare due volte con lo stesso hash della stessa chiave e questo protegge dai replay attacks.

Gli sviluppatori hanno sempre preferito la retrocompatibilita’ con quante piu’ applicazioni client possibile, spesso di vecchia generazione, a discapito della sicurezza.

Openvpn 2.4 è un software che utilizzo tantissimo e il supporto per protocolli di crittografia avanzati di tipo ellittico per la crittografia è, finalmente, default.

Configurazione

Configureremo un sistema debian stretch con Openvpn 2.4 e openssl-1.0.2j.

E’ mia intenzione fornire il livello di sicurezza piu alto possibile per i dati in transito, per gli utenti e per il server stesso, iniziamo.

Innanzitutto configuriamo il forwarding sulla nostra vpnbox con qualche comando iptables e qualche modifica a etc/sysctl.conf, il file dove è possibile apportare modiche al kernel, al tcp/ip stack, alla virtual memory e quant’altro, senza riavviare la nostra vpnbox, on the fly.

Grazie ad iptables utilizzeremo il NAT che permettera’ ai clients della vpn di collegarsi alla rete pubblica.


-P FORWARD DROP
-A FORWARD -s 10.1.0.0/24 -i tun0 -o eth0 -j ACCEPT
-A FORWARD -d 10.1.0.0/24 -i eth0 -o tun0 -j ACCEPT
# nat/masquerade
-t nat -A POSTROUTING -s 10.0.1.0/24 -o eth0 -j MASQUERADE
# in etc/sysctl.conf abilitiamo il forwarding per i clients
net.ipv4.ip_forward = 1

Adesso impostiamo la porta di asolto, il protocollo, l’interfaccia di rete utilizzata, nel nostro caso tun0 e l’ip che l’interfaccia virtuale della nostra vpn utilizzera’.


port 4343
proto udp
dev tun0
server 10.1.0.0 255.255.255.0

Per il numero di porta ho scelto un valore diverso dal default 1192.

TCP o UDP ?

Tcpreset.net ai suoi clienti offre entrambi i protocolli.

A proposito di questo argomento il protocollo UDP resta quello consigliabile in termini di velovita’ proprio perchè piu’ semplice del TCP.

Il protocollo TCP garantisce la consegna dei dati implementando meccanismi di controllo e di rinvio dei dati stessi, operazione che richiede il suo tempo.

L’UDP, al contrario, invia i dati in rete e poi se ne disinteressa.

Per questo motivo è molto usato nello streaming di audio e video dove è necessaria molta velocita’ e anche nella risoluzione dei nomi di dominio con il DNS.

La direttiva Server definisce quale numerazione e classe di ip la nostra vpn utilizzera’ per sè e i clients.

La vpnbox avra’ ip 10.1.0.1 sulla sua interfaccia di rete, mentre un pool di 254 indirizzi ip sara’ a disposizione dei clients che la utilizzeranno.

Routing

Inoltre dovremmo dire ad Openvpn 2.4 il routing che avranno i clients.
Utilizzando la classe di ip privati dai quali i clients provengono, impostiamo il routing:


# Routing
client-config-dir /etc/openvpn/ccd/client1
route 192.168.1.0 255.255.255.0
# nel file etc/openvpn/ccd/client1 con iroute definiamo che classe di ip client1 fa parte.
iroute 192.168.1.0 255.255.255.0

Poi impostiamo altri parametri che riguardano vari aspetti della connessione e sono dei buoni defaults.


keepalive 10 120
compress lz4
max-clients 60
tun-mtu 1500
persist-key
persist-tun

Vi consiglio di consultare il manuale disponibile sul sito ufficiale di Openvpn per i dettagli ;).

Certificati SSL con criptografia efemerale a curve ellittiche

Adesso creeremo i certificati necessari alla nostra VPN.
Il modo piu’ facile per impostare una CA è scaricare il pacchetto easyrsa.

$ git clone https://github.com/OpenVPN/easy-rsa.git easy-rsa/.

E’ mia intenzione utilizzare EC (curve ellittiche) per i certificati SSL di questo server invece di RSA.

Utilizzero’ il massimo in quanto a sicurezza che la criptografia a curve ellittiche ha da offrire con Openvpn 2.4.
Edita il file vars in questo modo:


set_var EASYRSA "$PWD"
set_var EASYRSA_OPENSSL "/usr/local/openssl/bin/openssl"
set_var EASYRSA_PKI "$EASYRSA/pki"
set_var EASYRSA_DN org
set_var EASYRSA_REQ_COUNTRY "US"
set_var EASYRSA_REQ_PROVINCE "California"
set_var EASYRSA_REQ_CITY "San Francisco"
set_var EASYRSA_REQ_ORG "Copyleft Certificate Co"
set_var EASYRSA_REQ_EMAIL "me@example.net"
set_var EASYRSA_REQ_OU "My Organizational Unit"
# Cetificati a curve ellittiche (y)
set_var EASYRSA_ALGO ec
# definiamo quali curve ellittiche usare
set_var EASYRSA_CURVE brainpoolP512r1
# Scadenza certificati della CA
set_var EASYRSA_CA_EXPIRE 365
set_var EASYRSA_CERT_EXPIRE 365
set_var EASYRSA_CRL_DAYS 365
# Cryptographic digest to use.
set_var EASYRSA_DIGEST "sha512"

Inizializiamo la PKI.


./easyrsa init-pki

Creiamo la CA.


./easyrsa build-ca

Generiamo una richiesta di certificato ed una chiave privata per il server.

./easyrsa gen-req server somename nopass

Firma il certificato

./easyrsa sign-req somename

Creiamo il certificato per gli utenti.

./easyrsa gen-req client1

Firmiamolo,

./easyrsa sign-req client1

Sul server adesso andiamo a specificare il path per certificati e chiave privata:


ca /etc/openvpn/EasyRSA-3.0.3/pki/ca.crt
cert /etc/openvpn/EasyRSA-3.0.3/pki/issued/vpn.server.crt
key /etc/openvpn/EasyRSA-3.0.3/pki/private/vpn.server.key

Sempre sul server andiamo a definire tutti i parametri per una connessione che usa esclusivamente TLSv1.2 e cifrari AEAD(GCM) che garantiscono perfect forward secrecy.

Cifrari

Vediamo di quali cifrari Openvpn 2.4 dispone.

Abbiamo detto che vogliamo solo quelli che supportano crittografia a curve ellittiche e vogliamo solo i cifrari piu’ forti, 256bit possono bastare.

root@VPN:# openvpn --show-ciphers | grep 256-GCM
AES-256-GCM (256 bit key, 128 bit block, TLS client/server mode only)

Risulta che Openvpn 2.4 con i suddetti criteri dispone di AES-256-GCM che e’ il nuovo cifrario di default per Openvpn 2.4 e sostituisce Blowfish BF-CBC (64bit).

Aggiungiamolo al file di configurazione:

cipher AES-256-GCM

Piu’ cifrari utilizziamo piu’estesa sara’ la gamma di applicazioni clients che sara’ in grado di connettersi alla nostra vpnbox.
Se ques

to puo essere considerato un bene in realta’ ci costringe all’uso di protocolli insicuri e deboli, inoltre offre a qualche maleintenzionato una superfice maggiore da attaccare.


root@VPN ~ # openvpn --show-tls | grep 256-GCM
TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-GCM-SHA384

Vediamo che i cifrari adesso sono tre stando alle caratteristiche da noi ricercate. Con Openvpn 2.4 è stato ridotto il numero di cifrari di default in tls-cipher.

E’ molto facile che un uso incorretto dei cifrari provochi degli errori nella connessione e inoltre meno cifrari ci sono e minori saranno le possibilita’ di bersaglio durante un attacco .

Qualsiasi sia il cifrario da voi scelto, il client, nel suo file di configurazione, deve contenere i medesimi cifrari del server.
Aggiungiamo al file di configurazione i cifrari disopra mostrati,

tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-GCM-SHA384

ed anche,


ncp-ciphers AES-256-GCM
ecdh-curve brainpoolP512r1

Ncp-cipehrs è una nuova opzione in Openvpn2.4.
Sta ad indicare che è possibile negoziare il cifrario che cripta il data channel. Ma per noi non ci puo’ essere alcuna negoziazione, AES-256-GCM come unica opzione.

ecdh-curve stabilisce invece quale curva ellittica usare.

Noi useremo brainpoolP512r1 che è considerato safe dal sito safecurves.cr.yp.to.

Autenticazione

L’autenticazione al momento è gestita unicamente con il buon vecchio PAM.

E’ in fase di allestimento un sistema d’autenticazione 2FA con google-authenticator.

Sicurezza

Openvpn2.4 supporta i migliori algoritmi di sicurezza.
Ammenochè tu non abbia per qualche motivo specifico bisogno di ultilizzare SSLv3,TLSv1 o TLSv1.1, essi vanno disabilitati in quanto insicuri e va utilizzato solo il protocollo TLSv1.2 e lo facciamo con questa direttiva:


tls-version-min 1.2

Un altra novita’ per Openvpn2.4 è la direttiva tls-crypt che è un upgrade del precedente tls-auth.

Crittografando il canale di controllo viene criptato anche il certificato utilizzato nella connessione TLS.

Quindi è anche più difficile determinare che si tratta di una connessione vpn dopo un packet inspection.

In conclusione la nostra vpn sara’ in esecuzione con l’utente non privileggiato nobody.

Andiamo ad aggiungere al file di configurazione le seguenti direttive:


user nobody
group nogroup

Queste sono alcune delle direttive implementate sulla vpn da me offerta.

Per ulteriori approfondimenti vi invito a consultare il sito di riferimento vpn.tcpreset.net [WORK IN PROGRESS]

Qualora fosse vostra intenzione usufruire della vpn da me offerta, per qualsiasi chiarimento, consulenza, sia per utilizzo privato che businness, alla pagina contatti tutti i dettagli.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *