Preporukezamenadmentimonitoringmree

Dokument najbolje prakse

(smernice i preporuke)

Izraen u okviru AMRES tematske grupe za oblast NMS (AMRES BDP 101)

Autori:EsadSaitovi,IvanIvanovi

Februar,2011.

2

DVIzOOK Aori p Dsa DzaE

TERENA 201

okument broj: erzija / datum:

zvorni jezik : Originalni naslovOriginalna verzij

ontakt:

MRES/RCUB srganizovana u preporukama z

elovi dokumenauvana.

okument je najednice (FP7/ducation Netwo

0. Sva prava z

GN Feb Srp

v: Preja / datum: Rev

esa

snosi odgovornAMRESu radi

za mrene serv

nta mogu se sl

nastao kao rez/2007-2013) poork and Assoc

adrana.

N3-NA3-T4-AMbruar, 2011. pski eporuke za movizija 1 (dokumad@rcub.bg.ac

nost za sadrajsproveenja z

vise u viokok

obodno kopira

zultat istraivao ugovoru br. iated Services

RES-BPD-101

onitoring i menamenta od 24. oc.rs, ivan.ivanov

j ovog dokumezajednikih aktivolskim obrazov

ati, nepromenje

anja koja su f238875, koji

(GN3).

adment mreeoktobara 2009vic@rcub.bg.a

enta. U izradi dvnosti na razvovnim i istraiva

eni, pod uslovo

finansirana srese odnosi na

e .) / 2. februar 2c.rs

okumenta uesoju i irenju dokim ustanova

om da je origin

edstvima Sed projekat Mu

2011.

stvovala je temkumenata sa tema u Srbiji.

nalni izvor nave

mog okvirnog lti-Gigabit Euro

matska grupa zaehnikim smer

eden i autorska

programa Evopean Resear

a NMS, rnicama

a prava

vropske rch and

3

Sadraj

Rezime 5

Uvod 6

1 Priprema mree za implementaciju NMS-a 7

1.1 In-band vs Out-of-band 7

1.1.1 In-band okruenje 7

1.1.2 Out-of-band okruenje 7

1.2 Logika segmentacija mree u in-band menadment okruenju 8

2 Interfejsi za pristup ureajima 9

2.1 Mreni ureaji 9

2.2 Serveri 10

2.3 Ostali ureaji 11

3 Pristup menadment mrei 12

3.1 IP adresiranje 12

3.2 Pristup menadment delovima mree od strane administratorskog osoblja 12

3.3 Meusobna izolovanost ureaja u menadment mrei 13

3.4 Primeri topologija 13

4 Logiki pristup ureajima (protokoli za pristup ureajima) 16

4.1 Protokoli za kontrolu i konfigurisanje ureaja 16

4.2 Pristup mrenim ureajima 17

4.3 Pristup serverima 18

4.4 Pristup ostalim ureajima 18

4.5 Protokoli za nadgledanje ureaja 19

4.5.1 SNMP v2c 20

4

4.5.2 SNMP v3 20

5 Odravanje konfiguracija 21

5.1 Backup konfiguracija 21

6 Nms server 22

6.1 Pozicija NMS servera u mrei 22

6.2 Preporuena verzija SNMPa na mrenim ureajima i serverima 22

6.3 Preporuene promenjive za nadgledanje 23

6.3.1 Mreni ureaji 23

6.3.2 Serveri 23

6.3.3 UPS-evi 24

6.4 MIB varijable 24

6.4.1 Standardne MIB varijable 24

6.4.2 Privatne MIB varijable 24

6.5 Trap mod rada 25

6.6 Primeri konfiguracija SNMP-a na uredajima 25

6.6.1 CISCO Ruter 25

6.6.2 LINUX Server 27

7 uvanje sistemskih logova (syslog) 30

7.1 SysLog protokol 30

7.2 Lokacija syslog servera 31

7.3 Instalacija 32

7.3.1 Mreni ureaji 32

7.3.2 Serveri 33

8 Protokol za analizu saobraaja 35

8.1 NetFlow protokol 35

8.2 Princip rada sistema 36

8.3 Lokacija kolektora u mrei 36

8.4 Konfigurisanje NetFlow eksportera 37

8.5 Indirektna reenja prikupljanje NetFlow statistike 37

Reference 40

Renik 41

5

Rezime

Cilj ovog dokumenta je da prui uvid u osnovne NMS aktivnosti, zajedno s preporukama za administratore kampus i/ili lokalnih mrea koji planiraju da primene NMS alat unutar svojih mrea.

Dokument poinje razmatranjem topologije mree. Promene u topologiji su predloene u skladu sa idejom da bi veina NMS aktivnosti trebalo da se odvijaju kroz menadment segment mree. Dve alternative su razmatrane. Menadment mrea i produkciona mrea mogu biti fiziki odvojene mree (out-band management segment) ili mogu da dele istu fiziu infrastrukturu (VLAN segment mree).

Dokument identifikuje najmanje tri komponente koje bi trebalo da budu pokrivene Network Managament System-om. To su upravljanje konfiguracijama i upravljanje logovima, uz ve prepoznatu Network Monitoring komponentu koja se impementira upotrebnom nekog od NMS softverskih paketa.

Dokument ukratko opisuje naee koritene portokole za upravljanje i njihovu upotrebu u razliitim okruenjima i na razliitim tipovima ureaja u mrei (tj. mreni ureaji, serveri, UPS ureaji, A/C), uz uslov da ne ugroavaju sigurost mree.

6

Uvod

Sistemi za menadment mrea danas predstavljaju jedan od najvanijih elemenata uspenog funkcionisanja raunarskih mrea. Odravanje i konfiguracija mrenih ureaja, servera i servisa, kao i kontinualno nadgledanje rada svih ureaja u mrei, predstavljaju kljune elemente sistema za menadment mrea. Za pozdan i bezbedan menadment ureaja i servisa, neophodno je dizajnirati mreu tako da se obezbedi najvei nivo sigurnosti i izolovanosti menadment saobraaja od produkcionog saobraaja. Drugi aspekt uspenog menadmenta raunarskih mrea jesu protokoli koji se za tu svrhu koriste, kao i njihova implementacija, odnosno nain upotrebe. U prvom delu, dokument opisuje dizajn menadment dela mree (out-of-band, in-band), zatim preporuke za korienje protokola za pristup ureajima kao i metode za uvanje (backup) konfiguracija. U drugom delu, dokument opisuje protokole za nadgledanje u raunarskim mreama i protokol za analizu saobraaja (netflow), kao i njihovu implementaciju i nain upotrebe.

7

1 Priprema mree za implementaciju NMS-a

1.1 In-band vs Out-of-band

In-band menadment podrazumeva da se za svrhu menadmenta koriste interfjesi i mrena oprema koja se ujedno koristi i za produkcioni saobraaj.

Out-of-band menadment podrazumeva koricenje zasebne mrene infrastrukture i zasebnih intefejsa za svrhu menadmenta u odnosu na mrene ureaje i interfejse ureaja koji se koriste za produkcioni saobraaj.

Out-of-band menadment se preporuuje za kampus mree ili delove kampus mrea koje su koncipirane tako da se mrena oprema i serveri nalaze u jednoj prostoriji (mainskoj sali / server sobi / jednom voritu).

1.1.1 In-band okruenje

Prednosti:

Ne zahteva dodatnu fiziku infrastrukturu (mrene intefejse na serverima, zasebne mrene ureaje, pasivnu infrastrukturu).

Mane:

Smanjen nivo sigurnosti, obzirom da menadment saobraaj koji predstavlja "osetljiv" sadraj, prolazi kroz istu infrastrukturu kao i produkcioni saobraaj, odnosno, saobraaj ka krajnjim korisnicima;

U sluaju zaguenja (u normalnom radu, ili usled nekog Denial of Service napada), otean je (moda i onemoguen) pristup ureajima radi intervencija koje bi pomogle eliminisanju problema.

1.1.2 Out-of-band okruenje

Prednosti:

Fiziki izdvojena infrastruktura prua veu sigurnost za osetljive menadment informacije. Omoguen pristup i u sluaju problema na produkcionim linkovima (npr. prekid linka, zaguenje itd.)

8

Mane:

Zasebna mrena infrastruktura podrazumeva i trokove za nabavku opreme Zahveta vee inicijalno angaovanje administratorskog osoblja i trokove za implementaciju

1.2 Logika segmentacija mree u in-band menadment okruenju

Jedan od kljunih elemenata u organizaciji mree jeste logika segmentacija mree. Ovo se postie definisanjem radnih grupa i kreiranjem VLAN-ova za svaku od grupa. Takoe, potrebno je definisati i VLAN za svrhu menadmenta.

Definisanje VLAN-ova se moe obaviti na sledei nain:

VLAN-MGMT - VLAN za menadment. Iako je uobiajeno da taj VLAN bude VLAN 1, zbog poveanja sigurnosti, preporuuje se da se za svrhu menadmenta definie neki drugi VLAN, kroz koji e prolaziti samo menadment saobraaj.

VLAN-SERVER-ENT - VLAN za enterprise servere (DNS, proxy, e-mail, web ...) VLAN-SERVER- - VLAN za workgroup servere (razni aplikativni serveri, serveri baza

podataka i sl.)

VLAN-ADMIN - Administratorski VLAN VLAN-USER- - Korisniki VLAN-ovi u zavisnosti od radne grupe

9

2 Interfejsi za pristup ureajima

Potrebno je razmotriti koje mogunosti su raspoloive za pristup razliitim tipovima ureaja, kao i preporuke za primenu pojedinih reenja u zavisnosti od topologije mree. Definisane su tri grupe ureaja:

Mreni ureaji - ruteri, layer2 i layer3 svievi Serveri Ostali ureaji - UPS, klima ureaji, tampai i sl.

2.1 Mreni ureaji

Pristup mrenim ureajima se moe obaviti na neki od sledeih naina:

Console port - pristup korienjem ovog porta predstavlja pristup interfejsu komandne linije (Command Line Interface - CLI). Ovakav vid pristupa ureaju ne zahteva komunikaciju kroz mreu ve se zahteva direktna veza serijskog (COM) porta raunara sa kojim se pristupa ureaju i samog Console porta. Pristup ureajima putem Console porta se koristi za inicijalane konfiguracije ureaja, auriranje softvera na ureajima, resetovanje ifara za pristup, kao i za situacije kada ureaju nije mogue prii putem mrenih intefejsa. Pristup se obavlja korienjem nekog od softvera za terminalni pristup (Hyper Terminal, Putty, SecureCRT itd.)

AUX - predstavlja port koji se moe iskoristiti za udaljeno povezivanje na ureaj koricenjem dial-in veze. Kako ovaj dokument predstavlja preporuke za kampus i lokalne mree, nema ozbiljnih situacija u kojima bi implementacija ovog reenja za pristup bila opravdana.

OOBM - pojedini proizvoai mrene opreme ugrauju out-of-band menadment portove kojima se dodeljuje IP adresa i omoguava pristup kao i bilo kom mrenom interfejsu, ali je ogranien pristup na podrane menadment protokole (telnet, ssh, http...)

Zaseban ethernet intefejs - Kada su u pitanju mreni ureaji, izdvajanje zasebnog mrenog intefejsa samo za namenu menadmenta nije uobiajeno (moe se rei i nije preporuljivo) obzirom da je cena "po interfejsu" na ruterima znaajno velika. Kada su u pitanju svievi sa velikim brojem portova, izdvajanje zasebnog interfejsa jeste preporuljivo reenje, ali samo u okviru data centra, odnosno, ukoliko nije potrebno postavljanje dodatne pasivne infrastrukture (trokovi OOBM-a, pogledati poglavlje 2.)

10

VLAN-MGMT pristup - Pristup mrenim ureajima kroz logilko odvajanje saobraaja u zaseban VLAN za menadment je preporuljivo, jer je za implementaciju potrebno izvriti samo konfiguraciju postojee aktivne opreme. Po ureajima, konfiguracija se svodi na sledee:

Svievi - sve veze izmedu svieva treba da se nalaze u modu za prenos vie VLAN-ova (generalno IEEE 802.1Q standard, kao to je trunk mod kod Cisco ureaja, ili tagging mod kod drugih proizvoaa). Kroz taj link je potrebno "propustiti" i menadment VLAN (VLAN-MGMT).

Ruteri - na ruterima je potrebno definisati podinterfejse (subinterface) sa IP adresom iz opsega definisanog za menadment VLAN (takoe,uz korienje IEEE 802.1Q standarda).

Kada se konfigurie obeleavanje frejmova (802.1Q), Cisco ureaji (moda jo neki proizvoa) prekonfigurisano alju frejmove iz VLAN1 kao 802.3 frejmove, odnosno alju ih neobeleene.

Kod drugih proizvoaa, potrebno je definisati koji se VLAN alje kao neobeleen (untagged).

Radi poveanja sigurnosti preporuka je da se, ukoliko je to na ureajima mogue konfigurisati, saobraaj za sve VLAN-ove alje obeleen. Ukoliko na nekim ureajima nije mogue slati sve VLAN-ove obeleene, preporuka je da se definie VLAN koji e biti izolovan od ostatka mree (black-hole) i da se saobraaj ovog VLAN-a alje kao neobeleen.

2.2 Serveri

Pristup serverima u svrhu menadmenta se moe ostvariti na neki od sledeih naina:

KVM svi - uobiajeno je da su serveri locirani na jednom mestu, rek ormanima, na stolovima u serverskoj sali i sl. Da bi se olakao pritup samim serverima, praksa je da se koristi KVM svi koji omoguava vezu keyboard-video-mouse prikljuaka svih servera sa jednim fizikim setom ovih komponenti (tastatura, monitor, mi). Menadment servera se na ovaj nain moe vriti samo ukoliko se administrator fiziki nalazi u serverskoj sali gde se nalazi i KVM svi.

OOBM - poznatiji proizvoai u servere ugrauju i port za out-of-band menadment. Ovaj port predstavlja jo jedan mreni interfejs, ali ima specijalnu namenu.

Prednosti:

Ovaj port ima zaseban kontroler na matinoj ploi i omoguava TCP/IP pristup serveru nezavisno od operativnog sistema na serveru. Ovim je omoguen udaljen pregled deavanja na samom serveru kao da je u pitanju direktan pristup serveru (tastatura-monitor-mi), ukljuujui i sam proces startovanja servera (booting process)

Udaljeni pristup BIOS podeavanjima servera

Udaljena kontrola - ukljuivanje, iskljuivanje i restart servera

Mane:

U zavisnosti od proizvoaa, razlikuje se implementacija ovog reenja - ne postoji uniformno reenje

U osnovnoj (besplatnoj) verziji pristupa serveru po ovom portu, limitirane su funkcionalnosti. Za iri set funkionalnosti, kod pojedinih proizvoaa, potrebno je platiti licence.

Mreni intefejs - preporuka je da serveri imaju najmanje dva mrena interfejsa, to je uobiajen sluaj sa serverima koji su danas u prodaji. Sa druge strane, nije neuobiajeno da se za serverske funkcije koriste klijentski raunari boljih performansi koji imaju samo jedan mreni interfejs.

11

Pristup serverima u ovim razliitim okolnostima tretiramo na sledei nain:

Serveri sa najmanje dva mrena interfejsa:

Preporuka je da se jedan od interfejsa servera konfigurie kao menadment interfejs, odnosno da se nalazi u mrei za menadment (OOB deo mree ili menadment VLAN). Drugi (ostali) interfejsi servera ne bi trebali da se koriste za svrhu menadmenta.

Drugi (ostali) interfejsi servera se koriste za produkcioni pristup servisima koje server nudi.

Serveri koji imaju jedan mreni interfejs

Kako je kod ovih servera nemogue fiziki odvojiti menadment saobraaj od produkcijskog, preporuuju se dva pristupa u zavisnosti od hardvera. Pri bilo kom od ovih pristupa, preporuuje se korienje protokola za pristup koji kriptuju saobraaj.

Ukoliko mrena kartica podrava IEEE 802.1Q standard, preporuuje se da se na samoj kartici definiu logiki interfejsi koji se pridruuju razliitim VLAN-ovima, ukljuujui i jedan logicki interfejs pridruen menadment VLAN-u.

Ukoliko mrena kartica ne podrava IEEE 802.1Q standard, tada ni logiki nije mogue odvojiti menadment saobraaj od produkcionog. U ovom sluaju, server ne bi trebalo da ima vezu sa menadment delom mree.

2.3 Ostali ureaji

Pod grupom ostali ureaji, definiemo sve ureaje kojima primarna namena nema potrebe za mrenom komunikacijom (npr. ureaji za neprekidno napajanje, klima ureaji, senzori za vlagu). Pristup radi menadmenta se obavlja preko sledeih intefejsa:

Serijski port - menadment korienjem serijskog porta na ureajima se obavlja koristei namenski softver proizvoaa. Uobiajeno je da ukoliko postoji i mreni interfejs na ureaju, serijski port slui samo za inicijalna podeavanja IP parametara radi prelaska na pristup po mrenom interfejsu.

Mreni interfejs - poznatiji proizvoai u paleti proizvoda imaju i kartice sa mrenim interfejsom koje se ugrauju u njihove ureaje za svrhu menadmenta.

12

3 Pristup menadment mrei

Za definisanje naina pritupa menadment mrei potrebno je definisati:

IP adresiranje ureaja u menadment mrei Metode pristupa menadment mrei Nivo meusobne izolovanosti ureaja u menadment mrei

3.1 IP adresiranje

Radi poveanja sigurnosti menadment delova mree, preporuuje se da se za te delove mree definiu zasebni IP adresni opsezi. Ovo vai za out-of-band menadment mreu, kao i za menadment VLAN segment. Ovi opsezi adresa ne bi trebalo da se oglaavaju (rutiraju) ostatku mree.

3.2 Pristup menadment delovima mree od strane administratorskog osoblja

Potrebno je definisati metode pristupa menadment delovima mree u razliitim okruenjima i situacijama.

Ovde smo definisali tri metode pristupa:

Pristup ureajima iz menadment dela mree:

Za ovaj vid pristupa potrebno je da u menadment delu mree postoji raunar iji je jedini mreni interfejs prikljuen u samu menadment mreu.

Ovom raunaru je dozvoljen pristup samo u okviru menadment dela mree. Pristup ureajima iz administratorskog VLAN segmenta:

Korienje NAT funkionalnosti za administratorske raunare koji prilaze ureajima u menadment delu mree

Adrese u koje se transliraju administratorski raunari su iz adresnog opsega menadment dela mree. Na ovaj nain se postie efekat pristupa iz same menadment mree

Pristup ureajima sa udaljenih lokacija:

13

Obavezno koricenje VPN tehnologije za pristup Kao i za pristup iz administratorskog VLAN segmenta i ovde se primenjuje funkcija NAT-a po istom

modelu

3.3 Meusobna izolovanost ureaja u menadment mrei

Radi postizanja veeg nivoa sigurnosti, potrebno je ograniiti meusobnu komunikaciju ureaja u menadment mrei. Preporuke za ova ogranienja su:

Menadment serverima se omoguava komunikacija sa svim ostalim ureajima u menadment mrei, ali samo za menadment protokole.

Ostali ureaji meusobno ne mogu da komuniciraju kroz menadment mreu

Ovaj nivo izolovanosti se na Cisco ureajima (moda na ureajima jo nekog proizvoaa) moe postii korienjem sledeih funkcionalnosti na OOBM sviu.

Private VLAN Portovi na OOBM sviu, na koje su povezani svi ureaji (osim menadment servera) se nalaze u

Isolated modu rada. Portovi koji se nalaze u Isolated modu rada mogu da komuniciraju samo sa portovima koji se nalaze u Promiscuous modu rada.

Portovi na OOBM sviu, na koje su povezani menadment serveri (kao i portovi za pristup OOBM mrei od strane administratora) se nalaze u Promiscuous modu rada. Portovi koji se nalaze u Promiscuous modu rada mogu da komuniciraju sa svim portovima, bez obzira na njihov mod rada.

MAC-Access Control List Omoguava se filtriranje unutar broadcast domena, bazirano na MAC adresama ureaja.

3.4 Primeri topologija

Na slici 3-1 je prikazan sveobuhvatni primer topologije menadment mree. Na primeru su prikazani:

Out-of-band menadment mrea Tri metoda pristupa menadment mrei (racunar u OOBM-u, pristup iz administratorskog VLAN-a,

udaljeni pristup kroz VPN)

Pristup menadment VLAN mrei iz OOBM mree Veze mrenih uredaja sa OOBM mreom korienjem console porta, specijalizovanog OOBM porta Veza mrenih uredaja sa menadment mreom kroz menadment VLAN Dodatni intefejs servera za vezu sa OOBM ili menadment VLAN delom mree Veze ostalih ureaja sa OOBM ili menadment VLAN delom mree Pozicije menadment servera i veze sa menadment delom mree, kao i sa ostatkom mree u sluaju

monitoring sistema.

14

Slika 3-1 Primer sveobuhvatne topologije menadment mree

15

Na slici 3-2 je prikazan primer segmentacije mree i veze ureaja sa menadment VLAN-om.

Slika 3-2 Topologija segmentirane mree i veze ureaja sa menadment VLAN-om

16

4 Logiki pristup ureajima (protokoli za pristup ureajima)

4.1 Protokoli za kontrolu i konfigurisanje ureaja

Nakon definisanih naina fizikog pristupa ureajima, potrebno je definisati i komunikacione protokole koji se preporuuju za koricenje u razliitim okolnostima.

Prvo su dati opisi protokola sa osnovnim karakteristikama a zatim i preporuke za korienje, zasebno za tipove ureaja sa kojima se komunicira.

TTY - Karakteristike:

Protokol za asinhronu serijsku komunikaciju. Koristi se u komunikaciji sa Console portom mrenih ureaja.

Telnet - Karakteristike:

Omoguava pristup komandnoj liniji (Command Line Interface - CLI) Protokol je podran na gotovo svim ureajima Komunikacija izmeu telnet klijenta (ureaja sa kojeg se pristupa) i telnet servera (ureaja kojem se

pristupa) se obavlja u ne-enkriptovanom modu (clear text) to je kljuna mana ovog protokola.

SSH (Secure Shell) - Karakteristike:

Omoguava pristup komandnoj liniji (vizuelno, identican Telnet protokolu) Komunikacija izmeu SSH klijenta i SSH servera se obavlja u enkriptovanom obliku, zbog ega se

preporuuje za primenu umesto Telnet protokola, gde god je to mogue

Za podrku ovom protokolu ureaji moraju imati softversku podrku za kriptovanje RDP (Remote Desktop Protocol) - Karakteristike:

Omoguava grafiki pristup serveru (pristup desktopu) Razvijen od strane Microsoft-a, ali postoje implementacije i za druge OS platforme Nivo kriptovanja podataka koji se prenose u komunikaciji RDP klijent - RDP server, se moe podesiti na

RDP serveru (windows server platforme). Koristi se algoritam RSA RC4, koji ima svoje nedostatke i ne moe se okarakterisati kao potpuno siguran.

17

Korienje se preporuuje kroz VPN mree VNC (Virtual Network Computing) - Karakteristike:

U pitanju je aplikacija bazirana na RFB protokolu (Remote FrameBuffering) Kao i RDP, omoguava grafiki pristup serverima Postoji nekoliko verzija VNC aplikacija i implementacija koje su besplatne, kao i onih za koje su

potrebne licence

VNC u svojoj osnovnoj (besplatnoj) verziji ne podrava nikakve mehanizme enkriptovanja saobraaja. Korienje se preporuuje kroz VPN mree

HTTP(S) {HyperText Transfer Protocol (Secure)} - Karakteristike

Omoguava web pristup uredajima U osnovnoj varijanti ne podrava enkripciju. HTTPS (HTTP Secure) predstavlja kombinaciju HTTP i

SSL/TLS protokola koji se smatra dovoljno sigurnim za prenos podataka.

4.2 Pristup mrenim ureajima

Kada su u pitanju mreni ureaji, korienje pojedinih protokola se preporuuje u sledeim okolnostima:

TTY protokol, odnosno pristup Console portu ureaja se preporuuje:

Kada je potrebno resetovati ifre za pristup ureaju Kada nije obezbeen pristup ureaju kroz mreu, nekim od protokola opisanih u nastavku U sluaju da je otean ili onemoguen pristup kroz mreu usled nekog DoS napada, obrisane

konfiguracije i/ili pogrene konfiguracije koja blokira pristup ureaju, itd.

Telnet protokol se preporucuje:

Kada nije mogua direktna veza na Console port ureaja Kada na uredajima ne postoji podrka za SSH pristup, to zavisi od verzije i podranih funkcija

operativnog sistema samog ureaja.

Ukoliko postoji VPN mrea kroz koju se ostvaruje veza sa sigurnim delom mree kroz koji se pristupa ureajima (out-of-band segment). Ili ukoliko postoji direktna veza sa menadment VLAN-om.

SSH protokol se preporuuje:

Ukoliko operativni sistem ureaja ima podrku za kriptovanje saobraaja, odnosno, podrku za sam protokol

Kada ne postoji direktna veza sa mreom iz koje se sigurno pristupa ureajima (out-of-band segment) ili sa menadment VLAN-om.

HTTP(S) protokol se preporuuje:

Ukoliko postoji podrka za HTTP protokol i pod sledeim uslovima: Za osnovnu verziju protokola (HTTP) vae iste preporuke kao za Telnet protokol

Za kombinaciju protokola HTTP + SSL/TLS (HTTPS), vae iste preporuke kao i za SSH protokol

18

4.3 Pristup serverima

Pristup serverima u svrhu menadmenta se moe fleksibilnije podesiti, obzirom da za najvei broj operativnih sistema postoji softverska implementacija gotovo svih protokola za pristup. Okruenja u kojima se preporuuju pojedini protokoli:

SSH pristup se preporuuje:

Kada su u pitanju Unix bazirani operativni sistemi, pristup koricenjem SSH protokola je uobiajena praksa i nje se treba drati.

Grafiki pristup:

Protokoli za grafiki pristup (RDP, VNC i sl.) se preporuuju za primenu iskljuivo kroz menadment mreu (out-of-band i/ili menadment VLAN)

Preporuuje se primena ovih protokola i van menadment dela mree ali iskljuivo ako se koristi VPN veza od klijenta do menadment dela mree.

Telnet pristup se preporuuje:

Iako su retki sluajavi kada je serverima potrebno prii Telnet protokolom, preporuka je da se ovaj protokol koristi samo ukoliko se pristupa serverima kroz interfejs koji se nalazi u menadment mrei (out-of-band ili menadment VLAN-u). Ovo podrazumeva obavezno postojanje minimum dva mrena intefejsa servera (poglavlje 2.2)

Ukoliko postoji VPN veza klijenta (raunara sa kojeg se pristupa) sa menadment delom mree

4.4 Pristup ostalim ureajima

Prisutup "ostalim" ureajima (UPS, klima ureaji itd.) zavisi od tipa konkretnih ureaja, kao i od hardverskog pristupa ureaju, odnosno od tipova mrenih intefejsa i protokola koji su podrani. Uobiajeni naini pristupa sa preporukom korienja su:

Telnet pristup:

Korienje Telnet protokola se preporuuje iskljuivo ako je mreni interfejs ureaja u menadment delu mree (out-of-band i/ili menadment VLAN-u)

Ukoliko nije mogue povezati mreni intefejs ureaja u zatieni menadment deo mree, Telnet protokol se ne preporuuje.

Web pristup:

Ukoliko postoji podrka za web (HTTP) pristup, preporuka je korienje istih samo ukoliko je mreni interfejs u zatienom menadment delu mree. Web pristup korienjem HTTPS protokola je preporuljivo koristiti i ukoliko mreni interfejs ureaja nije povezan u zatieni menadment deo mree.

19

4.5 Protokoli za nadgledanje ureaja

Dosta dananjih mrenih sistema se oslanja na monitoring pomou SNMP protokola. Sam SNMP protokol je dizajniran tako da veoma malo optereuje mreu. Naziva se prostim protokolom zato to koristi proste (nestrukturirane) tipove podataka. Ovaj protokol aplikativnog nivoa OSI modela sastavni je deo TCP/IP steka protokola. Sastoji se od skupa standarda kojima se definiu: nain upravljanja mreom, baze podataka za uvanje informacija i strukture korienih podataka. Koristi UDP kao transportni protokol, mada je mogue podesiti i rad preko TCP-a. Korienje SNMP protokola preko TCP-a nije preporuljivo u velikim mreama usled uspostavljanja velikog broja konekcija, to moe opteretiti ureaje, i zbog veliine zaglavlja TCP protokola, to moe poveati saobraaj na linku. Trenutno su aktuelne dve verzije SNMP protokola, SNMP v2c i SNMP v3. Karakteristike verzija sa stanovita sigurnosti su date u tabeli 4.5.1.

Tabela 4.5.1 Karakteristike SNMP protokola.

SNMP Security modeli i nivoi

Model Nivo Autentifikacija Enkripcija Princip rada

v1 noAuthNoPriv Community String - Koristi Community string za autentifikaciju.

v2c noAuthNoPriv Community String - Koristi Community string za autentifikaciju.

v3 noAuthNoPriv Korisniko ime - Koristi Korisniko ime za autentifikaciju.

v3 authNoPriv MD5 ili SHA -

Autentifikacija se bazira na HMAC-MD5 ili HMAC-SHA algoritmu. Umesto ifre se alje MD5 ili SHA hash.

v3 authPriv MD5 ili SHA DES/AES

Autentifikacija se bazira na MD5 ili SHA algoritmu. Omogucuje DES/AES enkripciju prilikom prenosa podataka.

Dva osnovna moda rada SNMP protokola su READ i READ/WRITE mod. READ mod omoguuje samo oitavanje SNMP promenjivih sa udaljenog ureaja, dok READ/WRITE omoguuje postavljanje pojedinih varijabli na udaljenom ureaju, odnosno kontrolu ureaja (restart rutera, backup trenute konfiguracije...). Prilikom konfigurisanja agenta na udaljenom ureaju mogue je podesiti ogranienja na MIB bazi (Management Information Base). Ako se READ/WRITE opcija koristi za setovanje samo jedne OID varijable, u MIB bazi treba izvriti ogranienja na SNMP agentu samo na tu OID vrednost. Tada bi podeavanje ostalih OID vrednosti bilo zabranjeno. Ovi primeri ce biti dati u sekciji koja se odnosi na podeavanje agenata na pojedinim tipovima ureaja.

20

4.5.1 SNMP v2c

Trenutno najzastupljenija verzija SNMP protokola je SNMP v2c (RFC 1901-1908). Kod verzije SNMP v2c se autentifikacija vri pomou community stringa i on se alje u istom tekstu preko mree. U sluaju da neko uhvati ovaj saobraaj pomou neke sniffing aplikacije, moe vrlo lako otkriti community string i na taj nain biti u mogunosti da ugrozi ispravan rad mree. Korienje SNMP v2c se preporuuje samo kada sami ureaji ne podravaju verziju SNMP v3, ali tada se obavezno uvode drugi mehanizmi za zatitu prilikom prenosa podataka (ACL, Firewalls....). Za nadgledanje mree preporuuje se korienje READ moda, a u sluaju potrebe za kontrolom mree (READ/WRITE) putem SNMP protokola preporuuje se uvoenje ogranienja u MIB bazi. Prilikom pokretanja SNMP v2c agenta na ureajima obino postoji predefinisana vrednost za community string i ona je postavljena na vrednost public. Taj, ve svima poznati, predefinisani community string treba obavezno promeniti na neku drugu vrednost po mogustvu kombinaciju brojeva i slova.

4.5.2 SNMP v3

Potreba za sigurnocu u mrei dovela je do razvoja SNMP v3.

SNMP v3 uvodi vane bezbednosne aspekte:

1. Integritet poruke (Message integrity), spreava mogunost izmene paketa prilikom prenosa 2. Autentifikacija, potvrda da je poruka stigla sa pravog izvorita 3. Kriptovanje paketa, spreavanje itanja poruka od strane neautorizovanog izvora

Iz tabele 4.5.1 se vidi da se kod SNMP v3 uvodi tri razliita nivoa sigurnosti. Najsigurniji nivo koristi autentifikaciju baziranu na SHA algoritmu i koristi DES ili AES enkripciju. Pre uvoenja nivoa sigurnosti treba proveriti da li mreni ureaji podravaju enkripciju saobraaja. U sluaju da ureaji ne podravaju enkripciju, moe se koristiti nii nivo sigurnosti koji koristi samo autentifikaciju. Trei, najslabiji nivo sigurnosti se ponaa praktino kao SNMP v2c i koristi korisniko ime, isto kao to SNMP v2c koristi community string, za pristup ureaju. Prilikom pokretanja SNMP v3 agenta preporueno je uvesti ogranienja u MIB bazi za READ i READ/WRITE mod na pojedine OID vrednosti.

21

5 Odravanje konfiguracija

5.1 Backup konfiguracija

Kako uvek moe doci do nenadanog otkaza nekog od uredaja, ili dela njegove funkcionalnosti, poeljno je da se pri zameni istog, uredaj postavi u stanje funkcionalnosti koje je imao pre otkaza i to uz minimizaciju vremena otkaza (down-time). Ovo je moguce ukoliko se pravilno i redovno odrava backup konfiguracija svih uredaja u mrei.

Kada su pojedinani tipovi uredaja u pitanju, pri backup-u konfiguracija, prvenstveno se misli na mrene uredaje. Backup konfiguracije kod mrenih uredaja je uobicajeno da se vri primenom nekog od jednostavnih protokola za prenos podataka kao to su TFTP i RCP.

Zajednicka mana ovih protokola je prenos podataka u neenkriptovanom obliku. Ovo predstavlja problem, jer su esto poverljive informacije upravo u konfiguracijama koje se backup-uju (korisniko ime/ifra, verzije operativnog sistema i sl.). TFTP se smatra jo nesigurnijim protokolom, obzirom da nema funkciju autentifikacije pristupa serveru.

Zbog svega gore navedenog, preporucuje se da se backup konfiguracija vri tako da su serveri za backup (TFTP i/ili RCP) obavezno povezani samo u zaticeni menadment deo mree i izolovani od ostatka mree.

Kada su u pitanju serveri, potrebno je backup-ovati sve konfiguracione parametre nekog servisa. Ovo je izvodljivo ukoliko se konfiguracioni parametri nalaze u nekom konfiguracionom fajlu, pa se isti moe preneti nekim protokolom za prenos podataka kao to su FTP ili SCP na server za backup.

Preporucuje se koricenje SCP protokola za prenos, obzirom da za razliku od FTP-a, enkriptuje podatke pri prenosu.

Eventualno, moguce je vriti backup ukoliko sama serverska (klijentska) aplikacija ima implementiran neki mehanizam za backup.

22

6 Nms server

6.1 Pozicija NMS servera u mrei

Pri definisanju pozicije NMS servera u mrei potrebno je striktno definisati politiku pristupa NMS serveru. Za kampus mree preporuke su sledee:

NMS server mora da ima jedan mreni interfejs koji se nalazi u menadment mrei (OOBM ili menadment VLAN-u). Ovaj interfejs slui kako za menadment samog NMS servera, tako i za komunikaciju NMS alata sa ostalim ureajima u mrei.

NMS moe, ukoliko je to potrebno, imati dodatni mreni interfejs u produkcijskom delu mree. Ovaj interfejs bi imao ulogu pristupa monitoring sistemu radi nadgledanja trenutnog statusa ureaja i detekcije alarma. Pristup po ovom interfejsu bi trebao biti limitiran na read only mod, sa mogunou izvravanja pojedinih predefinisanih akcija radi dijagnostike. Takoe, potrebno je limitirati pristup preko ovog interfejsa samo na eljene korisnike (administratori i helpdesk sluba).

6.2 Preporuena verzija SNMPa na mrenim ureajima i serverima

Veina ureaja podrava verziju SNMP v2c dok samo noviji ureaji podravaju verziju SNMP v3. Verzija SNMP protokola kod servera zavisi iskljuivo od tipa operativnog sistema koji se koristi. Kako Windows OS ne podrava verziju SNMP v3 potrebno je nai SNMP agenta koji je podava i instalirati ga. Jedna od besplatnih Windows verzija SNMP v3 agenta, koja je bazirana na linux-ovom paketu NET-SNMP, moe se preuzeti sa sledeeg sajta (http://marksw.com/snmpv3agent/windowsagent.html). Postoji dosta besplatnih varijanti Windows SNMP agenata koje se mogu preuzeti sa Interneta. U okviru instalacije Linux OS postoji paket NET-SNMP koji podrava verziju SNMP v3 i koji moe da se instalira zajedno sa operativnim sistemom. Implementacija SNMP v3 kod servera nee imati veliki uticaj na performanse ureaja tako da je SNMP v3 sa najviim nivoom sigurnosti preporuena za korienje kod servera. U sluaju rutera i svieva problem se moe javiti ako su memorija i CPU ve optereeni sa nekim drugim procesima tako da pokretanje SNMP v3 moe imati uticaj na performanse ureaja, naruito ako se oitava cela MIB baza i pritom se koristi nivo sigurnosti koji koristi enkripciju. U tom sluaju bez obzira to ureaji podravaju verziju SNMP v3 nije preporuljivo pokretati enkripciju SNMP saobraaja da ne bi dolo do degradacije peformansi ureaja, ve pokrenuti nivo koji koristi samo autentifikaciju.

23

6.3 Preporuene promenjive za nadgledanje

Pre implementacije monitoring sistema u mreu potrebno je definisati parametre koji e se nadgledati. MIB baza prua veliki broj OID parametara i pitanje je kako odabrati vrednosti koje nam pruaju najbitnije informacije o stanju mrenih ureaja i linkova. Tendencija u IT svetu je da se koriste standardne IETF MIB baze koje svaki proizvoa ureaja treba da podrava.

6.3.1 Mreni ureaji

Parametri koji se najee prate kod mrenih ureaja kao to su ruteri i svievi su:

1. Stanje Interfejsa (L2 i L3 veza) 2. Protok na interfejsu (dobija se indirektno uzastopnim oitavanjem brojaa i deljenjem sa vremenskim

intervalom izmedu oitavanja) i. Standardan In/Out saobraaj(bits/sec)

ii. Odbaen In/Out saobraaj(bits/sec)

iii. Preneti saobraaj po In/Out paketima(packets/sec) 3. Optereenje procesora 4. Optereenje memorije

i. I/O memorija

ii. CPU memorija

U sluaju potrebe za praenjem funkcija koje se ne sreu na svim ureajima odnosno koje su karakteristine za pojedine proizvoae potrebno je ispitati MIB baze proizvoaa koji je napravio taj ureaj.

6.3.2 Serveri

OID promenjive koje se mogu oitavati kod servera zavise od operativnog sistema. U optem sluaju svi operativni sistemi podravaju standardne IETF MIB baze, tako da je dosta OID vrednosti univerzalno za sve ureaje koji podravaju SNMP. Preporuene su sledee vrednosti:

1. Stanje Interfejsa (L2 i L3 veza) 2. Statistika interfejsa (dobija se indirektno)

i. Standardan In/Out saobraaj (bits/sec)

ii. Odbacen In/Out saobraaj(bits/sec)

iii. Protok po In/Out paketima(packets/sec)

iv. Koliko dugo je interfejs aktivan 3. Optereenje procesora 4. Optereenje memorije

i. HDD memorija

ii. RAM memorija 5. Swap space memorija 6. Broj sistemskih procesa 7. Lista pokrenutih servisa na serveru 8. Broj uspostavljenih TCP konekcija 9. Broj trenutno ulogovanih sistemskih korisnika

24

6.3.3 UPS-evi

U sluaju praenja SNMP promenjivih UPS ureaja, veina OID vrednosti se mora nai u MIB bazama proizvoaa. Preporuene varijable su:

1. Trentno stanje UPS-a, odnosno mod rada (battery mod, online mod, malfunction.....) 2. Kapacitet batrije UPS-a 3. Koliko dugo UPS moe da radi u battery modu. 4. Temperatura baterije 5. Izlazno optereenje UPS-a 6. Ulazni napon 7. Izlazni napon 8. Ulazna struja 9. Izlazna struja

6.4 MIB varijable

Varijable u MIB bazi se dele na dve grupe. Prva grupa predstavlja skup varijabli koje se mogu nai na svim ureajima (standardne varijable) dok druga grupa predstavlja varijable koje su specifine samo za pojedine proizvoae mrenih ureaja (privatne varijable).

6.4.1 Standardne MIB varijable

Standardne IETF MIB baze se nalaze pod MIB-2 (.1.3.6.1.2.1) vorom u MIB stablu. Neke od najee korienih varijabli iz ovog vora su:

1. interfaces (.1.3.6.1.2.1.2) - Ovde se nalaze sve informacije o stanju interfejsa na ureaju. 2. ifMIB (.1.3.6.1.2.1.31) - ifMIB Predstavlja proirenje interfaces MIB baze sa 32bit-nih brojaa na 64bit-

ne brojae. 3. tcp (.1.3.6.1.2.1.6) - Ovde se nalaze parametri koji opisuju tcp konekcije. 4. host (.1.3.6.1.2.1.25) - Host tabela sadri informacije o stanju procesora i memorije na serverima.

6.4.2 Privatne MIB varijable

Privatne MIB varijable definie i implementira proizvoa mrenih ureaja i one se mogu koristiti samo na ureajima tog proizvoaa. Sve privatne MIB varijable se nalaze pod enterprises (.1.3.6.1.4.1) vorom u MIB bazi. U daljem tekstu su dati primeri MIB varijabli pojedinih proizvoaa mrenih ureaja.

1. Cisco(.1.3.6.1.4.1.9) Sadri sve privatne MIB varijable koje su podrane na razliitim tipovima Cisco ureaja.

2. APC(.1.3.6.1.4.1.318) Sadri sve privatne MIB varijable koje su podrane na razliitim tipovima APC ureaja.

3. juniperMIB(.1.3.6.1.4.1.2636) - Sadri sve privatne MIB varijable koje su podrane na razliitim tipovima Juniper ureaja.

25

6.5 Trap mod rada

SNMP protokol se koristi za periodino oitavanje podataka sa udaljenih ureaja. Kada bi se desila promena na udaljenom ureaju ona bi bila detektovana tek kada bi je NMS (Network Monitoring System) server oitao, a taj vremenski interval moe biti dosta dug. Zato je uveden koncept trap poruka. U sluaju da se desi neka promena na udaljenom ureaju sam udaljeni ureaj bi generisao SNMP trap poruku ka NMS serveru u kojoj bi definisao promenu koja se javila. SNMP trap mod rada je tako dizajniran da isporuuje SNMP trap poruke putem udp-a po portu 162 i to samo u jednom smeru, bez zahteva za potvrdom o tome da li je primljen trap ili ne. SNMP v2c alje trap poruku sa community stringom u istom tekstu. Verzija SNMP v3 trap informacije alje tano odreenom korisniku sa odreenom ifrom i odreenim engineID-om i ta cela informacija, u zavisnosti od sigurnosnog modela, moe biti enkriptovana. Iz ovoga sledi da sam NMS server mora znati korisniko ime, ifru i engineID koji je konfigurisan na udaljenom ureaju da bi mogao da dekriptuje primljeni SNMP v3 trap. Podeavanja koja se koriste za SNMP v3 na udaljenim ureajima se moraju isto podesiti i na NMS serveru. Umesto da se kreira ogroman broj razliitih korisnika na NMS, na svim ureajima se moe generisati isti korisnik i to samo kao korisnik koji alje trap poruke. Kako se prilikom kreiranja korisnika na udaljenim ureajima automatski generie engineID, potrebno je runo promeniti enginID tako da bude isti za trap korisnika na svim ureajima. Prednosti korienja SNMP v3 kod trapa su u tome to nam omoguuju sigurnost prilikom primanja trap poruka, ali ako je mrea dizajnirana tako da nije lako mogue izvriti bilo kakav vid DoS napada na NMS moe se koristiti i SNMP v2c trap mod rada. Kompleksnost konfiguracije za trap kod SNMP v3 je jedan od glavnih razloga zato se ee koristi SNMP v2c za trap mod rada.

6.6 Primeri konfiguracija SNMP-a na uredajima

U konfiguracijama koje su korienje u primerima u nastavku teksta, vrednosti parametra (npr. community string) su prikazane u italic formi.

6.6.1 CISCO Ruter

6.6.1.1 SNMP v2c

U ovom primeru su prikazane komande za podeavanje verzije SNMP v2c protokola.

Pomou sledee komande, koja se koristi u konfiguracionom modu, pokree se SNMP agent na ruteru.

1. SNMPTEST(config)#snmp-server community donotusepublic ro acl10

String koji se koristi kao autentifikacija donotusepublic predstavlja vid zatite tako da e ruter odgovoriti samo onom ureaju koji mu poalje zahtev koji sadri ba ovaj string. Opcija ro naglaava da je mogue samo oitati podatke a ne i menjati ih (ro-read only). Takoe je mogue i menjati pojedine varijable (wr-write komanda) to moe dovesti do promene rada rutera (restart rutera), zato je veoma bitno da se ne koriste fabriki predefinisane vrednosti za community string i da se SNMP upiti ogranie samo na mogunost oitavanja a ne i menjanja varijabli. Konano na kraju komande je definisana access lista acl10 pomou koje se moe definisati pristup SNMP agentu na ureaju samo sa odreenih ip adresa.

26

Da bi se ispravno podesio i snmp trap mod rada potrebno je definisati community string za trap mod, pokrenuti SNMP-trap i definisati destinacionu adresu na koju e se slati trap poruke.

2. SNMPTEST(config)#snmp server enable traps snmp linkup likdown

3. SNMPTEST(config)#snmp server host 192.168.10.1 version 2c donotusepublic

U prvoj komandi se definie tip akcije za trap. Ako padne link ili se povrati generisae se trap poruka. U drugoj komandi se definie IP adresa na koju e se slati trap-ovi, verzija SNMP-a koja e se koristiti i community string.

6.6.1.2 SNMP v3

Pomou sledeih komanda se pokree SNMP v3 protokol na Cisco ureajima.

1. SNMPTEST(config)#snmp-server view MYGROUPV interfaces included

2. SNMPTEST(config)#snmp server group MYGROUP v3 auth read MYGROUPV

3. SNMPTEST(config)#snmp server user pera MYGROUP v3 auth md5 perapass priv des56 pera1234

4. SNMPTEST(config)#snmp server enable traps linkup linkdown

5. SNMPTEST(config)#snmp server host 192.168.10.1 traps version 3 priv MYGROUP

U prvoj komandi se definiu vrednosti u MIB bazi OID-ova koji mogu biti oitani sa ureaja. U ovom sluaju je omogueno oitavanje OID-a (interface) koji opisuju stanje interfejsa na ureaju. Ako se ne definie ovakva grupa predpostavlja se da je dozvoljen pogled na sve vrednosti u MIB bazi. Druga komanda definie grupu MYGROUP koja koristi SNMP v3 protokol i koja koristi autentifikaciju. Ova grupa ima mogunost oitavanja podataka iz MIB baze i to samo onih koji su definisani u "pogledu" MYGROUPV..

Trea komanda definie korisnika pera koji pripada grupi MYGROUP koji koristi SNMP v3, autentifikaciju pomou md5 algoritma i ima ifru perapass. Poslednjom opcijom u komandi 3 des56 pera1234 se definie passphrase koji se koristi za des56 enkripciju SNMP saobraaja.

etvrta komanda pokree SNMP trap mod rada.

Peta komanda definie NMS server koji e prikupljati trap poruke. U ovom sluaju prilikom komunikacije izmeu NMS i Cisco ureaja koristie se SNMP v3 i pravila koja su definisana pomou grupe MYGROUP. Odavde se vidi da se engineID automatski generisao i u sluaju da elimo da NMS server moe da primi trap poruke od user-a pera potrebno je videti koji je engineID usera pera i konfigurisati ga u SNMP agentu na NMS serveru.

Drugi nain je da se pomou sledee komande manuelno postavi engineID za lokalnog ili udaljenog korisnika.

27

6. snmp server engineID [local engineid-string] | [remote ip-address udp-port port- number engineid-string]

6.6.2 LINUX Server

6.6.2.1 LINUX Server - SNMP v2c

U sluaju podeavanja SNMP protokola na Linux operativnim sistemima prvo je potrebno instalirati SNMP deamon-a na server. U sledeem primeru bie opisana instalacija na CentOS 5.X operativnom sistemu pomou YUM komande. Sledea komanda omoguuje automatizovanu instalaciju SNMP deamona i korisnih komandi za kontrolu rada SNMP-a.

1. yum install net-snmp net-snmp-utils

Sledei korak je podeavanje servisa da se automatski pokree prilikom startovanja servera. Potrebno je uneti sledeu komandu.

2. chkconfig snmpd on

Sledea stavka je podeavanje community stringa i OID objekata koji mogu biti oitani sa servera. Potrebno je editovati fajl snmpd.conf koji se obino nalazi u direktorijumu /etc/snmp/ i izmeniti sledee redove. U redu

com2sec notConfigUser default public

potrebno je promeniti defaultni community string public u eljeni community string.

U redu

view systemview included .1.3.6.1.2.1.1

se vidi de su ukljueni svi OID-ovi koji se nalaze ispod cvora .1.3.6.1.2.1.1 u MIB drvetu. Pomou komande excluded mogue je iskljuiti pojedine OID vrednosti, odnosno uvesti ogranienja u prikazu MIB baze. Ovde je potrebno definisati OID vrednosti koje e server vraati kao odgovor na SNMP upite. Ako NMS zatrai OID koji nije ovde definisan server nee odgovoriti NMS-u.

Sada je potrebno pokrenuti servis sledeom komandom:

3. service snmpd start

Proveru je mogue uraditi pomou sledee komande:

4. snmpwalk -v 2c -c mojcommunity 127.0.0.1

28

Kao rezultat e se prikazati cela MIB tabela (drvo), ili deo MIB tabele, koji je definisan prethodnim komandama za ogranienje prilikom oitavanja MIB baze.

6.6.2.2 LINUX Server - SNMP v3

Instalacija SNMP v3 agenta je ista kao za prethodnu verziju 2c, samo je sada potrebno pokrenuti verziju SNMP v3. Potrebno je editovati fajl snmpd.conf, i dodati sledee komande.

syslocation MojGradiliLokacija

syscontact mojemail@provajder.com

view mojpogled included .1.3.6.1.2.1.2.2

createUser john MD5 john1234 DES john5678

rouser john priv -V mojpogled

Prva dva parametra, syslocation i syscontact su podaci koji slue da daju opte informacije o serveru. Oni nisu znaajni za ispravan rad SNMP protokola i mogu se dodati bez obzira na verziju SNMP-a. Bitni su za administratore servera koji e imati pored osnovnih informacija o stanju servera i informaciju o lokaciji servera i kontakt osobi kojoj se mogu obratiti u sluaju pojave problema. Syslocation i Syscontact su neki od parametara koji se mogu nai na svim ureajima koji podravaju SNMP protokol. Trei red definie pogled mojpogled, odnosno skup OID vrednosti iz MIB stabla. U ovom sluaju je definisana tabela interfejsa servera. Mogue je dodati vie tabela ili pomou komande exclude iskljuiti neke OID vrednosti. Ova ogranienja su veoma bitna zato to je pomou SNMP-a mogue i postaviti neke parametre a to direktno moe uticati na ispravan rad ureaja.

etvrta komanda kreira korisnika john cija je ifra john1234. Prlikom autentifikacije koristi se MD5 algoritam, a saobraaj je enkriptovan pomou DES algoritma. Passphrase koji se koristi prilikom enkripcije je john5678.

Peta komanda korisniku john daje read only (rouser) privilegije i to samo nad mojpogled pogledom na MIB bazu koji je definasn u treoj komandi.

Nakon editovanja snmp konfiguracionih fajlova potrebno je restartovati servis da bi se primenile izmene koje su uneene u te fajlove.

Mana ovakog konfigurisanja je to se vrednosti koje su uneene u konfiguracione fajlove uvaju u istom tekstu.

Komanda za restart je:

1. service snmpd restart

Provera podeavanja SNMP v3 na serveru je mogua pomou komande:

2. snmpwalk -v 3 -u john -l authPriv -a MD5 -A john1234 -x DES -X john5678 192.168.1.1

29

6.6.2.3 Konfiguracija SNMP protokola pomou Perl skripte

Uz net-snmp paket se automatski instaliraju i Perl skripte koje omoguuju osnovna podeavanja SNMP agenta. Tri skripte koje omoguuju konfigurasanje SNMP agenta se zovu snmpconf, snmpusm i net-snmp-conf. Prva skripta omoguuje interaktivnu konfiguraciju osnovnih funkcija SNMP agenta dok se druga i trea skripta mogu koristiti za kreiranje SNMP v3 korisnika.

Prednost konfigurisanja pomou perl skripti je to se posle restarta servisa osetljivi parametri uvaju u enkriptovanom obliku. Ovo je preporuen princip konfigurisanja snmp agenta.

Podeavanja SNMP agenta su mogua na dva naina. Manuelnim editovanjem konfiguracionih fajlova snmpd.conf i snmptrapd.conf (kao u glavi 6.2.2.2) ili pomou Perl skripti. Sve detaljne informacije o net-snmp paketu se mogu nai na http://net-snmp.sourceforge.net sajtu.

30

7 uvanje sistemskih logova (syslog)

7.1 SysLog protokol

SysLog protokol je razvijen kao mehanizam za sakupljanje informacija o promenama i dogaajima u Unix operativnim sistemima i jedna od veoma korisnih osobina mu je bila mogunost slanja tih poruka preko mree. Time se omoguilo prikupljanje poruka na centralnom serveru, a samim tim i lake i bre otkrivanje i reavanje problema. SysLog koristi UDP protokol (port 514) na transportnom sloju a na aplikativnom sloju ne postoji mehanizam koji bi obezbedio informaciju o tome da li je poruka ispravno preneta do odredita, tako da je svrstan u klasu nesigurnih protokola. I pored ovih mana SysLog predstavlja jedan od esto korienih protokola za sakupljanje informacija o stanju sistema.

Format poruka nosi sledee informacije koje opisuju stanje sistema.

Facility - Identifikuje objekat koji je generisao poruku. To moe biti operativni sistem , proces ili neka aplikacija. Facility se predstavlja celobrojnom vrednou i vrednosti od 0 do 15 su rezervisane za Unix operaivne sisteme dok su vrednosti od 16 do 23 tradicionalno predviene za mrene ureaje (rutere, svieve).

U tabeli 7.1.1 je dat prikaz Facility vrednosti.

Integer Facility 0 Kernel messages 1 User-level messages2 Mail system 3 System daemons 4 Security/authorization messages5 Messages generated internally by SysLogd6 Line printer subsystem 7 Network news subsystem 8 UUCP subsystem 9 Clock daemon 10 Security/authorization messages 11 FTP daemon12 NTP subsystem 13 Log audit

31

14 Log alert 15 Clock daemon16 Local use 0 (local0) 17 Local use 1 (local1) 18 Local use 2 (local2) 19 Local use 3 (local3) 20 Local use 4 (local4) 21 Local use 5 (local5) 22 Local use 6 (local6) 23 Local use 7 (local7)

Tabela 7.1.1 Facility vrednosti

Severity - Moe uzimati jednu od osam celbrojnih vrednosti i one opisuju trenutnu teinu problema.

Mogue vrednosti su date u tabeli 7.1.2.:

Integer Severity 0 Emergency: System is unusable. 1 Alert: Action must be taken immediately.2 Critical: Critical conditions. 3 Error: Error conditions. 4 Warning: Warning conditions. 5 Notice: Normal but significant condition. 6 Informational: Informational messages.7 Debug: Debug-level messages.

Tabela 7.1.2 Severity vrednosti

Hostname Sadri IP adresu ureaja koji alje SysLog podatke i to obino IP adresu interfejsa sa koga se poruke alju.

Timestamp Informacija o vremenu kada je SysLog poruka generisana. Preporuuje se da se koristi NTP protokol kako bi postojala ispravna vremenska sinhronizacija na ureajima. Veoma je bitno da postoji taan vremenski redosled izmeu svih SysLog poruka.

Message Sadri SysLog poruku koju je generisao ureaj kao i jo neke dodatne informacije o procesu koji je generisao poruku.

7.2 Lokacija syslog servera

esta je situacija da se aplikacija koja sakuplja syslog instalira na serveru koji prikuplja SNMP podatke. To je jednostavno i prihvatljivo reenje za sisteme ako server ima dobre performanse i moe da izdri istovremenu obradu SNMP i SysLog podataka. Kritina taka je rad baze u kojoj se obino uvaju te poruke. Ogroman broj generisanih syslog poruka e dovesti do estog upisa u bazu a samim tim i est upis na hard disku. Tako da se ispravnim izborom hardwer-ske konfiguracije moe izvriti razdvajanje baza na razlicite hard diskove i dobijanje na performansama. Drugo reenje, u sluaju velikog exporta SysLog poruka, je da se odvoji poseban server samo za SysLog aplikaciju.

32

Za poziciju SysLog servera u mrei vae iste preporuke koje su definisane za NMS server.

7.3 Instalacija

Pre pokretanja SysLog servisa u mrei veoma je bitno ispravno pokrenuti vremensku sinhronizaciju na mrenim ureajima i na samom SysLog serveru. Ovo je bitno uraditi da bi poruke bile sauvane u tanom vremenskom redosledu u bazi SysLog kolektora. Preporueno je da se eksportuju sve SysLog poruke a da se filtriranjem izdvajaju najbitnije, eventualno podesiti da se eksportuju SysLog poruke koje se vezane samo za pojedine bitne funkcije ureaja ili bitnih servisa. Pokretanje SysLog agenta na pojedinim ureajima je prikazano u daljem tekstu.

7.3.1 Mreni ureaji

Pokretanje SysLog agenta na ruterima i svievima je objanjeno na Cisco ureajima.

SysLog servis se pokree pomou sledeih komandi.

1. ABC(config)#logging on

2. ABC(config)#logging host 10.10.5.1

3. ABC(config)#logging trap informational

4. ABC(config)#logging source-interface Loopback0

5. ABC(config)#logging buffered 100000

6. ABC(config)#logging buffered debug

7. ABC(config)#logging monitor informational

8. ABC(config)#no logging console

Pomou prve komande se pokree logovanje podataka. Druga komanda definie IP adresu SysLog servera (kolektora) na koji e se vriti eksport podataka.

Trea komanda definie do kog nivoa kriticnosti e se poruke eksportovati na server. Informational predstavlja level 6 to znai da e se skupljati sve poruke od kritinosti 0 do kritinosti 5.

etvrta komanda definie source adresu koja e se javljati u loggovima i preporueno je postaviti loopback adresu poto je ona uvek aktivna. U sluaju da je SysLog server nedostupan ili da elimo direktno na ureaju da oitamo poruke preporuuje se da se odvojiti sistemska memorija u kojoj e se uvati ove poruke.

Peta komanda definie veliinu bafera u bajtima.

esta komanda omoguuje logovanje debug komandi.

33

Sedma komanda definie nivo kritinosti za terminalne linije dok se u poslednjoj komandi iskljuuje slanje logova na konzolnu liniju.

7.3.2 Serveri

7.3.2.1 Windows

Windows operatini sistemi nemaju instaliranog SysLog agenta ve se oslanjaju na svog agenta koji se zove Event Logger. U sluaju da elimo da skupljamo SysLog podatke, koje generie server sa Windows platformom, potrebno je da instaliramo posebnog SysLog agenta koji e prevoditi poruke koje je generisao Event Logger u SysLog format i slati takve poruke na udaljeni SysLog server. Dve besplatne verzije ovakvih agenata se mogu preuzeti sa sledeeg sajta https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys/ i http://ntsyslog.sourceforge.net/.

7.3.2.2 LINUX

Prilikom instalacije Linux OS automatski se instalira i SysLog agent. Agent je prekonfigurisan tako da sve poruke koje generie sistem on sakuplja u fajlove koji se nalaze u /var/log/ direktorijumu. U sluaju da elimo da podesimo Facility i Severity parametre pojedinih delova sistema, kao i lokaciju gde e poruke biti sauvane (lokalni fajl ili udaljeni server), potrebno je editovati i konfiguristai fajl /etc/syslog.conf.

Primer fajla /etc/syslog.conf je dat u daljem tekstu:

*.info;mail.none;authpriv.none;cron.none /var/log/messages

authpriv.* /var/log/secure

mail.* -/var/log/maillog

cron.* /var/log/cron

*.emerg *

local7.* /var/log/boot.log

Iz prve komande se vidi da e se sve poruke iji je Severity vei ili jednak vrednosti info (informational), osim poruka iji je Facility mail, authpriv ili cron, biti eksportovane u folder /var/log/messages. Druga komanda eksportuje sve poruke iji je Facility jednak authpriv i one e se eksportovati u folder /var/log/secure.

Trea komande eksportuje poruke iji je Facility jednak cron a Severity moe uzimati sve mogue vrednosti i poruke se eksportuju u folder -/var/log/maillog.

etvrta komanda eksportuje sve poruke iji je Severity jednak Emergency i to na konzolu svih ulogovanih korisnika.

Peta komanda eksportuje sve poruke iji je Facility jednak local7 u folder /var/log/boot.log.

34

U sluaju da elimo da eksportujemo poruke na udaljeni centralizovani SysLog server (192.168.1.1) u konfiguracioni fajl /etc/syslog.conf potrebno je dodati sledeu komandu:

*.* @192.168.1.1

Pomou ove komande se eksportuju sve poruke na udaljeni SySlog kolektor. Na kraju je potrebno restartovati SysLog agenta pomou sledee komande:

service syslog restart

U sluaju da elimo da sakupljamo SysLog poruke neke aplikacije koja radi na Linux serveru potrebno je podesiti aplikaciju tako da eksportuje svoje logove na bilo koji lokalni Facility, a u syslog.conf fajlu podesiti opciju tako da SysLog agent eksportuje taj lokalni Facility na udaljeni SysLog server.

Preporuuje se istovremeno uvanje logova i u fajlovima, tako da u sluaju ako je centralni SysLog server nedostupan, administrator moe imati uvid u promene na serveru koje je SysLog registrovao.

U sluaju da na serveru postoji pokrenut proces koji generie dosta poruka fajlovi e se dosta brzo popunjavati i zauzimati memoriju. U tom sluaju je potrebno pokrenuti logrotate opciju koja uva fajlove odreeni vremenski period a onda ih brie.

Ove komande se zadaju u konfiguracionom fajlu /etc/logrotate.conf. Definie se vremenski period, kompresija, privilegije, i veliina fajlova.

Na Linux platformama se danas esto koristi novija verzija SysLoga pod nazivom rsyslog. Ova verzija SysLoga je poboljana u odnosu na standardni syslog ali se ne nalazi kao standardni paket u svim distribucijama Linuxa.

Standardni SysLog agent se takoe moe konfigurisati tako da prima poruke od drugih ureaja i ponaa se kao kolektor SysLog poruka. Jedan od dostupnih kolektora SysLog poruka koji radi na Linux operativnim sistemima se moe skinuti sa sledeeg sajta http://code.google.com/p/php-syslog-ng/downloads/list.

35

8 Protokol za analizu saobraaja

U dananjim mreama je veoma bitno vriti analizu/inspekciju saobraaja, ne samo do L2 nivoa (SNMP - Broj prenetih bajtova/paketa na interfejsu ureaja) ve i na L3 i L4 nivou. Na taj nain se stie uvid u prirodu saobraaja kao i servise koji se najvie koriste (optereuju mreu), a i prua informacija o koliini prenetog saobraaja.

8.1 NetFlow protokol

Primer protokola koji se danas najee koristi za prikupljanje statistike je Netflow protokol koji je razvila Cisco kompanija. Danas se u praksi najee sreu dve verzije Netflow protokola, verzija 5 i verzija 9. Za razliku od verzije 5 verzija 9 nudi fleksibilni format poruka kao i podrku za MPLS i IPV6. Kod ostalih proizvoaa se takoe moe nai ovaj protokol samo pod drugim nazivom (Juniper-Jflow, Huawei-NetStream). Sve ove varijante NetFlow protokola su meusobno kompatibilne. Na slici 8.1 je dat format NetFlow V5 poruke.

Slika 8.1 - Primer NetFlow V5 formata poruke

Usled potrebe za univerzalnim standrardom, od strane IETF organizacije definisan je IPFIX protokol kao univerzalni protokol za eksport prikupljene statistike saobraaja.

36

8.2 Princip rada sistema

Kada se na ureaju pokrene NetFlow protokol, poinje da se prikuplja statistika za sav saobraaj koji prolazi kroz ureaj. Statistika se zatim periodino eksportuje ka serveru (kolektoru) gde je pokrenuta aplikacija koja prima i vri obradu tih podataka prema zadatim kriterijumima. Kao rezultat analize se obino prikazuju grafici i tabele sa rezultatima i iz njih se lako mogu uvideti problemi koji su se javili. Kod nekih aplikacija postoji mogunost automatskog detektovanja problema (napada) u mrei.

Rezultati ovakve analize nam pruaju sledee informacije:

Informacije o ukupnom prenetom saobraaju izmedu pojedinih subneta. (Bytes, Packets, Flows) Informacije o ukupnom prenetom In/Out saobraaju na pojedinim interfejsima eksportera. Informacije o ukupnom prenetom saobraaju na nivou protokola, servisa, hosta. Informacije o hostovima kojima se pristupalo iz spoljane mree. Detekcija odbaenog saobraaja (Saobraaj koji su odbacile ACL, Loe rutiranje..). Predikciju ponaanja saobraaja u budunosti.

Na ovaj nain se mogu detektovati:

Pojava Virusa u mrei. (Velika koliina saobraaja se generie u OUT smeru, ili ka DNS ili MAIL serverima)

Pojava DoS napada. Zloupotreba protoka. (youtube, facebook, torrent.) Pristup zabranjenim sajtovima. Pokuaji napada/pristupa zatienim mrenim ureajima. Pronalazak otvorenih portova u mrei. Top Talker korisnici.

8.3 Lokacija kolektora u mrei

Lokacija kolektora koji prikuplja NetFlow statistiku zavisi od same arhitekture mree. Koliina NetFlow podataka koju mreni ureaji eksportuju direktno zavisi od koliine saobraaja koja prolazi kroz taj ureaj (eksporter). Empirijski se pokazuje da procenat NetFlow saobraaja ne prelazi 1% od ukupnog saobraaja u mrei, tako da ne postoji problem udaljenosti servera (kolektora) od mrenog ureaja koji eksportuje podatke (eksportera). Bitniji parametri su dostupnost i sigurnost servera. Fizika lokacija servera se obino vezuje za centralno vorite zato to veina glavnog sobraaja prolazi kroz njega. Preporuuje se postavljanje servera u odvojeni Vlan (Menadment Vlan) i postavljanje zatite u vidu firewall-a na server. U sluaju otkaza pojedinih mrenih ureaja bitno je da NetFlow server bude dostupan za prikupljanje i analizu saobraaja.

37

8.4 Konfigurisanje NetFlow eksportera

Konfigurisanje eksporta NetFlow statistike na ureajima zavisi od karakteristika samih ureaja ali i od arhitekture mree. Na slici 8.2 je dat primer nepravilnog konfigurisanja NetFlow eksporta.

Slika 8.2 - Nepravilno konfigurisan eksport NetFlow statistike

Na slici se vidi da je na interfejsima Gi1/1 i Gi1/2 konfigurisano prikupljanje Netflow statistike i to na Gi1/1 interfejsu u IN smeru a na Gi1/2 interfejsu u OUT smeru. Sa slike se vidi da e jedan flow, koji prolazi od take A do take B, biti dva puta obraen i eksportovan ka NetFlow kolektoru. U drugom sluaju komunikacija od take B do take A nee biti obuhvaena statistikom. Usled toga e se dobiti pogrena informacija o ovom saobraaju (duplirae se vrednosti i to samo u jednom smeru). Obino na ureajima postoji mogunost eksporta NetFlow statistike koju je mogue podeavati na nivou interfejsa, i to u jednom od dva smera, ulaznom (in/ingress) smeru ili izlaznom (out/egress) smeru. Neki ureaji imaju mogunost eksporta i u ulaznom i u izlaznom smeru istovremeno. Na slici 2.2 je dat prikaz ispravno konfigurisanog eksporta na centralnom ureaju. Na interfejsima Gi1/1 i Gi1/2 je konfigurisan netflow eksport samo u IN smeru.

Slika 8.3 - Ispravno podeen NetFlow eksport

Sada e se eksportovati informacija o saobraaju u smeru od teke A do take B (Eksport sa Gi1/1 interfejsa koji se vri za saobraaj u IN smeru) i eksportovae se informacija od hosta B do hosta A (Eksport sa Gi1/2 interfejsa koji se vri za saobraaj u IN smeru). U ovom sluaju nema dupliranja eksportovane statistike. Sa ove slike se vidi da je mogue pokrenuti NetFlow eksport na centralnom ureaju i na taj nain pokriti celu mreu. Sav saobraaj koji proe kroz centralni ruter e biti eksportovan ka NetFlow kolektoru. Jedini saobraaj koji se nee detektovati je onaj koji ne prolazi kroz centralni ruter. Na slici 2.3 je dat primer situacije kada se statistika o jedom delu saobraaja ne eksportuje.

8.5 Indirektna reenja prikupljanje NetFlow statistike

Podrka za NetFlow protokol je obino implementirana u ruterske platforme. Veina svieva ne podrava netflow protokol, osim pojedinih L3 svieva (cisco6500, cisco4500...).

38

U sluaju kada se javlja potreba za analizom saobraaja, a sami mreni ureaji ne podravaju NetFlow protokol, mogue je na indirektan nain sakupiti te informacije.

Na slici 8.4 je prikazana ovakva situacija.

Slika 8.4 - Preusmeravanje saobraaja ka NetFlow-deamon serveru

Slika 8.5 - Detaljniji prikaz postavljanja servera i povezivanja (Port Mirroring) portova

Na slikama 8.4 i 8.5 se vidi da je izvreno preusmeravanje saobraaja (port mirroring) ka serveru gde je pokrenut NetFlow deamon. Kada se pokrene port mirroring na sviu, interfejs ka kome se sav saobraaj prosleuje postaje neupotrebljiv za normalnu komunikaciju izmeu ureaja. On samo prosleduje sav saobraaj (IN/OUT) sa interfejsa sa kim je uraen port mirroring. Problem je kako eksportovati statistiku ako je interfejs na koji je povezan server sa NetFlow-demonom neupotrebljiv za normalnu komunikaciju. Reenje je dodavanje jo jedne mrene kartice na server i njeno povezivanje na svi. Na slici 8.5 je plavom strelicom prikazan eksport NetFlow statistike sa druge mrene kartice sa servera. Ovakvom konfiguracijom je omogueno da se vri eksport NetFlow statistike i sa L2 ureaja. Mana je dodatno zauzimanje portova na sviu i potreba za dodatnim serverom. Jedan port na sviu se koristi za primanje kopiranog (mirrored ) IN/OUT saobraaja a drugi za slanje NetFlow statistike. Sada se na serveru moe pokrenuti aplikacija koja vri netflow analizu prikupljenog saobraaja. Jedan od alata za kreiranje Netflow statistike, IN/OUT saobraaja na serveru, je softflow aplikacija. Ona ima mogunost da eksportuje statistiku lokalno (127.0.0.1) ka kolektoru na samom serveru ili ka kolektoru na udaljenom serveru. Na slikama 8.6 i 8.7 su prikazani primeri kada se Netflow statistika eksportuje lokalno i kada se eksportuje na udaljenu lokaciju gde se nalazi NetFlow kolektor.

39

Slika 8.6 Primer kada se NetFlow statistika eksportuje NetFlow kolektoru lokalno

Slika 8.7 Primer kada se Netflow statistika eksportuje na udaljeni server gde se nalazi NetFlow kolektor

Na ovaj nain je mogue izvriti prikupljanje NetFlow statistike i u situacijama kada ureeaji ne podravaju NetFlow protokol.

40

Reference

[1] http://www.net-snmp.org/ [2] http://www.mindrot.org/projects/softflowd/ [3] http://www.cisco.com/en/US/docs/ios/solutions_docs/netflow/nfwhite.html [4] RFC-1901-1908, SNMP v2c [5] RFC-3411-3418, SNMP v3 [6] Mauro D., Schmidt K.(July 2001), Essential SNMP. [7] CentOS SNMP and Syslog manuals

41

Renik

ACL Access List AES Advanced Encryption Standard CLI Command Line Interface CPU Central Processing Unit DES Data Encryption Standard DNS Domain Name System DoS Denial of Service FTP File Transfer Protocol HMAC-MD5 Hashed Message Authentication Code, Message Digest 5 HMAC-SHA Hashed Message Authentication Code, Secure Hash Algorithm HTTP HyperText Transfer Protocol HTTPS HyperText Transfer Protocol Secure IP Internet Protocol IPFIX Internet Protocol Flow Infromation Export IPv6 Internet Protocol version 6 MIB Management Information Base MPLS Multiprotocol Label Switching NAT Network Address Translation NETFLOW Cisco Proprietary Protocol NMS Network Management System NTP Network Time Protocol OID Object Identifier OOBM Out of Band Management RCP Remote Copy Protocol RDP Remote Desktop Protocol RFB Remote Frame Buffering SCP Secure Copy SNMP Simple Network Management Protocol SSH Secure Shell SSL Secure Socket Layer SYSLOG System Logger TCP Transmission Control Protocol TFTP Trivial File Transfer Protocol TLS Transport Layer Security UPS Uninterruptible Power Supply VLAN Virtual Local Area Network

42

VNC Virtual Network Computing VPN Virtual Private Network