Simple Network Management Protocol (SNMP) is a standard network management protocol that enables central monitoring and configuration of enterprise devices such as routers, switches, servers, and firewalls through a manager-agent model using Management Information Bases (MIBs) and Object Identifiers (OIDs). SNMP supports both proactive polling on UDP port 161 and reactive trap notifications on UDP port 162 to detect events such as link failures, but security depends critically on the protocol version used, with SNMPv1 and SNMPv2c transmitting community strings in plain text while SNMPv3 adds authentication and encryption per RFC 3411. Proper implementation requires managing agent configuration, avoiding default credentials, using SNMPv3 with appropriate access controls, and maintaining correct MIBs to prevent blind spots, reduce detection time, and protect against reconnaissance and tampering attacks.
So funktioniert SNMP
SNMP verwendet ein Manager-Agent-Modell. Der Agent läuft auf einem verwalteten Gerät und stellt dessen Daten als Objekte bereit, die durch Objektkennungen (OIDs) identifiziert und in einer Management Information Base (MIB) organisiert sind.
- Definition der Daten: Jede MIB beschreibt die Objekte, die ein Gerät melden kann, wie beispielsweise Schnittstellenzähler oder CPU-Auslastung, und weist jedem Objekt eine eindeutige OID in einer Baumstruktur zu.
- Anfrage senden: Der Manager sendet eine Nachricht an den Agenten über den UDP-Port 161. Eine „Get“-Anfrage liest ein bestimmtes Objekt aus, „GetNext“ und „GetBulk“ durchlaufen den Baum schrittweise, und „Set“ ändert einen beschreibbaren Wert.
- Authentifizierung der Anfrage: SNMPv1 und SNMPv2c identifizieren den Absender anhand einer Community-Zeichenkette. SNMPv3 bietet zusätzlich eine benutzerbasierte Authentifizierung und optionale Verschlüsselung.
- Antwort zurückgeben: Der Agent sucht die angeforderten Objekte und sendet die Werte oder eine Fehlermeldung an den Manager zurück.
- Benachrichtigung senden: Wenn ein definiertes Ereignis eintritt, beispielsweise der Ausfall einer Verbindung, sendet der Agent ohne Abfrage eine Trap an den Manager über den UDP-Port 162. Ein „Inform“ funktioniert wie eine Trap, erfordert jedoch eine Bestätigung.
Ein SNMP-Walk ist eine wiederholte Abfolge von „GetNext“- oder „GetBulk“-Anfragen, mit denen alle Objekte unter einem ausgewählten Knoten im OID-Baum abgerufen werden. Er wird häufig verwendet, um festzustellen, welche Informationen ein Gerät bereitstellt. Traps decken Ereignisse zwischen den Abfragezyklen ab, jedoch ist die UDP-Übertragung eines einfachen Traps nicht garantiert.
Häufige SNMP-Probleme
Geräte, bei denen Community-Strings wie „public“ oder „private“ belassen wurden, ermöglichen es jedem, der auf den UDP-Port 161 zugreifen kann, Daten zu lesen und in manchen Fällen auch zu schreiben. Sicherheitsscans weisen häufig auf dieses Problem bei Druckern und Switches hin, die nach der Installation nie abgesichert wurden.
Ein Trap-Empfänger erhält keine Meldungen, weil für das Gerät kein Trap-Ziel konfiguriert ist, eine Firewall den UDP-Port 162 blockiert oder die Community bzw. der SNMPv3-Benutzer nicht übereinstimmt. Da Traps unaufgefordert gesendet werden und SNMPv1- sowie SNMPv2c-Traps nicht bestätigt werden, gibt der Absender keinen Hinweis auf einen Fehler.
Abfragen laufen ab oder geben Authentifizierungsfehler zurück, wenn Manager und Agent sich hinsichtlich der Sicherheitsstufe, des Authentifizierungsprotokolls oder des Datenschutzprotokolls nicht einig sind. Eine weitere häufige Ursache ist eine Nichtübereinstimmung der für Traps und Informs verwendeten Engine-ID.
Aggressive Abfrageintervalle oder umfangreiche „GetBulk“-Walks über große Tabellen, wie z. B. Routing- oder ARP-Tabellen, können bei älteren Geräten die CPU-Auslastung erhöhen und Lücken in den Diagrammen verursachen. Das Problem lässt sich in der Regel durch eine zeitliche Staffelung der Abfragen und eine Begrenzung der angeforderten OIDs beheben.
Wenn nicht die richtige Hersteller-MIB geladen ist, zeigen Tools rohe numerische OIDs oder falsch gelesene Werte an. Ein Zählerüberlauf bei 32-Bit-Schnittstellenzählern kann zudem falsche Spitzenwerte auf schnellen Verbindungen erzeugen; hier sind 64-Bit-Zähler die bessere Wahl.