互連網雲生態下DDOS安全產品的一些考慮和測試方法（一）

標籤：

DDOS攻擊簡介

　　安全的三要素——“保密性”、“完整性”和“可用性”中，DOS（Denial of Service拒絕服務的攻擊）所針對的目標是服務的“可用性”。這種攻擊方式利用目標系統的網路服務功能缺陷或者直接消耗系統資源（主要是網路資源），使得該目標系統無法提供正常的服務。

       DDOS 攻擊(Distributed Denial of Service分散式阻斷服務)指攻擊者操縱多台用戶端(稱為肉雞或傀儡機)，聯合起來對一個或多個目標發動DDoS攻擊（同時攻擊或按一定策略攻擊），以提高拒絕服務的攻擊效果。

       某種意義上講，沒有“可用性”，何談“保密性”和“完整性”？缺少DDOS防禦的網路服務，隨時都有從網路上”消失”的危險。DDOS攻擊是目前最強大的，最難防禦的攻擊之一，和單純的技術攻擊手段相比，DDOS攻擊更像是一種流氓或者強盜行為，即所謂的流氓會武術。

DDOS攻擊原理和常用方法攻擊原理

         網路中的大部分資料都使用TCP/IP協議傳輸（包括其他如UDP等）,這些資料包必須遵循嚴格的協議標準，通常情況下滿足這些協議的包對於目標服務和網路裝置而言是正常資料，尤其是包含商務邏輯的資料，這些都是無害的；就像車站的檢票員一樣，如果乘客提供的車票合法可識別，且檢票乘客均為正常乘車乘客，則檢票過程通暢且安全；如果乘客提供的車票不合法或無法判斷是否合法，再或者10個乘客中有9個月台票(甚至閑雜人等)，那麼很明顯檢票員的大部分精力消耗在非法車票的識別或者非正常乘客上，從而影響正常乘客的檢票流程；同時，如果大量非法乘客滯留在列車上，也會導致正常乘客無法進入列車。入口資源和服務資源，是最容易阻塞的位置和受到攻擊的目標。

         和檢票員的工作流程類似：1. 異常資料包(無用資料包)過多時，往往能造成網路裝置或伺服器的過載；2. 利用資料包或者協議的某些缺陷，人為的造一些不完成的畸形包，也會造成網路裝置活伺服器無法正常處理，從而產生拒絕服務；3. 儘管資料包正常，但不符合目標服務的正常商務邏輯，這種包的海量傳輸，也會造成拒絕服務。

         總的來說，DDOS攻擊的角度有如下兩種：

1. 按量取勝：這種DDOS發起海量的資料攻擊，包括正常包以和異常包的大量攻擊，使得網路裝置和寬頻負載過高，資源耗盡，阻塞IDC入口；由於這種攻擊大部分在上層協議，更接近業務本身，攻擊沒有嚴格的邊界，防禦這種“流量型”的DDOS使得ISP和ICP面臨很大的挑戰；典型攻擊如UDP Flood；
2. 曲徑通幽：相比而言這種攻擊比較靈巧，屬於技術型攻擊，往往利用協議伺服器或者軟體的某種缺陷，僅僅通過幾個包就能持續的佔用有限的資源，使得華麗麗的目標服務無法處理正常資料，從互連網上短暫性消失；這種“資源型”攻擊中著名的如慢速連線攻擊Slowloris；

然而，實際的網路環境很少有單一類型的攻擊，混合型的攻擊，以及正常流量和異常流量的各種組合，是當前攻擊的主流方式；

DDOS攻擊的常用如下：

　　攻擊者往往從互連網各種角落搞到大批肉雞（傀儡機），並通過controller操作這些肉雞向目標服務發起混合型攻擊，比如syn flood或者dns query flood，甚至將其他網站的流量直接引到目標伺服器，正所謂道高一尺魔高一丈，對於各種各樣的DDOS攻擊，業內並沒有哪種防禦手段能夠在保證業務的同時防禦所有類型DDOS攻擊，更多的情況是在做兩者的折中。

　　但DDOS的核心目的永遠不會變，就是“對有限資源無限濫用”，包括直接濫用和間接濫用，已達到破壞“可用性”的目的。

防禦基礎常用攻擊和防護SYN Flood

　　Syn flood是最為經典的DDOS攻擊，它利用了TCP/IP協議三向交握設計中的缺陷，以小博大，一直活躍了幾十年，即使是現在，syn flood在互連網上已然很猖獗。Syn flood生命力過分強大的原因，在於它針對的是TCP/IP協議的缺陷，這個龐大的互連網的基礎，想要修複或重構，幾乎是不可能的。

攻擊原理

 

三向交握的過程如下：

1. Client發送同步syn包到server，包含client連接埠號碼和初始序號x；
2. Server收到client包後，向client發送syn+ack報文，包含確認號x+1和ack初始序號y；
3. Client發送ack報文到server，包含確認號y+1和序號x+1；

 

三向交握為了保證TCP的串連的可靠性，在第三向交握時做了一些異常處理，包括：

1. 做3~5次重試，等待client IP響應；約30s~120s遍曆一次等待列表，如仍未收到Client IP響應則放棄串連；
2. 第二次握手，當server發出syn+ack後會預留一定資源儲存這些資訊，為第三向交握做準備；

　　如果串連是偽造的，server會分配資源和時間來等待第三向交握，保證串連的可靠；當大量這種偽造的請求發起時，server需要大量的資源處理這種未完成三向交握的串連，且不斷進行第三向交握的重試，結果就是沒有資源處理正常的請求串連，而等待隊列被這種惡意包佔滿，從而無法處理正常的串連請求，導致了拒絕服務。

防禦手段

　　防禦syn flood的方法，通產的思路是彌補三向交握的缺陷，一方面減小緩解server資源壓力，一方面是增大等待隊列，還有就是減小重試次數。

　　Sync ookies可以起到緩解server資源壓力的作用，它的處理方法是不再儲存狀態資訊以等待client確認，而是以基於時間種子的隨機數替代普通隨機數作為syn初始序號y，當收到第三向交握時通過cookie校正演算法確定是否和發出去的syn+ack序號匹配，最終完成三向交握；

　　net.ipv4.tcp_max_syn_backlog參數(/etc/sysctl.conf，核心參數)則可以過server的記憶體換取更長的等待隊列，使得攻擊無法輕易的佔滿等待隊列而產生拒絕服務；

　　net.ipv4.tcp_synack_retries則降低server第二次握手的syn+ack重試次數，不至於長時間佔用資源；

　　提高協議自身抵抗力當然需要伺服器額外的資源，所以實際情況如何處理，還需要考慮伺服器配置效能和server業務進行折中。

　　除了提高協議自身能力外，防禦syn flood還可以從異常行為識別下手，比如首包丟棄和黑白名單的思路；

　　首包丟棄的思路是丟棄掉client的首次報文，等待client 的syn的重傳報文，有重傳行為的IP則添加到白名單，沒有重傳行為的串連則認為是攻擊行為；則處理過程為：

　　丟包重試的方案對syn flood起到明顯的防禦作用，然而這種方案缺不適合在server上處理——它對業務處理對產生負面的影響，比如影響時間增大等；一種思路是把首包丟棄的過程和業務處理過程分離出來，用專門的裝置來處理——幾乎所有的網路清洗裝置都具備這種功能，丟包重試在這種清洗裝置上有了更最佳化的方案，一般把這种放在其他裝置上處理首包丟棄的方案叫做TCP Proxy。

　　不過事實上首包丟棄只是TCP Proxy狹義的一個功能，幾乎所有和業務本身脫離的處理，都可以放在TCP Proxy端，比如上面提到的syn cookie和首包丟器結合的方式，在清洗裝置上類比server進行三向交握的驗證，維護其黑白名單，並最終轉寄server的業務資料。成熟的清洗裝置能夠鑒別TCP包的更多異常和畸形，甚至通過類比響應來鑒別用戶端的攻擊和惡意行為，並對這些流量進行清洗和過濾。

DNS Query Flood攻擊原理

　　DNS Query Flood可以看做是UDP flood的升級版。UDP flood屬於“流量型”DOS攻擊，最常見的情況就是採用大量的UDP小包對骨幹網和網路裝置進行攻擊。防禦UDP Flood的痛點在於它的無串連狀態和五花八門的協議，不過提供UDP服務的IP很少，過濾偽造的IP相對比較容易，純粹的UDP流量攻擊慢慢也就變少了，而且大部分網路傳輸並不是UDP方式。但是流媒體服務和DNS這些以UPD為基礎協議的服務，仍然是UDP Flood的重點攻擊對象。

　　Query Flood的和UDP Flood最大的區別是Query Flood是應用程式層攻擊而UDP Flood是協議層攻擊。協議層次越高，和業務關聯性越大，防禦起來越難。Query Flood實際上執行的是真實的query，一種業務行為，但如果多台肉雞同時發起這樣的海量網域名稱查詢請求，對server來說則無法給正常的query請求返回結果，也就導致了拒絕服務。Query Flood為了增加攻擊的隨機性，不但需要像UDP flood一樣在協議層偽造IP和連接埠，更需要在應用程式層偽造參數和網域名稱等。隨機性的目的，在於繞開dns伺服器的過濾和緩衝。

防禦手段

         Query Flood的防禦可以從以下三個層面考慮：

1. 黑白名單

對網域名稱進行授權，採取最小許可權原則，非白名單中網域名稱一律拋棄，以提高處理效能；

1. 強制TCP重發

類似於首包丟棄的方法，首次DNS報文直接丟棄，強制client採取TCP方式進行網域名稱Query；

1. 緩衝

增加DNS緩衝和網域名稱請求命中率，避免過多效能消耗；

Slowloris攻擊原理

　　這是一種與大多數攻擊背道而馳的攻擊手段，以慢著稱，有些時間這種攻擊很難被發現，它利用的是web server的一些特徵來達到攻擊目的，這種曆史悠久的攻擊現在看來有些情況下依然行之有效。

　　Slowloris攻擊的是web server容器的並發上限，無論哪種web容器，都會對並發的串連數有一個上限，達到這個上限串連數後，web server無法接受新的請求，即：

　　當web server接收到新的http請求時，開啟新的串連處理請求，處理完成後關閉這個串連；如果這個串連一直處理串連狀態，新的http請需要開啟新的串連進行處理；如果所有串連都一直處於串連狀態，那麼web server將服務處理任何新的請求。

　　Slowloris利用http的特性來達到這一目的：由於http請求以\r\n\r\n標識著headers的結束，如果web server只收到\r\n，則認為http headers部分沒有結束，保持串連不放，等待後續的內容。實際的攻擊中，一般是將http headers中的connections設定為keep-alive，這樣web server會保持住這個TCP串連不斷開，接下來間歇性的發送一些索引值對到web server，就能一直保持著串連的不斷開。當然也可以將content-length設定為很大，然後階段性的post資料到web server，即HTTP POST DDOS。

　　這樣的串連可以很容易的通過多線程或者肉雞建立，不需要大量的流量，很快就能使web server的串連達到上限，而不再處理新的http請求。

防禦手段

防禦Slowloris，同樣需要從產生Slowloris的根本原因上進行考慮：1. TCP連線時間 2. http headers的傳輸時間 3. 每個TCP串連的報文數，所以Slowloris防禦方法如下：

1. 對TCP串連的時間長度進行控制和統計，將長時間串連的TCP請求拉入黑名單；
2. 設定http headers的最大傳輸時間，超過則中斷連線且拉入黑洞單；
3. 統計每個TCP連線時間內的報文數，過多過少的報文都是不正常的；

HTTP Flood （CC）攻擊原理

　　和上述幾個典型的DDOS攻擊相比，HTTP Flood攻擊是最令人頭疼的，因為目前所有的anti-ddos產品都沒有行而有效進行防禦——這是因為HTTP Flood不是網路層攻擊，而是一種應用程式層攻擊。它有另外一個名字更為響亮，CC(Challenge Collapsar)，是挑戰當時綠盟的一款叫做Collapsar(黑洞)的DDOS防禦裝置的一種挑釁的叫法。

　　網路層攻擊都有著顯著的特徵，但是應用程式層的攻擊，完全類比使用者請求，類似於各種搜尋引擎和爬蟲一樣，這些攻擊行為和正常的業務並沒有嚴格的邊界，很難辨別。CC的原理與其類似。

　　Web服務的效能受著相關資源的影響，直接資源套件括CPU，MEM，DISK和NET（也就是效能測試的4個度量指標），這些資源受到資料庫查詢，網路頻寬，檔案大小，記憶體配置和演算法等軟硬體條件影響。

　　一些資源消耗較大的事務和頁面，比如如果web應用涉及到分頁和分表，很明顯控制頁面的參數過大，頻繁的翻頁會佔用較多的web server資源，尤其在高並發頻繁調用的時候，類似這樣的事務，成了最早的CC攻擊最早的目標。由於現在的攻擊大都是混合型的，摻雜在正常的業務中，所以一般帶有類比使用者行為的頻繁操作都可以認為是CC攻擊（哪些事務資源消耗嚴重也需要猜和判斷）。但總體來說，CC這種應用程式層的攻擊特點，就是和業務應用邊界模糊。比如各種刷票軟體對12306的訪問，某種程度上就是CC攻擊；另外某個網站或者店鋪做了活動和宣傳，導致忽然過多流量訪問某天的忽然訪問，如果web server無法支援這樣突高的流量，也是一種類CC行為。

　　由於CC攻擊瞄準的是web應用的後端業務，所以除了導致拒絕服務之外，還會直接影響web應用的功能和效能，比如影響web影響時間，影響資料庫服務，影響磁碟讀寫等，這些都會導致功能和效能的異常。

　　另外，和前面提到的DDOS攻擊相比，CC攻擊更容易發起。由於它發起的流量屬於正常的業務流量，很難被鑒別，所以很多時候不需要大量的肉雞；互連網上有著豐富的HTTP代理，可以使用這些HTTP代理直接向目標發起HTTP攻擊；甚至還可以入侵一個大流量網站，再將訪問到這個網站的流量轉寄到目標位置。

防禦手段

　　儘管對CC來說目前並沒有行之有效防禦手段，但是一些方法對CC攻擊還是有一定的防禦效果。

　　限制訪問頻率：可以通過IP和cookie定位用戶端，並判斷一段時間內的訪問頻率，如果過於頻繁，可以暫時添加到黑名單，或直接返回錯誤頁面；訪問頻率的邏輯也可以放在清洗裝置上，對訪問頻率過高的用戶端直接添加黑名單。這種方法簡單，但是有兩點不足：1. 無法判斷來自Proxy 伺服器的攻擊 2. 誤殺正常訪問。

　　CDN緩衝：緩衝能夠對CC起到緩和的作用，對於大部分請求可以使用緩衝中的結果直接返回，單伺服器適用，互連網服務同樣適用；對於大型的互連網結構，一般都有CDN節點來做內容的緩衝。

　　人機識別：最常用的人機識別方式是驗證碼，它的根本目的就是攔截請求的自動重放，但驗證碼在攔截自動請求的同時也影響使用者體驗，另外如果驗證碼的不是足夠的“隨機”，通過彩虹表還是可以繞開；判斷User-agent也是一種方法，但是User-agent也是可以修改的，遇到這種自動請求會失效；利用用戶端解析JS(或者flash)也是一種判斷方法：類比的請求無法像用戶端(瀏覽器)一樣解析JS，發送一段JS 到用戶端，收到正常跳轉則正常處理並添加到白名單。

　　Web容器：web容器自身也提供一些防禦能力，可以通過配置參數根據業務需求進行折中處理，比如一些如timeout，maxclients，alivetimtout等參數。

 

互連網雲生態DDOS攻擊特點和防禦手段

　　互連網的發展，讓越來越多的人們享受到網路技術帶來的便利，也正因為如此，互連網面臨的安全問題也日益嚴重，道高一尺魔高一丈，防禦方法需要不斷的研究改進以應對花樣百出的攻擊手段。

　　近幾年迅速崛起的雲生態圈，當然也需要應對各種各樣的安全攻擊。和雲生態的複雜性一樣，此時的DDOS攻擊，也不再是純粹單一的DDOS攻擊。

特點動一發而動全身

　　供應商網路，骨幹網，IDC入口，叢集，CDN，負載平衡，主機，服務等等很多點部署在一起，支撐起龐大的雲生態網路。

　　這樣多層次龐大複雜的網路環境中，任何一點出現問題，都可能對業務帶來影響；甚至有些攻擊不再基於某一單一層次，而是基於多個層次組合上的漏洞或者缺陷。所以長鏈路的系統拓寬了DDOS攻擊的目標範圍，而越來越多的組件和服務遷移到雲上，任何組件都可能導致業務線出現故障。

　　另外，由於不同使用者的業務位於一個相同的物理機上，任何一個使用者的業務受到攻擊，都可能影響其他使用者的業務。

混合攻擊

　　正所謂沒有新的元素，只有新的組合。進階的攻擊都會根據目標的攻擊範圍和環境，進行多層次多方法的組合。這種混合攻擊包括欺騙性、針對性和混淆性等等。

　　欺騙性：比如syn flood攻擊時可以加入進行驗證的syn+ack報文，以此混淆清洗裝置的syn cookie檢測，加強攻擊效果和清洗裝置壓力。這樣的欺騙性混合，往往需要對網路設別的清洗和判斷策略有一定的瞭解，打的是攻防仗，任何策略泄露或被猜到，都會帶來嚴重的後果。

　　針對性：互連網的混合攻擊針對性比較強，比如CC攻擊不再類比使用者瀏覽器操作的請求，而直接類比web api的調用，這種調用的正常業務也是自動的，在CC中加入這種業務，使得攻擊和正常業務界限更為模糊，清洗裝置更難過濾。

　　混淆性：最簡單的混合攻擊就是幾種DDOS攻擊直接混合，比如syn flood, slowloris和CC混合在一起進行攻擊，這種方式會讓清洗裝置壓力增大，而且如果服務受到了攻擊，工作人員需要花時間判斷是哪種攻擊導致的。

應用程式層攻擊

　　由于越來越多的元件服務和應用遷移到雲這個複雜且龐大的網路環境中，處於頂層的各種應用，成了各種DDOS攻擊的目標，雲環境下應對DDOS的痛點在於，使用大部分處於應用程式層以下的裝置和環境來防禦集中在應用程式層的攻擊，而基礎設施和應用的關係是支撐和保護，不能直接控制應用。如何防禦應用程式層的DDOS攻擊，是當前雲生態圈下DDOS防禦面臨的最大問題。

肉雞的選擇

　　雲環境不但提供了彈性計算，CDN，儲存等各種服務，還提供了虛擬機器主機，VIP和通暢的頻寬，這樣的環境為中小公司提供了更好的創業環境的同時，也為駭客提供了資源。

　　比如國內的一個特殊的職業——黃牛，每年春運購票高峰時，他們的需求便接踵而來。他們是雲端服務的客戶之一——按時間和寬頻購買大量主機，直接部署自己的鏡像，然後開始使用這些主機進行刷票，幾百台主機在雲環境下幾乎秒殺火車票。主機購買的時間長度（比如1小時）對於黃牛刷火車票來說足夠用了，對於黃牛來說這樣的成本是很低的。

　　然而對於12306來說這無疑是一個噩夢，儘管是正常的業務訪問，某種意義上看卻是攻擊，而且直擊核心業務——不但正常的使用者無法登陸和操作，而且連票都賣完了，購票網站還混啥呢？

　　同樣的道理，黃牛如果真的是駭客呢？如果這些主機不是購買的而是入侵的呢？這些主機也就成了效能良好的傀儡機，為駭客提供了便利。

非技術策略

　　雲生態下的創業公司是痛苦的，一方面要遭受駭客和同行的攻擊，一方面還要花錢購買各種雲端服務和安全服務。在感歎的同時也要為奮鬥在安全防禦產品線的同事們辯解一下，和其他應用相比，安全體系往往需要投入更多的人力來維護。

　　安全防禦這件事，與其說是技術系統，不如說是人工營運體系。因為安全防禦本身就一個半自動化的體系，看似高大上的安全產品，其實都是後端各種攻防戰的積累。DDOS防禦也脫離不了各部門的應急和處理，比如運營，營運，開發，測試，客服，網工等等，正常情況下運營和網工也需要保持電話通暢和網路可用，甚至路邊散步的時候忽然就需要開啟電腦人工處理某個攻擊事件。

　　所以選擇攻擊的時機，也是攻擊成敗的一個因素。人員工作時間有早晚，應用的業務處理白天和晚上也不同，網路的擁堵也不同。之前在一個互連網公司工作過，團建的時候是禁止發活動相關的微博的，因為競爭者會在團建的時候做自己的安排，如發布新版本和攻擊等。

　　安全的攻防，是個持續的過程，而且絕對的結果導向；對於攻擊方來說，使用哪種技術和漏洞不重要，攻擊的結果才重要，所有對結果有影響的任何要素都需要考慮。

防禦策略

　　互連網和雲環境的DDOS防禦，目前來說依然是一個挑戰，因為防禦的目標不再是一個應用或者服務，而是一個生態圈。

縱深防禦

　　縱深防禦是白帽子的一個原則，雲生態的DDOS防禦同樣適用。每個層次必須有自己各自的安全防護，不依賴於其他層面的保護，且有自身的警示和跟蹤。

　　針對不同層次的安全防禦進行規劃，才能從整體出發構建整體的防禦體系。不同層面有不同層面的特點，實施的安全措施也不同，相互配合才能保證整體的安全；另外，有些攻擊需要在某些層次做針對性的防禦，比如syn flood和slowloris的這樣的防禦可以放到清洗裝置中，而防火牆可以做網路底層的防禦，主機安全負責雲主機的應用安全，內部防火牆則在主機被控製為傀儡機時切斷和controller的串連，而SLB和CDN層上也需要的一定的清洗和過濾。

最小化部署

　　隨著雲生態的逐漸成熟，雲端服務的需求量也不斷增加，包含橫向和縱向的擴充，比如擴容和最小化環境部署。

　　在這裡，擴容指有伺服器達到上限或新功能特殊需要擴建新的服務叢集，最小化部署指將雲生態的全部或部分縮放部署在某個區域網路內，比如現在各雲廠商都在推的私人雲端。

　　雲產品的安全防禦，屬於雲生態的預設屬性，雲環境擴容或者最小化部署的同時，要求安全防禦也要有這種”最小化部署”的可移植性：一方面虛擬&物理的安全裝置，可以部署在網路的任何地方；另一方面，整套安全防禦體系可以隨雲的移動而移動，複製到任何部署雲的地方。

引擎粒度

　　這裡提到的引擎指WAF，IPS，IDS，DLP。互連網雲生態環境，要求這些引擎更加強大，並且可以為處於各層次的節點提供引擎服務。

　　一方面引擎要保證最小粒度的可見，能夠方便的部署在其他層面或者直接提供服務；另一方面雲生態的內部也要防禦層次間的安全和攻擊問題。

　　保證引擎粒度的最小可見度，對於一個優秀的雲環境，是必須的。

業務整合安全

　　前面提到，應用程式層的DDOS攻擊會直接帶來業務層的影響，而雲生態中面臨的業務安全並不僅僅是DDOS攻擊帶來了，也包含其他技術攻擊(注入、釣魚、暴力破解等)和業務攻擊(欺詐等)，所以在構架安全防禦的體系中，業務安全自身也要整合到體系中。

　　業務安全性組件含的範疇比較廣，更多的是網狀的結構，不同的業務對自身安全要求也不同，所以業務安全的整合，更多的是以服務的形式對外提供。

服務化

　　和業務整合安全類似，雲體系的安全防禦體系需要逐步的服務化，並對外輸出。

　　首先，不同使用者的業務不同，對安全的業務需求也不同——遊戲行業對DDOS攻擊的防禦需求遠大於普通網站業務，所以在防禦力度上使用者需要有所選擇；

　　另一方面，有些使用者對雲端服務提供的預設安全引擎和裝置並不滿意，希望能夠選擇其他的引擎和裝置。

　　基礎這些考慮，雲生態對外提供各種服務的同時，也將安全服務化，並提供對外服務方式，如介面或者相關的頁面操作。

架構

　　除了防禦體系的整體策略需要考慮外，安全技術之外的一些架構處理也可以配合防禦，雲生態是一個整體，靠各層配合；雲安全同樣也是一個整體，需要各層的配合。享受安全防禦體系保護的同時，去配合安全體系建設，是雲體系中各層的架構需要。

備份|緩衝|CDN

         大型互連網服務，都具有支撐業務的備份和快取服務，這些對安全防禦有著重要作用：備份可以加快警示後的處理並且降低損失，緩衝對於DDOS攻擊更是起到的緩和作用。正因為如此，CDN節點數量從某種角度來說，可以衡量一個系統的DDOS防禦能力。

         除了CDN節點數量外，每個節點的VIP分配需要根據實際攻擊情況處理，比如對一定數量的VIP，可以根據CDN節點遭受攻擊的嚴重程度和VIP被攻擊的頻率做好VIP的重新分配，優先對哪些CDN節點分配哪些VIP，得到的DDOS防禦能力是不同的。

另外，對於分布式的CDN，受到大流量攻擊時如何分流到不同節點，動態輪詢和hash的結果，也不會相同。

負載平衡

　　負載平衡服務，除了提供了負載平衡和VIP外，還可以提供負載平衡層面的監控資料，比如流量相關：bps, pps, qps等；串連相關：VIP、TCP等串連的 newconns, concurconns；業務相關：業務處理量，失敗處理等。

　　雖然大型的互連網服務系統都會有專門的系統做分光後的流量分析，但這些分析是通用的，並不能做某一層專屬的分析；另外，業務相關的分析，也只能由每一層做自身特定的處理。

手段

         除了在策略和架構角度的考慮，一些常用的安全的原則和技巧在雲安全防禦體系中也是經常用到的，這裡只做簡單的介紹。

最小許可權

　　最小許可權原則是安全的基本原則之一，要求只授予必要許可權，不必要的許可權不能授權。雲環境中，每層內部需要梳理本層的業務需求和許可權，保證其他層次調用時使用最小許可權，其他許可權的操作採取不信任的態度。

黑白名單

         黑白名單也是安全的基本原則之一，相對於“最小許可權”在多種許可權上的信任，黑白名單的信任建立在絕對互斥的基礎上，非白即黑或非黑即白。很多時候安全的防禦過程，就是條件判斷的過程，這個過程中黑白名單起著絕對重要的作用。

         但在雲生態這種多層次的防禦環境下，黑白名單的使用也需要注意一些問題：

1. 如果黑白名單是動態，那麼盡量保證黑白名單是單一邏輯維護；
2. 黑白名單不要共用使用，每個層使用自己的黑白名單；

由於不同業務和層次關係關注各自不同的策略和規則，分層使用黑白名單不但益處維護，也減少故障的產生。

訪問頻率

         之前在CC的防禦裡提到了使用清洗裝置使用IP和Cookie定位用戶端計算訪問頻率，但對於應用程式層來說訪問頻率並不是絕對的，所以很容易出現誤殺的情況。

         一種做法是訪問頻率的判斷交由各層處理，這樣的判斷結果更具有針對性，且各自的判斷演算法也不相同，效果會更好。

         目前的一種成熟做法，是在旁路對訪問頻率做監控，當訪問串連超過預定閾值，切換清洗裝置對主路流量做清洗操作，最終通過清洗的結果決策下一步操作。

人機識別

　　在CC中提到過人機識別和典型的人機識別，即驗證碼，人機識別的根本目的是判斷請求是否由機器重發，但識別的過程也面臨著問題。

　　驗證碼的缺點之前提到過，影響使用者體驗，而且不夠隨機的情況下驗證碼同樣可以繞過，在使用者體驗和識別的過程上，很難做到一個折中。

　　之前參與過一個刷票軟體的開發，經曆了12306驗證碼的各種變革，最終12306還是沒有一個好的方案通過驗證碼過濾掉所有刷票提交操作——有時候自動化對映像的識別能力比人眼還好使，那麼顯然驗證碼在這種情況下沒有達到設計初衷。　　

　　人機識別面臨的模糊邊界顯然不止這些，比如之前提到的webapi的調用。這些介面的調用，本來就是由程式發起的，如果程式不斷迴圈調用，那麼是否也是一種攻擊呢？

　　無論驗證碼，還是更複雜的訪問頻率計算，或者其他人機識別方法，想提高識別的精度需要更複雜的計算；然而無論再好的演算法，做流量分析的時候，都無法保證速度和精度的雙贏。隨著機器學習和離線資料處理的發展，相信在人機識別上會有更好的方案出來。

溝通協作

　　之前提到了，DDOS的防禦永遠都是一個攻防戰，處在半自動的積累過程中，想要有更好的防禦效果，需要良好的監控，組織和流程來支援。看似簡單的攻擊處理，都是處於各流程的同事的積累和配合。

互連網雲生態下DDOS安全產品的一些考慮和測試方法（一）