abdullahshammari796-ctrl/aegis-soc-lab

# Aegis — 威胁检测与响应实验室 ## 目录 - [项目概述](#project-overview) - [实验室架构](#lab-architecture) - [阶段 1 — 基础架构](#phase-1--foundation) - [阶段 2 — SIEM 安装](#phase-2--siem-installation) - [阶段 3 — Agent 部署](#phase-3--agent-deployment) - [阶段 4 — 首次检测：Sudo 暴力破解](#phase-4--first-detection-sudo-brute-force) - [阶段 4.5 — FIM 与持久化检测](#phase-45--fim--persistence-detection) - [阶段 5 — 网络侦察与 SSH 暴力破解](#phase-5--network-reconnaissance--ssh-brute-force) - [阶段 6 — PKI 深度解析](#phase-6--pki-deep-dive) - [阶段 7 — Cowrie 蜜罐](#phase-7--cowrie-honeypot) - [阶段 8 — 使用 Suricata 进行网络 IDS](#phase-8--network-ids-with-suricata) - [阶段 9 — 威胁情报富化](#phase-9--threat-intelligence-enrichment) - [跨阶段经验总结](#cross-phase-lessons-learned) - [MITRE ATT&CK 覆盖范围](#mitre-attck-coverage) - [展示的技能](#skills-demonstrated) - [下一步计划](#whats-next) ## 项目概述 Aegis 是一个完全隔离的安全运营实验室，能够检测、告警并富化真实的攻击——完全在一台 Windows 笔记本电脑上端到端构建。在九个阶段中，我部署了 SIEM，通过 agent 为端点装备了监控，模拟了 MITRE ATT&CK 中的攻击者技术，编写了自定义的 Wazuh 解码器和规则，部署了交互式 SSH 蜜罐，叠加了网络 IDS，最后完成了自动威胁情报富化，将每个网络告警与包含 517 个已知恶意 IP 的情报源进行交叉比对。 最核心的成果是：当攻击者从已知恶意 IP 扫描 SIEM 时，会触发两个告警——Suricata 的签名匹配告警*以及*一个 12 级富化告警，告诉分析师“我们已有关于此来源的情报”。这就是真实 SOC 中噪声与信号的差别。 每个阶段都引入了新的检测能力或加固步骤。它们相互依赖：阶段 1-3 建立平台，阶段 4 和 4.5 证明其对攻击者技术有效，阶段 5 增加了侦察模拟，阶段 6 通过适当的 PKI 证书链强化了仪表板，阶段 7 增加了交互式欺骗层，阶段 8 通过 Suricata 增加了三层可见性，阶段 9 则以威胁情报富化为整个技术栈加冕。 ## 实验室架构 ``` graph LR subgraph "LabNet — 192.168.56.0/24 (Host-only)" subgraph "Kali Linux — 192.168.56.101" KaliOS[Kali 2026.1] Cowrie[Cowrie Honeypot
port 2222] Agent[Wazuh Agent 001] KaliOS --> Cowrie KaliOS --> Agent end subgraph "Aegis-SIEM — 192.168.56.102" Suricata[Suricata 7.0.3
50,180 ETOpen rules] Wazuh[Wazuh 4.14.5
Manager + Indexer + Dashboard] CDB[(Threat Intel CDB
517 IPs)] PKI[2-tier PKI
Root + Intermediate CA] Suricata -->|eve.json| Wazuh CDB -->|enrichment| Wazuh PKI -->|HTTPS| Wazuh end Agent -->|encrypted| Wazuh end Attacker[Attacker traffic] --> Kali Attacker --> Suricata ``` | 组件 | 详情 | |---|---| | 宿主机 OS | Windows, 16 GB RAM | | Hypervisor | Oracle VirtualBox | | 实验室网络 | Host-only `LabNet` — 192.168.56.0/24，无互联网桥接 | | SIEM 虚拟机 | Ubuntu Server 24.04 — 4 GB RAM, 60 GB 磁盘 | | 端点虚拟机 | Kali Linux 2026.1 — 4 GB RAM, 40 GB 磁盘 | | SIEM Stack | Wazuh 4.14.5 (manager + indexer + dashboard，all-in-one) | | IDS | Suricata 7.0.3 运行于 `enp0s8`，HOME_NET=`192.168.56.102/32` | | 蜜罐 | Cowrie SSH 蜜罐运行于 TCP/2222 (systemd) | | 规则集 | ETOpen 50,180 条规则 + 7 条自定义 Wazuh 规则 (100200–100205, 100300) | | 威胁情报 | Emerging Threats Compromised IPs — 517 条记录的 CDB 列表 | | PKI | 2 层架构 (Root CA → Intermediate CA → Server cert)，使用 OpenSSL | ## 阶段 1 — 基础架构 ### 目标 建立一个完全隔离的实验室环境，其中包含两台可以相互通信但无法访问公共互联网的虚拟机。隔离是这里最重要的属性——本实验室中的每一次攻击都允许是声势浩大、具有破坏性且显而易见的，因为没有任何东西会离开宿主机。 ### 实现 选择 Oracle VirtualBox 作为 hypervisor，因为它在 Windows 上免费可用，并且具有直观的 host-only 网络。配置了两台虚拟机： - **Aegis-SIEM** — Ubuntu Server 24.04，4 GB RAM，60 GB 磁盘，两块网卡（一块 NAT 用于构建期间的初始软件包下载，一块 host-only 用于实验室流量） - **Kali-Lab** — Kali Linux 2026.1，4 GB RAM，40 GB 磁盘，相同的双网卡设置 Host-only 网络 `LabNet` 被配置为 `192.168.56.0/24`，并禁用了 DHCP。两台虚拟机都分配了静态 IP（`192.168.56.101` 用于 Kali，`192.168.56.102` 用于 SIEM），并在 Ubuntu 的 `/etc/netplan/` 和 Kali 的 `/etc/network/interfaces.d/` 中进行了配置。在初始软件包安装完成后，每台虚拟机上的 NAT 网卡都被禁用以强制隔离。 ### 验证 ``` # 来自 Kali ping -c 2 192.168.56.102 # Should succeed ping -c 2 8.8.8.8 # Should fail (isolation working) ``` ### 结果 两台可达的、相互隔离的虚拟机构成了后续所有工作的基础。该实验室是一个密封的环境——攻击者流量、IDS 签名和 SIEM 遥测数据都保留在内部。 ## 阶段 2 — SIEM 安装 ### 目标 在 `Aegis-SIEM` 上部署一个 SIEM 平台，能够从多个来源摄取端点日志、网络告警和文件完整性事件，并提供用于事件响应的可查询仪表板。 ### 实现 Wazuh 4.14.5 使用官方的 all-in-one 安装程序进行部署，该程序将 manager、indexer（OpenSearch 分支）和 dashboard 捆绑在单个主机上。选择 all-in-one 方法是因为它反映了小型组织实际部署 Wazuh 的方式——分离的主机拓扑增加了操作复杂性，这对于学习实验室来说没有意义。 ``` # 下载并运行 all-in-one installer curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh sudo bash ./wazuh-install.sh -a ``` 安装程序生成了初始凭据，并引导生成了组件间 TLS 所需的证书。仪表板在端口 443 上的 `https://192.168.56.102` 处启动。 ### 验证 ``` # 检查所有三个服务是否正在运行 sudo systemctl status wazuh-manager wazuh-indexer wazuh-dashboard ``` 这三个服务都返回了 `active (running)`。登录仪表板并导航到 Management 部分，显示 manager 状态健康，且 indexer 可达。 ### 结果 一个功能齐全的 SIEM，准备好接收来自 agent 的遥测数据。仪表板的自签名证书将在阶段 6 中被适当的 PKI 证书链替换。 ## 阶段 3 — Agent 部署 ### 目标 将 Kali 端点注册为 Wazuh manager 的受管 agent，以便端点日志、系统事件和命令行活动实时流入 SIEM。 ### 实现 在 SIEM 上，通过仪表板的 agent 管理界面注册了一个新 agent。仪表板生成了一个注册命令，其中包含 manager 的 IP 和注册密钥。 在 Kali 上，安装了 Wazuh agent 软件包并将其指向 manager： ``` curl -so wazuh-agent.deb \ https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.14.5-1_amd64.deb sudo WAZUH_MANAGER='192.168.56.102' WAZUH_AGENT_NAME='Kali-Lab' \ dpkg -i ./wazuh-agent.deb sudo systemctl enable wazuh-agent --now ``` 该 agent 在仪表板中显示为 `Kali-Lab`，ID 为 `001`，状态为 `Active`。默认的 agent 配置摄取了 `/var/log/auth.log`、`/var/log/syslog` 和其他几个标准 Linux 日志源。 ### 验证 在 Kali 上触发了一个测试事件（使用故意输入错误的密码执行 `sudo whoami`），相应的告警在几秒钟内出现在仪表板的 Security Events 视图中。 ### 结果 遥测管道已投入运行。实验室现在可以监控 Kali 上的端点活动。接下来的一切——sudo 暴力破解检测、FIM、蜜罐集成——都依赖于这个管道的正常工作。 ## 阶段 4 — 首次检测：Sudo 暴力破解 ### 目标 验证 SIEM 是否能端到端检测真实的攻击者技术：从端点上的操作，到 agent 的日志捕获，再到 manager 的告警生成，最后到仪表板中的可视化。 ### 实现 选择的攻击者技术是 sudo 暴力破解尝试——以低权限用户身份重复执行失败的 `sudo` 调用以尝试提权。这对应于 **MITRE T1548.003 — Abuse Elevation Control Mechanism: Sudo and Sudo Caching**。 Wazuh 默认规则集包含对重复身份验证失败的检测，但特定于 sudo 的规则是标准 `pam_rules.xml` 规则集的一部分，该规则集会在 `/var/log/auth.log` 中的多个失败 `sudo` 事件时触发。 ### 攻击模拟 在 Kali 上，以非 root 用户身份： ``` for i in {1..8}; do echo "wrongpassword$i" | sudo -S whoami 2>/dev/null done ``` ### 检测 在攻击发生后的几秒钟内，Wazuh 仪表板显示了多个 `rule.level >= 5` 的告警，当超过失败阈值时，升级为相关的高严重性告警。触发的规则是 Wazuh 的默认规则 `5403`（多次 sudo 失败），MITRE ID 显示在告警元数据中。 ### 结果 首次确认的端到端检测。平台运作正常。这个阶段虽小但至关重要——后续的每个阶段都假设此管道是可靠的。 | 字段 | 值 | |---|---| | 技术 | T1548.003 | | Wazuh 规则 | 5403（多次 sudo 失败） | | 日志源 | `/var/log/auth.log` | ## 阶段 4.5 — FIM 与持久化检测 ### 目标 使用 Wazuh 的文件完整性监控 (FIM) 模块检测攻击者持久化——具体来说，是创建后门用户账户。 ### 实现 FIM 已在默认 agent 配置中启用，并具有默认的扫描间隔。检查了 agent 的 `ossec.conf`，确认 `/etc/passwd` 和 `/etc/shadow` 处于 FIM 监控之下： ``` /etc ``` 实时监控意味着对 `/etc` 下文件的更改将在几秒钟内被检测到，而不是等待下一次定期扫描。 ### 攻击模拟 在 Kali 上，模拟攻击者持久化： ``` sudo useradd -m -s /bin/bash backdoor_user sudo passwd backdoor_user # set a known password ``` ### 检测 仪表板几乎立即浮现了两个 FIM 告警：一个是 `/etc/passwd` 的修改（添加了新行），另一个是 `/etc/shadow` 的修改（添加了新的哈希密码条目）。每个告警都显示了前后的差异以及 SHA256 哈希值变化。 这对应于 **MITRE T1565.001 — Stored Data Manipulation**，该技术系列涵盖了对手对存储数据的修改，包括 `/etc/passwd` 等系统文件。 ### 结果 FIM 作为第二道检测防线起作用——即使攻击者禁用了 shell 日志记录或擦除了 `auth.log`，FIM 模块也能捕获文件修改。这是深度防御原则的实际应用：为相同的攻击者目标设置多个独立的检测层。 | 字段 | 值 | |---|---| | 技术 | T1565.001 | | Wazuh 规则 | 550（FIM 文件已修改）, 554（FIM 文件已添加） | | 日志源 | FIM 实时 syscheck | ## 阶段 5 — 网络侦察与 SSH 暴力破解 ### 目标 检测源自非端点内部的网络级攻击者活动——端口扫描和凭据暴力破解。 ### 实现 从 Kali 对 SIEM 主机模拟了两个攻击向量。第一个是 nmap 端口扫描；第二个是使用 `hydra` 对 SIEM 的 SSH 服务进行 SSH 暴力破解。 对于 nmap 检测，Wazuh 的默认规则集包含 `5712`（"SSHD: ATTACK Possible attack on the ssh server (or version gathering)"）以及相关规则，这些规则会在 `/var/log/auth.log` 和 SSH 守护进程日志中出现的扫描活动特征时触发。 对于 SSH 暴力破解，Wazuh 的 `5712` 和更高严重性的 `5720`（来自同一来源的多次 SSH 身份验证失败）提供了关联逻辑。 ### 攻击模拟 ``` # Reconnaissance sudo nmap -sS -sV -p 1-1000 192.168.56.102 # 使用小型 wordlist 进行 SSH brute-force hydra -l aegis -P /usr/share/wordlists/rockyou-small.txt \ ssh://192.168.56.102 -t 4 -V ``` ### 检测 nmap 扫描在 SSH 连接尝试探测服务时产生了多个 `5712` 告警。hydra 的运行产生了一连串 `5710` 告警（sshd 身份验证失败），当超过单个源 IP 的失败阈值时，最终触发了级别为 10 的规则 `5720`。 暴力破解活动对应于 **MITRE T1110 — Brute Force**，而网络发现活动对应于 **T1046 — Network Service Discovery**。 ### 结果 现在，即使在攻击者的机器上没有安装 agent，网络级攻击也会生成告警。这很重要，因为并非每个对手都会配合地安装你的 agent——大多数网络检测必须在 SIEM 的有利位置或通过网络传感器将在阶段 8 中添加）进行。 | 字段 | 值 | |---|---| | 技术 | T1110, T1046 | | Wazuh 规则 | 5710, 5712, 5720 | | 日志源 | `/var/log/auth.log` | ## 阶段 6 — PKI 深度解析 ### 目标 用适当的两层 PKI 证书链替换 Wazuh 仪表板默认的自签名证书，使仪表板能够在浏览器中无警告地加载——显示绿色的挂锁——并使实验室展示真实的证书操作，而不是教程中的捷径。 ### 实现 使用 OpenSSL 构建了两层证书授权机构： 1. **Root CA** — 寿命长（10 年），概念上保持离线（使用密码加密，绝不直接用于签发） 2. **Intermediate CA** — 寿命较短，由 Root CA 签名，用于签发终端实体证书 3. **Server 证书** — 由 Intermediate CA 签名，带有涵盖 IP `192.168.56.102` 和主机名 `aegis-siem` 及 `aegis-siem.lab` 的使用者可选名称 (SAN) 扩展 完整的目录结构位于 `~/aegis-pki/` 中，并为 `root-ca/`、`intermediate-ca/` 和 `certs/` 设置了单独的子目录。CA 私钥使用强密码（已隐去）进行 AES-256 加密——出于显而易见的原因，没有保存在代码库中。 服务器证书的关键 OpenSSL 配置摘录： ``` [ server_cert ] basicConstraints = CA:FALSE keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth subjectAltName = @alt_names [ alt_names ] DNS.1 = aegis-siem DNS.2 = aegis-siem.lab DNS.3 = localhost IP.1 = 192.168.56.102 IP.2 = 127.0.0.1 ``` 一旦服务器证书签发完毕，它就被部署到 Wazuh 仪表板的证书路径中，连同完整的证书链（服务器 + 中间证书）一起，并重启了仪表板服务。 然后，将 Root CA 导入到 Windows 宿主机上 Edge 的受信任根证书存储中，从而完成了信任链。 ### 验证 在 Edge 中加载 `https://192.168.56.102` 时，出现了绿色的挂锁，没有任何警告。证书查看器显示了完整的三层链：Aegis Lab Root CA → Aegis Lab Intermediate CA → aegis-siem 证书。 ### 结果 一个贴近生产环境的 PKI。真实的组织几乎从不用自签名证书部署 SIEM——它们会与内部 CA 集成。这个阶段以微缩的形式展示了相同的操作，并关注 SAN 配置（这是实际部署中导致“此站点不安全”警告的最常见原因）。 ## 阶段 7 — Cowrie 蜜罐 ### 目标 部署一个交互式的 SSH 蜜罐，允许攻击者使用弱凭据“登录”，捕获他们输入的每个命令，并以高严重性告警的形式向 Wazuh 提取结构化的会话遥测数据。 ### 实现 Cowrie 作为 Python 应用程序安装在 Kali 上，以专用的非特权用户身份运行，暴露在端口 `2222` 上（因为真正的 SSH 服务仍然在 `22` 上监听）。编写了一个 systemd 单元来管理该服务： ``` [Unit] Description=Cowrie SSH Honeypot After=network.target [Service] Type=simple User=cowrie WorkingDirectory=/opt/cowrie ExecStart=/opt/cowrie/bin/cowrie start -n ExecStop=/opt/cowrie/bin/cowrie stop Restart=on-failure [Install] WantedBy=multi-user.target ``` Cowrie 被配置为将 JSON 日志输出到 `/opt/cowrie/var/log/cowrie/cowrie.json`。Kali 上的 Wazuh agent 被扩展，将此文件作为 `json` 日志源读取。 自定义检测规则在 `/var/ossec/etc/rules/cowrie_rules.xml` 中编写，涵盖了六种不同的蜜罐事件： | 规则 ID | 事件 | 等级 | MITRE | |---|---|---|---| | 100200 | Cowrie 会话已连接 | 5 | T1078 | | 100201 | Cowrie 登录失败 | 7 | T1110 | | 100202 | Cowrie 登录成功（低难度凭据） | 10 | T1078 | | 100203 | Cowrie 会话内执行了命令 | 10 | T1059 | | 100204 | 攻击者通过 Cowrie 下载了文件 | 12 | T1105 | | 100205 | Cowrie 会话已断开 | 3 | — | 编写过程中的一个常见陷阱：描述变量 `$(username)` 只有在解码器提取确切名称的字段时才能正确解析。为了使解码器、规则字段引用和 JSON 路径全部对齐，需要进行多次迭代。 ### 验证 从另一台机器使用 `ssh root@192.168.56.101 -p 2222` 和密码 `123456` 进行测试登录，产生了一连串告警——级别为 5 的连接、级别为 7 的失败尝试、最终级别为 10 的“成功”（Cowrie 设计上会接受某些弱凭据，以吸引攻击者继续操作），以及在伪造的 shell 中输入的每个命令产生的级别为 10 的命令告警。 ### 结果 一个主动的欺骗层。Cowrie 通过自定义的 MITRE 映射检测，将攻击者困住，并将丰富的会话遥测数据——每一个命令、每一次下载尝试、尝试过的每一对凭据——馈送到 Wazuh 中。 ## 阶段 8 — 使用 Suricata 进行网络 IDS ### 目标 通过在 SIEM 主机上部署 Suricata 作为网络 IDS，为实验室增加第三层可见性，启用完整的 ETOpen 规则集并将告警转发给 Wazuh。 ### 实现 Suricata 7.0.3 安装在 `Aegis-SIEM` 上，并绑定到 host-only 接口 `enp0s8`。`suricata.yaml` 中的 `HOME_NET` 变量被设置为 `192.168.56.102/32`——即 SIEM 本身——这样“入站”告警就表示发往 SIEM 的流量，而不是穿过它的流量。（这是一个常见的混淆点：HOME_NET 定义了什么算作你正在防御的网络*内部*。） 下载并启用了完整的 ETOpen 规则集——50,180 条签名，涵盖了从端口扫描到已知 C2 流量模式再到特定 CVE 漏洞利用尝试的所有内容。该规则集使用 `suricata-update` 进行了更新。 Suricata 的 `eve.json` 输出（结构化的 JSON 事件日志）被写入到 `/var/log/suricata/eve.json`。Wazuh manager 被配置为将此文件作为 `json` 日志源读取。 Wazuh 内置了规则 `86601`（"Suricata: Alert"），该规则解析来自 `eve.json` 的 Suricata 事件并创建相应的 Wazuh 告警。基础集成不需要自定义规则——但阶段 9 将在此基础上进行构建。 ``` json /var/log/suricata/eve.json ``` ### 验证 来自 Kali 的 nmap 扫描（`sudo nmap -sS -A 192.168.56.102`）触发了多个 Suricata 签名，所有这些都在几秒钟内以 `86601` 告警的形式出现在 Wazuh 中。触发的签名包括 `ET SCAN Suspicious inbound to MSSQL port 1433`、`ET INFO Possible Kali Linux hostname in DHCP Request Packet` 以及各种扫描检测规则。 ### 结果 添加了三层可见性。实验室现在可以在数据包级别查看攻击，而不仅仅是从端点日志查看。FIM（阶段 4.5）+ 端点日志（阶段 3-5）+ 蜜罐遥测（阶段 7）+ 网络 IDS（阶段 8）的组合提供了真正的深度防御。 | 字段 | 值 | |---|---| | 技术 | T1046, T1190 | | Wazuh 规则 | 86601 (Suricata: Alert) | | Suricata 接口 | `enp0s8` | | 规则集大小 | 50,180 条 ETOpen 规则 | ## 阶段 9 — 威胁情报富化 ### 目标 将每个 Suricata 告警与精选的已知恶意 IP 源进行实时交叉比对，并在找到匹配项时触发单独的高严重性告警。这就是*可疑流量*与*已知恶意行为者*之间的区别——这正是 SOC 分析师实际需要的优先级划分。 ### 实现 利用 Emerging Threats Compromised IPs 源构建了一个 Wazuh CDB 列表（Constant Database，用于规则内的快速键值查找）： ``` sudo curl -o /tmp/compromised-ips.txt \ https://rules.emergingthreats.net/blockrules/compromised-ips.txt # 格式化为 Wazuh CDB list：每行 "IP:label" sudo awk 'NF && !/^#/ {print $0":ET_COMPROMISED"}' /tmp/compromised-ips.txt \ | sudo tee /var/ossec/etc/lists/threat_intel_ips > /dev/null # 添加 lab test 条目以进行 end-to-end validation echo "192.168.56.101:LAB_TEST_KALI" \ | sudo tee -a /var/ossec/etc/lists/threat_intel_ips > /dev/null ``` 最终列表：517 个条目（516 个来自 ET + 1 个实验室测试）。 CDB 列表在 `ossec.conf` 中被引用： ``` etc/lists/threat_intel_ips ``` Wazuh 4.x 在 manager 重启时自动编译 CDB 列表——不需要单独的 `makelists` 步骤（较旧的指南提到了这一点；该二进制文件在 4.x 中不存在）。 级联规则在 `/var/ossec/etc/rules/threat_intel_rules.xml` 中编写： ``` 86601 etc/lists/threat_intel_ips THREAT INTEL HIT: Suricata alert from known malicious IP $(src_ip) - cross-reference matched T1595 threat_intel,attack, ``` 起作用的三个方面：`86601` 仅将此规则作为 Wazuh Suricata 规则的子项触发；`` 将 JSON `src_ip` 字段作为键在 CDB 中查找；`level="12"` 将告警置于任何优先级队列的顶部。 ### 验证 — 合成注入 在运行真实流量之前，通过注入一个伪造的 Suricata 事件来验证规则逻辑： ``` sudo bash -c 'echo "{\"timestamp\":\"2026-05-25T11:35:00.000+0000\",\"flow_id\":2,\"src_ip\":\"192.168.56.101\",\"src_port\":22222,\"dest_ip\":\"192.168.56.102\",\"dest_port\":22,\"proto\":\"TCP\",\"event_type\":\"alert\",\"alert\":{\"signature\":\"TEST INJECTION FROM KALI\",\"signature_id\":99999,\"severity\":2}}" >> /var/log/suricata/eve.json' ``` `alerts.json` 中的预期输出： ``` L12: THREAT INTEL HIT: Suricata alert from known malicious IP 192.168.56.101 - cross-reference matched ``` ✅ 在将规则暴露给真实流量之前确认了逻辑。 ### 验证 — 实时攻击 从 Kali 发起了真实的 nmap 扫描： ``` sudo nmap -sS -sV -A -p 1-1000 192.168.56.102 ``` 在扫描窗口内，`alerts.json` 中生成了六个规则 `100300` 告警，其中四个落在仪表板的 15 分钟视图内。触发级联的 Suricata 签名包括： ``` ET SCAN Suspicious inbound to MSSQL port 1433 ET INFO Possible Kali Linux hostname in DHCP Request Packet (x2) SURICATA ICMPv4 unknown code ``` `ET INFO Possible Kali Linux hostname in DHCP Request Packet` 签名尤其能说明问题：Suricata 仅凭单个 DHCP 请求包就通过名称识别出了攻击者的操作系统。攻击者自己的机器宣告了它的身份。 并非所有的 Suricata 告警都级联到了规则 `100300` 中，这是正确的行为：某些签名（ICMPv4 异常、某些 DHCP 检测）不会在标准字段中填充 `src_ip`，因此它们会触发 `86601`，但无法根据源 IP 信誉列表进行富化。 ### 结果 对于 SOC 分析师来说，其价值在于优先级划分。仅凭阶段 8，每个 Suricata 告警都需要进行分类。有了阶段 9，告警可以清晰地分为两个级别： - 级别 3–7（默认 Suricata）——来自未知源的机会性活动。在时间允许时进行分类。 - 级别 12（已富化）——来自我们已有情报的源的活动。*立即查看。* 相同的模式（CDB 列表 + 带有 `` 查找的子规则）可以自然地扩展到为 Cowrie 蜜罐告警（阶段 7）、暴力破解事件（阶段 5）或任何其他由 Wazuh 解析的源叠加信誉机制。 | 字段 | 值 | |---|---| | 技术 | T1595 (Active Scanning) | | 自定义规则 | 100300 (Level 12) | | 父规则 | 86601 (Suricata: Alert) | | 威胁情报源 | Emerging Threats Compromised IPs（517 个条目） | ## 跨阶段经验总结 在此项目期间耗费了大量时间的事项汇总列表——这种细节正是区分仅仅照抄教程的人与真正构建和调试过系统的人的关键。 **Wazuh 4.x 改变了 CDB 列表的处理方式。** 较旧的指南提到使用 `/var/ossec/bin/ossec-makelists` 将文本源编译为二进制 `.cdb` 文件。该二进制文件在 4.x 中已不存在——manager 会在重启时自动编译。不要再去寻找它了。 **JSON 字段命名在规则定义中至关重要。** 引用 Suricata 事件的自定义规则必须使用 `src_ip`（带下划线，与 JSON 路径匹配），而不是 `srcip`（较旧的 Wazuh 解码器约定）。使用错误的名称会默默失败——规则可以编译，父项会触发，而子项永远不会匹配。这也适用于描述变量中的 `$(src_ip)`。 **威胁情报源的形状比其质量更重要。** Wazuh CDB 列表仅匹配确切的 IP——而不匹配 CIDR 范围。FireHOL Level 1 主要包含范围，因此无法使用。Emerging Threats Compromised IPs 是单个 IP 条目，这是正确的形状。请选择与您工具的查找语义相匹配的情报源，而不仅仅基于其声誉。 **区域 ISP 屏蔽会影响情报源的选择。** 由于 SSL 握手屏蔽，从 UAE 无法访问 `torproject.org`。切换到 `emergingthreats.net` 解决了连接问题。如果您在具有内容过滤的地区构建实验室，这一点值得注意。 **PKI 主机名绑定非常脆弱。** 浏览器信任的仪表板要求证书的 SAN 与访问 URL 的方式完全匹配——IP 与主机名与 FQDN 都有影响。在实际部署中，大多数“此站点不安全”警告正是由这种不匹配造成的。 **Suricata HOME_NET 定义了什么算作“内部”。** 如果设置错误，要么所有东西看起来都像攻击，要么什么都不像。对于监控自身入站流量的单主机实验室传感器，`HOME_NET=/32` 是正确的设置。 **在实时攻击之前进行合成注入。** 每个自定义规则都是通过在生成真实流量*之前*将精心构造的事件注入日志文件中来验证的。这可以将规则逻辑错误与数据源错误分离开来——这是一种至关重要的调试原则，可扩展到现实世界的检测工程中。 **解码器/规则/JSON 三角测量。** 当自定义规则不触发时，错误存在于以下三个地方之一：解码器提取了错误的字段、规则引用了错误的字段名称，或者 JSON 源根本不包含该字段。在断定规则逻辑错误之前，请务必检查这三个方面。 ## MITRE ATT&CK 覆盖范围 | 战术 | 技术 | ID | 检测机制 | |---|---|---|---| | 权限提升 | Sudo and Sudo Caching | T1548.003 | Wazuh 规则 5403 (阶段 4) | | 防御规避 / 影响 | Stored Data Manipulation | T1565.001 | FIM 实时 syscheck (阶段 4.5) | | 凭据访问 | Brute Force | T1110 | Wazuh 规则 5710, 5720; Cowrie 规则 100201 | | 发现 | Network Service Discovery | T1046 | Wazuh 规则 5712; Suricata ET SCAN 签名 | | 初始访问 | Exploit Public-Facing Application | T1190 | Suricata ETOpen exploit 签名 (阶段 8) | | 初始访问 / 防御规避 | Valid Accounts | T1078 | Cowrie 规则 100200, 100202 | | 执行 | Command and Scripting Interpreter | T1059 | Cowrie 规则 100203（蜜罐会话中的命令） | | 命令与控制 | Ingress Tool Transfer | T1105 | Cowrie 规则 100204（蜜罐中的文件下载） | | 侦察 | Active Scanning | T1595 | 自定义规则 100300 (阶段 9) | ## 展示的技能 **检测工程。** 在两个不同的系列（用于 Cowrie 会话事件的规则 100200–100205；用于威胁情报富化的规则 100300）中编写了自定义的 Wazuh 规则。构建和集成 CDB 列表以进行实时信誉查找。针对解析第三方 JSON 输出（Cowrie、Suricata）的解码器设计。通过 `` 和 `` 进行规则链接。在规则级别映射 MITRE ATT&CK。 **工具应用。** Wazuh 完整技术栈（manager、indexer、dashboard、agents）——安装、加固、自定义规则部署、FIM 配置。Suricata 7.0.3——接口绑定、ETOpen 规则集管理、eve.json 输出、SIEM 集成。Cowrie SSH 蜜罐——安装、systemd 服务编写、JSON 日志配置。 **密码学与 PKI。** 使用 OpenSSL 的两层证书授权机构 (Root CA + Intermediate CA)。使用者可选名称、密钥用法和扩展密钥用法扩展、证书链验证。带有完整证书链并安装在浏览器信任存储中的可信仪表板 HTTPS。 **Linux 与基础设施。** Ubuntu Server 24.04 管理。systemd 服务编写和依赖项管理。通过 netplan 进行网络配置。跨文件权限、JSON 路径不匹配和 decoder 字段命名的日志管道故障排除。 **对手模拟。** Sudo 暴力破解 (T1548.003)、后门用户创建 (T1565.001)、使用版本检测和 OS 指纹识别的 nmap 侦察、使用 hydra 进行 SSH 凭据暴力破解 (T1110)。 ## 下一步计划 如果实验室继续扩展，可能的扩展方向： - **Windows 端点。** 添加一个将 Sysmon 日志转发到 Wazuh 的 Windows 11 受害者虚拟机。大多数企业环境以 Windows 为主，其规则逻辑与 Linux 有很大不同。 - **用于取证。** 在 Wazuh 之上叠加 Velociraptor 作为端点取证工具。Wazuh 负责检测；Velociraptor 负责调查。 - **主动响应自动化。** 将 Wazuh 的主动响应框架接入 iptables，以便级别 12 的告警（例如规则 100300）自动在可配置的持续时间内屏蔽违规 IP。这是实验室迈向 SOAR 风格自动化的路径。 - **用于托管威胁情报。** 用 MISP 替换单源 CDB 列表，支持多个情报源、分类法和 IOC 共享。CDB 模式保留，但源变为可插拔的。 - **检测即代码。** 使用 CI 测试框架对每个自定义 Wazuh 规则进行版本控制——为每个规则设置合成事件，并对预期触发的告警进行自动断言。这将临时的规则编写转化为可持续的工程实践。 *Aegis 是一个历时数月独立构建的学习项目。上述每一项检测都经过了模拟攻击的测试，并在仪表板中得到了验证。*

标签：Metaprompt, Wazuh, x64dbg, 威胁情报, 安全测试工具, 安全运营, 开发者工具, 扫描框架, 插件系统, 蜜罐, 证书利用