Mahmoud-Ossama/PurpleSOC
GitHub: Mahmoud-Ossama/PurpleSOC
一个在单一 Docker Compose 环境中集成自主红队攻击模拟与双引擎（深度学习+LLM）蓝队检测的 AI 驱动紫队网络安全平台。
Stars: 3 | Forks: 2
[](https://git.io/typing-svg)
    
    
     
[](https://skillicons.dev)
[](https://skillicons.dev)
| 层级 | 技术 | 作用 |
|---|---|---|
| 🔴 **红队编排** | TypeScript · Node.js · Temporal | 持久化的五阶段渗透测试 pipeline |
| 🔴 **红队 LLM 引擎** | OpenAI-compat SDK · Ollama · OpenRouter | 与提供商无关的 agent 循环 |
| 🔴 **脆弱目标** | PHP 8.1 · Apache · MySQL | 完整的 OWASP Top 10 攻击面 |
| ⚖️ **反向代理** | HAProxy 2.8 · Lua | 零延迟 JSON payload 镜像 |
| 📡 **流量分析** | CICFlowMeter · Java · OpenJDK 11 | 80+ 双向流量特征 |
| 🤖 **ML 检测** | Keras · TensorFlow · FastAPI · scikit-learn | DNN 二分类器，<8ms 推理 |
| 🧠 **LLM 检测** | LangChain · Groq · Pydantic · PyMongo | 语义 payload 分析 |
| 🗄️ **存储** | MongoDB 7.0 | 中央文档存储 |
| 🖥️ **仪表板** | Next.js 14 · TypeScript · Tailwind CSS | 实时 SOC 分析师界面 |
| 🐳 **编排** | Docker Compose | 7 容器隔离环境 |
## 🐳 Docker 容器
```
graph LR
subgraph COMPOSE["🐳 Docker Compose Environment"]
direction TB
subgraph RED["🔴 Red Team"]
A["VulnShop\nphp:8.1-apache\n:8080"]
B["REDTEAM Agent\nnode:20-alpine"]
end
subgraph ROUTING["⚙️ Traffic Layer"]
C["HAProxy\nhaproxy:2.8\n:80 · :443 · :514"]
D["CICFlowMeter\nopenjdk:11\nshared netns"]
end
subgraph BLUE["🔵 Blue Team"]
E["ML Detector\npython:3.11-slim\n:8000"]
F["LLM Agent\npython:3.11-slim"]
end
subgraph PLATFORM["🟣 Platform"]
G[("MongoDB\nmongo:7.0\n:27017")]
H["SOC Dashboard\nnode:20-alpine\n:3000"]
end
B --> C --> A
C -.-> D --> E --> G
C --> F --> G --> H
end
```
| 容器 | 基础镜像 | 端口 | 职责 |
|---|---|---|---|
| **VulnShop** | `php:8.1-apache` | `8080` | 故意遗留漏洞的 PHP 电子商务应用 (OWASP Top 10) |
| **HAProxy** | `haproxy:2.8` | `80, 443, 514` | 反向代理 + 内嵌 Lua 脚本，用于零延迟 JSON 日志记录 |
| **CICFlowMeter** | `openjdk:11` | — | 共享 HAProxy 的 network namespace；捕获原始数据包 → 80+ 流量特征 |
| **ML Detector** | `python:3.11-slim` | `8000` | FastAPI + Keras DNN；接收特征向量，返回攻击/良性判定 |
| **LLM Agent** | `python:3.11-slim` | — | TCP:514 socket server → LangChain/Groq → 结构化威胁判定 → MongoDB |
| **MongoDB** | `mongo:7.0` | `27017` | 双检测引擎的中央文档存储 |
| **SOC Dashboard** | `node:20-alpine` | `3000` | Next.js 前端；实时威胁订阅源、地图、图表 |
## 🔴 红队 — REDTEAM Agent
REDTEAM 是一个 TypeScript/Node.js 自主化渗透测试框架。它通过一个**由 Temporal 编排、LLM 驱动的五阶段 pipeline**，将静态代码分析与实时应用探测相结合。
### 五阶段 Pipeline
```
flowchart TD
classDef phase fill:#7F1D1D,stroke:#EF4444,color:#FCA5A5,stroke-width:2px
classDef vuln fill:#78350F,stroke:#F59E0B,color:#FDE68A,stroke-width:2px
classDef report fill:#4C1D95,stroke:#A78BFA,color:#DDD6FE,stroke-width:2px
P1("📁 Phase 1 — Pre-Recon\nStatic code analysis\nMaps routes · auth · attack surface"):::phase
P2("🌐 Phase 2 — Recon\nLive application correlation\nConfirms endpoints · discovers routes"):::phase
subgraph P34["⚡ Phases 3–4 — Parallel per Vulnerability Class"]
direction LR
VA1("💉 Injection\nVuln → Queue → Exploit"):::vuln
VA2("⚡ XSS\nVuln → Queue → Exploit"):::vuln
VA3("🔑 Auth\nVuln → Queue → Exploit"):::vuln
VA4("🚪 AuthZ\nVuln → Queue → Exploit"):::vuln
VA5("🌍 SSRF\nVuln → Queue → Exploit"):::vuln
end
P5("📊 Phase 5 — Report\nAssembly · dedup · exec summary\ncomprehensive_security_assessment_report.md"):::report
P1 --> P2 --> P34 --> P5
```
### Agent 模型层级分配
| Agent | 层级 | 模型 | 理由 |
|---|---|---|---|
| 预侦察 | **大型** | `qwen3:32b` | 深度静态分析，最大化上下文窗口 |
| 侦察 | **中型** | `qwen3:8b` | 实时关联需要可靠的 tool calling |
| 漏洞探测 agent (×5) | **中型** | `qwen3:8b` | 频繁使用工具；平衡速度与推理能力 |
| 漏洞利用 agent (×5) | **中型** | `qwen3:8b` | 证据优先，条件执行 |
| 报告 / 总结 | **小型** | `llama3.2:3b` | 仅提取信息；无复杂推理 |
### 支持的 LLM 提供商
| 提供商 | API Key | 最适用场景 |
|---|---|---|
| `ollama` | 否 | 本地 / 离线 / 开发 |
| `openrouter` | 是 | 云端生产环境扫描 |
| `agent_router` | 可选 | 自定义路由基础设施 |
| `openai_compat` | 可选 | 任何兼容 OpenAI 的 endpoint |
🔌 提供商池 — 应对速率限制的弹性机制
使用 `REDTEAM_PROVIDER_1_*`, `REDTEAM_PROVIDER_2_*` 等配置多个提供商。 该池实现了带有**两级冷却时间**的自动故障转移： | 错误类型 | 基础冷却时间 | 最大冷却时间 | |---|---|---| | `rate_limit` (HTTP 429) | 60秒 | 5 分钟 | | `transient` (超时 / 网络 / 服务器) | 10秒 | 60 秒 | - 发生任何 `error.retryable === true` → 轮询至下一个提供商 - `maxAttempts = providers.length × 3` - 所有提供商使用 `300s` 超时以处理庞大的工具调用上下文
|  |
|---|
| *图 4.1 — 训练 epoch 中收敛的 Loss 曲线、准确率和 AUC-ROC* |
|  |
|---|
| *图 4.3 — 在 565,576 条预留测试流上的混淆矩阵（左）与 ROC 曲线 AUC=0.9994（右）* |
### 引擎 2 — LLM 语义 Agent (`agent/agent.py`)
一个 Python 服务，它从 HAProxy (TCP:514) 读取原始 HTTP payload，并使用经过 prompt 工程设计的 LLM 执行语义安全分析。该层检测**仅靠流统计无法察觉的应用层攻击**。
#### 威胁评分公式
```
S = w_type × w_confidence × 10.0
```
| 攻击类型 | 权重 | 理由 |
|---|---|---|
| `SQLi` | **1.00** | 完全控制数据库的潜在风险 |
| `CMD_INJECTION` | **1.00** | 远程代码执行的潜在风险 |
| `PATH_TRAVERSAL` | **0.90** | 文件系统访问；凭证泄露 |
| `SSRF` | **0.85** | 内网跳板渗透 |
| `XSS` | **0.75** | 客户端执行；会话窃取 |
| `Benign` | **0.00** | 无威胁 |
#### Prompt 工程 — v1 → v5 迭代
```
xychart-beta horizontal
title "False Positive Rate Reduction Through Prompt Engineering"
x-axis ["v1 Naive", "v2 +Taxonomy", "v3 +JSON Format", "v4 +FP Examples", "v5 +Evidence Req"]
y-axis "FP Rate (%)" 0 --> 20
bar [18.4, 11.7, 8.3, 3.9, 2.1]
```
| 版本 | FP 率 | FN 率 | 主要变更 |
|---|---|---|---|
| v1 (朴素) | 18.4% | 4.2% | 自由格式输出，无示例 |
| v2 | 11.7% | 4.8% | + 正式的攻击类型分类体系 |
| v | 8.3% | 4.5% | + 强制结构化 JSON 输出 |
| v4 | 3.9% | 4.1% | + 精选的良性流量示例 (FP 指引) |
| **v5** | **2.1%** | **3.8%** | **+ 强制要求证据引用** |
📋 生产环境系统 Prompt 结构 (v5)
``` ATTACK TAXONOMY: SQLi | XSS | PATH_TRAVERSAL | CMD_INJECTION | SSRF | Benign FALSE POSITIVE GUIDANCE: - "select" in a product search is NOT SQLi - HTML angle brackets in blog content are NOT XSS - ".." as part of a legitimate URL slug is NOT path traversal REQUIRED JSON OUTPUT (no preamble, no markdown fences): { "attack_type": "
### ML 检测器 — 预留测试集 (N = 565,576 条流量)
| 指标 | 值 | 可视化 |
|---|---|---|
| 总体准确率 | **99.25%** | `████████████████████` 99.25% |
| AUC-ROC | **0.9994** | `████████████████████` 99.94% |
| F1-Score (攻击) | **0.9810** | `███████████████████░` 98.10% |
| 精确率 (攻击) | **97.80%** | `███████████████████░` 97.80% |
| 召回率 (攻击) | **98.39%** | `███████████████████░` 98.39% |
| 类别 | 数量 |
|---|---|
| ✅ 真阳性 | 109,524 |
| ✅ 真阴性 | 451,801 |
| ❌ 假阳性 | 2,464 |
| ❌ 假阴性 | 1,787 |
| 🎯 决策阈值 | τ = 0.89 |
### 系统延迟与吞吐量
| 组件 | 平均延迟 | 吞吐量 | 备注 |
|---|---|---|---|
| HAProxy Lua 日志记录 | **< 1 ms** | > 10,000 req/s | 内存中处理，无磁盘 I/O |
| CICFlowMeter | ~50 ms/flow | ~2,000 flows/s | 流后计算 |
| ML 检测器 | **~8 ms** | ~120 req/s | 单次 Keras 前向传播 |
| LLM Agent | 1.2–3.5 s | ~20 req/s | 主要瓶颈 (API 调用) |
| MongoDB 写入 | ~5 ms | ~3,000 writes/s | 单节点 |
| 仪表板轮询周期 | 5 秒间隔 | — | 可配置 |
## 🎯 双引擎检测覆盖范围
核心实证结论：**攻击者必须同时欺骗两种根本不同的检测机制**。逃避 ML 引擎需要统计上正常的流量；而逃避 LLM 引擎则需要干净的 payload——对于大多数攻击类别而言，这两个要求是相互矛盾的。
```
vennDiagram
```
| 攻击场景 | 🤖 ML 引擎 | 🧠 LLM 引擎 | 原因 |
|---|---|---|---|
| 标准 SQL 注入 | ✅ | ✅ | 两者通过互补模态检测 |
| URL 编码的 SQLi | ✅ | ✅ | LLM 在分析前进行解码 |
| **慢速 SQLi (1 req / 5 min)** | ❌ | ✅ | 流统计数据表现正常；LLM 读取 payload |
| 快速自动化扫描 (500/min) | ✅ | ✅ | 两者均检测到；ML 检测到速率异常 |
| **良性流量中的 XSS** | ❌ | ✅ | 短的 GET 请求在统计上显得正常；LLM 抓取 `