新部署的應(yīng)用讓W(xué)AF“躺槍”

四川 賴文書

根據(jù)業(yè)務(wù)需要，公司開發(fā)團隊開發(fā)了新應(yīng)用vueerp，筆者運維團隊配合將新應(yīng)用部署到服務(wù)器，并配置F5 實現(xiàn)了后端的負載均衡，通過融合安全網(wǎng)關(guān)發(fā)布到互聯(lián)網(wǎng)。

故障現(xiàn)象

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

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

軟件運維組的同事初步判斷為跟公司的網(wǎng)絡(luò)環(huán)境或配置有關(guān)，自然也就聯(lián)系網(wǎng)絡(luò)運維組進行排查。

故障分析及排查

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

經(jīng)負責(zé)融合安全網(wǎng)關(guān)的同事排查發(fā)現(xiàn)，在WAF 的白名單中添加了公司互聯(lián)網(wǎng)出口IP 地址，據(jù)稱以前由于公司開發(fā)測試團隊需要對發(fā)布的應(yīng)用進行壓力測試，導(dǎo)致該IP 超過TCP FLOOD 防護設(shè)置的閾值被自動加入黑名單，為避免影響開發(fā)測試工作才添加白名單。

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

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

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

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

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

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

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

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

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

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

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

圖1 導(dǎo)出WAF 日志對比

圖2 WAF 特征事件停用

圖3 Tomcat 日志分析

故障定位及解決

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

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

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

結(jié)語

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