Mes premières 24 heures avec un honeypot DNS

En tant qu’ingénieur qui passe la plupart de ses journées plongé dans les outils d’observabilité, j’ai parfois une idée que je dois simplement suivre. C’était l’une de ces expériences : lancer un résolveur DNS sur une IP propre que personne n’annonce, puis laisser Internet lui parler quand même. Le seul travail du résolveur était de rester silencieux, de tout journaliser et d’alimenter Grafana avec les requêtes résultantes. Un docker compose up -d plus tard, j’avais Unbound, Loki, Prometheus, Grafana et Traefik qui suivaient le trafic en direct et imprimaient des histogrammes de curiosité, de mauvaise configuration et du scanner occasionnel. Ce README est le rapport de ce premier jour, ce que la pile capture, pourquoi c’est important pour moi et ce que cela met en lumière sur le paysage actuel de la sécurité.

L’expérience

J’ai intentionnellement introduit zéro signal de mon côté, pas de perte de paquets, pas de réponses adaptées, pas d’atténuation. Juste Unbound avec la journalisation activée, Loki qui suit le fichier de logs, Prometheus qui scrape les métriques de l’exportateur, Traefik qui sert de frontend à Grafana et Docker Compose qui les relie. Le résolveur se trouvait sur 94.130.27.226, une IPv4 rafraîchissante « propre » que j’avais trouvée (vérifiez son état sur https://www.abuseipdb.com/check/94.130.27.226 si vous voulez une base pré-bruit), et j’ai laissé le monde faire son affaire. Un seul ordinateur portable pouvait regarder chaque panneau, lancer tools/dns_query_storm.sh quand je voulais remuer la marmite, puis laisser le bruit retomber dans les schémas que l’Internet global choisissait d’envoyer.

Vous pouvez jeter un œil à ces tableaux de bord en direct sur https://dns.cybersafeintl.co.uk/public-dashboards/eb554b5b74e14f4d95e376c0033ee83d, bien qu’ils soient hébergés sur le serveur le plus bas de gamme de la pile, attendez-vous donc à des rafraîchissements lents pendant les requêtes lourdes.

Ce que les tableaux de bord capturent

• Débit : Prometheus scrape la métrique unbound_total_num_queries de l’exportateur Unbound, donc le panneau « Throughput (QPS, 5m rate) » montre les requêtes par seconde et les décompose par source. Cette vue répond à la question « qui martèle le résolveur ? », les pics soudains pointent directement vers des ASN basés au Bangladesh ou en Pologne, et les logs permettent de voir facilement si des tempêtes de SERVFAIL/NXDOMAIN accompagnent les rafales.
• Top clients : LogQL de Loki groupe par client_ip, et les tableaux de bord intègrent déjà topk(sort_desc(...)). Cela garde les panneaux propres tandis que le script d’exportation me permet de vider les mêmes requêtes dans des CSV pour une analyse hors ligne, des rapports ou des histoires reproductibles. La première capture a montré cinq adresses IP dans les plages 45.179.* et 45.6.*, chacune émettant plus de 5k requêtes en cinq minutes, soit une ferme de scanners, soit un client agressif.
• Domaines : Les panneaux « Top domains » exposent la popularité de qname sur des fenêtres de 5 min et 24 h. L’instantané de 5 minutes incluait scb.se, dhl.com et cmu.edu, tandis que l’exportation de 24 h incluait cbs.nl, scb.se, atlassian.com, et . Pourquoi ces domaines ? C’est la partie intéressante, s’agit-il de services légitimes, de résolveurs mal configurés ou de scanners opportunistes à la recherche d’enregistrements obsolètes ? Envoyez-moi un mot si vous avez une théorie.

Chaque panneau que vous voyez a un CSV correspondant dans exports/ ; regroupez-les (zip -r exports.zip exports/) quand vous voulez joindre l’histoire brute à un article de blog ou à un rapport d’incident.

Ce qu’il y a sous le capot

• docker-compose.yml démarre Unbound, l’exportateur Unbound, Loki + Promtail, Prometheus, Grafana et Traefik en une seule commande.
• unbound/ stocke les configurations du résolveur et les logs. Les contrôles TTL, serve-expired et les paramètres de cache maintiennent la fidélité afin que nous capturions ce que les clients demandent réellement.
• Les répertoires prometheus/, loki/ et grafana/ contiennent les données et les fichiers de provisionnement afin que les métriques et les tableaux de bord survivent aux redémarrages.
• grafana/dashboards/unbound-traffic-insights.json est pré-provisionné avec la vue que vous voyez ; toutes les requêtes PromQL/Loki agrègent et trient déjà pour garder les panneaux lisibles.
• tools/dns_query_storm.sh vous permet de simuler des tempêtes de requêtes lorsque vous devez tester les temps de réaction.
• redeploy.sh automatise la mise hors service de toute la pile, la récupération des mises à jour et la reconstruction avec un seul script.
• export_dashboard_data.py parcourt maintenant le JSON du tableau de bord, frappe chaque requête Prometheus/Loki et écrit des fichiers CSV nettoyés dans un répertoire pour les partager.

Pour commencer

1. cd hetzner_deploy/unbound-dns
2. cp .env.example .env et configurez GRAFANA_DOMAIN, les identifiants administrateur Grafana, LETSENCRYPT_EMAIL et toutes les surcharges TLS nécessaires.
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. Pointez un client DNS vers l’hôte sur le port 53, laissez Traefik se placer sur HTTPS pour Grafana, et vous observez le trafic passif en quelques minutes.

Exporter et partager ce que vous voyez

1. pip install requests (l’exportateur est en Python pur).
2. python export_dashboard_data.py --duration 24h --outdir exports/24h --timeout 90 pour récupérer chaque requête du tableau de bord, la convertir en CSV et placer les résultats dans exports/24h.
3. zip -r exports.zip exports/ pour regrouper les tables brutes avant de les publier, de les joindre à un article de blog ou de les envoyer à des collaborateurs.
4. Réexécutez avec --duration 6h ou des horodatages --end pour des tranches ciblées, ou utilisez --filter domains si vous ne voulez que les panneaux de domaines.

Ce que j’ai remarqué le premier jour

• Sur l’exportation granulaire de 5 minutes, scb.se, dhl.com, cmu.edu, up.pt et utc.fr ont chacun généré des centaines de milliers de requêtes. Pourquoi ces cibles ? La constellation de domaines d’entreprises européennes me fait soupçonner un CDN, un service de restauration ou un scanner qui tente de réhydrater des caches obsolètes.
• L’exportation de 24 heures dresse un tableau encore plus large : cbs.nl, scb.se, atlassian.com, abb.com et up.pt ont collectivement généré plus de 250 millions de requêtes. Ce niveau de volume n’est pas un bruit aléatoire, soit des clients à grande échelle, soit un appareil persistant qui ne cesse jamais de résoudre.
• Les clients les plus actifs étaient une poignée d’adresses IPv4 45.179.* et 45.6.*, chacune dépassant 5k requêtes dans les cinq minutes observées. Ils font peut-être partie d’un FAI ou d’une ferme de scanners, mais quoi qu’ils soient, les tableaux de bord les rendent faciles à suivre.

Qu’est-ce que cela met en évidence ? Cela illustre à quel point une infrastructure DNS exposée peut devenir un flux passif de trafic intéressant, même lorsqu’elle n’est pas annoncée. Internet continue de poser des questions, et cette configuration se contente d’écouter attentivement. Si vous êtes curieux de savoir comment cette expérience s’inscrit dans mon travail plus large, consultez les autres dépôts, parfois je lance une idée comme celle-ci et je dois voir où elle mène.

Ce que cette expérience m’a procuré comme sensation

• Cette configuration fonctionne pour presque rien et donne pourtant l’impression d’un laboratoire de recherche complet. Regarder le résolveur se remplir de requêtes non sollicitées a rendu la pile vivante, un peu dérangeant mais fascinant.
• Je ne filtre rien, donc si vous voulez le tester ou y pointer vos propres scripts, allez-y. Les tableaux de bord vous montreront exactement combien de bruit vous avez créé.
• Les exportations facilitent la conservation de ce bruit. Compressez le dossier exports/ ou joignez directement les CSV là où vous racontez l’histoire.
• Je suis toujours curieux à propos de ces domaines et adresses IP de clients ; si vous voyez des schémas similaires sur votre propre honeypot, partagez les statistiques ici pour que nous puissions comparer nos notes.

Où aller à partir de là

• Ajoutez Alertmanager ou des scripts personnalisés si vous voulez réagir à des anomalies comme des rafales de SERVFAIL ou des tempêtes soudaines de NXDOMAIN.
• Étendez export_dashboard_data.py ou les requêtes Loki avec des métadonnées supplémentaires (ASN client, raison SERVFAIL, pays) pour répondre à des questions plus approfondies.
• Alimentez la sortie de Loki dans un pipeline d’analyse secondaire, ou importez les CSV de Prometheus dans un notebook pour des expériences de classification.
• Gardez l’histoire vivante : réexécutez l’exportateur avec de nouvelles fenêtres (--duration 12h, --end ...), conservez les sorties dans des répertoires horodatés et mettez à jour ce README avec les statistiques fraîches pour que l’intrigue reste actuelle.

Si vous suivez avec votre propre honeypot, mettez à jour ce README avec les statistiques de vos exportations afin que nous puissions comparer les histoires et voir si les mêmes sites et clients reviennent sans cesse.

Légal

Ce projet est fourni « en l’état ». Il n’y a aucune garantie d’aucune sorte, expresse ou implicite, y compris mais sans s’y limiter la qualité marchande, l’adéquation à un usage particulier ou l’absence de contrefaçon, et je ne suis pas responsable des dommages résultant de son utilisation. Vous assumez tous les risques associés au déploiement, à la configuration ou à l’exploitation de cette pile.

Soutien

Si vous trouvez ce projet utile, pensez à le soutenir :