SNMP

SNMP (Simple Network Management Protocol)
Familie:	Internetprotokollfamilie
Einsatzgebiet:	Netzwerkverwaltung
Neueste Version:	SNMPv3
Ports:	161/UDP 162/UDP (Trap)
SNMP im TCP/IP‑Protokollstapel: Anwendung SNMP Transport UDP Internet IP (IPv4, IPv6) Netzzugang Ethernet Token Bus Token Ring FDDI …
Standards:	RFC 1157 (SNMP, 1990) RFC 3410 ff (SNMPv3, 2002) (siehe Text)

Überwachung der Netzwerkkomponenten von der Managementkonsole aus

Das Simple Network Management Protocol (englisch für „einfaches Netzwerkverwaltungsprotokoll“, kurz SNMP), ist ein Netzwerkprotokoll, das von der IETF entwickelt wurde, um Netzwerkelemente (z. B. Router, Server, Switches, Drucker, Computer usw.) von einer zentralen Station aus überwachen und steuern zu können. Das Protokoll regelt hierbei die Kommunikation zwischen den überwachten Geräten und der Überwachungsstation. Hierzu beschreibt SNMP den Aufbau der Datenpakete, die gesendet werden können, und den Kommunikationsablauf. SNMP wurde dabei so ausgelegt, dass jedes netzwerkfähige Gerät mit in die Überwachung aufgenommen werden kann. Zu den Aufgaben des Netzwerkmanagements, die mit SNMP möglich sind, zählen:

• Überwachung von Netzwerkkomponenten,
• Fernsteuerung und Fernkonfiguration von Netzwerkkomponenten,
• Fehlererkennung und Fehlerbenachrichtigung.

Durch seine Einfachheit, Modularität und Vielseitigkeit hat sich SNMP zum Standard entwickelt, der sowohl von den meisten Managementprogrammen als auch von Endgeräten unterstützt wird. So ist SNMP z. B. nicht auf das Netzwerkprotokoll IP als Transport angewiesen. Es gibt Implementierungen, die über IPX (Novell, NetWare) oder AppleTalk (Apple, MacOS) angesprochen werden können.

Funktionsweise

Das Prinzip der SNMP-Kommunikation

Zur Überwachung werden sogenannte Agenten eingesetzt. Dabei handelt es sich um Programme, die direkt auf den überwachten Geräten laufen. Diese Programme sind in der Lage, den Zustand des Gerätes zu erfassen und auch selbst Einstellungen vorzunehmen oder Aktionen auszulösen. Mit Hilfe von SNMP ist es möglich, dass die zentrale Managementstation mit den Agenten über ein Netzwerk kommunizieren kann. Dazu gibt es sechs verschiedene Datenpakete, die gesendet werden können:

• GET, zum Anfordern eines Management-Datensatzes
• GETNEXT, um den nachfolgenden Datensatz abzurufen (um Tabellen zu durchlaufen)
• GETBULK, um mehrere Datensätze auf einmal abzurufen, wie z. B. mehrere Reihen einer Tabelle (verfügbar ab SNMPv2)
• SET, um einen oder mehrere Datensätze eines Netzelementes zu verändern. Manchmal verlangt ein Netzelement die gleichzeitige Änderung mehrerer Datensätze, um die Konsistenz zu überprüfen. Beispielsweise erfordert die Konfiguration einer IP-Adresse die gleichzeitige Angabe der Netzwerkmaske.
• RESPONSE, Antwort auf eines der vorherigen Pakete.
• TRAP, unaufgeforderte Nachricht von einem Agenten an den Manager, dass ein Ereignis eingetreten ist. Programme wie Wireshark, die zum Dekodieren von Protokollen wie SNMP benutzt werden, nennen dieses Datenpaket auch REPORT. Ein TRAP kann nämlich auch geschickt werden, wenn die in einem SET-Datenpaket beschriebene(n) Datensatzänderung(en) nicht durchgeführt werden konnte(n), und nicht nur, um eine Fehlfunktion (z. B. einen Defekt eines Moduls eines Netzelements) zu melden.

Die drei Get-Pakete (Get, GetNext, GetBulk) können vom Manager zu einem Agenten gesendet werden, um Daten über die jeweilige Station anzufordern. Dieser antwortet mit einem Response-Paket, das entweder die angeforderten Daten enthält oder eine Fehlermeldung.

Mit dem Set-Paket kann ein Manager Werte beim Agenten verändern. Damit ist es möglich, Einstellungen vorzunehmen oder Aktionen auszulösen. Der Agent bestätigt die Übernahme der Werte ebenfalls mit einem Response-Paket.

Wenn der Agent bei der Überwachung des Systems einen Fehler erkennt, kann er diesen mit Hilfe eines Trap-Paketes unaufgefordert an die Management-Station melden. Diese Pakete werden nicht vom Manager bestätigt. Der Agent kann daher nicht feststellen, ob der Trap beim Manager angekommen ist.

Damit die Netzwerkbelastung gering bleibt, wird zum Versenden der Nachrichten das verbindungslose UDP-Protokoll verwendet. Der Agent empfängt dabei die Anfragen (Requests) auf dem Port 161, während für den Manager der Port 162 zum Empfangen der Trap-Meldungen vorgeschrieben ist.

Management Information Base

Dieser Artikel oder Abschnitt bedarf einer Überarbeitung. Näheres ist auf der Diskussionsseite angegeben. Hilf mit, ihn zu verbessern, und entferne anschließend diese Markierung.

Die MIB in der Kommunikation zwischen Manager und Agenten

SNMP selber definiert nicht, welche Werte eine Netzwerkkomponente liefern kann oder muss, da das von der Art der jeweiligen Komponente abhängt.

Die Werte, die von einem Manager über eine gemanagte Netzwerkkomponente ausgelesen und verändert werden können, die so genannten ‚Managed Objects‘, werden daher in einer Management Information Base (kurz MIB) beschrieben. Dabei handelt es sich um Beschreibungsdateien, in denen die einzelnen Werte tabellarisch aufgeführt werden. Die MIB ist jeweils spezifisch für eine bestimmte Komponente (oder eine Klasse von Komponenten, etwa Switches).

Der MIB-Baum

Die Informationen der MIB sind in Form einer Baumstruktur organisiert, deren einzelne Zweige entweder durch Nummern oder alternativ durch alphanumerische Bezeichnungen dargestellt werden können. Die MIB-2 ist zum Beispiel unter iso.org.dod.internet.mgmt.MIB-2 zu finden, das ebenso durch die Zahlenreihe 1.3.6.1.2.1 eindeutig bestimmt ist (1 für iso, 3 für org usw.). Diese aus Punkten und Zahlen bestehende Zeichenkette nennt man Object Identifier (OID). In den MIBs wird dann weiter verzweigt bis zu den einzelnen Daten, die jeweils auch eine eigene OID besitzen und somit eindeutig identifiziert werden können.

Diese Dateien sind in der abstrakten Beschreibungssprache SMIv2 geschrieben, welche auf ASN.1 basiert. Zu jedem Datum, das vom Agenten abgerufen oder verändert werden kann, werden in diesen Dateien eine Reihe von Informationen angegeben:

• Name,
• Datentyp,
• Zugriffsberechtigung (read-only, read-write, not-accessible),
• Status (Mandatory, Optional, Deprecated, Obsolete),
• Beschreibungstext,
• OID.

Mit Hilfe der Beschreibungsdateien sind die Managementprogramme in der Lage, den hierarchischen Aufbau der Daten jedes beliebigen SNMP-Agenten darzustellen und Werte von diesem anzufordern.

Mehrere solche MIBs wurden in RFCs, einer Reihe von technischen und organisatorischen Dokumenten zum Internet, definiert. Besonders hervorzuheben ist hierbei die bereits erwähnte MIB-2, die in der RFC 1213 definiert wurde und von allen Netzwerkkomponenten unterstützt wird. Neben dieser Standard-MIB existieren eine ganze Reihe von weiteren in RFCs definierten MIBs für verschiedene Technologien (z. B. ISDN-MIB), Protokolle (z. B. OSPF-MIB) oder Komponenten (z. B. UPS-MIB). Sie enthalten jeweils allgemeine Objekte wie z. B. Portstatus, Router-Id, Ladezustand der Batterie und ähnliches.

Neben den in den RFCs definierten MIBs kann jeder Hersteller von Soft- oder Hardware eigene MIBs, sogenannte private MIBs, definieren, die die speziellen Eigenschaften seines Produktes wiedergeben. Diese werden unter der OID iso(1).org(3).dod(6).internet(1).private(4).enterprises(1) bei der IANA, einer für die Vergabe von IP-Adressen, Top Level Domains und IP-Protokollnummern zuständigen Organisation, registriert. Mittlerweile sind unter dieser OID mehrere tausend Firmen registriert (siehe private enterprise numbers). Ist einer OID einmal ein Objekt zugeordnet, so darf sich die Bedeutung dieser OID – sofern vom Gerät (dem SNMP-Agenten) unterstützt – nicht wieder ändern. Es darf auch keine Überschneidungen geben.

Die im Bild „Der MIB_Baum“ gezeigten Root-Nodes „ccitt“ und „joint“ werden für snmp nicht verwendet. CCITT ist beispielsweise ein Unterbaum, der von dem International Telegraph and Telephone Consultative Commitee gepflegt wird, welches zusammen mit der Internationalen Organisation für Normung (ISO) ebenfalls den JOINT Unterbaum pflegt.

Wirklich interessant ist für SNMP nur der Unterbaum .iso.org.dod.internet (.1.3.6.1), welcher auch einfach mit „internet“ abgekürzt werden kann. Ein snmpget nach „internet.xy“ würde also denselben Wert liefern, wie ein snmpget nach „.iso.org.dod.internet.xy“ bzw. „.1.3.6.1.xy“.

Versionen

Version 1

Die erste Version von SNMP wurde 1988 in den folgenden RFCs definiert:

• RFC 1155 – Structure and Identification of Management Information for TCP/IP-based internets (Ersetzte die RFC 1065)
• RFC 1156 – Management Information Base for Network Management of TCP/IP-based internets (Ersetzte die RFC 1066)
• RFC 1157 – A Simple Network Management Protocol (Ersetzte die RFC 1067 und die RFC 1098)

Das Hauptproblem der ersten Version ist die schlechte Sicherheit. Eines der Probleme ist die ungesicherte Verwendung des Passwortes. Das Passwort wird im Klartext übertragen, kann so leicht abgehört und somit durch unberechtigte Parteien verwendet werden.

Secure SNMP

Das gestiegene Bedürfnis nach Sicherheit führte dazu, dass 1992 drei RFCs über SNMPsec (Secure SNMP) veröffentlicht wurden.

• RFC 1351 – SNMP Administrative Model
• RFC 1352 – SNMP Security Protocols
• RFC 1353 – Definitions of Managed Objects for Administration of SNMP Parties

Diese Version wurde nie eingeführt, sondern durch SNMPv2 ersetzt.

Party-Based SNMP Version 2 (SNMPv2p)

1993 wurde SNMPv2p von der IETF veröffentlicht. Es verbesserte SNMPv1 in puncto Sicherheit und Vertraulichkeit und führte eine Kommunikation zwischen verschiedenen Managern ein. Durch den neuen GetBulk-Befehl wurde das Abfragen von Tabellen erheblich erleichtert.

• RFC 1441 – Introduction to version 2 of the Internet-standard Network Management Framework
• RFC 1445 – Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)
• RFC 1446 – Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)
• RFC 1447 – Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)

Diese Version wird heute nicht mehr verwendet.

User-Based SNMP Version 2 (SNMPv2u)

Bei SNMPv2u versucht man, durch Benutzernamen die Sicherheit zu erhöhen.

• RFC 1909 – An Administrative Infrastructure for SNMPv2
• RFC 1910 – User-based Security Model for SNMPv2

Diese Version wird heute nicht mehr verwendet.

Community-Based SNMP Version 2 (SNMPv2c)

SNMPv2c ist bezüglich Sicherheit auf dem Stand von SNMPv1. Es ist lediglich erweitert um ein paar zusätzliche Funktionen, die es bereits bei SNMPv2p gab:

• Tabellen müssen nicht mehr mit den GetNext-Befehl durchlaufen werden sondern können mit dem GetBulk-Befehl auf einmal geholt werden.
• Kommunikation zwischen verschiedenen Managern.

Diese Version hat sich durchgesetzt und breite Akzeptanz erfahren. Wenn heutzutage von SNMPv2 gesprochen wird, ist meistens diese Version gemeint.

• RFC 1901 – Introduction to Community-based SNMPv2
• RFC 1905 – Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2) (Ersetzte die RFC 1448)
• RFC 1906 – Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2) (Ersetzte die RFC 1449)

Version 3

SNMP-Versionen 1 und 2c bieten fast keine Sicherheitsmechanismen. Daher stammt auch die scherzhafte Deutung der Abkürzung SNMP als „Security is not my problem“ (Sicherheit ist nicht mein Problem). In der aktuellen Version 3 wurden die Sicherheitsmechanismen deutlich ausgebaut. Die damit einhergehende gestiegene Komplexität (z. B. Schlüsselverwaltung) hat aber dazu geführt, dass SNMPv3 noch nicht so weit verbreitet ist wie SNMPv2.

SNMP in der neuesten Version 3 wird durch eine Reihe neuer RFCs definiert (die Spezifizierung erfolgte im Dezember 2002):

• RFC 3410 – Introduction and Applicability Statements for Internet-Standard Management Framework
• RFC 3411 – An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks
• RFC 3412 – Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
• RFC 3413 – Simple Network Management Protocol (SNMP) Applications
• RFC 3414 – User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
• RFC 3415 – View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
• RFC 3416 – Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)
• RFC 3417 – Transport Mappings for the Simple Network Management Protocol (SNMP)
• RFC 3418 – Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)

Paketaufbau

Die Beschreibung der SNMP-Pakete erfolgt durch ASN.1, die Kodierung für den Transport übers Netzwerk mittels Basic Encoding Rules (BER). Die meisten SNMP-Pakete sind identisch aufgebaut. Lediglich bei Trap-Meldungen werden im PDU-Header teilweise andere Informationen versendet.

Aufbau eines SNMP-Paketes, für nicht Trap-Meldungen

Länge der Nachricht in Byte		SNMP-Paket Header
Versionsnummer
Community Name
Pakettyp (Get, GetNext, …)	PDU-Header	PDU (Protocol Data Unit)
PDU Länge in Byte
RequestID
Fehlerstatus
Fehler-Index
Länge des PDU-Bodys in Byte	PDU-Body
Variable Binding 1
Variable Binding 2
. . .
Variable Binding n

SNMP-Paket Header

Im Header wird die Gesamtgröße des Pakets, die Versionsnummer (SNMPv1, SNMPv2 oder SNMPv3) und der Community Name übertragen. Durch Zuweisen von Communitys sollten Zugriffsrechte vergeben werden. In den meisten Fällen wurde aber als Community Name „public“ gewählt für Lesezugriff und „private“ für Lese- und Schreibzugriff. Sicherheit kann aber auch durch andere Namen nicht erreicht werden, da der Community Name im Klartext übertragen wird und von jedem im Netz mitgehört werden kann.

PDU-Header (Nicht-Trap-Pakete)

Im ersten Teil des PDU-Headers wird die Art des SNMP-Paketes und die Größe der PDU übertragen. Der Aufbau des zweiten Teils hängt von der Art des SNMP-Paketes ab.

Damit Antwortpakete den vorherigen Anfragen zugeordnet werden können, gibt es die Request ID, welche bei Anfrage und Antwort identisch sind. Damit ist es möglich, mehrere Anfragen zu verschicken und die Antworten wieder richtig zuzuordnen.

Der Fehlerstatus und -index wird dazu verwendet, bei Antwortpaketen mitzuteilen, warum eine Anfrage nicht bearbeitet werden konnte. Solange kein Fehler auftritt, sind die beiden Felder mit dem Wert Null belegt. Im Fehlerfall gibt der Fehlerindex an, beim wievielten Datensatz der Fehler auftrat. Mit dem Fehlerstatus wird der Grund des Fehlers angegeben. Der Fehlerstatus kann bei SNMPv1 einen von 6 möglichen Werten haben:

• kein Fehler;
• Paket ist zu groß zum Versenden;
• die OID wird nicht unterstützt;
• falscher Datentyp oder Wert (nur als Antwort auf Set-Pakete möglich);
• nur Lesezugriff (nur als Antwort auf Set-Pakete möglich)
• unbekannter Generierungsfehler.

PDU-Header (Trap-Pakete)

Die ersten beiden Felder des PDU-Header sind bei Traps identisch mit denen anderer SNMP-Pakete. Das Feld Pakettyp gibt an, dass es sich um einen Trap handelt. Ebenfalls wird hier die Größe der PDU angegeben. Im zweiten Teil werden andere Werte übertragen, die nur bei Traps benötigt werden.

Aufbau des PDU-Header eines SNMP-Trap-Paketes

Pakettyp (Trap)	PDU-Header
PDU-Länge in Byte
OID des Gerätes, das den Trap generiert hat
IP-Adresse des Absenders
allgemeine TrapID
firmenspezifische TrapID
Zeitpunkt des Auftretens des Trap-Ereignisses

Zum Erkennen, von wem die Nachricht kommt, wird die IP-Adresse des Absenders mitgesendet und dessen OID. Die OID gibt an, um was für ein Gerät es sich handelt. Das ist wichtig zu wissen, wenn es sich um einen firmenspezifischen Trap handelt, die nur für diesen Gerätetyp gilt.

Danach folgt die allgemeine TrapID. Es gibt sieben mögliche allgemeine TrapIDs:

• Kaltstart
• Warmstart
• Link Down
• Link Up
• Authentifizierungsfehler
• EGP-Nachbar verloren
• firmenspezifisch

Wird in diesem Feld angegeben, dass es sich um eine firmenspezifischen Trap handelt, wird dessen ID im nachfolgenden Feld übertragen.

Da es möglich ist, dass Trap-Pakete nicht in der Reihenfolge eintreffen wie sie versendet wurden, gibt es zusätzlich noch eine Zeitangabe, die auf Hundertstelsekunden genau angibt, wie lang der SNMP-Agent gelaufen ist, bis das Trap-Ereignis auftrat. Dadurch ist es möglich die Trap-Ereignisse in die zeitlich richtige Reihenfolge zu bringen.

PDU-Body

Im PDU-Body werden die eigentlichen Werte übertragen. Jeder Wert wird in einer sogenannten Variable Binding übertragen:

Variable Binding

Größe der Variable Binding	Variable Binding
OID
Datentyp
Wert

Zu einer Variable Binding gehören deren OID, der Datentyp und der Wert selber.

Es gibt keine Vorgabe, wie viele Variable Bindings im PDU-Body mitgeschickt werden dürfen. Es ist also möglich, mehrere Werte mit einem Get-Befehl abzufragen. Wenn aber das Antwortpaket dabei zu groß wird, kann es passieren, dass die entsprechende Fehlermeldung im Antwortpaket zurückgeschickt wird.

Bei Traps ist es auch möglich, dass keine Variable Bindings mitgeschickt werden. In dem Fall wird die TrapID als ausreichende Information angesehen.

Im SNMP-Paket ist keine Angabe vorgesehen, welche die Anzahl an mitgeschickten Variable Bindings angibt. Das lässt sich nur über die Größenangabe des PDU-Bodys und der Größenangabe der einzelnen Variable Bindings herausfinden.

Sicherheitsprobleme

Ein schwacher Aspekt von SNMP Version 1 bis 2c ist die Sicherheit. Diese Versionen von SNMP unterstützen keine Anmeldung mit Kennwort und Benutzernamen, es werden sogenannte Communities verwendet. Diese haben jedoch den Nachteil, dass jeder User im Netzwerk mit einem passenden Programm Systeminformationen auslesen und sogar Werte verändern kann.

SNMP Version 3 bietet unter anderem Verschlüsselung und bessere Authentifizierung; dies wird aber zur Zeit aufgrund der höheren Komplexität oft nicht genutzt.

Communities sind einfache Namen, wie zum Beispiel “PUBLIC“ (darf nur lesen) oder “PRIVATE“ (darf auch schreiben), die mit der Anfrage zusammen vom SNMP Service übermittelt werden. Man kann natürlich einen sehr langen und komplizierten Community Namen verwenden, der Nachteil ist jedoch, dass SNMP-Pakete nicht verschlüsselt sind und deshalb sehr einfach von einem Angreifer “gesnifft“ werden können.

Allowed Host: Es gibt jedoch die Möglichkeit, die IP-Adressen der Systeme einzuschränken, die mit einem überwachten SNMP-System Kontakt aufnehmen dürfen. Dies ist ein relativ einfacher Schutz und mit ARP-Spoofing einfach zu fälschen.

Management-Schutz: Neuerdings ist es üblich, dass man für die Überwachung der Systeme ein eigenes Netzwerk erstellt, um den Nutzdaten-Verkehr vom Management-Verkehr zu trennen.

Read Only: Man hat auch die Möglichkeit, auf gewisse Systeme ein “Read Only“ zu vergeben. Somit kann jedes Überwachungsgerät nur lesen. Dies wird häufig bei Routern verwendet.

^[1]

Siehe auch

• Agent Extensibility Protocol (AgentX)

Einzelnachweise

1. ↑ Systeme verraten sensible Daten per SNMP. In: Heise.de, 4. März 2008 (online)

Weblinks

• OID Info SNMP OID Repository
• SNMP FAQ part 1 part 2 (englisch)
• Sicherheitsprobleme bei SNMP vermeiden Artikel auf IT-Defender.com