1. 程式人生 > >常見爬蟲/BOT對抗技術介紹(一)

常見爬蟲/BOT對抗技術介紹(一)

 

爬蟲,是大家獲取網際網路公開資料的有效手段。爬蟲、反爬蟲技術、反-反爬蟲技術隨著網際網路的不斷髮展,也在不斷髮展更新, 本文簡要介紹現代的爬蟲/BOT對抗技術,如有疏漏,多謝指正!

 

一、反爬蟲/BOT技術

1.1 Robots.txt

Robots.txt是一個古老的爬蟲協議檔案,他的位置位於域名根目錄下。譬如http://example.com/robots.txt 。 嚴格來講Robots.txt並不算一個反爬蟲技術,而是一個由爬蟲遵守的協議。它通過幾個簡單的命令告知遵守Robots.txt的爬蟲哪些可以被爬取,哪些不能。一般的搜尋引擎爬蟲會遵守這個協議,而對於上升到爬蟲技術對抗的層次來說,這個檔案毫無意義。

 

1.2 IP層/網路層

網路層是反爬蟲技術涉及到的最下層,再下的鏈路層資訊在IP報文的傳輸過程中會被三層交換機丟棄,沒有任何意義。IP報文帶有的最重要的資訊就是IP請求的來源地址, 來源地址極難(近乎不可能)偽造的特性, 使得這個欄位成為反爬蟲策略中最重要的欄位。 封殺IP/IP段是網站可以執行的最嚴厲的懲罰。由於國內的ISP大量的使用了NAT技術,導致大量使用者共用IP的情況越來越多, 內容提供方在做IP封殺時會越來越謹慎, 因為這樣做會導致極高的誤殺率,以至影響正常使用者的網站訪問。 但是即使如此, 源IP也是反爬蟲策略中最為核心的資料,反爬策略的執行動作一般都要圍繞源IP進行。

 

1.3 HTTP層

HTTP協議層有幾個有趣的HTTP頭,它們是制定反爬蟲策略的常用資料。

1.3.1 X-Forwarded-For

X-Forwarded-For(XFF)是用來識別通過HTTP代理或負載均衡方式連線到Web伺服器的客戶端最原始的IP地址的HTTP請求頭欄位。 Squid 快取代理伺服器的開發人員最早引入了這一HTTP頭欄位,並由IETF在HTTP頭欄位標準化草案中正式提出。
XFF頭由普通HTTP代理伺服器新增, 在使用者通過普通HTTP代理訪問網站時, 使用者的IP地址會被新增到這個頭中。 一些新手程式設計師在寫程式碼時,往往會把這個的IP地址當做使用者的真實IP地址使用,從而被爬蟲利用。

 

1.3.2 Referer

Referer是瀏覽器在頁面跳轉時帶入的HTTP頭,指示使用者上一個頁面的URL, 一般來說,網站90%以上的流量應該帶有Referer頭, 在一些常見的反爬策略中, 大量的不帶Referer頭的源IP請求會觸發"要求輸入驗證碼"策略。

1.3.3 User-Agent

User-Agent 是一個古老的HTTP頭,指示使用者瀏覽器的版本、作業系統等基本資訊, UserAgent偽裝已經在其他的文章裡有過充分的討論,故本文不再贅述。

 

1.4 應用層/瀏覽器層

在HTTP層之上是應用層,HTTP層上的資料最終會交由瀏覽器或者APP去渲染、執行。 本文重點討論基於現代瀏覽器的應用層反爬、及反反爬技術。

1.4.1 應用層反爬蟲/BOT技術簡介
1.4.1.1 驗證碼

驗證碼(CAPTCHA)是一種古老而有效的方式,用來判別請求方是否是人類。從最初的簡單數字驗證碼、到後來的中文驗證碼,到現代的圖片驗證碼, 驗證碼是應用層最普遍,也最核心的爬蟲對抗技術。 對於一些簡單的數字、字母驗證碼, 隨著近幾年機器學習、神經網路的快速發展,已經近乎於無效。有人訓練出基於LSTM的模型可以達到80~90%的識別正確率。 對於圖片驗證碼, 也有灰產專門用人工打碼平臺來處理,所以單憑驗證碼很難有效處理爬蟲問題, 過多的驗證碼也會導致正常使用者的體驗受到影響。

 

1.4.1.2 JS渲染(Ajax / SPA)

眾所周知, Ajax技術在2004年左右開始迅速發展,成為重要的瀏覽器端技術, 也讓爬蟲從靜態爬蟲轉化為動態爬蟲。 從此,爬取網站的資料不再是簡單的一個HTTP請求, 然後解析HTML頁面就可以了。大量的網站使用ajax來構建網站前端,也使得解析資料變得越來越困難。 在網站完全不設防的狀態,爬蟲也不止需要解析HTML頁面, 亦需要解析Ajax介面返回的資料。

 

1.4.1.3 介面加密與JS混淆

一般Ajax介面返回的是一個JSON/XML資料格式,除了給爬蟲工程師製造一點點的麻煩以外,並沒有任何的反爬蟲作用,  只需一點點的前端逆向能力(利用Chrome Debug工具, 找到網路請求),就可以找到ajax介面,並通過對應的庫解析出資料。但是如果前端通過JS混淆、並把ajax介面通過token進行加密的話,事情就變得比較麻煩了。 這種做法的思路是, ajax介面除了正常的HTTP請求引數外,額外還要接受一個Token引數,這個token引數是前端的js指令碼通過其他的引數加密出來的, 它可能是xor、md5、或者是sha256等等。引數可以是使用者名稱、ip、cookies的sessionid、甚至是使用者的操作流程(支付寶的做法)再加上前端把js的函式呼叫層層巢狀、隱藏、 再加上js指令碼混淆,令破解者無法方便的逆向出token計算的流程, 就可以達到一定的反爬目的。

 

1.4.1.4 資料混淆

爬蟲的目的是獲取到有效的資料。對於許多應用來說,獲取到錯誤的資料往往比獲取不到資料更加致命。(想象一下比價網站拿到的都是錯誤資料的場景)。這個思路的核心就是,當爬蟲命中反爬規則之後,使用錯誤的資料代替正確的資料返回給爬蟲, 這種方式非常隱蔽,又可以對對手造成足夠的麻煩, 可以說非常的猥瑣、也相當的有效。

 

1.4.1.5 行為分析

使用者的操作軌跡與爬蟲的操作軌跡是不同的。舉個例子, 在電商網站上,使用者可能會瀏覽100個或者更多相似的商品,最終選擇一個進行下單。而爬蟲的行為可能是瀏覽100000個商品,且它們之間彼此關聯度很低, 最終也不會有任何購買動作。從這個維度來說,就可以判斷出這個請求來源是客戶還是爬蟲。 結合其他的反爬手段,就可以對爬蟲造成有效干擾。低階的行為分析基於規則,高階的行為分析基於機器學習。 對於使用者操作比較多的網站來講,是一種很可靠的反爬手段。

 

1.4.1.6 儲存跟蹤與flash Storage

Cookies是眾所周知的瀏覽器保持狀態的一種機制。 除了Cookies,現代的瀏覽器還支援localStorage。以目前國內使用者的使用習慣,絕大多數使用者不會設定拒絕Cookies保持。所以,拒絕Cookies跟蹤的客戶端可以認為就是爬蟲。通過Cookies,就可以跟蹤使用者的行為軌跡。 除此之外,如果使用者使用瀏覽器模擬技術,一定在每次請求時會清空Cookies。 Cookies被清空之後,我們仍然有機會使用flash來繼續跟蹤使用者。今天的(2017年)Flash確實是一個夕陽技術,但仍然保持極高的市場佔用率,在PC端,90%以上的國內視訊網站依然採用flash作為播放器的客戶端。所以,一個以PC端流量為主的網站,可以使用flash來進行使用者跟蹤。值得高興的是,在flash外掛中,通過Capabilities.serverString可以獲取到非常多的系統資訊,包括作業系統、語言、系統解析度、DPI等等等等。這些系統資訊與JS上下文、UserAgent、使用者訪問日誌進行一起分析,就可以判斷是否是偽裝為爬蟲的瀏覽器。舉個例子,如果是正常的使用者, 從flash、js上下文、useragent拿到的引數應該是一致的,而如果偽造過UA(不那麼高明的偽造),則肯定會有紕漏。正所謂一個謊言需要用十個謊言去掩蓋。

 

1.4.1.7 navigator物件

瀏覽器中的window.navigator物件保持了很多的作業系統、瀏覽器資訊。navigator物件的資訊配合Useragent、flash,可以用來判斷是否是偽裝瀏覽器。

 

1.4.1.8 假鏈陷阱

假鏈陷阱作為反爬手段,多見於半靜態網站。 它的思路主要是構建一個不可見的a標籤, 如果爬蟲跟蹤所有的頁面連結,勢必會掉到構造好的陷阱,導致爬蟲命中反爬策略。

 

1.4.1.9 瀏覽器指紋

瀏覽器指紋技術常用於客戶端跟蹤及反機器人的場景。核心思路是, 不同瀏覽器、作業系統、以及作業系統環境,會使得canvas的同一繪圖操作流程產生不同的結果。如果是相同的執行環境,同一套Canvas操作流程會產生相同的結果。 瀏覽器指紋的優勢是不需要瀏覽器保持本地狀態,即可跟蹤瀏覽器。  由於國內特色的Ghost系統安裝,這種方式的誤殺率並不低,

 

1.4.1.10 JS引擎指紋

這種思路是,不同的JS引擎在執行相同的JS語句時,會有不同的結果。 舉個例子來說,eval.toString().length,在Safari瀏覽器中的結果是 37 , 在IE中是39 , 在Chrome 中的結果是33. 通過判斷JS引擎的動作和UserAgent中聲稱的瀏覽器型別,可以判斷是否是偽造瀏覽器。

 

1.4.2 應用層反反爬蟲/BOT方案簡介

1.4.2.1 前端逆向

前端逆向,就是利用前端所有程式碼、資料都是暴露給客戶端的特點, 通過分析HTML、JS等原始碼來獲取資料的技術。 常用的前端逆向工具就是Chrome Debug 工具。前端逆向分析通常用來分析那些動態渲染的網站。 如果分析透徹,可以避免使用瀏覽器模擬的方式來進行爬取。

 

1.4.2.2 瀏覽器模擬

瀏覽器模擬指利用真實的瀏覽器去請求、執行頁面和指令碼。應用場景是爬取帶有複雜JS和介面加密的網站、也被BOT用於複雜網站。常見的瀏覽器模擬框架有Selenium WebDriver、 PhatomJS。 Selenium 是通過瀏覽器的debug介面進行瀏覽器的遠端操控API。PhantomJS是一個嵌入了瀏覽器核心的js渲染服務,這種技術可以用來對抗動態渲染和介面加密。所有的渲染和加密過程都由瀏覽器核心完成。 高階的做法是用CEF(Chrome Embedded Framework)進行二次開發。通過二次開發CEF,可以獲得很強的靈活性, 比如在頁面載入之前劫持JS物件、用C++程式碼hook native js api等等。這種技術的主要劣勢是低下的效能。 與純粹的HTTP請求程式碼來說, 這種方案要多吃50~500倍的CPU。 也就是說, 它的效率要下降數十倍到數百倍左右。

 

1.4.2.2 字元識別

光學字元識別(OCR)用於對抗簡單的數字、字母驗證碼。初級的OCR基於模板。高階的字元識別基於神經網路,比如[這個專案],它基於LSTM模型,可以提供更好的識別率。

 

1.4.2.4 行為模擬

行為模擬是指在爬蟲和BOT的過程中,有意的留下Cookie,並請求一些與需要爬取資料無關的介面或者做一些動作,用來模擬一般使用者的動作, 用於對抗行為分析。 在BOT場景下,這種方式也用來模擬使用者的活躍度和留存率。 一般來說,行為模擬的主要依據來源於前端逆向的工作, 破解者需要確定究竟有哪些HTML元素和使用者行為事件被網站所關注,並針對性的做出想要模擬的行為。 大多數情況下,爬蟲的行為模擬是請求某個日誌上報介面, 而一些比較特殊的網站(比如支付寶), 使用者行為資料附著在請求普通介面的引數中,並經過高度混淆。

 

1.4.2.6 打碼平臺

打碼平臺用來對抗強度比較高的驗證碼和人機驗證方案。正常的驗證碼流程是,由網站生成一張圖片傳遞給使用者,使用者輸入這張圖片的資訊傳回網站,完成人機驗證。 破解者通過對接打碼平臺,將使用者識別資訊的環節放到打碼平臺去做,打碼平臺組織一群專職人員,進行驗證碼的識別工作,並傳回爬蟲,完成驗證碼的識別工作。高階的打碼平臺還會利用這些海量的打碼資料進行模型訓練。

 

1.4.2.7 JS Hook

這種方式主要用來對抗js上下文的跟蹤和分析。做法是,在頁面載入前,通過替換JS上下文的物件,將JS上下文中的物件和方法替換掉。 例如,將window.screen物件替換, 使網站的js程式碼獲取到替換後的螢幕解析度。 JS Hook一般在CEF二次開發中實現,也可以通過劫持普通瀏覽器的流量完成js hook。

 

 

二、IP層反反爬蟲技術

2.1 代理伺服器

對於爬蟲的客戶端程式設計來說,利用代理伺服器進行源IP更改,是最簡單易行的方式。 代理伺服器分為HTTP代理和Socks代理兩類。HTTP又分為HTTP和HTTPS代理, Socks又分為Socks4和Socks5兩類。

 

2.2.1 HTTP代理

HTTP代理是一種常見的代理服務型別。常用80、8080埠, 它的協議在RFC 7230 中定義。  對於連線到它的客戶端來說,它是服務端;對於要連線的服務端來說,它是客戶端。它就負責在兩端之間來回傳送 HTTP 報文。 根據XFF頭部的新增與否, 分為普通代理和高匿代理兩類。 普通代理會把請求方的源IP新增在HTTP請求頭, 而高匿代理不會。對於服務端程式設計師來說,通過XFF頭判斷使用者的源IP來源是一種十分 Too Young , sometimes naive 的行為,因為服務端完全沒有能力判斷這個XFF頭是由請求方偽造的,還是由代理伺服器新增的。 網上流傳的一些Java程式碼,會首先判斷XFF頭,如果有則將XFF頭作為源IP處理,這種方式基本沒有任何反爬蟲作用。

 

2.2.2 Socks代理

SOCKS是另外一種常見的代理服務。SOCKS是"SOCKetS"的縮寫[1]。這個協議最初由David Koblas開發,而後由NEC的Ying-Da Lee將其擴充套件到版本4。最新協議是版本5,與前一版本相比,增加支援UDP、驗證,以及IPv6。根據OSI模型,SOCKS是會話層的協議,位於表示層傳輸層之間。 也就是說,Socks通過TCP連線作為隧道進行代理。 Socks代理中,Socks5代理最為常見。

 

接下來我會介紹其他的的IP層反-反爬蟲方案。

目錄如下

2.2 VPN
2.3.1 簡單 VPN
2.3.2 混合網路VPN

2.3 VPS
2.4 單機PPP撥號
2.5 併發PPP撥號

三、併發PPP連線技術簡介
3.1 PPP協議棧簡單介紹
3.2 PPP連線和ADSL的關係
3.3 都會網路技術簡介
3.4 併發PPP連線方案的適用範圍
3.5 國內併發PPP連線服務提供商

四、Linux路由
4.1 Linux基礎路由簡介
4.2 Linux高階路由簡介

 

綜上所述,使用代理IP是解決反扒機制的最佳解決方案,也是最簡單有效的。

為此,我個人研發了一款代理IP池專案,現歡迎大家內測體驗~

傳送門:www.2808proxy.com

解決爬蟲的IP源問題。