VPN siete s OpenVPN (4)

VPN siete s OpenVPN (4)
02.12.2008 10:40 | Články | Jaroslav Imrich
V dnešnej časti sa zoznámime s významom pojmu PKI a pozrieme sa bližšie na konfiguráciu OpenVPN s certifikátmi.

1. Asymetrické šifrovanie a elektronický podpis

V jednej z predchádzajúcich častí seriálu som spomínal, že asymetrické šifry používajú kľúčový pár (napr. RSA) pozostávajúci z privátnej a verejnej časti a že dáta zašifrované verejným kľúčom je možné dešifrovať len privátnym kľúčom a naopak. Pre ľahšie pochopenie významu certifikátov sa najskôr zameriame na pojem elektronický podpis. Veľmi zjednodušene je možné povedať, že elektronický podpis je dátová štruktúra alebo súbor, ktorý obsahuje hash dokumentu zašifrovaný pomocou privátneho kľúča podpisujúcej osoby.

Predpokladajme, že Alice vlastní kľúčový pár a chce elektronicky podpísať dokument. Musí teda vypočítať hash (napr. SHA1) tohto dokumentu a výsledok zašifrovať pomocou svojho privátneho kľúča. Pôvodný dokument pošle Alice spolu s podpisom Bobovi e-mailom.

Ak chce mať Bob istotu, že dokument, ktorý dostal e-mailom naozaj pochádza od Alice, musí overiť jej elektronický podpis. To znamená, že vypočíta hash prijatého dokumentu pomocou rovnakého algoritmu aký použila Alice, čo je v tomto prípade SHA1. Následne použije Bob verejný kľúč Alice na dešifrovanie hashu dokumentu z elektronického podpisu, ktorý vytvorila Alice svojím privátnym kľúčom. Ak je Bobom vypočítaný hash dokumentu zhodný s hashom dešifrovaným z elektronického podpisu, Bob môže zodpovedne prehlásiť, že dokument pochádza od Alice a nebol cestou k nemu nikým pozmenený.

Z predchádzajúceho textu je možné získať základnú predstavu o elektronickom podpise, no nezodpovedanou otázkou ostáva, ako sa dostal verejný kľúč Alice k Bobovi. Ak by ho Alice poslala Bobovi e-mailom, mohol by ho cestou niekto vymeniť za iný verejný kľúč a Bob by dokumenty podpísané útočníkom považoval za dokumenty pochádzajúce od Alice. Je teda veľmi dôležité sprostredkovať medzi zúčastnenými stranami výmenu verejného kľúča dôveryhodným spôsobom. V tomto jednoduchom príklade by dôveryhodný spôsob mohol vypadať tak, že Alice donesie Bobovi svoj verejný kľúč osobne na USB kľúči.

Predstavme si ale, že chceme používať elektronický podpis (asymetrické šifrovanie) v oveľa väčšom merítku. Napríklad v organizácii, ktorá má stovky zamestnancov. Ak by sme použili spôsob výmeny verejných kľúčov osobným prenosom na USB kľúči, musel by každý zamestnanec odniesť svoj kľúč všetkým svojim kolegom. To by znamenalo, že zamestnanci by nerobili nič iné, iba by si medzi sebou vymieňali verejné kľúče. A to nepočítame s tým, že pri prezradení alebo strate privátneho kľúča by si zamestnanec musel vygenerovať nový kľúčový pár a opäť rozdistribuovať nový verejný kľúč.

Riešení tohto problému je viacero. GnuPG sa ho snaží riešiť princípom tzv. pavučiny dôvery (z angl. web of trust), no v praxi oveľa viac bežný a rozšírený je princíp PKI (Public Key Infrastructure) u nás často nazývaný infraštruktúrou verejného kľúča.

2. PKI

Aby sme zabránili chaosu pri výmene verejných kľúčov modelom "každý s každým", poveríme jedného zamestnanca evidenciou verejných kľúčov všetkých ostatných - spravíme z neho certifikačnú autoritu (ďalej len CA). Úlohou tejto CA bude dôveryhodným spôsobom zozbierať verejné kľúče všetkých zamestnancov a podpísať ich svojim privátnym kľúčom - vydať certifikáty.

Ak bude niekto chcieť overiť podpis dokumentu vytvorený certifikátom ktoréhokoľvek zamestnanca, použije verejný kľúč CA na overenie pravosti verejného kľúča zamestnanca (overí podpis CA na certifikáte zamestnanca) a až potom overí podpis samotného dokumentu. Všetci zamestnanci teda budú potrebovať dôveryhodným spôsobom získať iba verejný kľúč (certifikát) CA.

Certifikát bežne obsahuje unikátne sériové číslo, identifikáciu vlastníka kľúčového páru tzv. Subject, verejný kľúč, špecifikáciu platnosti certifikátu (zvyčajne 1 rok) a tiež účel, na ktorý môže byť používaný. V prípade, že dôjde k prezradeniu privátneho kľúča zamestnanca alebo zamestnanec ukončí s firmou pracovný pomer, CA pridá sériové číslo jeho certifikátu na zoznam zrušených certifikátov - CRL (Certificate Revocation List). Pri overovaní podpisu je preto vždy potrebné okrem kontroly pravosti certifikátu skontrolovať aj jeho platnosť voči CRL.

Osobne za najväčší problém PKI považujem preukázateľnosť dôveryhodnosti CA, čo je vec, ktorá sa bohužiaľ nedá vyriešiť technologicky. Certifikačné autority síce svoje privátne kľúče uchovávajú v bezpečnom úložisku (kryptografický hardvér podobný čipovej karte), ale ak spravia napríklad pri overovaní identity žiadateľa o certifikát vedome alebo nevedome chybu či výnimku, má to negatívny dopad na všetkých používateľov PKI dôverujúcich tejto autorite.

3. Certifikačná autorita s gnoMint

Predpokladám, že základné pojmy ako PKI, certifikát, CA alebo CRL sú z predchádzajúceho textu jasné, a tak sa môžeme smelo pustiť do vytvorenia vlastnej PKI infraštruktúry. Asi nikomu netreba predstavovať aplikáciu OpenSSL, ktorá je de facto štandardným riešením pokiaľ sa jedná o vydávanie certifikátov a prevádzkovanie jednoduchej CA. Balík OpenVPN tiež obsahuje sadu skriptov s názvom EasyRSA, ktoré prácu s OpenSSL výrazne uľahčujú.

Osobne však na správu CA preferujem grafické nástroje, kde je ponuka tiež široká. Môžete sa napríklad rozhodnúť pre multiplatformovú aplikáciu XCA využívajúcu knižnicu OpenSSL a grafický toolkit Qt, alebo môžete siahnuť po aplikácii gnoMint, ktorá je grafickou nadstavbou nad knižnicou GnuTLS a využíva grafický toolkit GTK.

Nech už sa rozhodnete pre ktorúkoľvek zo spomínaných aplikácií, pre ďalší postup podľa tohoto článku budete potrebovať vytvoriť self-signed certifikačnú autoritu, vydať certifikáty pre jeden server a dvoch klientov, zrušiť certifikát jedného klienta a vygenerovať CRL.

Pôvodne som chcel na tomto mieste popísať proces vytvorenia a prevádzky CA s aplikáciou gnoMint pomocou screenshot-ov, no kvôli značnej rozsiahlosti som od tohto zámeru upustil a pripravil som radšej video. K dispozícii sú tiež anglické a slovenské titulky, ktoré je nutné manuálne zapnúť v pravom dolnom rohu videa.

 

 

Ak ste postupovali podľa videa a vydali ste všetky potrebné certifikáty, mali by ste mať k dispozícii nasledovné súbory:

openvpnca.cerCertifikát CA v PEM formáte
openvpnca.crlZoznam zrušených certifikátov CA v PEM formáte
192.168.1.1.keyPrivátny kľúč servera v nešifrovanom PEM formáte
192.168.1.1.cerCertifikát servera v PEM formáte
client1.keyPrivátny kľúč Klienta 1 v nešifrovanom PEM formáte
client1.cerCertifikát Klienta 1 v PEM formáte
client2.keyPrivátny kľúč Klienta 2 v nešifrovanom PEM formáte
client2.cerCertifikát Klienta 2 v PEM formáte

4. OpenVPN a certifikáty

Konfigurácia OpenVPN s certifikátmi je podobná ako pri statickom kľúči s tým rozdielom, že každá zo zúčastnených strán používa svoj vlastný privátny kľúč a certifikát. Rád by som upozornil, že v nasledujúcom texte už nebudem uvádzať podrobnosti typu kam uložiť konfiguráciu, ako to celé spustiť, ako otestovať či je VPN sieť funkčná alebo kde nájsť chybové hlásenia ak niečo nefunguje. Odpoveď na všetky uvedené otázky je totiž možné nájsť v predchádzajúcich dieloch seriálu.

Súborom, ktoré obsahujú privátne kľúče je potrebné nastaviť prístupové práva tak, aby ich mohol čítať iba používateľ root. Na serveri je ešte potrebné vygenerovať súbor s parametrami pre Diffie-Hellman Key Agreement Protocol (ďalej len Diffie-Hellman). Aj keď je tento súbor možné vygenerovať priamo v aplikácii gnoMint, vo videu som túto aktivitu zámerne vynechal, pretože so samotným PKI priamo nesúvisí. Potrebný súbor je možné vygenerovať pomocou aplikácie OpenSSL príkazom:

root@server:~# openssl dhparam -out dh.pem 2048

Konfigurácia OpenVPN servera bude nasledovná:

# Konfiguracny subor VPN servera
local 192.168.1.1
dev tun
server 10.1.1.0 255.255.255.0
ca openvpnca.cer
cert 192.168.1.1.cer
key 192.168.1.1.key
#crl-verify openvpnca.crl
dh dh.pem
push "redirect-gateway"
comp-lzo
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
user openvpn
group openvpn
daemon

Väčšina parametrov je známa z predchádzajúcich dielov. Nový je napríklad parameter "server" nasledovaný špecifikáciou siete, ktorý v tomto konkrétnom prípade zabezpečí, že server bude klientom automaticky prideľovať IP adresy z rozsahu 10.1.1.0/24. Konfiguračná direktíva "ca" určuje cestu k certifikátu CA, ktorej klienti budú serverom akceptovaní, direktíva "cert" cestu k certifikátu servera, direktíva "key" cestu k privátnemu kľúču servera a direktíva "crl-verify" cestu k zoznamu zrušených certifikátov. Direktívu "crl-verify" zatiaľ necháme zakomentovanú. Direktíva "dh" určuje cestu k súboru s parametrami pre Diffie-Hellman. Parameter "push" nasledovaný konfiguračnou direktívou "redirect-gateway" sa postará o to, že táto direktíva bude posielaná klientom a tí ju použijú vo svojej konfigurácii. Takýmto spôsobom sa dá zo servera centrálne upravovať napríklad smerovacia tabuľka klientov.

Konfigurácia klientov bude nasledovná:

# Konfiguracny subor VPN klienta
client
dev tun
remote 192.168.1.1
tls-remote 192.168.1.1
ca openvpnca.cer
cert client1.cer
key client1.key
comp-lzo
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
user openvpn
group openvpn
daemon

Aj v tomto prípade je väčšina direktív už známa. Novinkou je direktíva "client", ktorá o.i. povoľuje prijímanie "push" parametrov od servera. Význam direktív "ca", "cert" a "key" je rovnaký ako pri serveri s tým rozdielom, že na klientskej stanici určuje cesty k príslušným súborom patriacim Klientovi 1. Nad významom direktívy "tls-remote" budeme ešte polemizovať v ďalšej sekcii článku, no pre úplnosť uvediem, že je nasledovaná hodnotou položky commonName zo subject-u certifikátu servera a zabezpečuje, že sa klient odmietne pripojiť na server, ktorého certifikát nevyhovie tomuto kritériu.

S obdobnou konfiguráciou by sa mal úspešne pripojiť aj Klient 2. Ak ste ale pozorne sledovali video a postupovali podľa neho pri vydávaní certifikátov, tak ste si určite všimli, že certifikát Klienta 2 bol certifikačnou autoritou zrušený, a preto by mal byť tomuto klientovi odmietnutý prístup do VPN siete. Odkomentujte teda direktívu "crl-verify" v konfigurácii servera, reštartujte na ňom aplikáciu OpenVPN a pokúste sa znova pripojiť s certifikátom Klienta 2. Ak ste nikde neurobili chybu, Klientovi 2 bude prístup do VPN siete naozaj odmietnutý.

5. Nie je všetko zlato čo sa blyští

Pri používaní PKI si treba v prvom rade uvedomiť, že je len nadstavbou nad asymetrickým šifrovaním. Kľúčové páry používané klientom, serverom či samotnou autoritou sa principiálne nijako nelíšia, a preto je napríklad možné použiť certifikát klienta v úlohe certifikačnej autority alebo servera. Akousi záplatou, ktorá má zabrániť takémuto "zneužívaniu" kľúčov je špecifikovanie účelu, na ktorý môže byť certifikát používaný. Do klientskych certifikátov sa teda zvyčajne pridáva rozšírenie "Extended key usage" s hodnotou "TLS Web client authentication" a do serverových certifikátov "TLS Web server authentication".

Ak však aplikácia pracujúca s certifikátmi tieto rozšírenia ignoruje, či už zámerne alebo nedopatrením, môže to mať negatívny vplyv na bezpečnosť. Môžete si to jednoducho vyskúšať tak, že spustíte OpenVPN server s privátnym kľúčom a certifikátom Klienta 1 a pokúsite sa naň pripojiť s privátnym kľúčom a certifikátom Klienta 2. Ak vynecháte direktívu "tls-remote", spojenie bude bez najmenších problémov nadviazané. Aplikácia OpenVPN totiž bez dodatočnej konfigurácie nekontroluje účel, na ktorý bol certifikát vydaný. Vlastník certifikátu Klient 1 by teda mohol s vysokou pravdepodobnosťou úspešne vykonať man-in-the-middle (ďalej len MITM) útok na Klienta 2 a naopak. Je viacero spôsobov ako tomuto útoku zabrániť, no všetky bohužiaľ vyžadujú, aby sa používateľ orientoval v problematike PKI či sieťových útokov na vyššej než bežnej úrovni.

Prvá možnosť je pomocou direktívy "tls-remote" do konfigurácie klienta napevno zadať commonName certifikátu servera. Pre účely tohto článku a siete s jedným serverom je toto riešenie postačujúce, no môže sa stať zásadným problémom, ak by ste potrebovali vytvoriť cluster rozkladajúci zátaž na viacero serverov.

Druhá možnosť je definovať účel použitia certifikátu pomocou neštandardného rozšírenia "Netscape Certificate Type", ktoré OpenVPN radu 2.0 dokáže používať. Ako už názov tohto rozšírenia napovedá, jedná sa o proprietárne riešenie spoločnosti Netscape, ktorému by sa malo v dnešnej dobe radšej vyhýbať. Preto som ho nepoužil ani v tomto článku.

Tretia a pravdepodobne "najčistejšia" možnosť je vydávať certifikáty pre servery samostatnou certifikačnou autoritou. Toto riešenie zabraňuje spomínanému MITM útoku a neznamená problém ani v prípade, že sa rozhodnete použiť cluster. Ak pre vás PKI nie je cudzím pojmom, určite viete, že je dobrou praktikou nepoužívať jednu certifikačnú autoritu na všetko, ale vytvoriť sústavu autorít s odlišnými politikami, ktoré vydávajú rôzne typy certifikátov. Táto skutočnosť často uniká dokonca aj komerčným spoločnostiam poskytujúcim certifikačné služby napriek tomu, že sa pravdepodobne jedná o najlepšie riešenie.

6. Záver

Piaty diel tohto seriálu bude venovaný viacfaktorovej autentizácii a použitiu čipových kariet ako bezpečného úložiska privátnych kľúčov. Tento diel bude zároveň posledný, a preto sa prosím ozvite v diskusii pod článkom ak si myslíte, že som niektorej téme nevenoval dostatočný priestor. Pokúsim sa to napraviť :)



    • pekny serial 02.12.2008 | 12:27
      kain   Návštevník
      velmi pekny serial, potesilo ma hlavne ze konecne niekto spomenul bezpecnostne problemy na ktore sa vseobecne v tutorialoch zabuda.
      Tesim sa na dalsi diel.
      • Re: pekny serial 05.12.2008 | 11:30
        Nipo   Návštevník
        Pridavam sa ... len tak dalej a drzim palce
    • Ako ziskat certifikat pre domenu mozilla.com :) 24.12.2008 | 17:10
      luzr   Návštevník
    • priklad 28.12.2008 | 19:34
      Avatar Branislav Poldauf Ubuntu LTS, Debian stable  Používateľ
      serial velmi pekny a ku koncu pre mna velmi poucny (konecne viem asi ako sa na skole prihlasujeme pomocou certifikatou na siet)

      ale chcel by som jednu vec,viac nazornych prikladov,
      napriklad nazorny priklad pre takuto modelovu situaciu (alebo aj ine) by mi velmi pomohol

      domacnost s pripojenim k internetu (povedzme aDSL o t-comu) s wifi routrom a 3 pc v domacej sieti (vsetky pripojene cz wifi)

      dalej uzivatel s notebookom ktory sa chce pripojit do danej domacej siete (zdielanie dokumentov, remote desktop)

      je to moja konkretne situacia a zatial sa mi nedari uspesne pripojit sa na remote desktop (co by som asi najviac potreboval) doma pouzivam VNC a pc su XP aj ubuntu
      Linux: the operating system with a CLUE... Command Line User Environment
    • nejde net 21.02.2009 | 18:39
      hahiho   Návštevník
      naozaj velmi perfektne howto :D
      i ked som to nenastavoval len podla tohto navodu uz to bezi :D
      a chcel by som sa hned aj na nieco opytat co mi dost prekaza
      - ako server mam jeden pc kde bezi aj openvpn server (192.168.1.2/24)
      - siet v ktorej je server je dalsi pc (192.168.1.3/24)
      - tato siet (192.168.1.0/24) je pripojena do internetu cez router (192.168.1.1/24)
      - ak sa z pc 192.168.1.3/24 pripojim na openvpn siet (10.1.1.0/24) vypadne mi pripojenie na internet (riesenie su dve sietovky ale to nechcem :))

      v openvpn vyuzivam tun0 zariadenie cize NATovanie

      a este styri male problemiky
      1. nejde mi pingovat pc => server opacne to funguje
      2. preco mi nastavuje server aj predvolenu branu na pc na openvpn zariadeni na adresu ktora je volna (10.1.1.5)
      3. zakazdym co sa pripojim cez openvpn na server dostanem inu ip. co sa stane ak ip dojdu? zacne ich pridelovat odznova?
      4. mozem na openvpn zariadeni na pc nastavit staticku ip?

      dakujem za radu
      • Re: nejde net 22.02.2009 | 01:08
        Avatar Jaroslav Imrich Ubuntu  Používateľ
        K prvej casti:

        Dve sietovky urcite nie. Ak ti nejde net, skontroluj smerovaciu tabulku na klientskom systeme (prikaz route). Po pripojeni do VPN sa ti pravdepodobne zmenil zaznam pre default gateway - deje sa to napr. pri pouziti direktivy "redirect-gateway" alebo pri dalsich direktivach suvisiacich so smerovanim. Zamysli sa nad tym, ci tie direktivy naozaj potrebujes alebo uprav nastavenia servera tak, aby poskytoval internetovu konektivitu aj VPN klientom.

        > 1. nejde mi pingovat pc => server opacne to funguje

        Firewall na serveri ?

        > 2. preco mi nastavuje server aj predvolenu branu na pc na openvpn zariadeni na adresu ktora je volna (10.1.1.5)

        Dovod zmeny brany som popisal vyssie - pravdepodobne direktiva "redirect-gateway". Zdovodnenie "volnej" IP najdes v OpenVPN HowTo od textu "Specifically, the last octet in the IP address..." dalej.

        > 3. zakazdym co sa pripojim cez openvpn na server dostanem inu ip. co sa stane ak ip dojdu? zacne ich pridelovat odznova?

        Ak spojenim "IP dojdu" myslis to, ze bude pripojenych tolko klientov aby boli naraz obsadene vsetky adresy, tak vtedy sa novy klient nepripoji. V takom pripade treba pouzit vacsi adresny rozsah.

        > 4. mozem na openvpn zariadeni na pc nastavit staticku ip?

        Mozes ak upravis aj konfiguraciu servera. Pozri si vsak radsej direktivu "client-config-dir" tiez v OpenVPN HowTo a posuvaj tomu klientovi vzdy rovnaku IP adresu zo servera. Ziskas tak moznost rekonfigurovat to priamo zo servera bez zasahu na klientovi.

        Len pre istotu pridavam link na IP kalkulacku. Pravdepodobne ju budes potrebovat :)
        We can't solve problems by using the same kind of thinking we used when we created them - A. Einstein
        • Re: nejde net 26.03.2009 | 15:36
          hahiho   Návštevník
          diki za odpovede idem to poskusat dam vediet ako som dopadol :D
    • riesenie :D 26.03.2009 | 17:05
      hahiho   Návštevník
      1. uz hladam prikaz pre iptables :D
      2. z configu vpn servera som odstranil direktivu
      push "redirect-gateway" a uz so smerovanim na internet nie je problem
      3. myslel som to trochu inak :D
      ked som sa s klientom pripojil prvy raz dostal som ip 192.168.2.3
      ked som sa pripojil druhy raz tak som dostal ip 192.168.2.4
      teraz mam napr ip 192.168.2.7
      a ja jednoducho chcem klientom nastavovat pevnu ip najlepsie ak by bola definovana v configu klienta

      thx :D
      • Re: riesenie :D 18.06.2009 | 00:47
        hahiho   Návštevník
        no uz mam vsetky problemy vyriesene az na jeden :D
        chcem definovat ip adresy klientov v ich configu
        (mam to tak ze vsetci pouzivaju jeden kluc (tusim ze to je direktiva "duplicate-certificates")). je to tak ze casto sa meni pocet klientov vo vpnke a su to stale iny ludia :D a tak je dost neprakticke kazdemu generovat certifikat a kluc a pridelovat im ip adresy preto by som potreboval aby boli definovane v configu klienta.
        thx :D