最近逛一些國內(nèi)外的知名技術(shù)網(wǎng)站，發(fā)現(xiàn)了一個現(xiàn)象，大家仿佛約好了似的，都開始搞人機(jī)驗證了。

為啥原來人機(jī)驗證很少，現(xiàn)在頻率這么高呢？

原因很簡單：AI爬蟲。

現(xiàn)在大家已經(jīng)習(xí)慣了問AI技術(shù)問題，但是AI的數(shù)據(jù)從哪里來呢？自然是從這些技術(shù)網(wǎng)站“爬”來的。

如果爬蟲按照robots.txt還好，壞就壞在有些爬蟲完全不按規(guī)則行事，技術(shù)網(wǎng)站就不得不防了。

“原先就被爬，AI 起來以后，防不勝防，爬的更狠了”——某位大論壇的 CEO 如是說。

防止爬蟲，技術(shù)上有很多方法，例如檢查User-Agent，Referer，限制訪問頻率，檢查Cookie等等。

只不過這些傳統(tǒng)的方式很容易被爬蟲繞過，逃過檢測。

所以現(xiàn)在出現(xiàn)了一些更高級的反爬蟲思路，例如識別行為：檢測鼠標(biāo)鍵盤的使用習(xí)慣，檢測瀏覽器窗口的擺放位置，綜合判斷是不是真人行為。

識別本地瀏覽器的客戶端特征，禁止無頭瀏覽器訪問。

注入算力驗證腳本，消耗 CPU 資源，抬高客戶端的訪問成本，讓原本每秒可以訪問 1000 次的設(shè)備，在被保護(hù)后每秒只能訪問 1 次。

打亂HTML結(jié)構(gòu)，混淆JS代碼等等。

這些防護(hù)行為，網(wǎng)站想自己實現(xiàn)非常麻煩的，最好用專業(yè)的軟件，比如雷池這樣的Web應(yīng)用防火墻。

雷池全球裝機(jī)量超過50多萬臺，日均處理300億次請求，檢出率76.17%，誤報率僅0.22%。

在GitHub上，雷池的star已經(jīng)達(dá)到20.9k，是最受歡迎的WAF項目，沒有之一。

它的安裝非常簡單，一行命令就行：

bash -c "$(curl -fsSLk https://waf-ce.chaitin.cn/release/latest/manager.sh)"

安裝成功以后，就可以打開瀏覽器訪問雷池控制臺了

https:// :9443/

01

爬蟲防護(hù)

安裝好以后，進(jìn)入人機(jī)驗證設(shè)置：

然后訪問被雷池 WAF 防護(hù)的網(wǎng)站，就會看到雷池正在檢查客戶端環(huán)境的安全性。

合法用戶等待兩三秒以后，真正的網(wǎng)頁內(nèi)容會自動載入，惡意用戶則會被阻攔。

如果檢測到本地客戶端被自動化程序控制，訪問依然會被阻止，如下圖：

還可以啟用動態(tài)防護(hù)功能，，對返回給瀏覽器的 HTML、JS 進(jìn)行動態(tài)處理，讓每一次訪問看到的代碼形態(tài)都不完全一樣。

這樣一來，爬蟲和自動化腳本就很難通過“靜態(tài)規(guī)則”來理解頁面結(jié)構(gòu)，比如這個JavaScript：

被雷池進(jìn)行動態(tài)加密以后變成了這個樣子，很難辨認(rèn)了。

特別值得一提的是，雷池的人機(jī)識別是采用的是云端驗證方式，每一次驗證都會調(diào)用長亭的云端 API 來輔助驗證。

結(jié)合雷池的 IP 威脅畫像數(shù)據(jù)，瀏覽器指紋數(shù)據(jù)，最終對于爬蟲的識別率超過 99.9%。可以說是反惡意爬蟲的最佳利器。

與此同時，云端的算法和 JS 邏輯會持續(xù)自動更新，即使被厲害的大佬破解，破解的也只是過去的版本，雷池永遠(yuǎn)跑在攻擊者的前面。

看著這么高的識別率，網(wǎng)站站長們肯定會擔(dān)心這會不會影響 SEO，會不會影響搜索引擎對于網(wǎng)站頁面的收錄情況。

答案當(dāng)然是 “不會”，雷池貼心的提供了各大搜索引擎的爬蟲 IP 列表，如果對 SEO 有需求，只需要對這些 IP 加白即可。

02

CC防護(hù)

在 Web 世界里，有一類攻擊特別讓人難受，叫 CC 攻擊（Challenge Collapsar）。

攻擊者會控制大量肉雞（被感染的電腦）或代理服務(wù)器，偽裝成正常瀏覽器訪問網(wǎng)站，不斷訪問首頁、搜索頁、接口等。每個請求看起來都合法（有正常的 User-Agent、Referer、Cookie），但數(shù)量極其巨大。

最終讓服務(wù)器過載，網(wǎng)頁卡死、數(shù)據(jù)庫阻塞或服務(wù)崩潰。

由于請求看起來都合法，這種攻擊非常難以防御。

針對這種情況，雷池防火墻提供了“頻率限制”的功能，如果某個 IP 在短時間內(nèi)發(fā)起大量 HTTP 請求，就阻斷該 IP 后續(xù)的所有訪問，要求它通過人機(jī)驗證，確保是真人才行。

還有不少應(yīng)用存在高峰流量的情況，比如搶票，熱點事件等，如果不進(jìn)行限流，服務(wù)很容易被海量的請求沖垮，誰也用不了。

當(dāng)然程序員可以寫代碼，深入到網(wǎng)站內(nèi)部去實現(xiàn)限流功能，但是很麻煩，使用雷池的“等待室”功能，根本不用對應(yīng)用做任何改變就可以實現(xiàn)限流。

這里配置的在線用戶是超過了100人就需要進(jìn)入等待室等候了，而進(jìn)入應(yīng)用的用戶，如果超過3分鐘在網(wǎng)頁上沒有操作，對不起，那就去等候室重新排隊吧。

03

身份認(rèn)證

第一次看到“防火墻自帶身份認(rèn)證”這個功能時，我也愣了一下。按理說，認(rèn)證不是應(yīng)用程序自己該做的事嗎？

但仔細(xì)想想，這個功能解決的其實是一個很現(xiàn)實的問題：很多系統(tǒng)從一開始就沒打算暴露在公網(wǎng)。

比如一些內(nèi)部工具、監(jiān)控頁面、管理后臺，本來只打算給小范圍的人用，結(jié)果后來為了方便，直接掛到了服務(wù)器上。

這類系統(tǒng)往往認(rèn)證簡單，甚至干脆沒有認(rèn)證，一旦被掃到，就是一個現(xiàn)成的入口。

雷池在這里提供的是一種“外掛式”的解決方案：不改應(yīng)用代碼，只在防火墻層面加一層身份校驗，就能把這個入口先堵住。

它不是用來替代應(yīng)用本身的權(quán)限系統(tǒng)，而是在你來不及重構(gòu)之前，先把門鎖上。

04

語義檢測

除了上面所說的各種防護(hù)，雷池對于 SQL 注入、XSS、路徑穿越、命令注入這些老生常談的攻擊方式，自然不在話下。

雷池的準(zhǔn)確率、檢出率都非常高，誤報率，漏報率非常低，性能指標(biāo)優(yōu)于全球的一些知名產(chǎn)品：

但真正讓我覺得它“不只是換了個殼”的，是它背后的思路。

傳統(tǒng)防火墻更多是規(guī)則匹配，比如看到 union、select 這些關(guān)鍵字，就覺得你可能在搞 SQL 注入。

問題是，這種方式一方面容易誤傷，另一方面也很容易被繞過， 稍微有點經(jīng)驗的攻擊者，換個寫法、插點注釋，例如只要在在 union 和 select 中間插入了注釋字符：union /**/ select，這樣破壞了關(guān)鍵字的特征，傳統(tǒng)防火墻就檢測不出來了。

雷池用的是另一條路：語義分析。

它不是只盯著字符本身，而是嘗試?yán)斫膺@段輸入“在語義層面想干什么”。

對HTTP 請求解碼之后，會根據(jù)內(nèi)容類型交給不同的解析器，再判斷這段輸入是否真的會構(gòu)成攻擊。

說白了，就是：不看你寫得像不像壞人，而是看你做的事能不能真的傷到系統(tǒng)。

05

總結(jié)

正是由于雷池精準(zhǔn)地、漂亮地解決了Web系統(tǒng)廣泛存在的安全問題，吸引了全球大量客戶的使用，成為優(yōu)秀企業(yè)的信賴之選。

如果你也有Web網(wǎng)站，需要把安全防護(hù)做好，強(qiáng)烈建議考慮下雷池這個非常優(yōu)秀的開源的WAF。

最后，有什么建議和問題，歡迎大家加入雷池的微信交流群：

也歡迎大家到GitHub，給雷池點個小星星，支持下國產(chǎn)的WAF:

https://github.com/chaitin/SafeLine