SVEUČILIŠTE U ZAGREBU

FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

Zavod za telekomunikacije

Kolegij: Osnove upravljanja mrežom

SEMINARSKI RAD

SNMPv3 - SIGURNOSNI MEHANIZMI Ivan Babić

Zagreb, siječanj 2007.

SADRŽAJ

1 UVOD....................................................................................................................3

2 OSNOVNI SNMP KONCEPT - (BASIC SNMP CONCEPTS) ......................5

3 SNMP ARHITEKTURA .....................................................................................6

3.1 SNMP entitet..................................................................................................6

3.2 TRADICIONALNI SNMP AGENT..............................................................9

3.3 OBRADA PORUKA I USM .......................................................................10

3.4 USER-BASED SECURITY MODEL (USM) ..........................................11

3.4.1 Kriptografske funkcije .........................................................................12

3.4.2 PARAMETRI USM PORUKE............................................................13

3.4.3 USM MEHANIZMI VREMENSKOG TOKA (TIMELINES)...........15

4 VIEW-BASED ACCESS CONTROL MODEL..............................................17

4.1 PROCESIRANJE KONTROLE PRISTUPA ..............................................18

5 ZAKLJUČAK ....................................................................................................20

6 LITERATURA ...................................................................................................20

2

1 UVOD

SNMP (Simple Network Management Protocol)je razvijen 1988 godine i postao je

najrašireniji mrežno upravljački alat za TCP/IP mreže. On definira format za

prikazivanje upravljačkih informacija

SNMP je najkorišteniji mrežno upravljački protokol u TCP/IP mrežama. Sama

funkcionalnost SNMPv1 je potaknula razvoj SNMPv2, kojem su također nedostajale

mogućnosti sigurnosne zaštite. Nakon toga je razvijen SNMPv3 koji ima razvijen

nivo sigurnosti kao što su autentikacija, privatnost i kontrola pristupa. Također

definira format prikazivanja upravljačkih informacija i okvira za organizaciju

distribuiranih sistema u upravljanim sistemima i agentima.Više specifičnih struktura

baza podataka ( Menagment Information Bases - MIB's ) je definirano kao dio SNMP

paketa. MIB's specificiraju često upravljane objekte poput bridgeva i routera.

Nagli je rast popularnosti SNMP-a pokazao nedostatke u funkcionalnosti, kao što su

prenosi veće skupine podataka i nedostatak sigurnosti (mehanizmi autentiikacije i

privatnosti ). Nadograđena verzija je SNMPv2, u kojoj je bila uključena funkcija

sigurnosti i druge mogućnosti, nikada nije bila općeprihvaćena. Ova verzija je

koristila jednostavnu i nesigurnu funkciju sa šiframa koju je uzela iz SNMPv1 verzije,

i zvala se SNMPv2c. Više nezavisnih skupina je radilo na razvoju sigurnosnog

unapređenja, SNMPv2u i SNMPv2* varijante. Sve to je dovelo do stvaranja SNMPv3

radne grupe koja je 1998. sastavila niz prijedloga ( RFC 2271-2275). Ti dokumenti su

stvorili okosnicu za razvoj SNMP sigurnosti i definirali niz pravila za mrežnu

sigurnost i kontrolu pristupa.

Broj Naslov

RFC 2271 An Architecture for Describing SNMP Management Frameworks

RFC 2272 Message Processing and Dispatching for SNMP

RFC 2273 SNMPv3 Applications

RFC 2274 User-Based Security Model for SNMPv3

RFC 2275 Introduction to Version 3 of the Internet Network

Internet Draft Introduction to v3 of the Internet Network Management framework

Tablica 1. – RFC pravila koja tvore SNMP

3

SNMPv3 nije samostalna zamjena za SNMPv1,SNMPv2, već definira sigurnosne

mogućnosti koje se mogu koristiti u spoju s SNMPv2 i SNMPv1.

Dokument RFC-2271 opisuje arhitekturu u koju se uklapaju sve dosadašnje i buduće

verzije SNMP-a. RFC-2275 opisuje mogućnost kontrole pristupa, koja je zamišljena

da radi neovisno od jezgre SNMPv3.

Slika 1.1 – SNMP paket sa sigurnosnim zaglavljem i v1 i v2 PDU dijelom

Slika 1.1 opisuje vezu između različitih verzija SNMP-a u smislu njihovog formata.

Dio vezan za procesiranje sigurnosti se odvija na nivou poruke. SNMPv3 definira

USM ( User Security Model ) koji koristi dio zaglavlja poruke (message header).

Zaglavlje poruke se sastavlja sa SNMPv1 ili SNMPv2 paketom, ( PDU - protocol

data unit). Protocol Data Unit prenosi vrstu upravljačke naredbe ( get ili set ) i listu

imena varijabli na koju se ta naredba odnosi.

Ukratko, SNMPv3 je SNMPv2 uz dodatak sigurnosti i administracije.

Slika 1.2 - arhitektura SNMP protokola

4

2 OSNOVNI SNMP KONCEPT

Osnovna ideja bilo kojeg sistema za upravljanje mrežom je postojanje dvije vrste

sistema, agenti i upravitelji. Svaki čvor u mreži s kojim se mora upravljati ( PC,

server, usmjeritelj ) sadrži agentski modul.

Agent je odgovoran za :

- sakupljanje i održavanje informacija o lokalnom okruženju, - prosljeđivanje informacija upravitelju, kao odgovor na zahtjev ili redovnu

komunikaciju - odgovaranje na upraviteljeve naredbe o promjeni lokalne konfiguracije ili nekih

parametara.

Jezgru sistema upravljanja čini niz programa koji ispunjavaju potrebe mrežnog

upravljanja. Kao najosnovije, sistem će imati osnovne programe za nadgledanje

izvođenja, konfiguracije i održavanja. Složeniji sistemi će uključivati složenije

programe i programe za sigurnosno upravljanje mrežom.

Svi mrežno upravljani programi dijele mrežno upravljivi protokol, koji im pruža

osnovne mogućnosti primanja upravljačkih informacija od agenata te izdavanja

naredbi agentima. Svaki agent održava bazu upravljačkih informacija (MIB) koja

sadrži trenutne i stare informacije o svojoj konfiguraciji i prometu. Upravljačka

stanica će održavati globalnu upravljačku bazu, MIB sa sažetkom informacija od svih

agenata.

SNMP je projektiran kao jednostavan alat za primjenu sa malom potrošnjom

procesora i mrežnih resursa. Protokol pruža četiri osnovne funkcije:Get, Set, Trap,

Inform.

GET - koriste upravitelji da bi prikupili informacije od agenata, iz MIB baze SET – Koriste upravitelji da bi upisali vrijednosti u agentovu bazu (MIB) TRAP – koriste agenti da pošalju znak uzbune upravitelju INFORM – koristi upravitelj da pošalje znak uzbune drugom upravitelju

Veliki broj standardiziranih MIB struktura daje snagu i prednost SNMP-u. Na svakom

agentu MIB diktira koje će informacije agent prikupljati i spremati.

5

Slika 2. - Mogućnosti SNMP protokola

3 SNMP ARHITEKTURA

SNMP arhitektura se sastoji od distribuiranih, međusobno povezanih SNMP entiteta.

Svaki entitet primjenjuje dio SNMP mogućnosti, te može djelovati kao agentski čvor,

upravljački čvor ili kao kombinacija toga dvoje.

RFC 2271 opisuje glavna pravila za SNMPv3

Projektirati modularnu arhitekturu koja će:

- dozvoliti implementaciju na nizu različitih okruženja, pri čemu će neki koristiti minimalnu funkcionalnost a neki će se koristiti u složenom mrežnom upravljanju

- stvoriti mogućnost napredovanja dijela arhitekture - uključiti alternativne sigurnosne modele

3.1 SNMP entitet Svaki SNMP entitet sadrži jedan SNMP Engine koji implementira funkcije slanja i

primanja poruka, autentikacijskih i enkriptirajućih poruka i kontrolu pristupa

upravljanim objektima. Ova funkcionalnost je omogućena kao servis jednom ili više

programa koji su konfigurirani sa SNMP Engine-om i čine SNMP entitet.

Uloga SNMP entiteta je određena modulima koji implementiraju taj entitet. Agent će

koristiti određeni niz modula, dok će upravitelj koristiti drugi niz.

Tradicionalni SNMP upravitelj komunicira sa agentom pomoću naredbi (get, set), i

pomoću upozorenja koje šalje agent upravitelju. On sadrži tri kategorije aplikacija.

6

Command Generator Applications nadzire i upravlja podatcima na udaljenom agentu

(Get, GetNext, GetBulk i Set).

Notification Originator Application stvara poruke, InformRequest PDU

Notification Receiver Application obrađuje dolazne poruke (InformRequest,

SNMPv2-Trap i SNMPv1 Trap PDU)

SNMP Engine obavlja dvije glavne funkcije:

- prihvaća izlazne PDU (protocol data unit) pakete od SNMP aplikacija uključujući umetanje autentikacijskog koda, enkripcije i enkapsulacije PDU-a unutar poruke

- prihvaća dolazne SNMP poruke od transportnog sloja, obavlja neophodno procesiranje uključujući autentikaciju, dekripciju i izdvajajući PDU iz poruke prosljeđuje je odgovarajućoj SNMP aplikaciji

Slika 3.- Uloga SNMP Engina

SNMP Engine još sadrži Dispatcher, Message Processing Subsystem i Security

Subsystem

Dispatcher je jednostavan upravitelj prometa, prihvaća odlazne PDU-ve od neke aplikacije i prosljeđuje je transportnom sloju za slanje.

Message Processing Subsystem prihvaća odlazne PDU-ve od Dispatcher-a i priprema ih za slanje tako da ih stavi u zaglavlje poruke (messagge header) i vraća Dispather-u. Također prima dolazeće poruke od Dispatcher-a, procesira svako zaglavlje poruke i vraća mu ih zajedno s PDU-om.

Security Subsystem obavlja autentifikaciju i enkripciju.

7

Svaku odlaznu poruku Message Processing Subsystem proslijedi Security Subsystem

dijelu. Ovisno o zahtijevanoj usluzi Security Subsystem može enkriptirati omotanu

PDU, eventualno neka polja u zaglavlju poruke i može generirati autentikacijski kod

koji stavlja u zaglavlje poruke. Obrađena poruka se vraća Message Processing

Subsystem.

Slična procedura se dešava s dolazećom porukom. Ako je potrebno Security

Subsystem provjerava autentikacijski kod i vrši dekripciju. Security Subsystem može

podržavati više sigurnosnih modela, ali je za sada jedini definirani User-Based

Security Model (USM) za SNMPv3 (definirano u RFC 2274).

Slika 3.1 - Tradicionalni SNMP upravitelj

8

3.2 TRADICIONALNI SNMP AGENT

Tradicionalni SNMP agent može sadržavati tri vrste aplikacija.

Command Responder Applications osigurava pristup upravljačkim podatcima.

Ove aplikacije odgovaraju na dolazne zahtjeve tako što dohvaćaju ili postavljaju

upravljane objekte i zatim stvaraju Response PDU.

Notification Originator Application inicijalizira asinkronu poruku, u slučaju

tradicionalnog agenta to su SNMPv2-Trap ili SNMPv1 Trap PDU.

Proxy Forwarder Application prosljeđuje poruke između entiteta.

SNMP Engine kod tradicionalnog agenta ima iste komponente kao i SNMP Engine za

tradicionalnog upravitelja, osim što mu je dodan i Access Control Subsystem. Ovaj

podsistem pruža uslugu autorizacije kontrole pristupa MIB-u za čitanje i podešavanje

upravljanih objekata. Implementacija Security Subsystem dijela može podržavati

jednu ili više različitih modela kontrole pristupa. Za sada jedini definirani sigurnosni

model je View-Based Access Control Model (VACM) za SNMPv3 (definirano u RFC

2275)

Slika 3.2 - Tradicionalni SNMP agent

Sigurnosne funkcije su organizirane u dva odvojena podsistema, sigurnost i kontrola

pristupa. To je dobar primjer modularnog dizajna, jer ta dva podsistema imaju

potpuno različitu funkciju i zato je korisno ne miješati ih i dopustiti daljnje

samostalno napredovanje. Security Subsystem je zadužen za privatnost i

9

autentikaciju, a djeluje na SNMP porukama. Access Control Subsystem je zadužen

za autorizaciju pristupa upravljačkim podatcima i djeluje na SNMP PDU-u.

. Slika 4. - SNMPv3 terminologija

3.3 OBRADA PORUKA I USM

RFC 2272 definira opći model obrade poruka. Taj model je odgovoran za primanje

PDU-va od Dispatcher-a, enkapsulirajući ih u poruku i navodeći USM da ubaci

sigurnosne parametre u zaglavlje poruke. On također prima dolazeće poruke,

prosljeđuje ih USM-u koji provjerava sigurnosne parametre u zaglavlju poruke, te

dostavlja enkapsulirani PDU Dispatcher-u.

Slika 5. prikazuje strukturu poruke. Prvih pet polja stvara model za obradu poruka na

odlaznim porukama i obrađuje model procesiranja poruka kod dolaznih poruka.

Slijedećih šest polja prikazuje sigurnosne parametre koje koristi USM. Zadnja tri

polja su PDU zajedno s contextEngineID i contextName, a tvore ograničeni PDU

korištenu za PDU procesiranje.

10

Slika 5. – Format SNMPv3 poruke s USM dijelom

3.4 USER-BASED SECURITY MODEL ( USM ) RFC 2274 definira User Security Model ( USM ). On osigurava privatnost i tehnike

autentikacije SNMP protokola.

USM primarno služi sprječavanju slijedećih prijetnji :

- IZMJENA INFORMACIJE - Treća strana bi mogla izmijeniti poruku

poslanu od strane koja upravlja komunikacijom (opremom) i time bi mogla

utjecati na sam sistem kao takav i vršiti neovlaštene izmjene postavki uređaja

ili cijelog sistema. Smisao zaštite je onemogućiti neovlaštenom tijelu izmjenu

upravljačkih parametara uključivši one koje se odnose na konfiguraciju,

operativno vođenje i naplaćivanje.

- LAŽNO PREDSTAVLJANJE - lažnim predstavljanjem u ulozi upravljačke

strane žele se promijeniti upravljačke postavke ili upravljati sistemom

(agentima)

- IZMJENA TOKA INFORMACIJA - SNMP upravlja sistemom pomoću

„nepovezanog“ transportnog protokola. Postoji opasnost od preusmjeravanja

SNMP poruka u smislu zadržavanja poruka, dupliciranja i ponovnog

korištenja poruka s ciljem neovlaštenog upravljanja uređajima.

11

Primjer: kopiranje poruke za resetiranje ili gašenje uređaja koju neovlaštena

osoba naknadno ponovo šalje.

- OTKRIVANJE PODATAKA- treća strana može promatrati komunikaciju

između upravljačkog sistema i agenta i saznati određene podatke o samom

sistemu.

Primjer: presretanje set naredbe koja mijenja šifru

USM nije namijenjen da štiti od ove dvije prijetnje :

- DoS ( Denial of Service ) napada jer takva vrsta napada ne onemogućuje samo

SNMP komunikaciju ( sistem-agent ) nego onemogućuje rad cijele mreže.

Sam sistem svakako treba biti spreman na rušenje jednog dijela mreže i mora

znati kako se ponašati u tom slučaju

- Ne onemogućuje napadaču da prati promet ( obrazac prometa ) i šablonu

komunikacije između upravljačkog sistema (menager-a) i agenta jer mnogi

sistemi komuniciraju predvidivim obrascima komunikacije.

3.4.1 Kriptografske funkcije Dvije kriptografske funkcije su definirane za USM, autentikacija i enkripcija. Da bi

podržavao ove funkcije, SNMP Engine zahtjeva dvije vrijednosti: privatni ključ

( privKey ) i autentikacijski ključ ( authKey ).

Odvojene vrijednosti ova dva ključa se održavaju za ove korisnike:

- Lokalni korisnik : svaki korisnik na tom SNMP Engine-u kojem su upravljačke operacije dozvoljene

- Udaljeni korisnik : svaki korisnik na udaljenom SNMP Engine-u za kojeg komunikacija zatražena

Ove vrijednosti su korisnički atributi spremljeni za svakog bitnog korisnika.

USM dozvoljava korištenje jednog od postojećih autentikacijskih protokola:

HMAC-MD5 i HMAC-SHA-96. HMAC koristi sigurnu hash funkciju i skriveni ključ

da bi stvorio autentikacijski kod poruke. Njegovo korištenje je popularno u internet

aplikacijama, a definiran je u dokumentu RFC 2104. Za HMAC-MD5-96, HMAC se

koristi sa MD5 hash funkcijom kao. 128 bitni authKey se koristi kao ulazna vrijednost

u HMAC algoritam. Algoritam stvara 128 bitnu vrijednost koja se skraćuje na 96 bita.

Za HMAC-SHA-96 koristi se SHA-1 hash funkcija. Algoritam stvara 160 bita dug niz

iz 160 bitnog authKey-a, koji se opet smanjuje na 96 bita ( 12 okteta ).

12

USM koristi CBC ( cipher block chaining ) mod od DES-a ( Data Encryption

Standard ) za enkripciju. 128 bitni privKey se koristi kao ulazna vrijednost

enkripcijskog protokola, prvih 64 bita privKey-a se koriste kao DES ključ. DES

koristi samo 56 bitni ključ , pa se najmanje važan bit svakog okteta ignorira. Za CBC

mode 64 bitni inicijalizacijski vektor ( IV ) je potreban pa se zadnja 64 bita privKey-a

koriste za to.

3.4.2 PARAMETRI USM PORUKE

Kada je odlazna poruka proslijeđena USM-a od Message Processor-a, USM

ispunjava sigurnosna polja unutar zaglavlja poruke.

Kada je dolazna poruka proslijeđena USM-u od Message Processor-a USM obrađuje

vrijednosti pohranjene unutar sigurnosnog dijela zaglavlja poruke.

SIGURNOSNE PORUKE :

msgAuthoritativeEngineID: ime pošiljatelja (Trap, Response, or Report ) ili odredišta (Get, GetNext, GetBulk, Set, or Inform.)

msgAuthoritativeEngineBoots: brojčana vrijednost koliko puta se SNMP engine inicijalizirao i reinicijalizirao od početne konfiguracije

msgAuthoritativeEngineTime: broj sekundi od zadnje promjene snmpEngineBoots-a msgUserName: ime korisnika koji šalje poruku msgAuthenticationParameters: vrijednost je NULL ako se ne koristi autentikacija,

inace je autentifikacijski parametar msgPrivacyParameters: vrijednost je NULL ako enkripcija ne koristi, inače je

enkripcijski parametar

Prilikom slanja poruke prvo se vrši enkripcija, ako je zatražena. ScopedPDU je

enkriptiran i stavlja se u poruku, a msgPrivacyParameters se postavlja na vrijednost

potrebnu da se „initialization vector“ (IV) generira. Potom se ako je potrebno izvrši

autentikacija. Cijela poruka se ubacuje u HMAC ( koristi sigurnu hash funkciju i

skriveni ključ da stvori autentikacijski kod poruke ) a rezultirajući autentikacijski kod

se stavlja u msgAuthenticationParameters, slika 6.

13

Slika 6. - Procesiranje odlazne USM poruke

Nad dolazećom porukom prvo se izvršava autentikacija ako je korištena. USM

provjerava dolazeći MAC sa vrijednošću koju je sam izračunao. Ako se vrijednosti

poklapaju može se pretpostaviti da je poruka autentična i da dolazi od navedenog

izvora i nije mijenjana na putu. USM još provjerava da li je poruka stigla u

određenom vremenskom periodu. Ako nije stigla u navedenom vremenskom periodu

cijela poruka se odbacuje kao neautentična. Na kraju ako je scopedPDU enkriptiran

USM vrši dekripciju i vraća običan tekst, slika 6.1.

Slika 6.1 - Procesiranje dolazne USM poruke

14

3.4.3 USM MEHANIZMI VREMENSKOG TOKA ( TIMELINES ) USM sadrži mehanizme vremenskog toka koji štite sistem od kašnjenja poruka i

odgovora poruka. SNMPv3 nalaže da poruka mora biti primljena u određenom

vremenskom okviru i time onemogućava kašnjenje dolaska poruke i mogućnosti

napada pomoću poruke odgovora ( replay attack ).

Vremenski prozor treba biti najmanji mogući. Dovoljno velik da autentična poruka

može doći, a opet dovoljno mali da neautentične poruke ne mogu proći.

Dolazeća poruka se klasificira kao poruka izvan vremenskog okvira ako je barem

jedna od slijedećih stavki točna:

- snmpEngineBoots = 231 – 1

- msgAuthoritativeEngineBoots ≠ snmpEngineBoots

- the value of msgAuthoritativeEngineTime differs from

that of snmpEngineTime by more than ±150 s

Ako se poruka nalazi izvan vremenskog okvira, poruka pogreške se vraća pozivnom

modulu notInTimeWindow. Sinkronizacija i provjera vremenskog okvira se izvršava

samo ako je aktivan servis autentifikacije i poruka je autentična.

KEY LOCALIZATION

Da bi se uspostavila veza i komunikacija između autenticirane i neautenticirane strane

potrebno je da dijele skriveni autentikacijski i skriveni privatni ključ. RFC 2274 pruža

detaljnu specifikaciju o stvaranju i korištenju autentikacijski i privatnih ključeva.

Kako bi se pojednostavila kordinacija s ključevima svaki korisnik ima samo jedan

autentikacijski i ekripcijski ključ. Oni se ne spremaju u MIB, niti su dohvatljivi putem

SNMP-a.

15

Korisnikova šifra je se pretvara u ključ na način da:

1. korisnikova šifra se ponavlja dovoljno puta da bi se stvorio string digest0

duljine 210 okteta

2. ako je potreban 16 okteta dug ključ primjenjuje se MD5 hash algoritam nad

digest0 stringom da bi se stvorio string digest1, a ako je potreban string

duljine 20 okteta koristi se SHA-1 hash.

Izlazni string je korisnički ključ digest1. Ova tehnika stvaranja korisničkog ključa

usporava i onemogućava pokušaj nasilnog probijanja šifre (brute-force dictionary

attack ) zbog same dugotrajnosti stalnog stvaranja i pokušavanja korištenja ključa.

Također ne postoji potreba za spremanjem korisničkog ključa jer se on generira

pomoču korisničke šifre u trenutku kada postoji potreba za provjerom. Da se ključevi

čuvaju u centraliziranoj bazi skrivenih ključeva postojala bi mogućnost nedostupnosti

samoj bazi a time i ne mogućnosti funkcioniranja cijelog sistema. Ako bi se održavalo

više takvih baza time bi se povećavala opasnost od napada na bazu. Jedna šifra bi se

mogla koristiti za autentifikaciju i enkripciju, ali je sigurnija varijanta kada se jedna

šifra koristi za generiranje autentificirajuceg ključa a druga za enkripcijski ključ

Slika 7. - Key localization

Svaki SNMP agent ima jedinstven ključ za svakog korisnika koji moze upravljati tim

agentom. Ako više korisnika upravlja agentom tada SNMP agent ima jedinstveni

autentikacijski i enkripcijski ključ za svakog korisnika. Ako je ključ jednog korisnika

otkriven ključevi drugih korisnika su sigurni i neotkriveni. Korisnik koji upravlja sa

više agenata posjeduje jedinstven ključ za svakog agenta kojim upravlja.

16

4 MODEL KONTROLE PRISTUPA

Kontrola pristupa je sigurnosna stavka na PDU nivou. Ona odlučuje da li je pristup i

manipulacija lokalnim MIB-om od strane udaljenog upravitelja dopuštena.

SNMPv3 dokumenti definiraju view-based access control ( VACM ) model.

VACM (view based access control model) čine dvije bitne karakteristike:

- odlučuje da li je pristup objektu u lokalnom MIB-u dopušten ili ne

- koristi MIB da bi definirao kontrolu pristupa za agenta i dopušta konfiguraciju

udaljenog objekta

4.1 Elementi udaljenog objekta

RFC 2275 definira pet elemenata koji čine VACM: grupu, sigurnosni nivo, kontekst,

MIB view i pristupnu politiku.

GRUPE – su skupine <securityModel, securityName> parova u čije ime se SNMP

objektima može pristupiti. securityName se odnosi na vrstu pristupa i pristupna

pravila. Koncept grupe je koristan način grupiranja upravitelja ( manager-a ) s

obzirom na pravila pristupa ( access rights ). Jedna grupa može imati sva prava

pristupa i izmjene, dok druga grupa može biti ograničena samo na jedan dio prava.

Kombinacija securityModel i securityName može biti dodijeljena samo jednoj grupi.

NIVO SIGURNOSTI – Prava pristupa za grupe mogu odstupati ovisno o razini

zaštite poruke koja sadržava čitanje zahtjev. Agent može dopustiti pristup samo za

čitanje ali za pisanje će tražiti autentikaciju. Kasnije agent može zahtijevati da

osjetljivije poruke koje se razmjenjuju budu privatne i zaštićene.

KONTEKST - MIB kontekst je podskup instance objekata u lokalnom MIBu.

Kontekst pruža korisnu mogućnost stavljanja objekata u grupu ( collection ) s

različitim politikama privatnosti. Kontekst je koncept koji se odnosi na kontrolu

pristupa.

17

SNMP entitet jedinstveno identificiran od strane contextEngineID može imati više od

jednog konteksta. Objekat ili instance objekta može se pojaviti u više od jednom

kontekstu. Kada postoji višestruki kontekst, da bi identificirali objekat njegov

contextName i contextEngineID moraju biti identificirani u skladu s vrstom objekta i

njegovom instancom.

MIB pregledi ( views ) - SNMPv3 koristi koncept podstabla (subtree ). Podstablo je

jednostavan čvor u hijerarhiji imenovanja MIB-a.

SNMPv3 sadrži koncept podstabla. Podstablo je čvor u MIB-voj hijerarhiji

imenovanja i svih njegovih podređenih elemenata. Povezano sa svakom stavkom u

vacmAccesstable postoje tri MIB view-a, jedan za svako čitanje, pisanje i pristupnu

obavijest ( notify access ). Svaki MIB pregled se sastoji od niza “view” podstabla.

Svako “view” podstablo u MIB pregledu u je definirano kao uključeno ili isključeno.

MIB view ili uključuje ili isključuje sve instance objekta sadržane u tom podstablu.

VACM omogućava SNMP Engine-u da se konfigurira tako da pruža niz pristupnih

pravila.

4.2 PROCESIRANJE KONTROLE PRISTUPA SNMP aplikacija poziva VACM preko isAccessAlowed primitiva sa ulaznim

parametrima securityModel, securityName, securityLevel, viewType, contextName i

variableName. Svi ovi parametri su potrebni da se donese odluka kontrole pristupa.

Access Control Subsystem je definiran da pruža fleksibilan alat za konfiguraciju

kontrole pristupa agentu, tako da je odluke o kontroli pristupa podijelio u šest

odvojenih varijabli.

- who : kombinacija securityModel-a i securityName definira čija komunikacija

je zaštićena securityModelom

- where : contexName specificira gdje se željeni objekat nalazi

- how : kombinacija securityModel-a i securityLevel-a definira kako je ulazni

zahtjev ili Inform PDU zaštićen

18

- why : viewType specificira kako je pristup zatražen, za čitanje, pisanje ili

operaciju obavijesti. Odabrana stavka i vacmAccessTable sadrži jedan MIB

viewName za svaku od ove tri operacije

- what : variableName je objekat čiji prefiks identificira tip objekta a sufiks

instancu objekta. Tip objekta kazuje koja je vrsta upravljačke informacije

zatražena

- which : instanca objekta govori koji stvar od informacije je zatražena

Na kraju variableName je uspoređen sa pribavljenim MIB view-om, i ako se

vrijednosti podudaraju pristup je dozvoljen.

Koncept koji tvori VACM je rezultat kompleksnih definicija kontrole pristupa.

VACM stavlja sve koncepte iz SNMPv1 i SNMPv2c u odvojene varijable i time

smanjuje zauzeti prostor i procesne zahtjeve agenta.

Slika 8. prikazuje odnos ulaznih varijabli i kako se donosi odluka o kontroli pristupa.

Slika 8. - VACM logika

19

5 ZAKLJUČAK

Pojava SNMPv2 bila je bitan napredak u odnosu na SNMPv1, zadržavajući smisao,

bit i jednostavnost primjene. Verzija 2 pruža bolju podršku decentraliziranom

mrežnom upravljanju, proširuje mogućnosti izvođenja.

SNMPv3 nadopunjuje najslabiji dio prethodnih verzija, a to je sigurnost. Upotpunjava

najbitnije sigurnosne propuste koji su postojali, privatnost, autentikaciju i kontrolu

pristupa. Korisnici sada imaju upotpunjen alat koji će brzo postati standard i daljnji

razvoj će biti olakšan. Za očekivati je i pojavu novih MIB-va koji će biti definirani u

SNMPv3 okviru u cilju proširenja podrške različitim upravljačkim mrežnim

aplikacijama.

6 LITERATURA:

- WILLIAM STALLINGS . “SNMPV3: A security enhancement for SNMP”

- Stallings, W. “SNMP and SNMPv2: The Infrastructure for Network Management.”

- Internet RFC/STD/FYI/BCP Archives (RFC 2271, 2272, 2273, 2274, 2275)

- http://www.simple-times.org

- http://www.comsoc.org/pubs/surveys

- http://www.simple-times.org

20