WAF CDN 的識別方法
在日常滲透中,經常會遇到目標網站存在 WAF 和 CDN 的情況,如果直接對其進行漏洞掃描的話,大概率發現不了安全問題,反而給目標留下很多漏洞測試的告警,即浪費時間又沒有效果,在做漏洞掃描之前可以先進行 WAF 的識別,如果確認沒有 WAF 的情況,在進行漏洞掃描,而存在 WAF 的目標,可以進行手工測試,盡量不要使用明顯的攻擊方式,找一些邏輯方面的問題,WAF 是無法進行識別的。
首先看看 CDN 是什么,如何識別?
CDN 的全稱是 Content Delivery Network,即內容分發網絡。CDN 是構建在現有網絡基礎之上的智能虛擬網絡,依靠部署在各地的邊緣服務器,通過中心平臺的負載均衡、內容分發、調度等功能模塊,使用戶就近獲取所需內容,降低網絡擁塞,提高用戶訪問響應速度和命中率。CDN 的關鍵技術主要有內容存儲和分發技術。--百度百科
光看介紹不太明顯,下圖是 cloudflare 保護前后的架構:

在部署 CDN 之前,我們可以直接訪問目標網站,沒有任何阻礙,當然做任何事兒都是可以的,當目標部署了 CDN 之后,用戶訪問的所有流量都會經過 CDN 設備,然后 CDN 設備針對用戶的訪問,進行數據的返回,相當于有了一層反向代理,其實 WAF 的原理也是一樣的,只不過核心功能不一樣,CDN 的核心是針對網站進行加速,讓全球用戶訪問該網站都是如絲般順滑,而 WAF 的核心是讓做壞事的人,無處遁形,及時制止。
如果要去識別 CDN 該怎么辦呢?如果部署了 CDN,我們會在最開始訪問時就接觸到它,所以域名解析的 IP 地址就是 CDN 的 IP 而非目標的真實 IP,所以通過 IP 來判斷是主要的方式,前提是你要有一份完整的 CDN 系統 IP 地址規則庫,所幸有巨人整理好了,參考項目:
https://github.com/timwhitez/Frog-checkCDN

有了這個就可以很大概率上識別出網站是否存在 CDN 了,規則中還有一個關于 CNAME 的規則,這是什么原理?那得看看 CDN 是如何配置的,畢竟網站系統還是自己的不是 CDN 廠商的,所以不可能直接配置域名 DNS IP 到 CDN 處,需要一個中轉,在不改變目標網站配置的情況下,讓用戶流量先過 CDN 然后再到目標網站,看一下騰訊云關于 CDN 的配置方式:

配置 CNAME 就能做到上面的需求,在不改變目標網站配置的情況下,直接通過修改域名的 CNAME 記錄就可以達到部署 CDN 的效果,所以是可以通過獲取域名 CNAME 記錄,來判斷網站是否使用了 CDN 的情況。以上就是 CDN 的識別方法。
其次,看看 WAF 是如何識別的?
WAF 的配置跟 CDN 的配置差不多,如果類似 CDN 的配置,那么該 WAF 的部署方式屬于串連部署,就是所有流量先經過 WAF 設備,然后再到后端服務器,這樣對于攻擊事件,可以做到實時攔截,有一個缺點就是,容易誤傷用戶,如果 WAF 設備出現故障,那么會影響一大片用戶的訪問,造成 p0 級故障,這是安全同事不想看到的。
那么還有啥方式呢?就是旁路部署的方式,原理就是將所有流量鏡像到 WAF 設備,對于 WAF 設備來說,流量是實時的,但是對于目標系統來說只是將流量復制了一份而已,這種部署方式無法做到實時攔截,需要 WAF 審計出攻擊事件之后,再給目標系統發送指令,來對攻擊來源進行限制,比如封 IP,封賬號之類的操作。如圖:

那么如何識別呢?首先可以嘗試識別 CDN 的那種方式,從 IP、CNAME 上去匹配相應規則,這種可以識別那些 WAF 串聯在目標與用戶之間的 WAF,而旁路 WAF 部署則需要進行 WAF 觸發攔截之后,根據相應數據來進行規則判斷,比如項目:
https://github.com/EnableSecurity/wafw00f
https://github.com/stamparm/identYwaf
核心原理就是,有一個 WAF 指紋庫,通過構造惡意 payload 來進行觸發 WAF 攔截,然后再進行指紋比對,如果能比對上則說明存在 WAF,比如 sqlmap 檢測 WAF 的 Payload:
HEURISTIC_PAYLOAD = "1 AND 1=1 UNION ALL SELECT 1,NULL,'<script>alert(\"XSS\")</script>',table_name FROM information_schema.tables WHERE 2>1--/**/; EXEC xp_cmdshell('cat ../../../etc/passwd')#" # Reference: https://github.com/sqlmapproject/sqlmap/blob/master/lib/core/settings.py
當我們在一個沒有 WAF 的網站做測試時,使用上面的 payload 是不會有任何變化的,如圖:
https://edu.xazlsec.com/?1%20AND%201=1%20UNION%20ALL%20SELECT%201,NULL,%27%3Cscript%3Ealert(/%22XSS/%22)%3C/script%3E%27,table_name%20FROM%20information_schema.tables%20WHERE%202%3E1--/etc/passwd%27)#

當我們在一個有 WAF 的網站測試時,如圖:

出現了跟正常訪問不一樣的畫面,這就證明該網站存在了 WAF,因為 WAF 廠商也要考慮用戶體驗問題,正常用戶難免會觸發 WAF 攔截,WAF 誤傷問題很常見,所以攔截頁面都還是比較友好的,而且很有辨識度,能夠即使發現問題,經過投訴之后,及時解決,這對于識別 waf 來說也提供了便利。