BabsBBG/Gatekeeper2-Echelon
GitHub: BabsBBG/Gatekeeper2-Echelon
该项目是一个 5G 感知的 SOC 实验室，通过模拟 5G 核心网络实现威胁情报提取、AI 异常检测和自动化 DDoS 防御的完整安全运营流程。
Stars: 0 | Forks: 0
# Gatekeeper 2 - Echelon 行动
### 5G 感知网络威胁情报与自动化 DDoS 防御实验室
[](https://github.com/BabsBBG/Gatekeeper2-Echelon)
[](https://python.org)
[](https://splunk.com)
[](https://open5gs.org)
[](https://github.com/aligungr/UERANSIM)
[](LICENSE)
**[Gatekeeper 项目](https://github.com/BabsBBG/project-gatekeeper)的延续** —— Gatekeeper 保护了 Helix-Pulse 合并中的身份层，而 Echelon 行动则负责保护 Pulse 的 5G 基础设施网络层。
在此处阅读我关于该项目的设计思路 - [Medium](https://medium.com/@tobibabalola21/the-72-hour-window-how-i-built-a-5g-aware-soc-that-detects-ddos-attacks-and-auto-blocks-them-in-1-b1c70562e14f)
## 目录
1. [真实背景](#the-real-story)
2. [项目展示](#what-this-demonstrates)
3. [架构](#architecture)
4. [实验室环境](#lab-environment)
5. [关键指标](#key-metrics)
6. [阶段](#phases)
7. [问题与修复](#hiccups--fixes)
8. [项目结构](#project-structure)
9. [作者](#author)
## 真实背景
Helix Communications 在通过 Gatekeeper 项目巩固了其身份安全态势后，完成了对 **Pulse** 的收购。Pulse 是一家区域性 5G 运营商，为英格兰北部和米德兰兹地区的 34 万用户提供服务。
Pulse 在此次交易中并未带来成熟的安全能力：没有 SIEM，没有威胁情报功能，也没有 SOC。Helix 的 CISO 提出了一项优先级为 1（Priority 1）的关切：
事实证明，该评估过于乐观了 60 天。
**公告发布后第 31 天：** 暗网监控发现了一条来自威胁行为者 **null_meridian** 的帖子，这是一次受雇佣的 DDoS 攻击行动，专门针对服务于地方当局合同的企业 URLLC 切片。SOC 只有 72 小时的应对时间。
本项目即是 SOC 的应对方案。构建了一条从暗网威胁情报到自动化、亚秒级缓解的完整 pipeline。
## 项目展示
- 威胁情报提取与 IOC 管理
- SIEM 集成与检测工程
- 5G 独立组网核心部署与网络切片 (Open5GS + UERANSIM)
- AI 增强的异常检测
- 自动化 SOAR 事件响应
- 遵循 ITIL 标准的事件生命周期管理
## 架构
```
[Dark Web Simulation] → [IOC Extraction] → [SQLite Blacklist]
↓
[Splunk SIEM]
↓
[5G Network - Open5GS Core]
(AMF / SMF / UPF / Slicing)
↓
[UERANSIM - gNB + UE Simulation]
↓
[DDoS Attack Simulation - hping3]
↓
[Zeek Detection + AI Anomaly Detection]
↓
[SOAR Auto-Response - iptables]
↓
[Splunk Incident Timeline]
```
## 实验室环境
| 虚拟机 (VM) | 角色 | IP | 关键软件 |
|----|------|-----|--------------|
| VM1 | 5G 核心 | 192.168.56.102 | Open5GS, MongoDB (Docker), Node.js |
| VM2 | RAN 仿真 | 192.168.56.103 | UERANSIM (gNB + UE) |
| VM3 | SOC 技术栈 | 192.168.56.104 | Splunk, Zeek, Python (Isolation Forest) |
| VM4 | 攻击者 | 192.168.56.105 | hping3 |
**操作系统:** 所有虚拟机均使用 Ubuntu 24.04 LTS
**网络:** VirtualBox Host-only (192.168.56.0/24) + NAT 用于互联网访问
**安全提示:** 所有攻击模拟均在隔离的 VirtualBox 实验室中进行。`null_meridian` 是虚构的威胁行为者。
## 关键指标
| 指标 | 数值 |
|--------|-------|
| **提取的 IOC** | 3 |
| **自动封锁的 IOC** | 2 (高置信度 + 中置信度) |
| **AI 检测到的异常** | 20 ( out of 323,402 个连接) |
| **MTTR** | **1.084 秒** |
| **Zeek 检测** | DDoS_SYN_Flood, DDoS_GTP_Flood (5G 特有) |
| **网络切片** | 3 (eMBB, URLLC, mMTC) 并实施了 QoS |
| **UE IP** | 10.45.0.9 |
## 阶段
### 阶段 1 — 实验室架构与基础设置
在 VirtualBox 中配置了四台 Ubuntu 24.04 LTS 虚拟机，每台都配有双网络适配器：用于安装期间访问互联网的 NAT，以及用于在 192.168.56.0/24 子网内进行实验室内部通信的 Host-only。
| 虚拟机 (VM) | 角色 | 已安装 |
|----|------|-----------|
| VM1 | Open5GS 核心 | Open5GS, MongoDB (Docker), Node.js, Python3 |
| VM2 | UERANSIM | UERANSIM build, tmux, build-essential |
| VM3 | SOC 技术栈 | Splunk, Zeek, Grafana, InfluxDB, Python venv |
| VM4 | 攻击者 | hping3, net-tools |
### 阶段 2 — 威胁情报 Pipeline
模拟的暗网威胁数据 (`darkweb_data.json`, `multi_attacker_feed.json`) 由 `ioc_extractor.py` 解析，该脚本提取攻击者 IP、攻击方法、目标切片和置信度评级，并存入由 `blacklist_db.py` 管理的 SQLite 黑名单中。
**提取的 IOC：**
| IP | 方法 | 置信度 | 切片 |
|----|--------|------------|-------|
| 192.168.56.105 | UDP flood + SYN flood | 高 | URLLC |
| 192.168.56.110 | HTTP flood | 中 | eMBB |
| 192.168.56.111 | ICMP flood | 低 | mMTC |
**运行它：**
```
cd ~/gatekeeper2-echelon
python3 threat_intel/ioc_extractor.py
```
### 阶段 3 — SIEM 集成
IOC 及所有下游事件均通过 HTTP Event Collector (HEC) 推送至 Splunk。`splunk_forwarder.py` 负责处理三种事件类型的投递：IOC、AI 异常、SOAR 动作。`siem_pipeline.py` 负责编排整个摄取运行过程。`splunk_queries.md` 中记录了八个 SPL 检测查询，包括一个完整的事件时间线关联查询。
**HEC 配置：**
- URL: `https://192.168.56.104:8088/services/collector`
- SSL 已启用 — 务必使用 `https://`
**测试 HEC：**
```
curl -k https://192.168.56.104:8088/services/collector \
-H "Authorization: Splunk " \
-d '{"event": "HEC test"}'
```
### 阶段 4 — 5G 网络仿真
Open5GS 在 VM1 上运行完整的 5G 独立组网核心 (AMF, SMF, UPF, NRF, UDM, AUSF, PCF)。UERANSIM 在 VM2 上模拟基站 (gNB) 和连接的设备 (UE)，并在 Open5GS 中根据订阅者配置文件 (IMSI `999700000000001`) 进行注册。配置了三个网络切片 - eMBB、URLLC、mMTC - 并通过 Linux `tc` HTB 流量整形来强制执行特定于切片的 QoS。URLLC（企业切片）以最高优先级获得保证带宽。
Open5GS 和 UERANSIM 完全通过 CLI 和 systemd 进行操作，这与生产电信环境中管理 5G 核心基础设施的方式保持一致。WebUI 仅用于初始的订阅者注册。
**切片设计：**
| 切片 | SST | 服务 | 速率 | 上限 | 优先级 |
|-------|-----|---------|------|---------|----------|
| URLLC | 2 | 企业/地方当局 | 50mbit | 70mbit | 1 (受保护) |
| eMBB | 1 | 住宅 | 30mbit | 50mbit | 2 |
| mMTC | 3 | IoT | 10mbit | 20mbit | 3 |
**启动网络：**
```
# VM1 — Open5GS 已经作为 systemd 服务运行
sudo systemctl status open5gs-amfd
# VM2 — 终端 1
cd ~/UERANSIM
sudo ./build/nr-gnb -c config/open5gs-gnb.yaml
# VM2 — 终端 2
sudo ./build/nr-ue -c config/open5gs-ue.yaml
```
### 阶段 5 — 攻击模拟与 AI 检测
从 VM4 使用 `hping3` 发起 DDoS 攻击，包括 SYN flood 和专门针对端口 2152（GTP-U，5G 用户面协议）的 UDP flood。这直接针对 5G 数据路径，而不是通用的服务端口，使其成为一种感知 5G 的攻击。Zeek 使用自定义检测脚本 (`ddos_detect.zeek`) 监控实验室流量，并对两种攻击类型发出告警。`anomaly_detector.py` 在基线流量上训练 Isolation Forest 模型，并在攻击期间对实时流量进行评分，标记异常连接并将其转发至 Splunk。
**攻击命令 (VM4)：**
```
sudo hping3 -S --flood -V -p 80 -I enp0s8 192.168.56.102
sudo hping3 --udp --flood -V -p 2152 -I enp0s8 192.168.56.102
```
**运行 AI 检测 (VM3)：**
```
source ~/echelon-env/bin/activate
python3 threat_intel/anomaly_detector.py
```
### 阶段 6 — SOAR 与自动化缓解
`auto_responder.py` 是 SOAR 引擎。它读取活动黑名单，通过 iptables 自动封锁高置信度和中置信度的攻击者 IP，将每个动作连同精确的时间戳记录到 Splunk 中，并更新黑名单状态。低置信度的 IOC 将被跳过并标记，供分析师手动审查。一旦威胁解除，恢复模式将解除对 IP 的封锁并恢复服务。
**响应：**
```
sudo python3 mitigation/auto_responder.py --mode respond
```
**运行恢复：**
```
sudo python3 mitigation/auto_responder.py --mode recover
```
**结果：** MTTR（SOAR 触发 → 应用 iptables 规则）为 **1.084 秒**。2 个 IP 被自动封锁，1 个被跳过待人工审查。
### 阶段 7 — 可视化与最终仪表板
一个包含四个面板的、数据齐全的 Splunk 仪表板。包括 IOC 事件、AI 异常检测、显示 DDoS 激增的攻击流量时间表，以及展示自动封锁和恢复事件的完整 SOAR 审计追踪。
## 问题与修复
### 1. MongoDB CPU 指令集不兼容
**问题：** 原生 MongoDB 7.0 包在 VirtualBox 虚拟机上启动失败，报错 `core-dump (signal=ILL)`。
**原因：** MongoDB 7.0 需要 AVX CPU 指令，而虚拟化 CPU 不支持该指令。
**修复：** 使用 Docker 运行 MongoDB 4.4：
```
sudo docker run -d --name mongodb -p 27017:27017 mongo:4.4
```
### 2. AMF guami 配置错误
**问题：** AMF 启动失败，报错 `ERROR: No amf.guami` 和 `FATAL: Open5GS is terminated`。
**原因：** Open5GS v2.8.0 需要显式配置 `guami`，而旧版文档中未涵盖此项。
**修复：** 将正确的 `guami` 块添加到 `/etc/open5gs/amf.yaml`：
```
amf:
guami:
- plmn_id:
mcc: 999
mnc: 70
amf_id:
region: 2
set: 1
pointer: 0
```
### 3. AMF 计时器编码错误
**问题：** 修复 guami 后，AMF 崩溃并报错 `Not support GPRS Timer 3 [3240]`。
**原因：** 由于 GPRS Timer 3 的位编码机制，`t3512` 计时器值必须是 600 秒的倍数。3240 不是有效的倍数。
**修复：** 将值更改为 `3600`：
```
time:
t3502:
value: 720
t3512:
value: 3600
```
### 4. Splunk HEC 协议不匹配
**问题：** HEC curl 返回 `Received HTTP/0.9 when not allowed`。
**原因：** HEC 启用了 SSL，但脚本使用的是 `http://` 而不是 `https://`。
**修复：** 将所有 HEC URL 更改为 `https://`，并为自签名证书添加 `-k` 标志。
### 5. Zeek 脚本类型冲突
**问题：** Zeek 脚本失败，报错 `type clash in comparison (c$id$proto == tcp)`。
**原因：** Zeek 期望的是数字格式的协议 ID，而不是字符串字面量。
**修复：**
```
if (c$id$proto == 6) { ... } # TCP
if (c$id$proto == 17) { ... } # UDP
```
### 6. Zeek 日志位置混淆
**问题：** 在 `/opt/zeek/logs/current/` 中找不到 `conn.log`。
**原因：** 如果在不带 `--logdir` 参数的情况下运行，Zeek 会将日志写入当前工作目录。
**修复：** 在项目根目录下使用 `ls -la conn.log`。
### 7. Isolation Forest 基线过小
**问题：** 攻击者 IP 未能在 AI 异常结果中被清晰地单列出来。
**原因：** 基线仅有 7 条记录，不足以让 Isolation Forest 学习到有意义的正常流量模式。
**注意：** 已作为已知的实验室限制记录在案。5 分钟的基线可以产生更严格的隔离。攻击者 IP 依然被正确包含在被标记的异常之中。
### 8. UPF 互联网路由（VirtualBox NAT 限制）
**问题：** 尽管配置了正确的 iptables MASQUERADE 规则，`ping -I ogstun 8.8.8.8` 仍然失败并出现 100% 丢包。
**原因：** VirtualBox NAT 引擎不会将源自辅助 VM 子网的数据包转发到互联网，这是 Hypervisor 层面的限制，而不是 Linux 路由问题（通过 tcpdump 证实，数据包离开了 ogstun 但从未出现在 enp0s3 上）。
**影响：** 无 - 阶段 5/6 的所有攻击均通过 Host-only 网络针对内部实验室 IP 发起，该网络运行正常。此情况已记录在 `5g_network/lab_limitations.md` 中。
## 项目结构
```
gatekeeper2-echelon/
├── SCENARIO.md # Full threat narrative
├── itil_workflow.md # ITIL incident mapping
├── requirements.txt
│
├── darkweb_simulation/
│ ├── darkweb_data.json # null_meridian primary threat
│ └── multi_attacker_feed.json # 3 threat actors
│
├── threat_intel/
│ ├── blacklist_db.py # SQLite database manager
│ ├── ioc_extractor.py # IOC extraction pipeline
│ ├── anomaly_detector.py # Isolation Forest AI detection
│ └── blacklist.db # 3 active IOCs
│
├── siem_integration/
│ ├── splunk_forwarder.py # HEC client (4 send functions)
│ ├── siem_pipeline.py # Blacklist → Splunk orchestration
│ └── splunk_queries.md # 8 SPL detection queries
│
├── 5g_network/
│ ├── slices.md # Slice design and QoS config
│ ├── qos_preservation_evidence.md
│ └── lab_limitations.md
│
├── ddos_simulation/
│ ├── ddos_detect.zeek # Zeek DDoS detection script
│ ├── baseline_conn.log # Normal traffic baseline
│ ├── attack_conn.log # Attack-period traffic
│ └── anomaly_results.json # AI detection output
│
├── mitigation/
│ └── auto_responder.py # SOAR auto-responder
│
└── screenshots/
├── phase1/
├── phase2/
├── phase3/
├── phase4/
├── phase5/
├── phase6/
└── phase7/
```
## 快速开始
```
# 1. 提取 IOC
cd ~/gatekeeper2-echelon
python3 threat_intel/ioc_extractor.py
# 2. 发送到 Splunk
python3 siem_integration/siem_pipeline.py
# 3. 启动 5G 网络 (VM2 — 两个终端)
sudo ./build/nr-gnb -c config/open5gs-gnb.yaml
sudo ./build/nr-ue -c config/open5gs-ue.yaml
# 4. 发起攻击 (VM4) 并进行检测 (VM3)
sudo hping3 -S --flood -V -p 80 -I enp0s8 192.168.56.102
python3 threat_intel/anomaly_detector.py
# 5. 自动阻断 (VM1)
sudo python3 mitigation/auto_responder.py --mode respond
```
## 作者
**Oluwatobi Babalola**
GitHub: [@BabsBBG](https://github.com/BabsBBG)
LinkedIn: [Oluwatobi Babalola](https://linkedin.com/in/oluwatobi-babalola)
**从“威胁出现”到“IOC 被处理”的自动化时间差缩短至 1.084 秒。**
标签：5G网络, AI异常检测, DDoS防护, MITM代理, 威胁情报, 安全运营中心, 开发者工具, 网络映射, 自动化响应, 请求拦截, 逆向工具