AWS WAF实战、优势对比和缺陷解决-Toy模板网

这篇具有很好参考价值的文章主要介绍了AWS WAF实战、优势对比和缺陷解决。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

笔者为了解决公司Web站点防御性问题，较为深入的研究AWS WAF的相关规则。面对上千万的冲突，笔者不得设计出一种能漂亮处理冲突数据WAF规则。
AWS WAF实战、优势对比和缺陷解决,aws,网络,云计算

AWS WAF开发人员在线指南

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

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

缺乏可视化编辑能力
非常容易漏，即一个请求没有经过深度检测就被放过的可能
这里举个例子，如果我们检查一个请求具有客户端特征，如果我们选择了Accept就意味着这个请求将被特赦，无法再对其进行任何检查。
所以Accept动作是一个非常风险的设计动作。特别是当你的WAF已经设计比较复杂的时候。
对于官方的托管规则存在以下问题：
三个问题其实是一个问题，如何关闭特定托管子项，AWS的托管规则子项仅存在这种选择: Count,Accept,Block。想关都不关不掉。

a. 无法重复两次使用同一种托管规则
b. 无法删除被打上的标签
c. 无法关闭托管规则的子项：真乃一荣俱荣，一损俱损
如果无法关闭特定标签,后面就无法直接使用特定的命名空间进行判断.
因为拖管规则命名空间被一些需要根据业务关闭而又无法关闭的标签给污染了,导致后面每次使用该命名空间要么都要判断排除,要么就不能使用该命名空间,而需要独立使用子项(可能包含了数十种子项).
总之就是自虐.
当然我们做了解决:通过自定义的Filter规则,来替代AWS的特定拖管规则,在Filter规则里对特定不符合业务的子托管规则进行剔除操作.
在线编辑功能，只能两层(横向)
超出的部分就只能在线编辑,JSON的提示真是非人语言

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

最终笔者将以上5点扩展为具体规则，编写一个22层的WAF来解决了相关问题。文章来源地址https://www.toymoban.com/news/detail-656762.html

到了这里，关于AWS WAF实战、优势对比和缺陷解决的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！