© photocase.com

In bester Bademeister-Tradition brauchen Admins einen guten Überblick über ihr Netzwerk, um eventuelle Fehlerquellen frühzeitig zu entschärfen. Dank SNMP kein Problem: Das Protokoll liefert gezielte Einblicke in jede SNMP-fähige Komponente und gibt ihr bei Bedarf auch Anweisungen.

Wer viele Rechner aus der Ferne administrieren will, setzt klassischerweise auf das Simple Network Management Protocol (SNMP, [1] bis [5]). Neben Computern verstehen auch Netzwerkgeräte wie Router und Switches dieses Protokoll, viele Drucker sind SNMP-fähig und etliche Applikation bringen SNMP-Agenten mit. Eine Managementkonsole genügt, um den Gerätezoo der meisten Firmen im Blick zu behalten, Ausfälle rasch zu bemerken oder sogar die komplette Administration zu erledigen.

Es scheint aber, dass mehr als 15 Jahre nach der Standardisierung von Version 1 [1] das vermeintlich uralte Protokoll in Vergessenheit gerät. Viele Entwickler erfinden lieber eigene Management-Protokolle und -Verfahren statt auf das bewährte SNMP zu setzen. Sie verzichten damit auf den großen Vorteil des Standards: seine enorme Verbreitung und Flexibilität. Veraltet ist SNMP noch lange nicht, die RFCs für Version 3 sind gerade drei Jahre jung [3].

Die Nagios-Community ([7], [8]), bekannt auch für ihren erfinderischen Übereifer, hat mit Nagios eines der beliebtesten und besten Überwachungs- und Management-Werkzeuge unter Linux entwickelt. Die Web-basierte Applikation verwendet ein eigenes Client-Server-Protokoll und bringt Agenten und Plugins [9] mit. Genau betrachtet sind viele dieser Plugins unnötig, da Nagios auch SNMP beherrscht.

SNMP statt Plugin

Auf der Nagios-Mailingliste tauchen immer wieder Fragen nach Plugins auf, deren Aufgaben viel einfacher mit SNMP zu erledigen wären. Der Trend setzt sich bei kommerziellen Anbietern fort. Beispielsweise haben HP und IBM so genannte Konnektoren ab 500 Euro im Angebot, die eine bessere Überwachung durch Openview oder Tivoli gewährleisten sollen. Findige Admins verzichten dankend, weil auch jeder SNMP-Agent die benötigten Informationen bereitstellt. Der ist in fast jedem System enthalten, ohne Mehrkosten, und lässt sich meist vielseitig erweitern und anpassen.

Das Management per SNMP [6] funktioniert nach dem Client-Server-Prinzip (Abbildung 1). Im Netz betreibt der Admin eine oder mehrere Network Management Stations (NMS), die ihre zugeordneten Network Management Elements (NME) überwachen. Auf einer NMS sammelt die Manager-Software Daten über den Zustand der NME. Die NMS kontaktiert dazu Agenten, die auf den NMEs laufen und auf UDP-Port 161 reagieren. SNMP dient als Kommunikationsprotokoll zwischen Manager und Agent. Die Daten sind in einem MIB-Baum strukturiert (Management Information Base, siehe auch Tabelle 1 mit einer Akronymliste). Die Structure of Management Information (SMI) gibt vor, wie MIBs aufgebaut sind.

Abbildung 1: Auf jedem per SNMP verwalteten Gerät (Managed Object, rechts) läuft ein SNMP-Agent (Server-Rolle). Er reagiert auf Fragen des Managers (Client-Rolle: »GetRequest«, »GetNextRequest«) und Änderungswünsche (»SetRequest«) oder sendet von sich aus Hinweise (»Trap«).

Falls der Agent meldet, dass alles in Ordnung ist, zeigt beispielsweise das GUI des Administrators ein grünes Lämpchen, bei Problemen ein rotes. Um den Zustand abzufragen, sendet der Manager zunächst ein »GetRequest«-Paket (PDU, Protocol Data Unit), das der Agent mit einer »GetResponse« beantwortet. Den in der MIB an nächster Stelle liegenden Wert erfragt der Manager bequem per »GetNextRequest«. Auch darauf reagiert der Agent mit »GetResponse«.

Um das Verhalten eines NME zu steuern, sendet der Manager Befehle an einen Agenten, der daraufhin die Konfiguration der NME anpasst. Ein Befehl könnte etwa das Routing ändern. Dazu schickt der Manager dem Agenten einen SNMP-»SetRequest«, den der Agent – etwas unerwartet – mit einer »GetResponse« beantwortet. Die Antwort enthält die neuen Werte nach der Änderung.

Völlig aus der gewohnten Client-Server-Rollenverteilung fällt das »Trap«-Paket. Wenn ein Agent selbst ein Problem bemerkt und den Manager darüber informieren will, schickt er unaufgefordert ein »Trap« an den Manager (UDP-Port 162). Das ist per Default bei Authentifizierungsproblemen der Fall oder wenn ein Link (zum Beispiel ein Port am Switch) seinen Status ändert. Das Prinzip der SNMP-Nachrichten ist in Abbildung 1 zusammengefasst.

Alles in MIBs

SNMP-Agenten laufen auf sehr unterschiedlichen Geräten und die Manager-Applikationen gibt es auch von vielen Herstellern – genau hierin liegt der Vorteil der Standardisierung. Ein Kommunikationsprotokoll allein genügt aber nicht, um für globale Verständigung zu sorgen. Folgerichtig legt SNMP auch eine Struktur und eine Darstellungsform für die Management-Information fest. Welche Informationen es konkret gibt und wie Manager und Agent diese Daten adressieren, legt die Management Information Base fest.

Für die eindeutige Adressierung der einzelnen Infos innerhalb einer MIB sind OIDs zuständig (Object Identifier). Informationen über Objekte des Internets befinden sich im hierarchischen Baum unter »iso(1) org(3) dod(6) internet(1)« (Listing 1a). Zur Adressierung genügt auch die Folge der eingeklammerten Zahlen: ».1.3.6.1«.

01 internet     OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
02 mgmt         OBJECT IDENTIFIER ::= { internet 2 }
03 experimental OBJECT IDENTIFIER ::= { internet 3 }
04 private      OBJECT IDENTIFIER ::= { internet 4 }
05 enterprises  OBJECT IDENTIFIER ::= { private  1 }

MIBs beschreiben einen Satz von Objekten inklusive OID, Name, Syntax, Definition, Zugriffsrechten, Status und einer kurzen Erklärung. Die RFCs definieren die MIB-II [4] als Standard. Jeder Agent bietet eine MIB-II mit Daten über den TCP/IP-Stack. Um etwa anzufragen, wie lange ein System schon läuft, fragt der Manager nach der »SysUpTime« (Listing 1b). Deren OID lautet ».1.3.6.1.2.1.1.3.0«, ausgeschrieben: »iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) system(1) sysUpTime(3) sysUpTimeInstance(0)«. Die Beschreibung der OID (Zeile 8) verrät, dass dieses Objekt nicht die Uptime des Rechners wiedergibt, sondern die Zeitspanne seit dem letzten Start des SNMP-Agenten.

01 mib-2  OBJECT IDENTIFIER ::= { mgmt  1 }
02 system OBJECT IDENTIFIER ::= { mib-2 1 }
03 
04 sysUpTime OBJECT-TYPE
05   SYNTAX      TimeTicks
06   MAX-ACCESS  read-only
07   STATUS      current
08   DESCRIPTION
09     "The time (in hundredths of a second) since the
10     network management portion of the system was last
11     re-initialized."
12   ::= { system 3 }

Viele Hersteller packen zusätzliche Informationen in eigene MIBs. Cisco hat zum Beispiel die Herstellernummer 9. Die MIBs dieser Firma befinden sich unter ».1.3.6.1.4.1.9«, ausgeschrieben: »iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) cisco(9)«.

Für die MIB-Spezifikation verwendet SNMP die Beschreibungssprache SMI (Structure of Management Information, RFC 1155, [1]). SMI legt sowohl die allgemeine Struktur als auch die eindeutige Identifizierung von Netzwerk-Management-Informationen fest. SMI selbst ist in ASN.1 beschrieben (Abstract Syntax Notation Number 1), die es erlaubt, komplexe Datentypen und ihre zugeordneten Werte zu definieren.

ASN.1 BER (Basic Encoding Rules) legt Kodierungsregeln für Datentypen fest. Die räumen auch Zweifel aus, ob beispielsweise 10100101 als String oder als binär geschriebene Zahl 165 zu interpretieren ist; zusammen mit dem Wert kodiert BER auch den Datentyp. Die Versionsnummer 0 für SNMPv1 lautet in BER-Darstellung »02 01 00«. Die erste Stelle besagt, dass ein Feld vom Typ Integer folgt (02), das 1 Byte lang ist und den Wert 0 enthält. Vorteil: Selbst wenn ein Manager die Definition einer MIB eines seiner Agenten nicht kennt, kann das Programm dennoch die Werte der MIB korrekt darstellen. Auch für eine eventuelle Weiterverarbeitung ist es wichtig, den Datentyp zu kennen.

Die größte Schwäche von SNMPv1 ist die mangelhafte Authentifizierung. Lediglich ein so genannter Community-String teilt dem Agenten mit, ob ein Auftrag berechtigt ist. Jeder Agent unterscheidet einen Community-String für Get-Abfragen und einen für Set-Befehle. Jeder Manager, der diese Zeichenkette kennt, kann Daten aus dem Agenten auslesen oder diesem sogar Befehle geben.

Pseudo-Authentifizierung

Per Default sind »public« für Get-Anfragen und »private« für Set-Kommandos vorgegeben. Diese Wahl ist historisch bedingt: Auf einer Interop-Konferenz wollten Teilnehmer zeigen, dass die Kommunikation tatsächlich zwischen Implementationen unterschiedlicher Hersteller funktionierte. Die Tester wählten für diese Konferenz die beiden primitiven Passwörter. Dabei blieb es dann leider, da es so schön funktioniert hatte. Viele Admins verzichten aus ähnlichen Gründen darauf, den Community-String zu ändern. Zu allem Überfluss geht er in jedem Paket als Klartext über die Leitung. SNMP trägt daher auch den Spitznamen “Security is Not My Problem”.

Bei so geringem Schutz ist es verständlich, dass SNMPv1-Agenten kaum Set-Requests unterstützen. Die Sicherheitsproblematik bestimmte auch die weitere Entwicklung. Es folgten SNMPsec (Secure SNMP) und SNMPv2 [2], das einige neue Kommandos einführte, sich aber in vielen Untervarianten verzettelte. Mit SNMPv3 (siehe Kasten “SNMP-Version 3” und [3]) gibt es heute einen anerkannten Nachfolger, der ein komplettes Sicherheitsmodell implementiert. Einige der neuen Techniken wurden auch wieder zurück auf SNMPv1 portiert.

rocommunity Community Source OID

net-snmp-config --create-snmpv3-user -a Passwort Benutzername

snmpwalk -v3 -u Benutzername -l authPriv -A Passwort -X Passwort localhost .system

defSecurityName Benutzername
defContext ""
defAuthType MD5
defSecurityLevel authPriv
defAuthPassphrase Passwort
defVersion 3
defPrivPassphrase Passwort
defPrivType DES

Anwendung: Net-SNMP

Unter Linux stammt die bekannteste Implementierung eines SNMP-Agenten vom Net-SNMP-Projekt ([6], ehemals UCD-SNMP für University of California at Davis). Das Paket enthält auch Kommandozeilenwerkzeuge, um die Agenten abzufragen. Viele Distributionen bringen Net-SNMP bereits mit. Wer lieber selbst übersetzt: Das Paket ist auf Sourceforge erhältlich und kompiliert mit »./configure && make && make install«. Distributionspakete und selbst kompilierte Installationen unterscheiden sich vor allem in den verwendeten Pfaden.

Die meisten mitgelieferten MIBs bindet das Configure-Skript von sich aus ein, nur »HOST-RESOURCES«, »EVENT« und »MTA« fehlen. Wer diese braucht, gibt sie bei der Konfiguration explizit an. Die Dokumentation von Net-SNMP enthält mit »EXAMPLE.conf« eine Vorlage für die Konfiguration, die der Agent in »/etc/snmpd.conf« erwartet. Für erste Tests genügen einfache Sicherheitseinstellungen. Die Zeilen, die mit »com2sec« beginnen, sind wie folgt zu ändern:

# sec.name source community
com2sec local localhost public
# com2sec mynetwork NETWORK/24 COMMUNITY

Das gibt den Zugriff auf den Agenten für Localhost frei, der Community-String lautet »public«. Zugriffe von außen bleiben vorerst untersagt, daher ist »public« für den Test vertretbar. Im späteren Betrieb ist er unbedingt zu ändern!

Suche im MIB-Wald

Nach dem Start mit der überarbeiteten Konfigurationsdatei (»snmpd -c /etc/snmpd.conf«) wartet der Agent auf Anfragen. Am einfachsten geht das mit »snmpwalk«, das Tool ruft einen Ast des MIB-Baums ab. Es beginnt am angegebenen Punkt, fragt den Agenten mit »GetRequest« nach dem Wert und hangelt sich anschließend per »GetNextRequest«-Abfragen durch den Baum, bis es keine weiteren Werte in diesem Teil gibt. Interessant ist zum Beispiel die System-MIB; die Ausgabe des Aufrufs »snmpwalk -v1 -c public localhost .system« ist in Listing 2 zu sehen.

01 SNMPv2-MIB::sysDescr.0 = STRING: Linux notebook 2.6.5-7.111.5-default #1 Wed Nov 17 11:08:17
02 SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
03 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1137) 0:00:11.37
04 SNMPv2-MIB::sysContact.0 = STRING: Me <me@somewhere.org>
05 SNMPv2-MIB::sysName.0 = STRING: notebook
06 SNMPv2-MIB::sysLocation.0 = STRING: Right here, right now.
07 SNMPv2-MIB::sysORLastChange.0 = Timeticks: (2) 0:00:00.02

Die Informationen zum Kernel in »sysDescr« besorgt der Agent selbst; den Standort und den Systemverantwortlichen »sysContact« (am besten mit Telefon) muss der Administrator im Konfigurationsfile »snmpd.conf« hinterlegen. Der Aufruf zeigt auch, dass die Tools die angegebene OID in jeder MIB suchen, wenn der OID-Pfad nicht vollständig angegeben ist.

Die »IF«-MIB bietet alle Informationen zu den Interfaces des Systems, unter anderem die komplette Routingtabelle. Die Zählerstände dieser MIB dienen zum Beispiel als Datenbasis für MRTG (Multi Router Traffic Grapher, [11]). Abbildung 3 zeigt den Datendurchsatz am DE-CIX [12], dem zentralen deutschen Internetknoten (Commercial Internet Exchange). Dasselbe Verfahren taugt auch bestens für den eigenen Internetanschluss. Lesenden SNMP-Zugang zum Router gewähren die meisten Provider auf Anfrage.

Abbildung 2: Jedes SNMPv1-Paket beginnt mit einer Versionsnummer und dem Community-String, leider als Klartext. Die SNMP-PDU selbst besteht aus einer Typangabe und dem Inhalt der Nachricht.

Abbildung 3: Datendurchsatz am DE-CIX (zentraler Internetknoten). MRTG fragt die Werte mittels SNMP ab, speichert ihren Verlauf und gibt sie als Grafik aus.

Wer sich für die Ressourcen seines Systems interessiert und seinen Agenten mit der »HOST-RESOURCES«-MIB kompiliert hat (»./configure –with-mib-modules =host«), kann einen Blick in die ».host«-Tabelle werfen. Sie informiert über Hardware (System, Speicher, Devices und so weiter) und die Software (was ist installiert, was läuft zur Zeit, was verbraucht wie viel Ressourcen).

Tiefe Einblicke

Das Net-SNMP-Paket enthält auch eine so genannte private MIB, die das Projekt selbst entwickelte. Sie ist bei der IANA als »enterprises.2021« registriert. Das Wandern entlang dieser MIB mit »snmpwalk -v1 -c public localhost .enterprises.2021« informiert zum Beispiel über den freien Speicher »memTotalFree«, die Belegung der Partitionen »dskPercent« und die durchschnittliche Prozessorlast »laLoad« (Load Average).

Wer einen einzelnen Wert aus der MIB braucht, greift besser zum Befehl »snmpget«. Damit ist es auch möglich, Monitoring-Programme wie Nagios [7] so zu konfigurieren, dass sie einzelne Werte überwachen und beim Überschreiten eines Grenzwerts Alarm schlagen. Idealerweise sieht Nagios in einem gut gepflegten Netz so aus, wie Abbildung 4 zeigt.

Abbildung 4: Nagios informiert über den Zustand der Rechner und Router in einem Netzwerk. Es kann dazu sein eigenes Managementprotokoll verwenden, bedient sich auf Wunsch aber auch bei SNMP. Damit sammelt es Informationen von Netzwerkgeräten wie Routern und Switches.

MIBs einspielen

Die Erkundungsreise muss sich nicht auf den lokal laufenden SNMP-Agenten beschränken. Da recht häufig der Community-String unverändert »public« lautet, geben die Netzwerkgeräte der näheren Umgebung (Switches, Router) bereitwillig Auskunft. Somit taugt der SNMP-Dienst hervorragend zur Dokumentation eines Netzes, und zwar mit IP- und MAC-Adressen, Routing, Betriebssystemen, Patch-Ständen, installierten Applikationen und vielem mehr.

Interessante Informationen stecken in den herstellerspezifischen Zusatz-MIBs. Net-SNMP zeigt die Bedeutung der zusätzlichen OIDs, wenn die Software auf dem Managementsystem die MIB-Definition kennt. Mit deren Hilfe klappt auch die Übersetzung zwischen numerischen OIDs und deren Textform. Die Definitionsdateien sind auf den CDs zu finden, die zur verwalteten Hardware gehören, sowie auf den FTP-Servern der Hersteller oder im MIB-Depot [13]. Die Dateien enden auf ».txt«, ».mib« oder ».my«.

Tabelle 2 zeigt eine kleine Auswahl von Beispiel-OIDs. Alle (bis auf die von HP) befinden sich im ».enterprises«-Zweig. Der vollständige Pfad beginnt daher mit ».1.3.6.1.4.1«. Die Spalte “Bedeutung” wurde aus der Originalbeschreibung der MIBs übersetzt und glänzt gelegentlich mit ungewollter Komik.

Will ein Admin die MIB-Definition nicht systemweit in »/usr/share/snmp/mibs« hinterlegen (oder in »/usr/local/share/snmp/mibs«, je nach Installation), genügt es auch, sie in »~/.snmp/mibs/« zu kopieren. In beiden Fällen müssen die SNMP-Tools wissen, welche Zusatz-MIBs sie zu beachten haben. Das erfahren sie aus der Systemvariablen »MIBS«. Lautet ihr Inhalt auf »+Name«, dann beachten die Tools zusätzlich zu den Standard-MIBs die neu hinzugefügte. Deren Name steht am Anfang der MIB-Definitionsdatei vor »DEFINITIONS ::= BEGIN«. Da MIBs oft aufeinander aufbauen, ist es einfacher, alle auf einmal bekannt zu machen, »export MIBS=ALL« genügt.

Agent mit Sonderauftrag

Seine wahre Flexibilität zeigt SNMP, wenn Admins die Agenten um angepasste Funktionen ergänzen. Sie können dazu eigene MIBs entwickeln und den Agenten mit selbst programmiertem C-Code erweitern. In der Praxis ist das aber selten nötig, da Net-SNMP-Agenten bereits sehr leistungsfähig sind. Den kompletten Umfang der Konfigurationsmöglichkeiten verraten »man snmpd.conf« oder das Stöbern auf der Net-SNMP-Homepage [6].

Zum Beispiel kann Net-SNMP gezielt einzelne Prozesse überwachen. Die Beispielkonfiguration schlägt »mountd«, »ntalkd« und »sendmail« vor. Zusätzlich zum Namen erkennt der Agent auch, wie oft minimal und maximal dieser Prozess laufen soll:

proc sendmail 10 1

Diese Konfiguration in »/etc/snmpd.conf« legt fest, dass ein bis zehn Sendmail-Prozesse als Normalzustand gelten. Falls die Bedingung nicht zutrifft, setzt der Agent das entsprechende »prErrorFlag« und liefert den Fehlertext über »prErrMessage«. Bemerkt das Managementsystem einen Fehler, kann es über SNMP sogar erste Hilfe leisten: Die Konfiguration des Agenten enthält optional einen Befehl, der das Problem zu beseitigen versucht, etwa:

procfix sendmail /etc/init.d/sendmail restart

Schreibt der Manager den Wert »1« in das Agentenregister »prErrFix«, führt der Agent den Befehl aus. Im »snmpset«-Befehl ist die OID anzugeben, die zum überwachten Programm gehört: »prErrorFix.Nummer«. Danach folgen der Datentyp (hier »i« für Integer) und der gewünschte Wert:

snmpset -v1 -c private localhost prErrFix.1 i 1

Im Logfile sollte sich zeigen, ob Sendmail wirklich neu gestartet ist. Solche Aktionen vollautomatisch ausführen ist aber kritisch: Mehrfach hintereinander aufgerufen nimmt ihr Nutzen stark ab. Besser ist es, den Befehl manuell auszulösen oder das Managementsystem in mehreren Eskalationsstufen zu betreiben. Sinnvoll wäre: Zunächst den automatischen Fix versuchen und – wenn der Fehler in einer vorgegebenen Zeitspanne erneut auftritt – den Admin alarmieren.

Festplattenplatz

Den verfügbaren Platz einer Festplattenpartition überwacht der Agent, wenn die Konfiguration folgende Zeile enthält:

disk / 10000

Falls der freie Platz auf der Root-Partition die 10-MByte-Grenze unterschreitet, setzt der Agent das »dskErrorFlag«. Unter »dskPercent« zeigt er, wie groß der Anteil freien Speichers derzeit ist. Entsprechendes gilt für die Prozessorlast, die in der Tabelle »loadTable« steht. Mit der Nagiostat-Erweiterung [10] liest Nagios (ähnlich wie MRTG) Werte aus einem SNMP-Agenten und stellt den Inhalt als Grafik dar. Die Abbildungen 5a und 5b zeigen die damit gemessene Prozessorauslastung eines Servers.

Abbildung 5a: Diese Nagios-Installation überwacht für einen Computer den Festplattenplatz und die Prozessorlast mit Hilfe von SNMP. Zudem fragt Nagios einzelne Dienste direkt ab.

Abbildung 5b: Nagiostat bereitet die Prozessorlast grafisch auf. Deutlich ist die Schwankung im Verlauf eines Jahres zu erkennen. Der Server steht in einer Schule und hat in den Ferien wenig zu tun.

Sogar Logfiles kann ein Net-SNMP-Agent überwachen. Leider ist diese Funktion kaum dokumentiert. In der Konfiguration müssen der Name des Tests, das zu überwachende Logfile, die Zeitabstände zwischen den Prüfungen und der gesuchte Ausdruck (als Regular Expression) angegeben sein. Soll der Agent die Logdatei des Mailservers alle 30 Sekunden nach Nachrichten über unbekannte Benutzer durchsuchen, so lautet die Konfiguration:

logmatch unknown_user /var/log/mail 30 User unknown

Der Agent liefert die Gesamtzahl an Fundstellen in »logMatchGlobalCount« sowie in »logMatchCount« die Trefferzahl seit der letzten Anfrage.

Von selbst aktiv

Der Agent sorgt selbst dafür, dass er – auch ohne Anfrage des Managers – das Logfile alle 30 Sekunden nach weiteren Treffern durchsucht und die Werte in der MIB anpasst. In anderen Fällen ermitteln Agenten einen Wert erst, wenn wirklich eine Anfrage dazu vorliegt.

Durch eine Statistik der »User unknown«-Einträge im Mail-Log kann das Managementsystem so genannte Rumpelstielzchen-Attacken entdecken. Mit ihr versuchen Spammer gültige Mailadressen zu erfahren, indem sie viele Benutzernamen durchprobieren. Auch Brute-Force-Attacken gegen SSH sind so auszumachen. Abbildung 6 zeigt als Beispiel die Spam-Statistik eines Mailservers. Grün sind die verarbeiteten Mails dargestellt und blau die erkannten Spams.

Abbildung 6: Verkehrsstatistik eines Mailservers. Grün dargestellt sind die verarbeiteten Mails, Spam dagagen blau. Im April senkt eine neu eingeführte RBL-Prüfung (Realtime Blackhole List) die Zahl verarbeiteter Mails um 50 Prozent. Durch besseres Training erkennt Spamassassin seit Februar mehr Müll.

Die einfachste Technik, um einen SNMP-Agenten mit eigenen Kommandos aufzurüsten, besteht darin, ihn externe Befehle ausführen zu lassen. Zum Beispiel den Status der Festplatte »/dev/hda« mit »smartctl« abzufragen [14]:

exec diskstatus /usr/sbin/smartctl -q silent /dev/hda

Ein Aufruf des Teilbaums »extTable« startet das Diskstatus-Kommando und liefert das Ergebnis. Die Ausgabe von »snmpwalk -v1 -c public localhost .extTable« ist in Listing 3 zu sehen. Der Wert »0« in »extResult.1« (Zeile 4) zeigt, dass die Festplatte nach Meinung der Smartmontools in Ordnung ist und keiner Nachforschung bedarf. Ein Managementsystem könnte bei abweichenden Werten ein rotes Lämpchen aktivieren. In »extOutput« wäre die erste Zeile der Standardausgabe zu sehen, so vorhanden.

01 UCD-SNMP-MIB::extIndex.1 = INTEGER: 1
02 UCD-SNMP-MIB::extNames.1 = STRING: diskstatus
03 UCD-SNMP-MIB::extCommand.1 = STRING: /usr/sbin/smartctl -q silent /dev/hda
04 UCD-SNMP-MIB::extResult.1 = INTEGER: 0
05 UCD-SNMP-MIB::extOutput.1 = STRING:
06 UCD-SNMP-MIB::extErrFix.1 = INTEGER: 0
07 UCD-SNMP-MIB::extErrFixCmd.1 = STRING:

Trap und Inform

Statt Prozessor- und Netzwerkkapazität mit regelmäßigen Zustandsabfragen zu verschwenden, ist es besser, wenn der Agent das System selbstständig überwacht und den Manager informiert, sobald ein kritischer Zustand eintritt. Dafür sind die SNMP-Traps vorgesehen. Per Default sendet der Agent Traps beim Starten und Beenden, wenn ein Interface zwischen den Zuständen Up und Down wechselt und auch bei falschen Community-Strings (Authentication Failures). Listing 4 – in »snmpd.conf« eingetragen – sorgt dafür, dass er sich zusätzlich meldet, falls die Prozessorlast über 40 Prozent steigt.

01 trapsink 127.0.0.1
02 trapcommunity public
03 agentSecName internal
04 monitor -u internal -o sysUpTime.0 -o laLoadInt -r 30 "high processor load" laLoadInt>40

Zeile 1 definiert das Ziel der Fehlermeldungen, der dazu passende Community-String folgt darunter. Net-SNMP benötigt noch einen Usernamen (für SNMPv3), mit dem der Agent den Test durchführt, in diesem Fall lautet er »internal«. Das »monitor«-Kommando in der letzten Zeile definiert den Test. Der Agent überwacht alle 30 Sekunden (»-r 30«), ob irgendwo in der »laLoadInt«-Tabelle (sie enthält Durchschnittswerte für 1, 5 und 15 Minuten) ein Wert größer 40 steht, der eine Prozessorlast von mehr als 40 Prozent bedeutet. Ist dies der Fall, löst der Agent eine Trap-Meldung aus. Sie enthält die »sysUpTime« und alle Einträge der »laLoadInt«-Tabelle.

Sammelstelle

Auf dem Managementsystem sammelt ein Trap-Daemon die Traps ein. Für die Konfiguration in Listing 4 muss er auf derselben Maschine laufen (gestartet mit dem Kommando »snmptrapd -f -Lo«). Bei großer Last auf dem System sendet der Agent eine erste Trap-Meldung. Hält der Zustand länger an, unterbleiben aber weitere. Erst nachdem die auslösende Bedingung wegfällt (hier, wenn die Last unter 40 Prozent sinkt), schaltet sich der Monitor wieder scharf.

Da SNMP-Pakete per UDP das Netz durchqueren, erhält der Agent keine Rückmeldung, ob sein Trap zum Manager durchgedrungen ist. SNMPv3 (siehe Kasten “SNMP-Version 3”) begegnet dem Missstand mit den neuen »Inform«-Nachrichten. Der Manager muss deren Empfang quittieren. Außerdem kann Net-SNMP die herkömmlichen Traps auch per TCP verschicken.

SNMP eignet sich hervorragend für viele tägliche Arbeiten beim Verwalten kleiner und großer Netze. Ohne Funktionsmonster vom Schlage eines HP Openview oder CA Unicenter einsetzen zu müssen, profitieren Admins von diesem Standard – sei es mit den einfachen Kommandozeilenwerkzeugen oder durch spezielle Tools wie MRTG. Bleibt nur zu hoffen, dass die hart arbeitenden Administratoren die Vorzüge des einfachen Standards wieder entdecken, um ihre komplizierten Aufgaben leicht zu lösen. (fjl)