题图是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作为起点。
假设你已经拥有一个空白的WAF:
第一步找到你的WAF:
继续让我们选择它,你的可能叫别的名字,显然这并不重要:(如果你的伙伴没有为你配置需要你自行创建一个ACL)
左侧的功能分页说明一下:
编辑规则主要看 Rules:
2号位置就是规则区了,3号可以手工添加一条规则:
我们先手工添加一条规则尝试:
你有两个选项:
Add managed rule groups:
即:添加托管规则
Add my own rules and rule groups:
添加自定义规则
我们会发现AWS WAF的规则是串型执行:Priority一列就是顺序。
这里列出的是AWS 付费(2023年12月31日)的3种托管规则集:
这里列出11种 AWS 免费的托管规则:
此外还提供了一些三方不同厂商提供的付费托管规则,OWASP TOP10等应有尽有:
总之托管规则应有尽有,但因为其面向通用场景,而不能完全适配我们自己的业务,还是需要我们动手DIY一些适合我们的规则。
点击: Add my own rules and rule groups 添加自定义规则
默认是 Rule visual editor: 即可视化编辑器:
点击 Rule JSON editor 进入JSON编辑器,此模式的优点是:
这也就是 AWS WAF的所谓高级编辑模式了。
只用可视模式
目标是 当用户请求 每five(5)分钟 达到 600次的时候,就Block(拒绝)对方。直到对方速度低于此速度。
(AWS的槽点在于只能 配置每5分钟。。。)
配置如下:
点击Save Rules,此时你的WAF便具有了一定的HTTP泛洪防御能力。
actuator攻击是一种很常见的试探攻击,处理不当很可能导致信息泄露等威胁。
所以我们的WAF可以如此配置:
当请求URI中涉及 actuator则Block(阻断)
配置如下图:
至此你又拥有了另一个安全规则。
现在你可以根据你的防御需求来尝试调配自己的规则了
这里提供一种WAF配置思路,结合了官方的建议:
可以从上到下添加至少如下的检查规则分别为:
是什么
什么场景下使用?
为了后面的规则能判断前面的规则是否识别出特定问题了
使用前面的例子,如果我发现对方在尝试高频率请求,可以不直接拒绝而是 使用 Count 统计,再打一个标签:high_speed)高频率,如下图:
后面的其他规则,通过通过判断是否为高频率 而进一步做出决策,例如下下图一个名为anti_attack的规则:
至此相比你已经了解了标签的最主要的用法。
当然你需要根据你要防护服务器的实际情况进一步完善,思考以下几个问题:
优势:语法较简洁,查询快,在线趋势显示好。
缺点:比较贵,查询按次收费
优势:便宜
缺点:
优势:其实它也是 Kibana。但是增加了官方的自己服务的数据解析,让你可以任意查询WAF数据。
缺点:比自建ES Kibana要有一点成本。需要租一台AWS的服务器并为此付费(建议是内存优化类型的)