ravikirank29/Enterprise-SSH-Threat-Monitoring

# 🛡️ 企业级 SSH 威胁监控与检测工程

基于云的 SOC 检测工程实验室 | 从认证遥测到检测、告警与调查

AWS EC2 • Splunk Enterprise • Ubuntu Linux • Kali Linux • SPL • 检测工程

## 📌 执行摘要 **企业级 SSH 威胁监控与 Splunk 检测工程** 是一个端到端的、基于云的 SOC（安全运营中心）实验室，展示了 Linux SSH 威胁监控的完整生命周期——从原始认证遥测到集中式 SIEM 分析、自定义检测、仪表盘、自动化告警以及分析师调查。 该环境使用 **AWS EC2** 部署，其中 Ubuntu Linux 系统作为被监控的端点，而 Splunk Enterprise 提供集中式的安全监控。 由 OpenSSH 服务生成的认证遥测记录在： ``` /var/log/auth.log ``` **Splunk Universal Forwarder** 持续监控认证日志，并通过 **TCP 端口 9997** 将安全事件转发至 Splunk Enterprise。 这些事件存储在一个专用的： ``` linux_auth ``` index 中，并使用自定义的 **Splunk 搜索处理语言 (SPL)** 进行分析。 来自 Kali Linux 系统的受控认证测试生成了具有代表性的安全遥测数据，使得完整的检测管道得以验证。 该项目演示了完整的安全监控生命周期： ``` Attack Simulation ↓ Authentication Telemetry ↓ Log Collection ↓ Centralized SIEM ↓ Detection Engineering ↓ Dashboard Visualization ↓ Automated Alerting ↓ SOC Investigation ``` ## ⭐ 项目亮点 | 能力 | 实现 | |---|---| | ☁️ **云基础设施** | AWS EC2、VPC 和安全组 | | 📡 **遥测管道** | Ubuntu `auth.log` → Splunk Universal Forwarder → Splunk Enterprise | | 🔎 **检测工程** | 针对失败、源 IP、目标用户和暴力破解行为的自定义 SPL 检测 | | 📊 **SOC 可见性** | 用于认证监控和调查的运营仪表盘 | | 🚨 **自动化检测** | 带有已验证触发历史的定时 Splunk 告警 | | 🕵️ **调查工作流** | 告警 → 源 IP → 目标账户 → 时间线 → 认证结果 → 分流处理 | ## 📑 目录 - [项目目标](#-project-objectives) - [架构](#️-architecture) - [架构组件](#-architecture-components) - [数据流](#-data-flow) - [技术栈](#️-technology-stack) - [项目工作流](#-project-workflow) - [AWS 基础设施](#️-aws-infrastructure) - [Splunk 配置](#-splunk-configuration) - [日志收集管道](#-log-collection-pipeline) - [攻击模拟](#-attack-simulation) - [检测工程](#-detection-engineering) - [检测目录与用例](#-detection-catalog--use-cases) - [SOC 监控仪表盘](#-soc-monitoring-dashboard) - [自动化告警](#-automated-alerting) - [检测查询验证](#-detection-query-validation) - [SOC 调查工作流](#️-soc-investigation-workflow) - [实施证据](#-implementation-evidence) - [仓库结构](#️-repository-structure) - [文档](#-documentation) - [关键成果](#-key-outcomes) - [展示的技术技能](#-technical-skills-demonstrated) - [工程经验教训](#-engineering-lessons-learned) - [版本 1.0](#-version-10) - [未来路线图](#️-future-roadmap) - [安全考虑](#-security-considerations) - [许可证](#-license) - [作者](#-author) # 🎯 项目目标 该项目的主要目标是演示 SOC 如何监控和调查针对 Linux SSH 服务的凭据攻击。 该项目旨在： - 使用 Splunk Enterprise 部署集中式 SIEM - 在 AWS 中构建基于云的安全监控基础设施 - 监控 Linux SSH 认证活动 - 使用 Splunk Universal Forwarder 收集认证日志 - 将安全遥测数据集中到专用的 Splunk index 中 - 模拟受控的 SSH 认证活动 - 开发自定义 SPL 检测规则 - 检测重复的认证失败 - 识别潜在的 SSH 暴力破解行为 - 识别攻击源 IP 地址 - 识别经常被列为目标的用户账户 - 监控成功的 SSH 认证 - 将成功的认证与之前的失败相关联 - 构建可运行的 SOC 监控仪表盘 - 配置自动定时告警 - 记录完整的从攻击到检测的工作流 # 🏗️ 架构 该项目实现了一个端到端的 SSH 安全监控管道，连接了攻击模拟、端点遥测、日志转发、SIEM 分析和 SOC 调查。

该架构遵循以下工作流： ``` Kali Linux │ │ Controlled SSH Testing │ TCP/22 ▼ Ubuntu Target Server │ │ /var/log/auth.log ▼ Splunk Universal Forwarder │ │ TCP/9997 ▼ Splunk Enterprise │ ├── linux_auth Index ├── SPL Detection Rules ├── Dashboards └── Scheduled Alerts │ ▼ SOC Analyst │ ├── Monitoring ├── Investigation └── Incident Response ``` # 🧩 架构组件 ## Kali Linux Kali Linux 代表受控的安全测试系统。 它用于针对实验室环境生成认证活动，以便对安全检测进行测试和验证。 使用的工具包括： - Nmap - Hydra - SSH client ## Ubuntu 目标服务器 Ubuntu EC2 实例充当被监控的 Linux 端点。 该服务器运行 OpenSSH 服务并生成认证遥测数据。 主要监控的日志源是： ``` /var/log/auth.log ``` 事件包括： - 失败的认证尝试 - 成功的认证 - 无效的用户名 - SSH 守护进程活动 - 认证失败 - 会话创建 - 会话终止 ## Splunk Universal Forwarder Splunk Universal Forwarder 安装在被监控的 Ubuntu 端点上。 它的作用是持续监控： ``` /var/log/auth.log ``` 并将新事件转发到 Splunk Enterprise 服务器。 ``` /var/log/auth.log │ ▼ Splunk Universal Forwarder │ │ TCP/9997 ▼ Splunk Enterprise ``` ## Splunk Enterprise Splunk Enterprise 充当集中式的 SIEM 平台。 其职责包括： - 接收认证遥测数据 - 索引安全事件 - 执行 SPL 搜索 - 运行检测逻辑 - 支持威胁狩猎 - 可视化认证活动 - 生成定时告警 - 支持 SOC 调查 认证事件存储在： ``` index=linux_auth ``` ## SOC 分析师 SOC 分析师使用集中式监控环境来： - 监控认证活动 - 审查安全仪表盘 - 调查触发的告警 - 识别可疑的源 IP - 分析被针对的账户 - 审查认证时间线 - 确定可疑活动是否需要升级处理 # 🔄 数据流 ``` Controlled Security Test │ ▼ SSH Authentication Activity │ ▼ Ubuntu OpenSSH Service │ ▼ /var/log/auth.log │ ▼ Splunk Universal Forwarder │ │ TCP/9997 ▼ Splunk Enterprise │ ▼ linux_auth Index │ ▼ SPL Detection Engineering │ ├──────────────┐ ▼ ▼ SOC Dashboard Scheduled Alert │ │ └──────┬───────┘ ▼ SOC Investigation ```

# 🛠️ 技术栈 | 层级 | 技术 | 用途 | |---|---|---| | 云 | AWS EC2 | 托管基于云的基础设施 | | SIEM | Splunk Enterprise | 集中式安全监控 | | 目标端点 | Ubuntu Linux | 被监控的 SSH 服务器 | | 安全测试 | Kali Linux | 受控的攻击模拟 | | 日志收集 | Splunk Universal Forwarder | 转发认证遥测数据 | | 日志源 | `/var/log/auth.log` | Linux 认证事件 | | 测试工具 | Hydra | 受控的认证测试 | | 侦察 | Nmap | 验证 SSH 服务暴露情况 | | 协议 | SSH | 远程认证 | | 检测语言 | SPL | 安全分析和检测 | | 可视化 | Splunk Dashboard | SOC 监控 | | 告警 | Splunk Scheduled Alerts | 自动化检测通知 | | 基础设施 | AWS VPC / Security Groups | 网络隔离和访问控制 | # 🚀 项目工作流 ## 阶段 1 — AWS 基础设施 部署了 AWS EC2 基础设施以托管安全监控环境。 该环境包括： - Splunk Enterprise Server - Ubuntu Linux Target Server - 网络安全控制 - 安全组规则 ## 阶段 2 — Splunk Enterprise 安装 Splunk Enterprise 并将其配置为集中式 SIEM。 创建了一个专用的 index： ``` linux_auth ``` 配置了 Splunk 以通过以下端口接收转发的事件： ``` TCP/9997 ``` ## 阶段 3 — Universal Forwarder 在 Ubuntu 目标上安装了 Splunk Universal Forwarder。 配置了 forwarder 以监控： ``` /var/log/auth.log ``` 并将认证遥测数据发送到 Splunk Enterprise。 ## 阶段 4 — 数据验证 使用以下方式验证了数据摄入： ``` index=linux_auth ``` 这确认了在 Ubuntu 端点上生成的认证事件已成功到达 Splunk Enterprise 服务器。 ## 阶段 5 — 受控攻击模拟 从 Kali Linux 测试系统生成了受控的 SSH 认证活动。 这产生了包括以下内容的遥测数据： - 登录失败尝试 - 成功的认证事件 - 重复的认证尝试 - 多个被针对的用户名 ## 阶段 6 — 检测工程 开发了自定义 SPL 搜索，将原始认证遥测数据转化为可操作的安全检测。 ## 阶段 7 — 仪表盘开发 将检测结果集成到了可运行的 SOC 仪表盘中。 ## 阶段 8 — 自动化告警 配置了定时的 Splunk 告警，以自动检测潜在的暴力破解认证活动。 # ☁️ AWS 基础设施 实验室基础设施使用 AWS EC2 部署。

### AWS 安全组 使用 AWS 安全组控制网络访问。

所需的通信包括： | 源 | 目标 | 端口 | 用途 | |---|---|---:|---| | 授权测试系统 | Ubuntu 目标 | 22 | SSH | | Ubuntu 目标 | Splunk Enterprise | 9997 | Splunk 日志转发 | | 授权分析师 | Splunk Enterprise | 8000 | Splunk Web | ### VPC 网络

云网络在被监控系统之间提供连接，同时安全组限制了不必要的访问。 # 🔧 Splunk 配置 Splunk Enterprise 为该项目提供集中式安全监控。 ### Splunk Enterprise 界面

### Forwarder 接收端口 配置了 Splunk Enterprise 以通过 TCP 端口 `9997` 接收 Universal Forwarder 数据。

### Forwarder 状态 验证了被监控的 Ubuntu 端点与 Splunk Enterprise 之间的连通性。

# 📥 日志收集管道 主要的认证遥测源是： ``` /var/log/auth.log ``` Universal Forwarder 持续监控此文件。

完整的摄入管道是： ``` SSH Event │ ▼ OpenSSH │ ▼ /var/log/auth.log │ ▼ Splunk Universal Forwarder │ │ TCP/9997 ▼ Splunk Enterprise │ ▼ linux_auth Index ``` ### Splunk 中的认证事件

这确认了 Linux 认证遥测的端到端收集成功。 # 🧪 攻击模拟 进行了受控的安全测试以生成真实的认证事件。 ## SSH 服务验证 在授权实验室中使用 Nmap 验证目标 SSH 服务是否可访问。

## 受控认证测试 从 Kali Linux 测试环境生成了认证活动。

然后生成的事件被： ``` Generated on Ubuntu ↓ Written to auth.log ↓ Forwarded to Splunk ↓ Indexed in linux_auth ↓ Analyzed with SPL ↓ Detected by Security Rules ``` # 🔎 检测工程 该项目核心技术重点是**将原始认证事件转化为可操作的安全检测**。 检测策略侧重于： - 失败的 SSH 认证活动 - 成功的 SSH 认证活动 - 认证失败激增 - 来自单个来源的重复失败 - 频繁被针对的用户账户 - 潜在的暴力破解活动 - 重复失败后的成功认证 检测查询在以下文件中进行版本控制： ``` spl/ ``` 这将检测逻辑与文档分离开来，允许对规则进行独立维护和改进。 # 🧠 检测目录与用例 ## `DET-001` — SSH 登录失败趋势 ``` index=linux_auth "Failed password" | timechart count ``` **目的：** 识别失败 SSH 认证活动的变化和激增。 ## `DET-002` — SSH 登录成功趋势 ``` index=linux_auth "Accepted password" | timechart count ``` **目的：** 随时间监控成功的 SSH 认证活动。 ## `DET-003` — 排名靠前的攻击源 IP ``` index=linux_auth "Failed password" | rex "from (?\d+\.\d+\.\d+\.\d+)" | stats count by src_ip | sort -count ``` **目的：** 识别导致最多失败认证尝试的源 IP 地址。 ## `DET-004` — 最受关注的目标用户 ``` index=linux_auth "Failed password" | rex "for (invalid user )?(?\w+)" | stats count by user | sort -count ``` **目的：** 识别接收到最多认证尝试次数的用户账户。 ## `DET-005` — SSH 暴力破解检测 ``` index=linux_auth "Failed password" | rex "from (?\d+\.\d+\.\d+\.\d+)" | stats count by src_ip | where count >= 5 ``` **目的：** 识别超过预定认证失败阈值的源 IP 地址。 ## `DET-006` — 多次失败后的成功认证 此检测将重复的认证失败与随后的成功认证活动相关联。 完整的已验证 SPL 逻辑维护在： ``` spl/ ``` **目的：** 突出显示可能需要优先调查的认证序列。 # 📊 SOC 监控仪表盘 **企业级 SSH 威胁监控仪表盘**提供了对认证活动的集中可见性。

该仪表盘包括： - SSH 登录失败趋势 - SSH 登录趋势 - 排名靠前的攻击 IP 地址 - 最受关注的目标用户账户 - SSH 暴力破解检测 - 成功登录关联 ## 暴力破解检测面板

此面板突出显示超过配置的认证失败阈值的源 IP 地址。 ## 成功登录关联

此检测帮助分析师调查与之前失败相关的成功认证活动。 ## 认证登录趋势

认证趋势提供了对登录活动随时间变化的可见性。 ## 排名靠前的攻击 IP

此可视化帮助优先调查最活跃的可疑来源。 # 🚨 自动化告警 该项目针对潜在的 SSH 暴力破解活动实施了定时 Splunk 告警。 ## 告警配置

该告警定期执行检测搜索，并评估可疑活动是否超过配置的阈值。 ## 告警触发历史

触发历史确认了该检测在受控测试期间成功生成了告警。 ## 告警结果

告警结果为分析师提供了开始调查所需的信息。 告警工作流如下： ``` Authentication Events │ ▼ Scheduled SPL Search │ ▼ Detection Threshold │ ▼ Suspicious Activity Found │ ▼ Alert Triggered │ ▼ SOC Analyst Investigation ``` # 🔬 检测查询验证 暴力破解检测逻辑直接在 Splunk Search 中进行了验证。 ### 查询验证 — 第 1 部分

### 查询验证 — 第 2 部分

此验证确认了检测逻辑能够正确识别与配置标准匹配的认证活动。 # 🕵️ SOC 调查工作流 当检测到可疑的认证活动时，分析师可以遵循以下调查流程： ``` Alert Triggered │ ▼ Review Source IP │ ▼ Identify Targeted Accounts │ ▼ Review Authentication Timeline │ ▼ Check for Successful Authentication │ ▼ Review Related Security Events │ ▼ Determine Severity │ ▼ Escalate / Respond ``` 生产环境中的响应可能包括： - 封锁已确认的恶意来源 - 保护或禁用受损账户 - 重置凭据 - 审查端点活动 - 搜索额外的威胁指标 - 升级事件响应 # 📸 实施证据 项目截图按实施阶段组织： ``` screenshots/ ├── alerts/ ├── architecture/ ├── attacks/ ├── aws/ ├── dashboard/ └── splunk/ ``` 这些截图共同记录了从基础设施部署到攻击模拟、日志收集、检测工程、仪表盘开发和自动化告警的完整进展。 # 🗂️ 仓库结构 ``` Enterprise-SSH-Threat-Monitoring/ │ ├── README.md ├── CHANGELOG.md ├── LICENSE │ ├── assets/ │ ├── diagrams/ │ ├── architecture.drawio │ └── architecture.png │ ├── docs/ │ ├── 01_Project_Overview.md │ ├── 02_Lab_Architecture.md │ ├── 03_AWS_Deployment.md │ ├── 04_Splunk_Configuration.md │ ├── 05_Log_Collection.md │ ├── 06_Attack_Simulation.md │ ├── 07_Detection_Engineering.md │ ├── 08_Dashboard.md │ ├── 09_Alerting.md │ └── 10_Lessons_Learned.md │ ├── images/ │ ├── architecture.png │ ├── banner.png │ ├── dashboard-preview.png │ └── workflow.png │ ├── screenshots/ │ ├── alerts/ │ │ ├── 16-alert-config.png │ │ ├── 17-alert-triggered.png │ │ └── 18-alert-results.png │ │ │ ├── architecture/ │ │ │ ├── attacks/ │ │ └── 10-hydra.png │ │ │ ├── aws/ │ │ ├── 01-ec2-instances.png │ │ ├── 02-security-group.png │ │ └── 03-vpc-network.png │ │ │ ├── dashboard/ │ │ ├── 11-dashboard.png │ │ ├── 12-bruteforce-table.png │ │ ├── 13-success-correlation.png │ │ ├── 14-login-trend.png │ │ └── 15-top-attacking-ip.png │ │ │ └── splunk/ │ ├── 04-splunk-home.png │ ├── 05-forwarder-port.png │ ├── 06-forwarder-status.png │ ├── 07-monitor-authlog.png │ ├── 08-linux-auth-events.png │ ├── 09-nmap-scan.png │ ├── 19.1-bruteforce-query.png │ └── 19.2-bruteforce-query.png │ ├── scripts/ │ └── spl/ └── Detection queries ``` # 📚 文档 详细的技术文档位于 `docs/` 目录中。 | 文档 | 描述 | |---|---| | `01_Project_Overview.md` | 项目目标和范围 | | `02_Lab_Architecture.md` | 架构与组件设计 | | `03_AWS_Deployment.md` | AWS 基础设施部署 | | `04_Splunk_Configuration.md` | Splunk Enterprise 配置 | | `05_Log_Collection.md` | 认证日志收集管道 | | `06_Attack_Simulation.md` | 受控安全测试 | | `07_Detection_Engineering.md` | SPL 检测开发 | | `08_Dashboard.md` | SOC 仪表盘实施 | | `09_Alerting.md` | 自动化告警工作流 | | `10_Lessons_Learned.md` | 挑战与技术教训 | # 🏆 关键成果 该项目展示的不仅仅是 SIEM 部署。它展示了构建和验证完整防御性监控工作流的能力： - 在 AWS 上**构建**了基于云的 Splunk 监控环境。 - 使用 Splunk Universal Forwarder **集中**了 Linux SSH 认证遥测数据。 - 针对可疑的认证行为**开发**了自定义 SPL 检测。 - 使用受控的安全测试和具有代表性的遥测数据**验证**了检测逻辑。 - 通过仪表盘和定时告警将检测**运营化**。 - 通过架构图、实施证据、检测查询和调查工作流对环境进行了**记录**。 # 💡 展示的技术技能 ### 安全运营 - SOC 监控 - 安全事件分析 - 告警调查 - 事件分流 - 认证监控 ### SIEM 工程 - Splunk Enterprise - Splunk Universal Forwarder - 日志摄入 - Index 管理 - SPL - 仪表盘开发 - 告警工程 ### 检测工程 - 检测规则开发 - 认证分析 - 基于阈值的检测 - 检测验证 - 事件关联 ### 云安全 - AWS EC2 - AWS VPC - AWS Security Groups - 云网络 ### Linux - Ubuntu 管理 - OpenSSH - Linux 认证日志 - 服务配置 - 日志分析 ### 安全测试 - Kali Linux - Nmap - 受控认证测试 - 攻击模拟 ### 工程 - Git - GitHub - 技术文档 - 架构设计 - 版本控制 # 🧠 工程经验教训 ## 可靠的遥测是首要前提 有效的检测工程依赖于可靠的安全遥测。 完整的数据管道必须正常运行： ``` Log Source ↓ Universal Forwarder ↓ Network ↓ Splunk Receiver ↓ Index ↓ Detection ``` ## 检测规则需要验证 返回结果的搜索并不自动意味着它是一个可靠的检测。 检测逻辑应针对具有代表性的安全遥测数据进行测试，并审查是否存在误报和漏报。 ## 仪表盘应支持调查 一个有用的 SOC 仪表盘应该帮助分析师回答特定的安全问题，而不是仅仅展示原始数据。 ## 告警需要调优 静态阈值对于演示检测概念很有用，但生产环境需要基于以下因素进行调优： - 环境规模 - 预期的认证量 - 用户行为 - 历史基线 - 已知的管理活动 # ✅ 版本 1.0 版本 1.0 奠定了企业级 SSH 威胁监控项目的基础。 ### 已完成 - [x] AWS 基础设施部署 - [x] Splunk Enterprise 部署 - [x] Splunk Universal Forwarder 配置 - [x] Linux 认证日志收集 - [x] SSH 安全监控 - [x] 受控攻击模拟 - [x] SPL 检测工程 - [x] SOC 仪表盘 - [x] 定时告警 - [x] 告警验证 - [x] 技术文档 - [x] 架构文档 - [x] 截图证据 - [x] 版本控制的检测查询 # 🛣️ 未来路线图 ## 版本 2.0 — 高级检测工程 计划的改进包括： - 密码喷洒检测 - 权限提升监控 - 可疑的 `sudo` 活动 - 新用户账户监控 - SSH 配置变更监控 - MITRE ATT&CK 映射 - 高级认证关联 ## 未来扩展 未来的潜在功能包括： - 威胁情报富化 - IP 信誉分析 - 威胁狩猎仪表盘 - Windows 端点监控 - Sysmon 遥测 - 跨平台检测工程 - SOAR 集成 - 自动化事件响应工作流 # 🔐 安全考虑 本仓库旨在用于： - 网络安全教育 - 防御性安全研究 - 检测工程 - 授权的安全测试 本项目中记录的所有安全测试均在授权和受控的实验室环境中进行。 以下敏感信息永远不应提交到仓库中： - AWS 凭据 - 私有 SSH 密钥 - API 密钥 - 访问令牌 - 密码 - 账户标识符

⬆ 返回顶部

# 📄 许可证 该项目在 **MIT License** 下授权。 详情请参阅 `LICENSE` 文件。 # 👤 作者 ## Ravi Kiran Kambhampati **网络安全 | SOC 运营 | 检测工程 | 云安全** 该项目是专注于以下领域实践经验的网络安全实战作品集的一部分： - 安全运营 - SIEM 工程 - 检测开发 - 云基础设施 - Linux 安全监控 - 事件调查

🛡️ 企业级 Splunk SSH 威胁监控

认证遥测 → 检测工程 → 告警 → 调查

版本 1.0.0

标签：AWS, CTI, DPI, PE 加载器, 威胁情报, 安全运营, 开发者工具, 扫描框架, 红队行动, 逆向工具