BrendanH3000/OTX-DNS-Threat-Feed-Pipeline
GitHub: BrendanH3000/OTX-DNS-Threat-Feed-Pipeline
整合 Pi-hole、AlienVault OTX 和 Wazuh SIEM 的实时 DNS 威胁情报流水线，实现对恶意 C2 域名查询的自动检测与告警。
Stars: 0 | Forks: 0
# -OTX-DNS-Threat-Feed-Pipeline
实时 DNS 威胁情报流水线，集成了 Pi-hole、AlienVault OTX 和 Wazuh SIEM。Python 脚本从 OTX 拉取恶意 C2 域名，并写入 Wazuh CDB 列表。自定义解码器解析 Pi-hole DNS 日志，检测规则交叉引用实时查询，当发现已知的恶意域名活动时触发高严重性警报。
项目笔记/步骤
1. 首先，我需要通过 SSH 连接到我的防火墙，并将 DNS 日志转发到我的 Wazuh SIEM。
2. 据我所知，Unifi 没有内置的 DNS 转发功能，找到解决方案可能比较棘手。
3. 看起来在 Unifi OS 上进行的本地修复可能会因系统更新而被覆盖，安装我自己的本地 DNS 服务器也许是更简单的选择，我仍然可以使用 Unifi 原生 DNS 作为故障转移。
4. 我使用了 Pi-hole 容器安装脚本在 Proxmox 上安装，因为我的 Proxmox 实例上没有 Debian ISO 模板。(var_version="12" bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/pihole.sh)")
5. 现在我需要在我的家庭实验室网络上配置本地 DNS，
6. 现在有了本地 DNS 服务器和内置 Unifi OS 的故障转移功能，我可以在我的 Pi-hole 服务器上创建一个 syslog 转发，将其发送到我 Proxmox 主机上的 syslog 服务器。
7. 需要在 Pi-hole 容器上安装 rsyslog 并配置其转发到 syslog 服务器。
8. 在 Pi-hole 上安装完成后，需要将 rsyslog 指向 DNS 日志的正确文件。
9. 这里我们可以看到日志从 Pi-hole 的 514 端口流出。
10. 我们可以看到日志从 Pi-hole 源流入 syslog。
11. OTX 脚本从两个源拉取恶意域名 → 将其写入位于 /var/ossec/etc/lists/otx-domains 的 CDB 列表文件
Pi-hole DNS 日志通过 rsyslog → syslog 服务器 → Wazuh 流动
Wazuh 解码器解析 Pi-hole 日志并提取查询的域名
Wazuh 规则检查该域名是否与 CDB 列表中的内容匹配 → 如果匹配则触发警报
12. 现在我们需要生成一个 OTX 开放威胁交换 的 API 密钥，我们将在 Python 脚本中引用它
13. 我决定在这个实例中使用针对恶意软件 C2 域名的威胁源。
14. 然后我编写了 API 调用函数并收到了 JSON 响应，获取响应后，我创建了一个解析器函数来返回被报告的域名。
15. 现在我需要回到 Pi-hole 日志并创建一个解码器，该解码器可用作父触发器并在 SIEM 中记录 DNS 查询。示例："Mar 8 15:33:31 dnsmasq[207]: query[A] default.exp-tas.com from 192.168.1.98"
16. 这是我在正则表达式测试器上的解码器示例正则表达式。
17. 这是将 DNS 日志发送到我的 SIEM 的父规则和子规则，子规则将交叉引用 OTX 导入的域名列表，如果匹配则触发高严重性警报。
18. 检查 Wazuh，看起来日志正在流动，其中包含此 vscode 相关的 DNS 查询。
19. 将脚本移动到 Wazuh 服务器后，我创建了环境变量文件和 CDB 列表，该列表将在脚本运行时自动填充。
20. 然后在 ossec.conf 文件中，我附加了 CDB 列表，以便 Wazuh 管理器在匹配来自威胁交换的指标时进行引用（在列表目录中添加了 otx-domains）。
21. 添加 cron 作业，将允许 CDB 域名列表每天两次从我订阅的威胁源或我在 curl 请求中定义的源进行更新。
22. 现在是使用 Wazuh 警报测试器 /var/ossec/bin/wazuh-logtest 进行测试的时候了。我输入了一条包含来自 IOC 源域名的伪造日志。看起来警报将会生成。
23. 完整的威胁情报流水线现在已正常工作。来自网络上所有设备的 DNS 查询流经 Pi-hole -> rsyslog -> Wazuh，在那里它们被解码并与来自 AlienVault OTX 的实时 IOC 列表进行匹配。当设备查询已知的恶意 C2 域名时，SIEM 中会触发 12 级警报，提供准实时的可见性。
**后续步骤/改进：**
- 订阅更多 OTX 威胁源以扩大覆盖范围
- 在我所有的终端上部署 Wazuh agents 以进行基于哈希的 IOC 匹配
- 添加主动响应，以便在规则 100061 触发时自动在 Pi-hole 级别阻止恶意域名
- 使用 Wazuh API 集成 Grafana 仪表板以进行威胁可视化
6. 现在有了本地 DNS 服务器和内置 Unifi OS 的故障转移功能，我可以在我的 Pi-hole 服务器上创建一个 syslog 转发，将其发送到我 Proxmox 主机上的 syslog 服务器。
7. 需要在 Pi-hole 容器上安装 rsyslog 并配置其转发到 syslog 服务器。
8. 在 Pi-hole 上安装完成后，需要将 rsyslog 指向 DNS 日志的正确文件。
9. 这里我们可以看到日志从 Pi-hole 的 514 端口流出。
10. 我们可以看到日志从 Pi-hole 源流入 syslog。
11. OTX 脚本从两个源拉取恶意域名 → 将其写入位于 /var/ossec/etc/lists/otx-domains 的 CDB 列表文件
Pi-hole DNS 日志通过 rsyslog → syslog 服务器 → Wazuh 流动
Wazuh 解码器解析 Pi-hole 日志并提取查询的域名
Wazuh 规则检查该域名是否与 CDB 列表中的内容匹配 → 如果匹配则触发警报
12. 现在我们需要生成一个 OTX 开放威胁交换 的 API 密钥，我们将在 Python 脚本中引用它
13. 我决定在这个实例中使用针对恶意软件 C2 域名的威胁源。
14. 然后我编写了 API 调用函数并收到了 JSON 响应，获取响应后，我创建了一个解析器函数来返回被报告的域名。
15. 现在我需要回到 Pi-hole 日志并创建一个解码器，该解码器可用作父触发器并在 SIEM 中记录 DNS 查询。示例："Mar 8 15:33:31 dnsmasq[207]: query[A] default.exp-tas.com from 192.168.1.98"
16. 这是我在正则表达式测试器上的解码器示例正则表达式。
17. 这是将 DNS 日志发送到我的 SIEM 的父规则和子规则，子规则将交叉引用 OTX 导入的域名列表，如果匹配则触发高严重性警报。
18. 检查 Wazuh，看起来日志正在流动，其中包含此 vscode 相关的 DNS 查询。
19. 将脚本移动到 Wazuh 服务器后，我创建了环境变量文件和 CDB 列表，该列表将在脚本运行时自动填充。
20. 然后在 ossec.conf 文件中，我附加了 CDB 列表，以便 Wazuh 管理器在匹配来自威胁交换的指标时进行引用（在列表目录中添加了 otx-domains）。
21. 添加 cron 作业，将允许 CDB 域名列表每天两次从我订阅的威胁源或我在 curl 请求中定义的源进行更新。
22. 现在是使用 Wazuh 警报测试器 /var/ossec/bin/wazuh-logtest 进行测试的时候了。我输入了一条包含来自 IOC 源域名的伪造日志。看起来警报将会生成。
23. 完整的威胁情报流水线现在已正常工作。来自网络上所有设备的 DNS 查询流经 Pi-hole -> rsyslog -> Wazuh，在那里它们被解码并与来自 AlienVault OTX 的实时 IOC 列表进行匹配。当设备查询已知的恶意 C2 域名时，SIEM 中会触发 12 级警报，提供准实时的可见性。
**后续步骤/改进：**
- 订阅更多 OTX 威胁源以扩大覆盖范围
- 在我所有的终端上部署 Wazuh agents 以进行基于哈希的 IOC 匹配
- 添加主动响应，以便在规则 100061 触发时自动在 Pi-hole 级别阻止恶意域名
- 使用 Wazuh API 集成 Grafana 仪表板以进行威胁可视化标签：C2检测, DNS安全, IP 地址批量处理, Pi-hole, Proxmox, Python, Syslog, Wazuh, 信标分析, 威胁情报, 安全管道, 家庭实验室, 开发者工具, 恶意域名, 无后门, 私有化部署, 网络安全, 逆向工具, 防御规避, 隐私保护