Meine ersten 24 Stunden mit einem DNS-Honeypot

Als Ingenieur, der die meiste Zeit bis zum Hals in Observability-Tools steckt, bekomme ich gelegentlich eine Idee, die ich einfach umsetzen muss. Dies war eines dieser Experimente: einen DNS-Resolver auf einer sauberen IP hochfahren, die niemand bewirbt, und dann das Internet trotzdem mit ihm reden lassen. Die einzige Aufgabe des Resolvers war es, ruhig zu bleiben, alles zu protokollieren und Grafana mit den resultierenden Abfragen zu füttern. Ein docker compose up -d später hatte ich Unbound, Loki, Prometheus, Grafana und Traefik, die den Live-Traffic verfolgten und Histogramme von Neugier, Fehlkonfiguration und gelegentlichen Scannern erstellten. Diese README ist der Bericht von diesem ersten Tag, was der Stack erfasst, warum es mir wichtig ist und was es über die aktuelle Sicherheitslandschaft hervorhebt.

Das Experiment

Ich habe bewusst null Signal von meiner Seite eingebracht, keine Packet Drops, keine maßgeschneiderten Antworten, keine Abwehrmaßnahmen. Nur Unbound mit aktiviertem Logging, Loki, der die Logdatei verfolgt, Prometheus, das Exporter-Metriken abgreift, Traefik vor Grafana und Docker Compose, das alles zusammenschaltet. Der Resolver saß auf 94.130.27.226, einer erfrischend „sauberen“ IPv4, die ich gefunden hatte (überprüfen Sie den Status unter https://www.abuseipdb.com/check/94.130.27.226, falls Sie eine Vor-Rausch-Baseline möchten), und ich ließ die Welt ihr Ding machen. Ein einzelner Laptop konnte jedes Panel beobachten, tools/dns_query_storm.sh ausführen, wenn ich die Suppe würzen wollte, und dann den Rausch in die Muster abklingen lassen, die das globale Internet senden wollte.

Sie können einen Live-Blick auf diese Dashboards unter https://dns.cybersafeintl.co.uk/public-dashboards/eb554b5b74e14f4d95e376c0033ee83d werfen, obwohl sie auf dem günstigsten Server im Stack laufen, rechnen Sie also bei hohen Abfragen mit langsamen Aktualisierungen.

Was die Dashboards erfassen

• Durchsatz: Prometheus sammelt die Metrik unbound_total_num_queries des Unbound-Exporters, sodass das Panel „Throughput (QPS, 5m rate)“ die Abfragen pro Sekunde anzeigt und nach Quelle aufschlüsselt. Diese Ansicht beantwortet die Frage „Wer hämmert auf den Resolver ein?“ – plötzliche Spitzen verweisen direkt auf ASNs aus Bangladesch oder Polen, und die Logs machen es einfach zu erkennen, ob SERVFAIL/NXDOMAIN-Stürme die Ausbrüche begleiten.
• Top-Clients: Lokis LogQL gruppiert nach client_ip, und die Dashboards verpacken alles bereits in topk(sort_desc(...)). Das hält die Panels sauber, während das Exporter-Skript mir erlaubt, dieselben Abfragen in CSVs für Offline-Analysen, Berichte oder reproduzierbare Geschichten zu exportieren. Der erste Capture zeigte fünf IP-Adressen in den Bereichen 45.179.* und 45.6.*, die jeweils über 5k Abfragen in fünf Minuten abschossen – entweder eine Scanner-Farm oder ein aggressiver Client.
• Domains: Die Panels „Top-Domains“ zeigen die Popularität von qname über 5-Minuten- und 24-Stunden-Fenster. Der 5-Minuten-Schnappschuss enthielt scb.se, dhl.com und cmu.edu, während der 24-Stunden-Export cbs.nl, scb.se, atlassian.com, und umfasste. Warum diese Domains? Das ist der interessante Teil – sind es legitime Dienste, falsch konfigurierte Resolver oder opportunistische Scanner, die veraltete Einträge verfolgen? Schicken Sie mir eine Nachricht, wenn Sie eine Theorie haben.

Jedes Panel, das Sie sehen, hat eine entsprechende CSV in exports/; bündeln Sie sie (zip -r exports.zip exports/), wenn Sie die rohe Geschichte an einen Blogbeitrag oder Incident-Report anhängen möchten.

Was unter der Haube steckt

• docker-compose.yml startet Unbound, den Unbound-Exporter, Loki + Promtail, Prometheus, Grafana und Traefik mit einem einzigen Befehl.
• unbound/ speichert Resolver-Konfigurationen und Logs. TTL-Steuerungen, serve-expired und Cache-Einstellungen bewahren die Genauigkeit, sodass wir erfassen, was die Clients tatsächlich anfragen.
• Die Verzeichnisse prometheus/, loki/ und grafana/ enthalten Daten und Provisionierungsdateien, sodass Metriken und Dashboards Neustarts überstehen.
• grafana/dashboards/unbound-traffic-insights.json ist mit der Ansicht, die Sie sehen, vorprovisioniert; alle PromQL/Loki-Abfragen aggregieren und sortieren bereits, um die Panels lesbar zu halten.
• tools/dns_query_storm.sh ermöglicht es Ihnen, Abfragestürme zu simulieren, wenn Sie Reaktionszeiten testen müssen.
• redeploy.sh automatisiert das Herunterfahren des gesamten Stacks, das Ziehen von Updates und das Neuerstellen mit einem einzigen Skript.
• export_dashboard_data.py durchläuft nun das Dashboard-JSON, führt jede Prometheus/Loki-Abfrage aus und schreibt bereinigte CSV-Dateien in ein -Verzeichnis zum Teilen.

Erste Schritte

1. cd hetzner_deploy/unbound-dns
2. cp .env.example .env und konfigurieren Sie GRAFANA_DOMAIN, Grafana-Admin-Anmeldedaten, LETSENCRYPT_EMAIL sowie alle benötigten TLS-Überschreibungen.
3. sudo chown -R 472:472 grafana-data && sudo mkdir -p prometheus/data && sudo chown -R 65534:65534 prometheus/data
4. docker compose build && docker compose up -d
5. Richten Sie einen DNS-Client auf den Host auf Port 53 aus, lassen Sie Traefik auf HTTPS für Grafana sitzen, und schon beobachten Sie passiven Traffic innerhalb von Minuten.

Exportieren und Teilen, was Sie sehen

1. pip install requests (der Exporter ist reines Python).
2. python export_dashboard_data.py --duration 24h --outdir exports/24h --timeout 90, um jede Dashboard-Abfrage abzurufen, in CSV zu konvertieren und die Ergebnisse unter exports/24h zu platzieren.
3. zip -r exports.zip exports/, um die Rohdaten zu bündeln, bevor Sie sie veröffentlichen, an einen Blogbeitrag anhängen oder an Mitarbeiter senden.
4. Führen Sie erneut mit --duration 6h oder --end-Zeitstempeln für gezielte Ausschnitte aus, oder verwenden Sie --filter domains, wenn Sie nur die Domain-Panels möchten.

Was mir am ersten Tag aufgefallen ist

• In dem 5-Minuten-Export generierten scb.se, dhl.com, cmu.edu, up.pt und utc.fr jeweils Hunderttausende von Lookups. Warum diese Ziele? Die Konstellation europäischer Unternehmensdomains lässt mich einen CDN-, Wiederherstellungsdienst oder Scanner vermuten, der versucht, veraltete Caches aufzufrischen.
• Der 24-Stunden-Export zeigt ein noch größeres Bild: cbs.nl, scb.se, atlassian.com, abb.com und up.pt generierten gemeinsam über 250 Millionen Abfragen. Dieses Volumen ist kein zufälliges Rauschen – entweder groß angelegte Clients oder ein hartnäckiges Gerät, das nie mit dem Auflösen aufhört.
• Die geschäftigsten Clients waren eine Handvoll IPv4-Adressen der Bereiche 45.179.* und 45.6.*, die jeweils über 5k Abfragen in den beobachteten fünf Minuten abfeuerten. Sie könnten Teil eines ISPs oder einer Scanner-Farm sein, aber was auch immer sie sind, die Dashboards machen die Verfolgung einfach.

Was zeigt das? Es veranschaulicht, wie exponierte DNS-Infrastruktur selbst dann zu einem passiven Feed interessanten Traffics werden kann, wenn sie nicht beworben wird. Das Internet stellt weiterhin Fragen, und dieses Setup hört einfach aufmerksam zu. Falls Sie neugierig sind, wie dieses Experiment in meine breitere Arbeit passt, schauen Sie in die anderen Repos – manchmal verfolge ich eine Idee wie diese und muss sehen, wohin sie führt.

Wie sich dieses Experiment angefühlt hat

• Dieses Setup läuft für ein paar Cent und fühlt sich dennoch wie ein ganzes Forschungslabor an. Dem Resolver dabei zuzusehen, wie er sich mit unaufgeforderten Abfragen füllt, ließ den Stack lebendig wirken – irgendwie beunruhigend, aber faszinierend.
• Ich filtere nichts, also wenn Sie es einem Stresstest unterziehen oder Ihre eigenen Skripte darauf richten möchten, nur zu. Die Dashboards zeigen Ihnen genau, wie viel Rauschen Sie verursacht haben.
• Die Exporte machen es einfach, dieses Rauschen zu bewahren. Packen Sie den Ordner exports/ in ein ZIP oder hängen Sie die CSVs direkt an, wo immer Sie die Geschichte erzählen.
• Ich bin immer noch neugierig auf diese Domains und Client-IPs; wenn Sie ähnliche Muster auf Ihrem eigenen Honeypot sehen, hinterlassen Sie die Statistiken hier, damit wir unsere Beobachtungen vergleichen können.

Wo es von hier aus weitergehen kann

• Fügen Sie Alertmanager oder benutzerdefinierte Skripte hinzu, wenn Sie auf Anomalien wie SERVFAIL-Ausbrüche oder plötzliche NXDOMAIN-Stürme reagieren möchten.
• Erweitern Sie export_dashboard_data.py oder Loki-Abfragen um zusätzliche Metadaten (Client-ASN, SERVFAIL-Grund, Land), um tiefere Fragen zu beantworten.
• Speisen Sie die Loki-Ausgabe in eine sekundäre Analyse-Pipeline ein oder laden Sie die Prometheus-CSVs in ein Notebook für Klassifikationsexperimente.
• Halten Sie die Geschichte am Leben: Führen Sie den Exporter mit neuen Fenstern erneut aus (--duration 12h, --end ...), bewahren Sie die Ausgaben in mit Zeitstempeln versehenen Verzeichnissen auf und aktualisieren Sie diese README mit den neuen Statistiken, damit die Handlung aktuell bleibt.

Wenn Sie mit Ihrem eigenen Honeypot folgen, aktualisieren Sie diese README mit Statistiken aus Ihren Exporten, damit wir Geschichten vergleichen und sehen können, ob dieselben Seiten und Clients immer wieder zurückkommen.

Rechtliches

Dieses Projekt wird „wie besehen“ bereitgestellt. Es gibt keinerlei Garantien, weder ausdrücklich noch stillschweigend, einschließlich, aber nicht beschränkt auf die Garantie der Marktgängigkeit, der Eignung für einen bestimmten Zweck oder der Nichtverletzung von Rechten, und ich hafte nicht für Schäden, die aus seiner Nutzung entstehen. Sie übernehmen alle Risiken, die mit dem Bereitstellen, Konfigurieren oder Betreiben dieses Stacks verbunden sind.

Unterstützung

Wenn Sie dieses Projekt nützlich finden, erwägen Sie, es zu unterstützen: