Weniger umständlich als die generischen SNMP-Werkzeuge, aber trotzdem mit allen Analyse- und Management-Funktionen ausgestattet: Scotty ist eine leistungsfähige und frei erhältliche grafische Oberfläche für SNMP und weitere Protokolle.

Es ist ein Wunschtraum vieler Netzwerkadministratoren: Ein Tool, mit dem sie auf ihrem Arbeitsplatz-PC das gesamte Netz im Blick haben. Dieses Tool sollte den Zustand des Netzes und die kleinen Konfigurationsdetails mit wenigen Mausklicks zeigen. Das SNMP-Protokoll liefert dafür die passende Infrastruktur, die Kommandozeilen-Tools von Net-SNMP und Verwandten allein sind aber nicht ausreichend.

In den letzten Jahren wurden daher viele Frontends entwickelt, die die gesammelte Information menschenfreundlich aufbereiten und in einer grafischen Oberfläche darstellen. Viele dieser Verwaltungswerkzeuge kosten jedoch eine Menge Geld, oft mangelt es am Funktionsumfang oder es hapert an der Performance – kurzum, alles Gute ist selten beisammen.

In diese Lücke stößt das von Jürgen Schönwälder entwickelte Scotty. Auf der Basis von Tcl/Tk implementiert das Paket ein System zur Netzwerkverwaltung mit einer Motif-ähnlichen Oberfläche. Die Quellcode-Distribution ist unter[1] erhältlich, einige Linux-Distributoren haben Scotty auch in ihre Paketsammlungen integriert. Nähere Informationen zu Aufbau und Handling der Software bieten[2] und[3].

Scotty, das Universaltalent

Das Scotty-Paket besteht aus zwei Komponenten: der Tcl-Erweiterung Tnm und dem grafischen Editor Tkined. Tnm (Tcl Network Management) implementiert eine Reihe von Protokollen, die über einfache Aufrufe in Tcl-Programmen nutzbar sind. Tkined ist in der Art eines Flowcharters oder vektororientierten Zeichenprogramms aufgebaut und stellt die Netzwerkstruktur grafisch dar.

Die Tnm-Erweiterung von Tcl/Tk unterstützt folgende Protokolle:

• SNMP in den Versionen v1, v2c und v2u; v3 ist in Arbeit;
• ICMP (Internet Control Message Protocol) mit Ping, Netmask- und Timestamp-Abfragen sowie Traceroute;
• DNS-Lookups der Record-Typen A, PTR, HINFO, MX und SOA;
• HTTP-Requests und -Responses;
• RPC mit den Diensten Portmapper, Mount-Daemon, Stat- und Etherstat-Daemon sowie PCNFS;
• NTP-Requests (Network Time Protocol, Version 3)
• sowie UDP ohne besondere Differenzierung.

Zusätzlich zu diesen Standardabfragen liefert Scotty weitere Kommandos, die die Netzwerkverwaltung vereinfachen. Eine Auswahl zeigt Tabelle 1. Für alle Kommandos gibt es übersichtliche Manualseiten, ebenso für Tnm insgesamt. Kenner der Tcl/Tk-Sprache finden Beispielskripte im Verzeichnis »/usr/lib/ tnm*/examples«, mit deren Hilfe sie Scotty anpassen und erweitern können.

Tabelle 1: Wichtige Scotty-Kommandos

Auf der Oberfläche

Ist Scotty nicht in der eigenen Linux-Distribution enthalten, hilft[1] weiter. Ein symbolischer Link »scotty.tar.gz« zeigt dort auf die jeweils aktuelle Version (zurzeit 2.1.11). Das Auspacken und Kompilieren klappt ohne Besonderheiten. Das Paket benötigt Tcl/Tk 8.3 und eine Reihe von Bibliotheken, die auf einem gepflegten System meist vorhanden sind. Genauere Auskunft geben die mitgelieferten Readme-Dateien.

Zentrales Arbeitsmittel für den Administrator ist der Netzwerk-Editor Tkined, der sich einfach mit »tkined &« starten lässt. Seine Arbeitsoberfläche gliedert sich in drei Bereiche:

• Eine Menüleiste am oberen Rand, die alle implementierten Skripte enthält und überdies eine Menge Parameter für das Programm selbst anbietet.
• Darunter eine Zeichenfläche (Canvas) für die Network Map, der grafischen Übersicht über das Netzwerk.
• Die Werkzeugleiste am linken Rand, die hauptsächlich zum manuellen Bearbeiten der Network Map dient.

Eine neue Network Map entsteht auf verschiedenen Wegen: Zum einen kann man die gesamte Map mit der Werkzeugleiste komplett von Hand zeichnen. Damit es nicht nur eine schöne Zeichnung bleibt, stellen Kontextmenüs die Verbindung zu den realen Geräten her. Die zweite Möglichkeit ist, eine Network Map als Konfigurations-File zu formulieren und mit »File | Open« in die Arbeitsfläche zu laden.

Scotty entdeckt das Netz

Weit bequemer ist es jedoch, Scotty selbst alle Arbeit erledigen zu lassen. Eine Übersicht des vorhandenen Netzes erstellt die Funktion »Discover IP Network«, die sich im Menü »IP Discover« versteckt. Auch dieses Menü ist zunächst verborgen: Ein Klick auf den gleichnamigen Eintrag im Menü »Tools« fügt es zur Menüleiste hinzu. Das Menü-Handling von Tkined ist etwas ungewöhnlich, aber schnell erlernt (Kasten “Besonderheit: Menüs in Tkined”). Praktisch sind die abreißbaren Menüs, die man überallhin verschieben kann – allerdings verschwinden sie wegen ihrer Kleinheit auch recht schnell unter anderen Fenstern.

Um ein Netzwerk mit allen Knoten in die Tkined-Zeichenfläche zu zaubern, genügen zwei Dinge: auf »Discover IP Network« klicken und die IP-Netzadresse in das Dialogfeld »request« eintragen. Je nach Rechner- und Netzauslegung dauert es einige Sekunden oder Minuten, bis die Identifikation vollständig ist. Die erzeugte Network Map sieht im Urzustand zwar abenteuerlich aus, ist aber mit ein paar Handgriffen in eine Form verwandelt, wie sie Abbildung 1 zeigt.

Den ebenfalls gewöhnungsbedürftigen Umgang mit den grafischen Elementen in der Zeichenfläche erklären die Menüpunkte »Key Bindings« und »Man Page (tkined)« im Hilfemenü. Dort sind auch interessante Details über die zahlreichen Auswahlmöglichkeiten für Netzwerkobjekte, die Arbeit mit mehreren Zeichenflächen und anderes zu erfahren. Die Grundlagen sind im Kasten “Der grafische Editor” zusammengefasst.

Abbildung 1: Tkined stellt das Testnetz dar. Die Rohversion, die mit Hilfe des »IP-Discover«-Menüs entsteht, lässt sich mit der Werkzeugleiste (links) in diese übersichtliche Darstellung verwandeln.

Ein Blick ins Netz

Für einen ersten Überblick im Netz müssen keine SNMP-Agenten laufen, die sonstigen von Scotty unterstützten Protokolle liefern auch schon eine Menge nützlicher Informationen. Das Menü »IP-Trouble« enthält dazu einige Werkzeuge. Mit gedrückter Shift-Taste lassen sich mehrere Hosts in der Network Map gleichzeitig auswählen, um sie gemeinsam zu untersuchen.

»Ping« überprüft, ob die Hosts prinzipiell erreichbar sind, »Multi Ping« testet die Reaktion auf verschiedene Paketgrößen. »Traceroute« stellt ebenfalls fest, ob die Hosts erreichbar sind, und liefert im negativen Fall die Stelle, ab der es nicht mehr weitergeht. Der Vorteil gegenüber den klassischen Netzanalyse-Tools auf der Textkonsole ist, dass hier die Objekte der Begierde (sprich: Hosts) bequem mit der Maus wählbar sind.

»Daytime« sagt etwas über die Betriebsbereitschaft des Internet-Daemons auf der Remote-Station, falls dieser Dienst freigeschaltet ist. »Finger« verrät Ähnliches bezüglich der Benutzer, die dort gerade eingeloggt sind. Abbildung 2 zeigt, dass diese Dienste in der getesteten Konfiguration nur auf »marsix.kosmix.own« erreichbar sind. Das muss nicht heißen, dass sie auf den anderen Rechnern nicht in Betrieb sind: Möglicherweise darf nur die Arbeitsstation, auf der Scotty läuft, dort nicht zugreifen. Für einen Rechner, der explizit dem Monitoring der Netzwerk-Hosts dient, sollte dies freilich eingerichtet sein.

»TCP Services« führt einen Portscan auf die angewählten Hosts durch. Er zeigt alle Serverdienste an, die antworten. Dienste, die vorhanden sein sollen, lassen sich auf diesem Weg auf ihre Funktionsfähigkeit prüfen. Dieses Tool spürt auch Dienste auf, die eigentlich nicht nötig sind und möglicherweise ein Sicherheitsrisiko darstellen. In einem Netz mit gut konfigurierter Firewall sollte die Firewall selbst von der Analyse ausgeschlossen sein. Andernfalls nimmt sich Scotty für jeden Port bis zu zwei Minuten Zeit. Bei einigen tausend Ports kann das Tage dauern.

Ähnlich wie bei den Diensten mit festem TCP-Port spürt »RPC Services« bekannte RPC-Dienste auf, etwa NFS. Zusätzlich enthält das »IP-Trouble«-Menü Einträge, die NFS-Exports und gemountete Verzeichnisse anzeigen, analog zur Ausgabe von »showmount«. Wenn auf den einzelnen Hosts implementiert, lassen sich auch »rstatd«- und »etherstatd«-Antworten periodisch auswerten.

Abbildung 2: Über das Tool »IP-Trouble« ist ein erster Rundblick im Netz möglich. Das Ausgabefenster zeigt die Ergebnisse von »Ping« (die ersten drei Zeilen), »Daytime« (nächsten drei) und »Finger« (Rest).

Sichtschutz

Für weitere Untersuchungen sind auf den Stationen im Netz SNMP-Agenten erforderlich. Einerseits ist es möglich, mit Scotty-Skripten eigene, kleine Agenten zu schreiben, Hinweise dazu gibt die Dokumentation. Der übliche Weg ist jedoch ein richtiger SNMP-Daemon, zum Beispiel »cmu-snmpd«, »ucdsnmpd«, »net-snmpd« oder schlicht »snmpd«. Ein solcher Agent ist in jeder verbreiteten Linux-Distribution enthalten. Nähere Informationen sind im SNMP-Artikel in dieser Titelstrecke zu finden.

In neueren Installationen ist die Zugriffssteuerung aus Sicherheitsgründen erheblich restriktiver als in früheren Ausgaben, manchmal bereitet das Probleme bei der Zusammenarbeit mit Scotty. Deshalb im Folgenden einige Anmerkungen zur zweckmäßigen Gestaltung der VACM-Konfiguration (View-based Access Control Model) in der Datei »snmpd .conf«. Die wichtigste Aufgabe besteht darin, Communities zu definieren, deren Namen nicht so bekannt sind wie das klassische »public« – sonst steht dem Missbrauch nichts im Weg. Diesen selbst definierten Community-Strings werden dann Sichtfenster (Views) auf den Datenbestand zugeordnet, die der jeweilige Personenkreis unbedingt für seine Arbeit benötigt. Die Zusammenhänge stellt Abbildung 3 dar.

Intern verwendet »snmpd« nicht die mit der Client-Kommandozeile übergebene Community, sondern eigene Security-Namen. Die Zuordnung von Community zu Sicherheitsnamen definiert die Mapping-Direktive »com2sec«. Der Parameter »source« schränkt in dieser Direktive die Zugriffe auf einen bestimmten Host oder ein Teilnetz ein.

Abbildung 3: Die Zugriffssteuerung des SNMP-Agenten bildet Community-Strings auf interne Security-Namen ab, die in Gruppen zusammengefasst werden. Diese Gruppen dürfen auf Views zugreifen, also auf Ausschnitte des MIB-Baums.

Zugriffsrechte für Gruppen

Die Sicherheitsnamen fasst »group« zu Gruppen zusammen. Wenn mehrere der Security-Namen identische Berechtigungen erhalten sollen, ist dies sehr übersichtlich und verbessert die Performance. Gruppendefinitionen enthalten unter Umständen nur ein einziges Mitglied; wegen der einheitlichen Syntax ist das leider nicht zu umgehen. Die »group«-Anweisung legt die Mitglieder der Gruppe fest sowie das jeweilige Sicherheitsmodell. Der Name des Modells deckt sich mit der verwendeten SNMP-Version, etwa »v1« oder »v2c«.

Views sind Sichten auf Teile des MIB-Baums, den der SNMP-Server bereitstellt. Das Kommando »view« definiert den View-Namen und einige Parameter. Es legt fest, ob die folgenden Angaben im Fenster enthalten sind (included) oder nicht (excluded) und nennt außerdem den MIB-Ast, auf den sich das Kommando bezieht. Es schließt optional mit einer hexadezimalen Maske, die den Zugriff auf einzelne Spalten von MIB-Tabellen regelt.

Für die tatsächlichen Zugriffsrechte (Read, Write, Notify) auf einzelne Views sind die »access«-Direktiven zuständig. Sie geben den zuvor definierten Gruppen ihre Rechte, wobei sie zusätzlich nach Herkunft der Abfrage (Context, Prefix) und benutzter Sicherheitsstufe (Model, Level) differenzieren können.

Agent ohne Public-Community

Eine Beispielkonfiguration für das kleine Netz aus Abbildung 1 ist in Listing 1 zu sehen. Das Beispiel verzichtet auf die Standardkonfiguration der Community »public«, sie ist auch nicht unbedingt erforderlich. Manche Administratoren streichen diese Community ganz bewusst, um nicht jedermann den Zugriff auf sensible Daten zu gewähren.

Auf diese Weise dürfen nur die Mitglieder der Community »moni« von der Station mit der IP-Adresse »192.168.231.1« aus den gesamten MIB-Inhalt von jedem so konfigurierten Host lesen. Sie müssen sich dazu nicht gesondert authentifizieren, weder mit der Protokollvariante SNMPv1, noch mit SNMPv2c, sie müssen nur den Community-String kennen.

Listing 1: VACM-Beispielkonfiguration

01 # /etc/snmpd.conf
02 # Mapping of community names into "security names"
03 #       sec.name  source         community
04 com2sec monitor   192.168.231.1  moni
05 
06 # Mapping of sec names into group names
07 #       group.name  sec.model  sec.name
08 group   ro          v1         monitor
09 group   ro          v2c        monitor
10 
11 # Creating views to let the groups have access rights to
12 #       view.name   incl/excl  subtree  mask (optional)
13 view    all         included   .1
14 
15 # Granting the groups access to views
16 #       group.name  context  model  level   prefix  read  write  notify
17 access  ro          ""       v1     noauth  exact   all   none   none
18 access  ro          ""       v2c    noauth  exact   all   none   none

Ein Blick unter die Haube der Hosts

Die frischgebackene Community »moni« ist nun in die Scotty-Konfiguration einzutragen. Das geschieht über »Set SNMP Parameter« in den SNMP-Tools-Menüs (Abbildung 4). Als Protokoll ist SNMPv2 die bessere Wahl als SNMPv1 – falls es alle Agenten im Netz verstehen. Alle anderen Einstellungen können unverändert bleiben. Gibt es Probleme beim Antwortverhalten einzelner Server, hilft ein höherer Timeout-Wert.

Mit diesen Einstellungen steht einer Tiefenprüfung der Hosts nichts mehr im Wege. Einen ersten Überblick geben die Unterpunkte des Menüs »SNMP Host & Ident«. Vorher ist es ratsam, mit »SNMP Trouble | SNMP Devices« herauszufinden, welche Agenten im Netz überhaupt auf die Scotty-Anfragen reagieren.

Allgemeine Aussagen in aller Kürze über die angefragten Systeme erhält man mit »SNMP Host | Host Information« und »SNMP Trouble | System Information«. Unter anderem ist auf einen Blick zu sehen, ob die Uhren aller Rechner richtig gestellt sind. Detaillierte Angaben liefern die anderen Teile des »SNMP Host«-Menüs, etwa

• Speichermedien (RAM, Festplatten) und deren Auslastung,
• Prozessor(en),
• eingehängte Dateisysteme,
• laufende Prozesse.

Einen noch tieferen Blick unter die Haube erlauben die Menü-Einträge in »SNMP Trouble«. Diese Bezeichnung ist keinesfalls als “Schwierigkeiten mit SNMP” zu übersetzen, sondern lediglich als etwas laxe Zusammenfassung von “SNMP-based tools for network troubleshooting” zu verstehen.

Abbildung 4: In Scotty ist der Menü-Eintrag »Set SNMP Parameter« für die SNMP-Client-Konfiguration zuständig. Wichtig sind vor allem der Community-String und die SNMP-Version.

TCP/IP-Stack überwacht

Für jeden der untersuchten Hosts sind hier in 15 Kategorien Hunderte von Einzeldaten zugänglich, die sehr genau alle Gegebenheiten und Abläufe in den unteren drei Schichten des TCP/IP-Stacks reflektieren. Wer einen solchen Röntgenblick einmal gewagt hat, der weiß, wie wichtig bei diesem scharfen Werkzeug der Schutz vor unbefugten Benutzern ist. Mit einer nicht ganz alltäglichen Community-Bezeichnung und einer restriktiven Konfiguration der Agenten (siehe Abbildung 3 und Listing 1) ist schon ein guter Anfang gemacht.

Netzdaten stets im Blick

Natürlich ist das gelegentliche Anschauen und Auswerten von Parametern nur die halbe Miete beim Netzwerk-Monitoring. Einen kontinuierlichen Überblick über zeitliche Abläufe in der Auslastung des Netzes geben die dynamischen Diagramme (Barcharts und Stripcharts) von Scotty. Sie sind in Tkined schnell mit der »SNMP Monitor«-Funktion angelegt. Neben dem Durchsatz von Netzwerkkarten (Interface Load) und der Auslastung einzelner Dienste (TCP Service User) zeigen sie auf Wunsch den zeitlichen Verlauf jeder beliebigen MIB-Variablen (Abbildung 5).

Verwirrend für Scotty-Neulinge ist, dass beim automatischen Anlegen mehrerer Grafiken für einen Netzknoten zunächst alle deckungsgleich übereinander liegen, also nur eine zu sehen ist. Durch Ziehen mit der mittleren Maustaste sind sie aber rasch verteilt und übersichtlich angeordnet wie die Auslastungs-Statistiken der vier Netzwerk-Interfaces von »mondix .kosmix.own« in Abbildung 5.

Zu guter Letzt bringt Scotty noch zwei Browser für den SNMP-Datenbaum mit. Einer davon ist rein textbasiert, kann aber mit der Maus bedient werden. Er ist unter dem Menüpunkt »SNMP Browser | MIB Browser« zu finden. Der zweite Browser stellt die Hierarchie-Ebenen und Verzweigungen grafisch dar, zu finden ist er unter »Tools | SNMP Tree«. Beide leisten etwa das Gleiche, mit beiden lassen sich sowohl die Definitionen als auch die Inhalte sämtlicher MIB-Variablen anzeigen. Beide bieten auch den Rundgang (Walk) durch Teilbäume an, um nicht jeden einzelnen Wert per Hand aufrufen zu müssen.

Fazit und Ausblick

Große MIBs durchsuchen ist eine schöne Beschäftigung für lange Winterabende oder verregnete Sommertage, will sagen: Aus der MIB kommt man zwar klüger heraus, als man hineingegangen ist, aber es dauert alles seine Zeit. Da ist es tröstlich zu wissen, dass man ständig wiederkehrende Managementaufgaben nicht durch heftiges Herumklicken lösen muss, sondern mit vertretbarem Aufwand eigene Scotty-Ergänzungs-Skripte schreiben kann.

Alles in allem ist Scotty ein durchweg brauchbares, an Funktionen fast ein wenig zu reiches, gewöhnungsbedürftiges, aber im Endeffekt enorm zeitsparendes Werkzeug. Mit ihm gelingt es, die Vorzüge von SNMP so richtig zur Geltung zu bringen. Und vor allem: Es ist freie Software. Obendrein glänzt es durch exzellente Performance, wie ein Vergleichstest[4] zeigt.

Gespannt sein darf man auf die demnächst erscheinende Version 3, die SNMPv3 implementieren wird und eine noch bessere Zusammenarbeit mit der Tcl-Version 8 verspricht. (fjl)