AWS WAF（配合 CloudFront）基础防护配置：免费能做什么、要不要开日志、如何限制危险方法

前提：你已经把站点接入 CloudFront（域名 Alias 到 CloudFront），本篇只讲 AWS 侧的防护（WAF/行为）。

1）你看到的 "CreatedByCloudFront-xxxx" 是什么？能直接用吗？

当你在 CloudFront 创建分配并在向导里启用 Security（或默认安全防护）时，AWS 可能会自动生成一个 Web ACL，名字类似：

CreatedByCloudFront-xxxxxxx

✅ 可以直接用，它已经绑定到了你的 CloudFront Distribution（你截图右侧写着已包含 CloudFront 发行版）。

2）默认 Web ACL 里这些规则是否"配置正确"？

你截图里默认规则一般包括（名称可能略有不同）：

RateBasedRule（限速）：按 IP 触发阈值（例如 300/5min）
AWSManagedRulesAmazonIpReputationList：拦截信誉差 IP
AWSManagedRulesCommonRuleSet：通用 Web 漏洞/异常请求
AWSManagedRulesKnownBadInputsRuleSet：已知恶意输入

✅ 这些属于"基础防护"，能挡住一部分扫描、恶意 UA、常见注入/探测请求。

⚠️ 但它不是"洪水/全能 DDoS 防火墙"，大流量或复杂攻击仍可能穿透或把回源压垮。

3）一定要做的关键动作：把规则从 Count 改成 Block

你截图里 RateBasedRule 显示"在 Count 模式下运行"，这表示：

Count：只统计，不拦截
Block：直接拦截

操作步骤

WAF & Shield → Web ACL → 进入 CreatedByCloudFront-xxxx → Rules（规则）：

逐条点开规则（尤其是 RateBasedRule）
Action 从 Count 改为 Block
保存

✅ 建议：

RateBasedRule：直接 Block（因为你现在明显遭遇大规模扫描/探测）
其它 Managed Rules：如果怕误伤，可先 Count 观察 10~30 分钟，再切 Block

4）"拦截危险方法（PUT/PATCH/DELETE）"在哪里设定？

结论

WAF 免费层里，做"HTTP 方法"条件匹配是受限的（你截图里"HTTP 方法"是灰色，提示需升级计划）
✅ 最推荐且不额外付费的办法：在 CloudFront Behavior 里限制 Allowed HTTP methods

5）在 CloudFront 行为里限制危险方法（推荐做法）

目的：让 CloudFront 直接拒绝除 GET/HEAD 之外的请求（或只给少数路径放开 POST）。

5.1 站点纯展示/导航类（最强硬）

CloudFront → Distribution → Behaviors：

Default behavior（*）
Allowed HTTP methods：选择 GET, HEAD
Viewer protocol policy：Redirect HTTP to HTTPS
其他先默认

这样会在边缘层直接挡掉大多数扫描里出现的 PUT/PATCH/DELETE/OPTIONS 等请求。

【图占位：Behavior 里 Allowed HTTP methods 选 GET, HEAD】

5.2 如果站点确实有 POST（如 WP 登录/接口）

建议拆分行为（按路径区分）：

Default (*)：GET, HEAD
/wp-login.php*：GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE（或至少包含 POST）
/wp-admin/*：同上（如果需要）
/wp-json/*：如果用到 REST API，放开 POST/OPTIONS

注意：你截图里是在"Create behavior"页面，Allowed methods 是可以选到包含 POST/PUT 等的，这个不需要 WAF 专业版。

【图占位：按 wp-login/wp-json 创建单独行为放开 POST】

6）WAF 的"日志记录和指标"要不要开？

你截图 Web ACL 列表里"日志记录和指标：未启用"。

建议

指标（Metrics）建议开启：几乎没有操作成本，用于看拦截量、Top IP、Top Rule 命中
日志（Logging）按需开启：日志会落到 S3 / CloudWatch Logs / Kinesis，可能产生费用与存储压力

7）验证防护是否生效（最小测试方案）

7.1 验证 CloudFront 行为拦截方法

在本机 PowerShell：

powershell 复制代码

# 期望：GET/HEAD 正常 200
iwr https://wwwnav.com -Method Head -TimeoutSec 10

# 期望：如果 Default behavior 仅允许 GET/HEAD，则 POST/PUT 应被 CloudFront 拒绝（403/405）
iwr https://wwwnav.com -Method Post -TimeoutSec 10
iwr https://wwwnav.com -Method Put  -TimeoutSec 10
iwr https://wwwnav.com -Method Patch -TimeoutSec 10
iwr https://wwwnav.com -Method Delete -TimeoutSec 10

你之前遇到的 curl -I ... --max-time 在 PowerShell 里会被当成 Invoke-WebRequest 参数解析而报错。

用 iwr ... -TimeoutSec 这种 PowerShell 原生命令更稳。

【图占位：PowerShell 测试 GET/HEAD/POST 结果】

7.2 验证 WAF 是否在拦截

WAF → Web ACL → Sampled requests / Metrics：

看 Blocked requests 是否上升
看 RateBasedRule 是否命中并拦截

【图占位：WAF Metrics/采样请求看到 Block 增长】

8）你日志里大量 499 / 405 的含义（快速解释）

405 ：源站（Nginx/应用）不允许该方法（比如对 / 发 PUT）
499：Nginx 记录的"客户端主动断开连接"
- 当 CloudFront/攻击方超时或中止连接时，源站可能记录 499
- 说明：大量扫描请求仍在打到源站（或回源），需要在 CloudFront/WAF 更早挡住

9）最终落地建议（免费方案能做到的上限）

WAF：把默认规则里能 Block 的尽量 Block（至少 RateBasedRule Block）
CloudFront 行为：
- Default：GET/HEAD
- 仅对必须的路径放开 POST（wp-login/wp-json 等）
开启 Metrics 观察；日志仅短期开启定位问题
源站 Nginx 仍建议保留基础限制（但本文不展开）

常见问题

Q1：为什么 WAF 里 "HTTP 方法" 是灰色？

A：你当前 Web ACL 使用的是 CloudFront 统一费率的免费计划能力，细粒度的某些请求组件匹配（如 HTTP 方法）会提示升级。解决办法是用 CloudFront Behavior 限制方法。

Q2：我已经有 CreatedByCloudFront Web ACL，是不是就算"开了 WAF"？

A：要确认两点：

Web ACL 是否已关联到你的 CloudFront Distribution（你截图已显示关联）
规则是否在 Block（不是 Count）
只要规则仍是 Count，就等于"没拦截"。

复制代码