新部署的應用讓WAF“躺槍”

四川 賴文書

根據業務需要，公司開發團隊開發了新應用vueerp，筆者運維團隊配合將新應用部署到服務器，并配置F5 實現了后端的負載均衡，通過融合安全網關發布到互聯網。

故障現象

在公司發布測試過程一切正常，可是當軟件運維同事大強回家后想打開應用作些調試，正常登錄后點擊其中一個模塊居然報“HTTP1.1/403 Forbidden，Access not allowed”錯誤提示頁面。

403 簡單的理解為沒有權限訪問此站，我們都正常登錄了系統為什么會沒有權限？聯系開發團隊，得到的回復是服務器配置原因，并給了兩個博客網址參考修改服務器配置，其中一個博客是IIS 服務器報403 錯誤通過更改文件夾權限解決；另一個是tomcat 報403 錯誤通過注釋掉RemoteAddrValue解決。但都不存在這樣的問題，而且該故障回到公司訪問又神奇的消失了。

軟件運維組的同事初步判斷為跟公司的網絡環境或配置有關，自然也就聯系網絡運維組進行排查。

故障分析及排查

為重現該故障現象，網絡運維組連接4G 熱點訪問新應用vueerp，瀏覽器確實返回了403 頁面。難道真是公司互聯網到IDC 機房的網絡配置有什么不一樣？用tracert 命令跟蹤新應用映射到公網IP，數據包傳輸路徑確認是從公司互聯網出口IP 到的IDC 機房公網IP，并不是軟件運維同事認為的走業務專網到的IDC 機房，那又是什么原因呢？

經負責融合安全網關的同事排查發現，在WAF 的白名單中添加了公司互聯網出口IP 地址，據稱以前由于公司開發測試團隊需要對發布的應用進行壓力測試，導致該IP 超過TCP FLOOD 防護設置的閾值被自動加入黑名單，為避免影響開發測試工作才添加白名單。

難道加了白名單就能正常訪問新應用？說不通啊。為驗證公司正常訪問新應用是否是白名單的影響，再次借助手機4G 測試，用手機瀏覽訪問www.ip138.com 查詢到4G 網絡出口IP，再將手機出口IP 加入WAF 白名單，最后訪問新應用正常了。

這一確認好像真是白名單引起了新應用vueerp 的訪問故障，網絡組討論分析故障的可能原因，包括融合安全網關的相關配置有誤；設備本身的BUG 引發或者開發部署的代碼異常。

我們首先檢查ADC（應用交付模塊）的發布策略、NGFW（下一代防火墻模塊）的訪問策略、WAF（網站應用防火墻）的站點安全項與新應用vueerp 相關的配置，逐條推敲各條配置項，對可能有疑問的配置進行了測試確認。

根據瀏覽器返回403 的信息，是tomcat 服務器返回的錯誤頁面，確認經過融合安全網關并沒有丟棄和阻斷客戶端的訪問數據包，從配置檢查中沒有找到故障的原因。聯系融合安全網關廠商對這一故障現象進行分析，廠商工程師首先對特征庫進行檢查，發現其版本是一個月前的。

根據他們排查流程首先得解決這個問題，于是從后臺檢查WAF 到升級服務器的網絡，ping 升級服務器的IP和Telnet 對應端口均正常。其實關于WAF 特征庫版本的問題，我們之前就曾聯系廠商咨詢，當時解釋說他們的升級服務器未更新對應的版本，從升級日志來看也說明WAF 的自動升級運行正常。但是這次聯系的廠商工程師確認到升級服務器已經更新了，可WAF 仍然無法升級到最新版本，同時排除了網絡層面的原因，由于處理這問題的工程師主要負責NGFW和ADC 產品線，對于升級問題需要協調WAF 專家診斷處理。這過程由于廠商自身協調流程的原因，需要負責WAF的二線工程師發起專家診斷請求，只得重新聯系廠商的WAF 二線工程師排查問題。

經廠商WAF 專家指點，特征庫的自動升級確實出現了問題，解決辦法是手動更新特征庫新版本，后續就可以自動升級了。事件特征庫升級后通過手機4G 訪問新應用仍然報403 錯誤，這就排除了特征庫引起的故障。

只能進行其他方向的探索，在WAF 管理頁面的“應用監控”/“安全事件監控”項，導出安全事件日志對比加白名單前后的信息差異，發現手機4G 網絡出口IP 加WAF白名單后，在日志里的HOST、URL 和REFERER 列沒有記錄任何信息，在事件名稱列記錄為“全局訪問控制白名單”，安全類型列為“安全審計”，在事件級別列為“中級”；而未加WAF 白名單時卻在HOST、URL 和REFERER 記錄了相關信息，并且在事件名稱列記錄為“HTTP_認證請求”，安全類型列為“其它事件”，在事件級別列為“非攻擊”。

該事件表明，有用戶正在向HTTP 服務器發送基本認證請求。HTTP 基本認證不同于SSL，SSL 提供加密傳輸的機制，而HTTP 基本認證提供了對受保護資源的訪問控制策略。

HTTP 協議通信過程中，定義了基本認證過程以允許HTTP 服務器對Web 瀏覽器進行用戶身份認證的方法。當一個客戶端向HTTP 服務器進行數據請求時，如果客戶端未被認證，則HTTP 服務器將通過基本認證過程對客戶端的用戶名及密碼進行驗證。客戶端在接收到HTTP服務器的身份認證要求后，會提示用戶輸入用戶名及密碼，客戶端將用戶名和密碼用“：”合并，并將合并后的字符串用BASE64 加密為密文，并于每次請求數據時，將密文附加于請求頭（Request Header）。HTTP 服務器在每次收到請求包后，根據協議取得客戶端附加的用戶信息（BASE64 加密的用戶名和密碼），解開請求包，對用戶名及密碼進行驗證，如果用戶名及密碼正確，則根據客戶端請求，返回客戶端所需要的數據；否則返回錯誤代碼或重新要求客戶端提供用戶名及密碼。

無論是否加白名單在日志的動作列都是“通過“狀態如圖1 所示，這驗證了我們最初的判斷，融合安全網關上的WAF、NGFW 和ADC 配置是正確的，并沒有阻斷或丟棄客戶端的訪問數據包，那又為什么在沒加白名單的情況下瀏覽器會呈現403 的狀態碼呢？既然日志對比分析看到了客戶端訪問新應用時，沒加白名單的情況下匹配到“其它事件”/“HTTP_認證請求”事件，那停用該事件策略會不會正常呢？

于是WAF 二線工程師進行了測試操作，結果在沒有加白名單的情況手機瀏覽器仍然返回403 頁面。廠商工程師根據處理類似故障的經驗接著停用了“HTTP_HEAD命令”“HTTP_POST 命令”“HTTP_找不到對象”等事件，每停一個事件都用手機4G網絡訪問新應用確認都不正常，最后在停用“HTTP_登錄失敗“如圖2 時奇跡出現了，瀏覽器返回了新應用vueerp正常的頁面。至此，只是把分析定位故障點有效地向前推進了一步，引發故障的最終原因仍未浮出水面。

圖1 導出WAF 日志對比

圖2 WAF 特征事件停用

圖3 Tomcat 日志分析

故障定位及解決

最后只能找軟件運維同事提供tomcat 服務器日志進行分析，對比在手機4G 網絡IP 加入白名單前后的日志信息，從中尋找新應用運行時的蛛絲馬跡。在沒加白名單的情況下產生了多條"GET/vueerp/login?loginI d=40a380956b8e2be9016b92 9c3bd62d37 HTTP/1.1" 404 995”日志，狀態碼404 表示訪問請求的資源不存在，多條相同日志表示請求有重試；而在WAF 加了白名單后還是產生了一條“/vueerp/login?loginId=40a380956 b8e2be9016b92ad59792f4a HTTP/1.1" 404 995”，后面都是正常返回頁面內容的相關文件如圖3，狀態碼均為200 也表示正常響應了訪問請求。

為什么會出現這樣的日志？只得請開發同事了解其中緣由。由于新應用vueerp采用了新的前端開發框架vue.js，在實現前端路由時添加了一個 404 頁面，用來充當用戶輸入不存在的路由時的界面，這就是為什么我們正常訪問時能在tomcat日志里看到一條404 的信息。問題根源也基本確認是開發的代碼和WAF 的“HTTP_ 登錄失敗”特征事件發生了作用，導致在WAF 不加白名單的情況下訪問新應用報403錯誤頁面。

為了保障IDC 信息系統的整體安全性，不能長期在WAF 上停用“HTTP_登錄失敗”事件來保障新應用正常訪問。因此，需要開發同事對代碼進行優化調整，最終他們采用了vue.js 的hash路由模式，它是頁面 URL 中以#開頭的一個字符串標識，當它發生變化時會觸發 hashchange 事件，該模式就不需要404 頁面做跳轉。

結語

這次故障處理可謂動用了“海陸空”三軍力量，運維團隊、安全設備廠商和開發團隊聯合排查，才完美解決。其過程難免有置疑、爭吵、指責等，但更多的是冷靜思考、積極配合收集多層面信息，根據不同線索、不同角度和維度進行測試確認，才很快消除了故障點。