0xMadhusankha/aws-incident-response-lab
GitHub: 0xMadhusankha/aws-incident-response-lab
一个基于 AWS 原生服务构建的动手实验项目，演示如何通过 CloudWatch 日志监控和 Lambda 自动化实现 EC2 实例的实时安全隔离。
Stars: 0 | Forks: 0
# AWS 事件响应与自动化 EC2 隔离实验
## 概述
这是 AWS SimuLearn 的一个动手实验，专注于云环境中的事件响应。核心理念非常直接：当暴力破解攻击击中你的应用服务器并开始产生大量 HTTP 401 错误时，系统应该能够检测到它并自动隔离受损实例。无需人工干预，也无需等待人员发现。
我亲自搭建了整个流水线：从设置日志摄取到配置告警，连接通知服务，并亲眼看着一个 Lambda 函数实时剥夺 EC2 实例的访问权限。最后那一步看到效果时确实令人非常有成就感。
## 解决的问题
在传统设置中，安全团队的某个人需要注意到流量峰值，进行调查，然后手动撤销访问权限并更新安全组。这需要时间，而在真实的攻击场景中，时间就是生命。
这个实验展示了如何自动化整个响应链。系统检测到异常的 401 活动的那一刻，就会自行处理遏制措施。实例被隔离（移除 IAM 角色，替换为没有入站/出站规则的安全组），并且保持运行状态，以便仍然可以进行取证分析。
这正是现代云 SOC（安全运营中心）工作流的设计方式。检测 → 通知 → 自动化响应，在关键遏制步骤中完全无需人工介入。
## 使用的服务
### 🔔 Amazon SNS (Simple Notification Service)
一种可以向多个订阅者发送消息的通知服务。你向一个“主题”发布消息，该主题的任何订阅者都会收到它。在这里，它充当了 CloudWatch（检测）和 Lambda（响应）之间的桥梁。当警报触发时，它会向 SNS 主题发布消息，订阅该主题的 Lambda 函数会被自动调用。
### 📊 Amazon CloudWatch
AWS 的监控和日志服务。它从你的资源收集日志和指标。在这个项目中它做了两件事：通过 CloudWatch Agent 从 EC2 实例摄取应用日志，然后根据警报条件评估这些日志以检测攻击。
### ⚡ AWS Lambda
无服务器计算。你编写一个函数，定义它的触发条件，剩下的运行工作由 AWS 处理。无需管理服务器。在这里，一个 Lambda 模拟攻击者（循环发送 40 次错误登录尝试），另一个执行实际的事件响应工作（隔离 EC2 实例）。
### 🖥️ Amazon EC2 (Elastic Compute Cloud)
运行 Flask Web 应用程序的虚拟服务器。这是场景中的“受害者”，即被暴力攻击锁定并最终隔离的实例。
### 🔧 AWS Systems Manager (SSM)
一种管理服务，允许你访问和管理 EC2 实例，而无需 SSH 密钥或打开入站端口。我使用了它的两个功能：**Fleet Manager** 用于查看和管理实例，**Session Manager** 用于直接从 AWS 控制台打开终端会话。
### 🗂️ AWS SSM Parameter Store
配置数据的安全存储。配置 CloudWatch Agent 后，配置会保存在这里，以便后续引用和复用，这对于在多实例中大规模部署相同的 Agent 配置非常有用。
### 🔑 AWS IAM (Identity and Access Management)
控制 AWS 中的权限。EC2 实例拥有一个 IAM 实例配置文件（附加到实例的角色），该角色赋予了它某些权限。隔离响应的一部分就是移除该角色，因此即使有人仍然连接着，他们也没有任何 AWS 权限去执行操作。
## 整体运作流程
以下是从头到尾的完整流程：
### 步骤 1 — 设置 SNS 主题
首先创建了一个名为 `UnauthorizedExceptionNotification` 的 SNS 主题。然后使用电子邮件协议订阅了一个邮箱地址，AWS 会发送一封确认邮件，只有点击确认链接后订阅才会激活。这个 SNS 主题随后被邮件告警和隔离 Lambda 函数共同使用。
### 步骤 2 — 检查 EC2 实例
在 EC2 中检查了 AppServer 实例，确认 IAM 角色和安全组已经附加并配置完毕。我还复制了实例 ID，因为后续的 CloudWatch 指标和 Lambda 工作流中会用到它。
### 步骤 3 — 通过 SSM 安装 CloudWatch Agent
我没有使用 SSH 登录，而是使用了 **SSM Fleet Manager** → 选中 AppServer → Node Actions → Execute Run Command。选择 `AWSConfigureAWSPackage` 文档，将名称设置为 `amazon-cloudwatch-agent`，手动定位目标实例，然后运行。输出结果确认软件包安装成功。
### 步骤 4 — 配置 CloudWatch Agent
使用 Session Manager 直接在实例内部打开了终端会话，不需要 SSH、密钥对或开放端口。运行配置向导：
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard
```
通过向导配置其将 `/home/ssm-user/record.log` 发送到 CloudWatch 日志组，并设置了 7 天的保留期。然后将该配置保存到 SSM Parameter Store 并启动了代理：
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
-a fetch-config -s -m ec2 \
-c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json
```
### 步骤 5 — 为 401 错误创建指标过滤器
在 CloudWatch Logs 中，打开 `record.log` 日志组，搜索 `401` 事件，然后创建了一个名为 `Unauthorized401` 的指标过滤器。将其映射到：
**命名空间:** `LabApplications`
**指标名称:** EC2 实例 ID（以便警报知道是哪个实例触发了它）
**值:** 每次命中为 1，单位: Count
### 步骤 6 — 模拟攻击
在设置警报之前，使用名为 `Generate401Traffic` 的测试事件运行了 `labFunctionTrafficGenerator` Lambda。该函数使用错误凭证对登录接口进行了 40 次连续轰炸。检查日志，发现全是 401 错误，完全符合预期。
### 步骤 7 — 创建 CloudWatch Alarm
在 CloudWatch → Alarms → Create Alarm 中：
选择 `LabApplications` 指标（与实例 ID 绑定的那个）
统计信息: **Sum**，周期: **30 秒**
条件: **大于 20**
缺失数据处理: **视为良好**（这样基线静默期就不会触发误报）
操作: 在处于 ALARM 状态时通知 `UnauthorizedExceptionNotification` SNS 主题
将其命名为 `Unauthorized401ErrorBreach`。创建后，它首先进入 `Insufficient data` 状态，几分钟后一旦获取到基线数据，就会进入 `OK` 状态。
### 步骤 8 — 关联隔离器 Lambda
转到 `labFunctionisolator` Lambda → Add Trigger → SNS → 选中 `UnauthorizedExceptionNotification`。现在，只要这个 SNS 主题收到消息，该函数就会自动触发。
### 步骤 9 — 触发完整流水线
再次运行流量生成器 Lambda。这一次：
1. 40 次错误登录尝试 → 记录了 40 个 401 错误
2. CloudWatch 检测到 30 秒内总和大于 20 → 触发警报
3. 警报发布到 SNS 主题
4. SNS 调用隔离器 Lambda
5. Lambda 移除实例的 IAM 角色，并附加 `Isolated_SG`（一个没有入站或出站规则的安全组）
### 步骤 10 — 验证隔离
回到 EC2 → AppServer → Security 标签页：
- IAM Role: 已移除
- Security Group: `Isolated_SG`
实例仍在运行，但已被完全切断。没有入站连接，没有出站流量，也没有 AWS 权限。已准备好进行取证。
## 我的实际收获
**SSM 是这个实验中最让我感兴趣的部分之一。** 在此之前，我一直认为 SSH 是访问 Linux 服务器的常规方式。使用 Session Manager 直接从 AWS 控制台打开终端，而无需 SSH 密钥或开放端口，感觉更简单也更安全。
**日志摄取是一切的基础。** 如果日志没有流动，任何检测或自动化都无法工作。正确设置 CloudWatch Agent，选择正确的日志路径，并将配置保存到 Parameter Store，事实证明这比我预期的更为重要。
**指标过滤器比看起来更强大。** 使用 EC2 实例 ID 作为指标名称，通过警报 → SNS → Lambda 链路传递上下文，这个技巧是我以前没有想到的。它简单但有效，Lambda 不需要做任何额外的查找就能知道是哪个实例触发了警报。
**自动化响应。** 在做这个实验之前，我大多认为事件响应是一个手动过程。看到 AWS 在警报触发后自动隔离 EC2 实例，让我理解了云环境如何能够利用自动化做出更快速的响应。
## 这个实验的价值
这个实验涵盖了一种在云安全中频繁出现的模式：**检测 → 通知 → 响应**。这里的具体触发条件是 HTTP 401 错误，但同样的架构也适用于 GuardDuty 发现、CloudTrail 异常、异常的数据传输量——实际上，任何可以表示为 CloudWatch 指标或日志模式的内容都可以使用。
构建这个流程让我更清晰地了解了自动化事件响应如何融入云 SOC，也让我明白了为什么在云环境中，传统的“等待人工介入”模型无法扩展，毕竟手动调查和响应会耗费过多时间。
*作为 [Skill Builder](https://skillbuilder.aws) 上 AWS SimuLearn 事件响应实验的一部分完成*
## 概述
这是 AWS SimuLearn 的一个动手实验，专注于云环境中的事件响应。核心理念非常直接：当暴力破解攻击击中你的应用服务器并开始产生大量 HTTP 401 错误时，系统应该能够检测到它并自动隔离受损实例。无需人工干预，也无需等待人员发现。
我亲自搭建了整个流水线：从设置日志摄取到配置告警，连接通知服务，并亲眼看着一个 Lambda 函数实时剥夺 EC2 实例的访问权限。最后那一步看到效果时确实令人非常有成就感。
## 解决的问题
在传统设置中，安全团队的某个人需要注意到流量峰值，进行调查，然后手动撤销访问权限并更新安全组。这需要时间，而在真实的攻击场景中，时间就是生命。
这个实验展示了如何自动化整个响应链。系统检测到异常的 401 活动的那一刻，就会自行处理遏制措施。实例被隔离（移除 IAM 角色，替换为没有入站/出站规则的安全组），并且保持运行状态，以便仍然可以进行取证分析。
这正是现代云 SOC（安全运营中心）工作流的设计方式。检测 → 通知 → 自动化响应，在关键遏制步骤中完全无需人工介入。
## 使用的服务
### 🔔 Amazon SNS (Simple Notification Service)
一种可以向多个订阅者发送消息的通知服务。你向一个“主题”发布消息，该主题的任何订阅者都会收到它。在这里，它充当了 CloudWatch（检测）和 Lambda（响应）之间的桥梁。当警报触发时，它会向 SNS 主题发布消息，订阅该主题的 Lambda 函数会被自动调用。
### 📊 Amazon CloudWatch
AWS 的监控和日志服务。它从你的资源收集日志和指标。在这个项目中它做了两件事：通过 CloudWatch Agent 从 EC2 实例摄取应用日志，然后根据警报条件评估这些日志以检测攻击。
### ⚡ AWS Lambda
无服务器计算。你编写一个函数，定义它的触发条件，剩下的运行工作由 AWS 处理。无需管理服务器。在这里，一个 Lambda 模拟攻击者（循环发送 40 次错误登录尝试），另一个执行实际的事件响应工作（隔离 EC2 实例）。
### 🖥️ Amazon EC2 (Elastic Compute Cloud)
运行 Flask Web 应用程序的虚拟服务器。这是场景中的“受害者”，即被暴力攻击锁定并最终隔离的实例。
### 🔧 AWS Systems Manager (SSM)
一种管理服务，允许你访问和管理 EC2 实例，而无需 SSH 密钥或打开入站端口。我使用了它的两个功能：**Fleet Manager** 用于查看和管理实例，**Session Manager** 用于直接从 AWS 控制台打开终端会话。
### 🗂️ AWS SSM Parameter Store
配置数据的安全存储。配置 CloudWatch Agent 后，配置会保存在这里，以便后续引用和复用，这对于在多实例中大规模部署相同的 Agent 配置非常有用。
### 🔑 AWS IAM (Identity and Access Management)
控制 AWS 中的权限。EC2 实例拥有一个 IAM 实例配置文件（附加到实例的角色），该角色赋予了它某些权限。隔离响应的一部分就是移除该角色，因此即使有人仍然连接着，他们也没有任何 AWS 权限去执行操作。
## 整体运作流程
以下是从头到尾的完整流程：
### 步骤 1 — 设置 SNS 主题
首先创建了一个名为 `UnauthorizedExceptionNotification` 的 SNS 主题。然后使用电子邮件协议订阅了一个邮箱地址，AWS 会发送一封确认邮件，只有点击确认链接后订阅才会激活。这个 SNS 主题随后被邮件告警和隔离 Lambda 函数共同使用。
### 步骤 2 — 检查 EC2 实例
在 EC2 中检查了 AppServer 实例，确认 IAM 角色和安全组已经附加并配置完毕。我还复制了实例 ID，因为后续的 CloudWatch 指标和 Lambda 工作流中会用到它。
### 步骤 3 — 通过 SSM 安装 CloudWatch Agent
我没有使用 SSH 登录，而是使用了 **SSM Fleet Manager** → 选中 AppServer → Node Actions → Execute Run Command。选择 `AWSConfigureAWSPackage` 文档，将名称设置为 `amazon-cloudwatch-agent`，手动定位目标实例，然后运行。输出结果确认软件包安装成功。
### 步骤 4 — 配置 CloudWatch Agent
使用 Session Manager 直接在实例内部打开了终端会话，不需要 SSH、密钥对或开放端口。运行配置向导：
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard
```
通过向导配置其将 `/home/ssm-user/record.log` 发送到 CloudWatch 日志组，并设置了 7 天的保留期。然后将该配置保存到 SSM Parameter Store 并启动了代理：
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
-a fetch-config -s -m ec2 \
-c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json
```
### 步骤 5 — 为 401 错误创建指标过滤器
在 CloudWatch Logs 中，打开 `record.log` 日志组，搜索 `401` 事件，然后创建了一个名为 `Unauthorized401` 的指标过滤器。将其映射到：
**命名空间:** `LabApplications`
**指标名称:** EC2 实例 ID（以便警报知道是哪个实例触发了它）
**值:** 每次命中为 1，单位: Count
### 步骤 6 — 模拟攻击
在设置警报之前，使用名为 `Generate401Traffic` 的测试事件运行了 `labFunctionTrafficGenerator` Lambda。该函数使用错误凭证对登录接口进行了 40 次连续轰炸。检查日志，发现全是 401 错误，完全符合预期。
### 步骤 7 — 创建 CloudWatch Alarm
在 CloudWatch → Alarms → Create Alarm 中：
选择 `LabApplications` 指标（与实例 ID 绑定的那个）
统计信息: **Sum**，周期: **30 秒**
条件: **大于 20**
缺失数据处理: **视为良好**（这样基线静默期就不会触发误报）
操作: 在处于 ALARM 状态时通知 `UnauthorizedExceptionNotification` SNS 主题
将其命名为 `Unauthorized401ErrorBreach`。创建后，它首先进入 `Insufficient data` 状态，几分钟后一旦获取到基线数据，就会进入 `OK` 状态。
### 步骤 8 — 关联隔离器 Lambda
转到 `labFunctionisolator` Lambda → Add Trigger → SNS → 选中 `UnauthorizedExceptionNotification`。现在，只要这个 SNS 主题收到消息，该函数就会自动触发。
### 步骤 9 — 触发完整流水线
再次运行流量生成器 Lambda。这一次：
1. 40 次错误登录尝试 → 记录了 40 个 401 错误
2. CloudWatch 检测到 30 秒内总和大于 20 → 触发警报
3. 警报发布到 SNS 主题
4. SNS 调用隔离器 Lambda
5. Lambda 移除实例的 IAM 角色，并附加 `Isolated_SG`（一个没有入站或出站规则的安全组）
### 步骤 10 — 验证隔离
回到 EC2 → AppServer → Security 标签页：
- IAM Role: 已移除
- Security Group: `Isolated_SG`
实例仍在运行，但已被完全切断。没有入站连接，没有出站流量，也没有 AWS 权限。已准备好进行取证。
## 我的实际收获
**SSM 是这个实验中最让我感兴趣的部分之一。** 在此之前，我一直认为 SSH 是访问 Linux 服务器的常规方式。使用 Session Manager 直接从 AWS 控制台打开终端，而无需 SSH 密钥或开放端口，感觉更简单也更安全。
**日志摄取是一切的基础。** 如果日志没有流动，任何检测或自动化都无法工作。正确设置 CloudWatch Agent，选择正确的日志路径，并将配置保存到 Parameter Store，事实证明这比我预期的更为重要。
**指标过滤器比看起来更强大。** 使用 EC2 实例 ID 作为指标名称，通过警报 → SNS → Lambda 链路传递上下文，这个技巧是我以前没有想到的。它简单但有效，Lambda 不需要做任何额外的查找就能知道是哪个实例触发了警报。
**自动化响应。** 在做这个实验之前，我大多认为事件响应是一个手动过程。看到 AWS 在警报触发后自动隔离 EC2 实例，让我理解了云环境如何能够利用自动化做出更快速的响应。
## 这个实验的价值
这个实验涵盖了一种在云安全中频繁出现的模式：**检测 → 通知 → 响应**。这里的具体触发条件是 HTTP 401 错误，但同样的架构也适用于 GuardDuty 发现、CloudTrail 异常、异常的数据传输量——实际上，任何可以表示为 CloudWatch 指标或日志模式的内容都可以使用。
构建这个流程让我更清晰地了解了自动化事件响应如何融入云 SOC，也让我明白了为什么在云环境中，传统的“等待人工介入”模型无法扩展，毕竟手动调查和响应会耗费过多时间。
*作为 [Skill Builder](https://skillbuilder.aws) 上 AWS SimuLearn 事件响应实验的一部分完成*标签：401错误监控, AWS, CloudWatch, DPI, EC2隔离, Incident Response, IR, Lambda, Serverless, SNS告警, 云SOC, 免杀技术, 安全取证, 微服务安全, 暴力破解检测, 自动化隔离, 逆向工具