在我的上一篇文章談到了如何使用tcpdump和wireshark，并帶您了解了幾個(gè)用例。今天我們來(lái)看看另一個(gè)常見(jiàn)的問(wèn)題，如何緩解 DDoS（分布式拒絕服務(wù)）導(dǎo)致的性能下降。

什么是 DDoS？

DDoS 的前身是 DoS（Denial of Service），即拒絕服務(wù)攻擊，是指利用大量合理請(qǐng)求占用過(guò)多目標(biāo)資源，使目標(biāo)服務(wù)無(wú)法響應(yīng)正常的請(qǐng)求.

DDoS（Distributed Denial of Service）采用基于 DoS 的分布式架構(gòu)，利用多臺(tái)主機(jī)同時(shí)攻擊目標(biāo)主機(jī)。這樣，即使目標(biāo)服務(wù)部署了網(wǎng)絡(luò)防御設(shè)備，仍然無(wú)法應(yīng)對(duì)大量的網(wǎng)絡(luò)請(qǐng)求。

從攻擊原理來(lái)看，DDoS 可分為以下幾種。

• 用盡帶寬：無(wú)論是服務(wù)器還是路由器、交換機(jī)等網(wǎng)絡(luò)設(shè)備，帶寬都有一個(gè)固定的上限。當(dāng)帶寬耗盡時(shí)，會(huì)出現(xiàn)網(wǎng)絡(luò)擁塞，無(wú)法傳輸其他正常的網(wǎng)絡(luò)數(shù)據(jù)包。
• 耗盡系統(tǒng)資源：網(wǎng)絡(luò)服務(wù)的正常運(yùn)行需要一定的系統(tǒng)資源，如CPU、內(nèi)存等物理資源，以及連接表等軟件資源。一旦資源耗盡，系統(tǒng)將無(wú)法處理其他正常的網(wǎng)絡(luò)連接。
• 耗盡應(yīng)用資源：應(yīng)用程序的運(yùn)行通常還需要與其他資源或系統(tǒng)進(jìn)行交互。如果應(yīng)用程序一直忙于處理無(wú)效請(qǐng)求，也會(huì)導(dǎo)致正常請(qǐng)求的處理速度變慢，甚至沒(méi)有響應(yīng)。

無(wú)論哪種類型的 DDoS，危害都是巨大的。那么，如何發(fā)現(xiàn)系統(tǒng)遭受了 DDoS 攻擊，如何應(yīng)對(duì)這種攻擊呢？讓我?guī)私庖粋€(gè)現(xiàn)實(shí)生活中的用例。

案例準(zhǔn)備

您需要遵循：

• 3 臺(tái) Linux 主機(jī)：應(yīng)用程序、攻擊者、客戶端

• 預(yù)安裝docker、sar、hping3、tcpdump、curl。

應(yīng)用服務(wù)器

讓我們?cè)趹?yīng)用主機(jī)上啟動(dòng)一個(gè)簡(jiǎn)單的nginx服務(wù)：

[root@app~]#dockerrun-itd--name=nginx--network=hostnginx
a8b3685d5eef0ffa2dead081b88d50d777db04bedbdb77ba886ca89b4bb690d2
[root@app~]#dockerps
CONTAINERIDIMAGECOMMANDCREATEDSTATUSPORTSNAMES
a8b3685d5eefnginx"/docker-entrypoint.…"24secondsagoUp21secondsnginx

客戶端

然后，在客戶端主機(jī)中，使用curl訪問(wèn) Nginx 正在監(jiān)聽(tīng)的端口，并確認(rèn) Nginx 已經(jīng)正常啟動(dòng)：

[root@client~]#curl-s-w'Httpcode:%{http_code}
Totaltime:%{time_total}s
'-o/dev/nullhttp://172.31.88.139
Httpcode:200
Totaltime:0.002437s

從這里可以看出，正常情況下，我們?cè)L問(wèn) Nginx 只需要 2ms（0.002s）。

攻擊者

現(xiàn)在，讓我們從攻擊者主機(jī)那里運(yùn)行hping3命令來(lái)模擬 Dos 攻擊：

#-Smeanssetsyn，-pmeansport80
#-iu10sendapacketframeevery10m-seconds
$hping3-S-p80-iu10--flood192.168.0.30
HPING172.31.88.139(eth0172.31.88.139):Sset,40headers+0databytes
hpinginfloodmode,noreplieswillbeshown

緩解攻擊

現(xiàn)在讓我們回到客戶端主機(jī)，再次嘗試curl命令：

[root@client~]#curl-s-w'Httpcode:%{http_code}
Totaltime:%{time_total}s
'-o/dev/nullhttp://172.31.88.139
Httpcode:000
Totaltime:10.001s
curl:(28)Connectiontimedoutafter10000milliseconds

這次普通客戶端的連接超時(shí)，其并沒(méi)有收到 Nginx 服務(wù)的響應(yīng)。

這里發(fā)生了什么事呢？讓我們回到主機(jī)應(yīng)用程序，并檢查當(dāng)前的網(wǎng)絡(luò)狀態(tài)：

[root@app~]#sar-nDEV1
0849IFACErxpck/stxpck/srxkB/stxkB/srxcmp/stxcmp/srxmcst/s%ifutil
0850docker00.000.000.000.000.000.000.000.00
0850eth022274.00629.001174.6437.780.000.000.000.02
0850lo0.000.000.000.000.000.000.000.00

從這次sar的輸出可以看出，網(wǎng)絡(luò)接收到的 PPS 已經(jīng)達(dá)到 2 萬(wàn)多，但是 BPS 只有 1174kB。因此，可以計(jì)算每個(gè)包的大小只有54B（）。

包大小不算大，但這是個(gè)什么樣的包呢？讓我們使用tcpdump來(lái)捕獲：

[root@app~]#tcpdump-ieth0-ntcpport80
0948.287047IP172.31.82.28.27095>172.31.88.139:Flags[S],seq1288268370,win512,length0
0948.287050IP172.31.82.28.27131>172.31.88.139:Flags[S],seq2084255254,win512,length0
0948.287052IP172.31.82.28.27116>172.31.88.139:Flags[S],seq677393791,win512,length0
0948.287055IP172.31.82.28.27141>172.31.88.139:Flags[S],seq1276451587,win512,length0
0948.287068IP172.31.82.28.27154>172.31.88.139:Flags[S],seq1851495339,win512,length0
...

在該輸出中，Flags [S]表示這是一個(gè) SYN 數(shù)據(jù)包。而大量的 SYN 數(shù)據(jù)包表明這是一次 SYN Flood 攻擊。如果我們用wireshark來(lái)觀察，可以更加直觀地看到 SYN Flood 的過(guò)程：

事實(shí)上，SYN Flood 是互聯(lián)網(wǎng)上最經(jīng)典的 DDoS 攻擊。從上圖也可以看出它的原理：

• 客戶端構(gòu)造大量 SYN 包，請(qǐng)求建立 TCP 連接；
• 服務(wù)器收到包后，會(huì)向源 IP 發(fā)送一個(gè) SYN+ACK 包，并等待三次握手的最后一個(gè) ACK 包，直到鏈接超時(shí)。

這種等待狀態(tài)的 TCP 連接通常也稱為半開(kāi)連接（Half-Open Connection）。由于連接表（Connection Table）的大小是有限的，而大量的半開(kāi)連接會(huì)導(dǎo)致連接表快速填滿，從而無(wú)法建立新的 TCP 連接。

從下面的 TCP 狀態(tài)圖可以看到，此時(shí)服務(wù)器端的 TCP 連接會(huì)處于SYN_RECEIVED狀態(tài)：

我們可以使用netstat來(lái)查看所有連接的狀態(tài)，但需要注意的是SYN_REVEIVED的狀態(tài)通常縮寫(xiě)為SYN_RECV。

[root@app~]#netstat-n-p|grepSYN_REC
tcp00172.31.88.139:80172.31.82.28:12503SYN_RECV-
tcp00172.31.88.139:80172.31.82.28:13502SYN_RECV-
tcp00172.31.88.139:80172.31.82.28:15256SYN_RECV-
tcp00172.31.88.139:80172.31.82.28:18117SYN_RECV-
...

從結(jié)果中可以發(fā)現(xiàn)，存在大量的SYN_RECV狀態(tài)的連接，源 IP 地址為172.31.82.28。現(xiàn)在，讓我們統(tǒng)計(jì)一下正處于SYN_RECV狀態(tài)的連接數(shù)：

[root@app~]#netstat-n-p|grepSYN_REC|wc-l
193

找出源 IP 后，只需丟棄相關(guān)數(shù)據(jù)包即可解決 SYN 攻擊的問(wèn)題。此時(shí)，iptables可以幫你完成這個(gè)任務(wù)：（注意：Serban 在評(píng)論中建議“在這種情況下，DROP比可能REJECT更好”）

[root@app~]#iptables-IINPUT-s172.31.82.28-ptcp-jREJECT

執(zhí)行上述命令后，讓我們?cè)俅螐目蛻舳酥鳈C(jī)嘗試curl：

$curl-w'Httpcode:%{http_code}
Totaltime:%{time_total}s
'-o/dev/null--connect-timeout10http://172.31.88.139
Httpcode:200
Totaltime:1.572171s

但一般來(lái)說(shuō)，SYN Flood 攻擊中的源 IP 是不固定的（例如，您可以通過(guò)將--rand-source選項(xiàng)添加到hping3命令來(lái)隨機(jī)化源 IP）。此時(shí)，剛才的方法并不適用。

幸運(yùn)的是，我們還有許多其他方法可以達(dá)到類似的目的。例如，我們可以通過(guò)兩種方式限制同步數(shù)據(jù)包的速率：

#Limitthenumberofsynconcurrencyto1persecond
$iptables-AINPUT-ptcp--syn-mlimit--limit1/s-jACCEPT
#LimitthenumberofnewlyestablishedconnectionsforasingleIPin60secondsto10
$iptables-IINPUT-ptcp--dport80--syn-mrecent--nameSYN_FLOOD--update--seconds60--hitcount10-jREJECT

到目前為止，我們已經(jīng)初步限制了 SYN Flood 攻擊。但這還不夠，因?yàn)槲覀兊陌咐皇菃我坏墓粼础?/p>

如果多臺(tái)機(jī)器同時(shí)發(fā)送 SYN Flood，則該方法可能直接失效。因?yàn)槟赡軣o(wú)法通過(guò) SSH 連接到機(jī)器（SSH 也是基于 TCP 的），更不用說(shuō)執(zhí)行上面的那些排查命令了。

TCP 優(yōu)化

為了緩解多臺(tái)機(jī)器的 SYN Flood 攻擊，我們可以將半開(kāi)連接容量從默認(rèn)的 256 增加到 1024：

$sysctlnet.ipv4.tcp_max_syn_backlog
net.ipv4.tcp_max_syn_backlog=256
$sysctl-wnet.ipv4.tcp_max_syn_backlog=1024net.ipv4.tcp_max_syn_backlog=1024

另外，每當(dāng)連接狀態(tài)為 SYN_RECV 的連接時(shí)，如果連接失敗，內(nèi)核會(huì)自動(dòng)重試，默認(rèn)重試次數(shù)為 5 次。您可以通過(guò)執(zhí)行以下命令將其減少到 1 次：

$sysctl-wnet.ipv4.tcp_synack_retries=1
net.ipv4.tcp_synack_retries=1

此外，TCP SYN Cookies 也是一種特殊的防御 SYN Flood 攻擊的機(jī)制。SYN Cookies 根據(jù)連接信息（包括源地址、源端口、目的地址、目的端口等）和加密種子（如系統(tǒng)啟動(dòng)時(shí)間）計(jì)算哈希值（SHA1）。該哈希值稱為 cookie。啟用 SYN Cookies 后，無(wú)需再保持半開(kāi)連接狀態(tài)，同時(shí)半開(kāi)連接的數(shù)量也將沒(méi)有限制。

$sysctl-wnet.ipv4.tcp_syncookies=1
net.ipv4.tcp_syncookies=1

需要注意的是，上面sysctl命令所修改的配置是臨時(shí)的，重啟后將會(huì)丟失。您可以通過(guò)將它們添加到/etc/sysctl.conf文件中使其持久化。例如：

$cat/etc/sysctl.conf
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_synack_retries=1
net.ipv4.tcp_max_syn_backlog=1024
$sysctl-p

結(jié)論

今天，我們談到了在分布式拒絕服務(wù) (DDoS) 情況下的緩解措施。DDoS 利用大量偽造請(qǐng)求，使目標(biāo)服務(wù)消耗大量資源來(lái)處理這些無(wú)效的請(qǐng)求，進(jìn)而無(wú)法正常響應(yīng)正常用戶請(qǐng)求。

由于 DDoS 分布的流量大和難以追蹤等特點(diǎn)，目前沒(méi)有辦法完全防御 DDoS 帶來(lái)的問(wèn)題，因此只能緩解其造成的影響。