AWS WAF实战、优势对比和缺陷解决

文章目录

• • 挑战和目标
  • [AWS WAF的优势](#AWS WAF的优势)
  • [AWS WAF的不足](#AWS WAF的不足)
  • 我是怎么做的?
  • [什么是比较好的AWS WAF设计?](#什么是比较好的AWS WAF设计?)

笔者为了解决公司Web站点防御性问题，较为深入的研究AWS WAF的相关规则。面对上千万的冲突，笔者不得设计出一种能漂亮处理冲突数据WAF规则。

AWS WAF开发人员在线指南

挑战和目标

笔者意图引进WAF，但运维同学折腾了几个月都没有开启WAF成功，面临有以下挑战和目标：

• 解决大量与现有业务的冲突
• 尽可能的Block掉攻击流量
• 风险操作统一管理(统一给一个标签出来)方便我们监控

笔者只能接管WAF的配置权限，设计WAF规则，并最终解决了相关落地问题。

AWS WAF的优势

1. 高度可配置 相对阿里来说
2. 纯JSON语言 DSL(领域内语言)

AWS WAF的不足

1. 缺乏可视化编辑能力

   非常容易漏，即一个请求没有经过深度检测就被放过的可能

   这里举个例子，如果我们检查一个请求具有客户端特征，如果我们选择了Accept就意味着这个请求将被特赦，无法再对其进行任何检查。

   所以Accept动作是一个非常风险的设计动作。特别是当你的WAF已经设计比较复杂的时候。

2. 对于官方的托管规则存在以下问题：

   三个问题其实是一个问题，如何关闭特定托管子项，AWS的托管规则子项仅存在这种选择: Count,Accept,Block。想关都不关不掉。

   a. 无法重复两次使用同一种托管规则

   b. 无法删除被打上的标签

   c. 无法关闭托管规则的子项：真乃一荣俱荣，一损俱损

   如果无法关闭特定标签,后面就无法直接使用特定的命名空间进行判断.

   因为拖管规则命名空间被一些需要根据业务关闭而又无法关闭的标签给污染了,导致后面每次使用该命名空间要么都要判断排除,要么就不能使用该命名空间,而需要独立使用子项(可能包含了数十种子项).

   总之就是自虐.

   当然我们做了解决:通过自定义的Filter规则,来替代AWS的特定拖管规则,在Filter规则里对特定不符合业务的子托管规则进行剔除操作.

3. 在线编辑功能，只能两层(横向)

   超出的部分就只能在线编辑,JSON的提示真是非人语言

我是怎么做的?

1. 解决可视化问题
   制作了可视化工具，能解析AWS 的WAF JSON.
   特别是对Accept/Block/Count的目标和各规则之间关系进行了解析和展示.
2. 关闭特定托管规则子项
   过自定义的Filter规则,来替代AWS的特定拖管规则,在Filter规则里对特定不符合业务的子托管规则进行剔除操作.
3. 在线编辑只能两层
   只能强行用复制粘贴方法了.在一个规则里测试好,再复制出来.
   幸亏我22层规则是纵向的,横向的只有2-3层的样子.

什么是比较好的AWS WAF设计?

我认为做到以下几点可称为好的AWS WAF设计：

1. 流量过滤器
2. 干掉纯IP流量
   如果你的服务器不需要支持纯IP连接的话.纯IP真是万恶之源.
3. 给优先用户一些标签
   给登录用户一个标签,给公司出去流量一个标签
4. 对托管规则做一个适合业务的裁剪(通过上面提到Filter规则)
5. 集中管理
   也就是各层判断根据判断结果打标签,一概不做Block.
   等所有标签决策投票完毕后,有任何问题的,继续走:Will_Ban层
   由决策层统一做判断:
   比如是我们的保护路径或者登录用户我们就纳入Manual层,做记录,放行
   其他自然流入最底的Tail_End进行Block.

最终笔者将以上5点扩展为具体规则，编写一个22层的WAF来解决了相关问题。