cruisethecity/aws-incident-response-honeypot

# AWS 云安全与事件响应模拟 ## 概述 本项目演示了一个完整的云安全事件响应生命周期。我使用 Terraform 预置了 AWS 基础设施，通过 Node.js 执行了模拟的暴力破解攻击，使用 Splunk 建立了安全运营中心（SOC）监控，并应用基础设施即代码（IaC）修复措施以保护受攻击的环境。 ## 阶段一：云架构预置 部署了一个自定义的 AWS 虚拟私有云（VPC），配置为捕获并记录网络遥测数据。 * **基础设施：** 自定义 VPC、公有和私有子网以及一个互联网网关。 * **资源：** Amazon RDS PostgreSQL 数据库，临时配置为 `publicly_accessible = true`，作为初始攻击面。 * **日志记录：** 配置了 AWS VPC Flow Logs，自动路由到 S3 存储桶以供 SIEM 摄取。 ## 阶段二：攻击模拟 设计并部署了一个 Node.js 脚本以模拟外部威胁行为者。 * 生成持续的身份验证请求以测试日志记录和监控阈值。 * 目标指向 PostgreSQL 端口 5432 和 SSH 端口 22。 ## 阶段三：SOC 遥测与跨团队交接 VPC Flow Logs 被路由到 S3 存储桶并摄取到 Splunk Enterprise 中，使安全运营中心（SOC）能够建立实时监控仪表盘。我还配置了自动化的事件通知，利用 `slack_alert.js` 将实时威胁数据直接推送到安全团队的通信渠道。  **威胁升级：** 检测到异常流量后，SOC 分析师升级了一份正式的事件报告，其中包含以下入侵指标： * **事件量：** 15,025 个被阻止的网络事件。 * **威胁来源：** 外部 IP 10.0.1.179 被识别出正在进行系统性端口扫描。 * **所需操作：** 云基础设施团队被正式请求对目标数据库执行即时网络隔离。 ## 阶段四：事件修复 收到来自 SOC 团队升级的工单后，我执行了基础设施修补，以缓解活跃威胁并保护环境。 1. 更新了 Terraform 的 `main.tf` 配置，将数据库参数修改为 `publicly_accessible = false`。 2. 应用了 Terraform 更新，将数据库实例迁移到私有子网。 3. 通过重新运行模拟验证了修补效果，结果出现网络超时，确认威胁已被消除。 ``` $ node attack_sim.js [+] Initiating connection to database... [-] Error: Connection Timeout. Network unreachable. [+] Remediation verified: Database successfully isolated in private subnet. ```

标签：AMSI绕过, AWS安全, ECS, GNU通用公共许可证, MITM代理, Node.js, Slack通知, SOC监控, SSH攻击, Terraform, 云架构, 威胁检测, 安全仪表板, 安全运营, 扫描框架, 插件系统, 日志收集, 暴力破解攻击, 漏洞利用检测, 网络隔离