如何在 Linux 上模擬和緩解 DDoS 攻擊

在我的上一篇文章談到了如何使用?tcpdump?和?wireshark，并帶您了解了幾個用例。今天我們來看看另一個常見的問題，如何緩解 DDoS（分布式拒絕服務）導致的性能下降。

什么是 DDoS？

DDoS 的前身是 DoS（Denial of Service），即拒絕服務攻擊，是指利用大量合理請求占用過多目標資源，使目標服務無法響應正常的請求.

DDoS（Distributed Denial of Service）采用基于 DoS 的分布式架構，利用多臺主機同時攻擊目標主機。這樣，即使目標服務部署了網絡防御設備，仍然無法應對大量的網絡請求。

從攻擊原理來看，DDoS 可分為以下幾種。

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

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

案例準備

您需要遵循：

• 3 臺 Linux 主機：應用程序、攻擊者、客戶端

• 預安裝?docker、sar、hping3、tcpdump、curl。

應用服務器

讓我們在應用主機上啟動一個簡單的?nginx?服務：

[root@app?~]#?docker?run?-itd?--name=nginx?--network=host?nginx
a8b3685d5eef0ffa2dead081b88d50d777db04bedbdb77ba886ca89b4bb690d2
[root@app?~]#?docker?ps
CONTAINER?ID???IMAGE?????COMMAND??????????????????CREATED??????????STATUS??????????PORTS?????NAMES
a8b3685d5eef???nginx?????"/docker-entrypoint.…"???24?seconds?ago???Up?21?seconds?????????????nginx

客戶端

然后，在客戶端主機中，使用?curl?訪問 Nginx 正在監(jiān)聽的端口，并確認 Nginx 已經正常啟動：

[root@client?~]#?curl?-s?-w?'Http?code:?%{http_code}\nTotal?time:%{time_total}s\n'?-o?/dev/null?http://172.31.88.139
Http?code:?200
Total?time:0.002437s

從這里可以看出，正常情況下，我們訪問 Nginx 只需要 2ms（0.002s）。

攻擊者

現(xiàn)在，讓我們從攻擊者主機那里運行?hping3?命令來模擬 Dos 攻擊：

#?-S?means?set?syn，-p?means?port?80
#?-i?u10?send?a?packet?frame?every?10?m-seconds
$?hping3?-S?-p?80?-i?u10?--flood?192.168.0.30
HPING?172.31.88.139?(eth0?172.31.88.139):?S?set,?40?headers?+?0?data?bytes
hping?in?flood?mode,?no?replies?will?be?shown

緩解攻擊

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

[root@client?~]#?curl?-s?-w?'Http?code:?%{http_code}\nTotal?time:%{time_total}s\n'?-o?/dev/null?http://172.31.88.139
Http?code:?000
Total?time:10.001s
curl:?(28)?Connection?timed?out?after?10000?milliseconds

這次普通客戶端的連接超時，其并沒有收到 Nginx 服務的響應。

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

[root@app?~]#?sar?-n?DEV?1
08:55:49????????IFACE???rxpck/s???txpck/s????rxkB/s????txkB/s???rxcmp/s???txcmp/s??rxmcst/s???%ifutil
08:55:50??????docker0??????0.00??????0.00??????0.00??????0.00??????0.00??????0.00??????0.00??????0.00
08:55:50?????????eth0??22274.00????629.00???1174.64?????37.78??????0.00??????0.00??????0.00??????0.02
08:55:50???????????lo??????0.00??????0.00??????0.00??????0.00??????0.00??????0.00??????0.00??????0.00

從這次?sar?的輸出可以看出，網絡接收到的 PPS 已經達到 2 萬多，但是 BPS 只有 1174kB。因此，可以計算每個包的大小只有?54B（）。

包大小不算大，但這是個什么樣的包呢？讓我們使用?tcpdump?來捕獲：

[root@app?~]#?tcpdump?-i?eth0?-n?tcp?port?80
09:15:48.287047?IP?172.31.82.28.27095?>?172.31.88.139:?Flags?[S],?seq?1288268370,?win?512,?length?0
09:15:48.287050?IP?172.31.82.28.27131?>?172.31.88.139:?Flags?[S],?seq?2084255254,?win?512,?length?0
09:15:48.287052?IP?172.31.82.28.27116?>?172.31.88.139:?Flags?[S],?seq?677393791,?win?512,?length?0
09:15:48.287055?IP?172.31.82.28.27141?>?172.31.88.139:?Flags?[S],?seq?1276451587,?win?512,?length?0
09:15:48.287068?IP?172.31.82.28.27154?>?172.31.88.139:?Flags?[S],?seq?1851495339,?win?512,?length?0
...

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

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

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

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

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

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

[root@app?~]#?netstat?-n?-p?|?grep?SYN_REC
tcp????????0??????0?172.31.88.139:80??????????172.31.82.28:12503??????SYN_RECV????-
tcp????????0??????0?172.31.88.139:80??????????172.31.82.28:13502??????SYN_RECV????-
tcp????????0??????0?172.31.88.139:80??????????172.31.82.28:15256??????SYN_RECV????-
tcp????????0??????0?172.31.88.139:80??????????172.31.82.28:18117??????SYN_RECV????-
...

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

[root@app?~]#?netstat?-n?-p?|?grep?SYN_REC?|?wc?-l
193

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

[root@app?~]#?iptables?-I?INPUT?-s?172.31.82.28?-p?tcp?-j?REJECT

執(zhí)行上述命令后，讓我們再次從客戶端主機嘗試?curl：

$?curl?-w?'Http?code:?%{http_code}\nTotal?time:%{time_total}s\n'-o?/dev/null--connect-timeout?10?http://172.31.88.139
Http?code:?200
Total?time:1.572171s

但一般來說，SYN Flood 攻擊中的源 IP 是不固定的（例如，您可以通過將?--rand-source?選項添加到?hping3?命令來隨機化源 IP）。此時，剛才的方法并不適用。

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

#?Limit?the?number?of?syn?concurrency?to?1?per?second
$?iptables?-A?INPUT?-p?tcp?--syn?-m?limit?--limit?1/s?-j?ACCEPT
#Limit?the?number?of?newly?established?connections?for?a?single?IP?in?60?seconds?to?10
$?iptables?-I?INPUT?-p?tcp?--dport?80?--syn?-m?recent?--name?SYN_FLOOD?--update?--seconds?60?--hitcount?10?-j?REJECT

到目前為止，我們已經初步限制了 SYN Flood 攻擊。但這還不夠，因為我們的案例只是單一的攻擊源。

如果多臺機器同時發(fā)送 SYN Flood，則該方法可能直接失效。因為您可能無法通過 SSH 連接到機器（SSH 也是基于 TCP 的），更不用說執(zhí)行上面的那些排查命令了。

TCP 優(yōu)化

為了緩解多臺機器的 SYN Flood 攻擊，我們可以將半開連接容量從默認的 256 增加到 1024：

$?sysctl?net.ipv4.tcp_max_syn_backlog
net.ipv4.tcp_max_syn_backlog?=?256
$?sysctl?-w?net.ipv4.tcp_max_syn_backlog=1024net.ipv4.tcp_max_syn_backlog?=?1024

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

$?sysctl?-w?net.ipv4.tcp_synack_retries=1
net.ipv4.tcp_synack_retries?=?1

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

$?sysctl?-w?net.ipv4.tcp_syncookies=1
net.ipv4.tcp_syncookies?=?1

需要注意的是，上面?sysctl?命令所修改的配置是臨時的，重啟后將會丟失。您可以通過將它們添加到?/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

結論

今天，我們談到了在分布式拒絕服務 (DDoS) 情況下的緩解措施。DDoS 利用大量偽造請求，使目標服務消耗大量資源來處理這些無效的請求，進而無法正常響應正常用戶請求。

由于 DDoS 分布的流量大和難以追蹤等特點，目前沒有辦法完全防御 DDoS 帶來的問題，因此只能緩解其造成的影響。