Linux VPN Infrastructure

Il Protocollo IpSec

IpSec utilizza diversi protocolli per stabilire una connessione fra i peer e criptare il traffico.
IKE (Internet Key Exchange, porta UDP 500) viene usato per negoziare una nuova connessione.
Si divide in due fasi:
- La prima fase, di autenticazione, stabilisce una SA (Security Association) fra i due peer
- La seconda fase, di scambio chiavi, usa la SA creata per negoziare una nuova SA da usare per la criptazione dei dati.
L'autenticazione si può basare su chiavi predefinite (PSK, PreShare Keys), chiavi RSA o certificati x509.
AH (Authentication header, IP type 51) e ESP (Encapsulating security payload, IP type 50) sono due diversi protocolli che possono essere usati per il trasporto dei dati nel tunnel. Possono coesistere o essere usati singolarmente, anche se si tende a preferire ESP perchè oltre a garantire autenticità e integrità dei dati, ne preserva la confidenzialità, criptandoli.

IpSec può lavorare in due diverse modalità: transport mode e tunnel mode.
Nel primo i dati sono criptati a livello di protocollo di trasporto (TCP, UDP) e lo scambio avviene direttamente fra i due peer della VPN, nel secondo è viene criptato l'intero pacchetto IP, non rivelando, al di fuori del tunnel, indirizzi IP e porte usate da sorgente e destinazione. In questa modalità si usano collegare fra loro due diverse reti, con i rispettivi client  inconsapevoli della presenza di un tunnel.

L'integrità dei dati viene garantita da algoritmi di hash come MD5 o SHA.
Per la confidenzialità si usano algoritmi di criptazione simmetrici come 3DES, AES e Blowfish.

Lavorando a livello di rete, AH o ESP possono trasportare sia traffico UDP che TCP ma hanno seri problemi quando uno dei due peer del tunnel viene nattato. Le RFC 3947 e 3948 definiscono i metodi per negoziare IKE e incapsulare ESP  in pacchetti UDP per permettere il Nat Traversal (NAT-T).

Soluzioni VPN su Linux

.

Esistono diverse soluzioni software per fare VPN con Linux usando protocolli e algoritmi diversi.

IPSEC  Stardard IETF (RFC 2401 et al.), su Linux è implementato da:
- FreeSwan, progetto ora sospeso da cui sono derivati OpenSwan (usato in varie distribuzioni) e StrongSwan. Comprende uno stack IpSec lato kernel (KLIPS) e un demone di gestione chiavi in userspace (pluto).
- nei Kernel 2.6 il supporto IpSec è nativo e può essere utilizzato uno dei demoni disponibili, in userspace, per gestire IKE (racoon derivato dal progetto KAME (Ipsec per Free/NetBSD), lo stesso pluto, o isakmpd derivato dall'implementazione IpSec in OpenBSD)

PPTP - Definito nella RFC 2637 ma non standard IETF è particolarmente comune nel mondo Windows.
Su Linux esiste il server PoPToP e un pptp client, entrambi ben interoperabili con il mondo Microsoft.
Considerato meno sicuro di IpSec.

VPN su SSL/TLS sono una alternativa valida perchè usano protocolli e algoritmi consolidati e permettono il trasporto di arbitrari pacchetti IP. L'implementazione OpenSource più evoluta di VPN SSL è OpenVPN, disponibile su Linux, altri Unix, MacOS e Windows.

Soluzioni non standard basate su protocolli legacy che possono comunque implementare algoritmi di criptazione diffusi:
Cipe con supporto per Linux e Windows.
Tinc disponibile sia su Unix vari che su Wondows.
Vtun disponibile su ambienti Unix. Development poco attivo.
Vpnd disponibile per Linux.
PPP over SSH, soluzione, descritta nel Linux VPN HOW-TO, ormai obsoleta.

OpenSwan (FreeSwan, StrongSwan) - IpSec su Linux

OpenSwan ( http://www.openswan.org/ ) è l'implementazione IpSec più diffusa sui Linux recenti. Deriva da FreeSwan ( http://www.freeswan.org/ ), la prima implementazione IpSec su Linux, progetto non più mantenuto.
Altro fork di FreeSwan è StrongSwan ( http://www.strongswan.org/ ) con interessanti feature ma meno diffuso.

Il progetto è composto da 2 componenti:
- Il modulo del kernel per il supporto IpSec (KLIPS).
- Gli strumenti in userland per autenticarsi con Ike (Pluto) e gestire il tunnel.

Tenere presente che il kernel 2.6 ha, incorporati nel ramo ufficiale, dei propri moduli per la gestione di Ipsec (chiamati 26sec o NET_KEY) che sono alternativi a KLIPS. Quest'ultimo è disponibile anche per kernel 2.0, 2.2 e 2.4 ed ha un livello di maturità maggiore.

Installazione
Per compilare da sorgenti, scrivere, nella directory scompattata:
make programs Compila i programmi in userland
make install Li installa copiandoli nelle adeguate directory
make oldmod Compila KLIPS (per kenrle precendenti il 2.6)
make minstall Installa i moduli compilati
Molte distribuzioni prevedono OpenSwan fra i pacchetti standard o in pacchetti realizzati da terze parti, per cui la soluzione più comoda è quella di usare pacchetti RPM o DEB precompilati.

Configurazione
/etc/ipsec.conf è il file di configurazione principale. Notare che questo è lo stesso nome del file di configurazione degli ipsec-tools sui kernel 2.6, che però ha un formato diverso.

Troubleshooting
ipsec verify - Verifica se le varie componenti del sistema sono regolarmente inizializzate
ipsec whack --status - Mostra lo stato corrente del sistema IPsec
ipsec barf - Visualizza a video una grande quantità di informazioni utili per il debugging e il troubleshooting in caso di problemi.

OpenVPN: VPN OpenSource basata su SSL

OpenVPN ( http://openvpn.net/ ) è un progetto interessante per realizzare VPN basate su SSL/TLS per l'autenticazione e la confidenzialità dei dati, garantendo maggiore sicurezza rispetto ai metodi di altre soluzioni VPN legacy. Esiste per Linux, Windows, MacOS e altri Unix per cui
Lavora completamente in userspace ed ha una installazione e configurazione semplici.
Viene usato UDP (porta 1194 di default) come protocollo di trasporto e può incapsulare arbitrario traffico IP, utilizza i device TUN/TAP e le relative interfacce di rete (tun0, tun1 ....).

Installazione
Esiste come pacchetto precompilato in molte distribuzioni. La compilazione dei sorgenti non presenta particolari difficoltà e non richiede la compilazione del kernel o di un modulo.
Volendo si può creare un rpm direttamente dai sorgenti con:
rpmbuild -tb openvpn-[versione].tar.gz

Configurazione
Il file di configurazione sta in /etc/openvpn/.
Nei documenti distribuiti con i sorgenti  o comunque nell'HowTo ufficiale esistono numerosi esempi di configurazione per contesti diversi.
La creazione di certificati x509 e di una certification authority propria è facilitata da alcuni appositi script.

Troubleshooting
Via syslog vengono loggati i messaggi del server e, in caso di problemi questi sono generalmente piuttosto espliciti. A livello di firewalling e networking si applicano le solite procedure:
- attivazione di adeguato logging su iptables per capire se qualcosa viene erroneamente filtrato
- verifica di routing e parametri di rete.

Vantaggi
- Cross platform, esiste per i principali sistemi operativi
- Semplice da installare e configurare, client e server si differenziano solo per la configurazione
- Utilizza robusti e consolidati algoritmi di criptazione e hashing
- Più semplice di IpSec, più sicuro di protocolli custom usati per altre soluzioni open source
- Come IpSec opera in tunnel mode e può trasportare pacchetti IP di qualsiasi natura.
- Non ha problemi con il natting
- Può usare certificate x509 per la distribuzione delle chiavi pubbliche

Svantaggi
- Lavorando in user space e usando device TUN/TAP è potenzialmente più lento di soluzioni kernel based, anche se prove reali sembrano dimostrare il contrario.
- L'overhead dei pacchetti è relativamente elevato: il pacchetto IP da trasportare viene incaspulato in SSL e a sua volta incapsulato in UDP.

PopTop - Linux PPTP Server

PopTop ( http://www.poptop.org/ ) è la soluzione opensource PPTP lato server più diffusa.

Installazione
Il pacchetto precompilato è generalmente disponibile con il nome pptpd.
I sorgetni sono scaricabili dal sito ufficiale http://www.poptop.org
Utilizza il pppd per stabilire la connessione e il modulo del kernel mppe per supportare la cifratura standard usata da client Windows.

Configurazione
/etc/pptpd.conf - E' il file di configurazione principale
/etc/ppp/options.pptp - E', di default, il file dove si configurano i parametri ppp
/etc/ppp/chap-secrets - Contiene login e password degli utenti (PopTop si può integrare anche con un radius server esterno).

Troubleshooting
Per diagnosticare problemi, sia lato client che lato server, è molto completo il documento:
http://pptpclient.sourceforge.net/howto-diagnosis.phtml
I messaggi di log sono generalmente disponibili in /var/log/messages o /var/log/syslog.

Il protocollo PPTP

PPTP (Point to Point Tunneling Protocol) è protocollo usato per VPN sviluppato da Microsoft e altri vendor, descritto nella RFC informativa 2637 ma non ancora standard IETF.

Fondamentalmente si tratta di una sessione PPP su GRE (Generic Routing Encapsulation).
Utilizza la porta TCP 1723 per l'autenticazione e lo scambio di informazioni fra client e server e il procotollo di trasporto GRE (IP type 47) per lo scambio e la criptazione dei dati.

L'autenticazione può avvenire via PAP o CHAP, ma generalmente si usa MSCHAP-v2 che fornisce le chiavi per la criptazione dei dati con MPPE (Microsoft Point-to-Point Encryption).

Su Linux il supporto MPPE non è ancora nel kernel ufficiale, per cui spesso va patchato sul kernel esistente ed è necessario se non si vuole che il proprio traffico attraversi il tunnel in chiaro.

Vantaggi
- Nativo su Windows (ed estremamente facile da configurare tramite Wizard)
- Trasporta sia traffico UDP che TCP
- Diffuso su diversi sistemi operativi (Linux, BSD, MacOS X ma anche Windows Mobile)

Svantaggi
- E' considerato meno sicuro di IpSec, risultando particolarmente debole nella definizione di chiavi di sessione realmente random.
- L'installazione su Linux, per l'interoperabilità con i parametri di default di Windows, richiede il patching del kernel.

Cipe - VPN per Linux e Windows

Cipe ( http://cipe-linux.sourceforge.net/ ) è una soluzione per VPN relativamente conosciuta nel mondo Linux che presenta anche una versione per Windows.
Usa come protocollo di trasporto UDP, che veicola datagrammi IP criptati con gli algoritmi Blowfish e Idea. E' composto da due parti: un modulo del kernel, che si occupa di gestire i pacchetti scambiati e presentare una interfaccia di rete dedicata, e un programma in userspace, ciped, con cui si gestisce il tunnel.

Installazione
Cipe è presente nei pacchetti predefiniti di alcune distribuzioni o è compilabile separatamente seguendo le istruzioni sul sito ufficiale.

Configurazione
/etc/cipe/options - Contiene le opzione di default per ciped, con una sintassi simile a quella di pppd.

Vantaggi
- Diffuso nel mondo Linux e relativamente semplice da usare
- Trasporta un intero datagramma IP e quindi qualsiasi protocollo di trasporto e applicativo
- Esiste una implementazione su Windows

Svantaggi
- Non è uno standard
- E' considerato da alcuni (rif: Peter Gutmann) poco sicuro
- Appare essere meno diffuso di un tempo

VPND

.

Vpnd: ( http://vpnd.dotsrc.org/ ) è un datato ma ancora occasionalmente aggiornato, progetto di VPN basata su trasporto UDP.
La sua caratteristica è la semplicità e l'immediatezza, a scapito della sicurezza. E' disponibile solo per Linux e FreeBSD e non pare avere una community folta.

Caratterisitche principali:
- comunicazione criptata con Blowfish nella modalità CFB ( Cipher Feedback Mode )
- creazione interfaccia SLIP
- comunicazione su  linea seriale o TPC/IP
- lunghezza massima chiave per la criptazione:  da 0 a 576 bits
- personalizzazione tempo di aggiornamento della chiave

Installazione
Prima di installare verificare che il kernel supporti l'interfaccia SLIP (Serial Line Internet Protocol), utilizzato da vpnd per effettuare la connessione tramite linea seriale (modem) o IP. Decompressi i sorgenti lanciare i soliti configure/make.

Configurazione
Il file di configurazione è /etc/vpnd.conf, ha una sintassi piuttosto semplice che permette di definire ip e porta di client e server, l'interfaccia slip da usare e altri parametri relativi la gestione della connessione.
La configurazione lato client differisce solo nella sezione "client/server"  e ovviamente IP.

Vantaggi
- Alternativa relativamente semplice e piuttosto funzionale per realizzare VPN interamente basate su Linux

Svantaggi
- Obbligo di scambio delle chiavi preventivo in modalità manuale
- Molte riserve sulla sicurezza della soluzione
- Disponibile solo per Linux e FreeBSD
- Progetto poco aggiornato e apparentemente poco seguito

Tinc - Vpn peer to peer

Tinc ( http://www.tinc-vpn.org/ ) è una soluzione per VPN basata su OpenSSL, incapsulato su UDP, che si presta bene, per la facilità della configurazione e la capacità di distribuire le tabelle di routing, ad essere utilizzata su scenari con numerose VPN fra diverse sedi.
Esiste per Linux, altri Unix, MaxOs e Windows, come OpenVPN lavora in user space su device TUN/TAP e questo lo rende facilmente adattabile a diversi sistemi operativi.

Installazione
Disponibile come pacchetto nativo o extra in molte distribuzioni, non presenta particolari difficoltà di installazione (tincd è il binario del servizio e si occupa di tutto).
Lavorando in user space non richiede la ricompilazione o il patching del kernel, che comunque deve supportare i device TUN/TAP (di default in molte distro).

Configurazione
/etc/tinc/tinc.conf è il suo file di configurazione di riferimento, ma la logica di tic fanno propendere per l'uso di una directory /etc/tin al cui interno, in diverse sottodirectory esistono i file di configurazione per ogni rete connessa tramite VPN.

Vantaggi
- La sua logica peer to peer rende semplice aggiungere una nuova VPN ad una infrastruttura esistente
- Scalabilità, ridondanza e robustezza su scenari di vpn complessi
- Cross platform, esiste per i principali sistemi operativi (per quanto ben testato solo su Linux)

Svantaggi
- Non usa un protocollo standard  
- La sicurezza della sua implementazione è stata messa in discussione, pare comunque essere più solida di altre soluzioni quali Cipe o Vtun
- Lavorando in user space e usando device TUN/TAP è potenzialmente più lento.

Sicurezza e VPN

La sicurezza è un aspetto intrinseco e fondamentale per una VPN:
A - nel tunnel passano dati sensibili, traffico "interno" e potenzialmente riservato
B - ad uno o entrambi i lati del tunnel esiste un apparato che, generalmente, ha una interfaccia pubblica, raggiungibile da Internet e una interna sulla LAN locale

Questo comporta problemi di sicurezza a 2 livelli:
A1 - Il traffico deve essere confidenziale e integro
B1 - Gli applicativi che gestiscono il tunnel e devono avere porte aperte su Internet e non devono essere vulnerabili
B2 - Se non si usano particolari sistemi di autenticazione (chiavi hardware, certificati digitali, smart key tipo RSA SecureID) basta sapere login e password per entrare in VPN e quindi accedere ad aree interne riservate.

Spesso ci si concentra solo sul punto A1 e alcune soluzioni di VPN sono considerate poco sicure perchè utilizzano metodi potenzialmente craccabili per lo scambio iniziale di chiavi e la successiva criptazione dei dati.
Ipsec è considerato generalmente il protocollo più sicuro.
PPTP, CIPE, VTUN e, in parte, TINC sono considerati genericamente meno sicuri, in particolare per quanto riguarda la confidenzialità (e quindi i metodi di crittazione) dei dati..
Celebre il tal senso l'analisi di Peter Gutmann nel post (href="http://diswww.mit.edu/bloom-picayune/crypto/14238) Linux's answer to MS-PPTP.

Per il punto B1 la sicurezza è data da chi sviluppa i singoli applicativi e da quanto questi sono soggetti a vulnerabilità serie. Come qualsiasi server di rete, un VPN server deve esporre delle porte sulle quali negoziare il tunnel e, quando si è in modalità road-warrior, è necessario lasciare queste porte accessibili a tutta Internet.
Avere porte pubbliche aperte su un apparato che ha anche interfacce interne sulla LAN è una pessima idea, ma in questi casi anche una necessità.

Tutto quanto descritto per i punti A1 e B1 diventa irrilevante se le password degli utenti sono deboli, se vengono usate le stesse password usate per altre applicazioni (per esempio la posta, magari controllata in chiaro via pop3 o imap) ecc.

Esistono metodi per avere VPN server accessibili da tutta Internet e, allo stesso tempo, non esposti costantemente a tutti gli indirizzi:
- Port knocking - Sul VPN server, senza porte accessibili dall'esterno, o su un firewall a monte è in esecuzione un servizio che monitora il traffico sull'interfaccia esterna ed esegue comandi (apre l'accesso a dati IP) quando riceve pattern di traffico predefinito. Controindicazione: spesso è necessario avere un client per inviare il pattern di traffico richiesto dal server.
Maggiori informazioni: http://www.portknocking.org/  
- Remote Firewall Opening - Metodo per applicare una regola dinamica ad un firewall per permettere di accedere al VPN server, autenticandosi e visitando specifiche pagine web su un server separato e indipendente. Introduce un livello di autenticazione ulteriore su un server separato.
Maggiori informazioni: Chiedere di RIP a [email protected]

Scenari di VPN su Linux

Il design di una infrastruttura VPN basata su Linux dipende da diversi fattori che determinano anche il tipo di scelte tecnologiche da adottare.

Scenario 1: VPN LAN to LAN - VPN Server amministrati in proprio
Se si ha il controllo completo di tutti i peer di queste VPN (possono essere anche diverse, con una struttura hub and spoke (a raggio) avente un VPN concentrator centrale e diversi VPN server periferici) è possibile scegliere una soluzioni interamente basata su Linux e quindi, oltre a IpSec, anche alternative legacy come Tinc, Cipe, Opentun, oltre a Pptp o ssh over ppp. Vtun andrebbe usato solo dove non ci sono particolari necessità di sicurezza.
Le regole di firewalling dovrebbero essere stringenti e permettere VPN solo agli IP dei peer. Se si hanno a disposizione apparati hardware diversi (router Cisco, firewall Pix ecc), la scelta si restringe a IpSec e PPTP.
Via software, invece, è possibile gestire VPN Linux-Windows anche con OpenVPN o Tinc.
Se la rete è complessa e presenta una architettura distribuita (non un tipico hub and spoke con un concentratore VPN centrale) ha senso valutare Tinc per la sua scalabilità e ridondanza.

Scenario 2: VPN LAN to LAN - VPN Server misti
Se si ha a che fare con apparati non completamente sotto il proprio controllo (server di partner ecc.) IpSec diventa la scelta di riferimento, avendo cura di implementare IKE per il key management (lo scambio chiavi manuale diventerebbe poco gestibile) e di filtrare tutti gli IP esclusi quelli dei peer.
Assicurarsi di considerare le reti remote come non fidate di default, permettendo solo il traffico necessario alle attività richieste dalla VPN.

Scenario 3: VPN Client to LAN - Client e Server Linux
Generalmente se si prevede l'accesso in VPN direttamente da un client, è necessario poter lasciare la possibilità di collegarsi a qualsiasi IP e di prevedere la possibilità che questa avvenga da un client nattato. Se i client sono solo Linux è possibile scegliere uno dei vari protocolli disponibili, prediligendo quelli di configurazione più agevole che lavorano in userland come OpenVPN o Tinc.

Scenario 4: VPN Client to LAN - Client misti e Server Linux
Se i client (Windows) devono poter essere facilmente configurati da utenti non esperti, PPTP rimane la scelta più ovvia, in quanto nativa in Windows e semplice da configurare, se i client possono essere configurati da personale tecnico si può provare con IpSec o OpenVPN (comunque di semplice installazione) o Tinc.

Per gli scenari che devono poter lasciar accesso da qualsiasi IP arbitrario, vale la pena valutare soluzioni di port knocking, o analoghe alternative, per aprire le porte di accesso per le VPN solo on demand.

Firewalling per VPN

La configurazione di una VPN spesso si scontra con regole di firewalling errate che determinano problemi e perdite di tempo.
Alcuni principi fondamentali, validi per ogni VPN Linux in rete pubblica:
- I peer della VPN, sia in una configurazione lan to lan che roadwarrior devono avere un IP pubblico ed avere la porta usata per negoziare il tunnel accessibile (intervenire su catena di INPUT di iptables)
- Le interfaccie virtuali che vengono create per ogni connessione sono soggette ad Iptables. per cui va permesso nei termini che si desiderano per permettere ai client collegati di accedere ad host delle reti interne (intervendire su catena di FORWARD di iptables).

Esempio di iptables
Vediamo un esempio semplice, basato sulla policy che tutto il traffico in uscita è permesso mentre quello in entrata viene filtrato e i client collegati in VPN (siano essi roadwarrior o host di una LAN remota) accedono senza limiti alla LAN locale.
Le regole che seguono si applicano ad un VPN server, che fa da gateway (con natting) di una rete interna (10.0.0.0/24) con interfaccia esterna su IP pubblico (eth1), interfaccia interna su LAN (eth0) e interfacce dedicate al tunnel (ppp0, ipsec0, tun1 a seconda dei protocolli usati)

1- Policy di default (tutto bloccato)
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

2- Regole standard per loopback, traffico correlato e in uscita
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 10.0.0.0/255.255.255.0 -i eth0 -j ACCEPT
4- Regole per permettere l'accesso, la negoziazione e lo scambio dei dati del tunnel, queste si applicano agli IP pubblici dei peer e variano a seconda del protocollo.
Esempio per Ipsec (aperto a tutti):
iptables -A INPUT -p udp --dport 500 -j ACCEPT
iptables -A INPUT -p ah -j ACCEPT
iptables -A INPUT -p esp -j ACCEPT
Esempio per PPTP (aperto solo all'indirizzo IP 213.215.144.242)
iptables -A INPUT -p tcp --dport 1723 -s 213.215.144.242 -j ACCEPT
iptables -A INPUT -p gre -s 213.215.144.242 -j ACCEPT
Esempio per OpenVPN (aperto a tutti):
iptables -A INPUT -p udp --dport 1194 -j ACCEPT

4- Regole per permettere il traffico dagli host collegati al tunnel alla rete interna
iptables -A FORWARD -i ppp0 -j ACCEPT
iptables -A FORWARD -i ppp1 -j ACCEPT
iptables -A FORWARD -i ppp2 -j ACCEPT
Notare che, se si lavora a livello di interfaccia, va specificata una interfaccia per ogni tunnel aperto contemporaneamente, altrimenti, ma meno raccomandabile, si può specificare l'IP sorgente.
Le regole sopra si applicano a VPN PPTP, con Ipsec vanno usate interfacce tipo ipsec0, ipsec1, ipsec2..., con OpenVPN o altri software basati sui driver TUN/TAP i nomi sono tun0, tun1 ecc.

5- Logging di tutti i pacchetti prima che vengano droppati per policy di default (questa regola deve essere alla fine, nel nostro caso)
iptables -A INPUT -m pkttype --pkt-type unicast -j LOG --log-prefix "[INPUT DROP] "
iptables -A FORWARD -m pkttype --pkt-type ! broadcast -j LOG --log-prefix "[FORWARD DROP] "
iptables -A OUTPUT -m pkttype --pkt-type ! broadcast -j LOG --log-prefix "[OUTPUT DROP] "