手把手教你如何配置 AWS WAF 入门

1 前言

题图是Security Automations for AWS WAF 架构图。描绘了 AWS WAF 如何筛选对各种 AWS 资源的 Web 请求、存储来自 AWS WAF 的日志以及监控威胁日志。

当你开始使用WAF（Web Application Firewall）时，你便能为其后的内容提供保护。WAF不仅可以配置复杂的规则来判断请求是否为攻击或不需要的流量，还有另一种有趣的玩法：通过AWS Lambda进行动态控制。

想象一下，如果某个IP正在进行多次恶意请求，仅仅拦截单次请求可能会被对方轻易绕过。这时，我们可以借助AWS Lambda的WAF日志分析器或CloudWatch等工具进行感知，并动态地添加IP声誉列表来控制攻击源或向管理员发出警报。

AWS WAF与亚马逊的其他服务完美结合，玩法多样，绝不仅仅是静态的防护盾牌。当然，在此之前，你需要对WAF有一个基本的了解。接下来，我将通过详细的步骤，指导你配置一个全新的WAF作为起点。

2 新手第一步

假设你已经拥有一个空白的WAF：
第一步找到你的WAF：

继续让我们选择它，你的可能叫别的名字，显然这并不重要：（如果你的伙伴没有为你配置需要你自行创建一个ACL）

左侧的功能分页说明一下：

编辑规则主要看 Rules：

2号位置就是规则区了，3号可以手工添加一条规则：

3 实践

3.1 了解托管规则

我们先手工添加一条规则尝试：
你有两个选项：
Add managed rule groups:
即：添加托管规则
Add my own rules and rule groups:
添加自定义规则

我们会发现AWS WAF的规则是串型执行：Priority一列就是顺序。
这里列出的是AWS 付费（2023年12月31日）的3种托管规则集：

这里列出11种 AWS 免费的托管规则：

此外还提供了一些三方不同厂商提供的付费托管规则，OWASP TOP10等应有尽有：

总之托管规则应有尽有，但因为其面向通用场景，而不能完全适配我们自己的业务，还是需要我们动手DIY一些适合我们的规则。

3.2 编写自己的DIY规则

点击： Add my own rules and rule groups 添加自定义规则

默认是 Rule visual editor: 即可视化编辑器：

点击 Rule JSON editor 进入JSON编辑器，此模式的优点是：

• 方便快速复制
• 方便多级嵌套条件编写
  可视化只支持一层的逻辑判断，举个例子：
  如果 http.method == “options” ，则继续判断 如果 http.url 开头是 “/api” 则允许
  因为涉及两级判断所以只能使用 Rule JSON editor模式了。。。
  下图 显示了*** Rule JSON editor*** 模式
  

这也就是 AWS WAF的所谓高级编辑模式了。

3.3 配置实战A，控制泛洪攻击（攻击请求速率）

只用可视模式

目标是 当用户请求 每five(5)分钟 达到 600次的时候，就Block（拒绝）对方。直到对方速度低于此速度。
（AWS的槽点在于只能 配置每5分钟。。。）

配置如下：

点击Save Rules，此时你的WAF便具有了一定的HTTP泛洪防御能力。

3.4 配置实战B：当检查到特定路径请求的时候拒绝对方的试探

actuator攻击是一种很常见的试探攻击，处理不当很可能导致信息泄露等威胁。
所以我们的WAF可以如此配置：
当请求URI中涉及 actuator则Block（阻断）
配置如下图：

至此你又拥有了另一个安全规则。

4 更进一步

4.1 什么是合理的规则设计？如何利用好AWS的分层结构？

现在你可以根据你的防御需求来尝试调配自己的规则了

这里提供一种WAF配置思路，结合了官方的建议：

可以从上到下添加至少如下的检查规则分别为：

1. 白名单
2. 黑名单
3. 速率控制：也就是HTTP泛洪攻击防护
4. 自定义的防护任务
5. 托管规则

4.2 几个重要的AWS WAF 概念及简易运用

标签 和 标签组

• 是什么
  

• 什么场景下使用？
  为了后面的规则能判断前面的规则是否识别出特定问题了

使用前面的例子，如果我发现对方在尝试高频率请求，可以不直接拒绝而是 使用 Count 统计，再打一个标签：high_speed)高频率，如下图：
后面的其他规则，通过通过判断是否为高频率 而进一步做出决策，例如下下图一个名为anti_attack的规则：

至此相比你已经了解了标签的最主要的用法。

4.3 进一步提升你的WAF防御可以考虑问题

当然你需要根据你要防护服务器的实际情况进一步完善，思考以下几个问题：

• 能否对白名单的IP也可以进行安全检查？
  而不是因为对方是白名单，就可以放弃对它的进一步安全分析
• 能否分级观察不同的压力情况？以辅助安全检查员做出安全决策？
• 能否更多统一的建立对攻击流量的标签分析
• 当你的业务是从中途开始上WAF，该如何解决冲突又不危害现有业务的正常工作？
• 如何动态的改变WAF，通过其他AWS服务？
  使WAF能够变成的动态、有机的防御设施

4.4 管理WAF日志的方案选型心得

4.4.1 用 CloudWatch Logs Insights 分析WAF日志

优势：语法较简洁，查询快，在线趋势显示好。
缺点：比较贵，查询按次收费

4.4.2 用自建ES Kibana管理WAF日志

优势：便宜
缺点：

1. 保存时间可能跟其他日志混合无法长期，如果你们运维解决了这个问题也还好。
2. 需要进一步对WAF的日志做解析，ES默认是不理解WAF的自定义结构的。识别不出更进一步的字段，导致你得下载下来进一步的分析。这样失去了在线查询的意义。

4.4.3 用 AWS OpenSearch 来管理WAF日志

优势：其实它也是 Kibana。但是增加了官方的自己服务的数据解析，让你可以任意查询WAF数据。
缺点：比自建ES Kibana要有一点成本。需要租一台AWS的服务器并为此付费（建议是内存优化类型的）