Сигурност на Виртуални Частни Мрежи и прилагането им в малки и средни предприятия

OpenVPN има няколко основни технологични качества, които много хора подценяват, но те пестят много поддръжка и откриват много нови възможности. Първото качество е, че е Open. Това значи, че е free, разпространява се на source. Работи и покрива всякакви платформи (освен телефони). Няма разлика между клиент и сървър. Всеки клиент, може да е сървър (и да се закачват към него други клиенти), и всеки сървър може да е клиент .

OpenVPN използва TCP или UDP сесия, за да реализира тунела си до сървъра. Тук може да звучи не толкова тържествено колкото използването на IPSec да речем, но реализирането на VPN на 6-ти и 7-ми слой по OSI модела, а не на 3-ти има съществени предимства. Много незапознати хора си мислят, че в Интернет света всичко е прекрасно, че всичко се развива логично, че протоколите са перфектни, няма дефекти, няма грешки, няма войни между производителите, и всичко е съвместимо. Мислят си, че в Интернет света съществува голяма дружба и че всички се държат за ръце, и се обичат, малките производители обичат големите, а големите още повече, и няколкократно обичат по-малките. Това разбира се не е така.

Обаче поради свършването на IP адресите и бавния (поради бизнес причини) development на IPv6 правят така, че NAT е задължителният механизъм за връзка към Интернет на практически всяка фирма. Това значи, че ако сте на гости на някой във фирмата му, и искате да отворите VPN към вашата, и вашият VPN клиент използва технологии като IPSec или PPTP/L2TP (GRE), най вероятно няма да можете да отворите повече от една сесия (ако сте двама колеги), а вероятно дори и една. Да, някой Firewall-и (не и Cisco, предимно Linux базирани) поддържат инспекция на PPTP тунелите и позволяват пускането на повече от един (чрез инспектиране на Session ID-то в GRE тунела), или допускат IKE на 500 порт едновременно с IKE на 4500 порт, за да се осъществи NAT-T negotiation-а и да мине NAT-T на IPSec. Но пак да спомена – масовия Windows не поддържа NAT-T. Масовите Firewall-и не позволяват повече от една (дори и една) GRE сесия. Да не говорим за друг масов случай – параноята, която кара администраторите на някой мрежи да търсят механизми да стопират възможността за отваряне на VPN сесии от вътрешната мрежа на фирмата, към някъде навън, за да не може чуждия гост, да открадне голямата фирмена тайна. Отделно някой фирми използват Proxy-та и през тях не минава нито GRE (PPTP, L2TP), нито IPSEC.

OpenVPN няма нито един от тези проблеми. Той минава през UDP или TCP. Може да бъде скрит зад HTTP request или каквото и да е. Може да работи с всеки Source и Destination порт. Може да го пуснете на DNS порта, и да изглежда като DNS заявка. Може да мине през 80-ти порт, през нормално или Transparent Proxy, изглеждащ като HTTP заявка. Може да мине през Socks (за разлика от Cisco Easy VPN, Juniper VPN, PPTP/L2TP/IPSec клиента в Windows). Това значи, че практически няма случай, ако сте в мрежа, където да има достъп до нещо от интернет каквото и да е то, и да не се закачите към фирмената си вътрешна мрежа. Ако конфигурационният файл е направен добре, клиента може да пробва автоматично 4-5 различни начина за свързване.
OpenVPN отваря логически интерфейс за всеки тунел. Можете да се пусне повече от един VPN клиент едновременно, свързан към различна мрежа. Така, ако правим поддръжка и се намираме някъде в чужбина, може да сме закачени едновременно и към фирмената ни мрежа, и към мрежата на клиента, на който искаме нещо да му конфигурираме.

OpenVPN поддържа автоматична конфигурация. Това звучи странно, защото на фона на съвременните VPN клиенти, това е нещо нормално, но все пак има много такива, които не поддържат автоматична конфигурация. Например IPSEC не поддържа стандартно. Затова и има частни разширения (като това на Cisco през XAUTH в IKE-то) или изпълнения като пускане на IP върху PPP върху L2TPv2 върху IPSEC върху IP (Juniper и Microsoft, поне е сравнително стандартно). На OpenVPN можете да конфигурират компресия, криптиращи и автентикационни протоколи, автентикация, мрежи, приоритети, DNS и Wins сървър, както и всяка DHCP възможна опция.

Една от екстрите е възможността да слагаме приоритети на конфигурационните параметри в случай на конфликт. Така ако пуснем VPN-а докато се намираме във вътрешна мрежа, ако не сме с OpenVPN, най вероятно ще настане loop, мрежовият достъп ще изчезне, или VPN клиента ще изчезне с досадно съобщение (заради конфликт на IP адреси, или опит на тунела да си прекара собствения трафик през тунела) или просто няма да се отвори. Това е особено забележим проблем с Cisco VPN клиент под Windows. OpenVPN има механизъм как тези проблеми да бъдат решени незабележимо от страна на потребителя. Това значи, че администратора може да го инсталира (примерно openvpn-gui от http://www.openvpn.se) така, че да се стартира автоматично, винаги, и потребителя без значение къде се намира – в офиса или навън, ще достъпва офисните ресурси по скрит и незабележим за него, но в същия момент сигурен начин. Служителите на фирмата може дори да не знаят, че имат VPN клиент.
OpenVPN поддържа огромен набор операционни системи – Windows (включително 95), всякакъв UNIX, върху всякакви платформи и процесори, Embedded Systems (като embedded Linux върху WRT54GL на Linksys), MACOS и какво ли не. Това разнообразие е неприсъщо за друга технология, освен PPTP.
OpenVPN поддържа VPN сесия с Ethernet Bridging, а не само Routed VPN сесия. Повечето VPN клиенти изискват VPN сесията да бъде с различни IP адреси, и трафика към нея да се маршрутизира на Layer3 по OSI модела. Това обаче създава огромни проблеми, особено в по-големи фирми с по-сложни конфигурации. Налага се да се заделят специално IP адреси за VPN, да се провизионират по различен начин (без значение дали се ползват или не), и някак си да бъдат маршрутизирани към VPN сървъра. Което пък поставя ограничения къде в мрежата може да бъде VPN сървъра и т.н. При OpenVPN всички тези проблеми са решими, но има и по-хитър начин – Bridged клиента. Можете да направите така, че компютъра във VPN сесия да изглежда така все едно се намира в мрежата ви директно, да си взима IP адрес и конфигурация (дори и чрез 802.1x) по стандартния начин, от вашия DHCP сървър, и ръководенето и следенето на това какво става да е централизирано, имайки в добавка и всички други споменати до сега предимства.

OpenVPN поддържа автентикация със сертификати, пароли или трети механизъм. Може да бъде разширен със скриптове, които да се стартират автоматично от страна на сървъра или клиента при закачване и да правят нещо допълнително, непредвидено в протокола. А и се разработва изключително активно. Може да оторизира не само в посока клиент-сървър, но и клиента може да оторизира сървъра и така да се пази от man in the middle атаки нещо, което е принципен проблем за всеки VPN.

За по-лесно обяснение на идеята за виртуализация на мрежовия интерфейс, тръгваме от приказ на OSI модела.

5. Приложен, представителен, сесиен слой

DHCP • DNS • FTP • HTTP • IMAP4 • IRC • MIME • POP3 • SIP • SMTP • SNMP • SSH • TELNET • BGP • RPC • RTP • RTCP • TLS/SSL • SDP • SOAP • L2TP • PPTP •

4. Транспортен слой

TCP • UDP • DCCP • SCTP • GTP •

3. Мрежов слой

IP (IPv4 • IPv6) • ARP • RARP • ICMP • IGMP • RSVP • IPSec •

2. Канален слой

ATM • Ethernet • FDDI • Frame Relay • GPRS • PPP

1. Физически слой

Ethernet fizički sloj • ISDN • Modems • PLC • RS232 • SONET/SDH • G.709 • Wi-Fi •

Tun интерфейса представя виртуална мрежова карта, в реалността подобна с устройствата които свързват две точки на отделни мрежи. (на пример свързване на две мрежи с наета Т1 връзка). Но, така реализираното устройство няма да насочва данните към физическия слой, а към програмата която чете и пише приетите пакети в двете посоки.

Първия Tun драйвер е написан от Maxim Krasnyansky 1999 година.

Tap интерфейса е подобен, само че се използва за по-комплицирани мрежови топологии, за разлика от комуникацията точка-до-точка, където се използва tun.

Пример:

На компютри А и Б са инсталирани tun интерфейси и мрежова апликация с два процеса. Първият процес изпраща данни от tun интерфейса на мрежата, а другия процес обратно. Ако апликацията се стартира на два компютъра свързани с някакъв физически интерфейс, може да се каже, че е направен обикновен VPN без защита.

Основната идея на всички достъпни VPN решения е защита от пасивни и активни атаки. Пасивен хакер е този който подслушва канала за комуникация, но не влияе върху информацията.

Активният хакер може да се вмъкне в комуникационния канал, да добавя, променя или да изтрива данни в комуникационния канал. Активният хакер обикновено се нарича „man in the middle“ (човек в средата).

По-голямата част от потребителите смята, че сигурността на VPN се състои от множество на алгоритми за криптиране с които се решава проблема на подслушване. От гледна точка на сигурността, VPN трябва да реши и по-важен проблем, а това е идентификация на потребителя и блокирането на активните атаки. Това означава подписване на всеки пакет, така че получателя да знае, че пакетът идва от проверен източник.

OpenVPN използва HMAC (keyed-hash message authentication code) функция за идентификация на пакет. HMAC принадлежи към подгрупата на MAC (message authentication code) функция и използва компресия (MD5 или SHA) и ключ за защита.

Дефинираме функцията HMAC като:

HMAC_K (m) = h ((K ⊕ opad) || h (K ⊕ ipad ) || m)

където:

K - ключ за шифриране с добавени нули на дължината на бита във блок функцията за компресия. (128 битова за MD5, 160 битова за SHA-1)

ipad (inner pad) - шестнадесетична константа, дължината на ключовете;

opad = 0x5c5c5c ... 5c5c

opad (outer pad) - шестнадесетична константа, дължината на ключовете;

|| - функция за свързване на текст

⊕ - логическа функция XOR

Конструкцията и анализа на HMAC алгоритъма за първи път е представен от: Mihir Bellare, Ran Canetti, Hugo Krawczyk , 1996 година.

HMAC идентификацията на комуникационните пакети не е достатъчна за защитата от така наречените “повтарящи атаки” (replay attack). На пример: Хакерът може да запише за него интересния трафик (на пр. Парична трансакция) и да го възпроизвежда. Доколко системата няма защита от такава атака, възможно е да има низа от такива съмнителни трансакции.

Решение на този проблем е с добавяне на единствени временски етикети на всеки пакет. Тогава получателят на данните трябва да внимава да не приеме два пъти пакетите със същите временни етикети. OpenVPN използва SWA алгоритъма (Sliding Window Algorithm) за предотвратяване на активни атаки с повторение.

За криптиране OpenVPN използва готова OpenSSL библиотека с функции. При това е възможно да се използват статични ключове които се обменят между участниците в комуникацията, в по-простите изпълнения. Но, възможно е използването на RSA инфраструктура на публични ключове за справяне с чувствителната точка в HMAC идентификацията, а това е обмяна на ключовете.

4. 
   ПРАКТИЧЕН ПРИМЕР: СВЪРЗВАНЕ НА ДВА ОБЕКТА С ИЗПОЛЗВАНЕ НА СТАТИЧНИ КЛЮЧОВЕ
   

Може да се види, че на компютъра е инсталирана нова мрежова карта: Win32 Adapter V8. Новата мрежова карта представлява виртуално устройство, чрез което данните могат да преминат по два начина. Ако трафикът се пренасочва към съществуващата мрежова карта, вградена в компютъра това се нарича „bridge“ режим на работа. В противен случай всички настройки на виртуалния адаптер, които се извършват са като за „истинска“ мрежова карта със собствен IP адрес и това се нарича „router“ режим на работа.

Първо и основно настройване на сървъра се извършва с настройки вътре в конфигурационните файлове. За начало може да се използват шаблонни файлове, които се намират в папката: C:\ProgramFiles\OpenVPN\sample-config\ под името: sample.openvpn.txt, който се копира в папката C:\ProgramFiles\OpenVPN\config под името: server.ovpn.

Конфигурационния файл се отваря и се търси ред съдържащ текста: remote myremote

Ако искаме да разрешим достъп от точно определен адрес като на пример 89.185.223.34, тогава този ред би трябвало да изглежда: remote 89.185.223.34. Ако искаме да разрешим достъп от който и да е адрес, тогава или трябва да изтрием този ред или трябва да го коментираме с „ ; “ в началото.

По подразбиране цялата комуникация се извършва чрез UDP протокола и порта 1194. Ако искаме да е различно трябва да променим редовете, които започват с port (настройка на порта) и proto (избор на протокола).

След това се избира начина на връзка със сървъра. Ако искаме да свържем две мрежи от коментираме редът с текста: dev tap. В противен случай става свързване на няколко различни локации с една централна и тогава се избира редът: dev tun

За начало е по-простия вариант, свързване на две мрежи (в нашия пример на свързване на два компютъра с MS Windows XP операционни системи)

В този случай се генерира статичен ключ, с който се криптира комуникацията между двете локации.

В рамките на програмното меню се избира командата: Generate a static OpenVPN key, след което в папката C:\ProgramFiles\OpenVPN\config се създава 2048 битов ключ за криптиране на комуникацията под името key.txt. За да стане ключът активен, в конфигурационния файл трябва да се добави ред: secret key.txt. Остава още конфигурирането на два параметъра: verb и mute. Параметърът „verb“ определя колко подробно се отбелязва актуалното състояние на програмата в log файла. Минималната стойност е 0 (отбелязват се само грешките), а максималната е 11. Параметърът „mute“ дефинира колко пъти се опитва свързване отново, в случай, че първото свързване не е успешно.

Началният конфигурационен файл би трябвало да изглежда така:

dev tap

secret key.txt

persist-tun

ifconfig 10.0.20.1 255.255.255.0

verb 4

mute 10
Клиентът се настройва почти със същите параметри както и сървъра, с малки разлики. Така параметърът „remote“ на страната на клиента е публичния IP адрес на мрежата, на която се свързва. Също така обикновено на страната на клиента се поставя „ifconfig“ параметър, с който се дефинира IP адрес който клиента ще получи при свързването към отдалечената мрежа.

Тогава конфигурационният файл от страна на клиента трябва да изглежда така:

dev tap

secret key.txt

verb 4

mute 10
На края ще трябва да се реши по какъв начин ще се стартират приложенията на отдалечените компютри. Може да се използват routing или bridged режими на работа.

Ако операционната система на компютрите е Windows XP, свързването на мрежовите адаптери по този начин е много прост. От списъка на мрежовите адаптери се избира ТАР адаптера и съществуващата мрежова карта с комбинация от натиснат клавиш CTRL и левия бутон на мишката.

Избор на мрежови карти за свързване

Активира се десния бутон на мишката и се избира командата – Bridge Connections

Свързване на избраните мрежови карти

Резултатът е нова мрежова карта съставена от OpenVPN и „истинската“ мрежова карта.

Резултат от свързването на виртуалната и истинската мрежова карта

С двоен клик върху GUI иконата намираща се на десктопа се стартира OpenVPN на компютъра:

Икона за стартиране на OpenVPN

Резултатът е стартирането на нова системна картинка в лентата с инструменти:

Новата картинка в системната лента

В случай че активирате десния бутон на мишката върху картинката, дава се възможност за въвеждане на желания конфигурационен файл:

Ако всичко е добре настроено, резултатът е съобщение, че свързването е успешно и че е конфигурирана безплатна VPN връзка между две отделни мрежи свързани към обща подмрежа.

Използване на статичен ключ е много лесно за конфигуриране, но има сериозен недостатък. В случай на кражба на ключ, хакер може без затруднения да се вмъкне в канала за комуникация.Те също не могат да се прилагат за всички действия на удостоверяване на страна на сървъра (на пример допълнителна идентификация с парола).

За да се установи инфраструктура на публични ключове трябва да се дефинира CA център на сигурен компютър. В нашия пример, е възможно за тази цел да се използва компютър, който няма никакъв достъп до мрежата.

Генерирането на сертификата е описано в няколко точки:

1. 
   Проверява се версията на OpenSSL библиотеките на сървъра и клиента. Желателно е да са същите. Стартира се прозорец с командния ред и се избира папката:
   

Стартира се openssl.exe и след това се задава командата: version и на екрана се изписва версията на библиотеките.

2. 
   Настройват се данните за притежателя на генерираните сертификати. За да може това да се извърши, необходимо е да се стартира файла:
   

Резултатът е файл vars.bat, генериран в същата папка. Поставя се големината на ключа на 2048 бита и се настройват останалите параметри за генериране на пример:

set KEY_SIZE = 2048

set KEY_COUNTRY = MK

set KEY_PROVINCE = SR

set KEY_CITY = STRUMICA

set KEY_ORG = DELTA-V

set KEY_EMAIL = vetatoy@gmail.com

Стартира се vars.bat, a след него clean-all.bat за да се „изчисти“ листата с ключове.

3. 
   Създава се CA root certificat със стартирането на build-ca.bat. По време на генерирането е нужно да се впишат данните също като в файла vars.bat. За полето „Common Name“ може да се запише името на фирмата, която издава сертификата с добавяне на „-CA“ , както в примера.
   

Създаване на CA root certificate

Крайният резултат са файловете ca.cert и ca.key в папката :

C:\ProgramFiles\OpenVPN\easy-rsa\keys

ca.key e частен CA ключ и трябва да се пази на много сигурен компютър който няма достъп до мрежата.

Списък на генерирани CA root файлове

4. 
   След това се създава сертификат и частен ключ за VPN сървъра със стартиране на командата:
   

Вкарват се необходимите данни за издадените сертификати също като при създаването на публичния CA сертификат.

Резултатите от стартирането на командата са частен ключ и сертификат за сървър (server.key, server.crt), подписани с CA ключ, издадени за срок от 10 години. Срокът можем да контролираме с файла build-key-server.bat.


Създаване на сертификат и ключ за сървъра

5. 
   Създават се сертификати и ключове за клиентите, които ще се свързват със сървъра, със стартирането на:
   

На пример ако са три клиента (клиент1, клиент2, клиент3) , стартира се три пъти командата build-key.bat, за всеки клиент отделно:

build-key klient1

build-key klient2

build-key klient3

Резултатът е двойки ключове и сертификати за всеки клиент, в поддиректорията \keys.

6. 
   Генерира се Diffie Hellman параметър със стартирането на build-dh.bat. Резултатът е голям, случайно генериран прост брой, който се копира само на сървъра. Тази стъпка трае най-дълго.
   
7. 
   Добавя се допълнителна защита с генерирането на ta ключове, със стартирането на командата:
   

Резултатът е ключ за HMAC подписване на пакетите, с цел за допълнителна идентификация. Ключовете морът да се обменят със сървъра и клиента и да се копират в \keys.

Конфигурационните файлове се настройват както в примера със статичен ключ, но вместо статичен ключ се вписани имената на сертификатите и ключовете за сървъра и клиентите.

Пример на конфигурационния файл за сървъра:

dev tap

ca ca.crt

cert server.crt

key server.key

dh dh1024.pem

persist-tun

ifconfig 10.0.20.1 255.255.255.0

verb 4

Пример на конфигурационния файл на клиент, който се свързва от отдалечен IP адрес 89.185.213.205:

remote 89.185.213.205

dev tap

ca ca.crt

cert klient1.crt

key klient1.key

verb 4

mute 10