Bundesamt für Sicherheit in der Informationstechnik

M 2.144 Verwendung von SNMP als Netzmanagement-Protokoll

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Leiter IT, IT-Sicherheitsbeauftragter

Das Simple Network Management Protocol ( SNMP ) gilt derzeit als Standardprotokoll für Netzmanagement.

Die wesentlichen Vor- und Nachteile von SNMP sind:

  • SNMP zeichnet sich durch ein einfaches Design und damit auch durch eine einfache Implementation aus. Dies reduziert die Fehleranfälligkeit und verbessert die Stabilität des Protokolls.
  • SNMP ist sehr weit verbreitet und gilt als ein De-Facto-Standard. Dadurch wird es durch fast jedes Produkt im Netz- und Systemtechnikumfeld unterstützt.
  • Das Protokoll kann sehr einfach an zukünftige Bedürfnisse angepasst werden. Aus diesem Grund und der oben genannten weiten Verbreitung von SNMP kann es als sehr zukunftssicheres Protokoll (Investitionsschutz) bezeichnet werden.
  • Es handelt sich um ein verbindungsloses, einfaches Protokoll auf Transportebene. Damit ist die Performance der Übertragung der SNMP -Pakete im Netz besser als beim verbindungsorientierten CMIP (Common Management Information Protocol).
  • SNMPv3 bietet ausreichend gute Möglichkeiten zur Authentisierung und Verschlüsselung an, so dass diese in den Versionen SNMPv1 und SNMPv2 bestehenden Mängel beseitigt wurden.
  • Der Einsatz von SNMPv1 oder SNMPv2 birgt Sicherheitsrisiken, die es unter Umständen einem Angreifer ermöglichen, weitgehende Informationen über die System- und Netzumgebung zu erhalten. Insbesondere existiert, abgesehen von den Community-Namen (die bei SNMP die Möglichkeit zur Bildung von Gruppen und bei SNMPv1 und SNMPv2 einen rudimentären Passwortschutz bieten), kein echter Passwortschutz beim Zugriff auf die Netzkomponenten.
  • Aufgrund der Einfachheit des Protokolls und der verfügbaren Möglichkeiten weist SNMP Schwächen im Umgang mit sehr großen oder stark expandierenden Netzen auf.
  • Die Performance der Version 1 ist bei aufwendigeren MIB -Abfragen ungenügend, da immer der gesamte MIB -Baum angegeben werden muss.

SNMP ist ein einfach zu implementierendes Protokoll, das dazu eingesetzt wird, Managementinformationen zwischen einzelnen Netzkomponenten (Agenten) und einer zentralen Managementstation (Manager) auszutauschen. Hierzu werden in einem lokalen Netz ein oder eventuell mehrere Manager und je ein Agent pro IT -System, das mit SNMP überwacht bzw. konfiguriert werden soll, installiert. Die Agenten sind auf den überwachten IT -Systemen ( z. B. Router, Switches, Server etc. ) installiert. Sie ermitteln Statusinformationen von den Komponenten, auf denen sie installiert sind und können die Konfiguration abfragen bzw. ändern. Sie sammeln über diese Systeme Informationen und legen sie in einer Managementdatenbank (Management Information Base, MIB ) ab.

Die Managementinformationen bestehen im Wesentlichen aus Werten von Statusvariablen, die im Managementagenten vorgehalten werden und den jeweiligen Zustand des zugehörigen verwalteten Objektes beschreiben. Welche Statusvariablen (Name und Typ) in den einzelnen Agenten existieren, ist in der MIB beschrieben. Dabei ist die Information hierarchisch organisiert, und jedem Wert ist eine eindeutige Identifikationsnummer zugeordnet, die auf den Variablen damit eine eindeutige Reihenfolge definiert.

Die Nachrichtentypen sind im Einzelnen:

  • GetRequest: wird vom Manager an Agenten geschickt, um von ihnen den Wert einer oder mehrerer Statusvariablen abzufragen.
  • GetNextRequest: wird vom Manager an Agenten geschickt, um von ihnen den Wert oder die nächsten Werte gemäß der Reihenfolge der Variablen in der MIB abzufragen.
  • GetBulkRequest: ist eine Sonderform bei der der GetNextRequest Befehl mehrfach wiederholt wird. Die Anzahl der Wiederholungen lässt sich mit Hilfe des Max-Repetitions Wert festlegen.
  • SetRequest: wird vom Manager an Agenten geschickt, um dort den Wert einer Variablen zu setzen.
  • GetResponse: wird von Agenten zum Manager geschickt, um die angefragten Werte zu senden oder das Setzen eines Variablenwertes zu bestätigen.
  • Trap: wird von Agenten verwendet, um den Manager über Ausnahmeereignisse zu informieren. Das Senden einer Trap-Nachricht erfolgt, im Gegensatz zur GetResponse-Nachricht, ohne vorherige Anfrage vom Manager.
  • InformRequest: wird von Agenten oder einem anderen Manager verwendet, um über ein Ausnahmeereignis zu informieren. Im Gegensatz zur Trap muss der Empfang des InformRequest vom Manager bestätigt werden.
  • Report: kann über das Setzen des reportableFlags angefordert werden und informiert über das Ergebnis einer zuvor gesendeten Anforderung.
Die Authentisierung erfolgt bei SNMPv1 und SNMPv2 lediglich mittels eines unverschlüsselten "Community Strings". Als Standardeinstellung bei nahezu allen Herstellern ist der read-Community-String auf den Wert "public" eingestellt, während der write-Community-String auf den Wert "private" gesetzt ist. Die SNMP Community Strings werden im Klartext über das Netz übertragen. Allerdings gibt es auch in SNMPv2 bezüglich der unterstützten Sicherheit unterschiedliche Varianten. Wenn die unsicheren SNMP -Versionen genutzt werden und für die Administration kein eigenes Administrationsnetz eingerichtet wurde, kann ein Angreifer leicht die Kontrolle über Netzkomponenten erlangen, wenn diese Default-Einstellungen beibehalten werden. SNMPv1 und SNMPv2 sollten daher nicht mehr eingesetzt, stattdessen sollte SNMPv3 (oder höher) verwendet werden. Erst ab dieser Version sind stärkere Authentisierungs- und Verschlüsselungsoptionen vorhanden.

In der Praxis werden jedoch noch immer Systeme eingesetzt, die Version 3 nicht unterstützen und die daher auf ältere Protokollversionen angewiesen sind. In diesem Fall muss der Einsatz einer älteren Version begründet und dokumentiert werden, vor allem sollten die Risiken offengelegt und akzeptiert werden. Diese unsicheren Protokolle sollten allenfalls nur innerhalb eines separaten abgeschotteten Administrationsnetzes (siehe M 2.582 Möglichkeiten zur Einrichtung eines Managementnetzes ) eingesetzt werden. Dies sollte aber höchstens eine Übergangslösung darstellen, langfristig sollten nur noch Geräte eingesetzt werden, die SNMP -Protokolle ab Version 3 unterstützen.

Darüber hinaus müssen die voreingestellten Community-Namen unbedingt gegen andere, schwer zu erratende Namen ausgetauscht werden und auch regelmäßig gewechselt werden (siehe M 4.82 Sichere Konfiguration der aktiven Netzkomponenten ). Die individuellen Netzelemente sollten unterschiedliche Community-Namen besitzen. Die mit den Community-Namen verbundenen Zugriffsberechtigungen müssen auf das absolut erforderliche Minimum gesetzt werden. Weiterhin sollte der Zugriff per SNMP auf Netzelemente mit Hilfe von Access Control Listen auf die Netzmanagement-Stationen beschränkt werden (siehe M 4.80 Sichere Zugriffsmechanismen bei Fernadministration ). Wenn ältere Versionen von SNMP nicht benötigt werden, sollten diese deaktiviert werden.

In der Version SNMPv3 wurde das Konzept der Community-Namen durch einen Benutzernamen ersetzt. Jeder Benutzer ist einer Gruppe zugeordnet, die für die einzelnen überwachten Objekte fein einstellbare Rechte besitzen. Über die Gruppenzugehörigkeit kann auch eingestellt werden, welche Benachrichtigungen (traps) ein Benutzer sehen darf.

SNMPv3 bietet verschiedene Verfahren an, um die Authentisierung der Benutzer zu gewährleisten: einfache Überprüfung des Benutzernamens, Authentisierung mittels MD5 bzw. SHA . Die übertragenen Informationen können außerdem verschlüsselt werden. Es sollten jeweils die stärksten Sicherheitsmerkmale eingesetzt werden.

Aus Sicherheitssicht sollte deshalb auf den Einsatz von SNMPv1 und SNMPv2 verzichtet und SNMPv3 verwendet werden. Der überwiegende Teil moderner IT -Systeme und aktiver Netzkomponenten beherrschen SNMPv3 ebenso wie die Netzmanagement-Software. Der höhere Aufwand, der bei der Konfiguration von SNMPv3 zu leisten ist, wird durch die erhöhte Sicherheit ausgeglichen.

Für den Fall, dass ein herstellerspezifisches Protokoll eingesetzt wird, existiert meist die Möglichkeit, sogenannte Proxies zum Einbinden von SNMP zu verwenden. Auch in diesem Fall muss detailliert geprüft werden, ob das proprietäre Netzmanagement-Protokoll für den Verwendungszweck geeignet ist und ob es dieSicherheitsanforderungen der Institution an das Netzmanagement erfüllt.

Prüffragen:

  • Wird auf den Einsatz veralteter Netzmanagement-Protokolle wie SNMPv1 und SNMPv2 verzichtet?

  • Bei zwingendem Einsatz veralteter Netzmanagement-Protokolle: Sind die damit einhergehenden Risiken dokumentiert?

  • Werden die Community-Namen geändert, individuell auf Netzelemente vergeben und regelmäßig gewechselt?

  • Sind die mit den Community-Namen verbundenen Zugriffsberechtigungen auf das absolut erforderliche Minimum gesetzt?

  • Ist der Zugriff per SNMP auf Netzelemente durch Access Control Listen auf die Netzmanagement-Stationen beschränkt?

Stand: 15. EL Stand 2016