API接口訪問頻次限制 / 網站惡意爬蟲限制 / 網站惡意訪問限制 方案

采用多級攔截,后置攔截的方式體系化解決

1 分層攔截

1.1 第一層 商業web應用防火牆(WAF)

直接用商業服務

傳統的F5硬件,不過現在用的很少了 雲時代就用雲時代的產品,典型代表 阿里雲 web應用防火牆

1.2 第二層 API 網關(API Gateway)層

API 網關(API Gateway)

kong為代表的開源 API 網關 實現 openresty + lua 自實現 windows平台 安全狗、雲鎖 實現

1.3 第三層 應用層

用Redis內置lua腳本

redis是塊磚,哪里需要哪里搬 redis內置了lua引擎,2.6版本后你可以編寫一段lua腳本,完成邏輯判斷流程

常見的有對某維度計數器法 對某維度令牌桶法 維度的概念比如就是IP或者IP+模塊等, 多個字段合並成一個維度

本方案滿足絕大多數應用層的限流需求 當然也可以自己用應用層程序實現,前提是redis+lua滿足不了你的需求

2 后置攔截

基本的套路其實很簡單,從日志這里計算出惡意IP,惡意用戶,再給其他系統用 分控的基本思想也是這樣的

已經在用ELK日志系統:可以用ES中定時查詢高頻IP,送入WAF做攔截 已經在用流計算系統:flink和spark等流計算系統計算出高頻惡意IP,用戶等

然后就可以應用這些計算出的結果數據做限制,封禁等

3 一+二+三+后置協同工作

第一層Waf當然有攔截,但是對於新IP他不會馬上生效, 會有幾分鍾的時間才會攔截 特別是惡意爬蟲IP池一上,大量新IP就來了,第一層會放過來,如果只是一層,結果就是數據庫慢查詢告警叮叮叮

配合上二層 三層 一層一層攔截 如果沒有精力搞二層,那么第一層用買的,第二層不做,搞第三層

后置攔截的結果可以作為長期封禁使用 這種多次攔截的策略和多級緩存的概念是不是很像 多層次的攔截保障源站監控告警靜悄悄

面向C端的產品被爬蟲,被惡意訪問的概率會大很多 面向B端的網頁也不是沒有風險 面向B端的API也有限流的需求