Differences

This shows you the differences between two versions of the page.

--- amres_cbp_wiki:amres_bpd_101 [2011/05/10 23:28]
mara
+++ amres_cbp_wiki:amres_bpd_101 [2011/05/11 14:54] (current)
mara
@@ Line 3: / Line 3: @@
 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).
-^AMRES BPD no        | 101 |
+^AMRES BPD no        ^ **101** |
 ^Tematska grupa/Working group  | Nadgledanje mreže/Network management |
 ^Kategorija dokumenta/Category  | Preporuka/Recommendation |
-^ ^ |
+^Naslov originala ^ **Preporuke za menadžment i monitoring mreže** |
-^Originalna verzija dokumenta na srpskom jeziku         | {{:amres_cbp_wiki:javni_deo:bpd_srpski_recommended_network_management_architecture_-_final.pdf| PDF}}|
-^Naslov originala | Preporuke za menadžment i monitoring mreže |
 ^Originalna verzija/datum	 | Revizija 1  (dokumenta od  24. oktobara  2009.)/ 2. februar 2011. |
-^ ^ |
+^Originalna verzija dokumenta na srpskom jeziku         | {{:amres_cbp_wiki:javni_deo:bpd_srpski_recommended_network_management_architecture_-_final.pdf| PDF}}|
-^English version         | |
+^Title          ^**Network Monitoring and Management Recommendations** |
-^Title          |Network Monitoring and Management Recommendations |
 ^Version/date  |Revision 1 (of the document dated 24 October 2009)/ 2 February 2011 |
+^English version         | {{:amres_cbp_wiki:javni_deo:gn3-na3-t4-abpd101.pdf|PDF}}|
+^ ||^
 ===== Rezime  ======
@@ Line 34: / Line 34: @@
 Finally, the document briefly describes the most frequently used management protocols and their application in different environments and on different types of devices within a network (such as network devices, servers, UPS devices and A/C), provided they do not jeopardise the security of the network.
-======Uvod======
-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.
-======Priprema mreže za implementaciju NMS-a======
-=====In-band vs Out-of-band=====
-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
-=====Logička segmentacija mreže u in-band menadžment okruženju=====
-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
-======Interfejsi za pristup uređajima======
-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.
-=====Mrežni uređaji=====
-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.
-=====Serveri=====
-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.
-=====Ostali uređaji - UPS, klima uređaji itd.=====
-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.
-======Pristup menadžment mreži======
-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
-=====IP adresiranje=====
-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.
-=====Pristup menadžment delovima mreže od strane administratorskog osoblja=====
-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
-=====Primeri topologija=====
-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.\\
-{{ amres_cbp_wiki:nms:bpd_network_management.jpg?800 }}\\
-;#;
-//Slika 4-1 Primer sveobuhvatne topologije menadžment mreže//
-;#;\\
-Na slici 4-2 je prikazan primer segmentacije mreže i veze uređaja sa menadžment VLAN-om.\\ \\
-{{ amres_cbp_wiki:nms:vlan_topologija2.jpg? }}
-;#;\\
-//Slika 4-2 Topologija segmentirane mreže i veze uređaja sa menadžment VLAN-om.//
-;#;
-\\
-======Logički pristup uređajima (protokoli za pristup uređajima)======
-=====Protokoli za kontrolu i konfigurisanje uređaja=====
-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.
-===== Pristup mrežnim uređajima =====
-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 =====
-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
-===== Pristup ostalim uređajima - UPS, klima uređaji itd. =====
-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.
-=====Protokoli za nadgledanje uredaja=====
-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.
-^ 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  |  Username  |  -  |Koristi Username za autentifikaciju.|
-|  v3  |  authNoPriv  |  MD5 ili SHA  |  -  |Autentifikacija se bazira na HMAC-MD5 ili HMAC-SHA algoritmu. Umesto password-a 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 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.
-===SNMPv2c===
-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.
-===SNMPv3===
-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:
-  -  Integritet poruke (Message integrity), sprecava mogucnost izmene paketa prilikom prenosa
-  -  Autentifikacija, potvrda da je poruka stigla sa pravog izvorišta
-  -  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.
-======Održavanje Konfiguracija======
-=====Backup konfiguracija na nekom serveru=====
-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//.
-======Nadgledanje uređaja u mreži ======
-=====Pozicija NMS servera u mreži=====
-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).
-=====Preporučena verzija SNMPa na mrežnim uređajima i serverima=====
-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.
-=====Preporučene promenjive za nadgledanje=====
-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.
-====Mrežni uređaji====
-Parametri koji se najčešće prate kod mrežnih uređaja kao što su ruteri i svičevi su:
-  -  Stanje Interfejsa (L2 i L3 veza)
-  -  Protok na interfejsu (dobija se indirektno uzastopnim očitavanjem brojača i deljenjem sa vremenskim intervalom izmedu očitavanja)
-    -  Standardan In/Out saobraćaj(bits/sec)
-    -  Odbačen In/Out saobraćaj(bits/sec)
-    -  Protok po In/Out paketima(packets/sec)
-  -  Opterećenje procesora
-    -  Opterećenje memorije
-    -  I/O memorija
-    -  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.
-====Serveri====
-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:
-  -  Stanje Interfejsa (L2 i L3 veza)
-  -  Statistika interfejsa (dobija se indirektno)
-    -  Standardan In/Out saobraćaj (bits/sec)
-    -  Odbacen In/Out saobraćaj(bits/sec)
-    -  Protok po In/Out paketima(packets/sec)
-    -  Koliko dugo je interfejs aktivan
-  -  Opterećenje procesora
-  -  Opterećenje memorije
-    -  HDD memorija
-    -  RAM memorija
-    -  Swap space memorija
-  -  Broj sistemskih procesa
-  -  Lista pokrenutih servisa na serveru
-  -  Broj uspostavljenih TCP konekcija
-  -  Broj trenutno ulogovanih sistemskih korisnika
-====Ups-evi====
-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:
-  -  Trentno stanje UPS-a, odnosno mod rada (battery mod, online mod, malfunction.....)
-  -  Kapacitet batrije UPS-a
-  -  Koliko dugo UPS može da radi u battrery modu.
-  -  Temperatura baterije
-  -  Izlazno opterećenje UPS-a
-  -  Ulazni napon
-  -  Izlazni napon
-=====MIB varijable=====
-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 MIB varijable====
-Standardne IETF MIB baze se nalaze pod MIB-2 (.1.3.6.1.2.1) cvorom u MIB drvetu.
-  -  interfaces (.1.3.6.1.2.1.2) - Ovde se nalaze sve informacije o stanju interfejsa na uređaju.
-  -  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.
-  -  tcp (.1.3.6.1.2.1.6) - Ovde se nalaze parametri koji opisuju tcp konekcije.
-  -  host (.1.3.6.1.2.1.25) - Host tabela sadrži informacije o stanju procesora i memorije na serverima.
-====Privatne MIB varijable====
-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.
-  -  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.
-  -  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.
-  -  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.
-=====Trap mod rada=====
-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.
-=====Primeri konfiguracija SNMP-a na uredajima=====
-====CISCO Ruter====
-===SNMP V2c===
-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.\\
-|//1. SNMPTEST(config)#snmp-server community donotusepublic ro acl10//|
-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.
-|//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 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.
-===SNMP V3===
-Pomoću sledećih komanda se pokreće SNMP V3 protokol na Cisco uređajima.
-|//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 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 //**pera**//i 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.
-|//6. snmp-server engineID [local engineid-string] | [remote ip-address udp-port port-number engineid-string]//|
-====LINUX Server====
-===LINUX Server - SNMP V2c===
-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.\\
-|//1. yum install net-snmp net-snmp-utils//|
-Sledeći korak je podešavanje servisa da se automatski pokreće prilikom startovanja servera. Potrebno je uneti sledeću komandu.\\
-|//2. chkconfig snmpd on//|
-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
-|//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 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:
-|//3. service snmpd start//|
-Proveru je moguće uraditi pomoću sledeće komande:\\
-|//4. snmpwalk -v 2c -c mojcommunity 127.0.0.1//| \\
-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.
-===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 sledeće 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 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:\\
-|//2. snmpwalk -v 3 -u john -l authPriv -a MD5 -A john1234 -x DES -X john5678 serveripaddr//|
-===Konfiguracija SNMP protokola pomoću  Perl skripte===
-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.
-======Čuvanje logova ======
-=====SysLog Protokol=====
-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.\\
-^Integer^Facility^
-| 0 |Kernel messages|
-| 1 |User-level messages|
-| 2 |Mail system|
-| 3 |System daemons|
-| 4 |Security/authorization messages|
-| 5 |Messages generated internally by SysLogd|
-| 6 |Line printer subsystem|
-| 7 |Network news subsystem|
-| 8 |UUCP subsystem|
-| 9 |Clock daemon|
-| 10 |Security/authorization messages|
-| 11 |FTP daemon|
-| 12 |NTP subsystem|
-| 13 |Log audit|
-| 14 |Log alert|
-| 15 |Clock daemon|
-| 16 |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)|
-  *  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:
-^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.|
-  *  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.
-=====Lokacija syslog servera=====
-Č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.
-=====Instalacija=====
-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.
-====Mrežni uređaji====
-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.
-|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|
-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.
-====Serveri====
-===Windows===
-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/.
-=== LINUX===
-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:
-^Facility.Severity^Lokacija^
-|*.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 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:
-|//*.*   @192.168.1.1//|
-Pomoću ove komande se eksportuju sve poruke na udaljeni SySlog kolektor.
-Na kraju je potrebno restartovati SysLog agenta pomoću sledeće komande:
-|//service syslog restart//|
-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.
-===== Autori =====
-   Esad Saitović
-   Ivan Ivanović
-   AMRES/ RCUB
-   Kumanovska bb
-000 Beograd
-   Srbija
-   Phone  : +381 11 3031
-   Email  : esad.saitovic@rcub.bg.ac.rs, ivan.ivanovic@rcub.bg.ac.rs