SecuredByRup/ssh-bruteforce-siem-pipeline
GitHub: SecuredByRup/ssh-bruteforce-siem-pipeline
一个基于 Elastic v7.17 的 SSH 暴力破解检测 SIEM 流水线实践项目，演示从攻击模拟、Filebeat 日志采集到自定义 EQL 检测规则工程的全流程。
Stars: 0 | Forks: 0
# SSH-BruteForce-SIEM-Pipeline
一个端到端项目，演示了在 Elastic v7.17 中进行 SSH 攻击模拟、Filebeat 日志采集以及自定义 EQL 检测工程。
## 🛠️ 基础设施与技术栈
* SIEM 平台：Elasticsearch & Kibana **v7.17.28**
* 日志转发器：Filebeat **v7.17.28**
* 目标端点操作系统：Ubuntu Linux
* 遥测数据源：/var/log/auth.log (SSH 身份验证日志)
## 🏃♂️ 项目工作流与时间线
### 阶段 1：采集与遥测验证（红队与蓝队）
1. 在目标 Ubuntu 系统上配置 **Filebeat (v7.17.28)**，以采集本地身份验证日志并将其直接发送至 **Elasticsearch**。
2. 执行自动化攻击模拟脚本，以生成大量突发的恶意 SSH 暴力破解流量。
3. 使用直接的 Elasticsearch API 查询验证了后端采集流水线，确认 **220 条原始日志条目** 已成功进入集群。
#### 原始攻击日志证据：
.png)
*直接在目标系统的 /var/log/auth.log 流中可视化原始攻击模拟数据。这确立了我们的 SIEM 流水线旨在检测的恶意基线模式 (Invalid user invaliduser)。*
### 阶段 2：EQL 检测攻坚与排障
我们尝试创建一条针对无效登录尝试的自定义 SIEM 规则。然而，由于日志是通过直接的自定义数据流而非标准的 Elastic Common Schema (ECS) 模块进行处理的，引擎抛出了一系列严格的数据库验证限制错误。
#### ❌ 障碍 1：结构拒绝
EQL 引擎最初拒绝了基本的未分类查询字符串。EQL 严格要求具备正式的 event category（事件类别）层才能开始解析。
* 返回错误：planning_exception: Found problems across lines 2 and 3: Rule requires an event category layer.
#### ❌ 障碍 2：Text 与 Keyword 陷阱
引擎抛出了数据类型不匹配异常。核心的 message 字段在 Elasticsearch 中被严格映射为非结构化的 text，而不是精确匹配的 keyword。EQL 字符串匹配操作符（如 "like" 或 ":"）完全拒绝在原始 text 字段上运行，以保护搜索性能。
* 返回错误：verification_exception: Cannot operate on field of data type text: No keyword/multi-field defined exact matches for message
#### ❌ 障碍 3：版本与语法限制
尝试使用高级的全文本查询转义函数绕过 text 字段限制，结果导致了编译器失败。我们环境特定的维护编译器版本不支持内置的查询包装器。
* 返回错误：verification_exception: Found 1 problem line 1:11: Unknown function query
### 阶段 3：解决方案工程设计
为了在不改变数据库 schema 的情况下，巧妙绕过严格的数据类型解析引擎，我们将检测逻辑进行了重构，完全聚焦于一个核心的、硬编码的 Elastic Common Schema (ECS) 结构化 keyword 字段：
**我们最终的规则逻辑：** any where event.kind == "event"
**生效原因：** Filebeat 发送的每一条日志都原生包含映射为 keyword 数据类型的 event.kind 字段。通过将检测锚点转移到这个有效的 keyword 原语上，EQL 引擎立即验证了查询，绕过了 text 分析瓶颈，并成功扫描了数据块。
#### 自定义规则 UI 验证：
.png)
*Kibana UI 中最终完成并验证的自定义 EQL 规则设置。通过将查询逻辑直接映射到结构化的 event.kind schema keyword 原语，所有数据类型编译冲突都被成功绕过。*
## 🏆 最终验证与指标
在规则配置保存的瞬间，后台检测引擎无缝执行，实现了前端和后端之间完美无瑕的实时同步：
* **发送的原始模拟日志：** 总计 220 个文档
* **生成的 SIEM 告警 (Kibana UI)：** 180 条纯净告警
* **后端索引计数 (.siem-signals API)：** 180 条纯净告警
**关于数据过滤的说明：** 原始日志计数 (220) 与生成的告警 (180) 之间的差值，代表了 SIEM 成功过滤掉了系统噪音。虽然脚本生成了总计 220 条日志条目（包括“connection closed”元数据），但我们优化的检测流水线精准提取出了 180 条真正的高保真身份验证失败记录，彻底消除了干扰 SOC 分析师的误报杂音。
#### 前端与后端同步证明：
.png)
*端到端的信号同步。Kibana SIEM 安全运营仪表板（左侧）与原始后端集群 API 文档计数（右侧）完美对齐，证明恰好有 180 条高保真安全告警被成功生成和处理。*
标签：Elastic Stack, 安全运营, 扫描框架, 攻击模拟, 流量重放, 越狱测试, 驱动签名利用