🥇Võrgu seadmete jälgimine SNMPv3 abil Zabbixis

See artikkel käsitleb võrguvahendite jälgimise eripära SNMPv3 protokolli abil. Räägime SNMPv3-st, jagan oma kogemusi täiuslike mallide loomisel Zabbixis ning näitan, mida on võimalik saavutada laiaulatusliku häirete korraldamisel suures võrgus. SNMP protokoll on põhiline võrguvahendite jälgimise aluseks, samas kui Zabbix sobib suure hulga objektide jälgimiseks ja saadud mõõdikute mahukate kogumite kokkuvõtmiseks.

Mõned sõnad SNMPv3-st

Alustame SNMPv3 protokolli eesmärgist ja selle kasutamise eripärast. SNMP ülesanded on võrgu seadmete jälgimine ja elementaarne juhtimine, saates neile lihtsaid käske (näiteks võrgu liideste sisse ja välja lülitamine või seadme taaskäivitamine).

SNMPv3 peamine erinevus eelnevate versioonide suhtes on klassikalised turvafunktsioonid [1-3], nimelt:

autentimine (Authentication), mis määrab, et päring on saadud usaldusväärselt allikult;
šifreerimine (Encryption), et takistada edastatavate andmete avamist kolmandate isikute poolt;
puutumatuse (Integrity), st garantii, et pakett ei olnud edastamisel vale.

SNMPv3 eeldab turvamudeli kasutamist, kus autentimisstrateegia määratakse konkreetse kasutaja ja rühma jaoks, kuhu ta kuulub (SNMP eelmistel versioonidel võrreldi objekti jälgimise serverilt saadud päringus ainult 'community', mis on tekstistring 'parooliga', edastatav avatud kujul (plain text)).

SNMPv3 tutvustab turvataseme mõistet — lubatud turvatasemete komplekti, mis määrab seadme seadistamise ja SNMP-agensi käitumise jälgitava objekti puhul. Turvamudeli ja turvataseme kombinatsioon määratleb, millist turvamehhanismi kasutatakse SNMP paketi töötlemisel [4].

Tabelis on kirjeldatud SNMPv3 mudelite ja turvatasemete kombinatsioonid (esimesed kolm veergu otsustasin jätta originaali järgi):

Seega kasutame SNMPv3 autentimisrežiimis šifreerimisega.

SNMPv3 seadistamine

Võrguvahendite jälgimine eeldab SNMPv3 protokolli sama seadistuse rakendamist nii jälgimisse serveris kui ka jälgitavas objekti juures.

Alustame Cisco võrguseadmestiku seadistamisega, selle minimaalne vajalik konfiguratsioon on järgmine (konfigureerimise jaoks kasutame CLI-d, nimed ja paroolid olen ma lihtsustanud segaduse vältimiseks):

snmp-server group snmpv3group v3 priv read snmpv3name 
snmp-server user snmpv3user snmpv3group v3 auth md5 md5v3v3v3 priv des des56v3v3v3
snmp-server view snmpv3name iso included

Esimene rida snmp-server group määratleb SNMPv3 kasutajate grupi (snmpv3group), lugemisrežiimi (read) ja grupi snmpv3group õiguse vaadata teatud MIB-puu osi, millest snmpv3name hiljem konfiguratsioonis määrab, millistele MIB-puu osadele grupp snmpv3group juurdepääsu saab.

Teine rida snmp-server user määratleb kasutaja snmpv3user, tema kuuluvuse grupile snmpv3group, samuti md5 autentimise rakendamise (md5 parool on md5v3v3v3) ja des krüptimise (des parool on des56v3v3v3). Loomulikult on parem kasutada aes-i, siinkohal toon selle lihtsalt näiteks. Samuti on kasutaja määratlemisel võimalik lisada juurdepääsupoliitika (ACL), mis reguleerib, millised jälgimisserverite IP-aaddrid on õigustatud seda seadet jälgima — see on samuti parim praktika, kuid ma ei soovi meie näidet keerulisemaks muuta.

Kolmas rida snmp-server view määratleb koodinime, mis määrab MIB-puu osad snmpv3name, et neid saaks nõuda snmpv3group kasutajate rühm. ISO, mitte rangelt ühe teatud oksa määramine, võimaldab grupil snmpv3group saada juurdepääsu kõigile jälgimise objekti MIB-puu elementidele.

Sarnane seadistus Huawei seadme jaoks (ka CLI-s) näeb välja järgmine:

snmp-agent mib-view included snmpv3name iso
snmp-agent group v3 snmpv3group privacy read-view snmpv3name
snmp-agent usm-user v3 snmpv3user group snmpv3group
snmp-agent usm-user v3 snmpv3user authentication-mode md5 
            md5v3v3v3
snmp-agent usm-user v3 snmpv3user privacy-mode des56
            des56v3v3v3

Pärast võrguseadmete seadistamist on oluline kontrollida SNMPv3 protokolli kaudu juurdepääsu olemasolu jälgimisserverist, selleks kasutan snmpwalk'i:

snmpwalk -v 3 -u snmpv3user -l authPriv -A md5v3v3v3 -a md5 -x des -X des56v3v3v3 10.10.10.252

Visuaalselt selgem tööriist konkreetsete OID-objektide küsimiseks, kasutades MIB-failide – snmpget:

Nüüd liigume SNMPv3 tüüpilise andmeelemendi seadistamise juurde Zabbix'i mallis. Lihtsuse ja MIB-ist sõltumatuse huvides kasutan numbrilisi OID-sid:

Kasutame kohandatud makrode võtmeväljade jaoks, kuna need on kõigi andmeelementide jaoks mallis ühesugused. Neid saab määrata malli raames, kui kõigil teie võrgu seadmetel on SNMPv3 parameetrid ühesugused, või võrgu sõlme raames, kui erinevate jälgimisobjektide SNMPv3 parameetrid erinevad:

Pange tähele, et jälgimissüsteemil on ainult kasutajanimi ja autentimise ning krüpteerimise paroolid. Kasutajagrupp ja MIB-objektide vahemik, millele juurdepääs on lubatud, määratakse jälgimisobjektil.
Nüüd liigume malli täitmise juurde.

Zabbixi küsitluse mall

Lihtne reegel igasuguste küsitluse mallide loomisel – tehke need võimalikult detailsed:

Kannan suurt tähelepanu inventeerimisele, et suurt võrku oleks mugavam hallata. Sellest räägime natuke hiljem, aga praegu – märguanded:

Mugavuse huvides on märguannete nimedes sisse ehitatud süsteemsed makrod {HOST.CONN}, et juhtpaneelil alajaotuses häired kuvataks mitte ainult seadmete nimed, vaid ka IP-aadressid, kuigi see on rohkem mugavuse küsimus kui vajadus. Seadme kättesaamatuse määramiseks kasutan, peale tavalise echo-päringu, ka SNMP protokoli kaudu sõlme kättesaamatuse kontrolli, kui objekt on ICMP kaudu kättesaadav, kuid ei vasta SNMP-päringutele – selline olukord on võimalik näiteks IP-aadresside dubleerimise korral erinevatel seadmetel, vale seadistatud tulemüüride või vale SNMP seadistuse tõttu jälgimisobjektidel. Kui kasutada sõlmede kättesaadavuse kontrollimist ainult ICMP kaudu, võib võrgu sündmuste uurimise hetkel jälgimisandmeid mitte olla, seetõttu tuleb nende saabumist kontrollida.

Liigume võrgu liideste avastamise juurde – see on võrgu seadmete jaoks kõige olulisem jälgimisfunktsioon. Kuna võrgu seadmel võib olla sadu liideseid, on vajalik filtreerida need, mis pole vajalikud, et mitte koormata visualiseerimist ja mitte täita andmebaasi üle.

Kasutame SNMP jaoks standardset avastamisfunktsiooni, millel on palju avastatavaid parameetreid, et saavutada paindlikum filtreerimine:

discovery[{#IFDESCR},1.3.6.1.2.1.2.2.1.2,{#IFALIAS},1.3.6.1.2.1.31.1.1.1.18,{#IFADMINSTATUS},1.3.6.1.2.1.2.2.1.7]

Sellise tuvastamise korral on võimalik filtreerida võrgu liideseid nende tüüpide, kasutaja kirjelduste "description" ja portide halduslike seisundite järgi. Filtrid ja regulaaravaldised filtratsiooni jaoks näevad minu puhul välja järgmiselt:

Tuvastamise korral jäetakse välja järgmised liidesed:

manuaalselt välja lülitatud (adminstatus<>1), IFADMINSTATUS abil;
ilma tekstilise kirjelduseta, IFALIAS abil;
mille tekstilises kirjelduse on märk *, IFALIAS abil;
olemasolevad teenistus- või tehnilised, IFDESCR abil (minu puhul kontrollitakse regulaaravaldistes IFALIAS ja IFDESCR ühe regulaaravaldisena alias).

SNMPv3 protokolli andmete kogumise šabloon on peaaegu valmis. Ärgem peatugem andmestruktuuride prototüüpide detailidele, vaid liikuge tulemuste juurde.

Järeldused jälgimisest

Alustuseks – väikese võrgu inventuur:

Kui valmistada ette šabloonid iga võrgu seadme seeria jaoks, siis on võimalik saavutada analüüsimiseks mugav kokkuvõtete struktureerimine, sealhulgas praegune tarkvara, seerianumbrid ja teade serverisse saabuvad koristajatest (madala Uptime'i tõttu). Alljärgneb väljavõte minu šabloonide nimekirjast:

Ja nüüd – peamine jälgimislaud, kus on jagatud tasemete järgi tõrked:

Tänu komplekssele lähenemisele šabloonides igas seadme mudelis on võimalik saavutada, et ühe jälgimissüsteemi raames korraldatakse tööriistad rikete ja avariide prognoosimiseks (vastavate andurite ja mõõdikutega). Zabbix sobib hästi võrgu, serveri ja teenuse infrastruktuuride jälgimiseks, ning võrgu varustuse hooldamise ülesanne demonstreerib selgelt selle võimalusi.