Chinmayee2Bidwai/SSH-BruteForce-SIEM-SOAR-Lab

GitHub: Chinmayee2Bidwai/SSH-BruteForce-SIEM-SOAR-Lab

一个基于 Splunk SIEM、Sigma 规则和 iptables 的 SSH 暴力破解检测与自动化响应实验室项目,演示了完整的 SOC pipeline。

Stars: 0 | Forks: 0

# 自动化 SSH 暴力破解检测与缓解 Pipeline (SIEM/SOAR 实验室) ## 📌 项目概述 这个作品集项目展示了一个端到端的安全运营 pipeline。它模拟了来自外部攻击者的实时 SSH 暴力破解攻击,将安全日志接入 SIEM 平台以实现实时可视化,并部署了自动化的主动防御响应机制来缓解威胁。 **MITRE ATT&CK 技术:** [T1110 - Brute Force](https://attack.mitre.org/techniques/T1110/) (Credential Access) ## 🛠️ 技术与使用的工具 | 类别 | 工具 | |---|---| | SIEM | Splunk Enterprise | | 攻击模拟 | Kali Linux & Hydra | | 目标环境 | Ubuntu Server (Linux) | | 自动化 / SOAR | Bash Scripting & Netfilter/iptables | | 检测工程 | Sigma Rule (YAML) | ## 🎛️ 架构与 Pipeline 流程 1. **攻击:** Kali Linux 使用 Hydra 针对目标发起高速 SSH 暴力破解攻击。 2. **日志记录:** Ubuntu 目标原生将每次身份验证失败记录到 `/var/log/auth.log`。 3. **SIEM 接入:** Splunk 通过专用的文件输入实时监控并索引日志,在攻击展开时提供全面的可视化。 4. **自动化防御:** 自定义的 Bash 脚本 (`scripts/auto_block.sh`) 会追踪日志,在滑动时间窗口内跟踪每个源 IP 的失败尝试次数,并在超过阈值时动态添加 `iptables DROP` 规则——无需人工干预即可隔离攻击者。 5. **检测规则:** 供应商中立的 Sigma 规则 (`detection/lnx_ssh_brute_force.yml`) 以可移植格式记录了检测逻辑,可转换为任何现代 SIEM(Splunk、Elastic、Sentinel、QRadar 等),而不仅限于本实验室。 ``` Kali Linux (Hydra) ---> Ubuntu Server (/var/log/auth.log) ---> Splunk (ingestion + visibility) | v auto_block.sh (detect + iptables DROP) ``` ## 🛡️ 检测规则 (Sigma) 参见 [`detection/lnx_ssh_brute_force.yml`](detection/lnx_ssh_brute_force.yml)。 ``` title: SSH Brute Force Detection id: a7d2e411-1337-4b88-824a-7bc9b60b73c2 status: experimental description: Detects high velocity of failed SSH login attempts indicating a potential brute force attack. logsource: product: linux service: sshd detection: selection: _raw|contains: 'Failed password' timeframe: 1m condition: selection | count() > 5 falsepositives: - Automated administrative scripts - User forgetting credentials level: high ``` ## 🤖 自动化缓解脚本 参见 [`scripts/auto_block.sh`](scripts/auto_block.sh)。 它充当了一个轻量级的 SOAR 引擎:它实时追踪 auth 日志,在 **60 秒的滑动窗口** 内跟踪每个源 IP 的失败登录时间戳(而不是全时段计数,因为全时段计数会有风险:随着时间推移,合法用户如果输入错密码,可能会被永久封锁),一旦突破阈值就会触发 `iptables DROP` 规则。 ``` #!/bin/bash LOG_FILE="/var/log/auth.log" THRESHOLD=5 WINDOW_SECONDS=60 declare -A ip_timestamps tail -Fn0 "$LOG_FILE" | while read -r line; do if echo "$line" | grep -q "Failed password"; then IP=$(echo "$line" | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' | head -n 1) [ -z "$IP" ] && continue NOW=$(date +%s) ip_timestamps["$IP"]="${ip_timestamps[$IP]} $NOW" NEW_LIST="" for ts in ${ip_timestamps[$IP]}; do if (( NOW - ts <= WINDOW_SECONDS )); then NEW_LIST="$NEW_LIST $ts" fi done ip_timestamps["$IP"]="$NEW_LIST" FAIL_COUNT=$(echo "$NEW_LIST" | wc -w) if [ "$FAIL_COUNT" -gt "$THRESHOLD" ]; then if ! iptables -C INPUT -s "$IP" -j DROP 2>/dev/null; then echo "[ALERT] $(date '+%F %T') - Brute-force detected from $IP ($FAIL_COUNT failures in ${WINDOW_SECONDS}s). Blocking traffic." iptables -A INPUT -s "$IP" -j DROP fi fi fi done ``` ## 📊 结果 - 模拟攻击量:Hydra 使用 4 个并行任务针对 SSH 服务排入了 **14,344,399 次密码尝试** (rockyou.txt wordlist) - Splunk 在 24 小时的时间窗口内从目标处接入了 **560 个与身份验证相关的事件**,确认了来自 `/var/log/auth.log` 的实时日志可见性 - 在 Splunk 中构建了专用的 **"Linux Security Dashboard"**,以可视化随时变化的事件量,并按来源类型细分事件 - 注意:本次运行的截图详细捕捉了攻击和接入 pipeline;iptables 自动拦截触发在脚本测试期间已单独验证,但未在本次运行的截图中体现——重新运行并录制屏幕是计划的后续步骤 ### 截图 | # | 截图 | 展示内容 | |---|---|---| | 1 | `images/01-hydra-attack-terminal.png` | 从 Kali Linux 针对使用 rockyou wordlist 的 SSH 目标发起的 Hydra 暴力破解攻击 | | 2 | `images/02-iptables-baseline.png` | Ubuntu 目标上基线 `iptables -L -n -v` 的输出,展示防火墙链的状态 | | 3 | `images/03-splunk-log-search.png` | Splunk 搜索展示实时从目标接入的 560 个身份验证事件 | | 4 | `images/04-splunk-dashboard.png` | Splunk 中自定义的 "Linux Security Dashboard" 可视化事件量和来源类型细分 | ## ⚠️ 局限性与未来改进 坦率面对项目的局限性本身也是成熟度的标志——以下是 v1 版本尚未处理的问题,以及我在生产环境中将如何解决它们: 1. **仅限内存中的状态** —— 如果脚本重启,`ip_timestamps` 就会重置。生产版本会持久化存储状态(例如 Redis 或本地 SQLite 文件),这样重启就不会丢失跟踪记录。 2. **永久封锁,无自动过期** —— 一旦某个 IP 被封锁,它就会永远处于封锁状态。真正的 SOAR playbook 应该在冷却期后自动解封,或者在采取永久性措施之前要求分析师进行审查。 3. **基于 IP 的封锁是可以绕过的** —— 轮换源 IP(或隐藏在 CGNAT 后面)的攻击者将完全打破这种防御。更具弹性的方法是将此措施与账户锁定策略和基于行为/速度的检测结合起来,而不仅仅依赖 IP 信誉。 4. **无法区分攻击与分心员工** —— 单个确实忘记密码并反复尝试的用户可能会触发与攻击者相同的阈值。调整阈值/窗口,并在自动封锁特权账户之前提醒人工,将降低这种风险。 5. **检测是基于阈值的,而非基于行为的** —— 缓慢、低频的撞库尝试(每小时来自多个 IP 的少量尝试)将隐匿于监测之下。成熟的检测机制会将整个网络的失败登录关联起来,而不是孤立地针对单个 IP 进行检测。 ## 🔁 如何复现 1. 在同一网络上搭建一个 Ubuntu Server 虚拟机(目标)和一个 Kali Linux 虚拟机(攻击者)。 2. 在 Ubuntu 目标(或专用的收集器)上安装 Splunk Enterprise,并在 `/var/log/auth.log` 上配置文件监控输入。 3. 从 Kali 中,使用常见的 wordlist 针对目标的 SSH 服务运行 Hydra。 4. 在 Ubuntu 目标上运行 `scripts/auto_block.sh`(由于需要修改 iptables,请以 root 身份运行)。 5. 观察 Splunk 中实时出现的失败登录,并观察脚本如何在超过阈值后发出 `[ALERT]` 并应用 `iptables DROP` 规则。 6. 将 `detection/lnx_ssh_brute_force.yml` 加载到兼容 Sigma 的 pipeline 中(例如通过 [sigma-cli](https://github.com/SigmaHQ/sigma-cli)),将其转换为原生的 Splunk 搜索。 ## 🧠 本项目展示了什么 - 端到端的 SOC pipeline 思维:攻击 → 日志 → 检测 → 响应,而不仅仅是一个孤立的脚本 - 实时的 SIEM 日志接入和监控配置 - 使用供应商中立的 Sigma 格式进行检测工程,并与 MITRE ATT&CK 映射 - 基础的 SOAR/自动化逻辑,包括对其当前局限性的如实评估
标签:Bash, iptables, PB级数据处理, SOAR, 安全运维, 应用安全