phillipmartin/gopassivednsNetzwerkbasierter passiver DNS-Logger, der DNS-Abfragen aus Live-Datenverkehr oder Pcap-Dateien erfasst und protokolliert und JSON für die Integration mit SIEM- und Threat-Intelligence-Plattformen ausgibt.
Netzwerkbasiertes DNS-Logging in Go
Ein netzwerkerfassungsbasierter DNS-Logger, inspiriert von https://github.com/gamelinux/passivedns. Er verwendet gopacket für libpcap und Paketverarbeitung. Er gibt JSON-Logs aus. Er ist für die Erfassung hoher Abfragevolumina in Umgebungen mit einem bis Hunderten von DNS-Resolvern ausgelegt.
Es ist eine gute Wahl. Ich habe dies gebaut, weil ich glaube, dass Aufgaben, die die Verarbeitung großer Mengen unvertrauter Daten mit vielen schlecht dokumentierten Randfällen beinhalten, von einer verwalteten Laufzeitumgebung gehandhabt werden sollten, um Speicherkorruptionsangriffe zu verhindern. Ich habe PassiveDNS in mehreren Organisationen eingesetzt und gopassivedns gebaut, um einige spezifische Schmerzpunkte zu lösen, die ich beobachtet habe: Ich musste viele Standorte instrumentieren, ich musste die Speicherschicht skalieren, um eine SEHR GROSSE Anzahl von Abfragen zu verarbeiten, und ich wollte eine Testsuite mit guter Abdeckung aller DNS-Randfälle.
Auch eine gute Wahl. Systeme wie Bro werden in der Regel an Netzwerkausgängen eingesetzt, was zur Folge hat, dass die tatsächliche Quelle der Abfrage hinter Ihren rekursiven Resolvern verborgen wird. Das bedeutet, dass Sie in der Regel Bro bereitstellen und das Resolver-Abfrage-Logging (sofern möglich) durchführen müssen und die Logs beider Systeme in ein zentrales Logsystem integrieren müssen, um eine Abfrage zu einem Client zurückzuverfolgen. gopassivedns wurde entwickelt, um auf Ihren Resolvern ohne Konfigurationsänderungen am Resolver und/oder an Ihren Netzwerkausgängen bereitgestellt zu werden, zentral über ein zuverlässiges Protokoll zu loggen und einfach in jedes Logsystem geparst zu werden.
Die Unterstützung der Resolver für das Abfrage-Logging, einschließlich Frage und Antwort, ist bestenfalls lückenhaft. Einer der am meisten eingesetzten DNS-Server, BIND, unterstützt es überhaupt nicht. Andere, wie Windows DNS, haben wirklich schreckliche Logformate. Darüber hinaus erfasst netzwerkbasiertes Logging Abfragen, die direkt von Ihren Clients an entfernte Server (z. B. Google DNS) gesendet werden.
Konfigurationsoptionen können als Umgebungsvariablen, in einer .env-Datei oder über die Kommandozeile angegeben werden. Die Priorität ist: Kommandozeilen-Flags, .env-Datei und schließlich bereits in der Umgebung definierte Variablen. Die Konfigurationsoptionen sind wie folgt:
Sie müssen entweder -dev oder -pcap angeben.
Es gibt bekannte Probleme mit Goroutinen und dem Standard-Daemonisierungsprozess (https://github.com/golang/go/issues/227), daher empfehle ich dringend, eine der hier beschriebenen Methoden zu verwenden: http://stackoverflow.com/questions/10067295/how-to-start-a-go-program-as-a-daemon-in-ubuntu, um diesen Prozess mit Systemtools als Daemon auszuführen.
Wenn Sie sich für die Verwendung von Syslog-Logging entscheiden, verwenden wir golangs "log/syslog", das einen Unix-Socket benötigt, der zur Kommunikation mit Syslog an einem der folgenden Orte sein muss: /dev/log, /var/run/log oder /var/run/syslog.
Sie haben 3 Möglichkeiten: Setzen Sie es auf Ihrem/n Resolver(n) oder auf Ihrem/n Gateway(s) oder beidem ein. Die Bereitstellung auf Ihren Resolvern ist gut, da Sie die IP-Adresse des Clients erhalten, der die ursprüngliche Anfrage gesendet hat. Sie können auch das vorgelagerte Bein der Anfrage (vom Resolver zum nächsten Resolver in der Kette) sehen, es sei denn, Sie passen Ihren BPF-Filter an, um dieses Bein zu ignorieren. Die Bereitstellung auf Ihren Gateways bedeutet, dass Sie das Bein Client -> interner Resolver nicht sehen, daher kann es schwierig sein, eine Anfrage einem bestimmten Client zuzuordnen. Andererseits sehen Sie Anfragen, die Ihre internen Resolver umgehen. Sie werden natürlich auch die Abfragen sehen, die vom Resolver zu welchem vorgelagerten Resolver auch immer gesendet werden. In einer idealen Welt würde ich dieses Tool auf jedem meiner internen Resolver und auf einem Tap an meinen Gateways einsetzen. Die internen Resolver hätten einen BPF-Filter, der das vorgelagerte Bein der Abfrage ignoriert, und das Gateway würde nichts ignorieren.
Im Moment würde ich empfehlen, Logstash zu verwenden, um die Logs an einen Elasticsearch-Cluster zu senden. Alle Logs sind JSON, daher sollte dies recht einfach sein. Ich würde auch die Verwendung von etwas wie HDFS für die Langzeitspeicherung und Bulk-Analyse vorschlagen. DNS-Abfragen sind eine erstaunliche Quelle interner Daten!
