連線變慢，DDoS 就像喪屍般來襲！用電影「末日之戰」解釋網路癱瘓，不是高手也能搞懂資安

「如喪屍浪湧般前仆後繼而來」，這幾乎是「分散式阻斷服務攻擊」（DDoS，distributed denial-of-service attack）的最佳詮釋，如同「到銀行提款領一元銅板、到加油站加油分數次結帳」利用「癱瘓」造成不便、使之就範，就是 DDoS 的核心攻略，甚至更進階地模仿惡搞者胡鬧行為「假冒 A 名、訂便當給 B 」，著實令網管人員頭痛不已。然而， DDoS 為何近年間如此大肆興起、花招百出？

根據調研機構報告指出，「DDoS  分散式阻斷服務攻擊」於 2012~2016 年 與2017 ~ 2018 年間爆量成長，其原因歸咎於「網路服務崛起」、「連網設備遽增」、「惡意軟體取得容易」三大原因。宛如喪屍電影中「越往人多的地方跑，越有可能被咬」的固定套路，舉凡有網路功能的裝置（如：網路攝影機）都有能「被咬」（遭駭客操作），成為向企業網路發出癱瘓攻擊的喪屍設備。　 有趣的是我們發現，電影中防禦喪屍的方法竟可以巧妙的應用在網路安全中。

實務上，全球應用最廣泛的雲端服務大廠 Amazon Web Services ( AWS ) 也用類似「末日之戰」中的抗屍手法，協助客戶排除 DDoS 攻擊。AWS Support 團隊選擇從 CDN 內容交付網路（Content Delivery Network）與 DNS 網域名稱系統（Domain Name System）下手，採取「啟用 CDN 服務」與「調整 DNS 設定」來協助客戶解決問題。

首先，利用 CDN 其分散式節點的特性，將攻擊的流量「疏洪」至 AWS 於世界各地的伺服器上，好處不僅將瞬間的大量癱瘓攻擊「化整為零」，更將攻擊分流到多個不同的 AWS 伺服器上，此舉形同為原始伺服器製造出多個分身，避免「 IP 位址」與「網域名稱」暴露而遭到駭客鎖定攻擊。其後，再將原始伺服器「 IP 位址」與「網域名稱」隱藏在 CDN 後方，讓後續幾波的惡意癱瘓流量找不到位置，因而無法針對性的集中攻擊。

AWS Support 團隊指出，電影末日之戰前段中主角強調「要不斷移動，不要待在原地」的教條，因為這樣很容易就被找到了。當然，實務上伺服器不可能到處移動，但我們卻能製造出看起來「不斷移動的現象」，即為原始伺服器製造出大量的「分身」。你可以想像一下，當駭客以為正在攻擊目標時，卻發現目標的數量增加且不斷變化，無法發動針對性的集中攻擊，亦或只能把攻擊分散至如「熱誘彈」般的數個分身伺服器上。障眼法效果，不禁讓人想到電影中布萊德彼特對自己施打天花病毒，佯裝重症者來躲避攻擊，即便喪屍在眼前仍然能毫無顧忌的穿梭其中。同樣，縱然有威脅存在，客戶也能 提供正常的服務維運。

此外，AWS Support 團隊更建議透過防火牆的設定，將安全的 IP 地址加入白名單內，來保護原始伺服器。更進階的做法，則是透過 AWS WAF 的「以速率為基礎的規則」來限制每個 IP 地址的請求次數，如：設定 5 分鐘內，單個 IP 地址發送超過 500 次請求，則判斷為異常行為並加入阻擋清單。

駭客們就這兩三招？他們當然不是省油的燈，除了透過上述被「啃咬」感染的喪屍設備進行攻擊，還透過了升級版的槓桿行為來加深 DDoS 的攻擊力道、增加追查難度，AWS Support 團隊就曾發現過這樣的攻擊案例。

某日，客戶收到了來自 AWS 安全機構的通報，指出該客戶帳號底下的資源正在攻擊另一個網站（受災方）。原本以為只是一起單純的資安事件，卻在 AWS Support 團隊追蹤下有了重要發現：原來駭客（發動方）竟假冒某個第三方網站（受災方）的 IP 位址，向該客戶的資源發送連線請求而該資源也不疑有他的將之視為正常的連線請求，並給予回應，想不到這回應卻成了第三方網站的癱瘓攻擊。在這案例中，AWS 所服務的這家客戶不僅被誤認成了攻擊者，實際上卻是受害者。

當 AWS Support 團隊發現此一現象是「偽造攻擊者手法」後，立即採取了以下因應措施：首先，先抓出「流量」是誰發起的？AWS Support 團隊建議，AWS 客戶可以使用 VPC 流量日誌找出發起連線的來源。其次，透過安全群組及網路存取控制清單 (ACL) 去管控「允許存取」的連接埠及 IP 清單。最後，AWS 客戶可以檢視 Trusted Advisor (註1)的檢查結果來確認是否存在開放過多連接埠的安全群組問題。