amitambekar510/sentinel-ioc-block

# 恶意 IOC 自动拦截 — 用于边界防火墙的 TOR / 恶意 IP 源摄取    **作者 / 创意所有者：** Amit Ambekar **状态：** 提案 / 概念验证 **分类：** SOC — 威胁情报、网络防御、防火墙自动化 ## 1. 概述 本项目提出了一条自动化 pipeline，用于摄取公开的 **Tor 出口节点**和**恶意 IP / IOC 源**，并将它们作为动态拦截/拒绝列表推送到我们**由 SOC 管控的边界防火墙**中。 核心理念：任何到达防火墙的入站或出站流量都会与这些实时威胁源进行比对。如果源/目的 IP 匹配已知的 Tor 出口节点、代理、垃圾邮件机器人或滥用报告 IP，防火墙会自动**拦截/拒绝**该连接，使其无法到达内部系统——从而减少 SOC 的人工分拣工作量并缩小暴露窗口。 验证通过后，我们可以评估将同样的匹配流量日志输入到 **ELK（通过 Logstash）** 中，以实现可视化、告警和长期趋势分析——这有待于对许可证、数据量和基础设施影响的内部审查。 ## 2. 问题描述 - 恶意攻击者经常通过 Tor 出口节点、开放代理和已知的滥用 IP 段来路由攻击流量，以掩盖其来源。 - 目前，这些流量是在事后被动捕获的（事件发生后），而不是在边界上进行主动防御。 - 我们目前尚未将自动化、持续刷新的 IOC 源集成到防火墙中。 ## 3. 目标 构建一个轻量级的、定时的获取器，要求如下： 1. 从受信任的、免费的威胁情报源拉取 IOC/IP 列表。 2. 对它们进行标准化/去重。 3. 将它们发布为防火墙可消费的对象（地址组 / 动态列表）。 4. 在遵守每个源速率限制的安全时间间隔内进行刷新。 5. （阶段 2，有待内部审查）通过 Logstash 将匹配/拒绝日志发送到 ELK，用于仪表板展示和告警。 ## 4. 数据源 ### 4.1 Tor 出口节点 | 来源 | URL | 备注 | |---|---|---| | Tor 官方项目 | https://check.torproject.org/exit-addresses | 目前我们找到的唯一直接/官方的 Tor 出口列表。需要探索更多直接来源。 | | dan.me.uk Tor 节点列表（全部 + 出口） | https://www.dan.me.uk/tornodes | 完整的节点 + 出口节点列表。 | | dan.me.uk 原始列表（仅出口） | https://www.dan.me.uk/torlist/?exit | **受速率限制 — 请参阅下方的限制说明。** | | dan.me.uk 原始列表（完整） | https://www.dan.me.uk/torlist/?full | **受速率限制 — 请参阅下方的限制说明。** | **重要限制（dan.me.uk）：** 他们的数据每 30 分钟才更新一次，频繁/激进的轮询会导致**至少 30 分钟的 IP 暂停处罚（Suspended）**，屡犯者将面临永久封禁的风险。根据他们自己的声明： **决策：** 我们**不会**高频轮询 dan.me.uk。最小获取间隔必须**≥120 分钟**，以远低于其限制并避免被暂停。这需要在调度器/cron 级别强制执行。 ### 4.2 FireHOL IP 列表（主要推荐来源） GitHub 项目（大约每 5–10 小时更新一次）：https://github.com/firehol/blocklist-ipsets 主页：https://iplists.firehol.org/ 建议初始摄取的列表： 1. `abuseipdb_30d.ipset` — https://github.com/firehol/blocklist-ipsets/blob/master/abuseipdb_30d.ipset 2. `botscout_30d.ipset` — https://github.com/firehol/blocklist-ipsets/blob/master/botscout_30d.ipset 3. `cleantalk_30d.ipset` — https://github.com/firehol/blocklist-ipsets/blob/master/cleantalk_30d.ipset 4. `cleantalk_new_30d.ipset` — https://github.com/firehol/blocklist-ipsets/blob/master/cleantalk_new_30d.ipset 5. `dshield_30d.netset` — https://github.com/firehol/blocklist-ipsets/blob/master/dshield_30d.netset 6. `firehol_abusers_30d.netset` — https://github.com/firehol/blocklist-ipsets/blob/master/firehol_abusers_30d.netset 7. `sslproxies_30d.ipset` — https://github.com/firehol/blocklist-ipsets/blob/master/sslproxies_30d.ipset 8. `stopforumspam_30d.ipset` — https://github.com/firehol/blocklist-ipsets/blob/master/stopforumspam_30d.ipset 9. `socks_proxy_30d.ipset` — https://github.com/firehol/blocklist-ipsets/blob/master/socks_proxy_30d.ipset 10. `tor_exits_30d.ipset` — https://github.com/firehol/blocklist-ipsets/blob/master/tor_exits_30d.ipset ### 4.3 AbuseIPDB 社区黑名单（通过 borestad 镜像） GitHub：https://github.com/borestad/blocklist-abuseipdb/tree/main 推荐的原始列表：https://raw.githubusercontent.com/borestad/blocklist-abuseipdb/main/abuseipdb-s100-30d.ipv4 **维护者的使用指南：** - 使用** 30 天或更短**时间窗口的列表，以避免误报。 - **不要**使用 `abuseipdb-s100-all.ipv4` — 该列表仅供统计使用，不用于强制执行拦截。 - `s100` = 约 100% 的置信度评级。 - 维护者认为来自此列表的 IPv6 覆盖/拦截“几乎毫无用处” — 请将其视为低优先级。 - **所有底层功劳均归属于 AbuseIPDB**（https://www.abuseipdb.com/）— 此仓库仅是一个精选的镜像/派生项目。 ## 5. 刷新间隔策略 | 来源 | 最小安全间隔 | 原因 | |---|---|---| | dan.me.uk (`?exit`, `?full`) | 120 分钟（他们自己的数据每 30 分钟刷新一次，但我们将缓冲时间增加 4 倍以确保安全） | 激进的轮询 → 导致临时/永久的 IP 暂停处罚 | | check.torproject.org/exit-addresses | 60 分钟（提议中 — 待验证） | 未找到文档记录的硬性限制；但无论如何都应保持保守策略 | | FireHOL ipsets (GitHub) | 60 分钟（源本身每 5–10 小时更新一次） | GitHub 原始文件存在限制；轮询速度快于源更新频率毫无益处 | | AbuseIPDB (borestad mirror) | 60 分钟（源大约每天更新） | 同上 — 遵守上游更新节奏 | ## 6. 提议架构（高级层面） ``` [Scheduler / Cron Job] │ ▼ [Fetcher Script] ── pulls & normalizes IOC/IP lists (Tor + FireHOL + AbuseIPDB) │ ▼ [Dedup / Validate / Format] ── convert to firewall-native object format │ ▼ [SOC-Controlled Firewall] ── dynamic address group / deny list, auto-applied │ ▼ Traffic hits firewall → matched against IOC list │ ┌────┴─────┐ ▼ ▼ Match No Match │ │ DENY/BLOCK Allow (normal flow) │ ▼ [Logstash] → [ELK] (Phase 2 — pending internal review) → Dashboards, alerting, historical trend analysis ``` ## 7. 分阶段推出计划 1. **阶段 0 — 试点（本提案）：** 部署在**由 SOC 管控/观测用的防火墙上**（不全面应用于生产环境），以验证源质量、误报率和匹配量。 2. **阶段 1 — 调优：** 审查试点数据，调整刷新频率和源选择，如有必要则剔除产生噪音的列表。 3. **阶段 2 — ELK 集成（待内部检查）：** 通过 Logstash 将匹配/拒绝的流量日志转发到 ELK，用于仪表板展示和告警。在继续之前，需要在内部确认 ELK 的容量/许可证。 4. **阶段 3 — 生产环境推出：** 验证通过后，扩展到更广泛的防火墙资产中。 ## 8. 基础设施说明 — 防火墙隔离 我们建议为 SOC 操作配备**专用/独立的防火墙**，使其与处理**客户端通信流量**（包括发往 Logstash 的流量）的防火墙区分开来。这种隔离可以： - 防止 SOC 的威胁情报/测试流量影响面向客户端的通信路径。 - 保持 Logstash 摄取流量的隔离性，更易于监控和故障排除。 - 降低因源数据意外导致误报拦截所带来的爆炸半径。 ## 10. 许可证 / 使用说明 本仓库仅记录了**创意、架构和数据源参考**。此处不存储任何专有的防火墙配置、凭证或内部基础设施详情。任何实现脚本都应遵守每个上游源的速率限制和使用条款。 *有关如何对此创意/文档提出修改建议，请参阅 `CONTRIBUTING.md`。*

标签：IP黑名单, 内容过滤, 域名收集, 威胁情报, 安全运营中心 (SOC), 开发者工具, 私有化部署, 网络安全, 防御规避, 防火墙自动化, 隐私保护