如何通过 GuardDuty 和 Systems Manager 自动化地进行恶意文件处置

自动化的威胁检测和响应，既可以减轻企业安全运营人员的运维工作投入、缩短响应时间，又可以满足网络安全等级保护 MLPS 和 PCI DSS 等安全框架的相关要求。在亚马逊云科技的云采用框架安全专业指导文件中，也明确提出了安全自动响应是一个关键的指导原则。

您可以通过使用亚马逊云科技的各种产品，构建您的云环境安全威胁的自动检测和响应的解决方案。例如，通过配置事件 Event 来触发 Lambda 功能来自动响应 GuardDuty 检测到的可疑或恶意的行为。根据不同检测结果的 Event 类型，您可以配置不同的自动化响应动作，包括修改网络访问控制规则、终止 EC2 实例或撤销 IAM 安全凭据等。

在本博客中，我们介绍如何使用亚马逊云科技的 Systems Manager 产品，自动化地响应（删除）被 GuardDuty 检测发现的恶意文件或病毒文件，以满足企业安全运营和合规的技术要求。

关于 GuardDuty 检测结果的自动响应的解决方案，亚马逊云科技已经有了一个对恶意 IP 地址自动拦截的方案，通过在 VPC NACL 和 WAF ACL 中自动添加规则的方式来实现，具体参考如下链接。本方案是针对 GuardDuty 检测出的恶意文件的自动响应的方案，通过 SSM 执行 shell 命令删除文件的方式来实现。为了能让客户同时使用这两个方案，本方案的代码（包括 Cloud Formation 和 Lambda 代码）都是基于前一个方案的代码框架来实现；客户只需要在 Event Bridge 中调整所需要自动响应的 event 类型，即可实现不同方案或两个方案同时使用的目的。

被参考的方案：

“How to use Amazon GuardDuty and AWS Web Application Firewall to automatically block suspicious hosts”

https://aws.amazon.com/blogs/security/how-to-use-amazon-guardduty-and-aws-web-application-firewall-to-automatically-block-suspicious-hosts/

1 使用到的核心产品介绍

亚马逊云科技的 GuardDuty 产品是一项威胁检测服务，它持续监控您的 AWS 账户和工作负载的恶意活动，并提供详细的安全检测结果。Malware Protection 恶意文件检测功能是 GuardDuty 产品下一项新发布的功能，帮助您检测 EC2 或容器实例上的恶意文件。这种检测活动不需要在 EC2 上部署 Agent，通过扫描 EBS 的方式来实现。能检测的恶意文件主要包括 trojans 木马、worms 蠕虫、crypto miners 加密货币挖矿程序、rootkits、bots 僵尸程序等。

GuardDuty 产生 findings 检测结果，这些检测结果说明了潜在的安全问题，包括受影响的 EC2 或容器负载、或者云环境的安全凭据。所有的检测结果都应该被尽快出来，比如调查受影响的 EC2 实例中的恶意文件、并手动或自动地删除这些恶意文件。

亚马逊云科技的 Systems Manager 是一个端到端的云资源管理产品，包括亚马逊云科技的云资源、也包括混合云或多云环境的云资源。Run Command 是 Systems Manager 产品的一个重要功能模块，使用此模块，您可以远程、安全地管理 EC2 实例的配置；包括自动地执行系统管理任务和执行一次性的配置变更。

2 方案整体

在本博客中，我们将向您暂时如何通过亚马逊云科技的 GuardDuty 和 Systems Manager 产品来自动响应 GuardDuty 实时检测的恶意文件。当 GuardDuty 检测到恶意文件（Malware）的存在时，会实时自动触发 Lambda 函数，进而通过 Systems Manager 在 EC2 上删除被发现的恶意文件；再删除文件之前，会对文件及其相关信息在 S3 和 DDB 中进行备份，便于在需要恢复被删文件的时候使用。

该方案的整体架构图如下所示：

步骤说明：

1. GuardDuty 检测到恶意文件的发现结果 finding。
2. EventBridge 通过 rule 配置 GuardDuty 发现结果的事件，类型是 execution:EC2/MaliciousFile。
3. EventBridge 收到类型为 execution:EC2/MaliciousFile 的 GuardDuty 发现结果，第一个 Lambda 函数被触发，并解析 GuardDuty 发现结果的内容。
4. 在第一个 Lambda 函数中，通过 Systems Manager 的 run command 在 EC2 上获取恶意文件及其属性信息；然后继续通过 Systems Manager 的 run command 命令把 malware 文件上传到 S3 进行备份。备份恶意文件及其属性信息，是为了误删除操作后手工可以进行恢复操作。
5. 在第一个 Lambda 函数中，再在 DDB 中初始创建一个新的 Item，保存 malware 的 profile 信息，包括 EC2 实例 id、文件路径、文件属性信息等，并把这个 Item 状态设置为“created”。
6. 步骤 4 中的 Systems Manager 的 run command 命令异步执行的结果，会自动在 S3 的 SystemsManagerOutputPrefix 目录中创建一个执行结果的文件；该文件的写入事件（也是 EventBridge 的 event），会触发第二个 lambda。
7. 第二个 Lambda 开始工作，首先从 S3 下载为备份 malware 文件所执行的 run command 命令的执行结果的文件；取的是步骤 5 的结果，如果成功，那么下一步。
8. 第二个 Lambda 函数，更新 DDB 的 item 为“archived“状态，代表 malware 文件在 S3 上备份成功。
9. 根据 malware 文件名从 DDB 中获取文件路径和 EC2 实例 id；根据 EC2 实例 id，通过 Systems Manager 的 run command 在 EC2 上删除恶意文件。
10. 更新 DDB item 为“deleted”状态，代表恶意文件在 EC2 上成功删除。
11. 通过 SNS，发送一个邮件通知，说明 EC2 上发现的恶意文件，已经被成功删除。

3 本方案中涉及到的 GuardDuty 发现的结果

GuardDuty finding 中有如下 8 种和 malware 相关的类型，本方案当前只做 EC2 类型的恶意文件 finding（即 Execution:EC2/MaliciousFile）的自动响应；如需对其他类型 finding 的自动响应，可按需自行更改 Event Bridge 的 Rule 即可。

• Execution:EC2/MaliciousFile，
• Execution:EC2/SuspiciousFile
• Execution:ECS/MaliciousFile
• Execution:ECS/SuspiciousFile
• Execution:Container/MaliciousFile
• Execution:Container/SuspiciousFile
• Execution:Kubernetes/MaliciousFile
• Execution:Kubernetes/SuspiciousFile

本方案中通过后续步骤的 CloudFormation 创建的 EventBridge Rule 的具体内容如下，即 EventBridge 检测到 Execution:EC2/MaliciousFile 类型的 GuardDuty 发现结果后，触发第一个目标 Lambda 函数。

{
  "source": ["aws.guardduty"],
  "detail": {
    "type": [{
      "prefix": "Execution:EC2/MaliciousFile"
    }]
  }
}

4 Prerequisites

在部署本方案前，需要：

1. 在运行本方案的账号中，需要有一台能访问公网的 EC2，用来在其中下载恶意文件、从而触发告警。
2. 在 Systems Manager 中启用了 Host Management 功能；可以通过 Quick Setup 来启用，如下图：

配置好 Quick Setup 后，验证一下 Host Management 功能是否可以正常工作。在 EC2 的 Console 的实例管理页，选择“Connect”，然后选择“Session Manager”Tab 页，如果没有提示错误、且可以成功“connect”进 EC2 示例即代表功能正常。

3. 确保打开 GuardDuty for Malware Protection 的功能，且推荐打开“如果检测到恶意软件，则保留扫描的快照“的功能，以避免恶意文件自动删除产生的误删除现象；如果出现误删除情况，可以通过备份的文件进行文件级别的恢复，或者通过保留的快照来做整体恢复。

4. EC2 的 IAM role 需要有 S3 的读写权限，可以限定具体的 S3 bucket。在现有 EC2 的 Profile 的 IAM Role 上，增加 AmazonS3FullAccess 的 Policy。

5 方案部署和概览

本章节中主要包括如下步骤的内容：

1. 通过 CloudFormation 模版来部署本方案所需要的各种资源；
2. 检查资源是否被成功创建；
3. 在 EC2 上模拟恶意文件；
4. 确认恶意文件被从 EC2 上删除；
5. 确认恶意文件被成功备份到 S3 的备份目录中；
6. 确认 DDB 中备份的恶意文件信息及“deleted”状态；
7. 如果是只测试，可以通过 CloudFormation 模版来释放相关资源。

Step 1: 通过 CloudFormation 来创建资源

1、先创建一个 S3 bucket，命名为 guardduty2nacl-xxxx；S3 bucket 需要开启 EventBridge 的 notifications 开关，用于产生 event。

2、从如下 github 地址 https://github.com/aws-samples/amazon-guardduty-waf-acl-ssm 下载 Lambda 代码及 CloudFormation template 的代码，直接下载整个目录。

3、把下载的代码等整个目录放到创建的 S3 bucket 中。

4、执行 CloudFormation template，template 文件在下载的代码库的 templates 目录。

5、填写 stack name 和邮件地址，邮件地址用来接收告警邮件；在 CloudFormation 执行完之后，会收到需要订阅 SNS 的邮件，需要按照邮件内容来订阅，这样后续才能正常接收告警。其他参数可以保持缺省值。

6、指定 artifacts 的目录，即 Lambda 代码所在 S3 bucket 的 bucket name 和 prefix；其他两个参数可以保持缺省值。

7、然后其他都缺省，执行 template。

备注：现在的 CloudFormation 中创建的 CloudFrontWebACL 在 China region 环境中运行需去掉，因为 China region 没有 CloudFront。

Step 2: 检查资源的创建情况

1. EventBridge rule1，guardduty2nacl7-GuardDutytoACLEvent-****，之前方案中创建的 event rule，初始设置为 Disable 状态，即不启用该功能；如果需要启用，可以手工在 EventBridge 中把 Disable 改为 Enable，或者通过修改 CloudFormation 的 template 来实现。
2. EventBridge rule2，guardduty2nacl7-GuardDutytoSSMEvent-****，本方案中创建的 event rule，用于触发第一个 Lambda 函数。
3. EventBridge rule3，guardduty2nacl-S3ObjectCreatedbySSMRuncommandEvent-****，本方案中创建的 event rule，用于触发第二个 Lambda 函数。
4. Lambda function，guardduty2nacl7-GuardDutytoACLLambda-****，在之前的 Lambda 上迭代了本方案的功能，还是同一个 Lambda 包，即第一个 Lambda 函数。
5. Lambda function，guardduty2nacl7-GuardDutytoSSMLambda-****，第二个 Lambda 函数。
6. DDB table，guardduty2nacl7-GuardDutytoACLDDBTable-****，之前方案的创建的 DDB 表。
7. DDB table，guardduty2nacl7-GuardDutytoSSMDDBTable-****，本方案中创建的 malware profile 的 ddb 表。
8. SNS，guardduty2nacl7-GuardDutytoACLSNSTopic-****，与之前方案共用的 SNS topic。

Lambda function guardduty2nacl7-GuardDutytoACLLambda-**** 的环境变量包括：

Lambda function guardduty2nacl7-GuardDutytoSSMfindingLambda-**** 的环境变量包括：

Step 3: 在 EC2 中下载挖矿软件来触发 EC2 malware 事件

1、在 EC2 上执行如下命令，会下载一个恶意文件 cnrig-0.1.5-linux-x86_64；该文件是一个挖矿程序，此处仅作演示用，并不真正执行挖矿动作。

wget -o my_miner_test https://github.com/cnrig/cnrig/releases/download/v0.1.5-release/cnrig-0.1.5-linux-x86_64

2、然后 ping 一下如下域名，用于触发 GuardDuty 检测的 vpc flow 流量、产生 GuardDuty finding：

ping xmr.pool.minergate.com

该步骤执行完后，需要等一段时间，GuardDuty 会根据网络流量检测出告警；然后 GuardDuty 会自动触发在 EC2 上的 Malware 检查，检查到 Malware file 后，还会有一个告警。

如下图是 GuardDuty 的告警：

如下图是 GuardDuty 的 malware 检测告警：

Step 4: Confirm the malware file is removed in the EC2

登录到 EC2 实例，会发现 Step3 中下载的文件 cnrig-0.1.5-linux-x86_64，在 EC2 的目录中被删除。

Step 5: Confirm the malware file in the S3 bucket

在 S3 的 bucket 中的 MalwareBackup/目录下，会看到备份的挖矿程序文件：

Step 6: Confirm the entry in the DDB

被删除的 malware 文件的属性信息，会被保存到 DDB 中；如果有需要手工恢复的需要时，可以参考这些属性信息来恢复。

Step 7: Release the resources by CloudFormation template

演示完成后，在 CloudFormation 中删除 stack，即可释放所有资源。

6 结论

通过本博客，您已经学到了通过 SSM 来自动处理 GuardDuty 发现的恶意文件；除了在 EC2 上删除该恶意文件之外，本博客也把被删除的恶意文件及文件属性进行了备份，便于有需要时来进行恢复。

本博客可以结合本文引用的博客来同时使用，同时满足自动阻断 IP 地址和删除恶意文件的需求。

本篇作者