Netzwerk¨uberwachungstools

Transcrição

Netzwerküberwachungstools
Tom Gehring, Uwe Kretschmer und Jochen Sommmer
Vorlesung Mess- und Diagnoseverfahren in Netzen“
”
Prof. Dr. H. Sauerburger
08. Januar 2002
Zusammenfassung
In der vorliegenden Ausarbeitung gehen die Autoren zunächst auf grundliegende Probleme bei der Überwachung von Netzen ein und welche Ziele die Netzwerküberwachung dabei verfolgt. Der Fokus liegt dann im Speziellen auf einer
Marktübersicht, welche Software anhand von Szenarien für den Anwender geeignet ist. Dabei werden - den Szenarien zugeordnet - die wichtigsten Programme
detailiert erklärt, sodass selbst ein nicht fachmännischer Anwender entscheiden
kann welches Programm am Ehesten seinen Bedürfnissen nahe kommt.
Inhaltsverzeichnis
1 Einführung
4
1.1
Probleme in Netzen . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2
Ziele der Netzwerküberwachung . . . . . . . . . . . . . . . . . .
7
1.3
Allgemeine Schwierigkeiten der Netzwerküberwachung . . . . . .
9
1.3.1
Der Promiscuous Mode . . . . . . . . . . . . . . . . . . .
9
1.3.2
Collission Domain . . . . . . . . . . . . . . . . . . . . .
10
1.3.3
Der Diagnose Port . . . . . . . . . . . . . . . . . . . . .
10
1.3.4
Broadcast Domain . . . . . . . . . . . . . . . . . . . . .
11
1.3.5
Typische Protokolle in Netzwerken . . . . . . . . . . . .
11
1.3.6
Juristische Schwierigkeiten . . . . . . . . . . . . . . . . .
12
2 Szenarien und ausgewählte Tools
2.1
Szenario 1 - Schreiner Häberle . . . . . . . . . . . . . . . . . . . 16
2.1.1
2.2
14
WS-Watch . . . . . . . . . . . . . . . . . . . . . . . . .
17
Szenario 2 - kleine Netze . . . . . . . . . . . . . . . . . . . . . .
19
2.2.1
MRTG, Multi Router Traffic Grapher . . . . . . . . . . .
20
2.2.2
Ethereal, ein Sniffer für Protokollanalyse und komplexere
Fehlersuche . . . . . . . . . . . . . . . . . . . . . . . . .
21
1
INHALTSVERZEICHNIS
2.3
2
Szenario 3 - Kleine und Mittlere Unternehmen . . . . . . . . . . .
24
2.3.1
TKined / Scotty . . . . . . . . . . . . . . . . . . . . . . .
26
2.3.2
WhatsUp Gold . . . . . . . . . . . . . . . . . . . . . . .
30
2.3.3
NAI´s Sniffer Pro 4.5 . . . . . . . . . . . . . . . . . . . .
33
3 Produktmatrix
37
4 Anhang
38
4.1
Quellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.2
Kontakte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
Abbildungsverzeichnis
1.1
Pyramide - Einordnung von Netzwerküberwachung . . . . . . . .
5
2.1
Screenshot von WS Watch . . . . . . . . . . . . . . . . . . . . .
17
2.2
Screenshot von WS Watch . . . . . . . . . . . . . . . . . . . . .
18
2.3
Screenshot von MRTG . . . . . . . . . . . . . . . . . . . . . . .
20
2.4
Ethereal Hauptfenster/Computer . . . . . . . . . . . . . . . . . .
22
2.5
Ethereal Paketaufbau . . . . . . . . . . . . . . . . . . . . . . . .
23
2.6
Ethereal Hauptfenster/Computer . . . . . . . . . . . . . . . . . .
33
2.7
Sniffer Hauptfenster/Computer . . . . . . . . . . . . . . . . . . .
34
2.8
Sniffer Talker . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
2.9
Sniffer Distributed . . . . . . . . . . . . . . . . . . . . . . . . .
36
3
Kapitel 1
Einführung
Um sich für die richtige Software zur Überwachung von Netzwerken zu entscheiden, möchten wir zunächst auf die grundliegenden Problematiken eingehen welche im allgemeinen in heutigen Netzwerken auftreten können. Diese Problematiken können jedoch so vielfältig sein, dass es nicht möglich ist sämtliche mögliche
Probleme anzusprechen. Jedoch versuchen wir im Rahmen dieses Kapitels auf die
wichtigsten und auch für den nicht fachmännischen Anwender am ehesten nachvollziehbaren Probleme einzugehen. Dabei sollen nicht nur technische Aspekte
beleuchtet werden, sondern auch Problematiken menschlicher Herkunft.
Um den Bereich dieser Ausarbeitung einzugrenzen möchten wir zunächst das
Themengebiet anhand einer Pyramide (Abbildung 1.1) aufzeigen. Hierbei haben
wir die Überwachung in dem unteren Drittel angesiedelt um zu verdeutlichen das
eine gute Netzwerküberwachung Voraussetung ist für die darüberliegenden autonomen Bereiche wie Helpdesk, Trouble-Ticket System oder Netzwerkmanagement. Auf diese speziellen Bereiche werden wir jedoch im Rahmen dieser Ausarbeitung nicht näher eingehen.
Über der Netzwerküberwachung befindet sich der Bereich des Helpdesk und des
Trouble-Ticket Systems. Der Helpdesk ist die zentrale Anlaufstelle eines grösseren Unternehmens zur Bearbeitung von Problemen aus dem IT-Bereich. Hier auflaufende Probleme können, müssen jedoch nicht immer direkt etwas mit dem
Netzwerk zu tun haben. Ein Trouble-Ticket System dient dazu Fehler systematisch abzuarbeiten. Fehler, Probleme können dem Thema nach eingetragen werden. Das Service Personal ist dann in der Lage diese Tickets auszuwerden. Tritt
ein Fehler somit häufiger auf, so kann man hier gezielt nach der Behebung des
Problems suchen. Auch dieses System kann allgemein auf die hanze IT-Struktur
4
KAPITEL 1. EINFÜHRUNG
5
des Unternehmens angewendet werden.
Im oberen Bereich der Pyramide ist nun das komplette Netzwerkmanagement angesiedelt. Der Fluß an Information findet dabei immer nur von unten nach oben
statt. Probleme und Fehler die aus der Netzwerküberwachung resultieren werden
immer nur nach oben weitergegeben. Dazu muss jedoch die IT-Infrastruktur dafür
ausglegt sein. Ein kleines Unternehmen wird wahrscheinlich Netzwerküberwachung betreiben, jedoch kann es vermutlich auf ein komplexes Trouble Ticket
System verzichten. Auch intensives Netzwerkmanagemet mag noch keine Rolle
spielen. Je grösser ein Unternehmen ist desto mehr muss es in die obere Bereiche
der Pyramide investieren. Für ein grosses Unternehmen ist ein gut durchdachtes
Netzwerkmanagement elementar wichtig, allerdings kann dieses nur optimal eingesetzt werden wenn die Grundlage der Netzwerküberwachung sehr weit ausgeprägt ist. Genau dies spiegelt sich in der eingesetzten Software zu Überwachung
von Netzwerken wieder.
Netzwerk
management
Helpdesk
Trouble-Ticket System
Abbildung 1.1: Pyramide - Einordnung von Netzwerküberwachung
1.1 Probleme in Netzen
Die Probleme welche in Zusammhang mit dem Netzwerk auftreten können wie
bereits geschuldert vielfältiger Natur sein. Jedoch möchten wir die naheliegensten
und unserer meinung nach auch wichtigsten näher eingehen.
6
Gewachsene Netze
Ein Unternehmen expandiert im Laufe der Zeit. Damit wächst auch das Netzwerk
eines Unternehmens. Man kann sich vorstellen, dass Teile des Gebäudes vor Jahren mit einem Token Ring als Netzwerk ausgestattet worden sind. Vor kurzem
jedoch wurde ein neuer Gebäudekomplex hinzugebaut und man hat sich dabei
für eine modernes Gigabit-Ethernet entschlossen. Beide Topologien und Typen
müssen nun in das Firmennetzwerk integriert werden. Dabei kann es im Layer-21
Bereich zu Problemen kommen indem es Schwierigkeiten bei den Übergängen
zwischen den Protokollen gibt. Hinzu kommt, dass der Aufbau des Netzes wächst
und somit immer schwerer überschaubar bleibt. In einem grossen Netz können
zum Beispiel sehr viele Protokolle eingesetzt werden. Es ist unmöglich genau zu
wissen wo welches Protokoll gerade eigesetzt wird. Zudem können auch neue
Protokolle in ein vorhandenes Netzwerk integriert werden. Zum Beispiel möchte
das Unternehmen Abteilungen mit Voice over IP (VoIP) ausstatten. Ein solches
Protokoll kann so diversen Problemen führen.
Endgeräte nicht erreichbar
Ein im Prinzip typisches Problem welches sich in Unternehmen nahezu jeden Tag
abspielt ist der nicht funftionierende Drucker. Aufgeregt beschwert sich die Sekretärin das ihr Word-Dokument nicht auf dem Drucker in ihrem Büro herauskommt. Alleine für dieses Problem gibt es zahlreiche Ursachen die entweder netzunabhängug sind und somit nicht in unseren Bereich fallen oder eben doch als
Grund ein Problem an dem Netzwerk haben. Darunter kann man auch das Nichterreichen eines Servers verstehen.
Performance Problem
Die Ursachen hierfür sind nun nicht mehr so trivial. Ein Mitarbeiter könnte bemängeln
das der Zugriff zum Internet enorm langsam geworden ist in letzter Zeit. Ebenso
kann auch der interne Datenverkehr betroffen sein indem es der Sekretärin einfach
zu lange dauert die Geschäfts Vorlage von einem zentralen Server herunterzuladen
in ihre Word Anwendung. Das Problem lann sich schleichend bemerkbar machen
oder prompt.
Geografische Lage
Wie bereits geschildert kann ein Netzwerk ungemein wachsen. Dabei sind die zu
überwachenden Geräte oftmals nicht innerhalb weniger Minuten erreichbar. Ein
Gebäudekomplex könnte z. Bsp. ausserhalb der Stadt liegen oder gar noch ent1
Bezieht sich auf das 7-Schichten OSI Referenzmodell
7
fernter. Es kann auch sein, dass die Geräte die zu überwachen sind nicht unbedingt
Netzwerktypische Komponenten entsprechen. Fahrkartenautomaten der Satdtwerke sind in der ganzen Stadt verteilt. Auch hier macht es Sinn solche Geräte auf
Funktion fern überwachen zu können.
Unsaubere Konfiguration
Bei der Konfiguration z. Bsp. eines Routers kann es dem Systemadministrator
durchaus passieren, dass er einen Zahlendreher einbaut und selbst nach mehrmaliger Überprüfung dies nicht merkt. Soll nun plötzlich eine Verbindung über diesen
Router laufen taucht plötzlich ein Problem auf. Ebenso kann es passieren das man
zwei gleiche IP Nummern vergibt. Sollten nun zwei Server mit der gleichen IP
Nummer im Netz laufen kann es sein, das ein Mitarbeiter innerhalb einer Domaine eventuell auf den einen Server zugreifen kann, jedoch erst ein Mitarbeiter der
von ausserhalb der Domaine auf den Server möchte schildert das Problem, dass
der Server nicht mehr existiert. Die Ursache eines solches Problemes erfordert
einiges an Verständnis und Erfahrung des System Administrators.
1.2 Ziele der Netzwerküberwachung
Es wird also deutlich, dass ein Problem vielerlei Ursachen haben kann welche mit
Hilfe eines Netzwerküberwachungstools schnell gelöst werden soll. Darüberhinaus gibt es aber noch Ziele die kein Problem als Grundlage haben müssen.
Hohe Verfügbarkeit erreichen
Ein besonderer wichtiger Punkt im Bereich des Finanzwesens. Stellen Sie sich
vor, ihre Hausbank bei der sie Aktiengeschäfte abwickeln ist nur eine Stundw
nicht mit dem Internet verbunden und bekommt somit keine Aktienkurse. Eine solche Bank könnten daraufhin neben einem Image Verlust auch eine Klage
drohen. Aus solchen Gründen gibt es gerade im Finanzwesen sogenannte Hochverfügbarkeitsverträge. Diese soll eine je nach Vertrag bezifferte Vergügbarkeit
garantieren.
Zentrale Überwachung
Wie bereits erwähnt können bei den zu überwachenden Geräten auch Fahrkartenautomaten oder CNC Maschinen gemeint sein. Eine Überwachung sollte deshalb
von einer zentralen Stelle erfolgen. Entweder über diverse Protokolle oder die Benutzung von sogenannten Pods die man beliebig n ein Netz integrieren kann. Die
8
Abfrage dieser Pods kann auch wieder aus einer zentralen Lage stattfinden.
Flexible Alarmierung
Nicht alle Alarmzustände sind gleich kritisch zu bewerten. Wichtig ist, dass die
Software vielschichtige Einstellungsmöglichkeiten bietet in denen verschiedene
Zustände leicht zu definieren sind. Eine Priorisierung ist aus diesen Gründen sehr
effektiv. Weiterhin gibt es Alarmzustände die aus einem vorhergehenden bereits
registrierten Alarm hervorgehen welche aus Erfahrung gleich mitüberprüft werden. Solche Alarmmeldungen sollten je nach dem gefiltert werden.
Früherkennung
Durchdachte Verfolgung von möglichen Gefahrenquellen und deren rasche und
frühe Erkennung verhindern einen Netzausfall. Bemerkt man zum Beispiel das die
Last eines Routers, die über Monate hinweg bei zum Beispiel 35 Prozent lag und
seit kurzer Zeit auf 60 Prozent ansteigt könnte ein guter System Administrator frph
genug erkennen, dass hier ein Denied-Of-Service Attake eines Hackers vorliegen
kann. In einem solchen Falle kann eine kurzfristige Abschaltung des Netzwerkes,
besser gesagt die vorübergehende Trennung zum Internet die Firma vor einem
grösseren Schaden bewahren.
Skalierbarkeit
Wie eingangs bereits aufgezeigt sollte das Netzwerk einer Firma mit der Unternehmenspolitik mitwachsen. Dabei soll es früh genug anzeigen wo Flaschenhälse
entstehen. Oftmals werden neue Server in einem bestehenden Netz integriert an
Stellen wo das vorhandene Netz schon sehr belastet ist. Diesen Flaschenhals gilt
es zu erkennen und den Systemplanern darauf hinzuweisen. Ebenso wenn beschlossen wird neue Protokolle zu fahren. Zum Beispiel könnte die Einführung
des H.323 - Protokoll für Voice over IP - dazuführen, dass das Netz sprunghaft an
Performance verliert. Die eingesetzte Software muss hier in der Lage sein eben
auch solche Protokolle zu erkennen.
Fehlererkennung
Wichtig ist ebenfalls das die Überwachungssoftware auch Fehler in einer Art und
Weise darstellt. Entweder durch farbige Icons in Signalfarben bei Fehlern, Popup
Fenster oder andere Möglichkeiten zur Signalisierung eines Fehlers. Schlisslich
muss man eingehenden Beschwerden über nicht funktionierende Drucker umgehend nachgehen. Sagt die Software jedoch, dass kein Fehler vorliegt so kann man
dies der Sekräterin mitteilen.
9
Fehlerursache eingrenzen
Liegt nun aber der Fall vor das der Drucker als zum Beispiel rotes Icon leuchtet muss der Administrator mit Hilfe von Ping oder Traceroute die Strecke zum
Drucker abfragen, um diesen Fehler einzugrenzen. Kommt er bis zum letzten Hop
durch, so weiss er, dass der Fehler bei dem Drucker zu suchen ist, oder jedenfalls
an der Strecke bis zum letzten noch erreichbaren Hop. Die Tools zur Eingrenzung
des Fehlers müssen nicht Teil des Überwachungstools sein.
1.3 Allgemeine Schwierigkeiten der Netzwerküberwachung
Um Netzwerküberwachung zu betreiben gibt es jedoch noch einige Schwierigkeiten die es gilt abzuklären. Zu einem können diese technischer Natur sein, jedoch
gibt es auch juristische Grenzen die jemanden an einer Überwachung eines Netzwerkes oder einer Komponente hindern, oder diese erschweren.
1.3.1 Der Promiscuous Mode
Die Software welche wir einsetzen möchten benötigt natürlich einen Rechner auf
der sie installiert worden ist. Ebenso benötigt dieser Rechner eine Netzwerkkarte
über die der Rechner an das zu sniffende Netz angeschlossen ist. Eine Netzwerkkarte ist nicht gleich eine Netzwerkkarte. Zunächst kann der Preis der Karte schon
einiges über die Karte aussagen. Bei dem normalen Betrieb einer Netzwerkkarte
wissen wir, dass ab der zweiten Schicht des OSI-Modells nur noch die Pakete in
die oberen Schichten geleitet werden welche für den Rechner explizit bestimmt
sind, sowie natürlich Broadcast Meldungen. Für das Sniffern von Paketen ist dies
natürlich ungeeignet da wir nur den eigenen für diesesn Rechner bestimmten Verkehr und dessen Pakete mitbekommen.
Aus diesem Grund muss die Netzwerkkarte in der Lage sein alle ankommenden
Pakete nach oben in die höheren Schichten durchzuleiten. Dafür muss die Karte sich in den Promiscuous Mode setzen lassen. Dies passiert automatisch. Der
Anwender bekommt davon nichts mit.
Was passiert nun aber wenn die Netzwerkkarte an einem 100 Mbit Netz angeschlossen ist welches gerade sehr viel Traffic verarbeiten muss. Die Karte muss
10
nun alle ankommenden Pakete nach oben durchleiten, damit diese Pakete analysiert werden können. Bei einem 100 Mbit Netz können das natürlich extrem viele
sein. Die Karte ist nun vielleicht gar nicht mehr in der Lage alle Pakete nach oben
durchzureichen. Das bedeutet, vielleicht kommt nur noch jedes fünfte Paket in
den oberen Schichten an weil die Karte ausgelastet ist. Betreiben wir mit einer
solchen Karte Netzwerküberwachung werden wir Ergebnisse bekommen die sehr
ungenau sind. Die Ergebnisse sind praktisch wertlos.
Also spielt die Qualität der Karte eine entscheidene Rolle. Eine Netzwerkkarte mit
einem eigenen Prozessor sollte in der Lage sein alle ankommenden Pakete nach
oben durchzuleiten. Unsere Ergebniise sind somit genau und wieder brauchbar.
1.3.2 Collission Domain
Befindet sich der Rechner an einem BNC verkabelten Netzwerk so bekommt der
Rechner alle Pakete mit, die in diesem Netzwerkstrang kursieren.
Gleiches gilt auch in einem TP verkabelten Netzwerk sofern sich der Rechner an
einem Hub angeschlossen befindet. Sämtlicher ankommender Traffic wird auf alle
Ports des Hubs verteilt.
Befindet sich der Rechner aber an einem Switch angeschlossen, so haben wir ein
Problem. Die Collision Domain ist dann nur der Weg von Rechner bis zu dem Port
am Switch wo der Rechner angeschlossen ist. Die Funktionsweise eines Switch
ist ja bekanntlich, dass der Switch sich merkt welche MAC-Adresse an welchem
Port hängt. Die zu verteilende Pakete kann er somit jedem Port zuordnen. Daraus
folgt, dass an dem Rechner wieder nur die Pakete ankommen die für den Rechner
selbst auch bestimmt sind. Ein Sniffern über den anderen Traffic ist hier nicht
möglich.
1.3.3 Der Diagnose Port
Hier gibt es nun verschiedene Möglichkeiten dieses Problem zu umgehen. Entweder ist der Switch in der Lage zum Beispiel über eine Monitor Funktion alle Ports
auf einen anderen Ports mitauszugeben. An diesem Port kann nun der Rechner
wiederum angeschlossen werden. Allerdings sollte einem bewusst sein, dass zum
Beispiel jeder Port mit maximal 100 Mbit gefahren werden kann. Je nach Anzahl
der Ports kann es hier zu hohem Traffic führen. Vorsicht ist also geboten.
11
Eine andere Möglichkeit ist, dass der Switch direkt einen Diagnose Port hat an
dem man den Rechner anschliessen kann. Die Information die hier auf diesem
Port ausgegeben werden hängen jedoch stark vom Hersteller der Hardware ab.
1.3.4 Broadcast Domain
Trotz alle dem ist ein Router das Ende. Bis zu einem Router kann man ein Netzwerk in dem man sich befindet überwachen. Alles was ausserhalb dieser Broadcast Domäne sich befindet bedarf anderer Mittel um überwacht werden zu können.
Hier kommt es zu dem Einstaz von speziellen Protokollen zur Netzwerküberwachung.
1.3.5 Typische Protokolle in Netzwerken
Ein im TCP/IP verankertes Protokoll, welches netzübergreifend eingesetzt werden
kann ist zum Beispiel ICMP (Internet Control Message Protocol) 2 . Anzumerken
bleibt nur, dass zum Beispiel ein Ping auf der Basis von ICMP funktioniert. Dies
macht Sinn, da ich mit einem Ping jeden momentan am meinem Netz angeschlossenen Rechner abfragen kann ob er ’noch am Leben’ ist.
Typische Protokolle die in Netzwerken eine wichtige Rolle spielen sind u.a.
• RMON (Remote Moitoring)
• SNMP (Simple Network Management Protocol)
• RIP (Routing Information Protocol)
• OSPF (Open Shortest Path First)
• BGP (Border Gateway Protocol)
Auf RMON und SNMP werden wir an dieser Stelle ebenfalls nicht näher eingehen. Wir verweisen an dieser Stelle an die betreffenden Ausarbeitungen die
ebenfalls im Rahmen dieser Vorlesung zu RMON und SNMP entstanden sind.
2
RFC 792
12
RIP ist ein älteres Protokoll, welches dem Router sagt welche Router seine nächsten
sind. Der Austausch der Information wird über dieses Protokoll geregelt. RIP wird
heute immer mehr von OSPF abgelöst weil RIP nicht gerade intelligent arbeiten
kann.
OSPF 3 wird heute bei Routern eingesetzt. Dabei bekommen die Router die komplette Topologie des vorhandenen Netzwerkes anhand einer Tabelle. Somit kennen
die Router den genauen Weg zur Zieladresse. Anhand des Spanning Tree Algorithmus wird nun der effektivste verfügbare Weg für ein Paket gewählt.
BGP 4 wird eingesetzt um die Routing Informationen zweier autonomen Netze
auszutauschen. Zei Netze einer Firma sind zum Beispiel über das Internet miteinander verbunden. Einsatzgebiet ist zum Beispiel zwischen zwei ISPs.
1.3.6 Juristische Schwierigkeiten
Ein Unternehmen ist zum Beispiel über einen lokalen ISP an das Internet angeschlossen. Zur Sicherheit hat das Unternehmen 2 Leitungen in das Internet von
dem ISP. Die primäre Leitung könnte zum Beispiel eine 155 Mbit Datenleitung
sein. Sollte diese Leitung einmal ausfallen, so existiert noch eine 2 Mbit Standleitung auf die dann ausgewichen werden kann. Für den Anschluss an das Internet
stellt der ISP Gerätschaften zur Verfügung die sich im Keller des Unternehmens
befinden.
Fällt nun die primäre Standleitung aus und durch einen Fhler im Routing wird
nicht automatisch auf die sekundäre Leitung umgeschaltet. So kann man diesen
Vorfall nur eingrenzen. Direkte Zugriffsmöglichkeiten auf die fremden Gerätschaften sind nicht vorgesehen. Man ist also nicht in der Lage den Fehler der vom ISP
verursacht wurde festzustellen.
Kommen wir wieder auf unser Beispiel mit den Banken zurück ist vorstellbar,
dass es sehr schnell zu hohen sieben stelligen Euro Beträgen kommen kann die
als Streitwert vor Gerichten geltend gemacht werden. Eine Beweisführung wer
nun Schuld hat ist sehr schwer.
Auch hier ist es uns nicht möglich alle Schwierigkeiten die auftreten können abzuhandeln. Jedoch sollten Sie einen Eindruck vermittelt bekommen haben was als
3
4
RFC 1583
RFC 1771
13
Voraussetzung für den effektiver Einsatz von Tools vorausgesetzt werden kann.
Dazu kommen wir nun speziell im nächsten Kapitel zu sprechen.
Kapitel 2
Szenarien und ausgewählte Tools
Nachdem wir nun einige Probleme die in Netzwerken auftreten können, und anschliessend Ziele und Probleme mit Netzwerküberwachung beschrieben haben,
möchten wir nun anhand von verschiedenen Szenarein einige Netzwerküberwachungstools vorstellen.
Viele Betriebssystem Beigaben wie Ping, Traceroute oder NSlookup helfen zwar
in manchen Fällen Fehler und Probleme zu finden, doch kann man hier nicht von
Netzwerküberwachung reden. Hier sind also spezielle Tools nötig um möglichst
viele der vorher beschriebenen Ziele der Netzwerküberwachung zu erreichen.
Hier ist zu erwähnen, dass der Einsatz solcher speziellen Netzwerküberachungstools immer abhängig von einigen Faktoren ist:
• KnowHow, Support, Schulung
• Komplexität des Netzes
• Ziele die durch die Überwachung erreicht werden sollen
• Betriebssystem, Preis
Das nötige Know-How des Benutzers ist natürlich Grundvoraussetzung für den
Einsatz eines Netzwerküberwachungstool. Ein Sniffer, der eine Unzahl von Protokollen versteht und dekodieren kann, nützt natürlich nichts, wenn man mit den
gesammelten Daten nichts anfangen kann. Je umfangreicher ein Tool ist, also je
mehr Funktionen es bietet, bedeuted dies meist automatisch, dass der Benutzer das
nötige Know-How braucht, um diese auch zu verstehen und zu nutzen zu können.
14
KAPITEL 2. SZENARIEN UND AUSGEWÄHLTE TOOLS
15
Sieht man z.B. die Gefahr das man das Netz mit SNMP auch sehr belasten kann,
so ist hier ein User der nichts versteht oftmals sogar ein Risikofaktor.
Support und Schulungen sind ebenfalls ein Faktor bei der Wahl des Netzwerküberwachungstools. Bei großen, komplexen Netzen werden zwar sehr oft extra Fachleute eingestellt um diese zu überwachen, doch werden hier auch sehr oft sehr
Umfangreiche und komplexe Tools eingesetzt. Um diese komplexen Tools auch
richtig und effizient einsetzten zu können sind also oft Schulungen für die Mitarbeiter nötig. An einem laufenden und wichtigen Netz, bei dem man sich keine
Downzeiten erlauben kann, ist es sicherlich der falsche Weg das Tool durch benutzen und ausprobieren kennenzulernen. Ausserdem ist auch Support wichtig. Gibt
eine Firma viel Geld aus für ein Überwachungstool, sollte auch genügend Support
angeboten werden, falls es Schwierigkeiten beim Einsatz mit diesem Tool gibt. Installiert man ein Tool auf einem Rechner und es läuft nicht, muss und im Notfall
auch ein Fachman vom Hersteller des Tools zur Firma kommen, der genügend
Erfahrung besitzt, den Fehler schnell zu finden und das Tool wieder zum laufen
zu bekommen.
Bei einem sehr einfachen Netz braucht man sicherlich kein sehr komplexes Tool.
D.h. auch die Komplexität des Netzes ist mitentscheindend bei der Wahl des Tools.
Bei einem sehr kleinen und einfachen Netz bei dem es auch mal Downzeiten geben darf, ist ein teures und sehr Umfangreiches Tool sicherlich übertrieben. Hier
will man viellleicht nur einen schnellen Überblick welche Rechner und Komponenten in Betrieb sind, und welche nicht. Bei einem großen und kompexen Netz,
das vieleich sogar noch ein gewachsenes Netz mit verschiedenen Topologien und
Protokollen ist, benötigt man aber wiederum ein umfangreiches Tool das in der
Lage ist alle Protokolle zu verstehen. Wie am Anfang bereits erwähnt gibt es beim
Mesen und Überwachen in Netzen auch Schwierigkeiten. Bei einem großen und
komplexen Netz muss mein Überachungstool also in der Lage sein mit trotz Switche, Router, Collisiondomains, Broadcastdomains usw. eine vernünftige Überwachung bieten, sprich es muss die entsprechende Funktionalität bieten.
Je nach Netzwerk und Abhängikeit vom Netzwerk, hat man natürlich auch verschiedene Ziele die man durch die Netzwerküberwachung erreichen will. Ist eine
Firma abhängig von einem funktionierenden Netzwerk, und müßte starke Verluste
durch einen Áusfall des Netzwerks hinnehmen, hat sie sicherlich viel höhere Ziele
als ein Betreiber einer sehr kleinen Firma, oder der eines privaten Netzwerks, bei
dem ein Ausfall zwar ärgerlich ist, aber keine so schwerwiegenden Konsequenzen
hätte. Das passende Tool zur Neztwerküberwachung ist also immer in Bezug zu
den Zielen die man durch die Netzwerküberwachung erreichen will zu sehen.
Eine weitere Rolle bei der Suche nach dem richtigen Tool, ist auch der Preis und
16
das Betriebssystem. Während eine kleine Firma, oder ein User der ein Home-LAN
betreibt natürlich kosten sparen will, und somit ein möglichst kostenloses, oder
billiges Produkt sucht, sind große Firmen durchaus gewillt auch höhere Summen
für ein Tool auszugeben, um somit ein optimales Tool für eine effiziente Überwachung zu erstehen. Während man in grossen Netzen auch oft ein Mix aus den
veschiedenesten Betriebsstemen hat, findet man aber auch in kleineren Netzen
oft nur Windows Plattformen. Hier ist es weniger ein Problem welches Betriebssystem überwacht weren soll, aber man muss sich vorher klar werden von welchem Betriebssystem man überwachen will. Es gibt einige Produkte die auf allen
Plattformen laufen, und einige die nur auf Windows oder Unix/Linux Plattformen
laufen.
Insgesamt ist ein Netzwerküberwachungstool also nicht nur nach dem Funktionsumfang zu wählen, sondern es spielen eben wie erwähnt viele andere Faktoren wie Preis, Betriebssystem, KnowHow, Support und Schulungen eine Rolle.
In den Folgenen Abschnitten möchten wir deshalb eine Reihe von veschiedene
Netwerküberachungstools anhand verschiedener Szenarien vorstellen.
2.1 Szenario 1 - Schreiner Häberle
Schreiner Häberle arbeitet in einer kleinen Schreinerei, welche ein kleines Netzwerk hat und mehrere PC´s zur Buchhaltung, Zeichnen von neuen Möbelstücken
usw. Der Betrieb der Schreinerei ist also nicht abhängig von einem funktionierenden Netzwerk, und doch ist es ärgerlich das es häufig zu kleinen Störungen
kommt. Nachdem sich der Chef von Schreiner Häberle nun schon öfters geärgert
hat, das er nicht drucken kann, oder nicht auf den Server kommt, beauftragt er
Schreiner Häberle doch die PC´s und das Netzwerk etwas zu überwachen, da er
weiß, das dieser auch zu Hause ein kleines Netzwerk mit DSL Flatrate hat. Schreiner Häberle selbst hat zwar zu Hause ein kleines Netzwerk, doch verfügt er selbst
nur über ein kleines Grundwissen was Netzwerke und PC´s betrifft und ließt eben
ab und zu eine Computerzeitschrift. Für Ihn ist die Aufgabe des Chefs also eher
eine Zusatzlast, für die er weder viel Zeit noch Mühe investieren will, noch bekommt er zusätzliches Geld für diese Zusatzarbeit. Sein Chef will auch nichts für
die Software bzw. wenn den nötig sehr wenig Geld für eine Überwachungssoftware ausgeben.
Schreiner Häberle geht also ins Internet und sucht nach einer geeigneten Software. Natürlich sollte die Software auf einem Windows Rechner laufen, und viele
Funktionen muss die Software auch nicht haben. Meist löst Schreiner Häberle die
17
Netzwerkprobleme schon mit einem Ping oder Traceroute und stellt fest, das der
’defekte’ Drucker einfach ausgeschalten ist.
Das Tool, das Schreiner Häberle also sucht, sollte einfach und intuitiv bedienbar
sein, auf Windows-Plattformen laufen und möglichst billig. ein passendes Tool
hierfür wäre z.B. WS-Watch.
2.1.1 WS-Watch
WS-Watch bedeutet Winsocket-Watch und läuft auf allen Windowsplattformen.
Entwickelt wurde WS-Watch von John A.Jumod wird leider nicht mehr weiterentwickelt, ist aber noch ohne Probleme aus dem Internet herunterzuladen und
kostenlos.
WS-Watch stellt das zu überwachende Netzwerk in einer kleinen Karte dar. Leider bietet WS-Watch keine Autodiscovery und alle Rechner bzw. Netzwerkkopmonenten müssen von Hand eingetragen werden. Zu jeder Netzwerkomponente
können verschiedene Eigenschaften wie IP-Adresse, Name und weitere Informationen eingetragen werden. WS-Watch stellt die Netzwerkomponente dann in einer Map graphisch dar. WS-Watch bietet auch die Funktion die einzelnen Komponenten in einem selbst gewählten Zeitintervall zwischen 1 Sekunde und einer
Minute immer wieder anzupollen. Dabei benützt WS-Watch einen Ping also das
ICMP -Protokoll um die Verfügbarkeit der Komponenten zu überprüfen. Erreichbare Komponenten stellt WS-Watch dann Grün , nicht erreichbare Stationen Rot
in der Karte dar.
Abbildung 2.1: Screenshot von WS Watch
Durch die Abfrage per ICMP bietet WS-Watch also einen schnellen Überblick
18
übder die Stationen und ob sie erreichbar sind oder nicht. Äußerem muss man
nun nicht mehr alle Stationen einzeln anpingen, und vor allem muss man die IPAdressen nicht mehr auswendig wissen, oder von einem Zettel abtippen. Geht
man in der Karte mit der Maus auf eine Netzwerkomponente bekommt man auch
alle Informationen zu dieser Komponente angezeigt. Sprich den Namen, die IPAdresse, die Zusatzinformationen die man eingegeben hat, und ob die Komponente erreichbar ist oder nicht. Ist die Komponente nicht erreichbar sieht man unter
dem Punkt Lostßeit wievielen Überprüfungen die Komponente schon nicht mehr
erreichbar ist.
Zusätzlich bietet WS-Wacth aber auch einige nützliche Dienste mehr. Man kann
durch einen Doppleklick auf eine Netzwerkomponente eine Telnet oder FTPVerbindung herstellen. Das Programm selbst überprüft jedoch leider nicht ob dies
überhaupt möglich ist, und versucht einfach eine Verbindung herzustellen. Natürlich
kann eine FTP oder TelnetVerbindung nicht nur zu den auf denen in der Karte eingezeichneten Komponenten durch Doppelklick, sondern zu jeder beliebigen Station hergestellt werden. Immer vorrausgesetzt natürlich diese befinden sich im gleichen Netz oder es besteht eine Verbindung ins Internet. Weitere nützliche Dienste von WS-Watch sind lookup, traceroute, whois und finger, wobei whois also
Abfragen zu einer Domain oder finger sprich einem Dienst zum Abrufen von Benutzerinformationen auf Internet-Hosts zur Überwachung des Netzwerks weniger
nützlich sind.
Abbildung 2.2: Screenshot von WS Watch
Insgesamt ist WS-Watch also ein sehr einfaches aber durchaus praktisches Tool,
das einem einen schnellen Überblick über den Netzstatus gibt, und auch ein par
weitere nützliche Dienste bietet. Für Schreiner Häberle oder andere Personen die
ohne großen Aufwand und Wissen Ihr Netz gern besser und schneller im Blick
haben wollen also ideal. Äußerem ist WS-Watch auch kostenlos, und mit ein paar
19
hundert Kilobyte eine sehr kleine Applikation zum schnellen herunterladen.
2.2 Szenario 2 - kleine Netze
In Szenario 2 handelt es sich um ein kleines WG-LAN, das aber auch mit dem
Lan einer kleineren Firma zu vergleichen ist. Das Home WG-LAN befindet sich
im F-Bau in der Friedrichstrasse in Furtwagen. Hier sind Wohnungen mit jeweils
2 Bewohnern direkt nebeneinander. Alle Wohnungen sind durch ein Koaxialkabel also mit 10 MBit/s Halfduplex miteinander vernetzt. Eine Wohnung selbst hat
noch ein geswichtes Netz mit 100 MBit/s Fullduplex, und ist über einen Router
an das restliche Netz angeschlossen. Äußerem deinen den 4 WG´s 2 DSL Standleitungen als Internetanbindung. Bei den Bewohnern der Wohnungen handelt es
sich ausschließlich um Studenten, aus den Fachbereichen Product Engineering,
Wirtschaftsinformatik aber auch von Computer-Networking. Das heißt es ist ein
gewisses KnowHow vorhanden, und auch Interesse. Das einzusetztende Überwachungstool sollte also eine Reihe von Anforderungen erfüllen. Die Studenten
haben Interesse eine Langezeitmessung ihres Netztes, vor allem von den DSLFlatrates zu machen, wollen einen Überblick über die Vorgänge im Netz, und was
für Protokolle im Netz Ihr Unwesen treiben. Äußerem haben sie Interesse daran, die Top-Talker und Top-Protokolle auf einen Blick ausfindig zu machen , und
wollen auch mal in das Netz Sniffen, um mögliche Passwörter im Klartext oder
unsinnige Protokolle zu finden.
Für Szenario 2 möchten wir nun einige Produkte vorstellen. Die Produkte passen
natürlich nicht nur in das von uns beschriebene Szenario, aber um die Produkte
etwas anschaulicher darzustellen haben wir uns diese Szenerien ausgedacht. Im
folgenden stellen wir also nun folgende Netzwerküberwachungstools für Szenario
2 vor:
• MRTG
• Ethereal
• Scotty
20
2.2.1 MRTG, Multi Router Traffic Grapher
MRTG heißt Multi Router Traffic Grapher und ist momentan unter der Version 2.9.18pre erhältlich. MRTG ist ein Open Source Produkt, also frei erhältlich.
MRTG läuft sowohl auf Windows Plattformen als auch auch Unix bzw. Linux
Plattformen. MRTG ist ein Perl Script, das bei Unix/Linux Systemen einen Chronjob und bei Windows Systemen den Scheduler startet und regelmäßig SNMP Abfragen startet. Standarmäßig ist hier im conifg File ’ifoctests-in’ und ’ifoctetsout’ eingetragen. Aus den gesammelten Daten erzeugt MRTG dann Grafiken welche auf einer HTML Seite angeschaut werden können. MRTG ist somit ein ideales Werkzeug um Langzeitmessungen in Netzwerk zu machen. Vor allem eignen
sich solche Langzeitmessungen natürlich für Router zum Internet oder Gateways.
MRTG bietet leider keine Alarmfunktion. Ist der Router zum Internet z.B zu 80
Prozent ausgelastet währe eine Alarmfunktion sicher nützlich, doch da es sich bei
MRTG um ein Perl-Script handelt, ist solch eine Funktion durch etwas Programmieren auch leicht zu implementieren.
Abbildung 2.3: Screenshot von MRTG
Mit MRTG hat man also die Möglichkeit die Last in seinem Netz vernünftig und
21
ohne großen Aufwand zu erfassen. Lastanalysen sind in größeren Netzen sehr
wichtig, muß doch ein eventuell nötiges Redesign gut geplant sein, vor allem
wenn der Netzbetrieb nicht unterbrochen, oder so wenig wie möglich unterbrochen werden darf. Vor allem ist hier zu beachten, das eine kurze Lastmessung in
einem Netzwerk nie ein wirklich aussagekräftiges Mittel ist, über die Auslastung
seines Netzwerks einen Überblick zu bekommen. In jedem Netzwerk gibt es Zeiten wie nach dem Essen in der die Auslastung sehr hoch ist, und Zeiten in denen
fast kein Verkehr herrscht. MRTG bietet hier eine sehr gute Lösung. In verschieden einstellbaren Zeiten werden die SNMP Abfragen an die Netzwerkomponente
gestellt und MRTG stellt diese dann als Übersicht graphisch dar. Dabei wird eine
Graphik für den Tag, den Monat, und das Jahr dargestellt um für jedes Zeitintervall eine vernünftigen Überblick zu bekommen.
2.2.2 Ethereal, ein Sniffer für Protokollanalyse und komplexere Fehlersuche
Ethereal ist ein Sniffer der unter Windows und Linux/Unix einsetzbar ist, und ein
Open Source Produkt, also kostenlos erhältlich. Ein Sniffer ist ein Protokollanalysetool, mit dem es möglich ist den Datenverkehr im Netzwerk mitzuprotkollieren um beispielsweise etwas komplexeren Problemen auf den Grund zu gehen,
oder Protokolle die nicht gewünscht sind zu finden, und den Sender zu ermitteln. Unterstützt die Netzwerkkarte den sogenanten ’Promisciuous Mode’, ist es
mit Ethereal möglich alle Pakete der selben Collisous-Domain mitzulesen uns zu
speichern.
Ein Protokollanalyseprogramm, ein sog. ’Sniffer’ wird also eingesetzt, um den
Datenverkehr mit zu protokollieren, und ihn danach zu analysieren. Auf diese
Weise wird z.B. eine Überprüfung korrekter Firewall-Funktionen, sowie eine Suche nach unerlaubten Aktivitäten im Netzwerk, oder auch eine Netzwerkperformanceanalyse gemacht. Zur Analyse der Daten muss das Programm die gesammlten Daten natürlich interpretieren und verstehen können. Ethereal ist diesbezüglich
ein sehr mächtiges Tool, und versteht eine Vielzahl von Protokollen. Zu der großen
Vielzahl der verstanden Protokolle ist es mit Ethereal aber auch möglich, die gesammelten Daten zur späteren Verarbeitung für andere gängigen Netzwerktools
zu exportieren.
Capturen von Daten mit Ethereal
Das sogenannte ’capturen’ - also Sammeln von Paketen - mit Ethereal ist sehr
einfach, was man auch über die gesamte Handhabung von Ethereal sagen kann.
22
Um nun also Datenpakete mit Ethereal mit zu protokollieren uns zu sammeln,
geht man nach dem Start des Programms einfach auf ’Capture’ und anschließend
auf ’Start’. Ein kleines Fenster zeigt hierbei an, wieviele Pakete Ethereal mitgelesen hat, und die wichtigsten Protokolle sind hier ebenfalls aufgelistet. Durch
diese Fenster erhhält man also eine Übersicht wieviel Pakete gesammelt wurden,
und wieviel Pakete davon zu einem best. Protokoll zuzuordnen sind. Beim ’capturen’ vonPaketen besteht bei Ethereal auch die Möglichkeit, sich die gesammelten
Pakete im Hauptfenster von Ethreal in ’real-Time’ also in Echtzeit während des
Sammelns anzeigen zu lassen.
Abbildung 2.4: Ethereal Hauptfenster/Computer
Natürlich ist es mit Ethereal auch möglich die Daten zu filtern, ist man z.B. nur
an bestimmten Informationen interessiert, und möchte diese übersichtlicher dargestellt. Die ist bei Ethereal möglich durch eine Vielzahl von setzbaren Filtern.
Grundsätzlich gibt es 2 Methoden Filter anzuwenden. Eine Möglichkeit ist es,
erst einmal Daten zu sammeln und zu speichern, und danach auf diese Daten
die gewünschten Filter anzuwenden. Die andere Möglichkeit ist es, den oder die
gewünschten Filter schon vor dem capturen der Daten zu setzten. Dies hat den
Vorteil das Ethereal nun nur die Daten sammelt, die auch später analysiert werden
sollen. Somit zeichnet man also schon im Voraus eine viel geringere Datenmenge auf, und belastet auch sein System weniger. wodurch man auch über längere
Zeiträume Daten sammeln kann.
23
Beim setzten von Filtern mit Ethereal gibt es dabei kaum Grenzen. Es ist möglich
nach Empfänger oder Absender, nach Port oder Protokoll, und vielem mehr Filter
zu definieren. Beim setzten dieser Filter, ist es auch möglich diese Filterparameter
logisch miteinander mit ’and’ und ’or’ zu verknüpfen. Ein typisches Einsatzszenario eine Sniffers mit Filter wäre z.B. die Aufgabe ein Netzwerkredesign an einem
bestehenden und laufenden Netzwerk zu planen, mit der Aufgabe ein reines IP
Netzwerk zu realisieren. Bevor hier das Redesign durchgeführt wird, sollte sichergestellt werden, das es kein Programm mehr gibt, das z.B. IPX braucht. Hat man
das Redesign gemacht, und würde auf eine wichtige Anwendung stoßen, die ein
’nicht-IP’ Protokoll braucht, wäre dies ein Problem. Durch das setzten eine Filter,
welcher definiert nur ’nicht-IP’ Pakete zu sammeln wäre dieses Problem schon im
Voraus zu begegnen. Da es nicht viele ’nicht-IP’ Protokolle gibt, und durch den
Filter nur diese gesammelt werden, kann über einen sehr großer Zeitraum gesammelt werden. Somit kann man sich dann auch vor dem Redesign sicher sein, das
kein ’nicht-IP’ Protokoll mehr im Netz ist, das man vorher nicht entdeckt hat.
Paketanalyse
Ein Paket läßt sich mit Ethereal sehr schön analysieren, und Ethereal stellt das Paket sehr übersichtlich dar. Es besteht die Möglichkeit sich vom Anfang des Pakets
bis zum Ende des Pakets durchzuklicken, und es werden sämtliche Informationen
wie IP-Heeader,Flags, Source-Port, Destination-Port, Source-Ip, Destination IP,
und vieles mehr anschaulich dargestellt.
Abbildung 2.5: Ethereal Paketaufbau
Eine weitere sehr Nützliche Funktion von Ethereal ist ’follow TCP-Stream’. Nimmt
man ein TCP Paket der gesammelten Daten, und sagt Ethereal ’follow TCPStream’, sucht das Programm alle Pakete die zu diesem TCP-Stream gehören,
und zeigt diese gesammelt und übersichtlich dar. So ist es Möglich schnell und
einfach Kommunikationsbeziehungen in den gesammelten Daten zu erkennnen
24
und zu analysieren.
2.3 Szenario 3 - Kleine und Mittlere Unternehmen
Bei diesem Szenarion handelt es sich um LANs bei kleinen und mittleren Unternehmen (KMUs). Diese bestehen aus mehereren Subnetzen, die anhand der internen Anforderungen logisch aufgeteilt sind. Also beispielsweise ein oder mehrere
Subnetze für das Rechenzentrum und jeweils ein Subnetz für jede Abteilung.
Ein solche Firma kann natürlich auch mehrere Niederlassung haben, die eventuell
sogar weltweit verteilt sind. Somit ist in einer solchen Umgebung also auch mit
mindestens einer WAN-Anbindung zu rechnen, die über einen externen Anbieter zugekauft wird. Es ist heute davon auszugehen, daß es sich dabei um einen
Internet Service Provider (ISP) handelt, der entweder selbst die nötigen VPNVerbindungen anbietet, oder dem Kunden die Einrichtung der VPNs selbst überläßt.
Innerhalb einer KMU ist auf jeden Fall tiefergehendes Know-How im Bezug auf
Netzwerke zu erwarten, da meist festangestellte Mitarbeiter für die Wartung und
Überwachung der Netzwerks vorhanden sind. Es könnte sich aber auch um externe Dienstleister handeln, die diese Aufgabe übernehmen. Zudem ist ein starkes
Interesse vorhanden, das Netzwerk ständig zu überwachen. Je größer eine Firma
wird, desto mehr Umsatz beziehungsweise Gewinn wird in direkter Abhängigkeit
vom Netzwerk erzeugt. Fällt also ein solches Netzwerk aus, wird sich dies Sicher
auf die Umsatzsituation des Firma auswirken.
Bedingt durch diese Abhängigkeit, wird es in einem solchen Umfeld auch möglich,
höhere Ausgaben für die Netzwerküberwachung zu rechtfertigen. Diese Ausgaben
werden meist auch getätigt. Somit wird der Einsatz kommerzieller Produkte problemlos möglich. Zudem stehen finanzielle Mittel zur Schulung der Mitarbeiter
zur Verfügung. Oft ist es sogar der Fall, daß Mitarbeiter Schulungen besuchen
müssen, um sich innerhalb der Firma für bestimmte Aufgaben zu qualifizieren.
Die eingesetzten Produkte zur Netzwerküberwachung sollen innerhalb eines KMU
vor allem folgende Punkte sicherstellen beziehungsweise bieten:
• Es soll eine möglichst hohe Verfügbarkeit des Netzwerks und dessen Dienste garantiert werden, um mögliche Umsatz- oder Gewinneinbußen möglichst
zu verhindern oder zumindest möglichst gering zu halten.
25
• Die Überwachung soll möglichst zentral und umfassend geschehen, um die
Wege und Zeiten möglichst gering zu halten.
• Es muß eine flexible Alarmierung möglich sein, um typische Situationen
wie Urlaub oder Krankheit eines Miarbeiters zu ermöglichen. Es sollte also beispielsweise möglich sein, grundsätzlich eine Vertretung zu definieren, die zusätzlich zum eigentlichen Empfänger benachrichtigt wird. Zudem
sollte es möglich sein, Alarme von Folgefehlern automatisch unterdrücken
zu können. Ein Beispiel dafür wäre die Unterdrückung des Alarms eines
Serverausfalls, wenn der Switch, an dem der Server angeschlossen ist, defekt ist.
• Die Software sollte weiterhin dazu in der Lage sein, erste Anzeichen eines
auftretenden Problems frühzeitig zu erkennen. Das könnte beispielsweise
die Erkennung einer ansteigenden Fehlerrate an einem Port eines Switches
oder Routers sein. Eine solche Situation würde beispielsweise darauf hindeuten, daß ein Kabel oder der Port des Gerätes ausgetauscht werden sollte.
• Zudem sollte das Tool zusammen mit dem Netzwerk mitwachsen können,
wenn innerhalb der Firma neue Anforderungen entstehen. Werden also beispielsweise innerhalb des Firmennetzes VLANs eingeführt, so sollte das
Überwachungstool dazu in der Lage sein, auch VLANs überwachen zu
können - auch wenn bei der Anschaffung des Produkts noch keine VLANs
im Netzwerk existiert haben.
• Zu guter Letzt sollte ein solches Tools zudem in der Lage sein, Fehler
selbstständig möglichst vollständig zu analysieren oder zumindest einzugrenzen. Auf diese Weise kann ein solches Tool bereits bei der Erkennung
eines Fehlers mögliche Lösungsvorschläge machen beziehungsweise zumindest die Anzahl der möglichen Fehlerursachen auf ein überschaubares
Maß reduzieren. Auf diese Weise wird die Zeit, die zur Behebung eines
aufgetretenen Fehlers benötigt wird, auf ein absolutes Minimum begrenzt.
Die Produkte, die in diesem Szenario eingesetzt werden könnten, sind im Prinzip die gleichen, die auch im Home- oder WG-LAN eingesetzt werden könnnte. Allerdings wird im Umfeld eines KMU sehr wahrscheinlich die kommerzielle Variante gewählt werden. Einerseits besteht bei kommerziellen Produkten der
Möglichkeit von Support-Verträgen. Andererseits ist die Weiterentwicklung des
Tools relativ sichergestellt. Zudem besteht im Fall des totalen Versagens des Produkts gegebenenfalls die Möglichkeit, des Hersteller in die Haftung zu nehmen
und auf Schadensersatz zu verklagen.
26
Als zusätzliche Produktkategorie, die möglicherweise zu Einsatz kommen könnte seinen an dieser Stelle noch kurz vollwertige Netzwerkmanagement-Tools wie
Openview oder Netview erwähnt. Bei großen Netzen bietet sich der Einsatz einer kompletten Programm-Suite an, da eine reine Überwachung in einem solchen
Umfeld nicht mehr ausreicht. Hier sind dann noch zusätzlich Aufgaben wie Accounting oder Change-Management nötig, um den Überblick über ein sehr großes
Netz aufrecht zu erhalten. Da solche Tools aber nur am Rande für Überwachung
zuständig sind, soll hier nicht näher darauf eingegangen werden.
2.3.1 TKined / Scotty
Bei Scotty handelt es sich um ein Open-Source-Produkt, das in TCL/TK geschrieben wurde. Dabei handelt es sich um eine Script-Sprache, die einerseits zur Erstellung der GUI benötigt wird und andererseits die nötigen Netzwerkfunktionen
zur Verfügung stellt. Ursprünglich stammt Scotty aus der Unix-Welt. Es gibt allerdings auch Windows-Binaries.
Scotty stellt ein zu überwachendes Netzwerk als strukturierte Map dar. Diese Map
kann wahlweise manuell gezeichnet werden, oder mit Hilfe einer Auto-DiscoveryFunktion erstellt werden. Im gegensatz zu den anderen hier getesteten Tools ist
Scotty selbstständig dazu in der Lage, Router beziehungsweise Gateways zu erkennen. Diese Fähigkeit verlängert zwar den Discovery-Prozess auf ein Vielfaches
der Zeit, die andere Tools benötigen, dafür ist aber die Map nach der Discovery
vollständig und vor allem korrekt. Das bedeutet beispielsweise, daß die Map nach
der Discovery automatisch in Subnetze aufgeteile ist, die dann nach Wunsch gruppiert werden können.
Schon im Standardumfang stehen viele verschiedene Tools zur Verfügung, die
eingesetzt werden können. Diese Tools können grob in drei Kategorien unterteilt
werden:
• Discovery und Mapping
• Troubleshooting
• Monitoring und Überwachung
Da Scotty im Source-Code vorliegt und in einer relativ leicht verständlichen ScriptSprache programmiert ist, kann der Funktionsumfang natürlich beliebig erweitert
27
werden. Somit wird es möglich, fast beliebig viele spezifische eigene Erweiterungen in das Programm zu integrieren. Auf diese Weise ist Scotty auch in Umgebungen einsetzbar, wo Standardsoftware an ihre Grenzen stößt beziehungsweise
bereits überfordert ist. Solche Erweiterungen sind zwar mit personellem und damit finanziellem Aufwand verbunden, sind aber angesichts der nicht vorhandenen
Anschaffungskosten meist vetretbar.
Schulungen oder anderweitiger Support sind für ein Open-Source-Produkt natürlich
von Herstellerseite nicht erhältlich. In Newsgroups und Foren findet jedoch ein reger Austausch zwischen Nutzern statt. Mit Hilfe dieser Quellen sollten alle eventuell auftretenden Probleme mit diesem unkomplzierten Programm schnell und
zuverlässig lösbar sein. Zudem können diese Kommunikations-Plattformen als
Bezugsquellen für Erweiterungen genutzt werden.
Discovery und Mapping
Mit Hilfe dieser Tools können die Maps erstellt und bearbeitet werden. Dabei ist
grundsätzlich zwischen zwei verschiedenen Arten von Maps zu unterscheiden:
• logische Maps
• geographische Maps
Die logischen Maps repräsentieren ausschließlich den logischen (strukturierten)
Aufbau eines Netzes. Sie sagen allerdings nichts über den tatsächliche Aufstellungsort einer Komponente aus. Bei den meisten Netzwerken wird die logische
Map jedoch vollkommen ausreichend sein, da sich das Netz auf ein Gebäude oder
ein Firmengelände beschränkt. In solchen Fällen genügen im Allgemeinen Anmerkungen in der Map. Alternativ ist immer noch ein Netzplan vorhanden, mit
dessen Hilfe sich der tatsächliche Ort einer Komponente in Erfahrung bringen
läßt.
Die geographische Map macht hingegen nur bei Netzen Sinn, die über größere Bereiche - also beispielsweise landes- oder weltweit - verteilt sind, wie es beispielsweise bei Backbone-Betreibern oder Konzernen mit mehreren Niederlassungen
der Fall ist.
Die einzelnen Komponenten, die in einer Map erfaßt sind, lassen sich beliebig zu
Gruppen zusammenfassen. Es bietet sich natürlich an, die Gruppen nach sinnvollen Kriterien zu erstellen. Ein solches Kriterium wären zum Beispiel Subnetze. Die so erstellen Gruppen lassen sich beliebig auf der Map positionieren
28
und können auf- und zusammengeklappt werden. Im zusammengeklappten Zustand wird dann eine Gruppe nur noch durch eine ’Wolke’ symbolisiert, was dem
Überblick sehr förderlich ist. Die logischen Verbindungen zwischen den einzelnen
Komponenten gehen beim Gruppieren und zusammenklappen natürlich nicht verloren. Somit können jederzeit auch andere Kritereien - wie beispielsweise Clients
und Server - für die Gruppierung verwendet werden.
Der Map-Editor selbst ist leider ziemlich primitiv und nicht besonders intuitiv gestaltet. Daher ist er erst nach einer kurzen Einarbeitungszeit schnell und produktiv
bedienbar. Nach dieser Einarbeitungsphase kann die Bedienung aber sehr schnell
und zielgerichtet erfolgen. Sollte einem Benutzer die kombinierte Nutzung von
Maus und Tastatur nicht liegen, kann dies durch Änderungen am Source-Code
leicht behoben werden. Allerdings ist es genau diese Kombination von Maus- und
Tastaturkommandos, die eine schnelle Bedienung ermöglicht.
Troubleshooting
In Scotty sind verschiedene Arten von Troubleshooting-Werkzeugen realisiert, die
bei auftretenden Problemen genutzt werden können. Allen Werkzeugen ist gemeinsam, daß die Ergebnisse in Protokollfenstern dargestellt werden, deren Inhalt
als Datei gespeichert oder direkt per Mail verschickt werden kann. Diese Protokolle können dann beispielsweise als Anhang beziehungsweise Zusatzinformation
an das Abarbeitungsprotokoll eines Trouble-Tickets angehängt werden.
Die Troubleshooting-Tools bestehen grob aus drei Gruppen:
• Standard-Tools
• RPC-Tools
• SNMP-Tools
Die Standard-Tools bestehen aus Funktionen wie Ping, Traceroute und NSlookup. Einfach ausgedrückt handelt es sich also um die üblichen KommandozeilenProgramme, die bei auftretenden Problemen zuerst eingesetzt werden, um einen
groben Überblick über die Art des Problems zu erhalten. Es ist mit Hilfe dieser
Tools natürlich nicht möglich, genauere Informationen über aktuelle lokale Parameter eines Hosts zu erhalten.
Zu diesem Zweck können beispielsweise die RPC-Tools verwendet werden. Diese setzen auf dem abzufragenden Host natürlich einen laufenden Portmapper und
29
und einen entsprechenden, dort registrierten Dienst voraus. In vielen Umgebungen wird daher mit diesen Tools nur wenig anzufangen, da ein Portmapper aus
sicherheitsgründen heute nur auf Hosts läuft, auf denen er unbedingt nötig ist.
Von einem solchen Host lassen sich dann allerdings einige Informationen abfragen, die sonst nur per SNMP oder einen Remote-Login in Erfahrung zu bringen
wären.
Mit Hilfe der SNMP-Tools zum Troubleshooting kann jegliche Information über
einen Host abgefragt werden, die der dort laufende SNMP-Agent liefern kann.
Weiterhin können für alle Variablen, die mit Hilfe des auf dem Host laufenden
SNMP-Agent gesetzt werden können, neue Werte eingetragen werden.
Die SNMP-Tools setzen natürlich - wie die RPC-Tools auch - voraus, daß der
Host noch erreichbar ist. Die Erreichbarkeit sollte daher zunächst immer mit Hilfe
der Standard-Tools geprüft werden. Sollte ein Host nicht erreichbar sein, kann
mit Hilfe dieser Tools - wie oben bereits erwähnt - der Grund dafür zumindest
eingegrenzt werden.
Monitoring und Überwachung
Um Fehler feststellen zu können, denen dann mit Hilfe der Troubleshooting-Tools
auf den Grund gegangen werden kann, muß ein Netzwerk zunächst überwacht
werden. Und genau darin besteht eigentlich die Hauptaufgabe von Scotty. Die
Grundlage für alle Überwachungsfuntionen besteht aus einer Map. Für alle darin
enthaltenen Elemente können - abhängig vom Typ des Elements - verschiedene
Überwachungsfunktionen genutzt werden.
Dabei ist dringend darauf zu achten, den Überwachungsintervalle nicht zu niedrig einzustellen, da durch die Abfragen natürlich Traffic im Netz werzeugt wird.
Wenn eine entsprechend große Zahl an Hosts überwacht wird, dann können so
schnell mehrere Hundert bis Tausend KBit/s an Traffic entstehen.
Für alle Überwachungsfunktionen existieren mehrere Arten der Alarmierung:
• Anzeige in der Map durch Farbänderung und Blinken des Elements
• Popup-Fenster
• Eintrag in das Syslog
Diese Alarmierungsmethoden könnne beliebig kombiniert werden. Die Flexibilität wird bei Scotty durch externe Tools ermöglichst, die in der Unix-Welt gängig
30
sind. Speziell durch den Eintrag in das Syslog wird prinzipiell jede beliebige Art
der Alarmierung möglich. So könnte beispielsweise Logsurf eingesetzt werden,
um das Syslog in annähernd Echtzeit auf spezifische Einträge zu überwachen.
Logsurf wiederum kann dann nach der Erkennung eines bestimmten Alarms verschiedene Alarme auslösen, indem einfach die entsprechenden externen Programme gestartet werden. Es könnte sich dabei beispielsweise um den Versand einer
Mail oder einer Pager-Nachricht handeln.
Die einfachste Form der Überwachung bei Scotty besteht darin, einen Host in regelmäßigen Abständen per Ping (ICMP Echo Request) auf Erreichbarkeit zu überprüfen. Eine solche Überwachung erfordert weder auf dem überwachten noch auf
dem überwachenden Host einen nennenswerten Aufwand an Resourcen. Allerdings kann auf diese Weise auch nur festgestellt werden, ob der Host rein netzwerktechnisch erreichbar ist. Eine Kontrolle, ob irgendwelche Dienste, die auf einem Host laufen (sollten) noch erreichbar sind, ist auf diese Weise nicht möglich.
Scotty kann Systeme aber auch per SNMP überwachen. Auf diese Weise wird es
möglich, nicht nur die Erreichbarkeit eines Systems regelmäßig zu überprüfen,
sondern es besteht zusätzlich die Möglichkeit, bestimmte Betriebsparameter zu
überwachen. Solche Parameter sind zum Beispiel die CPU-Last oder die Auslastung der Netzwerkinterfaces. Die überwachten Parameter können auf Wunsch
auch als Diagramm dargestellt werden, um darin gegebenefalls frühzeitig einen
Trend zu erkennen. Zudem ist es möglich, Grenzwerte zu definieren, bei deren
Überschreitung ein Alarm ausgelöst wird.
2.3.2 WhatsUp Gold
WhatsUp Gold ist im Gegensatz zu Scotty ein kommerzielles Produkt der Firma
IPSwitch. Der Funktionsumfang entspricht grob gesehen in etwa dem von Scotty.
Allerdings handelt es sich um eine reines Windows-Programm und liegt natürlich
nicht im Source-Code vor.
Discovery und Mapping
Bei WhatsUp Gold werden die zu überwachenden Hosts ebenfalls in einer Map
dargestellt, die ebenfalls entweder manuell oder automatisch erzeugt werden kann.
Allerdings ist WhatsUp Gold nicht dazu in der Lage die logische Struktur zu erkennen und diese automatisch in die Map einzutragen. So erkennt WhatsUp Gold
bei der Auto-Discovery beispielsweise keine Gateways beziehungsweise Router
zwischen Subnetzen.
31
Allerdings erstellt WhatsUp Gold bei der Auto-Discovery über mehrere Subnetzte für jedes Subnetz eine eigene Map, die dann jeweils über eine zentrale Map
erreicht werden kann, ohne die entsprechende Datei explizit öffnen zu müssen.
Dieses Aufteilen von mehreren Subnetzen auf getrennte Maps erhöht bei großen
Netzen die Übersichtlichkeit. Zudem können für jede einzelne Map bestimmte Parameter wie Ansprechpartner oder Personen, die alarmiert werden sollen, getrennt
eingestellt werden. Somit können unterschiedliche Zuständigkeiten innerhalb einer Firma zumindest ansatzweise innerhalb des Programms beachtet werden.
Der Map-Editor selbst ist relativ komfortabel gehalten und kann sehr intuitiv bedient werden. Allerdings lädt er durch seine Zeichenfunktionen und die mitgelieferten Beispielmaps sehr stark zum SSpielenëin. Leider ist es mit dem Editor
nicht möglich, feste logische Verbindungen zu zeichnen, die beim Verschieben eines Hosts innerhalb der Map erhalten bleiben. Es ist also immer nötig, zunächst
den Host in der Map neu zu plazieren und danach zumindest das eine Ende des
Netzwerkkabelsän die richtige Position nachzuführen.
Troubleshooting
WhatsUp Gold bietet ebenfalls eine Palette von Tools zum Troubleshooting. Es
handelt sich im prinzip bis auf einige Einschränkungen um den gleichen Umfang wie bei Scotty. So sind Pings, NSlookups oder Whois-Abfragen ebenfalls
möglich. Allerdings fehlt die komplette Palette an RPC-Tools. Zudem sind die
Möglichkeiten, Troubleshooting per SNMP zu betreiben, relativ eingeschränkt,
da nur Abfragen möglich sind. Außerdem unterstützt das Programm nur die Standard MIB-2. Erweiterungen der unterstützten MIBs sind nicht möglich.
Die Troubleshooting-Tools sind nicht direkt in das Programm beziehungsweise
dessen Oberfläche integriert, sondern es handelt sich dabei um externe Zusatzprogramme. Es besteht somit zwar auch die Möglichkeit, diese Tools problemlos auf
Hosts anzuwenden, die nicht in einer Map eingetragen sind, dafür fehlt aber auch
der Komfort bei der Anwendung dieser Tools auf Hosts in der Map. Das bedeutet beispielsweise, daß jedesmal der Hostname beziehungsweise die IP manuell
eingegeben werden müssen.
Monitoring und Überwachung
Zur Überwachung von Hosts stehen mehrere Möglichkeiten offen. So ist es auch
bei WhatsUp Gold möglich, eine einfache Überwachung per Ping durchzuführen.
Diese ist natürlich wieder mit der Einschränkung verbunden, daß nur festgestellt
werden kann, ob der Host überhaupt erreichbar ist. Ob bestimmte Dienst noch
laufen ist auf diese Weise nicht feststellbar.
32
Weitergehende Funktionen, wie das Überwachen von SNMP-Variablen sind jedoch auch möglich. Da WhatsUp Gold jedoch nur die Standard MIB-2 unterstützt,
sind die Möglichkeiten eingeschränkt. Sollten von bestimmten SNMP-Variablen
mehrere Instanzen existieren, wie das beispielsweise bei Festplatten oder NetzwerkInterfaces der Fall sein kann, so muß die Instanz manuell angegeben werden.
WahtsUp Gold ist nicht dazu in der Lage, die Werte aller Instanzen anzuzeigen. Es
muß also bei jeder Variable bekannt sein, wieviel Instanzen exisitieren und welche
Instanz welchem Gerät zugeordnet werden muß - wobei sich letzteres zumindest
teilweise über andere Bereiche der MIB feststellen läßt.
Eine graphische Darstellung der Werte einer überwachten SNMP-Variable in einem Diagramm ist nur außerhalb der Map in einem eigenen Programmfenster
möglich. Sollen Variablen mehrerer Hosts als Diagramme angezeigt werden, so
ist für jeden dieser Hosts ein eigenes Fenster nötig. Dies ist eine Tatsache, die
definitiv nicht dazu geeigneet ist, die Übersichtlichkeit zu erhöhen.
Alarme
Alarmierungen können bei WhatsUp Gold bereits mit Hilfe der im Programm
integrierten Funktionen relativ flexibel durchgeführt werden. Die Palette der eingebauten Alarmierungsmethoden reicht von einer Darstellung innerhalb der Map
über Mails bis hin zu Pager-Nachrichten. Es ist zwar möglich die maximale Zahl
der Wiederholungen eines Alarms zu definieren, eine Eskalation oder eine Definition der Schwere des Alarms ist allerdings nicht möglich - beziehungsweise muß
mit externen Mitteln gelößt werden. Folgealarme, die aus einem bestehenden Fehler entstehen - beispielsweise das Nicht-Erreichen eines Servers nach dem Ausfall
eines Routers auf dem Weg zu diesem Server - lassen sich ebenfalls nicht unterdrücken. Es kann somit also geschehen, daß auf Grund eines kleinen Fehlers
eine sehr große Zahl an Alarmen bei den Verantwortlichen eintrifft. Damit wird es
unnötig erschwert, den eigentlichen Fehler anhand der Alarme auszumachen und
gezielt zu beheben.
Remote-Zugriff
WhatsUp Gold besitzt einen integrierten Webserver, der es ermöglicht, auf die
meisten Programmfunktionen auch per Browser zuzugreifen. Da gezielt auf JavaApplets und Ähnliches verzichtet wurde, ist eine aktiv vom Programm ausgehende Echtzeit-Alarmierung auf diese Weise nicht möglich. Gute Dienste leistet die
Möglichkeit des Remote-Zugriffs allerdings dann, wenn von ’unterwegs’ überprüft werden soll, ob eine ausgeführte Reparatur erfolgreich war und ein bestehendes Netzwerkproblem behoben wurde. Es genügt somit eine einzele Lizenz
des Programms. Zudem muß der Rechner beziehungsweise das Notebook, das
33
vor Ort eingesetzt wird, bei weitem nicht so leistungsfähig sein, wie es sein müßte,
wenn WhatsUp Gold vor Ort eingesetzt werden würde.
2.3.3 NAI´s Sniffer Pro 4.5
Das letzte Produkt in Szenario 3 ist Sniffer pro 4.5 von Network Associates. Sniffer pro 4.5 ist wie Ethereal ein Protokollanalysetool und wurde für eine 32-Bit
Architektur wie Windows 95/98 und Win NT entwickelt. Sniffer pro 4.5 kann
somit wie Ethereal Daten in real-timecapturen und auch das setzten einer sehr
großen Menge von Filtern ist möglich. Wodurch hebt sich nun Sniffer pro 4.5 also von Ethereal ab ? Hier gibt es eine vielzahl von nennenswerten Eigenschaften
von Sniffer pro 4.5. Zum einen ist hier die graphische Aufbereitung der Daten zu
nennen. Sniffer pro 4.5 bereitet die Daten sehr schön graphisch auf, so kann man
sich eine Kommunikationsmatrix in Form eines Kreises darstellen lassen in der
alle Kommunikationsbeteiligten aufgezeigt werden. Diese Matrix ist auch passenden zu verschiedenen Schichten des ISO-OSi 7 Schichtenmodels darstellbar
(z.B Layer 2 Matrix oder Layer 3 Matrix).
Abbildung 2.6: Ethereal Hauptfenster/Computer
Außerdem generiert Sniffer pro 4.5 aus den gesammelten Daten von selbst sehr
schöne Grafiken wie eine Grafik für die Top-Talker oder Top-Protokolle.
Sniffer pro 4.5 bietet als einziges getestetes Tool auch eine sehr Umfangreiche
und flexible Alarmierung. So kann es bei Überschreitung von vorab eingestellten
Grenzwerten Alarmmeldungen generieren und erfassen. Wenn Ausnahmebedingungen im Netzwerk ein sofortiges Eingreifen verlangen, kann die Alarmmeldung
34
Abbildung 2.7: Sniffer Hauptfenster/Computer
Abbildung 2.8: Sniffer Talker
an Beeper oder Pager, per E-Mail oder SNMP-Traps weitergeleitet werden. Durch
das definieren von verschiedenen Aktionen bei Alarmen sind auch verschiedene
Eskalationsstufen bei Alarmen möglich.
Aus den gesammelten Daten wird bei Sniffer Pro auch ein automatisches Aufzeigen von Anomalitäten unterstützt. Hier unterscheidet Sniffer pro dann zwischen
2 verschiedenen Anomalitäten. Zum einen ein ’Symptom’ - ein nicht kritischer
Vorfall wie z.B die Wiederübertragung eines Pakets - und zum anderen ein ’Diagnoses’ also ein kritischer Fehler der ein rasches Handeln erfordert.
Sniffer pro wird oft auch als de-facto Industriestandard bei den Protkollanalysetools bezeichnet. Dies liegt vor allem an der modularen Aufbauweise von Sniffer
35
pro. Sniffer pro selbst ist nur ein Teil großen Pakets. Wie schon beschrieben gibt
es beim sniffen von Daten immer das Problem wo man sich beim sammeln der
Daten befindet. Für Sniffer pro gibt es eine Vielzahl von Hardware und auch Softwaremodulen die sich speziell der Problematik des Sniffens in großen geswitchten
Netzwerken widmen.
Network Associates bietet also nicht nur den Sniffer pro 4.5 an sondern auch
Module wie den Sniffer portable, also einen portablen Sniffer um wenn nötig an
einer bestimten Stelle zu messen, und viele andere Module wie:
• Sniffer Basic
• Sniffer Wireless
• Sniffer Pro Wan Suite
• Sniffer Pro High Speed Suite (Gigabit und ATM)
• Sniffer Optical
• Sniffer Voice
• Sniffer Reporter
• Distributet Sniffer System DSS/RMON Pro
Auch die nötige Hardware zu Sniffen mit dem Sniffer Pro von Network Associates wird angeboten. So gibt es zum einen einen Full-Duplex-Pod, der z.B. in
den Uplink zischen 2 Switches gestellt wird, oder an den Analyseport eines Switches angesschlossen wird, und über genügend Bandbreite verfügt, um den vollen
Verkehr messen.
Sniffer Pro bietet also eine sehr Umfangreiche Palette um sein Netzwerk optimal zu überwachen. Ein Mit Sniffer Pro überwachtes Netzwerk könnte wie folgt
aussehen.
Abbildung 2.9: Sniffer Distributed
36
Kapitel 3
Produktmatrix
Als Anhang zu dieser Dokumentation finden Sie noch als Endergebnis unserer
Arbeit eine Produktmatrik die Ihnen bei der Entscheidung Hilfe geben soll.
37
Kapitel 4
Anhang
4.1 Quellen
• Sniffer Pro - www.sniffer.com
• MRTG - http://www.ee.ethz.ch/˜oetiker/webtools/mrtg/
• WSWatch - ftp://papa.indstate.edu/winsock-l/Misc-Winsock/ws watch.zip
• Scotty - http://wwwhome.cs.utwente.nl/ schoenw/scotty/
• WhatsUp Gold - http://www.ipswitch.com
• Netzwerkseite - http://www.netzwerkseite.de
4.2 Kontakte
Tom Gehring Friedrichstr. 3 78120 Furtwangen eMail: [email protected]
Tel.: 0172-7350841
Uwe Kretschmer Zum Schenkenbrünnle 1 77933 Lahr eMail: [email protected] Tel.: 0173-2777997
Jochen Sommer Friedrichstr. 3 78120 Furtwangen eMail: [email protected]
Tel.: 0172-6306815
38
Produktübersicht Netzwerküberwachungstools
WSWatch
Ethereal
Tkined-Scotty
Sniffer pro 3.5
What´s up Gold
Polling / Monitoring:
ICMP (ping ,traceroute, usw.)
●
○
●
○
●
SNMP
○
○
●
○
●
Analysen:
Last-Analyse
○
○
●
●
●
Protokoll-Analyse
○
●
○
●
○
Top-10 Protokolle
○
○
○
●
○
Top-10 Talker
○
○
○
●
○
Errors
○
●
●
●
●
Alarmfunktionen:
Flexible Alarmierung
○
○
Erweiterbar
○
●
Alarmkriterien (up, down,Last)
○
○
●
●
●
Hanhabung / Komfort:
Map / Auto-Discovery
●/○
○/○
●/●
○/○
●/●
Intuitive Bedienung
●
●
●
●
●
Management-Funktionen
○
○
○
○
●
Plattformen:
Win32
●
●
●
●
●
*NIX
○
●
●
○
○
Produktinfo:
Hersteller
John A. Junod
Open Source
Open Source
NAI
IPSwitch
http://wwwhome.cs. http://www.sniffer.com http://www.ipswitch.com
URL Ftp://papa.indstate. http://
utwente.
edu/winsock-l/Misc- www.ethereal.com
nl/~schoenw/scotty/
Winsock/ws_watch.
zip
Preis
Kostenlos
Kostenlos
Kostenlos
Ab 9.000 €
Ab 850 €
Anmerkungen:
Zu Siffer Pro Sehr viele Zusatzmodule und Hardware verfügbar, somit auch sehr breites Spektrum. Die in der Tabelle fehlenden Funktionen können
durch Zusatzmodule nachgekauft werden.

Netzwerk¨uberwachungstools

Transcrição

Documentos relacionados

7.¨Ubung ” Nebenläufige und verteilte Programmierung“

Preise zuz€glich 19% MwSt, sowie Frachtkosten Italien

stadthaus - Spanish Hot Properties

Aktueller Kursflyer - Food

Kurzfassung Büttiker Graf

Gymnasium Eversten Oldenburg Anmeldung Klasse 5

Projektautomatisierung

Gottes Wirken in meinem Leben

Frauenleiden intim (März 2013)

Installation des VP62 Codecs für die NSV Tools (http:///www