Das Kommando »rndc dumpdb« erzeugt
einen Abzug aller gecachten Einträge in
der Datei »named_dump.db«. Die landet
in dem Verzeichnis, das in der »named.
conf« für den Nameserver unter »op-
tions« | »directory« eingetragen ist. Diese
Datei enthält in einem großen Zonefile
sämtliche Records, die der Nameserver
zu diesem Zeitpunkt kennt. Der Admin
sollte hier am ehesten die A-Records he-
rauspicken.
Gehen die Angreifer etwas trickreicher
vor, sollte er prüfen, ob das lokale Netz-
werk in Richtung Internet eher unge-
wöhnliche Record-Typen abfragt. Ein
wenig Analyse mit Grep & Co. hilft hier
weiter. Der folgende Befehl liefert eine
einfache Liste aller abgefragten Hostna-
men (aber auch anderer Records):
egrep '^[a‑zA‑Z0‑9]' /var/lib/bind/U
named_dump.db | grep ‑v PTR | sort | lessDie Sortierung hilft dabei der manuel-
len Analyse. Jedoch ist eine Suche nach
verwendeten Domains ebenfalls sinnvoll.
Das nächste Kommando fahndet nach
den gecachten SOA-Records:
grep SOA /etc/bind/dns/named_dump.db | awk U
'{print $2}' | sortLeider enthält diese Datei keine Informa-
tionen darüber, wer eine gegebenenfalls
verdächtige Anfrage gestellt hat. Aber das
Ergebnis der Analyse kann der Admin
verwenden, um mit T-Shark die DNS-
Anfragen nach dem Fragesteller zu fil-
tern. Da Angreifer, die DNS-Namen für
ihre C&C-Server verwenden, deren Gül-
tigkeit häufig auf einen kurzen Zeitraum
beschränken und ihre Server immer wie-
der bewegen, kann diese Analyseformzielführend sein. Die Frage ist aber, ob
überhaupt DNS zum Einsatz kommt.Angeln im Datenfluss
Eine Alternative zu T-Shark und Tcp-
dump ist das Einsammeln von Netflow-
Daten. Das Netflow-Protokoll [7] stammt
ursprünglich von Cisco und kursiert auch
unter anderen Namen (etwa J-Flow bei
Juniper). Die Technologie sammelt Ver-
bindungsdaten und exportiert diese in
einem UDP-Strom an einen Netflow-Coll-
ector, der sie dann verarbeitet.
Es gibt verschiedene Iterationen des
Protokolls. Version 9 ist als RFC 3954
standardisiert. Viele Hersteller unter-
stützen es, der Linux-Kernel bringt ein
entsprechendes Kernelmodul mit. Unter
dem Namen Ipfix ist auch Version 10 des
Protokolls verbreitet.
Konkret sendet der Exporter Daten über
IP-Verbindungen. Darin steht konkret,
welche IP-Adresse auf welchem Quell-
port mit welcher Ziel-IP-Adresse auf wel-
chem Zielport kommuniziert. Zusätzlich
übermittelt der Exporter Daten über die
Menge der gesendeten Pakete sowie der
übermittelten Bytes in jeder Richtung.Sammeldienst
Der Netflow Collector hilft bei der Ana-
lyse. Er steckt in einer Reihe verschie-
dener Tools, da Forensiker oft mehrere
Datenquellen zusammenführen müssen.
Der Artikel betrachtet den Netflow Coll-
ector im ELK-Stack.
ELK steht für eine Kombination aus Elas-
ticsearch, Logstash und Kibana. Unter
[8] beschreibt die Webseite von ElasticZur Option »-e« gehört auch die Option
»-T«, die das Ausgabeformat definiert.
Ein Aufruf kann dann etwa so aussehen:
tshark ‑T json ‑e ip.addr ‑r Capture‑File
Dank des Parameters »-T json« gibt T-
Shark die Daten strukturiert in Json aus,
sodass eine weiterverarbeitende Software
keinen Parser mehr braucht, sondern die
Standardbibliothek nutzt.Verdächtige Namen
Im anfangs vorgestellten Fall gingen spä-
tere Versionen der Malware dazu über, ih-
ren C&C-Server per DNS zu finden. Dazu
verwendeten sie den lokalen DNS-Server.
Das lässt dem Admin zwei Optionen: Er
kann den gesamten DNS-Traffic auswer-
ten oder beim Einsatz von Bind als rekur-
sivem Resolver erst einmal einen Blick in
die Datenbank werfen. Hier schaut er, ob
er auf verdächtige Einträge stößt.01 input {
02 udp {
03 port => 2055 codec => netflow {
04 versions => [5, 9, 10]
05 } type => netflow tags => "netflowdata"
06 }
07 }
08
09 output {
10 if "netflowdata" in [tags] {
11 elasticsearch {
12 hosts => "127.0.0.1" index => "netflow‑%{
+YYYY.MM.dd}"
13 }
14 }
15 }Listing 1: Logstash mit NetflowAbbildung 3: Das Kibana-Dashboard lässt sich an verschiedene Bedürfnisse anpassen.Titelthema42
http://www.linux-magazin.deNetzwerkanalyse