ejk52515/Splunk-SIEM-Log-Analysis

# Splunk SIEM 与日志分析       ## 概述 本实验搭建了一个可用的安全信息和事件管理 (SIEM) pipeline。一台运行 Active Directory 的 Windows Server VM 将其 Windows Event Logs 转发到另一台运行 Splunk Enterprise 的 Ubuntu VM。Splunk 对这些事件进行索引并使其可被搜索，从而支持 SOC 分析师日常执行的认证失败调查、威胁狩猎和告警等操作。 这里的所有操作都在 Splunk 免费许可证（每天 500 MB 索引量）和符合 Azure 免费层条件的资源上运行，因此总成本为 **$0**。 | 字段 | 值 | | --- | --- | | 认证对标 | CompTIA Security+ · CySA+ · Splunk Core Certified User | | 工具 | Splunk Enterprise（免费许可证）· Splunk Universal Forwarder | | 环境 | Azure — Ubuntu 22.04 VM + Windows Server VM（来自实验 1） | | 完成时间 | 跨多次会话需 4–6 小时 | | 预计成本 | $0 | | 职业相关性 | SOC 分析师 (Tier 1–3) · 安全工程师 · 事件响应人员 | ## 架构 Windows Server VM 和 Splunk 索引器位于**两个独立的 Azure Virtual Network** 中。为了让它们能够通信，这些 VNet 通过 **VNet Peering** 连接，并且一条 NSG 规则允许在 TCP 9997 上进行 forwarder 通信。Windows Server 通过 Peering 将 Security、System 和 Application 日志转发给 Splunk 索引器；索引器将它们存储在一个专用的 index 中，并通过 Web UI 公开这些日志，用于搜索、仪表盘和告警。 ``` flowchart LR subgraph ADNET["AD VNet — 10.1.0.0/16"] subgraph WIN["Windows Server VM (Lab 1)"] AD["Active Directory
Security / System / Application logs"] UF["Splunk Universal Forwarder
inputs.conf"] AD --> UF end end subgraph SPLNET["Splunk VNet — 10.0.0.0/16"] subgraph LNX["Ubuntu 22.04 VM"] REC["Receiver :9997"] IDX["Index: windows_logs"] WEB["Web UI :8000"] REC --> IDX --> WEB end end UF -- "encrypted forward · TCP 9997
across VNet Peering" --> REC ANALYST["Analyst workstation
(SSH :22 / HTTP :8000)"] WEB --> ANALYST ANALYST -- "SPL searches · dashboards · alerts" --> WEB classDef win fill:#0078D4,stroke:#005a9e,color:#fff; classDef lnx fill:#65A637,stroke:#4a7d28,color:#fff; classDef ext fill:#444,stroke:#222,color:#fff; class AD,UF win; class REC,IDX,WEB lnx; class ANALYST ext; ``` **网络暴露（Azure NSG 规则）：** | 端口 | 用途 | 源（本实验） | 生产环境建议 | | --- | --- | --- | --- | | 8000 | Splunk Web UI | 任意 | 仅限受信任的管理员 IP | | 22 | 通过 SSH 连接 Ubuntu VM | 任意 | 仅限受信任的管理员 IP | | 9997 | Universal Forwarder 输入 | 对等的 VNet (`10.1.0.0/16`) | 仅限对等的 VNet | ## 本实验解决的问题 一个中型组织每天跨越工作站、Active Directory、防火墙、Web 服务器和云资源生成数百万条日志事件。如果没有 SIEM，这些日志会停留在孤立的系统中——没有人能够跨系统搜索它们、关联事件或发现表明攻击的模式。 SIEM 是 SOC 的核心工具。当告警触发时，分析师会打开 SIEM 以了解发生了什么、时间、来源以及受影响的内容。Splunk 是部署最广泛的商业 SIEM，这使得实操 Splunk 的经验几乎与每一个安全运营岗位直接相关。 | 角色 | 本实验如何适用 | | --- | --- | | SOC 分析师 (Tier 1) | 监控仪表盘，搜索日志以发现可疑活动，上报发现的问题 | | SOC 分析师 (Tier 2–3) | 构建检测规则，跨来源关联事件，威胁狩猎 | | 云安全工程师 | Microsoft Sentinel 和 AWS Security Hub 复用相同的 SIEM 心智模型 | | 事件响应人员 | 在安全事件期间构建事件时间线并确定泄露范围 | ## 关键概念

什么是 SIEM？

安全信息和事件管理。这是一个从整个环境中收集日志数据并使其可以在一处进行搜索的平台。它的两个核心工作是**关联**（跨系统连接事件，以揭示单一系统无法显示的模式）和**告警**（在满足可疑条件时自动通知分析师）。

什么是 SPL (Splunk Processing Language)？

用于向 Splunk 提问的查询语言。它作为一个 pipeline 工作：从一个搜索开始，然后通过过滤、转换和可视化命令传递结果。例如：`index=windows_logs EventCode=4625 | stats count by Account_Name | sort -count` 会查找失败的登录，按用户名进行计数，并按最高值排序。每次搜索都遵循相同的模式——先找到事件，然后塑造结果。

什么是 Splunk index？

用于事件的命名存储桶，类似于数据库表。搜索使用 `index=name` 指定要查询哪个 index。为不同数据源使用独立的 index，可以独立控制保留期、权限和存储。本实验使用了一个 index：`windows_logs`。

什么是 Universal Forwarder？

一种轻量级、免费的 Splunk agent，安装在你想收集其日志的任何计算机上。它监控日志文件和 Windows Event Logs，对数据进行压缩和加密，并使用最少的 CPU 和 RAM 通过端口 9997 将其转发给索引器。

关键 Windows Event ID

| Event ID | 含义 | 安全信号 | | --- | --- | --- | | 4624 | 成功登录 | 正常活动的基线 | | 4625 | 登录失败 | 某一账户激增 = 暴力破解；分散在多个账户 = 密码喷洒 | | 4740 | 账户锁定 | 连续的锁定可能表明攻击正在进行中 |

什么是 inputs.conf？

告诉 Universal Forwarder 要收集哪些数据的配置文件。它驻留在 forwarder 主机上。每个 `[bracketed]` 块都定义了一个数据源；其下方的设置控制其行为（`disabled=0` = 启用，`start_from=oldest` = 收集历史记录）。只需编辑一次，重启一次 forwarder。

## 我的构建内容 | 展示的技能 | 实际应用 | | --- | --- | | 部署 Splunk + 配置数据输入 | 每个 Splunk 部署都是从通过 Universal Forwarder 获取数据开始的 | | 熟悉 Splunk 界面 | 搜索、仪表盘、告警、报告——任何 SOC 角色的基本要求 | | 编写 SPL 搜索 | 这项技能将能够发现威胁的分析师与只盯着仪表盘的分析师区分开来 | | 构建安全仪表盘 | 随时间变化的登录失败、主要来源、按用户划分的认证失败——一目了然的安全态势 | | 识别失败的登录尝试 | 区分正常的用户失误和暴力破解攻击 | | 构建自动化告警 | Splunk 在定义的条件触发时执行操作，而不是等待人类去注意 | | 编写账户锁定检测 (4740) | 锁定轨迹可以揭示正在进行的密码喷洒（检测已就绪；本次运行未生成锁定事件） | ## 构建演练 ### 步骤 1 — 在 Azure VM 上部署 Splunk Splunk Enterprise 提供免费下载（60 天完整试用，之后自动转换为每天 500 MB 的免费许可证）。请选择 **Splunk Enterprise for Linux** —— 而不是 Splunk Cloud 或 SOAR。 **虚拟机规格：** | 设置 | 值 | | --- | --- | | OS | Ubuntu 22.04 LTS（符合免费层条件） | | 大小 | Standard_B2s（2 个 vCPU，4 GB RAM —— Splunk 要求 ≥ 4 GB） | | 磁盘 | 最少 30 GB | | 入站 NSG 端口 | 8000、9997、22（范围如上表所示） | **安装（通过 SSH 在 Ubuntu VM 上运行）：** ``` # 下载 Splunk Enterprise（版本为构建日期时的最新版本）。 # 如果此 URL 出现 404 错误，请从 splunk.com → Free Trials and Downloads 获取当前的 .deb wget 命令。 wget -O splunk.deb "https://download.splunk.com/products/splunk/releases/10.2.2/linux/splunk-10.2.2-80b90d638de6-linux-amd64.deb" # 安装软件包 sudo dpkg -i splunk.deb # 启动 Splunk 并接受许可协议（提示输入管理员凭据） sudo /opt/splunk/bin/splunk start --accept-license # 启用 Splunk 在重启时自动启动 sudo /opt/splunk/bin/splunk enable boot-start # 现在可以通过以下地址访问 Web UI：http://:8000 ``` ### 步骤 2 — 配置数据输入 **A 部分 — 在 Splunk 中启用接收：** 1. 登录 Web UI → **Settings → Forwarding and Receiving** 2. **Configure Receiving → New Receiving Port →** 输入 `9997` → **Save** 3. **Settings → Indexes → New Index →** 将其命名为 `windows_logs` → **Save** **B 部分 — 在 Windows Server VM 上安装 Universal Forwarder**（实验 1 中的 AD 主机 —— *不是* Splunk VM）： 1. 从 splunk.com 下载 Windows 64 位 Universal Forwarder 2. 在安装过程中，将 **Receiving Indexer** 设置为 Splunk VM 的 **私有 IP : 9997** 3. 使用默认设置完成安装 **C 部分 — 配置 `inputs.conf`**，路径为 `C:\Program Files\SplunkUniversalForwarder\etc\system\local\inputs.conf` （如果 `local` 文件夹不存在，请创建它；使用以管理员身份运行的记事本进行编辑）： ``` [WinEventLog://Security] # Authentication 事件 — 登录、失败、锁定 disabled = 0 start_from = oldest current_only = 0 evt_resolve_ad_obj = 1 # Resolve AD names so usernames appear instead of SIDs index = windows_logs # REQUIRED — without this, data lands in main, not windows_logs [WinEventLog://System] # OS 级事件 — 服务启动/停止、驱动程序故障 disabled = 0 index = windows_logs [WinEventLog://Application] # 来自已安装应用程序的事件 disabled = 0 index = windows_logs ```  然后重启 forwarder（以管理员身份运行 PowerShell）： ``` Restart-Service SplunkForwarder ``` **D 部分 — 连接两个 VNet（VNet Peering + NSG 规则）：** Windows Server 和 Splunk VM 位于**独立的 Azure Virtual Network** 中，因此即使有正确的端口规则，它们默认也无法通信。这需要两个步骤： 1. 在 **Splunk VM 的 NSG** 上，添加一条允许来自 AD VNet 范围（forwarder 的源）的 **TCP 9997** 流量的入站规则。 2. 在两个网络之间创建 **VNet Peering**：**Virtual Networks → (Splunk VNet) → Peerings → Add**，选择 AD VNet 作为远程网络，让 Azure 配置双向连接。等待两边都显示 **Status: Connected**。 在网络配置完成后，再次重启 forwarder，使其重新尝试连接： ``` Restart-Service SplunkForwarder ``` ### 步骤 3 — 基础 SPL 搜索 **确认数据正在传输：** ``` index=windows_logs | head 100 ``` 如果返回了结果，说明 forwarder 正在工作。如果为空，请验证 Windows VM 上的 `SplunkForwarder` 服务是否正在运行。 **失败的登录（暴力破解指标）：** ``` index=windows_logs sourcetype=WinEventLog:Security EventCode=4625 | stats count by Account_Name, Workstation_Name | sort -count ``` 在短时间内某一账户计数达到 5 次及以上，即可能是暴力破解尝试。 **按登录类型划分的成功登录：** ``` index=windows_logs sourcetype=WinEventLog:Security EventCode=4624 | stats count by Account_Name, Logon_Type | sort -count ``` 登录类型：`2` 交互式 · `3` 网络 · `5` 服务账户 · `10` RDP。 **账户锁定事件：** ``` index=windows_logs sourcetype=WinEventLog:Security EventCode=4740 | table _time, Account_Name, Caller_Computer_Name | sort -_time ``` 某一账户出现多次锁定 = 很可能是暴力破解或密码喷洒。*在本实验运行中，模拟活动未产生 4740 事件，因此此搜索返回为空——它作为一个随时可用的检测手段被包含在内，一旦发生真实的锁定事件，它就会显示数据。* **前 10 个登录失败的用户名（威胁狩猎）：** ``` index=windows_logs sourcetype=WinEventLog:Security EventCode=4625 earliest=-24h | stats count as failures by Account_Name | sort -failures | head 10 ``` 24 小时内出现 20 次以上的失败值得调查。AD 中不存在的用户名表明发生了账户枚举。 **下班时间登录：** ``` index=windows_logs sourcetype=WinEventLog:Security EventCode=4624 | eval hour=strftime(_time, "%H") | where hour < 7 OR hour > 19 | table _time, Account_Name, Workstation_Name, Logon_Type | sort -_time ``` 下班时间的服务登录（Type 5）是预期的；普通用户在下班时间的交互式登录（Type 2/10）则需要审查。 ### 步骤 4 — 构建安全仪表盘 我构建了一个名为 **Windows Security Overview** 的仪表盘（**Dashboards → Create New Dashboard**），以便一目了然地展示安全态势，而无需手动重新运行搜索。  | 面板 | 显示内容 | 可视化方式 | | --- | --- | --- | | Acct Activity — Last 24h | 按 `Account_Name` 和 `Logon_Type` 细分的登录活动 | 柱状图 | | Top Processes — Last 24h | 按 `Creator_Process_Name` 统计的最频繁进程创建事件 | 柱状图 | | Login Activity Over Time | 通过 `timechart count` 显示一天内的登录量 | 折线图 | ### 步骤 5 — 创建自动化告警 告警可实现检测的自动化：Splunk 不再是盯着仪表盘，而是按计划运行搜索，并在满足条件时通知你——这正是真实 SOC 检测的工作方式。 我创建了一个名为 **High Privileged Logon Count** 的定时告警，当返回结果时触发，并执行 **Add to Triggered Alerts** 操作。  | 设置 | 值 | | --- | --- | | 名称 | High Privileged Logon Count | | 状态 | Enabled | | 应用 | search | | 告警类型 | Scheduled (cron 计划) | | 触发条件 | Number of Results > 0 | | 触发操作 Add to Triggered Alerts | 作为参考，以相同方式构建的暴力破解阈值告警如下所示： ``` index=windows_logs sourcetype=WinEventLog:Security EventCode=4625 | stats count as failures by Account_Name | where failures > 10 ``` ## 验证 | 检查项 | 如何验证 | | --- | --- | | 数据已流入 Splunk | `index=windows_logs \| head 10` 返回近期事件 | | 登录失败搜索有效 | 运行 `EventCode=4625` 搜索；如果为空，在 Windows VM 上故意输错几次密码后重新运行 | | 仪表盘显示数据 | **Windows Security Overview** 显示已填充的面板 | | 告警处于活动状态 | **Settings → Searches, Reports, and Alerts** 列出的 **High Privileged Logon Count** 状态为 Enabled | ## 技能总结 本实验展示了端到端的 SIEM 能力：部署平台、使用 Universal Forwarder 检测 Windows 终端、编写调查性 SPL、在仪表盘中可视化安全态势，以及通过定时告警将检测操作化。这些正是 Tier 1–3 SOC 分析师、安全工程师或事件响应人员在实际工作中所执行的工作流程。 ## 法律与道德声明 本实验完全在一个自有的、隔离的 Azure 实验环境中使用我控制的账户和系统进行的。所展示的检测技术仅用于防御性安全监控和教育目的。请勿对你不拥有或缺乏明确书面授权测试的系统运行认证失败或枚举测试。

标签：Azure, Terraform 安全, 安全实验环境, 红队行动, 运维监控