© Albert Beukhof / 123RF.com

Flows ermöglichen es, festzustellen, welche Netzwerkgeräte miteinander kommunizieren und wie viele Daten dabei übertragen wurden. OpenNMS kann Flows sammeln und visualisieren.

Administratoren überwachen wichtige Netzwerkverbindungen, um Probleme wie eine Überlastung früh zu erkennen. Häufig kommt zu diesem Zweck SNMP zum Einsatz, um die Metriken der Netzwerkschnittstellen abzufragen. Die Messwerte lassen sich über Zeitreihendiagramme visualisieren, und der Anwender kann Schwellwerte festlegen, bei deren Überschreitung er benachrichtigt wird.

Aber was passiert, wenn ein Administrator eine solche Benachrichtigung erhält? Ein Blick auf das Zeitreihendiagramm verrät zwar, dass die Netzwerkverbindung ausgelastet ist, aber die Frage, welche Konversationen mit welchen Anwendungen diese Verbindung nutzen, bleibt offen. Informationen aus Flows können diese Lücke schließen. Mittlerweile bieten auch viele Netzwerkgeräte den Export solcher Informationen an, doch bleiben sie oft ungenutzt.

Dieser Artikel zeigt, wie sich OpenNMS Horizon ergänzend zum klassischen Monitoring mit SNMP einsetzen lässt, um die Zusammensetzung des Netzwerkverkehrs mithilfe von Flow-Protokollen sichtbar zu machen. Mit entsprechender Visualisierung in Grafana und einem offenen Zugang zu den Flow-Daten via Elasticsearch kann OpenNMS Horizon so Administratoren bei der Fehlerdiagnose, Kapazitätsplanung und bei sicherheitsrelevanten Themen unterstützen.

Was sind Flows?

Flows haben nicht zwangsläufig einen Zusammenhang zu einer Verbindung auf der Transportschicht, sondern bezeichnen eine Menge von IP-Paketen mit gleichartigen Eigenschaften, die innerhalb einer definierten Zeitspanne einen Messpunkt passieren [1]. Diese Eigenschaften umfassen, wie in Abbildung 1 gezeigt, unter anderem die IP-Adressen von Quelle und Ziel, die jeweiligen Ports sowie das Transportprotokoll.

Abbildung 1: Ein Flow ist eine Menge von IP-Paketen mit gemeinsamen Eigenschaften wie Quell- und Zieladresse.

Ursprünglich wurde NetFlow von Cisco Systems für Routing-Komponenten konzipiert. Ziel war hier, die CPU-intensive Berechnung der Routing-Entscheidung nur einmal pro Ziel auszuführen und das Ergebnis in einem Cache auf der Netzwerkkomponente abzulegen. Allerdings skalierte NetFlow aufgrund des hohen Aufkommens von kurzlebigen Netzwerkflüssen im Backbone- beziehungsweise Core-Bereich nicht optimal und wurde letztlich durch Cisco Express Forwarding (CEF) abgelöst. Die mit NetFlow ursprünglich gesammelten Daten der Paketflüsse eigneten sich allerdings sehr gut für Verkehrsanalysen und die Kapazitätsplanung. Cisco implementierte daher schließlich auch ein Protokoll, das es erlaubt, die gesammelten Daten zur Auswertung der IP-Datenströme an einen sogenannten Flow Collector weiterzuleiten.

NetFlow mauserte sich so zum De-facto-Standard, und auch andere Hersteller exportierten Daten im NetFlow-Format. Dabei gilt bis heute die Version 5 von NetFlow als die am weitesten verbreitete. Grund dafür ist das einfach zu implementierende Paketformat, das aus einem einleitenden Header und einer Menge von Records besteht. Hier gilt es allerdings zu beachten, dass diese Version noch keine IPv6-Adressierung unterstützt und daher nur zum Erfassen von IPv4-basierten Verkehrsdaten taugt. Mit der Version 9 von NetFlow als offener Standard [2] wurde schließlich ein Template-basierter Protokollansatz gewählt, der es erlaubt, flexibel die Informationen zu exportieren, die man zur Auswertung braucht.

Die Modellierung und die Standardisierungsprozesse der einzelnen Komponenten begannen 2001 mit der Gründung der Arbeitsgruppe IP Flow Information Export (IPFIX) innerhalb der Internet Engineering Task Force (IETF). Ziel war es, ein flexibles Nachrichtenformat zu entwickeln, das die Weiterleitung gezielt definierbarer Metriken erlaubt. Dabei wurde schließlich das durch Cisco Systems entwickelte Protokoll NetFlow in der Version 9 als Grundlage für Design und Entwicklung gewählt. IPFIX nutzt wie auch NetFlow einen Template-basierten Ansatz, was bedeutet, dass einem Collector vor der Übertragung der eigentlichen Daten deren Zusammensetzung mitgeteilt wird [3]. Dabei definiert IPFIX sogenannte Information Elements, die durch die Internet Assigned Numbers Authority (IANA) zentral registriert und verwaltet werden.

Bei der Erfassung und Analyse von Verkehrsdaten in Netzwerken spielt auch der sFlow-Standard [4] eine Rolle. Dieses Protokoll beschreibt ein auf Stichproben basierendes Verfahren, um in definierbaren Intervallen einzelne Paket-Header zu einem Collector zu senden. Die durch dieses Protokoll erfassten Daten von Paketflüssen beziehen sich auf die Header-Informationen zum Zeitpunkt der Stichprobe und stellen daher eine Momentaufnahme dar. Damit eignet sich sFlow vor allem für protokollunabhängige Auswertungen von Header-Informationen.

Sie müssen eine Netzwerkkomponente zunächst als Flow-Exporter konfigurieren, damit sie die entsprechenden Verkehrsdaten an einen Flow-Collector sendet. Abbildung 2 zeigt ein Beispiel für die Konfiguration von NetFlow v9 auf einem Cisco-IOS-Gerät. Ein Monitoring-System muss für den Empfang von NetFlow-Daten einen entsprechenden Flow Collector zur Verfügung stellen.

Abbildung 2: So werden beispielhaft Flow Collector und Exporter für NetFlow v9 auf einem Cisco-Gerät konfiguriert.

Flows in OpenNMS

Seit 2018 erlaubt das freie Monitoring-System OpenNMS das Sammeln und Klassifizieren solcher Verkehrsdaten. Dabei achteten die Entwickler beim Entwurf von Anfang an auf eine gute Skalierbarkeit. OpenNMS unterstützt sowohl NetFlow v5 und v9 als auch IPFIX und sFlow. Abbildung 3 zeigt den groben Aufbau der benötigten Komponenten zum Auswerten von Flow-Daten mit OpenNMS Horizon.

Abbildung 3: Eine schematische Darstellung des OpenNMS-Horizon-Stacks für das Sammeln von Flows.

Zum Speichern von Monitoring-Inventar, Ereignissen und Statusinformationen verwendet OpenNMS eine PostgreSQL-Datenbank. In einer einfachen Installation liegen die Zeitreihen in RRD-Dateien. Für spezialisierte und anwendungsbezogene Dashboards kann Grafana zum Zug kommen. Das setzt die Installation des Grafana-Plugins OpenNMS Helm [5] voraus, das die entsprechenden Datenquellen OpenNMS Performance, OpenNMS Entities und OpenNMS Flows zur Verfügung stellt.

Die Verkehrsdaten haben einen anderen Charakter als typische Zeitreihen und werden daher in einer Elasticsearch-Instanz mit installiertem OpenNMS-Drift-Plugin [6] abgelegt. So stehen die notwendigen Funktionen für das Speichern, Abfragen und die Aggregation der Verkehrsdaten zur Verfügung. Ein minimales Setup zur Flow-Auswertung mit OpenNMS Horizon sehen Sie in Abbildung 4.

Abbildung 4: Ein minimales OpenNMS zur Flow-Auswertung mit OpenNMS Horizon.

Installation und Konfiguration

Die Komponente Telemetryd in OpenNMS Horizon übernimmt die Aufgabe des Flow Collectors und entscheidet, welche Flow-Protokolle sie auf welchen Ports empfängt. In der Standardkonfiguration ist diese Komponente aktiv und kann die gängigen Protokolle NetFlow v5/v9, IPFIX und sFlow auf Port 9999/UDP empfangen und verarbeiten. Dabei wird das Protokoll beim Auslesen des Flow-Headers erkannt, sodass die Daten den Weg zum entsprechenden internen Parser finden. Das Verhalten von Telemetryd passen Sie in der Konfigurationsdatei »telemetryd-configuration.xml« an.

Um die Flow-Daten zu speichern, muss auf den Elasticsearch-Knoten das OpenNMS-Drift-Plugin [6] installiert sein. Im nächsten Schritt hinterlegen Sie in OpenNMS Horizon, wie Elasticsearch zu erreichen ist. Dazu erzeugen Sie die Konfigurationsdatei »$OPENNMS_HOME/etc/org.opennms.features.flows.persistence.elastic.cfg« mit dem Inhalt aus Listing 1.

# Elasticsearch persistence configuration
elasticUrl = http://my-elastic-ip:9200
elasticIndexStrategy=daily

Je nach dem zu erwartenden Verkehrsaufkommen wählen Sie für das Speichern der Verkehrsdaten in Elasticsearch unterschiedliche Index-Strategien, beispielsweise stündlich, täglich, monatlich oder jährlich. In produktiven Umgebungen spielen unter anderem Faktoren wie Redundanz und Indizes eine wichtige Rolle. Die Referenz [7] beschreibt alle verfügbaren Konfigurationsparameter. Nach dem Erzeugen der Datei starten Sie OpenNMS Horizon mit »systemctl restart opennms« neu, sodass es beginnt, Flow-Daten entsprechend zu speichern.

Jetzt gilt es noch, die zentralen Netzwerkkomponenten so zu konfigurieren, dass sie ihre Verkehrsdaten an Port 9999/UDP der OpenNMS-Horizon-Instanz senden. Um sinnvolle Auswertungen über die Flow-exportierenden Geräte zu ermöglichen, müssen Sie diese als Knoten in OpenNMS via SNMP überwachen.

Auswerten von Verkehrsdaten

Nach dem Empfang der Verkehrsdaten bringt OpenNMS diese zunächst in ein einheitliches Format und reichert sie mit Zusatzinformationen an. Die umfassen die Zuordnung der exportierenden Netzwerkgeräte und – sofern möglich – auch der Quell- und Zieladressen zu in OpenNMS verwalteten Knoten. Zudem ergänzen Reverse-DNS-Abfragen aus Sicht des jeweiligen Collectors die Quell- und Zieladressen durch eventuell vorhandene FQDNs. Schließlich werden die angereicherten Verkehrsdaten vor dem Speichern anhand von in OpenNMS definierten Regeln klassifiziert.

Es gibt mehrere Tausend vordefinierte Regeln, die den Verkehr anhand von Transportprotokoll und Port-Nummer in verschiedene Protokolle einordnen. Darüber hinaus können Sie in der Web-UI eigene Regeln definieren, die auch die Quell- und Zieladressen einschließen. Auf diese Weise lässt sich interessanter, erwünschter oder unerwünschter Verkehr klassifizieren.

Das Beispiel aus Abbildung 5 zeigt eine benutzerdefinierte bidirektionale Regel, die den TCP- und UDP-Verkehr auf Port 873 zwischen den IP-Adressen 10.1.2.10 und 192.168.23.42 einer Applikation namens Backup-over-Rsync zuordnet. Eine solche Regel lässt sich darüber hinaus auch mittels der in OpenNMS bekannten Filterregeln auf bestimmte Exporter einschränken.

Abbildung 5: Ein Beispiel für das Erstellen einer OpenNMS-Klassifikationsregel.

Zudem erlaubt OpenNMS den Import und Export der Klassifikationsregeln als CSV-Dateien. Das ermöglicht es Ihnen, Klassifikationsregeln beispielsweise in einer Tabellenkalkulation zu pflegen oder sie auf welche Art auch immer zu generieren. Ein Beispiel könnte hier das Erzeugen von Regeln auf Basis von im Internet frei verfügbaren Adresslisten von Wallet-Anbietern sein, um Krypto-Mining im Unternehmen zu erkennen und zu unterbinden.

Für Grafana benötigen Sie nun neben der Datenquelle »OpenNMS Performance« eine weitere des Typs »OpenNMS Flow«. Schließlich lässt sich über die Plugin-Seite von OpenNMS Helm das Flow-Deep-Dive-Dashboard importieren. Es erlaubt unter Angabe eines Exporter-Knotens und einer Schnittstelle die Einsicht in die dieser Schnittstelle zugeordneten Daten. Da OpenNMS auch via SNMP die Metriken der Schnittstellen einsammelt, lassen sich diese direkt mit den aggregierten Werten der Verkehrsdaten vergleichen. Damit können Sie zusätzlich zur Auslastung einer Schnittstelle auch auswerten, wie sich dieser Verkehr letztlich zusammensetzt. Das hilft sowohl, Engpässe im Netz zu identifizieren, als auch den Datenverkehr im Unternehmensnetz zu priorisieren.

Wie Abbildung 6 zeigt, wird der Durchsatz sowohl grafisch als auch tabellarisch für die Top-N-Applikationen, Top-N-Konversationen, Top-N-Hosts und nach DSCP-Werten aggregiert visualisiert.

Abbildung 6: Das Deep-Dive-Dashboard dient der Flow-Analyse in Grafana.

Zusätzlich zu einer Auswertung über dieses auf Flow-Daten spezialisierte Dashboard lassen sich für jeden Messpunkt auch RRD-Spuren für die definierten Applikationen erzeugen. Das aktivieren Sie in der Datei »telemetryd-configuration.xml« auf Ebene der Adapter über den Parameter »applicationDataCollection«.

Möchten Sie für diese Daten zusätzlich Schwellwerte prüfen, erreichen Sie das über den Parameter »applicationThresholding«. Auf diese Weise lassen sich Alarme auf Basis von Applikationen generieren. Beispielsweise wäre eine Alarmierung beim Auftreten von Datenverkehr zu problematischen Adressen außerhalb des Unternehmensnetzes möglich oder eine Warnung beim Unterschreiten des Datendurchsatzes bei der Replikation zwischen redundanten Systemen.

Skalierbarkeit

OpenNMS vermag auch in sehr großen Umgebungen Verkehrsdaten zu sammeln. Grundlage dafür ist die Verteilung der Teilaufgaben auf sogenannte Minions und Sentinels. Als Minion dient dabei zum einen die abfragende Komponente, über die Sie überwachte Knoten mittels ICMP, SNMP oder ähnlichem abfragen. Zum anderen nehmen Minions aber auch Logs, SNMP-Traps oder Verkehrsdaten entgegen (Abbildung 7).

Abbildung 7: Durch den Einsatz von OpenNMS-Minions als Flow-Kollektoren erreichen Sie eine gute Skalierung.

Die erfassten Metriken und Daten werden dann an eine OpenNMS-Instanz oder in größeren Umgebungen an die Sentinels weitergegeben, die sie weiterverarbeiten. Im Falle von Verkehrsdaten lassen sich so die Klassifikation und Anreicherung der Flows verteilen. Auf diesem Weg schaffen es einige Nutzer, 450 000 Flows pro Sekunde zu verarbeiten und damit über 100 GByte an Verkehrsdaten pro Stunde in ihren Elasticsearch- oder Cortex-Clustern zu speichern. Abbildung 8 zeigt den Aufbau einer größeren Umgebung zum Auswerten von Verkehrsdaten.

Abbildung 8: So könnte eine große OpenNMS-Umgebung zur Flow-Auswertung aufgebaut sein.

Darüber hinaus existiert mit Nephron [8] eine Möglichkeit, hochaufgelöste Flow-Daten mithilfe eines Apache-Flink-Clusters über größere Intervalle zu aggregieren, um die Erstellung komplexer Auswertungen über längere Zeiträume zu ermöglichen.

Fazit

Auch wenn die Sammlung von Verkehrsdaten mittels OpenNMS etwas Einarbeitung benötigt, erhält man damit doch ein robustes Werkzeug zur Kapazitätsplanung und zur Untersuchung von Durchsatzproblemen oder Sicherheitsvorfällen. Die Entwickler haben dieses Feature seit dem Ausrollen intensiv gepflegt und weiterentwickelt und jedes noch so seltsame Verhalten des ein oder anderen Netzwerkgeräts adressiert.

Die Verfügbarkeit der Verkehrsdaten in Elasticsearch in einem einfachen, aber für alle Protokolle einheitlichen Format bietet zudem Potenzial für Experimente und das Umsetzen eigener Use Cases für die Netzwerküberwachung.

Das Github-Repository OpenNMS Forge Stack-Play [9] enthält viele Container-Stacks für Docker Compose, die das Zusammenspiel der verschiedenen Komponenten einer OpenNMS-Horizon-Installation demonstrieren. Dort finden Sie im Verzeichnis »minimal-flows/« auch ein Beispiel für das Verarbeiten von Verkehrsdaten zum Ausprobieren und Experimentieren. (jcb)