AndreiR19/home-soc-lab

# 家庭 SOC 实验室 — Kali + Wazuh SIEM + Ubuntu 受害机 这是一个自建的安全运营中心 (SOC) 实验室，旨在练习蓝队的检测工作流：通过 Kali Linux 对受监控的 Ubuntu Server 目标发起模拟攻击，并利用 Wazuh（开源 SIEM/XDR）对这些活动进行收集、关联和告警。 本项目作为个人从软件开发转向蓝队 / SOC Analyst 岗位的过渡路径的一部分而构建，旨在展示在 SIEM 部署、基于主机的检测和网络故障排除方面的实际动手经验——不仅是跟随教程操作，还包括在此过程中调试真实的基础设施问题。 ## 架构 三台虚拟机隔离在一个专用的内部网络上，各自扮演着不同的 SOC 角色： | 角色 | 机器 | 操作系统 | 功能 | |---|---|---|---| | **红队 (攻击者)** | Kali Linux | Kali rolling | 生成模拟攻击（端口扫描、暴力破解） | | **目标 (受害机)** | Ubuntu Server | 22.04.5 LTS | 受监控的端点，运行 Wazuh Agent | | **SIEM (蓝队控制台)** | Ubuntu Server | 22.04.5 LTS | 运行 Wazuh Manager + Indexer + Dashboard | ### 网络拓扑 每台 VM 都有**两个网络适配器**： - **Adapter 1 — NAT**: 仅用于互联网访问（软件包更新、下载） - **Adapter 2 — Host-Only (`vboxnet0`, `192.168.56.0/24`)**: 用于所有 VM 间通信和监控流量的隔离实验网络 | 机器 | Host-Only IP | |---|---| | Kali | 192.168.56.10 | | Ubuntu 受害机 | 192.168.56.104 | | Wazuh Server | 192.168.56.105 | 这反映了一种常见的现实模式：将管理/面向互联网的接口与隔离的监控网段分离开来。 ## 技术栈 - **Hypervisor**: Oracle VirtualBox - **SIEM**: Wazuh 4.14.7（Indexer + Manager + Dashboard，单节点“all-in-one”安装） - **攻击者工具包**: Kali Linux (`nmap`, `hydra`) - **目标加固基线**: `ufw`（防火墙 + 日志记录） ## 设置摘要 1. 在 VirtualBox 中配置了 3 台 VM，每台都具有双 NIC（NAT + Host-Only）。 2. 在受害机和 Wazuh-server VM 上安装了 Ubuntu Server 22.04.5 LTS。 3. 为三台机器在 Host-Only 网络上分配了静态 IP。 4. 使用官方的一体化安装程序在 SIEM VM 上安装了 Wazuh（Indexer、Manager、Dashboard、Filebeat）： curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh sudo bash ./wazuh-install.sh -a 5. 在受害机 VM 上安装了 Wazuh Agent，并将其指向 Manager 的 Host-Only IP： curl -o wazuh-agent.deb https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.14.7-1_amd64.deb sudo WAZUH_MANAGER='192.168.56.105' dpkg -i ./wazuh-agent.deb sudo systemctl enable --now wazuh-agent 6. 在 Wazuh Dashboard（**Agents** 视图）中验证了 agent 的注册。 7. 从 Kali 对受害机发起了受控攻击并验证了检测。 ## 调试之旅 这是最重要的部分——真实的基础设施工作主要是故障排除。以下是在设置过程中遇到的实际问题、诊断方法以及修复方式。 ### 1. Wazuh dashboard 安装失败 — 磁盘空间 **症状**: 安装脚本成功完成了 Indexer 和 Manager，但在 Dashboard 步骤失败，并自动回滚了整个安装。 **诊断**: 检查 `/var/log/wazuh-install.log`，发现： ``` E: You don't have enough free space in /var/cache/apt/archives/. E: Write error - write (28: No space left on device) ``` `df -h` 确认 LVM root 卷只有 12GB —— Ubuntu 引导式安装程序在分配逻辑卷时相对于虚拟磁盘分配不足。 **修复**: 从宿主机调整了 VDI 大小（`VBoxManage modifyhd ... --resize 51200`），然后在客户机内部实时扩展了 LVM 栈： ``` sudo growpart /dev/sda 3 sudo pvresize /dev/sda3 sudo lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv ``` ### 2. 第二次安装尝试失败 — 残留状态损坏 **症状**: 磁盘大小调整后，第二次安装尝试走得更远（Indexer 成功了），但 Manager 未能启动： ``` ./wazuh-install.sh: line 3350: /var/ossec/bin/wazuh-keystore: No such file or directory WARNING: The Wazuh manager package could not be removed. ``` **诊断**: 第一次（磁盘空间）失败的自动回滚导致 `/var/ossec` 和相关目录处于不一致的状态，从而破坏了第二次安装。 **修复**: 在重新安装之前，手动清除了所有 Wazuh 组件和目录： ``` sudo systemctl stop wazuh-manager wazuh-indexer filebeat wazuh-dashboard sudo apt-get remove --purge -y wazuh-manager wazuh-indexer wazuh-dashboard filebeat sudo rm -rf /var/ossec /etc/filebeat /usr/share/filebeat \ /var/lib/wazuh-indexer /etc/wazuh-indexer /usr/share/wazuh-indexer \ /var/lib/wazuh-dashboard /etc/wazuh-dashboard /usr/share/wazuh-dashboard sudo systemctl daemon-reload ``` 在重新安装之前，通过 `dpkg -l | grep wazuh` 验证了状态是干净的。第三次尝试端到端成功。 ### 3. 安装后立即从浏览器无法访问 Dashboard **症状**: `https://` 在安装后立即返回连接错误。 **诊断**: `sudo ss -tlnp | grep 443` 显示没有程序在监听 —— 但这项检查运行得太早了。`sudo journalctl -u wazuh-dashboard` 显示服务仍在初始化（OpenSearch Dashboards 启动缓慢，在 `systemctl start` 后大约需要 30–60 秒），并最终记录了： ``` "message":"Server running at https://0.0.0.0:443" ``` **修复**: 不需要修复 —— 只需等待服务完成初始化，然后通过浏览器的强制刷新重试即可。 ### 4. Agent 已安装并运行，但从未出现在 Dashboard 中 **症状**: `systemctl status wazuh-agent` 显示 `active (running)` 并且所有子模块均已启动，但 Dashboard 一直显示“未注册任何 agent”。 **诊断**: 在受害机上执行 `sudo tail /var/ossec/logs/ossec.log` 显示 agent 反复注册失败： ``` wazuh-agentd: INFO: Requesting a key from server: 192.168.56.104 wazuh-agentd: ERROR: (1208): Unable to connect to enrollment service at '192.168.56.104:1515' ``` Agent 被配置为连接到**自身的 IP** (192.168.56.104) 而不是 Manager 的 IP (192.168.56.105) —— 原始 `WAZUH_MANAGER` 安装变量中的一位数字拼写错误。 **修复**: 直接在 `/var/ossec/etc/ossec.conf` 中更正了地址： ```

192.168.56.105

``` 然后执行 `sudo systemctl restart wazuh-agent`。Agent 成功注册，并在 Dashboard 中显示为 **Active**。 ### 5. Kali 完全无法连接到受害机 (`Destination Host Unreachable`) **症状**: 从 Kali 对受害机执行 `nmap` 和 `ping` 均失败，报错 `Destination Host Unreachable`，且源地址是 Kali 自身的 Host-Only IP —— 这意味着数据包根本没有离开 Kali。 **诊断**: 在 Kali 上执行 `ip route` 显示**在两个具有相同源 IP 的不同接口上存在通往同一子网的两条路由**： ``` 192.168.56.0/24 dev eth0 ... src 192.168.56.10 metric 100 192.168.56.0/24 dev eth1 ... src 192.168.56.10 metric 101 ``` `eth0`（NAT 适配器）由于某种原因也获取了 Host-Only IP，并且——由于其路由 metric 较低——内核优先选择通过 NAT 接口路由 Host-Only 流量，而该接口没有通往该网络的路径。 **修复**: 从 `eth0` 中移除了重复的 IP，并通过 `nmcli connection show` 确认静态 IP 仅正确限定在 Host-Only 连接配置文件中，而没有重复到 NAT 连接上。在更正了 NetworkManager 配置文件后（而不仅仅是临时的 `ip addr del`，因为这在协调时会恢复），路由问题得到解决，并且与受害机的连接已恢复。 ### 6. 从 Kali 进行的端口扫描未在 Dashboard 中生成告警 **症状**: 修复连接后，对受害机执行 `nmap -sV -sC` 成功（发现 `22/tcp open ssh`），但 Wazuh Dashboard 中没有任何显示。 **根本原因（这是设计使然，并非 Bug）**: Wazuh 是一个 **HIDS (Host-based IDS)**，而不是 NIDS。默认情况下，它不检查流经主机的网络流量——它监控的是受监控系统*内部*发生的事情（日志、文件完整性、身份验证事件）。外部端口扫描不会在受害机内部留下任何痕迹，除非受害机自身的防火墙记录了传入的连接。 **正在进行的修复**: 在受害机上启用带有日志记录功能的 `ufw`，以便将扫描流量记录到 `/var/log/ufw.log` 中，随后 Wazuh 的 `logcollector` 便可将其收集： ``` sudo ufw default deny incoming sudo ufw allow ssh sudo ufw logging on sudo ufw enable ``` 在此将其记录为一个已知的局限性/下一步计划，而不是一个已解决的问题——请参阅下文的 **未来改进**。 ## 已执行的攻击模拟 | 攻击 | 工具 | 开箱即用的 Wazuh 能否检测到？ | |---|---|---| | SSH 暴力破解 | `hydra` | 是 — 通过 `/var/log/auth.log` 监控（规则 ~5710–5712） | | 端口扫描 (`nmap -sV -sC`) | `nmap` | 默认不能（HIDS 局限性 — 见上文） | ## 截图 ### 架构  ### Dashboard 概览  ### Agent 状态  ### 检测到 SSH 暴力破解  ## 主要收获 - 像默认 Wazuh 这样的基于 HIDS 的 SIEM 关注的是**主机活动**，而不是原始网络流量——理解这一区别对于正确界定检测覆盖范围至关重要。 - 大部分真实的设置时间都花在了调试基础设施上（磁盘大小调整、LVM、路由、NetworkManager 配置文件、损坏的软件包状态），而不是 SIEM 本身——这是对 SOC/系统管理员工作的真实预览。 - Agent 和 Manager 之间的注册问题几乎总是与 IP/连接有关，最好通过在 Agent 端查看 `/var/ossec/logs/ossec.log` 来进行诊断。 ## 未来改进 - [ ] 通过 `ossec.conf` 中的自定义 `` 块将 `ufw` 日志转发到 Wazuh，以获取针对端口扫描和其他网络级侦察的告警。 - [ ] 添加 Suricata 作为与 Wazuh 集成的基于网络的 IDS，以实现真正的 NIDS 覆盖。 - [ ] 为实验室特定场景编写自定义的 Wazuh 检测规则（XML decoders/rules）。 - [ ] 添加第二个受害机主机（例如 Windows 目标）以实现多操作系统日志关联。 - [ ] 使用 Vagrant/Ansible 自动化整个环境，以确保可重复性。 ## 免责声明 该实验室完全运行在隔离的 Host-Only 虚拟网络上，没有暴露于生产系统或公共互联网。所有攻击均针对自有的、专门构建的实验室 VM 进行模拟。

标签：VirtualBox, Wazuh, 安全实验环境, 安全运营中心(SOC), 插件系统