TKK | Tietoverkkolaboratorio | Opetus

VER K ONHALLINTA                     Johdanto SNMP MIB Esimerkki Viitteet   SNMP SNMP-arkkitehtuuri SNMP:stä puhuttaessa tarkoitetaan usein koko Internet-verkonhallinnan viitekehystä (Internet-standard Management Framework), johon kuuluu varsinaisen SNMP-protokollan lisäksi mm. hallintatietojen ja niiden rakenteen määrittely (MIB ja SMI). Standardin[10] mukaan SNMP-hallintajärjestelmään kuuluu: useita verkon solmuja, joissa toimii SNMP-osapuoli (SNMP entity), joka on sovellus, jolla on pääsy hallintavälineistöön (management instrumentation). Näitä kutsutaan yleensä agenteiksi. ainakin yksi SNMP-osapuoli, jossa toimii hallintasovellus. Tätä kutsutaan yleensä hallinta-asemaksi (manager). hallintaprotokolla, jonka avulla siirretään hallintatietoa SNMP-osapuolten (esim. agenttien ja hallinta-asemien) välillä. Näiden ohessa luetellaan usein (esim. [9], [2]) myös varsinaiset verkonhallintatiedot, jotka on määritelty omissa standardeissaan (SMI RFC:ssä 1155, MIB-II RFC:ssä 1213 ). Hallintaosapuolet tarkkailevat ja kontrolloivat hallittavia osapuolia lähettämällä kyselyitä ja komentoja. Hallittavat osapuolet ovat verkon laitteita, joissa toimii SNMP-agentti. Ne voivat olla esim. reitittimiä, verkkotulostimia, työasemia - mitä tahansa ATM-kytkimestä Coca-Cola -automaattiin [9],[10]. SNMP:n toimintaperiaate SNMP on nimensä mukaisesti pyritty tekemään yksinkertaiseksi, jotta agentin ajaminen ei toisi liikaa vaatimuksia hallittaville laitteille. SNMP:n viestit voidaan periaattessa jakaa kolmeen ryhmään: Get-viestit: Hallinta-asema pyytää agentilta jonkun muuttujan arvoa (get-request), ja agentti lähettää vastauksen (get-response). Hallinta-asema voi kysyä tietokannan (MIBin) seuraavaa arvoa lähettämällä viestin get-next-request, johon agentti taas vastaa get-response -viestillä. Set: Hallinta-asema pyytää agenttia asettamaan jollekin tietokannan muuttujalle halutun arvon (set-request). Agentti vastaa tähän get-response -viestillä. Trap: Agentti tiedottaa hallinta-asemalle verkon tapahtumasta, esim. virhetilanteesta. Hallinta-aseman tehtäväksi jää päättää mahdollisista toimenpiteistä. SNMP toimii protokollapinossa UDP:n päällä. (Periaattessa muutkin protokollat käyvät, esimerkiksi SNMP IPX:n päällä on määritelty RFC 1298:ssa, mutta käytännössä UDP on yleisin vaihtoehto[11].) UDP on tunnetusti yhteydetön ja epäluotettava, ja tämä näkyy tietysti myös SNMP:ssä. Paketteja voi hukkua matkalla, jolloin SNMP:n pitää itse huolehtia uudelleenlähetyksestä. Agentin lähettämiin Trap-viesteihin ei kuitenkaan lähetetä kuittausta, joten tällainen viesti saattaa hävitä huomaamatta [2]. Tämän vuoksi on tapana käydä hallittavat kohteet läpi tietyin väliajoin poikkeavien tilanteiden varalta [5]. Tyypillisesti viestit kulkevat siis seuraavaan tapaan: Kuva 1.   Esimerkki hallinta-aseman ja agentin välisestä viestinnästä. (Piirsi Jan H.) Kysyttäviä tietoja voisivat olla esimerkiksi vastaanotettujen pakettien määrä ja eteenpän lähetettyjen pakettien määrä. Hallittavat muuttujat muodostavat tietokantoja, joita kutsutaan MIBeiksi (Management Information Base). Näiden tietokantojen rakenne on määritelty SMI-standardissa (Structure of Management Information, RFC 1155). Rakenteen määrittelyyn käytetään ISO:n standardoiman ASN.1-kielen mukautettua osajoukkoa [6]. MIBit ovat siis käytännössä muuttujien kokoelmia. SNMP-terminologiassa näitä muuttujia kutsutaan olioiksi, koska jokaisella hallittavalla agentilla on oma instanssi kustakin muuttujasta. Olio-ohjelmointimielessä voisi ehkä ajatella, että agentit olisivat olioita ja muuttujat eli SNMP-oliot niiden ominaisuuksia. SMI:n mukaan muuttujille (olioille) tulee olla määriteltynä nimi eli olion tunniste (Object Identifier) tiettyjä ominaisuuksia kuten tietotyyppi joukko operaatioita jotka voidaan kohdistaa k.o. olioon, esim. read, write Olion tunniste (Object Identifier) rakentuu hierarkisesti standardissa määritellyn nimeämispuun mukaan. Puun juuri on nimetön, ja sen alla on kolme somua: ISO(1), CCITT(0) (nykyinen ITU) ja nämä yhdessä(2). Solmut ja niiden lapset lapset on numeroitu, ja niihin voidaan viitata joko nimellä tai numerolla. Solmun ISO lapsista numero kolme on nimeltään org, ja sillä puolestaan on lapsi nimeltä dod, eli Yhdysvaltojen puolustusministeriö, jonka numero org:n alla on 6. Dod-solmulla on lapsi nimeltä internet(1), jonka puolustusministeriö on antanut IAB:lle ja jota hallinnoi käytännössä IANA. Internet-solmun alla on on mm. solmut mgmt(2) ja private(4) joiden alla on määritelty MIBejä. Esim. mib-2:n tunniste on iso.org.dod.internet.mgmt.mib-2 tai vaihtoehtoisesti 1.3.6.1.2.1 Kuva 2.   Osa SMI:n käyttämää nimeämispuuta. (Piirsi Jan H.) SNMP:n versiot Tähän mennessä käsitellyt asiat ovat pääperiaatteiltaan samoja kaikille SNMP:n versiolle, eli SNMPv1, 2, ja 3:lle. SNMPv1 määriteltiin RFC 1157:ssa (toukokuu 1990) ja se on vielä nykyäänkin (vuonna 2000) eniten käytetty versio [9]. SNMPv2 määriteltiin RFC:issä 1441-1450 ja 1452 (huhtikuussa 1993) . SNMPv2 sisältää mm. kaksi uutta viestiä: Inform, jolla kerrotaan toisille hallinta-asemille tapahtumista, sekä Get-bulk, jolla voi pyytää suurempia tietomääriä kerralla pitkän get-next -pyyntöputken sijasta. SNMPv2 ei ole täysin yhteensopiva SNMPv1:n kanssa, joskin yrityksiä niiden yhteiskäyttöön on tehty (esim. RFC 2089: V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent). Versiossa 2 yritettiin parantaa turvallisuutta (huonolla menestyksellä), muttei puututtu huonoon skaalautuvuuteen, joka on toinen SNMPv1:n suurimmista puutteista. Näin ollen SNMPv2 ei tarjoa kovinkaan paljon merkittävää parannusta SNMPv1:een. Käytännössä SNMPv2:sta pidetään epäonnistuneena, eikä sitä juuri käytetä[9]. IETF:llä on SNMPv3-työryhmä, joka on tähän mennessä tuottanut ainakin seitsemän RFC:tä jotka liittyvät SNMPv3:een (RFC:t 2570-2576). Niissä käsitellään mm. eri versioiden rinnakkaiseloa (RFC 2576) ja määritellään uusi turvamalli (RFC 2574). SNMPv3:a aletaan pikku hiljaa ottaa käyttöön [9]. SNMP:n turvallisuus Verkonhallinnassa on tietysti oleellista, ettei kuka tahansa pääse vaihtamaan hallintaan liittyvien muuttujien arvoja ja vaikkapa käskemään laitteita käynnistämään itsensä uudelleen. Näin ollen SNMP:ssä pitää varmistaa, että erityisesti Set-viestit tulevat oikealta hallinta-asemalta. SNMPv1:ssä käytetään salasanaa ja tarkistetaan lähettäjän IP-osoite[4]. Salasana kulkee kuitenkin selväkielisenä, ja lähettäjän IP-osoitteen väärentäminen ei ole erityisen vaikeaa. Siksi versio 1:n Set-viestit ovat harvoin käytössä, ja SNMPv1:tä käytetään enemmänkin verkon valvontaan kuin varsinaiseen hallintaan[9,2]. SNMPv2:ta suunnitellessa haluttiin parantaa turvallisuutta, ja siinä suunniteltiin käytettävän autentikointia ja salausta. Toteutuksesta tuli kuitenkin raskas ja huono, ja sen tilalle kehiteltiin erilaisia viritelmiä. Näin saatiin erilaisia SNMPv2:n toteutuksia, esim. SNMPv2*, SNMPv2c ja SNMPv2u [6,7]. SNMPv2u perustuu RFC:hen 1910 (helmikuulta 1996, melkein kolme vuotta SNMPv2:n määrittelyn jälkeen!), ja siinä toteutetaan vihdoin jollain tavalla autentikoinnin ja salauksen käyttö. SNMPv3:sen suunnittelussa on jälleen kiinnitetty huomiota turvallisuuteen, ja tällä kertaa toteutuksen pitäisi olla kohtuullisen toimiva. SNMPv3:n turvamalli on määritelty RFC:ssä 2574. Potentiaalisia turva-aukkoja löytyy tosin ainakin SNMPv3:n ja v1:n välisestä muunnoksesta. [8]       [Johdanto] [SNMP]  [MIB]  [Esimerkki]  [Viitteet]   Jarno Haikonen, Jan Hlinovsky & Antti Paju 28.11.2000