Esperienza su Virtual Private Network (VPN) |
|
|
|
Per la realizzazione di questo modulo useremo
Netkit4TIC
con la
connettività
con la rete reale (leggere il file README).
Riportiamo di seguito la mappa
(pdf)
della rete
dell'esercizio con il relativo schema di numerazione.
Lo script di nome lab.conf che genera i cinque host virtuali
con le configurazioni dei gate{L,R}, le immagini dei custom floppy
per gateL e per gateR è contenuto nel
tarball.
Valgono tutte le considerazioni fatte in
Bering uClibc che quindi non ripetiamo.
Il package che abbiamo deciso di utilizzare per costruire la
VPN è ipsec.lrp che implementa
Openswan IPSEC.
Richiede l'installazione dei pacchetti
libm.lrp, mawk.lrp e lpthread.lrp
e del modulo ipsec.o nel caso di kernel modulare.
Dopo aver settato correttamente l'ambiente Netkit lancia lo script:
realHost$ lstart
La policy che abbiamo adottato su entrambe i gateway è la seguente:
# /etc/shorewall/policy #SOURCE DEST POLICY # If you want open access to the vpn from your local net, # uncomment the following line #loc vpn ACCEPT info #vpn loc ACCEPT info # loc net ACCEPT net all DROP all all REJECT
Le eccezioni alla policy per il gateL sono:
# /etc/shorewall/rules #ACTION SOURCE DEST PROTO DEST # Incoming icmp request ACCEPT vpn loc icmp 8 # Incoming ssh request ACCEPT vpn loc tcp 22 # Incoming http request ACCEPT vpn loc tcp 80
Le eccezioni alla policy per il gateR sono:
# /etc/shorewall/rules #ACTION SOURCE DEST PROTO DEST # Outgoing icmp request ACCEPT loc vpn icmp 8 # Outgoing ssh request ACCEPT loc vpn tcp 22 # Outgoing http request ACCEPT loc vpn tcp 80
Attiviamo il tcpdump su pcL e su R:
pcL# tcpdump -i eth0 -n R# tcpdump -i any -n
ora eseguiamo un ping da pcR verso pcL e un ping da pcR verso gateL (eth0):
(gateL) 212.1.1.1 -- 212.1.1.2 -- 212.1.2.2 -- 212.1.2.1 (gateR) | | 10.10.10.0/24 10.10.20.0/24 | | (pcL) 10.10.10.1 10.10.20.4 (pcR) pcR# ping -c 1 10.10.10.1; \ ping -c 1 212.1.1.1
Il traffico osservato dall'host R generato dal ping verso pcL passa cifrato, come pacchetti ESP, e invece quello generato dal ping verso gateL passa in chiaro (File ACP). Il traffico osservato dall'host pcL è ovviamente in chiaro (File ACP). Dall'host virtuale pcR ricerchiamo una pagina web su pcL:
pcR# lynx -dump http://10.10.10.1/ | strings
Benvenuto 10.10.20.4 su 10.10.10.1
Controlliamo su pcL il log di apache:
pcL# tail -f /var/log/apache/access.log
10.10.20.4 - - [21/May/2005:16:14:41 +0200] "GET /index.html HTTP/1.0" \
200 190 "-" "Lynx/2.8.5rel.1 libwww-FM/2.14 SSL-MM/1.4.1 GNUTLS/1.0.16"
Questa comunicazione è stata resa possibile perchè in fase di configurazione di shorewall nel tunnel abbiamo permesso su pcR flusso http in uscita e su pcL flusso http in ingresso (in /etc/shorewall/rules dei gateway).
Il file /var/log/auth.log del gateL contiene:
ipsec__plutorun: Starting Pluto subsystem...
pluto[N]: Starting Pluto (Openswan Version 2.4.4 X.509-1.5.4 PLUTO_SENDS_VENDORID \
PLUTO_USES_KEYRR; Vendor ID OEz}FFFfgr_e)
pluto[N]: Setting NAT-Traversal port-4500 floating to off
pluto[N]: port floating activation criteria nat_t=0/port_fload=1
pluto[N]: including NAT-Traversal patch (Version 0.6c) [disabled]
pluto[N]: ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0)
pluto[N]: starting up 1 cryptographic helpers
pluto[N]: started helper pid=643 (fd:6)
pluto[N]: Using KLIPS IPsec interface code on 2.4.32-bs3
pluto[N]: Changing to directory '/etc/ipsec.d/cacerts'
pluto[N]: Changing to directory '/etc/ipsec.d/aacerts'
pluto[N]: Changing to directory '/etc/ipsec.d/ocspcerts'
pluto[N]: Changing to directory '/etc/ipsec.d/crls'
pluto[N]: Warning: empty directory
pluto[N]: added connection description "netkit"
pluto[N]: listening for IKE messages
pluto[N]: adding interface ipsec0/eth0 212.1.1.1:500
pluto[N]: loading secrets from "/etc/ipsec.secrets"
pluto[N]: "netkit" #1: initiating Main Mode
pluto[N]: ERROR: "netkit" #1: sendto on eth0 to 212.1.2.1:500 \
failed in main_outI1. Errno 1: Operation not permitted
pluto[N]: packet from 212.1.2.1:500: received Vendor ID payload [Openswan \
(this version) 2.4.4 X.509-1.5.4 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR]
pluto[N]: packet from 212.1.2.1:500: received Vendor ID payload [Dead Peer Detection]
pluto[N]: "netkit" #2: responding to Main Mode
pluto[N]: "netkit" #2: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
pluto[N]: "netkit" #2: STATE_MAIN_R1: sent MR1, expecting MI2
pluto[N]: "netkit" #2: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
pluto[N]: "netkit" #2: STATE_MAIN_R2: sent MR2, expecting MI3
pluto[N]: "netkit" #2: Main mode peer ID is ID_IPV4_ADDR: '212.1.2.1'
pluto[N]: "netkit" #2: I did not send a certificate because I do not have one.
pluto[N]: "netkit" #2: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
pluto[N]: "netkit" #2: STATE_MAIN_R3: sent MR3, ISAKMP SA established \
{auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
pluto[N]: "netkit" #3: responding to Quick Mode {msgid:43276e4f}
pluto[N]: "netkit" #3: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
pluto[N]: "netkit" #3: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
pluto[N]: "netkit" #3: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
pluto[N]: "netkit" #3: STATE_QUICK_R2: IPsec SA established \
{ESP=>0x494dff3a <0x5e4bcfb6 xfrm=AES_0-HMAC_SHA1 NATD=none DPD=none}
pluto[N]: "netkit" #1: received Vendor ID payload [Openswan (this version) 2.4.4 \
X.509-1.5.4 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR]
pluto[N]: "netkit" #1: received Vendor ID payload [Dead Peer Detection]
pluto[N]: "netkit" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
pluto[N]: "netkit" #1: STATE_MAIN_I2: sent MI2, expecting MR2
pluto[N]: "netkit" #1: I did not send a certificate because I do not have one.
pluto[N]: "netkit" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
pluto[N]: "netkit" #1: STATE_MAIN_I3: sent MI3, expecting MR3
pluto[N]: "netkit" #1: Main mode peer ID is ID_IPV4_ADDR: '212.1.2.1'
pluto[N]: "netkit" #1: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
pluto[N]: "netkit" #1: STATE_MAIN_I4: ISAKMP SA established \
{auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
pluto[N]: "netkit" #4: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1}
pluto[N]: "netkit" #4: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
pluto[N]: "netkit" #4: STATE_QUICK_I2: sent QI2, IPsec SA established \
{ESP=>0x494dff3b <0x5e4bcfb7 xfrm=AES_0-HMAC_SHA1 NATD=none DPD=none}
e quello del gateR contiene:
ipsec__plutorun: Starting Pluto subsystem...
pluto[N]: Starting Pluto (Openswan Version 2.4.4 X.509-1.5.4 PLUTO_SENDS_VENDORID \
PLUTO_USES_KEYRR; Vendor ID OEz}FFFfgr_e)
pluto[N]: Setting NAT-Traversal port-4500 floating to off
pluto[N]: port floating activation criteria nat_t=0/port_fload=1
pluto[N]: including NAT-Traversal patch (Version 0.6c) [disabled]
pluto[N]: ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0)
pluto[N]: starting up 1 cryptographic helpers
pluto[N]: started helper pid=677 (fd:6)
pluto[N]: Using KLIPS IPsec interface code on 2.4.32-bs3
pluto[N]: Changing to directory '/etc/ipsec.d/cacerts'
pluto[N]: Changing to directory '/etc/ipsec.d/aacerts'
pluto[N]: Changing to directory '/etc/ipsec.d/ocspcerts'
pluto[N]: Changing to directory '/etc/ipsec.d/crls'
pluto[N]: Warning: empty directory
pluto[N]: added connection description "netkit"
pluto[N]: listening for IKE messages
pluto[N]: adding interface ipsec0/eth0 212.1.2.1:500
pluto[N]: loading secrets from "/etc/ipsec.secrets"
pluto[N]: "netkit" #1: initiating Main Mode
pluto[N]: "netkit" #1: received Vendor ID payload [Dead Peer Detection]
pluto[N]: "netkit" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
pluto[N]: "netkit" #1: STATE_MAIN_I2: sent MI2, expecting MR2
pluto[N]: "netkit" #1: I did not send a certificate because I do not have one.
pluto[N]: "netkit" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
pluto[N]: "netkit" #1: STATE_MAIN_I3: sent MI3, expecting MR3
pluto[N]: "netkit" #1: Main mode peer ID is ID_IPV4_ADDR: '212.1.1.1'
pluto[N]: "netkit" #1: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
pluto[N]: "netkit" #1: STATE_MAIN_I4: ISAKMP SA established \
{auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
pluto[N]: "netkit" #2: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1}
pluto[N]: "netkit" #2: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
pluto[N]: "netkit" #2: STATE_QUICK_I2: sent QI2, IPsec SA established \
{ESP=>0x5e4bcfb6 <0x494dff3a xfrm=AES_0-HMAC_SHA1 NATD=none DPD=none}
pluto[N]: packet from 212.1.1.1:500: received Vendor ID payload [Openswan \
(this version) 2.4.4 X.509-1.5.4 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR]
pluto[N]: packet from 212.1.1.1:500: received Vendor ID payload [Dead Peer Detection]
pluto[N]: "netkit" #3: responding to Main Mode
pluto[N]: "netkit" #3: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
pluto[N]: "netkit" #3: STATE_MAIN_R1: sent MR1, expecting MI2
pluto[N]: "netkit" #3: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
pluto[N]: "netkit" #3: STATE_MAIN_R2: sent MR2, expecting MI3
pluto[N]: "netkit" #3: Main mode peer ID is ID_IPV4_ADDR: '212.1.1.1'
pluto[N]: "netkit" #3: I did not send a certificate because I do not have one.
pluto[N]: "netkit" #3: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
pluto[N]: "netkit" #3: STATE_MAIN_R3: sent MR3, ISAKMP SA established \
{auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
pluto[N]: "netkit" #4: responding to Quick Mode {msgid:e8707608}
pluto[N]: "netkit" #4: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
pluto[N]: "netkit" #4: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
pluto[N]: "netkit" #4: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
pluto[N]: "netkit" #4: STATE_QUICK_R2: IPsec SA established \
{ESP=>0x5e4bcfb7 <0x494dff3b xfrm=AES_0-HMAC_SHA1 NATD=none DPD=none}
dove abbiamo evidenziato in colore l'attesa del gateR da parte del gateL e in colore la corretta apertura del canale cifrato.
Generazione delle chiavi |
|
Per la generazione delle chiavi abbiamo usato il pacchetto
freeswan installato su una Debian Sarge. I comandi:
# ipsec newhostkey --hostname gateL --output ipsec.secrets.L --bits 4096 # ipsec newhostkey --hostname gateR --output ipsec.secrets.R --bits 4096
Poi dal file ipsec.secrets.L
abbiamo estratto la stringa alla destra
di #pubkey= e l'abbiamo riportata sul file
ipsec.conf alla destra del simbolo leftrsasigkey=.
Analogamente dal file ipsec.secrets.R
abbiamo estratto la stringa alla destra
di #pubkey= e l'abbiamo riportata sul file
ipsec.conf alla destra del simbolo
rightrsasigkey=.
In seguito i file ipsec.secrets.{L,R} sono diventati
ipsec.secrets nei rispettivi host.
Monitoraggio rete attraverso SNMP |
|
Ci proponiamo ora di configurare la raccolta di informazioni
statistiche via SNMP da parte del lato R. Per questo scopo
sono stati attivati agent SNMP sia nei firewall che sul nodo pcL
mentre per il test di connettività useremo snmpwalk
dal nodo pcR. Gli agent sui firewall hanno configurato
il servizio in ascolto sulla sola interfaccia interna utilizzando
il file /etc/default/snmpd e aggiungendo alla
valorizzazione del parametro SNMPDOPTS il valore IP address
dell'interfaccia eth1. I moduli lrp necessari alla funzionalità
SNMP sono: snmpmibs, libsnmp e netsnmpd.
Aggiungiamo delle eccezioni alle regole del nodo gateR
che esprimono il permesso da parte della LAN R di comporre query
snmp sulla LAN L e sul firewall stesso:
# /etc/shorewall/rules # # Accept SNMP connections from loc to vpn # #ACTION SOURCE DEST PROTO DEST ACCEPT loc vpn udp 161 ACCEPT loc vpn tcp 161 ACCEPT loc vpn udp 162 ACCEPT loc vpn tcp 162 # # Accept SNMP connections from loc to fw # #ACTION SOURCE DEST PROTO DEST ACCEPT loc fw udp 161 ACCEPT loc fw tcp 161 ACCEPT loc fw udp 162 ACCEPT loc fw tcp 162
Aggiungiamo delle eccezioni alle regole del nodo gateL
che esprimono il permesso da parte del traffico SNMP proveniente
dalla VPN di comporre query SNMP sulla LAN L e sul gateL stesso:
# /etc/shorewall/rules #ACTION SOURCE DEST PROTO DEST # # Accept SNMP connections from vpn to loc # ACCEPT vpn loc udp 161 ACCEPT vpn loc tcp 161 ACCEPT vpn loc udp 162 ACCEPT vpn loc tcp 162 # # Accept SNMP connections from vpn to firewall # ACCEPT vpn fw udp 161 ACCEPT vpn fw tcp 161 ACCEPT vpn fw udp 162 ACCEPT vpn fw tcp 162
Possiamo verificare estraendo ad esempio i MAC address:
pcR# snmpwalk -Os -v 2c -c public 10.10.10.1 ifPhysAddress | grep -v ': $' ifPhysAddress.1 = STRING: fe:fd:a:a:a:1 pcR# snmpwalk -Os -v 2c -c public 10.10.10.2 ifPhysAddress | grep -v ': $' ifPhysAddress.4 = STRING: fe:fd:d4:1:1:1 ifPhysAddress.5 = STRING: fe:fd:a:a:a:2 ifPhysAddress.9 = STRING: fe:fd:d4:1:1:1 pcR# snmpwalk -Os -v 2c -c public 10.10.20.3 ifPhysAddress | grep -v ': $' ifPhysAddress.4 = STRING: fe:fd:d4:1:2:1 ifPhysAddress.5 = STRING: fe:fd:a:a:14:3 ifPhysAddress.9 = STRING: fe:fd:d4:1:2:1
Ora configuriamo cacti per la raccolta e la visualizzazione del traffico. Puntiamo il browser su:
realHost$ mozilla-firefox http://192.168.77.2/cacti/
e completiamo la procedura di installazione. Da ricordare che
l'utente admin ha password admin che
in seguito ci viene chiesto di cambiare.
Come suggerisce la pagina iniziale i passi sono:
Configurare IPSec nel DNS |
|
Il termine "opportunistic encryption" indica la possibilità di attivare una cifratura anche se non precedentemente configurata con lo scambio delle chiavi. Naturalmente entrambi i gateway devono essere configurati in modo da attivare questa particolare modalità.
Per generare la chiave pubblica nel formato opportunistic-encryption per i record DNS TXT e KEY:
gateL# ipsec showhostkey --file /etc/ipsec.secrets \
--txt @L.istituto.it
# RSA 4096 bits gateL Sun May 22 00:40:36 2005
IN TXT "X-IPsec-Server(10)=@L.istituto.it" " AQNk...Hww=="
gateL# ipsec showhostkey --file /etc/ipsec.secrets \
--key @L.istituto.it
# RSA 4096 bits gateR Sun May 22 00:44:09 2005
IN KEY 0x4200 4 1 AQOX...0Q=="
analogamente per il gateR.
|
|
Sandro Doro (email me)