SNMP – Geräte ohne Agent

Switch, NAS, USV oder Drucker mitprüfen, ohne dort Software zu installieren.

Wofür das gut ist #

Ein Switch, ein NAS, eine USV oder ein Drucker kann keinen Agenten ausführen. Sie stehen aber im selben Netz wie deine Server und fallen genauso aus – oft sogar folgenreicher, weil an einem Switch alles andere hängt.

SNMP ist der kleinste gemeinsame Nenner, den praktisch jedes dieser Geräte spricht. NODE64 nutzt es, um sie mitzuprüfen: Ein Agent auf einem deiner Server fragt sie ab, und danach erscheinen sie im Dashboard wie jedes andere Gerät – mit Zustand, Befunden und Verlauf.

Warum die Abfrage vom Agenten kommt #

SNMP ist ein Protokoll fürs lokale Netz. Wollte unser Server ein Gerät hinter deiner Firewall fragen, müsstest du dafür einen Port aufmachen – also genau das tun, wovon dieses Werkzeug abrät.

Der Agent auf deinem Server hat den Zugang bereits. Er bekommt die Zieladressen über denselben Kanal wie alles andere, fragt ab und schickt die Ergebnisse mit dem nächsten Upload mit.

Einrichten #

Unter Einstellungen › SNMP-Ziele:

Adresse des Geräts und, falls abweichend, den Port (Standard 161).
Abfragendes Gerät – einer deiner Server mit Agent, der das Ziel über das Netz erreicht.
Fassung und Zugangsdaten (siehe unten).
Takt – wie oft abgefragt wird. Fünfzehn Minuten sind ein guter Anfang.

SNMP-Ziele zählen wie jedes andere Gerät gegen dein Tarif-Limit.

v3 oder v1/v2c #

Das ist die wichtigste Entscheidung auf der Seite.

Bei v1 und v2c geht der Community-String unverschlüsselt über das Netz – bei jeder einzelnen Abfrage. Wer im selben Netz mitliest, kennt ihn nach wenigen Sekunden. Und es gibt keine Zugangskontrolle darüber hinaus: Der String ist das Passwort, und er ist derselbe für jeden, der ihn kennt.

v3 bringt Benutzerkennungen, eine Prüfsumme über jede Nachricht und wahlweise Verschlüsselung. NODE64 unterstützt für die Prüfsumme SHA und MD5, für die Verschlüsselung AES und DES.

Verfahren	Empfehlung
v3 mit SHA + AES	Die richtige Wahl, wenn das Gerät sie kann.
v3 mit MD5 oder DES	Nimm es, wenn nichts Besseres geht – immer noch weit besser als v2c.
v1 / v2c	Nur, wenn das Gerät nichts anderes beherrscht. Dann gehört das Abfragenetz getrennt.

Läuft ein Ziel über v1 oder v2c, meldet NODE64 das als Befund. Das ist keine Schikane: Es ist der Zustand, den man kennen sollte.

Verschlüsselung ohne Prüfsumme lässt NODE64 nicht zu. Das ist keine Formalie – ohne Prüfsumme liesse sich der verschlüsselte Teil unterwegs unbemerkt austauschen.

Zugangsdaten #

Community-Strings und v3-Passwörter werden verschlüsselt abgelegt (mit dem Schlüssel der Installation, genau wie das Geheimnis der Zwei-Faktor-Anmeldung) und nie wieder angezeigt – wie ein API-Schlüssel. Wer sie ändern will, legt das Ziel neu an.

Entschlüsselt werden sie an genau einer Stelle: beim Ausliefern an den Agenten, über denselben authentifizierten Kanal, über den auch alles andere läuft. In keiner Ansicht, keinem Bericht und keinem Protokolleintrag tauchen sie auf.

Nur lesend – und zwar einkompiliert #

SNMP kennt einen schreibenden Befehl (SET), mit dem sich Geräte umkonfigurieren lassen. NODE64 kann ihn nicht. Nicht „ist abgeschaltet", sondern: Es gibt im Agenten keine Funktion, die ihn ausführt. Was nicht einkompiliert ist, kann auch kein Konfigurationsfehler versehentlich auslösen.

Abgefragt wird ausserdem eine geschlossene Liste von Werten – Systemangaben, Anschlusstabelle, Speicherfüllstände, Prozessorlast. Kein Durchlauf über den gesamten Baum, keine Herstellerzweige. Das ist Absicht: Ein Switch führt unter seiner privaten Kennung oft die komplette Konfiguration einschliesslich Zugangsdaten.

Was erhoben wird #

System: Beschreibung, Hersteller (aus der Kennung), Name, Standort, Laufzeit.
Anschlüsse: Nummer, Name, Beschriftung, Geschwindigkeit, Verwaltungs- und Betriebszustand, Fehler- und Verwurfszähler und – wenn das Gerät sie liefert – das Datenvolumen.
Speicher: Füllstände von Platten, Flash und Arbeitsspeicher.
Prozessorlast, falls das Gerät sie führt.

64-Bit-Zähler #

Beim Datenvolumen gibt es einen Haken, der oft übersehen wird: Die alten 32-Bit-Zähler laufen auf einem Gigabit-Anschluss nach gut 34 Sekunden über. Jede Messung mit grösserem Abstand wäre geraten.

NODE64 liest deshalb bevorzugt die 64-Bit-Zähler (ifHCInOctets). Liefert ein Gerät sie nicht, bleibt das Datenvolumen leer – und in der Geräteansicht steht, warum. Eine falsche Zahl wäre schlechter als keine.

Befunde #

Befund	Bedeutung
v1/v2c im Einsatz	Der Community-String geht im Klartext über das Netz.
Standard-Community	`public`, `private` und ihresgleichen – jedes Scan-Skript probiert sie zuerst.
Antwortet nicht	Gerät aus, Firewall dazwischen, oder Zugangsdaten geändert.
Übertragungsfehler	Fast immer Verkabelung: Kabel, Stecker, Transceiver, Duplex-Mismatch.
Port an, aber ohne Verbindung	Eingeschaltet und ohne Link. Bewusst abgeschaltete Ports werden nicht gemeldet.

Grenzen #

Traps werden nicht empfangen. NODE64 fragt in seinem Takt ab; ein Gerät, das von sich aus meldet, wird nicht gehört. Das würde einen offenen Port auf deinem Server bedeuten.
Keine Herstellererweiterungen. Nur die standardisierten Tabellen. Der Temperatursensor eines bestimmten Switch-Modells wird nicht ausgelesen.
Kein Schwachstellen-Abgleich. Für Netzgeräte gibt es keinen Paketbestand, gegen den sich vergleichen liesse. Die Firmware steht in der Gerätebeschreibung; ob sie aktuell ist, musst du beim Hersteller nachsehen.

Mehrere Sonden je Ziel #

Ein Ziel kann von mehreren Geräten mit Agent abgefragt werden, mit einer Rangfolge. Abgefragt wird immer von der Sonde mit dem besten Rang, die gerade meldet; schweigt sie länger als zehn Minuten, übernimmt die nächste.

Es fragt dabei immer genau eine. Zwei gleichzeitig wären doppelte Last auf dem Switch, zwei Erhebungen, die sich beim Schreiben überholen, und beim kleinsten Unterschied zwei Wahrheiten.

Der Massstab für „meldet noch" ist der Herzschlag der Sonde, nicht ihr SNMP-Erfolg. Eine Sonde, die läuft, aber das Ziel nicht erreicht, hat eine Aussage gemacht – nämlich „von hier aus geht es nicht". Die soll nicht dadurch verlorengehen, dass sofort jemand anders übernimmt. In der Zielübersicht steht deshalb je Sonde, wann sie das Ziel zuletzt erreicht hat und woran es sonst scheiterte.

Die letzte Sonde eines Ziels lässt sich nicht entfernen. Ein Ziel ohne Sonde wird nie wieder abgefragt und sähe dabei aus wie eines, an dem nichts passiert.

Das eigene Gerät über SNMP abfragen #

Läuft auf einem Server mit Agent zusätzlich ein SNMP-Dienst, wird er nicht ungefragt mitgelesen. Der Schalter dafür steht in den Geräteeinstellungen und ist ab Werk aus.

Der Grund ist nicht Vorsicht, sondern Sinn: Der Agent weiss über sein eigenes System mehr, als SNMP je liefern könnte – Pakete mit Versionen, Dienste mit Zustand, Dateien mit Prüfsumme. Dasselbe System zusätzlich über SNMP zu lesen brächte doppelte Daten in schlechterer Qualität.

Was tatsächlich ausgelesen wird #

Die Liste der abgefragten Objekte ist geschlossen. Es gibt keinen Rundumlauf über den ganzen Baum und keine Herstellerzweige unter 1.3.6.1.4.1.* – dort liegt bei vielen Geräten die Konfiguration einschliesslich Zugangsdaten.

Tabelle	Was daraus wird
`ifTable`, `ifXTable`	Anschlüsse, Zustand, Fehler, Datenvolumen
`ipAddrTable`, `ipAddressTable`	Adressen des Geräts, IPv4 und IPv6
`hrStorageTable`	Füllstände von Platten, Flash, Arbeitsspeicher
`hrFSTable`	eingehängte Dateisysteme
`hrDeviceTable`	Geräteteile mit Zustand und Fehlerzähler
`hrSWRunTable`	nur die Anzahl laufender Programme
`tcpCurrEstab`, `udpTable`	nur Zahlen, nie Verbindungslisten
`entPhysicalTable`	Bauteile, Modell, Hardware- und Firmwarestand
`dot1dBaseTable`	Brücken-Anschlüsse, Brücken-Adresse
`ipForwarding`, `sysServices`	ob das Gerät routet, welche Dienste es meldet
`lldpRemTable`	Nachbarn – daraus lässt sich die Verkabelung lesen

Drei Dinge fehlen hier mit Absicht:

Seriennummern (entPhysicalSerialNum). Sie identifizieren ein Gerät eindeutig gegenüber Dritten und helfen bei der Überwachung keinen Millimeter.
Verbindungslisten aus tcpConnTable. Wer sieht, mit wem ein Router gerade spricht, weiss mehr, als eine Überwachung wissen muss.
Programmnamen aus hrSWRunTable. Welche Programme auf einem fremden Gerät laufen, ist dessen Sache; dass es zweihundert statt zwanzig sind, ist eine Betriebsauskunft.

Was dein Gerät wirklich liefert #

Nicht jedes Gerät kennt jede Tabelle. In der Geräteansicht steht unter „Was dieses Gerät beantwortet" je Tabelle, was bei der letzten Abfrage herauskam – vier mögliche Antworten:

Antwort	Bedeutung
liefert	Die Tabelle wurde beantwortet und hat Zeilen.
leer	Beantwortet, aber ohne Inhalt – etwa ein Switch ohne Nachbarn.
kennt es nicht	Das Gerät führt diese Tabelle nicht.
Abfrage fehlgeschlagen	Zeitüberschreitung oder Abbruch.

Der Unterschied zwischen den mittleren beiden ist der Punkt: Ein Switch ohne LLDP-Nachbarn und einer ohne LLDP-MIB liefern beide nichts und sagen völlig Verschiedenes aus.

Diese Angabe steht hier und nicht in einer Tabelle in dieser Doku, weil eine solche Tabelle entweder unvollständig oder falsch wäre – und in einem Jahr beides. MikroTik etwa listet im RouterOS-Handbuch dreizehn unterstützte MIBs auf (MIB-2, HOST-RESOURCES-MIB, IF-MIB, IP-MIB, IP-FORWARD-MIB, IPV6-MIB, BRIDGE-MIB, ENTITY-MIB und weitere); LLDP-MIB steht nicht dabei, obwohl das Handbuch an anderer Stelle lldpRemTable ausdrücklich beschreibt – dort allerdings mit dem Hinweis, dass nur über LLDP gefundene Nachbarn erscheinen, über CDP oder MNDP gefundene nicht. TCP-MIB und UDP-MIB fehlen in der Liste ebenfalls. Netgear veröffentlicht überhaupt keine vollständige Liste; sie steht nur im Web-Menü des jeweiligen Geräts unter „Supported MIBs" und unterscheidet sich je Modell und Firmware.

Dein Gerät beantwortet die Frage also selbst, und zwar für genau sein Modell und seine Firmware.

MikroTik: Agent im Container statt SNMP? #

RouterOS kann seit Version 7.4 Container ausführen, und der NODE64-Agent wird für linux/arm, linux/arm64 und linux/amd64 gebaut – genau die Architekturen, die RouterOS unterstützt. Technisch spricht also nichts dagegen.

Praktisch sind drei Dinge zu bedenken, und sie stammen aus MikroTiks eigener Dokumentation:

Container müssen am Gerät freigeschaltet werden. `/system/device-mode/ update container=yes` verlangt anschliessend einen Druck auf die Reset-Taste oder einen Kaltstart – also physischen Zugang. Aus der Ferne geht es nicht.
MIPS-Geräte können es nicht. Das betrifft unter anderem den ursprünglichen hEX und den hAP lite. Geräte mit EN7562CT-Prozessor (etwa hEX Refresh) laufen nur mit arm32v5-Abbildern.
MikroTik gibt keine Sicherheitszusage. Wörtlich heisst es dort, dass Container bei einem kompromittierten Gerät das Einschleusen von Schadsoftware erleichtern und es „keinerlei Sicherheitsgarantie" gebe. Ausserdem wird eine angeschlossene Festplatte empfohlen; Geräte mit 16 MB Flash brauchen sie.

Unsere Einschätzung: Auf einem Router mit ausreichend Speicher, physischem Zugang und arm64-Prozessor bringt der Agent deutlich mehr als SNMP – er kennt Pakete, Dienste und Dateien. Auf allem anderen bleibt SNMP der richtige Weg. Eine offizielle Unterstützung dafür ist noch nicht gebaut; dieser Abschnitt hält nur fest, was geprüft wurde.