淺談DDoS攻擊 1 - 多IP防護的新思路

隨着物聯網的發展, DDoS 攻擊變得愈來愈廣泛. 站長們或多或少都據說過或實際被 DDoS 攻擊過. 本文經過我這幾年應對 DDoS 的經驗, 來給你們描述一個開銷比較小的 DDoS 防護思路, 但願可以拋磚引玉.

分類

常見的 DDoS 攻擊從流量真實性 (流量是否真正做用到了業務上) 上來說, 顯而易見只有兩種:

- 真實流量 DDoS

- 假流量 DDoS

咱們先看真實流量 DDoS. 真實流量 DDoS 實際上是很難防護的, 尤爲是對站點資源真實請求的攻擊, 將會對運維帶來極大壓力.

好比利用網絡上公開的 web 反向代理站點發起的攻擊, 這種攻擊與正經常使用戶訪問高度類似, 很難解決.

又或者注入了大流量網站, 將大流量網站的請求跨域請求到了受害者的站點.

但這種攻擊成本高, 並且收益不高, 因此對於中小型站點是不多見的.

接下來是假流量 DDoS.

從攻擊成本, 流量放大倍數等因素綜合來看, 基於非 TCP 協議的反射型 DDoS 攻擊仍然是如今針對中小站點小規模 DDoS 攻擊的最佳選擇.

所以, 站點所受攻擊大機率也是反射型的假流量 DDoS 攻擊.

想要完成這樣的攻擊, 須要如下條件:

- 能夠修改 Packet Header 來將流量導向受害者.

- 可利用的反射節點存在反射.

咱們來依次講解:

可修改 Packet Header 指, 因爲 UDP 等協議是非面向鏈接的, 所以僞造 Source IPv4 Address 是很容易的, 這樣就能夠把 Source IPv4 Address 設置爲受害者的 IPv4 地址.

反射節點指, 利用上面的可篡改的協議訪問一些特定暴露在網絡上的服務時, 這些服務返回的數據比請求所需的數據大, 而且大不少倍. 越大攻擊效果越好.

例如 Memcached 協議漏洞, 假設有一些 Memcached 服務器沒有加任何保護措施就放在了公網上, 咱們甚至能夠自由操做這些 Memcached 服務器. 那麼咱們只需在 Memcached 裏面 SET 一個巨大的數據, 而後發起一個對 Memcache 的請求, 該請求的 Source IPv4 Address 填寫爲攻擊目標的 IPv4 地址. 這樣就完成了攻擊.

這樣的攻擊足足能夠把流量放大 10,000 - 51,200 倍, 畢竟請求的 Payload 就是一個 GET {key} 的二進制數據. 但返回的倒是咱們以前 SET 到裏面的一大坨數據. 假設咱們控制的僵屍網絡能夠發起 50Mbps 的請求, 那麼通過 Memcached 協議漏洞的放大, 咱們獲得的攻擊帶寬就是 50Mb * 51,200 = 2.44Tb. 這是多麼可怕的結果. 要知道歷史上最大的 DDoS 帶寬也才 1.35Tb.

這樣的攻擊的成本是至關低的. 現現在家用寬帶的上行都有不少甚至能達到 30Mb 的帶寬, 而家用物聯網設備也愈來愈多. 咱們能夠想象到, 一旦家裏有存在漏洞的設備, 那麼這些漏洞頗有可能被利用. 最典型的就是一些家用路由器的 SSDP 漏洞, 路由器剛好又是插在寬帶的入口上的. 若是能被訪問到, 這將是很可怕的後果.

雲服務商的防禦服務

普通對於反射式 DDoS 攻擊最好的防護方式固然仍是交給雲服務商去作. 但云服務商提供的高防 IP 或 DDoS 防禦服務也有如下缺點:

- 售價高

下面是國內某雲服務商的最低檔高防 IP 服務的售價:

線路資源: 八線BGP, 地域: 中國大陸, 保底防禦帶寬: 30Gb, 彈性防禦帶寬: 30Gb, 業務帶寬: 100 M, 功能套餐: 標準功能, 防禦域名數: 50, 業務QPS: 3000, 端口數: 50, 購買數量: 1, 購買時長: 1個月, 配置費用: 20,800.00 CNY

30Gb, 每個月 2 萬塊. 能夠負責任的說, 這個防禦帶寬人家想打垮你簡直是欺負幼兒園小朋友. 但這個價格可不是通常中小型站點能接受的.

- 延時不理想

接入高防後, 用戶流量會先到高防, 而後回源到你的業務.

可是, IDC 的高防設備須要巨大的帶寬接入, 所以高防設備爲了節省帶寬等費用, 所在的 IDC 頗有可能不在一線城市. 這就帶來了第二個問題, 延時會增長許多. 這對用戶體驗是傷害性的.

- 回源 IP 不慎泄露

這個嚴格來說不是高防服務商的問題, 而是自身的問題. 因爲回源 IP 不慎泄露, 致使 DDoS 仍是直接打在了本身的業務對應的 IP 上.

一種新思路

那麼, 咱們本次就討論如何去經過一些其餘的思路去防護相似這樣的攻擊.

咱們先分析攻擊者的整個操做流程.

首先, 攻擊者須要肯定攻擊目標, 由於攻擊數據包的協議是 4 層協議, 因此攻擊者須要的信息只有一個, IP 地址.

可能他接到的就是個IP地址, 也有可能他接到的是個域名, 或者URL. 這時候他就要經過 DNS 把域名轉換到 IP 地址.

而後它把 IP 地址, 或一堆 IP 地址 (好比你的域名負載均衡到了多個IP). 填寫到他的攻擊程序中. 而後剩下就是運行程序, 開始攻擊了.

咱們能夠想到, 攻擊者控制的發起帶寬確定不是無限的, 能夠用的反射資源也不是無限的, 所以, 若是同時攻擊的目標越多, 每一個目標分攤的攻擊帶寬就越小.

好的, 這就是咱們防護的第一個核心思路: 經過多 IP 來減小每 IP 的被攻擊帶寬.

另外, 在我對攻擊過程的觀察中, 發現有的攻擊對 IP 的變化是不敏感的.

好比, 你遭到攻擊的 IP 被 IDC 下線了, 這時候你換了個新 IP, 攻擊有時並不會馬上來攻擊你的新 IP.

這種要麼是你實際上是無辜的, 對面攻擊的是一個 IP 範圍, 你只是剛好被波及了. 這種狀況常見於跟別人複用服務器的狀況.

另外的可能就是攻擊者沒有及時跟進變化或者放棄了攻擊.

那麼, 咱們能夠經過以上的思路, 去構建咱們的防護體系.

首先咱們須要買一個服務, 叫作 CNAME 負載均衡.

應用了 CNAME 負載均衡後, 用戶訪問你的域名, 首先會請求 DNS, 獲得目標域名對應的 CNAME 域名, 而後經過 CNAME 域名去獲取真實的目標 IP.

CNAME 負載均衡的優點是, DNS 切換 CNAME 記錄比切換 A 記錄生效更快, 客戶端緩存比較容易獲得更新 (固然這要看 DNS 服務商和客戶端的具體設置和實現).

生效快緩存容易更新就意味着, 發生攻擊時, 經過切換 IP 來讓正經常使用戶繼續訪問這個過程會代價更小.

那麼不妨咱們來計算一下. 假設我 CNAME 負載均衡後面對應了 50 個 IP. 那麼一波300Gb的攻擊, 若是被均攤, 每 IP 受到攻擊的平均帶寬是 300Gb / 50 = 6Gb. 這個攻擊帶寬頗有可能會包含在購買 IP 時贈送的防護帶寬以內了.

那麼, 50 個 IP 的成本是怎樣的呢? 每 IP 的租用均價 (按流量付費,流量費用另計) 大概是 0.020 CNY/h, 50 個 IP 一個月就是 0.02 x 24 x 30 x 50 = 720CNY. 是否是很便宜?

甚至咱們還能再屯它 50 個 IP, 被打了的時候就挨個換, 跟他玩, 看誰先沒耐心.

進階防護

有了多 IP 後, 咱們甚至能夠再弄一些更復雜的防護策略.

咱們剛纔假定的都是每 IP 的流量是均分的. 但實際上站點用戶在地理位置上不是均勻分佈的. 所以有些 IP 必然正常流量會大一些. 那麼針對這些IP, 咱們能夠買一些便宜的防禦服務. 經過變相降級的方式, 讓大部分用戶遭到攻擊時, 仍然能夠繼續訪問. 因爲攻擊者跟咱們信息不對等, 所以他若是想知道哪些 IP 是大流量 IP 而轉去攻擊的話, 仍是很難的. 這樣也算變相節省了防護部分的費用.

若是咱們能接入雲服務商的 OpenAPI, 甚至咱們能夠經過程序去動態的更換IP, 進一步下降運維壓力.

總結

以上所講的防護方式, 對於無狀態業務是最有效的, 例如網站.

但對於有狀態業務, 例如遊戲服務器, 是很難的. 遊戲服務器不管是什麼協議, 很難去切換IP. 由於一但切換, IP 對應的全部客戶端就要從新鏈接服務器, 這對一些實時性很高的遊戲是難以忍受的. 但對於自己就用 HTTP 的一些實時性較低的遊戲, 例如棋牌類遊戲, 是能夠考慮的.

多屯點 IP 沒壞處, 畢竟一個 IP 放着一個月也才 14 塊.

上述方案在我接近 3 年的實際應用期間, 起到了不小的做用, 對於 100Gb 如下的攻擊, 基本在發現被攻擊 15 分鐘以內, 就可讓大部分用戶繼續正常訪問了. 但對於 500Gb 以上的攻擊, 更多的比的是耐心, 尤爲是在買不起高防的狀況下, 只能人工防護, 儘可能減少損失了.

本文僅是我的經驗, 歡迎各位大佬不吝斧正.

Reference

• www.cloudflare.com/learning/dd…