因為最近不欠DDoS的實際對應機會
找了本書看看，寫摘要及個人處理心得
這篇主要著重個人能處理的部分
DDoS有好幾種攻擊方式
直接攻擊是最早發展出來的攻擊做法，簡單但是現在也容易處理
1. ICMP flooding
2. UDP flooding
ICMP是網路協定中的廣播傳輸規格，UDP則是常見的網路傳輸規格
直接攻擊是丟這兩個類型的封包到被攻擊對象，現在較少見了
因為這個攻擊取決於攻擊者本身的頻寬，如果本身的頻寬不夠，攻擊就不構成威脅
另一方面則是相對好處理，可以在防火牆端直接Drop這兩種封包
雖然會接收UDP封包的Server 數量多了些，但仍然能從封包pattern等等協助處理
反射和放大攻擊(DRDoS, Distributed Reflection Denial of Service)是進階的攻擊方式
將請求的來源IP偽造成被攻擊對象的IP
那些接收到請求的Server或設備的回應封包會被送到被攻擊的對象
反射攻擊因此更難以溯源
另外因為攻擊者會選擇回應封包量大的對象丟出偽造的請求
所以用較少的頻寬就能消耗更多的網路頻寬
這個攻擊的其中兩種較常見
1.ACK
連線建立的其中一個步驟是ACK確認
如果Server遲遲接收不到請求端的ACK回應，就會發送要求確認的請求到請求端
這個特性因此被利用
2.DNS
DNS也是常見的被攻擊的設備，只能指望大多數的DNS擁有者會更新有漏洞的設備
攻擊鏈路(The Coremelt Attack)不以對象為目標，而是以其上層的骨幹網路為目標
這個攻擊需要有分布足夠廣泛的殭屍網路
讓殭屍網路經由被攻擊目標的骨幹網路互相對傳大量封包占用頻寬
讓被攻擊對象難以藉由出入口的骨幹網路接收或傳送封包
因為很難確定互傳封包的雙方是真的有傳送需求、或是有意的攻擊，更加難以防護跟緩解
這個攻擊也不是個人能處理的，需要指望上層的ISP供應商
除了消耗頻寬外，系統資源也可能是被攻擊的對象
1.攻擊TCP
主機會藉由連結表保存TCP的連線資訊
藉由大量快速建立的TCP連線占滿Server的連結表，就能讓目標無法接受新的TCP連線
2.SYN
SYN flood可以參考wiki的說明，也是占用主機的總連線數量
PSH、RST 這兩種也是同樣的目的
Sockstress 這樣的慢速攻擊則是從不一樣的作法達成相同目的的攻擊方式
將傳輸速度設限到非常小，長時間的拖住連線的進行，讓連線無法快速地被釋放
除了連線資源外，還有應用資源的攻擊類型
1. HTTP flooding 會盡可能請求無法被cache的資源，如個人資訊
2. SSL Flood and SSL Renegotiation Attacks
這兩種攻擊消耗系統的運算能力或記憶體空間
特別是SSL的解密耗用資源是一般請求的數倍
所以即使是送出錯誤的SSL請求也能耗用系統大量的記憶體或CPU運算
這個是我目前碰過較棘手的攻擊之一
黑客不會沒有目的就發動攻擊
常見的原因有 1.練技術 2.報復 3.勒索 4.國家級的目的
DDoS 的應對方式就是讓服務能撐下去
讓黑客覺得即使再繼續投入資源也沒辦法達成目的
當然現在很多服務都講求運端運算，DDoS也不例外
DDoS 的租用服務讓攻擊成本降低
所以現在發動DDoS的頻率很頻繁，攻擊的對象也不局限在大型服務廠商
緩解DDoS攻擊的處理方式有以下幾個
1. CDN
絕大多數的網站都會使用的方式之一，將靜態資源放到CDN上降低Server的傳輸量
2. IP信譽
紀錄短時間內大量連線的IP，當一個IP請求到一定數量就封鎖他
這個也幾乎是各個網站的標準設定之一
當然這個沒那麼準確，較新型的攻擊也會平衡各殭屍網路IP的請求數量
3.攻擊特徵匹配
看看攻擊的連線的header或內容是否含有哪些特徵
在防火牆端就可以過濾掉有特定特徵的連線
有些比較難纏的攻擊的內容也不太好抓特徵
4.速度匹配
SSL的驗證流程理論上不會重複太多次，重複協商了SSL很多次的連線也考慮Drop掉
太長時間沒有完成的請求也應該要Drop
上面有提過最近公司碰到的SSL攻擊比較棘手
有過Container的instance因為記憶體被吃光而crash的狀況
當然因為我們有重啟跟平衡負載機制，所以那段期間客戶應該較沒受到影響
後來我們追蹤Container的連線機制source code
發現他是用效率較差的while迴圈+thread的sleep做 Non-blocking
升級Container版本後，連線的效率改善也讓SSL攻擊的影響降低
所以追蹤自己用的Container機制並更新到適合的版本也是一種做法
5.流量洗清設備
分成硬體跟軟體的解決方案
硬體的話可以購買單純的流量洗清設備
這類專門處理流量的設備會具有容量較多的TCP連線表，可以容納更大量的外部連線
加上提供設定可以解決一部份的攻擊
軟體層解法則是可以另外建立一個接收並過濾連線的Container instance
Nginx 跟 Node.js 都是很輕量、擅長對應大量連線的容器
之前的話我們有很認真地考慮過為了這個機制改變架構
不過後來其他方面改善後，一般的DDoS就影響不大
加上我們希望等日後服務規模更大後再一併調整架構
所以暫時還沒有實現的機會
搭配上述解法，我們還可以用一些方式來過濾連線
1. Flag transfer
例如: Http Status 302會要求連線轉址到其他位置
但是反射攻擊或不具備解析Http Status能力的流量攻擊，就會卡在這邊而不會轉到其他網址
Java端的實現sample如下
response.setStatus(HttpServletResponse.SC_MOVED_PERMANENTLY);
response.setHeader("Location", "http://somewhere/");
2. 使用者端真實性驗證
例如 JavaScript運算要求，簡單的要求回傳1+1的結果
如果連線端不是瀏覽器或不具備JavaScript辨識引擎就會被過濾
另一些需要人類辨識的機制，例如recapthca這類的圖片驗證碼也是這樣的概念
以Ragic使用雲端服務的經驗來看，較傳統的SYN flood對我們幾乎是無感
影響較多的還是SSL攻擊等較新型、作用在更高連線層次的攻擊
DDoS應付能力也可以做為軟體建置是否使用雲端服務的考量之一
找了本書看看，寫摘要及個人處理心得
這篇主要著重個人能處理的部分
DDoS有好幾種攻擊方式
直接攻擊是最早發展出來的攻擊做法，簡單但是現在也容易處理
1. ICMP flooding
2. UDP flooding
ICMP是網路協定中的廣播傳輸規格，UDP則是常見的網路傳輸規格
直接攻擊是丟這兩個類型的封包到被攻擊對象，現在較少見了
因為這個攻擊取決於攻擊者本身的頻寬，如果本身的頻寬不夠，攻擊就不構成威脅
另一方面則是相對好處理，可以在防火牆端直接Drop這兩種封包
雖然會接收UDP封包的Server 數量多了些，但仍然能從封包pattern等等協助處理
反射和放大攻擊(DRDoS, Distributed Reflection Denial of Service)是進階的攻擊方式
將請求的來源IP偽造成被攻擊對象的IP
那些接收到請求的Server或設備的回應封包會被送到被攻擊的對象
反射攻擊因此更難以溯源
另外因為攻擊者會選擇回應封包量大的對象丟出偽造的請求
所以用較少的頻寬就能消耗更多的網路頻寬
這個攻擊的其中兩種較常見
1.ACK
連線建立的其中一個步驟是ACK確認
如果Server遲遲接收不到請求端的ACK回應，就會發送要求確認的請求到請求端
這個特性因此被利用
2.DNS
DNS也是常見的被攻擊的設備，只能指望大多數的DNS擁有者會更新有漏洞的設備
攻擊鏈路(The Coremelt Attack)不以對象為目標，而是以其上層的骨幹網路為目標
這個攻擊需要有分布足夠廣泛的殭屍網路
讓殭屍網路經由被攻擊目標的骨幹網路互相對傳大量封包占用頻寬
讓被攻擊對象難以藉由出入口的骨幹網路接收或傳送封包
因為很難確定互傳封包的雙方是真的有傳送需求、或是有意的攻擊，更加難以防護跟緩解
這個攻擊也不是個人能處理的，需要指望上層的ISP供應商
除了消耗頻寬外，系統資源也可能是被攻擊的對象
1.攻擊TCP
主機會藉由連結表保存TCP的連線資訊
藉由大量快速建立的TCP連線占滿Server的連結表，就能讓目標無法接受新的TCP連線
2.SYN
SYN flood可以參考wiki的說明，也是占用主機的總連線數量
PSH、RST 這兩種也是同樣的目的
Sockstress 這樣的慢速攻擊則是從不一樣的作法達成相同目的的攻擊方式
將傳輸速度設限到非常小，長時間的拖住連線的進行，讓連線無法快速地被釋放
除了連線資源外，還有應用資源的攻擊類型
1. HTTP flooding 會盡可能請求無法被cache的資源，如個人資訊
2. SSL Flood and SSL Renegotiation Attacks
這兩種攻擊消耗系統的運算能力或記憶體空間
特別是SSL的解密耗用資源是一般請求的數倍
所以即使是送出錯誤的SSL請求也能耗用系統大量的記憶體或CPU運算
這個是我目前碰過較棘手的攻擊之一
黑客不會沒有目的就發動攻擊
常見的原因有 1.練技術 2.報復 3.勒索 4.國家級的目的
DDoS 的應對方式就是讓服務能撐下去
讓黑客覺得即使再繼續投入資源也沒辦法達成目的
當然現在很多服務都講求運端運算，DDoS也不例外
DDoS 的租用服務讓攻擊成本降低
所以現在發動DDoS的頻率很頻繁，攻擊的對象也不局限在大型服務廠商
緩解DDoS攻擊的處理方式有以下幾個
1. CDN
絕大多數的網站都會使用的方式之一，將靜態資源放到CDN上降低Server的傳輸量
2. IP信譽
紀錄短時間內大量連線的IP，當一個IP請求到一定數量就封鎖他
這個也幾乎是各個網站的標準設定之一
當然這個沒那麼準確，較新型的攻擊也會平衡各殭屍網路IP的請求數量
3.攻擊特徵匹配
看看攻擊的連線的header或內容是否含有哪些特徵
在防火牆端就可以過濾掉有特定特徵的連線
有些比較難纏的攻擊的內容也不太好抓特徵
4.速度匹配
SSL的驗證流程理論上不會重複太多次，重複協商了SSL很多次的連線也考慮Drop掉
太長時間沒有完成的請求也應該要Drop
上面有提過最近公司碰到的SSL攻擊比較棘手
有過Container的instance因為記憶體被吃光而crash的狀況
當然因為我們有重啟跟平衡負載機制，所以那段期間客戶應該較沒受到影響
後來我們追蹤Container的連線機制source code
發現他是用效率較差的while迴圈+thread的sleep做 Non-blocking
升級Container版本後，連線的效率改善也讓SSL攻擊的影響降低
所以追蹤自己用的Container機制並更新到適合的版本也是一種做法
5.流量洗清設備
分成硬體跟軟體的解決方案
硬體的話可以購買單純的流量洗清設備
這類專門處理流量的設備會具有容量較多的TCP連線表，可以容納更大量的外部連線
加上提供設定可以解決一部份的攻擊
軟體層解法則是可以另外建立一個接收並過濾連線的Container instance
Nginx 跟 Node.js 都是很輕量、擅長對應大量連線的容器
之前的話我們有很認真地考慮過為了這個機制改變架構
不過後來其他方面改善後，一般的DDoS就影響不大
加上我們希望等日後服務規模更大後再一併調整架構
所以暫時還沒有實現的機會
搭配上述解法，我們還可以用一些方式來過濾連線
1. Flag transfer
例如: Http Status 302會要求連線轉址到其他位置
但是反射攻擊或不具備解析Http Status能力的流量攻擊，就會卡在這邊而不會轉到其他網址
Java端的實現sample如下
response.setStatus(HttpServletResponse.SC_MOVED_PERMANENTLY);
response.setHeader("Location", "http://somewhere/");
2. 使用者端真實性驗證
例如 JavaScript運算要求，簡單的要求回傳1+1的結果
如果連線端不是瀏覽器或不具備JavaScript辨識引擎就會被過濾
另一些需要人類辨識的機制，例如recapthca這類的圖片驗證碼也是這樣的概念
以Ragic使用雲端服務的經驗來看，較傳統的SYN flood對我們幾乎是無感
影響較多的還是SSL攻擊等較新型、作用在更高連線層次的攻擊
DDoS應付能力也可以做為軟體建置是否使用雲端服務的考量之一
留言
張貼留言