SNMP und andere Monitoring-Protokolle

Wir haben bereits an anderer Stelle ausführlich beschrieben, was SNMP ist, und fassen uns deshalb an dieser Stelle kurz. SNMP (Simple Network Management Protocol) gibt es schon seit langer Zeit. Die erste Version wurde 1988 offiziell als RFC (Request for Comments) veröffentlicht. Bei diesem zeitlichen Vorsprung ist es keine große Überraschung, dass sich SNMP zum Standard für das Monitoring und Konfiguration von Netzwerken entwickelt hat.

Das Konzept der Traps – also asynchroner Benachrichtigungen vom Agenten an Manager –  hat sich schnell durchgesetzt. SNMP trug maßgeblich dazu bei, das Konzept agentenbasierter Protokolle bekannt zu machen. Es wird von der IETF (Internet Engineering Task Force) definiert und wurde seit seiner Einführung in drei Hauptversionen weiterentwickelt. Die zweite Version ist nach wie vor weit verbreitet, obwohl sie weniger zuverlässig und sicher ist als die dritte Version.

Das Protokoll arbeitet mit dem Konzept von Managern und Agenten: Der Manager sammelt die Metriken von den verschiedenen Agenten. Diese können Diagnosedaten entweder selbstständig und ereignisbasiert per SNMP-Traps senden, oder auf eine Abfrage durch den Manager warten. In diesem Fall sendet der Manager einen SNMP-Get-Befehl, um Informationen von einem oder mehreren im Netzwerk verteilten Agenten abzufragen. SNMP verwendet für beide Kommunikationswege das UDP-Protokoll – Port 161 für (Abfragen) Get und 162 für Traps.

Beim Thema Sicherheit ist SNMP nicht das stärkste Protokoll. Ursprünglich wurden nur sogenannte „Community Strings“ implementiert. Dabei handelt es sich um vordefinierte Strings, die wie Passwörter funktionieren. Sie wurden im Klartext über das Netzwerk gesendet, was mehr als nur ein Sicherheitsrisiko darstellte. Mit der zweiten Version des SNMP-Protokolls führte man eine grundlegende Authentifizierung mittels Benutzername und Passwort ein. Sie soll sicherstellen, dass die Kommunikation zwischen den richtigen Agenten und Managern erfolgt. Die eigentliche Sicherheit der Daten selbst hat sich dadurch jedoch kaum verbessert, da SNMP diese noch immer größtenteils im Klartext überträgt. Erst durch die dritte und letzte Version von SNMP, bei der Authentifizierung und Verschlüsselung zum Einsatz kommen, ist die Sicherheit erhöht.

Die Hauptstärke von SNMP liegt in der großen Menge an Daten, die die auf den Geräten installierten Agenten bereitstellen. Die über SNMP zugänglichen Variablen sind in Hierarchien organisiert. Sie werden als MIB (Management Information Base) definiert und beschreiben die Struktur der von einem System abrufbaren Daten. Die Hierarchien bestehen aus verschiedenen OIDs (Object Identifiers), die jeweils eine Variable darstellen, die die SNMP-Agenten lesen und senden können. OIDs sind kein spezifischer Bestandteil von SNMP, sondern ein internationaler Standard, um jedes Objekt oder Konzept in der Informatik zu definieren.

Die größte Stärke von SNMP liegt in seiner weiten Verbreitung. Es ist deutlich einfacher, Geräte zu überwachen, die das Protokoll unterstützen, da man keine zusätzliche Software darauf installieren muss. Bei anderen Monitoring-Protokollen ist dies selten der Fall, da sie entweder nur bestimmte Betriebssysteme unterstützen oder Hersteller sie nicht – wie es bei SNMP häufig der Fall ist – standardmäßig auf ihren Geräten vorinstalliert haben. Dank der breiten Unterstützung durch die Hersteller von Netzwerkhardware ist SNMP in vielen Fällen die einfachste Lösung für die Einrichtung eines Monitorings.

SNMP-Traps sind zwar die bekannteste Betriebsart, in der Praxis wird SNMP vor allem für das Polling-basierte Monitoring mittels Get verwendet. Beide Methoden haben ihre Daseinsberechtigung sowie Stärken und Schwächen.

SNMP ermöglicht es den IT-Teams, unter anderem Informationen zur Kühlung, Spannung oder Temperatur abzurufen beziehungsweise Benachrichtigungen zu erhalten, was mit anderen Monitoring-Protokollen oft nicht möglich ist. Beim Server-Monitoring ist die Kenntnis des Gesundheitszustands der Hardware für die Aufrechterhaltung einer funktionierenden Infrastruktur unerlässlich.

In der Regel ermöglicht SNMP die konstante Erfassung von Metriken über zahlreiche Hosts. Diese Metriken lassen sich zentralisieren und später analysieren oder von einer Monitoring-Software, die SNMP unterstützt, nahezu in Echtzeit überprüfen. Da SNMP sehr umfassend ist, ist es häufig die erste Wahl von Netzwerk-Admins, um mit dem Monitoring zu beginnen.

Syslog dient in erster Linie dem Sammeln von Logs auf Unix-ähnlichen Systemen. Im Gegensatz zu den meisten anderen in diesem Artikel behandelten Protokollen ist Syslog plattformspezifisch.

Syslog gilt als Standard für die Erfassung von Applikations- und Geräte-Logs unter Unix und seinen Nachfolgern. Ursprünglich von Eric Allman in den frühen 1980er Jahren als ein Log-System für den E-Mail-Server Sendmail entwickelt, funktionierte es so gut, dass andere Unix-Applikationen begannen, es zu unterstützen. Damit begann die Dominanz von Syslog auf diesen Systemen.

>Heutzutage ist es auf vielen Unix-ähnlichen Systemen in Form einer seiner Weiterentwicklungen vorhanden (Rsyslog, syslog-ng). Seit einigen Jahren wird es jedoch langsam durch das Journal von systemD verdrängt.

Syslog überträgt Logs. Es sendet das, was es von Services und Applikationen erhält an eine Quelle und ein Ziel, die beide konfigurierbar sind. Praktisch gesehen wird eine Log-Nachricht (definiert in RFC3164) erstellt, die zwei Teile enthält: den TAG und den CONTENT. Später teilte man den TAG-Teil in mehrere Teile auf. Das Kernkonzept besteht jedoch darin, dass der TAG den Namen des Prozesses oder Programms enthält, der die Nachricht erzeugt, und der CONTENT die dazugehörigen Details.

Syslog dient nicht nur dazu, Logs weiterzuleiten, sondern ist auch ein System, um die Logs zu kategorisieren und anschließend zu analysieren. Syslog hat einen numerischen Code von 0 bis 23 eingeführt, der "facility" genannt wird und jedem Log beigefügt ist. Er dient zur Identifizierung des Ursprungs des jeweiligen Logs. 0 steht für Meldungen auf Kernel-Ebene, 1 für Benutzermeldungen, 2 für Meldungen des Mailsystems usw. Auf diese Weise können IT-Teams die Logs leicht filtern und schneller finden, was sie interessiert.

Ein weiterer numerischer Code, diesmal von 0 bis 7, steht für die Kritikalität. 0 ist das kritischste Level – auch als Notfall bezeichnet –, während 7 nur für die Fehlersuche Anwendung findet.

Syslog unterstützt, wenn auch nur rudimentär, das interne Filtern von Logs. Es ermöglicht die Verwendung von regulären Ausdrücken, um die Masse an Logs zu durchforsten. So lässt sich genau das finden, was für Monitoring-Zwecke notwendig ist.

Syslog befasst sich mit Logs, die oft eine größere Bandbreite an Daten enthalten und standardmäßig historisch sind. Es ist daher leistungsfähiger als viele Netzwerk-Monitoring-Protokolle. Wenn Sie eine umfangreiche historische Übersicht mit vielen Details benötigen, ist eine Protokollverwaltungssoftware wie Syslog die richtige Wahl.

Es empfängt die Logs von vielen Prozessen und kann diese an verschiedene Ziele senden. In der Regel handelt es sich hierbei um eine lokale Datei oder einen entfernten Syslog-Server. Ein lokales Debugging ist auch über die Konsole möglich. Developer-Teams und Admins nutzen diese Funktion gleichermaßen, um die Ursache für die Fehlfunktion eines Services oder einer Applikation schnell zu ermitteln.

Die Fehlersuche bei bestimmten Services anhand von Logs ist eine der vielen Aufgaben von IT-Teams. Syslog schafft einen Raum, in dem sich diese Logs sammeln und analysieren lassen.

Ganz so einfach stellt es sich jedoch nicht immer dar. Syslog entstand zunächst aus einer einzigen Applikation, ehe viele andere damit begannen, es auf eigene Faust zu unterstützen – ohne sich dabei an einen Standard zu halten. Daher gaben sie Logs aus, die vom ursprünglichen Format abwichen. Die unterschiedlichen Arten, wie eine Applikation Logs erstellt, ist die größte Schwierigkeit von Syslog. Es ist kompliziert, Logs zu analysieren, die unterschiedlich formatiert sind. Die ursprüngliche Idee, die Meldungen jeder Applikation zu vereinheitlichen, ist demnach gescheitert.

Das macht Syslog jedoch nicht unbrauchbar. Es macht es nur komplexer, die für das Monitoring notwendigen Informationen zu finden. Auf die ursprüngliche Version folgten verschiedene Implementierungen, mit dem Ziel, die Probleme zu beheben und das Protokoll zu verbessern. Heutzutage ist Syslog auf vielen Linux-Systemen veraltet und wird durch die Journaling-Fähigkeiten von systemD abgelöst.

ICMP (Internet Control Message Protocol) ist ein 1981 entwickeltes Protokoll, das dazu dient, Statusinformationen und Fehlermedlungenin TCP/IP-Netzwerken auszutauschen oder die Verbindungen zu bestimmten IP-Zielen zu prüfen (Ping). Es ist ein integraler Bestandteil des größeren IP-Protokolls und arbeitet auf der Netzwerkschicht (Network Layer) des OSI-Modells.

ICMP benutzt IP als Kommunikationsbasis, indem es sich als Protokoll einer höheren Schicht interpretiert. Das heißt, ICMP-Pakete sind in IP-Pakete eingekapselt. Der Typ eines ICMP-Pakets wird durch ein 8-Bit-Feld am Anfang des Headers angegeben. Direkt danach folgt ein weiteres 8-Bit-Feld, das den Code definiert. Die Kombination aus Typ und Code klassifiziert das jeweilige ICMP-Paket. Theoretisch könnte es 256 solcher Pakete geben, doch die meisten davon sind veraltet oder nicht vergeben. Tatsächlich sind 43 Typen offiziell klassifiziert. Von diesen werden nur wenige Kombinationen aus Typ und Code in der Praxis häufig verwendet.

Üblich sind Typ 8, Code 0 (Echo Request) und Typ 0, Code 0 (Echo Reply). Sie werden häufig von dem Dienstprogramm "ping" verwendet und einfach als “pingen” bezeichnet. Dabei wird mit einem Echo Request eine ICMP-Nachricht an eine IP-Adresse gesendet. Ist der Ziel-Host erreichbar und so konfiguriert, dass er auf solche Anfragen antwortet, was oft durch Firewalls blockiert wird, erfolgt eine Antwort in Form eines ICMP Echo Reply. In diesem Fall funktioniert die Verbindung. 

Bleibt die Antwort aus, ist der Host entweder nicht erreichbar oder ICMP-Anfragen werden auf dem Wet, meist durch eine Firewall, verworfen.

Wenn ein Host auf dem Weg zu einer Adresse keine Route zu ihr finden kann, antwortet er mit einer ICMP-Nachricht vom Typ 3, Code 1– Destination Unreachable. Innerhalb der ICMP-Meldungen von Typ 3 gibt es 15 weitere Codes, die jeweils die Gründe dafür angeben, warum ein Host nicht antwortet. Durch die Analyse dieser Codes lässt sich mit ICMP ein grundlegendes Netzwerk-Monitoring durchführen.

Ein weiterer wichtiges Anwendungsgebiet von ICMP ist das Kommandozeilen-Tool "traceroute" (oder "tracert" auf Windows-Systemen). Es ermöglicht das Nachverfolgen des Pfads von einer Quelle zu einem Ziel, indem es gezielt ICMP-Pakete einsetzt. Jeder auf dem Weg liegende Host reduziert einen Wert im IP-Header – das sogenannte TTL-Feld (Time to Live) –, das bei traceroute initial auf 1 gesetzt wird. Erreicht dieser Wert den Wert 0, wird das Paket verworfen und ein ICMP-Fehler zurückgeschickt. 

Anhand der Funktionsweise von ICMP lässt sich ein Hauptanwendungsfall leicht erkennen: Es wird verwendet, um Hosts im Netzwerk anzupingen und anhand ihrer Antworten mögliche Probleme zu erkennen.   Im Bereich des Netzwerk-Monitorings ist dies der wichtigste Einsatzzweck von ICMP. 

Ein zweiter, nicht weniger bedeutender Einsatzbereich ist das Tool traceroute, das ICMP verwendet, um den kürzesten Pfad zu einem Ziel zu ermitteln, die Latenz zu messen und Routing-Probleme aufzudecken. 

Mit Ping und Traceroute bietet ICMP somit eine einfache, aber wirkungsvolle Methode, um schnell und effizient festzustellen, welche Teile in einem Netzwerk funktionieren – und welche nicht.  Infrastruktur-Engpässe lassen sich etwa durch traceroute identifizieren, wenn ein überlasteter Host nicht mehr korrekt auf ICMP-Anfragen reagiert. Solche Probleme lassen sich mit einem einzigen Befehl innerhalb von Sekunden sichtbar machen.

Eine der Einschränkungen von ICMP besteht darin, dass das „Warum“ eines Netzwerkproblems oft nur angedeutet, aber nicht ausdrücklich erklärt wird. Das Protokoll ist nicht so komplex wie andere und eher auf eine schnelle Fehlerbehebung als auf die umfassende Erfassung von Metriken ausgerichtet. Daher sind weitere Untersuchungen notwendig, um die Ursachen eines Problems zu verstehen. Trotzdem ist ICMP für jeden Netzwerkadmin eine unschätzbare Erkenntnisquelle. 

NetFlow ist eine vergleichsweise alte Technik zur Netzwerküberwachung, die 1996 intern bei Cisco entwickelt wurde. Sie erfasst IP-Datenverkehr beim Eintritt und Austritt aus einer Schnittstelle und ist – ähnlich wie SNMP – speziell für das Netzwerk-Monitoring konzipiert.

Bis zur Version 5 war das Protokoll nur für Cisco-Geräte bestimmt. Heute haben viele Netzwerkhersteller eigene Implementierungen in ihren Routern und Switches. Diese basieren zwar auf Ciscos ursprünglicher Version, treten jedoch unter eigenen Namen auf, etwa Jflow, NetStream, Cflowd, Rflow und andere. NetFlow kann SNMP in Teilen ersetzen, da es ebenfalls auf vielen Netzwerkgeräten wie Routern und Switches verfügbar ist, auch wenn der Einsatzzweck sich unterscheidet.

Die NetFlow-Architektur basiert auf der Annahme, dass ein "Collector" existiert, der die von verschiedenen Geräten gesammelten Informationen empfängt und analysiert. Bei diesem Collector handelt es sich in der Regel um einen Server, der sich im selben Netzwerk wie die NetFlow-fähigen Router und Switches befindet. Ein "Exporter", in der Regel ein auf einem Netzwerk-Host installierter Agent, aggregiert die erfassten Pakete und stellt sie dem Collector zur Verfügung.  Die eigentliche Analyse übernimmt eine Analyse-Applikation, die die vom Collector gesammelten Datenflüsse auswertet.

NetFlow definiert einen Flow als eine Abfolge zusammenhängender Pakete zwischen einer Quelle und einem Ziel. Jeder Flow wird durch sieben Merkmale beschrieben: Quell- und Ziel-IP-Adresse, verwendete IP-Protokollversion, Quell- und Ziel-Ports (bei TCP/UDP) und der IP Type of Service (ToS). Diese Flows stellen also eine Zusammenfassung einer Verbindung dar, eines Datenfluss von A nach B. Durch das Sammeln und Analysieren dieser Flows kann ein Netzwerkadmin Engpässe, Störungen oder größere Probleme in einem Netzwerk erkennen.

sFlow steht für "sampled flow" – und der beschreibt bereits die Funktionsweise des Protokolls. Es handelt sich um einen herstellerübergreifenden Standard zur Paket-Exportierung auf Schicht 2 des OSI-Models. 

Ursprünglich von der InMon Corp entwickelt, wird sFlow heute vom sFlow.org-Konsortium gepflegt und weiterentwickelt. Aktuell wird sFlow von verschiedenen Herstellern von Netzwerkgeräten unterstützt, mit einer Ausnahme: Viele Anbieter von Netzwerk-Management-Software unterstützen sFlow bislang nicht. 

Anders als der Name vermuten lässt – und im Gegensatz zu NetFlow – kennt sFlow kein eigentliches Konzept von “Flows”. Stattdessen basiert sFlow auf dem Sampling von Paketen, die auf einem Gerät der OSI-Schicht 2 (etwa einem Switch oder Router) mit installiertem sFlow-Agenten, oder höher verarbeitet werden.

sFlow liefert somit nur ein Teilbild des Netzwerkverkehrs, während NetFlow nahezu den gesamten Verkehr erfasst. 

Konkret führt sFlow zwei Arten von Stichproben durch:

• Flow Samples entstehen durch zufälliges Erfassen einzelner Pakete oder Anwendungsoperationen.

• Counter Samples basieren auf zeitgesteuertem Auslesen von Zählern, etwa zur Auslastung von Schnittstellen. 

Durch diese Kombination liefert sFlow einen kompakten, ressourcenschonenden Überblick über das aktuelle Netzwerkgeschehen – ideal für Umgebungen, in denen hohe PErformance und geringe Last beim Monitoring benötigt werden.

Das eigentliche Paket-Sampling wird wie folgt durchgeführt: Immer wenn ein Paket an einer Schnittstelle eintrifft, entscheidet der sFlow-Agent, ob es erfasst wird oder nicht. Diese Entscheidung basiert auf einem internen Zähler, der bei jedem eingehenden Paket heruntergezählt wird. Sobald der Zähler 0 erreicht, wird ein Sample genommen und als sFlow-Datagramm zur Analyse an einen zentralen Server gesendet. Dies ist der sFlow-Kollektor, das Pendant zum NetFlow-Kollektor.

Die Sampling-Rate der Pakete wird vom IT-Team festgelegt. Je höher der Anteil der gesampelten Pakete, desto genauer ist das Monitoring. Allerdings steigt damit auch die erzeugte Datenmenge und somit die Netzwerklast durch Monitoring-Daten.

Die sFlow-Daten werden als UDP-Paket über Port 6343 übertragen. Ein möglicher Datenverlust durch die Verwendung von UDP statt TCP wird dabei bewusst in Kauf genommen, da eine geringe Anzahl verlorener Samples das Gesamtbild kaum verfälscht. 

IPFIX (Internet Protocol Flow Information eXport) ist der direkte Nachfolger von NetFlow. Es entstand aus der Notwendigkeit heraus, ein offenes Protokoll für den Export von Flow-Informationen von unterstützten Geräten zu haben. NetFlow gehört Cisco und ist trotz weit verbreiteter Implementierungen durch andere Hersteller weiterhin ein proprietäres Protokoll. IPFIX wurde von der IETF auf Basis von Version 9 des NetFlow-Protokolls standardisiert, sodass die beiden Protokolle eng miteinander verwandt sind.

IPFIX definiert einen herstellerunabhängigen Standard für die Strukturierung und Übertragung von IP-Flow-Informationen – also wie diese Daten vom Exporter zum Collector übermittelt werden sollen. 

IPFIX funktioniert ähnlich wie NetFlow, beinhaltet jedoch einigie zusätzliche Schritte und ist insgesamt flexibler aufgebaut. . Zunächst kommen an einem oder mehreren Observation Points sogenannte Metering Processes zum Einsatz.  Diese Prozesse erfassen und analysieren den beobachteten Netzwerkverkehr, filtern und aggregieren die Informationen und erzeugen daraus sogenannte Flows. Sie sind vergleichbar mit dem, was bei NetFlow die Exporter erledigen.  Ein Exporter fasst mehrere Observation Points zu einer Observation Domain zusammen und überträgt die generierten Flows per IPFIX an einen oder mehrere Kollektoren, die wiederum für die Auswertung der gesammelten Daten zuständig sind. 

Die Architektur von IPFIX ist sehr flexibel. Das bedeutet, dass es keine Begrenzung hinsichtlich der Anzahl der Exporteure und Kollektoren gibt. Ein einzelner Exporter kann Daten an mehrere Kollektoren senden, oder viele Exporter liefern Daten an einen gemeinsamen Collector. 

In IPFIX sendet jeder Exporter in regelmäßigen Abständen IPFIX-Nachrichten an die konfigurierten Empfänger. Anders als viele anderen Flow-basierte Protokolle kann IPFIX dabei sowohl TCP als auch UDP verwenden – bevorzug jedoch SCTP (Stream Control Transmission Protocol). Dabei handelt es sich um ein zuverlässiges Transportprotokoll mit integrierter Unterstützung für Multiplexing und Multi-Streaming.

Eine wichtige Neuerung in IPFIX ist die Einführung von Templates zur Strukturierung von Daten. Sie definieren das Format der übermittelten Flows und machen das Protokoll erweiterbar – Nutzer können eigene Felder und Datentypen definieren, was besonders bei herstellerübergreifenden Umgebungen von Vorteil ist. Templates ermöglichen es, unterschiedliche Implementierungen verschiedener Anbieter effektiv zu handhaben. 

SSH steht für "Secure Shell Protocol" – und bereits der Name macht deutlich, dass es um Sicherheit geht. Es wurde 1995 als eine sichere Alternative zu Login-Protokollen wie rlogin, Telnet und FTP entwickelt. Diese funktionierten zwar technisch zuverlässig, boten aber keinerlei Schutzmechanismen. Das führte zu Sicherheitsrisiken, die zwar ursprünglich als vernachlässigbar galten, sich letztendlich aber als untragbar erwiesen. Das ursprüngliche Ziel von SSH war somit nicht das Monitoring von Geräten, sondern der sichere Zugriff per Login.  Monitoring kann zwar nach dem Verbindungsaufbau erfolgen, steht aber nicht im Mittelpunkt des Protokolls. 

SSH verbreitete sich rasch auf allen wichtigen Betriebssystemen, einschließlich eingebetteter Systeme, und Netzwerkgeräten. Als offenes Protokoll unter der IETF hat SSH zahlreiche Weiterentwicklungen hervorgebracht, darunter: 

• SCP (zum Kopieren von Dateien), 

• SFTP (eine sicherere FTP-Alternative), 

• FASP (für performante  Datenübertragung), und weitere Protokollvarianten, die auf SSH aufbauen. 

Die Hauptaufgabe von SSH besteht darin, den sicheren Remote-Zugriff auf ein System oder Service zu ermöglichen. Es unterstützt eine Reihe von Authentifizierungsmethoden, die den IT-Teams Zugriffsrechte auf einem entfernten Host geben.

Die einfachste, aber am wenigsten sichere Methode ist die klassische Benutzer/Passwort-Authentifizierung. Deutlich verbreiteter ist jedoch die Authentifizierung über öffentliche Schlüssel:  Dabei wird ein kryptografisches Schlüsselpaar lokal erzeugt und dem SSH-Server zur Verfügung gestellt. Beim Login gleicht der Server die Schlüssel ab und gewährt nur bei Übereinstimmung den Zugang.

Ein ähnliches Verfahren nutzt die Host-basierte Authentifizierung, bei der jedoch nicht der Benutzer, sondern das gesamte Quell-Gerät über Schlüssel authentifiziert wird.  Weitere Verfahren sind:

• Keyboard Interactive und Challenge-Response, bei denen ein einmaliger Authentifizierungsvorgang durch manuelle Eingabe (z. B. eines Einmalpassworts) erfolgt,

• GSSAPI/Kerberos, wodurch sich Nutzer an SSH-fähigen Systemen authentifizieren können, ohne jedes Mal ein Passwort eingeben zu müssen – sofern ein entsprechender Kerberos-Server vorhanden ist.

All diese Methoden lassen sich über die Konfigurationsdatei des SSH-Servers gezielt aktivieren oder deaktivieren. Aus Sicherheitsgründen empfiehlt es sich, nur die wirklich benötigten Verfahren zuzulassen, um potenzielle Angriffsflächen zu minimieren.

Nach erfolgreicher Authentifizierung wird eine Shell auf dem entfernten System geöffnet, die dann wie eine lokale Umgebung genutzt werden kann – mit den Rechten, die dem jeweiligen Benutzer auf dem Zielsystem zugewiesen sind.

Im Gegensatz zu klassischen Monitoring-Protokollen sammelt SSH keine Daten automatisch. Es bietet lediglich einen sicheren Weg, um aus der Ferne auf Systeme zuzugreifen, wobei es ein hohes Maß an Rechten gewährt. Daher ist SSH kein Netzwerk-Monitoring-Protokoll, aber dennoch äußerst nützlich bei der Fehlersuche in Systemen.

Der Zugriff mit vollen Rechten auf einen fehlerhaften Host bietet IT-Teams nicht nur eine volle Kontrolle, sondern auch die Möglichkeit zur Analyse und Fehlerbehebung aus erster Hand.  Alles, was auf dem entfernten Gerät verfügbar ist, lässt sich – bei ausrechenden REchten – auch über SSH erreichen: etwa das Neukonfigurieren einer fehlerhaften Datenbank, das Zurücksetzen einer Firewall-Regel oder die Behebung fehlerhafter Installationen. 

SSH gewährt also mächtige Eingriffsrechte, obwohl es sich um ein überwiegend manuelles Werkzeug handelt, das zudem über keine Funktionen wie  automatisches Sampling, Polling oder Analysen bietet. SSH kommt jedoch dann zum Einsatz, wenn man tief in das Innere eines Systems vordringen muss

Mit großer Macht kommt bekanntlich auch große Verantwortung. SSH ist da keine Ausnahme. Wer die volle Kontrolle über ein Remote-Gerät hat, kann es ebenso leicht fehlkonfigurieren. Ein Risiko, das bei anderen Protokollen wie SNMP oder Flow-basierten Ansätzen deutlich geringer ist.

Zudem erfordert SSH eine längere Einrichtungszeit: Schließlich müssen erst Schlüssel erzeugt und verteilt, Benutzerkonten angelegt und Berechtigungen konfiguriert werden. Die Installation von SSH selbst ist jedoch einfach, da es von allen gängigen Betriebssystemen unterstützt wird.

WMI steht für Windows Management Instrumentation und ist eine Erweiterung des Windows-Driver-Modells. Es stellt eine Schnittstelle zur Erfassung von Informationen über einen Windows-Host bereit. Darüber hinaus bietet WMI eine API mit der sich Windows-Systeme über Skriptsprachen wie VBScript oder PowerShell erweitern und steuern lassen. 

Es ist die Microsoft-Implementierung des WBEM-Standards (Web-Based Enterprise Management) und gehört somit zur Familie von WBEM-kompatbiolen Implementierungen, die plattformübergreifend einheitliches System-M;anagement ermöglichen sollen. WMI selbst ist jedoch ausschließlich unter Windwos verfügbar.

WMI funktioniert aus logischer Sicht wie andere agentenbasierte Monitoring-Lösungen. Eine Komponente auf dem Zielsystem verwaltet sogenannte Namespaces und stellt Informationen bereit, die von sogenannten WMI-Clients (oder Consumers) abgefragt werden. Diese sind verleichbar mit einem Server, der Daten von einem entfernten Agenten abruft. 

 WMI-Komponenten sind seit 2000 auf allen Windows-Versionen standardmäßig enthalten, können aber auch auf älteren Versionen nachinstalliert werden.

Damit WMI funktioniert, muss es auf dem Zielsystem entsprechend eingerichtet werden. Dies erfordert, dass eine Reihe von Ports geöffnet sind. Da WMI auf andere Windwos-Dienste wie NetBIOS, SMB und RPC angewiesen ist, müssen auch deren Ports für den WMI-Client erreichabr sein. WMI selbst nutzt einen dynamischen Portbereich: 

• 1025-5000 beiWindows 2000, XP und Server 2003,

• 49152-65535 beiWindows 2008, Vista und neueren Versionen.

• alternatriv lässt sich WMI auch auf einen festen Port konfigurieren, was insbesondere in sicherheitskritischen Umgebungen empfohlen wird. 

Sobald WMI eingerichtet ist,, bietet es eine umfangreiche Infrastruktur zur Systemverwaltung. Es ist also mehr als nur ein Monitoring-Protokoll. Daten werden mithilfe von Skripten oder Anwednungen abgefragt, die in verschiedensten Programmiersprachen geschrieben sein können, etwa PowerShell, Visual Basic, C++, C# oder über ActiveX-Steuerungen. 

Die eigentliche Abfrage erfolgt entweder via PowerShell oder über WQL (WMI Qery Language) – eine SQL-ähnliche Abfragesprache, die speziell für WMI entwickelt wurde. Auf diese Weise lassen sich nicht nur Informationen auslesen, sondern auch Verwaltungsaufgaben durchführen, z. B.: das Starten von Diensten, das Ändern von Konfigurationen oder das Installieren von Software. 

RMON (Remote Network Monitoring) ist eine Erweiterung von SNMP, die ursprünglich von der IETF entwickelt wurde, um Informationen der OSI-Schichten 1 und 2 in Ethernet- und Token-Ring-Netzwerken zu überwachen. Dabei handelt es sich also um Bereiche, die SNMP selbst nicht abgedeckt hat. 

Spätere Versionen von RMON erweiterten den Funktionsumfang auf die Netzwerk- und Anwendungsschicht, sodass eine umfassendere Überwachung möglich wurde. 

Für gewitchte Netzwerke exisitert mit SMON (Switch Monitoring) bereits eine spezielle Variante. Für leistungsstarke Netzwerke mit hohem Durchsatz gibt es die Erweiterung HCRMON (High Capacity RMON), die an die Anforderungen moderner Netzwerkinfrastrukturen angepasst ist. 

RMON ist auf vielen High-End-Switches und -Routern als zusätzliches Protokoll neben dem SNMP-Agenten vorhanden.

RMON unterscheidet sich funktional nicht grundlegend von SNMP. erweitert dieses jedoch um detaillierte Überwachungsfunktionen auf tiefere Ebenen des Netzwerks. 

Im RMON-Modell werden die Agenten als "Probes" bezeichnet und fungieren als Server, die Netzwerkdaten erfassen, analysieren und an die netzwerkseitigen Management-Anwendungen weiterleiten, die als Clients agieren. Diese Beziehung folgt dem klassischen Client-Server-Prinzip. 

Viele SNMP-fähige Geräte lassen sich durch einfache Softwareerweiterungen zu RMON-fähigen Geräten machen. In anderen Fällen ist jedoch ein zusätzliches Hardwaremodul, eine sogenannte “Hosted” Probe”, erforderlich, das physisch in das Gerät integriert werden muss. 

Ist RMON einmal aktiviert, überwacht es den Datenverkehr direkt auf dem Gerät, auf dem es installiert ist – darunter Überlastungen, Paketverluste und übermäßige Kollisionen. In der Regel befindet sich nur ein RMON-Probe pro Subnetz, die zentrale Daten zur Netzwerkqualität sammelnt. 

> Die von der Probe gesammelten Daten können von einem SNMP-Agenten verwendet werden oder eine SNMP-Trap auslösen, wenn bestimmte Bedingungen erfüllt sind. 

RMON unterteilt seine Überwachungsfunktionen in neun Gruppen, die jweils verschiedene Aspekte des Netzwerkverkehrs abdecken. Diese GRuppen reichen von: 

• Netzwerkstatistiken,

• über die Abtastrate der Daten,<

• MAC-Adressen-Erkennung, 

• bis zu einer Ranking-Funktion, die Hosts nach deren Traffic-Volumen und ihrer Nutzung einstuft. <

Durch diese strukturierte Erfassung liefert RMON detaillierte Einblicke in das Verhalten einzelner Netzwerkteilnehmer und ist besonders nützlich für die Langzeitüberwachung und Fehlerdiagnose.

Suricata ist ein Open-Source-System zur zur Intrusion Detection (IDS) und Intrusion Prevention (IPS), das von der Open Information Security Foundation (OISF) entwickelt wurde. Die erste Version erschien im Jahr 2010und ist für alle gängigen Betriebssysteme verfügbar.

Ein Intrusion-Detection-System erkennt potenzielle Bedrohungen im Netzwerk und schlägt Alarm, während ein Intrusion-Prevention-System zusätzlich aktiv eingreift – etwa durch das Blockieren verdächtigen Datenverkehrs.

Suricata vereint beide Funktionen in einem System und ermöglicht so sowohl die Erkennung als auch die Abwehr von Angriffen in Echtzeit.

Suricata überwacht Pakete auf Netzwerkschnittstellen. Sobald es auf einem potenziell gefährdeten Host installiert ist, beginnt  es damit, Netzwerkpakete abzufangen und zu analysieren. Diese gleicht es mit einer Liste von Signaturen ab, auch Regeln genannt. Jede Regel besteht aus:

• einem Header – der das Protokoll, die IP-Adressen, Ports und die Verkehrsrichtung, also in welche Richtung der Netzwerkverkehr läuft,

• einem Optionsteil, in dem Bedingungen wie Inhalte oder Flags angegeben werden und

• einer Aktion, die ausgeführt wird, wenn die Regel zutrifft. 

Die möglichen Aktionen ähneln Firewall-Funktionen: Ein übereinstimmendes Paket kann blockiert, abgelehnt, durchgelassen oder protokolliert (Alert generiert) werden. 

Suricata wird mit einer Vielzahl an vordefinierten Tegelwerken ausgeliefert, sodass man nicht bei Null anfangen muss. Diese Regeln bilden das Herzstück von Suricata und machen es sowohl zu einem IDS als auch zu einem IPS – je nachdem wie es konfiguriert ist.