hubertwojcik/redteam-vs-blueteam-lab

# 红队对蓝队实验室 一个实践安全实验室，记录了跨三个阶段的完整红队对蓝队模拟——加固前、加固过程本身以及加固后。旨在展示实证安全思维：不仅是理论，而是可衡量的加固前后影响。 ## 本项目展示的内容 - 在未加固 Linux 系统上的侦察和攻击技术 - 使用 Ansible 进行系统性加固（SSH 密钥、Fail2ban、UFW、AppArmor） - 加固后重新执行相同的攻击，并记录其失败模式 - 使用 Wazuh 进行实时检测——自定义规则在攻击模式发生时触发告警 - 蓝队思维：运行手册、检查清单、日志分析、威胁建模 目标不是展示攻击命令——而是展示**它们带来的改变**，以及防御者如何思考以消除这一差距。 ## 实验室架构 ``` ┌─────────────────────┐ ┌──────────────────────────┐ │ Kali Linux (VM2) │ │ Ubuntu 22.04 (VM1) │ │ Red Team / Attack │ ───────► │ Target + Wazuh Agent │ │ │ │ 192.168.x.x │ └─────────────────────┘ └──────────┬───────────────┘ │ agent → manager ┌──────────▼───────────────┐ │ Wazuh Manager (VM3) │ │ SIEM / Alert console │ └──────────────────────────┘ Host-only network (isolated, no internet access) ``` ## 阶段结构 ### 第一阶段 —— 对未加固系统的攻击 **目标：** 建立基线。攻击者能在针对默认 Ubuntu 安装的攻击中了解并执行什么？ 使用的工具： - `nmap` —— 端口扫描、服务指纹识别、OS 检测 - `hydra` —— 针对默认凭据的 SSH 暴力破解 - `nikto` —— Web 服务扫描（如适用） **记录的结果：** 开放端口、发现的服务、成功的暴力破解、信息泄露。 → 参见 [`rounds/round1-pre-hardening/findings.md`](rounds/round1-pre-hardening/findings.md) ### 第二阶段 —— 使用 Ansible 进行加固 **目标：** 对 VM1 应用可重现的加固基线。无需手动更改——一切皆代码化。 应用的加固： | 控制 | 实现 | |---|---| | 禁用 SSH root 登录 | 在 sshd_config 中设置 `PermitRootLogin no` | | 禁用密码认证 | 仅限 SSH 密钥 | | 暴力破解防护 | 设置了激进阈值的 Fail2ban | | 防火墙 | UFW —— 拒绝除 SSH 外的所有入站流量 | | 进程隔离 | 强制执行 AppArmor 配置文件 | | 检测代理 | 安装并注册 Wazuh Agent | 变量（端口、用户、阈值）集中在 `ansible/group_vars/all.yml` 中——角色中没有硬编码。 → 参见 [`ansible/playbooks/hardening.yml`](ansible/playbooks/hardening.yml) ### 第三阶段 —— 相同的攻击，在加固 + Wazuh 监控之后 **目标：** 重新执行第一阶段的攻击，记录哪些失败了、为什么失败，以及 Wazuh 实时检测到了什么。 **记录的结果：** 被拦截的 SSH 暴力破解（Fail2ban 封禁 + `/var/log/auth.log` 证据）、减小的攻击面、失败的凭据重用、针对攻击模式触发的 Wazuh 告警。 → 参见 [`rounds/round3-post-hardening/findings.md`](rounds/round3-post-hardening/findings.md) → 参见 [`rounds/round3-post-hardening/wazuh-alerts.md`](rounds/round3-post-hardening/wazuh-alerts.md) ## 仓库结构 ``` redteam-vs-blueteam-lab/ │ ├── environment/ │ ├── diagram.png # Network topology │ ├── lab-setup.md # VM config, network mode, OS versions │ ├── vm-specs.md # Hardware specs (anonymized IPs) │ ├── baseline-state.md # What the target looks like before any changes │ └── threat-model.md # Attacker profile, goals, assumptions — read first │ ├── ansible/ │ ├── inventory.ini │ ├── group_vars/ │ │ └── all.yml # Central variables: ports, users, thresholds │ ├── playbooks/ │ │ └── hardening.yml # Full hardening playbook │ └── roles/ │ ├── ssh-hardening/ │ ├── fail2ban/ │ ├── firewall/ │ └── wazuh-agent/ # Installs and enrolls the Wazuh agent │ ├── wazuh/ │ ├── setup.md # How to stand up Wazuh Manager │ ├── custom-rules/ │ │ └── ssh-bruteforce.xml # Custom detection rule for Hydra-style attacks │ └── alerts-examples/ # Screenshots of alerts firing during Round 3 │ ├── rounds/ │ ├── round1-pre-hardening/ │ │ ├── findings.md │ │ ├── nmap-scan.txt │ │ ├── hydra-results.txt │ │ └── screenshots/ │ ├── round2-hardening/ │ │ ├── changes-applied.md │ │ ├── ansible-run-log.txt │ │ └── screenshots/ │ └── round3-post-hardening/ │ ├── findings.md │ ├── nmap-scan.txt │ ├── hydra-results.txt │ ├── auth-log-excerpt.txt │ ├── wazuh-alerts.md # What Wazuh detected, alert IDs, timeline │ └── screenshots/ │ ├── runbooks/ │ ├── ssh-bruteforce-response.md # Step-by-step IR for SSH brute-force │ ├── hardening-checklist.md # CIS Benchmark-style checklist │ └── lessons-learned.md # What surprised me, what I'd do differently │ └── docs/ └── methodology.md # Why these tools, why this order ``` ## 技术栈 | 类别 | 工具 | |---|---| | 攻击平台 | Kali Linux | | 目标平台 | Ubuntu 22.04 LTS | | 侦察 | Nmap | | 凭据攻击 | Hydra | | Web 扫描 | Nikto | | 漏洞利用（可选） | Metasploit Framework | | 基础设施即代码 | Ansible | | 入侵防御 | Fail2ban | | 防火墙 | UFW / nftables | | 强制访问控制 | AppArmor | | SIEM / 检测 | Wazuh | | 虚拟化 | VirtualBox | ## 关键发现（摘要） | 攻击向量 | 第一阶段（加固前） | 第三阶段（加固后） | |---|---|---| | SSH 端口暴露 | 开放，默认端口 | 开放，非默认端口 | | 通过 SSH 进行 Root 登录 | 允许 | 拦截 | | 密码暴力破解 | 成功 | 尝试 N 次后 IP 被 Fail2ban 封禁 | | 服务指纹识别 | 暴露完整版本信息 | 最少的 banner | | 不必要的服务 | 多个开放端口 | 减少至最低限度 | | 检测 | 无 | 首次尝试后几秒钟内产生 Wazuh 告警 | 包含日志和屏幕截图的完整详细信息位于每个 `rounds/` 目录中。 ## Wazuh：自定义检测规则 `wazuh/custom-rules/ssh-bruteforce.xml` 规则可检测来自单一来源的快速连续 SSH 失败——即 Hydra 产生的模式。这超越了默认的 Wazuh 规则集：它针对第一阶段中观察到的特定攻击签名进行了调整。 这就是蓝队思维变得清晰可见的地方：不仅是“Wazuh 正在运行”，而是“这是规则，这就是为什么阈值设置为 X 的原因，这是它产生的告警。” → 参见 [`wazuh/custom-rules/`](wazuh/custom-rules/) 和 [`rounds/round3-post-hardening/wazuh-alerts.md`](rounds/round3-post-hardening/wazuh-alerts.md) ## 我学到了什么 - Ansible 使加固变得**可审计**——任何人都可以阅读 playbook 并确切知道发生了什么改变，而且 `group_vars` 将配置集中在一处 - Fail2ban 日志是攻击发生并被拦截的最清晰证明——比任何屏幕截图都好 - 编写自定义 Wazuh 规则迫使你不仅要了解工具层面，还要在日志层面理解攻击模式 - 威胁建模决定了一切：了解假设的攻击者有助于确定哪些控制最为关键 - “默认安全”在原生 Ubuntu 上是一个神话——第一阶段和第三阶段之间的差距是巨大的 → 完整的反思见 [`runbooks/lessons-learned.md`](runbooks/lessons-learned.md) ## 自己运行该实验室 ``` # 审查基线状态（无需 playbook —— 已记录在 environment/ 中） cat environment/baseline-state.md # 从 Kali 运行第一轮攻击，记录结果 # 应用加固 + 注册 Wazuh agent ansible-playbook -i ansible/inventory.ini ansible/playbooks/hardening.yml # 重新运行攻击，观察 Wazuh 告警，比较结果 ``` 完整的 VM 设置说明请参见 [`environment/lab-setup.md`](environment/lab-setup.md)，Wazuh Manager 设置请参见 [`wazuh/setup.md`](wazuh/setup.md)。 ## 作者 作为作品集项目构建，旨在展示实用的安全工程技能——攻击意识、系统性防御、基础设施即代码规范以及实时检测工程。

标签：Ansible, CTI, Wazuh, 安全实验靶场, 插件系统, 系统加固, 系统提示词