基于行为流量分析、Random Forest 分类以及内核级 ipset/iptables 执行的自适应两阶段 Layer 4 DDoS 缓解网关。
第一道防线
一个自适应的两阶段第 4 层体积型 DDoS 缓解网关。
作者: Abdullah Armiyao
项目: 基于行为流量分析的自适应两阶段近实时第 4 层体积型 DDoS 缓解框架

大多数 DDoS 缓解使用固定阈值:阻断任何每秒发送数据包数超过某个硬编码数值的来源。这在两个方向上都会失效。合法流量在繁忙时段激增,真实用户被阻断;或者攻击者恰好保持在阈值线以下并成功通过。
FLOD 学习你的正常流量是什么样子,并移动自己的检测边界以与之匹配。它能区分 DDoS 洪泛和突发流量(合法的流量激增),无需任何人手动调整阈值。
它以内联方式部署在流量源与受保护主机之间的网关上,并在内核中丢弃或限速违规来源。
仪表盘将其阻断的地址标记为攻击者,因此即使不了解网络布局的人也能分辨哪些发送方是恶意的。被限速的地址单独列出,因为限速也用作预防措施,并且会一次性应用于整个组。
阶段 1 是数据包路径上的 Rust 传感器。它捕获发往受保护主机的每个数据包,在短窗口内计算速率和来源多样性,并将它们与自身维护的基线进行比较。它只做算术运算,因此不会妨碍流量。
阶段 2 是 Python 服务。它每个窗口从阶段 1 接收一次摘要,用随机森林对其进行分类,并通过 ipset 和 iptables 实施内核级执行。隔离森林在每个窗口上与之并行运行,标记出与两个模型所学内容都不同的流量,以单独的 Anomalous 状态呈现,而不驱动执行。阶段 2 还提供 Web 仪表盘。
两者通过 Unix 域套接字连接。
模型在捕获的、带标签的流量上训练,而部署会持续捕获更多流量。隔离森林发现不熟悉的窗口,以及随机森林高置信度判定为 DDoS 的窗口,会被写入捕获文件。一个周期性任务用随机森林和第二个构建方式不同的模型对它们重新评分,只有当两者都以高置信度选择同一类别,且两者都在该行被捕获之后训练时,才会暂存一行用于训练。仪表盘中的审核页面显示暂存的行,每页 500 行,由人工决定是将它们合并到训练数据中还是丢弃。没有任何内容会自动进入训练集。
FLOD 仅基于数据包头部即可观察到的第 4 层体积型洪泛工作:速率、源 IP 熵、协议混合,以及流量在其最繁忙来源上的集中程度。在实践中,这意味着既高流量又集中的洪泛,来自一组有界的真实地址。
有一项明确不在范围内,另一项得到部分解决:
应用层攻击。 不解析请求内容,因此低速慢速请求洪泛和连接耗尽超出了仅头部特征集所能观察的范围。
随机化源欺骗。 为每个数据包伪造新的源地址会提高熵而不是降低熵,从而反转基于地址的特征所寻找的信号。源端口熵、TTL 方差和 TCP SYN 指纹多样性在地址伪造下保持不变,并弥补了这一检测盲点,但检测欺骗性洪泛比阻止它的问题更窄:阻断伪造地址仍然会惩罚真正拥有该地址的人,因此针对此类攻击的安全执行仍然悬而未决。参见检测和说明。
git clone https://github.com/DevInBlack001/ddos-reduction-system.git
cd ddos-reduction-system
sudo bash scripts/install.sh --interface <IFACE> --victim-ips <IP1>,<IP2>
sudo systemctl enable --now ddos-stage2
sudo systemctl enable --now ddos-stage1
安装程序会先构建 Stage 1,然后将 Stage 2 的代码和虚拟环境复制到 /opt/flod/stage2(由 root 拥有),并在那里设置管理账户,因为 Stage 2 以 root 身份运行,绝不能从非特权账户仍可写入的检出目录中执行任何内容。可变状态、数据库、JSON 配置、训练好的模型都存放在 /var/lib/flod 中。从此以后,检出目录仅作为源使用;重新运行 scripts/install.sh 或 scripts/update.sh 会从中刷新已安装的副本。原因请参见安全。
仪表板位于端口 8000,一旦安装程序的自签名证书就位,便通过 HTTPS 访问。完整说明(包括其所依赖的网络布局)见wiki。
安装程序还会在可能的情况下搭建 eBPF 构建工具链,以匹配你的发行版所附带的 LLVM 版本。这部分是可选的:没有它,传感器仍可在 libpcap 上构建和运行。
传感器有两种捕获后端。libpcap 是默认选项,可在任何环境中工作。在工具链就位的情况下,--capture-mode kernel 会改为通过 XDP 和 TC 在驱动路径中统计数据包,每个窗口唤醒用户空间一次,而不是每个数据包唤醒一次。两种方式的检测结果完全相同。
检测调优是通过测量而非猜测来完成的。scripts/calibrate.py 会读取传感器自身的日志,对普通流量进行采样,并计算出在你的网络上异常边界应位于何处。
若想在不安装任何东西的情况下试用,可直接从工作副本运行:
sudo bash scripts/run.sh
它会询问所需的每个值,为每个值提供默认值,并询问是否也启动 Stage 2。添加 --defaults 可在不被询问的情况下接受所有内容。
要运行测试套件:
scripts/test.sh
Wiki,用于运行系统:
| 页面 | 涵盖内容 |
|---|---|
| 安装 | 环境要求、网络部署位置、首次登录 |
| 配置 | 传感器参数、执行策略调优、告警 |
| 仪表盘指南 | 控制台中的每个页面 |
| 故障排查 | 出现问题时 |
docs/,用于理解或修改系统:
| 文档 | 涵盖内容 |
|---|---|
| 架构 | 处理流水线、线程模型、抓包调优、出口流量测量 |
| 检测 | Welford、EWMA、熵、异常边界、基线持久化 |
| 解释器 | 面向非技术读者的每个术语和每个线格式字段的说明 |
| IPC | 特征向量线格式 |
| 执行 | 分类、四个缓解层级、NAT 处理 |
| 剧本 | 在四个层级之上叠加的、由操作员定义的触发/阶段序列 |
| 告警 | Discord、电子邮件、Telegram,以及用于其他任何渠道的通用 webhook |
| 训练 | 采集带标签的数据并训练模型 |
| 测试 | 运行两套测试套件 |
| 安全 | 加固过程与威胁模型 |
| 路线图 | 已完成和计划中的版本 |
| 基准测试结果 | FLOD 与固定阈值对比:硬件、方法、完整输出 |
| 实时基准测试 | 针对已部署网关的七阶段流量测试活动 |
| 后端基准测试 | 在吞吐量、CPU、延迟和切换方面对内核与 libpcap 进行比较 |
| 经验教训 | 开发过程中发现的真实缺陷,保留下来以总结其普遍意义 |
CONTRIBUTING.md 涵盖开发环境搭建与约定。 SECURITY.md 涵盖漏洞报告。
本项目由我本人独立完成。概念、架构、两阶段设计、检测方法、执行策略、特征集,以及所有版本中的每一项功能决策,均源自我本人。我将其作为网络安全、统计检测和系统编程方面的学习练习来构建,并在整个过程中主导其设计与演进。
在实现过程中,我将 AI 用作编码助手,按照我的规格编写和重构代码,并在我权衡设计取舍时充当讨论对象。关于构建什么、为什么构建以及系统应如何行为的决策均由我做出。
这是一个个人开源项目,也是一个可运行的系统,但尚未经过生产级安全产品所需的对抗性测试。请将其部署在实验网络中,或部署在你可以承受其出错的环境中。
截至 V10,仪表盘提供三种可选的设计风格系列,并支持操作员定义的剧本;参见路线图。
参见 LICENSE。