Was ist SNMP? MIB, OID, Traps und SNMPv3

Kaum ein Satz fällt in einem Netz so oft und hilft so wenig wie „das Internet ist langsam“. Welcher Standort, welche Uhrzeit, wie langsam: Ohne diese drei Antworten ist Langsamkeit keine Störungsmeldung, sondern eine Meinung. SNMP (Simple Network Management Protocol) ist das Protokoll, das Netzwerkgeräten genau diese Fragen regelmäßig stellt und die Antworten in Messwerte verwandelt.

Am schnellsten versteht man es über eine adressierbare Brandmeldeanlage. Die Zentrale fragt jeden Melder auf ihrer Ringleitung einzeln per Adresse ab, jedes Mal dasselbe: „Nummer drei, Status?“ Der Melder antwortet, die Zentrale notiert es und geht weiter. Bei echtem Rauch wartet der Melder aber nicht, bis er dran ist; er meldet sich selbst. Diese zwei Verhaltensweisen, regelmäßige Abfrage und unaufgeforderte Meldung, erklären die ganze Architektur von SNMP.

Dieser Artikel ist der zweite im Leitfaden Monitoring und Alarme, nach Was ist Syslog? Syslog liefert Sätze, SNMP Zahlen. Befehle, Mitschnitte und Ausgaben stammen aus dem Labor des Autors und sind unverändert.

Was ist SNMP, und welches Problem löst es?

SNMP ist ein Protokoll der Anwendungsschicht, mit dem Zustandsinformationen von Netzwerkgeräten gesammelt werden. Wie viele Pakete ein Switch verworfen hat, wie voll eine Leitung ist, wie ausgelastet eine CPU: Das fragen Sie mit diesem Protokoll. Die Antwort ist kein Satz, sondern eine Zahl, und weil sie eine Zahl ist, lässt sie sich speichern, vergleichen und grafisch darstellen. Das eigentliche Problem ist sprachlich: „Das Internet ist langsam“ ist eine Meinung, keine Messung. SNMP macht aus der Meinung eine Zahl.

Eine Unterscheidung vorab: SNMP misst, wie voll eine Leitung ist, nicht, ob ein Gerät erreichbar ist. Dafür nutzen Monitoring-Systeme Ping. Auch Benutzer, deren Signal schwach ist, weil ein Access Point ausgefallen ist, sagen „das Internet ist langsam“, obwohl die Leitung gar nicht voll ist. SNMP sagt Auslastung, Ping Erreichbarkeit; mit beidem ist die Beschwerde keine Streitfrage mehr.

SNMP existiert, weil Menschen nicht skalieren. Zehn Standorte mit je einem Router, einer Firewall und zwei Switches sind 40 Geräte; je vier Werte einmal täglich von Hand abzulesen sind 160 Ablesungen. Das Entscheidende ist aber nicht Aufwand, sondern Kontinuität: Störungen passieren, wenn niemand hinsieht. Wann brauchen Sie es nicht? Bei einem Switch und wenigen Rechnern kosten Server, Software und Dashboard mehr, als sie bringen. Die Schwelle ist überschritten bei mehreren Standorten, einer nach Kapazität bezahlten Leitung oder wenn Sie von Ausfällen durch Benutzer erfahren.

Wie SNMP funktioniert: Manager, Agent und Abfrage

SNMP hat zwei Seiten: Der Manager fragt, der Agent antwortet. Der Manager erzeugt die Abfragen, in der Praxis ein Monitoring-Server. Der Agent ist Software auf dem überwachten Gerät, ob Switch, Router, Firewall, Server, Drucker oder USV. Das Verhältnis ist bewusst asymmetrisch: Der Agent baut keine Verbindungen auf, er hört zu. Das verkleinert die Angriffsfläche, hat aber einen Preis, den der Mechanismus weiter unten begleicht.

Abfragen laufen über UDP, und das ist Notwendigkeit, keine Vorliebe. Eine Statusabfrage ist ein einzelner Schuss: Kommt keine Antwort, ist erneutes Fragen billiger als verlorene Pakete zu retten. Und Hunderte Geräte müssen in Sekunden befragt werden.

Die Abfrage durch den Manager heißt Polling und geht an UDP-Port 161. Der Server fragt jedes Gerät im gewählten Intervall, typischerweise alle fünf Minuten. Eine Messung liefert eine Zahl, zwei aufeinanderfolgende liefern eine Differenz. Der Byte-Zähler einer Schnittstelle wächst nur und sagt allein nichts; die Differenz zweier Werte im Abstand von fünf Minuten geteilt durch die Zeit ergibt die Bandbreite pro Sekunde. Genau so entstand die Spitze zwischen 9 und 10 Uhr aus der Anekdote oben.

Was ist ein SNMP-Trap? Das Gerät meldet sich zuerst

Polling ist regelmäßig, und darin liegt seine Schwäche. Bei Abfragen alle fünf Minuten wird eine Leitung, die direkt nach einer Abfrage ausfällt, erst rund fünf Minuten später bemerkt. Ein Trap ist eine Meldung, die das Gerät ungefragt sendet, und sie kommt auf Port 162 an. An der Brandmeldeanlage ist das der Melder, der bei Rauch sofort selbst auslöst.

• Poll: Manager → Agent, Zielport 161. Der Manager fragt.
• Trap: Agent → Manager, Zielport 162. Das Gerät meldet.

161 und 162 sind also nicht „zwei SNMP-Ports“, sondern zwei Gesprächsrichtungen. Hört Ihr Server nicht auf 162, können Ihre Geräte jahrelang Meldungen senden, die nie ankommen.

Um zu sehen, was ein Trap auf der Leitung trägt, habe ich den Laborswitch absichtlich mit falschem Community-String abgefragt und auf 162 gelauscht. Alle drei Versuche erzeugten eine Meldung; hier eine, 67 Byte:

0000  30 41 02 01 01 04 06 70 75 62 6c 69 63 a7 34 02  0A.....public.4.
0010  01 02 02 01 00 02 01 00 30 29 30 0e 06 08 2b 06  ........0)0...+.
0020  01 02 01 01 03 00 43 02 5e ad 30 17 06 0a 2b 06  ......C.^.0...+.
0030  01 06 03 01 01 04 01 00 06 09 2b 06 01 06 03 01  ..........+.....
0040  01 05 05                                         ...

Erstens, das a7 im vierzehnten Byte. In der Anfrage weiter unten steht dort a0, in der Antwort a2. Die Gesprächsrichtung ist kein eigenes Feld, sondern im Pakettyp kodiert. Zweitens, die beiden Werte. Der erste, 1.3.6.1.2.1.1.3.0, ist die Betriebszeit des Geräts, also wann es passierte. Der zweite, 1.3.6.1.6.3.1.1.4.1.0, hat als Wert wieder eine Adresse: 1.3.6.1.6.3.1.1.5.5, „Authentifizierung fehlgeschlagen“. Die Art des Ereignisses ist kein Satz, sondern eine Nummer. Der Monitoring-Server sucht sie in seinem Katalog, statt Text zu zerlegen. Die Betriebszeiten der drei Meldungen, 24237, 24438 und 24637, liegen etwa zwei Sekunden auseinander: Das Gerät meldete jeden Versuch einzeln. Drittens, und am unangenehmsten, das siebte Byte: public steht auch hier. Der Community-String reist nicht nur in Ihren Abfragen im Klartext, sondern auch in den Meldungen, die das Gerät von sich aus sendet.

Ein sauberer Aufbau nutzt beides: Polling liefert Trends, Traps liefern Ereignisse.

Labor: Warum der Trap-Empfänger zuerst nichts hörte

Dieser Abschnitt steht nicht im türkischen Original. Bevor der Mitschnitt oben gelang, verließen die Meldungen den Switch und kamen beim Programm auf dem Windows-Arbeitsplatz nie an. Am Switch lag es nicht, sondern an der Windows-Firewall, und die naheliegende Lösung half nicht.

Windows bringt eine vorkonfigurierte eingehende Regel für SNMP-Traps mit. Sie einzuschalten scheint die Antwort. Hier ihre tatsächlichen Filter, mit PowerShell gelesen:

foreach ($n in 'SNMPTRAP-In-UDP','SNMPTRAP-In-UDP-NoScope') {
  $r = Get-NetFirewallRule -Name $n
  $a = $r | Get-NetFirewallApplicationFilter
  $s = $r | Get-NetFirewallServiceFilter
  $p = $r | Get-NetFirewallPortFilter
  "{0} | prog={1} | svc={2} | {3}/{4} | enabled={5}" -f $n, $a.Program, $s.Service, $p.Protocol, $p.LocalPort, $r.Enabled
}

SNMPTRAP-In-UDP | prog=%SystemRoot%\system32\snmptrap.exe | svc=SNMPTRAP | UDP/162 | enabled=False
SNMPTRAP-In-UDP-NoScope | prog=%SystemRoot%\system32\snmptrap.exe | svc=SNMPTRAP | UDP/162 | enabled=False

Lesen Sie die Mitte jeder Zeile. Die Regel öffnet nicht UDP 162, sondern UDP 162 für ein Programm und einen Dienst: Windows’ eigenes snmptrap.exe, das als Dienst SNMPTRAP läuft. Jeder andere Trap-Empfänger ist ein anderes Programm, die Regel greift für seinen Verkehr nie. Beide Regeln sind außerdem ab Werk deaktiviert.

Das zweite Hindernis war leiser. Auf dieser Maschine gab es eingehende Block-Regeln für den Interpreter, unter dem der Empfänger lief, und unter Windows gewinnt eine Block-Regel gegen eine Allow-Regel, gleich in welcher Reihenfolge sie angelegt wurden. Selbst eine korrekte Allow-Regel änderte nichts, bis die Block-Regeln abgeschaltet waren.

Die Prüfliste, wenn ein Windows-Trap-Empfänger schweigt:

1. Prüfen, ob die Traps das Gerät verlassen, mit einem Mitschnitt an der Schnittstelle des Empfängers.
2. Sich nicht auf die vorkonfigurierte SNMP-Trap-Regel verlassen, außer Sie nutzen Windows’ eigenen Trap-Dienst. Legen Sie eine eingehende Allow-Regel für UDP 162 an, gebunden an das Programm Ihres Empfängers.
3. Nach Block-Regeln suchen, die auf dieses Programm oder diesen Port passen; sie überstimmen Ihre Allow-Regel still.
4. Hinterher zurückbauen, wenn es ein Test war. Beim ersten Mal habe ich das versäumt; die Regeln blieben nach der Messung offen und mussten später geschlossen werden.

Was ist eine MIB? Der Katalog dessen, was ein Gerät weiß

Woher weiß der Server, dass 1.3.6.1.6.3.1.1.5.5 „Authentifizierung fehlgeschlagen“ heißt? Allgemeiner: Woher weiß der Manager, was er fragen soll, und der Agent, was gefragt wird? Beide brauchen ein gemeinsames Wörterbuch: die MIB.

Eine MIB (Management Information Base) ist der Standardkatalog der Informationen, die von einem Gerät abgefragt werden können. Sie enthält keine Daten, sondern sagt, wo Daten stehen, welchen Typ sie haben und was sie bedeuten. An der Brandmeldeanlage ist das die Melderliste aus der Inbetriebnahme: welches Stockwerk, welcher Raum, Rauch oder Wärme. Die Melderliste entspricht der MIB, die Nummer einer einzelnen Zeile der OID. Entscheidend ist, dass die MIB vorab vereinbart ist; deshalb kann ein Server Geräte verschiedener Hersteller dasselbe fragen.

Was ist eine OID? Eine Adresse im Katalog

Eine OID (Object Identifier) ist die Adresse einer Information in der MIB, eine punktgetrennte, hierarchische Zahlenfolge. Die Standardadresse der Systembeschreibung ist 1.3.6.1.2.1.1.1.0: 1.3.6.1 ist die Wurzel des Internet-Baums, 2.1 der Standard-Managementzweig, die nächste 1 die Systemgruppe, die folgende 1 das Beschreibungsobjekt, die 0 am Ende seine einzige Instanz.

1.3.6.1.2.1.1.1.0    Systembeschreibung
1.3.6.1.2.1.1.3.0    Betriebszeit
1.3.6.1.2.1.1.5.0    Systemname
1.3.6.1.2.1.1.6.0    Standort
1.3.6.1.2.1.2.1.0    Anzahl Schnittstellen

Die Abfrage von vier dieser Adressen am Laborswitch brachte zwei Ergebnisse, die in viele MIB-Erklärungen gehören. Die Anzahl der Schnittstellen war 119. Das Gerät hat 48 Ports; der Rest sind VLAN-Schnittstellen, Stack-Verbindungen und logische Schnittstellen. Die Zahl ist richtig, aber keine „Portanzahl“; was sie bedeutet, legt die Katalogdefinition fest, nicht Ihre Intuition. Und Systemname und Standort kamen leer zurück. Die Adressen existieren, das Gerät versteht die Frage, aber niemand hat sie ausgefüllt. Das ist sehr verbreitet, und das Ergebnis ist ein Dashboard voller namenloser Kästen.

Wo das Bild der Brandmeldeanlage bricht

Zweimal. Die Melderliste einer Anlage ist gebäudespezifisch, die MIB dagegen universell. Und die Ringleitung einer Brandmeldeanlage ist physisch getrennt, SNMP teilt das Netz mit Ihren Daten. Um eine Melderleitung abzuhören, muss man ins Gebäude; um SNMP mitzuhören, genügt es, im Netz zu sein. Genau darum geht es im nächsten Abschnitt.

SNMP-Versionen: v1, v2c und v3

Es gibt drei Versionen, und der Unterschied ist keine Funktionsliste, sondern die Antwort auf die Frage, wer fragen darf. v1 ist das Original und heute durch nichts mehr gerechtfertigt. v2c ist verbreitet, mit besseren Datentypen und Sammelabfragen, steht bei der Authentifizierung aber dort, wo v1 steht. v3 fügt die Sicherheitsschicht hinzu.

Ein Community-String ist der Zugangstext in v1 und v2c, und entgegen verbreiteter Annahme verhält er sich nicht wie ein Passwort. Passwortähnlich ist nur, dass man ohne ihn keine Antwort bekommt. Alles andere fehlt: Er wird unverschlüsselt gesendet, mit jeder Abfrage erneut, und kommt in jeder Antwort zurück. Und im Feld ist er meist ein gemeinsamer Wert auf allen Geräten.

Labor: den Community-String im Paket sehen

Die Standardantwort im Feld lautet: „Eine Nur-Lese-Community ist harmlos, sie kann ja nur lesen.“ Ich habe an einem verwalteten Switch eine Nur-Lese-Community eingerichtet und die Anfrage von Hand gebaut, weil es nicht um die Antwort, sondern um die Bytes im Paket geht. Die Abfrage der Schnittstellenanzahl, 43 Byte ohne Header:

0000  30 29 02 01 01 04 06 70 75 62 6c 69 63 a0 1c 02  0).....public...
0010  04 64 c8 5a 35 02 01 00 02 01 00 30 0e 30 0c 06  .d.Z5......0.0..
0020  08 2b 06 01 02 01 02 01 00 05 00                 .+.........

Ab dem siebten Byte steht public, einfach als Klartext; die Folge 2b 06 01 02 01 02 01 00 in der Mitte ist die gefragte Adresse. Die Antwort des Geräts:

0000  30 2a 02 01 01 04 06 70 75 62 6c 69 63 a2 1d 02  0*.....public...
0010  04 64 c8 5a 35 02 01 00 02 01 00 30 0f 30 0d 06  .d.Z5......0.0..
0020  08 2b 06 01 02 01 02 01 00 02 01 77              .+.........w

Das abschließende 02 01 77 ist die erwartete Ganzzahl, 0x77, also 119. Lehrreich ist wieder Byte sieben: public steht auch in der Antwort im Klartext. Wer mithört, muss nicht einmal eine Abfrage abpassen. Unangenehmer war eine weitere Messung: Auf die Frage nach der Systembeschreibung lieferte das Gerät den vollständigen Modellnamen und die Firmware-Version im Klartext. Ich maskiere sie hier, aus genau dem Grund, der auch Sie interessieren sollte: Für einen Angreifer sind Modell und Version die erste Angabe bei der Wahl der passenden Schwachstelle. Ein offener Community-String gibt nicht nur „Lesen“; er gibt die Identität des Geräts preis.

Dieselbe Abfrage mit SNMPv3

SNMPv3 schafft den Community-String ab und ersetzt ihn durch Benutzername, Authentifizierung und Verschlüsselung. Ich habe am selben Switch einen v3-Benutzer angelegt und dieselbe Frage gestellt. Der Ablauf besteht aus mehr als „Verschlüsselung an“:

1. Discovery. Der Client sendet zuerst eine unauthentifizierte Anfrage; das Gerät meldet Engine-ID, Bootzähler und Betriebszeit. Ehrlich gesagt die weiche Stelle von v3: Ein Mithörer erfährt zumindest, dass das Gerät existiert und wie lange es läuft.
2. Schlüsselableitung. Das Passwort wird nicht direkt genutzt, sondern gestreckt, gehasht, mit der Engine-ID des Geräts kombiniert und erneut gehasht. Ergebnis: ein Schlüssel, der nur für dieses Gerät gilt.
3. Signieren und Verschlüsseln. Der Inhalt wird mit einem abgeleiteten Schlüssel verschlüsselt, die Nachricht mit einem anderen signiert.

Der Authentifizierungsschlüssel, den mein Client ableitete:

99e4f6a753f99ab77f6784608e28d89dbab58731

Der Wert, den der Switch für diesen Benutzer in seiner Konfiguration speicherte, war identisch. Beide Seiten kamen unabhängig zum selben Schlüssel. Das ist das Design in einer Zeile: Das Passwort reist nie über das Netz und wird auf dem Gerät nicht gespeichert. Die v3-Anfrage, 131 Byte, der entscheidende Teil:

0030  0b 73 65 72 63 65 69 7a 6c 65 6d 65 04 0c 4e ed  .serceizleme..N.
0040  aa 9d d8 f1 f4 a2 c9 96 73 c9 04 08 c0 f2 fa ed  ........s.......
0050  c9 bc a5 0a 04 2d a8 8b 18 0e 55 9e 7d 09 14 3f  .....-....U.}..?
0060  a2 38 38 c6 b2 21 1f 96 b0 4d a4 fd 3b 4a 3e 86  .88..!...M..;J>.

Der Benutzername steht im Klartext, serceizleme, und das ist gewollt: Die Gegenseite muss wissen, mit wessen Schlüssel sie prüft. v3 verbirgt nicht den Benutzernamen, sondern das Passwort; ich habe programmatisch geprüft, dass keines der beiden Passwörter in irgendeiner Form im Paket vorkommt. Alles ab Offset 0x50 ist verschlüsselter Inhalt; die Adresse, die wir in der v2c-Anfrage lesen konnten, ist nicht zu sehen. Die Antwort kam genauso, 173 Byte ohne lesbares Feld.

Der Unterschied zwischen v2c und v3 ist nicht „Verschlüsselung kam dazu“, sondern dass sich geändert hat, was als Identität gilt. In v2c ist Identität ein Text und damit kopierbar. In v3 ist sie ein an das Gerät gebundener Schlüssel; kopiert funktioniert er nirgendwo sonst.

Syslog und SNMP: Messen gegen Erzählen

v3 schließt die Sicherheitsseite. Eine Klasse von Fragen beantwortet SNMP aber nie: Eine Zahl erzählt keine Geschichte. SNMP sagt, die CPU liegt bei 80 %; welche Anmeldung scheiterte, sagt es nicht. Eine Syslog-Zeile desselben Laborswitches:

<189> Aug 18 12:09:19 192.168.1.2-1 TRAPMGR[trapTask]: traputil.c(735) 221 %% Link Down: Vl1

Das <189> ist das Prioritätsfeld aus Was ist Syslog?; wichtig ist hier, dass der Rest ein Satz ist. Traps sind von Maschinen zuordenbar: Bei einer bestimmten OID eine Aktion auszulösen ist einfach. Syslog ist für Menschen lesbar: Welche Schnittstelle, wann, in welchem Prozess, steht im Satz. Ein sauberer Aufbau sammelt beides. Der häufigste Fehler: beides einrichten und herrenlos lassen. Meldungen gehen an alle, niemand schaut hin, und ein Jahr später ist der Alarm Hintergrundrauschen.

SNMP in der Praxis: Reihenfolge und Fehlersuche

1. Erst den Zugang beschränken, dann das Protokoll einschalten. SNMP sollte nur aus dem Managementnetz erreichbar sein; der richtige Ort dafür ist das Netzdesign, siehe Was ist ein VLAN? Prüfen Sie zusätzlich, dass 161 und 162 am Übergang nach außen geschlossen sind.
2. v3 nutzen, v2c nur für den Übergang.
3. Nur lesend bleiben. Schreibrechte nicht über SNMP vergeben; Geräte über eine verschlüsselte Managementsitzung konfigurieren.
4. Systemname und Standort ausfüllen.
5. Die Geräteuhr prüfen. Eine Grafik ist nur so gut wie ihre Zeitachse.

Ob es funktioniert, prüfen Sie in drei Schritten: eine einzelne Abfrage senden (entscheidend ist, dass eine Antwort kommt), die Antwort auf Plausibilität prüfen (119 Schnittstellen sind mehr als Ports, kein Fehler) und bestätigen, dass Sie auf 162 hören, bei Windows mit der Prüfliste oben.

Häufige Fehler. Ein falscher Community-String wird still verworfen: Ich habe es gemessen, keine Antwort, kein Fehler. „String falsch“, „Gerät aus“, „Firewall dazwischen“ und „SNMP nie eingeschaltet“ sehen von der fragenden Seite gleich aus. Der Trap-Mitschnitt zeigt aber: still nur zur falschen Seite. Das Gerät meldet den Fehlversuch an den Monitoring-Server; sichtbar ist er nur für den, der auf 162 hört, das greifbarste Sicherheitsargument für Trap-Sammlung. Ab Werk aus heißt nicht sicher: Mein erster Versuch mit dem bekanntesten Standard-String bekam keine Antwort, SNMP war ab Werk aus; das Risiko liegt im String, den Sie beim Einschalten wählen, und darin, wie v2c ihn transportiert. Derselbe String auf allen Geräten: Ein Mitschnitt öffnet das ganze Inventar. Fünf Minuten für jede Kennzahl: Für Kapazitätstrends gut, doch eine Spitze von Sekunden verschwindet im Mittelwert. Traps ohne Zuständigen: Eine Meldung gehört zu einer Person oder Rufbereitschaft, nicht in ein Postfach.

Fazit

SNMP passt in zwei Sätze. Der Manager fragt in regelmäßigen Abständen, der Agent antwortet. Im Notfall meldet sich der Agent zuerst. Alles andere ist Detail: Die MIB legt fest, worüber gesprochen wird, die OID, welche Adresse Sie fragen, und die Version, wer fragen darf.

Der eigentliche Gewinn ist nicht technisch. In einem überwachten Netz löst „das Internet ist langsam“ keinen Streit aus; jemand öffnet eine Grafik, findet das Zeitfenster und sucht die Ursache. Sobald eine Meinung durch eine Messung ersetzt ist, wird das Problem lösbar, noch bevor es gelöst ist.