# SNMP Deep Dive: Netzwerk-Monitoring für das Enterprise

TL;DR / Management Summary Das SNMP (Simple Network Management Protocol) ist der kleinste gemeinsame Nenner für das Monitoring von Hardware. Ob Switch, USV (UPS) oder Drucker – fast jedes IP-fähige Gerät spricht SNMP. Ein Senior Admin nutzt dieses Protokoll, um Port-Auslastungen, CPU-Temperaturen und Fehlermeldungen (Traps) in Echtzeit zu erfassen. Sicherheit ist dabei das A und O: Wir meiden das unsichere SNMP v2c und setzen konsequent auf SNMP v3 mit Verschlüsselung und Authentifizierung.

# 1. Konzepte & Versionen

Vom ‘Klartext’ zur ‘Verschlüsselung’.

SNMP v1/v2c: Nutzt eine “Community String” (Passwort) im Klartext. (Nur in isolierten Management-VLANs sicher).
SNMP v3 (Empfohlen): Unterstützt Benutzer-Accounts, Verschlüsselung (AES) und Authentifizierung (SHA).
MIB (Management Information Base): Die “Übersetzungstabelle” des Herstellers.
OID (Object Identifier): Die exakte Adresse eines Datenpunkts (z.B. .1.3.6.1.2.1.1.3.0 für die Uptime).

# 2. Einrichtung in der Praxis

Daten abfragen.

# Schritt 1: Gerät vorbereiten (Beispiel OPNsense)

Services -> SNMP.

Enable: Aktivieren.
Version: v3.
User/Password: Erstellen Sie einen Monitoring-User.
Bind Interface: Nur am LAN oder Management-Interface lauschen.

# Schritt 2: Abfrage vom Monitoring-Server (Shell)

Nutzen Sie snmpwalk, um alle Werte eines Geräts zu sehen:

snmpwalk -v3 -u mon_user -l authPriv -a SHA -A pass1 -x AES -X pass2 10.0.1.1

# 3. Deep Dive: SNMP Traps

Wenn das Gerät ‘schreit’.

Normalerweise fragt das Monitoring-System die Daten ab (Polling).

Trap: Das Gerät sendet von sich aus eine Nachricht, sobald ein Ereignis eintritt (z.B. “Port 5 Down” oder “Stromausfall”).
Vorteil: Sofortige Reaktion ohne Wartezeit auf den nächsten Polling-Zyklus.
Wichtig: Der Monitoring-Server muss einen Trap Receiver (Dienst) laufen haben.

# 4. Day-2 Operations: MIB Management

Kryptische Zahlen in Text verwandeln.

Ohne MIB-Dateien sieht ein Log so aus: 1.3.6.1.4.1.9.9.48.1.1.1.5.1 = 45000.

Aktion: Laden Sie die MIB-Dateien Ihres Herstellers (Cisco, Dell, APC) in Ihr Monitoring-System (Zabbix/Checkmk).
Ergebnis: ciscoMemoryPoolUsed = 45000.

# 5. Troubleshooting & “War Stories”

Wenn der Graph eine Null-Linie zeigt.

# Top 3 Fehlerbilder

Symptom: Timeout bei der Abfrage.
- Ursache: Firewall blockiert UDP Port 161 (Polling) oder UDP Port 162 (Traps).
- Lösung: OPNsense Regeln prüfen (Artikel 553).
Symptom: “Unknown Object Identifier”.
- Ursache: Die passende MIB ist auf dem Monitoring-Server nicht installiert.
Symptom: Hohe CPU-Last am Switch während des Scans.
- Ursache: Zu viele parallele Abfragen oder zu kurze Intervalle.
- Fix: Intervall auf 60-300 Sekunden erhöhen.

# “War Story”: Der “SNMP-DDoS”

Ein Admin wollte “Echtzeit-Monitoring” und fragte 48 Switch-Ports alle 1 Sekunde via SNMP ab. Das Ergebnis: Die CPU des Switches stieg auf 100%. Da der Switch-Kernel die Management-Abfragen priorisierte, kam er nicht mehr dazu, die STP-Heartbeats (Artikel 729) zu verarbeiten. Die Katastrophe: Der Cluster dachte, die Pfade seien tot und löste eine STP-Neuwahl aus, was das gesamte Netzwerk für 30 Sekunden lahmlegte. Lehre: SNMP ist ein Management-Protokoll, kein Hochleistungs-Datenstrom. Nutzen Sie für Sekunden-Intervalle lieber Streaming Telemetry (falls Hardware-Support vorhanden) oder halten Sie die Intervalle moderat.

# 6. Monitoring & Reporting

Anomalie-Erkennung.

# Wichtige OIDs für das RZ

Uptime: 1.3.6.1.2.1.1.3.0.
CPU Load: Herstellerspezifisch.
Traffic In/Out: 1.3.6.1.2.1.2.2.1.10 (ifInOctets).

# 7. Fazit & Empfehlung

SNMP ist das Rückgrat der Hardware-Observability.

Empfehlung: Nutzen Sie SNMP v3 konsequent für alle Geräte.
Wichtig: Deaktivieren Sie die “Public” Community-Strings. Viele Geräte werden mit public (Read) und private (Write) ausgeliefert – eine offene Tür für Angreifer.

# Anhang: Cheatsheet (SNMP Tools)

Tool	Zweck	Plattform
`snmpget`	Einzelnen Wert abfragen	Linux
`snmpwalk`	Ganzen Baum auslesen	Linux
MIB Browser	Grafische OID Suche	Windows/macOS
iReasoning	Bekannter MIB Browser	Alle