DDoS防御方案

1、攻擊流量到底多大談到DDoS防御，首先就是要知道到底遭受了多大的攻擊。這個(gè)問題看似簡 單，實(shí)際上卻有很多不為人知的細(xì)節(jié)在里面。以SYN Flooc為例，為了提高發(fā)送效率在服務(wù)端產(chǎn)生更多的 SYN等待隊(duì)列， 攻擊程序在填充包頭時(shí)，IP首部和TCP首部都不填充可選的字段，因此IP首部 長度恰好是20字節(jié)，TCP首部也是20字節(jié)，共40字節(jié)。對(duì)于以太網(wǎng)來說，最小的包長度數(shù)據(jù)段必須達(dá)到 46 字節(jié)，而攻擊報(bào)文只有 40字節(jié)，因此，網(wǎng)卡在發(fā)送時(shí)，會(huì)做一些處理，在 TCP首部的末尾，填充6個(gè) 0 來滿足最小包的長度要求。這個(gè)時(shí)候，整個(gè)數(shù)據(jù)包的長度為14字節(jié)的以太網(wǎng)頭，20字節(jié)的IP頭，20 字節(jié)的TCP頭

2、，再加上因?yàn)樽钚“L度要求而填充的 6個(gè)字節(jié)的0, 一共是60 字節(jié)。但這還沒有結(jié)束。以太網(wǎng)在傳輸數(shù)據(jù)時(shí)，還有 CRC僉驗(yàn)的要求。網(wǎng)卡會(huì)在 發(fā)送數(shù)據(jù)之前對(duì)數(shù)據(jù)包進(jìn)行 CRC僉驗(yàn)，將4字節(jié)的CRC直附加到包頭的最后 面。這個(gè)時(shí)候，數(shù)據(jù)包長度已不再是 40字節(jié)，而是變成 64字節(jié)了，這就是常 說的SYN小包攻擊，數(shù)據(jù)包結(jié)構(gòu)如下：|14字節(jié)以太網(wǎng)頭部|20字節(jié)IP頭部|20字節(jié)TCP|6字節(jié)填充|4字節(jié)檢驗(yàn)|目的MAC|源MAC|協(xié)議類型| IP頭|TCP頭|以太網(wǎng)填充| CRC檢驗(yàn)|到64字節(jié)時(shí)，SYN數(shù)據(jù)包已經(jīng)填充完成，準(zhǔn)備開始傳輸了。攻擊數(shù)據(jù)包很 小，遠(yuǎn)遠(yuǎn)不夠最大傳輸單元（MTU）的1500字

3、節(jié)，因此不會(huì)被分片。那么這些 數(shù)據(jù)包就像生產(chǎn)流水線上的罐頭一樣，一個(gè)包連著一個(gè)包緊密地?cái)D在一起傳輸 嗎？事實(shí)上不是這樣的。以太網(wǎng)在傳輸時(shí)，還有前導(dǎo)碼（preamble）和幀間距（in ter-framegap ）。 其中前導(dǎo)碼占8字節(jié)（byte），即64比特位。前導(dǎo)碼前面的7字節(jié)都是1010, 1 和 0間隔而成。但第八個(gè)字節(jié)就變成了 101011，當(dāng)主機(jī)監(jiān)測(cè)到連續(xù)的兩個(gè) 1 時(shí),就知道后面開始是數(shù)據(jù)了。在網(wǎng)絡(luò)傳輸時(shí),數(shù)據(jù)的結(jié)構(gòu)如下：|8字節(jié)前導(dǎo)碼|6字節(jié)目的MAC地址|6字節(jié)源MAC地址|2字節(jié)上層協(xié)議類 型|20字節(jié)IP頭|20字節(jié)TCP頭|6字節(jié)以太網(wǎng)填充|4字節(jié)CRC檢驗(yàn)|12字節(jié)幀

4、間距|也就是說，一個(gè)本來只有40字節(jié)的SYN包，在網(wǎng)絡(luò)上傳輸時(shí)占的帶寬，其 實(shí)是 84 字節(jié)。有了上面的基礎(chǔ)，現(xiàn)在可以開始計(jì)算攻擊流量和網(wǎng)絡(luò)設(shè)備的線速問題了。當(dāng)只填充IP頭和TCP頭的最小SYN包跑在以太網(wǎng)絡(luò)上時(shí)，100Mbit的網(wǎng)絡(luò)，能 支持的最大 PPS(Packet PerSecond 是 100X 106/(8* (64+8+12)=148809 1000Mbit的網(wǎng)絡(luò)，能支持的最大 PPS是。SYN Flood 防御前文描述過，SYN Flooc攻擊大量消耗服務(wù)器的CPU內(nèi)存資源，并占滿 SYN等待隊(duì)列。相應(yīng)的，我們修改內(nèi)核參數(shù)即可有效緩解。主要參數(shù)如下：4.tcp_syncooki

5、es = 14.tcp_max_syn_backlog = 81924.tcp_synack_retries = 2分別為啟用SYN Cookie設(shè)置SYN最大隊(duì)列長度以及設(shè)置SYN+ACI最大重 試次數(shù)。SYN Cookie的作用是緩解服務(wù)器資源壓力。啟用之前，服務(wù)器在接到SYN數(shù)據(jù)包后，立即分配存儲(chǔ)空間，并隨機(jī)化一個(gè)數(shù)字作為SYN號(hào)發(fā)送SYN+AC數(shù)據(jù)包。然后保存連接的狀態(tài)信息等待客戶端確認(rèn)。啟用SYN Cookie之后，服務(wù)器不再分配存儲(chǔ)空間，而且通過基于時(shí)間種子的隨機(jī)數(shù)算法設(shè)置一個(gè)SYN號(hào)，替代完全隨機(jī)的SYN號(hào)。發(fā)送完SYN+AC確認(rèn)報(bào)文之后，清空資源不保存任何 狀態(tài)信息。直到服務(wù)器

6、接到客戶端的最終 ACK包，通過Cookie檢驗(yàn)算法鑒定是 否與發(fā)出去的SYN+AC報(bào)文序列號(hào)匹配，匹配則通過完成握手，失敗則丟棄。當(dāng)然，前文的高級(jí)攻擊中有 SYN混合ACK的攻擊方法，則是對(duì)此種防御方法的 反擊，其中優(yōu)劣由雙方的硬件配置決定4.tcp_synack_retries是降低服務(wù)器SYN+ACK艮文重試次數(shù)，盡快釋放等待 資源。這三種措施與攻擊的三種危害一一對(duì)應(yīng)，完完全全地對(duì)癥下藥。但這些 措施也是雙刃劍，可能消耗服務(wù)器更多的內(nèi)存資源，甚至影響正常用戶建立 TCP 連接，需要評(píng)估服務(wù)器硬件資源和攻擊大小謹(jǐn)慎設(shè)置。除了定制TCP/IP協(xié)議棧之外，還有一種常見做法是 TCP首包丟棄方案

7、，利 用TCPB議的重傳機(jī)制識(shí)別正常用戶和攻擊報(bào)文。當(dāng)防御設(shè)備接到一個(gè)IP地址的SYN報(bào)文后，簡單比對(duì)該IP是否存在于白名單中，存在則轉(zhuǎn)發(fā)到后端。如不 存在于白名單中，檢查是否是該IP在一定時(shí)間段內(nèi)的首次SYN報(bào)文，不是則檢 查是否重傳報(bào)文，是重傳則轉(zhuǎn)發(fā)并加入白名單，不是則丟棄并加入黑名單。是 首次SYN報(bào)文則丟棄并等待一段時(shí)間以試圖接受該 IP的SYN重傳報(bào)文，等待超 時(shí)則判定為攻擊報(bào)文加入黑名單。首包丟棄方案對(duì)用戶體驗(yàn)會(huì)略有影響，因?yàn)閬G棄首包重傳會(huì)增大業(yè)務(wù)的響 應(yīng)時(shí)間，有鑒于此發(fā)展出了一種更優(yōu)的 TCPProxy方案。所有的SYN數(shù)據(jù)報(bào)文由 清洗設(shè)備接受，按照SY NCookie方案處理。

8、和設(shè)備成功建立了 TCP三次握手的 IP地址被判定為合法用戶加入白名單，由設(shè)備偽裝真實(shí)客戶端IP地址再與真實(shí)服務(wù)器完成三次握手，隨后轉(zhuǎn)發(fā)數(shù)據(jù)。而指定時(shí)間內(nèi)沒有和設(shè)備完成三次握手 的IP地址，被判定為惡意IP地址屏蔽一定時(shí)間。除了 SYN Cookie吉合TCP Proxy外，清洗設(shè)備還具備多種畸形 TCP標(biāo)志位數(shù)據(jù)包探測(cè)的能力，通過對(duì) SYN 報(bào)文返回非預(yù)期應(yīng)答測(cè)試客戶端反應(yīng)的方式來鑒別正常訪問和惡意行為。清洗設(shè)備的硬件具有特殊的網(wǎng)絡(luò)處理器芯片和特別優(yōu)化的操作系統(tǒng)、 TCP/IP 協(xié)議棧，可以處理非常巨大的流量和 SYN隊(duì)列。HTTP Flood 防御HTTPFlood攻擊防御主要通過緩存的方

9、式進(jìn)行，盡量由設(shè)備的緩存直接返回 結(jié)果來保護(hù)后端業(yè)務(wù)。大型的互聯(lián)網(wǎng)企業(yè)，會(huì)有龐大的CDN節(jié)點(diǎn)緩存內(nèi)容。當(dāng)高級(jí)攻擊者穿透緩存時(shí)，清洗設(shè)備會(huì)截獲HTTP請(qǐng)求做特殊處理。最簡單的方法就是對(duì)源IP的HTTP請(qǐng)求頻率做統(tǒng)計(jì)，高于一定頻率的IP地址加入黑名單。這種方法過于簡單，容易帶來誤殺，并且無法屏蔽來自代理服務(wù)器的攻 擊，因此逐漸廢止，取而代之的是 JavaScript跳轉(zhuǎn)人機(jī)識(shí)別方案。HTTP Flood是由程序模擬HTTP請(qǐng)求，一般來說不會(huì)解析服務(wù)端返回?cái)?shù)據(jù)， 更不會(huì)解析JS之類代碼。因此當(dāng)清洗設(shè)備截獲到 HTTP請(qǐng)求時(shí)，返回一段特殊 JavaScript代碼，正常用戶的瀏覽器會(huì)處理并正常跳轉(zhuǎn)不影

10、響使用，而攻擊程序 會(huì)攻擊到空處。DNS Flood 防御DNS攻擊防御也有類似HTTP的防御手段，第一方案是緩存。其次是重發(fā)， 可以是直接丟棄DNS報(bào)文導(dǎo)致UDP層面的請(qǐng)求重發(fā)，可以是返回特殊響應(yīng)強(qiáng)制 要求客戶端使用TCP協(xié)議重發(fā)DNS查詢請(qǐng)求。特殊的，對(duì)于授權(quán)域 DNS的保護(hù)，設(shè)備會(huì)在業(yè)務(wù)正常時(shí)期提取收到的 DNS 域名列表和ISPDNSIPJ表備用，在攻擊時(shí)，非此列表的請(qǐng)求一律丟棄，大幅降 低性能壓力。對(duì)于域名，實(shí)行同樣的域名白名單機(jī)制，非白名單中的域名解析 請(qǐng)求，做丟棄處理。慢速連接攻擊防御Slowloris 攻擊防御比較簡單，主要方案有兩個(gè)。第一個(gè)是統(tǒng)計(jì)每個(gè)TCP連接的時(shí)長并計(jì)算單位

11、時(shí)間內(nèi)通過的報(bào)文數(shù)量即可 做精確識(shí)別。一個(gè)TCP連接中，HTTP報(bào)文太少和報(bào)文太多都是不正常的，過少 可能是慢速連接攻擊，過多可能是使用 HTTP1.1協(xié)議進(jìn)行的HTTPFlooc攻擊，在一個(gè)TCP連接中發(fā)送多個(gè)HTTP請(qǐng)求。第二個(gè)是限制HTTP頭部傳輸?shù)淖畲笤S可時(shí)間。超過指定時(shí)間 HTTPHeader 還沒有傳輸完成，直接判定源IP地址為慢速連接攻擊，中斷連接并加入黑名 單?；ヂ?lián)網(wǎng)企業(yè)防御DDoS攻擊，主要使用上文的基礎(chǔ)防御手段，重點(diǎn)在于監(jiān) 控、組織以及流程。監(jiān)控需要具備多層監(jiān)控、縱深防御的概念，從骨干網(wǎng)絡(luò)、IDC入口網(wǎng)絡(luò)的BPS PPS協(xié)議分布，負(fù)載均衡層的 VIP新建連接數(shù)、并發(fā)連接數(shù)、

12、BPS PPS 到主機(jī)層的CPU狀態(tài)、TCP新建連接數(shù)狀態(tài)、TCP并發(fā)連接數(shù)狀態(tài)，到業(yè)務(wù)層的 業(yè)務(wù)處理量、業(yè)務(wù)連通性等多個(gè)點(diǎn)部署監(jiān)控系統(tǒng)。即使一個(gè)監(jiān)控點(diǎn)失效，其他 監(jiān)控點(diǎn)也能夠及時(shí)給出報(bào)警信息。多個(gè)點(diǎn)信息結(jié)合，準(zhǔn)確判斷被攻擊目標(biāo)和攻 擊手法。一旦發(fā)現(xiàn)異常，立即啟動(dòng)在虛擬防御組織中的應(yīng)急流程，防御組織需要囊 括到足夠全面的人員，至少包含監(jiān)控部門、運(yùn)維部門、網(wǎng)絡(luò)部門、安全部門、 客服部門、業(yè)務(wù)部門等，所有人員都需要 2-3 個(gè)備份。流程啟動(dòng)后，除了人工 處理，還應(yīng)該包含一定的自動(dòng)處理、半自動(dòng)處理能力。例如自動(dòng)化的攻擊分 析，確定攻擊類型，自動(dòng)化、半自動(dòng)化的防御策略，在安全人員到位之前，最 先發(fā)現(xiàn)攻擊的部門可以做一些緩解措施。除了 DDoS到來之時(shí)的流程等工作之外，更多的工作是在攻擊到來之前。主 要包含CDN節(jié)點(diǎn)部署、DNS設(shè)置、流程演習(xí)等。對(duì)于企業(yè)來說，具備多個(gè)CDN節(jié)點(diǎn)是DDoS防御容量的關(guān)鍵指標(biāo)。當(dāng)一個(gè)機(jī)房承擔(dān)不住海量數(shù)據(jù)時(shí)，可以通過 DNS輪詢的方式，把流量引導(dǎo)到多個(gè)分布節(jié)點(diǎn)，使用防御設(shè)備分頭處理。因此 DNS的TTL值需要設(shè)置得足夠小，能夠快速切換，每個(gè) CDN節(jié)點(diǎn)的各種VIP設(shè) 置也需要準(zhǔn)備充分。在虛擬化時(shí)代，各種用戶的不同業(yè)務(wù)共處在相同的物理機(jī)平臺(tái)，遭受 DDoS 攻擊的可能性越來越高，而且一個(gè)用戶被攻擊可能牽扯到大量的其他用戶，