我运行DNS蜜罐的头24小时

作为一名大部分时间都埋头于可观测性工具的工程师，偶尔会有一些我必须去实践的想法。这就是其中一次实验：在一个干净的IP上启动一个DNS解析器，该IP未被任何人宣传，然后让互联网随意与之通信。这个解析器唯一的任务就是保持安静、记录一切，并将结果查询输入Grafana。执行一次docker compose up -d后，我拥有了Unbound、Loki、Prometheus、Grafana和Traefik，它们追踪实时流量并打印出好奇心、错误配置以及偶尔出现的扫描器的直方图。这份README就是第一天的报告——这个栈捕获了什么，为什么它对我很重要，以及它揭示了当前安全环境的哪些方面。

实验

我故意没有引入任何人为信号——没有数据包丢弃，没有定制响应，没有缓解措施。只有启用了日志记录的Unbound、跟踪日志文件的Loki、抓取导出器指标的Prometheus、作为Grafana前端的Traefik，以及将它们组合在一起的Docker Compose。解析器位于94.130.27.226，这是一个我找到的“干净”IPv4地址（如果你想了解噪音前的基线，请访问https://www.abuseipdb.com/check/94.130.27.226查看其状态），然后我让世界自行其是。只需一台笔记本电脑就能观察所有面板，在我想搅动环境时运行`tools/dns_query_storm.sh`，然后让噪音回落到全球互联网选择发送的任何模式。

你可以在此处实时查看那些仪表盘：https://dns.cybersafeintl.co.uk/public-dashboards/eb554b5b74e14f4d95e376c0033ee83d，但它们运行在栈中最低端的服务器上，因此在查询量大时刷新可能会变慢。

仪表盘捕获的内容

• 吞吐量：Prometheus抓取Unbound导出器的unbound_total_num_queries指标，因此“吞吐量（QPS，5分钟速率）”面板显示每秒查询数，并按来源细分。该视图回答了“谁在猛击解析器？”这个问题——突增直接指向孟加拉国或波兰的ASN，而日志可以轻松判断SERVFAIL/NXDOMAIN风暴是否伴随突增发生。
• 顶级客户端：Loki的LogQL按client_ip分组，仪表盘已将所有内容包装在topk(sort_desc(...))中。这保持了面板的整洁，而导出器脚本让我可以将相同的查询转储到CSV文件中，用于离线分析、报告或可重现的故事。首次捕获显示45.179.*和45.6.*范围内的五个IP地址，每个在五分钟内发送了5000+次查询——要么是扫描器农场，要么是激进的客户端。
• 域名：“顶级域名”面板展示了5分钟和24小时窗口内的qname热度。5分钟快照中出现了scb.se、dhl.com和cmu.edu，而24小时导出则包括cbs.nl、scb.se、atlassian.com、abb.com和up.pt。为什么是这些域名？这就是有趣的部分——它们是合法服务、错误配置的解析器，还是追逐过时记录的投机扫描器？如果你有理论，请告诉我。
• 日志：Loki也流式传输原始日志尾部，因此你可以看到与SERVFAIL、缓存预热或客户端扩展查询组合相关的峰值。将这些日志与导出的CSV结合起来，你可以重建世界在询问什么的时间线。

你看到的每个面板在exports/中都有对应的CSV文件；当你想要将原始故事附加到博客文章或事件报告中时，将它们打包（zip -r exports.zip exports/）。

幕后组件

• docker-compose.yml 通过一个命令启动Unbound、Unbound导出器、Loki + Promtail、Prometheus、Grafana和Traefik。
• unbound/ 存储解析器配置和日志。TTL控制、serve-expired和缓存设置保证了保真度，使我们能够捕获客户端实际请求的内容。
• prometheus/、loki/和grafana/目录存储数据和配置供应文件，因此指标和仪表盘在重启后仍然存在。
• grafana/dashboards/unbound-traffic-insights.json 已预配置了你看到的视图；所有PromQL/Loki查询已经聚合和排序，以保持面板可读。
• tools/dns_query_storm.sh 让你在需要测试响应时间时模拟查询风暴。
• redeploy.sh 通过单个脚本自动化拆卸整个栈、拉取更新和重建。
• export_dashboard_data.py 现在遍历仪表盘JSON，命中每个Prometheus/Loki查询，并将清理后的CSV文件写入exports/目录以供分享。

开始使用

1. cd hetzner_deploy/unbound-dns
2. cp .env.example .env 并配置 GRAFANA_DOMAIN、Grafana管理员凭据、LETSENCRYPT_EMAIL 以及任何你需要的TLS覆盖。
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. 将DNS客户端指向主机上的端口53，让Traefik作为Grafana的HTTPS前端，几分钟内你就能看到被动流量。

导出并分享你看到的内容

1. pip install requests（导出器是纯Python）。
2. python export_dashboard_data.py --duration 24h --outdir exports/24h --timeout 90 拉取所有仪表盘查询，转换为CSV，并将结果放入exports/24h目录。
3. zip -r exports.zip exports/ 打包原始表格，然后发布、附加到博客文章或发送给协作者。
4. 使用--duration 6h或--end时间戳重新运行以获得目标切片，或者如果你只想要域名面板，使用--filter domains。

我在第一天注意到的

• 在5分钟粒度导出中，scb.se、dhl.com、cmu.edu、up.pt和utc.fr每个都产生了数十万次查找。为什么是这些目标？欧洲企业域名的集合让我怀疑是CDN、恢复服务或试图重新填充过时缓存的扫描器。
• 24小时导出描绘了更大的图景：cbs.nl、scb.se、atlassian.com、abb.com和up.pt共同产生了超过2.5亿次查询。这种数量级不是随机噪音——要么是大规模客户端，要么是永不停止解析的持久设备。
• 最繁忙的客户端是少数几个45.179.*和45.6.*的IPv4地址，每个在观察的5分钟内发射了超过5000次查询。它们可能是ISP或扫描器农场的一部分，但无论它们是什么，仪表盘使得追踪它们变得轻而易举。

这说明了什么？它展示了即使DNS基础设施未被宣传，它如何成为有趣流量的被动馈送。互联网不断提问，而这个设置只是仔细倾听。如果你好奇这个实验如何融入我的更广泛工作，请查看其他仓库——有时我运行这样的想法，必须看看它会走向何方。

这个实验的感觉

• 这个设置运行成本极低，却感觉像一个完整的研究实验室。看着解析器充满未经请求的查询，让整个栈感觉活了起来——有点令人不安但又引人入胜。
• 我没有过滤任何东西，所以如果你想对其进行压力测试或将你自己的脚本指向它，请随意。仪表盘会精确显示你搅起了多少噪音。
• 导出使得保留这些噪音变得容易。打包exports/文件夹或直接附加CSV文件，无论你在哪里讲述这个故事。
• 我仍然对那些域名和客户端IP感到好奇；如果你在自己的蜜罐上看到类似模式，请把数据贴回来，以便我们比较笔记。

接下来可以做什么

• 添加Alertmanager或自定义脚本，如果你想对异常（如SERVFAIL突增或突然的NXDOMAIN风暴）做出反应。
• 扩展export_dashboard_data.py或Loki查询，添加额外元数据（客户端ASN、SERVFAIL原因、国家）以回答更深层次的问题。
• 将Loki输出输入辅助分析管道，或将Prometheus CSV转储到笔记本中进行分类实验。
• 保持故事活跃：使用新的窗口（--duration 12h，--end ...）重新运行导出器，将输出放在带时间戳的目录中，并用新统计数据更新此README，使情节保持最新。

如果你正在跟进自己的蜜罐，请用你导出的统计数据更新此README，以便我们比较故事，看看相同的站点和客户端是否不断返回。

法律声明

本项目按“原样”提供。不提供任何形式的明示或暗示的担保，包括但不限于适销性、特定用途适用性和非侵权性，并且我不对因使用本项目而产生的任何损害承担责任。你承担部署、配置或操作此栈的所有风险。

支持

如果你觉得这个项目有用，可以考虑支持它：