Gayatri-Nakar/aws-cloud-security-lab

# AWS 云蜜罐：攻击面分析实验室 ## 目标 我希望获得云安全和日志分析的实战经验。我构建了一个故意配置不当的 AWS EC2 实例，上面运行着一家虚构公司的内网，将其在互联网上暴露了 8 个小时，收集了所有能收集到的各层级日志，并对攻击情况进行了分析。这个代码库包含了一切：基础设施代码、Web 应用程序以及分析 pipeline。 该实例运行着 Apache、PHP 和 SQLite，托管了一个虚构的“Meridian Corp”员工门户，包含登录页面、管理员板块、文档下载和搜索功能。其安全组（security group）被故意配置错误：SSH、HTTP 和 HTTPS 均对 0.0.0.0/0 开放。这种错误配置正是本实验的核心目的。 ## 代码库结构 ``` aws-cloud-security-lab/ ├── terraform/ # Full IaC for the lab environment │ ├── main.tf │ ├── vpc.tf │ ├── security_group.tf # The intentional misconfiguration │ ├── ec2.tf # Auto-terminates after 8 hours │ ├── iam.tf # Least-privilege instance role │ ├── s3.tf # Hardened log bucket │ ├── cloudtrail.tf │ ├── flow_logs.tf │ ├── guardduty.tf # Optional, disabled during this run │ ├── user_data.sh.tpl # First-boot deployment script │ └── terraform.tfvars.example │ ├── webapp/ # The fake Meridian Corp employee portal │ ├── public/ # What Apache serves to the internet │ │ ├── index.php │ │ ├── login.php │ │ ├── admin.php │ │ ├── search.php │ │ ├── docs.php │ │ ├── contact.php │ │ └── policy_documents/ │ ├── db/ # SQLite schema, outside the web root │ └── scripts/ # Setup and log sync helpers │ ├── analyze_logs.py # Five-phase log analysis pipeline └── README.md ``` ## 分析 pipeline 的功能 `analyze_logs.py` 从 S3 获取原始日志，并通过五个阶段对其进行处理： 1. **净化（Sanitize）** -- 在进行任何其他数据处理之前，掩码自身的 IP 地址 2. **解析（Parse）** -- 将所有七种日志源标准化为同一个 SQLite 表 3. **关联（Correlate）** -- 跨日志源按源 IP 分组，以发现多源攻击者 4. **映射（Map）** -- 使用 MITRE ATT&CK 技术 ID 标记观察到的行为 5. **报告（Report）** -- 编写 Markdown 结果报告 它处理的日志源包括：Apache access log、Apache error log、Linux auth.log、自定义 PHP 应用程序日志、SQLite 登录尝试快照、VPC Flow Logs 和 CloudTrail。 ## 映射至 MITRE ATT&CK 的发现 在这 8 小时的窗口期内，该实例记录了来自 5,405 个不同源 IP 的 14,711 起事件。其中大部分是互联网背景噪音。值得关注的发现如下： | 技术 | 实际发生的情况 | |---|---| | T1595.002 Active Scanning: Vulnerability Scanning | 两个 IP 以同步波次（间隔 5 小时，时间戳精确到秒）运行了一份完全相同的多 CVE 利用清单。这是一次扫描操作，使用了两个源地址。探测了 CVE-2021-41773、CVE-2017-9841、CVE-2018-20062、pearcmd RCE 和 Docker API。均未成功。 | | T1595.001 Active Scanning: Scanning IP Blocks | Censys 和 Palo Alto Xpanse 均在第一个小时内表明身份并对该实例进行了索引。 | | T1190 Exploit Public-Facing Application | 来自上述同步扫描器的特定 CVE payload。 | | T1046 Network Service Discovery | 两个 IP 进行了系统性的端口扫描：一个扫描了 VNC 范围（5900-5999，62 个 TCP 端口），另一个扫描了 UDP 端口 4051-4099。两者均被安全组拒绝。 | | T1083 File and Directory Discovery | 一个使用真实 iPhone Safari 用户代理的 IP 浏览了该站点并下载了一份文档。这可能是一个真实的人类用户发现了这个暴露的 IP。 | 同样值得注意的还有两件没有发生的事情：没有任何人提交过一次登录表单，也没有发生经典的 SSH 暴力破解。确实发生的 SSH 活动均属于侦察、抓取 banner 以及来自四个 IP 的身份验证前断开连接，其中包含一次中止的 root 登录尝试。 ## 分为三部分的系列文章 本项目在 Medium 上通过三篇文章进行了记录： - **第 1 部分：构建云蜜罐** -- 目的初衷、基础设施设计、Web 应用程序、遇到的 Bug 以及我是如何使其运行的 - **第 2 部分：设计日志净化与标准化 Pipeline** -- 分析 pipeline 的工作原理及其结构设计背后的原因 - **第 3 部分：技术发现报告** -- 全面分解针对该实例的攻击行为，结合所有日志源进行关联并映射至 ATT&CK [在 Medium 上阅读](#) *（发布后添加链接）*

标签：AWS, DPI, ECS, PB级数据处理, Terraform, 安全运维, 漏洞探索, 蜜罐, 证书利用, 逆向工具