点击上方蓝字关注“汪宇杰博客”

导语

昨天写了篇《使用 Azure Web 应用防火墙拦截黑客攻击》然后自爆了，我博客的后台管理被 WAF 干掉了。我996了半小时，终于让 Azure WAF 放过了被误杀的平民。今天把方法分享给大家。

误杀平民

我的博客后台配置了 Azure AD 集成身份认证。结果开启 WAF 后，一登录就爆：

于是我开始了996之……

要分析这个平民究竟是怎么死的，首先得开启 WAF 的日志。这个日志不在 WAF 里，而在关联的 Front Door 里。

进入 WAF 绑定的 Front Door，进入 Diagnostic settings，点击 + Add diagnostic setting

在 Category details 里勾选 FrontdoorWebApplicationFirewallLog，建议保留 30 天日志。

Destination details 里配置日志保存到哪里去。我假装看了看我的劳力士，选择了两个位置：Log Analytics 及 storage account。

这里可以根据自己需要选择，如果你和我一样也就有微软赠送的 12000 美元的 Azure，全选上也没事。临时排查问题的话，为了省钱可以只选 storage account。

现在再次访问被误杀的博客后台，等待 WAF 记录日志。

根据你的有钱程度，Azure 日志可能在几分钟到几十分钟内输出到刚才配置的目标位置。以 storage account 为例，WAF 的日志会输出到一个专门的 Container 中，名为 ingishts-logs-frontdoorwebapplicationfirewalllog。

进入这个 Container，像剥洋葱一样一层层剥开目录后，最里面就有个 JSON 格式的日志文件，把它下载到本地。

用假装轻量级，实际一开就占用几百兆内存的 Visual Studio Code 打开日志文件。就能发现博客后台的请求具体是被哪条防火墙规则屏蔽的。

此处我发现规则名称为：DefaultRuleSet-1.0-SQLI-942440，最后的 942440 即为规则的ID，一会儿可以去找出来吊打。被屏蔽的原因在 matches 节点里，可以发现是 ASP.NET Core 的 Cookie 被 WAF 认为像个奇怪的SQL攻击而误杀了。（也许买点只要9块8的培训班课程转Java就好了）

排爆

回到 Azure WAF 的 managed rules 里，搜索刚才的ID：942440，可以活捉误杀我博客后台的规则。虽然在此处我可以直接禁用这条规则，或者设置为只记录log而不屏蔽，但这么做无疑增加了遇到真正攻击的危险。因此，我们需要增加一个排除规则，而不要上来就粗暴的禁用规则。

点击 Manage exclusions

添加一条规则。Rule group 选择 SQLI，Rule 找到 94240。Match variable 里添加：

Request cookie name, Contains, .AspNetCore.Cookies 

保存后根据你的有钱程度，等5-10分钟 WAF 刷新。然后又能愉快的打开博客后台啦：

虽然 996 了一会儿，但总体而言 Azure WAF 还是能够点点鼠标轻松排爆，十分优秀！

汪宇杰博客

Azure | .NET | 微软 MVP

无广告，不卖课，做纯粹的技术公众号

喜欢本篇内容请点个在看