文章目录
-
- [1 前言](#1 前言)
- [2 新手第一步](#2 新手第一步)
- [3 实践](#3 实践)
-
- [3.1 了解托管规则](#3.1 了解托管规则)
- [3.2 编写自己的DIY规则](#3.2 编写自己的DIY规则)
- [3.3 配置实战A，控制泛洪攻击（攻击请求速率）](#3.3 配置实战A，控制泛洪攻击（攻击请求速率）)
- [3.4 配置实战B：当检查到特定路径请求的时候拒绝对方的试探](#3.4 配置实战B：当检查到特定路径请求的时候拒绝对方的试探)
- [4 更进一步](#4 更进一步)
-
- [4.1 什么是合理的规则设计？如何利用好AWS的分层结构？](#4.1 什么是合理的规则设计？如何利用好AWS的分层结构？)
- [4.2 几个重要的AWS WAF 概念及简易运用](#4.2 几个重要的AWS WAF 概念及简易运用)
-
- [标签 和 标签组](#标签 和 标签组)
- [4.3 进一步提升你的WAF防御可以考虑问题](#4.3 进一步提升你的WAF防御可以考虑问题)
- [4.4 管理WAF日志的方案选型心得](#4.4 管理WAF日志的方案选型心得)
-
- [4.4.1 用 CloudWatch Logs Insights 分析WAF日志](#4.4.1 用 CloudWatch Logs Insights 分析WAF日志)
- [4.4.2 用自建ES Kibana管理WAF日志](#4.4.2 用自建ES Kibana管理WAF日志)
- [4.4.3 用 AWS OpenSearch 来管理WAF日志](#4.4.3 用 AWS OpenSearch 来管理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配置思路，结合了官方的建议：
可以从上到下添加至少如下的检查规则分别为：
- 白名单
- 黑名单
- 速率控制：也就是HTTP泛洪攻击防护
- 自定义的防护任务
- 托管规则
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日志
优势：便宜
缺点：
- 保存时间可能跟其他日志混合无法长期，如果你们运维解决了这个问题也还好。
- 需要进一步对WAF的日志做解析，ES默认是不理解WAF的自定义结构的。识别不出更进一步的字段，导致你得下载下来进一步的分析。这样失去了在线查询的意义。
4.4.3 用 AWS OpenSearch 来管理WAF日志
优势：其实它也是 Kibana。但是增加了官方的自己服务的数据解析，让你可以任意查询WAF数据。
缺点：比自建ES Kibana要有一点成本。需要租一台AWS的服务器并为此付费（建议是内存优化类型的）