Discovery von Netzwerkgeräten – Teil 2

Im ersten Teil dieser Blogserie habe ich die MIB behandelt. Auch in Teil 2 schaffe ich noch die Grundlagen und werde hier nun einen Überblick über das verwendete Netzwerkprotokoll geben.

Ich werde hier jedoch nicht auf sämtliche Funktionen des Protokolls eingehen, sondern mich auf die wesentlichen Teile beschränken, die für das Discovery von Netzwerkgeräten notwendig sind.

Teil 2 – Das Simple Network Management Protocol (SNMP)

Das Hauptaugenmerk bei der Entwicklung von SNMP lag darin, Informationen von Geräten möglichst einfach und mit möglichst wenig Netzwerkverkehr zu erhalten.

Um den Netzwerkverkehr gering zu halten, wurde als Basis von SNMP das verbindungslose UDP gewählt. Somit entfällt Verbindungsaufbau und Rückmeldung wie beim TCP, was jedoch das Risiko birgt, dass Meldungen verloren gehen können. Der Netzwerkverkehr wird damit minimiert, jedoch ist es nicht möglich, zu erkennen, warum ein Paket verloren gegangen ist. Es kann an einer schlechten Netzwerkstruktur liegen, eine Firewall blockierte das Paket oder aber das abgefragte Gerät hat das Paket einfach verworfen, da es ausgelastet ist oder das Protokoll gar nicht unterstützt wird.

Um das Protokoll einfach zu halten, wurden nur wenige Befehle implementiert.

  • get-request = Abfrage eines Datensatzes
  • getnext-request = Abfrage des nächsten Datensatzes in der MIB
  • getbulk (ab SNMPv2c) = mehrere Datensätze gleichzeitig abfragen
  • set-request = schreiben eines Datensatzes
  • get-response = Antwort auf eine der get- oder set-Abfragen
  • trap = Das Gerät sendet unaufgefordert eine Nachricht.

Abgesehen von trap und get-response, sind alle Befehle sogenannte poll-Befehle. Das bedeutet die Geräte werden aktiv abgefragt und liefern dann ihre Daten. Da SNMP nicht nur für Discovery-Funktionalität verwendet wird, sondern auch für das Überwachen von Daten auf den Geräten (Monitoring), wird im Netzwerkmanagement-Bereich oft von „Pollen“ und „Poll-Intervallen“ gesprochen. Damit sind dann die zeitlichen Abstände gemeint, in denen eine Variable regelmäßig vom Gerät abgefragt wird. Dies bedeutet: Je geringer die Poll-Intervalle sind, desto größer sind Netzwerkverkehr und Belastung der Endgeräte.

Aus diesem Grund ist es sehr wichtig, sich vor der Einrichtung von Discovery oder Monitoring Gedanken über die abzufragenden Werte zu machen.

Zum Beispiel:

Wenn eine monatliche Auswertung über die Verwendung von Druckern erfolgen soll, macht es keinen Sinn, den Wert für „gedruckte Seiten“ jede Minute zu „pollen“. Hier wäre eine tägliche oder wöchentliche Abfrage vollkommen ausreichend.

Es ist aber nicht nur wegen des entstehenden Netzwerkverkehrs wichtig, sich Gedanken über die Poll-Intervalle zu machen. Vielmehr ist es so, dass zu häufiges „Pollen“ das Endgerät belastet und dass viele Werte vom Endgerät nicht ständig aktualisiert werden. Bei einem zu kleinen Poll-Intervall kommt es dann zu ungewollten Effekten, da dann der gleiche Wert nochmals geholt wird. Dies scheint auf den ersten Blick kein Problem zu sein – dass dem aber nicht so ist, möchte ich anhand eines Beispiels zeigen:

Falls ich eine Portauslastung eines Gigabit-Switches betrachten möchte, benötige ich mehrere Werte. Hierzu gehören die Geschwindigkeit des Ports, die vergangene Zeit zwischen zwei Polls und wie viele Bytes gesendet und empfangen wurden. Gerade bei den gesendeten und empfangenen Bytes ist es jedoch so, dass diese Werte teilweise nur alle 30 Sekunden vom Gerät aktualisiert werden. Bei einem Poll-Intervall von 5 Sekunden würde dann ständig 0% Auslastung angezeigt und nach der Aktualisierung plötzlich eine real nicht vorhandene Auslastungsspitze.

So viel zu SNMP im Allgemeinen.

SNMPv1 und SNMPv2c

Im Folgenden werde ich nun auf Eigenheiten der unterschiedlichen SNMP-Implementierungen eingehen.

Die beiden meist verbreiteten Protokolle, SNMPv1 und SNMPv2c, sind sich sehr ähnlich, auch wenn sie nicht miteinander kompatibel sind. Ein Gerät, das nur SNMPv1 unterstützt, muss auch mittels SNMPv1 abgefragt werden, ebenso bei SNMPv2c.

In Sachen Sicherheit gibt es bei keinem der beiden Protokolle einen Vorteil. Beide setzen auf communities im Klartext, was dazu führt, dass dieses Pseudopasswort mit einem einfachen Sniffer Tool (z.B. Wireshark) ausgelesen werden kann.

Da SNMP neben den get-Befehlen auch einen set-Befehl unterstützt, empfiehlt es sich dringend, die Set-Option auf den Geräten abzuschalten und nur lesenden Zugriff zu erlauben. Es ist zwar sehr bequem und einfach, auf Geräten Funktionen freizuschalten, jedoch ist der Sicherheitsaspekt nicht zu unterschätzen. Gerade Router und Switches sind von zentraler Bedeutung für die Verfügbarkeit des Netzwerkes und sollten somit keine offene Tür für Angriffe bieten. Um Änderungen an diesen Geräten durchzuführen, empfiehlt es sich, z. B. eine SSH-Verbindung zu wählen. Für die Erfassung von Geräten ist es ausreichend, dass SNMP nur Lesezugriff auf die Geräte hat.

Wie schon erwähnt, sind sich die beiden Protokolle sehr ähnlich. Der größte Unterschied liegt im getbulk-Befehl, der mit SNMPv2c eingeführt wurde. Mittels dieses Befehls ist es möglich, mehrere MIB-Variablen gleichzeitig zu holen. Gerade wenn mehrere Werte benötigt werden, kann dies den Netzwerkverkehr entlasten. Wir nehmen unser Beispiel aus dem letzten Blog-Artikel und erweitern es noch etwas:

In der MIB wären folgende Variabeln abgebildet und sollen abgefragt werden.

München.Straße.Hausnummer.männliche Bewohner

München.Straße.Hausnummer.weibliche Bewohner

München.Straße.Hausnummer.Anzahl Stockwerke

München.Straße.Hausnummer.Anzahl Wohnungen

München.Straße.Hausnummer.Anzahl Tiefgargenplätze

Mit einem normalen get-Befehl würden fünf Anfragen gesendet und ebenso fünf Antworten. Mittels des getbulk-Befehls würden hingegen nur eine Anfrage und eine Antwort gesendet. Je mehr Werte benötigt werden, desto wichtiger ist es, die getbulk-Funktion zu verwenden.

Gerade hier unterscheiden sich auch die Discovery-Tools. Gute Tools verwenden automatisch die getbulk-Funktionalität, um performanter und weniger belastend für Netzwerk und Geräte zu sein.

SNMPv3

SNMPv3 unterscheidet sich sehr stark von seinen Vorgängern. Mit dieser Version wurden endlich Sicherheitsmechanismen eingebaut. Mit SNMPv3 wurde endlich ein Authentifizierungskonzept implementiert und es ist möglich, den Netzwerkverkehr verschlüsselt zu übertragen. Auch wurden Mechanismen eingebaut, die unter anderem vor „man in the middle“-Attacken schützen. Hierfür werden Zeitfenster verwendet, in denen die Antworten erfolgen müssen, und eindeutige EngineIDs.  Leider ist es dadurch zu einer sehr komplexen Angelegenheit geworden und überfordert viele Administratoren. Gerade das Thema EngineIDs führt oft zu Fehlern und Missverständnissen. Oft liefern die Hersteller von Geräten hier keine eindeutige EngineID aus, sondern ähnlich dem Defaultpasswort überall dieselbe. Dies führt dann bei der Kommunikation mit der Management Station zu Fehlern bzw. es können keine Werte ermittelt werden.

Während SNMPv2c bei Windows bereits mitgeliefert wird, müssen die SNMPv3-Funktionen meist von Drittherstellern zugekauft und installiert werden.

Diese beiden Faktoren, Komplexität und mangelnde Standardverfügbarkeit, führen dazu, dass SNMPv3 immer noch nicht so stark verbreitet ist, wie der Sicherheitsaspekt fordern würde. Wer aber nicht nur Informationen von seinen Geräten holen, sondern auch Parameter an den Geräten mittels SNMP ändern möchte, der sollte aus Gründen der Sicherheit auf SNMPv3 setzen.

Fazit

Auch wenn SNMPv1 und SNMPv2c keine Sicherheitsmechanismen unterstützen und mitliefern, sollte man die Vorteile nicht unterschätzen. Gerade für den Aufbau einer CMDB mittels automatisiertem Discovery reichen die reinen get-Befehle aus. Auf den Geräten besteht die Möglichkeit, die set-Funktionalität abzuschalten und auch nur Anfragen von bestimmten IP-Adressen zu akzeptieren. Somit können mögliche Gefahren stark reduziert werden und man erhält trotzdem die wichtigen Informationen, wie z.B. Firmware-Versionen der Netzkomponenten. Wer jedoch auch Werte mittels SNMP auf den Geräten ändern will, sollte dies nur mittels SNMPv3 machen.

 

Autor: Martin Erl, Leiter Software Entwicklung

Kontakt: Martin.Erl@realtech.com

Digitalisierungstransparenz auf Knopfdruck: Alles über den Information Hub dot4

Comments

Schreibe einen Kommentar

Your email address will not be published. Required fields are marked *