一場無休止的戰爭 淺談縱深防爬的「抗戰」之路

原標題：一場無休止的戰爭 淺談縱深防爬的「抗戰」之路

0x00 爬蟲=爬數據？

之所以又提「什麼是爬蟲」這個老生常談的問題，是前幾天有個驗證碼介面被刷的用戶在群里討論防護方案，他認為這種不算是爬蟲，爬數據的才叫爬蟲（這裡的「爬數據」指的是爬機票酒店住宿價格新聞小說漫畫評論SKU等等）。

沒錯，傳統意義上的爬蟲定義是這樣的，但本文即將討論的爬蟲，指任何能自動化完成一系列Web請求最終達到某種目的的程序，這些目的包括但不限於模擬投票讓你在某個在線評選中高票勝出、破解你的驗證碼（或者把驗證碼發給打碼平台）、模擬正常用戶下單買票以後卻不付款（讓正常用戶無票可買）等等、……現如今爬蟲的「趨利性」已經非常明顯，從獲取核心的商業信息（如價格、用戶信息等）到擾亂正常用戶的活動（如搶購、惡意刷票等），爬蟲已帶來越來越多業務營收、公司信譽以及核心數據方面的損失。

0x01爬蟲的幕後黑手們

反爬蟲與反反爬蟲的對抗是一條不歸路嗎？

這個問題要辯證來看，從阿里雲安全團隊線上對抗的經驗來看，答案完全取決於你在跟什麼水平的爬蟲對抗，我們姑且拍腦袋把互聯網上的爬蟲流量來源劃為下面這幾類：

嗯…你大概也看出來，越往上，就越是不歸路了。現如今專業的黑灰產團伙因為背後有足夠強的利益驅動，不論是資源（比如換IP用的IP池）還是技術能力（各種繞過防爬策略的猥瑣手法）都有了長足進步，老話怎麼說的來著，無利不起早，就怕流氓會武術……

不過還好，二八法則至少從量上看也適用於這個話題，往往佔比例更大的，還是技術含量相對較低的爬蟲，畢竟攻防都有成本，對於大多數爬蟲來說，爬不動你可以爬別人嘛，何必花力氣研究你的防爬策略呢？畢竟沒有防爬保護的站點才是大多數XD。

撿軟柿子捏的思路還有另一個更常見的場景。現如今大部分的業務都會提供傳統PC、移動端APP以及API等多個服務渠道，APP做了加固爬網頁，網頁做了混淆爬API…這是真真的木桶原理，哪裡好爬爬哪裡，哪裡防爬策略好繞過就爬哪裡，這不是理論上的場景，而是我們已經真實遇到的案例。因此，一個能覆蓋所有場景的防爬體系非常重要。

0x02 何為縱深？有多深？

因材施教，對症下藥。回到之前對攻擊者的分層上來說，我們需要有不同的套路對付不同等級的攻擊者。在無數個與線上爬蟲對抗的日夜裡，我們既見過簡單封禁一個IP就搞定的大規模撞庫行為，也遇到過具備完善的監控系統和技術人員24小時繞個不停的黑產團伙。從對抗上來說，絕對安全不會被繞過的系統是不存在的，我們能做的就是不斷提高攻擊者的繞過成本，而這個成本會隨著防護層次的豐富指數級上漲。

下面我們來梳理一下防爬的思路：特徵庫直接封禁、JS無感人機識別、行為異常檢測和威脅情報庫。

1. 特徵檢測

經驗豐富的安全人員往往能很快從訪問日誌中看出有無異常行為，舉幾個常見的例子：

● 正常用戶不會直接請求的頁面訪問卻不帶任何referer

● 從主域名跳轉過來的請求不帶任何cookie

● UA包含Python/Java/xxBot/Selenium

● 省內生活論壇卻有大量海外IP訪問

● request body中包含一個大量重複的手機號

這些明顯或不明顯的「特徵」，都可以作為第一道爬蟲檢測策略——特徵封禁。這裡的特徵可以是各種HTTP頭部、body以及它們的組合條件。阿里雲爬蟲風險管理產品提供了非常靈活的七層訪問控制策略，如同一把應用層的瑞士軍刀，是行走江湖的必備佳品：

2. JS無感人機識別

除了訪問控制，通過JS採集網頁環境中的操作行為、設備硬體信息、指紋等特徵來判斷請求是否來自於自動化工具也是常見的思路。思路雖然簡單，但在沒什麼秘密的前端對抗環境中，確保採集到的信息和風險判斷模型的準確性卻是專業的安全團隊投入相當大的精力來建設的能力。

現在，我們將阿里巴巴集團積累多年的驗證碼集成到了防爬產品中，用戶不需要做任何業務改造即可接入，一鍵獲得淘寶同款的人機識別能力，在諸如下圖所示的防護垃圾註冊、撞庫、暴力破解、驗證碼被刷、惡意下單等場景下有著很好的效果（補充一句：正經用戶無感知喲）：

3. 行為異常檢測

特徵匹配因具備很強的對抗特徵，是最容易繞過的防護規則，接下來我們聊聊異常行為檢測。說到行為，大部分第一反應肯定是限速。沒錯，但是限速兩個字展開卻有很多細節的問題，比如以什麼路徑作為限速條件？除了IP還能以什麼作為限速對象？除了頻率還有什麼統計方式？我們再舉幾個栗子：

● 我擔心以IP為對象限速會誤傷公司出口等NAT環境，希望以客戶端為對象來統計

沒問題，我們可以用cookie、設備指紋、MAC地址等多種指標。

● 我只關注登錄介面的暴力破解行為，希望只對這個介面做統計

沒問題，統計路徑匹配/login.php即可，我們支持前綴、正則、完全匹配等方式。

● 我的業務請求中會有一個參數userid來標識某個用戶，我想基於這個指標做限速

沒問題，您只需要在配置里指定這個參數的key（如userid）即可，我們會對超過閾值的value（如xiaoming）進行處置。

● 爬蟲會遍歷我業務中很多不存在的路徑，我希望當一個會話中404的比例超過一定值時採取措施

沒問題，可以根據響應狀態碼（如404、502）的統計來識別爬蟲。

這類基於會話行為的規則也可以靈活的滿足很多場景下的異常行為檢測需求：

當然異常行為檢測遠不止這些，從UBA（UserBehavior Analysis）角度去建模，也是一種不錯的思路（畢竟這年頭不說點機器學習也不好意思談安全了）。機器學習能夠綜合多個觀察角度和維度去識別爬蟲，增加了繞過和對抗的成本，這是相對於規則類防護的一個優勢。而且，針對一些精心構造的低頻、離散IP，機器學習可以很好的彌補規則檢測的短板。

目前，阿里雲安全的演算法團隊已經有十幾種針對不同場景下惡意爬蟲的識別模型，包括時序異常、請求分布異常、業務邏輯異常、上下文異常、指紋異常等等，藉助阿里雲平台強大的實時計算能力，可以做到實時的異常行為檢測——實時是個很關鍵的點，因為隨著爬蟲越來越智能，有一些高級爬蟲等一般演算法產出結果的時候早就消失在人海深藏功與名了，識別效率會大打折扣。

4. 威脅情報能力

之前說到了甲方做防爬的一些優勢，那麼從全國最大的雲平台上誕生的防爬產品最大的優勢就是威脅情報的能力了，這裡再舉個栗子：

以航空行業為例，機票向來是爬蟲重點關注的對象，從爬蟲的角度來看，一個黃牛或旅行社背後的爬蟲往往會光顧各大航司以獲取最全的票價信息，所以當我們檢測到一個爬蟲光顧了ABCDE航司後，你說他爬X航的概率大嗎？當然。 這個不是假設，而是我們已經在實際的流量中發現的行為。於是我們由此拓展開來，基於一定的模型生成在多家航司網站上有過可疑行為的，實時的（注意是實時的哦）爬蟲庫，這就是典型的雲上協同防禦模型。這樣對於新接入的X航來說，我們甚至可以用情報的思路把防護做到事前。

其實從攻擊者的角度來看也很好理解，雖然現如今專業的爬蟲都會租用大規模的代理IP池、寬頻IP池，實現「被封秒換」的效果以逃避爬蟲檢測，但攻擊的成本也是存在的，也要考慮資源復用的問題，所以不同的攻擊者從IP販子手裡買到的可能是相同的一票IP。於是當我們把這些代理IP擴大到一定量以後，就會在惡意行為上出現越來越高的重合度。

目前阿里雲安全團隊從雲上流量分析出的各種類型的威脅情報庫已經具備一定的規模，依據云平台強大的計算能力，可以依據歷史一小時/一天/一周（場景不同）的流量情況計算，以應對快速變化的黑灰產資源池，這是我們防爬體系的另一個重要組成部分。

0x03 好的防爬系統應該體現人的價值

攻防對抗永遠是動態的，沒有一套萬金油的策略可以搞定所有場景，因此好的安全產品應該體現人的價值，幫助安全工程師將自身的技術和經驗最高效地發揮價值。所以，阿里雲安全團隊致力於提供給用戶的爬蟲風險管理產品，致力於打造一套儘可能靈活的「工具」，幫助用戶跳過繁瑣的實現細節，直接在策略甚至業務層面進行防護規則的部署，同時利用雲上海量的數據和計算能力、彈性擴容能力以及威脅情報，幫用戶快速打造適合自己業務特點的防爬系統。

同時，結合阿里雲的SLS日誌服務，我們可以很方便的對當前流量做快速分析，或者設置個性化的業務指標監控和告警，如將最近半小時內某域名下某個IP的訪問路徑按次數排序、某種策略的命中及繞過情況、監控每分鐘的註冊量/下單量有沒有突增的情況、滑塊驗證彈出及通過的情況等等，這樣我們就完成了一個從檢測到處置再到監控和對抗的閉環。

0x04結語

反爬與反反爬是一場無休止的戰爭，像任何一場戰爭一樣，最終拼的還是雙方的資源。近些年隨著selenium、按鍵精靈、打碼平台和人工智慧等一系列「猥瑣」手段的加入，對於真正持續投入對抗的場景，終局大概是雙方達成某種心照不宣的默契然後相忘於江湖吧……

end

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！