Sempre di più negli ultimi anni e mai come in questi giorni si parla di Smart Working. Una delle tecnologie necessarie per permettere questo tipo di attività è senza dubbio la VPN che insieme a pfSense costituiscono una soluzione efficace al problema.
Questa guida ha l’obiettivo di descrivere ed approfondire le differenze tra IPSec vs OpenVPN implementate mediante pfSense.
Hardware utilizzato:
Questa guida si può applicare a tutti gli hardware da noi certificati della linea firewall che potete trovare qui: https://www.miniserver.it/firewall
Ambiente software:
pfSense® 2.4.x
Prima un po’ di teoria
Una VPN (Virtual Priate Network), è un “collegamento virtuale” che permette di creare una rete privata tra due o più workstation, che non si trovano sulla stessa rete LAN.
Questo collegamento virtuale viene chiamato Tunnel.
Ma cosa si intende esattamente per sicurezza in ambito smart working?
Si intende la sicurezza del canale di comunicazione, ovvero del Tunnel.
Il Tunnel infatti viene creato attraverso la rete pubblica (Internet) e quindi dei potenziali attaccanti potrebbero “sniffare” il nostro traffico, vedere i nostri indirizzi IP delle reti interne, modificare il nostro traffico dati, ecc…
È chiaro quindi che non possiamo permettere tutto questo.
La soluzione è quindi utilizzare delle VPN sicure, che permettono di creare Tunnel che garantiscano:
- Autenticazione del client (utente remoto)
- Riservatezza della comunicazione
- Integrità dei dati trasmessi: un attaccante non può modificare i dati senza che io non me ne accorga.
- protezione da Replay e da Filtering: i dati devono essere ricevuti esattamente nell’ordine con cui vengono inviati.
Vediamo ora le tecniche più utilizzate per il “Tunneling”.
- Tunnel sicuro con IPSec
- Tunnel sicuro con SSL
pfSense e OPNSense implementano entrambe le soluzioni.
Tunnel sicuro con IPSec
IPSec è un’architettura che contiene più protocolli per garantire la sicurezza nella trasmissione a livello IP del modello OSI.
Permette in particolare di:
- creare delle VPN sicure su reti non fidate (reti pubbliche)
- fare sicurezza end-to-end
IPSec possiamo definirlo come uno strumento con una configurazione più complessa rispetto ad altri strumenti per creare VPN sicure.
Questa complessità deriva dal fatto che IPSec deve essere configurato in modo che gestisca due parti fondamentali della comunicazione:
- I protocolli che implementano lo scambio delle chiavi simmetriche per poter cifrare/decifrare i dati trasmessi/ricevuti.
- Gli algoritmi e modalità che permettono la cifratura vera e propria dei dati.
Scambio delle chiavi
Prima di definire come vengono scambiate le chiavi, è importante definire il concetto di Security Association (SA) che è alla base del funzionamento di IPsec.
Una SA possiamo definirla come un “contratto” tra i due interlocutori, nel quale vengono stabiliti i meccanismi e le chiavi da utilizzare per la comunicazione con IPsec. Il protocollo per stabilire le SA si chiama IKE (Internet Key Exchange).
IKE è composta da due fasi:
Prima fase
Creazione di una prima SA bidirezionale (SA ISAKMP), che serve per proteggere le successive SA dedicate alla comunicazione IPsec vera e propria.
Questa prima fase può essere fatta in con due modalità diverse:
- main mode: più pesante l’elaborazione, ma più sicuro.
- aggressive mode: meno pesante, ma meno sicuro.
Nell’immagine di seguito (fig.1) viene mostrata una parte di interfaccia di pfSense per la configurazione della prima fase di IPSec. Notiamo infatti che è possibile specificare il campo in cui viene descritta la modalità con cui verrà fatta questa fase (Negotiation mode).
In questa prima fase avviene l’autenticazione dei due interlocutori.
L’autenticazione può essere fatta con due modalità:
- Pre shared Key (PSK): viene usata una chiave simmetrica condivisa tra i due interlocutori. Questa modalità potrebbe risultare piuttosto insicura, in quanto non si riesce a distinguere “chi ha fatto che cosa”, ovvero non posso distinguere le due controparti. Inoltre, il fatto di avere un “segreto condiviso” tra le due controparti potrebbe portare a problemi di sicurezza.
- Firma digitale (RSA): La firma digitale si basa su cifratura asimmetrica, quindi senza l’utilizzo di una chiave condivisa, eliminando tutti gli svantaggi del “segreto condiviso” come nel caso del PSK.
Con la firma digitale possiamo anche distinguere perfettamente le due controparti.
Sempre nell’immagine precedente notiamo il campo Authentication Method dell’interfaccia di pfSense, che specifica con quale modalità verrà eseguita l’autenticazione.
La cifratura simmetrica dei dati all’interno di questa prima fase può essere fatta con diversi algoritmi; cercare di prediligere algoritmi “forti”, come ad esempio quelli della famiglia AES. Evitare DES o 3DES in un ambiente di produzione in quanto ormai obsoleti e quindi vulnerabili.
Definendo la cifratura, occorre anche definire:
- algoritmo di Hash per il calcolo del digest dei dati: sconsigliato MD5
- Diffie-Hellman (DH) group: DH è il protocollo che permette lo scambio delle chiavi simmetriche. Il group è il numero che identifica la “forza” della chiave utilizzata nel processo di scambio chiavi. Possono essere da 1 a 30, andando da un livello di sicurezza minimo (1) a massimo (30). Più utilizziamo una chiave sicura, tanto più sarà oneroso il calcolo che la genera e quindi dispendioso a livello computazionale. Un buon compromesso tra sicurezza a velocità di creazione del canale potrebbe essere 14.
Nell’immagine seguente (fig.2) vediamo come è possibile specificare queste caratteristiche di cifratura in questa prima fase per pfSense.
L’algoritmo di cifratura simmetrica viene specificato con il campo Encryption Algorithm. Nel nostro caso è stato scelto AES256-GCM, dove GCM definisce l’algoritmo a blocchi e il campo Key length è la lunghezza del blocco di dati che verrà cifrato ad ogni ciclo.
L’algoritmo di Hash viene specificato con il campo Hash, mentre il gruppo Diffie-Hellman dal campo DH Group
Seconda fase:
In questa fase vengono negoziate le SA IPsec vere e proprie.
Queste SA sono molto più rapide della precedente SA ISAKMP, in quanto non devono più preoccuparsi di tutta negoziazione preliminare svolta già dalla SA ISAKMP.
Algoritmi e modalità
Passiamo a definire come vengono cifrati i dati nella trasmissione e come vengono “imbustati” nel pacchetto IP.
IPsec mette a disposizione due protocolli, ovvero AH e ESP, ognuno dei quali garantisce diversi livelli di sicurezza, in particolare:
- AH (Autentication Header), garantisce
- integrità dei dati
- autenticazione del mittente
- no Replay
- ESP (Encapsulating Security Payload), garantisce
- integrità dei dati
- autenticazione
- no Replay
- riservatezza dei dati
Senza entrare troppo nello specifico, vediamo che AH non garantisce la riservatezza dei dati.
Questo vuol dire che i dati non verranno cifrati e quindi un potenziale attaccante potrebbe eseguire uno “sniffing” dei dati all’interno del Tunnel.
Esistono due modalità diverse per implementare la sicurezza in IPsec:
- Transport Mode
- Tunnel Mode
Transport Mode
Questa modalità prevede che IPsec sia attestato sugli host finali della comunicazione, ovvero sicurezza end-to-end.
- vantaggi
- computazionalmente leggero
- svantaggi
- gli header IP che specificano sorgente e destinazione sono sempre in chiaro
- non protegge i campi variabili nei pacchetti
- non si instaura nessun tunnel
- configurazione di IPsec direttamente sugli host finali (PC, tablet ecc…)
Tunnel Mode
A differenza della Transport Mode, in questa modalità IPsec di attesta sui gateway della rete.
- vantaggi
- protezione anche dei campi variabili nei pacchetti
- si instaura un tunnel
- svantaggi
- computazionalmente pesante
Tuttavia, ha poco senso parlare di Tunnel Mode o Transport Mode senza che venga associato anche il protocollo AH o ESP.
Per configurare queste impostazioni di pfSense, accorre aggiungere la seconda fase del protocollo Ipsec cliccando su + Add P2.
Nella figura seguente (fig.3) vediamo che attraverso il campo Mode possiamo definire la modalità di Ipsec, sceglienda tra Transport Mode e Tunnel Mode
Proseguendo nella configurazione (fig.4), arriviamo alla scelta tra AH e ESP.
Notiamo che l’interfaccia grafica cambia in base alla scelta tra AH e ESP: se si sceglie AH, si deve solamente definire l’algoritmo di Hash, attraverso la voce Hash Algorithms.
Se si sceglie ESP, oltre l’algoritmo di hash si deve indicare qualche algoritmo di cifratura si utilizzerà per garantire la riservatezza dei dati trasmessi (fig.5)
Vediamo ora due scenari di esempio.
Il primo scenario mostrerà una implementazione di IPsec in Transport Mode evidenziando cosa più o non può vedere un attaccante sulla rete pubblica, in base al protocollo utilizzato per la sicurezza (AH o ESP).
Il secondo scenario sarà analogo, ma per un’implementazione di IPsec in Tunnel Mode.
IPsec Transport Mode
Vediamo nell’immagine (fig.6) che se si utilizza il protocollo AH il traffico non è mail cifrato e quindi un attaccante può sniffare il traffico in qualsiasi punto della comunicazione. Viene garantita invece integrità, autenticazione delle parti e no replay.
Con ESP invece, vengono mostrati in chiaro solo gli IP degli host finali (PC1 e PC2) mentre tutto il resto dei dati sensibili viene cifrato. Come AH, viene garantita integrità, autenticazionone delle parti e no replay.
IPsec Tunnel Mode
In questo scenario vediamo (fig.7) che la completa cifratura del pacchetto iniziale avviene all’interno del TUNNEL IPsec, utilizzando il protocollo ESP. Usando ESP infatti, non vengono cifrati solamente gli IP di tunnel, mentre gli IP dei rispettivi host (PC1 e PC2) sono protetti da cifratura, insieme ai dati sensibili. Un attaccante che fa sniffinig sul TUNNEL vedrebbe in chiaro solamente gli IP di Tunnel.
Se utilizziamo AH, il traffico sarebbe tutto in chiaro come nel caso Transport Mode.
Da notare che la modalità Tunnel Mode concentra tutto il carico computazionale di cifratura sui gataway e non sugli host finali.
Questa è una considerazione da non sottovalutare in ambito aziendale, in quanto gli host finali non sempre possiedono la potenza di calcolo sufficiente per implementare IPsec in modo sicuro.
In ambito smart working sicuramente la modalità utilizzata è la Tunnel Mode, in cui il tunnel si attesta tra il PC remoto e il gateway aziendale. Il nome più comune per questo tipo di VPN è road-warrior, ma in termini accademici prende il nome di Secure Gateway.
Vediamo una rappresentazione nell’immagine di seguito (fig.8).
Negli ultimi anni, si è diffuso molto il concetto di BYOD, ovvero “Bring your own device”, all’interno delle aziende.
Infatti sempre più aziende permettono ai loro collaboratori di accedere alla rete aziendale da remoto, attraverso i propri dispositivi personali (Laptop, Smartphone ecc…).
Il costo da pagare è una non banale configurazione di IPsec e della necessità di avere una potenza di calcolo sufficiente sull’host remoto e sul gateway.
E’ possibile tuttavia implementare un VPN concentrator come gateway. Questo dispositivo infatti implementa IPsec con hardware dedicato alla crittografia evitando quindi di rallentare la comunicazione.
Tunnel sicuro con SSL VPN
In ambito smart working è indispensabile che un utente remoto sia, in poco tempo, in grado di accedere alla sua rete aziendale e quindi essere produttivo.
Senza dubbio l’utilizzo di una SSL VPN facile da configurare fa al caso nostro, permettendo anche in pochi minuti l’accessibilità alla rete dell’ufficio.
Una SSL VPN altro non fa che sfruttare una connessione sicura SSL creando un vero e proprio tunnel tra le parti.
Più nello specifico, quello che viene fatto è un TUNNEL a livello TCP/UDP (Layer 4), a differenza di IPsec che crea un TUNNEL (in Tunnel Mode) a livello IP (Layer 3).
Una SSL VPN garantisce:
- Autenticazione iniziale delle parti
- Autenticazione del server
- Autenticazione del client (utente remoto)
- Riservatezza dei messaggi
- Autenticazione ed integrità dei messaggi
- Protezione da Raplay
Esistono 4 approcci diversi per la SSL VPN.
1. Clientless: l’utente remoto esegue l’autenticazione per la VPN direttamente da una pagina web del browser. Una volta stabilita la connessione, si crea la VPN su canale sicuro SSL. Da notare che l’autenticazione dell’utente remoto è un semplice login, che potrebbe essere potenzialmente pericoloso. Il vantaggio è che è totalmente indipendente dal Sistema Operativo dell’utente remoto (fig.9).
2. Browser plug-in: il vendor della VPN mette a disposizione un plug-in da caricare sul browser. L’autenticazione non verrà più eseguita su una pagina web ma gestita dal plugin. Anche in questo caso è totalmente indipendente dal Sistema Operativo (fig.10).
3. Eseguibile stand alone: con questo approccio è indispensabile l’installazione di uno strumento messo a disposizione dal vendor del servizio VPN (per esempio OpenVPN). In questo caso, sarà l’applicativo installato sulla postazione dell’utente ad eseguire l’autenticazione.
Tuttavia, questa modalità prevede che si utilizzi un certificato (personale per ogni utente remoto) emesso dal gestore della VPN. Il certificato verrà poi utilizzato dall’applicativo per eseguire l’autenticazione dell’utente, il tutto “rafforzato” dal login dell’utente.
E’ chiaro dunque che in questa modalità ci deve essere fornito un certificato dall’azienda che mette a disposizione la VPN. Questo migliora di molto i livelli di sicurezza per l’autenticazione dell’utente remoto, a discapito però della gestione e distribuzione dei certificati per ogni utente (fig.11).
4. Mobile app: esistono delle app per smartphone che eseguono la stessa funzione di un’applicazione per SSL VPN installata sul PC.
Questo permette anche ad uno smartphone di collegarsi mediante SSL VPN. Anche in questo caso si necessita di un certificato per ogni utente remoto (fig.12).
Mettiamo a confronto queste quattro modalità fornendo utili spunti per la configurazione.
In particolare, i primi due metodi (Clientless e Browser plug-in) non richiedono un’autenticazione dell’utente remoto attraverso un certificato. Occorre quindi solamente decidere quali algoritmi di cifratura settare sul gateway che implementa SSL VPN.
Evitiamo l’utilizzo di algoritmi di cifratura deboli come DES o 3DES e tutti gli algoritmi a blocco associati (CBC, CFB ecc…).
Un algoritmo comunemente utilizzato per la cifratura è BF-CBC oppure AES CBC che offrono un buon compromesso tra sicurezza e velocità.
Le ultime due tipologie (Eseguibile Stand alone e Mobile app) possono richiedere l’installazione di un certificato sul dispositivo utilizzato dall’utente remoto oltre al solito login con username e password. Questo aumenta di molto di sicurezza della VPN.
Da notare che quel certificato può essere ri-utilizzato su più dispositivi di uno stesso utente; questo è un grosso beneficio per la scalabilità del servizio (non mi devo preoccupare di creare un certificato per ogni device), a discapito però della sicurezza (potrei passare il certificato e credenziali di accesso ad un utente sconosciuto, oppure un utente malevolo se ne potrebbe impossessare).
OpenVPN è una delle tecnologie per le SSL VPN più utilizzate, in quanto offre prestazioni e sicurezza elevati, accompagnati però da una facilità di implementazione (sia per l’utente remoto sia per l’amministratore di rete).
Quale scegliere?
Una differenza che potrebbe essere determinate sulla scelta di una VPN rispetto ad un’altra è la granularità con cui posso gestire gli accessi alla rete.
Dato che il protocollo IPsec opera a livello IP (Layer 3 OSI), una VPN IPsec darebbe pieno accesso alla rete aziendale indipendentemente dall’applicazione che l’utente remoto utilizza.
Mentre con l’utilizzo di SSL VPN che opera a livello TCP/UPD (Layer 4 OSI), è possibile introdurre delle limitazioni.
In generale, si tende a prediligere IPsec per VPN site-to-site, mentre per la VPN di accesso (road warrior) si predilige la SSL VPN per una maggiore facilità di implementazione rispetto ad IPsec.
In conclusione quindi, entrambe le soluzioni SSL VPN che IPsec solo molto performanti dal punto di vista della velocità di trasmissione a parità di hardware utilizzato.
È compito dell’amministratore di rete decidere qual è il compromesso migliore che le due tecnologie possono offrire in base alle informazioni ed alle esigenze della propria infrastruttura di rete.
Nello scenario smart working è indispensabile avere un sistema VPN che permetta in modo agevole di accedere alla rete aziendale, senza perdere tempo in complicate configurazioni da parte dell’utente, garantendo sempre la sicurezza.
Statisticamente, OpenVPN è la soluzione che rappresenta il miglior compromesso.
