Der Aufruf zum Installieren sieht also
folgendermaßen aus:
modprobe ipt_NETFLOW destination=172.25.1.117U
:2055,protocol=10Den zweiten Parameter darf der Admin
auch weglassen, da Version 10 Standard
ist. Die »2055« ist die zur Logstash-Konfi-
guration passende Portnummer.
Noch aber fängt der Linux-Rechner nicht
an Daten zu senden. Erst IPtables-Regeln
mit dem Target »NETFLOW« sorgen da-
für. Im einfachsten Fall setzt der Admin
auf einem Linux-Router das Kommando
iptables ‑I FORWARD ‑j NETFLOW
ab. Fällt die Regel spezieller aus, sendet
das Gateway nur bestimmte Pakete wei-
ter. Als Forensiker sollte der Admin die
Suche auf jene Pakete einschränken, die
durch das Gateway laufen und nicht im
internen Netz bleiben wollen. Die Auf-
gabe besteht ja darin, verdächtige Verbin-
dungen nach außen zu finden.Netzwerkhardware
Klassische Netzwerkhardware beherrscht
das Netflow-Protokoll oft ohne zusätzli-
che Module, wobei Admins bei manchen
Herstellern womöglich eine Zusatzlizenz
brauchen. Bei Netzwerkhardware sollten
sie jedoch darauf achten, dass nicht die
meist schwache CPU der Management-
einheit die Aufgabe des Flow-Sammelnsübernimmt. Einen Router, der in Hard-
ware mehrere 100-GBit/s-Schnittstellen
bedient, überfordert dies schnell.
Hier ist die Sample-Rate der Schlüssel,
um das Gleichgewicht zwischen Daten-
sammeln und Überlastung des Systems
zu steuern. Das erlaubt eine Datensamm-
lung auch auf Netzwerkgeräten, denen
Tcpdump fehlt.
Hier müsste der Admin andernfalls erst
einen Spiegelport aufsetzen und dort ei-
nen Linux-Rechner installieren. Die Ins-
tallation sammelt im ersten Schritt Daten,
dann kommt Kibana (Abbildung 3) zum
Zuge, um diese zu sichten. Die Dash-
boards »NetFlow: Conversation Partners«
beziehungsweise »NetFlow: Traffic Ana-
lysis« bieten Überblicke.
Auf der Suche nach der oder den Nadeln
im Heuhaufen verwendet der Admin nun
die Filterfunktion oben auf der Webseite.
Im Wesentlichen geht es darum, Bekann-
tes großflächig auszusortieren.
Die Timeline-Visualisierungen nach dem
Ziel, die über die Zeit sammeln, wie viele
Pakete oder Bytes aus dem Netzwerk an
welches Ziel gehen, können im normalen
Bürobetrieb auffälliges Verhalten anzei-
gen. Selbst ohne Proxy sollten Admins
in den Nebenzeiten maximal Updates
einspielen und die Spitzen in der Neben-
zeit untersuchen. Auch hierbei schließt
der Netzwerker dann wieder bekannte
Verbindungen aus und beobachtet den
restlichen Traffic (Abbildung 4).das einfache Setup für einen Single Host,
bei dem alle drei ELK-Komponenten auf
einer Maschine laufen. Der Aufruf
bin/logstash ‑‑modules netflow ‑‑setup ‑M U
netflow.var.input.udp.port=XXXX
initialisiert die Dashboards in Kibana und
legt auch ein paar Mappings an. Gleich-
zeitig startet der Aufruf Logstash mit ei-
ner Instanz, die auf Port XXXX Netflow-
Pakete annimmt. Listing 1 zeigt eine Er-
gänzung des »conf.d«-Verzeichnisses, die
den Netflow-Dienst beim regulären Start
von Logstash aktiviert. Laut Input-Block
in Zeile 4 ist auch Version 10 (Ipfix) ak-
tiviert, was im vorher genannten Aufruf
nicht der Fall war.
Mit Linux-Gateway
Kommen Linux-Gateways zum Ein-
satz, gibt es zwei Möglichkeiten, wie
diese Netflow-Daten produzieren: Open
Vswitch [9] erlaubt es, für jede Bridge
Netflow-Daten zu exportieren. Alternativ
existiert ein »ipt_NETFLOW«-Kernelmo-
dul, das im Zusammenspiel mit IPtables-
Regeln Flow-Daten exportiert. Der Admin
installiert das Paket entweder aus der
Distribution oder aus dem Git-Archiv
unter [10]. Beim Selberbauen muss er
zuvor natürlich die zum Bauen notwen-
digen Pakete installieren.
Das Kernelmodul benötigt die Informa-
tion, wohin es die Daten senden soll.
43http://www.linux-magazin.deTitelthemaNetzwerkanalyse