防御基礎(chǔ)

攻擊流量到底多大

談到DDoS防御，首先就是要知道到底遭受了多大的攻擊。這個問題看似簡單，實際上卻有很多不為人知的細節(jié)在里面。

以SYN Flood為例，為了提高發(fā)送效率在服務(wù)端產(chǎn)生更多的SYN等待隊列，攻擊程序在填充包頭時，IP首部和TCP首部都不填充可選的字段，因此IP首部長度恰好是20字節(jié)，TCP首部也是20字節(jié)，共40字節(jié)。

對于以太網(wǎng)來說，最小的包長度數(shù)據(jù)段必須達到46字節(jié)，而攻擊報文只有40字節(jié)，因此，網(wǎng)卡在發(fā)送時，會做一些處理，在TCP首部的末尾，填充6個0來滿足最小包的長度要求。這個時候，整個數(shù)據(jù)包的長度為14字節(jié)的以太網(wǎng)頭，20字節(jié)的IP頭，20字節(jié)的TCP頭，再加上因為最小包長度要求而填充的6個字節(jié)的0，一共是60字節(jié)。

但這還沒有結(jié)束。以太網(wǎng)在傳輸數(shù)據(jù)時，還有CRC檢驗的要求。網(wǎng)卡會在發(fā)送數(shù)據(jù)之前對數(shù)據(jù)包進行CRC檢驗，將4字節(jié)的CRC值附加到包頭的最后面。這個時候，數(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é)檢驗|

|目的MAC|源MAC|協(xié)議類型| IP頭 |TCP頭|以太網(wǎng)填充 | CRC檢驗 |

到64字節(jié)時，SYN數(shù)據(jù)包已經(jīng)填充完成，準備開始傳輸了。攻擊數(shù)據(jù)包很小，遠遠不夠最大傳輸單元（MTU）的1500字節(jié)，因此不會被分片。那么這些數(shù)據(jù)包就像生產(chǎn)流水線上的罐頭一樣，一個包連著一個包緊密地擠在一起傳輸嗎？事實上不是這樣的。

以太網(wǎng)在傳輸時，還有前導(dǎo)碼（preamble）和幀間距（inter-frame gap）。其中前導(dǎo)碼占8字節(jié)（byte），即64比特位。前導(dǎo)碼前面的7字節(jié)都是10101010，1和0間隔而成。但第八個字節(jié)就變成了10101011，當主機監(jiān)測到連續(xù)的兩個1時，就知道后面開始是數(shù)據(jù)了。在網(wǎng)絡(luò)傳輸時，數(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檢驗|12字節(jié)幀間距|

也就是說，一個本來只有40字節(jié)的SYN包，在網(wǎng)絡(luò)上傳輸時占的帶寬，其實是84字節(jié)。

有了上面的基礎(chǔ)，現(xiàn)在可以開始計算攻擊流量和網(wǎng)絡(luò)設(shè)備的線速問題了。當只填充IP頭和TCP頭的最小SYN包跑在以太網(wǎng)絡(luò)上時，100Mbit的網(wǎng)絡(luò)，能支持的最大PPS（Packet Per Second）是100×106 / (8 * (64+8+12)) = 148809，1000Mbit的網(wǎng)絡(luò)，能支持的最大PPS是1488090。#p#

SYN Flood防御

前文描述過，SYN Flood攻擊大量消耗服務(wù)器的CPU、內(nèi)存資源，并占滿SYN等待隊列。相應(yīng)的，我們修改內(nèi)核參數(shù)即可有效緩解。主要參數(shù)如下：

net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_max_syn_backlog = 8192

net.ipv4.tcp_synack_retries = 2

分別為啟用SYN Cookie、設(shè)置SYN最大隊列長度以及設(shè)置SYN+ACK最大重試次數(shù)。

SYN Cookie的作用是緩解服務(wù)器資源壓力。啟用之前，服務(wù)器在接到SYN數(shù)據(jù)包后，立即分配存儲空間，并隨機化一個數(shù)字作為SYN號發(fā)送SYN+ACK數(shù)據(jù)包。然后保存連接的狀態(tài)信息等待客戶端確認。啟用SYN Cookie之后，服務(wù)器不再分配存儲空間，而且通過基于時間種子的隨機數(shù)算法設(shè)置一個SYN號，替代完全隨機的SYN號。發(fā)送完SYN+ACK確認報文之后，清空資源不保存任何狀態(tài)信息。直到服務(wù)器接到客戶端的最終ACK包，通過Cookie檢驗算法鑒定是否與發(fā)出去的SYN+ACK報文序列號匹配，匹配則通過完成握手，失敗則丟棄。當然，前文的高級攻擊中有SYN混合ACK的攻擊方法，則是對此種防御方法的反擊，其中優(yōu)劣由雙方的硬件配置決定

tcp_max_syn_backlog則是使用服務(wù)器的內(nèi)存資源，換取更大的等待隊列長度，讓攻擊數(shù)據(jù)包不至于占滿所有連接而導(dǎo)致正常用戶無法完成握手。net.ipv4.tcp_synack_retries是降低服務(wù)器SYN+ACK報文重試次數(shù)，盡快釋放等待資源。這三種措施與攻擊的三種危害一一對應(yīng)，完完全全地對癥下藥。但這些措施也是雙刃劍，可能消耗服務(wù)器更多的內(nèi)存資源，甚至影響正常用戶建立TCP連接，需要評估服務(wù)器硬件資源和攻擊大小謹慎設(shè)置。

除了定制TCP/IP協(xié)議棧之外，還有一種常見做法是TCP首包丟棄方案，利用TCP協(xié)議的重傳機制識別正常用戶和攻擊報文。當防御設(shè)備接到一個IP地址的SYN報文后，簡單比對該IP是否存在于白名單中，存在則轉(zhuǎn)發(fā)到后端。如不存在于白名單中，檢查是否是該IP在一定時間段內(nèi)的首次SYN報文，不是則檢查是否重傳報文，是重傳則轉(zhuǎn)發(fā)并加入白名單，不是則丟棄并加入黑名單。是首次SYN報文則丟棄并等待一段時間以試圖接受該IP的SYN重傳報文，等待超時則判定為攻擊報文加入黑名單。

首包丟棄方案對用戶體驗會略有影響，因為丟棄首包重傳會增大業(yè)務(wù)的響應(yīng)時間，有鑒于此發(fā)展出了一種更優(yōu)的TCP Proxy方案。所有的SYN數(shù)據(jù)報文由清洗設(shè)備接受，按照SYN Cookie方案處理。和設(shè)備成功建立了TCP三次握手的IP地址被判定為合法用戶加入白名單，由設(shè)備偽裝真實客戶端IP地址再與真實服務(wù)器完成三次握手，隨后轉(zhuǎn)發(fā)數(shù)據(jù)。而指定時間內(nèi)沒有和設(shè)備完成三次握手的IP地址，被判定為惡意IP地址屏蔽一定時間。除了SYN Cookie結(jié)合TCP Proxy外，清洗設(shè)備還具備多種畸形TCP標志位數(shù)據(jù)包探測的能力，通過對SYN報文返回非預(yù)期應(yīng)答測試客戶端反應(yīng)的方式來鑒別正常訪問和惡意行為。

清洗設(shè)備的硬件具有特殊的網(wǎng)絡(luò)處理器芯片和特別優(yōu)化的操作系統(tǒng)、TCP/IP協(xié)議棧，可以處理非常巨大的流量和SYN隊列。#p#

HTTP Flood防御

HTTP Flood攻擊防御主要通過緩存的方式進行，盡量由設(shè)備的緩存直接返回結(jié)果來保護后端業(yè)務(wù)。大型的互聯(lián)網(wǎng)企業(yè)，會有龐大的CDN節(jié)點緩存內(nèi)容。

當高級攻擊者穿透緩存時，清洗設(shè)備會截獲HTTP請求做特殊處理。最簡單的方法就是對源IP的HTTP請求頻率做統(tǒng)計，高于一定頻率的IP地址加入黑名單。這種方法過于簡單，容易帶來誤殺，并且無法屏蔽來自代理服務(wù)器的攻擊，因此逐漸廢止，取而代之的是JavaScript跳轉(zhuǎn)人機識別方案。

HTTP Flood是由程序模擬HTTP請求，一般來說不會解析服務(wù)端返回數(shù)據(jù)，更不會解析JS之類代碼。因此當清洗設(shè)備截獲到HTTP請求時，返回一段特殊JavaScript代碼，正常用戶的瀏覽器會處理并正常跳轉(zhuǎn)不影響使用，而攻擊程序會攻擊到空處。

DNS Flood防御

DNS攻擊防御也有類似HTTP的防御手段，第一方案是緩存。其次是重發(fā)，可以是直接丟棄DNS報文導(dǎo)致UDP層面的請求重發(fā)，可以是返回特殊響應(yīng)強制要求客戶端使用TCP協(xié)議重發(fā)DNS查詢請求。

特殊的，對于授權(quán)域DNS的保護，設(shè)備會在業(yè)務(wù)正常時期提取收到的DNS域名列表和ISP DNS IP列表備用，在攻擊時，非此列表的請求一律丟棄，大幅降低性能壓力。對于域名，實行同樣的域名白名單機制，非白名單中的域名解析請求，做丟棄處理。

慢速連接攻擊防御

Slowloris攻擊防御比較簡單，主要方案有兩個。

第一個是統(tǒng)計每個TCP連接的時長并計算單位時間內(nèi)通過的報文數(shù)量即可做精確識別。一個TCP連接中，HTTP報文太少和報文太多都是不正常的，過少可能是慢速連接攻擊，過多可能是使用HTTP 1.1協(xié)議進行的HTTP Flood攻擊，在一個TCP連接中發(fā)送多個HTTP請求。

第二個是限制HTTP頭部傳輸?shù)淖畲笤S可時間。超過指定時間HTTP Header還沒有傳輸完成，直接判定源IP地址為慢速連接攻擊，中斷連接并加入黑名單。#p#

企業(yè)級防御

互聯(lián)網(wǎng)企業(yè)防御DDoS攻擊，主要使用上文的基礎(chǔ)防御手段，重點在于監(jiān)控、組織以及流程。

監(jiān)控需要具備多層監(jiān)控、縱深防御的概念，從骨干網(wǎng)絡(luò)、IDC入口網(wǎng)絡(luò)的BPS、PPS、協(xié)議分布，負載均衡層的VIP新建連接數(shù)、并發(fā)連接數(shù)、BPS、PPS到主機層的CPU狀態(tài)、TCP新建連接數(shù)狀態(tài)、TCP并發(fā)連接數(shù)狀態(tài)，到業(yè)務(wù)層的業(yè)務(wù)處理量、業(yè)務(wù)連通性等多個點部署監(jiān)控系統(tǒng)。即使一個監(jiān)控點失效，其他監(jiān)控點也能夠及時給出報警信息。多個點信息結(jié)合，準確判斷被攻擊目標和攻擊手法。

一旦發(fā)現(xiàn)異常，立即啟動在虛擬防御組織中的應(yīng)急流程，防御組織需要囊括到足夠全面的人員，至少包含監(jiān)控部門、運維部門、網(wǎng)絡(luò)部門、安全部門、客服部門、業(yè)務(wù)部門等，所有人員都需要2-3個備份。流程啟動后，除了人工處理，還應(yīng)該包含一定的自動處理、半自動處理能力。例如自動化的攻擊分析，確定攻擊類型，自動化、半自動化的防御策略，在安全人員到位之前，最先發(fā)現(xiàn)攻擊的部門可以做一些緩解措施。

除了DDoS到來之時的流程等工作之外，更多的工作是在攻擊到來之前。主要包含CDN節(jié)點部署、DNS設(shè)置、流程演習(xí)等。對于企業(yè)來說，具備多個CDN節(jié)點是DDoS防御容量的關(guān)鍵指標。當一個機房承擔不住海量數(shù)據(jù)時，可以通過DNS輪詢的方式，把流量引導(dǎo)到多個分布節(jié)點，使用防御設(shè)備分頭處理。因此DNS的TTL值需要設(shè)置得足夠小，能夠快速切換，每個CDN節(jié)點的各種VIP設(shè)置也需要準備充分。

在虛擬化時代，各種用戶的不同業(yè)務(wù)共處在相同的物理機平臺，遭受DDoS攻擊的可能性越來越高，而且一個用戶被攻擊可能牽扯到大量的其他用戶，危害被顯著放大，因此防御顯得尤為重要。阿里云的虛擬化業(yè)務(wù)，平均每天遭受約20起DDoS攻擊，最大流量達到接近20Gbit/s，所有這些攻擊都在15分鐘內(nèi)自動處理完成，讓客戶遠離DDoS的威脅，專心發(fā)展業(yè)務(wù)。

總地來說，對DDoS防御，主要的工作是幕后積累。臺上十分鐘，臺下十年功，沒有充分的資源準備，沒有足夠的應(yīng)急演練，沒有豐富的處理經(jīng)驗，DDoS攻擊將是所有人的噩夢。