FardeenI/Kali-Linux-and-ELK-Stack-Detection-Engineering-Lab
GitHub: FardeenI/Kali-Linux-and-ELK-Stack-Detection-Engineering-Lab
该项目使用 Terraform 在 AWS 上快速部署包含攻击机、Windows 目标机和 ELK SIEM 的检测工程实验室，帮助安全从业者低成本实践攻击检测与日志分析。
Stars: 6 | Forks: 0
# 检测工程实验室 — AWS 上的 Kali + ELK
这是一个基于 Terraform 自动化的检测工程实验室，它向 AWS 部署了一个模拟的企业网络：一台作为攻击者的 Kali Linux，一台集成了 Sysmon 和 Winlogbeat 的 Windows 目标机，以及一台运行 Elasticsearch 和 Kibana 的 Ubuntu SIEM。克隆代码仓库，填入你的变量，几分钟内即可拥有一个完全配置好的运行环境。
## 背景与动机
我经常通过新闻简报、博客和播客来跟进技术和网络安全的最新动态。Clint Gibler 的 [TLDR Sec](https://tldrsec.com/) 推介了一个由 Rafael Martinez 构建的检测工程实验室，该实验室使用 Terraform 向 AWS 部署攻击/防御基础设施 —— 我也想构建一个属于自己的版本。
当时我正深入研究计算机科学课程，并重度倾向于 AI 辅助软件开发，距离上次进行动手实践的安全工程已经有一段时间了。这个项目是一个回归“破坏与修复”事物的机会，同时也能学习使用 Terraform 进行基础设施即代码 的实践。
这个实验室设计中最吸引我的地方在于，它模拟了一个托管在 AWS 上的小型企业网络。它消除我通常在本地 hypervisor 上运行虚拟机时遇到的内存和存储瓶颈 —— 而且它的销毁速度与创建速度一样快。
## 架构
```
┌──────────────────────────────────────────────────────────────┐
│ AWS Default VPC (us-east-1) │
│ │
│ ┌─────────────┐ [all traffic] ┌──────────────────┐ │
│ │ Kali Linux │ ──────────────────► │ Windows Server │ │
│ │ (attacker) │ │ (target) │ │
│ │ t2.medium │ │ t3.medium │ │
│ └─────────────┘ └────────┬─────────┘ │
│ │ │
│ Winlogbeat (logs → 9200) │
│ Kibana setup (→ 5601) │
│ │ │
│ ┌────────▼─────────┐ │
│ │ Ubuntu SIEM │ │
│ │ Elasticsearch │ │
│ │ Kibana │ │
│ │ t2.large │ │
│ └──────────────────┘ │
│ │
│ Operator access: SSH (22) to Kali/Ubuntu │
│ RDP (3389) to Windows │
│ Kibana UI (5601) to Ubuntu │
└──────────────────────────────────────────────────────────────┘
```
### 组件
| 实例 | 操作系统 | 类型 | 角色 |
|---|---|---|---|
| Kali Linux | Kali | t2.medium | 攻击者 —— 运行攻击工具 |
| Windows Server | Windows | t3.medium | 目标机 —— Sysmon + Winlogbeat |
| Ubuntu SIEM | Ubuntu | t2.large | SIEM —— Elasticsearch + Kibana |
**数据流：** Kali 攻击 Windows → Sysmon 捕获详细的 Windows 事件 → Winlogbeat 将日志发送到 Elasticsearch → Kibana 将其可视化为仪表盘。
## 成本
所有价格均为 **us-east-1** 的 AWS 按需费率，并且可能会有所变动。在部署之前，请查看 [AWS 定价页面](https://aws.amazon.com/ec2/pricing/on-demand/) 获取当前费率。
### 计算资源 (EC2)
| 实例 | 类型 | 按需费率 | 24/7 全天候运行成本 | 每周运行 5 小时成本 |
|---|---|---|---|---|
| Kali Linux | t2.medium | $0.0464/hr | $33.87/mo | $1.01/mo |
| Ubuntu SIEM | t2.large | $0.0928/hr | $67.74/mo | $2.01/mo |
| Windows 目标机 | t3.medium | $0.0416/hr | $30.37/mo | $0.90/mo |
| **小计** | | | **$132/mo** | **$3.92/mo** |
### 存储 (EBS —— 无论实例处于何种状态都会持续计费)
| 卷 | 大小 | 成本 |
|---|---|---|
| Kali root | 25 GB (gp3) | $2.00/mo |
| Ubuntu SIEM root | 50 GB (gp3) | $4.00/mo |
| Windows root | 30 GB (gp3) | $2.40/mo |
| **小计** | | **$8.40/mo** |
### 公网 IPv4 地址
无论实例处于何种状态，AWS 对每个公网 IPv4 地址收取 $0.005/hr 的费用。对于全部三个实例，24/7 全天候运行的成本是 **$10.95/mo**；每周运行 5 小时的成本是 **$0.33/mo**。请注意，当实例停止时，动态公网 IP 会被释放，因此此项成本随运行时间而变化。
### 总费用估算
| 使用模式 | 预估每月成本 |
|---|---|
| 24/7 (永远在线) | ~$151/mo |
| 每周 5 小时 | ~$13/mo |
## 前置条件
在运行 `terraform apply` 之前，你需要：
1. **AWS 账户**，以及一个 IAM 用户，该用户的访问密钥已导出为环境变量：
export AWS_ACCESS_KEY_ID="your-access-key"
export AWS_SECRET_ACCESS_KEY="your-secret-key"
2. 已在你的 AWS 账户中创建的 **EC2 密钥对**（用于通过 SSH 连接到 Kali/Ubuntu 以及解密 Windows RDP 密码）。
3. **Kali Linux AMI 订阅** —— Kali AMI 通过 AWS Marketplace 分发，在启动前需要进行免费订阅。在运行 `terraform apply` 之前，请先[在此订阅](https://aws.amazon.com/marketplace/pp/prodview-fznsw3f7mq7to)。Windows Server AMI 由 AWS 拥有，无需订阅。
4. 已安装 **Terraform**（[下载](https://developer.hashicorp.com/terraform/install)）。
5. **你的公网 IP** —— 安全组将 SSH、RDP 和 Kibana 的访问限制为操作者指定的 CIDR。你需要知道采用 CIDR 表示法的公网 IP（例如 `1.2.3.4/32`）。运行以下命令以发现你当前的公网 IPv4 地址：
curl -4 ifconfig.me
6. **SSH 客户端** —— 用于连接到 Kali 和 Ubuntu 实例。AWS 要求密钥对文件在使用前具有严格的权限：
chmod 400 your-key.pem
7. **RDP 客户端** —— 用于连接到 Windows 实例（例如 macOS/Windows 上的 Microsoft Remote Desktop，或 Linux 上的 Remmina）。
8. **默认 VPC** —— 该实验室部署在你的 AWS 账户的默认 VPC 中。每个新的 AWS 账户在每个区域都会自带一个默认 VPC，但如果你的默认 VPC 已被删除，则需要先通过 VPC 控制台（`操作 → 创建默认 VPC`）重新创建它，然后再进行应用部署。如果你希望部署到不同的 VPC，请在 `main.tf` 中的每个 `aws_security_group` 资源中添加 `vpc_id` 参数，并在每个 `aws_instance` 资源中添加指向该 VPC 内子网的 `subnet_id` 参数。
## 快速开始
```
# 克隆仓库
git clone
cd detection-engineering/setup/terraform
# 从示例创建您的 variables 文件
cp terraform.tfvars.example terraform.tfvars
# 在 terraform.tfvars 中填入您的值（参见文件以获取指导）
# - Key pair 名称
# - 您的公网 IP
# - 您所在区域的 AMI ID（为 us-east-1 提供了默认值）
# 初始化 Terraform（下载 AWS provider）
terraform init
# 部署
terraform apply
```
当应用部署完成时，Terraform 将输出所有三个实例的公网 IP。
## 访问实验室
| 服务 | 方式 | 地址 |
|---|---|---|
| Kali Linux | SSH | `ssh -i your-key.pem kali@` |
| Ubuntu SIEM | SSH | `ssh -i your-key.pem ubuntu@` |
| Kibana | 浏览器 | `http://:5601` |
| Windows | RDP 客户端 | `:3389` —— 通过 AWS 控制台使用你的密钥对解密密码 |
## 生成检测日志
实验室运行后，从 Kali 机器向 Windows 目标发起的攻击会被 Sysmon 捕获，通过 Winlogbeat 发送到 Elasticsearch，并在 Kibana 中进行可视化 —— 这正是该实验室旨在实现的核心检测工程闭环。
一次简单的端口扫描是很好的初步测试。通过 SSH 登录到 Kali 并运行：
```
ssh -i your-key.pem kali@
nmap -sV
```
这将生成 Sysmon 的 **Event ID 3**（网络连接）条目，这些条目应在几秒钟内出现在 Kibana 的 Discover 视图中，位于 `winlogbeat-*` 数据视图下。
## 安全组设计
三个安全组强制执行最小权限访问：
- **Kali SG** —— 仅允许来自操作者 IP 的入站 SSH；出站不受限制。
- **Windows SG** —— 允许来自操作者 IP 的入站 RDP；允许来自 Kali 安全组的所有流量（攻击流量）。出站不受限制。
- **Ubuntu SG** —— 允许来自操作者 IP 的入站 SSH；允许来自操作者 IP 访问 Kibana UI (5601)；仅允许来自 Windows 安全组的 Elasticsearch (9200) 和 Kibana 设置流量 (5601)。
这意味着 Elasticsearch 永远无法直接从公共互联网访问 —— 只能通过 Windows 实例的安全组成员身份从该实例进行访问。
## 引导细节
每个实例在首次启动时都会通过 `user_data` 进行引导：
**Kali** —— 运行 `apt-get full-upgrade` 并安装 `kali-linux-default` 元软件包（标准 Kali 工具套件）。针对 Wireshark 和 Kismet 的交互式提示通过 `debconf` 进行了预先设置，以防止脚本挂起。
**Ubuntu (SIEM)** —— 从官方 Elastic 8.x APT 仓库安装 Elasticsearch 和 Kibana。Elasticsearch 被配置为监听所有接口的单节点集群。SSL/TLS (`xpack.security`) 被禁用 —— Elasticsearch 8.x 软件包会在 keystore 中预先填充 SSL 凭证，这与禁用安全功能产生冲突，因此 keystore 被清空并重新创建为空状态。这是一个有意的权衡：鉴于实验室私有 VPC 的上下文，并且生产级 TLS 配置不在本实验室的学习目标范围内，中间人攻击 (MITM) 的风险是可以接受的。Kibana 被配置为监听所有接口，以便可以通过实例的公网 IP 进行访问。
**Windows (目标机)** —— 使用 [SwiftOnSecurity 配置](https://github.com/SwiftOnSecurity/sysmon-config) 安装 Sysmon 以实现全面的事件覆盖，随后安装 Winlogbeat 8.17.0。Winlogbeat 配置在启动时被修补，将其用于 Elasticsearch (9200) 和 Kibana (5601) 的目标地址指向 Ubuntu 实例的私有 IP，并且启用了仪表盘设置，以便在启动时自动将预构建的 Winlogbeat 仪表盘加载到 Kibana 中。
## 验证部署
一旦实例运行起来，可以通过以下方式确认所有配置是否正确连通：
**Kali** —— 通过 SSH 登录并抽查工具是否已安装：
```
which nmap
which msfconsole
which wireshark
```
**Ubuntu** —— 检查服务状态：
```
sudo systemctl status elasticsearch
sudo systemctl status kibana
```
**Windows** —— 通过 RDP 登录并打开 PowerShell，以验证 Winlogbeat 配置和服务：
```
# 检查配置指向正确的 Elasticsearch/Kibana IP
Get-Content "C:\Program Files\Winlogbeat\winlogbeat-8.17.0-windows-x86_64\winlogbeat.yml"
# 确认服务正在运行
Get-Service winlogbeat
```
然后在浏览器中打开 `http://:5601`。在左侧的导航菜单中，展开 **Analytics** 部分：
- **Discover** —— 选择 `winlogbeat-*` 数据视图，以探索随着 Winlogbeat 流入的原始 Windows 事件日志。
- **Dashboards** —— 浏览启动时自动加载的预构建 Winlogbeat 仪表盘，获取 Windows 事件活动的可视化概览。
## 资源追踪
所有实验室资源都已打上标签，并归类在 **AWS Service Catalog App Registry** 应用程序（`DetectionEngineeringLab`）下。这使得在 AWS 控制台的 **MyApplications** 下查找和审计实验室创建的每一个资源变得非常容易。
## 销毁
```
terraform destroy
```
这将移除所有已配置的资源。由于 `*.tfstate` 已在 gitignore 中被忽略，你的状态文件是本地的 —— 在运行销毁之前，请勿删除该文件。
## 学习目标
这个项目是对多个领域的实践：
- **使用 Terraform 实现基础设施即代码** —— 将云基础设施声明为受版本控制的代码，包括 EC2 实例、安全组以及资源之间的依赖顺序。
- **检测工程基础** —— 了解 Windows 主机上的攻击者活动如何生成 artifacts，以及这些数据如何流经 Sysmon → Winlogbeat → Elasticsearch → Kibana。
- **安全组设计** —— 建模真实的网络分段策略，其中 SIEM 只能从 Windows 目标机访问（不能从公共互联网访问），攻击者可以访问目标机，但不能直接访问 SIEM。
- **云引导** —— 使用 `user_data` 在启动时完全配置实例，无需手动的部署后步骤，包括处理非交互式软件包安装和服务配置。
- **调试分布式系统** —— 诊断 Elasticsearch、Kibana 和 Winlogbeat 之间的启动顺序问题；解决 SSL/TLS keystore 冲突；以及通过安全组规则和服务日志追踪连接问题。
## AMI 说明 (us-east-1)
`terraform.tfvars.example` 中的默认 AMI ID 针对 us-east-1。如果你要部署到其他区域，请在应用之前查找适合你区域的同等 AMI。
| 实例 | 默认 AMI (us-east-1) |
|---|---|
| Kali Linux | ami-09e99f75cc7592017 |
| Windows Server | ami-0ab5e8edee718de14 (Windows Server 2022，AWS 拥有 —— 无需 Marketplace 订阅) |
| Ubuntu | ami-0ecb62995f68bb549 |
标签：AWS, DPI, ECS, ELK, IP 地址批量处理, OpenCanary, Terraform, 越狱测试, 靶场环境