Ovaj dokument sadrži preporuke za pripremu, sa aspekta povećanja sigurnosti, mrežnog okruženja u kome se uspostavlja bilo koji odabrani alat za nadzor i upravljanje mrežom (NMS alat).

Cilj dokumenta je da pruži uvid u osnovne NMS aktivnosti, zajedno s preporukama za administratore kampus i/ili lokalnih mreža koji planiraju da primene NMS alat unutar svojih mreža.

Dokument počinje razmatranjem topologije mreže. Promene u topologiji su predložene u skladu sa idejom da bi većina NMS aktivnosti trebalo da se odvijaju kroz menadžment segment mreže. Dve alternative su razmatrane. Menadžment mreža i produkciona mreža mogu biti fizički odvojene mreže (out-band management segment) ili mogu da dele istu fiziču infrastrukturu (VLAN segment mreže).

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 načešće korištene portokole za upravljanje i njihovu upotrebu u različitim okruženjima i na različitim tipovima uređaja u mreži (tj. mrežni uređaji, serveri, UPS uređaji, A/C), uz uslov da ne ugrožavaju sigurost mreže.

Razvoj mrežnih uređaja i novih kompleksnih protokola doveo je do toga da se današnji mrežni sistemi ne mogu održavati bez dobrog sistema za nadzor, kontrolu i konfigurisanje mreže. Pod sistemom se podrazumeva ne samo skup protokola koji se koristi za menadžment već i sama arhitektura menadžment mreže.

Cilj ovog dokumenta su preporuke administratorima Campus i/ili lokalnih mreža koji planiraju implementaciju menadžment softverskih paketa. U ovom dokumentu su preporučene tehinke i tehnologije koje treba da se primene u prilagođavanju mreže u cilju uspešne implementacije menadžment alata. Takođe, date su preporuke implementacije menadžment protokola i podešavanja softverskih alata za različita okruženja i potrebe.

In-band menadžment podrazumeva da se za svrhu menadžmenta koriste intefjesi i mrežna oprema koja se ujedno koristi i za produkcioni saobraćaj. Out-of-band menadžment podrazumeva korišcenje zasebne mrežne infrastrukture i zasebnih intefejsa za svrhu menadžmenta u odnosu na mrežne uređaje i interfejse uređaja koji se koriste za produkcioni saobraćaj. Out-of-band menadžment se preporučuje za mreže ili delove mreža koje su koncipirane tako da se mrežna oprema i serveri nalaze u jednoj prostoriji (mašinskoj sali / server sobi / jednom čvorištu).

In-band okruženje
Prednosti:

• Ne zahteva dodatnu fizičku infrastrukturu (mrežne intefejse na serverima, zasebne mrežne uređaje, pasivnu infrastrukturu).

Mane:

• Menadžment saobraćaj koji predstavlja “osetljiv” sadržaj, prolazi kroz istu infrastrukturu kao i produkcioni saobraćaj, odnosno, saobraćaj ka krajnjim korisnicima;
• U slučaju zagušenja (u normalnom radu, ili usled nekog Denial of Service napada), otežan je (možda i onemogućen) pristup uređajima radi intervencija koje bi pomogle eliminisanju problema.

Out-of-band okruženje
Prednosti:

• Izvojena fizička infrastruktura za menadžment saobraćaj
• Omogućen pristup i u slučaju problema na produkcionim linkovima
• Veća sigurnost “osetljivih” menadžment informacija

Mane:

• Potrebna dodatna mrežna infrastruktura
• Zahveta veće inicijalno angažovanje administratorskog osoblja i troškove za implementaciju

Jedan od ključnih elemenata u organizaciji mreže jeste logička segmentacija mreže. Ovo se postiže definisanjem radnih grupa i kreiranjem VLAN-ova za svaku od grupa. Ono što je nužno definisati jeste i VLAN za svrhu menadžmenta:

• VLAN-MGMT - VLAN za menadžment. Iako je uobičajeno da taj VLAN bude VLAN 1, zbog povećanja sigurnosti (o čemu će biti više reči u BPD-u o sigurnosti u campus mrežama), preporučuje se da se za svrhu menadžmenta definiše neki drugi VLAN, kroz koji će prolaziti samo menadžment saobraćaj. Preporuka je da svi mrežni uređaji imaju vezu sa VLAN-MGMT da bi se ista mogla koristiti u svrhu menadžmenta samih uređaja. Kada su u pitanju serveri, u situacijama u kojima serveri imaju minimalno dva mrežna interfejsa, preporučuje se da jedan interfejs predstavlja vezu sa VLAN-MGMT.
• VLAN-SERVER-ENT - VLAN za enterprise servere (DNS, proxy, e-mail, web …)
• VLAN-SERVER-WRKGRP - VLAN za workgroup servere (razni aplikativni serveri, serveri baza podataka i sl.)
• VLAN-ADMIN - Administratorski VLAN
• VLAN-USER-<workgroup> - Korisnički VLAN-ovi u zavisnosti od radne grupe

Potrebno je razmotriti koje mogućnosti su nam raspoložive za pristup različitim tipovima uređaja, kao i preporuke za primenu pojedinih rešenja u zavisnosti od topologije mreže. Definisane su tri grupe uređaja:

• Mrežni uređaji - ruteri, layer2 i layer3 svičevi
• Serveri
• Ostali uređaji - UPS, klima uređaji, štampači i sl.

Pristup mrežnim uređajima se može obaviti na neki od sledećih načina:

• Console port - pristup korišćenjem ovog porta predstavlja pristup interfejsu komandne linije (Command Line Interface - CLI). Ovakav vid pristupa uređaju ne zahteva komunikaciju kroz mrežu već se zahteva direktna veza serijskog (COM) porta računara sa kojim se pristupa uređaju i samog Console porta. Pristup uređajima putem Console porta se koristi za inicijalane konfiguracije uređaja, resetovanje šifara za pristup, kao i za situacije kada uređaju nije moguće prići putem mrežnih intefejsa. Pristup se obavlja korišćenjem nekog od softvera za terminalni pristup (Hyper Terminal, Putty, SecureCRT itd.)
• AUX - predstavlja port koji se može iskoristiti za udaljeno povezivanje na uređaj korišcenjem dial-in veze. Kako ovaj dokument predstavlja preporuke za kampus i lokalne mreže, nema ozbiljnih situacija u kojima bi implementacija ovog rešenja za pristup bila opravdana.
• OOBM - pojedini proizvođači mrežne opreme ugrađuju out-of-band menadžment portove kojima se dodeljuje IP adresa i omogućava pristup kao i bilo kom mrežnom interfejsu, ali je ograničen pristup na podržane menadžment protokole (telnet, ssh, http…)
• Zaseban ethernet intefejs - Kada su u pitanju mrežni uređaji, izdvajanje zasebnog mrežnog intefejsa samo za namenu menadžmenta nije uobičajeno (može se reći i nije preporučljivo) obzirom da je cena “po interfejsu” na ruterima značajno velika. Kada su u pitanju svičevi sa velikim brojem portova, izdvajanje zasebnog interfejsa jeste preporučljivo rešenje, ali samo u okviru data centra, odnosno, ukoliko nije potrebno postavljanje dodatne pasivne infrastrukture (troškovi OOBM-a, pogledati poglavlje 2.)
• VLAN-MGMT pristup - Pristup mrežnim uređajima kroz logilčko odvajanje saobraćaja u zaseban VLAN za menadžment je preporučljivo, jer je za implementaciju potrebno izvršiti samo konfiguraciju postojeće aktivne opreme. Po uređajima, konfiguracija se svodi na sledeće:
  • Svičevi - sve veze izmedu svičeva treba da se nalaze u modu za prenos više VLAN-ova (trunk mod kod Cisco svičeva, tagging mod kod ostalih proizvođača, generalno IEEE 802.1Q standard). Kroz taj link je potrebno “propustiti” i menadžment VLAN (VLAN-MGMT).
  • Ruteri - na ruterima je potrebno definisati podinterfejse (subinterface) sa IP adresom iz opsega definisanog za menadžment VLAN.

Kada se konfiguriše obeležavanje frejmova (802.1Q), Cisco uređaji (možda još neki proizvođač) prekonfigurisano šalju frejmove iz VLAN1 kao 802.3 frejmove, odnosno šalju ih neobeležene. Kod drugih proizvođača, potrebno je definisati koji se VLAN šalje kao neobeležen (untagged). Radi povećanja sigurnosti preporuka je da se, ukoliko je to na uređajima moguće konfigurisati, saobraćaj za sve VLAN-ove šalje obeležen. Ukoliko na nekim uređajima nije moguće slati sve VLAN-ove obeležene, preporuka je da se definiše VLAN koji će biti izolovan od ostatka mreže (black-hole) i da se saobraćaj ovog VLAN-a šalje kao neobeležen.

Pristup serverima u svrhu menadžmenta se može ostvariti na neki od sledećih načina:

• KVM svič - uobičajeno je da su serveri locirani na jednom mestu, rek ormanima, na stolovima u serverskoj sali i sl. Praksa da bi se olakšao pritup samim serverima jeste da se koriti KVM svič koji omogućava vezu keyboard-video-mouse priključaka svih servera sa jednim fizičkim setom ovih komponenti (tastatura, monitor, miš). Menadžment servera se na ovaj način može vršiti samo ukoliko se administrator fizički nalazi u serverskoj sali gde se nalazi i KVM svič.
• OOBM - poznatiji proizvođači u servere ugrađuju i port za out-of-band menadžment. Ovaj port predstavlja još jedan mrežni interfejs, ali ima specijalnu namenu.

Prednosti:

• Ovaj port ima zaseban kontroler na matičnoj ploči i omogućava TCP/IP pristup serveru nezavisno od operativnog sistema na serveru. Ovim je omogućeno da se udaljeno ima pregled dešavanja na samom serveru kao da je u pitanju direktan pristup serveru (tastatura-monitor-miš), uključujući i sam proces startovanja servera (booting process)
• Udaljeni pristup BIOS-u podešavanjima servera
• Udaljena kontrola - uključivanje, isključivanje i restart servera

Mane:

• U zavisnosti od proizvođača, razlikuje se implementacija ovog rešenja - ne postoji uniformno rešenje
• U osnovnoj (besplatnoj) verziji pristupa serveru po ovom portu, limitirane su funkcionalnosti. Za širi set funkionalnosti, kod pojedinih proizvođača, potrebno je platiti licence.
• Mrežni intefejs (zaseban obavezan/ili ne/) - preporuka je da serveri imaju najmanje dva mrežna interfejsa, što je uobičajen slučaj sa serverima koji su danas u prodaji. Sa druge strane, nije neuobičajeno da se za serverske funkcije koriste klijentski računari boljih performansi koji imaju samo jedan mrežni interfejs. Pristup serverima u ovim različitim okolnostima tretiramo na sledeći način:

Serveri sa najmanje dva mrežna interfejsa

• Preporuka je da se jedan od interfejsa servera konfiguriše kao menadžment interfejs, odnosno da se nalazi u mreži za menadžment (OOB deo mreže ili menadžment VLAN). Drugi (ostali) interfejsi servera ne bi trebali da se koriste za svrhu menadžmenta.
• Drugi (ostali) interfejsi servera se koriste za produkcioni pristup servisima koje server nudi.

Serveri koji imaju jedan mrežni interfejs

• Kako je kod ovih servera nemoguće fizički odvojiti menadžment saobraćaj od produkcijskog, preporučuju se dva pristupa u zavisnosti od hardvera. Pri bilo kom od ovih pristupa, preporučuje se korišćenje protokola za pristup koji kriptuju saobraćaj.
• Ukoliko mrežna kartica podržava IEEE 802.1Q standard, preporučuje se da se na samoj kartici definišu logički interfejsi koji se pridružuju različitim VLAN-ovima, uključujući i jedan logicki interfejs pridružen menadžment VLAN-u.
• Ukoliko mrežna kartica ne podržava IEEE 802.1Q standard, tada ni logički nije moguće odvojiti menadžment saobraćaj od produkcionog.

Pod grupom ostali uređaji, definišemo sve uređaje kojima primarna namena nema potrebe za mrežnom komunikacijom. Pristup radi menadžmenta se obavlja preko sledećih intefejsa:

• Serijski port - menadžment korišćenjem serijskog porta na uređajima se obavlja koristeći namenski softver proizvođača. Uobičajeno je da ukoliko postoji i eternet port uređaja, serijski port služi samo za inicijalna podešavanja IP parametara radi prelaska na pristup po eternet portu.
• Mrežni interfejs - poznatiji proizvođači u paleti proizvoda imaju i kartice sa mrežnim interfejsom koje se ugrađuju u njihove uređaje za svrhu menadžmenta.

Za definisanje načina pritupa menadžment mreži potrebno je definisati:

• IP adresiranje uređaja u menadžment mreži
• Metode pristupa menadžment mreži

Radi povećanja sigurnosti menadžment delova mreže, preporučuje se da se za te delove mreže definišu zasebni IP adresni opsezi. Ovo važi za out-of-band menadžment mrežu, kao i za menadžment VLAN segment. Ovi opsezi adresa ne bi trebalo da se oglašavaju (rutiraju) ostatku mreže. Za uredaje za koje postoji potreba da komuniciraju sa drugim uređajima i van menadžment dela mreže, kao što je to slučaj sa NMS serverom, preporučuje se korišćenje funkcije NAT-a na nekom uređaju trećeg sloja (layer 3 - L3) na kome bi se takođe primenila sigurnosna politika prolaska saobraćaja ka menadžment delovima mreže.

Potrebno je definisati metode pristupa menadžment delovima mreže u različitim okruženjima i situacijama. Ovde smo definisali tri metode pristupa: Pristup uređajima iz menadžment dela mreže:

• Za ovaj vid pristupa potrebno je da u menadžment delu mreže postoji računar (host) čiji je jedini mrežni interfejs priključen u samu menadžment mrežu.
• Ovom računaru je dozvoljen pristup samo u okviru menadžmenta dela mreže.

Pristup uređajima iz administratorskog VLAN segmenta:

• Korišćenje NAT funkionalnosti za administratorske računare koji prilaze uređajima u menadžment delu mreže
• Adrese u koje se transliraju administratorski računari su iz adresnog opsega menadžment dela mreže. Na ovaj način se postiže efekat pristupa iz same menadžment mreže

Pristup uređajima sa udaljenih lokacija:

• Obavezno korišcenje VPN tehnologije za pristup
• Kao i za pristup iz administratorskog VLAN segmenta i ovde se primenjuje funkcija NAT-a po istom modelu

Na slici 4-1 je prikazan sveobuhvatni primer topologije menadžment mreže. Ovaj primer topologije obuhvata:

• Out-of-band menadžment mrežu
• Tri metoda pristupa menadžment mreži (racunar u OOBM-u, pristup iz administratorskog VLAN-a, udaljeni pristup kroz VPN)
• Pristup menadžment VLAN mreži iz OOBM mreže
• Veze mrežnih uredaja sa OOBM mrežom korišcenjem console porta, specijalizovanog OOBM porta
• Veza mrežnih uredaja sa menadžment mrežom kroz menadžment VLAN
• Dodatni intefejs servera za vezu sa OOBM ili menadžment VLAN delom mreže
• Veze ostalih uređaja sa OOBM ili menadžment VLAN delom mreže
• Pozicije menadžment servera i veze sa menadžment delom mreže, kao i sa ostatkom mreže u slučaju monitoring sistema.
  

Na slici 4-2 je prikazan primer segmentacije mreže i veze uređaja sa menadžment VLAN-om.

Nakon definisanih načina fizičkog pristupa uređajima, potrebno je definisati i komunikacione protokole koji se preporučuju za korišcenje u različitim okolnostima. Prvo su dati opisi protokola sa osnovnim karakteristikama a zatim su preporučena korišćenja zasebno za tipove uređaja sa kojima se komunicira.
TTY - Karakteristike:

• Protokol za asinhronu serijsku komunikaciju. Koristi se u komunikaciji sa Console portom mrežnih uređaja.

Telnet - Karakteristike:

• Omogućava pristup komandnoj liniji (Command Line Interface - CLI)
• Protokol je podržan na gotovo svim uređajima
• Komunikacija između telnet klijenta (uređaja sa kojeg se pristupa) i telnet servera (uređaja kojem se pristupa) se obavlja u ne-enkriptovanom modu (clear text) što je glavna ključna mana ovog protokola.

SSH (Secure Shell) - Karakteristike:

• Omogućava pristup komandnoj liniji (vizuelno, identican Telnet protokolu)
• Komunikacija između SSH klijenta i SSH servera se obavlja u enkriptovanom obliku, zbog čega se preporučuje za primenu umesto Telnet protokola gde god je to moguće
• Za podršku ovom protokolu uređaji moraju imati softversku podršku za kriptovanje

RDP (Remote Desktop Protocol) - Karakteristike:

• Omogućava grafički pristup (pristup desktopu) serveru
• 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 može podesiti na RDP serveru (windows server platforme). Koristi se algoritam RSA RC4, koji ima svoje nedostatke i ne može se okarakterisati kao potpuno siguran.
• Korišćenje se preporučuje kroz VPN mreže

VNC (Virtual Network Computing) - Karakteristike:

• U pitanju je aplikacija bazirana na RFB protokolu (Remote FrameBuffering)
• Kao i RDP, omogućava grafički 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 podržava nikakve mehanizme enkriptovanja saobraćaja.
• Korišćenje se preporučuje kroz VPN mreže

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

• Omogućava web pristup uredajima
• U osnovnoj varijanti ne podržava enkripciju. HTTPS (HTTP Secure) predstavlja kombinaciju HTTP i SSL/TLS protokola koji se smatra dovoljno sigurnim za prenos podataka.

Kada su u pitanju mrežni uređaji, korišćenje pojedinih protokola se preporučuje u sledećim okolnostima:
TTY protokol, odnosno pristup Console portu uređaja se preporučuje:

• Kada je potrebno resetovati šifre za pristup uređaju
• Kada nije obezbeđen pristup uređaju kroz mrežu, nekim od protokola opisanih u nastavku
• U slučaju da je otežan ili onemogućen pristup kroz mrežu usled nekog DoS napada, obrisane konfiguracije i/ili pogrešne konfiguracije koja blokira pristup uređaju, itd.
  

Telnet protokol se preporucuje:

• Kada nije moguća direktna veza na console port uređaja
• Kada na uredajima ne postoji podrška za SSH pristup, što zavisi od verzije i podržanih funkcija operativnog sistema samog uređaja.
• Ukoliko postoji VPN mreža kroz koju se ostvaruje veza sa sigurnim delom mreže kroz koji se pristupa uređajima (out-of-band segment). Ili ukoliko postoji direktna veza sa menadžment VLAN-om.

SSH protokol se preporučuje:

• Ukoliko operativni sistem uređaja ima podršku za kriptovanje saobraćaja, odnosno, podršku za sam protokol
• Kada ne postoji direktna veza sa mrežom iz koje se sigurno pristupa uređajima (out-of-band segment) ili sa menadžment VLAN-om.

HTTP(S) protokol se preporučuje:

• Ukoliko postoji podrška za HTTP protokol i pod sledećim uslovima:
• Za osnovnu verziju protokola (HTTP) važe iste preporuke kao za Telnet protokol
• Za kombinaciju protokola HTTP + SSL/TLS (HTTPS), važe iste preporuke kao i za SSH protokol

Pristup serverima u svrhu menadžmenta se može fleksibilnije podesiti, obzirom da za najveći broj operativnih sistema postoji softverska implementacija gotovo svih protokola za pristup. Okruženja u kojima se preporučuju pojedini protokoli:
SSH pristup se preporučuje:

• Kada su u pitanju Unix bazirani operativni sistemi (Linux), pristup korišcenjem SSH protokola je uobičajena praksa i nje se treba držati.

Graficki pristup:

• Protokoli za grafički pristup (RDP, VNC i sl.) se preporučuju za primenu isključivo kroz menadžment mrežu (out-of-band i/ili menadžment VLAN)
• Preporučuje se primena ovih protokola i van menadžment dela mreže ali isključivo ako se koristi VPN veza od klijenta do menadžment dela mreže.

Telnet pristup se preporučuje:

• Iako su retki slučajavi kada je serverima potrebno prići Telnet protokolom, preporuka je da se ovaj protokol koristi samo ukoliko se pristupa serverima kroz interfejs koji se nalazi u menadžment mreži (out-of-band ili menadžment VLAN-u). Ovo podrazumeva obavezno postojanje minimum dva mrežna intefejsa servera (poglavlje [2.2-])
• Ukoliko postoji VPN veza klijenta (računara sa kojeg se pristupa) sa menadžment delom mreže

Prisutup “ostalim” uređajima zavisi od tipa konkretnih uređaja, kao i od hardverskog pristupa uređaju, odnosno od tipova mrežnih intefejsa i protokola koji su podržani. Uobičajeni načini pristupa sa preporukom korišćenja su:
Telnet pristup:

• Korišćenje Telnet protokola se preporučuje isključivo ako je mrežni interfejs uređaja u menadžment delu mreže (out-of-band i/ili menadžment VLAN-u)
• Ukoliko nije moguće povezati mrežni intefejs uređaja u zaštićeni menadžment deo mreže, Telnet protokol se ne preporučuje.

Web pristup:

• Ukoliko postoji podrška za web (HTTP) pristup, preporuka je korišćenje istih samo ukoliko je mrežni interfejs u zaštićenom menadžment delu mreže. Web pristup korišćenjem HTTPS protokola je preporučljivo koristiti i ukoliko mrežni interfejs uređaja nije povezan u zaštićeni menadžment deo mreže.

Dosta današnjih mrežnih sistema se oslanja na monitoring pomoću SNMP protokola. Sam SNMP protokol je dizajniran tako da veoma malo opterećuje mrežu. 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 definišu: način upravljanja mrežom, baze podataka za čuvanje informacija i strukture korišćenih podataka. Oslanja se na UDP, mada je moguće podesiti i rad preko TCP-a, što nije preporučljivo u velikim mrežama. Trenutno su aktuelne dve verzije SNMP protokola, V2c i V3. Karakteristike verzija sa stanovišta sigurnosti su date u sledećoj tabeli.

Dva osnovna moda rada SNMP protokola su READ i READ/WRITE mod. READ mod omogućuje samo očitavanje SNMP varijabli sa udaljenog uređaja a READ/WRITE omogućuje postavljanje pojedinih varijabli na udaljenom uređaju, odnosno kontrolu uređaja (restart rutera, backup trenute konfiguracije….). Prilikom konfigurisanja agenta na udaljenom uređaju moguće je podesiti ograničenja na MIB bazi. Ako se READ/WRITE opcija koristi za setovanje samo jedne OID varijable, u MIB bazi treba izvršiti ograničenja na SNMP agentu samo na tu OID vrednost. Tada bi podešavanje ostalih OID vrednosti bilo zabranjeno. Ovi primeri ce biti dati u sekciji koja se odnosi na podešavanje agenata na pojedinim tipvima uređaja.

Trenutno najzastupljenija verzija SNMP protokola je V2c (RFC 1901-1908). Kod verzije 2c se autentifikacija vrši pomoću community stringa i on se šalje u čistom tekstu preko mreže. U slučaju da neko “uhvati” ovaj saobraćaj pomoću neke sniffing aplikacije, može vrlo lako otkriti community string i na taj način biti u mogućnosti da ugrozi ispravan rad mreže. Korišćenje V2c se preporučuje samo kada sami uređaji ne podržavaju verziju V3, ali tada se obavezno uvode drugi mehanizmi za zaštitu prilikom prenosa podataka (ACL, Firewalls….). Za nadgledanje mreže preporučuje se korišćenje READ moda, a u slučaju potrebe za kontrolom mreže (READ/WRITE) putem SNMP protokola preporučuje se uvođenje ograničenja u MIB bazi. Prilikom pokretanja V2c agenta na uređajima obično 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 mogućstvu kombinaciju brojeva i slova.

Potreba za sigurnošcu u mreži dovela je do razvoja SNMP V3 koji uvodi autentifikaciju i enkripciju. SNMP V3(RFC 3411-3418) pruža tri važna servisa: autentifikaciju, privatnost i kontrolu pristupa. SNMPv3 uvodi važne bezbednosne aspekte:

1. Integritet poruke (Message integrity), sprecava mogucnost izmene paketa prilikom prenosa
2. Autentifikacija, potvrda da je poruka stigla sa pravog izvorišta
3. Kriptovanje paketa, sprecavanje citanja poruka od strane neautorizovanog izvora

Iz prethodne tabele se vidi da se V3 uvodi tri različita nivoa sigurnosti. Najsigurniji nivo koristi autentifikaciju baziranu na MD5 algoritmu i koristi DES ili AES enkripciju. Pre uvođenja nivoa sigurnosti treba proveriti da li mrežni uređaji podržavaju enkripciju saobraćaja. U slučaju da uređaji ne podržavaju enkripciju, može se koristiti niži nivo sigurnosti koji koristi samo autentifikaciju. Treći najslabiji nivo sigurnosti se ponaša praktično kao V2c i koristi username kao community string za pristup uređaju. Prilikom pokretanja SNMP V3 agenta preporučeno je uvesti ograničenja u MIB bazi za READ i READ/WRITE mod na pojedine OID vrednosti.

Kako uvek može doci do nenadanog otkaza nekog od uredaja, ili dela njegove funkcionalnosti, poželjno je da se pri zameni istog, uredaj postavi u stanje funkcionalnosti koje je imao pre otkaza. Ovo je moguce ukoliko se pravilno i redovno održava backup konfiguracija svih uredaja u mreži. Kada su pojedinacni tipovi uredaja u pitanju, pri backup-u konfiguracija, prvenstveno se misli na mrežne uredaje. Backup konfiguracije kod mrežnih uredaja je uobicajeno da se vrši 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 cesto poverljive informacije upravo u konfiguracijama koje se backup-uju (username/password, 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 vrši tako da su serveri za backup (TFTP i/ili RCP) obavezno povezani samo u zašticeni menadžment deo mreže i izolovani od ostatka mreže. 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 može preneti nekim protokolom za prenos podataka kao što su FTP ili SCP na server za backup. Preporucuje se korišcenje SCP protokola za prenos, obzirom da za razliku od FTP-a, enkriptuje podatke pri prenosu. Eventualno, moguce je vršiti backup ukoliko sama serverska (klijentska) aplikacija ima implementiran neki mehanizam za backup.

Pri definisanju pozicije NMS servera u mreži potrebno je striktno definisati politiku pristupa NMS serveru. Za kampus mreže preporuke su sledeće:

• NMS server mora da ima jedan mrežni interfejs koji se nalazi u menadžment mreži (OOBM ili menadžment VLAN-u). Ovaj interfejs služi kako za menadžment samog NMS servera, tako i za komunikaciju NMS alata sa ostalim uređajima u mreži.
• NMS može, ukoliko je to potrebno, imati dodatni mrežni interfejs u produkcijskom delu mreže. Ovaj interfejs bi imao ulogu pristupa monitoring sistemu radi nadgledanja trenutnog statusa uređaja i detekcije alarma. Pristup po ovom interfejsu bi trebao biti limitiran na read only mod, sa mogućnošću izvršavanja pojedinih predefinisanih akcija radi dijagnostike. Takođe, potrebno je limitirati pristup preko ovog interfejsa samo na željene korisnike (administratori i helpdesk služba).

Većina uređaja podržava verziju V2c dok samo noviji uređaji podržavaju verziju V3. Verzija SNMP protokola kod servera zavisi isključivo od tipa operativnog sistema koji se koristi. Kako Windows OS ne podržava verziju V3 potrebno je naći SNMP agenta koji je podžava i instalirati ga. Jedna od besplatnih Windows verzija SNMP V3 agenta, koja je bazirana na linux-ovom paketu “NET-SNMP”, može se preuzeti sa sledećeg 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 podržava verziju V3 i koji može da se instalira zajedno sa operativnim sistemom. Implementacija V3 kod servera neće imati veliki uticaj na performanse uređaja tako da je V3 sa najvišim nivoom sigurnosti preporučena za korišćenje kod servera. U slučaju rutera i svičeva problem se može javiti ako su memorija i CPU već opterećeni sa nekim drugim procesima i agentima tako da pokretanje V3 može imati uticaj na performanse uređaja, naručito ako se očitava cela MIB baza i pritom se koristi nivo sigurnosti koji koristi enkripciju. U tom slučaju bez obzira što uređaji podržavaju verziju V3 nije preporučljivo pokretati enkripciju SNMP saobraćaja da ne bi došlo do degradacije peformansi uređaja, već pokrenuti nivo koji koristi samo autentifikaciju.

Pre implementacije monitoring sistema u mrežu potrebno je definisati parametre koji će se nadgledati. MIB baza pruža veliki broj OID parametara i pitanje je kako odabrati vrednosti koje nam pružaju najbitnije informacije o stanju mrežnih uređaja i linkova. Tendencija u IT svetu je da se koriste standardne IETF MIB baze koje svaki proizvođač uređaja treba da podržava.

Parametri koji se najčešće prate kod mrežnih uređaja kao što su ruteri i svičevi su:

1. Stanje Interfejsa (L2 i L3 veza)
2. Protok na interfejsu (dobija se indirektno uzastopnim očitavanjem brojača i deljenjem sa vremenskim intervalom izmedu očitavanja)
   1. Standardan In/Out saobraćaj(bits/sec)
   2. Odbačen In/Out saobraćaj(bits/sec)
   3. Protok po In/Out paketima(packets/sec)
3. Opterećenje procesora
   1. Opterećenje memorije
   2. I/O memorija
   3. CPU memorija

U slučaju potrebe za praćenjem funkcija koje se ne sreću na svim uređajima odnosno koje su karakteristične za pojedine proizvođače potrebno je ispitati MIB baze proizvođača koji je napravio taj uređaj.

OID promenjive koje se mogu očitavati kod servera zavise od operativnog sistema. U opštem slučaju svi operativni sistemi podržavaju standardne IETF MIB baza, tako da je dosta OID vrednosti univerzalno za sve uređaje koji podržavaju SNMP. Preporučene su sledeće vrednosti:

1. Stanje Interfejsa (L2 i L3 veza)
2. Statistika interfejsa (dobija se indirektno)
   1. Standardan In/Out saobraćaj (bits/sec)
   2. Odbacen In/Out saobraćaj(bits/sec)
   3. Protok po In/Out paketima(packets/sec)
   4. Koliko dugo je interfejs aktivan
3. Opterećenje procesora
4. Opterećenje memorije
   1. HDD memorija
   2. RAM memorija
   3. Swap space memorija
5. Broj sistemskih procesa
6. Lista pokrenutih servisa na serveru
7. Broj uspostavljenih TCP konekcija
8. Broj trenutno ulogovanih sistemskih korisnika

U slučaju praćenja SNMP promenjivih UPS uređaja, većina OID vrednosti se mora naći u MIB bazama proizvođača. Preporučene varijable su:

1. Trentno stanje UPS-a, odnosno mod rada (battery mod, online mod, malfunction…..)
2. Kapacitet batrije UPS-a
3. Koliko dugo UPS može da radi u battrery modu.
4. Temperatura baterije
5. Izlazno opterećenje UPS-a
6. Ulazni napon
7. Izlazni napon

Varijable u MIB bazi se dele na dve grupe. Prva grupa predstavlja skup varijabli koje se mogu naći na svim uređajima (standardne varijable) dok druga grupa predstavlja varijable koje su specifične samo za pojedine proizvođače mrežnih uređaja (privatne varijable).

Standardne IETF MIB baze se nalaze pod MIB-2 (.1.3.6.1.2.1) cvorom u MIB drvetu.

1. interfaces (.1.3.6.1.2.1.2) - Ovde se nalaze sve informacije o stanju interfejsa na uređaju.
2. ifMIB (.1.3.6.1.2.1.31) - ifMIB Predstavlja proširenje interfaces MIB baze sa 32bit-nih brojača na 64bit-ne brojače.
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 sadrži informacije o stanju procesora i memorije na serverima.

Privatne MIB varijable definiše i implementira proizvođač mrežnih uređaja i one se mogu koristiti samo na uređajima tog proizvođača. 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 proizvođača mrežnih uređaja.

1. Cisco(.1.3.6.1.4.1.9) – Sadrži sve privatne MIB varijable koje su podržane na različitim tipovima Cisco uređaja.
2. APC(.1.3.6.1.4.1.318) – Sadrži sve privatne MIB varijable koje su podržane na različitim tipovima APC uređaja.
3. juniperMIB(.1.3.6.1.4.1.2636) - Sadrži sve privatne MIB varijable koje su podržane na različitim tipovima Juniper uređaja.

SNMP trap mod rada je tako dizajniran da isporučuje 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. V2c šalje trap poruku sa community stringom u čistom tekstu. Verzija V3 trap informacije šalje tačno određenom korisniku sa određenim password-om i određenim engineID-om i ta cela informacija, u zavisnosti od sigurnosnog modela, može biti enkriptovana. Iz ovoga sledi da sam NMS server mora znati username, password i engineID koji je konfigurisan na udaljenom uređaju da bi mogao da dekriptuje primljeni V3 trap. Podešavanja koja se koriste za V3 na udaljenim uređajima se moraju isto podesiti i na NMS serveru. Umesto da se kreira ogroman broj različitih korisnika na NMS, na svim uređajima se može generisati isti korisnik i to samo kao korisnik koji šalje trap poruke. Kako se prilikom kreiranja korisnika na udaljenim uređajima automatski generiše engineID, potrebno je ručno promeniti enginID tako da bude isti za trap korisnika na svim uređajima. Prednosti korišćenja V3 kod trapa su u tome što nam omogućuju sigurnost prilikom primanja trap poruka, ali ako je mreža dizajnirana tako da nije lako moguće izvršiti bilo kakav vid DOS napada na NMS može se koristiti i V2c trap mod rada. Kompleksnost konfiguracije za trap kod V3 je jedan od glavnih razloga zašto se češće koristi SNMP V2c za trap mod rada.

U ovom primeru su prikazane komande za podešavanje verzije V2c SNMP protokola. Pomoću sledeće komande, koja se koristi u konfiguracionom modu, pokreće se SNMP agent na ruteru.

String koji se koristi kao autentifikacija donotusepublic predstavlja vid zaštite tako da će ruter odgovoriti samo onom uređaju koji mu pošalje zahtev koji sadrži baš ovaj string. Opcija ro naglašava da je moguće samo očitati podatke a ne i menjati ih (ro-read only). Takođe je moguće i menjati pojedine varijable (wr-write komanda) što može dovesti do promene rada rutera (restart rutera), zato je veoma bitno da se ne koriste fabrički predefinisane vrednosti za community string i da se SNMP upiti ograniče samo na mogućnost očitavanja a ne i menjanja varijabli. Konačno na kraju komande je definisana access lista acl10 pomoću koje se može definisati pristup SNMP agentu na uređaju samo sa određenih ip adresa. 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.

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

Pomoću sledećih komanda se pokreće SNMP V3 protokol na Cisco uređajima.

U prvoj komandi se definišu vrednosti u MIB bazi OID-ova koji mogu biti očitani sa uređaja. U ovom slučaju je omogućeno očitavanje OID-a (interface) koji opisuju stanje interfejsa na uređaju. Ako se ne definiše ovakva grupa predpostavlja se da je dozvoljen pogled na sve vrednosti u MIB bazi. Druga komanda definiše grupu MYGROUP koja koristi SNMP V3 protokol i koja koristi autentifikaciju. Ova grupa ima mogućnost očitavanja podataka iz MIB baze i to samo onih koji su definisani u “pogledu” MYGROUPV. Treća komanda definiše korisnika pera koji pripada grupi MYGROUP koji koristi SNMP V3, autentifikaciju pomoću md5 algoritma i ima password perapass. Poslednjom opcijom u komandi 3 des56 pera1234 se definiše passphrase koji se koristi za des56 enkripciju SNMP saobraćaja. Četvrta komanda pokreće SNMP trap mod rada. Peta komanda definiše NMS server koji će prikupljati trap poruke. U ovom slučaju prilikom komunikacije između NMS i Cisco uređaja koristiće se SNMP V3 i pravila koja su definisana pomoću grupe MYGROUP. Odavde se vidi da se engineID automatski generisao i u slučaju da želimo da NMS server može da primi trap poruke od user-a pera potrebno je videti koji je engineID usera perai konfigurisati ga u SNMP agentu na NMS serveru. Drugi način je da se pomoću sledeće komande manuelno postavi engineID za lokalnog ili udaljenog korisnika.

U slučaju podešavanja SNMP protokola na Linux operativnim sistemima prvo je potrebno instalirati SNMP deamona na server. U sledećem primeru biće opisana instalacija na CentOS 5.3 operativnom sistemu pomocu YUM komande. Sledeća komanda omogućuje automatizovanu instalaciju SNMP deamona i korisnih komandi za kontrolu rada SNMP-a.

Sledeći korak je podešavanje servisa da se automatski pokreće prilikom startovanja servera. Potrebno je uneti sledeću komandu.

Sledeća stavka je podešavanje community stringa i OID objekata koji mogu biti očitani sa servera. Potrebno je editovati fajl snmpd.conf koji se obično nalazi u direktorijumu /etc/snmp/ i izmeniti sledeće redove. U redu

potrebno je promeniti defaultni community string public u željeni community string. U redu

se vidi de su uključeni svi OID-ovi koji se nalaze ispod cvora .1.3.6.1.2.1.1 u MIB drvetu. Pomoću komande excluded moguće je isključiti pojedine OID vrednosti, odnosno uvesti ograničenja u prikazu MIB baze. Ovde je potrebno definisati OID vrednosti koje će server vraćati kao odgovor na SNMP upite. Ako NMS zatraži OID koji nije ovde definisan server neće odgovoriti NMS-u. Sada je potrebno pokrenuti servis sledećom komandom:

Proveru je moguće uraditi pomoću sledeće komande:

Kao rezultat će se prikazati cela MIB tabela (drvo), ili deo MIB tabele, koji je definisan prethodnim komandama za ograničenje prilikom očitavanja MIB baze.

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 sledeće komande.

Prva dva parametra, syslocation i syscontact su podaci koji služe da daju opšte informacije o serveru. Oni nisu značajni 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 slučaju pojave problema. Syslocation i Syscontact su neki od parametara koji se mogu naći na svim uređajima koji podržavaju SNMP protokol. Treći red definiše pogled mojpogled, odnosno skup OID vrednosti iz MIB stabla. U ovom slučaju je definisana tabela interfejsa servera. Moguće je dodati više tabela ili pomoću komande exclude isključiti neke OID vrednosti. Ova ograničenja su veoma bitna zato što je pomoću SNMP-a moguće i postaviti neke parametre a to direktno može uticati na ispravan rad uređaja. Četvrta komanda kreira korisnika john ciji je password john1234. Prlikom autentifikacije koristi se MD5 algoritam, a saobraćaj je enkriptovan pomoću 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 trećoj komandi. Provera podešavanja SNMP V3 na serveru je moguća pomoću komande:

Uz net-snmp paket se automatski instaliraju i Perl skripte koje omogućuju osnovna podešavanja SNMP agenta. Tri skripte koje omogućuju konfigurasanje SNMP agenta se zovu snmpconf, snmpusm i net-snmp-conf. Prva skripta omogućuje interaktivnu konfiguraciju osnovnih funkcija SNMP agenta dok druga i treća skripta služi za kreiranje SNMP V3 korisnika. Podešavanja SNMP agenta su moguća na dva načina. Manuelnim editovanjem konfiguracionih fajlova snmpd.conf i snmptrapd.conf ili pomoću Perl skripti. Sve detaljne informacije o net-snmp paketu se mogu naći na http://net-snmp.sourceforge.net sajtu.

SysLog protokol je razvijen kao mehanizam za sakupljanje informacija o promenama i događajima u Unix operativnim sistemima i jedna od veoma koristnih osobina mu je bila mogućnost slanja tih poruka preko mreže. Time se omogućilo prikupljanje poruka na centralnom serveru, a samim tim i lakše i brže otkrivanje i rešavanje 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 odredišta, tako da je svrstan u klasu nesigurnih protokola. I pored ovih mana SysLog predstavlja jedan od najčešće korišćenih protokola za sakupljanje informacija o stanju sistema. Format poruka nosi sledeće informacije koje opisuju stanje sistema.

• Facility - Identifikuje objekat koji je generisao poruku. To može biti operativni sistem , proces ili neka aplikacija. Facility se predstavlja celobrojnom vrednošću i vrednosti od 0 do 15 su rezervisane za Unix operaivne sisteme dok vrednosti od 16 do 23 tradicionalno predviđene za mrežne uređaje (rutere, svičeve…). U sledećoj tabeli je dat prikaz Facility vrednosti.
  

• Severity - Može uzimati jednu od osam celbrojnih vrednosti i one opisuju trenutnu težinu problema.

Moguće vrednosti su date u sledećoj tabeli:

• Hostname – Sadrži IP adresu uređaja koji šalje SysLog podatke i to obično IP adresu interfejsa sa koga se poruke šalju.
• Timestamp – Informacija o vremenu kada se SysLog poruka generisala. Preporučuje se da se koristi NTP protokol kako bi postojala ispravna vremenska sinhronizacija na uređajima. Veoma je bitno da postoji tačan vremenski redosled između svih SysLog poruka.
• Message – Sadrži SysLog poruku koju je generisao uređaj kao i još neke dodatne informacije o procesu koji je generisao poruku.

Česta je situacija da se aplikacija koja sakuplja syslog instalira na serveru koji prikuplja SNMP podatke. To je jednostavno i prihvatljivo rešenje za sisteme ako server ima dobre performanse i može da izdrži istovremenu obradu SNMP i SysLog podataka. Kritična tačka je rad baze u kojoj se obično čuvaju te poruke. Tako da se ispravnim izborom hardwer-ske konfiguracije može izvršiti razdvajanje baza na razlicite hard diskove i dobijanje na performansama. Drugo rešenje, u slučaju velikog exporta SysLog poruka, je da se odvoji poseban server samo za SysLog aplikaciju. Za poziciju SysLog servera u mreži važe iste preporuke koje su definisane za NMS server.

Pre pokretanja SysLog servisa u mreži veoma je bitno ispravno pokrenuti vremensku sinhronizaciju na mrežnim uređajima i na samom SysLog serveru. Ovo je bitno uraditi da bi poruke bile sačuvane u tačnom vremenskom redosledu u bazi SysLog kolektora. Preporučeno 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 uređaja ili bitnih servisa. Pokretanje SysLog agenta na pojedinim uređajima je prikazano u daljem tekstu.

Pokretanje SysLog agenta na ruterima i svičevima je objašnjeno na Cisco uređajima. SysLog servis se pokreće pomoću sledećih komandi.

Pomoću prve komande se pokreće logovanje podataka. Druga komanda definiše IP adresu SysLog servera (kolektora) na koji će se vršiti eksport podataka. Treća komanda definiše do kog nivoa kriticnosti će se poruke eksportovati na server. Informational predstavlja level 6 što znači da će se skupljati sve poruke od kritičnosti 0 do kritičnosti 5. Četvrta komanda definiše source adresu koja će se javljati u loggovima i preporučeno je postaviti loopback adresu pošto je ona uvek aktivna. U slučaju da je SysLog server nedostupan ili da želimo direktno na uređaju da očitamo poruke preporučuje se da se odvojiti sistemska memorija u kojoj će se čuvati ove poruke. Peta komanda definiše veličinu bafera u bajtima. Šesta komanda omogućuje logovanje debug komandi. Sedma komanda definiše nivo kritičnosti za terminalne linije dok se u poslednjoj komandi isključuje slanje logova na konzolnu liniju.

Windows operatini sistemi nemaju instaliranog SysLog agenta već se oslanjaju na svog agenta koji se zove Event Logger. U slučaju da želimo da skupljamo SysLog podatke, koje generiše 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 sledećeg sajta https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys/ i http://ntsyslog.sourceforge.net/.

Prilikom instalacije Linux OS automatski se instalira i SysLog agent. Agent je prekonfigurisan tako da sve poruke koje generiše sistem on sakuplja u fajlove koji se nalaze u /var/log/ direktorijumu. U slučaju da želimo da podesimo Facility i Severity parametre pojedinih delova sistema, kao i lokaciju gde će poruke biti sačuvane (lokalni fajl ili udaljeni server), potrebno je editovati i konfiguristai fajl /etc/syslog.conf. Primer fajla /etc/syslog.conf je dat u daljem tekstu:

Iz prve komande se vidi da će se sve poruke čiji je Severity veći 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. Treća komande eksportuje poruke čiji je Facility jednak cron a Severity može uzimati sve moguće 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. U slučaju da želimo da eksportujemo poruke na udaljeni centralizovani SysLog server (192.168.1.1) u konfiguracioni fajl /etc/syslog.conf potrebno je dodati sledeću komandu:

Pomoću ove komande se eksportuju sve poruke na udaljeni SySlog kolektor. Na kraju je potrebno restartovati SysLog agenta pomoću sledeće komande:

U slučaju 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. Preporučuje se istovremeno čuvanje logova i u fajlovima, tako da u slučaju ako je centralni SysLog server nedostupan, administrator može imati uvid u promene na serveru koje je SysLog registrovao. U slučaju da na serveru postoji pokrenut proces koji generiše dosta poruka fajlovi će se dosta brzo popunjavati i zauzimati memoriju. U tom slučaju je potrebno pokrenuti logrotate opciju koja čuva fajlove određeni vremenski period a onda ih briše. Ove komande se zadaju u konfiguracionom fajlu /etc/logrotate.conf. Definiše se vremenski period, kompresija i privilegije fajlova. Standardni SysLog agent se takođe može konfigurisati tako da prima poruke od drugih uređaja i ponaša se kao kolektor SysLog poruka. Jedan od dostupnih kolektora SysLog poruka koji radi na Linux operativnim sistemima se može skinuti sa sledećeg sajta http://code.google.com/p/php-syslog-ng/downloads/list.

 Esad Saitović
 Ivan Ivanović
 AMRES/ RCUB
 Kumanovska bb
 11 000 Beograd
 Srbija

 Phone  : +381 11 3031
 Email  : esad.saitovic@rcub.bg.ac.rs, ivan.ivanovic@rcub.bg.ac.rs