VERKONVALVONTA LAHDEN AMMATTIKORKEAKOULU Tietotekniikan koulutusohjelma Tietoliikennetekniikka Opinnäytetyö Kevät 2006 Marko Mäkinen
Lahden ammattikorkeakoulu Tietotekniikan koulutusohjelma MÄKINEN, MARKO: Verkonvalvonta Tietoliikennetekniikan opinnäytetyö, 53 sivua Kevät 2006 TIIVISTELMÄ Työn tavoitteena on tutkia verkonvalvonnan järjestämistä yrityksen tarpeista lähtien. Verkonvalvonta on laaja kokonaisuus, ja siitä syystä se on jaettu ITU-T:n standardissa viiteen pienempään osa-alueeseen: vikojen-, käytön-, kokoonpanon-, suorituskyvyn- ja turvallisuuden hallintaan. Näiden osa-alueiden hallintaan ja valvontaan on kehitetty useita eri työkaluja. SNMP on TCP/IP-verkkojen verkonvalvonnassa yleisesti käytetty protokolla. Siitä on olemassa kolme eri versiota: SNMPv1, SNMPv2 ja SNMPv3, jotka ovat pääasiassa taaksepäin yhteensopivia. Protokolla mahdollistaa laitteiden etävalvonnan ja hallinnan Get- ja Set-operaatioilla, sekä laitteiden lähettämien Trapviestien avulla. SNMP-protokollaan sisältyvä MIB on hierarkinen hallintatietokanta, joka sisältää hallittavilla laitteilla olevien agenttien lähettämää informaatiota. MIB sisältää tuhansia eri objekteja, joista jokainen edustaa jotain laitteen hallinnoitua yksikköä. Objektin nimi koostuu luvuista, jotka periytyvät hierarkiassa korkeammalla tasolla olevista haarojen tunnisteista. Näiden tunnisteiden avulla verkonvalvontaohjelmat saavat tietoa laitteiden tilasta. RMON on SNMP-protokollaperheeseen kuuluva tiedonkeruu- ja analysointityökalu, joka kehitettiin poistamaan SNMP:n puutteita. Laitteissa olevan RMONagentin tehtävänä on seurata ja tallentaa verkossa tapahtuvan liikenteen tietoja. Ennaltamäärätyn tapahtuman havaittuaan se lähettää raportin hallinta-asemalle. Testattavana oli kaksi vapaan lähdekoodin ja yksi kaupallinen verkonvalvontaohjelma. Testauksessa huomattiin, että eri ohjelmien valvontaominaisuuksissa ja käytettävyydessä voi olla suuria eroja. HP Procurve Manager oli näistä kokonaisuudessaan laajin ja helppokäyttöisin, myös toistenkin sisältäessä hyviä ominaisuuksia. Nykyisin yritykset ja eri yhteisöt ovat riippuvaisia tietoverkoista, ja jo lyhyetkin käyttökatkokset saattavat aiheuttaa yritykselle suurta vahinkoa. Lisäksi lisääntyneet ulkopuoliset uhat asettavat omat vaatimuksensa toimivalle verkolle. Näistä syistä johtuen yritysten on tulevaisuudessa panostettava entistä enemmän toimivaan verkonvalvontaan. Avainsanat: verkonvalvonta, avoin lähdekoodi, SNMP, verkonhallintasovellukset
Lahti University of Applied Sciences Faculty of Technology MÄKINEN, MARKO: Network management Bachelor s Thesis in Telecommunications Technology, 53 pages ABSTRACT The aim of this thesis was to examine the organizing of the network management arising from the needs of the company. Network management is a wide area, and has therefore been divided into five smaller sectors according to the ITU-T standard. These sectors contain the management of the faults, the use, the configuration, the capacity and the safety. Several different tools have been developed to control and supervise these sectors. Three applications used to network management were tested, two of them were free source codes and one was a commercial network management application. In the testing it was noticed that there can be many differences in the management properties of the different programmes and in their usability. HP Procurve Manager was the widest and the easiest to operate. The other applications also contained good functions. Nowadays, companies and different communities are dependent on data networks and even a short interruption in use may cause great damage to the company. Furthermore, the increased external threats have set their own demands to the functional network. Due to these reasons, companies must invest to a good network control even more than before. Keywords: network monitoring, open source, network management applications
SISÄLLYS 1 JOHDANTO...1 2 VERKONVALVONTA...3 2.1 Yleistä...3 2.2 Verkonhallinnan osa-alueet...3 3 SNMP...6 3.1 SNMP:n kehitys...6 3.2 SNMP-operaatiot...7 3.2.1 Get-operaatio...8 3.2.2 Set-operaatio...10 3.2.3 Trap-operaatio...10 3.3 MIB...12 3.3.1 System ryhmä...14 3.3.2 Interface-ryhmä...15 3.3.3 IP ryhmä...16 3.3.4 TCP-ryhmä...17 3.3.5 UDP- ja EGP-ryhmät...18 3.3.6 SNMP-ryhmä...18 3.4 RMON...20 3.4.1 Yleistä...20 3.4.2 RMON MIB...20 3.4.3 RMON2...22 4 VERKONVALVONTAOHJELMAT...24 4.1 Nagios...24 4.1.1 Ominaisuuksia...25 4.1.2 Snmptrapd...27 4.1.3 Snmptthandler...27 4.1.4 Snmptt...28 4.1.5 Asetukset...29 4.1.6 Käyttö...31
4.2 HP Procurve Manager...34 4.3 Big Sister...41 4.4 Verkonvalvontaohjelmien vertailu...47 5 YHTEENVETO...50 LÄHTEET...52
LYHENNELUETTELO CMIP CMOT EGP FTP HEMS HTTP IAB ICMP IP ISO Common Management Information Protocol, OSI-protokolla verkonhallintaan CMIP over TCP/IP, ISO:n verkonhallintaprotokolla Exterior Gateway Protocol, Internetin reititysprotokolla File Transfer Protocol, TCP-protokollaa käyttävä tiedostonsiirtomenetelmä kahden tietokoneen välille High-level Entity-Management System, vanha verkonhallintaprotokollakokeilu Hypertext Transfer Protocol, protokolla, jota selaimet ja WWWpalvelimet käyttävät tiedonsiirtoon Internet Activities Board, järjestö, joka valvoo Internet-yhteisön yhteyskäytäntöjen kehitystä Internet-Control Message Protocol, yksinkertainen protokolla IPverkkojen saavutettavuuden raportointiin Internet Protocol, pakettien siirrosta vastaava protokolla International Organization for Standardization, kansainvälinen standardointiorganisaatio ITU-T International Telecommunication Union, televiestintäverkkoja ja - palveluja kansainvälisesti koordinoiva järjestö LAN MAC MIB Local Area Network, lähiverkko Media Access Control, laitteen yksilöllinen osoite Management Information Base, joukko olioita, joita voidaan käsitellä verkonhallintaprotokollan välityksellä
OSI PDU PING RMON SGMP SMI SMP SMTP SNMP TCP UDP VPN Open Systems Interconnection, ISO:n kehittämä avoin viitemalli tietokoneiden väliseen kommunikointiin Protocol Data Unit, yhteiskäytännön viesti, joka sisältää yhteyskäytännön kontrolli-informaation sekä käyttäjän informaatiota Packet Internet Groper, TCP/IP-protokollan työkalu, jolla testataan määrätyn laitteen saavutettavuutta Remote Monitoring, SNMP:n laajennus laitteiden etävalvontaan Simple Gateway Manangement Protocol, SNMP:n alkuperäinen nimi Structure and Idetification of Management Information, MIB:n olioiden määrittelyssä käytetyt säännöt Simple Management Protocol, ehdotus SNMP:n seuraajaksi Simple Mail Transfer Protocol, sähköpostin lähettämiseen ja vastaanottamiseen käytettävä protokolla Simple Network Management Protocol, TCP/IP-verkkojen hallinnassa käytettävä tietoliikenneprotokolla Transmission Control Protocol, tietoliikenneprotokolla Internettietokoneiden välisiin yhteyksiin User Datagram Protocol, TCP/IP-yhteyskäytäntö, jolla sovellus voi lähettää viestejä toiselle tietokoneelle Virtual Private Network, on tapa, jonka avulla voidaan muodostaa näennäisesti yksityinen verkko julkisen verkon yli
1 JOHDANTO Toimivan verkon ylläpidolta vaaditaan jatkuvasti enemmän panostusta. Verkkojen koon kasvaessa ja täten laitteiden ja käyttäjien lisääntyessä verkonvalvontaan on panostettava huomattavasti entistä enemmän. Jo lyhyetkin käyttökatkokset voivat aiheuttaa suurta vahinkoa yritykselle. Taloudellisten menetyksien lisäksi yrityksen maine kärsii, jos palvelut eivät ole saatavilla silloin, kun käyttäjä niitä tarvitsee. Tietoliikenneyhteyksien tärkeyden vuoksi jokaisella verkolla on ylläpitäjiä, joiden vastuulla on verkon asennus, ylläpito ja ongelmien ratkaiseminen. Heidän työtään helpottamaan on kehitetty lukuisia hallintatyökaluja, jotta verkon valvonta ja hallinta olisi nopeaa ja sujuvaa ja täten käyttökatkokset saadaan mahdollisimman lyhyiksi. Päijät-Hämeen koulutuskonsernilla on käytössä erittäin laaja verkko, joka kattaa kaikki eri toimipisteet. Laitteiden lisääntyessä ja verkon koon kasvaessa ja monimutkaistuessa vaaditaan entistä tehokkaampaa ja helpompaa valvontaa. Nyt käytössä on useita eri valvontaohjelmia ja tarkoitus on keskittää valvonta yhteen ohjelmaan, koska usean eri ohjelman käyttö rinnakkain ei ole tarkoituksenmukaista. Päijät-Hämeen koulutuskonsernin hallinnoima verkko muuttuu jatkuvasti, kun eri laitokset hankkivat uusia laitteita ja tarvitsevat uusia tietoliikenneyhteyksiä. Verkonhallinnan tehtävänä on toteuttaa nämä eri laitosten vaatimukset mahdollisuuksien mukaan ja turvata verkon sisäinen liikenne ja yhteydet ulkomaailmaan. Työn tavoitteena on tutkia eri verkonvalvontaohjelmistoja ja verrata niiden ominaisuuksia. Koska konsernilla on jo käytössä verkonvalvontaohjelmia, niin työssä perehdyttiin pääasiassa todennäköisesti käyttöön jäävään ohjelmaan ja siihen liittyviin ominaisuuksiin ja laajennuksiin. SNMP (Simple Network Management Protocol) on saavuttanut de factostandardin aseman verkonhallinnassa. Sen avulla voidaan etähallita verkossa olevia laitteita olematta fyysisesti laitteen luona. Tämän opinnäytetyön teoriaosuudessa tutustutaan verkonvalvontaan yleisellä tasolla sekä SNMP-protokollaan ja sen ominaisuuksiin.
2 Linux-ympäristö rajasi jo sinällään tutkittavia ohjelmia. Lisäksi ohjelmien vaatimat lisenssimaksut aiheuttivat osittain luonnollisen rajauksen. Vertailun vuoksi on mukaan otettu kuitenkin Windows-käyttöjärjestelmässä toimiva ohjelma.
3 2 VERKONVALVONTA 2.1 Yleistä Verkkojen koon kasvaessa ja verkkoliikenteen lisääntyessä verkonvalvonta on tullut entistä tärkeämpään rooliin. Jo lyhyet katkot tietoliikenneyhteyksissä voivat aiheuttaa suuria taloudellisia menetyksiä yrityksille. Lähes kaikki yritysten yhteydenpitoon liittyvät toimenpiteet, kuten tilaukset, sähköpostit ja viestintä toimivat verkon välityksellä. Verkonvalvonnan työkaluilla verkonvalvoja voi seurata verkon ja laitteiden tilaa reaaliaikaisesti ja täten lyhentää verkon vikojen korjaamiseen kulunutta aikaa. Eri ohjelmilla voidaan laitteiden ja verkon tilan seuraamisen lisäksi saada tietoa liikenteen määrästä ja laadusta. Lisäksi voidaan seurata eri palvelimilla olevien palvelujen saatavuutta. Näiden tietojen perusteella saadaan tietää verkon heikot kohdat ja voidaan varautua tuleviin muutoksiin. 2.2 Verkonhallinnan osa-alueet Verkonhallinta on laaja kokonaisuus ja se on ITU-T:n (International Telecommunication Union) verkonhallintastandardissa määritelty pienemmiksi osaalueiksi. Nämä alueet ovat: 1. vikojen hallinta (Fault management) 2. käytön hallinta (Accounting management) 3. kokoonpanon hallinta (Configuration management) 4. suorituskyvyn hallinta (Performance management) 5. turvallisuuden hallinta (Security management). (Puska 2000, 306.)
4 Vikojen hallinnassa pyritään havaitsemaan ja ilmoittamaan ylläpidolle verkon ongelmat. Kun vika on paikallistettu mahdollisimman tarkasti, eristetään muu verkko vian aiheuttamilta häiriöiltä. Laitteiden konfiguraatiota muutetaan tarvittaessa, tai verkon fyysistä rakennetta on muutettava, jotta vikaantumisen aiheuttamat häiriöt jäävät mahdollisen pieniksi. Lopuksi vikaantuneet laitteet korjataan tai vaihdetaan ja verkko pyritään palauttamaan alkuperäiseen tilaan. Nopeat toimenpiteet vähentävät käyttökatkoksia ja turvaavat eri palveluiden saatavuuden. Erilaisilla lokitiedoilla kerätään tietoa verkosta, ja ne auttavat verkon suunnittelussa ja ostopäätöksissä. Toimiva verkko on yritykselle ensiarvoisen tärkeä, joten vikojen hallintaa pidetään yhtenä tärkeimmistä osa-alueista. (Puska 2000, 306.) Käytön hallinnassa seurataan käytön tunnuslukuja niin, että eri käyttäjien tai käyttäjäryhmien verkon todellista käyttöä voidaan seurata. Saatua tietoa voidaan hyödyntää kapasiteettisuunnittelussa ja tarvittaessa voidaan tehdä toimenpiteitä käytön rajoittamiseksi. Käytön hallinnassa saatavia tunnuslukuja voidaan käyttää hyväksi myös mahdollisessa laskutuksessa. (Puska 2000, 307.) Kokoonpanon hallinta määrittelee nimensä mukaisesti eri verkkoelementtien määrittelytietoja. Verkonhallitsijan täytyy voida hallita laitteiden välisiä yhteyksiä ja tarvittaessa voida tehdä reititykseen muutoksia käyttäjien tarpeiden mukaisesti. Verkon laitteisiin on tallennettu niiden omat versio- ja konfiguraatiotiedot. Näiden tietojen ja lokitietojen avulla voidaan rajata vikatilanteita ja yhteensopivuusongelmia. Pahimmissa yhteensopivuusongelmissa laitteet voidaan palauttaa vanhempaan ja toimivampaan kokoonpanoon. (Puska 2000, 306.) Suorituskyvyn hallinnalla valvotaan verkon suorituskykyä ja pyritään pitämään se ennalta määrätyllä, hyväksytyllä tasolla. Viiveet, liikenteen määrä ja käyttöaste ovat hyviä mittareita tarkasteltaessa verkon suorituskykyä. Jos jokin tarkasteltava määre menee ennalta määrätyn alueen ulkopuolelle, järjestelmä aiheuttaa hälytyksen. Automatisoimalla laitteiden hälytykset helpotetaan tätä toimenpidettä. Tällöin verkon ylläpitäjän ei tarvitse jatkuvasti tarkastella laitteiden tilaa. (Puska 2000, 306.)
5 Turvallisuuden hallinnalla pyritään tarkastelemaan käytettyjä verkkoresursseja niin, että vain riittävän käyttöoikeuden omaavat saavat resurssit käyttöönsä. Yleiset Internet-sivut voivat olla kaikkien saatavilla, kun taas yrityksen henkilöstön käytössä olevat tietokoneet ja sisäiset Intranet-sivut voivat olla vain tiettyjen käyttäjien käytössä. Käyttöoikeuksissa määritellään kenellä ja mistä on oikeus päästä verkkoon, jotteivat ulkopuoliset pääsisi käsiksi heille kuulumattomiin laitteisiin ja palveluihin. (Puska 2000, 307.) Pienissä yrityksissä yleensä joku henkilö hoitaa koko verkonhallinnan oman työnsä ohessa. Yrityksen ja tietoverkon kasvaessa tarvitaan oma henkilöstö hoitamaan verkonvalvontaa. Valvontaa helpottamaan on kehitetty lukuisia eritasoisia valvontaohjelmia. Lähes poikkeuksetta kaikille hallittaville verkoille yhteistä on etävalvonta, joka on mahdollista nykyisten ohjelmien avulla. Parhaan ja soveliaimman valitseminen voi olla kompromissi, koska yrityksissä on otettava huomioon myös kustannustehokkuus.
6 3 SNMP 3.1 SNMP:n kehitys SNMP on TCP/IP:n (Transmission Control Protocol / Internet Protocol) päällä toimiva verkonhallintaprotokolla. Se kehitettiin alun perin TCP/IP-verkkojen keskitettyyn hallintaan. Nykyinen standardi määrittää kolmannen version SNMPv3. Erot eri versioiden välillä ovat pienet. Kaikissa versioissa käytetään samaa yleistä kehystä ja versiot ovat pääasiallisesti taaksepäin yhteensopivia. (Comer 2002, 556.) Koska TCP/IP:n kehityksessä ei kiinnitetty erityistä huomiota verkonhallintaan, niin 1970-luvun lopulla ei ollut käytössä varsinaisia verkonhallintaprotokollia. Käytössä ollut ICMP (Internet Control Message Protocol) tarjosi mekanismin viestien lähettämiseen reitittimistä ja tietokoneista muihin laitteisiin. ICMPviestejä käytettiin tavoitettavuuden ja viiveiden tarkkailuun. ICMP-viestejä välittävää PING-ohjelmaa (Packet Internet Groper) käytetään edelleen erittäin laajasti verkon ongelmien paikallistamiseen. 1980-luvun puolivälin jälkeen ruvettiin kiinnittämään huomiota tehokkaampaan verkonhallintaan. Useiden projektien joukosta nousi esiin kolme lupaavinta protokollaa HEMS (High-level Entity- Management System), SNMP ja CMOT (Common Management. Protocol over TCP/IP). Tuolloin elettiin aikaa, jolloin ajateltiin OSI-protokollien (Open System Interconnection) syrjäyttävän pian TCP/IP:n, joten vuoden 1988 alussa IAB (Internet Activities Board) valitsi CMOT:n pitemmän ajan ratkaisuksi TCP/IPverkkojen verkonhallinnassa. SNMP:n piti olla vain lyhyen tähtäimen ratkaisu, mutta OSI-yhteensopivuuden vaatimusten poistumisen myötä kehitys oli erittäin nopeaa. Huhtikuussa 1989 voidaan sanoa SNMP:n nousseen de facto-standardiksi TCP/IP-pohjaisten verkkojen hallinnassa. Toukokuussa 1990 itse verkonhallintaprotokolla SNMP, hallittavan tiedon rakenne ja identifionti SMI (Structure and Indetification of Management Information) sekä hallittavat tiedot MIB (Management Information Base) hyväksyttiin täysiksi Internet-standardeiksi. Maaliskuussa 1991 MIB korvattiin MIB-II:lla ja alkuperäistä alettiin kutsua nimellä MIB-I. (Hautaniemi 1994.)
7 SNMP:n yksinkertaisuudesta johtuen turvallisuus oli puutteellista. Pyyntöjä lähettäviä laitteita ei voida varmuudella todentaa puutteellisen autentikoinnin vuoksi. 1992 puolivälissä julkaistiin kaksi eri standardiehdotusta turvallisuusominaisuuksien parantamiseksi. Ensimmäisessä ehdotuksessa olisi vaadittu muutoksi protokollan viestien hallintaan viestien sisällön ja rakenteen pysyessä muuttumattomana. Toinen ja hyväksytty ehdotus oli SMP (Simple Management Protocol), joka sisälsi lisäksi parannuksia protokollan tehokkuuteen. Kaksi perustettua ryhmää, joista toinen keskittyi ainoastaan turvallisuuden kehittelyyn ja toinen kaikkeen muuhun paitsi turvallisuuteen, alkoivat kehittää uutta SNMP:tä SMP:n pohjalta. Uusi SNMPv2 standardiehdotus julkaistiin vuoden 1993 alussa ja saman vuoden syksyllä se hyväksyttiin standardiluonnokseksi. (Hautaniemi 1994.) SNMPv3 sisältää useita turvallisuuteen ja hallintaan liittyviä parannuksia. Suojaukseen liittyviä useita asetuksia voidaan muuttaa itsenäisesti. Suojauksista tärkeimpinä voidaan pitää 1. sanomien todennusta, jolla varmistetaan komentojen tuleminen valtuutetulta verkonhaltijalta. 2. yksityisyyttä, jolla varmistetaan etteivät ulkopuoliset pääse käsiksi viesteihin. 3. valtuuksien tarkistusta, jolla varmistetaan käyttäjän käyttöoikeudet. Asetusten muokkaus on mahdollista tehdä etämäärittelynä, joten itse laitteen luokse ei tarvitse mennä muuttaakseen asetuksia. (Comer 2002, 572.) 3.2 SNMP-operaatiot Verkonhallintaprotokollat määrittelevät verkonvalvojan käyttämän valvontaohjelman ja valvottavassa laitteessa sijaitsevan verkonhallintapalvelinohjelman välisen kommunikoinnin. Verkonhallintaprotokollat määrittävät sanomien rakenteen ja merkityksen, esitysmuodon sekä mahdollistavat käyttöoikeuksien määrittämisen. SNMP käyttää nouda-tallenna -menetelmää, jolla voidaan tietoa kuljettaa hallinta-asemalta agentille tai päinvastoin. Menetelmän suurimmat edut ovat vakaus, joustavuus ja yksinkertaisuus. Protokolla sisältää seuraavat operaatiot: GetReguest, jolla hallinta-asema pyytää muuttujaa agentilta
8 GetNextReguest, jolla hallinta-asema pyytää seuraavaa muuttujaa GetBulkReguest, jolla noudetaan useampi muuttujan arvo SetReguest, jolla talletetaan arvo määritettyyn muuttujaan GetResponce, jolla agentti vastaa hallinta-aseman lähettämiin set tai get pyyntöihin Inform reguest, jolla viitataan muissa laitteissa oleviin tietoihin Trap on tapahtuman käynnistämä ilmoitus, johon ei vastata. (Hautaniemi 1994.) Objektien arvot noudetaan ja tallennetaan GetReguest ja SetReguest toiminnoilla. ja vastaus annetaan responce toiminnolla. Koska SNMP-standardissa on määritelty, että jos SNMP-sanoma sisältää useisiin muuttujiin kohdistuvia toimintoja, niin palvelimen on suoritettava kaikki toiminnot tai ei yhtään toimintoa. Tästä johtuen jos yksikin arvo on virheellinen, niin mitään ei tehdä. Laitteistot voidaan määritellä lähettämään trap-viesti tietyn tapahtuman, esimerkiksi vikatilanteen yhteydessä. (Hautaniemi 1994.) 3.2.1 Get-operaatio Hallinta-asema ja agentti keskustelevat keskenään SNMP-viestien avulla. Viestit sisältävät tiedon käytettävästä protokollaversiosta, yhteisötunnuksen ja yhden edellä olevassa luvussa mainituista operaatioviesteistä. Hallinta-asema pyytää agentilta jonkin tietyn olion arvon getrequest operaatiolla, ja agentti vastaa Get- Responce-operaatiolla. (Hautaniemi 1994.) GetRequest-viesti sisältää viestityypin tunnuksen, viestitunnuksen sekä listan pyydettävistä olioiden ilmentymistä. Viestitunnusta käytetään hallinta-asemissa
9 yleensä lähetettyjen viestien identifioimiseen. Näin voidaan sovittaa yhteen lähetetyt pyynnöt ja vastaukset. Lisäksi sillä voidaan tunnistaa epäluotettavan siirtotien takia monistuneet viestit. (Hautaniemi 1994.) GetRequest pyynnön vastaanottava hallinta-agentti vastaa pyyntöön GetResponseviestillä ja sisällyttää siihen pyynnön sisältämän viestitunnuksen. Edellä mainittiin, että GetRequest-operaatio palauttaa joko kaikki pyydetyt ilmentymien arvot, tai yhtäkään arvoa ei palauteta. Tämän vuoksi ne palautetaan variable-bindingslistassa, mikäli kaikille pyydetyille olioille voidaan antaa arvo. Mikäli taas on yksikin olio, jolle ei voida antaa arvoa, ei millekään oliolle palauteta arvoa ja viestiin sisällytetään virhekoodi. Mahdollisia virheitä ovat seuraavat: Olion nimi ei vastaa mitään hallintatietokannassa olevaa olion tunnistetta tai pyydetty olio on johdettua tyyppiä eikä sillä voi olla mitään ilmentymän arvoa. Kummassakin tapauksessa agentti vastaa GetResponce viestillä, jossa error-status tyyppinä on nosuchname, ja error-index kenttään asetetaan ongelman aiheuttaneen olion järjestysluku. Kaikille pyydetyille olioille voidaan antaa arvo, mutta GetResponce viestin koko ylittää sallitun maksimipituuden. Tällöin virhetyyppinä on toobig ja error-index kentän arvo on nolla. Jos yhdelle tai useammalle oliolle ei voida antaa arvoa, palautettavan Get- Responce viestin virhetyyppinä on generr ja ongelmallisen olion järjestysluku laitetaan error-index kentän arvoksi. (Hautaniemi 1994.) GetResponce on identtinen GetRequest-viestin kanssa lukuun ottamatta PDUtyyppiä (Protocol Data Unit). Error-index, error-status ja variable-bindings-kentät saavat arvot tilanteen mukaan. (Hautaniemi, 1994.) GetNextRequest-viesti on muuten samanlainen GetRequest-viestin kanssa, mutta GetRequest-viestissä jokainen muuttuja variable-bindings-listassa viittaa olion ilmentymään, jonka arvo halutaan tietää, kun taas GetNextRequest-viestissä
10 muuttujalle palautetaan sen ilmentymän arvo, joka on muuttujaa seuraavana järjestyksessä. (Hautaniemi 1994.) 3.2.2 Set-operaatio SetRequest-viesti on lähes samanlainen GetRequest-viestin kanssa. Sen rakenne on muuten samanlainen, mutta variable-bindings-listassa on ne arvot, jotka olioiden ilmentymille halutaan antaa. SetReguest viestiin saatava GetResponse-viesti on samanlainen kuin GetRequest-viestiin saatava vastaus, eli se sisältää olioiden ilmentymien uudet arvot. (Hautaniemi 1994.) Viestin atomisuus on myös samanlainen GetRequest-viestin kanssa, eli mikäli yksikin olioista on virheellinen, yhdenkään ilmentymän arvoa ei muuteta, vaan palautetaan virhettä vastaava koodi nosuchname, toobig, tai generr. Lisäksi väärän tyyppisestä, väärän mittaisesta arvosta tai itse arvon suuruudesta on ilmoittava virhekoodi badvalue, jolla kerrotaan, että saatu asetettava arvo on virheellinen. (Hautaniemi 1994.) 3.2.3 Trap-operaatio Trap-viesti on hallinta-agentin oma-aloitteisesti hallinta-asemalle lähettämä viesti, jolla se ilmoittaa hallinta-asemalle hälytyksestä tai jostain muusta merkittävästä tapahtumasta. Tapahtumille määrätyt raja-arvot voivat olla nousevia, laskevia tai molempia. Näin agentti voidaan määritellä lähettämään ilmoitus tilanteen huonontuessa tai parantuessa. Yleensä agentti on määritelty lähettämään tapahtuman havaittuaan trap-viestit automaattisesti. Itse viesti eroaa rakenteeltaan huomattavasti muista viesteistä. (Ogletree 2001, 51.)
11 Trap-viestissä käytettävät kentät ovat PDU-type, joka osoittaa, että kyseessä on ilmoitusviesti. Enterprise ilmoittaa viestin generoineen järjestelmän, ja sen arvo saadaan system-ryhmän sysobejctid-oliosta. Agent-addr kertoo viestin lähettäneen laitteen IP-osoitteen. Generic-trap on yksi ennakkoon määritellyistä ilmoitusviestien tyypeistä. Specific-trap on koodi, joka voi osoittaa tarkemmin ilmoitusviestin syyn. Time-stamp ilmoittaa laitteen yhtäjaksoinen ylhäälläolemisajan viestin lähettämishetkellä. Variable-bindings sisältää lisää viestiin liittyvää informaatiota, jonka merkitys riippuu toteutuksesta. (Hautaniemi 1994.) Edellä mainittu Generic-trap-kenttä voi saada yhden seitsemästä arvosta, jossa ilmoitetaan tarkemmin viestin syy. coldstart(0): Lähettävä laite käynnistää itsensä uudelleen siten, että sen asetukset voivat muuttua. Yleensä tämä on odottamaton uudelleenkäynnistys, joka voi johtua esimerkiksi vakavasta viasta. warmstart(1): lähettävä laite käynnistää itsensä uudelleen ilman asetusten muutoksia. linkdown(2): Lähettävä laite ilmoittaa jonkin sen tietoliikenneyhteyden vikaantumisesta. Vikaantuneen linkin verkkoliitäntäolion nimi ja arvo ovat variable-bindings-listassa.
12 linkup(3) ilmoittaa, kun vikaantunut verkkoliitäntä on jälleen toiminnassa. autheticationfailure(4): laite on saanut SNMP-viestin, jonka autentikointi on epäonnistunut. egpneighborloss(5) ilmaisee, että laitteen EGP-protokollan (Exterior Gateway Protocol) mukaiseen naapuriin oleva yhteys on poikki. enterprisespecific(6) on varattu laite- ja ohjelmistovalmistajien omille ilmoitusviestityypeille. Viestin tarkempi tieto on Specific-trap-kentässä. (Hautaniemi 1994.) Näistä ehkä merkityksellisin on enterprisespecifig- tapahtuma. Enterprise tarkoittaa valmistajan tai käyttäjän itse määrittelemää tapahtumaa, kun taas muut on määritelty rfc-dokumentissa. Jokainen valmistaja voi itse määritellä tilanteet, milloin enterprisespecifig-tapahtuma syntyy. Näin on mahdollista saada Trapviestejä järjestelmälle ominaisista asioista. (Hunt 1998, 51.) 3.3 MIB MIB on hierarkinen tietokanta, johon agenttien keräämä informaatio sijoitetaan. MIB:n rakenne on tarkoin määritelty sisältäen tuhansia eri objekteja. Jokainen objekti edustaa jotain laitteen hallinnoitua yksikköä. Eri objektit on määritelty keräämään erilaisia tietoja laitteilta, kuten liikenteen määrää tai laitteen tilaa. (Comer 2002, 560.) Objektin nimi koostuu luvuista, jotka periytyvät hierarkiassa korkeammalla tasolla olevista haarojen tunnisteista, jotka erotetaan toisistaan pisteellä. 1.3.6.1.2.1.4 alkava mib on kaikkien IP-muutujanimiin liittyvä etuliite, joka voidaan kertoa myös tekstimuotona. Kuviosta 1 voidaan todeta, että IP-osoitteisiin liittyvät MIB:t alkavat tuolloin iso.org.dod.internet.mgmt.mib.ip. (Comer 2002, 561.)
13 KUVIO 1. Mib:n hierarkia (Tiirikainen 1998) Kun verkonvalvontaprotokollat käyttävät sanomissaan MIB-muuttujien nimiä, on kunkin nimen edessä oltava etuliite. Kun kyseessä on yksinkertainen etuliite esimerkiksi 0, niin se viittaa tuonnimisen muuttujan esiintymään. Tästä johtuen etuliitteen 0 esiintyessä reitittimelle lähetetyssä sanomassa ipinreceives muuttujan numeerinen nimi on 1.3.6.1.2.1.4.3.0, joka viittaa muuttujan esiintymään reitittimessä. Koska muuttujan etuliitteen sisältämiä lukuja on mahdoton arvata, niin ne on etsittävä standardeista. Kun käytettävissä ei ole mitään muuntoon käytettävää algoritmia, on ohjelmien, jotka muuttavat tekstimuotoisen viestin numeeriseen muotoon, käytettävä muunnostaulukoita. (Comer 2002, 561.)
14 3.3.1 System ryhmä Ryhmä sisältää järjestelmän tunnistavat objektit, kuten onko kyseessä laitteisto vai ohjelma. Ryhmä jakautuu seitsemään alaryhmään, jotka ovat: SysName ilmoittaa laitteen nimen. SysDescr, joka sisältää sanallisen kuvauksen järjestelmästä sisältäen yleensä laitteiston, käyttöjärjestelmän ja verkko-ohjelmiston nimen ja versionumeron. SysObjectID ilmoittaa valmistajan yksityisen MIB:n sijainnin. SysUpTime kertoo ajan, kuinka kauan järjestelmä on ollut yhtäjaksoisesti toiminnassa. SysContact sisältää laitteesta vastaavan henkilön yhteystiedot. SysLocation sisältää tiedot laitteen sijainnista. SysServices kertoo palveluiden määrän kokonaisuudelle. (Hautaniemi, 1994.) System-ryhmän tehtävänä on hallinnallisten tietojen ylläpito. Se pitää sisällään yleistä tietoa järjestelmästä ja sen kokoonpanosta.
15 3.3.2 Interface-ryhmä Interfaces- eli verkkoliityntäryhmä sisältää tiedot laitteen verkkoliitännöistä. kuten esimerkiksi niiden lukumäärästä, tyypistä, tilasta, sekä lähetetyistä ja vastaanotetuista paketeista. Ryhmä pitää sisällään muun muassa seuraavat alaryhmät: IfNumber, laitteessa olevien verkkoliitäntöjen lukumäärä IfDescr, sanallinen kuvaus verkkoliitännöistä IfType, verkkoliitännän tyyppi IfMtu, paketin suurin koko tavuina, jonka verkkoliityntä voi lähettää tai vastaanottaa IfSpeed, verkkoliitynnän kaistanleveys bitteinä sekunnissa IfAdminStatus ja if OperStatus, verkkoliitynnän toiminnallinen tila. (Hautaniemi 1994.) Edellä mainittujen lisäksi on olemassa muitakin interface-ryhmään kuuluvia olioita, joita voidaan käyttää verkonvalvonnassa. Esimerkiksi halutessa voidaan erillisen aliverkon laskutus hoitaa reitittimen runkoverkon liitynnän lähettämien ja vastaanottamien tavujen perusteella käyttäen olioita ifinoctets ja ifoutoctects. (Hautaniemi 1994.)
16 3.3.3 IP ryhmä IP-ryhmä on suurin ja monimutkaisin MIB-ryhmä. Se sisältää muun muassa IPprotokollaan liittyvää tietoa sekä reititystietoja. Ryhmässä on muun muassa seuraavat oliot: IpForwarding kertoo, toimiiko laite reitittimenä vai päätelaitteena. IpInReceives sisältää kaikkien vastaanotettujen IP-pakettien lukumäärän. Lukumäärä sisältää myös virheelliset paketit. IpInHdrErrors sisältää virheellisen otsikkokentän vuoksi hylättyjen IPpakettien lukumäärän. IpInAddrErrors sisältää virheellisen osoitekentän vuoksi hylättyjen pakettien lukumäärän. IpForwDatagrams kertoo edelleen lähetettyjen pakettien lukumäärän. IpInUnknownProtos sisältää ei-tuetun tai tuntemattoman protokollan vuoksi hylättyjen pakettien lukumäärän. IpAddrTable on paikalliset verkkoliitynnät sisältävä taulukko, jossa on tiedot muun muassa osoitteista. IpRouteTable on reititystaulu, jossa on laitteen omat reititystiedot. (Hautaniemi 1994.) Kokoonpanoa voidaan hallita muokkaamalla iproutetablen olioiden ilmentymiä, kuten lisäämällä reititystauluun rivejä tai muuttamalla joidenkin reititystietojen kustannuksia. Jos IP:tä tiedonsiirtoon käyttävät sovellukset toimivat hitaasti, voivat syynä olla laitteiston resurssien puute tai vialliset IP-otsikot. Yllämainituiden ja myös IP-ryhmään kuuluvien IpInDiscards, ipoutroutes, IpOutRequest ja
17 IpForwDatagrams määritteiden avulla voidaan laskea edellä mainittujen virheiden suhteellinen osuus erikseen lähetetyille ja vastaanotetuille paketeille. (Hautaniemi 1994.) 3.3.4 TCP-ryhmä Tcp-ryhmä sisältää yleistä tietoa laitteen TCP-konfiguraatiosta sekä taulukon, jossa on tiedot laitteen senhetkisistä TCP-yhteyksistä. Ryhmä sisältää muun muassa seuraavat oliot: TcpMaxConn ilmaisee yhtäaikaisten TCP-yhteyksien maksimilukumäärän. TcpCurrEstab kertoo TCP-yhteyksien lukumäärä kyselyhetkellä. TcpConnTable on taulukko, jossa on tiedot senhetkisistä TCP-yhteyksistä. TcpRetransSegs sisältää uudelleenlähetettyjen TCP-pakettien lukumäärän. Mikäli halutaan, että yhtäaikaisten TCP-yhteyksien maksimilukumäärä on dynaaminen, eli yhteyksiä voidaan luoda tarvittaessa, asetetaan tcpmaxconn arvoksi -1. TcpConnTable kertoo tietoa senhetkisistä TCP-yhteyksistä muun muassa vastapään IP-osoitteen, paikallisen ja vastapään TCP-porttien numerot sekä yhteyden tilan. Vaikka tcpretranssegs:n ilmaisema uudelleenlähetettyjen pakettien lukumäärä ei suoraan vaikuta tehokkuuden hallintaan, se voi antaa viitteitä siirtotien heikosta kunnosta. (Hautaniemi 1994.)
18 3.3.5 UDP- ja EGP-ryhmät UDP (User Datagram Protocol) on tiedonsiirron yhteyskäytäntö, joka tarjoaa yhteydettömän palvelun ylemmän tason Internet-protokollille. UDP-ryhmä sisältää tietoa UDP-protokollan mukaisista lähetetyistä ja vastaanotetuista paketeista. Ryhmään kuuluvassa UDPTable oliossa pidetään kirjaa niistä protokollan porteista ja osoitteista, joihin laite on määritelty hyväksymään yhteyksiä. Ryhmän laskurit pitävät kirjaa lisäksi muun muassa kaikista saapuneista UDP-paketeista sekä niistä, joiden sovellusta ei agentin järjestelmästä löydy. (Hautaniemi 1994.) EGP on syrjäytymässä oleva reitittimien käyttämä saavutettavuusyhteyskäytäntö. Tämä ryhmä pitää kirjaa EGP-protokollan mukaisista paketeista, sekä protokollan mukaisiin naapuruustietoihin perustuvista konfiguraatioista ja informaatiosta. (Hautaniemi 1994.) 3.3.6 SNMP-ryhmä SNMP-ryhmän olioihin kerätään tietoa erilaisista SNMP-protokollan mukaisista paketeista ja niihin liittyvistä virheistä. Ryhmässä on laskurit lähetetyille ja vastaanotetuille SNMP-protokollan eri viesteille. Koska SNMP-viestit sisältävät oman kentän virhetiedoille, niin näitä laskureita seuraamalla voidaan selvitellä mahdollisia SNMP-kyselyihin liittyviä ongelmia. Ryhmä sisältää seuraavat oliot: SnmpInPkts sisältää vastaantotettujen SNMP-pakettien lukumäärän. SnmpOutPkts sisältää lähetettyjen SNMP-pakettien lukumäärän. SnmpInBadVersions sisältää väärän SNMP-version vastaanotetut paketit. SnmpEnableAuthenTraps osoittaa lähettääkö laite Trap-viestin autentikointivirheen tapahduttua. (Hautaniemi 1994.)
19 Jos snmpenableauthentraps on määritelty niin, että se ei lähetä Trap-viestiä autentikointivirheen tapahduttua, voidaan tuntemattomalla nimellä varustettujen pakettien lukumäärä saada oliosta snmpinbadcommunitynames. Sitä ja snmpin- BadCommunityUses -oliota seuraamalla saadaan tietoa mahdollisten väärinkäytösyritysten varalta. (Hautaniemi 1994.)
20 3.4 RMON 3.4.1 Yleistä RMON (Remote Monitoring) on tiedonkeruu- ja analysointityökalu, joka kehitettiin poistamaan SNMP:n puutteita. Kuten SNMP:ssä, myös RMON:ssa on agentti ja hallinta-asema. RMON voidaan sijoittaa lähes mihin tahansa verkon laitteeseen. Agentin tehtävänä on kuunnella ja kerätä tietoa verkossa tapahtuvasta liikenteestä. Verkonvalvojan ennalta määrätyn tiedon havaittuaan se lähettää tiedon hallintaasemalle Trap- tai GetResponce viestinä. Eri laitevalmistajat voivat kytkeä RMON ominaisuuden omiin laitteisiinsa, mutta saatavilla on myös erillisiä verkkosegmenttiin liitettäviä laitteita. (Hautaniemi 1994.) RMON tarjoa kehittyneempiä tiedonkeruu- ja raportointimenetelmiä kuin SNMP. SNMP:ssä hallinta-aseman tehdessä jatkuvaa kyselyä verkon eri agenteilta RMON puolestaan kerää historiatiedon omaan tietokantaansa, ja tämä vähentää oleellisesti viestien määrää verkossa. Lisäksi RMON voi antaa verkkoliikenteen kannalta hyödyllistä tietoa istunnon kestäessä. Käyttäjien ja järjestelmien aiheuttamaa kuormaa voidaan tarkastella lyhyellä ja pitkällä tarkasteluajanjaksolla samalla kertaa. Esimerkiksi liikenteen kasvaessa ennalta määrättyä suuremmaksi RMON voi käynnistää hälytyksen. (Happonen 2005.) 3.4.2 RMON MIB RMON koostuu useasta standardoidusta hallintaryhmästä, jotka voivat sisältää alaryhmiä. Nämä RMON:in pääryhmät ovat Statistic, History, Alarms, Hosts, Hosts Top N, Matrix, Filters, Packet Capture, Events ja Token Ring. (Ogletree 2001, 50.) Statistic- eli tilastoryhmään kerätään tietoa verkkoliitännöistä. Ryhmä sisältää taulukon EtherStats Table, joka sisältää tämän ryhmän hallintaparametrien lisäksi tiedon jokaisesta verkkoliitännästä tiedon säilyttämistä varten. Näiden lisäksi
21 ryhmässä on omat laskurit muun muassa verkossa liikkuneille tavuille ja paketeille, havaituille pakettien virheille, törmäyksille sekä eripituisille paketeille. (Ogletree 2001, 50.) History-ryhmän tehtävänä on kerätä tapahtumahistoriaa ja tallentaa se myöhempää käyttöä varten. Oletusarvoisia näytteenottovälejä ja mittausaikaa voidaan muuttaa käyttäjän tarpeiden mukaisiksi ja samanaikaisesti voi olla käytössä useampia eri näytteenottotaajuuksia. (Ogletree 2001, 50.) Alarms- eli hälytysryhmän tehtävänä erilaisten laskurien seuraaminen. Kun agentti havaitsee ennaltämäärätyn rajan ylittyvän tai alittuvan, laukaisee se hälytyksen hallinta-asemalle. Hälytys lähetetään Trap-viestinä, joita agentti lähettää vain yhden virhettä kohdin. Seuraavan viestin agentti lähettää vasta kun objektin arvo on raja-arvon oikealla puolella. Hälytys vaatii toimiakseen Filters ja Events ryhmät, joiden avulla määritellään hälytysobjekti ja hälytyksen jatkokäsittely. (Jaakonhuhta & Lahtinen1997, 514.) Hosts-ryhmä kerää tietoa taulukkoon verkon isäntäkoneista MAC-osoitteen (Media Access Control) perusteella. Taulukkoon kerätään tietoa verkon eri laitteiden lähettämistä ja vastaanottamista tavuista ja paketeista sekä laitteiden lähettämistä virhepaketeista ja niin sanotuista broadcast- ja multicast-paketeista. Ryhmässä on myös toinen taulukko, johon kerätään vastaavat tiedot laitteiden havaitsemisjärjestyksen mukaisesti. (Ogletree2001, 50.) HostTopN-ryhmää käytetään selvittämään, mitkä laitteet kuormittavat verkkoa eniten tietyn kriteerin perusteella. Käytettävänä kriteerinä voi olla esimerkiksi lähetettyjen tai vastaanotettujen pakettien tai tavujen lukumäärä tiettynä ajanjaksona. Tämän ryhmä sisältää taulukot TopNControlTable ja HostTopNTable, joista ensin mainittu sisältää ryhmän hallintaparametrit ja jälkimmäinen tarkkailee dataa. (Ogletree 2001, 50.) Matrix-ryhmässä kerätään tietoa kahden eri laitteen välisestä verkkoliikenteestä, ja tietoa kerätään samalla tavoin kuin HostTopN-ryhmässä. (Ogletree 2001, 50.)
22 Filters-, Events- ja Capture-ryhmät kuuluvat oleellisesti yhteen ja sisältävät toistensa tarvitsemia määritteitä. Filters-ryhmän määrittelyjen mukaisesti Capture kaappaa paketteja. Suodattimeen voidaan määritellä kaapataanko ne paketit, jotka se päästää läpi vai ne, jotka se suodattaa pois. Suodatuksen ja kaappauksen jälkeen pakettia verrataan events-ryhmän määrityksiin. Jos tapahtuma täyttää ennaltamääritellyt ominaisuudet, tapahtuma voidaan suorittaa events-ryhmän sisältämien tietojen perusteella. Jokaiselle tapahtumalle voidaan määrittää oma toiminta, jolloin agentti voi lähettää esimerkiksi events-ryhmässä määritellyn hälytysviestin. (Hautaniemi 1994.) 3.4.3 RMON2 RMON MIB toi huomattavan laajennuksen SNMP-protokollaan. Se ei kuitenkaan mahdollistanut kuin OSI-mallin alempien kerrosten seuraamisen MAC-kerroksen yläpuolisten kerrosten jäädessä paitsioon. Lisäksi RMON kattaa ainoastaan yhden verkkosegmentin liikenteen, joten se ei vielä riitä tutkimaan suurten verkkojen toimintaa. Viereisen aliverkon liikenne näkyy paikalliselle aliverkolle ainoastaan kytkimen generoimana liikenteenä, eikä mahdollista ylikuormittajaa voi paikallistaa tarkasti. Näiden ongelmien poistamiseksi aloitettiin vuonna 1994 RMON2:n kehitystyö. RMON2 valmistui vuonna 1997. Se sisältää yhdeksän uutta tarkasteluryhmää, jotka ulottuvat verkko- ja sovelluskerrokselle asti. Uudet ryhmät ovat Protocol Directory Group, Protocol Distribution Group, Address Map Group, Network Layer Matrix Group, Network Layer Host Group, Application Layer Host Group, Application Layer Matrix Group, User History Collection Group ja Probe Configuration Group. (Stalling 1999, 227.) RMON ei määrittele erikseen protokollia mitä valvotaan, vaan päätös valvottavista protokollista on jätetty analysaattoreille ja valvontaohjelmien suunnittelijoille. Uusia tuettuja protokollia, joita voidaan seurata on muun muassa SMTP (Simple Mail Transfer Protocol), HTTP (Hypertext Transfer Protocol) ja FTP (File Transfer Protocol). Useimmat analysaattorit voivat muuttaa halutun liikenteen myös ihmisen luettavaan muotoon salattujen yhteyksien jäädessä edelleen salatuiksi. (Happonen 2005.)
23 Koska RMON 2 antaa mahdollisuuden seurata verkon liikennettä OSI-mallin tasolta 3 aina tasolle 7, niin liikennettä voidaan seurata verkko-osoitteiden tasolla Tämä mahdollistaa liikenteen seuraamisen LAN-segmenttiä (Local Area Network) suuremmasta näkökulmasta. LAN-segmentin sisäinen liikenne voidaan erotella ulkoapäin tulevasta liikenteestä. RMON2:n mahdollistaessa sovellustason protokollien tarkastelemisen ja purkamisen liikennettä voidaan valvoa myös laite ja sovelluskohtaisesti. RMON2 mahdollistaa myös protokollien erottelun, jolloin voidaan tarkastella näiden suhteellisia osuuksia verkkoliikenteestä. Kerätystä tiedosta voidaan kehittää verkonvalvojien käyttöön erilaisia graafisia näkymiä, joita voidaan käyttää hyväksi verkkoresurssien suunnittelussa. (Happonen 2005.)
24 4 VERKONVALVONTAOHJELMAT 4.1 Nagios Tässä opinnäytetyössä on testattu Nagioksen versiota 2.0, joka on kaikkien ladattavissa ohjelman kotisivuilta http://www.nagios.org/download/. Nagios on opensource eli avoimeen lähdekoodiin perustuva verkonvalvontaohjelma, joka on lisensoitu Free Software Foundationin GNU General Public License Version 2 lisenssillä. Lisenssi mahdollistaa käyttäjän kopioida, muokata ja levittää ohjelmaa lisenssissä mainittujen ehtojen mukaisesti. Avoimuus ja käyttäjien mahdollisuus muokata ohjelmaa tuo jatkuvasti uusia ominaisuuksia ja lisäosia ohjelmaan, joten päivityksiä kannattaakin käydä ajoittain tarkastamassa. Nagios on unix-pohjainen ohjelma, joka ei vielä perusasennuksen jälkeen sisällä mitään valvontaominaisuuksia, vaan kaikki toiminnot suoritetaan ohjelmaan liitettävillä plugineilla ja liitännäisillä. Pluginit ovat yleensä Perlillä kirjoitettuja pieniä ohjelmia, jotka suorittavat käyttäjän haluamia toimenpiteitä. Valmiita plugineita on ladattavissa osoitteesta http://nagiosplug.sourceforge.net/. Osa plugineista ja liitännäisistä vaatii toimiakseen lisäksi muita ohjelmia tai kirjastoja. Suosituksena http-palvelimeksi on Apache, ja osa cgi-skripteistä vaatii Thomas Boutellin gdkirjastosta vähintään version 1.6.3. Pienemmissä verkoissa laitteistoksi kelpaa vanhempikin Pentium II tasoinen laite, mutta suurempien verkkojen tarkastelussa prosessoritehoa tarvitaan enemmän tai valvottava alue voidaan luetettavuuden ja turvallisuuden vuoksi jakaa useamman koneen kesken. Tällöin toiminnot on jaettu useamman etäpalvelimen kesken ja niissä olevat agentit lähettävät tietoa nrpe-pluginia käyttäen itse järjestelmään. Koska siirrossa ei käytetä mitään suojausta, järjestelmä on tarkoitettu käytettäväksi suojatussa ympäristössä lähiverkon sisällä. Agentille pääsyä voidaan kuitenkin rajoittaa salasanojen ja sallittujen IP-osoitteiden listalla. Useamman verkon tai sellaisen verkon, jossa on useampia Nagios-palvelimia, palvelimet voivat kommunikoida keskenään passiivisesti nsca-pluginin avulla.
25 Etäpalvelimet suorittavat valvontakäskyn saatuaan oscp-komennon, joka lähettää keskuspalvelimelle valvontatuloksia send_nsca-ohjelmalla. Tiedot voivat olla salattuja usealla vaihtoehtoisella salausalgoritmilla. Etäpalvelimella suoritetaan vain valvontaan tarvittavat pluginit ja keskuspalvelin suorittaa kaiken muun toiminnan. 4.1.1 Ominaisuuksia Nagios-ohjelmalla voidaan seurata tehokkaasti verkon eri toimintoja ja tiloja. Kaikki liitetyt toiminnot on nähtävillä web käyttöliittymässä. Tärkeimpiä ominaisuuksia ovat: verkkopalveluiden monitorointi verkkolaitteiden monitorointi muun muassa prosessorikuorma, levytilan ja muistin käyttö, käytössä olevat prosessit ja lokitiedostot helppo pluginien teko, jolloin käyttäjä voi määritellä itselleen sopivat tarkistuskohteet hälytykset ylläpitäjille palvelun tai laitteen vikaantuessa sähköpostilla, tekstiviestillä tai jollain muulla käyttäjän määrittelemällä tavalla eri näkymät käyttöliittymässä eri käyttäjäryhmille ennalta määritellyt ohjelmat, jotka suoritetaan ongelmatilanteissa. Kaikki eri laitteiden tilat saadaan koottua yhteen selaimessa näkyvään käyttöliittymään. Käyttöliittymässä voidaan tarkastella laitteiden tilaa, verkon viiveitä, ilmoituksia, hälytyksiä, lokitietoja ja historiaa. Ennen kuin verkonvalvontaohjelma voi käsitellä laitteiden lähettämiä Trapviestejä, pitää olla jokin sovellus, millä ne vastaanotetaan ja käsitellään ohjelman
26 ymmärtämään muotoon. Sovelluksiksi valittiin Nagioksen dokumentaatiossa mainitut Snmptrapd ja Snmptt. Snmptrapd on ohjelma, mikä vastaanottaa ja tallentaa lokitiedostoihin SNMP-Trap viestejä ja informaatioviestejä TCP/IP:ssä. Snmptt:n mukana tullut Snmptthandler käsittelee viestit ja tallentaa ne spool-tiedostoon Snmptt:n saataville. Snmptt käsittelee viestit ja tekee määritellyt toimenpiteet. Kuviossa 2 on toimintakaavio edellä mainitusta. KUVIO 2. SNMP-Trap-viestien käsittelyn toimintakaavio (Sourceforce.net 2006)
27 4.1.2 Snmptrapd Snmptrapd vastaanottaa Trap-viestejä ja muokkaa ne käyttäjän haluamaan muotoon. Kuviosta 3 nähdään, että oletuksena viestit ovat osittain symbolisessa muodossa, jolloin ne eivät sellaisenaan sovellu käytettäviksi opinnäytetyössä käytettyjen ohjelmien kanssa. Ohjelmassa olevalla On määritteellä saapuneet viestit ovat numeerisessa muodossa, jolloin ne ovat suoraan käyttökelpoisia kyseisessä tapauksessa. Kaikki selkokielinen teksti on kuitenkin tarvittaessa luettavissa lokitiedostoista, jos kyseinen optio on otettu käyttöön. KUVIO 3. Normaali Trap-viesti 4.1.3 Snmptthandler Kaikki vastaanotetut Trap-viestit pitää käsitellä jollain ohjelmalla. Muutamien viestien käsittely on mahdollista Snmptt:n standalonemodessa. Se käy läpi kaikki vastaanotetut Trap-viestit ja tekee niiden mukaan määritellyt toimenpiteet ja siirtää ne spool-tiedostoon. Suuren verkon komponenttien lähettämä viestimäärä voi kasvaa todella suureksi, jolloin suositellaan käytettäväksi daemonmodea. Tällöin Trap-viestien käsittely suoritetaan Snmpthandlerilla, joka suorittaa Trap-viestien käsittelyn ja tekee määritellyt toimenpiteet ja siirtää ne spool-tiedostoon Snmptt:n saataville. Snmptthandlerin käyttö mahdollistaa huomattavasti suuremman viestimäärän käsittelyn ajanjaksoa kohti kuin pelkkä standalonemoden käyttö.
28 4.1.4 Snmptt Snmptt käsittelee spool tiedostoon saapuneet viestit ennaltamääritellysti. Snmptt voidaan määritellä käynnistämään eri ohjelmia, kun tietty viesti saapuu tai lähettämään tieto valvontaohjelmalle. Koko viestiä ei yleensä lähetetä valvontaohjelmalle, vaan ohjelmalla valitaan lähetettävät tiedot ja hälytyksen vakavuusaste. Kuviossa 4 on määritelty kyseiset toiminnot porttien toiminnoille. Jos portti on alhaalla, niin ohjelma lähettää Nagiokselle viestin, jossa kerrotaan portin tilan muuttuneen. Seuraava viesti lähetetään valvontaohjelmalle vasta, kun portti on jälleen käytössä, eli vaikka laite lähettää uuden viestin portin alhaalla olosta, niin sitä viestiä ei lähetetä. KUVIO 4. IF-MIB:n konfiguraatio Ohjelma tekee useita lokitietoja. Kaikki tiedot tallennetaan ohjelman omaan lokitiedostoon, josta ne ovat tarvittaessa saatavissa. Kuviossa 5 on hyväksytyn Trapviestin lokitiedosto. Tiedostossa on tapahtuman aikatiedot MIB-tunniste, tapahtuman vakavuusaste ja tyyppi sekä laitteen tiedot. Lisäksi tuntemattomille Trapviesteille, systeemille ja tapahtumille on omat lokitietonsa.
29 KUVIO 5. Tunnettujen SNMP-Trap viestien lokitiedosto 4.1.5 Asetukset Nagioksen perusasennuksen yhteydessä on mahdollista asentaa /etc/nagios tiedostoon esimerkki konfiguraatiotiedostot, jotka sellaisenaan eivät kelpaa käyttöön, vaan ne on muokattava käyttäjän haluamiksi. Tiedostoissa määritellään ohjelman asetukset ja pluginien toimintaan liittyvät asetukset. Lähes jokaiselle asetukselle löytyy lyhyt kommentti tiedostosta, mutta yksityiskohtaisempi kuvaus asetuksista löytyy Internetistä löytyvästä Nagios-dokumentista. Nagios.cfg on Nagioksen ensisijainen konfiguraatiotiedosto, jossa määritellään muiden konfiguraatiotiedostojen lisäksi muun muassa lokitiedostot, käyttäjät ja ryhmät sekä ulkoisten komentojen ja ohjelmien määritykset. Hosts.cfg, yksittäiset verkkolaitteet ja niiden ominaisuudet määritellään täällä. Tiedosto sisältää myös laitteiden osoite ja valvontaoptiot. Hostgroups.cfg sisältää tiedot määritellyistä laiteryhmistä. Yksittäinen laite voi kuulua yhteen tai useampaan ryhmään. Näin määriteltynä saadaan esimerkiksi kaikki samassa osoitteessa olevat laitteet samaan ryhmään. Services.cfg on eri palveluiden päätiedosto. Tiedostossa määritellään eri valvontaprosessit, eli mitkä toimenpiteet suoritetaan, kun määrätyt valvontarajat ylitetään. Tiedostossa on määritelty myös valvottavan laitteen valvonta-aika sekä kontaktiryhmät, joihin otetaan yhteyttä vikatilanteen ilmetessä.
30 Kuviossa 6 on määrittelyt esimerkkipalvelulle TRAP. Hostgroupin nimi on SWI- 03, jolloin se käsittää kaikki kytkimet, jotka on määritelty hostgroup.cfg:ssä kuulumaan kyseiseen ryhmään. Näin jokaista laitetta ei tarvitse ilmoittaa erikseen palvelua luotaessa. Kaikki muutkin palvelut tehdään saman periaatteen mukaan valiten itselle sopivat asetukset. KUVIO 6. Palveluiden esimerkkikonfiguraatio Checkcommands.cfg on services.cfg:n aputiedosto, jossa määritellään valvontatehtävät ja pluginien suorittamat komennot. Eri komennoilla on yksilöity nimi, jonka perusteella toiminnot suoritetaan. Contacts.cfg sisältää määritykset niille käyttäjille, joihin otetaan yhteyttä vikatilanteissa. Contactgroups.cfg:hen on määritelty eri ryhmiä contact.cfg:n käyttäjistä. Hälytykset lähetetään täällä olevien kontaktiryhmien perusteella. Eritasoiset hälytykset voidaan määrätä lähetettäväksi vain tietyille henkilöille, jolloin kukaan ylläpitäjä ei saa hänelle kuulumattomia hälytysviestejä. Timeperiod.cfg-tiedostossa määritellään erilaisia aikajaksoja, jolloin laitetta valvotaan. Valvonta-aikajaksoja käyttämällä saadaan turhat hälytykset pois laitteiden
31 käyttämättöminä aikoina. Tiedostossa on aikamääritykset myös eri käyttäjä- ja hälytysryhmille. 4.1.6 Käyttö Tietoturvan kannalta on tärkeää, että liikennettä rajoitetaan palomuurilla. Koska Trap-viestit ovat sisääntulevaa liikennettä, niin nekin on sallittava palomuurin määrityksissä. Palomuuriin tehtiin aukko kyseisille laitteille laittamalla niiden IPosoitteet ja käytettävä portti sallittujen listalle. Service.cfg:hen määriteltiin tarvittavat palvelut ja haluttujen hostien nimet. Snmptt.ini:iin määriteltiin haluttu MIB, host ja event, joilla määriteltiin haluttu toiminto kyseiselle MIB:lle. Snmptt:n ja Nagioksen uudelleenkäynnistyksen jälkeen kyseiset palvelut olivat käytössä. KUVIO 7. Nagioksen aloitussivu
32 Kuviossa 7 olevan aloitussivun vasemmassa reunassa on navigointipainikkeet, joista avautuvat kaikki valvontatoiminnot. Toiminnallisuuksia on paljon, ja niiden nimet ovat niin sanottuja itsensä selittäviä, joten käyttöliittymää on helppo käyttää pienen totuttelemisen jälkeen. General-osassa on Nagioksen dokumentaatio, jossa on ohjeet kaikille asetuksille ja linkki ohjelman kotisivuille, josta voi ladata lisää laajennusosia ohjelmaan. Monitoring-osassa on kaikki valvottavat laitteet nähtävissä joko yksittäin tai ryhmittäin lajiteltuna. Eri palvelut on myös ryhmitelty erikseen. Reporting-osasta löytyy historiatietoa hälytyksistä. Jokainen hälytys on nähtävissä erikseen, ja lisäksi hälytykset on nähtävissä erilaisina kaavioina. Kuviossa 8 on kaikki senhetkiset hälytykset. Ohjelma ilmoittaa eri väreillä hälytyksen vakavuusasteen. Hälytyksestä ilmenee kaikki tarvittava tieto, jolloin voidaan ryhtyä tarvittaviin toimenpiteisiin. Esimerkkikuvasta ilmenee vikaantuneen laitteen ja hälytyksen aiheuttaneen palvelun nimi, hälytyksen alkamisaika sekä lisätietoa hälytyksestä. Tässä tapauksessa lisätieto on määritelty snmptt:n konfiguraatiotiedostossa. KUVIO 8. Näkymä Nagioksen hälytyksistä
33 Hälytyksistä saadaan myös yksityiskohtaisempaa tietoa kuin edellä. Allaolevassa kuviossa 9 tarkastellaan yhtä hälytystä. Tarkistuksen tila on passive, joka tarkoittaa että tarkistusta ei suoriteta jatkuvasti, vaan agentti ilmoittaa tilan muutoksista. Osa palveluista voi olla aktiivisia kuten check_alive, jolloin ohjelma tekee hälytyksen, jos määrätyin välein ei saada yhteyttä laitteeseen. Näytöstä näkyy myös, milloin palvelun tila on viimeksi muuttunut sekä kuinka kauan tila on ollut kyseisenä. KUVIO 9. Varoituksen tiedot Monista konfiguraatiotiedostoista johtuen Nagioksen rakenne ja toimintaperiaate eivät ole yksinkertaisia, mutta juuri niiden ansiosta ohjelman valvontaominaisuudet ovat muokattavissa monipuolisesti. Helposti lisättävät laajennukset ja pluginit tekevät ohjelmasta monipuolisen verkonvalvontaohjelman. Muunneltavuuden ansiosta ohjelma soveltuu hyvin erilaisiin valvontaympäristöihin. Kuitenkin ennen kuin sitä voidaan konfiguroida ja käyttää tehokkaasti, on ymmärrettävä, miten se
34 toimii periaatteellisella tasolla. Kaikki konfiguraatiotiedostot on tekstipohjaisia, ja niiden muokkaaminen vie aikaa. Valmiit mallipohjat helpottavat tätä työtä, mutta edelleen kaikki asetukset on tehtävä käsin tiedostoja muokkaamalla. 4.2 HP Procurve Manager HP Procurve Manager on toiminnoiltaan erittäin laaja verkonvalvontaohjelmisto. Sen monipuoliset toiminnot mahdollistavat erilaisten verkkokokoonpanojen kattavan tarkastelun. Ohjelman kautta on mahdollista hallita kaikkien valmistajien SNMP-protokollaa tukevia laitteita. Ohjatut toiminnot neuvovat käyttäjää yksityiskohtaisesti eteenpäin, joten erilaisten toimintojen käyttäminen on yksinkertaista pienen opettelun jälkeen. Laitteiden lisääminen on mahdollista automaattisesti tai manuaalisesti. (Hewlett-Packard Development Company 2003.) Vähimmäisjärjestelmävaatimuksena on 2.0 GHz Intel Pentium III prosessori tai vastaava, 512 MB keskusmuistia ja vapaata levytilaa 5 GB. Käyttöjärjestelmänä pitää olla versiosta riippuen Windows XP Professional, Windows 2000 tai Windows Server 2003. Koska laitteistovaatimukset on asetettu niin korkealle, vanhemmat laitteet eivät tule kysymykseen. (Hewlett-Packard Development Company 2003.) Asennuksen jälkeen, ohjelmaa ensi kertaa käynnistettäessä, ohjelmaan pitää kirjautua pääkäyttäjän tiedoilla. Kirjautumisen jälkeen avautuu kuvion 10 mukainen pääsivu. Pääkäyttäjällä on kaikki oikeudet muokata ohjelman asetuksia ja vain pääkäyttäjillä on mahdollisuus lisätä uusia käyttäjiä. Käyttäjille voi antaa eritasoisia käyttöoikeuksia tarpeen mukaan. Valittavana on operator ja viewer tasoisten oikeuksien lisäksi no permission oikeudet, joka käsittää ainoastaan ohjelman tarkastelun.
35 KUVIO 10. HP Procurve Managerin pääsivu Pääsivulla on yleisnäkymä verkon ja sen laitteiden tilasta. Vasemmalla olevan hakemistopuun lisäksi ikkuna on jaettu kuuteen eri alueeseen, jotka ovat Network Status, Events, Device Configuration, Traffig Status, Discovery Status ja Inventory. Näistä jokaisella on oma nimenmukainen näkymänsä. Network Status-kentässä on nähtävillä verkon verkko- ja päätelaitteiden senhetkinen tila. Ohjelma ilmoittaa kolme eri vaihtoehtoa laitteiden tilalle. Good tarkoittaa, että laite toimii normaalisti ja on vastannut ohjelman kyselyyn, warning tarkoittaa, että laitteessa on jotain vikaa, mutta se on kuitenkin vastannut ohjelman kyselyyn. Jos laite ei vastaa ohjelman suorittamaan kyselyyn, niin tilaksi tulee unreachable. Events-osa ilmoittaa hälytysten ja tapahtumien määrän ja osaa klikkamalla avautuu informaatioruutu, jossa on tarkemmin kerrottu tapahtumista tai hälytyksistä. Siellä on lähteen ja aikatietojen lisäksi lyhyt kuvaus vian aiheuttajasta. Traffig Status-alueesta on luettavissa verkon suorituskyky huonoimman osan mukaan. Device Discovery-osa kertoo, mitkä skannauksen osat ovat käynnissä ja Inventory-osa kertoo laitteiden, verkkojen ja ryhmien yhteismäärän jaoteltuina ryhmittäin.
36 Laitteiden etsiminen verkosta ja niiden lisääminen automaattisesti tapahtuu valitsemalla Tools-valikosta Preferences. Avautuvasta ikkunasta valitaan Discovery ja Settings näkymässä valitaan IP-osoite, josta haku aloitetaan. Ohjelma etsii ikkunassa olevien hakuehtojen mukaisesti määrätyin väliajoin verkkoon kytkettyjä uusia laitteita. Jos jostain syystä ohjelma ei löydä haluttuja laitteita, on laitteita mahdollisuus etsiä myös manuaalisesti yksi kerrallaan. Tools-valikossa olevassa Manual Discovery Wizard-toiminnon avulla tämä käy helposti. IP-osoitteen ja SNMP:n yhteisönimien syöttämisen jälkeen ohjelma alkaa etsiä laitetta. Ohjelma antaa laitteen löydyttyään ilmoituksen, jolloin sen voi lisätä tarkkailulistalle. Jos ohjelma ei löydä laitetta kyseisellä IP-osoitteella tai SNMP:n yhteisönimi on väärä, ohjelma näyttää virheilmoituksen, jossa on mainittu virheen syy. Kyseisiin toimintoihin pitää olla tarpeeksi korkeat käyttöoikeudet. Laitteiden lisäämisen jälkeen ohjelma alkaa tarkkailla määriteltyjä laitteita. Näpäyttämällä jotain laitteen nimeä saadaan tarkempi kuvaus laitteesta. Kuviossa 11 on nähtävissä laitteen tiedot. Valitusta laitteesta näytetään nimi, IP- ja MACosoite, laitteen tila ja tilatiedot.. Lisäksi näytetään valmistajan tiedot ja mallinumerot sekä systeemitiedot. KUVIO 11. Laitteen tiedot (HP ProCurve Manager Help 2006)
37 Ohjelman tekemien erilaisten karttojen ja hakemistopuiden avulla voi tarkastella laitteiden sidoksia toisiinsa. Valvottavan verkon topologia on tarkasteltavissa esimerkiksi kuvion 12 graafisessa kartassa. Kartassa on laitteiden väliset yhteydet, jokaisen laitteen tila sekä laitteen IP-osoite tai nimi jos se on määritelty. Hiiren kursorin vieminen halutun laitteen päälle näyttää laitteen nimen ja kuvauksen laitteesta. Tuplaklikkaamalla laitetta saadaan esiin laitteen ominaisuudet ja konfiguraatiotiedot. Laitteen tila ja laitteiden väliset yhteydet on värikoodattu, joten vikaantunut laite tai yhteys on helposti paikallistettavissa. Lisäksi on valittavana puumaisia näkymiä, joko yhteyksien mukaan tai hierarkkisen rakenteen mukaan. Kartta sisältää myös Etsi-toiminnon, jolloin tietty laite voidaan etsiä nimen tai osoitteen perusteella. Tämä helpottaa laitteen paikallistamista etenkin suurissa verkoissa. KUVIO 12. Verkkokartta (HP ProCurve Manager Help 2006)
38 Suurten verkkojen lähettämien viestien ja monipuolisten valvontaominaisuuksien johdosta hälytyksiä ja valvontainformaatiota saattaa olla syytä rajoittaa. Ohjelmassa näytettäville tapahtumille on asetettavissa viisi erilaista suodatinta. Suodatus voi tapahtua itse tapahtuman, tapahtuman vakavuusasteen, päiväyksen, tapahtuman kuvauksen tai laitteen IP-osoitteen mukaan. Valinnan voi tehdä joko niin että valittu ominaisuus näytetään tai poistetaan, lisäksi voidaan suodattaa pois vähemmän- tai enemmänmerkitsevä tapahtuma. Esimerkiksi asettamalla tapahtuman vakavuusasteen mukainen ja älä näytä vähemmän kuin warning-tasoinen suodatus suodatetaan pois information- ja normal-tapahtumat ja näytetään vain warning- ja critical-vakavuusasteen tapahtumat. Ohjelmalla on useita tapoja käsitellä saapuneita hälytyksiä. Ensisijaisesti kaikkia hälytyksiä pääsee tarkastelemaan aloitussivun events-osan kautta. Joskus on tarpeen ilmoittaa hälytyksistä myös käyttäjille, jotka eivät ole paikalla. Tällöin ohjelma lähettää ilmoituksen tapahtumasta ennalta määriteltyihin sähköposteihin, ja lisäksi ohjelman voi asettaa suorittamaan haluttu komento hälytyksen tapahduttua. Aloitussivun Traffic Monitor välilehdeltä avautuvassa näkymässä on tietoa verkon reaaliaikaisesta tilasta. Kuviossa 13 näkyvät viisi eri mittaria näyttää omasta kategoriastaan huonoimman mittaustuloksen. Utilization näyttää prosentteina, kuinka paljon kyseinen segmentti käyttää kaistaa teoreettisesta kaistanleveydestä. Frames/sec näyttää verkon tai segmentin yli lähetettyjen kehysten lukumäärän sekunnissa. Jokainen protokolla on tarkasteltavissa erikseen. Broadcast/sec kertoo lähetettyjen broadcast viestien lukumäärän sekunnissa ja vastaavasti multicast/sec lähetettyjen multicast viestien lukumäärän. Error/sec näyttää havaittujen virheiden lukumäärän. Lukumäärä auttaa selvittämään verkon vikoja ja saamaan verkon toimimaan halutulla tavalla.
39 KUVIO 13 Liikenteen seuraamisen mittarit (HP ProCurve Manager Help 2006) Mittaustuloksia on havainnollistettu värikoodeilla, joista vihreä näyttää kaiken olevan kunnossa, keltainen varoittaa ja punainen osoittaa, että rajan ylitys on kriittinen. Mittaustuloksen ennalta määritellyn raja-arvon ylittäminen tai alittaminen aiheuttaa hälytyksen. Raja-arvot on määriteltävissä kuviossa 14 näkyvässä ikkunassa. Jokainen mittaus on varustettu oletusarvoilla, joita voidaan myös muuttaa vastaamaan omia tarpeita.
40 KUVIO 14. Hälytysten raja-arvot (HP ProCurve Manager Help 2006) Koska käytössä oli HP Procurve Managerin ilmainen kokeiluversio, niin kaikki ohjelmaan sisältyvät toiminnot eivät olleet käytettävissä. Lisäksi on olemassa kattavampi HP Procurve Manager Pro versio, joka sisältää vielä monipuolisemmat valvontamahdollisuudet. Ohjelmaa voidaan kuitenkin pitää hyvänä ja toiminnoiltaan kattavana verkonvalvontaohjelmana. Helppo asennus ja alkuasetusten automatisointi helpottaa käyttöönottoa. Käytettävyydeltään ohjelma on hyvä, ja kattava ohje helpottaa entisestään käytön opettelua.
41 4.3 Big Sister Big Sister on reaaliaikainen järjestelmä- ja verkonvalvontaohjelma. Ohjelmalla voidaan valvoa verkkoon liitettyjen laitteiden tilaa ja verkkoyhteyksiä. Ohjelma ilmoittaa, jos jokin verkon osan tiloista on muuttunut kriittiseksi. Lisäksi ohjelma kerää lokitietoihin dataa verkon tilasta ja näyttää käyttäjälle verkon tilassa tapahtuneet vaihtelut. Big Sister on avoimeen lähdekoodiin perustuva ohjelma, joka toimii yleisimmissä unix-tyyppisissä järjestelmissä. Ohjelma on lisensoitu Free Software Foundationin GNU General Public Licence version 2 lisenssillä, joka antaa käyttäjälle oikeuden kopioida, muokata ja levittää ohjelmaa lisenssissä mainittujen ehtojen perusteella. Big Sister-ohjelma koostuu kahdesta osasta, agentista ja tilankerääjästä. Agentti tarkkailee laitteen ja naapurilaitteiden verkon tilaa. Tietyin väliajoin agentti lähettää kerätyt tiedot tilankerääjälle. Tilankerääjä eli status collector tallentaa saamansa tiedot ja näyttää ne web-sivuilla. Tilankerääjä eli Big Sister palvelin pyörittää kolmea ohjelmaa, jotka ovat Big Sister Server (bbd), Big Sister Monitor (bsmon) ja Apache httpd. Ohjelman toimintaperiaate on kuvattu kuviossa 15.
42 KUVIO 15. Big Sisterin osat (Aeby, Bringer, Fritsch & Kerr 2006) Bbd on vastuussa kommunikoinnista agenttien kanssa Palvelin tarkastaa agenttien oikeudet tehdä aiottuja toimintoja. Bbd vastaanottaa tietoa niiltä laitteilta, joihin agentti on asennettu ja lähettää sen eteenpäin bsmon:lle. Bsmon käsittelee saamansa tiedot ja tekee tietojen perusteella tilasivut sekä suorittaa hälytykset. Kaikkia valvottavia laitteita tai palveluita valvotaan Big Sisterin uxmon-agentin avulla. Agentti asennetaan kaikkiin niihin laitteisiin, joita halutaan valvoa. Agentti kerää data laitteen tilasta ja lähettää sen palvelimelle jatkokäsittelyä varten. Kaikkiin laitteisiin ei voi asentaa uxmon-agenttia. Tällaisia laitteita on muun muassa useimmat kytkimet ja reitittimet. Näiden laitteiden tilaa voidaan tarkkailla ulkopuolisen agentin suorittamien SNMP- tai HTTP-pyyntöjen avulla.
43 Ennen Big Sister:n asentamista on tarvittaessa asennettava seuraavat lisäosat: Perl, Perl-modulit, RRDTool, Apache ja SpeedyCGI. Perl-moduleista pitää asentaa GD-kirjastossa olevat Lipbng, Libgd jazlib, Simon Leinen s SNMP, LWP User Agent:n sisältämät URI, MIME Base64, HTML Parser ja Digest MD5 sekä Netlib. Dokumentissa suositellaan lisäosien asentamista kyseisessä järjestyksessä, koska lisäosat ovat riippuvaisia toisista lisäosista. Ohjelma voidaan asentaa palvelimen ja agentin yhdistelmänä tai asentamalla vain palvelin tai agentti. Halutun asennusvaihtoehdon tapahduttua Big Sister on asennettu oletuksena tiedostoon /usr/local/lib/bs/. Ohjelma on luonut useita alitiedostoja. jotka sisältävät ohjelman asennetut osat ja konfiguraatiotiedot. Seuraavaksi lyhyt kuvaus tärkeimmistä konfiguraatiotiedostoista. Bb-display.cfg sisältää tilankerääjän tarvitsemat konfiguraatiotiedot, kuten Websivun näyttämiseen tarvittavat tiedot. Lisäksi bb-display.cfg-tiedostossa voidaan määritellä erilaisia ryhmiä, joiden luonnilla helpotetaan valvottavien laitteiden hallinnointia. Eri ryhmiä voidaan luoda esimerkiksi osoitteen, hallittavan laitteen tyypin tai käyttöjärjestelmän mukaan. Permission tiedosto sisältää tiedot niistä clienteista, jotka ovat sallittu ottamaan yhteyden bbd:hen ja mitä toimintoja ne saavat suorittaa. Tiedosto luetaan riveittäin, ja jokainen rivi sisältää listan hyväksytyistä tai kielletyistä operaatioista, joita client voi suorittaa. Jos client sisältyy useampaan käyttäjäriviin, niin käyttöoikeudet annetaan kumulatiivisesti järjestyksen mukaan. Jossain tapauksissa voi olla tarpeen antaa agentille normaalia korkeammat käyttöoikeudet. Luomalla uxmon-asroot tiedoston /adm-hakemistoon uxmon:in voi käynnistää root-käyttäjän oikeuksilla. Tiedoston luomisen jälkeen uxmon saa pääkäyttäjän oikeudet komennolla bb_start. Tätä tiedostoa ei tietoturvan kannalta kannata luoda, jos ei ole tarpeellista antaa agentille lisäoikeuksia.
44 Uxmon-net kertoo uxmon:lle mitä kaikkia tarkistuksia sen pitää käynnistää eri laitteille. Lisäksi tiedostossa on uxmon:lle tiedot siitä, minne hostien tilatiedot lähetetään. Etc-hakemisto sisältää muun muassa konfiguraatiotiedostot eri lokitiedostojen tarkkailuun. Erinimisillä lokitiedostoilla on oltava oma konfiguraatiotiedostonsa, jotta monitorit näyttävät oikean mittaustuloksen. Omat tiedostonsa voi olla esimerkiksi syslog:lle ja eventlog:lle. Hakemistossa on lisäksi eri palvelinmoduulien konfiguraatiotiedot ja käytettävät MIB:t. Eri tapahtumille voidaan määritellä erilaisia hälytyksiä. Hälytysten asetukset on talletettu bb_event_generator.cfg tiedostoon. Tiedostossa on tiedot eri tapahtumille ja niiden vaatimille toimenpiteille, tiedot hälytysten vastaanottajista sekä tapahtuman aiheuttaneen hälytyksen vakavuusaste. Jotta valvontatuloksia voidaan tarkastella web-selaimella, täytyy Apachen omaan httpd.conf tiedoston loppuun lisätä viittaus Big Sisterin omaan httpd.conftiedostoon. Ilman autentikointia web-käyttöliittymä on kaikkien IP-osoitteen tietävien saatavilla. Ulkopuolisten pääsyn rajoittamiseksi Apachen palvelimelle voidaan ottaa käyttöön käyttäjän tunnistus htaccesin avulla. Edellä mainittuun httpd.cfg tiedostoon pitää lisätä viittaukset tiedostoon, jossa käyttäjätiedot sijaitsevat.
45 Ohjelman pääsivulla, joka on näkyvissä kuviossa 16, on yleisnäkymä laitteiden tilasta. Käyttöliittymässä näkyvät valvontakohteet on määritelty bb-display.cfg tiedostossa. Samassa tiedostossa on määritelty myös Contents-ryhmässä näkyvät linkit, joita klikkaamalla saadaan näkyviin kyseisen ryhmän laitteiden tilatiedot. Hallintamahdollisuudet ovat rajalliset ja suoritettavat toiminnot keskittyvät pääasiassa laitteiden tilojen tarkkailuun, hälytysten kuittaamiseen ja erilaisten ryhmien hallinnoimiseen. Hälytykset näytetään eri väreillä hälytyksen kriittisyydestä riippuen. Vihreä tarkoittaa normaalitilaa, keltainen varoitusta ja punainen kriittistä tilaa. Lisäksi on sininen väri offline-tilalle, harmaa, jos laitetta ei tavoiteta ja violetti jos agenttia ei tavoiteta. KUVIO 16. Big Sisterin aloitussivu (Projects - Big Sister System and Network Monitor 2006)