AWS WAF（Web 应用防火墙）怎么用？有效防御 SQL 注入、跨站脚本与黑客恶意刷量

       在公网环境里，任何一个对外的 Web 服务、APP 接口或者电商网站，每天一开门营业，面对的就不仅是真实的客户，还有密密麻麻的黑客扫描器、恶意刷量爬虫、以及各种针对应用层漏洞的自动化攻击。

很多技术团队防范意识不够，以为服务器装个杀毒软件、安全组关掉不用的端口就万事大吉了。结果就是：核心数据库被一条简单的 SQL 注入语句直接脱裤洗劫、网页被植入恶意脚本（XSS）导致用户资金被盗、或者营销活动接口被黑产用黑客工具在几分钟内薅干了几十万的预算。

在传统架构里，对付这种应用层（OSI 七层模型中的第七层）的恶意攻击，需要改动大量的后端代码或在 Nginx 层面写一堆极其复杂的拦截规则，运维成本高且极易误杀正常请求。AWS亚马逊云代支付

而在亚马逊云上，最优雅、最省心的防御兵器就是 AWS WAF（Web Application Firewall，Web 应用防火墙）。它就像一个守在服务器最前线的“魔鬼安检员”，在请求还没到达你的后端服务器之前，就在边缘把各种暗器、毒药和恶意刷量大军死死挡在门外。

今天这篇深度教程不扯高深的安全黑话，用最接地气的实战视角，带你彻底收服 AWS WAF。

核心原理：AWS WAF 守在哪里？它是怎么工作的？

在配置之前，我们先搞清楚这个“安检员”在你的架构里到底站在什么位置。AWS WAF 不能直接挂在单台 EC2 云服务器上面，它是通过“寄生”在以下三个核心的流量入口层来发挥作用的：

• Application Load Balancer (ALB)： 你的应用负载均衡器。
• Amazon CloudFront： 你的全球 CDN 边缘节点。
• Amazon API Gateway： 你的微服务接口网关。

AWS亚马逊云代支付当一个美国黑客精心构造了一个包含恶意代码的请求发送过来时：

1. 流量首先到达 CloudFront CDN 边缘节点（或者 ALB）。
2. AWS WAF 瞬间介入。 它会用你配置好的“防御规则集（Web ACL）”，像过 X 光机一样去扫描这个请求的 Header（请求头）、Query String（URL参数）、Body（请求体）以及 IP 来源。
3. 如果匹配到黑客特征，WAF 直接在边缘吐出 403 Forbidden 拦截，攻击流量连你后端服务器的毛都碰不到，更不会消耗你任何的 CPU 和业务带宽。

第一阶段：三步落地 AWS WAF 核心防御（实战抄作业）

配置 AWS WAF 的核心是创建一个 Web ACL（Web 访问控制列表）。我们直接以“保护国内或海外的 ALB 负载均衡”为例，进行防御部署：

第一步：新建 Web ACL 并绑定入口

1. 登录 AWS 管理控制台，搜索并进入 WAF & Shield 控制台。
2. 在左侧导航栏点击 Web ACLs，然后点击右侧的 Create Web ACL。
3. 关键参数配置：Resource type： 如果你是想保护 CloudFront CDN，选 Global (CloudFront)；如果你是保护负载均衡，选 Regional resources 并选择你服务器所在的地域（如 us-west-2 美西俄勒冈）。Name： 给它起个清爽的名字，如 prod-web-waf-acl。
4. 在下方 Associated AWS resources 处，点击 Add AWS resources，勾选你正在跑着 Web 服务的 ALB 实例。点击 Next。

第二步：一键配置 AWS 官方托管规则集（封死 SQL 注入与 XSS）

AWS 官方非常贴心地帮我们写好了应付常规黑客攻击的“顶级防弹衣”，叫做 AWS Managed Rule Groups。你不需要懂高深的网络安全对抗，直接一键启用即可：

1. 在 Add rules and rule groups 页面，点击右侧的 Add rules -> Add managed rule groups。
2. 展开 AWS managed rule groups，你会看到一堆官方维护、实时更新的规则。强烈建议闭着眼睛勾选以下三款“核心主力”：Core rule set (CRS)： 核心规则集。这是 WAF 的灵魂，里面包含了对绝大多数常见漏洞（包括 OWASP Top 10）、本地文件包含（LFI）等常规攻击的防御。SQL database (SQLi) rule set： SQL 注入专项防御。专门盯着请求里的数据库特殊字符，死死焊死后端的数据库大门。Known bad inputs rule set： 漏洞扫描器防御。很多黑客喜欢用自动化的开源工具（如 SQLmap）来盲测你的网站，这个规则能精准识别这些工具的探针并直接封杀。
3. 点击 Add rules 保存。

第三步：开启速率限制（Rate-based Rule）—— 专治黑客恶意刷量

封死了漏洞攻击，接下来就要对付最让人头疼的恶意刷量、撞库、爬虫和 CC 攻击。

黑客为了打满你的带宽或者刷爆你的短信/验证码接口，会动用大量的肉鸡或者代理 IP 在短时间内疯狂并发。AWS WAF 的 Rate-based Rule（基于速率的规则） 是降服它们的最强手段。

1. 在规则页面，点击 Add rules -> Add my own rules and rule groups。
2. 配置参数：Rule type： 勾选 Rate-based rule。Rate limit（速率红线）： 设定一个单个 IP 在 5 分钟内的访问上限。例如，对于普通的 Web 网站，设置 2000 即可。如果是极其敏感的注册/登录接口，可以压缩到 100 - 300。Action： 选择 Block（直接拦截）或 Count（只记录不拦截，通常用于前期观察）。
3. 这样，一旦有某一个海外 IP 在 5 分钟内疯狂请求超过了你设定的红线，AWS WAF 会立刻给这个 IP 戴上上手铐，接下来的访问全部赏它一个 403，通常 5 到 10 分钟后行为正常了才会自动解封。

第二阶段：高手进阶——如何减少 WAF 的“误杀率”？

安全领域有一个永恒的痛点：防守越严，越容易误杀好人。 比如，你公司的财务员工在后台上传一个包含财务公式的 Excel 表格，WAF 的 SQL 注入规则可能误认为这是黑客代码，直接把财务大姐拦截了。

老练的架构师在 WAF 上线的第一天，会用下面这两个技巧来精细化运营：

1. 先开启“观察模式（Count）”走火测试

新买的防弹衣不要立刻拉去挡子弹。在生产环境刚添加完规则时：AWS亚马逊云代支付

• 避坑大招： 先将所有刚加入的 Managed Rules 的 Action 改为 Count。
• 在这个模式下，WAF 发现嫌疑请求时不会真的去拦截它，而是仅仅在日志里盖一个“嫌疑犯”的图章，让请求继续通过。
• 跑个 3 到 7 天，去控制台查看 WAF 的 CloudWatch 采样日志（Sampled requests）。如果发现很多正常用户的正常操作也被盖了章，说明规则过激了。此时可以在控制台针对特定的子规则进行 Exclude（排除），洗净误杀后，再正式把 Action 切换为 Block。

2. 精准开辟“绿色通道（IP 白名单）”

如果你们公司有专门的合作伙伴、或者是内部办公区的公网 IP 需要频繁调用接口，千万别让他们去跟黑客一起排队过安检。

• 在 WAF 手动创建一个 IP Set，把你公司的固定公网 IP 输进去。
• 在 Web ACL 里添加一条自定义规则：如果请求来自这个 IP Set，Action 直接设置为 Allow（放行），并且把这条规则的优先级（Priority）提到最顶上的 0 号位置。这样内部流量就可以直接刷脸进场。

第三阶段：看清 AWS WAF 的计费账本（它贵吗？）

AWS WAF 的计费非常清爽，它没有任何隐形的服务器开销，采用的是固定底座费 + 流量处理费的模式：

1. Web ACL 底座费： 每个 Web ACL 每月固定收取 $10。
2. 规则（Rule）费： 你在 Web ACL 里每添加一条规则（比如勾了一个 CRS 集，或者自己写了一个限速规则），每条规则每月收取 $1（AWS 官方自带的托管规则集大部分免费提供，不额外加钱）。
3. 请求处理费： 真正的弹性支出，每处理 100 万个请求，收取 $0.60。

💡 账本精算小案例： 假设你建了一个 Web ACL，挂了 3 条基础官方规则加 1 条限速规则（共 4 条 Rule），你的网站一个月总共有 2000 万次请求。固定月租：$10 (ACL) + $1 * 4 (Rules) = $14请求费：(2000万 / 100万) * $0.60 = $12总账单：一个月只需 $26 美元（约合人民币 180 元）。 用两张电影票的钱，就给公司的核心业务请了一个 24 小时贴身保护、永不疲倦的顶级数字保镖。

总结与防身口诀

在现代云原生架构里，把安全防御寄托在后端代码上是极度危险且落后的。利用 AWS WAF，我们在最外层的网络边缘就完成了洗涤恶意流量的壮举。最后送你四句老手都在用的 WAF 口诀：

1. 入口第一先挂锁： WAF 挂在 ALB 或 CDN 前，黑客探针边缘截。
2. 官方托管全勾上： CRS、SQLi 加 注入，主流漏洞一键补。
3. 限速规则压刷量： 敏感接口设红线，恶意爬虫直接闪。
4. 先 Count 后 Block： 生产发布别大意，先看日志再升级。AWS亚马逊云代支付