某網(wǎng)站部分用戶無法訪問現(xiàn)象故障分析

題前：這篇文本來是想發(fā)到科來論壇下的（帶有目的性），結(jié)果科來論壇已經(jīng)完全沉寂、管理員失蹤，我發(fā)的帖子審了兩個(gè)月也沒審?fù)?，極度失望，感覺白寫了。不過好歹也花了一番心血，原文貼到51CTO博客，懶得修改了。

背景：運(yùn)維的某網(wǎng)站，本地已配備360旗下網(wǎng)神公司的WAF設(shè)備。因最近網(wǎng)絡(luò)安保形勢嚴(yán)峻，為加強(qiáng)網(wǎng)絡(luò)安全防護(hù)能力，開始試用某云WAF系統(tǒng)（將域名解析地址指向云WAF系統(tǒng)地址，由云WAF系統(tǒng)負(fù)責(zé)擺渡），期間發(fā)現(xiàn)少量用戶無法登陸，原因不明。切回本地后故障依舊，但據(jù)網(wǎng)站管理員反映，清除瀏覽器緩存或更換瀏覽器后即可正常訪問。
接到反饋后，因故障無法重現(xiàn)且暫未發(fā)現(xiàn)可供搜集信息的用戶電腦，現(xiàn)場工程師未能提供更多有價(jià)值的信息，難以確定具體故障原因。因網(wǎng)站訪問量小且故障不明顯，因此留待故障重現(xiàn)后解決（一部分不可曰的原因是懶）。幾日后接到本地用戶反饋，開始做工。

排測過程：
經(jīng)用戶電腦測試，使用常用的360瀏覽器訪問完全無響應(yīng)，找出IE瀏覽器后訪問正常（為什么要找？這要問360安全衛(wèi)士）。
初步判斷為訪問被WAF系統(tǒng)攔截。
先PING域名，發(fā)現(xiàn)網(wǎng)站域名指向本地系統(tǒng)，由此排除云WAF直接攔截可能。
登陸本地WAF設(shè)備，發(fā)現(xiàn)用戶設(shè)備訪問被攔截記錄，攔截原因?yàn)榭缯灸_本***。故障原因找出。

題外話：朋友們這時(shí)肯定會非常疑惑，那為什么之前沒有出現(xiàn)這個(gè)故障呢？難道經(jīng)云WAF切換后會出現(xiàn)這種靈異事件？這時(shí)候管網(wǎng)絡(luò)的工程師解釋說，本地WAF上線時(shí)，防護(hù)的其他網(wǎng)站某些正常訪問會被此WAF跨站腳本***規(guī)則集下的某幾條規(guī)則攔截，當(dāng)時(shí)為保障系統(tǒng)正常運(yùn)行直接剔除了這幾條規(guī)則，現(xiàn)因網(wǎng)絡(luò)安保原因，試用云WAF系統(tǒng)前一周已經(jīng)重新啟用這幾條規(guī)則，可能因網(wǎng)站訪問量小之前并未發(fā)現(xiàn)異常。順帶說下，這個(gè)管網(wǎng)絡(luò)的就是本人，故障原因找出前完全忘了這回事。自責(zé)三秒鐘，然后開始抱怨，做工太雜太雜太雜真的會死人啊，記憶力嚴(yán)重衰退，日后必定會老年癡呆。

好了，說回正題。故障原因找到了，怎么解決呢？再次剔除這幾條規(guī)則實(shí)在是不符合本人職業(yè)素養(yǎng)，那就只能繼續(xù)深挖故障原因了。
用戶無法訪問是因?yàn)楸籛AF攔截，那，為什么會被攔截呢？
查看WAF攔截日志，除攔截規(guī)則外無任何其他異常信息。只能去現(xiàn)場抓包了。這時(shí)候隆重推薦下所用的網(wǎng)絡(luò)抓包軟件：科來網(wǎng)絡(luò)分析系統(tǒng) 10 技術(shù)交流版。沒錢買專業(yè)版的，幸好技術(shù)交流版也已經(jīng)夠用了（如此大力推薦，只望科來官方人員見到此貼后能讓我以巨優(yōu)惠價(jià)購買正式版過過癮）。
打開科來網(wǎng)絡(luò)分析系統(tǒng) 10 技術(shù)交流版，進(jìn)入實(shí)時(shí)分析界面，點(diǎn)擊開啟按鈕進(jìn)入抓包分析界面后，先開360瀏覽器，直接訪問域名，頁面無法打開，訪問域名下的/INDEX.DO頁面，仍然無法打開；然后開IE，兩個(gè)頁面均訪問正常，點(diǎn)擊停止按鈕結(jié)束抓包。
在分析界面中點(diǎn)擊TCP會話欄，在過濾輸入框中輸入網(wǎng)站域名進(jìn)行過濾，然后按發(fā)包時(shí)間進(jìn)行排序，結(jié)果截圖如下：

點(diǎn)開查看訪問失敗的記錄，發(fā)現(xiàn)TCP連接正常建立后，訪問請求無法送到服務(wù)器端，一直在不停重傳，截圖如下：

而訪問正常的記錄截圖如下：

由此可見，訪問網(wǎng)站的第一個(gè)請求就已經(jīng)被WAF攔截。接下來對比兩個(gè)請求包的參數(shù)差異。
以下是訪問被攔截的交易請求參數(shù)截圖：

以下是訪問正常的交易請求參數(shù)截圖：

經(jīng)對比，兩個(gè)交易只有攜帶的COOKIES參數(shù)有顯著差異：
被攔截的COOKIES參數(shù)：
Cookie: UM_distinctid=15e78eb321b81-05b400905-4349052c-1fa400-15e78eb321e305; _gscu_264088535=05267233ghc0ek25; __guid=188558254.4450887942645648000.1505720364652.8474; CNZZDATA1254021662=1759409609-1505716920-http%253A%252F%252Fwww.XXXX.gov.cn%252F%7C1505716920
訪問正常的的COOKIES參數(shù)：
Cookie: JSESSIONID=F91BD6BBF20E7FEF70066DD1CBB86819; CNZZDATA1254021662=2125437701-1505264969-%7C1505976274; _gscbrs_264088535=1; UM_distinctid=15ea368883f9b-07964ba146a25f4-19704f6e-1fa400-15ea36888401c6; _gscu_264088535=05980090ml7lf511; _gscs_264088535=05980090gjxj3h21|pv:5

由此可以看出：

1. 被攔截的COOKIES參數(shù)使用了URL轉(zhuǎn)義符，且轉(zhuǎn)義兩次。（http%253A%252F%252Fwww.XXXX.gov.cn，其中%25轉(zhuǎn)義后就是%）
2. 此COOKIES信息帶有CNZZ（站長之家）標(biāo)識；（參數(shù)中有CNZZDATA字樣）
   由此推斷：
3. 訪問URL參數(shù)中的COOKIES信息帶有轉(zhuǎn)義符，符合跨站腳本***的最基本特征之一，基本可以明確正常訪問被攔截是因?yàn)閃AF攔截規(guī)則簡單粗暴導(dǎo)致。
4. 經(jīng)網(wǎng)站管理員配合，明確留下此COOKIES信息的代碼是站長之家訪問統(tǒng)計(jì)代碼。
   經(jīng)測試，正常訪問此網(wǎng)站產(chǎn)生的COOKIES不含轉(zhuǎn)義參數(shù)；只有在登錄網(wǎng)站并注銷后仍不關(guān)閉瀏覽器且繼續(xù)訪問網(wǎng)站的情況下才會產(chǎn)生如被攔截的COOKIES參數(shù)，進(jìn)而導(dǎo)致訪問被WAF攔截，這也是為什么只有極少部分用戶訪問被攔截的原因。
   事后，網(wǎng)站管理員將網(wǎng)站代碼中的站長之家訪問統(tǒng)計(jì)代碼替換為百度訪問統(tǒng)計(jì)代碼之后，問題解決。
   事終感慨：
   1. 科來網(wǎng)絡(luò)分析系統(tǒng)確實(shí)好用，尤其是對于認(rèn)不了幾個(gè)英文的朋友；（再次重申：如此大力推薦，只望科來官方人員見到此貼后能讓我以巨優(yōu)惠價(jià)購買正式版過過癮）；
   2. 360網(wǎng)神的WAF有待大力改進(jìn)；
   3. 站長之家的統(tǒng)計(jì)代碼需要更新；
   4. 工作太雜真TM受不了。