DDOS防禦

SYN Flood防禦

前文描述過,SYN Flood***大量消耗服務器的CPU、內存資源,並佔滿SYN等待隊列。相應的,我們修改內核參數即可有效緩解。主要參數如下:

net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_max_syn_backlog = 8192

net.ipv4.tcp_synack_retries = 2

分別爲啓用SYN Cookie、設置SYN最大隊列長度以及設置SYN+ACK最大重試次數。

SYN Cookie的作用是緩解服務器資源壓力。啓用之前,服務器在接到SYN數據包後,立即分配存儲空間,並隨機化一個數字作爲SYN號發送SYN+ACK數據包。然後保存連接的狀態信息等待客戶端確認。啓用SYN Cookie之後,服務器不再分配存儲空間,而且通過基於時間種子的隨機數算法設置一個SYN號,替代完全隨機的SYN號。發送完SYN+ACK確認報文之後,清空資源不保存任何狀態信息。直到服務器接到客戶端的最終ACK包,通過Cookie檢驗算法鑑定是否與發出去的SYN+ACK報文序列號匹配,匹配則通過完成握手,失敗則丟棄。當然,前文的高級***中有SYN混合ACK的***方法,則是對此種防禦方法的反擊,其中優劣由雙方的硬件配置決定

tcp_max_syn_backlog則是使用服務器的內存資源,換取更大的等待隊列長度,讓***數據包不至於佔滿所有連接而導致正常用戶無法完成握手。net.ipv4.tcp_synack_retries是降低服務器SYN+ACK報文重試次數,儘快釋放等待資源。這三種措施與***的三種危害一一對應,完完全全地對症下藥。但這些措施也是雙刃劍,可能消耗服務器更多的內存資源,甚至影響正常用戶建立TCP連接,需要評估服務器硬件資源和***大小謹慎設置。

除了定製TCP/IP協議棧之外,還有一種常見做法是TCP首包丟棄方案,利用TCP協議的重傳機制識別正常用戶和***報文。當防禦設備接到一個IP地址的SYN報文後,簡單比對該IP是否存在於白名單中,存在則轉發到後端。如不存在於白名單中,檢查是否是該IP在一定時間段內的首次SYN報文,不是則檢查是否重傳報文,是重傳則轉發並加入白名單,不是則丟棄並加入黑名單。是首次SYN報文則丟棄並等待一段時間以試圖接受該IP的SYN重傳報文,等待超時則判定爲***報文加入黑名單。

首包丟棄方案對用戶體驗會略有影響,因爲丟棄首包重傳會增大業務的響應時間,有鑑於此發展出了一種更優的TCP Proxy方案。所有的SYN數據報文由清洗設備接受,按照SYN Cookie方案處理。和設備成功建立了TCP三次握手的IP地址被判定爲合法用戶加入白名單,由設備僞裝真實客戶端IP地址再與真實服務器完成三次握手,隨後轉發數據。而指定時間內沒有和設備完成三次握手的IP地址,被判定爲惡意IP地址屏蔽一定時間。除了SYN Cookie結合TCP Proxy外,清洗設備還具備多種畸形TCP標誌位數據包探測的能力,通過對SYN報文返回非預期應答測試客戶端反應的方式來鑑別正常訪問和惡意行爲。

清洗設備的硬件具有特殊的網絡處理器芯片和特別優化的操作系統、TCP/IP協議棧,可以處理非常巨大的流量和SYN隊列。

HTTP Flood防禦

HTTP Flood***防禦主要通過緩存的方式進行,儘量由設備的緩存直接返回結果來保護後端業務。大型的互聯網企業,會有龐大的CDN節點緩存內容。

當高級***者穿透緩存時,清洗設備會截獲HTTP請求做特殊處理。最簡單的方法就是對源IP的HTTP請求頻率做統計,高於一定頻率的IP地址加入黑名單。這種方法過於簡單,容易帶來誤殺,並且無法屏蔽來自代理服務器的***,因此逐漸廢止,取而代之的是JavaScript跳轉人機識別方案。

HTTP Flood是由程序模擬HTTP請求,一般來說不會解析服務端返回數據,更不會解析JS之類代碼。因此當清洗設備截獲到HTTP請求時,返回一段特殊JavaScript代碼,正常用戶的瀏覽器會處理並正常跳轉不影響使用,而***程序會***到空處。

DNS Flood防禦

DNS***防禦也有類似HTTP的防禦手段,第一方案是緩存。其次是重發,可以是直接丟棄DNS報文導致UDP層面的請求重發,可以是返回特殊響應強制要求客戶端使用TCP協議重發DNS查詢請求。

特殊的,對於授權域DNS的保護,設備會在業務正常時期提取收到的DNS域名列表和ISP DNS IP列表備用,在***時,非此列表的請求一律丟棄,大幅降低性能壓力。對於域名,實行同樣的域名白名單機制,非白名單中的域名解析請求,做丟棄處理。

慢速連接***防禦

Slowloris***防禦比較簡單,主要方案有兩個。

第一個是統計每個TCP連接的時長並計算單位時間內通過的報文數量即可做精確識別。一個TCP連接中,HTTP報文太少和報文太多都是不正常的,過少可能是慢速連接***,過多可能是使用HTTP 1.1協議進行的HTTP Flood***,在一個TCP連接中發送多個HTTP請求。

第二個是限制HTTP頭部傳輸的最大許可時間。超過指定時間HTTP Header還沒有傳輸完成,直接判定源IP地址爲慢速連接***,中斷連接並加入黑名單。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章