EleniKechrioti/soc-incident-response-lab
GitHub: EleniKechrioti/soc-incident-response-lab
一个基于 Docker 的容器化安全运营中心（SOC）实验室，结合 Suricata、ELK Stack 和本地大语言模型，模拟攻击杀伤链并实现 AI 驱动的事件响应与告警分类。
Stars: 1 | Forks: 0
# 容器化 SOC 实验室：威胁检测与 AI 驱动的事件响应
这是一个基于 Docker 构建的全面且容器化的安全运营中心 (SOC) 实验室环境。本项目模拟了完整的网络攻击杀伤链，实施了网络加固，使用入侵检测系统 (IDS) 检测威胁，通过 SIEM 可视化日志，并利用本地大语言模型 (LLM) 进行自动化告警分类和关联。
在本项目中，我们从零开始构建了一个功能齐全的微型**安全运营中心 (SOC)**，以体验完整的事件响应生命周期。我们的目标不仅是设置安全工具，而是积极防御网络、执行协同网络攻击并分析其后果。
**项目范围与方法：**
1. **构建基础设施：** 我们设计了一个隔离的 Docker 网络，包含一个攻击者节点、一个经过加固的受害 Web 服务器以及一个集中式的 SOC 监控站。
2. **执行攻击：** 我们针对受害者发起了模拟杀伤链，从网络侦察 开始，升级为 Web 漏洞扫描，并最终进行凭证暴力破解攻击。
3. **监控与可视化：** 我们使用 Suricata IDS 和严格的内核级防火墙规则 (`iptables` / `ulogd2`) 捕获恶意流量，将所有告警路由到 ELK Stack (SIEM)，以实时可视化追踪攻击者的步骤。
4. **引入 AI 进行分类：** 最后，我们提取了原始安全日志并将其输入到本地大语言模型 (Phi-3 Mini) 中。我们的目标是测试 GenAI 能否成功充当一级 SOC 分析师——比人类更快地关联告警、识别攻击阶段并撰写事件报告。
本仓库包含完整的基础设施即代码、配置文件和文档，以便您复现我们的 SOC 实验室。
## 架构概述
该实验室由三个独立且隔离的节点组成，它们在一个自定义的 Docker 桥接网络（`socnet` - `172.28.0.0/24`）上运行。
* **攻击者节点 (Kali Linux - `172.28.0.10`)：** 预配置了进攻性安全工具 (Nmap, Nikto, Hydra)，用于模拟攻击杀伤链。
* **受害者节点 (Ubuntu - `172.28.0.20`)：** 托管 Nginx Web 服务器和 SSH 的目标系统。由严格的 `iptables` (默认 DROP) 进行防御，并由 **Suricata IDS** 监控。内核日志 (NFLOG) 通过 `ulogd2` 捕获。
* **SOC 节点 (Ubuntu - `172.28.0.30`)：** 集中式监控站，托管 **ELK Stack** (Elasticsearch, Kibana)、用于日志提取的 **Filebeat**，以及运行 `Phi-3 Mini` LLM 以进行自动化告警关联的本地 **Ollama** 实例。
## 仓库结构与数据持久化
为了确保数据持久化（以便在容器重启时不会丢失日志和 SIEM 数据），本实验室大量使用了 Docker 绑定挂载。
**重要提示：** 在运行实验室之前，请确保您的目录结构与下方的树状图匹配。`data/` 和 `logs/` 目录直接映射到宿主机。如果它们不存在，Docker 将在执行时自动创建它们，但保持此结构对于 Filebeat 正确提取 Suricata 日志至关重要。
```
soc-lab/
├── docker-compose.yml
├── attacker/
│ └── Dockerfile
├── soc/
│ ├── Dockerfile
│ ├── config/ # Elasticsearch, Kibana, Filebeat YAML configs
│ └── scripts/ # Automated startup scripts
├── victim/
│ ├── Dockerfile
│ ├── config/ # Suricata YAML configuration
│ ├── rules/ # Custom Suricata IDS rules
│ └── scripts/ # Iptables hardening & startup scripts
├── data/ # Auto-generated: Persistent storage for Elasticsearch
└── logs/ # Auto-generated: Shared volumes for log routing
├── soc/ # ELK stack operational logs
└── victim/ # Suricata (eve.json, fast.log) & iptables (syslog.log)
```
## 使用的技术
* **基础设施：** Docker, Docker Compose, WSL2 (Ubuntu 22.04)
* **进攻性工具：** Nmap, Nikto, Hydra
* **防御与监控：** Iptables (状态防火墙), Suricata IDS, ulogd2
* **SIEM / 数据流水线：** Elasticsearch, Kibana, Filebeat
* **AI / ML：** Ollama, Phi-3 Mini (3.8B)
## 分步安装与执行
### 前置条件
* 已安装 Docker 和 Docker Compose。
* 确保为您的 Docker 引擎 / WSL2 环境分配了至少 **8GB RAM**（通过 `.wslconfig`），因为 Elasticsearch 和本地 LLM 需要大量内存。
### 1. 克隆仓库
```
git clone https://github.com/EleniKechrioti/soc-incident-response-lab.git
cd soc-incident-response-lab
```
### 2. 构建并部署环境
使用 Docker Compose 启动整个 SOC 架构。`-d` 标志表示在后台模式下运行。
```
docker compose up --build -d
```
验证以下三个容器 (`attacker`, `victim`, `soc`) 是否正在运行：
```
docker ps
```
### 3. 验证 SIEM 就绪状态
Elasticsearch 和 Kibana 完全初始化大约需要 30-60 秒。您可以监控 SOC 节点日志：
```
docker logs -f soc
```
初始化完成后，在浏览器中访问 Kibana：**http://localhost:5601**
## 模拟简单攻击 (POC)
要生成流量和告警，请从 `attacker` 容器执行以下命令。
**访问攻击者终端：**
```
docker exec -it attacker /bin/bash
```
**1. 侦察与端口扫描 (Nmap)**
```
nmap -sS 172.28.0.20
nmap -A 172.28.0.20
```
**2. Web 应用扫描 (Nikto)**
```
nikto -h http://172.28.0.20
```
**3. 凭证获取 / SSH 暴力破解 (Hydra)**
```
printf "1111\n2222\n3333\n4444\n5555\n6666\ntoor\n" > passwords.txt
hydra -l root -p passwords.txt ssh://172.28.0.20
```
## 威胁检测与 SIEM 可视化
在执行攻击时，Suricata 和防火墙会生成日志 (`eve.json`, `syslog.log`, `fast.log`)，这些日志将被 Filebeat 提取并在 Kibana 中进行可视化。
### Kibana 仪表板
SOC 仪表板有效地可视化了：
* **攻击类型 (签名)：** 经过噪声过滤的饼图，用于识别暴力破解、Web 扫描和 SQL 注入尝试。
* **目标端口：** 清晰识别目标服务（端口 80 HTTP，端口 22 SSH），排除临时端口。
* **攻击时间线：** 网络流量的峰值与 Nmap、Nikto 和 Hydra 的执行时间完美相关。
### 告警示例 (Suricata `eve.json`)
以下是 SSH 暴力破解攻击期间由 Suricata 生成并由我们的自定义规则捕获的 JSON 告警示例：
```
{
"timestamp": "2026-04-16T07:38:17.118585+0000",
"event_type": "alert",
"src_ip": "172.28.0.10",
"src_port": 60328,
"dest_ip": "172.28.0.20",
"dest_port": 22,
"proto": "TCP",
"alert": {
"action": "allowed",
"signature_id": 1000007,
"signature": "LOCAL Possible SSH brute-force / repeated connection attempts",
"severity": 3
}
}
```
## AI 驱动的告警分类
本实验室最先进的功能之一是集成了**本地大语言模型 (LLM)**，以充当自动化的一级 SOC 分析师。系统利用 AI 来加速初步分类过程并描绘出攻击杀伤链，而不是由人工手动关联成千上万行原始日志。
### 实施与克服限制
* **引擎与模型：** 我们在 SOC 容器内部直接部署了运行 **Phi-3 Mini (3.8B)** 模型的 **Ollama**。这确保了 100% 的数据隐私（日志永远不会离开实验室环境）。选择 Phi-3 是因为更大的模型（如 Llama 3）超出了我们的 WSL2 环境的内存限制并导致了崩溃。
* **数据处理 (分块)：** 原始的 SIEM 和 IDS 日志 (`eve.json`, `syslog.log`) 非常庞大，超出了标准 LLM 的上下文窗口。为了解决这个问题，我们实施了一个数据准备流水线：我们使用 `jq` 仅过滤出严重告警，并将它们以约 200 行的易于管理的块的形式输入给模型。
### SOC 分析师提示词
该模型使用以下上下文进行初始化，以指导其行为：
### AI 输出与评估
LLM 成功处理了这些数据块，并识别出了完整的攻击杀伤链：
1. **侦察：** ICMP ping。
2. **扫描与枚举：** Nmap 端口扫描和服务检测。
3. **Web 应用攻击：** Nikto HTTP 探测。
4. **凭证获取：** Hydra SSH 暴力破解。
**LLM 输出摘录示例：**
```
Incident Summary: The full incident timeline shows multiple web application attacks, port scanning activities potentially leading up to an unauthorized access attempt on a remote server (172.28.0.20). These events are spread across different times but exhibit patterns consistent with pre-attack reconnaissance and brute force attempts...
```
**人类与 AI 的结论对比：** 虽然 LLM 在发现趋势和提取通用入侵指标 方面表现得极其迅速，但人工验证仍然是必不可少的。该模型偶尔会在格式化和轻微的上下文误解方面遇到困难（例如，将 Telnet 映射签名与实际的 SSH 暴力破解混淆）。它作为一个强大的分类助手，但目前还不能完全取代人类分析师的精确关联技能。
## 清理
要安全地停止和移除容器、网络并保留数据卷：
```
docker compose down
```
要移除所有内容（包括持久化数据卷）：
```
docker compose down -v
```
标签：AI风险缓解, CTI, DLL 劫持, Docker, Metaprompt, 入侵检测系统, 大语言模型, 安全数据湖, 安全运营中心, 安全防御评估, 实验室环境, 密码管理, 插件系统, 版权保护, 网络映射, 请求拦截, 越狱测试