Suchen, die Kibana nicht direkt abbilden
kann, etwa komplexere statistische Aus-
wertungen, ermöglicht in dieser Konstel-
lation das Elasticsearch-API.Wonach suchen?
Eine pauschale Antwort, die sich tech-
nisch einfach umsetzen ließe, gibt es hier
nicht. Wichtig ist es, den bekannten und
gewollten Traffic auszusortieren, damit
sich Detailuntersuchungen auf die rele-
vanten Verbindungen konzentrieren. Das
Zählen von Verbindungspaaren ist etwa
ein simpler statistischer Ansatz.
Im Endeffekt sucht der Admin das Un-
gewöhnliche – getreu dem Sherlock-
Holmes-Motto: „Once you eliminate the
impossible, whatever remains, no matter
how improbable, must be the truth.“ Auf
Netzwerkebene kann das Traffic sein,
den es normalerweise nicht geben sollte.
Der äußert sich vielleicht darin, dass
Systeme auf ungewöhnlichen Ports mit
ungewöhnlichen Zielen kommunizieren
(oder dies versuchen).
Die andere Achse, um ungewöhnliches
Verhalten festzumachen, ist die Zeit-
achse. Immer wieder findet sich Mal-
ware, die sehr regelmäßig nach HauseDer Code allein ist noch kein Indikator,
reduziert aber die Menge der zu durch-
suchenden Logs massiv.Wer suchet, der findet
Fördert eine der vorgestellten Methoden
eine Auffälligkeit zutage, sei es einen Do-
mainnamen, einen Netzwerkbereich im
Internet oder Ähnliches, sollte der Admin
alle Quellen nach dem Auftreten des In-
dikators abklopfen. Nicht selten bleibt
nur ein Indikator unverändert (etwa nur
der Port bei wechselnden Adressen oder
Domainnamen).
Um die Arbeit zu erleichtern, erweisen
sich Lösungen wie ELK als nützlich, denn
die Suche nach den infizierten Systemen
ist sprichwörtlich die im Heuhaufen. Je
größer das Netzwerk, desto größer der
Heuhaufen.
Gesunder Menschenverstand gepaart mit
dem Wissen, was im eigenen Netzwerk
als normal gilt, helfen dem Admin in der
Regel, mit den vorgestellten Datenquellen
den normalen Traffic auszufiltern, um die
Nadel zu finden. (kki) nInfos
[1] Tcpdump: [http:// http://www. tcpdump. org]
[2] Wireshark: [http:// http://www. wireshark. org]
[3] ELK-Stack:
[https:// http://www. elastic. co/ de/ elk-stack]
[4] Splunk: [https:// http://www. splunk. com]
[5] Dumpcap: [https:// http://www. wireshark. org/
docs/ man-pages/ dumpcap. html]
[6] T-Shark: [https:// http://www. wireshark. org/ docs/
man-pages/ tshark. html]
[7] Netflow:
[https:// de. wikipedia. org/ wiki/ Netflow]
[8] Netflow-Modul für Logstash:
[https:// http://www. elastic. co/ guide/ en/
logstash/ current/ netflow-module. html]
[9] Open Vswitch:
[http:// http://www. openvswitch. org]
[10] »ipt_NETFLOW«-Kernelmodul:
[https:// github. com/ aabc/ ipt-netflow]Der Autor
Konstantin Agouros arbeitet als Head of Open
Source & AWS Projects bei der Matrix Techno-
logy AG und berät dort mit seinem Team Kunden
in Open-Source- und Cloud-Themen. Sein neues
Buch „Software Defined Networking: Praxis mit
Controllern und OpenFlow“ ist bei de Gruyter
erschienen.telefoniert. Hier ist ein Herzschlagmuster
auf der Zeitachse ein guter Indikator. Ar-
beiten die Mitarbeiter von 9 bis 17 Uhr
im Büro, sollten die Desktops höchstens
gegen Mitternacht Updates einspielen.
Existiert ein lokaler Updateserver, sollte
Traffic nach außen ganz fehlen.
Auch die geografische Verteilung des
Traffic in Richtung Internet ist interes-
sant. Fehlen Geschäftsbeziehungen zu
ehemaligen Sowjetrepubliken und stam-
men auch keine Mitarbeiter von dort,
lässt sich der Traffic dorthin als ein Warn-
zeichen deuten.
Kommt ein Webproxy zum Einsatz, zie-
hen Admins auch dessen Logs als Da-
tenquelle heran. Zusätzlich zur Analyse
unbekannter Domainnamen und Ziel-IPs
in ungewöhnlichen Ländern trägt hier
auch der HTTP-Returncode zur Klärung
der Situation bei. Häufig verschwinden
C&C-Server wieder, ohne dass die Mal-
ware dies bemerkt. Zugriffe über den
Proxy schlagen dann fehl, hinterlassen
aber eine Spur. Ein unbekannter Host
sorgt bei Squid als Proxy für den Fehler-
code 503:
1541025318.775 32 10.10.10.10 TCP_MISS/503 U
4040 GET http://www.skjhskshdf.sfkhskfshf/ U
‑ HIER_NONE/‑ text/htmlAbbildung 4: Im 24-Stunden-Graphen sollte der Admin die Spitzen in der Nacht im Drill-down untersuchen.Titelthema44
http://www.linux-magazin.deNetzwerkanalyse