Simple Network Management Protocol

Grundidee und Einsatz

SNMP steht für Simple Network Management Protocol, auf Deutsch „Einfaches Netzwerkverwaltungsprotokoll“. Es ist ein Netzwerkprotokoll der Internetprotokollfamilie und wurde von der IETF entwickelt, um Netzwerkelemente wie Router, Server, Switches, Drucker oder Computer von einer zentralen Station aus zu überwachen und zu steuern. Die neueste Version ist SNMPv3. SNMP arbeitet im TCP/IP-Protokollstapel auf Anwendungsebene und nutzt UDP über IP, zum Beispiel IPv4 oder IPv6.

Das Protokoll legt fest, wie die überwachten Geräte und die Managementstation miteinander kommunizieren. Es beschreibt den Aufbau der Datenpakete und den Ablauf der Kommunikation. Dadurch kann grundsätzlich jedes netzwerkfähige Gerät in eine Überwachung aufgenommen werden. Typische Aufgaben sind die Überwachung von Netzwerkkomponenten, die Fernsteuerung und Fernkonfiguration sowie die Fehlererkennung und Fehlerbenachrichtigung.

SNMP ist wichtig, weil es einfach, modular und vielseitig ist. Deshalb hat es sich als Standard im Netzwerkmanagement etabliert und wird von vielen Managementprogrammen und Endgeräten unterstützt.

Kommunikation zwischen Manager und Agent

Zur Überwachung werden Agenten eingesetzt. Ein Agent ist ein Programm oder eine entsprechende Hardware auf dem überwachten Gerät. Er erfasst den Zustand des Geräts, kann Einstellungen vornehmen und Aktionen auslösen. Die zentrale Managementstation kommuniziert über SNMP mit diesen Agenten.

SNMP kennt mehrere Pakettypen. Mit GET-REQUEST fordert der Manager einen Management-Datensatz an. GETNEXT-REQUEST ruft den nachfolgenden Datensatz ab und dient zum Durchlaufen von Tabellen. GETBULK gibt es ab SNMPv2; damit kann eine angegebene Anzahl von Datensätzen auf einmal abgerufen werden, ähnlich wie mit mehreren GETNEXT-REQUESTs. SET-REQUEST verändert einen oder mehrere Datensätze eines Netzelements, etwa bei einer Konfiguration. GET-RESPONSE ist die Antwort auf vorherige Anfragen. TRAP ist eine unaufgeforderte Nachricht eines Agenten an den Manager, wenn ein Ereignis eingetreten ist. INFORM-REQUEST ist ähnlich wie ein Trap aufgebaut, wird aber vom Empfänger quittiert.

Die drei GET-Pakete werden vom Manager an einen Agenten gesendet, um Daten anzufordern. Der Agent antwortet mit GET-RESPONSE, entweder mit den gewünschten Daten oder mit einer Fehlermeldung. Bei SET-REQUEST kann der Manager Werte beim Agenten ändern; auch hier bestätigt der Agent mit GET-RESPONSE. Erkennt der Agent selbst einen Fehler, kann er ihn mit einem TRAP melden. Ein TRAP wird nicht bestätigt, daher weiß der Agent nicht sicher, ob die Meldung angekommen ist.

Damit die Netzwerkbelastung gering bleibt, verwendet SNMP das verbindungslose Protokoll UDP. Requests und Responses zwischen Agent und Manager laufen über Port 161. Für TRAP-Meldungen ist Port 162 vorgesehen.

Datenbasis und Paketaufbau

Zum SNMP-basierten Management gehört neben dem Protokoll auch die Repräsentation der Daten im Netzwerkgerät. Diese Datenbasis heißt Management Information Base, kurz MIB. Sie beschreibt, welche verwaltbaren Informationen und Werte ein Gerät bereitstellt.

SNMP-Pakete werden mit ASN.1 beschrieben; für den Transport im Netzwerk wird die Kodierung Basic Encoding Rules, kurz BER, verwendet. Die meisten SNMP-Pakete sind ähnlich aufgebaut. Bei SNMPv1 bestehen Nicht-Trap-Pakete aus SNMP-Paket-Header, PDU-Header und PDU-Body. Im SNMP-Paket-Header stehen die Versionsnummer, also SNMPv1, SNMPv2 oder SNMPv3, und der Community Name. Communities dienen zur Vergabe von Zugriffsrechten. Häufig wurden standardmäßig „public“ für lesenden Zugriff und „private“ für Schreib-/Lesezugriff verwendet. Diese Namen sollten geändert werden, weil sie bekannt sind; die Sicherheit steigt dadurch aber nur begrenzt, da Community Names im Klartext übertragen werden.

Im PDU-Header von Nicht-Trap-Paketen stehen unter anderem der Pakettyp, die Request ID, der Fehlerstatus und der Fehlerindex. Die Request ID ist bei Anfrage und Antwort identisch, damit mehrere Anfragen und ihre Antworten richtig zugeordnet werden können. Fehlerstatus und Fehlerindex erklären bei Antwortpaketen, warum eine Anfrage nicht bearbeitet werden konnte. Ohne Fehler haben beide Felder den Wert Null. Bei SNMPv1 sind unter anderem folgende Fehlerstatus möglich: kein Fehler, Paket zu groß zum Versenden, OID wird nicht unterstützt, falscher Datentyp oder Wert, nur Lesezugriff und unbekannter Generierungsfehler.

Im PDU-Body stehen die eigentlichen Werte. Jeder Wert wird in einer Variable Binding übertragen. Eine Variable Binding besteht aus einer OID, also einer Objektkennung, und dem zugehörigen Wert. Es gibt keine feste Vorgabe, wie viele Variable Bindings ein PDU-Body enthalten darf. Werden zu viele Werte abgefragt und das Antwortpaket wird zu groß, kann eine Fehlermeldung zurückkommen.

Trap-Pakete

Trap-Pakete unterscheiden sich im PDU-Header teilweise von anderen SNMP-Paketen. Sie enthalten den Pakettyp „Trap“, die OID des Geräts, das den Trap erzeugt hat, die IP-Adresse des Absenders, eine allgemeine TrapID, eine firmenspezifische TrapID und den Zeitpunkt des Trap-Ereignisses.

Die IP-Adresse und die herstellerspezifische OID, etwa aus dem Bereich 1.3.6.1.4.1.*, helfen zu erkennen, von welchem Gerät die Meldung stammt. Das ist besonders wichtig bei firmenspezifischen Traps, die nur für bestimmte Gerätetypen gelten.

Es gibt sieben allgemeine TrapIDs: Kaltstart oder coldStart mit Wert 0, Warmstart oder warmStart mit Wert 1, Link Down oder linkDown mit Wert 2, Link Up oder linkUp mit Wert 3, Authentifizierungsfehler oder authenticationFailure mit Wert 4, EGP-Nachbar verloren oder egpNeighborLoss mit Wert 5 und firmenspezifisch oder enterpriseSpecific mit Wert 6. Wenn enterpriseSpecific angegeben ist, wird die konkrete firmenspezifische TrapID im folgenden Feld übertragen.

Da Trap-Pakete in anderer Reihenfolge eintreffen können, als sie gesendet wurden, enthalten sie zusätzlich eine Zeitangabe. Sie gibt auf Hundertstelsekunden genau an, wie lange der SNMP-Agent gelaufen ist, bis das Ereignis eintrat. So lassen sich Trap-Ereignisse zeitlich richtig ordnen. Bei Traps können auch keine Variable Bindings mitgesendet werden, wenn die TrapID als Information ausreicht.

Versionen und Entwicklung

SNMP Version 1 wurde 1988 in mehreren RFCs definiert: RFC 1155 zur Struktur und Identifikation von Managementinformationen, RFC 1156 zur Management Information Base und RFC 1157 zum Simple Network Management Protocol. Das Hauptproblem von SNMPv1 ist die unzureichende Sicherheit, besonders die unverschlüsselte Übertragung des Passwortes beziehungsweise Community-Namens.

1992 wurden drei RFCs zu Secure SNMP, auch SNMPsec, veröffentlicht: RFC 1351, RFC 1352 und RFC 1353. Diese Version sollte Sicherheitsfragen behandeln, wurde aber nie eingeführt und durch SNMPv2 ersetzt.

1993 veröffentlichte die IETF Party-Based SNMP Version 2, kurz SNMPv2p. Diese Version verbesserte SNMPv1 bei Sicherheit und Vertraulichkeit, verschlüsselte den Community-String, ermöglichte Kommunikation zwischen verschiedenen Managern und führte GetBulk ein. Sie wird heute nicht mehr verwendet.

Bei User-Based SNMP Version 2, kurz SNMPv2u, sollte die Sicherheit durch Benutzernamen erhöht werden. Auch diese Version wird heute nicht mehr verwendet.

Community-Based SNMP Version 2, kurz SNMPv2c, ist bei der Sicherheit auf dem Stand von SNMPv1, enthält aber zusätzliche Funktionen aus SNMPv2p. Tabellen können mit GetBulk auf einmal geholt werden, und Kommunikation zwischen verschiedenen Managern ist möglich. SNMPv2c hat sich durchgesetzt; wenn heute von SNMPv2 gesprochen wird, ist meist diese Version gemeint.

SNMPv3 ist die aktuelle Version. Sie wurde im Dezember 2002 durch RFC 3410 bis RFC 3418 spezifiziert. Da SNMPv1 und SNMPv2c fast keine Sicherheitsmechanismen bieten, wurden in SNMPv3 die Sicherheitsmechanismen deutlich ausgebaut. Dazu gehören unter anderem das User-based Security Model, kurz USM, und das View-based Access Control Model, kurz VACM. Die höhere Komplexität, zum Beispiel bei der Schlüsselverwaltung, führte aber dazu, dass SNMPv3 weniger verbreitet ist als SNMPv2.

Sicherheitsprobleme und Schutzmaßnahmen

Ein großer Nachteil von SNMP Version 1 bis 2c ist die fehlende Sicherheit. Diese Versionen unterstützen keine Anmeldung mit Benutzername und Kennwort, sondern verwenden Communities. Communities sind einfache Namen wie „PUBLIC“ für nur lesenden Zugriff oder „PRIVATE“ für Schreibzugriff. Sie wirken wie vorher vereinbarte Schlüssel, sogenannte Pre-shared Keys, werden aber mit der Anfrage übertragen.

Das Problem ist, dass SNMP-Pakete nicht verschlüsselt sind. Auch lange und komplizierte Community-Namen helfen daher nur begrenzt, weil Angreifer den Netzwerkverkehr abhören, also „sniffen“, können. Mit dem passenden Programm kann ein Nutzer im Netzwerk Systeminformationen auslesen oder sogar Werte verändern, wenn die Community entsprechende Rechte hat.

Eine Schutzmöglichkeit ist „Allowed Host“: Dabei werden die IP-Adressen eingeschränkt, von denen aus ein SNMP-System kontaktiert werden darf. Das ist ein einfacher Schutz, kann aber möglicherweise durch ARP-Spoofing oder IP-Spoofing umgangen werden. Eine weitere Maßnahme ist Management-Schutz durch ein eigenes Netzwerk für die Überwachung. Seit Anfang der 1990er Jahre ist es üblich, Nutzdaten-Verkehr und Management-Verkehr zu trennen. Diese Trennung heißt Out-of-Band; Kommunikation über das normale Datennetz heißt Inband-Kommunikation.

Außerdem kann man auf bestimmten Systemen nur „Read Only“ erlauben, sodass Überwachungsgeräte nur lesen dürfen. Das wird häufig bei Routern verwendet. SNMPv3 bietet unter anderem Verschlüsselung und bessere Authentifizierung, wird aber wegen der höheren Komplexität oft nicht genutzt.