PRTG und NetFlow/sFlow/IPFix

Die Firma Paessler verkauft das Produkt PRTG. Für den Einstieg in ein Monitoring tut es vielleicht auch die "Freeware", die bis zu 100 Sensoren unterstützt. Einer der Sensoren kann dabei der NetFlow-Sensor sein, um den es auf dieser Seite geht. Lesen Sie dazu auch die Seite NetFlow im Bereich Netzwerk und QoS.

Einrichten

Ein SFlow-Empfänger läuft physikalisch auf einer PRTG-Probe. Sie können in einem verteilten Netzwerk mit entsprechend dezentralen Probe-Systeme natürlich auch eigene sFlow-Empfänger einrichten. Die logische Eintragung erfolgt aber immer unter einem Device. Bei PRTG kann immer nur ein Device die Daten zum Sensor senden. Ratsam ist das aber nicht immer, denn so könnten Daten auch doppelt erfasst werden, wenn die Pakete durch zwei Geräte laufen. Insofern ist es schon besser auf einem Device einen neuen Flow-Sensor anzulegen. Sie können bei der Anlage auch direkt die Technologie auswählen. Dennoch bietet ihnen PRTG eine ganze Gruppe an Sensoren dieser Klasse an.

Ich habe mal einen sFlow-Sensor ausgewählt. Relevant sind die IP-Adresse des Senders, d.h. des Switches o.ä. Zudem wird hier ein Zielport-Port und die Ziel-IP einer Probe angegeben, auf der die Daten dann angenommen werden. Diese Information müssen Sie auf die Konfiguration des Switch abstimmen.

Wenn Sie dann auf dem Switch, Router oder anderen Sender diesen Empfänger gepflegt haben, dann brauchen Sie nur noch auf die Daten warten. Es dauert natürlich etwas, bis die Daten eintrudeln und die Bilder langsam entstehen

Auswerten

Über die Weboberfläche von PRTG haben Sie dann einen direkten einfachen Zugriff auf die gesammelten Informationen. Hier mal eine Momentaufnahme meines TPLink T2600G-28TS-Switch:

Hier sehen sie einen Lifegraph eines Firmenanschuss über 2 Stunden. Sie sehen gut den hohen Anteil an WWW-Verkehr.

Unten gibt es eine Tabelle, die die Zahlen noch genauer aufführt und über die historischen Daten können Sie natürlich noch mehr Informationen erhalten. Interessant ist aber auch die Auflistung der Partnerschaften, die auf der Übersicht für die letzten Minuten zu sehen ist

Ich gehe hier nicht tiefer in die Details, denn es ist natürlich möglich, auch die einzelnen Partnerschaften noch genauer zu analysieren.

Interessant sind diese Bilder schon. Leider beschränken sich diese Daten auf IP-Adressen und Ports. Manchmal würde ich mir wünschen, dass man auch SMTP-Domains (Quelle und Ziel) so mit quasi Bordmitteln visualisieren könnte

Anpassungen

Sie haben aber auch gesehen, dass bei der Anlage des Sensors nur ein paar vordefinierte Unterscheidungen nach Protokollen erfolgt.

Diese Vorauswahl können Sie aber anpassen. Es gibt aktuell aber keine GUI dafür. Sie müssen schon selbst per XML-Datei die Parametrisierung vornehmen.

Historische Daten nutzen

Über die Weboberfläche können Sie sehr einfach nicht nur den aktuellen Stand betrachten sondern sogar für historische Daten länger in die Vergangenheit zurück gehen. Über diesen Weg können Sie auch einfach Reports per HTML, CSV oder XML erstellen. Die Ausgabe fordern Sie per Browser an. Allerdings enthalten die Daten auch nicht mehr Details als die Ansicht. Sie können so zwar eine Liste der "Top Connections" und "Top Talker" auch als Report erzeugen aber eben keine vollständige Liste der Anfragen. AUch der Weg über die API könnte hilf hier nicht weiter . Wenn Sie eine aktive PRTG-Installation haben, dann erreichen Sie die Beschreibung über "Setup - PRTG API - Historic Data"

Die Nutzung dieser API ist allerdings sehr einfach möglich. Sie können einfach die URL auch per PowerShell per "Invoke-Webrequest" einfach abfordern und damit die Datei herunterladen. Eine XML-Ausgabe sieht dann aber z.B.: wie folgt aus:

Das sind einfach nur die zusammengefassten Werte ohne weitere Details:

Detaildaten über Debugging

Ich wollte aber schon gerne eine Liste der Verbindungen für weitergehende Analysen haben. Zuerst habe ich natürlich direkt in PRTG und den Foren gesucht: 

Dann habe ich noch mal Hoffnung geschöpft, als ich folgenden Artikel gelesen habe

  • Export customized netflow to csv
    https://kb.paessler.com/en/topic/74607-export-customized-netflow-to-csv
    ou export netflow traffic volume/bandwidth according to a netflow sensor channel configuration. However you cannot apply different channel filters retroactively, only existing netflow sensor channel data can be reported on. You can use the report feature with attached data files, or use the AP

Aber auch das hat nicht weiter geholfen. Ich war schon drauf und dran per PowerShell oder C# meinen eigenen sFlow/NetFlow-Collector zu bauen, der die Daten einfach in eine CSV-Datei loggt. So könnte ich sie später per PowerBI o.a. einfach weiter verarbeiten. Auch hier habe ich gesucht und es gibt sogar die ein oder anderen Tools wie z.B.: http://sflow-rt.com/. Aber dann habe ich die "Debug"-Funktion von PRTG entdeckt.

Ich habe etwas suchen müssen, bis ich die passende Datei dann in C:\ProgramData\Paessler\PRTG Network Monitor\StreamLog gefunden habe. Hier legt PRTG bei mir eine CSV-Datei an, deren Inhalt vielversprechend ist:

Der Inhalt ist einfach zu lesen. Es ist wirklich eine CSV-Datei:

Now,FromDateTime,ToDateTime,EthernetType,Protocol,SourceIP,SourcePort,SourceMAC,DestinationIP,DestinationPort,DestinationMAC,Size,ChannelID,ToS,SenderIP,InboundInterface,OutboundInterface
1/8/2018 4:20:37 PM,1/8/2018 3:20:37 PM,1/8/2018 3:20:37 PM,,17,192.168.179.34,45363,B6-41-37-0B-FB-80,192.26.175.183,10007,08-96-D7-49-D2-62,0,3009,0,192.168.178.2,10,0
1/8/2018 4:20:38 PM,1/8/2018 3:20:38 PM,1/8/2018 3:20:38 PM,,6,212.81.93.213,5938,CC-CE-1E-34-3D-04,192.168.178.8,60115,F0-4D-A2-DB-06-71,770281472,3009,2,192.168.178.2,17,0
1/8/2018 4:20:39 PM,1/8/2018 3:20:39 PM,1/8/2018 3:20:39 PM,,6,192.168.178.8,60115,F0-4D-A2-DB-06-71,212.81.93.213,5938,CC-CE-1E-34-3D-04,336896,3009,2,192.168.178.2,22,0

So ist auch nicht weiter verwunderlich, dass auch das PowerShell Commandlet "Import-CSV" die Datei direkt einlesen kann.

Damit steht einer eigenen Weiterverarbeitung nichts mehr im Wege.

Hinweis:
Bei meinem Musterdaten habe ich z.B. gesehen, dass der Flows nicht immer Rücksicht auf die Richtung nehmen. Wenn ein Client mit einem "High-Port" eine Verbindung zu einem Webserver auf Port 80 aufbaut, dann würde ich erwarten, dass auch nur ein Flow in diese Richtung erscheint. Stattdessen sehe ich aber auch Flows, die von Port 80 an den Client zurück gehen. Das ist mir schon bei der Auswertung der Top-Connections aufgefallen wenn in einem Heimnetzwerk z.B. öffentliche IP-Adressen als "Source IP" auftauchen. In dem Fall ist das aber kein Fehler von PRTG sondern anscheinend hängt es vom Flow-Sender ab, wie genau er die Flows auch analysiert. Wenn er immer nur Intervalle erfasst und das erste Paket in einem Intervall dann das Rückpaket ist, dann ist die Flow-Aufzeichnung falsch herum. Hier macht es dann wohl schon mal Sinn die Paarungen von mehreren Flow-Datensätzen zusammen zu führen oder nach Quelle und Ziel zu klassifizieren.

Hinweis:
Anscheinend löscht oder überschreibt PRTG die Datei selbst immer wieder. Ein Versuch einer Langzeitaufzeichnung ergab eine Datei, die 64 Megabyte groß war und die früheren Einträge waren überschrieben worden. Es fehlte sogar die Überschrift.

Achtung
IP-Adressen können als personenbezogene Daten angesehen werden. Sie sollten bei jeder Art der Auswertung immer darauf achten, dass die gültige Datenschutzbestimmungen erfüllt sind.

Aber es gibt noch weitere Einschränkungen, die beim Einsatz dieser Funktion nicht vernachlässig werden sollen

Debug-Daten weiterverarbeiten

Natürlich war von Paessler diese Verwendung vermutlich nicht vorgesehen und so sollte ich noch drei Dinge vorab klären, ehe ich darauf eine Lösung aufbauen:

  • Wie schnell wächst die Datei in einem "echten" System?
    Mein kleines Hausnetzwerk ist dazu ja keine Referenz. Aber man sollte sich schon Gedanken über ein "Aufräumen" machen
  • Welche Last produziert dies bei PRTG?
    Die ganzen "Flow"-Sensoren sind schon mit einer "hohen Belastung" in PRTG geführt. Wenn da nun noch Dateizugriffe dazu kommen, sollte man die Belastung des Gesamtsystems im Blick behalten. Allerdings hindert mich ja niemand eine eigene Probe nur für Flow-Empfang aufzustellen, wenn der eigentliche Server ansonsten überlastet wäre.
  • Datei-Rollover
    Aktuell scheint es so, als wenn PRTG die gleiche Datei immer wieder überschreibt, wenn Sie 64 Megabyte groß ist. Man kann sie aber einfach "umbenennen". PRTG startet dann beim nächsten Flow-Empfang einfach wieder eine neue Datei mit dem gleichen Namen. So könnte eine Auswertesoftware sich die Datei regelmäßig abziehen und nach der Verarbeitung löschen.

Insofern habe ich in einer mittleren Installation erst einmal das Debug-Logging aktiviert und beobachte weiter. Eine erste Demonstration der Möglichkeiten mit PowerBI finden Sie z.B. auf PowerBI und NetFlow/sFlow. Für eine längere Aufzeichnung könnte man die Datei per PowerShell in eine SQL-Datenbank importieren (Siehe PowerShell und SQL und PowerShell, SQL und BCP)

Weitere Links