Breve guida per rinforzare la sicurezza della Vostra Rete Informatica Virtuale (VPN) utilizzando Software Open Source, gratuito e modificabile a piacimento.
Ambiente Server: Linux Ubuntu Server 22.04; OpenVPN 2.5.5; OpenSSL 3.0.2.
Ambiente Client: Windows 10; OpenVPN GUI 11.15.0.0
Accessi Remoti all’epoca dello Smart Working
Il lavoro da remoto e il c.d. smart working, sono stati i protagonisti degli ultimi 3 anni.
Quasi chiunque, attività lvorativa permettendo, ha provato l’ebrezza di svolgere sessioni di lavoro recluso all’interno delle mura domestiche.
Purtroppo questo, spesso, ha comportato l’uso di strumenti poco ortodossi per accedere alle risorse digitali archiviate all’interno dei Server aziendali.
Nel migliore dei casi l’Utente, provvisto di chiavetta USB, ha copiato i file di propria pertinenza per lavorarci da Casa.
In altre occasioni, la sovrabbondanza di Software di controllo remoto (a base VNC e similari, che non cito per copyright), ha fatto tenere accesi computer per settimane in attesa del collegamento da remoto. Collegamento che, nella maggior parte dei casi, avveniva tramite computer Portatili con schermi così piccoli da consumarsi la vista a leggere cosa ci fosse scritto sul computer remoto. Tranne poi ricevere un messaggio derrore e la disconnessione perchè “si sta facendo un uso professionale del Software”. E credo che questo l’abbiamo provato tutti.
La VPN (Virtual Private Network), nella sua accezione tradizionale, è un’ottima alternativa. Consente di accedere alla rete LAN Aziendale (Interna) da qualsiasi parte del mondo, purchè connessa alla rete Internet.
Questo, naturalmente, solleva questioni di sicurezza. Prima fra tutte: Ma se si “apre” un accesso da tutto il mondo, non capita poi che tutto il mondo possa accedervi?
Questo è il problema: una porta affacciata al mondo esterno deve avere una chiave sicura per poter essere aperta. La semplice combinazione “username + password” , in questo caso, non possono essere considerate una chiave sicura. Soprattutto oggi che, con sistemi che utilizzano la AI (o IA, Intelligenza Artificiale) gli attacchi di ‘Brute Force’ sono diventati più aggressivi.
Perciò stanno prendendo sempre più piede i MFA (Multi Factor Authentication) o fattori multipli di autenticazione. Ossia Username + Password + qualcos’altro che so solo io. Per la precisione gli MFA si compingono, per definizione, di qualcosa che sai = Username + Password assieme a qualcosa che hai = un oggetto posseduto da chi è titolato ad accedere. Something You Know + Something You Have.
Tornando alle VPN, fino ad oggi, il massimo cui si pteva ambire era una combinazione tra Username + Password + Certificato rilasciato dal Server che autentica la connessione. Il sistema rispetta di fatto il Principio di SYK + SYH, ma, in caso di furto del computer portatile, (perchè quasi tutti installano le VPN sui PC portatili, e questi sono frequente oggetto di furto), il ladro si trova ad avere entrambi.
Google Authenticator
Google Authenticator viene incontro a queste esigenze di sicurezza offrendo chiavi e toppe a prova di “scassinatore”.
In questo caso Google Authenticator diventa “Something You Have Elsewhere” ovvero qualcosa che si ha, ma da un’altra parte, tipicamente sul telefonino.
Si tratta, in sostanza di una APP di google che, tramite un codice, si collega ad un sistema di autenticazione e ogni 30 secondi rilascia una OTP (One Time Password), sincronizzata con il Server.
Questa è un’aggiunta preziosa per rendere inviolabile la propria porta d’accesso alla Rete Aziendale.
Ovviamente questo non significa che la Rete Aziendale sia del tutto inviolabile; i mostri sacri dell’Informatica insegnano che qualsiasi sistema esposto alla Rete è potenzialmente violabile, ma passando da porte sul retro, o finestre, perchè il portone principale è blindato.
Configurazioni lato Server
Iniziamo a vedere le configurazioni minime indispensabili lato Server.
come da premessa per la costruzione del Server ci siamo avvalsi di Ubuntu Server 22.04 in versione “minimal” per minimizzare le risorse HW sfruttate.
Al termine dell’installazione, accedendo da remoto tramite ssh con un qualsiasi client ssh (Per la cronaca Windows, nelle versioni più recenti, ha incluso ‘ssh’ tra i suoi strumenti da riga di comando. Le opzioni sono le stesse di Linux), eseguire le seguenti operazioni
Omettiamo volutamente il ‘sudo’ ma questo è da aggiungere se le operazioni vengono lanciate da utente non ‘root’.
apt upgrade
apt update
apt install easy-rsa
apt install openvpn
apt install libpam-google-authenticator
apt install libqrencode3
apt install build-essential
Tutto ciò per avere tutti i software necessari installati.
Per le informazioni su come configurare, avviare e mettere in avvio automatico il Server OpenVPN rimando alle tonnellate di Tutorial presenti in Rete, anche se suggerisco sempre di prendere ad esempio quanto indicato sul Sito ufficiale di OpenVPN, tenendo conto che ci si riferisce alla verione “Community Edition”.
Personalmente preferiamo creare una cartella sotto /etc/openvpn all’interno della quale mettere certificati Server creati da easy-rsa, la cartella easy-rsa stessa e la configurazione server (server.conf)
Ad uso promemoria ricordiamo che Ubuntu Server, come CentOS e altri, ormai utilizzano ‘systemctl’ per avviare, riavviare, stoppare, abilitare e disabilitare servizi, e che, nel caso di ‘openvpn’ il comando è:
systemctl [start] [restart] [stop] [enable] [disable] openvpn-server@server [o il nome che è stato dato al file di configurazione *.conf]
Una volta avviata la VPN, andare a modificare il file ‘server.conf aggiungendo le seguenti righe:
# enable multi-factor authentication with google authenticator
reneg-sec 0
plugin /usr/lib/openvpn/openvpn-plugin-auth-pam.so "openvpn login USERNAME password PASSWORD 'verification code' OTP"
verify-client-cert none
username-as-common-name
*Da notare che per evitare equivoci abbiamo inserito il path assoluto di ‘openvpn-plugin-auth-pam.so’
Questo significa che stiamo imponendo a OpenVPN di richiamare il modulo PAM. a questo punto, quindi, bisognerà dire a PAM di utilizzare il modulo Google Authenticator.
cat >> /etc/pam.d/openvpn << EOM auth optional pam_faildelay.so delay=3000000 auth [success=1 default=ignore] pam_unix.so nullok_secure auth requisite pam_deny.so auth required pam_permit.so auth required pam_google_authenticator.so nullok EOM
Così abbiamo generato un file ‘openvpn’ all’interno di /etc/pam.d/ con tutte le info necessarie ad avviare Google Authenticator.
In base a come vengono generati i codici di Google Authenticator potrebbe essere necessario aggiungere alcune informazioni al file /etc/pam.d/openvpn; ad esempio nell’ultima riga:
auth required /usr/lib/x86_64-linux-gnu/security/pam_google_authenticator.so secret=/home/${USER}/.google_authenticator user=root nullok
Dove abbiamo ribadito il path assoluto del modulo google_authenticator ed abbiamo insegnato dove andare a trovare la corrispondente chiave di google, ossia all’interno della home dell’utente.
L’opzione nullok alla fine della riga significa che se ancora non è stato creato un qrcode per l’utente, questo accede ugualmente.
Per motivi di sicurezza, alla fine della preparazione degli utenti, sarebbe opportuno rimuoverla.
Quello che manca, a questo punto, è
- Creare Utente di sistema con Password
useradd utente
- Creare e firmare il Certificato corrispondente per l’utente creato
./easyrsa gen-req utente nopass
./easyrsa sign-req client utente
- Scaricare sul telefonino l’app Google Authenticator da ‘google play’ o ‘apple store’
- Generare il codice di Google Authenticator dell’utente creato
su - utente
google-authenticator
- Inquadrare il qrcode generato da google authenticator; si creerà un OTP riservato al Server OpenVPN
- Creare il flie Client di OpenVPN, tipicamente, per Windows ‘utente.ovpn’ con le varie opzioni, che non è questo il luogo per trattare, ma rimandiamo al solito forum della Community di OpenVPN. In aggiunta ad esse le seguenti righe:
reneg-sec 0
auth-user-pass
static-challenge "Codice Google Authenticator" 1
Così, avviando la VPN verranno richiesti:
Nome Utente
Password
Codice Google Authenticator
Risposta:
Se tutto è stato correttamente configurato il Server accetterà la chiamata.
Una ultima considerazione è d’obbligo:
Perchè tutto funzioni correttamente l’ora del Server DEVE essere esatta, quindi consigliamo di sincronizzarla con qualche Server NTP.
Supplemento 1.
Nel caso in cui la VPN si aprisse anche con codici google sbagliati, o addirittura senza immettere alcun codice … niente panico semplicemente il modulo ‘pam_google_authenticator.so’ è in grado di leggere il file ‘.google_authenticator’ generato al momento della creazione dei codici da parte dell’utente. Sarà necessario copiare tale codice in una cartella leggibile. Ad esempio noi abbiamo copiato i codici google in una cartella denominata: /var/unencrypted-home/ all’interno della quale ogni utente ha la propria cartella sotto cui copiamo i rispettivi file .google_authenticator.
A questo punto /etc/pam.d/openvpn dovrà diventare:
auth optional pam_faildelay.so delay=3000000
auth [success=1 default=ignore] pam_unix.so nullok_secure
auth requisite pam_deny.so
auth required pam_permit.so
auth required pam_google_authenticator.so secret=/var/unencrypted-home/${USER}/.google_authenticator user=root nullok
L’aggiunta merita una breve spiegazione: “secret=” indica a pam_google_authentiator dove andare a cercare il file di autenticazione ‘${USER}’ per ciascun user il proprio codice; ‘user=root’ è l’utente con cui andiamo a leggere il contenuto del file; infine ‘nullok’ indica al ‘pam_google_authenticator.so’ di verificare la presenza del file .google_authenticator all’interno dalla cartella dell’utente. Nel caso non esistesse, di accettare ugualmente l’autenticazione senza il doppio fattore. Quest’ultimo punto, in particoalre, è importante per aggiungere il doppio fattore a VPN già implementata, a caldo, diciamo, concede il tempo di completare i lavori. Tuttavia, a fine lavori, per maggior sicurezza, sarebbe bene toglierlo.
Lascia un commento
Devi essere connesso per inviare un commento.