ahmedmunzir/Automated-SSH-Brute-Force-Detection-and-Response-Pipeline-with-Wazuh
GitHub: ahmedmunzir/Automated-SSH-Brute-Force-Detection-and-Response-Pipeline-with-Wazuh
基于Wazuh构建的SSH暴力破解检测与自动响应实验环境，实现了从攻击检测、规则升级到防火墙自动封锁的完整防御流水线。
Stars: 0 | Forks: 0
# 基于 Wazuh 的 SSH 暴力破解自动检测与响应流水线
## 概述
本项目利用 Wazuh 构建了一套针对 SSH 暴力破解攻击的完整检测与响应流水线。
其目标是超越简单的告警生成，进而设计一套防御工作流，能够：
• 检测重复的 SSH 认证失败行为
• 利用关联规则对可疑行为进行升级处理
• 在目标系统上触发自动遏制措施
• 超时后自动恢复访问权限
该实验室构建在一个完全隔离的环境中，可以在其中安全地生成攻击活动并逐步进行分析。
## 实验环境
该实验室使用 **Proxmox** 构建，包含三台通过隔离内部网络连接的虚拟机。
**内部网络**
```
10.10.10.0/24
```
**虚拟机**
| 机器 | 角色 | IP |
|------|------|------|
| Kali Linux | 攻击者 | 10.10.10.10 |
| Ubuntu Target | 被监控端点 | 10.10.10.20 |
| Ubuntu SIEM | Wazuh 管理节点 + 仪表盘 | 10.10.10.30 |
Wazuh 管理节点还配置了**第二块网卡**，以便可以在不暴露攻击网络的情况下从笔记本电脑访问仪表盘。
```
192.168.68.118
```
## 使用的工具
• Proxmox
• Kali Linux
• Ubuntu Server
• Wazuh SIEM
• SSH
• Linux 认证日志
• UFW 防火墙
# 第一部分 — 基础设施与 SIEM 部署
第一阶段是构建监控基础设施。
### 环境设置
• 在 Proxmox 中创建隔离网络
• 部署三台虚拟机
• 分配静态 IP 地址
• 配置网络分段
### Wazuh 部署
Wazuh 安装在 **Ubuntu SIEM 机器**上，同时作为：
• Manager（管理节点）
• Dashboard（仪表盘）
这使系统能够：
• 收集日志
• 应用检测规则
• 通过 Web 界面可视化告警
### Agent 配置
Ubuntu 目标机被配置为 **Wazuh agent**。
步骤包括：
• 安装 Wazuh agent
• 将 agent 注册到 manager
• 验证连接性
• 确认日志正在被摄取
项目使用的主要日志源是：
```
/var/log/auth.log
```
在此阶段结束时，SIEM 环境已成功从目标机器摄取认证日志。
# 第二部分 — SSH 暴力破解检测与规则分析
基础设施运行正常后，下一步是模拟攻击。
### 攻击模拟
从 Kali 机器上，我对 Ubuntu 目标发起了重复的 SSH 登录尝试。
每次登录失败都会在认证日志中产生条目，并由 Wazuh agent 收集。
### 默认检测行为
最初，Wazuh 会针对每次认证失败尝试生成告警。
这些告警与以下默认规则相关联：
• SSH 认证失败
• 无效用户登录尝试
在短时间内重复失败后，Wazuh 升级了该事件。
### 关联行为
在 **8 次登录失败尝试**后，Wazuh 触发了暴力破解检测规则。
这展示了 Wazuh 如何关联事件，而不是孤立地处理它们。
生成的告警包含结构化信息，包括：
```
Source IP
Destination user
Source port
Frequency of attempts
Previous log entries
```
告警示例字段：
```
"srcip": "10.10.10.10"
"dstuser": "targetuser"
"frequency": 8
"level": 10
```
### MITRE ATT&CK 映射
该告警也被映射到：
```
T1110 — Brute Force
```
战术 (Tactic)：
```
Credential Access
```
这展示了 Wazuh 如何将检测与公认的攻击框架对齐。
# 第三部分 — 自定义升级逻辑
在验证了默认规则后，我实施了一项**自定义检测规则**来控制何时进行升级。
### 自定义规则
规则 ID：
```
100100
```
该规则配置为在以下情况触发：
• 发生 **3 次 SSH 登录失败尝试**
• 来自 **同一源 IP**
• 在定义的时间范围内
当达到此阈值时，规则生成一个：
```
Level 12 alert
```
这允许更早地检测到可疑行为。
### 规则逻辑
该规则通过以下方式链接：
```
if_matched_sid
```
这确保了规则**仅在原始 SSH 认证失败规则匹配后**才触发。
这种方法保留了正确的事件关联性，而不是生成孤立的告警。
### 验证
从 Kali 生成了重复的 SSH 登录尝试。
结果：
• 在第三次登录失败后
• **Wazuh 仪表盘中出现了一个 level 12 告警**
这确认了自定义检测逻辑运行正常。
### 故障排除
在此阶段发生了几个配置问题。
问题包括：
• XML 格式错误
• 标签位置不正确
• Wazuh manager 重启失败
为了解决这个问题，我：
• 审查了配置结构
• 修正了错位的 XML 标签
• 在重启 manager 之前验证了配置
这次故障排除强化了 SIEM 配置必须达到的精确度。
# 第四部分 — 利用 Active Response 实现自动遏制
最后阶段引入了**自动响应**。
目标是自定义规则触发后自动封锁攻击者。
### Active Response 配置
配置了 Wazuh **firewall-drop** 命令。
```
firewall-drop
firewall-drop
srcip
yes
```
然后将该响应链接到自定义规则。
```
firewall-drop
defined-agent
001
100100
600
```
### 行为
一旦规则 **100100** 触发：
1. Wazuh 将攻击者 IP 传递给防火墙脚本
2. 防火墙插入了 DROP 规则
3. 来自攻击者的 SSH 连接失败
验证步骤包括：
• 检查 `active-responses.log`
• 确认攻击者 IP 已被封锁
• 尝试再次从 Kali 进行 SSH
SSH 连接**挂起并超时**，确认封锁生效。
### 超时
配置了 **600 秒**的超时时间。
超时到期后：
• 防火墙规则自动移除
• SSH 连接恢复
# 关键收获
本项目展示了一个完整的防御工作流：
1. 基础设施部署
2. 攻击检测
3. 自定义规则工程
4. 自动遏制
实验室期间培养的技能：
• SIEM 部署
• 日志摄取与分析
• 检测规则工程
• 事件关联
• 自动化事件响应
• SIEM 配置故障排除
# 项目成果
最终系统成功地：
• 检测重复的 SSH 登录尝试
• 使用自定义规则对其进行升级处理
• 自动封锁攻击者 IP
• 超时后恢复访问
本项目超越了单纯查看告警，而是专注于**构建类似于真实 SOC 环境中实施的防御性检测与响应流水线。**
每次登录失败都会在认证日志中产生条目，并由 Wazuh agent 收集。
### 默认检测行为
最初，Wazuh 会针对每次认证失败尝试生成告警。
这些告警与以下默认规则相关联：
• SSH 认证失败
• 无效用户登录尝试
在短时间内重复失败后，Wazuh 升级了该事件。
### 关联行为
在 **8 次登录失败尝试**后，Wazuh 触发了暴力破解检测规则。
这展示了 Wazuh 如何关联事件，而不是孤立地处理它们。
生成的告警包含结构化信息，包括：
```
Source IP
Destination user
Source port
Frequency of attempts
Previous log entries
```
告警示例字段：
```
"srcip": "10.10.10.10"
"dstuser": "targetuser"
"frequency": 8
"level": 10
```
### MITRE ATT&CK 映射
该告警也被映射到：
```
T1110 — Brute Force
```
战术 (Tactic)：
```
Credential Access
```
这展示了 Wazuh 如何将检测与公认的攻击框架对齐。
# 第三部分 — 自定义升级逻辑
在验证了默认规则后，我实施了一项**自定义检测规则**来控制何时进行升级。
### 自定义规则
规则 ID：
```
100100
```
该规则配置为在以下情况触发：
• 发生 **3 次 SSH 登录失败尝试**
• 来自 **同一源 IP**
• 在定义的时间范围内
当达到此阈值时，规则生成一个：
```
Level 12 alert
```
这允许更早地检测到可疑行为。
### 规则逻辑
该规则通过以下方式链接：
```
if_matched_sid
```
这确保了规则**仅在原始 SSH 认证失败规则匹配后**才触发。
这种方法保留了正确的事件关联性，而不是生成孤立的告警。
### 验证
从 Kali 生成了重复的 SSH 登录尝试。
结果：
• 在第三次登录失败后
• **Wazuh 仪表盘中出现了一个 level 12 告警**
这确认了自定义检测逻辑运行正常。
### 故障排除
在此阶段发生了几个配置问题。
问题包括：
• XML 格式错误
• 标签位置不正确
• Wazuh manager 重启失败
为了解决这个问题，我：
• 审查了配置结构
• 修正了错位的 XML 标签
• 在重启 manager 之前验证了配置
这次故障排除强化了 SIEM 配置必须达到的精确度。
# 第四部分 — 利用 Active Response 实现自动遏制
最后阶段引入了**自动响应**。
目标是自定义规则触发后自动封锁攻击者。
### Active Response 配置
配置了 Wazuh **firewall-drop** 命令。
```
### 行为
一旦规则 **100100** 触发：
1. Wazuh 将攻击者 IP 传递给防火墙脚本
2. 防火墙插入了 DROP 规则
3. 来自攻击者的 SSH 连接失败
验证步骤包括：
• 检查 `active-responses.log`
• 确认攻击者 IP 已被封锁
• 尝试再次从 Kali 进行 SSH
SSH 连接**挂起并超时**，确认封锁生效。
### 超时
配置了 **600 秒**的超时时间。
超时到期后：
• 防火墙规则自动移除
• SSH 连接恢复
# 关键收获
本项目展示了一个完整的防御工作流：
1. 基础设施部署
2. 攻击检测
3. 自定义规则工程
4. 自动遏制
实验室期间培养的技能：
• SIEM 部署
• 日志摄取与分析
• 检测规则工程
• 事件关联
• 自动化事件响应
• SIEM 配置故障排除
# 项目成果
最终系统成功地：
• 检测重复的 SSH 登录尝试
• 使用自定义规则对其进行升级处理
• 自动封锁攻击者 IP
• 超时后恢复访问
本项目超越了单纯查看告警，而是专注于**构建类似于真实 SOC 环境中实施的防御性检测与响应流水线。**标签：AMSI绕过, FOFA, PB级数据处理, Proxmox, SSH暴力破解, UFW防火墙, Wazuh, 内存分配, 多包管理, 威胁检测, 安全运维, 实验室环境, 攻击模拟, 私有化部署, 网络安全, 自动化响应, 虚拟化, 规则编写, 防御规避, 隐私保护, 驱动签名利用