遊戲DDoS防護新方案--SDK版

目前遊戲行業 仍是 攻擊的重災區， 這個產品也 應運而生，採用分散式節點部署，攻擊流量分散在不同的節點上，可以無上限防禦 DDOS ， CC 攻擊其他協議攻擊等 。 非常全面的防禦各種攻擊入侵滲透，同時為 使用者 訪問加速。

此產品設計之初僅僅是“江湖救急”為了幫助幾個朋友的遊戲和線上教育平臺抵抗大流量攻擊，後來朋友介紹朋友，不斷有平臺接入測試，為不少平臺輕鬆防護了棘手的流量攻擊。由於傳統高防的不足，針對TCP埠的 CC 攻擊沒有太好的過濾策略，外加流量攻擊量不斷飆高，依靠硬防生抗效果不理想同時防護價格昂貴等，產品經過不斷歷練進行了三次重構。目前產品已經足夠穩定。

這個產品是一款專注於C/S架構的安全防護產品，利用分散式雲叢集攔截針對使用者伺服器的 CC 攻擊、 DDOS 攻擊，透過在APP客戶端整合 SDK 防禦模組，來實現精準快速的切換以及鏈路加密通訊，由於採用了隧道加密通訊技術，使用動態虛擬IP連線，因此，任何 DDOS 攻擊流量都無法進入隧道，同時還可以隱藏真實伺服器IP。

整個防護由三大模組組成，分別是客戶端 SDK 、智慧排程和 身份驗證 。

簡單演示一下大概效果，有感興趣的朋友可以進行溝通交流。市面上有不少同類商用產品，各有各的優點，這個產品並非商業軟體，而是之前給客戶平臺提供運維時候自己團隊開發的產物，有需要的可以免費提供部署和搭建。後續根據實際情況考慮開源。

一、生成 SDK 檔案

透過搭建jenkins線上生成 SDK 檔案

產品支援andro id\ios\windows 三端的原始碼和無原始碼整合。

隨便從搜尋引擎找了一款遊戲app進行演示，因為直接下載的apk檔案並無原始碼，因此，透過逆向的方式將 SDK 整合進去。

透過指令碼進行整合之後進行測試（三端無原始碼整合過程後續單獨寫一個獨立的介紹）。

如果客戶端有微信登入需要提供證書檔案進行重簽名。

 

二、抓包分析

首先安裝原版app進行抓包分析。

透過原版抓包能看到大量dns請求以及http明文請求資料。

再將逆向整合 SDK 的app進行安裝並抓包。

SDK啟動的時候會HOOK掉app的所有網路通訊，由於 SDK 和節點之間是加密傳輸的，因此抓包也無法獲取dns解析記錄以及http、tcp等明文資訊，全部都是私有加密協議進行了封包。（截圖中dns解析記錄應該是在app啟動 SDK 之前或者手機其他app解析請求）對比原版app的dns解析記錄。

62001 埠為 SDK 跟節點加密通訊埠。所有資料都被加密傳輸，無法解密出明文資料。

上圖為節點裡面進行dns解析服務，所有的客戶端dns解析都會在遠端節點進行解析，從而防範了dns汙染和劫持。也可以避免攻擊者獲取域名資訊。整合SDK之後抓包看到的全部都是加密封裝後的TCP資料包。

抓包看到 SDK 跟分配的節點 117 進行通訊，在IP為 117 的節點裡面將加密隧道程式斷開，模擬節點被攻擊產生無法訪問的情況。抓包看到 SDK 迅速切換到分配給使用者的第二個可用IP 154. 所有的切換都是無感知進行的。為了避免攻擊者重複拉取全部節點池， SDK 的驗證端做了身份識別，token、deviceid等方式進行驗證。每個使用者分配的一組 3 個ip都不會重複，如果攻擊者打死分配給他的節點IP，也只會影響到駭客自己。

斷線重連，節點異常自動切換。

SDK 方案優點主要是不依靠生抗來防護，而是透過大量分散式節點排程防護。

其次能完美防護 CC 攻擊，因為節點對外不提供任何業務埠，只對外開放一個加密傳輸隧道埠（ 62001 ）。

SDK 節點切換都是瞬間切換，不依靠域名dns解析方式。cname防護叢集切換依靠域名解析同時無法實現無縫切換，並且防 CC 效果依然不理想。

對比項	傳統方案	SDK 方案
防護能力	僅能靠一個本地機房，頻寬無法擴充套件，無法防禦更大的DDoS攻擊	分散式節點BGP接入，針對遊戲提供高可用的網路環境，理論上無上限的抗攻擊能力
身份驗證	傳統清洗機房僅靠硬體裝置來識別，無法解碼遊戲私有協議	資料包文全鏈路加密，身份驗證，防駭客破解，端到端的加密，遊戲安全接入
節點個數	節點數量有限，容易被逐一打死	節點數量很多，即使打死幾個對絕大多數使用者無影響
CC防護	CC攻擊防護效果不佳，大量漏殺和誤殺，嚴重影響業務	100% CC防護能力，0誤封
啟動防護	識別攻擊行為需要一個過程	即刻識別攻擊行為
攻擊成本	駭客輕易打出幾百Gbps的攻擊	找不到攻擊目標，駭客成本很高
防護成本	防護成本很高	防護成本較低
接入方式	需要DNS解析	無需DNS解析
排程能力	排程時間很長	秒級排程，快速切換節點
排程策略	排程策略很簡單	多維度，排程策略很靈活
節點使用	使用者集中到少數幾個防護節點上	使用者分散到不同節點上
隱秘性	駭客很容易找到攻擊目標	混淆加防逆向抓包，無法找到真實節點IP
防護配置	需配置防護策略	無需配置防護策略
策略制定	需根據攻擊特徵調整防護策略	一次接入，終身免疫
攻擊溯源	溯源困難	溯源成功率將大大提升

Q & A 問答集

1、 埠防CC效果如何？

答：SDK跟節點之間通訊是建立一個加密隧道，只有APP整合sdk之後的資料才會進入，攻擊量無法進入隧道內，同時節點不對外開放任何業務埠，只有一個加密隧道通訊埠 62001 開放。因此，任何針對業務埠的CC都起不到任何效果。所有的業務資料都透過封裝傳送到節點的加密隧道埠，到達節點之後進行解密解包將使用者業務資料傳送給原站伺服器。

2、 最高能防禦多大攻擊量？

答：因為不是依靠高防的生抗模式，全部都透過排程演算法分配節點，因此，駭客攻擊打死的節點也只是影響駭客自己，透過多層識別，杜絕全部節點被拉取。使用者可以在分配的一組唯一IP之間無感知切換。cname高防轉發模式則會出現掉線，延遲高，過濾規則誤封真實使用者的情況。無感知切換是透過SDK進行處理的，不存在透過cname域名進行排程切換的弊端。

3、 文中提到的虛擬IP如何使用？

答：為了更好的保護APP不被逆向破解，我們建議使用者客戶端連結服務端的域名解析到虛擬IP，如果客戶端繫結的是IP地址，可以換成我們的虛擬IP。虛擬IP是一個環路IP不會在網際網路上傳輸，但是客戶端整合SDK之後就可以使用虛擬IP跟我們節點建立加密通訊了。虛擬IP類似 127.0.0.1~127.0.0.255

4、 整合之後是否可以抓包到客戶端明文資料？

答：APP整合SDK之後會hook全部app的通訊資料封裝到我們的加密協議裡面，並與節點建立加密隧道。任何資料都是加密之後傳輸的，透過抓包是無法顯示明文的。有的客戶有單獨需求，比如社交影片等app，這類客戶流媒體資料較多，如果都走節點會造成增加成本和擔憂額外延遲等情況，因此sdk支援例外設定，比如連結第三方流媒體或者儲存更新資源等無需保護的連結進行直連訪問。

5、 是否可以私有化部署防護系統或者自己二次開發？

答：可以提供私有化部署，甚至如果您有開發能力都可以將原始碼二次開發，私有化部署更獨立，更安全，所有的資源、節點、資料都在使用者可控的獨立裝置上，與外界其他平臺無任何關聯。