Osana Tietoturvan hallinta-kurssia kuului suunnitella ja toteuttaa projekti, jonka aiheeksi valitsimme suojatut yhteydet ja varmenteet. Projekti tehtiin Ciscon Packet Tracer simulaattori ohjelmassa.
Projektin ideana oli rakentaa realistinen topologia kuvitteelliselle keskisuurelle yritykselle Ciscon Packet Tracer simulaattorissa. Tavoitteena oli rakentaa topologia, missä on Site-to-Site VPN-yhteys yrityksen kahden erillisen lähiverkon välillä Internetin yli. IP-pakettien tulee olla salattuja, kun ne ylittävät turvattoman Internetin. Topologiaan kuuluu täysin toimiva lähiverkko, jossa toimii DHCP, NAT, yhteydet ulkomaailmaan ja takaisin.
Loimme lähiverkon verkkolaitteilla virtuaalisia lähiverkkoja (VLAN), joiden avulla pystyy rajata broadcast-alueita, IP-pakettien liikennettä osastoilta toiselle ja lisäämän tietoturvaa. Konfiguroimme reunareitittimiksi molemmille lähiverkoille Ciscon ASA 5506-palomuurin, minkä ominaisuusiin kuuluu mm. suuri siirtonopeus, jonka ansiosta se sopii varsin hyvin verkon reunalle. Tarkoituksemme oli myös kahdentaa reittien kaapeloinnit ja konfiguroida verkkolaitteet suorittamaan kuormituksen tasapainotusta, mutta aika ei riittänyt tämän toteuttamiselle.
Verkkomme muuttui monta kertaa projektin aikana erilaisten syiden takia. Suurimmat muutokset olemme tehneet uuden oppimisen takia. Ensiksi olemme suunnitelleet, jonka jälkeen olemme opiskellut asiaa, sitä samalla sitä tehden. Asiaa tehdessä ja opiskellessa monesti huomattiin miten asiat oikeasti pitäisi toteuttaa. Me koimme tämän olleen toimiva opiskelutaktiikka, sekä projektin toteutustaktiikka.
Sovimme tekevämme lokaalisti versionhallintaa, jolloin se jäi jokaisen omalle vastuulle tehdä ja nimetä ne omasta mielestä järkevästi. Jaoimme versioita, sekä kerroimme mitä niille on tehty WhatsAppissa.
Projektin edetessä huomasimme Packet Tracer-ohjelmassa puutteita, kuten kaikki komennot eivät toimineet ja kun ohjelman käynnistää uudestaan, verkko ei toimi oikein.
Projektia ei aivan saatu maaliin asti monien haasteiden takia, mutta opimme hurjasti tietoturvan toteuttamisesta, verkkolaitteista, verkoista sekä Packet Tracer-ohjelmasta. Projektin ajoitus oli todella hyvä, koska meillä kaikilla oli samaan aikaan käynnissä Tietoverkkojen toiminta kurssi, josta opimme vähän kaikkea projektiin liittyvää.
Ensimmäiseksi loimme lähiverkon. Lähiverkkoon kuului seitsemän verkkosegmenttiä, Core, DMZ, Management, WLAN, Production, Research Team ja Internal Server Segment. Tarkoituksena oli luoda Research Teamille oma eristetty 10.10.0.0/16-verkko. Muille osastoille aluksi allokoimme 192.168.0.0 verkkoa 25 ja 26 bittisillä verkkomaskeilla, jotta saataisiin mahdollisimman tehokkaasti käytettyä osoitteet, mutta luovuttiin tästä myöhemmin. Päätimme, että turhaan jaamme niukasti osoitteita, kun ne eivät tule loppumaan tämän kokoisesta yrityksestä, sekä 24 bittisen verkkomaskin kanssa on huomattavasti selkeämpää työskennellä.
Kuvassa yllä ensimmäinen versio
Ensimmäisessä versiossa olisimme reitittäneet liikennettä jokaiselle verkkosegmentille annetulla omalla reitittimellä, jonka myöhemmin ymmärrettiin olevan tuhlausta. Muuten verkon malli pysyi pitkään hyvin samanlaisena.
Kuvassa toinen versio, laitteet yhdistetty ja keskustelee toistensa kanssa.
Toisessa versiossa olimme paremmin tutustuneet laitteistoon ja päätimme vaihtaa viisi reititintä yhteen OSI-mallin kolmannessakin kerroksessa toimivaan monikerroskytkimeen (Layer 3 Switch tai Multilayer Switch). Uskomme tämän olevan huomattavasti parempi vaihtoehto laitteiden hallinnan ja verkon implementoinnin kannalta.
Toisessa versiossa aloimme kytkemään laitteita yhteen ja konfiguroimaan laitteita. Konfiguroimme yhden verkkosegmentin tai VLAN:in kerrallaan, jolloin työskentelyssä pysyi systemaattisuus, jonka myöhemmin huomattiin olevan todella tärkeä tekijä. Ensimmäiseksi konfiguroimme distribuutio kytkimet, eli esimerkiksi kuvassa Switch7 (lähimpänä päätelaitteita). Asetimme kaikki FastEthernet-portit toimimaan verkkosegmentin VLAN:issa ja GigabitEthernet-portin, joka osoittaa monikerroskytkintä kohden, asetimme toimimaan trunk-porttina.
Tämän jälkeen konfiguroimme monikerroskytkimellä VLAN-liitännälle IP-osoitteen, jolloin tämä toimii päätelaitteiden default gatewayna. Kun saatiin ensimmäinen VLAN toimimaan, eli päätelaite pingasi onnistuneesti default gatewayhin, konfiguroimme monikerroskytkimen reitittämään paketteja. Tämän jälkeen rakensimme toisen VLAN:in vastaavasti kuin edellinen. Ensiksi testasimme toimivuuden pingaamalla default gatewayta, jonka jälkeen kokeilimme kulkeeko ICMP-viesti VLAN:ista toiseen. Näin saimme askel askeleelta topologiaa toimimaan, välttäen kuitenkin suuria harppauksia. Testaamatta joka kohtaa voi ongelman paikantaminen olla huomattavasti hankalampaa. Jatkoimme tällä tavoin työskentelyä saaden lähiverkko toimimaan. Jokaisesta verkkosegmentistä pystyi keskustelemaan toisen päätelaitteen kanssa, joka sijaitsee naapuriverkossa.
Saavuttaessamme staattisesti toimivan lähiverkon, halusimme lisätä dynaamisuutta siihen DHCP-palvelimella.
Kuvassa Server4-palvelin, jossa määritelty DHCP poolit
Teimme palvelimen, jolla jaamme IP-osoitteita koko lähiverkolle. Modernissa verkossa toimii dynaaminen osoitteiden jako, joka on tärkeää toimivan ja jatkuvasti muuttuvien päätelaitteiden takia. Jos työntekijöitä on jo useampiakin kymmeniä, staattisten osoitteiden ylläpitäminen olisi suuri työ.
Tällä DHCP-palvelimella loimme jokaiselle VLAN:ille oman poolin, josta palvelin jakaa osoitteita. Pooleista on otettu pois osoitteet, joita voidaan käyttää staattisille laitteille. Näitä voi olla VLAN:in oma palvelin ja verkkolaitteiden portit. Packet Tracerissa on DHCP-asetuksia varten helppokäyttöinen käyttöliittymä, mikä näkyy edellisessä kuvassa.
Jotta päätelaitteet osaavat pyytää DHCP-palvelimelta osoitteita, tulee määritellä monikerroskytkimen jokaiselle VLAN-liitännälle IP-Helper-osoite. Tällöin kun päätelaite lähettää DHCP-pyynnön, monikerroskytkin osaa lähettää sen eteenpäin.
Koska kyseessä oli kuitenkin tietoturvakurssi, yritimme ongelmista huolimatta keskittyä palomuureihin ja niiden kanssa työskentelyyn. Opiskelimme paljon materiaalia ASA-palomuurien käytöstä, jotta pääsimme käsittelemään niitä. Opiskelemalla ja luomalla pääsylistoja, osoitteiden muunnoksia, verkon segmentointia ja salaamalla liikennettä saimme vahvan käsityksen realistisista verkkototeutuksista ja miten tietoturva sekä -liikenne kulkevat käsikädessä.
Kuvassa DMZ sijoitettu uudestaan
Tässä vaiheessa sijoitimme DMZ uudestaan sopivammalle paikalle, lähiverkon ulkopuolelle. Näin turvaamme lähiverkkoamme ja kun DMZ on oikein sijoitettu, se myös toimii käyttötarkoituksensa mukaisesti. Nyt se on sisä- ja ulkopuolelta saatavissa oleva, mutta eristetty verkko. Internetistä tulevia pyyntöjä ei enää reititetä sisäverkkoon, jolloin mahdolliset vihamieliset paketit eivät pääse saastuttamaan sisäverkon laitteita.
ASA-palomuurien konfigurointi oli meille kaikille uutta ja aiheutti suuria määriä opiskelua. Ensiksi hämmennystä aiheutti oletuskonfiguraatiot, jonka jälkeen suurimmaksi haasteeksi koitui Packet Tracerin puutteelliset komennot ja hieman erilainen syntaksi.
Perus toimivuuden, eli pingaaminen ASA:n läpi onnistui suhteellisen helposti.
Tämä tapahtui luomalla pääsylistat (ACL), jotka sallivat halutun liikenteen molempiin suuntiin ja ottamalla ne käyttöön oikealla portilla oikeaan suuntaan. Pääsylistojen ja NAT:in konfiguroimin tapahtuu hieman eri tavalla, kuin normaalilla reitittimellä. ASA-palomuurissa käytetään parametreinä verkko-objekti (object network), jotka määritellään ennen ACL:lien ja NAT:tien luomista. ASA:n porteille annetaan ihan normaalisti osoitteetu, niin kuin muillekkin reitittimille, mutta ASA:ssa pitää määritellä mikä portti osoittaa ulospäin verkosta ja mikä osoittaa kohti lähiverkkoa.
Porteille pitää myös antaa turvallisuusluokitus (security level), nollasta sataan (0-100) ja nolla on turvattomin. Yleensä lähiverkkoon päin portin turvallisuusluokitus on 100, DMZ:lla 50, tämä tosin vaihtelee, ja ulos turvattomaan verkkoon se on nolla.
Enemmän kun pääsi käsittelemään verkko-objekteja, rupesi ne tuntumaan oikeastaan erittäin hyödyllisitä ja helppokäyttöisiltä. Ne helpottavat toistuvien esim. IP-alueitten kirjoittamista ja estää inhimillisten virheiden tulemisia, koska ei tarvitse kuin kerran kirjoittaa ne oikein.
ASA:n perus toimivuus onnistui suhteellisen helposti, mutta ongelmia rupesi tulemaan seuraavissa vaiheissa.
NAT overloading, eli PAT:in käyttöönotto on erittäin helppoa ja se tapahtuu vain muutamilla komennoilla. Pitää vain luoda verkko-objekti, antaa sille IP-osoitealue ja kertoa miltä portilta, minne porttiin menevää liikennettä halutaan muuntaa.
Staattinen NAT:taus oli melkein yhtä helppo ja tapahtui vain muutamilla komennoilla. Määriteltiin julkinen IP-osoite, minkä ASA aina käänsi samaan privaatti osoitteeseen, jolloin saadaan Internetistä ladattua yrityksemme verkkosivut.
Osoitemuunnoksen konfiguroinnissa tuli vastaan ohjelman rajoitteita. Aluksi ASA ei muuntanut osoitteita, kun se lähetti paketteja ulos. Tämä tapahtui, vaikka olimme toimineet täysin ohjeiden mukaisesti. Ohjeet ovat tosin oikealle ASA:lle, ei Packet Tracerin virtuaaliselle palomuurille. Ongelmaa tutkiessamme tuli ilmi, että Packet Tracer ohjelmassa on virhe ja ongelmalle oltiin löydetty ratkaisu1. Testasimme ratkaisua vaihtamalla ASA:n verkkomaskin suuremmaksi, 24-bittisestä 16-bittiseksi, jolloin osoitteenmuutokset rupesivat toimimaan.
Toiseksi ongelmaksi muodostui 10.10.0.0/16 Research Teamin verkko, jota ei onnistuttu saamaan toimimaan. Paketit menivät ASA:lle asti, mutta niitä ei muutettu julkisen osoitteen muotoon. Tätä yritettiin ratkoa opettajien ja Internetin avulla, mutta aika tuli vastaan ja mysteeri jäi selvittämättä. Tulimme siihen tulokseen, että konfiguraatiot olivat oikein ja vika on ohjelmassa.
Kuvassa lopullinen versio, missä lisätty ASA, poistettu turhia laitteita ja siistitty ulkonäköä.
Tavoitteemme oli luoda VPN-tunneli lähiverkkojen välille suojaamaan liikennettä ja saada fyysisesti erillään olevat verkot näkymään yhtenä isona lähiverkkona. Tajusimme, ettei tälläistä pysty tekemään, jos toinen laite on normaali reititin. Vaihdoimme sen ASA:an ja teimme muutekin verkkoon muutoksia.
Tämän version teimme täysin puhtaalta pöydältä edellisien versioiden oppeja noudattaen. Siistimme ulkonäköä, poistimme turhia päätelaitteita ja loimme uudet IP-avaruudet käyttäen /24 bittisiä verkkomaskeja työtämme helpottaen. VLAN:ien nimet muuttuivat jonkun verran osoitteiden mukana. Muuten verkkokokonaisuus pysyi samana.
Tämä tapahtuu konfiguroimalla ASA-palomuurit sopimaan oikeat tunnelointi parametrit. Käytimme tunnelointiin IPsec-protokollaa.
Protokollalle määrittelimme käyttämään Internet Key Exchange versio 1 (ikev1), jonka otimme käyttöön ASA:n julkisella portilla. Ikev1:lle määrittelimme menettelytavaksi (policy) 2, salausmenetelmäksi AES, hash metodiksi sha ja vielä autentikointimenetelmäksi ennalta määritellyn salasanan.
Diffie-Hellman (DH-group) ryhmäksi määrittelimme numero kaksi ja vielä aikarajaksi (lifetime) 86400 sekuntia. Loimme ikev1 muutoksen (transform set), nimeksi ipsec-vpn, salausmenetelmäksi esp-aes ja autentikointimetodiksi esp-sha-hmac.
Tämän jälkeen loimme pääsylistat (extended access-list), jotka päästävät halutut IP-osoitteet läpi. Seuraavaksi piti määritellä tunneliryhmät (tunnel-group), joiden nimiksi annettiin vastapuolen ASA:n julkinen IP. Tunneliryhmän tyypiksi annettiin ipsec-L2L ja attribuuteiksi annoimme ennalta määritellyn salasanan.
Lisäksi tulee määritellä crypto map oman verkon objektille vastakkaisen ASA:n julkinen IP, asettaa se käyttämään ikev1:stä ja oikeaa transform-settiä, eli ipsec-vpn:nää. Sitten viimeiseksi tämä crypto map enabloidaan ASA:n julkiselle portille.
Kun molemmat ASA:t konfiguroidaan oikeilla parametreillä ne sopivat IPsec-tunnelin säännöistä ja verifioivat toisensa. Sitten pitäisi toimia suojattu site-to-site VPN yhteys.
Kuvassa salataan ping-viesti palomuurien välillä
Lopuksi
Projektia ei saatu maaliin, syynä suuret haasteet itse Packet Tracer-ohjelman kanssa. Projekti kääntyi enemmänkin tietoliikenteen projektiksi. Itse tietoturva jäi suht olemattomaksi normaalien toimenpiteiden ja tietysti VPN-tunnelia lukuun ottamatta. Tietoturvaa tässä toteutettu tunnelin lisäksi pääsylistoilla, NAT:illa, lähiverkon segmentoinilla ja DMZ:lla. Kaikkien verkkolaitteiden salasanat ja etäyhteydet jäivät tekemättä, eli myös niin sanottu realistisuus jäi toteuttamatta.
Loppujen lopuksi olen itse tyytyväinen tulokseemme, opin paljon verkkolaitteiden konfiguroinnista, verkkojen suunnittelusta ja VPN ratkaisuista. Miljoonan ongelman ratkaisu projektin edetessä sai taas huomaamaan, miten tärkeää on systemaattisuus.
Latauslinkki itse projektin viimeiseen versioon
https://www.richterich.me/itsec/Tietoturvaprojekti_v5.vpn.pkt