Die heute gängigen Management-Umgebungen unterstützen in der Regel das Simple Network Management Protocol (SNMP). Die internationale Standardisierungsinstanz ISO hat zwar eine eigene Management-Umgebung definiert, sie wird aber hauptsächlich in Telekommunikationsnetzen verwendet. Im Bereich der Rechnernetze hat sich aber nicht der ISO-Standard etabliert, sondern das vom Internet Activities Board (IAB) verabschiedete SNMP.
Das IAB hat eine Arbeitsgruppe Internet Engineering Task Force (IETF) eingesetzt, die sich mit dem Management von TCP/IP-Netzen befassen soll. Das SNMP wurde entwickelt, um das Internet als Weitverkehrsnetz zum Verbinden von lokalen Rechnernetzen handhabbar zu gestalten. Bereits 1987 erschien das Simple Gateway Monitoring Protocol (SGMP, RFC 1028), das jedoch speziell für das Management von Gateways entwickelt wurde. Im August 1988 folgten die Dokumente RFC 1155, RFC 1213 und RFC 1157 zu SNMP.
Das Management von TCP/IP-Netzen mit SNMP stützt sich auf ein Modell, in dem eine Management-Station und ein Netzelement auf der Basis eines Protokolls Management-Informationen austauschen. Netzelemente sind beispielsweise Bridges, Router, Hub-Systeme, Gateways oder Endgeräte. Um Management-Funktionen ausführen zu können, muß das Netzelement mit einem Agenten ausgerüstet sein. Er hat die Aufgabe, Anweisungen, die über das Protokoll von der Management-Station kommen, entgegenzunehmen und Aktionen auszuführen.
Das Management des Netzelements beinhaltet, die Eigenschaften des Elements zu lesen oder zu verändern. Unter Eigenschaften sind beispielsweise die Konfiguration, der Zustand etc. zu verstehen. Um einen einheitlichen Zugriff auf die Attribute des Netzelements zu ermöglichen, wird dieses durch abstrakte Datenobjekte oder Variablen modelliert.
Die Merkmale, die für die Management-Station von Bedeutung sind, werden möglichst exakt durch Variablen beschrieben. Diese verwendet der Agent des Netzelements, um Anfragen der Management-Station zu beantworten.
Er hat die Aufgabe, die Werte der Variablen mit dem tatsächlichen Zustand des Netzelements konform zu halten, was eventuell auch eine Umkonfigurierung des Netzelements bei Schreibzugriffen auf Variablen umfaßt. Durch Schreibzugriffe lassen sich beliebige Aktionen im Agenten anstoßen. Das gesamte Management des Netzelements ist somit auf Schreib- und Lesezugriffe von Variablen reduziert.
Für die Management-Station gibt es zwei Möglichkeiten, Informationen von einem Netzelement zu erhalten: Sie läßt sich entweder erfragen, oder der Agent des Netzelements schickt eine Nachricht an eine Management-Station. Die Alternative dazu ist die Erzeugung eines "Traps" durch den Agenten. Ein Trap ist eine Aktion, die bei Eintreten eines Ereignisses ausgeführt wird. Stellt der Agent eine ungewöhnliche Situation fest, setzt er die Management-Station mit Hilfe einer Trap-Nachricht davon in Kenntnis. Bei der ersten Möglichkeit (dem Polling) kann die Management-Station den Zustand des Netzelements überwachen, indem sie die Zustandsvariablen in regelmäßigen Abständen ausliest.
Die Struktur, mit der diese Datenobjekte in einer Management Information Base (MIB) organisiert werden, wird durch die Management-Informationsstruktur (SMI = Structure of Management Information) festgelegt. Das TCP/IP-Management mit SNMP setzt sich demnach aus drei Teilen zusammen: einem Konzept für die Strukturierung der Management-Information (SMI), einer Sammlung von Definitionen für Management-Informationen (MIB) und einem Management-Protokoll (SNMP).
Die Kommunikation zwischen einer Management-Station und einem Netzelement findet durch den Austausch von Nachrichten statt. Für deren Übertragung genügt ein einfacher Datagrammdienst, vorgesehen ist die Übertragung mit dem User Datagramm Protocol (UDP). Jede einzelne Nachricht wird komplett und unabhängig durch ein einziges Datagram dargestellt.
Es werden insgesamt fünf Typen von Protokoll-Dateneinheiten (PDU) unterschieden:
- "GetRequest": Eine Management-Station fordert von einem Agenten Werte von Variablen an. - "GetNextRequest": nimmt Bezug auf die letzte GetRequest-Operation. Es wird das Objekt angefordert, das in der MIB-Hierarchie auf das zuletzt gelesene Objekt folgt. Dies ermöglicht zum Beispiel das einfache Auslesen von Tabellen.
- "GetResponse": liefert die Antwort auf einen vorangegangenen "GetRequest" oder "GetNextRequest". Dies kann auch eine Fehlermeldung sein.
- "SetRequest": Eine Management-Station fordert einen Agenten auf, den Wert einer Variablen zu verändern. Dadurch kann auf Agentenseite im Prinzip jede Operation angestoßen werden.
- "Trap": Ein Agent teilt seiner Management-Station unaufgefordert ein besonderes Ereignis mit. Je nach Ursache werden mehrere Trap-Typen unterschieden.
1992 erhielt die IETF einen Vorschlag für ein verbessertes sicheres SNMP, bei dem eine "Party-MIB" festlegt, wie die Management-Stationen Nachrichten miteinander austauschen können. Außerdem schreibt es zwingend die Verwendung des Data-Encryption-Standards (DES-Algorithmus) für die Verschlüsselung der Nachrichten vor. Als Authentisierungsmöglichkeit wurde der Algorithmus Message Digest 5 (MD5) vorgeschlagen.
Dieses neue Protokoll wurde in den Dokumenten RFC 1351, RFC 1352, RFC 1353 und RFC 1321 als Secure-SNMP (S-SNMP) eingeführt. S-SNMP ist jedoch nicht kompatibel mit SNMP, da es einen anderen Nachrichtenkopf und andere Prozeduren verwendet. Dementsprechend kompliziert gestaltet sich der Umstieg von SNMP auf S-SNMP.
Anfang 1993 stellte die IETF deshalb eine verbesserte Version mit dem Namen "SMP" vor, die zunächst auf Management-Plattformen mit SNMP koexistieren sollte. Die wesentlichen Unterschiede zu SNMP sind dabei erstmals die Möglichkeit der Verwendung nicht nur von UDP/IP als Transportprotokoll, sondern auch beispielsweise von Appletalk, IPX und OSI-Protokollen. Tabellenartige Informationen lassen sich über einen "Bulk-Retrieval"-Mechanismus kompakter abfragen.
Die Sicherheitsvorschläge von S-SNMP wurden überarbeitet und an die Zusammenarbeit mit SNMP angepaßt so muß beispielsweise nicht mehr zwingend der DES-Algorithmus benutzt werden. Die gesamten MIB-Definitionen von SNMP können weiter Verwendung finden in den Dokumenten sind auch Migrationsstrategien enthalten. Die Protokolldateneinheiten (PDU) wurden ebenfalls verbessert, und es wurden neue Datentypen definiert.
SNMPv2 stellt schließlich eine Zusammenführung der Management-Protokolle S-SNMP und SMP dar und wurde im April 1993 mit RFC 1441 bis 1452 eingeführt. In dieser neuen Version werden vor allem folgende Möglichkeiten integriert:
- eine effiziente Übertragung großer Datenmengen wie zum Beispiel Tabellen
- die Unterstützung einer hierarchischen Strukturierung der Management-Funktionen durch Kommunikation mit den Managern
- die Unterstützung verschiedener Protokolle zur Übertragung der Management-Information sowie
- eine Erweiterung um Authentisierungs- und Autorisierungsfunktionen.
Dies führte im Spezifikationsrahmen zu Veränderungen in einigen Bereichen. Die administrative Strukturierung hat sich geändert. Authentisierung und Autorisierung liegen einem neuen Modell zugrunde (Parties), und es besteht die Möglichkeit zum Austausch geheimer Nachrichten (Verschlüsselung). In der eigentlichen Protokollspezifikation war es unabdingbar, neue Datenpaketformate zu definieren, die den Austausch großer Datenmengen und den Informationsaustausch zwischen den Management-Stationen gestatten.
Ein eigenes Dokument, RFC 1449, widmet sich der Unterstützung verschiedener Protokollstapel. Schließlich wurde die Struktur der Management-Information und die Management-Informationsdatenbasis erweitert, um die neuen Authentisierungs- und Autorisierungsfunktionen sowie die Manager-zu-Manager-Kommunikation zu unterstützen (Party-MIB beziehungsweise Manager-zu-Manager-MIB).
Zu den unter SNMP verfügbaren Protokolldateneinheiten kamen im Dokument RFC 1448 folgende hinzu:
- "GetBulkRequest": Mit dieser Nachricht fordert eine Management-Station unter Umständen eine große Zahl von Variablenwerten an. Dabei wird nicht jede benötigte Variable explizit angegeben, sondern durch Angabe von sogenannten Wiederholungsfeldern eine bestimmte Anzahl von Variablen ab einer bestimmten Position festgelegt. Dies erlaubt das Abfragen ganzer Tabellen mit einer solchen Anforderung.
- "InformRequest": Diese Nachricht gestattet den Austausch von Informationen zwischen zwei Management-Stationen. Eine Station informiert damit eine andere über Variablenwerte eines lokal bekannten Partners (Party). Dies soll eine hierarchische Strukturierung des Managements unterstützen.
Zusammenfassend läßt sich sagen, daß sich das SNMP bisher durch den pragmatischen Ansatz, der die schnelle und effiziente Implementierung erlaubte, große Marktanteile sichern konnte. SNMPv2 wird diese Tendenz fortsetzen, obwohl bereits erste Mängel der neuen Version sichtbar werden.
So gehören die Sicherheitsaspekte auch weiterhin zu den Schwachstellen des Internet-Managements und lassen folglich den Ruf nach weiteren Verbesserungen laut werden. Bei SNMP ist mit Hilfe eines Protokollanalysators ("Sniffer") ganz einfach das Zugangspaßwort zu ermitteln. Ein Nachteil der vorgesehenen Algorithmen bei SNMPv2 liegt darin, daß die Software, die die Algorithmen implementiert, beim Export aus den USA den rigiden Einschränkungen der Cocom-Liste unterliegt.
Angeklickt
Das Simple Network Management Protocol hat sich bei TCP/ IP-Netzen einen großen Markt sichern können. Mit seiner 1987 entstandenen Urform eines Monitoring-Protokolls hat es heute nicht mehr viel gemein. Obwohl einige zwischenzeitliche Erweiterungen die Homogenität des Standards gefährdet haben, ist es doch wieder zu einer einheitlichen Grundlage gekommen. Die aktuelle Fassung SNMPv2 bietet einige sehr praktische Details. Gleichwohl gibt es Kritik an Schwachstellen, die die Mitglieder des zuständigen Standardisierungsteams im Internet Activities Board auf Trab halten. Der wichtigste Kritikpunkt sind Sicherheitsmängel.
*Diplomingenieur (BA) Peter Pendelin ist Technical Support Engineer bei der Netmanage Software GmbH in Neufahrn.