图1：过去6小时内发生的WAF事件。
2.查看此流量触发的前10个规则ID。 规则ID是进一步过滤流量和观察各种WAF事件的有效负载的好方法。 也就是说，开始按这些规则ID逐个过滤流量以进行进一步分析。
图2：WAF事件触发的前10条规则。
3.接下来,通过查看匹配值字段来查看触发此规则的有效负载值。
图3：匹配值列下的有效负载值。
4.分析有效负载值以确定它们是否是恶意的。 不确定它们是什么样的？ 下面是您可能会在负载中找到的一些潜在恶意值。
- 路径遍历：http://some_site.com.br/../../../../some dir/some file¹ http://testsite.com/get.asp?f=/etc/passwd²
- LFI漏洞：攻击者试图访问服务器上的敏感文件，如.ini。默认情况下，Edgecast WAF会阻止此文件和许多其他重要文件系统扩展。³
- 跨站点脚本：http://testsite.test/<脚本>alert(“测试”);</script>⁴ <img src=” http://url.to.file.which/not.exist”onerror=alert(document.cookie);>⁵
- SQL注入：从’a’=’a’的项目中选择*；⁶ select 1；⁷
- 远程执行代码：Eval(“\$$USER =‘$regdate’);⁸
- 基于时间的攻击：选择1和睡眠(2)；⁹选择基准(2000000，MD5 (‘a’))；¹⁰
5.如果您仍然不确定有效负载是否为恶意,一个很好的方法是查看发起请求的客户端IP列表以及相应的有效负载。 如果客户端IP是分布式的，也就是说，不同的，有效负载很有可能是误报。 但是，如果所有客户端IP都具有相同的值，则表明可能发生容量攻击，从而将其归类为恶意有效负载。 为了演示这一点，让我们参考步骤3，并选择此匹配值–{“IATA”:[“TGZ”,”MEX”]}并将其用作示例。 要查找发送此有效负载的客户端IP列表，请添加匹配的值作为筛选器，如下所示：
图5：发送有效负载值的客户端IP：{“IATA”:[“TGZ”,”MEX”]}。
在这种情况下，鉴于发出此请求的IP地址多种多样，这些请求很可能源自真实用户，因此很有可能成为误报的候选对象。
6.识别出误报后,您可以在”托管规则”部分中为其创建异常,但在执行此操作之前,您需要找出找到此负载的位置;查询字符串，请求标头，URL或其他位置。 通过在步骤5中查看同一页面上的”匹配于”列，可以轻松完成此操作。 在此用例中，有效负载在”data”查询参数中找到，如下所示：
图6：有效载荷值的位置：{“IATA”:[“TGZ”,”MEX”]}。
7.一个很好的经验法则是筛选包含误报有效负载的特定匹配字段，然后验证此匹配参数是否包含实际恶意有效负载的任何其他请求。 换句话说，在现场匹配的特定负载绝不是恶意的。 这是通过在有问题的字段上匹配的上添加过滤器来实现的。 查看我们的用例，我们可以确认在此查询参数中未发现任何恶意负载：
图7：在查询参数data中发送的所有有效负载值。
8.创建异常之前的最后一步是查找由匹配的时间字段触发的规则ID。 我们正在尝试记录由这种误报触发的所有规则(规则ID)。 根据我们的使用案例，此信息可在步骤5的同一页面上找到。
图8：由有效负载值触发的规则列表：{“IATA”:[“TGZ”,”MEX”]}。
9.是时候创建异常了。 转到”托管规则”部分，然后单击要向其中添加这些例外的托管规则。
图9：为WAF配置创建的现有托管规则。
10.转到”例外”选项卡,然后单击”添加新条件”。 选择字段上匹配的类型，如args，request_cookie或找到有效负载的URL。 然后输入参数的名称，如查询或cookie。 最后，输入有效负载触发的所有规则ID的列表。
