Panevropski Univerzitet APEIRON Banja Luka

“Korištenje IPSec VPN tehnologije za povezivanje Nacionalnih meteoroloških centara sa Globalnom telekomunikacionom mrežom

Svjetske meteorološke organizacije”

(Specijalistički rad) Mentor: Specijalizant : Prof.dr. dipl. IT.Menadžer Branko Latinović Kemal Šehbajraktarević

Sadržaj: 1.Uvod str. 2 2.GTS – Globalni Telekomunikacioni Sistem str. 5

2.1 Internet i GTS str. 6 2.2 GTS i sateliti str. 7 2.3 GOS i WWW str. 9 2.4 RMDCN kao dio GTS-a str. 10 2.5 RMDCN i MPLS str.12

3.Analiza postojećeg informacionog sistema METEOBIH-a str. 14 4.Reinžinjering informacionog sistema Meteobih-a str. 15

4.1 VPN – Virtuelna Privatna Mreža str. 15 4.2 Javne IP adrese str. 17 4.3 Free BSD kao operativni sistem VPN servera str. 21

5.Osiguravanje VPN tunela upotrebom IPSec-a str. 24 5.1 Kreiranje i testiranje virtuelnog linka str. 28

6. Osiguravanje virtualne mreže IPSec-om str. 30 6.1 Integritet podataka i vjerodostojnost poruke str. 32 - MD5 algoritam str. 33 - SHA algoritam str. 33 6.2 Enkripcija podataka str. 34

7. Konfiguracija IPSec VPN-a str. 36 8. Umjesto zaključka str. 41 9. Izvori str. 42 10. Skraćenice korištene u radu str. 44

1

1. Uvod

Meteorologija je, kao relativno mlada nauka (starosti oko 150 g.) već na samim početcima prepoznala važnost komunikacija i razmjenjivanja meteoroloških podataka između nacionalnih meteoroloških centara (NMC). To stoga što je većina meteoroloških fenomena takvih razmjera da istovremeno zahvataju područja više država, a nekada i veće dijelove kontinenata (sibirski anticiklon, frontalni poremećaji i sl.). Podaci izmjereni u jednoj državi nedovoljni su za identificiranje, analizu i prognoziranje ovakvih fenomena pa se stoga pojavila potreba za efikasnom razmjenom meteoroloških podataka u realnom vremenu. Podaci su se u početku razmjenjivali poštom što ni u kom slučaju nije odgovaralo zahtjevima operativne meteorologije. Sa tehničkim unaprjeđenjima u oblasti telekomunikacija mijenjao se i način razmjene podataka. Naročito velik napredak predstavljalo je uvođenje telegrafa krajem 19. stoljeća što je predstavljalo veliki iskorak ka razmjeni meteo podataka u realnom vremenu. To je i doba kada se formirala većina nacinalnih meteoroloških centara čiji je prioritetni zadatak bio sakupljanje meteoroloških podataka sa teritorije sopstvene države i slanje tih podataka u međunarodnu razmjenu. Razmjena podataka je prvobitno bila organizirana na bilateralnoj osnovi između pojedinih susjednih zemalja, ali se ubrzo shvatilo da je potrebno razmjenjivati potrebne podatke na globalnom nivou. Prvi preduslov za ostvarivanje tog zadatka bio je organizovanje svih postojećih nacionalnih meteoroloških centara u jednu svjetsku organizaciju. Tako je 1850 održana Prva međunarodna meteorološka konferencija, a njenim daljnim razvojem 1950. god. nastala je i Svjetska meteorološka organizacija, kao specijalizovana agencija Ujedinjenih Nacija (UN). Jedan od glavnih zadataka WMO-a bio je organizovanje tzv. WWW (World Weather Watch – bdijenje nad vremenom) te koordiniranje globalne razmjene meteoroloških podataka i produkata kao outputa ovog sistema. Tako je nastao Globalni telekomunikacioni sistem (GTS) Svjetske meteorološke organizacije (WMO) – zatvorena mreža koja je povezivala nacionalne meteorološke centre i koja je omogućavala siguran i pouzdan protok svih potrebnih informacija. Tehnički gledano, ova mreža je bila zasnovana na velikom broju iznajmljenih telegrafskih linija (nacionalnih i međunarodnih), i različitim tipovima telegrafa koji su koristili bušenu traku za prenos i prijem podataka. Brzina kojom su se podaci prenosili ovim sistemom bio je oko 74 bauda što otprilike odgovara količini od stotinu riječi u minuti. Jedno od prvih značajnijih tehničkih unaprjeđenja ovog telekomunikacionog sistema bio je uvođenje kompjutera kao sredstva za automatski prijem i obradu podataka. Šezdesetih godina prošlog (20.) vijeka nacionalni meteorološki centar u Washingtonu prvi je povezao sve teleprinterske linije kojima su podaci stizali u centar na IBM-ov 360 mainframe kompjuter putem komunikacijskog switching sistema, tako da su podaci automatski bivali pohranjivani na disk kompjutera.

2

Na samom početku meteorologija je operisala samo sa podacima koji su se mjerili na klasičnim meteorološkim stanicama, u određenim dnevnim terminima (na početku samo tri puta dnevno a kasnije svaka tri sata). Vremenom je broj stanica mnogostruko uvećan, kao i broj termina mjerenja, pa se tako sadašnja frekvencija mjerenja popela na svaki sat, a na nekim specijalizovanim (aeronautičkim) stanicama i svakih pola sata. Također su se pojavili i novi izvori podataka poput mjerenja vertikalnih profila putem radio sondi, mjerenja meteorološkim radarima, automatskim stanicama, senzorima instaliranim na satelitima, i sl. što je u mnogome povećalo količinu podataka koje je potrebno svakodnevno razmjenjivati. Ovaj proces povećanja količine podataka i produkata i dalje se nastavlja tako da se gotovo svakodnevno pojavljuju novi i novi izvori meteoroloških podataka (novi sateliti, novi senzori...). Svima je veoma brzo postalo jasno da postojeći telekomunikacioni sistem nije sposoban obezbijediti brzu i pouzdanu razmjenu tako velike količine podataka. Problem se pokušao riješiti fragmentiranjem globalne mreže pa su tako nastale Regionalne Telekomunikacione Meteorološke Mreže (RTMN). Svjetska meteorološka organizacija je izvršila podjelu cjelokupne svjetske teritorije na šest regiona, i to: Afrika, Azija, južna Amerika, sjeverna i centralna Amerika sa Karibima, jugo-zapadni Pacifik i Evropa. Svaki od ovih regiona ima svoju regionalnu mrežu kojom se razmjenjuju podaci od interesa samo za određeni region. Međutim, ni to nije bilo dovoljno dobro rješenje za narastajuću potrebu meteoroloških centara za sve većim brojem podataka.

1998. godine WMO je, zajedno sa ECMWF-om (Evropskim centrom za srednjeročnu prognozu) pokrenuo projekat izgradnje posebne regionalne telekomunikacione mreže (RMDCN) za region Evrope, kako bi zamijenila postojeće point-to-point linkove. Ova mreža je bila bazirana na frame relay tehnologiji i X.25 servisu uz korištenje TCP/IP –a kao transportnog protokola. Brzina prenosa podataka putem ove mreže kretala se od 32 – 512 kb/s što je predstavljalo značajno poboljšanje. Ova mreža omogućavala je prenos velikog broja podataka na efikasan i siguran način. Međutim, ovo rješenje je zahtjevalo prilično velika novčana sredstva koja su se morala plaćati u vidu godišnje članarine za ovu mrežu, što je bilo neprihvatljivo za male države i njihove meteorološke centre.

2004. godine RMDCN uvodi novu tehnologiju tzv. MPLS (Multi Protocol Label Switching) kojom se nastoji uvezati postojeći različiti načini komunikacija (različiti protokoli) a postojeća cijena pristupa ovoj mreži se još smanjuje.

Bosna i Hercegovina i njen Federalni hidrometeorološki zavod (koji

odlukom Visokog predstavnika obavlja poslove Državnog HM zavoda) se nakon sticanja nezavisnosti, te ratnog perioda 1992 – 1995 g. našla pred problemom ponovnog uspostavljanja međunarodne razmjene hidrometeoroloških podataka i produkata. Do 1992. godine sva komunikacija sa WMO-om kao i slanje podataka u GTS obavljala se preko bivšeg Saveznog hidrometeorološkog zavoda u Beogradu, koji je bio povezan putem iznajmljene linije sa regionalnim telekomunikacionim čvorištem u Sofiji. Raspadom Jugoslavije svaki od bivših Republičkih hidrometeoroloških zavoda

3

rješavao je problem komunikacija na svoj način. Tako su Slovenija i Hrvatska pristupile RMDCN mreži i spojile se na RTH Beč. Tadašnja Jugoslavija (Srbija+Crna gora) zadržala je svoju konekciju sa Sofijom, ali je unaprijedila konektujući se na RMDCN mrežu, dok se Makedonija nešto kasnije putem RMDCN mreže povezuje sa centrom u Sofiji. BiH nije mogla priuštiti pristupanje RMDCN mreži zbog, za našu ekonomsku situaciju, poprilično visokih godišnjih troškova članarine koji su iznosili cca. 50.000 EUR. Sa razvojem i sve većom penetracijom Interneta na ovim prostorima, pokušali smo pronaći neko web bazirano rješenje koje bi, zbog svoje niske cijene, bilo pristupačno. Kako smo prema tadašnjoj podjeli WMO-a trebali pripasti RTH-u u Beču to smo sa njima pokušali riješiti ovaj problem, ali nismo naišli na razumijevanje, uz obrazloženje da Internet tehnologija ne predstavlja siguran način komuniciranja. Kao prelazno rješenje uspostavili smo vezu sa NMC Slovenije putem secure FTP-a uz korištenje 128 -bitne enkripcije. Kolege iz Slovenije su prihvatile ovakav način razmjene podataka te su na sebe preuzeli obavezu da naše podatke proslijeđuju u GTS putem njihove RMDCN konekcije, a istovremeno i da set nama potrebnih podataka sa GTS proslijeđuju na naš FTP server. Ovo prelazno rješenje se pokazalo kao dobro i efikasno jer u svojoj gotovo sedmogodišnjoj eksploataciji do sada nismo imali nikakvih problema, ni na našoj, niti na strani kolega iz Slovenije. Međutim, to je predstavljalo samo jedno prelazno rješenje, te se moralo pristupiti trajnom i kvalitetnijem rješenju ovog problema.

Da bi rješili ovaj problem na ekonomski prihvatljiv način, uz istovremeno pridržavanje svih standarda WMO-a po pitanju sigurnosti i zaštićenosti podataka, zajedno sa kolegama iz regionalnog čvorišta u Sofiji (Bugarska) pokrenuli smo projekat povezivanja naših centara uz korištenje dostupnih web tehnologija. Tako smo planirali da uspostavimo VPN (Virtual private network) mrežu između naša dva centra, a da za osiguranje tako uspostavljenog tunela koristimo IPSec kao set protokola koji obezbjeđuju sigurnu razmjenu paketa na IP nivou. Za ovakav projekat morali smo obezbijediti podršku i dozvolu WMO-a, jer smo na jedan novi, do sada ne praktikovani način, ostvarili vezu na zatvorenu mrežu WMO-a. Nakon dobijanja takve jdozvole, kao i finansijske podrške, krenuli smo u ostvarivanje ovog, za nas veoma značajnog projekta.

4

2. GTS – Globalni Telekomunikacioni Sistem

Meteorologija, kao nauka ali i kao servis građana, koristi se ogromnim

brojem podataka koji se svakodnevno razmjenjuju između različitih nacionalnih centara i nezavisnih specijaliziranih institucija (ECMWF – Evropski centar za srednjoročnu prognozu, EUMETSAT – Evropska organizacija za eksploataciju meteoroloških satelita....). Zbog specifične uloge i važnosti ovih podataka Svjetska meteorološka organizacija (WMO) je od samog početka svog djelovanja posvećivala veliku pažnju sigurnosti i zaštiti, kao i autentičnosti meteoroloških podataka koji se razmjenjuju. U tu svrhu je i kreirana zatvorena telekomunikaciona mreža - GTS (Global Telecomunication System) kojom su nacionalni meteorološki centri povezani sa Regionalnim telekomunikacionim čvorovima (RTH) , a oni sa svjetskim meteorološkim centrima. GTS predstavlja kombinaciju terestrijalnih i satelitskih veza koje su organizovane kao point-to-point linije, multi-point-to–point linije (za prikupljanje podataka), point-to-multipoint linije (za distribuciju podataka i produkata), i dvosmjernih multipoint linija. GTS je organizovan u tri nivoa:

a) Glavna telekomunikaciona mreža (MTN) b) Regionalne telekomunikacione mreže (RMTNs) c) Nacionalne telekomunikacione mreže (NMTNs)

Struktura GTS-a data je na slici 1.

Slika 1; Struktura GTS-a1

Glavna telekomunikacijska mreža (MTN) predstavlja osnovu ovog sistema a povezuje tri glavna, svjetska meteorološka centra (Melburn, Moskvu i Vašington) sa šesnaest Regionalnih telekomunikacionih čvorišta (RTH) (Alžir,

1 Preuzeto sa http://www.wmo.ch/pages/prog/www/TEM/gts.html

5

Peking, Breknel, Brazilija, Buenos Aires, Kairo, Dakar, Džeda, Najrobi, Nju Delhi, Offenbah, Tuluz, Prag, Sofija, Beč i Tokio). Svjetska meteorološka organizacija je izvršila podjelu cjelokupne svjetske teritorije na šest regiona, i to: Afrika, Azija, južna Amerika, sjeverna i centralna Amerika sa Karibima, jugo-zapadni Pacifik i Evropa. Svaki od ovih regiona ima svoju regionalnu mrežu (RMTN) kojom se razmjenjuju podaci od interesa samo za određeni region, kako bi se smanjila količina nepotrbnih podataka na mreži. Nacionalne telekomunikacione mreže obezbjeđuju NMC-ma prikupljanje podatka sa teritorija za koji su odgovorne, kao i distribuciju određenih podataka i produkata na nacionalnom nivou. GTS je predominantno bio organiziran tako da podržava tzv. „message switching“ aplikacije – tj. aplikacije za preusmjeravanje meteoroloških biltena u predefinisanom formatu preko ograničenog OSI transportnog servisa baziranog na point-to-point X.25 distribuciji. Ovakva ograničena implementacija je bila adekvatna za stare aplikacije za preusmjeravanje poruka ali nije mogla zadovoljiti nove zahtjeve komuniciranja. Upotreba ISO/ITU standarda X.25 je usvojena od strane WMO-a u ranim '80-tim kako bi se obavljala razmjena podataka i produkata u WMO-ovim binarnim kodovima tipa GRIB, BUFR i sl. ali i da bi koristio kao osnova za aplikacije višeg nivoa OSI modela. X.25 se tada smatrao osnovnom komponentom OSI arhitekture kao i strategijskim pravcem za dalji razvoj na polju razmjene podataka. Međutim, pojavom Interneta i TCP/IP mrežnih protokola javile su se neke druge mogućnosti koje su bile daleko atraktivnije i prihvatljivije za implementaciju. Kako se Internet u cijelom svijetu nametao kao dominantna snaga u informacionim tehnologijama, tako je i WMO prihvatao njegove tehničke standarde. Prelazak na TCP/IP se nametnuo kao logično rješenje jer se podrška proizvođača za X.25 tehnologiju ubrzano smanjivala, a samim tim postajala i sve skuplja budući da se cijeli svijet okretao kao TCP/IP –u. TCP/IP je nudio mnoštvo gotovih „off the shelfl“ aplikacija koje su meteorološkoj zajednici nudile prijeko potrebna rješenja, poput FTP-a, elektronske pošte, web browsera, ali i multimedijalnih komunikacija. Na kraju TCP/IP je obezbjeđivao veze između članica WMO-a na mnogo fleksibilniji i raznovrsniji način od X.25 baziranog servisa. Sve ovo se direktno odražavalo i na smanjenje troškova koje su članice WMO-a imale za nabavku telekomunikacione opreme, nabavke i održavanja softvera i sl. 2.1 Internet i GTS U zadnjoj dekadi prošlog vijeka, (u našim krajevima nešto kasnije), došlo je do jakog i brzog razvoja Interneta. Takav razvoj je neminovno doveo WMO u poziciju da se izjasni o ulozi i prihvatljivosti upotrebe Interneta u operativnim komunikacijama nacionalnih centara. Internet je svakodnevno povećavao svoj kapacitet, penetraciju kao i različitost aplikacija koje su se mogle koristiti i u meteorologiji, nudeći ekonomski prihvatljivu funkcionalnost. Međutim, Internet je imao (i dalje ima) i svoje slabosti: njegovo funkcionisanje je nepredvidljivo naročito zbog enormnog porasta saobraćaja na njemu. Nadalje, gledajući globalno, njegova dostupnost u pojedinim dijelovima planete nije jednaka ni po dostupnosti niti po pouzdanosti. Upotreba Interneta nadalje uključuje određene sigurnosne proleme, i sl. Uzimajući sve to u obzir WMO je odlučio

6

da opstanak GTS-a kao specijalizovane mreže za razmjenu vremenski kritičnih meteoroloških podataka ne može biti doveden u pitanje, dok se Internet definisao kao ekonomski prihvatljiva infrastruktura za sistem prenosa vremenski ne-kritičnih podataka. Tako je u većini Nacionalnih meteoroloških centara Internet danas prihvaćen kao medij za brzu komunikaciju kako sa korisnicima svojih usluga, tako i sa drugim NMC-ima, ali samo na nivou svakodnevne komunikacije ali ne i za prenos vremenski kritičnih podataka. Među najprihvaćenijim servisima Interneta su e-mail, WWW, FTP, ali i razni servisi za on-line komunikaciju tipa Skype, ICQ i sl. Većina današnjih Centara sve svoje produkte čine dostupnim putem svojih Web portala koji se obično dijele na stranice dostupne svim posjetiocima sajta i stranice koje su zaštićene, tj. dostupne samo određenim korisnicima uz dodijeljeni im user name i pasword. Prednost Interneta nad svim danas korištenim specijalizovanim mrežama za prenos podataka u meteorologiji jeste u veoma velikim brzinama prenosa (Bandwith) koji je daleko jeftiniji i pristupačniji većini NMC-a. Tako nije rijetkost da pojedini NMC-i imaju izlaze na Internet sa bandwithom od dva, osam ili čak i 30 Mbps što je za sve dosadašnje zatvorene mreže GTS-a nezamisliva brzina. Kako su meteorološke aplikacije ali i produkti sve zahtjevniji u pogledu brzine prenosa ulaznih podataka, ali i outputa, to se Internet sve više nameće kao jedno od dobrih rješenja. Naravno, osnovni problem Interneta jeste njegova (ne) sigurnost, tako da su svi napori NMC-a sada usmjereni upravo na rješavanje tog problema. Da li će Internet preuzeti primat zasebnim meteorološkim mrežama i za prenos vremenski kritičnih podataka ostaje da se vidi. Jedan mali doprinos u tom smjeru predstavlja i ovaj rad. 2.2 GTS i sateliti Razvojem satelitskih komunikacija razvio se poseban telekomunikacioni sistem koji se uspješno integrirao u GTS. Ovaj sistem se koristi na globalnom, ali i na regionalnom, pa čak i nacionalnom nivou. U tu svrhu koriste se specijalizovani geostacionarni i polarni sateliti ali i komercijalni telekomunikacioni sateliti (MSG, METOP, MDD, RETIM, EUTELSAT, HOTBIRD, TURKSAT...). Satelitske komunikacije su sasvim uspješno dopunile sve postojeće gapove GTS-a naročito u predjelima gdje je implementacija terestrijalnih linija otežana (pustinje, planinski krajevi, velike vodene površine i sl.) Pojedine zemlje su satelitskim linkovima rješile čak i svoje nacionalne telekomunikacione mreže, kao npr. Turska koja je upotrebom VSAT tehnologije povezala preko 120 svojih meteoroloških stanica sa centrom u Ankari. Multi point telekomunikacioni servis putem satelita i radio emitovanja Zbog nemogućnosti da se do svih zainteresovanih korisnika dospije putem klasičnih telekomunikacionih GTS linkova WMO je inicirao i potencirao uključivanje satelita u multi point distribuciju meteoroloških podataka i produkata. Tako su se od '50-tih godina prošlog vijeka različite vrste satelitskih sistema postepeno uključival u GTS. Broj specijalizovanih meteoroloških satelita, ali isto tako i komercijalnih i raznih satelita za ekološka

7

osmatranja, koji su uključivani u GTS, stalno se povećavao. Danas je svaki od WMO regiona pokriven barem jednim sistemom satelitske distribucije, kao što je to pokazano u slijedećoj tabeli:

Tabela 1: Pokrivenost WMO regiona satelitskim sistemima za distribuciju

Satelitski sistemi za distribuciju meteoroloških podataka u regionu VI koriste DVB (digitalni video broadcast) tehniku, a najpoznatiji su RETIM kojim upravlja MeteoFrance, EUMETCAST kojim upravlja Evropska agencija za eksploataciju meteo satelita (EUMETSAT) kao i DWDSAT kojim upravlja Njemački meteo institut.

Slika 2; Meteorološki sateliti u orbiti2

2 Preuzeto sa www.esa.int/images/orbits,1.jpg

8

Do upotrebe satelita jedna od glavnih tehnika za multipoint distribuciju je bila HF radio -emitiranje. U tu svrhu su se koristile određene frekvencije za emitiranje dok su korisnici koristili tzv. faksimil prijemnike sa primitivnijim ploterima koji su primali i istovremeno iscrtavali meteorološke karte. Ovaj sistem distribucije meteoroloških produkata se još uvijek koristi u nekim manje razvijenim dijelovima svijeta. 2.3 GOS i WWW Različiti izvori svih meteoroloških podataka sačinjavaju jedinstven svjetski sistem osmatranja tzv. GOS (Globalni Osmatrački Sistem). Taj sistem se sa svakim novim tehničkim dostignućem proširuje i povećava. Trenutno stanje Globalnog osmatračkog sistema dato je na slici 3.

Slika 3; Globalni osmatrački sistem (GOS)3

U uvodu je spomenut WWW World Weather Watch tj. Svjetski sistem bdijenja nad vremenom. Ovaj sistem Svjetske meteorološke organizacije se sastoji od tri glavne komponente: 1) GOS (Globalni osmatrački sistem), 2) GTS (Globalni telekomunikacioni sistem i 3) GDPFS (Globalni sistem za procesiranje podataka). Tok podataka i produkata u ovom sistemu dat ja na slijedećem dijagramu:

3 Preuzeto sa http://www.wmo.ch/pages/prog/www/images/GOS

9

DATA MANAGEMENT

PRODUCT GENERATION

Global Data

Processing and Forecasting

System

DATA AND PRODUCT USERS

DATA COLLECTION

Global

Observing System

GOS

DATA AND PRODUCT

TRANSPORT

Global Telecommunication

System

Slika 4; Tok podataka (Data flow) - u sistemu WWW-a Kolika je važnost ovog sistema najbolje se vidi u situacijama kada on ne funkcioniše dobro. Jedan od najdrastičnijih primjera u istoriji WMO-a se desio 17. jula 2006. godine kada, je Cunami talas odnijeo oko 500.000 života u regionu jugoistočne Azije. Ne postojanje uređenog sistema za komunikaciju i prenos podataka, u ovom slučaju upozorenja, u tom regionu, u monogome je doprinijeo da broj nastradalih bude tako velik. 2.4 RMDCN kao dio GTS-a Kako se razvoj GOS-a nije dešavao ravnomjerno u svim regionima, to se i rješavanju problema razmjene sve veće količine podataka i produkata prišlo na regionalnoj osnovi. Tako se u regionu VI (Evropa), kao jednom od najrazvijenijih regiona, problem pokušao riješiti povećanjem broja RTH-ova i povećanjem brzine prenosa između pojedinih NMC-a i RTH-ova, tako da je shema regionalne telekomunikacijske mreže poprimila izgled kao na slici 3.

10

Slika 5; Regionalna telekomunikaciona mreža regiona VI (Evropa)4

Ovo rješenje je samo za kratko umanjilo postojeći problem te je stoga WMO naložila ECMWF-u (Evropskom centru za srednjeročnu prognozu), kao najjačem meteorološkom centru u Evropi (a i u svijetu), da organizuje, koordinira i implementira jednu novu regionalnu mrežu koja će zadovoljiti potrebe cjelokupnog regiona. ECMWF je, nakon provedene procedure izbora, u martu 1998. godine potpisao ugovor sa izabranom kompanijom Equant. Ova kompanija je predložila takvo mrežno rješenje koje će biti bazirano na frame relay i X25 servisima, uz korištenje TCP/IP–a kao transportnog protokola. Frame relay je takav mrežni protokol koji obezbjeđuje fleksibilno upravljanje bandwithom pomoću dva definisana parametra:

CIR – Commited Information Rate (zagrantovani propusni opseg) kojeg Equant, kao mrežni provajder, garantuje u komunikacijama između dva člana RMDCN-a, i

EIR – Excess Information Rate (prekoračenje zagarantovanog propusnog opsega u slučajevima neopterećenosti mreže) koje može ići do 1.5 puta više od CIR-a

Prema ovom rješenju sve članice RMDCN mreže su se morale pristupnom linijom povezati sa POP (point of presence – pristupna tačka) frame relay mreže u svojoj zemlji. Cisco je izabran kao glavni snabdjevač mrežnom opremom (ruteri i switchevi). Prvobitni ugovor o pristupanju ovoj mreži potpisala je do aprila 1999.godine 31 zemlja. Da bi se ispitalo predloženo tehničko rješenje zasnovano na frame relay servisu, uspostavljena je iste

4 Preuzeto sa http://www.wmo.ch/pages/prog/www/TEM/GTSstatus/R6rmtni.gif

11

godine pilot mreža koja je bila prototip predloženog rješenja. Ovom pilot mrežom povezana su dva meteo centra; Meteo France iz Tuluza i Meteorološki institut iz Lisabona. Tokom juna i jula te godine izvršen je čitav niz testova koji su pokazali određene probleme u rutiranju, ali je taj problem riješen novom konfiguracijom rutera. Nakon testne faze prišlo se povezivanju i preostalih dvadesetdevet NMC-a na najbliže Equantove POP-ove. Svaka od članica ove mreže morala je realizovati i back-up konekciju od svog centra do Equantovog POP-a putem ISDN veze. Osim veze NMC-a sa RTH-om kao glavnog rješenja, RMDCN je obezbjeđivao i vezu između pojedinih NMC-a, a sve putem PVC-a (permanent virtual circuit – stalne virtualne linije). Zahtjevi ECMWF-a kao glavnog ugovarača bili su da 90% svih PVC –a imaju zagarantovanu dostupnost od 99.5% , a da preostalih 10% PVC-a imaju dostupnost od 98.5% . Tokom ovog testnog perioda navedeni zahtjevi su u potpunosti ispunjeni pa je RMDCN pušten u operativni rad 15. marta 2000.godine. Stare iznajmljene linije koje su predstavljale GTS linkove konačno su se prestale koristiti. Većina zemalja članica RMDCN-a prešli su u ovoj fazi sa svojih starih aplikacija baziranih na X25 protokolu, na nove TCP/IP bazirane aplikacije, tako da je TCP/IP postao standard i za RMDCN. 2.5 RMDCN i MPLS

Krajem 2004. godine ECMWF je predložio prelazak na jednu novu tehnologiju tzv. IPVPN MPLS (IPVPN Multi Protocol Label Switching). Sve članice WMO-a koje su do tada bile priključene na RMDCN prihvatile su ovaj prijedlog. Nova mreža se uspostavljala paralelno sa funkcionisanjem stare RMDCN mreže, a konačno je u operativni rad puštena u junu 2007.

Ova nova mreža je bazirana na MPLS osnovnu infrastrukturu Orange Business Services (OBS - merger Orange, Equant i France Telecom-a uspostavljenog 1 Juna 2006). Ova nova tehnologija je omogućila OBS-u da implementira IP virtuelnu privatnu mrežu sa slijedećim osnovnim karakteristikama:

• Obezbijedila je svak-sa-svakim konekciju među članicama RMDCN-a. • Obezbijedila je dva nivoa servisa; Zlatni i srebreni. • Obezbijedila je balansirano opterećenje za tzv. Mission Critical sajtove • Elastičnost je postignuta sa tri moguće opcije:

o Mission Critical : Ovakvi sajtovi imaju dvije različito rutirane linije na različite OBS-ove P(oint) O(f) P(resence). Ove linije su spojene na dva različita rutera na strain korisnika.

o Extra Enhanced: Ovakvi sajtovi imaju dvije različito rutirane linije na različite OBS-ove P(oint) O(f) P(resence), ali su na korisnikovoj strani spojene na isti ruter.

o Enhanced: Ovakvi sajtovi koriste OBS backup servis koji se zasniva na warm standby ruterima i ISDN dial-up konekciji.

12

Slika 6; Topologija OBS-ovog MPLS-a5

Kao dodatna opcija po prvi put se u ovom projektu spominje upotreba VPN-a preko javne mreže-Interneta, kao moguće rješenje za one članice WMO-a koje nisu članice RMDCN-a. To je i bio osnov za naše rješenje povezivanja NMC Sarajevo sa RTH Sofijom.

Slika 7; Konfiguracija IPVPN opcije preko Interneta6

5 Preuzeto sa http://www.ecmwf.int/services/computing/rmdcn/ECMWF-Topology-Diagram-v2.9.gif 6 Preuzeto iz prezentacije gosp. Reiner M: „WMO-FIS“, maj 2005.

13

3. Analiza postojećeg informacionog sistema METEOBIH-a Prije nego se krenulo u realizaciju projekta povezivanja NMC-BiH sa RTH-om u Sofiji putem VPN mreže, neophodno je bilo izvršiti analizu postojećeg informacionog sistema METEOBIH-a. Postojeća lokalna računarska mreža (LAN) je bila fizički podijeljena u dvije, fizički odvojene mreže: jedna koja je služila za međunarodnu razmjenu podataka i ispunjavanje svih drugih međunarodnih obaveza (nazovimo je operativna mreža) , i druga koja je podržavala standardne potrebe uposlenika METEOBIH-a (www, e-mail…) Ovakva podjela je bila motivisana željom da se fizički spriječi pristup servisu međunarodne razmjene podataka, kako bi se smanjili sigurnosni incidenti. Međutim, ovakva konfiguracija je imala svoje nedostatke, pogotovo kada se uzme u obzir potreba učešća različitih sektora METEOBIH-a u međunarodnoj razmjeni podataka: meteorološkog, klimatološkog, hidrološkog... itd. Kao što je već rečeno, operativna mreža je koristila Internet kao osnovu za prenos podataka korištenjem SFTP-a na FTP server NMC-a Slovenije, kao i obrnuto. Za pristup Internetu koristio se iznajmljeni analogni vod kojeg je obezbjeđivao BHTelekom kao ISP (Internet Service Provider), uz korištenje njihovog tzv. Bussiness paketa sa dijeljenim opsegom od 512 Kbps. Dijeljenje opsega je podrazumijevalo garantovani bandwith od minimalno ¼ nominalnih 512 Kbps, što je u većini slučajeva bilo dovoljno. Na slijedećoj šemi dat je prikaz konfiguracije LAN-a METEOBIH-a i njegov pristup Internetu: V.35 port Ethernet

INTERNET

MODEM R UTER SWITCH

L A N

Satelitski sistem

Satelitski sistem

Slika 8: Postojeći LAN Meteobih-a

14

Meteobih je u sklopu ovog paketa imao jednu javnu IP adresu koja je bila dodijeljena externom portu rutera (Telindusov Crocus 2M), a sav promet prema računarima u LAN-u (sa privatnim adresama klase A) se preusmjeravao putem NAT servisa na ruteru, a preko ethernet porta konfigurisanog sa privatnom adresom. Ovakvo rješenje je bilo dosta dobro u pogledu sigurnosti jer je prema Internetu postojala samo jedna javna IP adresa, što je olakšavalo kontrolu pristupa “iz vana”. Većinu podataka dobijenih iz međunarodne razmjene, koristio je sektor prognoze gdje su se podaci, preusmjeravali FTP-om u lokalnoj mreži. Podaci za druge sektore, koji su bili fizički odvojeni od ove “operativne mreže” prenosili su se putem različitih medija – USB stick-ova, disketa i sl. Ovo je u mnogome usporavalo i otežavalo svakodnevni rad uposlenika, ali se na insistiranje menadžmenta Zavoda, ovakav pristup nije mijenjao. U postojeći informacioni sistem bila su uključena i dva satelitska sistema: francuski sistem za satelitsku distribuciju RETIM i satelitski sistem za prijem podataka sa EUMETSAT-ovih satelita METEOSAT i MSG. Sve ovo je činilo jedan informacioni sistem koji je svakodnevno primao nekoliko gigabajta različitih meteoroloških podataka, ali se oni ni izbliza nisu koristili u svom punom kapacitetu, upravo zbog načina organizovanja LAN-a u dvije fizički odvojene cjeline. 4. Reinžinjering informacionog sistema Meteobih-a Nakon detaljne analize postojećeg informacionog sistema Meteobih-a, kao i svih zahtjeva kolega iz RTH Sofija napravljen je plan potpunog reinžinjeringa LAN-a kao i kompletnog informacionog sistema. Naravno javile su se neke dileme koje smo otklanjali u toku same realizacije projekta, ali je već na samom početku postignuta saglasnost oko nekih rješenja. Usaglašena rješenja su podrazumijevala:

Da za povezivanje NMC Sarajevo i RTH Sofija koristimo VPN uz upotrebu IPSec-a

Da VPN server mora imati javnu IP adresu

Da oba VPN servera koriste Free BSD operativni system 4.1 VPN – Virtuelna Privatna Mreža Kao bazični document za uspostavljanje jedne ovakve veze koristili smo document WMO-a “RECOMMENDED PROCEDURES FOR INTERNET-BASED CONNECTIONS BETWEEN RTHS AND NMCS (VPN, IPSEC)“ kojeg je izradila WMO-ova Komisija sa bazične sisteme još 2002. godine. Svijesni toga da se mnogo izraza (kako na polju informatike tako i uopšte u životu) koristi ne znajući njihovo pravo značenje, eksperti iz navedene komisije su na samom početku dali definiciju V(irtual) P(rivate) N(etwork). U

15

svom objašnjenju poslužili su se jednostavnim raščlanjivanjem pomenutog akronima VPN: N(etwork) – mreža je deifnisana kao „...grupa uređaja koji među sobom mogu komunicirati na neki dogovoreni način, i tako slati i primati podatke između sebe.“ Pod uređajima se ovdje podrazumijevaju računari, printeri, routeri i sl. P(rivate) – privatno je definisano kao „...komunikacija između dva ili više uređaja na neki tajni način, tako da uređaji koji ne učestvuju u toj (privatnoj) komunikaciji nisu u stanju prodrijeti u komunicirani sadržaj, pa čak nisu ni svjesni postojanja jedne takve privatne veze.“ Radi pojašnjenja termina „privatna“ navodi se njene antipod – „javna“ što predstavlja nešto svima dostupno. V(irtual) – virtuelna. Za objašnjenje ovog pojma iskorišteno je objašnjenje iz Hakerskog riječnika (New Hacker's Dictionary) gdje se kaže da je virtualno: „...simulirano; izvršavanje funkcije nečega što realno nije prisutno.“ Opet se kao pojašnjenje uzeo antipod ove riječi – „realno“. Za daljne pojašnjenje VPN-a bitno je naglasiti da se ova „privatna“ komunikacija ne vrši putem privatne fizičke infrastrukture, već koristi infrastrukturu javne mreže – Interneta. Zato se definiše kao virtuelna, jer prava privatna mreža mora imati svoju zasebnu fizičku infrastrukturu. (Ovo je u potpunosti primijenjeno na IP VPN MPLS mreži OBS-a) Na kraju ovog, nešto šireg objašnjenja, data je definicija VPN mreže: „VPN je takvo komunikacijsko okruženje u kojem je pristup kontroliran tako da dozvoljava međusobnu komunikaciju samo unutar definirane interesne grupe, a konstruirana je na nekoj vrsti particioniranja zajedničkog komunikacionog medija, gdje ovaj zajednički medij omogućava mrežni servis na ne-isključiv način.“ Primjena IPSec VPN konekcije zahtijeva poznavanje i razumijevanje TCP/IP referentnog modela. Na slici 9 dat je uporedni prikaz standardnog OSI modela i TCP/IP modela.

Link layer

Slika 9; OSI i TCP/IP referentni model

16

Na link sloju TCP/IP modela nalazimo:

• ATM i Frame Relay konekcije • MPLS (Multi Protocol Label Switching) • Link-Layer Encryption (L2TP or PPTP)

- Na mrežnom sloju nalazimo :

• IPSEC - Na transportnom i aplikacionom sloju nalazimo

• SSL (Secure Socket Layer) protokol korišten uglavno od strane Netscape za enkripciju http saobraćaja

• TSL (Transport Secure Layer) standard IETF-a (Internet Engineering Task Force) baziran na SSL-u

• SOCKS • SSH

Za naše potrebe IPVPN+IPSec konekcije bitno je shvatiti da IPSec „operiše“ na mrežnom sloju referentnog modela. 4.2 Javne IP adrese Jedan od zahtjeva kolega iz Sofije je bio da budući VPN server mora imati svoju javnu IP adresu. Na prvi pogled nam se javila samo dva moguća rješenja: a) promjena komercijalnog paketa za pristup Internetu i dobivanje bloka od najmanje 16 javnih IP adresa, pošto je aktuelni paket omogućavao samo jednu javnu IP adresu, ili b) konfigurisanje VPN servera sa dvije mrežne kartice kao rutera i dodjeljivanje jedine postojeće javne IP adrese vanjskom ethernet portu, uz korištenje privatne adrese na portu prema LAN-u. Izbor rješenja je zavisio i od raspoloživih finansijskih sredstava jer je Bussiness pro paket, sa 16 javnih IP adresa, skuplji za 120% od postojećeg Bussiness paketa sa samo jednom javnom IP adresom. Međutim, Bussines pro paket je omogućavao i daleko veći propusni opseg (bandwith) od (zagarantovanih) 1 Mbps. Oba rješenja su bila tehnički izvodljiva ali su prevagnule prednosti Bussiness pro paketa, tako da se pristupilo rješenju sa više javnih IP adresa. Međutim, u toku same primjene došli smo do zaključka da je najoptimalnije rješenje u stvari kombinacija navedena dva rješenja. Tako smo uzeli blok od 16 javnih IP adresa ali smo defaultno rješenje BH

17

Telekoma, koje je podrazumijevalo instaliranje i jednog rutera u bridge modu, zamijenili setovanjem VPN servera kao rutera, čime smo, po našem mišljenju, dobili na sigurnosti cijele mreže. Za dobijanje bloka od (najmanje) 16 javnih IP adresa bilo je neophodno BH Telekomu dostaviti standardni RIPE obrazac u kojem se moralo obrazložiti upotreba određenog broja javnih IP adresa. Tako smo za upotebu javnih IP adresa predvidili i FTP server kao i mail server. Drugi prijedlog kolega iz Sofije je bio da se VPN server locira u demilitariziranu zonu (DMZ) kako bi se osigurala sigurnost LAN-a. Inače, demilitarizovane zone se kreiraju upavo zato da bi se servisi koji moraju biti otvoreni prema vanjskoj mreži (Internetu) odvoje od ostatka lokalne mreže kako bi se eventualni upad na neki od javnih servisa (www, DNS, mail…) ograničio samo na računar koji se nalazi u DMZ-u. Generalno gledajući, postoje dva načina za kreiranje DMZ –a; a) sa jednim firewallom sa tri mrežne karte (NIC). Na taj način se formira vanjska mreža od ISP-a (Internet service providera) do firewall-a. Unutarnja mreža se formira od druge mrežne kartice ka switchu LAN-a, a DMZ se formira od treće mrežne kartice. Takva konfiguracija je prikazana na slijedećoj slici.

Slika 9 ; Single firewall bazirana konfiguracija DMZ-a7

Jedna od osnovnih zamjerki ovakvom rješenju jeste to što sav mrežni promet u tom slučaju ovisi o jednom uređaju (PC-ju), i u slučaju greške ili pada sistema na tom računaru, pada cjelokupna mreža, što nije prihvatljivo rješenje za kritične aplikacije poput naše. b) Drugo rješenje je konfiguracija bazirana na dva firewall-a. Ovakav pristup je sigurniji ali i skuplji. U tom slučaju se prvi firewall konfiguriše tako da propušta i saobraćaj namijenjen DMZ-u i LAN-u, dok se drugi firewall konfiguriše da propušta samo saobraćaj namijenjen LAN-u.

7 Preuzeto sa http://en.wikipedia.org/wiki/Demilitarized_zone_(computing)

18

Slika 10; Dual firewall bazirana konfiguracija DMZ-a8

Alternativno rješenje je bilo da se segmentacija lokalne mreže izvede pomoću VLAN-ova (virtualnih lokalnih mreža). U tom slučaju bi se VPN server sa još nekoliko računara kojima bi se dodijelila javna IP adresa, poput FTP i mail servera, odvojili od ostatka LAN-a korištenjem VLAN-a (virtuelnog LAN-a) za što je trebalo upotrijebiti upravljivi switch (Cisco), dok je ostatak lokalne mreže adresiran privatnim IP adresama klase C. Ovo rješenje je na kraju i prihvaćeno kao najbolje. Virtuelni LAN je grupa fizičkih interfejsa na switch-u (portova) koji se ponašaju kao da su zasebni, fizički odvojeni switchevi. Ovakav pristup omogućava da se, uz upotrebu jednog fizičkog switcha, lokalna mreža podijeli na više segmenata potpuno izolovanih jednih od drugih. VLAN se koristi kada je potrebno odvojiti saobraćaj između dvije ili više grupa uređaja na mreži. Tako smo u našem primjeru, na 24-portnom Cisco upravljivom switchu definisali slijedeće VLAN-ove: Portovi 1-6 ……………………VLAN 1 (Odsjek Sabirni centar) Portovi 7-12 …………………. VLAN 2 (Prognoza vremena i klimatologija) Portovi 13-20………………… VLAN 3 (Hidrologija) Broj VLAN-ova koje je moguće kreirati na ovakav način nije ograničen (svaki port može pripadati posebnom VLAN-u). Svaka komunikacija između različitih VLAN-ova je onemogućena, čak i ako su mrežne (NIC) kartice na uređajima konfigurisane sa istim subnetom. Port 24 smo definisali kao trunk port. 8 Preuzeto sa http://en.wikipedia.org/wiki/Demilitarized_zone_(computing)

19

Šta je VLAN Trunking? Prvi VLAN Meteobih-a je definisan tako da njemu pripadaju slijedeći računari i uređaji:

VPN server DB server FTP server AMSS server (Automated Message Switching System) Satelitski prijemnik za RETIM satelitski sistem Satelitski prijemnik za EUMETSAT-ov MSG satelit UDCS server (Universal Data Collection System)

Sve navedene mašine morale su biti odvojene od ostatka mreže isključivo zbog sigurnosnih razloga, ali je određena komunikacija iz ostalih VLAN-ova prema njima morala biti obezbijeđena. Kada se LAN segmentira putem VLAN-ova, kao što smo to mi uradili, onda se komunikacija između različitih VLAN-ova može obezbijediti ili putem rutera ili putem tzv. trunk porta na upravljivom switchu, što smo i mi primijenili. Ovakav pristup zahtijeva da se jedan (ili više) portova konfiguriše kao trunk port , tako da on ima pristup svim VLAN-ovima za koje bude konfigurisan kao trunk port. Dakle, u našem slučaju port 24 je definisan kao trunk port za vezu između VLAN 1 i VLAN 2. Switch u ovom slučaju obezbjeđuje komunikaciju između VLAN-ova putem tzv. tagginga. Svaki paket koji primi ili šalje ovaj trunk port dobija mali tag (oznaku) koji pokazuje koji VLAN je uputio taj paket, odnosno kojem VLAN-u je taj paket upućen. Kada uređaj primi paket, pregleda tag da bi ustanovio koji VLAN šalje taj paket. Isto tako, kada neki od uređaja pošalje paket na switch, također dodaje tag paketu. Switch pregleda tag i određuje kojem VLAN-u je upućen. Kreiranje i uključivanje pojedinih računara u VLAN može se vršiti na dva načina; statički ili dinamički. Statički VLAN se naziva i port-bazirani VLAN. Pri takvom načinu se svaki port na switchu manuelno uključuje ili isključuje iz VLAN-a, ne vodeći pri tome računa koji uređaj odnosno računar je priključen na pojedini port. Svaka izmjena u pripadanju VLAN-u mora se ručno izmijeniti od strane administratora. Uređaji koji su uključeni u određeni VLAN ne prepoznaju da pripadaju VLAN-u, već se ponašaju kao da pripadaju određenom subnetu. Switch na kojem je izvršena segmentacija na VLAN-ove mora biti u stanju prepoznati od kojeg VLAN-a dolazi informacija, i proslijediti je samo članovima tog VLAN-a. Switch također mora voditi računa da takva informacija ne dođe do onih portova koji nisu članovi datog VLAN-a. Ovakav pristup je relativno jednostavan, brz i lagan za upravljanje. Ovakav, statički način kreiranja VLAN-ova smo primijenili i u našem slučaju. Dinamički VLAN se kreira uz pomoć specijalnog softvera poput Cisco Works 2000. U ovakvoj konfiguraciji članstvo u VLAN-u se definiše, ne na osnovu porta, već nekih drugih informacija, poput MAC adrese uređaja priključenog na switch, ili user-a logovanog na određeni računar.

20

Jedna od stvari oko koje je već na samom početku projekta postignuta saglasnost obje strane u projektu je bilo korištenje Free BSD-a kao operativnog sistema na oba VPN servera. 4.3 Free BSD kao operativni sistem VPN servera Jedan od zahtjeva kolega iz Sofije je bio da oba VPN servera rade pod Free BSD operativnim sistemom. Razloga za takav zahtjev je bilo više: Jedan od njih je taj da je RTH Sofija već imala dobro iskustvo sa funkcionisanjem VPN servera na ovom operativnom sistemu. Ostale prednosti Free BSD OS su:

Free BSD koristi ravnopravni multitasking sa dinamičkim podešavanjem prioriteta

Free BSD je više- korisnički sistem – više korisnika ga mogu istovremeno koristiti za potpuno nevezane poslove. Sistem sam vrši redistribuciju zahtjeva za pojedinim periferijama (printerima, CD ili DVD drajvovima i sl.)

Free BSD je siguran. Svoje sigurnosne opcije je uskladio sa izvještajima CERT-a; vodeće organizacije koja se bavi kompjuterskom sigurnošću.

Free BSD je pouzdan. Koristi ga veliki broj ISP u cijelom svijetu. Uobičajeno je da serveri sa ovim OS ostaju u funkciji bez restartovanja i po nekoliko godina. (za razliku od Windows servera gdje je to praktično nemoguće)

Free BSD obezbjeđuje kompletnu implementaciju TCP/IP umrežavanja. To znači da ovaj OS može bez ikakvih problema koegzistirati na mreži sa drugim operativnim sistemima ili funkcionisati kao glavni server kompanije koji je u stanju obezbjeđivati svim korisnicima funkcije poput e-mail-a, FTP-a, WWW-a, ali i opcije rutiranja i firewall zaštite.

Zaštita memorije osigurava da ni korisnici, niti aplikacije ne mogu uticati na druge korisnike ili aplikacije. Ako jedna aplikacija “padne” ona ne može uticati na ostale aplikacije.

Free BSD može “vrtiti” većinu programa napisanih za različite verzije UNIX-a i Linux-a na jednoj hardwerskoj platformi.

Osnovni sistem sadrži mnogo C, C++ i Fortran razvojnih alata. Free BSD je operativni sistem koji je proizašao iz Berkeley Software Distribucije (BSD) koja predstavlja verziju UNIX-a razvijenog na Univerzitetu Berkly u Kaliforniji. Free BSD ne predstavlja kloniranu verziju UNIX-a već je to u stvari pravi, reklo bi se originalni UNIX. Kao svoj logo BSD koristi sliku malog vraga:

Free BSD možete instalirati kao samostalni operativni sistem (što je najbolja solucija) ili kao paralelni operativni sistem sa bilo kojom verzijom Windowsa ili distribucijom Linuxa. Kako je u našem slučaju za VPN server određena potpuno nova mašina koja nije bila predviđena ni za kakve druge namjene, to smo se odlučili na čistu instalaciju Free

21

BSD-a na cjelokupnom hard disku. Kako i samo ime govori, Free BSD je potpuno besplatna verzija operativnog sistema i moguće ga je downloadovati sa http://www.freebsd.org/ . Instalaciju smo pohranili na CD i krenuli sa instalacijom. Nakon boot-anja otvara se sysinstall meni:

Slika 11; Osnovni instalacioni meni Free BSD-a

Ovaj meni nudi tri moguće opcije instalacije : Standardnu, Expresnu i Custom. Kakve su razlike između njih?

Standardna instalacija vas vodi kroz proces instaliranja korak po korak, a nakon svakog koraka dobijate pop-up poruku koja vas obavještava koji je slijedeći korak.

Ekspresna instalacija vas također vodi kroz instalaciju korak po korak ali nema nikakvih obavještenja o tome šta je slijedeći korak, što ubrzava cijeli proces instalacije.

Custom instalacija vas nakon svakog koraka vraća na početni meni tako da sami možete izabrati slijedeći korak . Kao i kod ekspresne instalacije ne dobijate nikakve poruke.

Veliki problem kod standardne i ekspresne instalacije jeste to što vam ne dozvoljavaju korak unazad. Tako ako prođete neki od koraka instalacije a zatim utvrdite da to u stvari nije ono što se željeli , morate dovršiti instalaciju i krenuti ponovo. Kod custom instalacije u takvom slučaju se jednostavno vratite korak unazad i napravite izmjene koje vam odgovaraju. Zato je preporučljivo izabrati custom instalaciju. Slijedeći korak je izbor particije na kojoj želimo instalirati naš Free BSD.

22

Slika 11; Izbor drajva za instalaciju Free BSD-a

Nakon izbora željenog drajva (particije), pritiskom na spacebar dobijamo informacije o izabranom disku/particiji.

Slika 12; Informacije o odabranom drajvu

Pošto je u našem slučaju Micorosoftova particija zauzimala gotovo čitav disk, uklonili smo je sa komandom D. Nakon toga je bilo potrebno kreirati particiju za BSD, a pošto smo željeli da BSD bude jedini operativni sistem na ovoj mašini izabrali smo opciju A – upotrijebi cijeli disk. U slijedećem koraku trebalo je izabrati koji boot manager želimo, pa pošto smo već odredili da nećemo imati dodatnih operativnih sistema na ovoj mašini izabrali smo opciju standard.

23

Slika 13; Izbor boot menadžera

Sve navedene komande još uvijek se ne izvršavaju, sve dok ne odaberemo opciju Commit kada stvarna instalacija i počinje. Sysinstall tada vrši slijedeće radnje:

Kreira particije Kreira strukturu file sistema Mountira file sistem i swap prostor Instalira softver

Na taj način smo izvršili instalaciju Free BSD operativnog sistema na našem VPN serveru. 5. Osiguravanje VPN tunela upotrebom IPSec-a IPSec pojedini autori smatraju zasebnim protokolom, dok ga drugi smatraju samo alatom za osiguranje konekcije ostvarene putem javne mreže kao što je Internet. IPSec leži na IP sloju u referentnom TCP/IP modelu. Omogućava da dva ili više računara komuniciraju na siguran način. Osnova za IPSec komunikaciju jeste SA (Security Associations-sigurnosna asocijacija). SA predstavlja vrstu ugovora između dva entiteta kojim se određuje koji IPSec protokoli će se koristiti za osiguranje paketa, transformacije, ključevi i njihovo trajanje, kao i mnogo drugih opcija. Prije nego što dva računara razmjene pakete moraju prvo kreirati SA. SA je uvijek jednosmjeran (simplex). Dakle, ako računari A i B žele da komuniciraju koristeći IPSec, svaki od njih će morati imati dva SA – SA in i SA-out. SA in računara A i SA out računara B moraju dijeliti iste kriptografske parametre. Nadalje, svaki protokol mora imati svoj SA (ESP i AH). Zato svaki IPSec host mora imati bazu u kojo će držati sve SA (SADB).

24

IPSec se satoji od dva pod-protokola:

Encapsulated Security Payload (ESP) koji štiti IP pakete od uticaja treće strane enkripcijom sadržaja, uz korištenje simetričnog kriptografskog algoritma (npr. Blowfish, 3DES)

Autentifikacija headera (AH) koji štiti zaglavlje (header) IP paketa od uticaja treće strane i ometanja izračunavanjem kriptografskog broja za provjeru i miješanje polja zaglavlja IP paketa pomoću sigurnosne funkcije. Nakon ovoga se dodaje novo zaglavlje koje omogućuje da se informacija sadržana u paketu provjeri.

Dva navedena pod-protokola se mogu koristiti zajedno, u paru ili odvojeno. IPSec se može koristiti ili za direktnu enkripciju saobraćaja između dva hosta, što je poznato kao transportni mod, ili za izgradnju virtuelnog tunela između dvije pod-mreže (tzv. tunel mod) čime se obezbjeđuje sigurna komunikacija između dvije mreže. Ovaj drugi, tunel mod je poznatiji kao Virtuelna Privatna Mreža tj. VPN. Kako IPSec manipuliše sa paketima u transportnom, a kako u tunel modu?

Slika 14; Funkcionisanje IPSec-a u transportnom modu

U transportnom modu, paket koji je kreiran od neke aplikacije, spušta se na transportni sloj TCP/IP referentnog modela gdje mu se dodaje TCP zaglavlje. Paket se zatim spušta na mrežni sloj gdje se paketu dodaje IP zaglavlje. Nakon toga IPSec odvaja IP zaglavlje, a zatim vrši enkripciju podataka sa višeg sloja. Zatim IPSec primijenjuje odabrani sigurnosni protocol, te na kraju

25

vrši ponovno kompletiranje cjelokupnog paketa. U ovom modu svo vrijeme se koristi realno IP zaglavlje, što znači da IP adrese oba host računara moraju biti rutabilne. U tunel modu je postupak nešto drugačiji.

Slika 15; Funkcionisanje IPSec-a u tunel modu

I u ovom modu su prva dva koraka ista kao i u transportnom modu, tj. aplikacija “spušta” paket na transportni sloj gdje mu se dodaje TCP zaglavlje. Međutim nakon toga, IPSec vrši enkripciju cjelokupnog datagrama. Nakon toga primijenjuje se sigurnosni protokol, a onda se dodaje novo IP zaglavlje in a kraju se cijeli paket ponovo sastavlja. Da bi IPSec funkcionisao na free BSD operativnom sistemu mora se u konfiguracijskom fajlu kernela na VPN serveru dodati slijedeća opcija:

options IPSEC #IP security

options IPSEC_ESP #IP security (crypto; define w/ IPSEC)

Postoji više različitih rješenja za VPN mreže. Jedna od opcija je da se dvije odvojene privatne mreže (LAN) povezane na Internet, spoje u jedinstvenu mrežu. U tom slučaju šema te dvije LAN mreže izgleda ovako:

26

Na gornjem dijagramu je data šema povezivanje dvije zasebne mreže putem VPN-a uz korištenje Free BSD-a kao operativnog sistema na oba VPN servera koji služe i kao gateway, i uz različite privatne mrežne adrese u LAN-ovima - : 192.168.1.2 i 192. 168.2.2 Oba gateway-a imaju po dvije mrežne kartice od kojih su one vanjske konfigurisane sa različitim, javnim IP adresama (A.B.C.D I W.X.Y.Z) . Dvije gateway mašine imaju na internoj mrežnoj kartici, koja ih veže za LAN privatne IP adrese (192.168.1.1 i 192.168.2.1) tako da računari iz obje mreže imaju konfigurisane te adrese kao adrese gateway-a. Namjera ovakve konfiguracije je da mašine iz jedne mreže vide mašine iz druge mreže kao da su direktno priključene na isti ruter. To znači da svaki računar iz jedne mreže (npr. sa IP adresom 192.168.1.20 može da šalje ping na bilo koji računar iz druge mreže (npr. 192.168.2.10) i da dobije odgovor. Ako u ovakvoj konfiguraciji učestvuju Windows mašine, one mogu vidjeti i komunicirati sa računarima iz druge mreže na potpuno isti način kao da su na istoj mreži. Jedina razlika u odnosu na komunikaciju u kolasičnom LAN-u jeste to da je ovakva komunikacija zaštićena, tj. kriptovana.

27

Kreiranje VPN –a između ovakve dvije mreže odvija se postepeno, u nekoliko koraka.

Prvi korak jeste kreiranje virtuelnog linka između dvije mreže, preko Interneta i njegovo testiranje (korištenjem ping-a).

Drugi korak podrazumijeva primjenu sigurnosne politike da bi se osigurala ispravna enkripcija i dekripcija prometa. Za testiranje ovog koraka koristi se alat tcpdump.

Treći korak podrazumijeva konfigurisanje dodatnog softvera na Free BSD gateway-ima koji treba da omogući i da se Windows mašine vide putem uspostavljenog VPN-a.

5.1 Kreiranje i testiranje virtuelnog linka Ako smo logirani na gateway mašinu u prvoj mreži, (javna IP adresa gateway-a je A.B.C.D a privatna 192.168.1.1) i pingamo IP adresu 192.168.2.1 koja je u stvari privatna adresa na drugom gateway-u (sa javnom IP adresom W.X.Y.Z), dešava se slijedeće: Naša gateway mašina mora znati kako da pronađe 192.168.2.1 tj. mora imati definisanu rutu do te mašine. Pošto se privatne IP adrese (kao što su 192.168.1.1 i 192.168.2.1) ne mogu rutirati na Internet onda je potrebno da se naš paket (naš ping) “upakuje” u drugi paket koji će onda biti rutiran na Internet kao paket kojeg šalje mašina sa javnom IP adresom (A.B.C.D) drugoj mašini sa javnom IP adresom (W.X.Y.Z). Ovaj proces pakovanja paketa u drugi paket se naziva enkapsulacija. Kada paket stigne na odredišnu javnu adresu (W.X.Y.Z) on se mora de-enkapsulirati i isporučiti pravoj odredišnoj adresi (192.168.2.1). Ovakva veza se može zamisliti kao određena vrsta tunela između dvije mreže. Ulazne tačke u te mreže predstavljaju gateway mašine sa javnim IP adresama. Tunelu se “mora reći” koje to privatne IP adrese treba da propušta, tako da u stvari, ovakav tunel koristimo za prenos prometa između privatnih IP adresa preko Interneta. Ovakav tunel se kreira koristeći generički interfejs ili gif uređaj na Free BSD-u. Svaki ovakav uređaj mora biti konfigurisan sa četiri IP adrese: dvije javne i dvije privatne IP adrese. Podrška za gif uređaj mora biti kompajlirana u kernelu Free BSD-a na obje gateway mašine. To se postiže dodavanjem slijedeće linije u konfiguracioni fajl kernela: device gif Konfiguracija tunela se vrši u dva koraka. Tunelu se prvo moraju definisati javne IP adrese koje će se koristiti za kreiranje tunela i to korištenjem ifconfig. Nakon toga se definišu i privatne adrese koje tunel treba da propušta. Tako se na prvom gateway-u slijedećim komandama definiše tunel:

28

# ifconfig gif0 create # ifconfig gif0 tunnel A.B.C.D W.X.Y.Z # ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff Na drugoj strani tj. na drugoj gateway mašini se koriste iste komande ali je ovdje redoslijed IP adresa obrnut: # ifconfig gif0 create # ifconfig gif0 tunnel W.X.Y.Z A.B.C.D # ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff Nakon toga možemo koristiti slijedeću komandu da provjerimo konfiguraciju: ifconfig gif0 U našem slučaju, prvi gateway bi na ovu komandu odgovorio na slijedeći način: # ifconfig gif0 gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280 tunnel inet A.B.C.D --> W.X.Y.Z inet 192.168.1.1 --> 192.168.2.1 netmask 0xffffffff Odavde se vidi da je uspostavljen tunel između dvije javne IP adrese A.B.C.D I W.X.Y.Z a da je tunelom dozvoljen promet između privatnih adresa 192.168.1.1 i 192.168.2.1. Ovaj postupak uspostavljanja tunela automatski će dodati novi unos u ruting tabelu na obje mašine. Sadržaj ove tabele moguće je vidjeti slijedećom naredbom (u ovom primjeru je naredba izvršena na VPN serveru u prvoj mreži, # netstat –rn a output izgleda ovako: Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire ... 192.168.2.1 192.168.1.1 UH 0 0 gif0 ...

29

Vrijednost u polju “flags” označava da je označena tzv. host ruta između dva udaljena VPN servera, ali pristup lokalnoj mreži iza servera nije definisan. Ako želimo da se naše dvije mreže ponašaju kao jedna onda moramo omogučiti svim mašinama u obje mreže da se “vide” i komuniciraju međusobno. Taj problem se rješava dodavanjem statičke rute na obje gateway mašine, naredbom: route add 192.168.2.0 192.168.2.1 netmask 0xffffff00 Ova naredba ima slijedeće značenje: Da bi pristupili bilo kojem računaru u mreži 192.168.2.0 pošalji paket na 192.168.2.1 Sličnu rutu treba definisati i na drugom gateway-u uz promjenu mrežne adrese, tj. 192.168.1.0 Nakon ovakvog podešavanja statičkih ruta sve mašine iz obje mreže će biti u stanju komunicirati jedne sa drugima. Uobičajeno je da se na ovakvim VPN serverima konfiguriše i firewall za što bolju zaštitu LAN mreža iza servera. Za početak konfigurisanja VPN-a obično se na firewall-u dopusti sav promet, a kada se veza između dvije mreže uspostavi onda se na firewall-u pojačavaju sigurnosne mjere. Dakle, za početak smo dozvolili sav promet naredbom: ipfw add 1 allow ip from any to any via gif0 Na ovakav način smo kreirali Virtualnu mrežu (VN) ali ona još uvijek nije (P)rivatna. Kako možemo provjeriti da li je konekcija osigurana? Jednostavnom naredbom; ping 192.168.2.1 a kao izlaz ćemo vidjeti slijedeće: 16:10:24.018080 192.168.1.1 > 192.168.2.1: icmp: echo request 16:10:24.018109 192.168.1.1 > 192.168.2.1: icmp: echo reply 16:10:25.018814 192.168.1.1 > 192.168.2.1: icmp: echo request 16:10:25.018847 192.168.1.1 > 192.168.2.1: icmp: echo reply 16:10:26.028896 192.168.1.1 > 192.168.2.1: icmp: echo request 16:10:26.029112 192.168.1.1 > 192.168.2.1: icmp: echo reply Ovo nam pokazuje da ICMP poruke idu i vraćaju su potpuno nekriptovane, a time i pogodne za prisluškivanje, što svakako ne želimo dozvoliti. 6. Osiguravanje virtualne mreže IPSec-om Evropski centar za srednjoročnu prognozu vremena (ECMWF) proveo je u maju 2003 godine feasibility studiju o upotrebi IPSec-a za osiguranje VPN mreže uspostavljene preko javne mreže – Interneta. Ova studija je imala za cilj da provjeri mogućnosti korištenja VPN-a osiguranog putem IPSec-a kao back-up konekcije za njihovu RMDCN (Regionalnu mrežu…). Ova studija je dala određene rezultate i preporuke kojih se nismo mogli slijepo pridržavati u

30

našem slučaju, ali u svakom slučaju određena saznanja dobivena nakon testiranja ovakvog rješenja dobro su nam došla. Osnovni razlozi tj. nedostaci jedne ovakve konekcije zbog kojih ECMWF ne preporučuje ovakvo rješenje kao osnovno rješenje za Nacionalne meteorološke centre jesu:

Internet kao mreža nema garancije za određeni propusni opseg (bandwith)

Internet ima svoje nedostatke kada je u pitanju QoS (Quality of Service)

Internet je podložan raznim napadima, uključujući naročito opasne DoS napade.

S vremena na vrijeme pojavljuju se prekidi u funkcionisanju Interneta. Ova studija opisuje IPSec na slijedeći način: “IPSec je end-to-end sigurnosni protokol kod kojeg sva funkcionalnost i inteligencija počivaju na krajnjim tačkama, bilo da su to gateway mašine ili krajnje host mašine. ISP-ova mreža nije svjesna postojanja IP VPN-a jer tuneling tehnologije osiguravaju prenos podataka putem enkapsulacije. Izvorna, kao i odredišna adresa ovakvih paketa jesu javne adrese krajnjih tačaka tunela, pa se tako ovi paketi rutiraju kao i svaki drugi kroz javnu mrežu - Internet.” U prošlosti se pokušavalo eksperimentirati sa različitim protokolima za osiguranje VPN tunela, ali se IPSec nametnuo i postao predominantan protokol za tuneliranje. IPSec podržava dvije osnovne funkcije

Autentifikaciju – obezbjeđujući autentičnost i integritet IP paketa. Enkripciju – kojom osigurava tajnost sadržaja paketa.

IPSec-om je moguće definisati tunel između dva gateway-a. IPSec gateway obično može biti pristupni uređaj (ruter) ili firewall na kojem je implementiran IPSec. IPSec gateway se obično nalazi između korisnikove privatne mreže (LAN-a) i ISP-ove javne mreže. IPSec tuneli se uspostavljaju dinamički, tj. raskidaju se kada nisu u upotrebi. Da bi se uspostavio IPSec tunel , dva gateway-a moraju autentificirati jedan drugoga, i definisati koji sigurnosni algoritam i ključ će koristiti za tuneliranje. Ovom metodom se originalni IP paketi enkapsuliraju u IPSec paket sa javnim adresama gateway-a u svom zaglavlju, pa se nakon toga rutiraju na klasičan način između dva kraja tunela.

31

IPSec ovo postiže koristeći:

Dva sigurnosna protokola : Authentication Header (AH), koji obezbjeđuje integritet podataka, i Encapsulation Security Payload (ESP), koji obezbjeđuje tajnost podataka.

Protokol za upravljanje kriptografskim ključevima -Internet Key Exchange (IKE), koji se koristi za uspostavljanje IPSec konekcije.

IKE protokol je veoma fleksibilan i podržava različite metode autentifikacije. Normalno, oba IPSec gateway-a moraju upotrebljavati isti metod koji dogovore u procesu “pregovaranja”. Dva glavna protokola za autentifikaciju su:

PreShared key (Unaprijed razmjenjeni ključ) Isti ključ se unaprijed konfiguriše na svakom od IPSec gateway-a. Prilikom uspostavljanja komunikacije IKE vrši autentifikaciju obje mašine tako što izračunava i šalje niz razbacanih (hash) podataka koristeći pre-konfigurisani ključ. Ako je suprotna mašina u stanju da kreira isti “hash” koristeći svoj ključ, onda obje mašine znaju da uspostavljena komunikacija nadalje mora ići uz osiguranje tajnosti prema određenim pravilima.

RSA (Rivest, Shamir, Adleman) potpis Ovaj metod koristi digitalni potpis na takav način da svaki uređaj digitalno potpisuje određeni set podataka a zatim ih šalje drugoj strani. RSA potpis koristi CA (Certificate Authority) da generiše jedinstveni digitalni certifikat koji se dodjeljuje svakom hostu radi autentifikacije. RSA je po funkciji sličan pre-shared ključu, ali on obezbjeđuje jaču sigurnost. 6.1 Integritet podataka i vjerodostojnost poruke Integritet podataka se implementira uključivanjem kratkog prikaza podataka u IPSec pakete. Ovaj kratki prikaz (message digest) se izračunava korištenjem hash funkcije. Svi uređaji koji se koriste za ostvarivanje VPN IPSec veze trebaju podržavati hash funkcije HMAC-MD5 i HMAC-SHA. Pored ove dvije, postoje i druge hash funkcije (algoritma) ali se one manje tj. rjeđe upotrebljavaju. Dvije navedene hash funkcije su bazirane na MD5 i SHA uz dodatne kriptografske funkcije HMAC algoritma. MD5 kreira 128 bitni prikaz poruke, a SHA koristi 160 bitni prikaz. Dakle SHA obezbjeđuje veću sigurnost od MD5 algoritma. HMAC SHA i HMAC MD5 koriste isijecanje najvažnijih 96 bita poruke. Ovaj metod “isijecanja” ima svoje sigurnosne prednosti (smanjuje se količina informacija u hash funkciji koje mogu biti dostupne u eventualnom napadu tj. prisluškivanju), ali i mane (manji broj bita napadaču za pogađanje). Funkcije za izračunavanje sažetka poruke (hash funkcije) su neinverzne funkcije koje pretvaraju nizove bitova proizvoljne duljine u niz bita fiksne duljine. Drugim rječima one od neke informacije proizvoljen duljine naprave "sažetak" točno određene duljine. Svojstvo dobrih hash funkcija jest da

32

nemaju inverzne funkcije (iz sažetka nemoguće je doći do orginalne poruke) te najmanja promjena informacije uzrokuje drastičnu promjenu sažetka. To svojstvo se koristi pri izradi digitalnog potpisa, gdje služi za provjeru integritet i izvornost poruke (uz kriptiranje asimetričnim tajnim ključem). MD5 algoritam Autor algoritma MD5 je Ronald L. Rivest (profesor na MIT-u i osnivač RSA Data Security koja se je spojila sa Security Dynamics u RSA Security). Algoritam se još može naći pod nazivom Riv92c po autoru i verziji algoritma. Osnovne karakteristike ovog algoritma su:

Jednostavan je za implementaciju

Duljina ulaznog teksta može biti proizvoljne veličine

Kodiraju se riječi po 32 bita

Dobiveni sažetak poruke je 128 bitni · U svakom od 4 koraka se vrši po jedna funkcija (transformacija) nad grupom od 16 podataka MD5 algoritam uzima ulaznu poruka proizvoljne duljine i proizvodi 128 bitni fingerprint (otisak prsta) ili message digest (sažetak poruke). Samo nagađanjem se može dobiti dvije poruke koje imaju isti sažetak poruke ili proizvesti poruku sa zadanim sažetkom poruke. MD5 je namijenjen za digitalno potpisivanje programa, kod kojih veliki fajl mora biti komprimiran sigurnim postupkom prije nego ih se kriptira sa (tajnim) privatnim ključem koristeći kriptoalgoritam poput RSA.Ukratko, MD5 služi verificiranju integriteta podataka i puno je sigurniji nego checksum ili neke druge metode. MD5 algoritam je dizajniran da bi bio relativno brz na 32bitnim procesorima. Također MD5 ne zahtjeva velike tablice. MD5 je nastavak MD4 algoritma. Malo je sporiji od njega, ali je više konzervativan u dizajnu. MD5 je nešto sporiji od MD4 algoritma, ali donosi bolju sigurnost. U MD5 su implementirane neki savjeti raznih korisnika (revizora) algoritma. Npr. za ulaznu poruku “abc” dobiti će se slijedeći sažetak 900150983cd24fb0d6963f7d28e17f72.

SHA algoritam

SHA predstavlja skup od pet kriptografskih hash funkcija dizajniranih od strane National Security Agency (NSA). Sam naziv predstavlja skraćenicu od Secure Hash Algorithm. I ovaj algoritam izračunava sažetak poruke (message digest) fiksne dužine, od poruke koja može biti proizvoljne dužine. Algoritam se smatra sigurnim ako je računskim putem nemoguće:

33

• Naći originalnu poruku na osnovu datog sažetka poruke, i • Naći dvije različite poruke koje daju isti sažetak.

Dakle, svaka, pa i najmanja promjena u poruci mora davati različit sažetak.

Pet navedenih funkcija su: SHA-1, SHA-224, SHA-256, SHA-384, i SHA-512. Zadnje četiri funkcije se ponegdje zajednički označavaju kao SHA-2.

Primjer:

Evo kako SHA-1 hašira slijedeću rečenicu:

The quick brown fox jumps over the lazy dog" = 2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12

I samo mala izmjena u datoj rečenici (npr. promjena riječi dog u cog ) daje potpuno drugačiji sažetak poruke:

("The quick brown fox jumps over the lazy cog" = de9f2c7f d25e1b3a fad3e85a 0bd17d9b 100db4b3

6.2 Enkripcija podataka Tajnost podataka osiguranih IPSec-om postiže se upotrebom simetričnih enkripcionih algoritama i ključevima za svaku sesiju. Najčešće korišteni algoritmi su :

ESP-NULL: podaci nisu kriptovani DES (Data Encryption Standard): koristi 56 bitni ključ za enkripciju. 3DES (Triple Data Encryption Standard): koristi 168 bitnu enkripciju AES (Advanced Encryption Standard): koristi 128, 192, i 256 bitne

ključeve . Preporuka je da svi IPSec uređaji podržavaju najmanje ESP-NULL i DES, ali pošto se DES smatra slabom enkripcijom onda se za pouzdanu komunikaciju preporučuje 3DES algoritam. Prilikom uspostavljanja VPN IPSec komunikacije i odabira algoritma za enkripciju mora se voditi računa o legislativi država na čijoj teritoriji se nalaze IPSec uređaji. Tako npr. USA ne dozvoljava upotrebu enkripcije jače od 128 bita. Zakonsku regulativu u vezi sa dozvoljenom enkripcijom možete provjeriti na: http://rechten.kub.nl/koops/cryptolaw/

34

Neki od zaključaka navedene ECMWF-ove studije su bili da:

IPSec protocol ima značajan uticaj na opterećenje CPU-a . Kriptovani tuneli opterećuju procesor uređaja daleko više nego li ne-

kriptovani. Manji ruteri koji podržavaju IPSec (npr. Cisco 1605) nisu pogodni za

IPSec tuneliranje kada je propusna moć (bandwith) konekcije veća od 128 kb/s

Preporuke proizašale iz ove studije su slijedeće: Preporučuje se upotreba X509 certifikata za autentifikaciju uređaja, kao najsigurnijeg metoda. Pored toga, preporučuje se generiranje 1024 bitnog RSA ključa, kao i upotreba DH grupa2 enkripcionog algoritma. Za autentifikaciju paketa treba koristiti oba (AH I ESP) protokola. Testovi su pokazali da ESP opterećuje procesor jednako kao i AH protokol, ali samo ESP može osigurati enkripciju paketa. Pošto priroda podataka (meteorološki podaci) ne zahtjeva strogu enkripciju, a pošto sa druge strane enkripcija opterećuje procesor, to se preporučuje samo autentifikacija paketa. Zato se preporučuje samo ESP NULL tj. upotreba ESP-a bez enkripcije. U slučaju da se ipak odluči za enkripciju podataka preporučuje se upotreba ESP 3DES-a. Što se tiče dizajna lokalne mreže kada se primjenjuje VPN IPSec, preporuka je da se VPN gateway smjesti u tz. DMZ (demilitarizovanu zonu) – zonu između firewall-a i Interneta. Sav promet između VPN servera i LAN-a treba ići kroz firewall. Firewall mora biti konfigurisan tako da dozvoljava IPSec saobraćaj, zato treba dozvoliti slijedeće protokole/portove.

Protocol/Port Objašnjenje IP protocol 50 ESP protokol IP Protocol 51 AH protokol UDP 500 IKE pregovaranje UDP/TCP 10000 NAT tuneliranje

Da bi se implementirao IPSec nije neophodno koristiti poseban IPSec uređaj. Moguća je kombinacija IPSec-a i firewal-a ili IPSec-a i gateway-a, ili (kao što smo se mi odlučili u našem slučaju) korištenje jednog uređaja sa sve tri funkcije. Postoji više načina za osiguranje linka uspostavljenog na gore opisani način, ali se IPSec smatra jednim od najpouzdanijih načina. IPSec obezbjeđuje mehanizam kojim se dva host računara dogovaraju o enkripcionom ključu a zatim koriste takav ključ da bi kriptovali podatke koji se šalju od hosta do hosta.

35

7. Konfiguracija IPSec VPN-a Dvije su oblasti koje se moraju razmotriti prilikom kreiranja IPSec konekcije: 1) Mora postojati mehanizam kako bi se dva servera dogovrila o enkripcionom mehanizmu. 2) Mora postojati mehanizam koji će definisati koji to promet treba da bude kriptovan. Normalno je da nije potrebno kriptovati sav izlazni promet već se kriptuje samo onaj dio koji je namijenjen za VPN komunikaciju. Takav set pravila koja definišu šta će se kriptovati a šta ne naziva se sigurnosna politika. Kada se radi osiguranje veze to je moguće uraditi ručno, definišući enkripcioni algoritam, enkripcioni ključ itd., ali se može koristiti tzv. deamon koji će implementirati Internet Key Exchange protocol (IKE). Kako smo mi odabrali Free BSD za operativni sistem VPN servera, za konfiguraciju sigurnosnih postavki koristili smo deamon poznat pod imenom RACOON. Racoon deamon mora biti pokrenut na oba VPN servera. Na svakom od njih se konfiguriše IP adresa drugog servera kao i tajni ključ kojeg sami odaberemo. Dva deamona zatim kontaktiraju jedan drugog, potvrde da su oni ti za koje se predstavljaju da jesu (uz pomoć tajnog ključa kojeg smo mi izabrali), a zatim generišu novi tajni ključ kojeg koriste za enkripciju VPN prometa. Deamoni povremeno automatski promjene ovaj ključ tako da je mogućnost “provale” svedena na minimum. Konfiguracioni fajl Racoon deamona se nalazi u ../etc/racoon gdje je potrebno dodati slijedeće dvije linije u konfiguracionom fajlu ../etc/rc.conf ipsec_enable="YES" ipsec_file="/etc/ipsec.conf" Također je potrebno definisati pre-shared ključ (ključ koji sami odabiremo). On se nalazi u fajlu /etc/racoon/psk.txt .Već smo rekli da ovaj ključ ne služi za enkripciju VPN prometa već samo za uspostavljene veze i autentifikaciju dva deamona. Psk.txt fajl sadrži po jednu liniju za svaki udaljeni VPN server sa kojim treba uspostaviti komunikaciju (dakle može ih biti više od dva). U našem slučaju imamo samo dva VPN servera tako da je na svakom od njih psk.txt file editiran tako da sadrži slijedeću liniju: Na serveru 1:

W.X.Y.Z jklWERwerwerw23

W.X.Y.Z predstavlja javnu IP adresu drugog gateway-a (iz sigurnosnih razloga ne navodim stvarne adrese), a umjesto riječi “secret” unesen je unaprijed dogovoreni ključ, gdje smo koristili ključ koji se sastoji od 10 karaktera koji predstavljaju kombinaciju valikih i malih slova, brojeva i specijalnih znakova. Na serveru br. 2 psk.txt izgleda ovako:

A.B.C.D jklWERwerwerw23

36

A.B.C.D ovdje predstavlja adresu prvog gateway-a, dok je tajni ključ isti kao i na prvom serveru.

Racoon deamon se zatim starta na obje gateway mašine. Da bi ova komunikacija funkcionisala na firewall-u se mora dopustiti tzv. IKE saobraćaj koji koristi UDP do ISKAMP (Internet Security Association Key Management Protocol) porta. To se postiže slijedećom konfiguracijom: ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp Kada se starta Racoon deamon možemo sa jedenog gateway-a probati “pingati” drugu gateway mašinu. Konekcija u ovom slučaju još uvijek nije kriptovana, ali će racoon deamoni uspostaviti sigurnu vezu između dvije mašine, na osnovu pre-shared ključa kojeg smo definisali u psk.txt fajlu. Razmjena ključeva zahtjeva određeno vrijeme što se može uočiti na određenom zastoju prije nego što se dobije odgovor na “ping” komandu. Kada se uspostavi ovakva sigurna veza potrebne informacije o njoj možemo vidjeti koristeći komandu:

setkey -D

Tako smo uradili pola posla u uspostavljanju VPN konekcije osigurane IPSec-om. Sada je potrebno kreirati razumnu sigurnosnu politiku. Pod razumnom sigurnosnom politikom podrazumijevamo niz pravila koji će omogućavati približno optimalan nivo sigurnosti, a koja neće bespotrebno usporavati promet između dva VPN servera. Da bi nam bilo jasnije šta sve moramo osigurati na ovkavoj vezi, prvo moramo pojasniti kako se odvija promet na ovako uspostavljenoj vezi. Svaki paket koji jedan od servera šalje drugom ima i header (zaglavlje) koje sadrži podatke o samom paketu. Ovo zaglavlje sadrži informaciju o IP adresu izvora paketa kao i o odredišnoj adresi. Pošto obje navedene adrese (192.168.1.1 i 192.168.2.1) spadaju u rang privatnih adresa, one se ne mogu rutirati na Internet. Zbog toga se svaki takav paket mora “upakovati” (enkapsulirati) u drugi paket koji će sadržavati javne IP adrese izvora i odredišta paketa. Tako ako je naš prvobitni paket izgledao ovako,

nakon dodatne enkapsulacije biće mu dodat još jedan header (zaglavlje) te će izgledati ovako:

37

Ovu enkapsulaciju vrši gif uređaj, a sav sadržaj paketa biva upakovan u ovaj novi paket prije nego se proslijedi na Internet. Kako je naša želja da sav promet između dva VPN servera bude kriptovan, to se može izraziti slijedećim algoritmom: “Ako paket odlazi sa adrese A.B.C.D a namijenjen je adresi W.X.Y.Z onda ga kriptuj koristeći potrebna sigurnosna pravila. Ako paket dolazi sa adrese W.X.Y.Z onda ga dekriptuj koristeći potrebna sigurnosna pravila.” Međutim, ako između dva gateway-a postoji i promet koji ne spada pod definisanin promet VPN-a , onda ovakav algoritam neće biti ispravan jer će kriptovati sav promet između dva gateway-a. U tom slučaju algoritam bi trebao glasiti: “Ako paket odlazi sa adrese A.B.C.D i sadrži u sebi enkapsuliran drugi paket, a namijenjen je adresi W.X.Y.Z onda ga kriptuj koristeći potrebna sigurnosna pravila. Ako paket dolazi sa adrese W.X.Y.Z i sadrži u sebi enkapsuliran drugi paket onda ga dekriptuj koristeći potrebna sigurnosna pravila.” Konfigurisanje sigurnosne politike se vrši upotrebom setkey-a. Setkey predstavlja konfiguracijski jezik za definisanje sigurnosne politike. Konfiguracija se može definisati direktno, nizom naredbi (koristeći stdin), ili se konfiguracija može sačuvati u posebnom fajlu uopotrebom opcije -f uz specifiranje imena konfiguracijskog fajla. Konfiguracija gateway-a na mreži 1, sa IP adresom A.B.C.D u slučaju da želimo da se sav saobraćaj između dva hosta kriptuje glasio bi ovako:

spdadd A.B.C.D/24 W.X.Y.Z/24 ipencap -P out ipsec

esp/tunnel/A.B.C.D-W.X.Y.Z/require;

Ovu konfiguraciju možemo spasiti u fajl (npr. /etc/ipsec.conf) a zatim startamo # setkey -f /etc/ipsec.conf Naredba spdadd kaže setkey-u da želimo da dodamo pravilo u bazu sigurnosne politike. Ostatak konfiguracijskog fajla označava koje pakete treba podvrći ovom pravilu. Adrese A.B.C.D/24 i W.X.Y.Z/24 su javne IP adrese

38

dva gateway-a uz označene maske mreže (…/24 označava da se za označavanje mreže koristi 24 bita, a za označavanje hosta 8 bita), što ukazuje da sav promet između hostova ove dvije mreže treba da podliježe navedenoj sigurnosnoj politici. Pošto želimo da svi paketi koji unutar sebe sadrže upakovane (enkapsulirane) druge pakete između dva gateway-a budu kriptovani upotrebljavamo naredbu ipencap. Opcija –P out definiše da se navedena politika treba primijenjivati na sve izlazne pakete, a naredba ipsec govori da ti paketi trebaju biti osigurani. U drugoj liniji se specificira kako će paketi biti kriptovani; esp je protokol koji će biti upotrebljen, a naredba /tunel označava da će svaki paket biti dodatno enkapsuliran u IPSec paket. Na kraju se ponavljaju javne IP adrese gatewey-a koje označavaju uspostavljeni sigurnosni kanal koji će se koristiti za prenos paketa, a naredba /require govori da svi paketi koji zadovoljavaju zadano pravilo moraju biti kriptovani. Na ovakav način smo definisali sigurnosnu politiku samo za odlazne pakete. Slična je konfiguracija i za ulazne pakete:

spdadd W.X.Y.Z/24 A.B.C.D/24 ipencap -P in ipsec

esp/tunnel/W.X.Y.Z-A.B.C.D/require;

Za razliku od konfiguracije za izlazne pakete, ovdje upotrbljavamo oznaku in, dok je redoslijed IP adresa obrnut od onoga za izlazne pakete. Istu konfiguraciju treba postaviti i na drugom gateway-u. Da bi sve to funkcionisalo, neophodno je u firewal konfiguraciji definisati pravilo koje će dozvoljavati ESP i IPENCAP paketima prolaz ka vani i unutra. Ova pravila moraju biti definisana na oba gateway-a:

ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z

ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D

ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z

ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D

Pošto su ova firewall pravila simetrična mogu su upotrijebiti u istom obliku na obje gateway mašine. Odlazni paket bi sada trebao izgledati ovako:

39

Originalni paket sa privatnim IP adresama

Enkapsulira-ni paket sa javnim IP adresama

Enkriptirani paket koji je osiguran od neovlašte-nog prislu-škivanja

Kada ovakav paket stigne na drugi kraj VPN-a on se prvo dekriptuje koristeći sigurnosnu vezu koju su uspostavila dva racoon deamona. Zatim ulazi u gif uređaj koji će otpakovati drugi omotač, nakon čega ostaje onaj originalni paket koji sada može biti proslijeđen na određeni host unutar udaljene lokalne mreže. Da bi provjerili da li je ova konekcija osigurana možemo ponovo upotrijebiti komandu “ping”. Ako se logiramo na prvu gateway mašinu (IP=A.B.C.D) i damo slijedeću komandu: tcpdump dst host 192.168.2.1 a zatim ping 192.168.2.1 izlaz koji ćemo dobiti izgledaće ovako: XXX tcpdump output Dakle, output komande ping više nije čitljiv, tj. kriptovan je. Na taj način smo enkriptovali sadržaj naše komunikacije između dva VPN srevera.

40

8. Umjesto zaključka Preporuke iz studije WMO-ove Komisije za bazične sisteme u vezi upotrebe IPSec VPN konekcije između NMC-a. Kako bi se uspostavili određeni standardi za upotrebu VPN konekcije osigurane IPSec-om u operativnom radu NMC-a WMO-ova Komisija za bazične sisteme donijele je slijedeće preporuke:

- Korsištenje tunel moda jer se u većini slučajeva IPSec konfiguriše na ruterima, firewall-ima, ili drugim sličnim uređajima.

- AH (Autentifikacija zaglavlja) treba izbjegavati - ESP (Encapsulation Security Payload) se može koristiti i za

autentifikaciju kao i za enkripciju. - Autentifikaciju treba raditi sa HMAC-MD5-96 - Enkripciju je dovoljno raditi sa DES-om

Ova posljednja preporuka je upitna, te smo se mi u svom slučaju odlučili za 3DES jer je DES dosta nesiguran. DES (Data Encryption Standard) upotrebljava 56 bitni ključ za enkripciju što je isuviše kratko, te se upotrebom brutal force napada može razbiti za nekoliko dana. Međutim ovakva preporuka je donešena zbog dva glavna razloga:

1) Upotreba dužeg ključa za enkripciju više opterećuje procesor 2) Podaci koji se prenose između NMC-a nisu toliko primamljivi za bilo

koga da bi potrošio vrijeme i novac za razbijanje 56 bitnog ključa. Što se tiče scenarija implementacije VPN konekcije između dva NMC-a treba se pridržavati slijedećeg redoslijeda radnji:

a) Definisati mod i protocol koji će se koristiti (npr. tunel mod sa 3DES enkripcijom)

b) Definisati pre-shared ključ c) Definisati IP adrese na VPN linku d) Modificirati konfiguraciju na firewall-ima (otvoriti UDP port 500 za

ISAKMP i IP port 50 za ESP) e) Implementirati definisanu konfiguraciju f) izvršiti testiranje

41

9. Izvori:

1. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/

2. http://www.wmo.int/pages/prog/www/TEM/EUDCS-IMTN/VPNIPsec.pdf

3. http://www.wmo.ch/pages/prog/www/TEM/gts.html

4. www.esa.int

5. http://en.wikipedia.org/wiki/

6. http://www.wmo.ch/pages/prog/www

7. http://www.ecmwf.int/services/computing/rmdcn/

8. http://en.wikipedia.org/wiki/Demilitarized_zone_(computing)

9. http://rechten.kub.nl/koops/cryptolaw

10. Reiner M; prezentacija „WMO-FIS“, maj 2005

11. WMO – Commision for Basic Systems; „RECOMMENDED PROCEDURES FOR INTERNET-BASED CONNECTIONS BETWEEN RTHS AND NMCS (VPN, IPSEC)“ – maj 2002

12. ECMWF Newsletter No 89 – Winter 2000/01; RMDCN Project in RA VI

13. WMO Secretariat; THE GLOBAL TELECOMMUNICATION SYSTEM

AND WWW DATA MANAGEMENT: INFORMATION SYSTEMS AND SERVICES (extracted from Publication WMO-No. 986 — Chapter 3) September 2005

42

10. Skraćenice korištene u radu:

- WMO – World Meteorological Organization (Svjetska meteorološka organizacija)

- ECMWF – Europian Centre for Medium Range Weather Forecast (Evropski centar za srednjoročnu prognozu)

- WWW- World Weather Watch (Bdijenje nad vremenom) - RMDCN – Regional Meteorological Data Communication Network

(Regionalna mreža za razmjenu meteoroloških podataka) - GOS – Global Observing System (Globalni osmatrački sistem) - GTS –Global Telecommunication System (Globalni telekomunikacioni

sistem) - RTH- Regional Telecommunication Hub (Regionalni telekomunikacioni

čvor) - MPLS- Multi Protocol Label Switching - EUMETSAT – Evropska organizacija za eksploataciju meteoroloških

satelita - TCP – Transport Communication protocol (Transportni protokol) - IP – Internet protocol - FTP – File Transfer protocol - NMC – Nacionalni meteorološki centar - LAN – Local Area Network (Lokalna mreža) - VPN- Virtual Private Network (Virtuelno privatna mreža) - POP- Point of Presence (Pristupna tačka) - IKE-Internet Key Exchange protocol (Protokol za razmjenu ključeva) - SHA- Secure Hash Algorithm (Sigurnosni algoritam za haširanje) - RSA (Rivest, Shamir, Adleman) – digitalni potpis - AH – Authentication Header (Autentifikacija zaglavlja) - ESP- Encapsulation Security Payload (Sigurnosna enkapsulacija

paketa) - DMZ- Demilitarized zone (Demilitarizirana zona) - NIC – Network Interface Card (Mrežna kartica) - MAC adresa – Media Access Control (Hardwerska adresa mrežnog

uređaja) - SA-Security Associations (Sigurnosna asocijacija)

43