VirtuSec-ITS25/automated-incident-response-lab

# 自动化事件响应实验室 ## 目录 1. [架构](#architecture) 2. [环境与 IP 地址](#environments-and-ip-addresses) 3. [目录结构](#directory-structure) 4. [组件](#components) 5. [前置条件](#prerequisites) 6. [快速开始](#getting-started) 7. [安全措施](#security-measures) 8. [安全分析](#security-analysis) 9. [检测规则](#detection-rules) 10. [验证](#verification) 11. [设计选择与理由](#design-choices-and-justification) 12. [未来改进与重构](#future-improvements-and-refactoring) ## 架构 ## 环境与 IP 地址 | 虚拟机名称 | 角色 | IP 地址 | 端口转发 | 描述 | | :--- | :--- | :--- | :--- | :--- | | `wazuh-manager` | 中央服务器 | `192.168.56.10` | `:443 → 宿主机:8443` | Indexer、Server、Dashboard 和 Ansible 控制节点。 | | `web-agent` | 被监控的系统 | `192.168.56.11` | — | 攻击目标（模拟 Web 服务器）。 | | `db-agent` | 被监控的系统 | `192.168.56.12` | — | 攻击目标（模拟数据库）。 | ## 目录结构 ``` automated-incident-response-lab/ ├── Vagrantfile ├── manager_key.pub ├── .gitignore └── ansible/ ├── ansible.cfg ├── site.yml ├── verify.sh ├── inventory/ │ └── hosts.ini ├── files/ │ └── wordlist.txt ├── playbooks/ │ ├── setup_target.yml │ ├── run_attack.yml │ ├── fim_test.yml │ └── cleanup.yml └── roles/ ├── attack_target/ │ ├── handlers/ │ │ └── main.yml │ └── tasks/ │ └── main.yml ├── attacker/ │ ├── tasks/ │ │ └── main.yml │ └── templates/ │ └── run_attack.sh.j2 └── wazuh_agent/ ├── defaults/ │ └── main.yml ├── handlers/ │ └── main.yml ├── tasks/ │ └── main.yml └── templates/ └── ossec.conf.j2 ``` ## 组件 ### Vagrantfile 在 VirtualBox 的私有网络上定义三台虚拟机。管理器在配置期间生成 ed25519 SSH 密钥对，并通过 `/vagrant` 同步文件夹共享公钥，以便代理节点将其添加到 `authorized_keys` 中。 ### ansible.cfg 最小化配置，禁用实验室环境的主机密钥检查，并设置默认的 inventory 路径。 ### inventory/hosts.ini 将服务器分组为功能单元（`wazuh_manager`、`wazuh_agents`），并使用 Vagrant SSH 密钥定义共享连接变量。 ### site.yml 按三个顺序 play 编排部署： 1. 将代理节点的 SSH 主机密钥扫描到管理器的 `known_hosts` 中 2. 在管理器上下载并运行 Wazuh 一体化安装程序 3. 在所有 `wazuh_agents` 节点上安装并配置 Wazuh 代理角色 ### roles/wazuh_agent 使用官方 apt 仓库安装 Wazuh 代理，并正确对 GPG 密钥进行去封装处理。从 Jinja2 模板部署 `ossec.conf`，启用对 `/etc`、`/bin`、`/sbin`、`/usr/bin`、`/usr/sbin` 的实时 FIM，并监控 `/var/log/auth.log` 中的认证事件。 ### roles/attack_target 创建一个密码较弱的 `testuser` 账户，并启用 SSH 密码认证，以便进行暴力破解模拟。可通过 `cleanup.yml` 完全还原。 ### roles/attacker 部署 Hydra 攻击工具，并从 `run_attack.sh.j2` 生成动态攻击脚本。模板在运行时从 Ansible inventory 中渲染目标 IP。 ### playbooks/setup_target.yml 将 `attack_target` 角色应用到所有 `wazuh_agents`，为模拟做准备。 ### playbooks/run_attack.yml 从管理器对 `web-agent` 运行 Hydra，使用常见密码字典针对 `testuser` 进行 SSH 暴力破解。 ### playbooks/fim_test.yml 在 `db-agent` 的 `/etc` 目录中自动创建、修改和删除测试文件，等待 Wazuh 通过 inotify 检测每次更改，然后验证管理器上是否生成了 FIM 警报。 ### playbooks/cleanup.yml 删除 `testuser`，将 SSH 密码认证恢复为禁用状态，并清除 Wazuh 主动响应添加的任何 iptables DROP 规则。 ### verify.sh 运行 10 项自动化检查，涵盖与两个代理节点的网络连通性、所有三个 Wazuh 服务、两台虚拟机上的代理的服务状态、管理器中的代理注册情况以及警报日志完整性。 ## 前置条件 **软件：** - VirtualBox (7.x+) - Vagrant (2.x+) - Ansible（本地安装或通过控制节点安装） **硬件要求：** - 最低 **16 GB 内存** — 管理器组件栈资源密集。 - **30-40 GB** 可用磁盘空间 — 建议存放在外部存储上（例如 `E:/Lab_Storage`）。 ## 快速开始 1. 克隆仓库 ``` git clone cd automated-incident-response-lab ``` 2. 启动并配置所有虚拟机 ``` vagrant up ``` 3. SSH 进入管理器 ``` vagrant ssh wazuh-manager cd /vagrant/ansible ``` 4. 安装 Wazuh 管理器和代理 ``` ansible-playbook --inventory inventory/hosts.ini site.yml ``` 5. 获取 Wazuh Dashboard 管理员密码 ``` sudo tar -O -xvf /tmp/wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt ``` 6. 准备攻击目标 ``` ansible-playbook --inventory inventory/hosts.ini playbooks/setup_target.yml ``` 7. 运行 SSH 暴力破解攻击 ``` ansible-playbook --inventory inventory/hosts.ini playbooks/run_attack.yml ``` 8. 运行 FIM 测试 ``` ansible-playbook --inventory inventory/hosts.ini playbooks/fim_test.yml ``` 9. 验证环境 ``` bash verify.sh ``` 10. 清理 ``` ansible-playbook --inventory inventory/hosts.ini playbooks/cleanup.yml ``` 11. 销毁虚拟机（从宿主机执行） ``` exit vagrant destroy -f ``` ## 安全措施 | 措施 | 范围 | 状态 | | :--- | :--- | :--- | | SSH 密钥认证 | 所有代理 | ✅ 通过 Vagrantfile 自动化 | | UFW 防火墙 | 所有代理 | ✅ 仅开放 SSH 端口 | | 主动响应 | Wazuh Agent | ✅ 攻击期间自动封锁 IP | | TLS 加密 | Dashboard | ✅ 内部自签名证书 | | 实时 FIM | db-agent | ✅ 基于 inotify，亚秒级检测 | | 集中日志监控 | 所有代理 | ✅ auth.log 由 Wazuh 管理器采集 | ## 安全分析 ### 故意设置的弱点 - **代理上启用了 SSH 密码认证：** `setup_target.yml` 在 `sshd_config` 中启用 `PasswordAuthentication yes`，以便进行暴力破解模拟。这可以通过 `cleanup.yml` 显式还原。在生产环境中，应始终禁用密码认证。 - **testuser 的弱密码：** `testuser` 账户使用 Hydra 字典中包含的密码创建，以确保暴力破解成功命中。这是出于演示目的有意为之。 - **从管理器发起攻击：** Hydra 在 `wazuh-manager` 上使用 `connection: local` 运行。这意味着安全监控节点同时也是攻击节点，这在生产环境中是不可接受的。此处这样做是为了将虚拟机数量控制在三台以内，并保持在内存预算范围内。 ### 仍存在的弱点 - **自签名证书：** Dashboard 使用 TLS 但没有公共 CA，这在实验室环境中是可以接受的，但在生产环境中需要有效的证书。 - **本地日志存储：** 日志存储在管理器本地。生产环境需要异地日志传输，以防止入侵后日志被篡改。 ### 防护层 - **网络分段：** 只有管理器节点暴露 Web 界面；代理节点仅与管理器进行入站通信。 - **自动化：** 零手动干预降低了人为配置错误的风险。 - **可见性：** 集中监控 `/var/log/auth.log` 确保所有登录尝试都被审计——包括失败和成功的——创建识别未授权访问尝试所需的数字痕迹。 ## 检测规则 | 规则 ID | 描述 | 级别 | 触发条件 | | :--- | :--- | :--- | :--- | | 5760 | sshd: 认证失败 | 5 | 每次 SSH 登录失败 | | 5763 | sshd: 暴力破解尝试 | 10 | 同一 IP 多次失败 | | 5758 | 超出最大认证尝试次数 | 8 | SSH 达到最大重试次数 | | 40111 | 多次认证失败 | 10 | 聚合失败 | | 2501 | 用户认证失败 | 5 | PAM 认证失败 | | 2502 | 用户多次输错密码 | 10 | 重复 PAM 失败 | | 550 | 完整性校验和已更改 | 7 | 文件被修改（FIM） | | 553 | 文件已删除 | 7 | 文件被移除（FIM） | | 554 | 文件已添加 | 5 | 文件被创建（FIM） | ## 验证 Wazuh Dashboard 可通过 `https://192.168.56.10` 访问（如果使用端口转发则为 `https://localhost:8443`）。使用部署后在 `wazuh-passwords.txt` 中找到的管理员凭据登录。 要验证实验室是否正常运行，请在管理器内部运行验证脚本： ``` bash verify.sh ``` 预期输出 — 10/10 项检查通过： ``` --- Network Connectivity --- Checking: Connectivity to Agent VM (192.168.56.11) ✅ OK Checking: Connectivity to DB VM (192.168.56.12) ✅ OK --- Local Service Status (Manager) --- Checking: wazuh-manager service is active ✅ OK Checking: wazuh-indexer service is active ✅ OK Checking: wazuh-dashboard service is active ✅ OK --- Remote Agent Status --- Checking: wazuh-agent is active on web-agent ✅ OK Checking: wazuh-agent is active on db-agent ✅ OK Checking: web-agent registered as Active in Manager ✅ OK Checking: db-agent registered as Active in Manager ✅ OK --- Log Integrity --- Checking: Wazuh alert log exists and is not empty ✅ OK Results: 10 passed, 0 failed ``` ## 设计选择与理由 **为什么使用 Wazuh 一体化安装程序而不是自定义角色？** 一体化安装程序处理 Wazuh 管理器、Indexer（OpenSearch）和 Dashboard 之间的相互依赖关系——包括 TLS 证书生成和内部认证。使用自定义 Ansible 角色复制这些功能需要大量额外复杂性。对于实验室环境，官方安装程序是最可靠且经过测试的方法。 **为什么从模板部署 ossec.conf 而不是使用 blockinfile？** 最初的方法使用 `blockinfile` 仅将 `` 块插入安装程序生成的 `ossec.conf` 中。这被替换为完整的 Jinja2 模板，以支持实时 FIM 配置（`realtime="yes"`），这需要修改 `` 块。完整模板可以完全控制代理配置，并且更易于维护。 **为什么使用 shell 任务处理 GPG 密钥而不是 get_url？** `get_url` 以其原始封装格式下载 GPG 密钥，Ubuntu 22.04 的 apt 无法直接与 `signed-by` 一起使用。通过 `gpg --dearmor` 管道下载会产生 `signed-by` 所需的二进制密钥环格式。`creates:` 参数使任务具有幂等性。 **为什么在 cleanup.yml 中硬编码管理器 IP？** `cleanup.yml` 仅针对 `wazuh_agents` 运行，不包含 `wazuh_manager` 作为 play 主机。Ansible 不会为当前 play 之外的主机填充 `hostvars`，因此 `hostvars['wazuh_manager']` 在运行时是未定义的。在固定的实验室网络中使用静态 IP `192.168.56.10` 是正确的解决方案。 **为什么使用基础设施即代码（IaC）？** Vagrant 和 Ansible 允许快速拆除和重新部署整个实验室环境。这通过仅在需要时保持实验室活跃来促进"绿色 IT"方法，并确保环境始终处于已知、可复现的状态。 **为什么选择 EDR（Wazuh）而不是传统 SIEM？** 选择 Wazuh 是因为它能够将日志分析与主动实时响应相结合——包括在超过暴力破解阈值时通过 iptables 自动封锁 IP。传统 SIEM 会检测到攻击但不会自动响应。 ## 未来改进与重构 - **严格的网络基线：** 重构 `roles/attack_target`，为所有传入流量设置全局 UFW `policy: deny`。这需要防火墙规则将 Wazuh 代理的特定端口 `1514` 和 `1515`（TCP/UDP）加入白名单，使日志传输不受干扰且安全。 - **代码模块化：** 为增强可维护性和可扩展性，将 playbook 任务拆分为独立的专用 Ansible 角色。 **创建者：** Karin Ekenberg & Sandra Victorsson **课程：** 虚拟化与自动化 **日期：** 2026-05-18

标签：Ansible, ATT&CK框架, PB级数据处理, SRE, URL发现, Vagrant, VirtualBox, Wazuh, x64dbg, 偏差过滤, 内存分配, 安全事件自动化响应, 安全实战, 安全实验室, 安全工具链, 安全工程, 安全攻防, 安全架构, 安全检测, 安全检测规则, 安全运维, 底层编程, 渗透测试靶机, 系统提示词, 网络攻防, 自动化事件响应实验室, 自动化运维, 配置修复