Prima di cominciare una piccolo test. Quanti di voi, da bravi sistemisti, controllate i log delle vostre macchine la mattina quando arrivate in ufficio? Sono sicuro che quasi tutti lo fate! Bene, se ci soffermiamo a guardare i tentativi di login falliti non sono spaventosamente alti?
Questo dovrebbe per lo meno farci scattare un campanello d’allarme, vero che se usiamo SSH è un protocollo abbastanza sicuro, vero che se usiamo una password forte (usiamo un password forte NO?!?!?!) difficilmente con un Brute-force si riuscirà a trovare, ma la cosa è per lo meno fastidiosa, è come se di continuo qualcuno vi citofonasse a casa dicendovi di essere vostra mamma, il/la vostro/a fidanzato/a, vostro fratello. Voi capite subito che non sono loro, non hanno la password, ma dovete continuamente andare al citofono per rispondere e magari qualcuno, prima o poi, v’inganna.

Come possiamo risolvere questo problema?Non possiamo certo staccare il citofono, la soluzione è nascondere il citofono dentro ad un tunnel il cui accesso è controllato da guardiani.Ecco che entra in gioco la VPN.
Uno schemino può farci capire meglio l’architettura di rete che vogliamo realizzare.

Come potete vedere abbiamo un percorso blu tratteggiato tra il gateway del nostro ufficio e il gateway della server farm.Quel percorso rappresenta il tunnel che i dati percorrono, lo andremo a realizzare su internet appoggiandoci a tecniche di crittografia e incapsulamento. L’idea di fondo è bloccare sul firewall della farm la porte tcp o udp che non vogliamo siano accessibili dall’esterno e consentire solo quelle provenienti dalla VPN.Dopo aver installato sulle macchine che faranno da gateway la nostra distribuzione linux preferita procediamo in due step.

Configuriamo la “Farm”

Come vedete dallo schema, abbiamo una LAN/24 con indirizzi pubblici, uno switch che interconnette tutti i nostri server i il gateway. E su questo Gateway che andremo a configurare il firewall e il vpn server.Sul Gteway abbiamo un IP pubblico 1.1.1.254 e un IP privato usato dalla struttura VPN 192.168.90.2

Le regole Di Iptables:

FilterTable:INPUT chain
iptables -P INPUT DROP “Droppiamo tutti i pacchetti di default, tutto ciò che non è esplicitamente permesso è proibito”
iptables -A INPUT-s 192.168.90.2 -j ACCEPT “Accettiamo il traffico proveniente dalla Vpn”
iptables -A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
“Accettiamo il traffico di risposta alle connessioni iniziate dal gateway”
iptables -A INPUT -p udp -m udp –dport 1194 -j ACCEPT “Accettiamo il traffico in ingresso al server VPN”

FilterTable:FORWARD chain
iptables -P FORWARD DROP “Droppiamo tutti i pacchetti di default, tutto ciò che non è esplicitamente permesso è proibito”
iptables -A FORWARD -s 192.168.90.2 -j ACCEPT “Consentiamo al traffico proveniente dalla vpn di transitare verso i server”
iptables -A FORWARD -p tcp -m tcp –dport 80 -j ACCEPT “Consentiamo il traffico web verso i server”
iptables -A FORWARD -s 1.1.1.0/24 -j ACCEPT “Consentiamo al traffico generato dai server di uscire su internet”

Configuriamo Openvpn

Terminata la configurazione del firewall installiamo openvpn (fate riferimento alle guide specifiche per la vostra distribuzione).Sarà necessario generare una serie di chiavi e certificati, assieme ad openvpn viene fornito un utilissimo tools chiamato easy-rsa adatto per questi scopi. Localizziamo easy-rsa (se abbiamo usato l’rpm potrebbe essere sotto /usr/share/doc/openvpn/) e copiamo tutta la cartella in /etc/openvpn/. Spostiamoci dentro /etc/openvpn/easy-rsa ed apriamo il file vars con un editor di testi, dobbiamo valorizzare le variabili KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, KEY_EMAIL senza lasciarne bianca neanche una.Fatto questo chiudiamo e salviamo il file dopodiche:

./vars
./clean-all
./build-ca

L’ultimo comando invoca un programma interattivo che ci chiederà di specificare i parametri immessi nel file vars proponendoli come default. L’unico che dobbiamo inserire è “COMMON-NAME” mettiamo “vpn-CA”.
A questo punto abbiamo in mano 2 file, una coppia di chiavi pubblica e privata.La chiave privata verrà usata dalla CA per firmare le chiavi pubbliche dei nodi partecipanti alla vpn e la chiave publica della CA verra usata dai nodi per verificare l’autenticità delle chiavi pubbliche degli altri nodi (I dettagli della crittografia a chiave pubblica li trattiamo magari in un altro articolo).

Ora dobbiamo generare chiave e certificato (o coppia di chiavi privata/pubblica) del server VPN e del Client presente nel nostro ufficio:

./build-key-server vpn-server
./build-key vpn-office-client

Analogamente a build-ca questi 2 comandi sono interattivi, alla richiesta del COMMON-NAME inseriamo vpn-server e vpn-office-client.
L’ultimo passo è generare i parametri di Diffie-Hellman:

“./build-dh”

Riassumiamo i key-files che abbiamo ottenuto

FileName Richiesto da Uso Segreto
ca.crt Server e client Certificato della CA No
ca.key Solo firma dei nuovi certificati Chiave privata della CA Si
dh.pem Server Vpn Parametri di Diffie-Hellman No
vpn-server.crt Server Vpn Certificato del server VPN No
vpn-server.key Server Vpn Chiave del server VPN Si
vpn-office-client.crt Client Vpn Certificato del client VPN No
vpn-office-client.key Client Vpn Chiave del client VPN Si

Ora copiamo, tramite un canale sicuro, i 3 file che ci servono sul nostro client, andremo poi a posizionarli al punto giusto, e continuiamo con il file di configurazione del server VPN.

/etc/openvpn/opnvpn.conf

dev tun #Modalita routing
proto udp #Udp perchè openvpn già controlla l’integrità e far 2 volte la stessa cosa non è mai saggio.
persist-key #Non rilegge la chiave in caso di SIGHUP
persist-tun #Non chiude e riapre il dispositivo tun in caso di SIGHUP
ca /etc/openvpn/keys/ca.crt #File del certificato della CA
cert /etc/openvpn/keys/vpn-office-client.crt #File del certificato del server Vpn
key /etc/openvpn/keys/cpn-office-client.key #File della chiave del server Vpn
dh /etc/openvpn/keys/dh1024.pem #File dei parametri di Diffie-Hellman
server 192.168.90.0 255.255.255.0 #Sottorete usata dalla Vpn
client-to-client #Se sono presenti più client possono comunicare tra di loro
ifconfig-pool-persist /etc/openvpn/ipp.txt #Salviamo le impostazione per-client (in caso di ambiente multi-client)
comp-lzo #Attiva la compressione
verb 3 #Livello di log
log /var/log/openvpn.log #Specifica il file di Log
daemon #demonizza il processo

Prestate attenzione che i percorsi dei file siano corretti, per i dettagli sulle direttive potete far riferimento alla documentazione ufficiale Quì.Salviamo il file e con un bel /etc/init.d/openvpn start facciamo partire il nostro server. Se vengono segnalati errori controllate il file di log e sistemate.

Ci siamo quasi, manca ancora un piccolo passo…
Configuriamo “l’ufficio”

Le regole Di Iptables del gatewy in ufficio:

FilterTable:INPUT chain
iptables -P INPUT DROP “Droppiamo tutti i pacchetti di default, tutto ciò che non è esplicitamente permesso è proibito”
iptables -A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT “Accettiamo il traffico di risposta alle connessioni iniziate dal gateway”

FilterTable:FORWARD chain
iptables -P FORWARD DROP “Droppiamo tutti i pacchetti di default, tutto ciò che non è esplicitamente permesso è proibito”
iptables -A FORWARD -s 192.168.0.0 -j ACCEPT “Consentiamo al traffico proveniente dalla LAN di transitare verso internet e la vpn”
iptables -A FORWARD -m state –state RELATED,ESTABLISHED -j ACCEPT “Consentiamo il traffico di risposta verso la LAN”

NatTable:POSTROUTINGchain
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j  MASQUERADE “Applichiamo il NAT al traffico in uscita dalla LAN”

Configuriamo Openvpn sul client dell’ufficio

Una volta installato e copiati i 3 file di chiave e certificati editiamo il file /etc/openvpn/openvpn.conf

client #Modalità client
nobind
dev tun
proto udp
remote 1.1.1.254 #Ip Pubblico e raggiungibile del server
persist-key
persist-tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/vpn-office-client.crt
key /etc/openvpn/keys/vpn-office-client.key
comp-lzo
verb 3
log /var/log/openvpn.log
keepalive 5 30

Una volta fatto questo lanciamo il servizio con /etc/init.d/openvpn start

Controlliamo il Log, se tutto è andato bene dovremmo ritrovarci un interfaccia di rete che si chiama tun0 di tipo P-t-P con indirizzo ip 192.168.90.x p-t-p 192.168.90.y. Se così è proviamo a fare un ping a 192.168.90.1, se riceviamo risposta è tutto ok.

L’ultima cosa da fare è dire al gateway di passare attraverso la vpn per le connessioni dirette ai server in server-farm:
route add -net 1.1.1.0/24 gw 192.168.90.y dove y è l’ultima cifra dell’indirizzo p-t-p dell’interfaccia tun0 che possiamo vedere con ifconfig.

L’ultima prova che ci resta da fare è un ping da uno dei client all’interno della LAN dell’ufficio verso un server della Farm, se riceviamo risposta abbiamo finito, la nostra VPN è funzionante.

Alcune considerazioni riguardo la sicurezza

Se consideriamo che, a meno di compromissione dei file di chiavi e certificati, per un attacante riuscire ad inserirsi nel tunnel è molto complesso, questo schema sembra molto sicuro. Ci sono tuttavia alcuni aspetti da tenere in considerazione.

Un possibile problema nasce dal fatto che non abbiamo imposto nessuna restrizione e nessun controllo sulla LAN dell’ufficio, la compromissione di questa rete comprometterebbe automaticamente anche la sicurezza della server-Farm in quanto il traffico proveniente dalla LAN stessa è considerato TRUSTED per la server-farm. Per questo motivo diventa molto importante concentrarsi anche sulla sicurezza della LAN e dei client connessi ad essa(o almeno di quelli autorizzati ad attraversare il tunnel).

Non bisogna anche dimenticarsi che è opportuno realizzare delle politiche di sicurezza forti sulle macchine che realizzano la VPN, la compromissione di una di queste 2 macchine farebbe chiaramente cadere tutta l’impalcatura di sicurezza che abbiamo tentato di realizzare.

Grazie per l’attenzione e buon lavoro.

Lascia un Commento

Devi aver fatto il login per inviare un commento

Page 1 of 11