Univerza v Ljubljani
Fakulteta za raˇ cunalniˇ stvo in informatiko
Urban Suhadolnik
Implementacija programsko doloˇ cljivega roba omreˇ zja s tuneli
WireGuard
DIPLOMSKO DELO
UNIVERZITETNI ˇSTUDIJSKI PROGRAM PRVE STOPNJE
RA ˇCUNALNIˇSTVO IN INFORMATIKA
Mentor : izr. prof. dr. Mojca Ciglariˇ c Somentor : as. Miha Grohar
Ljubljana, 2021
besedilo, slike, grafi in druge sestavine dela kot tudi rezultati diplomskega dela lahko prosto distribuirajo, reproducirajo, uporabljajo, priobˇcujejo javnosti in pre- delujejo, pod pogojem, da se jasno in vidno navede avtorja in naslov tega dela in da se v primeru spremembe, preoblikovanja ali uporabe tega dela v svojem delu, lahko distribuira predelava le pod licenco, ki je enaka tej. Podrobnosti licence so dostopne na spletni strani creativecommons.si ali na Inˇstitutu za intelektualno lastnino, Streliˇska 1, 1000 Ljubljana.
Izvorna koda diplomskega dela, njeni rezultati in v ta namen razvita program- ska oprema je ponujena pod licenco GNU General Public License, razliˇcica 3 (ali novejˇsa). To pomeni, da se lahko prosto distribuira in/ali predeluje pod njenimi pogoji. Podrobnosti licence so dostopne na spletni strani http://www.gnu.org/
licenses/.
Besedilo je oblikovano z urejevalnikom besedil LATEX.
Kandidat: Urban Suhadolnik Naslov: Naslov diplomskega dela
Vrsta naloge: Diplomska naloga na univerzitetnem programu prve stopnje Raˇcunalniˇstvo in informatika
Mentor: izr. prof. dr. Mojca Ciglariˇc Somentor: as. Miha Grohar
Opis:
Z razvojem podroˇcja interneta stvari (IoT) se v omreˇzja priklaplja vse veˇc naprav, ki nimajo moˇznosti uporabe naprednih varnostnih mehanizmov. Po- dobno teˇzavo, ˇceprav iz drugih razlogov, zasledimo pri zastarelih ali podedo- vanih napravah. Raziˇsˇcite moˇznosti varovanja takˇsnih naprav in predlagajte moˇzne reˇsitve z uporabo programsko doloˇcljivega roba omreˇzja. Preuˇcite ob- stojeˇce tehnologije, ki reˇsujejo to teˇzavo, izpostavite njihove pomanjkljivosti in predlagajte, kako bi jih lahko odpravili. Izbrano idejo implementirajte in testirajte ter komentirajte moˇznosti za njeno praktiˇcno uporabo.
Title: Software defined perimeter implementation with WireGuard tunnels
My study path was a little longer than for most, so I have to thank more po- eple for who I am today. During my studies, I spent one year at TU Berlin.
I spent most of my time there in the networking department. I have to thank Theresa Enghardt for passing on to me her love for the IPv6. To my colleague Gordon Gidofalvy for teaching me everything I know today about Cisco and Juniper systems. We were group partners but you were always like a mentor to me. When I returned to Ljubljana, I still had my bachelors thesis left.
Without the support and endless patience of my thesis mentor izr. prof. dr.
Mojca Ciglariˇc and co-mentor as. Miha Grohar I would have not succeeded.
Finally, I would like to thank my family for their unwavering support in wri- ting my thesis. Without all of you, I wouldn’t be who I am today. Thank you.
Moja ˇstudijska pot je bila malo daljˇsa kot pri veˇcini, zato se moram zahvaliti veˇcim ljudem za to, kar sem danes. Tekom ˇstudija sem eno leto preˇzivel na TU Berlin. Tam sem najveˇc ˇcasa preˇzivel na oddelku za omreˇzja. Posebej se moram zahvaliti Theresi Enghardt, ki je name prenesla svojo neverjetno ljubezen do IPv6. Kolegu Gordonu Gidofalvyju, da je name prenesel vso znanje, ki ga imam danes o sistemih Cisco in Juniper. Skupaj sva delala v skupini, a vedno si mi bil kot mentor. Ob povratku v Ljubljano mi je ostalo ˇse diplomsko delo. Brez podpore in neskonˇcne potrpeˇzljivosti montorice izr.
prof. dr. Mojce Ciglariˇc in somentorja asistenta Mihe Groharja mi ne bi uspelo. Za konec bi se ˇse zahvalil svoji druˇzini za neskonˇcno podporo pri pisanju diplome. Brez vseh vas danes ne bi bil to, kar sem. Hvala.
Za razvoj varnejˇsih sistemov
Kazalo
Povzetek Abstract
1 Uvod 1
1.1 Struktura diplomskega dela . . . 2
2 Motivacija 3 2.1 Podedovane naprave . . . 3
2.2 Pomanjkljiva varnost naprav IoT . . . 3
2.3 Kontrola dostopa . . . 4
2.4 Vkljuˇcitev streˇznikov v oblaku v interno omreˇzje . . . 5
2.5 Dodeljevanje dostopa zunanjim uporabnikom . . . 6
2.6 Izvedba pravic dostopa . . . 6
3 Pregled podroˇcja 7 3.1 Waverley Labs SDP . . . 7
3.2 OpenSPA/OpenSDP . . . 9
3.3 Kritika obstojeˇcih pristopov in kako se moj pristop razlikuje od obstojeˇcih . . . 10
4 Tehnologije in izrazi 13 4.1 Poˇzarni zid . . . 13
4.2 Avtentikacija z enim paketom – SPA . . . 14
4.3 Tuneli . . . 14
4.6 Interno omreˇzje . . . 15
5 Modeliranje napadalca 17 5.1 Opis napadalca . . . 18
5.2 Sploˇsni model za oddaljen dostop . . . 20
6 Programsko doloˇcljiv rob omreˇzja – Software defined peri- meter (SDP) 23 6.1 Perimeter . . . 23
6.2 Perimeter in varnost . . . 24
6.3 Programsko doloˇcljiv rob omreˇzja . . . 25
6.4 Naˇcini uporabe . . . 27
7 Tehniˇcna specifikacija moje implementacije SDP 29 7.1 Funkcionalne zahteve . . . 29
7.2 Izbira programske opreme . . . 31
7.3 Razvoj sistema T-SDP . . . 34
7.4 Arhitektura sistema . . . 35
7.5 Delovanje sistema . . . 37
7.6 Komunikacijski postopki . . . 40
7.7 Naˇcini uporabe . . . 45
8 Vrednotenje implementacije 51 8.1 Delovanje . . . 52
8.2 Moˇzne nadgradnje . . . 55
8.3 Nadaljnje delo . . . 55
9 Zakljuˇcek 57
Literatura 61
Seznam uporabljenih kratic
kratica angleˇsko slovensko
SDP Software defined perimeter Programsko doloˇcen obseg omreˇzja
SPA Single packet authetication Preverjanje pristnosti z enim paketom
IP Identification protocol Identifikacijski protokol IPv4 Identification protocol ver-
sion 4
Identifikacijski protokol ver- zija 4
IPv6 Identification protocol ver- sion 6
Identifikacijski protokol ver- zija 6
TCP Transmission Control Proto- col
Protokol za krmiljenje tran- sporta
UDP User Datagram Protocol Datagramski protokol IoT Internet of things Internet stvari
VPN Virtual private network Navidezno zasebno omreˇzje IaaS Infrastructure as a service Infrastruktura kot storitev SaaS Software as a service Programska oprema kot sto-
ritev
NAT Network address translation Prevajanje omreˇznih naslo- vov
CGNAT Carrier-grade NAT NAT pri ponudniku internate
Povzetek
Naslov: Implementacija programsko doloˇcljivega roba omreˇzja s tuneli Wi- reGuard
Avtor: Urban Suhadolnik
Na podroˇcju raˇcunalniˇske varnosti se iz leta v leto sooˇcamo z novimi izzivi in tveganji. V omreˇzje vkljuˇcujemo podedovane naprave in naprave interneta stvari, ki so pogosto varnostno ranljive. Zaradi nenehnega naraˇsˇcanja ˇstevila naprav in kompleksnosti internih omreˇzij moramo iskati nove reˇsitve za za- gotavljanje raˇcunalniˇske varnosti. Pristop programsko doloˇcljivega omreˇzja ponuja nove moˇznost.
V diplomski nalogi raziˇsˇcemo izzive segmentacije omreˇzja in oddaljenega do- stopa. Pregledamo koncept programsko doloˇcljivega roba, predlagamo nad- gradnjo s pomoˇcjo tunelov WireGuard in razvijemo svojo implementacijo T- SDP. Novo implementacijo SDP smo implementirali v topologiji odjemalec- krmilnik-prehod. Kontrolna komunikacija poteka v obliki HTTP REST kli- cev med odjemalcem in krmilnikom ter med krmilnikom in prehodom. Podat- kovna povezava poteka neposredno med odjemalci in prehodi preko protokola za tuneliranje WireGuard.
Konˇcni rezultat diplome je funkcionalna specifikacija in prototipni sistem T-SDP, ki izboljˇsa varnost in bi lahko nadomestila omreˇzja VPN.
Kljuˇcne besede: Programsko doloˇcljiv rob omreˇzja, SDP, Programsko doloˇcljivo omreˇzje, SDN, Poˇzarni zid, Modeliranje napadalca, Tunel, WireGuard, Od- daljen dostop, VPN, Varnost, IoT, Kibernetska varnost.
Abstract
Title: Software defined perimeter implementation with WireGuard tunnels Author: Urban Suhadolnik
In the field of computer security, we face new challenges and risks year af- ter year. Modern networks include Legacy devices and Internet of Things devices that are often vulnerable to exploitation. Due to the ever-increasing complexity of internal networks, we need to explore new approaches to ensure network security. Software defined networks offer such new possibilities.
In this thesis, we explore the challenges of network segmentation and re- mote access. We review the concept of software defined network, propose an improvement to SDP using WireGuard tunnels, and develop our own SDP implementation.
We have made T-SDP in the client-controller-gateway topology. Control communication takes place in the form of HTTP REST calls between client and controller and between controller and gateway. Data connection takes place directly between clients and gateways via the WireGuard tunnels.
The result of this thesis is a functional specification and SDP prototype T- SDP which is more secure and could replace VPNs in the future.
Keywords: Software defined perimeter, SDP, Software defined network, SDN, Firewall, Tunnel, WireGuard, Remote access, VPN, Security, IoT, Cy- bersecurity.
Poglavje 1 Uvod
Na podroˇcju raˇcunalniˇske varnosti se iz leta v leto sooˇcamo z novimi izzivi in tveganji. Vsako leto zaznavamo veˇcje ˇstevilo kibernetskih napadov, na kar nas opozarjajo tudi letna poroˇcila SICERT [28, 29, 30].
V varovanih omreˇzjih se pojavlja vedno veˇcje ˇstevilo podedovanih naprav (ang. Legacy naprave), ki pogosto ne podpirajo naprednih avtentikacijskih naˇcinov in varnih naˇcinov ˇsifriranja povezave, ali pa so le-te ranljive zaradi na novo odkritih varnostnih pomanjkljivosti in neobstojeˇcih varnostnih po- pravkov.
V interna omreˇzja vkljuˇcujemo vedno veˇc naprav t.i. interneta stvari (ang. Internet of things – IoT), ki so pogosto varnostno slabo zasnovane, ali pa proizvajalcu ni za zaupati na podroˇcju varnosti.
S pojavom dela od doma in infrastrukture v oblaku (IaaS) se je drastiˇcno spremenila tudi oblika omreˇzja. Razliˇcni uporabniki in storitve se nahajajo ne samo znotraj, ampak tudi izven nadzora organizacije. Razliˇcnim upo- rabnikom in napravam moramo dodeljevati ˇcedalje bolj kompleksne pravice dostopa, ki lahko obsegajo veˇc tehnologij na veˇc lokacijah.
Zaradi nenehnega naraˇsˇcanja ˇstevila naprav in kompleksnosti internih omreˇzij moramo iskati nove reˇsitve za zagotavljanje raˇcunalniˇske varnosti.
Pristopi programsko doloˇcljivega omreˇzja (ang. Software defined network) obetajo napredek na podroˇcju omreˇzne topologije.
1
V diplomski nalogi raziˇsˇcemo izzive segmentacije omreˇzja in oddaljenega dostopa. Pregledamo koncept programsko doloˇcljivega roba (ang. Software defined perimeter - SDP), predlagamo nadgradnjo s pomoˇcjo tunelov Wire- Guard in razvijemo svojo implementacijo T-SDP.
1.1 Struktura diplomskega dela
V 2. poglavju najprej opredelimo motivacijo za pisanje tega diplomskega dela in izzive, ki so spodbudili k snovanju nove reˇsitve. V 3. poglavju naredimo kratek pregled podroˇcja, obravnavamo obstojeˇce pristope in opredelimo, kako se naˇs pristop razlikuje od obstojeˇcih. V 4. poglavju opiˇsemo tehnologije in koncepte, ki so kljuˇcni za razvoj in razumevanje konˇcnega sistema. V 5. poglavju bomo modelirali napadalca, ki opisuje, v kakˇsnih okoliˇsˇcinah priˇcakujemo, da bo naˇs sistem deloval in kakˇsna tveganja so prisotna v ta- kem reˇzimu delovanja. V 6. poglavju definiramo teoretiˇcni pristop k SDP. V 7. poglavju zaˇcnemo z razvojem sistema T-SDP. Najprej definiramo funkcio- nalne zahteve novega sistema in se opredelimo do izbora programske opreme, potrebne za izvedbo. Nato doloˇcimo arhitekturo, delovanje in komunikacijske postopke sistema. Poglavje zakljuˇcimo s predvidenimi naˇcini uporabe. V 8.
poglavju vrednotimo implementacijo in postopek razvoja. V poglavju 8.1 in 8.2 predlagamo moˇzne nadgradnje in nadaljnje delo na podroˇcju SDP. V 9.
poglavju sledijo zakljuˇcne ugotovitve.
Poglavje 2 Motivacija
V tem poglavju predstavljamo sploˇsne izzive v kibernetski varnosti, ki so spodbudili k pisanju diplomskega dela.
2.1 Podedovane naprave
V omreˇzjih se pogosto nahajajo naprave z zastarelo in varnostno vpraˇsljivo programsko opremo. Takih naprav je verjetno veˇc, kot bi si ˇzeleli. Mnoge naprave so bile nastavljene po principu ”nastavi in pozabi”. Delovanje naprav je pogosto vezano na starejˇso razliˇcico programske opreme, kot na primer operacijski sistem. Posodobitev takih naprav ni mogoˇca oziroma je lahko celo prepovedana v podporni ali garancijski pogodbi. Takih sistemov pogosto ni mogoˇce preprosto odklopiti z interneta, ravno zaradi narave njihovega delovanja. Zaposleni, IT-sluˇzba in zunanji vzdrˇzevalci morajo imeti stalen dostop do sistemov za potrebe obratovanja in vzdrˇzevanja. Taki sistemi pogosto ne ponujajo kakrˇsne koli avtentikacije, ˇsifriranja ali nadzora dostopa.
2.2 Pomanjkljiva varnost naprav IoT
Mnoge naprave, ki jih vkljuˇcujemo v interno omreˇzje, imajo pogosto pomanj- kljivo varnost, saj nimajo na voljo varnostnih posodobitev ali pa so bile ˇze
3
na zaˇcetku zasnovane pomanjkljivo. To je ˇse zlasti znaˇcilno za naprave tako imenovanega interneta stvari. Med naprave interneta stvari sodijo hiˇsni pri- pomoˇcki, ki jih zaradi enostavnejˇse uporabe priklopimo na internet. To so hiˇsni termostati, hladilniki, klime, toasterji ipd. Z vidika varnosti lahko v isto skupino ˇstejemo tudi katerokoli drugo napravo, ki je priklopljena na in- ternet, do nje pa nimamo administratorskega dostopa in moˇznosti varnostnih posodobitev. Take naprave so npr. POS terminali in podobna oprema, ki je zaradi lastne funkcionalnosti priklopljena na internet ali pa je priklopljena na internet zaradi zunanjega vzdrˇzevanja.
Dejstvo je, da so ne varne naprave IoT prisotne v omreˇzjih. Zato se pojavlja problem utrjevanja varnosti takih naprav, saj so zaradi neustreznega dostopa moˇznosti za zagotavljanje varnosti minimalne.
2.3 Kontrola dostopa
V kolikor bi programsko opremo razvili na novo, bi pri varnosti in nadzoru najverjetneje uporabili koncept niˇcelne stopnje zaupanja (ang. zero-trust- network) [6, 22]. Tudi tak napreden sistem bi sˇcasoma postal ranljiv zaradi nezmoˇznosti posodabljanja programske opreme.
Ker se pri podedovanih napravah in napravah interneta stvari ni moˇzno zanesti na dovolj varno implementacijo avtorizacije in varne komunikacije [7], je edina moˇznost, da se kontrola dostopa zagotovi na omreˇzni ravni.
V tem primeru lahko del varnosti zagotovimo s pomoˇcjo navideznih omreˇzij VPN. Doloˇciti moramo pravila dostopa med podomreˇzji s pravili v poˇzarnem zidu. Trenutne implementacije omreˇzij VPN so prekompleksne in ne ponu- jajo dovolj finega nadzora dostopa. Roˇcna postavitev loˇcenega omreˇzja VPN in pravil poˇzarnega zidu za vsakega zaposlenega in zunanjega izvajalca ni smiselna. Moˇzna je le omejitev dostopa na statiˇcni IP, ki pa v omreˇzju VPN ni neposredno vezan na uporabnika. Nove povezave dobijo dinamiˇcni naslov IP, ki ga je lahko pred tem imel drug uporabnik oziroma se lahko vsakemu uporabniku dinamiˇcni naslov IP po doloˇcenem ˇcasu zamenja.
Diplomska naloga 5 S pomoˇcjo SDP lahko doloˇcene varnostne elemente prestavimo na omreˇzni nivo, na katerem lahko izvedemo kontrolo dostopa. S tem omogoˇcimo tudi zaˇsˇcito naprav, ki nimajo lastne kontrole dostopa, uporabljajo privzeto upo- rabniˇsko ime in geslo ali pa je na napravi ˇze znana varnostna pomanjkljivost, ki nepooblaˇsˇcenemu uporabniku omogoˇca vdor ali drugaˇcno manipulacijo.
Potrebujemo varnostni mehanizem, ki lahko naredi neposredno vez med uporabnikom, naslovom IP in poˇzarnim zidom. Dostop bi moral biti vezan na identiteto uporabnika in ne na lastnost, ki uporabnika opisuje zgolj posredno.
Pravice je potrebno dodeljevati bolj granularno, kot to omogoˇca segmentacija na podomreˇzja. Sama konfiguracija dodeljevanja dostopa bi morala biti pre- prostejˇsa za mikromanegement. Dodelitev dostopa na podlagi uporabniˇskih skupin, ki jih na primer ponujajo baze dostopa LDAP, bi bila bolj smotrna in laˇzja za upravljanje. Dostop je potrebno dodeljevati po principu “naj- manj, kot je treba”. Okoli vsake povezave moramo vzpostaviti lastnosti, ki so znaˇcilne za omreˇzja z niˇcelno stopnjo zaupanja, ˇsifriranje od zaˇcetka do konca in niˇcelno stopnjo zaupanja v kateri koli element omreˇzja med uporab- nikom in streˇznikom SDP. Lastnosti niˇcelnega zaupanja je potrebno doseˇci transparentno za delovanje aplikacije in brez spreminjanja streˇzniˇske in od- jemalske aplikacije.
2.4 Vkljuˇ citev streˇ znikov v oblaku v interno omreˇ zje
Del streˇzniˇske infrastrukture se danes nahaja v oblaku (IaaS) [21]. Lahko jo ponujajo veliki ponudniki oblaˇcnih storitev, ki ponujajo tudi storitev navide- znega omreˇzja, ki jo lahko obravnavamo kot loˇceno lokacijo in vzpostavimo tunel v naˇcinu toˇcka-toˇcka. Lahko pa so tudi bolj osnovni ponudniki navi- deznih oblaˇcnih storitev, ki ponujajo zgolj navidezne streˇznike z neodvisnimi naslovi IP brez navidezne omreˇzne infrastrukture, do katere bi lahko vzpo- stavili tunel v naˇcinu toˇcka-toˇcka. Smotrno je, da se tudi te oblaˇcne streˇznike vkljuˇci v interno omreˇzje organizacije. Z uporabo SDP lahko vzpostavimo
oddaljen tunel od vsakega uporabnika do vsakega streˇznika in lokacije.
2.5 Dodeljevanje dostopa zunanjim uporab- nikom
Del omreˇzja, ki ga vidi ena naprava, naj bi bil minimalen. V praksi pa se pogosto zgodi, da je del omreˇzja, ki ga vidi posamezna naprava mnogo veˇcji, kot bi bilo potrebno. Interna omreˇzja so pogosto preveˇc odprta. V kolikor napravi ne zaupamo, bi bilo primerno, da njeno vidno polje zmanjˇsamo z veliko stopnjo granulacije.
Pri oddaljenem dostopu se v interno omreˇzje vkljuˇcuje tudi zunanje iz- vajalce. Pogosto se za dostop do le ene naprave vzpostavi tunel v naˇcinu toˇcka-toˇcka med enim in drugim internim omreˇzjem ali pa se zunanjemu vzdrˇzevalcu dodeli dostop do omreˇzja VPN. Oba pristopa prekomerno izpo- stavljata interno omreˇzje. V prvem lahko zlonamerna programska oprema preskoˇci iz enega omreˇzja v drugega. V drugem primeru prepogosto izpo- stavljamo prevelik del omreˇzja zunanji osebi, ki potrebuje dostop do le ene naprave.
2.6 Izvedba pravic dostopa
Tudi rigidnejˇsi naˇcini omejevanja dostopa ne poznajo koncepta uporabnika.
Pravice dostopa opravlja loˇcen sistem - poˇzarni zid, ki koncepta uporab- nika ne pozna. Tako se porazgubi vez med identiteto uporabnika, izhodnim prometom iz tunela, naslovom IP in pravili v poˇzarnem zidu, ki omogoˇcajo dostop. Za varno implementacijo zunanjega dostopa menim, da moramo zbliˇzati posredno relacijo v neposredno relacijo med uporabnikom in pra- vicami dostopa. Lastnosti tunela, naslova IP in pravila poˇzarnega zidu so zgolj elementi realizacije dostopa za uporabnika. Izkoristiti moramo njihove lastnosti, da logiˇcno skrajˇsamo relacijo med uporabnikom in njegovim dosto- pom.
Poglavje 3
Pregled podroˇ cja
V ˇcasu pisanja diplomske naloge je bilo na voljo malo implementacij SDP.
Organizacija Cloud Security Alliance (CSA)1 ima delovno skupino, ki skrbi za razvoj specifikacije [20, 19] in promocijo koncepta SDP. Ker je koncept ˇse vedno v razvojni fazi, imamo na voljo le peˇsˇcico implementacij.
Obstaja nekaj zaprtokodnih implementacij. Med njimi sta AppGateSDP [41] in PulseSecure SDP [35], katerih analiza ni mogoˇca, saj specifikacija in koda nista na voljo. Odprtokodni implementaciji sta na voljo dve: Waverle- yLabs SDP [38] in OpenSDP [24, 25]. V pregledu obstojeˇcih implementacij smo se osredotoˇcili na odprtokodne projekte. Analiza takih projektov je laˇzja, saj so specifikacije javno dostopne, s tem pa je posamezniku omogoˇcen vpogled v delovanje programa.
Od razvoja sistema OpenSDP [26] leta 2018 na UL FRI se ˇstevilo raz- poloˇzljivih implementacij ni spremenilo, zato v veˇcjem delu tega poglavja zgolj povzamemo ugotovitve avtorja OpenSDP Gregorja Krmelja.
3.1 Waverley Labs SDP
Waverley Labs implementacija SDP temelji na preverjanju pristnosti z enim paketom (ang. Single packet authentication) z orodjem fwknop [16].
1https://cloudsecurityalliance.org/
7
Gregor Krmelj je o sistemu Waverley Labs SDP napisal:
”Obstaja odprto koden projekt podjeta Waverley Labs, ki im- plementira SDP. Programska oprema, ki implementira krmilnik SDP, je sprogramirana z uporabo ogrodja Node.js. Odjemalec in streˇznik SDP sta implementirana s posebno razliˇcico fwknop.
Vsak streˇznik SDP je zaˇsˇciten s fwknop. Krmilnik SDP skrbi, da se generirajo uporabniˇski kljuˇci in da se le te poˇsljejo vsa- kemu streˇzniku SDP. To je potrebno, ker kot smo ˇze opisali, fw- knop zahteva, da so uporabniˇski kljuˇci shranjeni na sistemu, ki ga fwknop ˇsˇciti. Pri namestitvi programske opreme, administrator ustvari svojo (samopodpisano) certifikatno agencijo. Certifikatna agencija (CA) podpisuje digitalna potrdila od komponent SDP.
CA predstavlja vsem komponentam zaupanja vredno avtoriteto.
Uporablja se pri preverjanju medsebojne povezave TLS. Krmil- nik SDP je povezan na podatkovno bazo MySQL. Podatkovna baza vsebuje podatke o uporabnikih, skupinah, streˇznikih SDP in o uporabniˇskih pravicah. Krmilnik iz podatkovne baze pri- dobi seznam storitev, do katerih ima uporabnik dovoljen dostop.
Poizvedba se sproˇzi, ko je postopek SPA uspeˇsen in ko je medse- bojna povezava TLS sklenjena. Krmilnik ob pridobitvi seznama sproˇzi ukaz (preko medsebojne povezave TLS) pri vsaki storitvi na seznamu, da dovoli povezavo odjemalcu. Po prejemu seznama storitev, odjemalec poˇslje paket fwknop na vsako storitev, da zah- teva dostop, ˇce je paket veljaven, se omreˇzna vrata od avtorizirane storitve odprejo”[26]
Implementacija Waverley Labs vsebuje tudi nekaj pomanjkljivosti po- vezanih z uporabo fwknop in razdelitvijo identifikacijsikih kljuˇcev. Krmelj nadaljuje o slabostih implementacije SDP Waverley Labs:
”Implementacija SDP Waverley Labs uporablja fwknop za SPA, zato so prisotne slabosti, ki smo jih opisali ˇze v prejˇsnjih
Diplomska naloga 9 poglavjih. To se predvsem navezuje na tesno sklopljen posto- pek avtentikacije in avtorizacije. Ker fwknop potrebuje kljuˇce od vseh uporabnikov v svoji konfiguracijski datoteki, SDP krmil- nik poˇslje vse kljuˇce vsaki storitvi. Poleg podvajanje podatkov in slabosti, ki jih tovrstno dejanje prinaˇsa, je shranjevanje upo- rabniˇskih kljuˇcev na vsaki storitvi varnostno tvegano. Kot tudi teˇzavi pri skalabilnosti sistema. Ker je krmilnik SDP napisan v programskem jeziku Javascript z uporabo ogrodja Node.js, bi lahko to postalo problematiˇcno. Node.js streˇznik, ki izvaja pro- gram Javascript, in se izvaja znotraj enega procesa (v eni niti).
Programiranje poteka asinhrono, poslediˇcno so vhodni/izhodni klici (npr. komunikacija z bazo) zelo uˇcinkoviti, saj ne blokirajo glavnega procesa. Slabost streˇznika Node.js je izvajanje procesor- sko intenzivnih poslov [27]. Klasiˇcen primer je uporaba kriptogra- fije. Izvajanje procesorsko zahtevnih poslov ne poteka asinhrono in poslediˇcno blokira glavni proces. To povzroˇci, da se zmoglji- vost procesiranja zahtev zmanjˇsa. Poleg vsega programski jezik Javascript ni najboljˇsa izbira za programsko opremo, ki izvaja po- sle krmilnika SDP. Za kritiˇcen kos infrastrukture, kot je krmilnik SDP, je boljˇsa izbira programski jezik, ki se prevede in nudi boljˇse zmogljivosti. Krmilnik SDP je tesno vezan na lastno podatkovno bazo. Takˇsen pristop vodi do podvajanje podatkov iz sistemov, kjer ˇze hranimo uporabniˇske podatke (npr. FreeIPA). V podjetjih takˇsna reˇsitev ni optimalna, saj pri usklajevanju podatkov med sistemi lahko pride do nepredvidljivih napak.”[26]
3.2 OpenSPA/OpenSDP
OpenSPA/SDP [26] gradi na pomanjkljivostih fwknop-a in sistema Waver- ley Labs SDP. OpenSPA [23] izboljˇsa koncepte, na katerih je zasnovan fw- knop. Zmanjˇsa velikost paketa z uvedbo binarnega zapisa paketa SPA, imple-
mentira podporo za IPv6 in moˇznost razˇsiritve kriptografskih mehanizmov.
OpenSDP dovoljenje dostopa uporablja OpenSPA. OpenSDP zdruˇzuje avten- tikacijo in odpiranje vrat v poˇzarnem zidu in zalednih sistemih, ki doloˇcajo, ali uporabnik lahko dostopa do posamezne storitve.
Kritika pristopa OpenSPA/SDP je, da se ne posveti varnosti komuni- kacije, ampak zgolj prvotni avtentikaciji. Varnost posamezne komunikacije prepusti uporabniˇski aplikaciji, kar je lahko v praksi tvegano, saj nekatere aplikacije sploh niso namenjene za uporabo preko interneta. ˇCe aplikacija ne podpira avtetikacije in ˇsifriranja povezave, je moˇzno komunikaciji pri- sluˇskovati. Avtentikacijski del je sicer brez pomanjkljivosti, vendar pa inte- griteta povezave temelji zgolj na izvornem naslovu IP, ki ga lahko napada- lec ponaredi oziroma drugaˇce prevzame [14, 17]. Po drugi strani se lahko tudi aplikacijam, ki podpirajo varno komunikacijo, zgodi, da se v njihovi implementaciji ˇsifriranja najde varnostna pomanjkljivost, ki ni odpravljena oziroma aplikacija ni posodobljena na razliˇcico, ki ima varnostno pomanjklji- vost odpravljeno.
Pristop, ki ne zagotavlja integritete povezave na vsaj istem nivoju, kot v internem omreˇzju, lahko naˇse omreˇzje izpostavi kumulativni pomanjkljivosti vseh aplikacij in storitev, ki delujejo skozi oddaljeno povezavo SDP.
3.3 Kritika obstojeˇ cih pristopov in kako se moj pristop razlikuje od obstojeˇ cih
Predstavljeni sistemi so se primarno posvetili samo odobritvi dostopa in zaˇsˇciti pred napadi DDOS. Varovanje komunikacije pa so prepustili posame- znim uporabniˇskim aplikacijam, ki morda sploh niso namenjene za komunika- cijo preko interneta. Waverley Labs SDP in OpenSDP v svoji implementaciji zaupata izvornemu naslovu IP. Prevzemi naslova IP, na primer z napadi na protokol BGP so moˇzni in se dogajajo [4, 9].
Pri razvoju teh sistemov pogreˇsam formalni varnostni okvir, v katerem naj bi sistem varno deloval. Oba sistema pri zasnovi ne uporabljata predpo-
Diplomska naloga 11 stavk, ki bi bile primerne za oddaljen dostop. Ni razvidno, ali je bil namen avtorjev oddaljen dostop in zamenjava za omreˇzja VPN. Slednje ni nujno krivda posameznih avtorjev, ampak sploˇsno stanje na podroˇcju. Sploˇsnega varnostnega okvirja, ki bi ga lahko uporabili na podroˇcju razvoja varnih ko- munikacijskih sistemov, ˇse ni. Njihova formalna uporaba je trenutno omejena na podroˇcje kriptografije [10].
Model napadalca potrebujemo zato, da opiˇsemo nevarnosti, ki so znaˇcilne za kontekst, v katerem sistem deluje. Opisi nevarnosti nam pomagajo, da novih sistemov ne razvijamo na napaˇcnih predpostavkah in nenamenoma spregledamo bistvene vektorje napada.
Izdelava ˇsirˇsega formalnega modela napadalca, ki bi pokril vse moˇzne nevarnosti, presega obseg tega diplomskega dela. Vseeno pa bomo poskusili opisati napadalca, ki smo ga imeli v mislih pri snovanju sistema.
Poglavje 4
Tehnologije in izrazi
V tem poglavju predstavljamo tehnologije, ki so potrebne za razvoj in razu- mevanje sistema T-SDP.
4.1 Poˇ zarni zid
Poˇzarni zidovi so filtri paketov, ki blokirajo, zavraˇcajo ali dovolijo dostop na osnovi pravil. Poznamo dva tipa poˇzarnega zida, in sicer poˇzarni zid s stanji in poˇzarni zid brez stanj. V poˇzarnem zidu brez podpore stanj so pravila sestavljena iz peterice: izvorni naslov IP, ciljni naslov IP, transportni protokol, izvorna vrata in ciljna vrata. V poˇzarnem zidu, ki podpira stanja, lahko definiramo pravila tudi na podlagi smeri, v kateri je bila vzpostavljena povezava, ˇce je povezava nova, ali je ˇze vzpostavljena, ali sorodna.
Vsa omreˇzja in naprave priklopljene v internet uporabljajo eno od oblik poˇzarnega zida za zaˇsˇcito pred nezaˇzelenim dostopom. Pri omreˇzjih bloki- ramo vhodni in izhodni promet na TCP/UDP vratih, ki jih uporabljajo po- tencialno nevarni protokoli. Na posameznih napravah uporabljamo poˇzarni zid z namenom, da bi prepreˇcili dostop storitev, ki delujejo na raˇcunalniku, ne ˇzelimo pa si, da bi do njih dostopali iz interneta.
13
4.2 Avtentikacija z enim paketom – SPA
”Single Packet Authentication (SPA) je metoda, s katero upo- rabnik dokaˇze svojo identiteto tako, da poˇslje samo en paket [8].
Za razliko od trkanja na vrata je celotno sporoˇcilo zapakirano v podatkovno polje enega paketa. Paket SPA se torej poˇslje le en- krat in to na toˇcno doloˇcena vrata. Takˇsen pristop reˇsi omejitve trkanja na vrata, saj omogoˇca poˇsiljanje veˇcje koliˇcine podatkov brez zakasnitev in prepreˇci napade, ki izkoriˇsˇcajo ranljivosti na zaporedje trkanj.
SPA je zgrajen po principu odjemalec-streˇznik [31]. SPA od- jemalec poˇslje en ˇsifriran paket, ki vsebuje uporabniˇski naslov IP, enkratno kriptografsko ˇstevilo in vrata, do katerih ˇzeli dostopati.
Odjemalec poˇslje paket SPA preko protokola IP do streˇznika, ki ga obdela. V primeru, da je SPA paket veljaven in da ima upo- rabnik dostop do storitve, se vrata odprejo z dodajanjem izjeme v poˇzarni zid za uporabnikov naslov IP in zahtevana vrata. V nasprotnem primeru SPA streˇznik zahtevo ignorira. Odjemalec nikdar ne prejme odgovora. Edina posledica postopka SPA je, da se v primeru uspeˇsne avtentikacije odprejo omreˇzna vrata.” [26]
4.3 Tuneli
Protokoli za tuneliranje so protokoli, ki v svoj podatkovni del enkapsulirajo cel paket drugega komunikacijskega protokola. To nam omogoˇca, da preko interneta vzpostavimo navidezne direktne povezave. Obiˇcajno se protokoli za tuneliranje uporabljajo skupaj z avtentikacijo in ˇsifriranjem enkapsuliranega paketa v podatkovnem delu.
Z uporabo avtentikacije lahko dovolimo le pooblaˇsˇcenim uporabnikom, da dostopajo do naˇsega internega omreˇzja. S ˇsifriranjem prepreˇcimo, da bi naˇsi komunikaciji kdo prisluˇskoval med tranzitom preko interneta.
Diplomska naloga 15
4.4 Navidezno zasebno omreˇ zje – VPN
Navidezno zasebno omreˇzje naredimo s protokoli za tuneliranje. Obiˇcajno gre za primer, ko ˇzelimo oddaljeno lokacijo ali uporabnika vkljuˇciti v naˇse interno omreˇzje. To si ˇzelimo takrat, kadar imamo interne storitve in streˇznike, ki jih zaradi razliˇcnih razlogov (omejitev dostopa, varnost itd.) ne ˇzelimo izpostaviti internetu. S pomoˇcjo tunelov ustvarimo omreˇzni segment, ki je del internega omreˇzja, obenem pa vkljuˇcuje dislocirano napravo.
4.5 Koncept niˇ celne stopnje zaupanja – Zero trust network
Koncept niˇcelne stopnje zaupanja (tudi omreˇzje z niˇcelno stopnjo zaupanja, ang. Zero-trust-network) pomeni, da ob vsaki povezavi zahtevamo oboje- stransko preverjanje pristnosti, uporabnika in streˇznika. Predstavlja naspro- tje internim omreˇzjem in omreˇzjem VPN, kjer imamo do internih naprav neko inherentno stopnjo zaupanja. Dohodni povezavi ne zaupamo zato, ker prihaja iz internega, zaupanja vrednega omreˇzja. Prav tako ne zaupamo ostalim identifikatorjem, katerih pristnosti ne moramo preveriti. Obiˇcajno se preverja pristnost podatkov s kriptografskim podpisom. V omreˇzju z niˇcelno stopnjo zaupanja ne zaupamo streˇzniku zgolj, ker nanj kaˇze vpis DNS ali pa zato, ker se nahaja na doloˇcenem naslovu IP, ampak tudi od njega zahtevamo, da se identificira s certifikatom tako kot uporabnik.
Identifikacija obiˇcajno poteka s kriptografsko podpisanimi certifikati ozi- roma s privatnimi kljuˇci.
4.6 Interno omreˇ zje
Interna omreˇzja so nasprotje omreˇzjem z niˇcelno stopnjo zaupanja. V in- ternem omreˇzju napravam zaupamo samo zato, ker so del internega omreˇzja oziroma del doloˇcenega podomreˇzja. Sluˇzbenemu raˇcunalniku zaupamo zato,
ker je del sluˇzbenega omreˇzja in ne zato, ker je sluˇzbeni. V kolikor se v sluˇzbenem omreˇzju pojavi nepooblaˇsˇcena naprava, avtomatiˇcno zaupamo tudi njej, predstavlja varnostno tveganje.
Interna omreˇzja so problematiˇcna, ker zaupamo vsemu, kar se v njih nahaja. Problem predstavlja tudi to, da se lahko dostop doloˇci le na pod- lagi podomreˇzja. Zelo teˇzko je doseˇci tako segmentacijo omreˇzja, da ima vsak uporabnik dostop samo do tega, kar potrebuje. V praksi ima dosto- pno podomreˇzje unijo dostopov vseh svojih uporabnikov. Interna omreˇzja so pomembna, kadar se streˇzniki nahajajo v istem omreˇzju kot uporabniki.
Poglavje 5
Modeliranje napadalca
Za doloˇcitev resniˇcno varnega komunikacijskega sistema potrebujemo moˇcan formalni model napadalca, pred katerim se ˇzelimo braniti. V enem izmed prvih del, ki je definiralo model napadalca, so zapisali:
”... an authentication protocol (security) should stem from more than a few people’s inability to break it.” (Prevod: Varnost avtetikacijskega protokola mora temeljiti veˇc kot na tem, da ga nekaj ljudi ne zna razbiti.)
– Bellare in Rogaway v delu Entity Authentication and Key Dis- tribution - 1994 [2]
Modeliranje napadalcev, znaˇcilno za kriptografske raziskave, ˇse ni imelo ˇsirˇse uporabe pri raziskovanju uporabne varnosti (ang. applied security rese- arch) [10] in razvoja komunikacijskih protokolov/sistemov. Zaradi tega sem opazil, da mnogi poskusi izboljˇsanja varnosti ne pomislijo na nekatere veˇcje tipe napadov, kot na primer prevzem naslova IP. Zato nekateri poskusi do- dajo kompleksnost napadalcu, vendar ne poveˇcajo varnosti v primeru, ˇce ima napadalec veˇcje sposobnosti, ker za njim stoji veˇcja organizacija ali pa, ˇce pozna delovanje internega omreˇzja. Eno izmed osnovnih vodil v kibernetski varnosti trdi:
17
”the enemy knows the system” (napadalec pozna sistem) oziroma v daljˇsi razliˇcici ”one ought to design systems under the assump- tion that the enemy will immediately gain full familiarity with them.”((Varnostni) sistem moramo zasnovati pod predpostavko, da se bodo napadalci takoj popolnoma seznanili z njimi.)
– Shanonova Maksima –Claude Shannon v delu Communication theory of secrecy systems – 1949 [33]
V primeru SDP sistem, ki je razvit zgolj po principu, ki temelji na zakri- vanju po naˇcelu need-to-know, ne zaˇsˇciti omreˇzja pred maˇsˇcevalnim bivˇsim zaposlenim, ki sistem pozna. Zaupanje v izvorni IP ni varno, v kolikor se moramo braniti pred napadalcem (npr. drˇzavnim akterjem), ki ima dovolj sredstev za druge oblike zbiranja informacij (npr. vohunjenje), da spozna podrobnosti sistema ali pa pred napadalcem, ki ima moˇc, da manipulira po- datke v tranzitu med uporabnikom in streˇznikom.
Formalne definicije napadalca ˇse nimamo, oblikovanje nove pa presega obseg tega diplomskega dela. Kljub temu se na podroˇcju uporabne varnosti razvija izrazoslovje [37, 3, 34]. Zato bomo v tej diplomi zgolj opisali, kakˇsnega napadalca smo imeli v mislih pri razvoju sistema SDP. Zanesli se bomo na obliko razvoja modela napadalca, ki ga opredeli Do Quang in sodelavci, v delu The role of the adversary model in applied security research [10]
5.1 Opis napadalca
Opisali bomo napadalca za primer oddaljenega dostopa, ki je primeren za naˇcin uporabe naˇse implementacije SDP. Pri komunikaciji preko javnega in- terneta se moramo zavedati, da komunikacija poteka preko infrastrukture, ki ni pod naˇsim nadzorom in lahko zlonamerna oseba z njo manipulira [1].
Prav tako so internetu izpostavljene storitve dostopne komurkoli, ne le naˇsim uporabnikom, zato moramo biti pozorni tudi na nepooblaˇsˇceni dostop.
Take predpostavke nam niso popolnoma tuje. Protokoli za tuneliranje so razviti pod podobnimi predpostavkami. Namen protokola IPSec je premo-
Diplomska naloga 19 stitev nezaˇsˇcitenega omreˇzja [32], kar predpostavlja, da potrebujemo doloˇcen nivo avtentikacije, ˇsifriranja in preverjanja integritete prometa.
IPsec creates a boundary between unprotected and protected interfaces, for a host or a network (see Figure 1 below). Traffic traversing the boundary is subject to the access controls specified by the user or administrator responsible for the IPsec configura- tion. These controls indicate whether packets cross the boundary unimpeded, are afforded security services via AH or ESP, or are discarded. [32]
Primeri uporabe oddaljenega dostopa SDP ali VPN se ne razlikuje. SDP je zamenjava za doloˇcene primere, kjer se trenutno uporablja VPN. Zato ni nepriˇcakovano, da pri razvoju sistema SDP upoˇstevamo enake okoliˇsˇcine, ki so za VPN bolj oˇcitne, tudi pri razvoju bolj kompleksnega sistema SDP, ki zdruˇzuje veˇc konceptov in tehnologij.
5.1.1 Predpostavke
Napadalec je lahko vladni akter z neomejenimi sredstvi in dostopom do teh- nologije ali pristopov, ki obiˇcajnim uporabnikom interneta morda niso na voljo. Napadalec lahko uporablja pristope, kot je ponarejanje BGP, s po- polno uspeˇsnostjo in globalnim dosegom. Napadalec je neverjetno hiter in zlahka zmaga v vseh race-condition primerih. Napadalec pozna notranje omreˇzje ˇzrtve in pozna vse streˇznike, storitve in njihovo lokacijo (IP in vrata) v omreˇzju (Shannonova Maksima). Napadalec ima vidnost celotnega inter- neta, zlasti celotne poti med uporabnikom in prehodom. Lahko manipulira s katero koli napravo ali omreˇzno povezavo na tej poti in lahko manipulira s katerim koli paketom, ki potuje po internetu.
Poleg tega lahko napadalec nadzoruje omreˇzje, kjer se nahaja uporabnik (odjemalec SDP). Bodisi kot skrbnik lokalnega omreˇzja v primeru javnega WiFi, omreˇzja WiFi, ki je del organizacije (npr. univerzitetni kampus), ali pa kot ponudnik internetnih storitev.
5.1.2 Cilji
• Pridobiti dostop do internega omreˇzja
• Pridobiti dostop do zavarovanih storitev in streˇznikov
• Kraja podatkov
5.1.3 Sposobnosti
Jasnovidnost – napadalec pozna notranjo strukturo omreˇzja ˇzrtve, lokacijo vseh streˇznikov, lokacijo vseh storitve, njihova omreˇzna vrata, razliˇcico storitve in vse aktivne varnostne ranljivosti. Napadalec v´e, do katere storitve uporabnik dostopa, in njegov nivo dostopa.
Nadzor nad svetovnim internetom – Napadalec lahko nadzoruje kate- rokoli ali vse omreˇzne povezavo in mreˇzno strojno opremo med upo- rabnikom in prehodom. Prav tako lahko pregleda, manipulira, blokira, spusti ali ponovno predvaja katerikoli paket na poti med uporabnikom in prehodom v skladu z modelom, ki so ga definirali Bellare in sodelavci [1].
Dostop do katerekoli tehnologije ali pristopa – Napadalec ima dostop do katerekoli komercialno dostopne tehnologije in pristopa. Na primer, napadalec lahko z veliko gotovostjo in z globalnim dosegom izvrˇsi ugra- bitev IP prek sporoˇcil BGP.
Vseprisotnost – Napadalec lahko ugotovi, kakˇsen dostop ima drug upo- rabnik v istem omreˇzju 2. plasti. Napadalec se lahko premakne tudi v katero koli omreˇzje 2. plasti, kjer je uporabnik, in izvaja napade na 2.
plasti.
5.2 Sploˇ sni model za oddaljen dostop
Predstavljen je moj poskus definicije formalnega modela napadalca. Za mo- rebitno nadaljnjo rabo bi morali definirati bolj podroben model. Vseeno pa
Diplomska naloga 21 ta poskus dosega svoj cilj. Avtorji sistema Waverley Labs SDP in Open- SDP v svojih nenapisanih predpostavkah niso upoˇstevali vektorjev napada, ki so potrebni za oddaljen dostop. Zato sem pripravil ta koncept modela napadalca, ki upoˇsteva veˇc vektorjev napada, znaˇcilnih za oddaljen dostop.
Poglavje 6
Programsko doloˇ cljiv rob omreˇ zja – Software defined perimeter (SDP)
6.1 Perimeter
Prvotno so se vse poslovne skrivnosti, podatki in streˇzniki fiziˇcno nahajali v stavbi organizacije. Vse naprave in dostop do njih so bili pod neposrednim nadzorom organizacije. Perimeter je definiran kot meja med napravami, ki so pod nadzorom organizacije, in tistimi, ki niso.
S prihodom interneta in dela od doma se je oblika perimetra nekoliko spremenila. Do informacij smo zaˇceli dostopati preko interneta na daljavo oziroma izven fiziˇcnega perimetra organizacije. Ker informacij zaupne narave ne moremo posredovati kar preko interneta, smo problem dostopa reˇsili z omreˇzjem VPN. Dislociran sluˇzbeni raˇcunalnik smo vkljuˇcili v interno omreˇzje oziroma v perimeter.
Se veˇˇ cje spremembe je perimeter doˇzivel s prihodom raˇcunalniˇstva v oblaku. Streˇzniki in podatki se ne nahajajo veˇc znotraj fiziˇcnega perime- tra, temveˇc so v oblaku. Meja perimetra je postala zabrisana. Ne vemo, veˇc niti, katere naprave in podatki so znotraj perimetra, niti katere naprave
23
so izven nadzora in varnostne politike organizacije.
Bolj dinamiˇcni so postali tudi streˇzniki. Oblaˇcne streˇznike vˇcasih vkla- pljamo po potrebi ali pa glede na cenovno ugodnejˇse ure izven konice. To- vrstni streˇzniki se tako vklapljajo-izklapljajo iz ure v uro, zaradi tega pa se dinamiˇcno spreminja tudi obseg omreˇzja. [40]
6.2 Perimeter in varnost
V tradicionalni omreˇzni arhitekturi se za varnost zanaˇsamo na perimeter.
Omreˇzje je segmentirano na podomreˇzja. Napravam znotraj internega omreˇzja avtomatsko zaupamo in dodelimo dostop do doloˇcenih podomreˇzij in naprav.
Uporabnik lahko vidi vse naprave v svojem podomreˇzju in naprave v podo- mreˇzjih, do katerih ima dostop. Dostopa pa tudi do streˇznikov v oblaku.
Tukaj klasiˇcna definicija perimetra ne zadostuje veˇc. Oblaˇcne storitve so lahko dinamiˇcne in menjajo svojo omreˇzno lokacijo. Uporabniki niso veˇc na raˇcunalnikih znotraj stavbe, temveˇc uporabljajo prenosne raˇcunalnike, ki so v sluˇzbenem omreˇzju, v domaˇcem omreˇzju ali na javnem omreˇzju WiFi. Var- nostne pomisleke povzroˇca tudi politika BYOD (bring your own device, sl.
prinesi svojo napravo), kjer zaposleni v sluˇzbo prinaˇsajo svoje raˇcunalnike in jih vkljuˇcujejo v interno omreˇzje. Ker je perimeter ˇcedalje bolj dinamiˇcen in se razlikuje od uporabnika do uporabnika, bomo uvedli nov izraz -perimeter uporabnika.
6.2.1 Perimeter uporabnika
Do sedaj je bil perimeter nekaj, v kar je bil uporabnik vstavljen. Redko smo omreˇzje prilagodili uporabniku. V SDP, kjer perimeter konstantno pri- lagajamo vsakemu uporabniku posebej, je smiselno, da perimeter definiramo drugaˇce, in sicer kot lastnost, ki je znaˇcilna za uporabnika in ne za omreˇzje.
Perimeter uporabnika je del omreˇzja, ki ga lahko uporabnik vidi.
Diplomska naloga 25
6.3 Programsko doloˇ cljiv rob omreˇ zja
Programsko doloˇcljiv rob omreˇzja naslavlja probleme dinamiˇcnih uporabni- kov, streˇznikov in varnosti dostopa. Namesto, da se uporabnika vkljuˇcimo v enega izmed statiˇcno doloˇcenih perimetrov, se ga prilagaja vsakemu uporab- niku posebej. Uporabnik se poveˇze v omreˇzje, njegov dostop pa je doloˇcen v bazi pravic dostopa z dostopnimi skupinami (ang. access groups). Upo- rabniku se lahko dodeli veˇc dostopnih skupin, pravice dostopa se izvede v poˇzarnem zidu.
SDP se od klasiˇcnega doloˇcanja pravic dostopa v omreˇzju razlikuje v tem, da je lahko naprava v klasiˇcnem omreˇzju, lahko v le enem podomreˇzju, ki deluje kot ena dostopniˇska skupina. V SDP je naprava lahko v veˇc dostopnih skupinah hkrati.
Ker lahko zelo natanˇcno doloˇcimo pravice dostopa na omreˇzni ravni, je vidno polje oziroma perimeter naprave moˇzno nastaviti tako, da vedno vse- buje le naprave, do katerih ima naprava tudi dejansko dostop. S pomoˇcjo SDP lahko vedno doseˇzemo need-to-know koncept vidnosti omreˇzja. [39]
6.3.1 Casovno omejen dostop in kontrola dostopa ˇ
Programsko doloˇcen perimeter se lahko po potrebi dinamiˇcno spreminja.
SDP s svojimi lastnostmi ponuja moˇznost, da realiziramo kontrolo dostopa na omreˇznem nivoju za naprave, ki je nimajo. Napravi lahko dostop dode- limo v eni dostopni skupini tudi za omejeno ˇcasovno obdobje, na primer za 60 sekund, ali za ˇcas veljavnosti prijave v posamezni sistem.
Podedovane in IoT naprave pogosto ne podpirajo ustreznih varnih komu- nikacijskih protokolov ali pa so bile v nameˇsˇcenih protokolih najdene var- nostne pomanjkljivosti, ustreznih posodobitev pa ni na voljo oziroma jih ni moˇzno namestiti, kar predstavlja varnostno tveganje. Take naprave lahko v omreˇzju zgolj izoliramo, kar ni vedno moˇzno ali smotrno. S pomoˇcjo SDP lahko stalno povezljivost naprave v omreˇzju omejimo na minimum. S SDP vidnost in dostop omogoˇcimo le ob uspeˇsni avtentikaciji za omejen ˇcas, lahko
tudi zgolj za eno TCP povezavo. Po preteˇcenem ˇcasu ali prekinjeni povezavi se je potrebno ponovno avtenticirati. Vsako povezavo odpremo izkljuˇcno takrat, ko jo potrebujemo in le kadar se avtenticiramo. S tem vsako ko- munikacijo nadgradimo s preverjanjem pristnosti in ˇsifriranjem ter integri- teto povezave, ki jo ponuja SDP. Kontrolo dostopa prestavimo iz naprave na omreˇzje.
Doloˇcanje pravic dostopa na nivoju omreˇzja je smotrno zato, ker imamo kot administratorji omreˇzja polni dostop do omreˇzne opreme, ne pa nujno do vsake posamezne naprave. S SDP lahko zaˇsˇcitimo tudi te naprave.
6.3.2 Osnovna topografija SDP
Slika 6.1: Osnovna shema SDP [20, 26]
V osnovni topografiji (Slika 6.1) so definirani elementi: krmilnik SDP, odje- malec SDP in streˇznik, ki podpira SDP [20]. Za potrebe tega dela bomo v naslednjem podpoglavju razˇsirili in definirali sestavne dele SDP in nadgradili ˇze obstojeˇco topografijo.
Diplomska naloga 27
6.3.3 Nadgrajena topografija
Obstojeˇci osnovni topografiji SDP dodajamo prehod SDP in bolj natanˇcno definiramo vlogo krmilnika SDP ter odjemalca.
Prehod SDP (ang. SDP gateway) Prehod SDP gostuje tunele, na ka- tere se povezujejo odjemalci SDP. Ob vzpostavitvi povezave s strani odjemalca SDP na prehod SDP se v poˇzarni zid naloˇzijo ustrezna pra- vila, ki omogoˇcajo dostop do odobrenih storitev. Avtorizirani promet se glede na pravila v poˇzarnem zidu prenaˇsa naprej do storitev. Ves podatkovni promet gre skozi vsaj en prehod SDP. Na prehodu se lahko vzpostavi dodatni varnostni nadzor, kot npr. IDS, IPS, dnevniˇski zapisi itd.
Krmilnik SDP Naloga krmilnika SDP je nadzor nad odjemalci in prehodi SDP. Krmilnik skrbi za avtentikacijo naprav na podlagi baze dostopa, kot je npr. LDAP. Po uspeˇsni avtentikaciji krmilnik odjemalcem SDP posreduje seznam storitev, do katerih ima posamezni uporabnik do- stop. Ob odobritvi dostopa do posamezne storitve posreduje dostopne podatke oziroma naslov IP, vrata tunela in avtentikacijske podatke.
Krmilnik posreduje prehodom SDP identifikacijske podatke odjemalcev SDP, skrbi za ustrezno vzpostavitev dostopa odjemalca SDP, nastavi tunel in pravila poˇzarnega zidu za dostop do storitev in skrbi za njihovo odstranitev, v kolikor prijava ali pravice dostopa poteˇcejo.
Odjemalec SDP Odjemalec SDP komunicira s krmilnikom SDP, ki mu po- sreduje avtentikacijske podatke in ˇzeljene dostope do storitev. Po pre- jetem odgovoru in navodilu za povezavo s strani krmilnika SDP se od- jemalec poveˇze preko prehoda SDP v omreˇzje SDP.
6.4 Naˇ cini uporabe
Sistem SDP upravlja veˇc razliˇcnih vlog v posameznem omreˇzju. Posamezne naloge pa lahko opravlja tudi samostojno. Naslednje vloge so povzete po
specifikaciji SDP 1.0 [20].
6.4.1 Oddaljen dostop
V primeru oddaljenega dostopa se sooˇcamo s problemom dodeljevanja do- stopa oddaljenim uporabnikom in zunanjim izvajalcem. Ker komunikacija poteka preko javnega interneta, so varnostne zahteve zelo visoke. Prav zato, ker nimamo nadzora nad javnim internetom, je potrebna uporaba tunelov za ˇsifriranje podatkov in moˇcno preverjanje pristnosti prometa. Vsak odjema- lec dobi svoj tunel. Na strani prehoda SDP je potrebno s pomoˇcjo lastnosti tunela vzpostaviti ˇcim bolj neposredno vez med uporabnikom in pravili v poˇzarnem zidu. V poˇzarni zid na podlagi identitete naloˇzimo pravila, ki omogoˇcajo dostop do storitev v internem omreˇzju.
6.4.2 Povezave na veˇ c oddaljenih lokacij hkrati
V raznolikem omreˇzju, ki obsega veˇc lokacij, IaaS in SaaS, je pomembno, da lahko uporabnik dostopa do storitev na veˇc lokacijah hkrati. Odjemalec SDP lahko nastavimo tako, da vzpostavi tunele do veˇc prehodov SDP. Tako se lahko oddaljeni uporabnik povezuje neposredno na vsako lokacijo in storitve v oblaku. Tako delovanje omogoˇca hitrejˇse delovanje, niˇzje latence povezav in razbremenitev centralne lokacije, preko katerih se v klasiˇcnih omreˇzjih z VPN obdeluje ves promet. Neposredno povezavo se lahko vzpostavi tudi do streˇznikov v oblaku.
6.4.3 Varen dostop
Namen oddaljene povezave SDP je, da omogoˇca varen dostop do internih storitev organizacije. SDP je lahko nadomesti sisteme VPN, ki omogoˇcajo dostop do internega omreˇzja, kar je prepogosto veˇc, kot je bilo potrebno.
Prednost SDP pred sistemi VPN je, da pri sistemih VPN omogoˇcimo do- stop do celotnega internega omreˇzja medtem ko, pri SDP omogoˇcimo dostop samo do storitev, do katerih ima uporabnik pravice dostopa.
Poglavje 7
Tehniˇ cna specifikacija moje implementacije SDP
Razvoj T-SDP se je zaˇcel z definiranjem funkcionalnih zahtev novega sistema.
S funkcionalnimi zahtevami povzamemo usmeritve, ki smo jih opredelili v prejˇsnjih poglavjih. Pri izbiri programske opreme za izvedbo posameznih komponent SDP smo primerjali veˇc razliˇcnih moˇznosti. Posebno pozornost smo posvetili vezi med izhodnim prometom iz tunela in pravili poˇzarnega zidu. Po izbiri protokola za tuneliranje, poˇzarnega zidu in naˇcina komuni- kacije smo se posvetili arhitekturi novega sistema. Opredelili smo, kakˇsna bo vloga posameznih komponent sistema in s katero programsko opremo jo bomo izvedli. Sledi naˇcrtovanje delovanja sistema in naˇcina komunikacije.
Na koncu sledijo ˇse predvideni naˇcini uporabe.
7.1 Funkcionalne zahteve
Z namenom, da bo novi sistem SDP vkljuˇceval predlagane izboljˇsave in da bo sistem odporen pred napadalcem, ki smo ga definirali, smo strnili usmeritve iz prejˇsnjih poglavij v naslednje funkcionalne zahteve.
1. Preverjanje pristnosti Sistem SDP mora podpirati preverjanje pristno- sti pri dodelitvi dostopa in to tudi izvajati tudi pri nadaljnji komunika-
29
ciji, ˇce ˇzelimo omejiti dostop do naˇsih storitev izkljuˇcno na pooblaˇsˇcene uporabnike.
2. ˇSifriranje povezave Eden izmed pomembnejˇsih naˇcinov uporabe SDP je oddaljen dostop. Kadar obˇcutljiva komunikacija poteka preko inter- neta, kjer omreˇzne opreme ne nadzorujemo, moramo povezavo ustrezno zaˇsˇcititi in ˇsifrirati, da prepreˇcimo tveganje za prisluˇskovanje ali mani- pulacijo komunikacije.
3. Niˇcelna stopnja zaupanja pri avtentikaciji uporabnika in dodelj- evanju pravic dostopa
Pri dodeljevanju dostopa se novi sistem ne sme zanaˇsati na posredne informacije o identiteti uporabnika. Dostopa ne smemo vezati na infor- macije, ki bi jih napadalec lahko manipuliral in informacije, ki se ˇcez ˇcas brez vednosti sistema SDP lahko spremenijo.
Avtentikacija uporabnika ali naprave lahko poteka le na podlagi kripto- grafsko varnih certifikatov. Dostop je lahko dodeljen samo na podlagi neposredne vezi med uporabnikom in pravicami dostopa, ali pa na po- sredni lastnosti, ki jo je definiral naˇs sistem in se ne spreminja skozi ˇcas in jih naˇs napadalec ne more manipulirati.
4. Kontrola dostopa Dinamiˇcno spremenljiv SDP ponuja moˇznosti reali- zacije kontrole dostopa na omreˇznem nivoju. Nov sistem mora omogo- ˇcati dinamiˇcne spremembe obsega omreˇzja za izvajanje kontrole do- stopa. Pomembno je, da lahko dodajamo nova pravila tudi po zagonu SDP. ˇZe dodeljen dostop mora biti moˇzno tudi odvzeti.
5. Need-to-know Granularnost kontrole dostopa, ki jo izvaja SDP, mora biti tako natanˇcna, da lahko vsakemu uporabniku prilagodimo vidno polje, da vidi le naprave, do katerih ima dostop.
6. Povezava na veˇc lokacij hkrati Novi sistem SDP mora biti sposoben neposredne povezave na veˇc lokacij hkrati za izboljˇsamo hitrost prenosa in niˇzje latence povezav
Diplomska naloga 31 7. Zaˇsˇcita komunikacije aplikacij brez avtorizacije in ˇsifriranja
Komunikacija skozi nov sistem SDP mora biti zaˇsˇcitena ne glede na aplikacijo, ki jo uporablja. V kolikor aplikacija ne uporablja preverjanja pristnosti, naj le-to omogoˇci SDP. ˇSifriranje vsake povezave naj bo privzeto.
8. Transparentna uporaba Sistem mora biti zasnovan tako, da ni po- trebna modifikacijah obstojeˇcih aplikacij. Zagotavljanje varnostnih la- stnosti SDP in delovanje sistema mora biti nezaznavno in neodvisno od uporabniˇske in streˇzniˇske aplikacije.
7.2 Izbira programske opreme
7.2.1 Programski jezik
Pri izbiri programskega jezika, ki bo povezoval vse komponente in program- sko opremo potrebno za SDP, smo se odloˇcili za Python, ker omogoˇca hitro prototipno programiranje. Na voljo ima zelo dobre razˇsiritve in omogoˇca dodajanje zunanjih modulov.
7.2.2 Protokol za tuneliranje
Med najbolj pogosto uporabljenimi protokoli za tuneliranje so IPSec, OpenVPN in WireGuard. IPSec in OpenVPN sta predstavnika tradicio- nalnih protokolov za tuneliranje. WireGuard je nov poskus z drugaˇcnim pristopom [12]. Starejˇsi pristopi so se zanaˇsali na loˇcevanje komunikacijskih plasti. OpenVPN in IPSec v osnovi zagotavljata transport na plasti 2, loˇceno od omreˇzne povezljivosti na plasti 3. To ima doloˇcene teoretske prednosti, saj se VPN povezava vede kot najeti vod med dvema lokacijama. V praksi to povzroˇca teˇzave, saj omreˇzje VPN ni le v naˇcinu toˇcka-toˇcka, ampak gostuje tudi veˇc tunelov na enem navideznem vmesniku. V primeru veˇc povezav na enem navideznem vmesniku pa doloˇcene predpostavke, ki veljajo za fiziˇcna
omreˇzja, ne veljajo veˇc. V fiziˇcnem omreˇzju ne vemo toˇcno, kdo poˇsilja, iz katerega naslova IP, saj je moˇzno naslov IP ponarediti. Tako tudi pri tradi- cionalnih protokolih za tuneliranje nimamo zagotovila, da doloˇcen naslov IP pripada pravemu uporabniku. Jamstva, da sta naslov in uporabnik ista, ni.
Izvor komunikacijskih paketov moramo preverjati v poˇzarnem zidu,
WireGuard pristopi k problemu na drugaˇcen naˇcin. Loˇcevanje na 2. in 3. plast po ISO/OSI modelu [18] v primeru oddaljenega dostopa ni smiselno [12]. Doloˇcene lastnosti so skupne in pravilno je, da ˇsifrirni kljuˇc in naslov IP obravnavamo skupaj. WireGuard uvaja konceptCryptokey Routing oziroma usmerjanje na podlagi ˇsifrirnih kljuˇcev, kar omogoˇca, da se lahko iz tunela, ki ga predstavlja doloˇcen javni kljuˇc, prenaˇsajo zgolj paketi z doloˇcenimi naslovi IP (npr. 10.192.122.3/32). Zaradi te lastnosti smo lahko prepriˇcani, da doloˇcen naslov IP res pripada doloˇcenemu uporabniku. Na podlagi naslova IP, ki je v tem primeru neposredno vezan na uporabnika, lahko v poˇzarnem zidu brez tveganja dodelimo dostop.
Teoretiˇcni pristop s protokolom OpenVPN
Ce ˇˇ zelimo razviti sistem SDP s pomoˇcjo protokola OpenVPN, moramo reˇsiti teˇzavo vezi med naslovom IP in tunelom. Ker ne moramo zaupati naslovu IP, moramo tunel nastaviti v naˇcinu toˇcka-toˇcka. Tako vsak tunel dobi svoj navidezni vmesnik, na katerega lahko v poˇzarnem zidu iptables pravila dode- limo neposredno na navidezni vmesnik. Visoka stopnja avtomatizacije SDPja omogoˇca, da med vsakim uporabnikom in prehodom vzpostavimo povezavo toˇcka-toˇcka in dodelimo svoj navidezni vmesnik OpenVPN. Slabost takega pristopa je, da bi s tem drastiˇcno poveˇcali strojno zahtevnost take implemen- tacije. Razvoj z uporabo protokola OpenVPN smo opustili.
Pristop s protokolom WireGuard
Izvedba SDP s pomoˇcjo protokola WireGuard je mnogo preprostejˇsa. Wire- Guard temelji na konceptuCryptokey Routing, kar pomeni, da so posamezni naslovi IP vezani na doloˇcen javni kriptografski kljuˇc [11]. WireGuard pre-
Diplomska naloga 33 veri, ali se izvorni naslov IP ujema s kljuˇcem, s katerim je paket podpisan.
V kolikor se izvorni IP in kljuˇc ne ujemata, se paket zavrˇze. Sam protokol zagotavlja, da izvorni IP pripada doloˇcenemu uporabniku. V poˇzarnem zidu nam ni veˇc potrebno preverjati izvora naslova IP. Dostop dovolimo zgolj z navedbo naslova IP, ki pripada uporabniku, kar predstavlja najosnovnejˇsi funkcionalnost poˇzarnih zidov.
[ I n t e r f a c e ]
P r i v a t e K e y = yAnz5TF+l X X J t e 1 4 t j i 3 z l M N q+hd2rYUIgJBgB3fBmk=
L i s t e n P o r t = 51820 [ Peer ]
PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
A l l o w e d I P s = 1 0 . 1 9 2 . 1 2 2 . 3 / 3 2 , 1 0 . 1 9 2 . 1 2 4 . 1 / 2 4 [ Peer ]
PublicKey = TrMvSoP4jYQlY6RIzBgbssQqY3vxI2Pi+y71lOWWXX0=
A l l o w e d I P s = 1 0 . 1 9 2 . 1 2 2 . 4 / 3 2 , 1 9 2 . 1 6 8 . 0 . 0 / 1 6 [ Peer ]
PublicKey = gN65BkIKy1eCE9pP1wdc8ROUtkHLF2PfAqYdyYBz6EA=
A l l o w e d I P s = 1 0 . 1 0 . 1 0 . 2 3 0 / 3 2
Slika 7.1: Primer nastavitve WireGuard [11]
Na Sliki 7.1 je primer konfiguracijske datoteke WireGuard. V razdelku [interface] je vpisan privatni kjuˇc navideznega vmesnika in vrata UDP na ka- terem WireGuard sprejema povezave. Za tem so razdelki[peer], ki opisujejo dohodne tunele. Iz slike je razvidno, da iz tunelov podpisanih z doloˇcenih javnim kljuˇcem sprejemamo samo doloˇcene naslove IP.
7.2.3 Poˇ zarni zid
Za poˇzarni zid smo izbrali iptables, ker je na voljo na praktiˇcno vseh Linux distribucijah in ima ustrezne funkcionalnosti. K odloˇcitvi je prispevalo tudi to, da je iptables moˇzno krmiliti s pomoˇcjo programskega jezika Python.
7.2.4 API
Med idejno zasnovo sistema T-SDP smo veliko ˇcasa porabili za izbiro naˇcina komunikacije med krmilnikom in prehodi ter krmilnikov in odjemalcem. V produkcijski implementaciji bi bilo pravilno, da bi zasnovali paket UDP, ki bi posredoval vse potrebne podatke in imel lastnosti preverjanja pristnosti z enim paketom (SPA). Ker pa gre za prototipno implementacijo in dokaz, da koncept deluje, smo se odloˇcili za HTTP REST API narejen v Python s pomoˇcjo modula Flask. Odloˇcitev, da uporabimo standardizirano obliko za komuniciranje, je zelo pospeˇsila razvoj. Flask omogoˇca tudi samodejno integracijo s spletnimi certifikati Let’s Encrypt, ˇsifriranje s pomoˇcjo HTTPS in avtentikacijo. Odloˇcitev za pospeˇsitev razvoja pa ni bila brez slabosti.
Flask ne ponuja preverjanje pristnosti z enim paketom (SPA). Uporablja protokol TCP, ki je ranljiv pred napadi DDOS. Vsaka morebitna ranljivost v Flask vpliva na ranljivost naˇsega programa [15]. Flask verjetno predstavlja najˇsibkejˇsi ˇclen v naˇsi implementaciji.
Moˇzna reˇsitev je menjava Flask z zasnovo lastnega paketa UDP ali pa da tudi Flask komunicira znotraj vnaprej doloˇcenega tunela WireGuard.
7.3 Razvoj sistema T-SDP
Za izvedbo SDP smo za zagotavljanje transporta in varnosti komunikacije izbrali tunele WireGuard. Z uporabo tunelov bomo vsaki IP komunikaciji za- gotovili najmodernejˇse ˇsifriranje in avtorizacijo povezave [12]. Z uporabo tu- nelov bomo lahko zaˇsˇcitili tudi obstojeˇce aplikacije, saj so tuneli uporabniˇski aplikaciji nevidni.
Diplomska naloga 35 Za vsako dinamiˇcno aplikacijo, ki se povezuje v omreˇzje SDP, bomo vzpo- stavili svoj tunel. Tunel bo vezan na odjemalca z javnim kljuˇcem. Z uporabo tesne vezi med dohodnimi povezavami in tuneli bomo vedeli, kateremu upo- rabniku pripada posamezna dohodna povezava. To lastnost bomo uporabili za doloˇcanje pravil poˇzarnega zidu v poˇzarnem zidu iptables. Ko dostopa ne potrebujemo veˇc, bomo tunel zaprli, pravila poˇzarnega zidu pa odstra- nili. Nevarnost, da bi povezava obstala po preteˇcenem dostopu, bomo s tem izniˇcili.
Komunikacija med posameznimi elementi SDP bo potekala preko HTTP REST API razvitega v Pythonu s pomoˇcjo modula Flask. Prehodi SDP bodo posredovali podatke o storitvah, ki jih gostujejo, preko REST zahtevkov na krmilnik. Uporabniki se bodo preko REST zahtevkov prijavljali na krmilnik.
Krmilnik bo brez beleˇzenja stanj odobrene zahtevke posredoval ustreznim prehodom SDP.
Dostope bomo izvajali po zgledu referenˇcnih programsko doloˇcljivih pri- stopov [36]. Veljavni bodo za omejen ˇcas, preden veljavnost poteˇce, jih bo potrebno obnoviti oz. odstraniti.
7.4 Arhitektura sistema
Slika 7.2: Arhitektura sistema
Prehod SDP Na prehodu SDP je nameˇsˇcen WireGuard, ki gostuje tunele.
V WireGuardu nastavimo, katere dohodne naslove IP sprejmemo iz tunela. V naˇsem primeru je to samo naslov /32, ki ga odjemalcu doloˇcil krmilnik SDP. Pravila dostopa izvrˇsujemo s pomoˇcjo poˇzarnega zidu iptables, ki je privzeto nameˇsˇcen na praktiˇcno vsaki Linux distribuciji.
Ko pride navodilo s strani krmilnika, prehod SDP nastavi WireGuard tunel in naloˇzi pravila poˇzarnega zidu v iptables. Ko dostop poteˇce, se WireGuard tunel podre, pravila v iptables pa odstranijo.
Krmilnik SDP Krmilnik SDP skrbi za nadzor nad omreˇzjem SDP. Pove- zuje se z bazami uporabnikov in pravic dostopa, kot je na primer LDAP, in skrbi za avtentikacijo in pravilen dostop do storitev. Prehodi SDP se prijavljajo v krmilnik in posredujejo svoje sezname storitev, ki jih kr- milnik vstavlja v svoj globalni seznam storitev. Odjemalci se vpisujejo v krmilnik in zaprosijo za dostop do storitev. Krmilnik za posamezni odobren dostop posreduje navodila prehodu in odjemalcu.
Odjemalec SDP Odjemalec SDP deluje na uporabnikovi napravi. Krmil- niku poˇslje podatke potrebne za prijavo in svoj javni kljuˇc WireGuard in prosi za dostop do doloˇcenih storitev. Krmilnik SDP preveri istove- tnost in posreduje naslov IP prehoda SDP, konfiguracijo WireGuard in odjemalˇcev naslov IP znotraj tunela. Odjemalec nato vzpostavi tunel WireGuard do prehoda SDP, kjer se nahaja storitev.
Storitev Storitev je program, ki deluje v istem omreˇzju kot prehod SDP.
Storitev opisuje: IP naslov, vrata TCP ali UDP in pravila poˇzarnega zidu, ki se morajo naloˇziti za dodelitev dostopa.
Tunel Protokol za tuneliranje WireGuard, tekom tranzita preko interneta, zagotavlja avtentikacijo, integriteto in ˇsifriranje povezave s pomoˇcjo enkapsulacije prvotne povezave.
Perimeter Perimeter s pomoˇcjo programske doloˇcljivosti prilagajamo potre- bam uporabnika. Ko uporabnik potrebuje dostop do doloˇcene storitve,
Diplomska naloga 37 ga razˇsirimo, da obsega dodatne streˇznike in lokacije. Ko uporabnik ne potrebuje dostopa, ga zmanjˇsamo po principu ”najmanj, kot je treba”, da poveˇcamo varnost omreˇzja.
7.5 Delovanje sistema
7.5.1 Izvedba programsko doloˇ cljivih omreˇ zij
Programsko doloˇcljivo omreˇzje (ang. software defined network) je koncept, v katerem loˇcimo transportno in kontrolno ravnino. Pamet se nahaja v krmil- niku, ki predstavlja kontrolno ravnino. Prehod SDP, ki posreduje promet, pa predstavlja transportno ravnino. V referenˇcnih programsko doloˇcljivih pristopih [36] vsako navodilo naloˇzimo v transportno ravnino za omejen ˇcas, preden se izbriˇse oziroma ga je potrebno obnoviti. Naprave na transportni ravnini v primeru neznane situacije povpraˇsajo krmilnik na kontrolni ravnini za navodila oziroma promet zavrˇzejo.
7.5.2 Programska doloˇ cljivost v T-SDP
Podoben pristop smo izbrali tudi v naˇsi implementaciji. Vsak ukaz je velja- ven zgolj za omejen ˇcas, preden ga je potrebno obnoviti oziroma se razveljavi.
Prehodi se morajo periodiˇcno prijavljati v sistem. V kolikor naprave ne ob- novijo prijave, se ˇsteje, da so nedosegljivi in se jih izloˇci iz omreˇzja SDP. Ob uspeˇsni proˇsnji uporabnika oziroma odjemalca za dostop do storitve se na- vodila za dostop naloˇzijo v prehod SDP, ki se nahaja na transportni ravnini.
Proˇsnjo za dostop je potrebno periodiˇcno obnavljati. V kolikor se proˇsnje ne obnovi, navodila za dostop poteˇcejo in se jih odstrani.
7.5.3 Glavne procedure
Slika 7.3: Diagram glavnih procedur
Na Sliki 7.2 je prikazano delovanje procedur. Prehod se prijavi v krmilnik.
Odjemalec nato zaprosi za dostop do storitev, ki se nahajajo na prehodu.
Obenem poteka na prehodu in krmilniku procedura, ki odstrani potekle pri- jave. Prijave v krmilnik in proˇsnje za dostop je potrebno obnavljati.
Delovanje naˇsega sistema nadzirajo tri procedure:
• Periodiˇcne prijave prehodov v sistem
• Periodiˇcna proˇsnja odjemalca za dostop do storitev
• Odstranjevanje poteklih dostopov in prijav
Periodiˇcne prijave prehodov v sistem
Prehodi v ˇcasovnem intervalu, ki je doloˇcen v nastavitvah, obnavljajo pri- javo v sistem, kar ima naslednje prednosti: Prehodi z rednim javljanjem sporoˇcajo, da so ˇse vedno dosegljivi. ˇCe pride do spremembe razpoloˇzljivih storitev na prehodu, lahko to hitro zaznamo. Zaznamo lahko spremembo javnega naslova IP. Zaradi takega naˇcina delovanja lahko prehod dodamo ali odstranimo, tudi po zagonu omreˇzja SDP.
Diplomska naloga 39 Periodiˇcna proˇsnja odjemalca za dostop do storitev
Periodiˇcno proˇsnje za dostop omogoˇcajo, da lahko dostop naknadno odvza- memo. ˇCas odvzema dostopa je odvisen od ˇcasovnika veljavnosti posamezne prijave.
Brisanje poteklih prijav
Na krmilniku in prehodu potekajo procedure, ki vsako sekundo preverijo, ali je kateri od dostopov ali prijav potekel. Ko najde poteklo prijavo, sproˇzi postopek za odstranjevaje pravil v poˇzarnem zidu. Ko prehod postane nedo- segljiv, procedura odstrani njegove storitve iz globalnega seznama storitev.
7.6 Komunikacijski postopki
Odjemalec Krmilnik Prehod
Prijava v sistem SDP Dodelitev naslova IP Prijava v sistem SDP
Dodelitev naslova IP Prosnja za dostop do storitve
Kljuc odjemalca in storitev Naslov IP prehoda
Vzpostavitev tunela
Slika 7.4: Diagram komunikacije od prijave do dostopa do storitve
7.6.1 Zagon prehoda in prijava v krmilnik
Potek:
1. Prehod ob zagonu v delovni pomnilnik naloˇzi nastavitve iz konfigura- cijske datoteke
2. Prebere javne kljuˇce 3. Naloˇzi seznam storitev 4. Prehod se prijavi v krmilnik
5. Ustvari navidezni vmesnik WireGuard
6. Navideznemu vmesniku WireGuard nastavi dodeljen naslov IP
Ob zagonu prehod v delovni pomnilnik naloˇzi konfiguracijsko datoteko in seznam storitev (Slika 7.4). Ob prvem zagonu ustvari zasebni in javni kljuˇc, sicer ga naloˇzi iz datoteke. Prehod se nato avtenticira in prijavi v krmil- nik. Z ukazomgateway/login (Slika 7.5) krmilniku posreduje javni naslov IP, vrata vmesnika API, vrata tunelskega vmesnika WireGuard in seznam stori- tev in vpiˇse storitve prehoda v globalni seznam storitev. Krmilnik v odgovoru
Diplomska naloga 41
{” i d ” : 1 ,
”name” : ” h t t p s t r e z n i k ” ,
” r o u t e s ” : [ ” 1 0 . 1 . 1 . 1 / 3 2 ” , ” 1 0 . 1 . 1 . 2 / 3 2 ” ] ,
” p r o t o ” : ”TCP” ,
” p o r t ” : ” 80 ” ,
” f w r u l e s ” : ” s e r v i c e s / 0 . f w r u l e s ” ,
” t i m e o u t ” : ” 10 ” }
Slika 7.5: Opis storitve v konfiguracijski datoteki
{
’ e n d p o i n t ’ : J a v n i n a s l o v IP prehoda ,
’ a p i P o r t ’ : Vrata API ( p r i v z e t o : 5 0 0 1 ) ,
’ wgPort ’ : Vrata WireGuard ( p r i v z e t o : 5 1 8 7 1 ) ,
’ w g p u b l i c K e y ’ : J a v n i k l j u ˇc prehoda ,
’ s e r v i c e s ’ : Seznam s t o r i t e v }
Slika 7.6: Ukaz gateway/login
(Slika 7.6) prehodu sporoˇci dodeljeni interni naslov IP. Prehod nastavi dode- ljen naslov IP na navidezni vmesnik WireGuard in ˇcaka na nadaljnja navo- dila krmilnika. Prehod mora periodiˇcno obnavljati prijavo. V kolikor prijava poteˇce, se ˇsteje, da prehod ni dosegljiv.
{
’ p u b l i c I P ’ : N a s l o v IP , k o t ga v i d i k r m i l n i k ,
’ g w I n t e r n a l I P ’ : D o d e l j e n n a s l o v IP z masko omre ˇz j a ,
’ gatewayTimeout ’ : V e l j a v n o s t p r i j a v e v sekundah }
Slika 7.7: Odgovor na ukaz gateway/login {
’ w g p u b l i c k e y ’ : J a v n i k l j u ˇc prehoda }
Slika 7.8: Ukaz client/login
7.6.2 Prijava odjemalca na krmilnik
Potek:
1. Odjemalec se prijavi na krmilnik SDP
2. Odjemalec ustvari navidezni vmesnik WireGuard 3. Navideznemu vmesniku nastavi dodeljen naslov IP
Odjemalec se prijavi na krmilnik z ukazom client/login (Slika 7.7). Kr- milnik v odgovoru (Slika 7.8) posreduje interni naslov IP, ki ga nastavi na navidezni vmesnik WireGuard in parameter allowed IPs, ki definira omreˇzja dostopna preko SDP.
{
’ c l i e n t I P ’ : D o d e l j e n n a s l o v IP z n o t r a j t u n e l a ,
’ a l l o w e d I P s ’ : Omreˇz j e , k i j o d o s t o p n o z n o t r a j SDP }
Slika 7.9: Odgovor na ukaz client/login
Diplomska naloga 43
7.6.3 Proˇ snja za dostop do storitve
1. Odjemalec prosi za dostop do storitve
2. Krmilnik posreduje odobrene storitve in javni kljuˇc odjemalca prehodu 3. Prehod naloˇzi pravila poˇzarnega zidu in zaˇcne gostovati tunel
4. Krmilnik posreduje naslov IP in javni kljuˇc prehoda odjemalcu 5. Odjemalec vzpostavi tunel do prehoda SDP
Odjemalec prosi krmilnik za dostop do storitev z ukazom service/reque- stAccess (Slika 7.9). Krmilnik preveri v bazi dostopa, kot je npr. LDAP, ali ima uporabnik dostop in posreduje odobreno proˇsnjo do ustreznega prehoda (Slika 7.10), ki pripravi tunel, ki sprejema odjemalˇcev javni kljuˇc, in naloˇzi pravila poˇzarnega zidu za dostop do storitve. Dostop je na prehodu velja- ven samo za omejen ˇcas in ga je potrebno obnavljati. ˇCe veljavnost prijave poteˇce, prehod odstrani dostope iz poˇzarnega zida in zapre tunel.
Odjemalec prejme odgovor krmilnika (Slika 7.11), ki vsebuje podatek o prehodu, ki gostuje storitev. Odjemalec nastavi omreˇzne poti v omreˇzje SDP in nastavi ˇcasovnik za obnovitev prijave. Prijava se obnavlja v intervalu, ki je krajˇsi od ˇcasovnika veljavnosti povezave.
{
’ i d ’ : U n i k a t n i i d e n t i f i k a t o r s t o r i t v e ,
’ w g p u b l i c k e y ’ : J a v n i k l j u ˇc o d j e m a l c a }
Slika 7.10: Ukaz service/requestAccess
