Nagios u TCP/IP mrežama (SNMP)

UNIVERZITET U SARAJEVU ELEKTROTEHNIČKI FAKULTET SARAJEVO

ODSJEK ZA TELEKOMUNIKACIJE

Implementacija SNMP sistema za nadzor IP mrežne infrastrukture i uređaja korištenjem open source alata

Nagios

Završni rad Prvog ciklusa studija

Mentor : Kandidatkinja: R. prof. dr. Vladimir Lipovac, dipl. ing. el. Kurtović Ena

Sarajevo, septembar 2014.

Sadržaj 1. Uvod u BSc rad ........................................................................................................................ 2

2. Network management – upravljanje mrežama .......................................................................... 3

2.1 Uvod u mreže ........................................................................................................................ 3

2.2 TCP/IP referentni mrežni model ........................................................................................... 4

3. TCP/IP Internet Standard Network Management Framework - SNMP ...................................... 5

3.1 Pregled i historija .................................................................................................................. 5

3.2 SNMP verzije ......................................................................................................................... 6

3.2.1 SNMPv1 .......................................................................................................................... 6

3.2.2 SNMPv2 .......................................................................................................................... 6

3.2.3 SNMPv3 .......................................................................................................................... 8

3.3 TCP/IP SNMP komponente i terminologija ........................................................................... 9

3.3.1 Tipovi uređaja ................................................................................................................ 9

3.3.2 SNMP entiteti ................................................................................................................. 9

3.4 Model rada SNMP-a ............................................................................................................ 10

3.5 Arhitektura SNMP framework-a i komponente protokola ................................................. 11

3.5 MIB objekti .......................................................................................................................... 12

3.6 MIB moduli i grupe objekata .............................................................................................. 15

3.6.1 Organizacija MIB objekata u grupe objekata ............................................................... 15

3.6.2 MIB moduli ................................................................................................................... 16

3.6.3 Format MIB modula ..................................................................................................... 17

3.7 SNMP Protokol .................................................................................................................... 18

3.7.1 Operacije SNMP protokola .......................................................................................... 18

3.7.2 Metode komunikacije .................................................................................................. 18

3.7.3 SNMP PDU klase .......................................................................................................... 18

3.7.4 GetRequest i (Get)Response poruke u Poll-driven komunikaciji ................................. 19

3.7.5 SNMPv1 očitavanje sadržaja iz tabela korištenjem GetNextRequest .......................... 20

3.7.6 SNMPv2/v3 očitavanje sadržaja iz tabela korištenjem GetBulkRequest ..................... 21

3.7.7 Modifikacija objekata SNMP protokola korištennjem SetRequest poruka ................. 21

3.7.8 Verifikacija zahtjeva za izmjenu objekata .................................................................... 23

3.7.9 Notifikacije o informacijama SNMP protokola korištenjem Trap(v2) i InformRequest poruka ................................................................................................................................... 23

3.7.10 Upotreba SNMPv2 InformRequest poruka ................................................................ 24

3.7.11 Generisanje SNMP poruka, adresiranje, transport i retransmisija ............................ 24

3.7.12 Prenos SNMP poruka korištenjem UDP-a .................................................................. 24

3.7.13 Format i definicija polja SNMP poruka ...................................................................... 25

3.7.14 Opšti format SNMP poruka ........................................................................................ 25

3.7.15 Opšti format PDU-a .................................................................................................... 26

3.7.16 Format SNMPv3 poruka ............................................................................................. 27

4. Open source alat Nagios ........................................................................................................... 28

4.1 Instalacija i konfiguracija Nagios-a ...................................................................................... 28

4.2 Instalacija Nagios NRPE-a na LINUX hostu .......................................................................... 35

4.3 Nagios online demo ............................................................................................................ 39

5. Zaključak .................................................................................................................................... 43

REFERENCE .................................................................................................................................... 44

1. Uvod u BSc rad

BSc rad je prvi pravi izazov sa kojim se susreće student bachelor studija. Izazov ovog

konkretnog rada je implementacija odabranog softverskog rješenja za nadzor ne toliko komplikovane mreže, što predstavlja fundament za dali napredak u ovoj oblasti, i rad sa mnogo komplikovanijim mrežama. Ovu temu sam odabrala iz razloga što je upravo rad sa mrežama sfera telekomunikacija koja me interesuje kao buduća karijera.

Ovaj BSc rad detaljno objašnjava radnu snagu zaslužnu za ispunjenje portebnih uslova za ostvarivanje komunikacija – protokol SNMP na kojem se zasniva saobraćaj informacija. SNMP je ključan za razumijevanje načina rada mrežne komunikacije, i zato mu je posvećena većina prostora koju dozvoljava BSc rad.

Konkretna implementacija nadzora alatom Nagios i mali spektar njegovih mogućnosti je predstavljen u zadnjim poglavljima. Nagios je veoma moćan alat i detaljna analiza alata bi umnogome prevazilazila zahtjeve i ograničenja BSc rada.

2. Network management – upravljanje mrežama

2.1 Uvod u mreže

Mrežom u najprostijem obliku se mogu smatrati dva uređaja povezana određenom vrstom linka preko kojega se vrši međusobna razmjena informacija. U samo par decenija, mreže su doživjele ekspanziju od isključivo vojne upotrebe do načina života u kojem je pristup beskrajnom oblaku informacija samo dodir prstom udaljen od svakog pojedinca, utkan u svakodnevnicu gotovo do nivoa podrazumijevanja. Ovakav vrtoglav razvoj je omogućio povezanost ne samo ogromnog broja uređaja, već ogromnog broja različitih uređaja sa sve većim spektrima funkcionalnosti. Kako same mreže postaju kompleksnije kroz više dimenzija istovremeno, tako i upravljanje mrežama i njihovo održavanje predstavljaju sve veći izazov administratorima.

ISO (International Organization for Standardization) je razvio model upravljanja telekomunikacijskim mrežama poznat kao FCAPS, akronim nastao od engleskih riječi fault, configuration, accounting, performance, security, kojima je predstavljeno pet funkcionalnih oblasti: Fault management - upravljanje greškama. Cilj ove oblasti je otkrivanje, prepoznavanje, izoliranje, prijava i otklanjanje grešaka u mreži. Veoma važan zadatak povjeren fault management-u je i predviđanje mogućih grešaka u cilju prevencije istih. Npr. neuobičajene pojave kao što su česte promjene u tabelama rutiranja (eng. route flapping), mogu ukazivati na nestabilnost rutiranja ili nepravilno konfigurisan ruter, a u slučaju da nivo saobraćaja pređe određenu vrijednost praga, automatskim obavještavanjem mrežnih administratora sprječavaju se problemi koji mogu nastati usljed zagušenja linka. Configuration management – upravljanje konfiguracijom. Oblast koja mrežnim administratorima pruža informacije o posmatranoj mrežnoj infrastrukturi, svim uređajima unutar nje, kao i svim promjenama izvršenim nad hardverom (izmjene uređaja ili njihovih komponenti) i softverom (update verzije softvera, izmjene konfiguracionih file-ova, izmjene operacionih sistema itd.). Ova oblast je od najveće važnosti i pri planiranju nadogradnje ili proširenja mreže. Pregled upravljanja konfiguracijom, kao i zahtjevi za IP mrežne infrastrukture su dati u [1]. Accounting management – upravljanje korisničkim nalozima. Oblast upravljanja korisničkim nalozima omogućava kontrolu pristupa mrežnim resursima. Korisnici resursa mogu biti ljudi ili drugi uređaji, kojima se dodjeljuju korisnički nalozi, pomoću kojih se vrši restrikcija i specifikacija vrste pristupa resursima, prikupljaju statistički podaci poput praćenja potrošnje određenih resursa, naplate korisničkih usluga, revizije i analize trendova. Detaljni uvod u accounting management je dat u [2]. Performance management – upravljanje performansama. Zaduženje ove oblasti je da osigura zadovoljavajući nivo performansi mreže. Analizom i kontrolom pojedinačnih mrežnih

komponenti, npr. linkova, rutera i hostova, kao i parametara poput propusnosti, vremena odziva mreže, postotka gubitka paketa, iskorištenosti linkova, stope greške itd. aktivno se prikupljaju informacije o stanju u mreži koje mogu poslužiti za identificiranje problema prije nego što oni nastanu. Centralnu ulogu u upravljanju performansama IP mrežnih infrastruktura igraju protokoli kao što je npr. SNMP (Simple Network Management Protocol). Security management – upravljanje sigurnošću. Ciljevi ove oblasti su kontrola pristupa mrežnim resursima prema strogo definisanom skupu pravila i propisa, nadzor i kontrola vanjskih pristupnih tačaka posmatrane mreže, očuvanje integriteta i privatnosti informacija, te alarmiranje u slučaju narušavanja sigurnosti [3].

2.2 TCP/IP referentni mrežni model Komunikacijski protokol (u daljem tekstu, protokol) je skup pravila i konvencija za razmjenu informacija između dva mrežna uređaja koji uključuje i pravila o sintaksi i semantici informacije.

TCP/IP (Transmission Control Protocol over Internet Protocol) mrežni model predstavlja arhitekturu u kojoj su zadaci mreže, kao i protokoli koji ih izvršavaju, podijeljeni u četiri funkcionalna sloja. Od najnižeg ka najvišem, to su:

Sloj linka Mrežni (Internet) sloj Transportni sloj Aplikacijski sloj Usporedba sa OSI/ISO referentnim modelom je data na slici 2.1.

Slika 2.1 Usporedba referentnih OSI/ISO i TCP/IP modela [5]

U samom TCP/IP-u operišu desetine različitih protokola, ali ime je dobio prema dva najvažnija – koja definišu centralni način rada arhitekture, Internet Protocol i Trasmission Control Protocol. Za većinu aplikacija koje rade kao dio TCP/IP arhitekture, protokol transportnog sloja je TCP. TCP pruža pouzdanu vezu za prijenos podataka između aplikacija. [6]

IP je protokol mrežnog sloja, koji pruža usluge logičke komunikacije između uređaja. IP sam po

sebi nije pouzdan protokol – ne garantuje isporuku paketa, samim tim ne garantuje integritet

podataka[3] .

3. TCP/IP Internet Standard Network Management Framework - SNMP

3.1 Pregled i historija

Funkcije upravljanja TCP/IP mrežom su najčešće povezane sa ključnim protokolom odgovornim za implementaciju tih funkcija: SNMP (Simple Network Management Protocol) . SNMP se smatra “načinom” na koji se vrši upravljanje TCP/IP mrežama, što zapravo predstavlja samo pojednostavljenje stvarne slike. SNMP protokol je zapravo samo dio više strategije upravljanja mrežama, nazvane Internet Standard Management Framework [7]. SNMP (Simple Network Management Protocol) je razvijen u kasnim osamdesetim, kada je u samo par mjeseci zamijenio svoga prethodnika - SGMP (Simple Gateway Management Protocol) [4]. IETF (Internet Engineering Task Force) je prepoznao važnost postojanja jednoznačnog standarda za upravljanje TCP/IP mrežama, te godine 1988. objavljuje dokument o sastanku održanom na ovu temu, u kojem je prezentovan zaključak da će SGMP biti temelj za novi Internet standard, nazvan SNMP. Daljnji razvoj je izvršila SNMP Radna Grupa (eng. SNMP Working Group). Dvoznačnost SNMP-a unosi dozu konfuzije, na nižem nivou SNMP se odnosi isključivo na protokol koji prenosi informacije o stanju mreže i mrežnih uređaja. Kako je SNMP radna grupa definisala, upravljanje TCP/IP mrežama se sastoji od većeg broja različitih elemenata organizovanih u arhitekturu, koja se naziva Internet Standard Management Framework. Nažalost, ova arhitektura višeg nivoa nema skraćenicu poput „ISMF“, već se i ona naziva SNMP-om. Iz navedenih razloga, u daljnjem tekstu je potrebno razlikovati „SNMP Protokol“ i „SNMP Framework“[7].

3.2 SNMP verzije 3.2.1 SNMPv1

Prva verzija SNMP-a, poznatija kao SNMP version 1, ili kratko SNMPv1, je razvijena početkom 1988., a objavljena je u augustu iste godine u formi tri RFC (Request for Comment) dokumenta. Ovi dokumenti su predstavljali početne opise tri glavne komponente SNMP Framework-a:

Structure of Management Information, skr. SMI,

Management Information Bases, skr. MIB,

SNMP Protokol.

SNMPv1 je brzo postao opšteprihvaćeni standard za upravljanje TCP/IP mrežama. Međutim, kako to biva sa svakom novom tehnologijom, korisnici SNMPv1 su brzo otkrili slabosti ove verzije, a sigurnost je bila oblast koja je najviše kriticizirana. SNMPv1 je koristila samo „trivijalnu“ autentikacijsku šemu datu u vidu strukture slične passwordu, nazvanoj community string. Sigurnosni propusti su vremenom doveli do ozbiljnih problema u razvoju SNMP-a, kao i brojnih prijedloga za poboljšanje iste, međutim kompromisno rješenje nije postignuto.

Tabela 3.1: Standardi SNMP verzije 1

3.2.2 SNMPv2 Prvi pokušaj poboljšanja sigurnosti kod SNMP-a je predstavljen u formi tri standarda obljavljena u julu 1992. godine, koja su definisala novi sigurnosni mehanizam – korištenje logičkih identifikatora nazvanih partijama. Ova verzija, nazvana SNMP Security, ili skr. SNMPsec, iako sigurnija od SNMPv1, nikada nije postala opšteprihvaćena. Dok je SNMPsec iščezavao, ideja o sigurnosti osnovana na partijama se itekako održala. Iskorištena je kao temelj pri definisanju prve totalne revizije SNMP-a - kada je SNMPv2 objavljen u aprilu 1993. godine. Nova verzija je sadržavala i novi sigurnosni model, kao i promjene u radu

samog SNMP protokola, promjene SMI standarda (definišući SMIv2), i formalizovala je koncept SNMP Framework-a. Nažalost, ni ovaj standard nikada nije doživio opšte prihvatanje. Mišljenja su bila podijeljena, jedna strana je doživljavala novu verziju kao ogroman napredak, dok je druga smatrala sigurnost na bazi partija prekompleksnom, što je rezultovalo novom lavinom varijanti SNMPv2 razvijanih od strana odvojenih grupa:

SNMPv1.5 (broj verzije niži od zadnje standardizovane verzije),

Community-Based SNMPv2 (SNMPv2c),

User-Based SNMPv2 (SNMPv2u),

SNMPv2* (potpuno neozbiljan asterisk u imenu verzije)

Mrežni administratori su se sredinom '90., u konfuziji izazvanoj morem podverzija druge verzije SNMP-a, masovno okretali SNMPv1. Ova dešavanja su klasičan primjer na kojem je pokazana važnost univezalne standardizacije.

Tabela 3.2: Standardi za SNMPv2 na bazi partija

3.2.3 SNMPv3

1996. godine započeo je rad na novom pristupu rješavanju problema, i povratku jednoznačnom SNMP-u. 1998. godine razvijena je treća verzija SNMP-a, nazvana SNMPv3, koja je uključivala dodatna poboljšanja nad SNMP-om, i konačno zadobila opšte povjerenje korisnika. Sa SNMPv3 uveden je formalizovani način rukovanja različitim sigurnosnim pristupima – lekcija koja je naučena iskustvom verzije SNMPv2.

SNMPv3 je zadržao način rada SNMPv2 protokola i PDU (Protocol Data Unit) – format poruka, kao i SMIv2 standard. Uvedena novina je upravo sigurnosne prirode, naime SNMPv3 dozvoljava inkorporiranje nekoliko sigurnosnih metoda u svoju arhitekturu, a uključuje standard koji opisuje korisnički-baziran pristup sigurnosti, koji se pojavio u verzijama SNMPv2u i SNMPv2*, spomenutim u poglavlju 3.2.2. Također, uvedeni su dodatni alati koji olakšavaju administraciju SNMP-a [7].

Tabela 3.3: Standardi SNMPv3 [7]

3.3 TCP/IP SNMP komponente i terminologija 3.3.1 Tipovi uređaja SNMP Framework pruža mrežnim administratorima mogućnost da pomoću specifičnog mrežnog uređaja, koji ima sposobnost komunikacije sa ostalim mrežnim uređajima, prikupljaju informacije od istih i modificiraju njihov način rada. Time su definisana dva osnovna tipa hardvera:

Upravljani čvorovi: Standardni mrežni čvorovi opremljeni softverom pomoću kojeg je omogućeno njihovo upravljanje pomoću SNMP-a. Generalno, to su konvencionalni mrežni uređaji - upravljani uređaji.

Network Management Stations (NMS): Specificirani mrežni uređaj na kojem je pokrenut specijalni softver kojim je omogućeno upravljanje iznad pomenutim čvorovima. U mreži mora postojati makar jedan NMS, jer u suštini su upravo oni uređaji koji pokreću SNMP.

3.3.2 SNMP entiteti Na svakom uređaju koji učestvuje u mrežnom upravljanju pomoću SNMP-a, je pokrenut sofver, generalno nazvan SNMP entitet. SNMP entitet je odgovoran za implementaciju različitih funkcija SNMP protokola. Svaki entitet se sastoji od dvije primarne softverske komponente, u ovisnosti o tome da li se radi o upravljanom čvoru, ili NMS-u. SNMP upravljani čvor može biti bilo koji mrežni uređaj programiran odgovarajućim softverom, koji može komunicirati koristeći TCP/IP, bili to primitivni terminalni uređaji, ili uređaji visoke pouzdanosti i dostupnosti. SNMP entitet na upravljanom čvoru se sastoji od sljedećih softverskih konstrukcija:

SNMP Agent: Softverski program kojim je implementiran SNMP protokol, i koji omogućava upravljanom čvoru da pruža informacije NMS-u, i prihvata instrukcije od njega.

SNMP Management Information Base (MIB): Definiše tipove pohranjenih podataka o čvoru, koji mogu biti prikupljani i korišteni za upravljanje tim čvorom. Informacije koje se razmjenjuju korištenjem SNMP-a preuzimaju formu objekata iz MIB-a.

U većim mrežama, NMS može biti odvojen računar namijenjen isključivo za upravljanje

tom mrežom. Međutim, softver je zapravo ključ koji uređaj čini NMS-om, tako da NMS zapravo i ne mora biti hardverski odvojen uređaj, tj. može vršiti sve funkcije NMS-a, a istovremeno obavljati sasvim različite funkcije u mreži. SNMP entitet na NMS-u se sastoji od:

SNMP menadžera: Sofverski program kojim je implementiran SNMP protokol, koji omogućava NMS-u prikupljanje informacija od upravljanih čvorova, i slanje instrukcija istim

SNMP aplikacije: Jedna ili više softverskih aplikacija koje služe kao interfejs mrežnom administratoru za korištenje SNMP-a za upravljanje mrežom.

3.4 Model rada SNMP-a SNMP framework se sastoji od nekoliko NMS-ova - posebnih mrežnih uređaja pomoću kojih se vrši interakcija sa upravljanim mrežnim uređajima, tj. čvorovima. SNMP menadžerima na NMS-u i SNMP agentima na upravljanim čvorovima je implementiran SNMP protokol koji omogućava razmjenu informacija za upravljanje mrežom. SNMP aplikacije pružaju mrežnim administratorima interfejs za pristup informacijama prikupljenih iz MIB-ova na svakom SNMP agentu, kao što je prikazano na slici 3.1.

Slika 3.1: SNMP model rada [7]

3.5 Arhitektura SNMP framework-a i komponente protokola SNMP framework se sastoji iz većeg broja komponenti koje definišu strukturu informacija za upravljanje mrežom, način njihovog pohranjivanja, i način njihove razmjene putem SNMP protokola. Također opisuje kako se međusobno uklapaju različite komponente te arhitekture, način implementiranja SNMP-a na mrežnim uređajima, i kako ti uređaji vrše interakciju. SNMP framework je u potpunosti informacijski orjentisan, i sadrži sljedeće primarne komponente:

Structure of Management Information (SMI): Struktura informacija mrežnog upravljanja je standard koji definiše strukturu, sintaksu i karakteristike informacija za upravljanje mrežom pomoću SNMP-a. Ova komponenta je ključna za osiguravanje interoperabilnosti mrežnih uređaja, a alat koji obavlja ovaj posao se naziva jezikom za opis podataka (eng. Data Description Language, skr. DDL).

Management Information Bases (MIB-ovi): Svaki čvor sadrži niz varijabli kojima su predstavljene informacije o radu upravljanog uređaja. Te informacije se šalju NMS-u, i/ili čvoru, tj. uređaju kao set instrukcija za upravljanje njime. MIB predstavlja puni set ovih varijabli koje opisuju karakteristike za upravljanje određenim tipom uređaja. Svaka varijabla u MIB-u se naziva MIB objektom, i definisana je koristeći SMI DDL. Uređaj može sadržavati mnoštvo MIB objekata, u ovisnosti od različitih hardverskih i softverskih elemenata koje sadrži. Prvobitno je samo jedan dokument definisao MIB za SNMP, ali je ovaj pristup bio poprilično nefleksibilan. Da bi se omogućilo jednostavnije definisanje MIB objekata, oni su dati posebnim RFC standardom, nazvanim MIB moduli. Preko 100 takvih MIB modula su do sada definisani.

Simple Network Management Protocol (SNMP): SNMP protokol definiše način razmjene informacija između SNMP agenata in NMS-a. SNMP protocol operations – funkcionisanje SNMP protokola, definiše različite SNMP poruke i način njihovog kreiranja i korištenja. SNMP transport mappings opisuje načine na koje SNMP može biti korišten preko različitih podmreža, kao što su TCP/IP, IPX i sl.

Sigurnost i administracija: SNMP framework pruža brojne elemente podrške trima iznad navedenim glavim komponentama arhitekture. Ovi elementi omogućavaju unapređenja pri radu SNMP protokola u oblasti sigurnosti, same implementacije SNMP-a, tranzicija između različitih verzija, i pri drugim administrativnim pitanjima.

Slika 3.2: Komponente SNMP Framework-a [7]

SNMP framework je dizajniran kao modularna arhitektura koja razdvaja definicione, podatkovne i funkcionalne elemente protokola. Ovo je umnogome olakšalo implementaciju SNMP protokola. Svaka od gore navedenih ključnih komponenti, SMI, MIB-ovi i sami SNMP protokol su definisani i opisani različitim standardima. Modularnost SNMP framework-a je također omogućilo izvršavanje promjena nad svakom od ovih komponenti relativno nezavisno od drugih, kao i olakšane tranzicije između SNMP verzija, naspram poteškoća koje bi izazvao jedan ogromni dokument kojim bi sve iznad bilo definisano.

3.5 MIB objekti MIB objekti su definisani prema pravilima SMI standarda. SMI koristi format sadržaja poruke kojim se specificiraju fundamentalne karakteristike svakog MIB objekta. Postoji pet mandatornih karakteristika MIB objekta: Object Name, Syntax, Access/Max-Access, Status, Definition/Description, dok su ostale karakteristike opcionalne. Konceptualni prikaz navedenih karakteristika i MIB-a je dat na slici 3.3.

Object Name – ime objekta Svaki objekat mora biti imenovan da bi se mogao jedinstveno identifikacirati. Ime objekta se sastoji od dva dijela, Object Descriptor – koji je zapravo konvencionalno tekstualno ime, intuitivno korisnicima, koje se dodjeljuje prema konkretnoj grupi MIB objekata u kojoj se taj objekat nalazi. Drugi dio imena se naziva Object Identifier, koji ukazuje na mjesto imenovanog objekta u MIB objekt hijerarhiji imena.

Slika 3.3: SNMP MIB

Ova slika prikazuje SNMP MIB koji sadrži N MIB objekata. Svaki objekat sadrži pet mandatornih karakteristika i varijabilan broj opcionalnih karakteristika.

Syntax – sintaksa Sintaksa definiše tip podataka objekta i strukturu koja ga opisuje. Ova karakteristika je veoma važna jer definiše tip informacija koje objekat sadrži. Postoje dvije osnovne dozvoljene kategorije tipova podataka:

Standardni tipovi podataka: Jedinstvena informacija o tipu podataka koji je korišten, npr. integer ili string. Oni se nazivaju bazni tipovi u SMIv2.

Tabelarni podaci: Kolekcija višestrukih elemenata podataka. Mogu biti u formi liste ili tabele baznih tipova. Npr. tabela integer-a može predstavljati set vrijednosti. U SMIv2 se nazivaju konceptualne tabele. Pristupa im se pomoću namjenskih SNMP mehanizama za čitanje tabela.

Access/Max-Access – Pristup/Maksimalni pristup Ovo polje definiše način na koji SNMP aplikacija uobičajeno koristi objekat, i u SMIv1 se nazivalo Access, sa četiri moguće vrijednosti: read-only, read-write, write-only i not-accessible. U SMIv2 ova karakteristika se naziva Max-Access ili prevedeno Maksimalni pristup. Može uzeti jednu od pet vrijednosti opisanih hijerarhijom u kojoj pristup više razine uključuje pristup svim nivoima koji su ispod te razine, ali ne i obratno. Vrijednosti pristupa u opadajućem poretku su date u tabeli ispod:

Tabela 3.4: Vrijednosti SNMP SMIv2 Max-Access-a

Status Status ukazuje na aktuelnost definicije objekta. U SMIv1 postojale su tri vrijednosti: mandatory - obavezno, optional – opcionalno, obsolete – zastarjelo. SMIv2 kombinuje prve dvije vrijednosti u current – aktuelno. Vrijednost obsolete je u potpunosti izbačena, a vrijednost deprecated je dodana, ukazujući na zastarjelu definiciju koja je zadržana radi kompatibilnosti.

Definition/Description Definicija u SMIv1, ili deskripcija u SMIv2 predstavlja tekstualni opis posmatranog objekta.

Optional Characteristics SMIv2 je dodao sljedeće opcionalne karakteristike koje se mogu pojaviti u definiciji objekta:

Units: Tekstualni opis jedinica vezanih za objekt.

Reference: Tekstualna unakrsna referenca na srodni dokument ili na druge značajne informacije o objektu.

Index: Vrijednost kojom se definišu objekti koji su zapravo kompleksniji „redovi“ drugih objekata.

Augments: Alternativa polju Index.

DefVal: Definiše prihvatljivu zadanu vrijednost objektu.

3.6 MIB moduli i grupe objekata Management Information Base sadrži kolekciju MIB objekata koji opisuju osobine uređaja koristeći SNMP Framework. Kada je tek nastao SNMP, nije postojalo mnogo objekata u MIB-u. To su bili većinom generički objekti koji su se primjenjivali na TCP/IP uređaje općenito. Uglavnom su to bile varijable koje su bile u vezi sa funkcionisanjem TCP/IP protokola kao što su IP, TCP i ICMP.

Iz tog razloga je samo jedan dokument definisao MIB za SNMP. Prvi ovakav dokument je bio [8], koji je kasnije prepravljen u [9]. Druga verzija MIB-a, MIB II, je definisana u [9], koji je suštinski bio isti, uz nekolicinu promjena. 3.6.1 Organizacija MIB objekata u grupe objekata Broj MIB objekata definisanih u ovim standardima je bio relativno mal, ali ipak je postojalo nekoliko desetina njih. Na samom početku je pretpostavljeno da će ih vremenom nastati mnogo više. Da bi se oni logički organizovali, raspoređeni su u grupe objekta. Ove grupe razdvajaju objekte i definišu način na koji im se treba pridružiti identifikator objekta u cjelokupnoj hijerarhiji imena objekata. Svakoj grupi su pridružene tri važne informacije:

Ime grupe: Ime koje se koristi kao labela u identifikacionom stablu. Ovi objekti su smješteni u „iso.org.dod.internet.mgmt.mib“ podstablu. Npr. grupa „system” bi bila “iso.org.dod.internet.mgmt.mib.system”.

Broj grupe: Broj koji korespondira imenu grupe, koji se koristi za stvaranje numeričkih identifikatora iz stabla objekata. Na primjer, grupa system ima dodijeljen broj 1, time je identifikator grupe objekta 1.3.6.1.2.1.1. Svi objekti u ovoj grupi će biti u tom stablu, npr. sysUpTime je 1.3.6.1.2.1.1.3.

Kod grupe: Tekstualna labela koja može biti ista kao i ime grupe, ili skraćenica. Koristi se kao prefiks pri pravljenju deskriptora objekata (tekstualnih imena objekata). Na primjer, za grupu system kod je sys, time je i objekt iz ove grupe sysUpTime.

Sve grupe date u narednojj tabeli su generičke, i primjenjene su u skoro svakom TCP/IP sistemu koji koristi SNMP, isključujući grupu „egp“. Prvih pet i zadnja grupa objekata su obavezne za sve sisteme. EGP je routing protokol koji je zastario, što govori o starosti liste grupa objekata.

Tabela 3.5 Generičke grupe MIB objekata

3.6.2 MIB moduli

Ono što se može primijetiti u tabeli 3.5, su grupe koje u njoj nisu sadržane. Ne postoje grupe objekata za većinu drugih TCP/IP protokola, niti varijable koje su potrebne za specifične vrste hardvera. Npr. većina hostova ima mrežnu karticu koja koristi protokole drugog sloja kao što su Ethernet ili Token Ring. Također nisu specificirani objekti za novije routing protokole kao što su OSPF i BGP, niti objekti povezani sa radom DNS-a.

Konstantno ažuriranje MIB dokumenta bi bilo nepraktično. Iz tog razloga u SNMPv2, MIB se umjesto dosadašnjeg jednog, sastojao od grupe dokumenata. Osnovna organizacija u grupe je zadržana, ali su sada grupe raspoređene u nekoliko standarda. Također je definisana i metoda kreiranja MIB modula koji opisuju nove grupe objekata specifične za određenu tehnologiju.

Tabela 3.6 Uobičajeni SNMP MIB moduli

3.6.3 Format MIB modula Format MIB modula je opisan u Structure of Management Information Standard version 2 (SMIv2). Ovaj dokument specificira kako moduli trebaju da budu definisani, na način veoma sličan definisanju samih objekata, tj. pomoću seta karakteristika koje moraju biti definisane pri opisu svakog modula. Potrebna polja su:

Ime modula: Sintaksički, moduli su zapravo objekti, pa kao i oni, imaju tekstualni deskriptor (npr. tcpMIB) i numerički identifikator, za slučaj tcpMIB-a je to broj 50.

Datum ažuriranja: Posljednji datum revizije modula

Organizacija: Naziv organizacije zadužen za razvoj modula

Kontakt informacije: Naziv, adresa i telefonski broj i e-mail adresa osobe odgovorne za modul

Opis: Opis modula

Revizija i opis revizije: Podaci uneseni nakon svake revizije, pregled historije modula. Nakon definicije samog modula, opisani su i pripadajući objekti u tom modulu.

3.7 SNMP Protokol SNMP Framework je u poglavlju 3.5 opisan kao informacijski orjentisan, što je ovoj tehnologiji u cjelini donijelo brojne beneficije, među kojima su najveće fleksibilnost i modularnost. U ovakvom modelu, operacije protokola za upravljanje mrežom nisu definisane kao određene komande za provjeru statusa upravljanog uređaja, već u formi varijabli koje nose upravljačke informacije, nazvane objektima. Ovi objekti mogu biti pregledani ili izmijenjeni od strane mrežnog administratora, pomoću komunikacijskog protokola. 3.7.1 Operacije SNMP protokola SNMP je protokol koji obezbjeđuje NMS-ovima, tj. posebnim mrežnim uređajima da vrše interakciju sa upravljanim mrežnim uređajima. Srž protokola se sastoji od seta operacija protokola (eng. protocol operations), pomoću kojih je opisan način razmjene informacija, tj. MIB objekata između SNMP agenata i menadžera. 3.7.2 Metode komunikacije Mrežnom administratoru koji koristi NMS, SNMP mora pružiti mogućnost da jednostavno provjeri status SNMP agenata na urpavljanim čvorovima. Generalno u komunikacijama postoje dvije tehnike koje se koriste u situacijama u kojima je potrebno da jedan entitet bude izviješten o stanju i aktivnostima na drugom entitetu:

Poll-Driven – „Anketiranje“ SNMP agenata za informacije, od strane NMS-a.

Interrupt-Driven – SNMP agent šalje informacije NMS-u, bez da to NMS od njega traži.

3.7.3 SNMP PDU klase Stvarna komunikacija informacija u SNMP protokolu se izvršava putem razmjene SNMP poruka, zvanih jedinice podataka protokola (skr. PDU). U SNMPv1 je bilo definisano šest takvih PDU-ova. Njihov broj se povećao u SNMPv2 i SNMPv3. Trenutni SNMP framework kategorizira PDU-e u različite klase. Ove klase opisuju kako funkcije svakog tipa poruka, tako i vrstu komunikacija koju koriste da izvrše zadatak (polling ili interrupting).

Tabela 3.7 SNMP PDU klase poruka

GetBulkRequest-PDU i InformRequest-PDU poruke su nove u SNMPv2/v3. GetResponse-PDU je

preimenovan u Response –PDU, kako je on zapravo odgovor (eng. Response), te novi Trapv2-PDU je zamijenio Trap-PDU.

Postoje još tri posebne klase definisane trenutnim SNMP Framework-om, koje nisu od posebnog interesa, kako one ne definišu aktivno korištene poruke. Klasa Internal sadrži posebnu poruku, Report-PDU, definisanu za internu SNMP komunikaciju. SNMP standardi također sadrže i dvije klase nazvane Confirmed (potvrđeno) i Unconfirmed (nepotvrđeno), koje se koriste za kategorizaciju poruka sadržanih u gore navedenoj tabeli. Report-PDU, Trapv2-PDU i Response-PDU poruke se smatraju nepotvrđenima, dok su ostale potvrđene.

Sve razmjene poruka unutar SNMP protokola su produkt međusobne komunikacije SNMP entiteta. Najčešće, entitet koji šalje poruke zahtjeva (eng. Request) su SNMP menadžeri, a oni koji šalju poruke odgovora (eng. Response) su SNMP agenti, uz izuzetak trap poruka, koje šalju agenti.

3.7.4 GetRequest i (Get)Response poruke u Poll-driven komunikaciji

Najjednostavniji vid razmjene informacija je jednostavna poll operacija, kojom se očitava jedna ili više informacionih varijabli za upravljanje mrežama. SNMP imlementira ovu operaciju kao dvosmjernu komunikaciju između SNMP menadžera i SNMP agenta, u vidu request/response razmjene poruka.

Zahtjev najčešće šalje korisnik aplikacije koji želi da provjeri status uređaja, ili dobije određenu informaciju o njemu. Sve informacije o jednom uređaju su pohranjene u formi MIB objekata. Komunikacija se svodi na zahtjev za informacije o određenom MIB objektu i odgovor uređaja u formi vrijednosti tog objekta. Koraci procesa su sljedeći:

1. SNMP menadžer kreira GetRequest-PDU: Bazirano na informacijama koje zahtijevaju aplikacija i korisnik, SNMP softver stanice za upravljanje mrežom kreira GetRequest-PDU poruku, koja sadrži nazive MIB objekata čije je vrijednosti potrebno saznati.

2. SNMP menadžer šalje GetRequest-PDU: SNMP menadžer šalje kreiranu poruku uređaju koji je potrebno „anketirati“ (eng. Poll)

3. SNMP agent prima i obrađuje poruku: SNMP agent prima GetRequest-PDU u vidu liste naziva MIB objekata, kojima provjerava validnost. Zatim agent provjerava vrijednosti svih varijabli koje su ispravno specificirane.

4. SNMP agent kreira Response-PDU: Agent kreira poruku koju je potrebno poslati SNMP menadžeru. Ova poruka sadrži vrijednosti MIB objekata i/ili kodove eventualno nastalih grešaka, kao npr. neispravan naziv objekta

5. SNMP agent šalje Response-PDU: Agent šalje kreiranu poruku natrag SNMP menadžeru 6. SNMP menadžer obrađuje Response-PDU: Menadžer obrađuje informacije koje je dobio

u Response-PDU poruci koju je primio od SNMP agenta.

Slika 3.4 SNMP poll proces

3.7.5 SNMPv1 očitavanje sadržaja iz tabela korištenjem GetNextRequest

Očitavanje sadržaja tabela od uređaja može se izvršiti korištenjem standardne GetRequest-PDU poruke, na način da se specifikuje svaki unos iz tabele jedan za drugim. Ovaj način očitavanja se suočava sa problemom: SNMP menadžer ne mora nužno znati koliko unosa postoji u datoj tabeli, tj. koliko unosa je potrebno da zahtijeva.

Ovaj problem je riješen kreiranjem novog tipa poruke, nazvane GetNextRequest-PDU, koja sadrži naziv varijable iz tabele, kao i konkretnog unosa iz tabele. Uređaj koji prima GetNextRequest-PDU koristi ove informacije da pronađe narednu vrijednost u tabeli i tu vrijednost vraća menadžeru GetResponse-PDU porukom. 3.7.6 SNMPv2/v3 očitavanje sadržaja iz tabela korištenjem GetBulkRequest

GetNextRequest-PDU poruka jeste funkcionalna, ali nije efikasnija od GetRequest-PDU poruka, kako je svaki unos iz tabele ponovo potrebno zahtijevati jedan po jedan. Izvlačenje podataka iz tabela na ovaj način je dugotrajno i rezultira velikom količinom saobraćaja generisanog brojem zahtijeva i odgovora koje je potrebno poslati.

SNMPv2 predstavlja mnogo jednostavniji i efikasniji način očitavanja tabelarnih podataka u vidu nove vrste poruke, nazvane GetBulkRequest-PDU. Ova poruka pruža SNMP menadžeru mogućnost da pomoću samo jednog zahtjeva dobije veći broj informacija o unosima iz tabele putem Response-PDU poruke.

Pomoću GetBulkRequest-PDU poruke je moguće dobiti informacije i o standardnim varijablama i o tabelarnim unosima. Lista je organizovana na takav način da regularni objekti se pojavljuju prvi, a zatim tabelarni objekti. Dva posebna parametra su sadržana u zahtjevu, nazvana Non Repeaters i Max Repetitions. Prvi specifikuje broj neponavljajućih standardnih objekata, a drugi broj iteracija ili unosa koje je potrebno očitati za preostale tabelarne objekte.

Naprimjer, ako SNMP menadžer zahtijeva 4 standardne varijable i 3 unosa iz tabele, GetBulkRequest-PDU bi sadržavao pet MIB specifikacija objekata, pri čemu je tabela posljednja. Polje neponavljajućih objekata bi bilo postavljeno na vrijednost 4, a maksimalni broj iteracija na 3. 3.7.7 Modifikacija objekata SNMP protokola korištennjem SetRequest poruka

GetNextRequest-PDU i GetBulkRequest-PDU su poruke „Read“ klase PDU-ova, koje omogućavaju SNMP menadžeru čitanje MIB objekata koje šalje MIB agent. Suprotnu funkciju predstavlja SNMP „Write“ klasa, koja sadrži samo jedan član: SNMP SetRequest-PDU poruku.

Namjena ovog PDU-a je poprlično očigledna, SetRequest-PDU specificira varijablu čiju vrijednost administrator želi modificirati. Treba napomenuti da SNMP ne sadrži specifične komande pomoću kojih bi administrator upravljao nadgledanim uređajema, već nudi metod kontrole – postavljanjem varijabli koje utječu na rad tog uređaja.

“Set” process je complement “Get” procesa, osnovna ideja je ista, ali način „putovanja“ i operacije nad objektom su inverzne, kao što slijedi:

SNMP menadžer kreira SetRequest-PDU: Na osnovu promjena nad informacijama koje je izvršio korisnik putem SNMP aplikacije, SNMP softver na stanici za upravljanje mrežom kreira SetRequest-PDU poruku, koja sadrži set naziva MIB objekata i vrijednosti na koje trebaju da budu postavljeni.

SNMP menadžer šalje SetRequest-PDU: SNMP menadžer šalje PDU ciljanom uređaju.

SNMP agent prima i obrađuje SetRequest-PDU: SNMP agent ispituje svaki objekat iz zahtjeva zajedno sa vrijednostima na koje ga je potrebno postaviti, i donosi odluku da li treba ili ne treba ispuniti taj zahtjev.

SNMP agent vrši izmjene i kreira Response-PDU: Pod pretpostavkom da su informacije u zahtjevu ispravne (i ispunjeni sigurnosni zahtjevi), SNMP agent vrši izmjene internih varijabli. Agent kreira Response-PDU poruku koju će poslati nazad SNMP menadžeru, sa potvdom o uspješnom izvršenju, ili ukazuje na eventualno nastale greške.

SNMP agent šalje Response-PDU: Agent šalje odgovor SNMP menadžeru.

SNMP menadžer obrađuje Response-PDU: SNMP menadžer obrađuje informacije iz pristigle Response-PDU poruke u cilju saznavanja rezultata tog seta.

Slika 3.5 Proces modifikacije SNMP objekata

3.7.8 Verifikacija zahtjeva za izmjenu objekata

Naredba uređaju da izmijeni svoju varijablu je dosta značajniji proces od samog zahtjeva za očitanje vrijednosti te varijable. Iz ovog razloga, uređaj mora sa oprezom analizirati i verifikovati informacije da bi se osigurala validnost zahtjeva. Provjere koje je potrebno izvršiti su:

Verifikacija naziva objekata nad kojima se vrše izmjene

Verifikacija da li je nad objektima dozvoljeno vršenje izmjena (bazirano na Access ili Max-Access karakteristikama objekata)

Provjera veličine i tipa vrijednosti iz zahtjeva da bi se osigurala validnost parametara 3.7.9 Notifikacije o informacijama SNMP protokola korištenjem Trap(v2) i InformRequest poruka

Drugi način razmjene informacija između SNMP uređaja je Interrupt-driven metoda. Do sada je bilo govora o tipovima poruka koje koristi poll-driven metoda, proces u kojem SNMP menadžer pravi poseban zahtjev, koji rezultira odgovorom SNMP agenta.

Polling je idealan za razmjenu rutinskih informacija koje je potrebno redovno sakupljati. Npr. GetRequest poruke se mogu koristiti da bi se potvrdile postavke na uređaju, analizirao broj grešaka u određenom vremenskom periodu, ili provjerile druge statistike tokom rada uređaja. Također, polling je jedini metod za operacije postavljanja vrijednosti, tj. njihovu izmjenu.

Za važne informacije koje zahtijevaju brzu razmjenu, polling metoda ne pokazuje dobre rezultate, s obzirom da poll-driven komunikaciju inicira SNMP menadžer – onaj kojem su te informacije potrebne. U slučaju da se na uređaju desi nešto neočekivano, menadžer o tome neće ništa saznati ukoliko ne napravi zahtjev za informacije o konkretno toj varijabli.

U stvarnom svijetu bi se primjena ovakve metode mogla uporediti sa primjerom hitne pomoći, koja bi svaki sat pozivala sve stanovnike da bi saznala da li je potrebno nekome poslati ambulantna kola. Iz sličnih razloga je u SNMP-u bilo potrebno implementirati mehanizam koji bi SNMP agentu omogućio inicijaciju saobraćanja informacija. Ovo je isprva omogućeno u SNMPv1 protokolu, uvođenjem Trap-PDU poruka.

Trap je set okolnosti koje uređaj kontinuirano nadgleda. U slučaju da dođe do određenog seta okolnosti, trap se okida i rezultuje slanjem Trap-PDU poruke koja sadrži informacije o promjenama SNMP menadžeru. Primjeri trap-ova u SNMPv1 su oni okinuti pojavama pada komunikacijskog linka, restartovanja uređaja, ili problema pri autentikaciji.

Komunikacija u slučaju trap poruke je trivijalna; SNMP agent šalje trap, i time je SNMP menadžer obaviješten o nastalim dešavanjima. Ove poruke spadaju u klasu Unconfirmed, tj. nepotvrđenih poruka, nikakve povratne informacije se ne šalju SNMP agentu.

Implementacija trap poruka podrazumijeva specifikaciju okolnosti pod kojim dolazi do okidanja trap-a, kao i destinaciju na koju se šalje Trap-PDU poruka. U SNMPv2, originalna trap notifikaciona poruka je održana u formi Trapv2-PDU poruke. 3.7.10 Upotreba SNMPv2 InformRequest poruka

SNMP sadrži još jedan tip notifikacijskih poruka – InformRequest-PDU. Ovaj tip poruka je srodan tipu trap poruka iz dva razloga. Oba tipa poruka se koriste pri komunikaciji koja inicirana od strane SNMP menadžera, i one se ponekad koriste zajedno.

Svrha InformRequest-PDU poruka je zapravo omogućavanje saobraćanja informacija između stanica za upravljanje mrežom. SNMP menadžer na jednom NMS-u može informisati drugog menadžera o određenom dijelu informacija slanjem InformRequest-PDU poruke. Menadžer koji primi InformRequest-PDU, vraća Response-PDU kao potvrdnu informaciju. 3.7.11 Generisanje SNMP poruka, adresiranje, transport i retransmisija

U prethodnim poglavljima je bilo govora o logičkim procesima koji koriste SNMP poruke za razmjenu informacija za upravljanje mrežom. Potrebno je razmotriti niži nivo detalja o načinu na koji SNMP uređaji te poruke kreiraju, adresiraju i šalju.

Generisanje SNMP poruka je nešto drugačije od standardog TCP/IP klijent/server modela koji koristi većina protokola. U SNMP-u ne postoje formalni „klijenti" i “serveri”, kako informacije za upravljanje mrežom mogu biti dobijene od bilo kojeg uređaja, tj. one su distribuisane. Većina razmijenjenih poruka koristi par poruka u vidu zahtjeva i odgovora. Network management station (NMS) najčešće igra ulogu klijenta u ovim razmjenama, a SNMP agent ulogu servera, iako se oni obično ne smatraju serverima u konvencionalnom smislu.

SNMP trap poruke ne pripadaju modelu zahtjev-odgovor. Kako za njih se ne vraća potvrda prijema, one pripadaju klasi Unconfirmed (nepotvrđenih) poruka. SNMPv2/v3 InformRequest-PDU poruka ima povratnu informaciju koja se šalje NMS-u koji je generiše. 3.7.12 Prenos SNMP poruka korištenjem UDP-a

Nakon što je SNMP poruka kreirana, ona se šalje pomoću protokola na slojevima nižim od aplikacijskog, na kojem je sami SNMP. Definisano je više načina prenosa na koji se SNMP PDU-ovi mogu poslati preko različitih protokol stogova, uključujući TCP/IP, OSI, IPX/SPX (Novell) i Appletalk.

Sadržaj SNMP poruka ovise o izabranom načinu prenosa odabranom pri implementaciji. Najčešće se koristi TCP/IP model, koji kao transportni protocol za SNMP poruke koristi UDP. UDP (User Datagram Protokol) je odabran zbog visoke efikasnosti pri prenosu jednostavnih

request/reply poruka, kako su široke mogućnosti koje nudi TCP nepotrebne, i dodaju redundansu koju su projektanti željeli da izbjegnu.

Za SNMP rezervisana su dva poznata UDP porta. Port 161 služi za opštu upotrebu, na kojem SNMP agent i menadžeri osluškuju dolazak SNMP zahtjeva. Drugi port broj 162 je rezervisan za SNMP trap-ove, koje osluškuju NMS-ovi, kako agenti ne primaju trap poruke.

Korištenje UDP-a omogućava brzu razmjenu SNMP informacija, kako nema potrebe za konekcijskom komunikacijom koju pruža TCP. Time su i zaglavlja poruka kraća, kao i vrijeme potrebno za prenos informacija. 3.7.13 Format i definicija polja SNMP poruka

U SNMP-u se ne koriste uobičajena polja za opisivanje poruka, kao što je to slučaj za većinu TCP/IP standarda. SNMP poruke se definišu korištenjem ASN.1 (Abstract Syntax Notation) jezika za opis podataka , koji se koristi i za opis MIB objekata. Razlog za ovakav pristup leži u činjenici da SNMP poruke implementiraju različite aktivnosti SNMP protokola, sa krajnjim ciljem prenosa MIB objekata između SNMP entiteta. Ovi MIB objekti postaju polja unutar poruka koje je potrebno poslati.

Kako su MIB objekti definisani korištenjem ASN.1 na način opisan SMI stadardom, ima smisla definisati i SNMP poruke i sva polja unutar njih korištenjem iste sintakse. S obzirom na prethodno, polja SNMP poruka se ponašaju kao objekti koji imaju određene karakteristike. Konkretno, svako polje ima naziv, i njegov sadržaj je opisan korištenjem nekog od uobičajenih SMI tipova podataka. Za razliku od uobičajenih formata poruka, gdje je svako polje opisano samo nazivom i dužinom, polje SNMP poruke je opisamo nazivom i sintaksom, kao npr. Integer, Octet String ili IpAddress. Sintakasa polja definiše njegovu dužinu, format i način na koji se koristi. Primjer polja Error Status, predstavlja status grešaka, gdje bi rangom Integer (cjelobrojnih) vrijednosti bili predstavljena različita stanja eventualnih grešaka. 3.7.14 Opšti format SNMP poruka

Za razumijevanje SNMP poruka, važno je napraviti razliku između SNMP poruka i SNMP PDU-ova. U dosadašnjem tekstu su se ova dva pojma koristila naizmjenično, kako svaka poruka nosi jedan PDU, a PDU je najvažniji dio poruke. Striktno posmatrajući, SNMP poruka i PDU nisu jedno te isto. PDU je zapravo informacija koja se razmjenjuje između SNMP entiteta, koja se nalazi unutar SNMP poruke. Poruka sadrži dodatna polja, tj. zaglavlja koja nose identifikacione i sigurnosne informacije. Konceptualno, SNMP poruka je sastavljena iz dva dijela:

Zaglavlje: Sadrži polja pomoću kojih se određuje način obrade poruke, i polja u kojima su implementirane sigurnosne informacije SNMP protokola.

Tijelo (PDU): Polje u kojem je sadržana većina poruke, tj. PDU koji se prenosi.

3.7.15 Opšti format PDU-a

Polja unutar svakog PDU-a generalno zavisi od tipa PDU-a, ali općenito, struktura je podijeljena na dva dijela:

PDU Control Fields: Set kontrolnih polja koja opisuju PDU i dostavljaju informacije od jednog do drugog SNMP entiteta

PDU Variable Bindings: Set koji sadrži opis MIB objekata unutar PDU-a. Svaki objekat je opisan kao “veza” naziva sa njegovom vrijednošću.

Svi PDU-ovi imaju ovakvu opštu strukturu, a jedino se razlikuju u broju kontrolnih polja, broju

“veza” varijabli i načinu na koji se koriste. Opšti format SNMP poruke je prikazan na narednoj slici.

Slika 3.6 Opšti format SNMP poruka Svaki variable binding opisuje jedan MIB objekat. Binding sadrži par podpolja, jedno specifikuje ime objekta iz standardnog sistema obilježavanja SNMP identifikatora objekata, a drugo njegovu vrijednost, formatiranu po pravilima SMI sintakse. Npr. ako je posmatrani objekat tipa Integer, vrijednost polja bi bila dužine 4 bajta i sadržavala bi određenu cjelobrojnu numeričku vrijednost.

3.7.16 Format SNMPv3 poruka

SNMPv3 je nastao u kasnim devedesetim, kao rješenje problema koji su se pojavili zajedno sa mnoštvom varijacija SNMPv2. SNMPv3 Framework je prihvatio mnoge komponente druge verzije ovog protokola, uključujući SNMPv2 rad protokola, tipove PDU-ova i njihov format. Među značajnijim promjenama u SNMPv3 je uvedeno fleksibilno rješenje za definisanje sigurnosnih metoda i parametara, kao i postojanje nekoliko sigurnosnih tehnika istovremeno.

Format SNMPv3 poruke prati generalni koncept koji sadrži zaglavlje i enkapsulirani PDU. Razlika je u poljima zaglavlja, koja se sada dijele na polja koja se bave sigurnosnim pitanjima i ona koja se istim ne bave. “Nesigurnosna” polja su za jednička za sve SNMPv3 implementacije, dok su sigurnosna polja posebno krojena prema svakom SNMPv3 sigurnosnom modelu. [7] Cjelokupni format SNMPv3 poruka je opisan u [11]

Slika 3.7: SNMPv3 opšti format poruka

4. Open source alat Nagios

Nagios je open source rješenje, softverska aplikacija za nadzor mreža i mrežne infrastrukture. Prvobitno nazvan NetSaint, promijenio je ime nakon pravnog spora sa vlasnicima sličnog zaštitnog znaka, nakon čega biva preimenovan u Nagios – rekurzivni akronim: „Nagios Ain’t Gonna Insist On Sainthood”, što u bukvalnom prevodu znači Nagios neće insistirati na svetosti. I “Agios” – svetac, se odnosi na grčku riječ άγιος, što je također referenca na “sveto” prvobitno ime. [12]

Nagios je besplatni alat koji se najčešće koristi na Linux operativnim sistemima, iako se može koristiti i n a Unix-u.

4.1 Instalacija i konfiguracija Nagios-a

Iako je Nagios alat moguće instalirati na mnoštvu operativnih sistema, najčešće se koristi Linux

CentOS. U ovoj praktičnoj izvedbi je korištena i Oracle VM virtuelna mašina, koja je dostupna na web stranici:

http://virtualboximages.com/CentOS+6.5+i386+Desktop+VirtualBox+VDI

Slika 4.2: Interfejs CentOS mašine

Nakon što su interfejsi podešeni na NAT, mašina je dobila pristup Internetu preko svoje vanjske konekcije. Na službenoj stranici:

http://library.nagios.com/library/products/nagiosxi/downloads/main nalazi se paket:

xi-2014r1.4.tar.gz koji je objavljen 14. 8.2014 godine, te predstavlja najnoviju i najbolju verziju ovog alata dostupnog kao open-source. Nakon se što se uradi download tar.gz formata paketa potrebno je u terminal upisati sljedeće naredbe za instalaciju alata:

Slika 4.2 Uspješno instaliran NAGIOS alat

cd Downloads mv xi-2014r1.4.tar.gz /tmp cd tmp tar -zxvf xi-2014r1.4.tar.gz su root adminuser ./fullinstall

Na narednim slikama dat je prikaz web-baziranog interfejsa koji Nagios ima, te koraka koje je potrebno izvršiti kako bi se na pravilan način izvršila početa instalacija.

Slika 4.3 Završen process instalacije Nagios XI i pristupni podaci Po ispravnoj instalaciji Nagios alata, dobiju se jedinstveni pristupni podaci:

username: nagiosadmin password: hkd842

Nakon logovanja na NAGIOS vrši se konfiguracija na način da se definiše nad kojom vrstom servera će se vršiti monitoring, te na kojoj adresi se nalaze hostovi koji se žele posmatrati.

Dalje postavke će biti predstavljene isključivo u vidu slika, objašnjenja procedura su trivijalna.

Slika 4.4: Konfiguracija Nagios-a

Slika 4.5 Odabir Linux servera

Slika 4.6: Unos podataka o Linux serveru

Slika 4.7 Postavke Linux Agenta

Slika 4.8 Wizard na kraju unosa podataka o hostu

4.2 Instalacija Nagios NRPE-a na LINUX hostu

Kako bi se nad nekim LINUX hostom mogao izvršiti monitoring, potrebno je izvršiti instalaciju NRPE Remote servera i izvršiti podešavanje podataka o odgovarajućem monitoring serveru. (Nagios Remote Plugin Executor) dodatak, koji je dizajniran da omogući Nagios plugin-e na udaljenim Linux/Unix mašinama. Glavni razlog uvođenja ovog dodatka je da se dozvoli Nagiosu nadgledalnje lokalnih resursa (npr. opterećenje CPJ, iskorištenost memorije i sl.) na udaljenim mašinama. Kako ovi resursi obično nisu pristupačni eksternim mašinama, potrebno je instalirati NRPE agenta. [13]

U nastavku je dat niz komandi koje je potrebno unijeti u terminal:

# useradd nagios

# passwd nagios

Instalacija dodatnih plugin-a

# mkdir –p /opt/Nagios/Nagios_Plugins

# cd /opt/Nagios/Nagios_Plugins

Sa stranice:

http://www.nagios.org/download/download.php

je potrebno izvršiti download paketa nagios-plugins-1.4.13.tar.gz.

# tar xzf nagios-plugins-1.4.13.tar.gz

# cd nagios-plugins-1.4.13

nakon čega se vrši kompajliranje i instalacija:

# yum –y install openssl-devel

# ./configure –with-nagios-user=nagios –with-nagios-group=nagios

# make

# make install

# chown nagios.nagios /usr/local/nagios

# chown –R nagios.nagios /usr/local/nagios/libexec

Potrebno je instalirati i xinetd paket, koji nije uključen u originalnu instalaciju:

# yum install xinetd

Potom je potrebno instalirati NRPE # mkdir –p /opt/Nagios/Nagios_NRPE

# cd /opt/Nagios/Nagios_NRPE Sa stranice:

http://www.nagios.org/download/download.php

je potrebni izvršiti download paketa NRPE 2.12

# tar –xzf nrpe-2.12.tar.gz

# cd nrpe-2.12 Potrebno je instalirati i podršku za sigurnu ssl konekciju: # yum –y install openssl-devel

Instalacija NRPE-a se vrši komandom: # ./configure

General Options:

-------------------------

NRPE port: 5666

NRPE user: nagios

NRPE group: nagios

Nagios user: nagios

Nagios group: nagios

# make all

# make install-plugin

# make install-daemon

# make install-daemon-config

# make install-xinetd

Potrebno je promijeniti adresu monitoring servera, te dodati servise:

# vi /etc/xinetd.d/nrpe

only_from = 127.0.0.1 <nagios_ip_address>

# vi /etc/services

nrpe 5666/tcp # NRPE

Potom je potrebno restartovati xinetd servis.

# chkconfig xinetd on

# service xinetd restart

Nakon što je sve uspješno instalirano potrebno je testirati NRPE:

# netstat –at |grep nrpe

Slika 4.9 NRPE uspješno osluškuje za SNMP saobraćaj

4.3 Nagios online demo U prethodnom poglavlju je pokazano kako se instalira Nagios i kako se može dodati vlastiti host koji je potrebno nadgledati. Pri odabiru rada sa online demo-om nad virtuelnom mašinom, prevagnula je činjenica da online demo koristi stvarne sisteme, koje nadgleda u realtime-u.

iosxi.demos.nagios.com

Slika 4.10 Ponuđene pristupne opcije za Nagios XI Demo

Nakon login-ovanja, pristupa se interfejsu za nadzor. Nadgledani hostovi i informacije o

njima su date sljedecom slikom:

Slika 4.11 Nadgledani hostovi i osnovni monitoring podaci

Klikom na bilo koji od hostova, otvara se detaljniji opis monitoring informacija, koje sadrže IP adresu hosta, status, trajanje nadzora, stabilnost hosta, posljednju kao i narednu zakazanu provjeru, i eventualne bilješke o tom hostu. Prikazane su i Quick Actions opcije, koje nude nekoliko brzih akcija koje se mogu izvršiti nad hostom, poput pinga, ili trenutne provjere hosta iako je ta provjera prije zakazane regularne. Npr. informacije o ruteru su prikazane na sljedeći način:

Slika 4.12 Detaljne informacije o hostu “Router”

Prikazano je i izvršenje brze akcije ping nad ovim ruterom.

Slika 4.13 Ping odziv rutera

Sada slijedi prikaz Operations Center-u, u kojem su prikazane greške i problem koji su

otkriveni nad servisima pokrenutim na hostovima:

Slika 4.14 Statusne informacije o problemima sa servisima

Hostovi su podijeljeni u grupe hostova, koji se mogu vidjeti u Hostgroup pregledu. Grupe hostova, kao i vrste nadziranih servisa su prikazani ne sljedećoj slici:

Slika 4.15 Grupe hostova i servisi na njima

Također, nudi se i pregled statističkih podataka, npr. dostupnost hostova i servisa u

vremenskom razmaku od 24h, kao i histogram u kojem je prikazana raspodjela upozorenja kroz sate.

Slika 4.16 prikaz dostupnosti hostova i servisa

Slika 4.17: Histogram upozorenja

Nagios je moćan alat koji nudi još mnoštvo mogućnosti za nadzor, konfiguraciju, pa čak i planiranje proširenja mreže.

5. Zaključak Cilj ovog BSc rada je nadzor jednostavne mreže pomoću open source alata Nagios. Kroz rad je detaljno objašnjen protokol koji omogućava komunikaciju nužnu za taj nadzor, SNMP protokol. S obzirom da je Nagios, kao i svaki open source alat, podložan konstantnim izmjenama i dopunama, što od strane Nagios radne grupe, što od strane korisnika, implementacija ovog sistema na Linux OS može biti izazov. Naravno, svaka mreža je jedinstvena, te samim tim i izazovi stavljeni pred administratora mreže su uvijek novi, a situaciju još gorom pravi činjenica da je i broj samih Linux operativnih Sistema poprilično velik, i ovisno i od izbora OS-a se mijenjaju načini instalacije, konfiguracije i implementacije. Metodom “trial and error” se postižu rezultati, uz nešto više vremena, i još više nerava, a garantovana formula za uspjeh teško da može biti predstavljena. Satisfakcija nakon što se hostovi odazovu na ping se može uporediti sa rođenjem djeteta, sve prethodne muke bivaju istog trenutka zaboravljene, jer prvi korak ka uspješnom nadzoru mreže i mrežne infrastructure je uspješno izvršen, i može se preći na konkretnije implementacije. Ova grana telekomunikacija je od ogromnog interesa, jer značaj mreža i potreba za istim mogu samo rasti, samim time se komplikuje i posao mrežnih administratora, što meni, kao autorici ovog BSc rada predstavlja jedinu sferu interesovanja.

REFERENCE [1] – RFC3139 [2]– RFC2975 [3] – James Kurose, Keith Ross, Computer Networking, A top-down approach, 6th edition, 2013. [4] – RFC1028 [5] – A. Tanenbaum, Computer Networks, 5th edition, 2011. [6] – William Stallings, Data and Computer Communications, 8th edition, 2007. [7] – Charles M. Kozierok, The TCP/IP Guide, ver.3, 2005. [8] – RFC 1066 [9] – RFC 1156 [10] – RFC 1158 [11] – RFC 3412 [12] – http://www.nagios.org/about/history [13] – http://nagios.sourceforge.net/docs/nrpe/NRPE.pdf