點擊上方藍字關注“汪宇杰博客”

導語

昨天寫了篇《使用 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

無廣告，不賣課，做純粹的技術公眾號

喜歡本篇內容請點個在看

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的Azure WAF 导致网站无法登录 AAD 的解决办法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。