📚SNMP-Grundlagen

Wer spricht mit wem, über welchen Port, mit welcher Version? Die Bausteine, die man für alles Weitere braucht.

🎬Abläufe zum Durchklicken

Der Manager fragt gezielt einzelne Instanzen ab – eine Anfrage, eine Antwort.

Schritt 0 / 2

Mit „Weiter“ startet der Ablauf.

📎 Quellen: RFC 3416 – Protokolloperationen (PDUs) · RFC 3413 – SNMP-Anwendungen · snmpcmd(1)

🧩Rollen nach RFC 3411/3413

SNMPv3 beschreibt jede SNMP-Einheit als Engine plus Anwendungen. „Manager“ und „Agent“ sind nur übliche Kombinationen – ein Linux-Server mit snmpd ist Agent, derselbe Server mit snmptrapd ist zusätzlich Notification Receiver.

SNMP-Einheit
├─ SNMP-Engine  (snmpEngineID – weltweit eindeutig)
│  ├─ Dispatcher              verteilt Nachrichten und PDUs
│  ├─ Message Processing      v1 · v2c · v3
│  ├─ Security Subsystem      Community-Modell · USM
│  └─ Access Control          VACM
└─ Anwendungen
   ├─ Command Generator       snmpget, snmpwalk      (Manager)
   ├─ Command Responder       snmpd                  (Agent)
   ├─ Notification Originator snmpd, snmptrap        (Agent)
   ├─ Notification Receiver   snmptrapd              (Manager)
   └─ Proxy Forwarder

📎 Quellen: RFC 3411 – SNMP-Architektur · RFC 3413 – SNMP-Anwendungen

🔌Transport: UDP 161 und 162

📥 UDP 161 – hier lauscht der Agent auf Get/GetNext/GetBulk/Set. Die Antwort geht an den Quellport der Anfrage.
🔔 UDP 162 – hier lauscht der Notification Receiver (snmptrapd) auf Traps und Informs.
📦 Jede Nachricht ist ein UDP-Datagramm. Jede SNMP-Einheit muss Nachrichten bis mindestens 484 Oktette annehmen; passt die Antwort nicht in die zulässige Größe, meldet der Agent tooBig.
🔁 UDP bestätigt nichts: Der Manager wiederholt nach einem Timeout selbst (Net-SNMP: -t 1 Sekunde, -r 5 Wiederholungen als Standard).
🔒 Weitere Transporte (TLS/DTLS, SSH) sind definiert, in der Praxis dominiert UDP.

Merksatz für Firewalls

Abfragen: Manager → Agent udp/161. Notifications: Agent → Manager udp/162. Wer nur eine Richtung öffnet, bekommt entweder Timeouts oder keine Traps.

📎 Quellen: RFC 3417 – Transport-Mappings · RFC 3416 – Protokolloperationen (PDUs)

🆚SNMPv1, v2c und v3 im Vergleich

	SNMPv1	SNMPv2c	SNMPv3
Standard	RFC 1157 (1990)	RFC 1901 (Rahmen), PDUs aus RFC 3416	RFC 3411–3418 (2002), Internet Standard STD 62
version-Feld	0	1	3
Sicherheit	Community-String im Klartext	Community-String im Klartext	USM: Benutzer, HMAC-Authentisierung, Verschlüsselung (DES/AES)
Zugriffskontrolle	je Community (implementierungsabhängig)	je Community (implementierungsabhängig)	VACM: Gruppen, Views, Kontexte (RFC 3415)
GetBulk	–	✔	✔
Inform (bestätigte Meldung)	–	✔	✔
Counter64	–	✔	✔
Fehler bei unbekannter OID	ganze PDU scheitert: noSuchName + error-index	je Varbind: noSuchObject / noSuchInstance / endOfMibView	wie v2c
Einsatz heute	nur Altgeräte	verbreitet, nur in vertrauenswürdigen Netzen	empfohlen, authPriv

📎 Quellen: RFC 1157 – SNMPv1 · RFC 1901 – Community-based SNMPv2 (v2c) · RFC 3416 – Protokolloperationen (PDUs) · RFC 3411 – SNMP-Architektur · RFC 3414 – User-based Security Model · RFC 3415 – View-based Access Control

🔑Community-String vs. USM – was ein Mitlesender sieht

Die Community ist das Passwort – und steht im Klartext in jedem Paket. Wer mitschneidet, kann sie wiederverwenden.

version

1 bzw. 3

👁️ lesbar & fälschbar

community

„beispiel-community“

👁️ lesbar & fälschbar

PDU-Typ, request-id

GetRequest, 4711

👁️ lesbar & fälschbar

OIDs

1.3.6.1.2.1.1.5.0

👁️ lesbar & fälschbar

Werte

„gw1.example.org“

👁️ lesbar & fälschbar

📎 Quellen: RFC 1157 – SNMPv1 · RFC 3414 – User-based Security Model · RFC 3826 – AES-CFB-128 für USM

📨Die PDU-Typen

Tag	PDU	Richtung	Zweck	Versionen
0xA0	GetRequest	Manager → Agent	Werte genau dieser Instanzen lesen	v1, v2c, v3
0xA1	GetNextRequest	Manager → Agent	lexikografisch nächste Instanz lesen (Basis von snmpwalk)	v1, v2c, v3
0xA2	Response	Agent → Manager (auch Empfänger → Absender eines Inform)	Antwort mit gleicher request-id	v1 (GetResponse), v2c, v3
0xA3	SetRequest	Manager → Agent	Werte schreiben – alles oder nichts	v1, v2c, v3
0xA4	Trap (v1)	Agent → Manager	altes Trap-Format mit enterprise, agent-addr, generic-/specific-trap	nur v1
0xA5	GetBulkRequest	Manager → Agent	viele Nachfolger auf einmal (non-repeaters, max-repetitions)	v2c, v3
0xA6	InformRequest	Agent/Manager → Manager	Meldung mit Bestätigung	v2c, v3
0xA7	SNMPv2-Trap	Agent → Manager	Meldung ohne Bestätigung; Varbinds 1 und 2: sysUpTime.0, snmpTrapOID.0	v2c, v3
0xA8	Report	Agent → Manager	Fehler/Discovery der SNMPv3-Engine (z. B. usmStatsUnknownEngineIDs)	v3

Alle v2-PDUs außer GetBulk haben denselben Aufbau: request-id, error-status, error-index und die Liste der Variable Bindings (OID + Wert). Bei GetBulk stehen an Stelle der beiden Fehlerfelder non-repeaters und max-repetitions.

📎 Quellen: RFC 3416 – Protokolloperationen (PDUs) · RFC 1157 – SNMPv1