一、前置条件与架构说明
配置前务必确认核心架构约束：
- 重要限制：AWS WAF 无法直接绑定 EC2 实例想要使用 WAF 实现应用层防护，流量路径必须满足：互联网 → CloudFront / ALB（应用负载均衡）→ EC2；WAF Web ACL 关联前端资源，流量清洗发生在请求抵达 EC2 之前。裸公网 EC2 无法直接挂载 WAF。
- 控制台界面持续更新，菜单名称、按钮路径存在小幅变动，配置时以线上界面为准。
- 技术支持：搭建多层安全架构、WAF 费用评估、挖矿入侵排查、安全基线整改，可联系云枢国际 /yunshuguoji 获取售前实例选型、架构方案以及售后配置指导。
二、网络访问控制与 IAM 权限自查（入侵第一道防线）
1、安全组最小权限配置
操作目标：收紧入站流量，缩小攻击暴露面，阻断自动化扫描与暴力破解。 排查与配置步骤： 1、梳理所有 EC2 绑定的安全组规则； 2、Linux SSH (22)、Windows RDP (3389)严禁开放 0.0.0.0/0，仅允许办公固定公网 IP、堡垒机 IP 接入；优先推荐使用 SSM Session Manager 免端口登录，彻底关闭远程管理端口对外暴露； 3、Web 业务端口 80/443，仅放行来自 ALB 安全组 ID 的入站流量，禁止直接对公网开放； 4、定期清理闲置、临时放行的 IP 规则。 预期效果：大幅降低 SSH/RDP 暴力破解、端口扫描攻击成功率。
2、IAM 角色、访问凭证与 IMDSv2 加固
操作目标：杜绝密钥泄露引发的横向渗透、挖矿木马滥用云资源权限。 排查步骤： 1、所有生产 EC2优先绑定最小权限 IAM 角色，禁止在代码、配置文件、镜像内硬编码 Access Key； 2、强制实例启用IMDSv2，关闭 IMDSv1，设置 hop-limit=1，防范 SSRF 漏洞窃取实例临时凭证； 3、定期清理长期闲置访问密钥，开启密钥轮换策略。
风险提示：大量挖矿入侵链条，都是通过 Web SSRF 读取 IMDSv1 凭证，调用 AWS 接口创建更多恶意实例。
三、系统级加固、挖矿木马检测与持续监控
1、操作系统基线加固
1）Linux 系统：禁用 root 远程登录；仅使用 SSH 密钥认证，关闭密码登录；定时执行 yum/apt 系统补丁更新； 2）定期排查/tmp、/var/tmp临时目录、crontab 定时任务、异常 SSH 公钥； 3）最小化安装服务，关闭无用端口与后台进程。
2、启用原生威胁检测体系，主动发现挖矿行为
推荐组合：Amazon GuardDuty + Security Hub + CloudWatch 告警 操作步骤： 1、全地域开启 GuardDuty，启用运行时监控 Runtime Monitoring、EBS 恶意软件防护，可以识别挖矿进程、矿池外联通信； 2、开通 AWS Security Hub，统一汇聚 GuardDuty、Inspector、配置合规基线告警； 3、CloudWatch 配置 CPU、网络流量异常突增告警，作为挖矿木马初步预警。 预期效果：当 EC2 出现异常外联矿池 IP、进程异常高负载、配置违反安全基线时，自动推送告警，实现入侵早发现。
四、AWS WAF 恶意爬虫拦截完整配置框架
恶意爬虫、AI 抓取脚本持续消耗 EC2 算力与出口带宽，容易引发服务卡顿、流量费用暴涨。基于 WAF 实现流量清洗，推荐分层规则组合方案。
WAF 部署流程
- 在 WAF 控制台创建 Web ACL；
- 将 Web ACL 关联前端资源：CloudFront 分发或者 ALB（无法直接选择 EC2）；
- 分层配置托管规则 + 自定义速率规则，建议按照下表组合部署：
| 规则类型 | 适用场景 | 预期防护效果 | 关键配置注意事项 |
| Amazon IP Reputation List | 拦截僵尸网络、代理恶意 IP | 自动屏蔽已知威胁源请求 | 规则优先级放置最顶部，优先拦截高危 IP |
| AWS Bot Control 托管规则 | 识别爬虫、自动化抓取、AI 机器人 | 区分验证爬虫与恶意非授权 Bot | 提供 Common/Targeted 两个防护等级；初期先用 Count 模式观测，防止误拦截搜索引擎 |
| 基于速率限制 Rate-based Rule | 抵御高频扫描、暴力爬虫 | 限制单 IP 短时间最大请求数量 | 5 分钟统计窗口，阈值依据业务正常访问峰值设定 |
| AWS 托管通用规则组 CRS | 拦截 SQL 注入、XSS 等 Web 攻击 | 基础 Web 漏洞防护 | 与爬虫规则搭配，实现攻击 + 爬虫一体化防护 |
实操建议：规则上线初期全部设置为 Count（仅统计不阻断），持续观测采样日志 3~7 天，确认无正常业务误拦截，再修改动作为 Block。
五、配置验证、日志排错流程
1、拦截效果验证
在外部服务器使用 curl 构造异常请求（伪造恶意 UA、高频循环请求），正常情况下 WAF 直接返回 403 Forbidden，流量不会转发至后端 EC2 实例。
2、误拦截排错方法
1）打开 WAF 控制台【采样请求 Sampled requests】，查看被拦截流量完整请求头、触发 ruleId； 2）定位引发误拦截的规则，临时调整为 Count 模式持续观察； 3）配置标签放行规则，对白名单业务 IP、正规搜索引擎 Bot 放行。
六、常见问题 FAQ
Q1：AWS WAF 可以直接保护裸公网 EC2 实例吗？
不可以。WAF 仅支持关联 CloudFront、Application Load Balancer、API Gateway。裸 EC2 想要接入 WAF，必须部署 ALB 作为流量入口，EC2 放入 ALB 目标组。
Q2：EC2 CPU 持续跑满，如何快速判断是否感染挖矿木马？
1、通过 CloudWatch 查看 CPU 指标持续高位；登录实例执行top/htop定位无名高占用进程； 2、执行netstat -antp检查是否大量外联矿池端口（3333、14444、5555 等）； 3、核查定时任务 crontab、/tmp 目录异常可执行文件； 4、启用 GuardDuty 恶意软件扫描，自动识别挖矿程序。
应急方案：感染严重时先实例隔离，制作快照留存取证，再基于干净加固镜像重建业务。
Q3：安全组已经只开放 80/443，为什么还会被植入挖矿后门？
安全组属于网络层防御，无法解析 HTTP 应用载荷。如果 EC2 内部 Web 程序存在 RCE 远程命令执行、文件上传漏洞，攻击者可以通过合法 80/443 端口传入恶意代码植入木马。网络层防护必须搭配 WAF 应用层防护 + 系统基线加固形成闭环。
Q4：开启 Bot Control 会不会拦截 Google、百度等正规搜索引擎？
Bot Control 可以自动识别 Verified Bot（验证可信爬虫），默认不会拦截主流搜索引擎。强烈建议先 Count 模式运行观察日志，确认搜索引擎标签正常放行后，再开启阻断策略，避免影响网站 SEO 收录。
Q5：EC2 安全组最小权限标准最佳实践是什么？
遵循默认拒绝原则。管理端口仅允许固定源 IP；Web 业务 EC2 安全组入站 80/443 只接收 ALB 安全组流量；杜绝 0.0.0.0/0 大范围放行规则；有条件的业务尽量将 EC2 部署在私有子网，不分配公网 IP。
