隔离遭入侵的计算实例

如果 GuardDuty 或您的监控发现某个 EC2 实例正在发起恶意出站连接、挖掘加密货币或扫描您的网络，就需要将其隔离。

隔离会将该实例与其他所有资源分开，使其无法继续造成危害，同时保留实例以便调查，而不是直接清除证据。

最彻底的隔离方式，是将该实例的安全组替换为一个专用于取证的安全组，其中不设置入站规则，最好也不设置出站规则。

由于安全组具有状态感知能力并且附加在实例上，这样无需触碰子网中的其他资源，就能立即切断几乎所有新连接。

停止或终止实例会清空 RAM，而许多恶意软件驻留在其中，也可能销毁攻击者留下的痕迹。

隔离会让实例保持运行但与外界隔离，这样您就可以创建磁盘快照、转储内存并观察其行为。只有在安全捕获证据后，才应清除实例。

遭到入侵的实例通常会通过实例配置文件携带 IAM 角色，攻击者可能正在窃取这些临时凭证并在其他位置使用。

请替换或移除该角色，并撤销活跃会话，使被盗凭证在所有 AWS 服务中停止工作，而不仅仅是在该实例上失效。

请立即为每个已附加的EBS卷创建快照，以冻结磁盘状态；如果您的工具支持，也请捕获内存。

请为这些工件添加隔离证据标签。在单独的取证实例上以只读方式挂载快照副本，可以在不修改原件且不冒再次感染风险的情况下进行调查。

如需增加一层防护，您可以在子网的网络 ACL中，为该实例的私有 IP 添加拒绝规则。

NACL 是无状态的，并且作用于子网边界，因此可以拦截安全组更改可能遗漏的路径。请将其作为兜底措施，而不是主要控制手段。

如果该实例位于 Elastic Load Balancer 后方，或属于 Auto Scaling 组，请将其注销，以停止向其转发流量。

请将 Auto Scaling 实例置于备用状态，或将其从组中分离，以免该组将其判断为运行状况不佳的主机并替换实例，从而终止您的证据。

在大规模环境中，手动步骤过于缓慢。一种常见模式是：将 GuardDuty 调查结果发送到 EventBridge 规则，再发送到 Lambda；Lambda 会替换安全组、创建卷快照、移除角色并为实例添加标签。

这样可以将多步骤响应转变为单个自动化操作，并在检测到威胁后的几秒内触发。

隔离可以争取时间，让您调查攻击者是如何入侵的。请检查 CloudTrail、VPC 流日志和主机上的日志，找出入口点——可能是暴露的端口、未修补的漏洞或被盗凭证。

如果不知道根本原因，重建的实例仍可能以完全相同的方式再次遭到入侵。

捕获证据并了解根本原因后，请使用干净且已修补的 AMI替换实例，而不是清理已感染的实例。

您几乎无法保证后门已被彻底移除。使用可信映像重新部署，比清理遭到入侵的主机更快，也可靠得多。

请为隔离实例及其快照添加清晰的标签，例如 Status=Quarantine 和事件 ID，避免自动化流程或操作员意外将其恢复服务，或删除证据。

请在事件记录中持续跟踪该实例直至事件关闭，并确认威胁已得到遏制，取证工件也已妥善保留。

请选择正确的凭证处理步骤。

通过替换为拒绝所有流量的安全组来隔离遭到入侵的 EC2 实例，同时保持实例运行；然后在进行任何更改前创建 EBS 卷快照并捕获内存。移除实例配置文件角色并撤销活跃会话，使被盗凭证失效；将实例从负载均衡器和 Auto Scaling 中移除，并添加 NACL 兜底规则。通过 GuardDuty 自动执行整个流程，调查根本原因，并使用可信 AMI 重建实例。