UNIVERZA V MARIBORU FAKULTETA ZA ELEKTROTEHNIKO, RAČUNALNIŠTVO IN INFORMATIKO Renato Mikša PROTOKOL SNMP IN NAMESTNIŠKI STREŢNIK Diplomska naloga Mari

Transkripcija

1 UNIVERZA V MARIBORU FAKULTETA ZA ELEKTROTEHNIKO, RAČUNALNIŠTVO IN INFORMATIKO Renato Mikša PROTOKOL SNMP IN NAMESTNIŠKI STREŢNIK Diplomska naloga Maribor, september 2008

2 i UNIVERZA V MARIBORU FAKULTETA ZA ELEKTROTEHNIKO, RAČUNALNIŠTVO IN INFORMATIKO 2000 Maribor, Smetanova ul. 17 Diplomska naloga visokošolskega strokovnega študijskega programa PROTOKOL SNMP IN NAMESTNIŠKI STREŢNIK Študent: Renato MIKŠA Študijski program: visokošolski strokovni, Računalništvo in informatika Smer: Programska oprema Mentor: izr. prof. dr. Božidar POTOČNIK Maribor, september 2008

3 ii ZAHVALA Zahvaljujem se mentorju dr. Boţidar Potočniku za pomoč in vodenje pri opravljanju diplomske naloge. Prav tako se zahvaljujem zaposlenim v podjetju MG-Soft, za pomoč pri programski izvedbi produkta. Posebna zahvala velja staršem, ki so mi omogočili študij.

4 iii PROTOKOL SNMP IN NAMESTNIŠKI STREŢNIK Ključne besede: protokol SNMP, namestniški streţnik, oddaljena diagnostika, preizkušanje programske opreme UDK: (043.2) Povzetek Danes se srečujemo z ogromnim številom različnih računalniških naprav, ki potrebujejo določen nadzor. Komunikacija med nadzorovano in nadzorno napravo pa seveda mora potekati po določenem, vnaprej predpisanem protokolu. To je bila glavna motivacija za nastanek in razvoj protokola SNMP (Simple Network Management Protocol). Danes obstajajo že tri različice in množica podrazličic protokola SNMP, pri čemer različica 1 ne zagotavlja nikakršne varnosti in zasebnosti pri komunikaciji, medtem ko različica 3 lahko zagotovi popolno varnost in zasebnost med komuniciranjem. Cilj te diplomske naloge je bil podrobno preučiti protokol SNMP in razviti namestniški strežnik, ki zna delati s tem protokolom in pretvarjati sporočila med različnimi verzijami protokola SNMP, in sicer med različicami 1, 2c in 3. Naš razviti namestniški strežnik smo temeljito preizkusili s klasičnimi metodami preizkušanja programske opreme. Pravilnost delovanja tega programskega produkta smo potrdili na nekaj testnih primerih. Ob tem smo pregledali še področja v industriji, kjer se protokol SNMP že s pridom uporablja. Analizirali in raziskali smo tudi trg, kjer smo ugotovili, da programski produkt, ki bi imel vso funkcionalnost našega namestniškega strežnika, še ne obstaja. Naš izdelek se trenutno nahaja v testiranju pri določenih končnih uporabnikih. Prve povratne informacije so pozitivne, saj kažejo na veliko zadovoljstvo končnih uporabnikov

5 iv SNMP PROTOCOL AND PROXY SERVER Key words: SNMP protocol, proxy server, remote diagnostic, software testing UDK: (043.2) Abstract Nowadays we face an ever increasing number of computer appliances that need some kind of control. A communication between the controlling and the controlled computer device has to use a certain pre-defined protocol to be effective. This was the main motivation for an origin and development of the SNMP protocol (Simple Network Management Protocol). There exist already three versions and several sub-versions of this protocol, whereat the version 1 does not provide any privacy and safety at communication, while the version 3 guarantees a completely safe and private communication. A purpose of this diploma project was to thoroughly analyze the SNMP protocol and develop a proxy server which will be able to handle this protocol and transform messages between different versions of SNMP protocol, namely between versions 1, 2c, and 3. Our developed proxy server was thoroughly tested by using classical software testing methods. Correctness of this software was verified by several testing examples. Besides, we also surveyed fields in the industry, where SNMP protocol is already prosperously used. We analyzed and researched a targeted market for our product and found out that there exist no similar programming products, which will have complete functionality of our proxy server. We offered our software to some of the interested endusers for testing purposes. The first feedbacks are positive, namely they indicate a great satisfaction of the end-users.

6 v VSEBINA 1 UVOD PREGLED OBSTOJEČIH REŠITEV PROTOKOL SNMP Pregled in osnovni koncept Podrobnosti protokola Razvoj in uporaba protokola UPORABA PROTOKOLA SNMP V REALNEM OKOLJU Potreba po namestniku Opis sistema Primer scenarija delovanja sistema Spremembe konfiguracije Problem preslikave zahtev Moţne implementacije preslikav Problem preslikave odgovorov NAMESTNIK SNMP PROXY AGENT Načrt in razvoj programskega produkta Korak 1 osnovno sprejemanje in posredovanje sporočil Korak 2 uvedba protokola SNMPv Korak 3 omogočanje večjega števila preslikav Korak 4 zapis podatkov v konfiguracijsko datoteko Korak 5 podpora sporočilom SNMP TRAP in INFORM Korak 6 prenos na operacijski sistem Unix Korak 7 program za urejanje konfiguracijske datoteke Implementacija Korak 1 osnovno sprejemanje in posredovanje sporočil Korak 2 uvedba protokola SNMPv Korak 3 omogočanje večjega števila preslikav Korak 4 zapis podatkov v konfiguracijsko datoteko Korak 5 podpora sporočilom SNMP TRAP in INFORM Korak 6 prenos na operacijski sistem Unix Korak 7 program za urejanje konfiguracijske datoteke PREIZKUŠANJE NAMESTNIŠKEGA STREŢNIKA Preizkušanje po metodi bele škatle Preizkušanje po metodi črne škatle Namestnik in oddaljeno diagnosticiranje Oddaljeno diagnosticiranje Uporaba namestniškega streţnika za oddaljeno diagnosticiranje REZULTATI IN DISKUSIJA Primer delovanja Vnos podatkov za preslikavo v Konfigurator Zagon namestnika Aktiviranje delovanja namestnika Preverjanje pravilnosti delovanja namestnika Sklep ZAKLJUČEK... 53

7 LITERATURA vi

8 vii KAZALO SLIK Slika 1: Uporabniški vmesnik SnmpFwd Slika 2: Delovanje Snmp Proxy Forwarder-ja podjetja AdventNet Slika 3: Prikaz delovanja sorodnih rešitev... 5 Slika 4: Umestitev namestnika v sistem Slika 5: Primer zapisa preslikave brez profilov Slika 6: Primer zapisa preslikave s profili Slika 7: Dva zgleda za zapis profila: levo profil za verzijo SNMPv1, desno profil za verzijo SNMPv Slika 8: Zapis nove preslikave z vnaprej definiranimi profili Slika 9: Definicija preslikave za sporočila tipa SNMP TRAP in INFORM Slika 10: Psevdokod preverjanja varnostnega nivoja za verzijo 3 protokola SNMP Slika 11: Primer zapisa preslikave v konfiguracijski datoteki Slika 12: Uporabniški vmesnik Konfiguratorja Slika 13: Okno za dodajanje novih preslikav Slika 14: Prikaz okna za urejanje preslikave Slika 15: Prikaz okna za delo s profili Slika 16: Dialog za dodajanje profilov Slika 17: Obvestilo o profilu, ki je v uporabi Slika 18: Prikaz preslikave v programskem modulu Konfigurator Slika 19: Izpisi pri zagonu namestnika Slika 20: Vnos podatkov namestnika v program MIB browser Slika 21: Pošiljanje zahteve na naš namestnik s pomočjo programa MIB browser Slika 22: Podrobnosti zahteve in prejetega odgovora Slika 23: Vnos podatkov ciljnega računalnika v program MIB browser Slika 24: Pošiljanje zahteve na ciljni računalnik s pomočjo programa MIB Browser Slika 25: Podrobnosti prejetega odgovora pri preverjanju pravilnosti delovanja našega namestnika

9 viii Uporabljene kratice SNMP enostaven protokol za nadzor omreţij (simple network management protocol) MIB managerska informacijska baza (management Information Base) OID označevalnik objekta (object identifier) PDU podatkovna enota protokola (protocol data unit) VBL seznam OIDjev (variable binding list) RFC zahteva za komentar (request for comment) SMI struktura upraviteljskih informacij (Structure of Management Information) IETF druţba za definiranje internetnih standardov (Internet Engineering Task Force) ASN.1 abstraktna sintaksa zapisa ena (Abstract syntax notation one) NMS mreţno-upraviteljski sistemi (Network-management systems) IP internetni protokol (Internet protocol) OSI medsebojne odprte sistemske povezave (Open Systems Interconnection) UDP nepovezovalni protokol za prenašanje paketov (User Datagram Protocol) CLNS brezpovezavni mreţni servis (Connectionless Network Service) DDP Protokol za povezavo preko AppleTalk omreţij (Datagram-Delivery Protocol) IPX Medmreţna izmenjava paketov (Interneworkt Packet Exchange) USM uporabniški varnostni model (User-based Security Model) VACM uporabniški model za nadzor dostopa (View Access Control Model) USB univerzalno serijsko vodilo (universal serial bus)

10 1 1 UVOD V današnjem času imamo ogromno računalniško vodenih naprav, ki opravljajo najrazličnejša dela. Srečujemo se, na primer, z raznimi roboti v proizvodnji, usmerjevalniki, bančnimi avtomati in še z mnogimi drugimi napravami. Ob svoji osnovni funkcionalnosti delovanja imajo te naprave običajno vgrajeno še posebno programsko opremo za njihov nadzor in krmiljenje. Z ustreznim povezovanjem in komuniciranjem, lahko ti programi posredujejo odgovornim osebah sporočila o stanju naprav. Seveda ne ţelimo, da bi bilo veliko različnih protokolov, preko katerih bi ti programi za nadzor delovali oz. komunicirali. Organizacija IETF (Internet Engineering Task Force) je zato definirala protokol SNMP (simple network management protocol), ki standardizira komunikacijo s takšnimi napravami. Primarni namen protokola SNMP je nadzor in upravljanje naprav IP (Internet Protocol). V tej komunikaciji se na eni strani srečujemo z napravo, ki jo ţelimo nadzorovati, na drugi strani pa je naprava, ki omogoča nadzorovanje oz. upravljanje prve naprave. Če ţelimo, da se obe napravi razumeta, je seveda nujno, da govorita isti jezik uporabljata isti protokol. Prva verzija protokola SNMP ni zagotavljala nikakršne varnosti. Uporabniki so to seveda identificirali kot veliko pomanjkljivost, zato se je čez čas razvila še druga verzija tega protokola (tj. protokol SNMPv2), ki je pa imela več različic. Najbolj razširjena različica je različica "c" (tj. protokol SNMPv2c). Ker pa protokol še vedno ni bil tako varen, kot so uporabniki ţeleli in zahtevali, so razvili še tretjo verzijo protokola (tj. protokol SNMPv3), ki pa ţe vključuje ustrezne varnostne mehanizme. Med evolucijo protokola SNMP so uporabniki v večini primerov samo zamenjali programsko opremo na nadzorni napravi (manager), medtem ko na nadzorovani napravi (agent) ni bilo moţno samo zamenjati programske opreme, ampak bi bilo potrebno zamenjati celotno napravo, kar pa je bil v mnogih primerih prevelik strošek. Tako se v podjetjih, ki so v slabšem finančnem stanju ali pa preprosto ne ţelijo plačati več tisoč evrov za novo napravo (agenta), še danes preko mreţe pošiljajo nezavarovani podatki. Moţna rešitev zgoraj omenjenega problema je v uvedbi t.i. namestniškega streţnika (proxy server), ki bi bil integriran na strani agenta in bi prestrezal sporočila agenta, ter jih zakodirana poslal skozi računalniško omreţje k ciljni napravi (managerju). S tem doseţemo, da se po omreţju pošiljajo zavarovana sporočila, med agentom in namestnikom

11 2 pa nezavarovana. Slednje v večini primerov niti ni nevarno, saj se agent in namestnik fizično nahajata skupaj, v mnogih primerih celo v istem računalniškem sistemu. V tej diplomski nalogi ţelimo podrobno preučiti protokol SNMP in napisati programsko opremo, ki bo znala delati z najbolj uporabljenimi verzijami protokola in vsemi tipi sporočil, definiranih za ta protokol. Program bo sprejemal pakete protokola SNMP, jih preoblikoval v ustrezno verzijo protokola, nastavljal varnostne parametre in pošiljal pakete protokola SNMP. Da pa se izognemo morebitnim varnostnim luknjam, bomo program napisali tako, da bo prejemal pakete samo z vnaprej določenimi varnostnimi parametri in jih pošiljal na vnaprej določene naslove, s prav tako definiranimi varnostnimi parametri za vsak naslov posebej. Takšno funkcionalnost bomo dosegli s konfiguracijsko datoteko. Za kreiranje in urejanje konfiguracijske datoteke bomo razvili posebni programski modul. Diplomsko delo je sestavljeno iz sedmih poglavij. V drugem poglavju bomo opravili pregled ţe obstoječih rešitev, ki znajo transformirati sporočila med različnimi verzijami protokola SNMP. V tretjem poglavju bomo podrobno predstavili protokol SNMP, v naslednjem poglavju pa bomo opisali, kako je moţno uporabiti protokol SNMP v realnem okolju, hkrati pa bomo opisali vse gradnike sistema za nadzor naprav. V petem poglavju bomo podrobno predstavili razvoj in implementacijo našega namestnika. Ob tem bomo opisali vse probleme, na katere smo naleteli med razvojem, opisali pa bomo tudi, kako smo jih odpravili. V šestem poglavju si bomo ogledali preizkušanje našega namestnika. V poglavju z rezultati in diskusijo pa bomo demonstrirali delovanje našega namestnika ter ovrednotili dobljene rezultate. Diplomsko delo sklenemo s kratkim zaključkom, kjer povzamemo glavne izsledke tega dela, zapišemo pa tudi glavne smernice za nadaljnje raziskave.

12 3 2 PREGLED OBSTOJEČIH REŠITEV V tem poglavju si bomo pogledali obstoječe rešitve, njihove prednosti in slabosti, ter jih poskušali primerjati s funkcionalnostjo, ki jo bo imela naša rešitev. Spoznali bomo, da podobne rešitve ţe obstajajo, vendar z manjšo funkcionalnostjo. V nadaljevanju bomo predstavili nekaj najpomembnejših obstoječih rešitev, pri čemer bomo za vsako rešitev uvedli nov razdelek. a) SNMP v1,v2c,v3 Forwarder Utility Podjetje LogiSoft AR Ltd. je razvilo produkt imenovan "SNMP v1,v2c,v3 Forwarder Utility". Njegova funkcionalnost je zelo podobna našim pričakovanim zahtevam, s to razliko, da ta produkt deluje samo na operacijskem sistemu Windows. Slika 1 prikazuje uporabniški vmesnik programa SnmpFwd. Slika 1: Uporabniški vmesnik SnmpFwd.

13 4 b) SNMP Proxy Forwarder Kot naslednjo bomo opisal rešitev podjetja AdventNet, ki je poimenovana "SNMP Proxy Forwarder". Funkcionalnost te programske opreme se v veliki meri sklada z našimi pričakovanji, vendar pa je ta produkt ponovno omejen zgolj na operacijski sistem Windows. Na spletni strani proizvajalci piše da podpira tudi verzijo protokola SNMPv3, vendar pa smo kasneje ugotovili, da ima program še nekaj pomanjkljivosti, med katerimi je tudi podpora protokolu SNMPv3, katere še niso uspeli dodati. To vsekakor lahko pomeni večjo trţno vrednost in večjo verjetnost morebitnega uspeha našega produkta. Na sliki 2 je prikazana shema delovanja SNMP Proxy Forwarderja podjetja AdventNet. Na levi vidimo več agentov, ki z namestnikom komunicirajo preko protokola verzije 1 ali 2c, na desni pa so različni managerji, s katerimi namestnik komunicira s protokolom verzije 3 (katera, kot ţe rečeno, ne deluje v programu). Konfiguracijske podatke namestnik pridobi iz različnih virov, kot je USM (User-based Security Model), drug agent ali VACM (View Access Control Model), kot je vidno na sliki spodaj. Slika 2: Delovanje Snmp Proxy Forwarder-ja podjetja AdventNet.

14 5 c) Drugo V literaturi smo odkrili tudi nekaj programskih rešitev, ki pa nimajo popolne funkcionalnosti, kot je zahtevana za naš produkt. Za nadaljnjo razlago je koristno, da jih na kratko opišemo. Princip delovanja teh rešitev je prikazan na sliki 3. Vsi ti produkti so v obliki programske opreme nameščeni na določeno napravo, ki pa privzeto ne podpira protokola SNMP. Ta programska oprema na nek specifičen način pridobi podatke od sistema, na primer o temperaturi procesorja, zasedenosti pomnilnika, porabi električne energije, številu uporabnikov povezanih na to napravo, količini goriva v avtomobilu, količini barve v kartuši, ali karkoli drugega, kar bi koga utegnilo zanimati. Primer takega produkta je program podjetja HP (Hewlett-Packard) imenovan HP SNMP Proxy Agent. Podjetje je razvilo ta produkt za nadzor njihovih tiskalnikov. Za pravilno delovanje je program potrebno namestiti na vse računalnike, na katere je priklopljen tiskalnik. Tiskalnik je lahko na računalnik priklopljen preko vodila USB (universal serial bus) ali paralelne povezave. Sistemski administrator mora imeti nameščen nadzorni program tega istega podjetja, ki pa zna pridobiti podatke iz vseh tiskalnikov priklopljenih na računalnike v lokalnem omreţju. Nadzorni program dejansko pridobi podatke od tiskalnikov v omreţju preko protokola SNMP. Slika 3: Prikaz delovanja sorodnih rešitev.

15 6 Po navedbah podjetja HP je nadzor nad tiskalniki skoraj tako dober, kot če bi imeli tiskalnik povezan lokalno na svoj računalnik. Edini pogoj za takšno delovanje je, da morajo tiskalniki biti znamke HP in da podpirajo protokol, ki ga uporablja HP SNMP Proxy Agent.

16 7 3 PROTOKOL SNMP Protokol SNMP se uporablja za nadzor naprav povezanih v računalniško omreţje. Z uporabo tega protokola lahko pridobimo podatke o nadzorovanih sistemih v obliki spremenljivk, ki med drugim tudi opisujejo konfiguracijo sistema. Namenski nadzorni programi lahko te spremenljivke prebirajo, včasih pa tudi nastavljajo. V nadaljevanju bomo opisali bistvene elemente protokola SNMP. 3.1 Pregled in osnovni koncept V tipičnem sistemu je večje število nadzorovanih naprav. Programska oprema imenovana agent teče na teh sistemih in sporoča podatke preko protokola SNMP nadzornim sistemom. Agenti SNMP pošiljajo nadzorne podatke nadzornih sistemov v obliki spremenljivk (npr. prosti spomin, sistemsko ime, trenutno število procesov). Nadzorni sistem lahko zahteva informacije z uporabo operacij GET, GETNEXT ali GETBULK protokola SNMP, ali pa agent sam pošlje podatke (brez zahteve nadzornega sistema) z uporabo operacij TRAP ali INFORM protokola SNMP. Nadzorni sistemi lahko pošljejo tudi konfiguracijske popravke ali kontrolne zahteve z operacijo SET. Konfiguracijske in kontrolne operacije se uporabijo samo takrat, kadar je potrebno izvesti spremembe omreţne infrastrukture. Nadzorne operacije se izvajajo v rednih intervalih. Spremenljivke v okviru protokola SNMP so hierarhično organizirane. Organiziranost spremenljivk skupaj z meta podatki (npr. tip in opis) opisuje managerska informacijska baza (MIB Management Information Base). Managerska informacijska baza (MIB) Protokol SNMP ne definira, katere informacije (spremenljivke) naj nadzorovani sistem nudi navzven. Raje uporablja razširjeno zasnovo, kjer so razpoloţljive informacije določene z bazami MIB. Te opisujejo strukturo nadzorovanih podatkov podsistema naprave, uporabljajo hierarhične imenske prostore (namespace), ki vsebujejo označevalnike objekta (OID Object Identifier). Vsak OID določa spremenljivko, ki jo lahko beremo ali nastavljamo preko protokola SNMP. Označevalnik objekta OID unikatno

17 8 definira nadzorovan objekt v hierarhiji MIB. Baze MIB uporabljajo zapis imenovan ASN.1 abstraktna sintaksa zapisa ena (abstract syntax notation one). Hierarhijo baz MIB si lahko predstavljamo kot drevesno strukturo, pri čemer koren nima imena, podnivoji pa so dodeljeni različnim organizacijam. Zgornji označevalniki OID baz MIB pripadajo različnim organizacijam, ki določajo standarde, na niţjem nivoju pa so označevalniki OID dodeljeni zdruţenim (in manjšim) organizacijam. Takšna struktura omogoča nadzor nad vsemi plastmi modela OSI (Open Systems Interconnection), sam nadzor pa se lahko razširja tudi v aplikacije, kot so podatkovne baze ali elektronska pošta, saj se lahko baze MIB namreč definirajo za najrazličnejša področja informacij in operacij. Vsaka nadzorovana naprava ima več nadzorovanih objektov (t.i. objekt MIB, ali povedano kratko objekt oz. MIB). Nadzorovan objekt pa sestoji iz ene ali več instanc objekta identificiranega z označevalnikom OID. V večini primerov gre za spremenljivke. Obstajata dva tipa nadzorovanih objektov: 1. skalarni objekti, ki definirajo eno instanco objekta, 2. tabelarni objekti, ki definirajo več sorodnih instanc objekta zdruţenih v tabelo MIB. Primer nadzorovanega objekta je atinput. To je skalarni objekt, ki vsebuje eno instanco objekta (t.j. celoštevilsko vrednost) in hrani skupno število prejetih paketov AppleTalk na vmesniku usmerjevalnika. Abstraktna sintaksa zapisa ena (ASN.1) V telekomunikacijskih in računalniških omreţjih je zapis ASN.1 standarden in prilagodljiv zapis, ki opisuje strukturo podatkov za predstavitev, kodiranje, prenos, in dekodiranje podatkov. Nudi mnoţico formalnih pravil za opis struktur objektov, ki so neodvisni od strojno-specifičnih kodirnih tehnik. Hkrati pa je natančen formalni zapis, ki odstranjuje vsake dvoumnosti. Zapis ASN.1 je skupen standard organizacij ISO in ITU-T, prvotno definiran leta 1984, kot del nekega drugega standarda. Kasneje, leta 1988, je zaradi velike uporabnosti postal svoj standard. Leta 1995 pa je bil še krepko posodobljen.

18 9 Prilagojena podmnoţica standarda ASN.1, tj. struktura managerskih informacij (SMI structure of management information) je navedena v protokolu SNMP za definiranje skupin povezanih objektov MIB, drugače imenovanih tudi moduli MIB. Osnovne komponente protokola SNMP Omreţje nadzorovano s protokolom SNMP sestavljajo tri ključne komponente: 1. nadzorovane naprave, 2. agenti, in 3. mreţno-managerski sistemi (NMS network-management system). Nadzorovana naprava je mreţno vozlišče, ki vsebuje agenta SNMP in se nahaja v nadzorovanem omreţju. Nadzorne naprave zbirajo in hranijo nadzorovane informacije in jih dajo na voljo sistemom NMS, ki seveda uporabljajo protokol SNMP. Nadzorovana naprava (t.i. mreţni elementi) je lahko vsaka naprava, vključno z usmerjevalniki, stikali, telefoni IP, tiskalniki, računalniki itd. Agent je mreţno-upraviteljski programski modul, ki se nahaja v nadzorovani napravi. Agent pozna lokalne nadzorovane informacije, ki jih je zmoţen pretvoriti v obliko, zdruţljivo s protokolom SNMP. Sistem NMS izvaja programe, ki spremljajo in nadzirajo nadzorovane naprave. Sistemi NMS zagotovijo potreben procesorski čas in pomnilniški prostor za nadzor omreţja. V vsakem nadzorovanem omreţju je lahko eden ali več sistemov NMS. 3.2 Podrobnosti protokola Podatkovni tipi SMI v verziji SNMPv1 Verzija SNMPv1 za strukturo SMI določa uporabo številnih podatkovnih tipov, ki jih delimo v dve skupini: 1. preprosti podatkovni tipi in 2. aplikacijski podatkovni tipi.

19 10 V strukturi SMI verzije SNMPv1 so definirani trije preprosti podatkovni tipi: 1. celo številčni tip podatkov v območju med do , 2. oktetni niz znakov to so urejena zaporedja od 0 do oktetov, 3. označevalniki OID dobimo jih iz skupka vseh OID, glede na pravila definirana v zapisu ASN.1. V strukturi SMI verzije SNMPv1 obstaja sedem aplikacijskih podatkovnih tipov: 1. Omreţni naslovi predstavljajo naslov iz določene druţine protokola. Verzija SNMPv1 podpira samo 32 bitne naslove IP. 2. Števci vsebujejo ne-negativne številčne vrednosti, ki se povečujejo dokler ne doseţejo največje dovoljene vrednosti, nato se vrnejo na nič. V verziji SNMPv1 poznamo samo 32 bitne števce. 3. Merilniki (gauges) vsebujejo ne-negativne številčne vrednosti, ki se lahko povečujejo ali zmanjšujejo med vnaprej predpisano najmanjšo in največjo dovoljeno vrednostjo. 4. Časovna enota (time tick) predstavlja čas nekega dogodka, izraţen v stotinkah sekunde. 5. Prosojnost (opaque) določa kodiranje, ki se uporablja za pridobivanje informacij iz niza znakov, ki ne podpirajo standarda določenega z zapisom ASN Predznačena celoštevilčna vrednost (integer). 7. Nepredznačena celoštevilčna vrednost (unsigned integer). Tabele MIB v verziji SNMPv1 Struktura SMI v verziji SNMPv1 definira strogo strukturirane tabele, ki se uporabljajo za zdruţevanje tabelaričnih objektov (tj. objekt, ki vsebuje več spremenljivk). Tabele imajo nič ali več vrstic, ki so oštevilčene tako, da lahko protokol SNMP pridobi ali spremeni celotno vrstico z eno operacijo, npr. GET, GETNEXT ali SET.

20 11 Strukture SMI v SNMPv2 Struktura SMI v verziji SNMPv2 je opisana v določilu RFC 2578 (request for comment). Prinaša nekaj dopolnil in izboljšav glede na podatkovne tipe SMI v verziji SNMPv1, kot na primer bitne nize znakov, omreţne naslove in števce. Bitni nizi znakov so definirani samo v verziji SNMPv2 in so sestavljeni iz nič ali več bitov. Omreţni naslov predstavlja naslov iz določene druţine protokolov. Števci so ne-negativna cela števila, ki se povečujejo do največje dovoljene vrednosti, potem pa se vrnejo na nič. V verziji SNMPv2 poznamo tako 32- kot tudi 64-bitne števce. Protokol SNMP deluje v aplikacijski plasti 7 modela OSI. V verziji SNMPv1 je specificiranih pet podatkovnih enot protokola (PDU Protocol data unit): 1. GET zahteva se uporablja za pridobitev dela nadzorovanih informacij. 2. GETNEXT zahteva se uporablja iterativno za zaporedno pridobitev nadzorovanih informacij. 3. GET odgovor uporabi agent kot odgovor na GET ali SET zahtevo. 4. SET zahteva se uporabi za inicializacijo in spreminjanje vrednosti. 5. TRAP se uporabi za sporočanje alarmov ali drugih asinhronih dogodkov na nadzorovanem podsistemu. V verziji SNMPv1 so asinhroni dogodki imenovani "trap", v vseh poznejših verzijah pa "inform". V modulih MIB v strukturi SMI verzije SNMPv1 so "trapi" definirani z uporabo makroja TRAP-TYPE, v verziji SNMPv2 pa jih definiramo z uporabo makroja NOTIFICATION-TYPE. V verziji SNMPv2 sta bili dodani naslednji enoti PDU: 1. GETBULK zahteva hitrejša metoda za pridobitev več nadzorovanih podatkov. 2. INFORM podobna operaciji TRAP, vendar zahteva odgovor. Običajno SNMP uporablja vrata UDP (User Datagram Protocol) številka 161 za agenta in vrata številka 162 za managerja. Manager lahko pošlje zahtevo iz poljubnih vrat (izvorna vrata) na vrata številka 161, ki pripadajo agentu (ciljna vrata). Odgo vor agenta se pošlje nazaj na izvorna vrata. Manager sprejema "trape" na vratih številka 162, agent pa jih lahko pošilja iz poljubnih vrat.

21 12 Informacijski moduli SMI v verziji SNMPv2 Strukture SMI v verziji SNMPv2 prav tako navajajo informacijske module, ki določajo skupine sorodnih definicij. Obstajajo tri skupine informacijskih modulov SMI: 1. moduli MIB vsebujejo definicije sorodnih nadzorovanih objektov. 2. Izjave ustreznosti zagotavljajo sistematičen način za opis skupine nadzorovanih objektov. 3. Izjave zmoţnosti uporabljene so za prikaz natančnega nivoja podpore, ki ga pričakuje agent od skupine MIB. Sistem NMS lahko prilagodi odnos do agenta glede na agentovo izjavo zmoţnosti. Verzija SNMPv3 Verzija SNMPv3 je definirana z določili RFC 3411 do RFC Verzija SNMPv3 zagotavlja večjo varnost komunikacije, hkrati pa izboljša moţnost oddaljenega konfiguriranja. Ta verzija je od leta 2004 standardna verzija protokola SNMP. Organizacija IETF je označila verzijo SNMPv3 za popoln internetni standard, kar je najvišje priznanje, ki ga lahko prejme protokol, določen z določili RFC. Prejšnje verzije protokola SNMP so zastarele (obsolete). Verzija SNMPv3 nudi pomembne varnostne funkcije: 1. Integriteta sporočil zagotavlja, da nihče ne more prestreči paketa na poti. 2. Overitev (authentication) zagotavlja, da je paket iz veljavnega vira. 3. Šifriranje paketov (encryption) onemogoči nepooblaščenim virom prisluškovanje komunikaciji. 3.3 Razvoj in uporaba protokola a) Verzija 1 Verzija SNMPv1 je prvotna implementacija protokola SNMP. Verzija SNMPv1 deluje na osnovi protokolov, kot so UDP, IP, CLNS (Connectionless Network Service), DDP (Datagram-Delivery Protocol) in IPX (Internetwork Packet Exchange). Zaradi svoje

22 13 uporabnosti je verzija SNMPv1 kmalu postala zelo priljubljena, hkrati pa je pridobila status de facto standarda za mreţni nadzor naprav v internetni skupnosti. Prve zahteve RFC za protokol SNMP, sedaj poznan kot verzija SNMPv1, so se pojavili leta 1988, in sicer: RFC 1065 struktura in identifikacija nadzorovanih informacij za TCP/IP. RFC 1066 baze MIB za mreţni nadzor v TCP/IP omreţjih. RFC 1067 preprost mreţni nadzorni protokol. Zgoraj navedeni protokoli so zastareli in so jih kasneje zamenjali naslednji: RFC 1155 struktura in identifikacija nadzorovanih informacij za omreţje TCP/IP. RFC 1156 baze MIB za mreţni nadzor v omreţjih TCP/IP. RFC 1157 preprost mreţni nadzorni protokol. Po določenem času je zahtevo RFC 1156 zamenjala zahteva RFC 1213, ki vsebuje verzijo 2 za baze MIB (tj. MIB-2) za mreţni nadzor omreţij TCP/IP. Verzija 1 protokola SNMP je bila pogosto tarča kritik in to predvsem zaradi slabe varnosti pri komunikaciji. Overitev agentov je bila izvedena z nizom znakov, ki je imel vlogo gesla, le-ta pa se je po omreţju prenašal kot navadno oz. golo besedilo. b) Verzija 2 Verzija SNMPv2, definirana z zahtevami od RFC 1441 do RFC 1452, je nadgradnja verzije 1 in vsebuje izboljšave pri zmogljivosti, varnosti, tajnosti in medupraviteljski komunikaciji. Vpeljuje operacijo GETBULK, kot alternativo iterativni operaciji GETNEXT, in sicer za pridobivanje večjih količin nadzorovanih podatkov z eno zahtevo. Mnogim uporabnikom se je zdel nov varnostni mehanizem v verziji SNMPv2 preveč kompleksen, zaradi česar ta različica ni bila širše sprejeta v javnosti. Verzija SNMPv2c je definirana v zahtevah RFC 1901 do RFC V začetku je bila neformalno znana tudi kot verzija SNMPv1.5. Verzija SNMPv2c je dejansko verzija SNMPv2 brez kompleksnega varnostnega mehanizma. Ta različica uporablja enako varnostno shemo kot verzija SNMPv1. Čeprav uradno ta različica ni pravi standard, se je v širši javnosti veliko uporabljala in je bila obravnavana kot de facto standard.

23 14 Verzija SNMPv2u je definirana v zahtevah RFC 1909 in RFC Gre za kompromis, ki nudi večjo varnost kot verzija SNMPv1, vendar pa brez kompleksnega varnostnega mehanizma, kot je v osnovni verziji SNMPv2. Podrazličica te verzije se je prodajala pod oznako SNMPv2*. Določeni deli tega mehanizma so bili pozneje uporabljeni v verziji SNMPv3. Kompatibilnost verzij SNMPv1 in SNMPv2c Verzija SNMPv2c ni kompatibilna z verzijo SNMPv1 v dveh ključnih področjih: 1) formatu sporočila in 2) operacijah protokola. Sporočila v verziji SNMPv2c uporabljajo drugačno glavo paketa in format PDU kot verzija SNMPv1. Verzija SNMPv2c prav tako uporablja dve operaciji, ki jih verzija SNMPv1 ne pozna. Obstaja pa zahteva RFC 1908, ki definira dve moţnosti soobstajanja teh dveh protokolov, in sicer namestniške agente in dvojezične mreţno-nadzorne sisteme (bi-lingual network management systems). Namestniški agent prejme sporočila, jim ustrezno spremeni protokol, ter posreduje na cilj. Dvojezični mreţno-nadzorni sistem pa vsebuje podporo za obe verzije protokola. Ob prejemu sporočila preveri, na osnovi katere verzije protokola je zgrajen prejeti paket, z agentom pa nato komunicira po ustrezni verziji protokola. c) Verzija 3 Verzija SNMPv3 je definirana z zahtevami od RFC 3411 do RFC To verzijo obravnava organizacija IETF od leta 2004 kot trenutno standardno verzijo protokola SNMP. Prejšnje verzije so označene kot zastarele. Pri implementaciji protokola SNMP pa so v praksi ponavadi podprte kar vse tri verzije, in sicer verzija SNMPv1, SNMPv2c in SNMPv3. Verzija SNMPv3 vsebuje tri nove pomembne varnostne mehanizme: 1. Overitev primer overitve je vpis uporabniškega imena in gesla, ki se morata ujemati na obeh straneh povezave. 2. Zasebnost onemogoča prisluškovanje paketom na poti od pošiljatelja do naslovnika.

24 15 3. Kontrola dostopa različnim uporabnikom lahko določimo dostop do različnih podatkov z različnimi pravicami.

25 16 4 UPORABA PROTOKOLA SNMP V REALNEM OKOLJU V tem poglavju bomo v celoti predstavili, kako je moţno uporabiti protokol SNMP za nadzor omreţnih sistemov. Opisali bomo vse gradnike, ki sodelujejo v tej komunikaciji, in sicer od naprave, ki jo ţelimo nadzorovati, do naprave, s katero bomo opravljali nadzor. V ta sistem bomo v nadaljevanju umestili naš programski produkt in ga ustrezno povezali z napravami. 4.1 Potreba po namestniku Potreba po namestnikih se je začela pojavljati ţe pred leti, ko je bil javnosti predstavljen protokol SNMPv2. Ker ni bilo velikih razlik med protokolom SNMPv1 in SNMPv2 se je v industriji še vedno uporabljal kar protokol SNMPv1. Z leti se je uporaba interneta zelo razširila, ob tem pa je bil predstavljen tudi protokol SNMPv3. Uporabniki protokola SNMP so se začeli zavedati nevarnosti interneta, kar je imelo posledico, da se je nova različica protokola začela vse bolj uveljavljati. Takojšen prehod delovanja naprav na protokol SNMPv3 seveda ni moţen, zato se je ta sprememba dogajala postopoma. Na trgu najdemo vedno več naprav, ki podpirajo protokol SNMPv3, kljub temu pa obstaja še mnoţica naprav, ki podpirajo samo starejši verziji protokola. Zaradi vedno bolj razširjenega spletnega kriminala je varnost na spletu ena izmed temeljnih strategij podjetij. Zaţelen je seveda varen prenos podatkov od pošiljatelja do naslovnika, zaradi česar se podjetja posluţujejo najrazličnejših metod, da bi zagotovila varnost. Ena izmed moţnih je uporaba namestnika, ki prestreza sporočila preden pridejo v javno omreţje in jim, v primeru, da niso zgrajena v protokolu SNMPv3, ustrezno spremeni obliko paketa in protokol, ter šele tako spremenjeno sporočilo pošlje naslovniku. Namestnika lahko uporabimo na več načinov. Če naprava (npr. računalnik) omogoča dodajanje novih aplikacij, ga lahko namestimo na agenta oz. managerja, ali pa ga, v primeru, da naprava ne podpira dodajanja novih aplikacij, namestimo kar na svoj računalnik in le-tega poveţemo z agentom oz. managerjem.

26 Opis sistema Naš sistem vsebuje napravo, ki jo ţelimo nadzorovati (agent) in napravo, s katero bomo to drugo napravo nadzorovali (manager). Agenti so lahko različne naprave, in sicer od raznih robotov v proizvodnji, tiskalnikov, usmerjevalnikov, gospodinjskih naprav ipd. Manager pa je v večini primerov osebni računalnik ali naprava s primernim uporabniškim vmesnikom, kjer lahko uporabnik prebira in zahteva ţelene podatke. Za laţje razumevanje bomo v nadaljevanju predstavili primer scenarija delovanja takšnega sistema. 4.3 Primer scenarija delovanja sistema Recimo, da je na strani agenta bančni avtomat, na strani managerja pa računalnik v banki. Podatki, ki se prenašajo po omreţju, so seveda zato lahko izredno občutljive narave. To je razlog, da je potrebno zagotoviti veliko varnost med prenosom podatkov in njihovo kriptiranje. Predpostavimo, da bančni avtomat in računalnik v banki ne podpirata protokola SNMPv3, podpirata pa protokol SNMPv1 in SNMPv2c. Zaradi tega bi se preko omreţja seveda prenašali nezavarovani podatki. Problem bi lahko rešili tako, da bi na računalniku v banki namestili programsko opremo, ki bi podpirala protokol SNMPv3. Bančnemu avtomatu pa seveda ne moremo kar tako zamenjati programske opreme, nakup novega pa bi bil predrag. Da bi rešili takšen problem, moramo namestiti naš programski produkt (tj. namestnik) na svoj računalnik in ga fizično postaviti k bančnemu avtomatu. Bančni avtomat poveţemo z računalnikom, ki ima nameščen namestnik, računalnik pa priklopimo na zunanje omreţje. Bančni avtomat bo od sedaj naprej pošiljal sporočila našemu namestniku, ta pa jih bo prevedel v protokol SNMPv3 in poslal v banko na nadzorni računalnik. S tem doseţemo, da se po omreţju pošiljajo kriptirana sporočila. Med bančnim avtomatom in namestnikom so sporočila nezavarovana, kar pa ne predstavlja posebnega problema, saj sta obe napravi praktično na isti fizični lokaciji in zato nihče ne more prestreči sporočil. Seveda moramo ustrezno prilagoditi (configure) bančni avtomat, namestnika in nadzorni računalnik v banki. Na drugi strani pa bo namestnik prestrezal vsa sporočila od nadzornika namenjena agentu. Sporočila bo pretvoril v ustrezno verzijo

27 18 protokola SNMP in jih nato poslal na bančni avtomat. Potrebne spremembe konfiguracije bomo podrobneje predstavili v nadaljevanju. Slika 4 predstavlja primer našega sistema. Slika 4: Umestitev namestnika v sistem. 4.4 Spremembe konfiguracije Potrebne spremembe v konfiguraciji naprav v našem sistemu bomo razloţili na primeru scenarija delovanja sistema opisanega v prejšnjem podpoglavju. Bančni avtomat moramo na novo konfigurirati tako, da bo pošiljal vsa sporočila na namestnika. Spremeniti mu moramo izhodni in vhodni naslov IP, vrata in varnostne parametre. Na drugi strani pa moramo računalniku v banki prav tako ustrezno določiti vhodni in izhodni naslov IP, vrata in varnostne parametre. Namestniku pa moramo povedati tudi iz katerega naslova IP in na katerih vratih naj pričakuje pakete od bančnega avtomata in varnostne parametre prejetih paketov. Določiti moramo tudi na kateri naslov IP, vrata in s kakšnimi varnostnimi parametri naj posreduje te pakete. Konfigurirati pa moramo tudi v obratni smeri, in sicer iz katerega naslova IP, na katera vrata in s kakšnimi varnostnimi parametri naj prejme zahteve od računalnika v banki in na kateri naslov, vrata in s kakšnimi varnostnimi parametri naj posreduje sporočila na bančni avtomat. V praksi je lahko namestnik vmesnik med več kot dvema sistemoma, zato moramo uvesti primerno preslikavo med managerji in agenti. Probleme pri preslikavi si bomo pogledali v naslednjem podpoglavju.

28 Problem preslikave zahtev Namestnik mora za vsako prejeto sporočilo vedeti, kam ga naj posreduje. Za vsako sporočilo, poslano od managerja, mora torej vedeti, kateremu agentu je namenjeno in obratno. Prvi problem lahko rešimo na več načinov. Prvi moţni način je, da pošiljamo sporočila z agenta namestniku na različna vrata. V namestniku pa moramo imeti ustrezno konfigurirano preslikavo iz vrat na managerjev naslov IP. Namestnik mora hkrati poslušati za sporočila na več različnih vratih. Druga moţnost je, da pošiljamo sporočila z različnimi parametri protokola SNMPv1 oz. SNMPv2c. V praksi to pomeni, da jim določimo različne SNMP skupine (SNMP community). En agent oz. naprava SNMP lahko namreč pripada več SNMP skupinam. Prednost tega je, da namestnik ne potrebuje poslušati na toliko različnih vratih, ampak zgolj na enih. V tem primeru pa potrebujemo preslikavo iz skupine dostopa (community) v naslov IP ciljnega računalnika. Pri implementaciji našega sistema smo se odločili za prvo moţnost, tj. preslikavo preko različnih vrat. Imamo več moţnosti implementacije. Prednosti in slabosti posameznega pristopa pa si bomo ogledali v naslednjem podpoglavju Moţne implementacije preslikav Prvi moţen način implementacije je, da programer ţe v fazi razvoja predvidi vse moţne preslikave. Ta način ima prednost v tem, ker lahko vse te preslikave ţe vnaprej ustrezno preizkusi, hkrati pa ne obstaja moţnost, da bi končen uporabnik kakorkoli vplival na delovanje oz. zanesljivost delovanja naprav. Rešitev ima pa tudi slabosti. Ena izmed največjih slabosti je, da je onemogočeno dodajanje novih preslikav. Ob dodajanju novih preslikav bi jih moral programer vnesti direktno v programsko kodo in ponovno narediti izvedljivi programski modul. Enako bi morali postopati, če bi ţeleli kakšno preslikavo odstraniti ali spremeniti. Takšna programska oprema je seveda specifična in je izredno prilagojena na enega naročnika. Pri vsakem novem naročniku bi imel razvijalec programov dodatno delo, kar pa seveda ni v interesu podjetja, razvijalca oz. programerja, niti naročnika. Slednji bi moral čakati na svoj programski produkt, da programer v njem ustrezno spremeni kodo ter ga preizkusi.

29 20 Druga, bolj praktična rešitev je z uporabo konfiguracijskih datotek. V tej implementaciji uporabnik vnese v konfiguracijsko datoteko vse preslikave, ki jih potrebuje. Če se pojavi potreba po novi preslikavi, potem uporabnik enostavno spremeni konfiguracijsko datoteko, novo preslikavo pa lahko takoj za tem ţe uporablja. Ta pristop je seveda veliko bolj uporaben, sam program pa je ob tem tudi veliko bolj prenosljiv. Takšen programski produkt lahko v nespremenjeni obliki prodamo večkrat, kupec pa dobi program takoj, ko ga potrebuje. Ima pa tudi ta rešitev svojo slabost. Programski produkt namreč pričakuje pravilno zapisano konfiguracijsko datoteko. Vsaka napaka v tej datoteki lahko povzroči nepravilno delovanje ali celo izpad sistema. Uporabnik zato potrebuje veliko znanja, da lahko pravilno oblikuje ter ureja konfiguracijsko datoteko. Ob tem pa je treba upoštevati še človeški faktor. Ljudje smo seveda zmotljivi, zato se lahko zelo hitro dogodi, da, na primer, pri dodajanju nove preslikave kopiramo staro preslikavo, pri tem pa pozabimo spremeniti določen nabor parametrov. S tem vnesemo napačne podatke, kar pa pogosto privede do izpada sistema. Da bi se temu problemu izognili, smo v naši rešitvi napisali program za urejanje konfiguracijskih datotek, ki smo ga poimenovali kar konfigurator. Konfigurator Ideja konfiguratorja je, da uporabniku poenostavi delo s konfiguracijsko datoteko, hkrati pa zmanjša ali celo popolnoma odstrani moţnost napak. Uporabniku pri dostopu do konfiguracijskih datotek s pomočjo konfiguratorja sedaj ni potrebno več poznati sintakse, uporabljene v konfiguracijski datoteki. Ker pa ta datoteka še vedno fizično obstaja na disku, kjer ima uporabnik sistemske pravice za dostop in njeno urejanje, moramo uporabniku dati jasna navodila, kako naj z njo ravna. V praksi to pomeni, da moramo v kazalo, kjer se nahaja konfiguracijska datoteka dodati še posebno datoteko z navodili (npr. PreberiMe.txt). Lahko pa na začetek konfiguracijske datoteke dodamo tudi komentar, kjer skušamo uporabniku razumljivo in na prijazen način svetovati, da te datoteke ne sme ročno spreminjati, ampak samo s pomočjo konfiguratorja.

30 Problem preslikave odgovorov Ta problem je enostavnejši od problema preslikave zahtev. Kadar agent pošlje zahtevo namestniku, si le-ta zapomni podrobnosti zahteve ter iz katerega agenta je bila poslana. Ko pa namestnik prejme odgovor od managerja, potem namestnik zgolj poišče v svojih internih podatkovnih strukturah, kateri agent je zahteval ta podatek ter ga ustreznemu agentu tudi posreduje. Za implementacijo takšne rešitve je potrebno natančno poznavanje zgradbe paketov protokola SNMP. Vsak paket vsebuje podatek o operaciji, številko vrat, varnostne parametre in mnoţico drugih parametrov, med katerimi je tudi številka zahteve. Med komunikacijo agent določi unikatno številko zahteve, manager pa mora vrniti odgovor s to isto številko. Ker pa v tej komunikaciji sodeluje še namestnik, se lahko zgodi, da bi namestnik iz dveh ali več različnih agentov dobil zahteve z isto zaporedno številko za istega managerja. Odziv managerja je v takšnem izjemnem primeru neznan in je odvisen od konkretne implementacije. Moţna implementacija je naslednja. Namestnik vsakemu paketu preden ga pošlje k managerju določi novo zaporedno številko. Ko pa namestnik prejme odgovor, mora ustreznemu agentu odgovoriti z zaporedno številko, ki jo je le-ta v osnovi določil. Da doseţemo takšno delovanje, si moramo ob prejemu zahteve zapomniti podatke o agentu, zaporedno številko prejetega paketa in zaporedno številko poslanega paketa. Ko dobimo odgovor od managerja, pa zgolj poiščemo v tabeli, kateremu agentu je odgovor namenjen. Odgovoru nato spremenimo zaporedno številko in ga posredujemo agentu. Zapis iz tabele izbrišemo po posredovanju odgovora.

31 22 5 NAMESTNIK SNMP PROXY AGENT V tem poglavju bomo najprej pogledali, zakaj je namestnik sploh potreben, kakšne teţave lahko pričakujemo pri implementaciji, opisali pa bomo tudi teţave, na katere smo dejansko naleteli med implementacijo. Poglavje bomo zaključili s predstavitvijo moţnih rešitev in kakšen pristop smo ubrali pri naši rešitvi. 5.1 Načrt in razvoj programskega produkta Implementacije našega namestnika smo se lotili postopoma, in sicer tako, da smo v vsakem koraku dodajali nove funkcionalnosti oz. razširjali obstoječe. Razvoj programa smo v grobem razdelili na 7 korakov oz. faz razvoja. Za vsako fazo smo zapisali pričakovano funkcionalnost našega programskega produkta. Z naslednjim korakom smo nadaljevali šele takrat, ko je bil predhodni korak temeljito preizkušen in potrjen. Na koncu bomo razvili še pomoţni program, katerega naloga bo urejanje konfiguracijske datoteke in zagotavljanje njene pravilnosti za pravilno delovanje namestnika Korak 1 osnovno sprejemanje in posredovanje sporočil Najprej smo naredili osnovni sprejem sporočil protokola SNMP verzije 1 in 2c, nato pa smo implementirali preslikavo med verzijama 1 in 2c, ter pošiljanje na ciljni računalnik. Sprejemanja sporočil v tem koraku nismo omejevali, pošiljali pa smo na vnaprej določen naslov, kjer smo lahko preverjali ustreznost poslanega paketa. Zatem smo dodali še funkcionalnost sprejemanja povratnih sporočil (SNMP Response), njihovo preoblikovanje v ţeleno verzijo protokola ter posredovanje odgovora agentu. Na koncu tega koraka pa smo dodali podporo še ostalim tipom sporočil, ki so opisani v podpoglavju 3.2, razen tipov SNMP TRAP in NOTIFICATION.

32 Korak 2 uvedba protokola SNMPv3 V drugem koraku smo dodali podporo verziji 3 protokola SNMP. Najprej smo izvedli implementacijo tega protokola brez overjanja in brez zasebnosti. Šele po pravilnem delovanju osnovne različice verzije 3, smo postopoma dodajali overitev in zasebnost. Po tem koraku pričakujemo sposobnost sprejemanja vseh paketov verzije 1 in 2c, ter posredovanje sporočil v poljubni verziji protokola. Prejeti odgovor se mora pravilno obdelati in odgovor vrniti agentu Korak 3 omogočanje večjega števila preslikav Do tega koraka smo imeli preslikavo samo med enim managerjem in agentom. Sedaj ţelimo uvesti večje število preslikav, ki smo jih na začetku zapisali kar v sam program. Vsaka preslikava se je zaradi večje hitrosti delovanja izvajala v svoji niti. S tem smo naredili naš program večnitni (multi-threaded). Za nas je to pomenilo, da je bilo vsako nepravilnost teţje odkriti ter smo zato morali biti pri programiranju še posebej previdni. Pravilnost delovanja smo temeljito preizkusili z vsemi kombinacijami preslikav in vsemi moţnimi tipi sporočil Korak 4 zapis podatkov v konfiguracijsko datoteko V prejšnjem koraku smo preslikave napisali kar v sam program, kar pa je za končni produkt nesprejemljivo. V nadaljevanju smo zato realizirali branje preslikav iz datoteke shranjene na disku. To branje se mora izvesti ob zagonu programa. Zaradi nedvoumnosti zapisa smo definirali pravila za zapis preslikav. Najbolj preprost način je prikazan na sliki 5.

33 24 Slika 5: Primer zapisa preslikave brez profilov. Na tem primeru vidimo, da poslušamo sporočila tipa QUERY (GET, GETNEXT, GETBULK, WALK in SET) na vratih Sporočilo mora biti verzije 1 (SNMPv1) z nastavljeno skupino dostopa "public" oz. "private", če je sporočilo tipa SNMP SET. Sporočilo pretvorimo v verzijo 3 (SNMPv3) z overitvenim geslom "AuthPassword", zasebnim geslom "PrivPassword" in uporabniškim imenom "SHA_DES_User", ter ga pošljemo na naslov na vrata 161 (ki so privzeta za vsa sporočila SNMP tipa QUERY). Predstavimo, da imamo n naprav, ki na identičen način sprejemajo ali pošiljajo sporočila. Potemtakem bi imeli n zapisov po 17 vrstic, kar pa pri velikem n lahko zasede ogromno prostora, hkrati pa branje takšne datoteke lahko preseţe pričakovan odzivni čas. Zato smo se odločili, da uvedemo profile, ki nedvoumno določajo tip sporočila z vsemi potrebnimi parametri. Če bi imele vse naprave različne nastavitve, potem s takšnim pristopom nismo naredili nobenega napredka. V praksi pa se pogosto dogaja, da ima več naprav iste nastavitve, hkrati pa sprejemajo sporočila istega tipa z enakimi varnostnimi parametri. Zaradi tega smo zapis v konfiguracijski datoteki spremenili v zapis, ki je prikazan na sliki 6.

34 25 Slika 6: Primer zapisa preslikave s profili. Vidimo lahko, da smo vse zapise, ki se navezujejo na tip sporočila zamenjali z dvema profiloma. Oba profila smo v nadaljevanju konfiguracijske datoteke tudi definirali (glej sliko 7). Slika 7: Dva zgleda za zapis profila: levo profil za verzijo SNMPv1, desno profil za verzijo SNMPv3. Pri konfiguraciji neke druge (nove) naprave lahko uporabimo obstoječe profile, s čimer prihranimo nekaj diskovnega prostora, pohitrimo pa tudi sam zagon programa. Pri sklicevanju na profil uporabimo ime profila, ki je zapisano pod ključem PROFILE_NAME. Če ţelimo, na primer, definirati novo preslikavo med agentom in managerjem, kjer oba uporabljata protokol SNMPv1 s standardnimi varnostnimi parametri, kjer je skupina dostopa za branje "public" in skupina dostopa za pisanje "private", lahko to na kratko zapišemo kot je prikazano na sliki 8. Slika 8: Zapis nove preslikave z vnaprej definiranimi profili.

35 26 Profila "V1_Public" nam tako ni potrebno še enkrat definirati, saj smo ga ţe definirali pri preslikavi "proxy1" (glej sliko 7). Ljudje smo zmotljivi, zato bi se pri ročnem vnašanju podatkov v takšno strukturo hitro zmotili ali pa bi postala datoteka preveč obseţna, da bi uspeli slediti vsem oznakam in številkam. Zato smo razvili še kratek program z ustreznim uporabniškim vmesnikom, s katerim uporabniku poenostavimo delo pri konfiguriranju. Naš program z razširjeno funkcionalnostjo smo nato temeljito preizkusili, hkrati pa smo izvedli še prvi obremenitveni test, kjer smo program pustili delovati najmanj 24 ur, da bi se pokazale morebitne pomanjkljivosti pri daljšem delovanju, kot so konstantno povečanje porabe pomnilnika (memory leak) ali procesorskega časa Korak 5 podpora sporočilom SNMP TRAP in INFORM V petem koraku smo dodali funkcionalnost obdelave sporočil tipa SNMP TRAP in INFORM. Pri teh sporočilih je posebnost, da jih pošilja agent in ne manager, zato moramo omogočiti tudi preslikovanje v obratni smeri. Tudi te preslikave moramo definirati v konfiguracijski datoteki. Primer takšne definicije je prikazan na sliki 9. Slika 9: Definicija preslikave za sporočila tipa SNMP TRAP in INFORM. Vidimo, da je zapis preslikave zelo podoben ţe omenjenim zapisom (glej sliki 6 in 8), od njih se loči le po ključu "TYPE". Za ta ključ imamo v splošnem dve moţnosti, in sicer "Query" ali "Notification".

36 Korak 6 prenos na operacijski sistem Unix Ena izmed glavnih zahtev delovanja našega programa je bila, da bi deloval tudi v drugih operacijskih sistemih (predvsem v OS Unix). Zato smo med samo implementacijo morali upoštevati razlike med sistemskimi klici v različnih operacijskih sistemih, in uporabljati čim bolj splošne klice. Izbrali smo OS Linux in distribucijo Red Hat 9.0. V tem koraku smo prenesli vso izvorno kodo programa iz OS Windows na izbrani sistem. Ustrezno smo napisali datoteko Makefile ter zatem prevedli izvorno kodo v izvedljivi modul. Cilj je seveda bil, da bi bila izvorna koda enaka na obeh operacijskih sistemih. Delujoči program smo temeljito preizkusili na obeh operacijskih sistemih. Prav tako smo še izvedli obremenitveni test na OS Linux. Ko je bila poraba pomnilnika enakomerna skozi celoten čas delovanja in ko tudi sicer nismo zasledili programskih napak, smo sklepali, da je program uspešno napisan Korak 7 program za urejanje konfiguracijske datoteke Čisto na koncu pa smo razvili še kratek programski modul za urejanje konfiguracijskih datotek. Zahtevana funkcionalnost je bila, da mora uporabniški vmesnik tega programa biti napisan razumljivo in brez dvoumnosti, tako da bo njegova uporaba kar najbolj enostavna. Vsebovati pa mora tudi zaščito proti brisanju profilov, in sicer tistih profilov, ki so trenutno v uporabi pri kateri izmed preslikav. Zaţelena je moţnost preizkušanja določene preslikave. Namestnik in program za konfiguriranje morata uporabljati isto izvorno kodo za branje in pisanje v konfiguracijsko datoteko. 5.2 Implementacija Naš programski produkt smo implementirali v programskem jeziku C++ v razvojnem okolju Visual Studio Program je dejansko konzolna aplikacija. Med implementacijo smo morali še paziti, da ga je bilo moţno prevesti tudi na OS Linux. Implementacije smo se lotili na osnovi grobega in detajlnega načrta (grobi načrt je bil opisan v podpoglavju

37 28 5.1). Pri implementaciji smo si pomagali s programskimi razredi, ki so jih napisali v podjetju MG-Soft. Ta programska koda je namreč dobro preizkušena, hkrati pa smo s tem tudi poenostavili in pohitrili razvoj programa Korak 1 osnovno sprejemanje in posredovanje sporočil Za implementiranje sprejemanja sporočil smo uporabili obstoječi razred podjetja MG-Soft, ki se uspešno uporablja v nekaterih drugih programskih produktih. S tem smo zagotovili pravilnost delovanje, saj je ta razred ţe dodobra preizkušen. Preslikave med verzijama 1 in 2c protokola SNMP smo se lotili postopoma. Najprej smo prejeti paket razstavili na dele, v drugi funkciji pa smo sestavili nov paket. V prejetem paketu nas zanimajo naslednji podatki: a) verzija protokola uporabimo funkcijo SnmpGetProtocolVersion(), b) tip sporočila (številska koda operacije SNMP) in c) struktura VBL (variable binding list) jo dobimo iz strukture PDU s klicem funkcije SnmpGetPduData(). V drugi funkciji pa ustvarimo nov paket. Zanj ustvarimo lasten PDU s funkcijo SnmpCreatePdu(), kjer kot argument podamo številsko kodo operacije SNMP ter VBL (ki smo ju pridobili iz podatkov prejetega sporočila), identifikacijsko številko izhodnega paketa in še nekaj manj pomembnih podatkov. Paket pošljemo s klicem funkcije SnmpSendMsg(), kjer kot argumente podamo kazalec na strukturo PDU, varnostne parametre in podatke o ciljnem računalniku. Na ciljnem računalniku preverimo ustreznost poslanega paketa in vrnemo odgovor, tj. paket tipa SNMP RESPONSE. Odgovor se vrne na isti naslov od kjer je bila poslana zahteva, v enaki verziji protokola in z enakimi varnostnimi parametri. V našem programskem produktu sprejmemo odgovor na enak način kot zahteve, tj. z uporabo obstoječega razreda. Tudi ta paket razdelimo na dele, ustvarimo nov paket, ki ga pošljemo izvornemu računalniku. Pri kreiranju novega paketa moramo paziti, da so varnostni parametri enaki tistim, s katerimi smo zahtevo prejeli, prav tako pa mora biti identifikacijska številka paketa z odgovorom enaka identifikaciji, ki jo je nosil paket z zahtevo. Zaradi tega moramo hraniti te podatke od trenutka prejetja zahteve pa vse do trenutka, ko pošljemo odgovor.

38 29 S takšno implementacijo smo dejansko podprli še ostale tipe sporočil, saj smo izhodnemu sporočilu vedno priredili isti tip, kot ga ima vhodno sporočilo. Sledil je temeljit preizkus delovanja programa. Med preizkusom smo opazili, da se poraba pomnilnika s časom izvajanja povečuje. Ker si podatkov ne shranjujemo, bi morala biti poraba pomnilnika večino časa konstantna, s kratkotrajnimi nihanji. Na osnovi posvetovanja smo ugotovili, da je za razliko od navadnih podatkovnih tipov (npr. število in niz), treba vse uporabljene tipe v tej komunikaciji na koncu vsake funkcije sprostiti, za kar obstajajo namenske funkcije. Problem so predstavljali naslednji podatkovni tipi: HSNMP_VBL, HSNMP_CONTEXT, HSNMP_PDU, HSNMP_ENTITY, smioid, smivalue in smioctets. Za sprostitev prostora, ki ga zasedajo spremenljivke teh tipov, pa se uporabljajo naslednje namenske funkcije, in sicer SnmpFreeDescriptor(), SnmpFreeVbl(), SnmpFreeEntity(), SnmpFreeContext() in SnmpFreePdu(). Tako smo na koncu vsake funkcije poskrbeli za sproščanje uporabljenih spremenljivk in poraba pomnilnika se je ustalila Korak 2 uvedba protokola SNMPv3 V tem koraku smo omogočili, da se izhodna zahteva lahko preoblikuje v verzijo 3 protokola SNMP. To pomeni, da lahko namestniku pošljemo zahtevo v verziji 1 ali 2c, on pa jo bo znal preoblikovati v verzijo 3. Koda za sprejemanje zahtev ostane enaka kot v koraku 1, nadgraditi moramo le drugi del, tj. kreiranje izhodnega sporočila in prejem odgovora. Za nastavljanje varnostnih parametrov za verzijo 3 protokola SNMP smo napisali novo funkcijo SetSecurityParams(). V verziji 3 imamo tri varnostne nivoje, zato moramo najprej preveriti, kateri varnostni nivo potrebujemo. Varnostni nivoji so: - SNMP_SEC_LEVEL_NOAUTH_NOPRIV brez overitve in brez zasebnosti, - SNMP_SEC_LEVEL_AUTH_NOPRIV z overitvijo in brez zasebnosti, - SNMP_SEC_LEVEL_AUTH_PRIV z overitvijo in z zasebnostjo. Varnostne parametre nastavljamo s klicem funkcije SnmpSetContextParameters(), ki ima naslednje parametre:

39 30 - hcontext: kontekstni objekt - pcontextname: ime kontekstnega objekta - pcontextengineid: ID kontekstnega motorja - psecurityname: varnostno ime - psecurityengineid: ID varnostnega motorja - nsecuritymodel: varnostni model - nminsecuritylevel: minimalen varnostni nivo - nmaxsecuritylevel: maksimalen varnostni nivo - nsecuritylevel: varnostni nivo - nauthprotocol: overitven protokol - pauthkey: overitven ključ - nprivprotocol: protokol zasebnosti - pprivkey: ključ zasebnosti. Nastavljanje različnih varnostnih nivojev smo preprosto rešili s switch stavkom. Psevdokod takšnega delovanja je prikazan na sliki 10. Slika 10: Psevdokod preverjanja varnostnega nivoja za verzijo 3 protokola SNMP. Verzija 3 protokola SNMP ima lastnost, da moramo nastaviti identifikacijske številko ciljne naprave (t.i. engine ID), ki jo dobimo tako, da pošljemo agentu zahtevo. Le-ta ugotovi, da številka ni pravilna, zato nam ne vrne odgovora (RESPONSE), ampak poročilo (REPORT), kar je nova vrsta paketa, ki ga je uvedla verzija 3. V tem poročilu je zapisano identifikacijsko število, ki si ga moramo zapomniti in uporabiti pri vsakem naslednjem paketu. Ker to poročilo ni odgovor, ki bi ga ţelel manager, zato moramo zahtevo ponovno poslati. Paket je popolnoma enak kot pri prvem pošiljanju, le da je spremenjena oz.

40 31 vnesena pravilna identifikacijska številka. Vendar tudi tokrat, agent še ne vrne odgovora, ampak še eno poročilo. Gre za poročilo, s katerim usklajujemo uro, kar je še en varnostni mehanizem verzije 3. Po obdelavi tega drugega poročila, pošljemo isto zahtevo še tretjič (ura je sedaj sinhronizirana). Šele tokrat dobimo pričakovan odgovor, ki ga obdelamo in vrnemo managerju. Zgoraj opisani postopek je treba izvesti le ob prvem pošiljanju zahteve agentu. Prejete podatke si moramo zato shraniti. Vsaki naslednji zahtevi pa te podatke takoj priredimo. Na ta način nam agent ţe v prvem povratnem paketu vrne pričakovan odgovor Korak 3 omogočanje večjega števila preslikav V tem koraku smo izvajanje vsake preslikave implementirali v svoji niti. V primeru manjšega števila preslikav se razlika v hitrosti izvajanja med klasično implementacijo preslikav in implementacijo preslikav z nitenjem ne bi poznala prav veliko. Pričakuje pa se, da bo število preslikav v posameznih primerih preseglo število 100. Zato je implementacija z uvajanjem nitenja nujno potrebna. Pri implementaciji tega koraka smo si prav tako pomagali z obstoječim in dobro preizkušenim razredom podjetja MG-Soft (razred MgWThread). Nadgrajeni programski sistem smo preizkusili z več različnimi preslikavami. Preizkus smo izvedli s petimi nitmi, kjer smo uporabili različne kombinacije preslikav in vse tipe sporočil Korak 4 zapis podatkov v konfiguracijsko datoteko V tem koraku smo naš program dopolnili tako, da ob zagonu prebere dovoljene preslikave iz konfiguracijske datoteke. Zapis oz. obliko konfiguracijske datoteke smo definirali ţe v podpoglavju 5.2.4, tukaj moramo le še implementirati branje iz te datoteke. Podoben zapis, kot je v konfiguracijski datoteki, uporabljamo še na drugih mestih, zato za implementacijo branja uporabimo kar obstoječi razred CDataFile podjetja MG- Soft, ki ga malenkostno modificiramo. Razred je ţe v osnovi napisan tako, da deluje pod

41 32 OS Windows, Unix in Apple. Ta razred dejansko vrača posamezne sektorje iz datoteke, zato moramo v našem programu zgolj še poskrbeti za pravilno interpretacijo teh zapisov. Zapise iz datoteke dobimo s pomočjo funkcije GetSection(), kjer kot argument podamo ime sekcije. V spodnjem primeru je ime sekcije "proxy1" (glej sliko 11). S funkcijo GetKey() dobimo posamezen ključ. Tej funkciji kot argument podamo ime sekcije (ali strukturo, ki jo vrne funkcija GetSection()) in ime ključa, ki nas zanima. Ključi so v spodnjem primeru SEND_ADDRESS, RCV_PORT in SEND_PORT, če naštejemo le nekatere. Funkcijo GetValue() pa uporabimo, če nas zanima vrednost posameznega ključa. Kot argument podamo ime sekcije (ali strukturo, ki jo vrne funkcija GetSection()) in ustrezno ime ključa. Po seznamu sekcij in ključih se lahko tudi pomikamo, in sicer s funkcijami GetFirstSectionName(), GetNextSectionName(), GetFirstSection(), GetNextSection(), GetFirstKey() in GetNextKey(). Slika 11: Primer zapisa preslikave v konfiguracijski datoteki. Ob zagonu programa s pomočjo zgoraj opisanih funkcij preberemo podatke iz datoteke in jih zapišemo v ustrezne spremenljivke. Pri tem smo predpostavili, da je konfiguracijska datoteka zapisana brez napak. Ta predpostavka je razumna, saj bo uporabnik vnašal vse preslikave s pomočjo namenskega programa (le-tega bomo predstavili v nadaljevanju). Sledil je temeljit preizkus programa, kjer smo vključili tudi prvi obremenitveni test. Program smo pustili neprekinjeno delovati 24 ur. Na ta način smo ţeleli odkriti morebitne pomanjkljivosti, predvsem neprimerno povečanje porabe pomnilnika. Preizkus smo izvedli tako, da smo najprej v konfiguracijsko datoteko vnesli nekaj pravilnih in nekaj namerno nepravilnih preslikav. Nato smo vnesli še 10 pravilnih preslikav ter pustili program delovati 24 ur. V tem času smo programu pošiljali v povprečju 3000 zahtev na sekundo.

42 33 Poraba pomnilnika se je v prvih minutah povečala za 20 %, nato pa v naslednjih 24 urah še za dodatnih 10 %, kar je pri takšni obremenitvi popolnoma sprejemljivo Korak 5 podpora sporočilom SNMP TRAP in INFORM Do polne funkcionalnosti našega programa manjka le še podpora sporočilom SNMP TRAP in INFORM. V tem koraku smo implementirali razred za sprejem in posredovanje teh dveh tipov sporočil. Pošiljanje sporočil poteka le v eni smeri, saj odgovora ne pričakujemo. Tudi pri pošiljanju teh sporočil potrebujemo preslikave. Zapis za preslikave smo definirali ţe v podpoglavju Razlika med prejšnjimi in tem zapisom je zgolj v ključu "TYPE", kjer imamo dve moţnosti, in sicer "QUERY" (za vse ţe prej omenjene tipe sporočil) ali "NOTIFICATION" (za sporočila tipa TRAP ali INFORM). Funkcionalnost tega razreda je podobna delovanju razreda za obdelavo ostalih sporočil protokola SNMP. Sporočilo torej sprejmemo, ga obdelamo in po potrebi zapišemo v drugi verziji protokola. Nov sestavljen paket pa pošljemo ciljnemu računalniku. Z dodajanjem te funkcionalnosti smo program dokončali. Program smo nato še temeljito preizkusili Korak 6 prenos na operacijski sistem Unix Na zadnje pa smo naš program prenesli še na OS Linux. Najprej je bilo potrebno napisati Makefile. To je dejansko skriptna oz. paketna datoteka, ki vsebuje zaporedje ukazov. Datoteko Makefile aktiviramo z ukazom make v ukazni lupini. V datoteki Makefile se uporabljajo spremenljivke, ki pa jih ni treba definirati. Le-te se namreč definirajo avtomatsko ob prvi uporabi, na njih pa se sklicujemo po naslednji sintaksi: znaku $ sledi v oklepajih zapisano ime spremenljivke (npr. "$(CC)"). Večino razlik med operacijskima sistemoma Windows in Linux smo identificirali ţe med implementiranjem, zato se je izvorna koda z manjšimi popravki zelo hitro prevedla v izvedljivi modul. Izvedljivi modul smo nato izčrpno preizkusili. Test je odkril določene napake, ki smo jih uspešno popravili.

43 34 Sledil je obremenitveni test na OS Linux, kjer smo ugotovili, da poraba pomnilniškega prostora bolj niha kot na OS Windows. Razlog za takšno obnašanje je značilnost OS Linux, ki pomnilnika ne sprošča sproti, ampak v rednih časovnih intervalih. Kodo na obeh operacijskih sistemih smo nato dokončno uskladili ter izvedli še hitri preizkus delovanja. Med zadnjim preizkušanjem nismo odkrili napak Korak 7 program za urejanje konfiguracijske datoteke Uporabniku ţelimo čimbolj olajšati delo z namestnikom, zato smo razvili še poseben program, ki je namenjen aţuriranju podatkov v konfiguracijski datoteki. Ta program smo poimenovali Konfigurator. Osnovni namen Konfiguratorja je, da uporabniku poenostavi delo s konfiguracijsko datoteko. Tako več ni potrebno ročno vpisovanje v konfiguracijsko datoteko, hkrati pa ta programski modul tudi zagotovi, da je konfiguracijska datoteka pravilno zapisana, s čimer se izognemo morebitnim napakam pri branje datoteke oz. napačnemu interpretiranju prejetih sporočil. Program mora biti čimbolj preprost, zato smo zgradili preprost uporabniški vmesnik, kjer so vsi izpisi berljivi in lahko razumljivi. Končni izgled uporabniškega vmesnika z ţe prebranim primerom konfiguracijske datoteke je prikazan na sliki 12. Slika 12: Uporabniški vmesnik Konfiguratorja.

44 35 Podatki so urejeni po vrstnem redu, in sicer so najprej podatki o sprejemu, nato o obdelavi, na koncu pa o pošiljanju paketa. V prvi vrstici vidimo, da program posluša na vratih 6160 (glej sliko 12). Pričakujemo, da bodo sporočila, ki bodo prispela na ta vrata, imela varnostne parametre definirane v profilu V1_Public. Prejeto sporočilo pretvorimo tako, da ustreza varnostnim parametrom definiranim v profilu SHA_DES_User ter ga pošljemo na vrata 161 računalnika z naslovom IP Na sliki 12 vidimo 2 zavihka. V prvem zavihku (Query) so prikazane preslikave za vse tipe sporočil, razen za tipa TRAP in INFORM. V drugem zavihku (Notification) pa so prikazane preslikave samo za sporočila tipa TRAP in INFORM. Uporabniški vmesnik je tudi v tem zavihku popolnoma identičen zgoraj opisanem, razlika je le v prikazanih podatkih. Na dnu tega vmesnika najdemo standardne kontrolne gumbe, kot so Exit (zapre okno, vse ne shranjene spremembe pa zavrţe), Apply (shrani spremembe ter ponovno zaţene Konfigurator) in OK (shrani spremembe in zapre program). Na desni strani uporabniškega vmesnika pa imamo gumbe za upravljanje s preslikavami. Funkcionalnosti teh gumbov so enake ne glede na izbran zavihek. V nadaljevanju bomo na kratko predstavili funkcionalnost teh kontrolnikov. Gumb Add Ob pritisku na gumb Add se odpre okno za vnos nove preslikave (glej sliko 13). Slika 13: Okno za dodajanje novih preslikav.

45 36 V vnosno polje Recieve port vnesemo številko vrat, kjer bomo poslušali/tipali sporočila. Pri drugem in tretjem kontrolniku imamo spustni meni, kjer iz menija izberemo ţeleni profil za prejem in pošiljanje. V polje Send port vnesemo vrata ciljnega računalnika, v kontrolnik Send Address pa naslov ciljnega računalnika. Če odgovora ne dobimo, pa vnosno polje Timeout določa čas (v sekundah) po katerem sporočilo ponovno pošljemo. Dovoljeno število teh poizkusov oz. ponovitev je določeno s kontrolnikom Retries. Ob pritisku na gumb OK se vnesena preslikava shrani v notranjo podatkovno strukturo, ki jo lahko zatem (od pritisku na gumb Apply ali OK glavnega okna) shranimo v konfiguracijsko datoteko. Gumb Cancel ta dialog zapre, hkrati pa se vsi vnosi zavrţejo. Gumb Edit Če ţelimo aktivirati gumb Edit moramo najprej izbrati ţeleno preslikavo iz seznama preslikav. Če povezave ne izberemo, se ob pritisku na ta gumb privzeto izbere kar prva povezava v seznamu. Enak učinek doseţemo, če dvakrat kliknemo na ţeleno preslikavo v seznamu. Dialog, ki se odpre (viden na sliki 14), ima enak nabor vnosnih polj kot vmesnik na sliki 13, le da so vnosna polja ţe izpolnjena. Vrednosti polj lahko po potrebi spremenimo in shranimo. Slika 14: Prikaz okna za urejanje preslikave.

46 37 Gumb Delete Ob pritisku na gumb Delete se odpre dialog, kjer potrdimo ali prekličemo brisanje izbrane preslikave. Gumb Test Z akcijo Test lahko preizkusimo delovanje agenta izbrane preslikave z nastavitvami, ki so določene v profilu Forward Profile. Z aktiviranjem tega gumba preverimo tudi, če je naprava (agent) v omreţju dosegljiva. Ta operacija pošlje paket z identifikacijo OID=0, operacijo GETNEXT in varnostnimi parametri definiranimi v izbranem izhodnem profilu za tega agenta. Če dobimo odgovor, potem uporabniku javimo, da naprava deluje, v nasprotnem primeru pa sporočimo napako, ki lahko pomeni, da je preslikava narobe definirana oz. naprava ni dosegljiva. Gumb Profiles S pritiskom na gumb Profiles (glej sliko 12) se odpre dialog s seznamom vseh vnesenih profilov. Iz slike 15 vidimo, da lahko profile dodajamo (Add), urejamo (Edit) ali brišemo (Delete). Dialog se odpre kot aplikacijsko modalno okno, kar pomeni, da moramo dokončati delo v tem dialogu preden se vrnemo v glavno okno Konfiguratorja. Gumbe na dnu tega dialoga pa uporabljamo za zapiranje okna in shranjevanje sprememb (gumb OK), zgolj za shranjevanje sprememb (gumb Apply) ali pa za zapiranje okna in zavračanje vseh neshranjenih sprememb (gumb Exit).

47 38 Slika 15: Prikaz okna za delo s profili. Za dodajanje novega profila aktiviramo gumb Add. Odpre se dialog, prikazan na sliki 16. Vanj vpišemo zahtevane lastnosti profila. Tukaj določimo ime profila in verzijo protokola SNMP. Glede na izbrano verzijo protokola SNMP se omogočijo oz. onemogočijo ostale lastnosti profila. Pri verziji 1 ali 2c moramo samo vpisati niz znakov za skupino dostopa za branje in pisanje (Read in Write Community). Če smo pa kot verzijo protokola izbrali verzijo 3 pa moramo vpisati še preostale podatke, kot so uporabniško ime, vrsta overitve (Authorisation), overitveno geslo, vrsto zasebnosti (Privacy) in geslo za zasebnost. Slika 16: Dialog za dodajanje profilov.

48 39 Pri urejanju profila se odpre enak dialog, kot je prikazan na sliki 16, le da so vsa polja ustrezno zapolnjena glede na izbran profil, ki ga urejamo. Pri brisanju profila se odpre dialog, kjer potrdimo oz. prekličemo brisanje. Če se profil uporablja v kateri izmed ţe vnesenih preslikav, se pri poskusu brisanja takšnega profila odpre dialog z obvestilom, ki uporabnika opozori, da je profil v uporabi in ga ni moţno izbrisati (glej sliko 17). Tedaj moramo bodisi izbrisati preslikavo, ki uporablja izbrani profil ali pa preslikavi ustrezno spremeniti profil. Šele ko tega profila ne uporablja nobena preslikava več, je izbris profila dovoljen. Slika 17: Obvestilo o profilu, ki je v uporabi.

49 40 6 PREIZKUŠANJE NAMESTNIŠKEGA STREŢNIKA V tem poglavju bomo opisali preizkus delovanja našega namestnika, ki smo ga preizkusili po metodi bele in črne škatle. Razloţili bomo, kaj pomeni posamezna metoda preizkušanja ter opisali njene prednosti ter slabosti. Na koncu poglavja pa bomo pregledali še moţnosti uporabe namestnika SNMP pri oddaljenem diagnosticiranju. 6.1 Preizkušanje po metodi bele škatle Preizkušanje po metodi bele škatle je preizkušanje, kjer imamo znan vhod, vemo kaj ţelimo na izhodu, zanima pa nas, kako iz vhodnih podatkov, po korakih, dobimo izhodne. S to metodo lahko pribliţno ocenimo tudi pokritost preizkušanja kode in nastavimo takšne vhodne podatke, da je pokritost kar največja. To vrsto preizkušanja imenujemo tudi strukturno preizkušanje. To preizkušanje smo izvajali med programiranjem, kjer smo preizkušali posamezne funkcije in razrede. Naš programski produkt smo razvili v okolju Microsoft Visual Studio 2005, ki ima vgrajen zelo pregleden očiščevalnik (debuger). To vrsto preizkušanja smo izvajali ves čas programiranja in sproti izvajali potrebne popravke programske kode. Druga metoda preizkušanja po metodi bele škatle je preizkušanje z izpisi. Kot smo omenili v podpoglavju imamo opravka z večnitnim programom, ki ga ne moremo v celoti preizkusiti z očiščevalnikom. V posamezne dele programske kode predvsem v tiste dele, ki se izvajajo v več nitih smo zato dodali različne izpise, s katerimi smo lahko po koncu izvajanja iskali morebitne napake. V primeru, da se je pokazala nepravilnost, smo najprej identificirali programsko kodo, kjer se je nahajal ustrezen izpis, zatem pa smo še popravili ta del kode, ki je vsebovala programsko napako. Moduli oz. posamezni deli našega programa so primerne velikosti, zato smo jih lahko brez večjih teţav preizkusili po metodi bele škatle. Za preizkušanje delovanja programa kot celote pa smo uporabili metodo črne škatle.

50 Preizkušanje po metodi črne škatle Pri preizkušanju po metodi črne škatle poznamo vhod in vemo, kaj pričakujemo na izhodu, vendar pa vpogleda v potek izvajanja nimamo oz. strukture programa ne poznamo. V tej metodi zato zgolj primerjamo dobljene izhode s pričakovanimi. To preizkušanje smo v našem produktu izvedli na ţe končanem programu (po fazi integracije). Izvajali smo ga tako, da smo na ciljnem računalniku preverili podatke, ki smo jih zahtevali, nato pa smo poslali zahtevo. Prejete podatke smo nato primerjali z dejanskimi podatki, ki smo jih dobili neposredno iz ciljnega računalnika. Če so se podatki ujemali, smo predpostavili, da naš namestnik deluje pravilno. Preizkus smo ponovili večkrat, vendar vsakokrat z različnimi zahtevami. Na ta način smo dosegli kar se da veliko pokritost preizkušanja kode. To metodo preizkušanja smo uporabili tudi pri preizkušanju programa z obremenitvijo (glej podpoglavje 5.1.4). 6.3 Namestnik in oddaljeno diagnosticiranje V nadaljevanju bomo opisali pojem oddaljeno diagnosticiranje, ob tem pa se bomo dotaknili tudi moţnosti, kako lahko uporabimo namestniški streţnik pri oddaljenem diagnosticiranju. Opise bomo podkrepili s praktičnimi primeri in moţnimi scenariji uporabe Oddaljeno diagnosticiranje Oddaljeno diagnosticiranje je diagnosticiranje strojne računalniške opreme, kjer nadzor oz. preizkušanje naprave opravljamo oddaljeno preko določene komunikacijske povezave. V praksi srečamo oddaljeno diagnosticiranje na različnih področjih, npr. v medicini, pri nadzoru mnoţice računalniških sistemov povezanih v omreţje, pri spremljanju dirkalnih avtomobilov, v vesoljskih plovilih, v letalih itd. Oddaljeno diagnosticiranje je po eni strani priljubljeno in koristno. Razlogov je več. Prvi razlog je zagotovo niţji stroški nadzora. Pri vesoljskih plovilih bi bilo nesmiselno voziti mnoţico ljudi, ki bi opravljala

51 42 diagnosticiranje. Drugi razlog pa je zagotovo večja varnost, saj lahko pri oddaljenem nadzoru vesoljskih plovil le-to opravimo kar iz varnega in nadzorovanega prostora (npr. pisarne). Nekaj podobnega je tudi pri nadzorovanju dirkalnih avtomobilov, kjer je ključnega pomena vsak dodaten kilogram teţe avtomobila. Oglejmo si primer uporabe oddaljene diagnostike pri spremljanju stanja dirkalnega avtomobila med dirkanjem. Inţenirji, ki se običajno nahajajo v garaţi, imajo s pomočjo računalnikov in oddaljene diagnostike moţnost spremljati vso dogajanje v dirkalnem avtomobilu na stezi. Na vpogled imajo različne podatke, in sicer od osnovnih podatkov, kot so npr. pritisk zraka v pnevmatikah, količina goriva v rezervoarju, izbrana prestava, lokacija na stezi, hitrost, število vrtljajev motorja, pa vse do kompleksnih podatkov, kot je npr. količina goriva vbrizgana v posamezen cilinder na takt motorja, porazdelitev zavorne sile glede na pritisk v amortizerjih, pre-krmarjenje, pod-krmarjenje ipd. Inţenirji imajo torej moţnost preučiti vse te podatke, hkrati pa lahko s pomočjo namenskih programov identificirajo, katero nastavitev avtomobila je smiselno prilagoditi. Tako lahko med obveznim postankom avtomobila zaradi menjave izrabljenih pnevmatik hitro spremenijo še druge nastavitve avtomobila. Takšno posodabljanje praktično zahteva minimalno časa, hkrati pa lahko dirkalnemu avtomobilu bistveno izboljša vozne lastnosti, kar se seveda pozna na dirkalni stezi. V opisanem zgledu je bila oddaljena diagnostika ob ţe zgoraj opisanih dveh razlogih koristna še zaradi bistvenega zmanjšanja količine ročnih posegov serviserjev na avtomobilu med dirko, saj se večina dela lahko opravi kar oddaljeno. S tem seveda lahko zmanjšamo število serviserjev (lokalno osebje) na minimum, kar po eni strani pomeni niţje stroške, po drugi strani pa tudi večjo varnost pri delu, saj te serviserje lahko zelo dobro izurimo za majhno število ročnih posegov, ki jih bodo med dirko opravljali Uporaba namestniškega streţnika za oddaljeno diagnosticiranje Iz opisanih prednosti oddaljenega diagnosticiranja opazimo, da je protokol SNMP zelo primeren za takšno delo. Z njim je namreč omogočen vpogled v vsako, še tako majhno podrobnost računalniškega sistema. Kot ţe vemo pa je protokol SNMP izredno hiter in učinkovit, omogoča pa tudi spreminjanje nastavitev.

52 43 V zgledih, opisanih v podpoglavju 6.3.1, bi lahko zelo učinkovito uporabili tudi naš namestniški streţnik za oddaljeno diagnosticiranje. Treba je vsekakor omeniti, da se danes v praksi uporabljajo drugačne rešitve (namenska programska oprema in namenski protokoli), vendar bi te probleme ekvivalentno rešili tudi s protokolom SNMP in našim namestnikom. Naš namestnik deluje na operacijskem sistemu Linux, Windows in Mac OS. Pri svojem delu zelo malo obremeni centralno procesorsko enoto, hkrati pa porabi tudi zelo majhno količino delovnega pomnilnika. Za njegovo izvajanje ne potrebujemo posebej zmogljivega računalniškega sistema. Takšni računalniki pa so danes lahko zelo majhnih dimenzij in teţe. V nadaljevanju bomo opisali nekaj scenarijev, kako bi naš namestnik uporabili v zgledih, predstavljenih v podpoglavju Predpostavimo še, da je na vseh sistemih podprta verzija 1 in/ali 2c protokola SNMP. Naša zahteva pa je, da ţelimo varen prenos podatkov na osnovi protokola SNMP. V dirkalnem avtomobilu ni prostora za osebni računalnik. Zato bi morali uporabiti manjši namenski računalniški sistem, na katerega bi namestili posebne specifične uporabniške programe. Takšen sistem bi prenašal nezavarovane podatke do managerja. To pa seveda ni sprejemljivo, saj bi lahko tudi druge ekipe spremljale, kaj se dogaja z avtomobilom. S tem bi druge ekipe dobile moţnost, da bi na nepošten način prišle do tajnih podatkov o dirkalnem avtomobilu, kar bi bilo moţno uporabiti pri posodabljanju nastavitev svojih avtomobilov, lahko pa bi celo izvedli sabotaţo ter bi posegli v nastavitve našega avtomobila. Spreminjanje funkcionalnosti (še bolj pa protokola prenosa podatkov) takšne uporabniške aplikacije običajno predstavlja velik strošek, hkrati pa je tudi preizkušanje takšne programske opreme v praksi lahko zelo nevarno. Dosti enostavneje je zgolj spremeniti ciljni naslov IP, kamor naj računalniški sistem avtomobila pošilja podatke. Ceneje in preprosteje bi bilo, da na ta računalniški sistem namestimo naš namestnik, v obstoječi aplikaciji pa spremenimo ciljni naslov IP tako, da bo vsa sporočila pošiljal našemu namestniku. Namestnik bi prejete podatke zakodiral (tj. jih pretvoril v verzijo 3) in jih poslal na ciljni računalniški sistem (managerja), ki se običajno nahaja v boksu ob dirkalni stezi. Ciljni računalniški sistem je ponavadi eden ali več osebnih računalnikov/ streţnikov, na katerega lahko prav tako brez problema namestimo naš namestnik. S tem bi inţenirji lahko varno spremljali dogajanje in stanje v dirkalnem avtomobilu.

53 44 Podobno bi lahko postopali pri nadzorovanju vesoljskih plovil, letal ipd. Uporabniška programska oprema, ki delujejo lokalno na teh plovilih je običajno zelo dobro preizkušena. Vsako spreminjanje te programske opreme bi, preden bi jo dali v ponovno produkcijsko delovanje, zahtevalo ogromno truda in preizkušanja. Ker je tudi v tem primeru varnost ključnega pomena, bi lahko na popolnoma enak način integrirali namestnik, s katerim pa bi zagotovili varnost prenesenih podatkov.

54 45 7 REZULTATI IN DISKUSIJA Temeljni rezultat tega diplomskega dela je vsekakor nov namestnik SNMP. V okviru tega poglavja bomo demonstrirali delovanje našega novega programskega produkta. Pravilnost delovanja bomo izkazovali s pomočjo posnetkov zajetih zaslonskih mask. Poglavje bomo sklenili s kratkim sklepom. 7.1 Primer delovanja V tem primeru si bomo pogledali postopek, ki je potreben za preslikavo sporočil iz verzije SNMPv1 protokola SNMP v verzijo SNMPv3, pri čemer uporabljamo overitev in zasebnost. Opisali bomo celoten postopek, dobljen rezultat pa bomo preverili z rezultatom, ki ga dobimo, če pošljemo isto zahtevo neposredno na ciljni računalnik, brez posredovanja našega namestnika Vnos podatkov za preslikavo v Konfigurator Najprej v programski modul Konfigurator vnesemo vse podrobnosti preslikave. Gre za naslednje podatke, in sicer številka vhodnih vrat, zahtevani varnostni parametri vhodnega sporočila (določeno s profilom), zahtevani varnostni parametri izhodnega sporočila (profil), vrata ciljnega računalnika in naslov ciljnega računalnika. Rezultat vnosa teh podatkov v Konfigurator je viden na sliki 18.

55 46 Slika 18: Prikaz preslikave v programskem modulu Konfigurator Zagon namestnika Šele ko se podatki o preslikavi shranijo v konfiguracijsko datoteko lahko zaţenemo namestnik. Za laţje razumevanje tega postopka oz. korakov, ki se izvršijo ob zagonu, smo program zagnali v konzolnem načinu. Na sliki 19 lahko tako vidimo inicializacijske zapise. Za nas pomembne vrstice smo označili s kvadratkom. Te vrstice bomo v nadaljevanju tudi na kratko opisali. Pri izpisu v prvi označeni vrstici se izvede branje podatkov iz konfiguracijske datoteke, zatem pa sledi izpis najbolj ključnih podatkov za posamezno preslikavo. Na osnovi tega izpisa lahko morebitno napako v konfiguracijski datoteki hitro izsledimo. V našem primeru so prebrane vrednosti pravilne (glej tudi sliko 18). Pri naslednjih treh označenih vrsticah se izvedejo inicializacijske metode, ki pripravijo preslikavo za uporabo. Inicializacijske metode se izvedejo za vsako preslikavo, ki se nahaja v konfiguracijski datoteki. Ob morebitnih napakah pri inicializaciji lahko prav tako na osnovi teh izpisov hitro ugotovimo, kje je prišlo do problemov ter jih lahko ustrezno popravimo.

56 47 Slika 19: Izpisi pri zagonu namestnika Aktiviranje delovanja namestnika Pri preizkušanju pravilnosti delovanja namestnika smo si pomagali s programom MIB Browser podjetja MG-Soft d.o.o. Ta program je ţe temeljito preizkušen, hkrati pa je zelo primeren za preizkušanje našega namestnika. V dialog programa MIB Browser najprej vnesemo naslov računalnika, kjer se nahaja naš namestnik (v našem primeru je to na lokalnem računalniku, zato naslov ), nato pa vnesemo še varnostne parametre, ki smo jih določili s profilom V1_Public, in vhodna vrata namestnika (glej definiranje profilov v podpoglavju 7.1.1). Vnos teh podatkov je prikazan na sliki 20.

57 48 Slika 20: Vnos podatkov namestnika v program MIB browser. Sledi pošiljanje zahteve na ciljni računalnik. V tem zgledu smo v obliki zahteve ţeleli dobiti podatek o imenu sistema, ki je shranjeno v spremenljivki sysname. V programu MIB Browser na to spremenljivko preprosto kliknemo z desno miškino tipko ter izberemo operacijo GET, kar je prikazano tudi na sliki 21.

58 49 Slika 21: Pošiljanje zahteve na naš namestnik s pomočjo programa MIB browser. Na sliki 22 so prikazani podatki o poslanem paketu in prejetem odgovoru. Vidimo lahko, da je bila poslana zahteva s protokolom SNMPv1 na naslov in vrata 6160, uporabljena operacija pa je bila GET, v seznamu VBL pa je bila zapisana zahteva sysname.0. V prejetem paketu pa lahko vidimo, da smo prejeli podatek, da je ime ciljne naprave APOLLO-OUT, v oglatih oklepajih pa je zapisana še njena šestnajstiška vrednost.

59 50 Slika 22: Podrobnosti zahteve in prejetega odgovora Preverjanje pravilnosti delovanja namestnika Pravilnost rezultatov, ki smo jih dobili z našim namestnikom, smo preverili tako, da smo v program MIB Browser vnesli podatke ciljne naprave in poslali paket neposredno na ciljno napravo, brez posredovanja našega namestnika. V našem zgledu smo za naslov ciljne naprave vnesli in varnostne parametre za verzijo SNMPv3. Vneseni podatki so prikazani na sliki 23. Vsi varnostni parametri niso vidni, saj tudi program MIB Browser, podobno kot naš namestnik in Konfigurator, uporablja profile. Slika 23: Vnos podatkov ciljnega računalnika v program MIB browser.