ot vm(18-12-2006)

reiting (19)   [ dobre ]  [ zle ]

Printer Friendly Variant za otpechatvane

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.





<< | >>