TEKNIIKAN JA LIIKENTEEN TOIMIALA


                                Tietotekniikka

                                 Tietov...
ALKULAUSE
Tämä insinöörityö tehtiin Protie Oy:lle. Haluan kiittää kaikkia projektissa mukana olleita,
Protietä annetusta m...
INSINÖÖRITYÖN TIIVISTELMÄ

Tekijä: Simo Leskinen

Työn nimi: Tietoturvallinen ja vikasietoinen yritysverkko

Päivämäärä: 2...
ABSTRACT

Name: Simo Leskinen

Title: Secure and redundant enterprise network

Date: 21 November 2008                     ...
SISÄLLYS

ALKULAUSE

INSINÖÖRITYÖN TIIVISTELMÄ

ABSTRACT

1     JOHDANTO                                                  ...
1




1   JOHDANTO

         Internetin huikea kasvu ja yritysten toimintojen siirtyminen verkkoon on saa-
         nut yr...
2

            ta verkosta uuteen verkkoon ja konfiguroitiin pääkonttorin vikasietoisuus lop-
            puun.




      ...
3




Kuva 1. OSI-mallin kerrosten toiminta.


Kokonaisuuksien järjesteleminen pienemmiksi kerroksiksi parantaa verkon
käs...
4

Sense Multiple Access with Collision Detect), joka on käytössä ethernet-
verkoissa. MAC-protokolla ja ethernet tarjoava...
5

Yhteydellisessä datansiirrossa muodostetaan ensin yhteys kommunikoivien
osapuolten välillä, siirretään haluttu data ja ...
6




          Kuva 2. TCP/IP-malli verrattuna OSI-malliin.


          Toisin kuin OSI-mallissa, TCP/IP-mallissa ei ole ...
7

            kon yli tarvitaan operaattorin tarjoamia palveluita. Alueverkoissa käytettyjä
            laitteita ovat re...
8

            Kuva 3. ADSL-verkkotopologia.


            ADSL on laajakaistateknologia, mikä tarkoittaa sitä, että se ei...
9




           Kuva 4. ATM-solun koostumus.


           GFC-kenttä (Generic flow control) on yleinen vuonohjaus kenttä,...
10

           rated Routing and Bridging) -toiminnolla. Operaattorin määrittelemä PVC
           (Permanent Virtual Circu...
11

           encapsulation aal5snap

           Valitsee ATM-sovituskerros 5:lla (AAL5) tapahtuva datan kapselointiproto...
12

             TCP/IP-verkoissa isäntäkoneet selvittävät IP-osoitteelle MAC-osoitteen käyt-
             täen ARP (Addre...
13

            tapaa, tällöin samainen 255.255.255.0 aliverkonmaski esitetään muodossa
            /24 (3 x 8-bittiä). [1...
14

kaiselle työasemalle ei tarvitsisi erikseen määritellä manuaalisesti IP-
osoitetta, tarvitaan osoitteiden jakoon menet...
15

            haarakonttoreihin. Näin Internet palveluntarjoajan ei tarvitse välittää DHCP
            viestejä omassa v...
16

5   TIETOTURVA YRITYSVERKOSSA

            Kun työssä oltiin päästy vaiheeseen, jossa kaikista haarakonttoreista oli t...
17

            Avainpari luodaan (ja samalla aktivoidaan SSH protokolla reitittimellä) ko-
            mennolla:

       ...
18

levat paketit liittyvät sisältäpäin alkaneisiin sessioihin ja mitkä taas eivät.
Tämän tiedon perusteella palomuuri hyl...
19

            Näin konfiguroidaan refleksiivisiä pääsylistoja. Refleksiivisyys tulee siitä, että
            FW_OUT pääs...
20

paketti kapsuloidaan uuteen IP-pakettiin ja IP-pakettien otsikoiden väliin syö-
tetään IPSec-otsikko. Näin saavutetaan...
21

           (cipher), joka huolehtii luottamuksellisuudesta ja tunnistajaosa (authentica-
           tor), joka huoleht...
22

VPN-konsentraattoreilla) ja VPN-liikenteen määrän ollessa suuri kannattaa
suosia DH-ryhmän 1 käyttöä.

Kuvassa 8 on es...
23

           din käyttö on suositeltavaa. Kun agressiivisessa moodissa vaihdetaan vain
           kolme viestiä, niin ma...
24

crypto isakmp key 4v4iNn1ppU address 2.2.2.1
crypto isakmp keepalive 10 periodic


Seuraavaksi määritetään voimassaolo...
25

           interface BVI1
            ip address 172.16.32.1 255.255.255.0
           crypto map VPN


          Pitää...
26

            tuksella siitä, että toinen laite olisi vain virratta varalla. Hyvä puoli valitussa
            lähestymis...
27

taisi edelleen Reititin A:lle ja valvottava linkki olisi ylhäällä. Näin Reititin A
edelleen käyttäisi ISP 1:stä oletus...
28

poikki. IP SLA monitor-toimintoa käyttäen valvonta konfiguroidaan seuraa-
vasti:

ip sla monitor 1
type echo protocol ...
29

valittavalle reitille. Osuma (match) -ehdot kertovat, mitkä ehdot täytyy täyttyä
ennen kuin route map:n toiminnot (set...
30

            Jäljitettäessä (engl. track) edellä esitetyllä tavalla yhteyden tilaa on syytä
            tarkistaa ainak...
31




            Kuva 11. Haarakonttorien vikasietoisuus.


            Kun pääkonttorin Reititin A:n yhteys palautuu ja...
32

HSRP on yksinomaan Ciscon käyttöjärjestelmillä toimiva redundanssiproto-
kolla. Sen avulla ryhmä reitittimiä muodostaa...
33




          Kuva 13. Pääkonttorin HSRP-toteutus kahdella eri operaattorilla.


          HSRP:tä voidaan myös käyttää...
34

kysymyksenä ja tästä näkökulmasta tarkasteltuna, hieman ikääntyneellä,
ATM-kehystyksellä toteutetulla, ADSL-pääsyllä p...
35

kasietoisuus yhdelle reitittimelle voimme vakuuttua vikasietoisuuden toimi-
vuudesta kaikissa skenaarioissa tarkistama...
36

reitittimistä vikasietoiset yhteydet käyttäen hyväksi tässä työssä esiteltyjä
keinoja.
37




VIITELUETTELO

[1]      Kaarlo, Kimmo. TCP/IP-verkot. 1. Painos. Porvoo: Docendo 2002.

[2]      Cisco Press. Cisco...
38




[14]   IP SLAs--Analyzing IP Service Levels Using the ICMP Echo Operation,
       Cisco Systems. 2005. Haettu 23.8....
Vikasietoinen Ja Tietoturvallinen Yritysverkko
Upcoming SlideShare
Loading in …5
×

Vikasietoinen Ja Tietoturvallinen Yritysverkko

1,952 views
1,801 views

Published on

insinöörityö 2008

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,952
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Vikasietoinen Ja Tietoturvallinen Yritysverkko

  1. 1. TEKNIIKAN JA LIIKENTEEN TOIMIALA Tietotekniikka Tietoverkot INSINÖÖRITYÖ TIETOTURVALLINEN JA VIKASIETOINEN YRITYSVERKKO Työn tekijä: Simo Leskinen Työn valvoja: Janne Salonen Työn ohjaaja: Petri Rahikkala Työ hyväksytty: __. __. 2008 Janne Salonen yliopettaja
  2. 2. ALKULAUSE Tämä insinöörityö tehtiin Protie Oy:lle. Haluan kiittää kaikkia projektissa mukana olleita, Protietä annetusta mahdollisuudesta ja luottamuksesta työn aikana, asiakasyrityksen yh- teyshenkilöä joustavasta yhteistyöstä ja ymmärryksestä, työn tekemisessä avustaneita yliopettaja Janne Salosta, lehtori Jussi Alhorinnettä ja Protien osaavaa henkilökuntaa. Isoin kiitos työni tukemisesta kuuluu avovaimolleni tinkimättömästä tuesta koko työurak- kani aikana. Helsingissä 21.11.2008 Simo Leskinen
  3. 3. INSINÖÖRITYÖN TIIVISTELMÄ Tekijä: Simo Leskinen Työn nimi: Tietoturvallinen ja vikasietoinen yritysverkko Päivämäärä: 21.11.2008 Sivumäärä: 38 s. Koulutusohjelma: Tietotekniikka Suuntautumisvaihtoehto: Tietoverkot Työn valvoja: yliopettaja Janne Salonen Työn ohjaaja: ryhmänjohtaja Petri Rahikkala Tämä insinöörityö tehtiin Protie Oy:lle. Työn tavoitteena oli suunnitella ja toteuttaa asia- kasyritykselle Suomen toimipaikat kattava tietoverkko. Työn tuloksena rakennettiin Es- poon pääkonttorilta tietoturvalliset ja vikasietoiset yhteydet kaikkiin haarakonttoreihin. Työssä esitellään ensiksi yrityksen haarakonttoreihin rakennetut ATM-tekniikkaan perus- tuvat ADSL-yhteydet, TCP/IP-protokollaperheen peruspalveluita, joihin toteutettu yritys- verkko nojaa. Tietoturvan osalta työssä käsitellään pääsylistoja ja IPSec VPN standardia. Vikasietoisuutta käsitellessä esitellään toteutettu vikasietoisuus IP SLA Monitor- ja track- toimintoja käyttäen. Lopuksi vertaillaan tehtyä toteutusta toisenlaiseen toteutukseen vi- kasietoisuuden osalta ja esitellään HSRP (Hot Standby Routing Protocol). Alkuvaiheessa työtä tehtiin testejä vikasietoisuuteen liittyen laboratorio-olosuhteissa. Näi- den testien jälkeen tehtiin yliheitto vanhasta yritysverkosta uuteen. Yliheiton aikana teh- dyissä lisätesteissä kävi ilmi, että vikasietoisuutta tulisi parantaa kattamaan myös runko- verkon viat. Tässä insinöörityössä suunniteltiin ja toteutettiin nämä parannukset. Työn lopputuloksena yritykselle jäi toimiva verkkoinfrastruktuuri, joka on hyvin varautunut niin tietoturvan haasteisiin ja yrityksen pääyhteyden katkeamiseen. Tämän työn suosituk- sena on tietyissä tapauksissa toteuttaa vikasietoinen Internet-yhteys yhdellä reitittimellä. Avainsanat: Yritysverkko, ADSL, IPSec, Vikasietoisuus, IP SLA Monitor
  4. 4. ABSTRACT Name: Simo Leskinen Title: Secure and redundant enterprise network Date: 21 November 2008 Number of pages: 38 Department: Information Technology Study Programme: Data Networks Instructor: Janne Salonen, Principal Lecturer Supervisor: Petri Rahikkala, Team Leader This final project was carried out for Protie. The objective of this study was to design and implement the customer company`s nationwide data network. Another aim was to make this data network secure and redundant. This study is based on tests carried out in a laboratory environment. After these tests a changeover from the old network was completed. During this period of time new informa- tion was discovered in the production environment regarding the failover mechanisms. It was found that fault tolerance can be achieved on a single router with IP SLA Monitor and tracking capabilities of Cisco routers. This study also includes a comparison between the implied model of redundancy and another possible solution for redundancy. HSRP (Hot Standby Routing Protocol) is introduced. As a result of this project the network infrastructure of the customer company is now well prepared for network security challenges and for the loss of the company`s main connec- tion to the Internet. Based on these results, it would be recommendable to add redundant Internet connections to a single router in some cases. Keywords: Networking, ADSL, IPSec, Redundancy, IP SLA Monitor
  5. 5. SISÄLLYS ALKULAUSE INSINÖÖRITYÖN TIIVISTELMÄ ABSTRACT 1 JOHDANTO 1 2 OSI- JA TCP/IP-VIITEMALLIT 2 3 HAARAKONTTORIEN ADSL-LIITTYMÄT 6 3.1 ADSL-arkkitehtuuri 7 3.2 ADSL-koodaustekniikat 8 3.3 Datan kehystys ja sovitus ATM:llä 8 3.4 ATM:n toiminta sillatussa muodossa 9 3.5 ADSL- ja ATM-käytännöntoteutus 10 4 TCP/IP-VERKOT 11 4.1 IP-osoitteet ja staattinen reititys 12 4.2 Osoitteiden ja asetusten jako DHCP-protokollalla 13 4.3 IP-osoitteiden muunnokset NAT-tekniikalla 15 5 TIETOTURVA YRITYSVERKOSSA 16 5.1 SSH-yhteydet reitittimien hallinnalle 16 5.2 Liikenteen rajoittaminen palomuurisäännöin 17 6 IPSEC PÄÄSTÄ-PÄÄHÄN ERILLISVERKOT (IPSEC LAN-TO-LAN VPN) 19 6.1 IPSEC-pakettivirtojen turvaus 19 6.2 IPSEC-avaintenvaihto 21 6.3 IPSEC VPN-toteutus 23 7 VIKASIETOINEN YRITYSVERKKO 25 7.1 Pääkonttorin vikasietoisuus 26 7.2 Haarakonttorien vikasietoisuus 30 7.3 Vaihtoehtoisia näkökulmia vikasietoisuuteen HSRP:llä 31 8 JOHTOPÄÄTÖKSET 33 VIITELUETTELO 37
  6. 6. 1 1 JOHDANTO Internetin huikea kasvu ja yritysten toimintojen siirtyminen verkkoon on saa- nut yritykset kiinnittämään yhä enemmän huomiota omien tietoverkkojensa tietoturvaan ja vikasietoisuuteen. Tämän työn tarkoituksena oli toteuttaa eräälle Protie Oy:n asiakkaalle tietoturvallinen ja vikasietoinen tietoverkko kustannustehokkaasti. Verkko tuli kattamaan pääkonttorin Espoossa sekä 10 haarakonttoria eri puolilla Suomea. Yrityksen hakiessa kasvua maakunnista se kohtaa haasteen; miten taata maantieteellisesti kaukana oleville kohteille pääsy pääkonttorin palvelimille. Sama haaste koskee yrityksen työntekijöitä, jotka tarvitsevat pääsyä palve- limille tien päältä tai hotelleista. Usein palvelimilta haettava tieto voidaan lu- kea salassa pidettäväksi ja on tärkeää, että siihen pääsee käsiksi vain luote- tut henkilöt. Jos taas tieto ei ole joissain tapauksissa saatavilla, saattaa tämä johtaa taloudellisiin menetyksiin. Virtuaalisten yksityisverkkojen (Virtual Pri- vate Network, VPN) yleistyminen on tehnyt mahdolliseksi tämän kaltaisten ongelmien ratkaisemisen edullisesti. Samalla se täyttää kaikki edellä maini- tut vaatimukset. Tässä insinöörityössä esitellään aluksi kaikkien tietoliikenneprotokollien ku- vauksista tuttu OSI-malli, joka auttaa hahmottamaan työn seuraavissa lu- vuissa esiintyviä asiakokonaisuuksia. Tämän jälkeen seuraa teoriaa yhteyk- sien toteuttamisesta OSI-mallin ensimmäisellä ja toisella kerroksella (ADSL ja ATM). Näiden yhteyksien päälle toteutetun IP-verkon yleisestä toiminnas- ta (OSI-mallin kolmas kerros) ja verkossa käytetyistä hyvin tunnetuista pal- veluista (OSI-mallin neljäs kerros) kerrotaan luvussa neljä. Työn lopussa pai- nopiste siirtyy tietoturvaan, VPN-ratkaisuun sekä vikasietoiseen toteutuk- seen. Käytännön toteutuksessa konfiguroitiin ensiksi reitittimille yhteys Internetiin ja etähallintayhteys. Maakuntiin konfiguroidut reitittimet postitettiin toimipis- teisiin kytkentäohjeineen ja etäyhteyttä käyttäen konfiguroitiin tietoturvalliset VPN-tunnelit sekä palomuurisäännöt. Seuraavaksi suunniteltiin, testattiin ja konfiguroitiin vikasietoisuuteen liittyvät asiat. Lopuksi tehtiin yliheitto vanhas-
  7. 7. 2 ta verkosta uuteen verkkoon ja konfiguroitiin pääkonttorin vikasietoisuus lop- puun. Taulukko 1. Työvaiheet Vaihe Tehtävä 1. Vaihe Internet- ja etähallintayhteyksien konfigurointi reitittimille. 2. Vaihe Reitittimien postitus toimipaikkoihin. 3. Vaihe Tietoturvan konfigurointi. 4. Vaihe Vikasietoisuuden konfigurointi. 5. Vaihe Yliheitto vanhoista Internet-liittymistä uusiin. 2 OSI- JA TCP/IP-VIITEMALLIT Internetin alkuaikoina useat laitevalmistajat ja ohjelmistovalmistajat kehitteli- vät toisistaan erillään erilaisia verkkoratkaisuja, jotka eivät olleet keskenään yhteensopivia. Tilanteen parantamiseksi Kansainvälinen Standardointiorga- nisaatio (ISO, International Standardization Organization) julkisti vuonna 1984 OSI-mallin, joka perustuu kerrosajatteluun ja jakaa protokollat seitse- mään kerrokseen. Tietoliikenneprotokollia esiteltäessä ei voida olla puhumatta OSI-mallista. Jokaisella OSI-mallin kerroksella alkuperäinen data ympäröidään kerrokselle ominaisella otsakkeella, jota kerros tarvitsee datan käsittelyyn. Datan siirty- essä kerrokselta toiselle korvataan kyseinen otsake uudella kuitenkin niin, että ylemmän kerroksen otsake säilytetään entisellään. Ydinideana on, että alemmat kerrokset tarjoavat palveluitaan ylemmille kerroksille. Kuvassa 1 on esitetty OSI-mallin toiminta kahden päätelaitteen ja reitittimen avulla. Siinä missä päätelaitteet toimivat kaikilla OSI-mallin seitsemällä kerroksella, niin reititin toimii vain kolmella ensimmäisellä kerroksella reitittäessä paketteja.
  8. 8. 3 Kuva 1. OSI-mallin kerrosten toiminta. Kokonaisuuksien järjesteleminen pienemmiksi kerroksiksi parantaa verkon käsittelyä. Samalla kerroksella sijaitsevat toiminnot mahdollistetaan protokol- lien avulla. Vaikka OSI-malli onkin sellaisenaan vanhentunut, niin sen luo- malta kerrosajattelulta ei voi välttyä verkkojen suunnittelussa, rakentamises- sa ja vianetsinnässä. OSI-mallin alimman kerroksen, fyysisen kerroksen tehtävänä on huolehtia bittien fyysisestä siirtämisestä. Tämä käsittää käytettävän median, joita voi- vat olla muun muassa puhelinjohdot, kategorian 5 suojaamaton parikaapeli UTP, optinen kuitu tai radiotie. Fyysinen kerros huolehtii ilmiöistä, joihin ylemmät ohjelmistolliset kerrokset eivät ota kantaa: liittimiin, siirtotien säh- köisiin ominaisuuksiin ja signaalien jännitetasoihin. [1, s. 19.] OSI-mallin toinen kerros, siirtokerros, huolehtii datan luotettavasta siirtämi- sestä fyysisen siirtotien ylitse. Siirtokerrokselle kuuluu fyysinen osoitteistus, verkkotopologia, verkkomedian saanti ja virhetunnistus. [2] Esimerkkejä siir- tokerroksista ovat Ethernet, ATM (Asynchronous Transfer Mode) ja Token Ring. [3, s. 24.] Tässä insinöörityössä käsitellään alueverkkojen yhteydessä ATM-protokollaa. MAC (Medium Access Control)-kerros on tärkeä alikerros siirtokerrokselle, joka takaa siirtokerroksen käytettävyyden eri käyttäjien kesken ja IP paketti- en siirron IP-laitteelta toiselle. MAC-kerros tarjoaa loogisen siirtoyhteyden laitteiden välillä. Laajimmin levinnyt MAC-protokolla on CSMA/CD (Carrier
  9. 9. 4 Sense Multiple Access with Collision Detect), joka on käytössä ethernet- verkoissa. MAC-protokolla ja ethernet tarjoavat tavan toteuttaa aliverkon lait- teiden tunnistaminen. Tämä tapahtuu 48-bitillä Ethernet-kehyksessä ilmais- tavalla MAC-osoitteilla, josta 24 bittiä on varattu valmistajan tunnistamiseen [1, s.36.] Muita, nykyisin vähän käytettyjä, MAC-protokollia ovat muun muassa Token Ring ja Token Bus [1, s.20.] Siirtokerroksella toimivia laitteita ovat keskitti- met, sillat ja kytkimet, joista tämän päivän verkoissa käytetään käytännössä vain kytkimiä. OSI-mallin kolmas kerros, verkkokerros, tarjoaa yhteydettömiä palveluita. [3, s. 24.] Tämä tarkoittaa sitä, että verkkokerros ei itse huolehdi pakettien peril- lemenon kuittauksista ja uudelleenlähetyksistä, vaan jättää sen ylempien kerrosten hoidettavaksi. Verkkokerroksen datayksikkö on paketti ja verkko- kerroksella toimivat reitittimet huolehtivat pakettien reitityksestä. Reitityksen lisäksi verkkokerros tarjoaa vuonvalvontaa ja laatuvaatimusten tarkkailua. [1, s.20.] Yleisesti käytettyjä verkkokerroksen protokollia ovat muun muassa yleisesti levinneet IP (Internet Protocol), ICMP (Internet Control Message Protocol), ARP (Address Resolution Protocol), RARP (Reverse Address Resolution Protocol). IP tarjoaa yhteydettömän, parhaan yrityksen (engl. best effort) menetelmän paketeille. ICMP-viestit kulkevat IP-paketeissa ja niiden avulla suoritetaan valvonta ja sanomanlähetyksiä. [4, s. 12-15.] OSI-mallin neljännellä kerroksella sijaitseva kuljetuskerros huolehtii datan segmentoinnista, eli isännältä tulevan datan pilkkomisesta segmenteiksi lä- hetystä varten. Lähetettäessä segmenttejä kuljetuskerros voi taata luotetta- van ja eheän yhteyden vuonohjauksella. [2, s. 57; 1, s. 27.] Vuonohjaus tar- koittaa sitä, että vastaanottava osapuoli voi tarvittaessa pyytää lähettävää osapuolta pysäyttämään datasegmenttien lähettämisen siksi aikaa, kunnes vastaanottava osapuoli on käsitellyt aiemman datan. Näin vältytään datan menetykseen johtavilta ylivuodoilta. Kuljetuskerroksen protokollat voidaan jakaa yhteydettömiin ja yhteydellisiin protokolliin. Yleisesti IP-verkoissa käy- tetyt protokollat ovat yhteydellinen TCP- ja yhteydetön UDP-protokolla. Yh- teydellinen protokolla voi huolehtia pakettien saapumisjärjestyksestä sekä niiden lähettämisestä uudelleen.
  10. 10. 5 Yhteydellisessä datansiirrossa muodostetaan ensin yhteys kommunikoivien osapuolten välillä, siirretään haluttu data ja viimeiseksi puretaan yhteys, kun taas yhteydettömässä datansiirrossa vain dataa lähettävä sovellus lähettää datan tietämättä, onko vastaanottava osapuoli valmiina sitä vastaanotta- maan. Yhteydettömässä siirrossa ei käytetä yhteyksien numerointia niiden seuraamiseksi toisin kuin yhteydellisessä siirrossa. Tämä tarkoittaa käytän- nössä sitä, että esimerkiksi jokaisessa UDP-paketissa täytyy olla kokonaise- na vastaanottajan IP-osoite. OSI-mallin kolmea ylintä istunto-, esitystapa- ja sovelluskerrosta kutsutaan yleisesti sovelluskerroksiksi. Istuntokerros huolehtii yhteyksien muodostami- sesta, hallitsemisesta ja purkamisesta. Esitystapakerros pitää huolen siitä, että siirrettävä data on molempien osapuolten kesken luettavassa muodos- sa. Sovelluskerros puolestaan tarjoaa palveluitaan OSI-mallin ulkopuolella sijaitseville sovelluksille ja takaa näin sovellusten pääsyn verkkoon. [2, s. 54- 58.] TCP/IP (Transmission Control Protocol/Internet Protocol) on yleinen nimi protokollaperheelle, jonka USA:n puolustusministeriö kehitti 1970-luvulla ARPANET-projektissaan maailmanlaajuisten verkkojen rakentamiseksi. TCP/IP-protokollaperheen tunnetuimmista protokollista IP-protokolla sijait- see verkkokerroksella ja on yhteydetön paketteja välittävä protokolla. TCP- protokolla puolestaan sijaitsee kuljetuskerroksella, on yhteydellinen ja da- tayksikkönä käyttää kehyksiä. TCP/IP on mallinnettu OSI-mallin kaltaiseksi viitemalliksi, jossa OSI-mallin esitystapa- ja istuntokerrokset ovat yhdistetty sovelluskerrokseksi (Application Layer) sekä siirtoyhteys- ja fyysinenkerros peruskerrokseksi (Network Access Layer). Kuvassa 2 verrataan TCP/IP- mallin kerroksia OSI-mallin vastaaviin kerroksiin.
  11. 11. 6 Kuva 2. TCP/IP-malli verrattuna OSI-malliin. Toisin kuin OSI-mallissa, TCP/IP-mallissa ei ole yritettykään enää pitää eril- lään protokollia, rajapintoja ja palveluita. Sen sijaan TCP/IP mallissa sekä verkko- (Internet Layer) ja kuljetuskerros (Transport Layer) ovat näkyvissä ylemmille sovelluskerroksen (Application Layer) tason ohjelmille. TCP/IP- mallissa on vain yksi verkkokerroksen protokolla, eli IP (Internet Protocol). 3 HAARAKONTTORIEN ADSL-LIITTYMÄT Tässä luvussa keskitytään käytännön toteutuksessa käytettyyn ADSL (engl. Asymmetric Digital Subscriber Line) –teknologiaan ja koodaustekniikoihin. Lisäksi esitellään datan kehystys ATM-protokollalla (engl. Asynchronous Transfer Mode). Työn ensimmäisessä käytännön vaiheessa täytyi luoda haarakonttorien fyysiset yhteydet (ADSL), siirtokerroksen yhteydet (ATM) ja lopulta verkkokerroksen yhteys (IP). Yhdessä näitä yhteyksiä käsitellään tässä työssä yhtenä WAN (Wide Area Network)-alueverkkona, joka muodos- taa pohjan yritysverkolle. WAN-alueverkoilla tarkoitetaan maantieteellisesti etäisten LAN (Local Area Network)-lähiverkkojen yhdistämistä toisiinsa OSI-viitemallin ensimmäisellä ja toisella kerroksella. [2, s. 513.] Tässä työssä LAN-verkkojen yhdistäminen on toteutettu yhdistämällä toimipaikat toisiinsa julkisen verkon yli salaamalla liikenne virtuaalisilla yksityisverkoilla. Liikenteen kuljettamiseksi julkisen ver-
  12. 12. 7 kon yli tarvitaan operaattorin tarjoamia palveluita. Alueverkoissa käytettyjä laitteita ovat reitittimet, kytkimet, modeemit ja tietoliikennepalvelimet. Käy- tännön toteutuksessa asiakkaan haarakonttoreissa käytetyissä verkkolait- teessa yhdistyvät reitittimen ja ADSL-modeemin ominaisuudet (Cisco 877). 3.1 ADSL-arkkitehtuuri Tavalliselle ihmiselle ADSL on synonyymi Internet-yhteydelle ja ADSL ym- märretään usein pelkästään operaattorin tarjoamana palveluna. ADSL tulisi käsittää OSI-mallin ensimmäisen kerroksen merkinantoteknologiana, kuten aiemmat modeemiteknologiat. ADSL-teknologian päällä on korkeamman ta- son kehystystapoja kuten ATM-kehystystapa. Tässä insinöörityössä ADSL- tekniikka loi siirtoverkon, jonka päälle on luotu yritysverkko eri palveluineen. ADSL on helppo kuvailla aiemmin esitetyn OSI-mallin avulla. Itse ADSL- teknologian voidaan ajatella sijaitsevan OSI-mallin fyysisellä kerroksella, tar- joten käyttäjille fyysisen yhteyden olemassa olevia puhelinlinjoja pitkin. OSI- mallin seuraava kerros, siirtoyhteyskerros, takaa pääsyn ADSL-kerrokselle. Tässä käsittelemme lähinnä työssä siirtoyhteystekniikkana käytettyä ATM- protokollaa, jota työssä käytetyt D-SLAMit sekä ADSL-sovittimet käyttävät kehystykseen. Siirryttäessä puolestaan OSI-mallin verkkokerrokselle IP- protokolla tarjoaa ADSL-yhteyksille reitityksen sekä osoitteistuksen. Ylem- mät kerrokset tarjoavat kuljetustoiminnot sekä muut tarpeelliset palvelut taa- ten loppukäyttäjälle näkyvän Internetin. Kuvassa 3 on esitetty perusverkko- topologia ja haarakonttorien Cisco 877 reitittimien pääsy Internetiin sekä pääkonttorin verkkoon.
  13. 13. 8 Kuva 3. ADSL-verkkotopologia. ADSL on laajakaistateknologia, mikä tarkoittaa sitä, että se ei käytä koko kuparimedian tarjoamaa kaistaa, vaan käyttää 23000 – 1 100 000 hertsin taajuusaluetta jakaen sen upstreamin ja downstreamin kesken asymmetri- sesti. Tämän taajuusalueen käyttö tekee ADSL:stä yhteensopivan puhelii- kenteen kanssa, jolle on varattu toinen osa kaistasta (0 – 4000 hertsin taa- juusalue). [5, s. 29 – 98.] 3.2 ADSL-koodaustekniikat Tästä taajuusalueesta ADSL ottaa kaiken irti käyttäen monimutkaista sig- naalinkäsittelyä puhelinlinjan molemmissa päissä. Signaalinkäsittelyssä käy- tetään nykyään lähinnä Diskreetti Monitaajuus koodausta (DMT, Discrete Multitone) aiemman Kantoaallottoman amplitudi- ja vaihemodulaation (CAP, Carrierless Amplitude and Phase) sijaan. DMT perustuu datan koodaukseen 256 kapeaan alikanttiaaltoon, jotka sijaitsevat 4.3125 kHz välein. Näiden ali- kanttiaaltojen bittitiheyttä voidaan häiriöiden vaatiessa moduloida niin, että yhden alikanttiaallon maksiminopeus on 60 kbps / 4 kHz taajuus. Datan mo- dulointiin käytetään käänteistä diskreettiä Fourier-muunnosta. [5, s. 39 – 44; 6] DMT koodauksen käyttöön tarvitaan kaksi osapuolta, joista kumpi tahansa ATU-C tai ATU-R voi aloittaa tiedon siirron. Enemmän lisätietoa ATM koo- daustekniikoista voi lukea muun muassa aiheeseen paneutuvasta teoksesta ADSL, jonka on kirjoittanut David Ginsburg, vuonna 2000. [5] 3.3 Datan kehystys ja sovitus ATM:llä Aiemmin kuvattiin ADSL:n toimintaa OSI-mallin fyysisellä kerroksella. Ennen datan modulointia se täytyy kehystää. DMT tukee asynkroonista tiedon siir- tomuotoa (ATM, Asynchronous Transfer Mode). ATM kehystää siirrettävän datan 53-tavuisiin soluihin, jotka koostuvat 5-tavuisista otsakkeista ja 48- tavuisista hyötykuormista. Toisin kuin esimerkiksi IP- tai Ethernet protokollis- sa, ATM-soluissa ei ole ollenkaan kohde- ja lähdeosoitteita. ATM onkin yh- teydellinen protokolla toisin kuin edellä mainitut ja yhteyden muodostus pe- rustuu virtuaalipiirien (VC, Virtual Circuit) ja virtuaalipolkujen (VP, Virtual Path) käyttöön. [7, s. 17 - 29.] Kuvassa 4 on esitetty ATM-solun rakenne.
  14. 14. 9 Kuva 4. ATM-solun koostumus. GFC-kenttä (Generic flow control) on yleinen vuonohjaus kenttä, jota käyte- tään useamman ATM-aseman liikennöidessä samalla ATM-rajapinnalla. 8- tai 12-bittistä VPI (Virtual Path Identifier)-kenttä yhdessä 16 bittisen VCI (Vir- tual Channel Identifier)-kentän kanssa käytetään yhteyden muodostukseen määränpään kanssa. PT (Payload Type) indikoi kuorman sisältöä. Tällä voi- daan erottaa varsinainen käyttäjädata hallintadatasta. CLP (Cell Loss Priori- ty) kenttää käytetään ylikuormitustilanteissa, joissa esiintyy solujen hävikkiä. CLP-kenttä kertoo ATM-kytkimelle, millä prioriteetilla solut sellaisessa vikati- lanteessa käsitellään. HEC (Header Error Check) tarkistaa otsakkeen vir- heettömyyden. ATM ei tarkista hyötykuorman (kuvassa data) virheettömyyttä vaan jättää sen ylempien kerrosten tarkastettavaksi. [5, s.59–72; 8] 3.4 ATM:n toiminta sillatussa muodossa Verkkolaitteiden siltaamisella tarkoitetaan sitä, että verkkolaitteet kommuni- koivat OSI-mallin siirtoyhteyskerroksella. ATM:n toiminta sillatussa tilassa ja reitittävässä tilassa on määritelty RFC (Request For Comments) dokumen- tissa 1483. ATM:n yli kuljetettavan protokollan tunnistamiseksi pitää virtuaa- lipiirin molemmissa päissä päästä yhteisymmärrykseen kuljetettavasta pro- tokollasta tai otetaan käyttöön type-kenttä, jossa määritellään mitä protokol- lia missäkin soluissa kuljetetaan. ATM-yhdistetty Cisco 877-reititin vastaanottaa ATM-virtuaalikanavalla dataa, ohjaa datan edelleen siltakerrokselle ja reitittää paketit eteenpäin IRB (Integ-
  15. 15. 10 rated Routing and Bridging) -toiminnolla. Operaattorin määrittelemä PVC (Permanent Virtual Circuit) määrittelee käytössä olevat VPI/VCI-arvot. [5, s. 77; 9] 3.5 ADSL- ja ATM-käytännöntoteutus Kaikkien etätoimipaikkojen Ciscon 877 reitittimiin konfiguroitiin työn alkuvai- heessa ADSL-yhteyden muodostamiseksi konfiguraatiot. Näistä konfiguraa- tioista puuttuvat NAT-osoitteenmuutokset. Niissä on myös käytetty privaat- tiosoitteita korvaamaan oikeat julkiset osoitteet. Tässä ovat olennaiset konfi- guraatiot ja selitykset niille: bridge irb Aktivoidaan yhdistetty reititys ja siltaus (engl. Integrated Routing and Brid- ging). Tämä ominaisuus mahdollistaa datan siirron reitittävistä rajapinnoista kytkeviin rajapintoihin. IRB:n avulla saadaan useampi looginen ja fyysinen rajapinta samaan VLANiin (Virtual Local Area Network). mtu 1492 Rajoittaa ATM-0 portista lähetettyjen IP-pakettien koon 1492 tavuun. no atm ilmi-keepalive Ottaa pois käytöstä ILMI:n (Interim Local Management Interface) käyttämän keepalive-ominaisuuden. dsl operating-mode auto Tämä komento jättää automaattiseksi käytössä olevan DMT-tilan. Vaihtoeh- toisesti tässä voidaan määrittää käyttöön operaattorin käyttämä DMT- tekniikka. bridge-group 1 Linkittää tämän rajapinnan BVI1:n (Bridge Virtual Interface) alaiseksi. interface ATM0.1 multipoint Ottaa käyttöön alirajapinnan ATM0-liitännälle, jonne tarkemmat ATM- konfiguraatiot on tehty. pvc bridging1 0/100 Määrittää käyttöön RFC 1483:n sillatussa tilassa ja sen käyttöön PVC 0/100:n.
  16. 16. 11 encapsulation aal5snap Valitsee ATM-sovituskerros 5:lla (AAL5) tapahtuva datan kapselointiproto- kollaksi SNAP, joka kertoo, mitä LAN-protokollaa siirretään (tässä tapauk- sessa IP) ATM-verkon yli. bridge-group 2 spanning-disabled Linkittää tämän rajapinnan kuulumaan BVI2:een. Vaihtoehtoinen ”spanning disabled” optio pysäyttää spanning tree protokollan käytön tässä rajapinnas- sa ja BPDU:ien (Bridge Protocol Data Unit) vastaanottamisen sekä lähettä- misen rajapinnassa. Spanning Treetä käytetään vikasietoisten kytkinverkko- jen luonnissa. interface BVI1 Luodaan BVI 1-virtuaalirajapinta. Tämä looginen rajapinta saa reitittävän protokollan (IP) konfiguraatiot, jotka sitten koskettavat kaikkia niitä fyysisiä rajapintoja, jotka on määritelty kuuluvaksi bridge-group 1:een. BVI:n avulla reititin reitittää siltaryhmän ja reitittävien rajapintojen välillä. bridge 1 protocol ieee Määrittää bridge 1:n käyttämään IEEE:n 802.1d STP:tä. bridge 1 route ip Valitaan reitityskäyttöön IP-protokolla bridge 1:n rajapinnoille, joilla on määri- tetty IP-osoite käyttöön (tässä tapauksessa BVI 1:n rajapinnalle). Siltaavana protokollana IP on jo käytössä oletuksena. 4 TCP/IP-VERKOT Ethernet-lähiverkossa isäntäkoneen lähettäessä paketin samassa aliverkos- sa majailevalle isännälle tarvitsee lähettäjän tietää vastaanottajan MAC- osoite. TCP/IP verkoissa data kulkee paketeissa. Jokaisessa IP-paketissa on siirrettävän tiedon lisäksi otsikkokenttä, joka sisältää muun muassa lä- hettäjän ja vastaanottajan IP-osoitteet. Koska TCP/IP-verkoissa ei lähetys- vaiheessa usein tiedetä kuin vastaanottajan IP-osoite, tarvitaan mekanismi myös MAC-osoitteen selvittämiseksi.
  17. 17. 12 TCP/IP-verkoissa isäntäkoneet selvittävät IP-osoitteelle MAC-osoitteen käyt- täen ARP (Address Resolution Protocol) -protokollaa ja RARP (Reverse ARP) tekee saman muunnoksen toiseen suuntaan. [2, s. 66-69.] Osoitteen- selvitykset tallennetaan ARP-tauluun, josta löytyvät selvitetyille IP-osoitteille vastaavat MAC-osoitteet. Kun data-paketteja siirretään lähiverkosta toiseen, tarvitaan reititystä. 4.1 IP-osoitteet ja staattinen reititys Jokaisella TCP/IP-protokollaperhettä käyttävällä laitteella on oma 32-bittinen osoitteensa. Nämä IP-osoiteet on jaettu julkisiin ja yksityisiin osoitteisiin RFC 1918:ssa (Address Allocation for Private Addresses). Alla taulukossa X on esitetty yksityiset osoitteet: Taulukko 2. RFC 1918:n yksityiset IP-osoitteet. Verkkoluokka Varatut IP-osoitteet CIDR A-Luokka 10.0.0.0 – 10.255.255.255 (10/8) B-Luokka 172.16.0.0- 172.31.255.255 (172.16/12) C-luokka 192.168.0.0-192.168.255.255 (192.168/16) Näiden edellä esitettyjen osoitteiden lisäksi on osa IP-osoitteista varattu eri- tystarkoituksiin kuten takaisinkytkentään (loopback, 127-alkuiset osoitteet), yleislähetyksiin (broadcast, 255.255.255.255), verkoille (network, 0.0.0.0) sekä ryhmälähetyksiin (multicast, 224.0.0.0-255.255.255.254). IP-osoitteista puhuttaessa on hyvä muistaa, että ne esitetään binaarimuodossa n.n.n.n, missä jokaista n:ää vastaa 8-bitin kuvaama kokonaisluku. Tästä esimerkkinä on osoite 192.168.255.255, joka binaarimuodossa on 11000000.10101000.11111111.11111111. IP-osoitteen lisäksi käytetään aliverkonmaskia (subnet mask) ilmaisemaan, kuinka monta bittiä IP-osoitteesta kuuluu verkko-osaan. Esimerkiksi osoit- teella 192.168.0.1 ja aliverkonmaskilla 255.255.255.0 ilmaistaan kyseisen osoitteen verkko-osa 192.168.0. Tämä aliverkonmaski voidaan ilmaista myös käyttäen luokatonta CIDR (Classless Inter-Domain Routing) merkintä-
  18. 18. 13 tapaa, tällöin samainen 255.255.255.0 aliverkonmaski esitetään muodossa /24 (3 x 8-bittiä). [1, s. 46 – 59.] 1990-luvun alussa näytti, ettei IP-verkkojen julkiset IP-osoitteet enää riitä kaikille. Tällöin otettiin käyttöön CIDR, joka tar- joaa mahdollisuuden vaihtelevan mittaisten aliverkonmaskien (engl. Varia- ble Length Subnet mask, VLSM) käyttöön. CIDR hylkää jäykät osoiteluokat, jotka olivat syynä osoitteiden haaskaamiselle ja antaa mahdollisuuden käyt- tää verkko-osoitteita tietyllä bittimaskilla. Tämä tarkoittaa sitä, että A-luokan 8-bittisen, B-luokan 16-bittisen tai C-luokan 24-bittisen avaruuden sijaan voi- daan myös käyttää esimerkiksi 20-bittistä aliverkonmaskia ja näin määrittää tarkemmin halutun aliverkon koko. [4, s. 397-399.] TCP/IP-maailmassa reitittimet ohjaavat pakettien välitystä isännältä toiselle reitittämällä. Reitittimen IP-reititys voidaan jakaa kahteen osaan; pakettien mekaaniseen välitykseen oikeaan liitäntään (forwarding) sekä reitittimen yl- läpitämien reititystaulujen päivitykseen (routing). [1, s. 82.] Reititin voi päivit- tää reititystaulunsa joko dynaamisesti toisten reitittimien kanssa käyttäen jo- tain reititysprotokollaa tai staattisesti käsin syötetyillä reiteillä. [4, s. 447.] Tässä työssä keskitytään vain staattiseen reititykseen, jota insinöörityössä käytettiin kertomaan muun muassa oletusyhdyskäytävä reitittimille. Tällai- sesta reitistä käytetään termiä oletusreitti. Se kertoo, mihin kohdeosoittee- seen lähetetään kaikki ne paketit, joiden seuraavan hypyn IP-osoitetta ei löydy reititystaulusta. Ciscon reitittimien IOS-käyttöjärjestelmässä tämä ta- pahtuu komennolla: ip route 0.0.0.0 0.0.0.0 192.168.182.5 [metric] Tässä 0.0.0.0 0.0.0.0 kuvastaa kaikkia niitä IP-osoitteita ja kaikkia niitä ali- verkonmaskeja, joihin ei löydy muuta viittausta reititystaulusta. Puolestaan 192.168.182.5 kuvastaa seuraavan hypyn IP-osoitetta. Samaan tyyliin voi- daan lisätä oletusreitti mihin tahansa verkkoon, kun korvataan 0.0.0.0 0.0.0.0 verkon osoitteella ja aliverkon maskilla. Metric-arvo kuvaa etäisyyttä kohdeverkkoon. Reittejä voi olla useampi samaan kohteeseen, jolloin vali- taan alhaisimman metric-arvon omaava reitti. 4.2 Osoitteiden ja asetusten jako DHCP-protokollalla Nykypäivänä monet kotikäyttäjät käyttävät tietämättään kotiverkossaan seu- raavaksi esiteltäviä DHCP- (Dynamic Host Control Protocol, RFC 1531 ja 3315) ja NAT (Network Address Translation, RFC 1631) -palveluita. Jotta jo-
  19. 19. 14 kaiselle työasemalle ei tarvitsisi erikseen määritellä manuaalisesti IP- osoitetta, tarvitaan osoitteiden jakoon menetelmä, joka hoitaa osoitteiden ja- on ja hallinnan dynaamisesti. DHCP on yleisesti käytetty protokolla, jonka näkyvin tehtävä on jakaa osoitteita niitä kyseleville DHCP-asiakkaille (DHCP Client). Isännälle annettavan IP-osoitteen lisäksi DHCP-palvelin jakaa isän- nälle käyttöön aliverkon maskin, oletusyhdyskäytävän ja nimipalvelimien IP- osoitteet. Osoitteiden jakelu tapahtuu seuraavasti: DHCP-asiakas lähettää alustustilassa DHCP DISCOVER-paketin yleislähetysosoitteeseen tarkoituk- senaan löytää verkosta DHCP-palvelin. Tämän jälkeen palvelin lähettää tar- jouksen asiakkaalle ja asiakas valitsee tarjouksen tai hylkää sen. DHCP:n toiminnassa on lieviä eroavaisuuksia riippuen käytetystä käyttöjärjestelmästä (esim. Windows, Linux ja IOS). DHCP:n universaali periaate on kuitenkin esitetty kuvassa 5. [2, s. 430; 1, s. 66–71.] Kuva 5. DHCP:n toiminta. Edellä esitettyä DHCP-protokollaa käytettiin tässä työssä jakamaan haara- konttoreihin osoitteita. Toinen vaihtoehto olisi ollut palvelittomissa haarakont- toreissa käyttää DHCP relay-palvelua (Cisco tuntee myös palvelun helper address nimellä), joka välittää DHCP-pyynnöt verkkojen välillä. Tätä toimin- toa käytettäessä olisi mahdollista jakaa etäverkkojen asiakkaille DHCP:llä osoitteet pääkonttorin DHCP-palvelimelta. Ciscon toteutusta DHCP- palvelimesta reitittimillä ei voida pitää yhtä skaalautuvana ja monipuolisena kuin DHCP:n palvelintoteutuksia, mutta se riitti tässä työssä riittävästi pieniin
  20. 20. 15 haarakonttoreihin. Näin Internet palveluntarjoajan ei tarvitse välittää DHCP viestejä omassa verkossaan. 4.3 IP-osoitteiden muunnokset NAT-tekniikalla Tässä työssä DHCP-palvelu jakaa työasemille osoitteita yksityisistä osoi- teavaruuksista. Jotta nämä koneet voisivat liikennöidä muun maailman kanssa, tarvitsevat nämä koneet ainutlaatuiset osoitteet julkisten IP- osoitteiden joukosta. Koska Ipv4- (Internet Protocol version 4) osoitteita on ollut rajoitettu määrä (noin 3,7 miljardia) ja korvaavan Ipv6-osoitteistuksen käyttöönotto on ollut hidasta, on tarvittu menetelmä, jolla osoitteita saadaan riittämään kaikille. Tällainen menetelmä on NAT-osoitteenmuunnos, joka julkaistiin vuonna 1994. Se toimii väliaikaisena hätäapuna osoitteiden hupenemiseen [1, s. 108], mutta toisaalta myös estää ulkoverkosta tapahtuvia yhteydenmuodos- tuksia sisäverkkoon. [2, s. 415.] Sen avulla laitteet voivat yksityisillä osoitteil- la muodostaa yhteyksiä myös oman yksityisen verkkonsa ulkopuolelle, julki- seen verkkoon. NAT-osoitteenmuunnos tapahtuu reitittimellä. Osoitteenmuu- tokset voidaan jakaa dynaamisiin-, staattisiin- ja porttiosoitemuunnoksiin. Dynaamisissa osoitteenmuutoksissa muunnetaan tarpeen mukaan sisäver- kon yksityiset osoitteet reitittimellä määriteltyihin julkisiin IP-osoitteisiin. Staattisessa osoitteenmuunnoksessa määritetään tietyt sisäverkon osoitteet muunnettavaksi tietyiksi julkisiksi osoitteiksi. Staattista osoitteenmuunnosta käytetään yleisesti hyväksi sallittaessa liikennettä ulkoverkosta tiettyyn sisä- verkon osoitteeseen. Sisäverkon IP-osoite käännetään ulkoverkon IP- osoitteeksi. Tämä muunnettu IP-osoite tallennetaan reitittimen ARP-taulussa osoittamaan ulkorajapinnan MAC-osoitteeseen. Yritysten yleisesti käyttämää porttiosoitemuunnosta (engl. PAT, Port Ad- dress Translation) taas puolestaan käytetään muuntamaan useampi yksityi- nen sisäverkon IP-osoite yhdeksi julkiseksi IP-osoitteeksi. Kun sisäverkon osoitteet sidotaan porttien numeroihin, saadaan yksi julkinen IP-osoite riittä- mään yrityksen lukuisille työasemille.
  21. 21. 16 5 TIETOTURVA YRITYSVERKOSSA Kun työssä oltiin päästy vaiheeseen, jossa kaikista haarakonttoreista oli toi- miva Internet-yhteys ja etähallintayhteys kaikkiin reitittimiin, oli aika tehdä reitittimille palomuurisäännöt ja VPN-tunnelit pääkonttoriin. Palomuurisään- nöt konfiguroitiin refleksiivisin pääsylistoin. Tietoturvaan kuuluu paljon muutakin kuin tässä luvussa käsiteltävät liiken- teen rajoittaminen (palomuurisäännöt) ja liikenteen salaus (IPSec VPN- tunnelit). Näiden lisäksi on yrityksen huolehdittava työasemiensa tietoturvas- ta ja varautua myös sosiaalisiin tietoturva uhkiin, kuten salasanojen kalaste- luun. 5.1 SSH-yhteydet reitittimien hallinnalle Reitittimien hallintaan käytetään sovelluskerroksen protokollia. Hallintaan käytettäviä sovelluskerroksen protokollia ovat muun muassa Telnet, HTTP ja SSH (secure shell). Jotta myös reitittimien hallinta tapahtuisi tietoturvallisesti, täytyy myös hallintaliikenne salata. Vanhalla telnet-protokollalla muodostet- tuja hallintayhteyksiä julkisen verkon yli ei voida pitää tietoturvallisina, sillä telnet-liikenne lähetetään salaamattomana. Jos joku kaappaisi matkan var- rella tällaista liikennettä, saisi hän poimittua suoraan salasanat päätelaittei- siin IP-paketeista. Toisin kuin Telnet, SSH salaa liikenteen. SSH käyttää hyväksi RSA (Rivest Shamir Adleman) -salausalgoritmia. RSA muodostaa yksisuuntaisen modu- laarifunktion, joka on helppo laskea, mutta jonka tulos on todella hankalaa selvittää. Tämä perustuu siihen, että erittäin suurien alkulukujen (jaollinen vain itsellään) jako tulontekijöihin on vaikeaa. SSH:n versiossa 1, jonka alun perin kehitti espoolainen Tatu Ylönen, oli haavoittuvuus mies-keskellä (man in the middle) -tyyppisille hyökkäyksille. Tämä haavoittuvuus, joka koski avaintenvaihtoa on kuitenkin korjattu SSH versiossa 2. SSH-version 2 käyt- täminen tulee pakottaa SSH-palvelimella (tässä tapauksessa reitittimellä). RSA-avaimet salausta varten luodaan pareissa. Toinen avaimista on julki- nen ja toinen yksityinen. Ennen RSA-avainten luontia Ciscon reitittimelle täy- tyy määrittää nimi ja toimialueen nimi. Tämä siksi, että RSA-avainparin ni- meämisessä käytetään reitittimen nimeä ja toimialueen nimeä hyväksi.
  22. 22. 17 Avainpari luodaan (ja samalla aktivoidaan SSH protokolla reitittimellä) ko- mennolla: crypto key generate rsa [usage-keys | general-keys] [keypair-label] [modu- lus] Kohdassa modulus voidaan määrittää käytetyn salausavaimien vahvuus. Suositeltavaa on käyttää 1024-bittistä modulusta, ei pelkästään tietoturvan takia vaan myös siksi, että tällöin avaimet ovat yhteensopivia IKE:n (Internet Key Exchange) kanssa. IKE on tarkemmin esitelty luvussa 6. 5.2 Liikenteen rajoittaminen palomuurisäännöin Reitittimellä on hyvä harjoittaa liikenteen rajoittamista ja seurantaa jo siitä syystä, että reititin on aina verkkojen rajalla, jakaen verkkosegmentit toisis- taan. Kaikkea liikennettä ei haluta päästä yrityksen sisäverkkoon tietoturvan vuoksi. Ciscon reitittimillä liikenteen rajoittaminen tapahtuu pääsylistoilla (engl. access list) ja tarkemmin sanottuna IP-pääsylistoilla. Liikenne rajoitet- taan sallimalla se vain tietyistä osoitteista ja sallimalla vain yrityksen kannal- ta mielekäs liikenne. Ciscon pääsylistat voidaan jakaa vakiopääsylistoihin (engl. standard access list) ja laajennettuihin pääsylistoihin (engl. extended access list). Lisäksi pääsylistoja voidaan käyttää joko staattiseen tai dynaa- miseen pakettien suodatukseen. Vakiopääsylistat antavat mahdollisuuden sallia tai kieltää liikenne tietyn koh- de- tai lähdeosoitteen perusteella kokonaan. Laajennetut pääsylistat puoles- taan rajoittavat liikenteen kulun käytetyn palvelun, kohde- ja lähdeosoitteet perusteella. Kaikkia näitä voidaan siis käyttää yhdessä käytettäessä laajen- nettuja pääsylistoja. Staattisessa pakettien suodatuksessa säädellään pakettivirtojen kulkua lu- kemalla seuraavia tietoja IP-paketeista: lähde- ja kohdeosoitteet, lähde- ja kohdeportit palveluille sekä TCP liput (engl. flags). Käytännössä lippujen kanssa pelaaminen on hankalaa, eikä tuota niin hyvää tietoturvaa (esim. hyökkääjä voi helposti väärentää TCP-paketin ACK bitin 0:sta 1:ksi) kuin ti- latietojen kerääminen TCP ja UDP istunnoista. Tilatietojen keräämiseen käy- tetään dynaamista pakettien suodatusta. Tilatiedot tallennetaan taulukkoon (engl. state table), josta palomuuri lukee, mitkä sisäänpäin ulkoverkosta tu-
  23. 23. 18 levat paketit liittyvät sisältäpäin alkaneisiin sessioihin ja mitkä taas eivät. Tämän tiedon perusteella palomuuri hylkää ja hyväksyy paketit. Ciscon pääsylistojen konfiguroinnissa ja seuraavan esimerkin yhteydessä in tarkoittaa ulkorajapintaan fastethernet 0 saapuvaa liikennettä ja out rajapin- nasta lähtevää liikennettä. Koska kyseessä on juuri ulkorajapinta tarkoittaa tämä sitä, että in tarkoittaa ulkoverkosta saapuvaa liikennettä ja out puoles- taan ulkoverkkoon lähtevää liikennettä. Esimerkkinä tästä sallitaan palomuu- rilla R1 (kuva 6) inside-verkoon (LAN) Internetistä palaava http-liikenne: ip access-list extended FW_IN permit tcp any any eq 80 evaluate FW_TRAFFIC ip access-list extended FW_OUT permit ip any any reflect FW_TRAFFIC Otetaan pääsylistat FW_IN ja FW_OUT käyttöön Outside-rajapintaan (fas- tethernet 0): interface fastethernet 0 ip access-group FW_IN in ip access-group FW_OUT out Kuva 6. Refleksiivisen pääsylistan toiminta.
  24. 24. 19 Näin konfiguroidaan refleksiivisiä pääsylistoja. Refleksiivisyys tulee siitä, että FW_OUT pääsylista lukee FW_TRAFFIC taulun istuntotilatietoja ja peilaa kuvassa X esitetyt ulospäin lähteneiden http-istuntojen sessionumerot si- säänpäin sallittavaan liikenteeseen. [10] 6 IPSEC PÄÄSTÄ-PÄÄHÄN ERILLISVERKOT (IPSEC LAN-TO-LAN VPN) Tässä luvussa esitellään IPSec (IP Security)-standardi, joka ensi kerran määriteltiin dokumentissa RFC 2401. IPSec on joukko tietoliikenneprotokol- lia, joiden avulla voidaan toteuttaa tietoturva OSI-mallin verkkokerroksella. IPSec-protokollat voidaan jakaa joko avaintenvaihtoprokolliin ja IP- datagrammit suojaaviin protokolliin. IPSec toimii IP-kerroksella salaten kaik- kien IP:n päällä toimivien protokollien pakettivirrat ottamatta kantaa salatta- vaan protokollaan. IP-datagrammien suojaukseen käytettäviä protokollia on kaksi: AH (Authen- tication Header) ja ESP (Encapsulating Security Payload), joista ainoastaan ESP takaa datan todennuksen, eheyden ja luottamuksellisuuden. AH puo- lestaan takaa datan todennuksen ja eheyden, muttei datan luottamukselli- suutta. Suojausprotokollat tarvitsevat toimiakseen luotettavaa avaintenvaih- toa. Avaimia vaihdetaan suojauksena brute force-hyökkäyksiltä, joissa tieto- koneiden kasvavaan laskentavoimaan perustuen käydään läpi kaikki mah- dolliset salasanayhdistelmät. IPSec:n käytössä avaintenvaihtoon käytettään yleisesti IKE (Internet Key Exchange) protokollaa. [3,s. 41- 50; 11,s. 257 - 292.] 6.1 IPSEC-pakettivirtojen turvaus IPSec:n pakettivirtojen siirtämisessä voidaan käyttää joko tunnelointi- (tunnel mode) tai kuljetustilaa (transport mode). Tunnelointitilaa käytettäessä suoja- taan koko IP hyötykuorma, kun taas kuljetustilaa käytettäessä suojataan vain ylempien kerrosten hyötykuorma. Tässä työssä on käytetty tunnelointiti- laa. Kuljetustilaa suositellaan käytettävän vain silloin, kun pakettivirtoja tur- vaavat osapuolet ovat myös itse keskustelevat osapuolet. Kuljetustilassa IP datagrammiin syötetään IPSec-otsikko IP-otsikon ja ylem- män kerroksen protokollan otsikon väliin, kun tunnelointitilassa koko IP-
  25. 25. 20 paketti kapsuloidaan uuteen IP-pakettiin ja IP-pakettien otsikoiden väliin syö- tetään IPSec-otsikko. Näin saavutetaan tunnelointilassa koko alkuperäisen IP-paketin (mukaan lukien otsikko) salaus. Tunnelointitilan käyttö on suosi- teltua, sillä sen avulla voidaan salata liikenteen alku- ja loppupään yksityiset IP-osoitteet. Se on myös NAT-yhteensopiva (NAT-transversal). ESP ja AH voivat molemmat toimia sekä tunnelointi- että kuljetustilassa. Kuvassa 7 on esitelty alkuperäinen, kuljetus- ja tunnelointitilan IP-paketti. Alkuperäinen IP TCP Data paketti otsikko otsikko Kuljetustilassa IP IPSec TCP Data turvattu otsikko otsikko otsikko Tunnelitilassa IP IPSec IP TCP Data turvattu otsikko otsikko otsikko otsikko Kuva 7. IP-paketin turvaus kuljetus- ja tunnelointitilassa. IP-pakettien turvaaminen vaatii tavan yhdistää toisiinsa käytetty turvaamis- tekniikka, salausavain ja tunnelin toisessa päässä sijaitseva IPSec- vertainen. IPSec SA (Security Association) linkittää nämä toisiinsa. SA:t ovat yksisuuntaisia. Tyypillisesti niitä on tunnelia kohden yksi menoliikenteelle ja yksi paluuliikenteelle. SA:t tunnistetaan IPSec-otsikossa sijaitsevasta SPI (Security Parameter Index) -luvusta, joka on satunnaisesti luotu luku. Kun IPSec-vertainen lähettää paketin, se tarkistaa, miten paketti käsitellään SPD (Security Policy Database) -tietokannasta, jonne IPSec Policyt on tal- lennettu. IPSec Policy määrittää, milloin ja miten IP-liikenne salataan. SPD antaa kolme vaihtoehtoa IP-paketille. Nämä ovat hylkäys (discard), ohitus (bypass) ja suojaus (protect). Hylättyä liikennettä ei päästetä sisään eikä ulos ja ohittava liikenne käsitellään turvaamatta sitä. Jos liikenne vastaa IP- Sec Policyn määrittämää suojattavaa liikennettä, niin sille etsitään SPD:stä osoitus tiettyyn SADB (Security Association Database) tietokannassa sijait- sevaan SA:iin. SA:lla toteutetaan tarvittavat tietoturva algoritmit ja lisätään aiemmin mainittu SPI IPSec-otsikkoon. IPSec:n pakettivirtojen turvaus on määritelty RFC dokumenteissa RFC 2406 (ESP) ja RFC 2402 (AH). Koska ESP takaa sekä luottamuksellisuuden, että todennuksen, ESP:n SA koostuu kahdesta osasta; salakirjoitusosasta
  26. 26. 21 (cipher), joka huolehtii luottamuksellisuudesta ja tunnistajaosa (authentica- tor), joka huolehtii todennuksesta. ESP:n käyttö vaatii, että vähintään toista näistä käytetään. [3, s. 41-55.] 6.2 IPSEC-avaintenvaihto Kun SPD määrittelee suojauksen paketille, mutta ei osoita olemassa ole- vaan SA:iin, luodaan dynaamisesti uusi IPSec SA. Tässä käytetään Internet Key Exchange (IKE)-avaintenvaihtoa hyväksi. IPSec käyttää IKE:ä myös avainten uusimiseen tietyin väliajoin raakavoima (brute force) -hyökkäyksiltä suojautuakseen. IKE-protokolla käyttää osia Oakley- ja SKEME- (Secure key Exchange Mechanism) -avaintenvaihtoprotokollista ja on virallinen IPSec:n avainten- vaihtoprotokolla, joskaan ei ainoa vaihtoehto. Uuden IPSec SA:n luominen koostuu kahdesta vaiheesta: IKE Phase 1:stä, jossa sovitaan käytettävistä turvausmenetelmistä (luodaan ISAKMP SA) ja IKE Phase 2:sta, jossa luo- daan identtiset IPSec SA:t molemmille IPSec-vertaisille, joiden avulla lähe- tettävä data suojataan. IKE Phase 1:ssä neuvoteltava SA määrittää, millä algoritmilla vertaisten vä- lillä IKE-liikenne (oletuksena UDP-portti 500) salataan ja miten autentikoi- daan toinen osapuoli. Phase 1:ssä neuvotellaan ensiksi käytettävä turvaeh- dotus (protection suite). Turvaehdotuksessa on kahden osapuolen välillä päästävä yhteisymmärrykseen käytettävästä salausalgoritmista (engl. enc- ryption, esim. 3DES), tiiviste-funktiosta (engl. hash function, esim. MD5, SHA), Diffie-Hellman ryhmästä (DH group) ja autentikointitavasta. Diffie-Hellman on salaukseen käytettävä protokolla, jota IKE käyttää luo- maan Phase 1:ssä yhteisen salaisuuden. Diffie-Hellman protokolla luo tur- vallisesti yhteisen avaimen käyttäen hyväksi sitä, että logaritmien laskemi- nen on kokonaislukuaritmetiikassa erittäin vaikeaa. Diffie-Hellman ryhmä määrittää käytettävän algoritmin ja ne vaihtelevat vahvuudeltaan, DH ryh- män 1:n ollessa 768-bittinen, ryhmän 2 ollessa 1024-bittinen ja DH ryhmän 5 ollessa 1680-bittinen vahvuudeltaan. Nagand Doraswamy ja IKE protokollan kehittäjä Dan Harkins kannattavat lähteessä [3, s.112] laitevalmistajien tukea vahvoille DH-ryhmille. Täytyy kuitenkin todeta, että kuten Chris Brenton neu- voo lähteessä [10, s. 409], niin käytännössä tehottomimmilla reitittimillä (ei
  27. 27. 22 VPN-konsentraattoreilla) ja VPN-liikenteen määrän ollessa suuri kannattaa suosia DH-ryhmän 1 käyttöä. Kuvassa 8 on esitetty DH:n toiminta. Ensimmäisessä vaiheessa vertaiset sopivat käytettävän DH ryhmän. Toisessa vaiheessa molemmat vertaiset luovat itselleen yhden yksityisen – ja yhden julkisen avaimen. Lopuksi yhdis- tämällä ne ristiin kuvan 8 mukaisesti luodaan identtiset jaetut salaisuudet, joita käytetään uusien salaus- ja autentikointiavainten luontiin IKE Phase 2:ssa. A B Vertainen A & B valitsevat DH Vertainen Vaihe 1 A ryhmän B Julkinen Julkinen arvo arvo Vaihe 2 Yksityinen Yksityinen arvo arvo Yksityinen arvo A Yksityinen arvo B ja julkinen arvo B ja julkinen arvo yhdistetään A yhdistetään A B Jaettu salai- = Jaettu salai- Vaihe 3 suus suus Kuva 8. Diffie-Hellman (IKE vaihe 1) avaintenvaihto. Vaikka näin saatu salaisuus olisikin turvallinen, täytyy vielä olla varma siitä, että vastapuoli todella on luotettava autentikoimalla se. IKE:n autentikointi voidaan tehdä etukäteen jaetuilla avaimilla (PSK, Pre Shared keys), digitaa- lisilla allekirjoituksilla eli sertifikaateilla tai salaamalla Diffie-Hellman salai- suudesta johdettu julkinen avain. Tässä työssä käytettiin vahvoja etukäteen jaettuja avaimia, mutta sertifikaattien käyttöönotolla voitaisiin jatkossa hel- pottaa tunneleiden ylläpitoa ja parantaa tietoturvaa entisestään. IKE Phase 1:ssä voidaan käyttää joko hitaampaa ja turvallisempaa main moodia (main mode) tai agressiivista moodia (agressive mode). Main moo-
  28. 28. 23 din käyttö on suositeltavaa. Kun agressiivisessa moodissa vaihdetaan vain kolme viestiä, niin main moodissa vaihdetaan yhteensä kuusi viestiä: • 2 viestiä sopivat turvaehdotuksen. • 2 viestiä vaihtavat Diffie-Hellman avaimet. • 2 viestiä autentikoivat vertaisen. IKE Phase 2:ssa on vain yksi moodi, quick moodi (quick mode). Kun phase 1:ssä on muodostettu turvallinen yhteys vertaiseen, niin phase 2:n tehtävänä on sopia käytettävistä IPSec parametreista ja luoda lopullinen IPSec SA. IKE Phase 2 sopii käytettävät IPSec parametrit niputettuna ”transform set”:iin, jo- ka on yhdistelmä algoritmeja ja protokollia jotka muodostavat yhdessä tur- vapolitiikan, security policyn, lopulliselle dataliikenteelle. [3, s. 41-139; 12, s. 453-509.] 6.3 IPSEC VPN-toteutus Kuten muutkin työssä tehdyt konfiguraatiot, niin myös IPSec-konfiguraatiot tehtiin Ciscon reitittimille käyttäen IOS-käyttöjärjestelmän komentoriviä. Ohessa esimerkkikonfiguraatio mahdollisesta haarakonttorin konfiguraatios- ta ja selitykset konfiguraatioille. Ensiksi luodaan isakmp policy, joka määrittää IKE:n Phase 1 salaukseksi 3DES:n (encryption 3des), tiivistefunktioksi MD5:n (hash md5) ja autenti- kointitavaksi etukäteen jaetut avaimet (authentication pre-share). crypto isakmp policy 10 encryption 3des hash md5 authentication pre-share Määritetään etukäteen jaetut avaimet vertaisille. Vertaisia on kaksi vi- kasietoisuuden vuoksi. Tähän palataan luvussa 7. Lisäksi määritetään isakmp keepalive, joka tarkistaa määritetyin väliajoin, että vertaiset ovat yhä saavutettavissa. crypto isakmp keepalive 10 periodic komento aloittaa DPD (Dead Peer Detection) -viestien lähettämisen vertaisille 10 sekunnin vä- liajoin. Periodic-optio komennon perässä mahdollistaa viestien jatkuvan lä- hettämisen. Näin saadaan havaittua nopeammin IPSec-tunnelin toimimatto- muus. [13] crypto isakmp key S4L41N3n address 1.1.1.1
  29. 29. 24 crypto isakmp key 4v4iNn1ppU address 2.2.2.1 crypto isakmp keepalive 10 periodic Seuraavaksi määritetään voimassaoloaika kaikille crypto map:eille ja IKE Phase 2:ssa sovittavat IPSec-parametrit (transform set): crypto ipsec security-association lifetime seconds 86400 crypto ipsec transform-set METROPOLIA-SET esp-3des esp-md5-hMAC Crypto map sitoo jo aiemmin määritellyn transform-set:n (METROPOLIA- SET) vertaisiin. Luodaan crypto map nimeltä VPN, jota käytetään molempien vertaisten kanssa, määritetään 60 sekuntia ajaksi, jolloin joutilaana olevalta vertaiselta poistetaan IPSec SA. Lopuksi kerrotaan crypto mapille, minkä pääsylistan (VPN-PAASY) mukaan tähän paketteja otetaan crypto map VPN:n käsittelyyn: crypto map VPN 10 ipsec-isakmp set peer 1.1.1.1 default set peer 2.2.2.1 set security-association idle-time 60 set transform-set METROPOLIA-SET match address VPN-PAASY Pääsylista VPN-PAASY kertoo, että haarakonttorin LAN verkosta 10.0.0.0 /8 lähtevät paketit pääkonttorin sisäverkkoon 192.168.182.0 /24 ovat IPSec mielenkiintoista liikennettä ja ne suojataan crypto map VPN:ssä määrätyllä tavalla. ip access-list extended VPN-PAASY permit ip 10.0.0.0 0.255.255.255 192.168.182.0 0.0.0.255 Yllä olevassa pääsylistassa käytettiin wildcard-maskeja (edellä oleva maskit 0.255.255.255 ja 0.255.255.255). Ne toimivat aivan kuten aliverkon maskit- kin paitsi, että ne esitetään käänteisessä muodossa niin, että binaarinollat ovat muutettu binaariykkösiksi ja toisin päin. Tästä seuraa se, että aliverkon maski 255.0.0.0 on wildcard-maskina esitettynä 0.255.255.255. Seuraavaksi sidotaan crypto map VPN vielä ulkorajapintaan, joka on haara- konttorien tapauksessa BVI1. Näin kaikilta ulkorajapintaan BVI1 tulevilta pa- keteilta tarkistetaan täsmäävätkö ne pääsylista VPN-PAASY:n kanssa, jos täsmäävät ne suojataan crypto map VPN:n mukaisesti:
  30. 30. 25 interface BVI1 ip address 172.16.32.1 255.255.255.0 crypto map VPN Pitää myös muistaa kieltää suojattavan liikenteen NAT-osoitteenmuutos: ip access-list extended NAT deny ip 10.0.0.0 0.255.255.255 192.168.182.0 0.0.0.255 permit ip 10.0.0.0 0.255.255.255 any Tässä deny ip-komento saa aikaan sen, että verkosta 10.0.0.0 /8 (haara- konttori) verkkoon 192.168.182.0 /24 (pääkonttori) matkaava liikenne suoja- taan ja alkuperäinen IP-paketin lähdeosoite pysyy muuttumattomana. Jos molempien päiden VPN-reitittimet ovat konfiguroitu eikä IPSec-tunneli nouse pystyyn, tulee vika paikantaa. Komentorivillä työskennellessä Ciscon IOS tarjoaa tähän kaksi show-komentoa, jotka yleensä antavat tarvittavan tiedon vian paikannukseen. Komennot ovat: show crypto isakmp sa show crypto ipsec sa Jos ensimmäinen komento kertoo, että isakmp sa on tilassa qm_idle (IPSec SA:t on onnistuneesti neuvoteltu), niin kannattaa seuraavasta komennosta tarkastaa salataanko paketteja varmasti molemmissa päissä. Näin saadaan vikatilanteessa selville, kummassa päässä liikenne ei kulje tunneliin. Tästä voidaan jatkaa tutkimalla (engl. debug) ongelmaa tuossa päässä tunnelia. 7 VIKASIETOINEN YRITYSVERKKO Yhtenä tämän työn keskeisistä tavoitteista oli luoda verkko, joka selviäisi sel- laisessa vikatilanteessa, jossa yrityksen pääkonttorin pääyhteys olisi poikki. Tätä varten on yritykseen hankittu kaksi eri internet-yhteyttä eri operaattoreil- ta. Kun pääkonttorin pääyhteys katkeaa, niin pääkonttorin pitää päästä verk- koon varayhteyttä käyttäen ja etäkonttorien muodostaa uusi VPN-tunneli pääkonttorin varalinjan kautta pääkonttorin sisäverkkoon. Lopulta valittu lä- hestymistapa ei perustu niinkään vikasietoisuus protokollan (esim. Ciscon HSRP, Hot Standby Routing Protocol) käyttöön vaan manuaalisesti konfigu- roitaviin jäljitysmekanismeihin yhdelle reitittimelle. Tämän lähestymistavan ratkaisi se, että pääkonttorin yhteydet oli alun perin myyty asiakkaalle aja-
  31. 31. 26 tuksella siitä, että toinen laite olisi vain virratta varalla. Hyvä puoli valitussa lähestymistavasta oli se, että toteuttamalla tämä ratkaisu saatiin hyvää ko- kemusta vikasietoisuuden toteuttamisesta yhdellä reitittimellä. 7.1 Pääkonttorin vikasietoisuus Pääkonttorin yhteydet toteutettiin niin, että kahdelta eri Internet- palveluntarjoajalta tilattiin SHDSL (Single-pair High-speed Digital Subscriber Line) Internet-yhteydet. Niiden mukana toimitettiin myös operaattorien reitit- timet (kuvassa X ISP 1 ja ISP 2), jotka on kytketty kiinni yrityksen reitittimeen (kuvassa X Reititin A). Operaattorien reitittimiltä on suora yhteys eri DSLAM:ien kautta operaattorien runkoverkkoihin. Kuvassa 9 on esitetty pääkonttorin yhteydet ulkomaailmaan ja skenaario I, jossa pääyhteys katke- aa välillä operaattorin reititin – yrityksen reititin (Cisco 1812 Integrated Servi- ces Router). Kuva 9. Pääkonttorin tietoliikenneyhteydet ja skenaario I. Kuvassa 9 Reititin A ei saa yhteyttä pääyhteyden kautta Internetiin ja ottaa tällöin käyttöön varayhteyden ISP2:n kautta. Tässä skenaariossa Reititin A on konfiguroitu valvomaan linkin tilaa (Reititin A 1.1.1.1). Tämän ollessa al- haalla otetaan käyttöön varayhteys. Tämä oli aluksi toteutettu vikasietoisuus, mutta tämä ratkaisu ei tuonut parannusta siihen skenaarioon, että itse ope- raattorin yhteys katkeaa jostain muualta kuin väliltä Reititin A – ISP1. Jos ISP1 reitittimeltä tällöin katkeaisi yhteys DSLAM:n takana olevaan runko- verkkoon ja näin koko yrityksen verkko menisi alas, ei Reititin A silti osaisi ot- taa käyttöön varalinjaa, sillä ISP1:n seuraavan hypyn IP-osoite 1.1.1.2 vas-
  32. 32. 27 taisi edelleen Reititin A:lle ja valvottava linkki olisi ylhäällä. Näin Reititin A edelleen käyttäisi ISP 1:stä oletusyhdyskäytävänä ja paketit hukkuisivat lin- jalle. Tämän problematiikan selvittäminen oli koko insinöörityön haastavin osa. Tarvittiin keino, jolla Reititin A pystyisi valvomaan etäisten ip-osoitteiden ti- laa, eikä siis vain linkin tilaa kuten skenaario I:ssä. Kun etäinen IP-osoite ei enää vastaisi Reititin A:lle, se poistaisi reititystaulusta vanhan oletusreitin ISP 1:lle ja siirtyisi käyttämään ISP 2:ta oletusyhdyskäytävänä. Etäisten IP- osoitteiden valvontaa varten tarvittiiin käyttöön IP SLA monitor-toiminto. IP SLA monitorin ICMP Echo-toiminto valvoo ICMP-viesteillä etäisen laitteen saatavuutta. Se vaatii toimiakseen lähettäväksi osapuoleksi Ciscon reititti- men ja vastaanottavaksi verkkolaitteeksi minkä tahansa laiteen, joka tukee RFC 862:sta. Cisco itse toki suosittelee, että tämä laite olisi myös Ciscon valmistama. IP SLA-monitor vaati Ciscon IOS (Internetwork Operating System) - käyttöjärjestelmän päivityksen uudempaan versioon. IP SLA monitor palaut- taa arvon up tai down sen mukaan, onko kohdeosoite tavoitettavissa. Tämä arvo sitten sidotaan käytettävään reittiin. IP SLA monitorin palauttaman ar- von sitominen reititystauluun syötettyihin reitteihin onnistuu käyttäen track toimintoa. Kuvassa 10 on esitetty skenaario II, jossa yhteys toimii vielä sil- loinkin, kun yhteys katkeaa kauempaa ja Reititin A:n oletusyhdyskäytävä 1.1.1.2 edelleen vastaa Reititin A:lle. Kuva 10. Pääkonttorin tietoliikenneyhteydet ja skenaario II. Valvottavaksi IP-osoitteeksi valittiin ISP 1:n WAN IP-osoite 10.10.10.1 sillä, jos tämä osoite on tavoittamattomissa, niin silloin pääyhteys on varmasti
  33. 33. 28 poikki. IP SLA monitor-toimintoa käyttäen valvonta konfiguroidaan seuraa- vasti: ip sla monitor 1 type echo protocol ipIcmpEcho 10.10.10.1 timeout 500 threshold 500 frequency 3 ip sla schedule 1 life forever start-time now Käytetyt ajastukset timeout 500 ja threshold 500 tarkoittavat, että monitor 1 odottaa 500 millisekuntia vastausta osoitteelta 10.10.10.1 ja päivittää tilatie- tonsa (ylhäällä tai alhaalla) 500 millisekunnin kynnyksin (threshold). Lähdet- täessä konfiguroimaan IP SLA monitoria reitittimelle tulee huomioida, että se on piilotettu toiminto Ciscon IOS-käyttöjärjestelmässä. Luodaan track 100 ja sidotaan se IP SLA monitor 1:n tila (up / down): track 100 rtr 1 reachability Luodaan track 200 ja sidotaan se invertoidusti track 100:aan: track 200 list boolean and object 100 not Konfiguroidaan staattiset oletusreitit, jotka sidotaan track 100:aan (pääyhte- ys) ja track 200:aan (varayhteys). Annetaan varareitille metric arvo 254 (ole- tuksena 1). Näin palataan käyttämään metric arvolla 1 reititystauluun uudel- leen nousevaa pääreittiä, kun IP SLA monitor alkaa jälleen palauttaa ”up” arvoa ja tämän seurauksena track 100 palaa ylös: ip route 0.0.0.0 0.0.0.0 1.1.1.2 track 100 ip route 0.0.0.0 0.0.0.0 2.2.2.2 254 track 200 Säädetään reititystaulun päivitykset tapahtumaan 3 sekunnin viiveellä staat- tisten reittien osalta: ip route static adjust-time 3 Jotta NAT-osoitteenmuutokset toimisivat myös varayhteyden ollessa käytös- sä, tulee luoda molemmille rajapinnoille (fastethernet 0 ja fastethernet 1) route-map:t. Route mapit toimivat pääsylistojen tavalla, mutta ne tuovat li- sämahdollisuksia monimutkaisiin verkkoihin tarjoamalla ehtoja (conditions)
  34. 34. 29 valittavalle reitille. Osuma (match) -ehdot kertovat, mitkä ehdot täytyy täyttyä ennen kuin route map:n toiminnot (set) suoritetaan. Pääsylistojen lisäksi NAT vaatii 2 ulkorajapinnalla käyttöön route mapit, sillä route mapien lopussa olevilla match interface komennoilla voidaan määrittää myös käytettävä rajapinta toisin kuin, jos käytettäisiin pelkkiä pääsylistoja. Route mapit konfiguroidaan käyttämään pääsylistaa nimeltä NAT, jossa salli- taan niille paketeille osoitteenmuutos, joiden lähdeosoite vastaa sisäverkon IP-osoitteita: route-map BACKUP-NAT2 permit 10 match ip address NAT match interface FastEthernet1 ! route-map BACKUP-NAT permit 10 match ip address NAT match interface FastEthernet0 ! ip access-list extended NAT permit ip 192.168.182.0 0.0.0.255 any Itse osoitteiden muunnokset konfiguroidaan sitten vielä erikseen molemmille rajapinnoille komennoilla: ip nat inside source route-map BACKUP-NAT interface FastEthernet0 over- load ip nat inside source route-map BACKUP-NAT2 interface FastEthernet over- load Viimeiseksi vielä ilmoitetaan rajapinnoille ovatko ne NAT:n ulko- vai sisäpuo- lella: interface FastEthernet0 ip address 1.1.1.1 255.255.255.248 ip nat outside ! interface FastEthernet1 ip address 2.2.2.1 255.255.255.248 ip nat outside ! interface Vlan1 ip address 192.168.182.0 255.255.255.0 ip nat inside
  35. 35. 30 Jäljitettäessä (engl. track) edellä esitetyllä tavalla yhteyden tilaa on syytä tarkistaa ainakin seuraavat neljä asiaa: IP SLA monitor:n palauttamat arvot, trackin tila, reittien tilat sekä NAT:n toimivuus. Komennolla show ip sla moni- tor 1 voimme tarkistaa monitor 1 toiminnan. Jos sen palauttamat succeeded arvot kasvavat, toimii ICMP viestien lähetys halutulla tavalla. Trackin tila puolestaan kertoo meille toimiiko asetetut ehdot ja palauttaako track 100 ar- von ”up” vai ”down”. Trackin 100 arvo voidaan tarkistaa komennolla show track 100. Reittien tilaa tarkistaessa on hyvä käyttää show ip route komen- non lisäksi spesifistä show ip route track-table komento, joka näyttää trackeihin sidottujen reittien lisäksi kyseisten trackien tilan. [14] 7.2 Haarakonttorien vikasietoisuus Haarakonttorien vikasietoisuudella tarkoitetaan tässä työssä sitä, että kun pääkonttorin pääyhteys on poikki, niin haarakonttorit muodostavat IPSec- tunnelit pääkonttorin varayhteyteen ja pääsevät tätä kautta käsiksi pääkont- torin sisäverkkoon. Koska yhteydet haarakonttoreista pääkonttoriin on ra- kennettu suojatuin IPSec-tunnelein, tarvittiin vikatilannetta varten redundant- tiset tunnelit pääkonttoriin. Luvussa 5.3 esitettiin, kuinka tunnelit ovat konfi- guroitu samaan crypto map:iin haarakonttorien reitittimillä ja kuinka Dead Peer Detection aktivoidaan havaitsemaan alas mennyt tunneli. Crypto mapin sisällä optiolla ”default” (set peer 1.1.1.1 default) määritetään oletus vertai- nen, jonka kanssa tunneli ensisijaisesti muodostetaan. Kun haarakonttorin reititin havaitsee ”kuolleen vertaisen”, IPSec:n SPD aloittaa välittömästi uu- den tunnelin muodostuksen toisen vertaisen kanssa (set peer 2.2.2.1). Tämä on esitetty kuvassa 11.
  36. 36. 31 Kuva 11. Haarakonttorien vikasietoisuus. Kun pääkonttorin Reititin A:n yhteys palautuu ja haarakonttorin reititin ha- vaitsee sen taas olevan ylhäällä, SPD poistaa vika-aikana luodun IPSec SA:n vertaisen 2.2.2.1 kanssa ja neuvottelee tunnelin pystyyn vertaisen 1.1.1.1 kanssa. Ajallisesti tämä konvergenssi tapahtuu muutamassa sekun- nissa, joka on riittävän nopea palautuminen vikatilanteesta ja loppukäyttäjäl- le huomaamaton. 7.3 Vaihtoehtoisia näkökulmia vikasietoisuuteen HSRP:llä Pääkonttorin vikasietoisuutta toteutettaessa olisi voitu käyttää redundanssi- protokollia ja kahta asiakasreititintä. Tässä luvussa käydään lyhyesti läpi re- dundanssiprotokolla HSRP:n (Hot Standby Routing Protocol) toiminta me- nemättä kuitenkaan tarkkoihin HSRP:n konfiguraatioihin. Nimensä mukai- sesti HSRP perustuu siihen, että toinen asiakaan reitittimistä on valmiusti- lassa (standby) kuunnellen aktiivilaitteen (active) tilaa.
  37. 37. 32 HSRP on yksinomaan Ciscon käyttöjärjestelmillä toimiva redundanssiproto- kolla. Sen avulla ryhmä reitittimiä muodostaa niin sanotun virtuaalireitittimen, joka toimii sisäverkon oletusyhdyskäytävänä. Kuvassa 12 on esitetty kuinka HSRP:n käyttö olisi muokannut verkkoa, jos molemmat Internet-yhteydet oli- si tilattu samalta operaattorilta. HSRP ryhmä 0:lle annetaan virtuaalinen IP- osoite ja virtuaalinen MAC-osoite, kuten myös operaattorin toimesta HSRP ryhmä 1:lle. Reititinryhmät valitsevat keskuudestaan aktiivisen reitittimen, jo- ka hoitaa pakettien reititykset. Valinta perustuu prioriteettinumeroon. Isom- man prioriteetin omaava laite toimii aktiivisena laitteena. Kuva 12. Pääkonttorin HSRP-toteutus yhdellä operaattorilla. Toinen reitittimistä jää valmiustilaan (standby). Valmiustilassa ja aktiivitilassa olevat laitteet lähettävät keskenään hello-viestejä multicast osoitteeseen 224.0.0.2 käyttäen UDP porttia 1985. Aktiivilaitteen viottuessa tai sen yhte- yksien katketessa valmiustilassa oleva laite rupeaa toimimaan aktiivilaittee- na. [15, s. 341-381]
  38. 38. 33 Kuva 13. Pääkonttorin HSRP-toteutus kahdella eri operaattorilla. HSRP:tä voidaan myös käyttää eri operaattorien kanssa, tällöin operaattorin laitteiden välillä ei ole HSRP-ryhmää, vaan pelkästään asiakkaan reitittimien välillä (kuvassa 13 HSRP ryhmä 0). HSRP konfiguroidaan sisäverkon raja- pintaan ja se voidaan joko konfiguroida valvomaan ulkorajapinnan tilaa tai etäisen IP-osoitteen tilaa. Valvottaessa etäisten IP-osoitteiden tilaa toimitaan aivan kuten tässä työssä toimittiin IP SLA Monitorin ja trackien kanssa. Ero- na kahden reitittimen toteutuksessa on se, että nyt meidän ei tarvitse sitoa reittejä eikä NAT-osoitteenmuunnoksia trackien tilaan. Riittää, että HSRP si- dotaan trackien tilaan. Kun tämä tila muuttuu, niin HSRP vaihtaa aktiivilaitet- ta. Eli kahden reitittimen toteutuksessa ei tarvitse käyttää route mapeja NAT:ien kanssa eikä manuaalisesti trackeihin sidottuja reittejä. Tätä toteu- tusta ei kuitenkaan tämän työn yhteydessä testattu tuotannossa. 8 JOHTOPÄÄTÖKSET Työssä ATM-tekniikalla toteutetut ADSL-liittymät olivat mielestäni onnistunut valinta. Sen jälkeen, kun nämä liittymät saatiin pystyyn niiden kanssa ei ole juuri ollut ongelmia. Liittymävalinnat täytyy nähdä ennen kaikkea kustannus-
  39. 39. 34 kysymyksenä ja tästä näkökulmasta tarkasteltuna, hieman ikääntyneellä, ATM-kehystyksellä toteutetulla, ADSL-pääsyllä puhelinverkon yli saavute- taan hyvä hinta-laatusuhde. Käytettäessä omia ADSL-päätelaitteita operaat- torin laitteiden sijaan, tulee käyttää vain laadukkaimpia laitteita, koska linjan vikaantuessa operaattori tulee aina olettamaan, että vika ei ole operaattorin verkossa ennen kuin toisin todistetaan. Käytännössä tästä voi aiheutua tur- hia kustannuksia, sillä yhteyden ollessa katki, emme pääse varmistamaan meidän päätelaitteen toimivuutta ja operaattorin tehdessä turhaa työtä, tulee se myös työstä laskuttamaan. Toisaalta ongelmasta päästään eroon, jos liit- tymien tilauksen yhteydessä tilataan erikseen operaattorilta päätelaitteet. Jos tästä aiheutuvat kustannukset eivät juuri nosta operaattorin kuukausi- maksua, niin operaattorin päätelaitteen käyttäminen on järkevämpää edellä mainitusta vastuusyystä. Mitä taas tietoturvaan tulee, niin ratkaisu täyttää yleiset tietoturvavaatimuk- set. Ei pidä kuitenkaan unohtaa, että tietoturvaan kuuluu paljon muutakin kuin tiedon salaus ja pääsyrajoitukset. Työtä tehdessäni kohtasimme sisä- verkosta alkunsa saaneen palvelunesto (engl. DOS, Denial of Service) - hyökkäyksen, kun eräs viruksen saastuttama tietokone alkoi lähettää ICMP- viestejä sisä- ja ulkoverkon IP-osoitteisiin. Vaikka viestit lähtivät vain yhdeltä työasemalta, oli tämä hyökkäys niin raju, että se aiheutti 15 minuutissa muis- tin loppumisen reitittimeltä ja koko verkon kaatumisen. Tätä voidaan pitää hyvänä muistutuksena siitä, että vaikka verkko voidaan suojata ulkopuolelta tulevilta hyökkäyksiltä niin yrityksen täytyy myös varautua virusten, matojen, haittaohjelmien sekä urkinnan aiheuttamiin uhkiin. Toisena vaihtoehtona vikasietoisuudelle olisi ollut toteutus, jossa kaksi reiti- tintä toimii yhtenä virtuaalireitittimenä kappaleessa 7.3 esitetyllä tavalla. To- teutettaessa tämä toinen vaihtoehto, olisi tarvittu toinen aktiivinen reititin päätoimipaikkaan. Toisaalta HSRP:n käytöllä olisi päästy vikasietoisuuteen myös laiterikon osalta. Nykyisessä toteutuksessa on reitittimen vioittumiseen varauduttu varalaitteella, joka ei ole kiinni verkossa. Myös HSRP:n kanssa olisi ollut mahdollista käyttää IP SLA Monitoria ja sitoa HSRP:n toiminta trackiin. Jos molemmat Internet-yhteydet tulevat samalta runkoverkon ope- raattorilta, tulee varmistua siitä, että kyseinen operaattori pystyy varmasti ta- kaamaan sen, että yhteydet kulkevat eri kupareissa. Toisaalta myös eri ope- raattoreita käytettäessä tulee tarkistaa kuparien reitit. Keskittämällä vi-
  40. 40. 35 kasietoisuus yhdelle reitittimelle voimme vakuuttua vikasietoisuuden toimi- vuudesta kaikissa skenaarioissa tarkistamalla seurannan tilan yhdeltä aino- alta laitteelta. Jos asiakkaalta löytyy tahtoa kahdentaa pääsy ulkoverkosta sisäverkon pal- velimille (esimerkiksi www- ja sähköpostipalvelimelle), voidaan tämä pääsy myös kahdentaa eri tavoin toteutus tavasta riippuen. Tällöin haasteeksi tulee ulkoa sisäänpäin saapuvan liikenteen ohjaus oikeaan osoitteenmuutokseen. Käytettäessä yhden reitittimen ja kahden eri operaattorin toteutusta, voidaan sitoa kaksi eri IP-osoitetta eri operaattorien verkoista samalle FQDN (engl. Fully Qualified Domain Name) nimelle, niin että päälinjalle NAT-muunnettu osoite saa korkeamman preferenssiarvon operaattorin DNS palvelussa. To- sin DNS:n RFC 1035:n määritelmästä seuraa, että kahdennus voidaan teh- dä vain MX-tietueille, ei A-tietueille. Käytännön vaikutus tästä on se, että vi- katilanteessa sähköpostien kulku sisäänpäin voidaan taata lisäämällä samal- la preferenssillä toinen IP-osoite yritys.fi:n MX-tietueelle. Ciscon reitittimillä on myös mahdollista jakaa NAT-tilatietoja HSRP-reititinten välillä, tällöin voi- taisiin kahdentaa pääsy ulkoverkosta sisäverkon palvelimille yhden operaat- torin HSRP-toteutuksessa (kuva 11). Toiminto vaati kuitenkin vähintään Cis- con 2600-sarjan reitittimet, eli tämä ratkaisu ei tullut huokeammilla laitteilla kyseeseen. Mikä tahansa vikasietoisuuden toteutustapa valitaan yritykselle, on tärkeää ensin selvittää mitä kaikkea ollaan valmiita kahdentamaan. Verkkoyhteyksi- en kahdentamiseen liittyy paljon työtä ja sen hallitseminen vaatii ymmärrystä reitityksestä sekä osoitteistuksesta ja osoitteenmuunnoksista. Tämän työn yhteydessä toteutettiin myös client-VPN-ratkaisu yrityksen myyntiedustajille käyttäen hyväksi pääkonttorin reitittimen VPN-palvelinominaisuuksia. Tätä Client VPN:ää ei kuitenkaan työn laajuuden vuoksi tässä työssä käsitelty. Tästä työstä jäi yritykselle 11 toimipaikkaa kattava verkko ja verkon toteu- tuksessa käytettyjä periaatteita voidaan soveltaa jatkossa muille asiakkaille rakennettaviin verkkoihin, etenkin Internet-yhteyksien kahdentamiseen yh- dellä reitittimellä. Jatkossa vikasietoisten internetyhteyksien kanssa olisi järkevää toteuttaa myös vikasietoinen kytkinverkko asiakkaille. Näin tulisi etenkin toimia niissä tapauksissa, joissa kytkimen vikatilanteessa ei pystytä nopeasti korvaamaan vioittunutta kytkintä. Tämän työn suosituksena on toteuttaa osalle asiakas-
  41. 41. 36 reitittimistä vikasietoiset yhteydet käyttäen hyväksi tässä työssä esiteltyjä keinoja.
  42. 42. 37 VIITELUETTELO [1] Kaarlo, Kimmo. TCP/IP-verkot. 1. Painos. Porvoo: Docendo 2002. [2] Cisco Press. Cisco Verkkoakatemia: Ensimmäinen vuosi, Edita, IT Press, Helsinki 2002. [3] Doraswamy, Nagand – Harkins, Dan. IPSec, The new Security Standard for the Internet, Intranets and Virtual Private Networks. Prentice-Hall Inc. New Jersey 1999. [4] Cisco Press. Cisco Verkkoakatemia: Toinen vuosi. Edita, IT Press. Helsinki 2002. [5] Ginsburg, David. ADSL. Edita, IT Press. Helsinki 2000. [6] Saukkonen, Jukka. ADSL. Teknillinen Korkeakoulu. Helsinki 1998. Haettu 20.7.2008. Saatavissa: http://www.tml.tkk.fi/Studies/Tik- 110.300/1998/Newtech/adsl_1.html. [7] Pandya, Abhijit S. – Ercan Sen. ATM Technology for Broadband Telecom- munications Networks. CRC Press LLC. Yhdysvallat. 1999. [8] Voldi, Tero. ATM. Teknillinen korkeakoulu tuotantotalouden osasto. Helsinki 1999. [9] Request For Comments 1483. Heinäkuu 1993. Haettu 27.7.2008. Saatavis- sa: http://rfc.dotsrc.org/rfc/rfc1483.html. [10] Brenton, Chris. Mastering Cisco Routers. Sybex Inc. Yhdysvallat 2000. [11] Mallery, John – Zann, Jason ja muut. Hardening network security, McGraw- Hill/Osborne, Yhdysvallat 2005. [12] Cisco Networking Academy Program. CCNP 2: Remote Access. Companion guide. Second Edition. Cisco Press. Yhdysvallat. [13] Cisco. IPSec Dead Peer Detection Periodic Message Option. 2007. Haettu 24.8. Saatavissa: http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gtdpmo.ht ml.
  43. 43. 38 [14] IP SLAs--Analyzing IP Service Levels Using the ICMP Echo Operation, Cisco Systems. 2005. Haettu 23.8.2008 Saatavissa: http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsicmp .html. [15] Cisco Networking Academy Program. CCNP 3: Building Multilayer Switched Networks Companion Guide. Second Edition. Cisco Press. Yhdysvallat. 2005.

×