Izgrazhdane
na X.509 PKI VPN
Veselin
Markov 12.2006
Tozi dokument razglezhda osushtestviavaneto na svurzanost mezhdu chastni
mrezhi prez publichna sreda (WAN) posredstvom kriptografsko
tunelirane. Reshenieto
se bazira na
SSL/TLS komunikatsiia i enkapsulirane na danni vurhu TUN/TAP interfeisi
posredstvom OpenVPN.
.: Vuvedenie
Po definitsiia VPN mrezhite mogat da budat sigurni (IPSec, SSL/TLS, L2TP,
PPTP) i takiva, koito predavat danni po neshifriran nachin, doveriaviaiki
se na tranzitna sigurnost ot strana na dostavchika (MPLS, L2F).
Vse
poveche dostavchitsi
predostaviat usluga "VPN", kato v niakoi sluchai klientut trudno mozhe da
izbegne poruchvaneto i ako se nuzhdae ot suotveten nachin na svurzvane do
otdalechena mrezha. CHesto protokoli kato ESP/AH bivat napulno "otriazvani"
ot upotreba bez preminavane kum po-visok tsenovi plan.
Ochevidno, budeiki v puti po-izgodno, ustanoviavane na VPN reshenie
(vmesto izgrazhdane i razshiriavane MAN ili WAN) e predmet na izbor za
goliam broi organizatsii.
Alternativno, eksploatatsiia na VPN tehologiia e vuzmozhno chrez izpolzvane
na SSL/TLS tunelirane. OpenVPN e takuv primer, poddruzhasht razlichni
metodi na svurzvane, udostoveriavane, v t.ch. spodelen klyuch, sertifikati,
smart karti, kombinatsiia ot potrebitelsko ime i parola, kakto i
kompleksni nachini za kriptirane na sesiiata i zapazvane na integriteta i.
OpenVPN
e svoboden softuer,
purvonachalno razraboten ot Dzheims Ionan, baziran na OpenSSL i e nalichen
pod GNU/Linux, BSD variatsii, OS X, Solaris, Windows.
Pri
realizatsiiata na OpenVPN
mogat da se izpolzvat 2 dopulnitelni interfeisa za komunikatsiia - tun i
tap. Ideiata pri tiah e da se simulirat mrezhovi ustroistva. TUN simulira
Point to Point u-vo (OSI L3) pri rutiran VPN, dokato TAP - Ethernet
(L2), pri VPN s mrezhov most (bridge). Po-kusno shte se spra otnovo na tiah.
Interesen fakt e, che OpenSSH (sled ver 4.3) sushto ima poddruzhka na
tun/tap draivera:
http://www.securityfocus.com/columnists/375
http://marc2.theaimsgroup.com/?l=secure-shell&m=114467685608028&w=2
Haraktena vuzmozhnost na OpenVPN e funktsioniraneto mu po UDP ili TCP (i
po tozi nachin vurhu proxy survuri). OpenVPN mozhe da raboti s dinamichni
kraini tochki, da tunelira mrezhi prez NAT, da se "razbira" dobre sus
stateful zashtitni steni, da pozvoliava prioritizatsiia na trafika koito
minava prez nego, kakto i simultanno da poddruzha goliam broi
klienti/trafik. Obmianata na klyuchove e vuzmozhna chrez statichni, spodeleni
takiva ili dinamichno, na baza na TLS. Trafikut se kompresira v realno
vreme chrez LZO biblyutekata.
Ot gledna tochka na sistemna sigurnost samiiat protses mozhe da raboti s
ponizheni prava i/ili v chroot sreda. Budeiki baziran na OpenSSL(1)
biblyutekata, OpenVPN mozhe da izpolzva vsichki shifri do koito (1) ima
dostup, v t.ch. AES-256, razlichna golemina na klyuch, mnozhestvo HMAC
digests. Vuzmozhno e i "zaklyuchvane" na protsesa v pametta (ne popada v
swap) chrez mlockall().
.:
Konfiguratsiia na OpenVPN
survur
Teoritichno poglednato, vuzmozhni metodi pri identifikatsiia na klient
bivat klasifitsirani spored:
- neshto koeto potrebiteliat znae (parola)
- neshto pritezhavano ot potrebitelia (taen klyuch kum sertifikat, smart
karta)
- neshto koeto potrebiteliat e (biometrichni danni - prustov otpechatuk,
danni ot skanirane na retina)
Razglezhdaniiat ot statiiata metod na identifikatsiia na potrebitel se
svezhda do PKI sistema, izgradena chrez SA. Informatsiia kasaeshta aspektite
ot suzdavane i administrirane na Dostoveren Iztochnik na Sertifikati
mogat da budat namereni tuk:
http://linux-bg.org/cgi-bin/y/index.pl?page=article&id=advices&key=386394133&layout=clean
Za ulesnenie na redoviia potrebitel, v paketa OpenVPN ima skriptove,
koito namaliavat usliiata po suzdavane na klientski i survurni
sertifikati.
Sushtestven moment ot aministratsiiata na VPN survur rabotesht s X.509
sertifikati e suzdavaneto i obnoviavaneto na CRL spisuk. V zavisimost ot
tova dali klient izpolzva validen ili anuliran sertifikat, iz log
failovete na openvpn shte sreshtnete slednite zapisi:
Thu
Dec 7 00:42:23 2006
224.100.200.191:63402 CRL CHECK OK:
/C=BG/ST=_/ L=_/O=Example_Corp./OU=IT_Dept./
CN=Example_Corp._VPN_designated_CA-2/ emailAddress=admin@example.net
Thu Dec 7 00:42:23 2006
224.100.200.191:63402 CRL CHECK OK:
/C=BG/ST=_/L=_/O=Example_Corp./OU=Marketing/CN=client1/emailAddress=admin@example.net
ili
Fri
Dec 8 01:16:59 2006
236.32.2.7:38889 CRL CHECK FAILED:
/C=BG/ST=_/L=_/O=Example_Corp./OU=HR/CN=client2/emailAddress=admin@example.net
is REVOKED
Vazhna osobenost ako izpolzvate chroot sreda e CRL da bude postaven na
miastoto kudeto zaklyuchvate protsesa (naprimer /var/empty).
Shematichno
predstaven mrezhovi model:
[ priv net 10.0.0.0/24 ]
[ client gw 224.100.200.191 ] -
WAN
- [ company gw 225.50.100.5 ]
[ dmz node addr 225.50.100.8 ]
[ priv net 192.168.0.0/22 ]
drugi vpn terminatsionni tochki
Vsushtnost,
vuprosniiat VPN se
izgrazhda mezhdu hostovete impala (10.0.0.2) i vpndial (192.168.0.156).
Sluchaiat, koito razglezhdam, izpolzva most (bridge) mezhdu eth0 i tap0
(tap1, tap2, tapX). Slednite komponenti sa neobhodimi zaredeni kato
moduli ili kompilirani statichno v iadroto:
CONFIG_BRIDGE=m
CONFIG_TUN=m
Mozhete, razbira se, da si spestite eventualni glavoboliia v tazi nasoka,
reshavaiki che i rutiran VPN vi vurshi rabota. Razlikata e v tova, che pri
izpolzvane na takuv tunel (tun) se nalaga da dobavite niakolko pravila s
iptables, za da maskirate trafika preminavasht prez tun ustroistvoto.
Tozi variant bi bil doniakude problemen po otnoshenie na NAT, naprimer
ako se opitvate da polzvate H.323 ili SIP protokol prez VPN-a si, ili
iskate po druga prichina mashinata vi da bude "vidima" na otseshtnata mrezha
(v iadro 2.6.19 ima eksperimentalna poddruzhka na connection tracking i
za 2-ta protokola).
Ako se nalozhi da polzvate opisaniiat VPN s bridge ot dial-up do
sravnitelno goliama mrezha ima opasnost kanalut da bude zapulnen ot
broadcast paketi.
Po
podrazbirane, portut na koito
slusha za zaiavki demon protsesut e UDP/1194. Ako vuznameriavate da
razreshite dostup na klienti s proizvolni IP adresi, sledva da go
pozvolite za vsichki vuv filter/INPUT. Sushto taka preprashtaneto na paketi
kum br0 triabva da e razresheno vuv filter/FORWARD.
Konfiguratsionniiat fail izglezhda taka:
port
6644
proto udp
dev tap0
tls-auth priv/ta.key 0
user nobody
group nobody
chroot /var/empty
cipher AES-256-CBC
auth RSA-SHA512
reneg-sec 1800
persist-key
persist-tun
ca priv/ca.crt
cert priv/server.crt
key priv/server.key
dh priv/dh2048.pem
crl-verify ca.crl
push "route 192.168.0.0 255.255.0.0"
server-bridge 192.168.0.156 255.255.252.0 192.168.3.10 192.168.3.150
push "redirect-gateway def1"
keepalive 10 120
comp-lzo
status openvpn-status.log
log openvpn.log
verb 3
Niakoi belezhki po nego:
-
ca.crl se namira vuv
/var/empty i e prochitaem za nobody
- klyuchut kum survurskiia sertifikat e dostupen edinstveno ot root
-
failut s Diffie-Hellman parametri mozhe da bude suzdaden taka: openssl
dhparam -out dh2048.pem 2048 (vuzmozhno e da otneme poveche vreme)
- ta.key e spodelen klyuch (stoinost 0 pri survur i 1 za klient)
generira se taka: openvpn --genkey --secret ta.key
- redirect-gateway def1 ukazva tseliiat klientski trafik da bude
rutiran prez vpn, koeto ot edna strana e udobno ako ima dobra
svurzanost, a ot druga povishava sigurnostta sled kato klientut popada
zad
korporativen firewall, do kraia na sesiiata si.
Marshrutnata tablitsa pri klientski host bi izglezhdala taka pri nalichnost
na tazi optsiia
225.50.100.8 via 10.0.0.1 dev eth0
192.168.0.0/22 dev tap0 proto kernel scope link src
192.168.3.10
192.168.0.0/16 via 192.168.0.156 dev tap0
10.0.0.0/24 dev eth0 proto kernel scope link src
10.0.0.2
127.0.0.0/8 dev lo scope link
0.0.0.0/1 via 192.168.0.156 dev tap0
128.0.0.0/1 via 192.168.0.156 dev tap0
default via 10.0.0.1 dev eth0
-
redut s push route
ukazva dostup do posochenite chastni mrezhi
- server-bridge
192.168.0.156 (openvpn adres na survur) 255.255.252.0 (mrezhova maska)
192.168.3.10 192.168.3.150 (adresi prednaznacheni za VPN potrebiteli)
-
persist-key,
persist-tun zapzvat niakoi veche izgradeni resursi/nastroiki pri HUP-vane
(ili prashtane na drug signal) na protsesa, tui kato ne se ochakva nobody
da ima dostup do tiah
- reneg-sec opredelia
vreme v sekundi do nov TLS handshake
.:
Konfiguratsiia na
OpenVPN klient
client
dev tap
# proto tcp
proto udp
remote 225.50.100.8 6644
# http-proxy 10.0.0.1 80
nobind
persist-key
persist-tun
auth RSA-SHA512
reneg-sec 1800
tls-auth priv/ta.key 1
cipher AES-256-CBC
user nobody
group nobody
ns-cert-type server
ca priv/ca.crt
cert priv/client1.crt
key priv/client1.key
comp-lzo
verb 3
-
remote opredelia
adres/port na vpn survura
-
nobind ukazva protsesut
da ne otvaria slushasht port
-
ns-cert-type server e
spomaga za predotvratiavane na mitm ataka v sluchai che pritezhatel na
sertifikat izdaden ot sushtoto CA se opita da se predstavi za survur, shte
bude provereno dali niz ot sertifikata mu otgovaria na iziskvaniiat tip
-
verb ukazva stepen na
izcherpatelnost na log suobshteniiata
-
http-proxy definira
adres na proxy survur, kakto i razlichni tipove otorizatsiia (basic, ntlm)
Pri squid, openvpn sesiiata shte bude registrirana po shoden nachin v
access.log:
1165770141.590 368564 10.0.0.1 TCP_MISS/200 1412503 CONNECT
225.50.100.8:6644 - DIRECT/225.50.100.8 -
Dokumentatsiiata po proekta OpenVPN e suvsem izcherpatelna i
preporuchitelna. Kum sushtiiat ima i poshtenski list s arhiv.
.:
Vruzki
[1]
http://www.openvpn.net
[2] http://www.openssl.org/docs/
[3] http://www.oberhumer.com/opensource/lzo/
[4] http://sourceforge.net/mailarchive/forum.php?forum_id=8453
[5] http://www.kernel.org/hg/linux-2.6/raw-file/d1f4bbb0befc/Documentation/networking/tuntap.txt
.: Prilozhenie
root@impala:pts/7
/opt/openvpn-2.0.9# openvpn --config cfg
Tue
Dec 12 11:36:08 2006
OpenVPN 2.0.9 i686-pc-linux [SSL] [LZO] built on Nov 11 2006
Tue Dec 12 11:36:08 2006 IMPORTANT: OpenVPN's default port number is
now 1194, based on an official port number assignment by IANA.
OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Tue Dec 12 11:36:08 2006 Control Channel Authentication: using
'priv/ta.key' as a OpenVPN static key file
Tue Dec 12 11:36:08 2006 Outgoing Control Channel Authentication: Using
512 bit message hash 'SHA512' for HMAC authentication
Tue Dec 12 11:36:08 2006 Incoming Control Channel Authentication: Using
512 bit message hash 'SHA512' for HMAC authentication
Tue Dec 12 11:36:08 2006 LZO compression initialized
Tue Dec 12 11:36:08 2006 Control Channel MTU parms [ L:1634 D:210
EF:110 EB:0 ET:0 EL:0 ]
Tue Dec 12 11:36:08 2006 Data Channel MTU parms [ L:1634 D:1450 EF:102
EB:135 ET:32 EL:0 AF:3/1 ]
Tue Dec 12 11:36:08 2006 Local Options hash (VER=V4): '90db4a0f'
Tue Dec 12 11:36:08 2006 Expected Remote Options hash (VER=V4):
'5b6da2ed'
Tue Dec 12 11:36:08 2006 NOTE: UID/GID downgrade will be delayed
because of --client, --pull, or --up-delay
Tue Dec 12 11:36:08 2006 UDPv4 link local: [undef]
Tue Dec 12 11:36:08 2006 UDPv4 link remote: 225.50.100.8:6644
Tue Dec 12 11:36:09 2006 TLS: Initial packet from 225.50.100.8:6644,
sid=199b7f24 c1ee9f76
Tue Dec 12 11:36:09 2006 VERIFY OK: depth=1,
/C=BG/ST=_/L=_/O=Example_Corp./OU=IT_Dept./CN=Example_Corp._VPN_designated_CA-2/emailAddress=admin@example.net
Tue Dec 12 11:36:09 2006 VERIFY OK: nsCertType=SERVER
Tue Dec 12 11:36:09 2006 VERIFY OK: depth=0,
/C=BG/ST=_/L=_/O=Example_Corp./OU=IT_Dept./CN=server/emailAddress=admin@example.net
Tue Dec 12 11:36:11 2006 Data Channel Encrypt: Cipher 'AES-256-CBC'
initialized with 256 bit key
Tue Dec 12 11:36:11 2006 Data Channel Encrypt: Using 512 bit message
hash 'SHA512' for HMAC authentication
Tue Dec 12 11:36:11 2006 Data Channel Decrypt: Cipher 'AES-256-CBC'
initialized with 256 bit key
Tue Dec 12 11:36:11 2006 Data Channel Decrypt: Using 512 bit message
hash 'SHA512' for HMAC authentication
Tue Dec 12 11:36:11 2006 Control Channel: TLSv1, cipher TLSv1/SSLv3
DHE-RSA-AES256-SHA, 2048 bit RSA
Tue Dec 12 11:36:11 2006 [server] Peer Connection Initiated with
225.50.100.8:6644
Tue Dec 12 11:36:12 2006 SENT CONTROL [server]: 'PUSH_REQUEST'
(status=1)
Tue Dec 12 11:36:12 2006 PUSH: Received control message:
'PUSH_REPLY,route 192.168.0.0 255.255.0.0,redirect-gateway
def1,route-gateway 192.168.0.156,ping 10,ping-restart 120,ifconfig
192.168.3.10 255.255.252.0'
Tue Dec 12 11:36:12 2006 OPTIONS IMPORT: timers and/or timeouts modified
Tue Dec 12 11:36:12 2006 OPTIONS IMPORT: --ifconfig/up options modified
Tue Dec 12 11:36:12 2006 OPTIONS IMPORT: route options modified
Tue Dec 12 11:36:12 2006 TUN/TAP device tap0 opened
Tue Dec 12 11:36:12 2006 /sbin/ifconfig tap0 192.168.3.10 netmask
255.255.252.0 mtu 1500 broadcast 192.168.3.255
Tue Dec 12 11:36:12 2006 /sbin/route add -net 225.50.100.8 netmask
255.255.255.255 gw 10.0.0.1
Tue Dec 12 11:36:12 2006 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0
gw 192.168.0.156
Tue Dec 12 11:36:12 2006 /sbin/route add -net 128.0.0.0 netmask
128.0.0.0 gw 192.168.0.156
Tue Dec 12 11:36:12 2006 /sbin/route add -net 192.168.0.0 netmask
255.255.0.0 gw 192.168.0.156
Tue Dec 12 11:36:12 2006 GID set to nobody
Tue Dec 12 11:36:12 2006 UID set to nobody
Tue Dec 12 11:36:12 2006 Initialization Sequence Completed
root@impala:pts/5
~# traceroute
google.com
traceroute:
Warning: google.com
has multiple addresses; using 64.233.167.99
traceroute to google.com (64.233.167.99), 30 hops max, 38 byte packets
1 192.168.0.156 (192.168.0.156) 77.031 ms
37.725 ms 37.310 ms
2 rtr.example.net (225.50.100.1) 56.517 ms
44.999 ms 45.874 ms
...
root@vpndial:pts/0
~# cat openvpn-status.log
OpenVPN
CLIENT LIST
Updated,Thu Dec 7 00:48:40 2006
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
client1,224.100.200.191:63402,99624,1415849,Thu Dec 7 00:42:14
2006
client2,236.32.2.7:43495,739726,130506933,Wed Dec 6 12:58:40 2006
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
4a:5e:ca:f3:3c:67,client1,224.100.200.191:63402,Thu Dec 7
00:48:03 2006
56:c7:1f:65:5d:d1,client2,236.32.2.7:43495,Wed Dec 6 12:58:41 2006
GLOBAL STATS
Max bcast/mcast queue length,122
END
Posledniiat
fail se aktualizira na vseki 60 sek.