Mein ursprüngliches Ziel war es in meinem Heimnetzwerk alle DNS Anfragen mitzuschneiden und mittels threat intelligence Plugin von Graylog zu analysieren.

Das vorbereiten der vorhandenen Infrastruktur im Netzwerk gestaltete sich schwieriger als gedacht, das für den Heimanwender erschwingliche IT Equipment bietet die dafür notwendigen Einstellungen meist eher nicht.

An den Weihnachtsfeiertagen, beim aufräumen purzelte mir ein Raspberry Pi vor die Füße und ich erinnerte mich an das pi-hole Projekt. So hatte ich binnen kurzer Zeit meinen eigenen Resolver im Haus, der zusätzlich auch noch einige Werbung auf allen ihn benutzenden Clients blockierte.

Unter der Haube läuft ein dnsmasq dessen Einrichtung kein Hexenwerk ist. Also kann das nachfolgende auch nur mittels eingeschalteter Protokollierung in einem eh schon vorhandenen Resolver genutzt werden.

Analyse des DNS Logfiles

Das Logfile eines dnsmasq sieht wie folgt aus.

Jan 12 00:00:10 dnsmasq[13849]: query[A] e.crashlytics.com from 192.168.0.52
Jan 12 00:00:10 dnsmasq[13849]: forwarded e.crashlytics.com to 192.168.0.1
Jan 12 00:00:10 dnsmasq[13849]: forwarded e.crashlytics.com to 192.168.0.1
Jan 12 00:00:10 dnsmasq[13849]: query[A] e.crashlytics.com from 192.168.0.52
Jan 12 00:00:10 dnsmasq[13849]: forwarded e.crashlytics.com to 192.168.0.1
Jan 12 00:00:10 dnsmasq[13849]: forwarded e.crashlytics.com to 192.168.0.1
Jan 12 00:00:10 dnsmasq[13849]: reply e.crashlytics.com is <CNAME>
Jan 12 00:00:10 dnsmasq[13849]: reply events-endpoint-d-1130254936.us-east-1.elb.amazonaws.com is 54.83.203.86
Jan 12 00:00:10 dnsmasq[13849]: reply events-endpoint-d-1130254936.us-east-1.elb.amazonaws.com is 54.243.214.67
Jan 12 00:00:10 dnsmasq[13849]: reply events-endpoint-d-1130254936.us-east-1.elb.amazonaws.com is 75.101.136.208
Jan 12 00:00:10 dnsmasq[13849]: reply events-endpoint-d-1130254936.us-east-1.elb.amazonaws.com is 54.225.169.184
Jan 12 00:00:10 dnsmasq[13849]: reply events-endpoint-d-1130254936.us-east-1.elb.amazonaws.com is 54.243.226.203
Jan 12 00:00:10 dnsmasq[13849]: reply events-endpoint-d-1130254936.us-east-1.elb.amazonaws.com is 54.243.70.100
Jan 12 00:00:10 dnsmasq[13849]: reply events-endpoint-d-1130254936.us-east-1.elb.amazonaws.com is 54.243.181.49
Jan 12 00:00:10 dnsmasq[13849]: reply events-endpoint-d-1130254936.us-east-1.elb.amazonaws.com is 54.243.34.44

Wenn man einen pi-hole benutzt wird eine grafische Auswertung angeboten, die für sich genommen schon einmal sehr hilfreich ist, mir ging es aber um weitere Auswertung und Bewertungen. Dazu wird das Logfile an Graylog übertragen. Ich nutze rsyslog welcher eh schon seine Daten an Graylog liefert.

module(load="imfile" PollingInterval="10")

input(type="imfile"
      File="/var/log/pihole.log"
      StateFile="/var/run/pihole.log.state"
      Tag="pihole"
      Severity="info"
      Facility="local7")

Verarbeitung des Logfiles

Die Verarbeitung innerhalb von Graylog erfolgt mittels processing pipelines. Eine andere art der Verarbeitung ist zum einen wegen des thread-intel-plugins nicht möglich, zum anderen bieten die pipelines eine Flexibilität die sonst nicht vorhanden ist. Die von mir erstellte Pipeline pihole / dnsmasq sieht wie folgt aus:

Bevor ich die einzelnen Regeln erkläre, ein kurzer Verweis auf diese Blog Posting in dem zusätzlich zur Dokumentation erklärt wird welche Schritte in welcher Reihenfolge gemacht werden sollten.

Pipeline Stages

In der ersten Stage (-9) setze ich den Hostname damit er meinem default entspricht. In der zweiten Stage (-1) wird mittels Grok Pattern das Logfile auseinander genommen und die gewonnenen werte in einzelne Felder geschrieben. Die dritte Stage beinhaltet alle threat intelligence regeln und säubert das Message Feld. In der letzten Stage wird noch ein Feld gesetzt um die suche zu vereinfachen.

Die rules sind in einem gist und hier eingebunden:

Damit die Regeln auch alle gespeichert werden können muss als erstes das Plugin threat intelligence installiert werden. Nach dem notwendigen Neustart von Graylog (im Cluster muss es auf allen Knoten sein!) sollte noch schnell unter system | configurations die Konfiguration angepasst werden. Ansonsten laufen die Regeln zwar, es wird aber kein externer Dienst abgefragt.

Sind die Regeln alle angelegt muss eine Pipeline erstellt werden. In dieser werden dann die Stages definiert und den Stages werden die einzelnen Regeln zugeordnet.

Die fertige Pipeline kann dann z.B. mit dem default stream verbunden werden. Sofort fängt die Verarbeitung der eintreffenden Nachrichten ein. Nachdem die Pipeline durchlaufen wurde, sieht eine verarbeitete Nachricht wie folgt aus:

Dashboard

Aus den sauberen Daten, lassen sich dann Dashboards bauen die einem schnell wichtige Informationen sichtbar machen. Aber auch die einfachere Suche wäre jetzt möglich.

Das Content Pack für dieses Dashboard ist als gist hinterlegt ebenfalls sind die beiden in den rules genutzten GROK Pattern enthalten.

An dieser Stelle noch ein Hinweis, aufgrund geltender Gesetze dürft ihr dies nicht einfach implementieren ohne das die Nutzer des Netzwerkes darüber informiert sind.