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

发布时间:2024年01月01日

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的服务器并为此付费(建议是内存优化类型的)

文章来源:https://blog.csdn.net/dalerkd/article/details/135321116
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。