Dmokom1/Network-Reconnaissance-Detection-Engineering

# Security Onion 中的侦察检测与自定义 SIEM 规则验证 本项目在一个用于网络检测和 SIEM 规则验证实践的隔离家庭 SOC 实验室中完成。 ## 概述 本项目侧重于在 Security Onion 中检测和验证侦察活动。 我模拟了从 Kali Linux 主机对 Windows Server 域控制器发起的 Nmap 扫描，查看了 Security Onion 生成的告警，确认了攻击者源 IP，并使用 Kibana 确认了相关的 Suricata 活动。 在日志中确认扫描行为后，我在 Elastic/Kibana 中创建了一个自定义阈值规则，用于对来自 Kali 源 IP 的重复 Suricata 活动进行告警。随后，我重新运行了针对性的 Nmap 扫描，以验证该规则是否成功生成告警。 目标不仅是运行 Nmap。目标是实践完整的检测工作流程： 1. 生成受控的侦察流量。 2. 查看 SIEM 告警。 3. 识别源和目标。 4. 深入辅助日志。 5. 构建自定义规则。 6. 重新测试活动以确认规则被触发。 ## 为什么构建本项目 侦察是攻击者尝试漏洞利用或凭据访问之前，防御者可能观察到的最早期行为之一。 我构建此实验室是为了实践扫描活动在 Security Onion 中的表现形式，以及如何将原始 IDS 告警转化为自定义检测规则。 本项目帮助我理解了： - Nmap 扫描行为在 Suricata 告警中的表现形式 - 如何从告警字段中识别扫描主机 - 如何从告警摘要视图切入 Kibana 日志数据 - 如何根据观察到的活动构建基于阈值的规则 - 为什么检测验证需要重新测试，而不仅仅是创建规则 ## 实验室环境 | 组件 | 详情 | |---|---| | 攻击者主机 | Kali Linux | | 攻击者 IP | `192.168.30.136` | | 目标主机 | Windows Server 域控制器 | | 目标 IP | `192.168.30.128` | | SIEM | Security Onion | | 检测引擎 | Suricata | | 日志审查 | Kibana / Elastic | | 扫描工具 | Nmap | ## 架构 ``` graph TD subgraph "Reconnaissance Activity" A[Kali Scanner] --> B[Nmap Scanning] B --> C[Windows Target] end subgraph "Network Monitoring" D[Zeek] E[Suricata] F[Network Sensors] end subgraph "SIEM & Detection" G[Security Onion] H[Custom SIEM Rules] I[Alert Generation] end C --> D C --> E D --> G E --> G F --> G G --> H H --> I ``` *展示组件和检测流程的高层实验室架构。* ## 使用的工具 | 工具 | 用途 | |---|---| | Nmap | 生成侦察扫描流量 | | Security Onion | 收集并显示 IDS 告警 | | Suricata | 检测与扫描相关的网络行为 | | Kibana / Elastic | 查询 Suricata 告警数据并创建自定义规则 | ## 项目流程 项目遵循以下顺序： 1. 从 Kali 对域控制器运行 Nmap 扫描。 2. 查看扫描生成的 Security Onion 告警。 3. 在告警详情中识别 Kali 源 IP。 4. 在 Kibana 中使用攻击者源 IP 查询 Suricata 告警数据。 5. 在 Elastic/Kibana 中创建自定义阈值规则。 6. 查看规则元数据和计划。 7. 确认自定义规则出现在检测规则列表中。 8. 重新对域控制器运行针对性的 Nmap 扫描。 9. 确认自定义规则在验证期间生成了告警。 ## 阶段 1：Nmap 侦察扫描 从 Kali Linux 主机对域控制器执行了 Nmap 扫描。  ### 证明了什么 扫描目标为： `192.168.30.128` Nmap 输出将该主机识别为 Windows 系统，并显示了多个通常与域控制器相关的开放服务，包括： - DNS - Kerberos - Microsoft RPC - NetBIOS - LDAP - SMB - Microsoft HTTPAPI 这创建了可供 Security Onion 和 Suricata 检查的网络活动。 ## 阶段 2：Security Onion 告警审查 扫描之后，Security Onion 生成了多个与 Nmap 和扫描行为相关的 Suricata 告警。  ### 证明了什么 Security Onion 显示了与扫描相关的告警，例如： - `ET SCAN Nmap Scripting Engine User-Agent Detected` - `ET SCAN Possible Nmap User-Agent Observed` - `ET SCAN NMAP OS Detection Probe` 告警视图显示了重复的扫描活动，并按规则名称、模块、严重性和计数对其进行分组。 这证实了 Nmap 扫描生成了可见的 IDS 遥测数据。 ## 阶段 3：告警下钻与源 IP 识别 查看了告警详情以识别扫描主机。  ### 证明了什么 告警下钻显示源 IP 为： `192.168.30.136` 目标 IP 为： `192.168.30.128` 这证实了扫描活动来自 Kali 主机并针对域控制器。 识别源 IP 至关重要，因为它使得调查能够从一般的告警摘要转向针对攻击者主机的重点查询。 ## 阶段 4：针对 Suricata 活动的 Kibana 查询 使用 Kibana 查询与 Kali 源 IP 相关的 Suricata 告警数据。  ### 使用的查询 ``` source.ip:192.168.30.136 AND event.dataset.keyword:suricata.alert ``` ### 证明了什么 查询返回了来自 Kali 主机的 Suricata 告警活动。 截图显示了源 IP 为 `192.168.30.136` 的多个事件，包括发往域控制器和其他内部目的地的流量。 这证实了源 IP 可以作为自定义实验室检测规则的可靠条件。 ## 阶段 5：自定义阈值规则创建 在 Elastic/Kibana 中使用观察到的 Suricata 告警活动创建了自定义阈值规则。  ### 规则逻辑 自定义查询使用了： ``` source.ip:192.168.30.136 AND event.dataset.keyword:suricata.alert ``` 规则被配置为在阈值达到以下条件时发出告警： ``` All results >= 10 ``` ### 证明了什么 这表明观察到的扫描行为已转化为自定义检测规则。 该规则并非旨在成为通用的、可用于生产环境的 Nmap 检测器。它是一个围绕来自 Kali 主机的已知扫描活动设计的实验室验证规则。 ## 阶段 6：规则元数据和计划 在启用规则之前，查看了规则元数据和计划。  ### 证明了什么 规则命名为： `Kali Suricata Alert` 描述指出，它用于检测在实验室侦察和网络扫描期间由 Kali 攻击主机生成的 Suricata 告警活动。 规则配置显示： - 严重性：高 - 风险评分：50 - 运行频率：每 1 分钟 - 额外回溯时间：1 分钟 - 每次运行最大告警数：100 - 标签：`kali`、`suricata`、`recon` 这证实了规则具有明确的目的和计划配置。 ## 阶段 7：自定义规则可见性 创建后，自定义规则出现在 Elastic 检测规则界面中。  ### 证明了什么 规则在 Elastic 中已启用并可见，名称为： `Kali Suricata Alert` 规则定义显示了自定义的 KQL 查询和阈值条件。 这证实了规则处于活动状态并准备好进行验证。 ## 阶段 8：针对性 Nmap 扫描验证 再次对域控制器运行针对性的 Nmap 扫描，以验证自定义规则。  ### 证明了什么 验证扫描的目标为： `192.168.30.128` 扫描产生了类似的域控制器服务发现结果，包括 Kerberos、LDAP、SMB、DNS 以及与 Microsoft RPC 相关的服务。 这创建了新的 Suricata 告警活动供自定义规则评估。 ## 阶段 9：自定义规则告警验证 在针对性扫描之后，自定义规则在 Elastic 中生成了告警。  ### 证明了什么 告警仪表板显示了一个针对以下项目的高严重性告警： `Kali Suricata Alert` 这证实了自定义规则在验证期间被触发。 证据支持该规则在验证测试期间触发了一次。不应夸大其为规则在每个环境中都能始终如一触发的证明。 ## 检测逻辑说明 自定义规则使用了三个简单的理念： ### 1. 源 IP 过滤 该规则专注于已知的 Kali 源 IP： `192.168.30.136` 这有助于隔离来自测试攻击者主机的活动。 ### 2. Suricata 告警过滤 该规则过滤 Suricata 告警事件： ``` event.dataset.keyword:suricata.alert ``` 这使规则专注于 IDS 告警遥测数据，而不是所有的网络流量。 ### 3. 阈值逻辑 当匹配的 Suricata 事件数量达到配置的阈值时，该规则发出告警。 这有助于将重复的扫描活动转化为更高级别的检测，而不是仅仅依赖于单独的原始 IDS 告警。 ## 主要发现 ### 1. Nmap 扫描活动在 Security Onion 中可见 在 Nmap 活动之后，Security Onion 和 Suricata 生成了与扫描相关的告警。 ### 2. 源 IP 是关键的切入节点 调查使用 `192.168.30.136` 将告警活动追溯到 Kali 主机。 ### 3. Kibana 确认了辅助 Suricata 遥测数据 Kibana 查询显示了与 Kali 源 IP 关联的 Suricata 告警。 ### 4. 自定义规则在验证期间成功触发 在创建规则并重新进行扫描之后，Elastic 为自定义阈值规则生成了告警。 ### 5. 规则是特定于实验室的 该规则围绕受控实验室中已知的攻击者 IP 构建。在生产环境中，这样的规则需要更广泛的逻辑和调优。 ## 局限性 这是一个受控的家庭实验室，而不是生产环境的检测部署。 重要的局限性： - 攻击者 IP 是提前已知的。 - 规则是围绕特定的 Kali 源 IP 构建的。 - 该规则验证的是实验室中基于阈值的检测，而不是通用的 Nmap 检测。 - 截图证据支持一次成功的验证告警。 - 生产规则需要进行额外的调优以避免误报。 - 仅基于源 IP 的逻辑可能会在攻击者更改 IP、使用 NAT 或混入正常流量时失效。 - 该规则不能对所有可能的侦察技术进行分类。 - 本项目侧重于检测验证，而不是事件遏制或响应。 ## 未来版本的改进 如果我扩展这个项目，我将通过以下方式进行改进： - 创建一个不依赖于固定源 IP 即可检测扫描行为的规则。 - 按 `source.ip` 分组，这样任何生成重复 Suricata 扫描告警的主机都能被检测到。 - 将目标端口多样性或唯一目标端口计数添加为检测逻辑。 - 测试多种 Nmap 扫描类型，例如 SYN 扫描、版本检测和脚本扫描。 - 审查数据包捕获以获取更深层次的网络级证据。 - 添加一个时间线，将扫描执行与 Suricata 告警及自定义规则触发进行映射。 - 将原始 Suricata 告警与自定义阈值告警进行比较。 ## 截图证据 | 截图 | 展示内容 | |---|---| | `Screenshots/02-nmap-scan-dc-identification.png` | 针对域控制器的 Nmap 扫描结果 | | `Screenshots/03-so-alerts-after-nmap-scan.png` | Security Onion 中与扫描相关的 Suricata 告警 | | `Screenshots/04-so-alert-drilldown-kali-source-ip.png` | 显示 Kali 源 IP 和域控制器目标 IP 的告警下钻 | | `Screenshots/05-kibana-query-kali-suricata-activity.png` | 针对来自 Kali 源 IP 的 Suricata 告警的 Kibana 查询 | | `Screenshots/06-kibana-search-threshold-rule-created.png` | 自定义阈值规则查询和阈值 | | `Screenshots/06b-kibana-rule-metadata-and-schedule.png` | 规则元数据、严重性、计划和标签 | | `Screenshots/07-kibana-custom-rule-visible.png` | 在 Elastic 中已启用并可见的自定义规则 | | `Screenshots/08-targeted-nmap-scan-dc.png` | 针对域控制器的针对性验证扫描 | | `Screenshots/09-custom-rule-fired-history.png` | 验证期间生成告警的自定义规则 | ## 我学到了什么 本项目帮助我培养了以下实用技能： - **检测工程**：创建识别可疑活动的规则 - **网络安全**：理解侦察模式和异常 - **SIEM 运营**：配置和使用安全监控工具 - **事件响应**：调查和验证安全告警 - **实验室构建**：为动手实践创建逼真的训练环境 这种实践经验巩固了理论知识，并提高了我将安全概念转化为可操作的检测逻辑的能力。 ## 仓库信息 **仓库**：[Network-Reconnaissance-Detection-Engineering](https://github.com/Dmokom1/Network-Reconnaissance-Detection-Engineering) **作者**：Dmokom1 **状态**：活跃的学习项目 *此仓库记录了我的动手安全实验室工作。内容反映了我的学习之旅以及对蓝队概念的实际应用。*

标签：AMSI绕过, CTI, Elasticsearch, IDS规则, Metaprompt, Nmap, Security Onion, SOC实验室, Suricata, Windows Server, 域控制器, 威胁检测, 安全实验室, 安全运营, 实时处理, 密码管理, 扫描框架, 插件系统, 攻击模拟, 现代安全运营, 网络安全, 虚拟驱动器, 越狱测试, 阈值告警, 隐私保护, 驱动签名利用