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]
|