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

四川 賴文書

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

故障現(xiàn)象

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

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

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

故障分析及排查

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

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

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

這一確認(rèn)好像真是白名單引起了新應(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)用防火墻）的站點(diǎn)安全項(xiàng)與新應(yīng)用vueerp 相關(guān)的配置，逐條推敲各條配置項(xiàng)，對(duì)可能有疑問的配置進(jìn)行了測試確認(rèn)。

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

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

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

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

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

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

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

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

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

圖2 WAF 特征事件停用

圖3 Tomcat 日志分析

故障定位及解決

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

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

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

結(jié)語

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