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

贊助專題 Supported By

評論
Photo Credit:Unsplash
Photo Credit:Unsplash
評論

本文章內容由「AWS」提供,經關鍵評論網媒體集團廣編企劃編審。

(本文啓發自AWS網路研討會内容,意者歡迎至此連結觀看重播:http://bit.ly/2MPLNEe) 

「客服反應,公司網路變慢」

「快去查一下,是不是 DDoS 攻擊」

DDoS  一詞對於 IT 工作者來說並不陌生,但對於廣大的職場工作者而言,恐怕是聽其名、觀其字卻不知為何物?事實上它並沒有那麼難懂,只要觀察「喪屍」與「惡搞者」就能知其一二。

喪屍片套路:越往人多的地方跑,越容易被咬

「如喪屍浪湧般前仆後繼而來」,這幾乎是「分散式阻斷服務攻擊」(  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 次請求,則判斷為異常行為並加入阻擋清單。  

【真實客戶特徵】
產業:廣告與商業智慧
主機:架設於現場部署環境(無保護下,易遭受攻擊)
現象:網站的可用性下降,造成網頁無法開啟,跳出錯誤訊息
影響:企業客戶(使用者)無法使用其平台服務(廣告資訊、精準投放、流量分析)
具備:AWS Enterprise Support
解方:
a. 隱藏原始伺服器 IP 地址,以避免直接受到攻擊
b. 設定 IP 地址白名單及請求速率條件,以阻擋異常流量

比喪屍可怕, 惡搞者行為:假冒 A 名,訂便當給 B

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

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

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

【真實客戶特徵】產業:加密貨幣
主機:架設在於 AWS 環境
現象:第三方網站誤以為遭受 AWS 客戶的資源攻擊
影響:AWS 客戶被回報為攻擊者,要求對資源進行調查
具備:AWS Enterprise Support
解方:
a. 使用安全群組及網路存取控制清單(ACL)管控「允許存取」連接埠及 IP 地址清單
b. 檢視 Trusted    Advisor 的檢查結果,確認以下兩點:1. 是否開放過多的連接埠給外部使用。 2. 連接埠是否開放過多的 IP 地址連線

防被啃、防被整,請學「第十人理論

若是以近期全球火紅的開箱大挑戰來看,AWS Support有著:應用工具、技術教學、人員解答、客製計劃,也同時擁有兩項診斷網路安全的工具AWS Personal Health Dashboard和 AWS Trusted Advisor。諮詢顧問團隊包含了 DevOps 技術、自動化、基礎設施協調作業、組態管理和持續整合的雲端支援工程師。

另外,AWS Shield ( 註 2 ),則可大致分為兩種形式,其中  AWS Shield Standard 是免費服務,適用於 AWS 所有客戶,可阻擋  96%的 DDoS 攻擊行動,付費部分則有 AWS Shield Advanced,可支援到應用層與網路層的資安防護,還能全天候獲得  AWS DDoS 安全團隊的協助。

電影末日之戰中,有個經典的「第十人理論」,其意義概要是若一件事情 9 個人都贊成去做,第  10 人無論如何都要站在防範於未然的立場,為可能的意外與風險做好準備,而台灣的企業在網路安全上也能採用 AWS Support 與  AWS Shield Advanced 來擔任最佳第十人的角色,全面防禦 DDoS 的相關攻擊。  

立即獲得 專家指導協助: https://amzn.to/2VkZdvZ (還不是 AWS 用戶?記得要先在以下連結完成註冊)

註1:AWS Trusted Advisor 是可提供即時指導的線上工具,能夠按照 AWS 最佳實務協助佈建您的資源。 無論是建立新的工作流程、開發應用程式或做為進行中改進的一部分,定期利用  Trusted Advisor 提供的建議有助於讓您以最佳方式佈建解決方案。

註2:AWS Shield 是一種受管的分散式拒絕服務 ( DDoS ) 保護服務,可保護 AWS 上執行的應用程式不受攻擊。AWS Shield 不只提供永遠開啟的偵測服務,還提供自動的內嵌風險降低功能,可將應用程式停機與延遲時間縮到最短。

評論