Dit artikel is gewijd aan de kenmerken van het monitoren van netwerkapparatuur met behulp van het SNMPv3-protocol. We zullen het hebben over SNMPv3, ik zal mijn ervaring delen met het maken van volwaardige sjablonen in Zabbix, en ik zal laten zien wat er kan worden bereikt bij het organiseren van gedistribueerde waarschuwingen in een groot netwerk. Het SNMP-protocol is het belangrijkste bij het monitoren van netwerkapparatuur, en Zabbix is geweldig voor het monitoren van een groot aantal objecten en het samenvatten van grote hoeveelheden binnenkomende statistieken.
Een paar woorden over SNMPv3
Laten we beginnen met het doel van het SNMPv3-protocol en de kenmerken van het gebruik ervan. De taken van SNMP zijn het monitoren van netwerkapparaten en het basisbeheer door er eenvoudige opdrachten naar te sturen (bijvoorbeeld netwerkinterfaces in- en uitschakelen of het apparaat opnieuw opstarten).
Het belangrijkste verschil tussen het SNMPv3-protocol en de vorige versies zijn de klassieke beveiligingsfuncties [1-3], namelijk:
- Authenticatie, die bepaalt dat het verzoek is ontvangen van een vertrouwde bron;
- encryptie (Encryptie), om openbaarmaking van verzonden gegevens te voorkomen wanneer deze door derden worden onderschept;
- integriteit, dat wil zeggen een garantie dat er tijdens de verzending niet met het pakket is geknoeid.
SNMPv3 impliceert het gebruik van een beveiligingsmodel waarin de authenticatiestrategie wordt ingesteld voor een bepaalde gebruiker en de groep waartoe hij behoort (in eerdere versies van SNMP werd het verzoek van de server naar het monitoringobject alleen vergeleken met ‘gemeenschap’, een tekst string met een “wachtwoord” verzonden in duidelijke tekst (platte tekst)).
SNMPv3 introduceert het concept van beveiligingsniveaus: acceptabele beveiligingsniveaus die de configuratie van apparatuur en het gedrag van de SNMP-agent van het monitoringobject bepalen. De combinatie van beveiligingsmodel en beveiligingsniveau bepaalt welk beveiligingsmechanisme wordt gebruikt bij het verwerken van een SNMP-pakket [4].
De tabel beschrijft combinaties van modellen en SNMPv3-beveiligingsniveaus (ik heb besloten de eerste drie kolommen te laten zoals in het origineel):
Dienovereenkomstig zullen we SNMPv3 gebruiken in de authenticatiemodus met behulp van codering.
SNMPv3 configureren
Voor het monitoren van netwerkapparatuur is dezelfde configuratie van het SNMPv3-protocol vereist op zowel de monitoringserver als het bewaakte object.
Laten we beginnen met het opzetten van een Cisco-netwerkapparaat, de minimaal vereiste configuratie is als volgt (voor configuratie gebruiken we de CLI, ik heb de namen en wachtwoorden vereenvoudigd om verwarring te voorkomen):
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 includedDe snmp-servergroep op de eerste regel – definieert de groep SNMPv3-gebruikers (snmpv3group), de leesmodus (read) en het toegangsrecht van de snmpv3group-groep om bepaalde takken van de MIB-boom van het monitoringobject te bekijken (snmpv3name en vervolgens in de configuratie specificeert tot welke takken van de MIB-boom de groep toegang heeft (snmpv3group zal toegang kunnen krijgen).
De snmp-servergebruiker op de tweede regel – definieert de gebruiker snmpv3user, zijn lidmaatschap van de snmpv3group-groep, evenals het gebruik van md5-authenticatie (wachtwoord voor md5 is md5v3v3v3) en des-codering (wachtwoord voor des is des56v3v3v3). Het is natuurlijk beter om aes te gebruiken in plaats van des; ik geef het hier alleen als voorbeeld. Wanneer u een gebruiker definieert, kunt u ook een toegangslijst (ACL) toevoegen die de IP-adressen regelt van monitoringservers die het recht hebben om dit apparaat te monitoren - dit is ook de beste praktijk, maar ik zal ons voorbeeld niet ingewikkelder maken.
De snmp-serverweergave op de derde regel definieert een codenaam die takken van de snmpv3name MIB-boom specificeert, zodat deze kunnen worden opgevraagd door de snmpv3group-gebruikersgroep. ISO biedt de snmpv3group-gebruikersgroep, in plaats van strikt één enkele vertakking te definiëren, toegang tot alle objecten in de MIB-boom van het monitoringobject.
Een soortgelijke opstelling voor Huawei-apparatuur (ook in de CLI) ziet er als volgt uit:
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
des56v3v3v3Na het instellen van netwerkapparaten moet u controleren of er toegang is vanaf de monitoringserver via het SNMPv3-protocol. Ik zal snmpwalk gebruiken:
snmpwalk -v 3 -u snmpv3user -l authPriv -A md5v3v3v3 -a md5 -x des -X des56v3v3v3 10.10.10.252
Een meer visueel hulpmiddel voor het opvragen van specifieke OID-objecten met behulp van MIB-bestanden is snmpget:
Laten we nu verder gaan met het instellen van een typisch data-element voor SNMPv3, binnen de Zabbix-sjabloon. Voor de eenvoud en MIB-onafhankelijkheid gebruik ik digitale OID's:
Ik gebruik aangepaste macro's in sleutelvelden omdat ze hetzelfde zullen zijn voor alle gegevenselementen in de sjabloon. U kunt ze instellen binnen een sjabloon als alle netwerkapparaten in uw netwerk dezelfde SNMPv3-parameters hebben, of binnen een netwerkknooppunt als de SNMPv3-parameters voor verschillende monitoringobjecten verschillend zijn:
Houd er rekening mee dat het monitoringsysteem alleen een gebruikersnaam en wachtwoorden heeft voor authenticatie en encryptie. De gebruikersgroep en het bereik van MIB-objecten waartoe toegang is toegestaan, worden gespecificeerd op het monitoringobject.
Laten we nu verder gaan met het invullen van de sjabloon.
Zabbix-enquêtesjabloon
Een eenvoudige regel bij het maken van enquêtesjablonen is om ze zo gedetailleerd mogelijk te maken:
Ik besteed veel aandacht aan inventarisatie om het werken met een groot netwerk makkelijker te maken. Hierover later meer, maar voor nu – triggers:
Voor een gemakkelijke visualisatie van triggers zijn systeemmacro's {HOST.CONN} in hun namen opgenomen, zodat niet alleen apparaatnamen, maar ook IP-adressen op het dashboard worden weergegeven in het waarschuwingsgedeelte, hoewel dit meer een kwestie van gemak dan van noodzaak is . Om te bepalen of een apparaat niet beschikbaar is, gebruik ik naast het gebruikelijke echoverzoek een controle op onbeschikbaarheid van de host met behulp van het SNMP-protocol, wanneer het object toegankelijk is via ICMP maar niet reageert op SNMP-verzoeken - deze situatie is bijvoorbeeld mogelijk , wanneer IP-adressen op verschillende apparaten worden gedupliceerd als gevolg van onjuist geconfigureerde firewalls of onjuiste SNMP-instellingen op monitoringobjecten. Als u de controle van de hostbeschikbaarheid alleen via ICMP gebruikt, zijn er tijdens het onderzoeken van incidenten op het netwerk mogelijk geen monitoringgegevens beschikbaar en moet de ontvangst ervan worden gecontroleerd.
Laten we verder gaan met het detecteren van netwerkinterfaces - voor netwerkapparatuur is dit de belangrijkste monitoringfunctie. Omdat er op een netwerkapparaat honderden interfaces kunnen zijn, is het noodzakelijk om de overbodige eruit te filteren om de visualisatie of de database niet onoverzichtelijk te maken.
Ik gebruik de standaard SNMP-detectiefunctie, met meer detecteerbare parameters, voor flexibeler filteren:
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]
Met deze ontdekking kunt u netwerkinterfaces filteren op type, aangepaste beschrijvingen en administratieve poortstatussen. Filters en reguliere expressies voor filteren zien er in mijn geval als volgt uit:
Indien gedetecteerd, worden de volgende interfaces uitgesloten:
- handmatig uitgeschakeld (adminstatus<>1), dankzij IFADMINSTATUS;
- zonder tekstbeschrijving, dankzij IFALIAS;
- met het symbool * in de tekstbeschrijving, dankzij IFALIAS;
- die service- of technisch zijn, dankzij IFDESCR (in mijn geval worden IFALIAS en IFDESCR in reguliere expressies gecontroleerd door één reguliere expressie-alias).
De sjabloon voor het verzamelen van gegevens met behulp van het SNMPv3-protocol is bijna gereed. We zullen niet dieper ingaan op de prototypes van data-elementen voor netwerkinterfaces; laten we verder gaan met de resultaten.
Resultaten van monitoring
Maak om te beginnen een inventaris van een klein netwerk:
Als u voor elke serie netwerkapparaten sjablonen voorbereidt, kunt u een eenvoudig te analyseren lay-out realiseren van samenvattende gegevens over de huidige software, serienummers en meldingen dat er een schoonmaker naar de server komt (vanwege de lage uptime). Een uittreksel van mijn sjabloonlijst vindt u hieronder:
En nu – het belangrijkste monitoringpaneel, met triggers verdeeld over ernstniveaus:
Dankzij een geïntegreerde aanpak van sjablonen voor elk apparaatmodel in het netwerk, is het mogelijk om ervoor te zorgen dat, binnen het raamwerk van één monitoringsysteem, een tool voor het voorspellen van fouten en ongevallen wordt georganiseerd (als de juiste sensoren en statistieken beschikbaar zijn). Zabbix is zeer geschikt voor het monitoren van netwerk-, server- en service-infrastructuren, en de taak van het onderhouden van netwerkapparatuur toont duidelijk de mogelijkheden ervan aan.
Lijst met gebruikte bronnen:1. Hucaby D. CCNP Routing and Switching SWITCH 300-115 officiële certificeringsgids. Cisco Press, 2014. blz. 325-329.
2. RFC3410.
3. RFC3415.
4. SNMP-configuratiehandleiding, Cisco IOS XE versie 3SE. Hoofdstuk: SNMP versie 3.
Bron: www.habr.com