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-a 1

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 orbiti 2

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 DATA AND PRODUCT
COLLECTION PRODUCT GENERATION
TRANSPORT
Global Global Data
Observing Processing and
Global
System Forecasting
Telecommunication
System
System
GOS

DATA MANAGEMENT

DATA AND PRODUCT USERS

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-a 5

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 Interneta 6

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:

INTERNET

Satelitski sistem

Satelitski sistem

SWITCH
MODEM R UTER
V.35 port Ethernet

LAN

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-a 7

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-a 8

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
 Enkriptirani
paket koji je
osiguran od
Enkapsulira- neovlašte-
ni paket sa nog prislu-
Originalni
javnim IP škivanja
paket sa
privatnim adresama
IP
adresama

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