DDos的前身是 DoS(Denail of Service)，即拒絕服務(wù)攻擊，指利用大連的合理請(qǐng)求，占用過多的目標(biāo)資源，從而使目標(biāo)服務(wù)器無法響應(yīng)正常請(qǐng)求

DDos(Distributed Denail of Service)，是在Dos的基礎(chǔ)上，采用了分布式架構(gòu)，利用多臺(tái)主機(jī)同時(shí)攻擊目標(biāo)主機(jī)，這樣即使目標(biāo)服務(wù)器部署了網(wǎng)絡(luò)防御設(shè)備，面對(duì)大量網(wǎng)絡(luò)請(qǐng)求時(shí)，還是無能為力

目前已知最大流量攻擊，是2018年Github遭受的DDos攻擊，峰值達(dá)到了1.35Tbps，PPS達(dá)到了1.2億

從攻擊原理看，DDos分為以下幾類

1.耗盡貸款，無論是服務(wù)器還是路由器，交換機(jī)等網(wǎng)絡(luò)設(shè)備，帶寬都有固定上限，帶寬耗盡后就會(huì)發(fā)生網(wǎng)絡(luò)擁堵，從而無法傳輸其他正常的網(wǎng)絡(luò)報(bào)文

2.耗盡操作系統(tǒng)的資源，網(wǎng)絡(luò)服務(wù)的正常運(yùn)行，都需要一定的資源，像CPU，內(nèi)存等物理資源，以及連接表等軟件資源，一旦耗盡，系統(tǒng)就不能處理其他正常的網(wǎng)絡(luò)連接

3.消耗應(yīng)用程序的的資源，應(yīng)用的運(yùn)行通常需要跟其他資源或系統(tǒng)交互，如應(yīng)用程序一直忙于處理無效請(qǐng)求，也會(huì)導(dǎo)致正常請(qǐng)求的處理變慢，甚至得不到響應(yīng)

比如構(gòu)造大量不同的域名來攻擊DNS服務(wù)器，就會(huì)導(dǎo)致DNS服務(wù)器不停的執(zhí)行迭代查詢，并更新緩存，這會(huì)極大地消耗DNS服務(wù)器資源，使DNS響應(yīng)變慢

案例準(zhǔn)備

環(huán)境如下

這里只使用了一臺(tái)機(jī)器只是傳統(tǒng)的Dos，而非DDos

案例分析

輸入下面命令，運(yùn)行nginx

# 運(yùn)行Nginx服務(wù)并對(duì)外開放端口docker run -itd -p 9527:80 nginx

用curl訪問nginx

-w 表示只輸出 HTTP 狀態(tài)碼及總時(shí)間，-o 表示將響應(yīng)重定向到 /dev/nullcurl -s -w 'Http code: %{http_code}\nTotal time:%{time_total}s\n' -o /dev/null http://【服務(wù)端IP】:9527/Http code: 200Total time:0.006s

運(yùn)行 hping3 命令，來模擬 DoS 攻擊：

# -S 參數(shù)表示設(shè)置 TCP 協(xié)議的 SYN（同步序列號(hào)），-p 表示目的端口為 80# -i u50 表示每隔 50 微秒發(fā)送一個(gè)網(wǎng)絡(luò)幀$ hping3 -S -p 9527 -i u50 【服務(wù)端IP】

再用curl訪問nginx

# --connect-timeout 表示連接超時(shí)時(shí)間# 需要把 hping3的 發(fā)送時(shí)間減小到120-200之間，否則tty終端會(huì)卡主curl-w'Http code: %{http_code}\nTotal time:%{time_total}s\n'-o/dev/null--connect-timeout10http://【服務(wù)端IP】:9527/%Total%Received%XferdAverageSpeedTimeTimeTimeCurrentDloadUploadTotalSpentLeftSpeed00000000--:--:--0:00:10--:--:--0Http code:000Totaltime:10.002scurl:(28)Connectiontimedoutafter10001milliseconds

查看網(wǎng)絡(luò)流量情況

sar-nDEV101:40:41PMIFACErxpck/stxpck/srxkB/stxkB/srxcmp/stxcmp/srxmcst/s01:40:42PMdocker00.000.000.000.000.000.000.0001:40:42PMlo0.000.000.000.000.000.000.0001:40:42PMveth0135a4e0.000.000.000.000.000.000.0001:40:42PMeth00.004829.350.00256.320.000.000.0001:40:42PMIFACErxpck/stxpck/srxkB/stxkB/srxcmp/stxcmp/srxmcst/s01:40:43PMdocker00.000.000.000.000.000.000.0001:40:43PMlo0.000.000.000.000.000.000.0001:40:43PMveth0135a4e0.000.000.000.000.000.000.0001:40:43PMeth00.004812.900.00254.350.000.000.00

(254.35*1024)/4812.9 計(jì)算出每個(gè)包大概54字節(jié)

很明顯是有大量的小包

tcpdump抓包分析

tcpdump-ieth0-ntcpport952713:45:49.182714IP【客戶端】.9527>【服務(wù)端】.talarian-mcast3:Flags[S.],seq2826135571,ack1762609067,win64240,options[mss1460],length013:45:49.182718IP【客戶端】.9527>【服務(wù)端】.talarian-mcast4:Flags[S.],seq586427663,ack1833631763,win64240,options[mss1460],length013:45:49.182724IP【客戶端】.9527>【服務(wù)端】.dnox:Flags[S.],seq1795830526,ack1902584524,win64240,options[mss1460],length013:45:49.182730IP【客戶端】.9527>【服務(wù)端】.nexus-portal:Flags[S.],seq295657488,ack197474288,win64240,options[mss1460],length0

這個(gè)輸出中，F(xiàn)lags [S] 表示這是一個(gè) SYN 包。大量的 SYN 包表明，這是一個(gè) SYN Flood 攻擊

實(shí)際上，SYN Flood 正是互聯(lián)網(wǎng)中最經(jīng)典的 DDoS 攻擊方式。從上面這個(gè)圖，你也可以看到它的原理：

• 即客戶端構(gòu)造大量的 SYN 包，請(qǐng)求建立 TCP 連接；

• 而服務(wù)器收到包后，會(huì)向源 IP 發(fā)送 SYN+ACK 報(bào)文，并等待三次握手的最后一次 ACK 報(bào)文，直到超時(shí)。

• 這種等待狀態(tài)的 TCP 連接，通常也稱為半開連接。由于連接表的大小有限，大量的半開連接就會(huì)導(dǎo)致連接表迅速占滿，從而無法建立新的 TCP 連接。

相關(guān)視頻推薦

Linux內(nèi)核源碼分析之TCP/IP協(xié)議棧源碼

《tcpip詳解卷一》：150行代碼拉開協(xié)議棧實(shí)現(xiàn)的篇章

學(xué)習(xí)地址：C/C++Linux服務(wù)器開發(fā)/后臺(tái)架構(gòu)師【零聲教育】-學(xué)習(xí)視頻教程-騰訊課堂

需要C/C++ Linux服務(wù)器架構(gòu)師學(xué)習(xí)資料加群812855908獲取（資料包括C/C++，Linux，golang技術(shù)，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒體，CDN，P2P，K8S，Docker，TCP/IP，協(xié)程，DPDK，ffmpeg等），免費(fèi)分享

查看 TCP 半開連接的方法，關(guān)鍵在于 SYN_RECEIVED 狀態(tài)的連接。我們可以使用 netstat ，來查看所有連接的狀態(tài)，不過要注意，SYN_REVEIVED 的狀態(tài)，通常被縮寫為 SYN_RECV。

執(zhí)行下面的 netstat 命令：

# -n 表示不解析名字，-p 表示顯示連接所屬進(jìn)程$netstat-n-p|grepSYN_RECtcp00【服務(wù)端】:9527【客戶端】:12503SYN_RECV-tcp00【服務(wù)端】:9527【客戶端】:13502SYN_RECV-tcp00【服務(wù)端】:9527【客戶端】:15256SYN_RECV-tcp00【服務(wù)端】:9527【客戶端】:18117SYN_RECV-

從結(jié)果中，可以發(fā)現(xiàn)大量 SYN_RECV 狀態(tài)的連接，找到源端ip，并將這個(gè)ip給禁掉

用iptables把DDoS給禁掉

iptables -I INPUT -s 【DDoS的ip】 -p tcp -j REJECT

再用curl訪問，速度快很多了

curl -w 'Http code: %{http_code}\nTotal time:%{time_total}s\n' -o /dev/null --connect-timeout 10http://【服務(wù)端IP】:9527/  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                 Dload  Upload   Total   Spent    Left  Speed10061210061200100k      0 --:--:-- --:--:-- --:--:--119kHttp code:200Total time:0.016s

SYN Flood 攻擊中的源 IP 并不是固定的。比如，可以在 hping3 命令中，加入 --rand-source 選項(xiàng)，來隨機(jī)化源 IP。這時(shí)，剛才的方法就不適用了。

解決辦法如下

# 限制 syn 并發(fā)數(shù)為每秒 1 次$ iptables -A INPUT -p tcp --syn -m limit --limit 1/s -j ACCEPT # 限制單個(gè) IP 在 60 秒新建立的連接數(shù)為 10$ iptables -I INPUT -p tcp --dport 80 --syn -m recent --name SYN_FLOOD --update --seconds 60 --hitcount 10 -j REJECT

如果是多臺(tái)機(jī)器同時(shí)發(fā)送 SYN Flood，這種方法可能就直接無效了�？赡苓BSSH都登不上了

所以，需要事先對(duì)系統(tǒng)做一些 TCP 優(yōu)化。

比如，SYN Flood 會(huì)導(dǎo)致 SYN_RECV 狀態(tài)的連接急劇增大，可以把默認(rèn)的半連接數(shù)調(diào)大

不過，半開狀態(tài)的連接數(shù)是有限制的，可以執(zhí)行下面命令

# 查看半連接大小sysctlnet.ipv4.tcp_max_syn_backlognet.ipv4.tcp_max_syn_backlog = 256 # 將半連接大小改為2048個(gè)sysctl-w net.ipv4.tcp_max_syn_backlog=2048net.ipv4.tcp_max_syn_backlog = 2048

另外，連接每個(gè) SYN_RECV 時(shí)，如果失敗的話，內(nèi)核還會(huì)自動(dòng)重試，并且默認(rèn)的重試次數(shù)是 5 次�？梢詧�(zhí)行下面的命令，將其減小為 1 次：

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

TCP SYN Cookies 也是一種專門防御 SYN Flood 攻擊的方法。SYN Cookies 基于連接信息（包括源地址、源端口、目的地址、目的端口等）以及一個(gè)加密種子（如系統(tǒng)啟動(dòng)時(shí)間），計(jì)算出一個(gè)哈希值（SHA1），這個(gè)哈希值稱為 cookie。

然后，這個(gè) cookie 就被用作序列號(hào)，來應(yīng)答 SYN+ACK 包，并釋放連接狀態(tài)。當(dāng)客戶端發(fā)送完三次握手的最后一次 ACK 后，服務(wù)器就會(huì)再次計(jì)算這個(gè)哈希值，確認(rèn)是上次返回的 SYN+ACK 的返回包，才會(huì)進(jìn)入 TCP 的連接狀態(tài)。因而，開啟 SYN Cookies 后，就不需要維護(hù)半開連接狀態(tài)了，進(jìn)而也就沒有了半連接數(shù)的限制。

注意，開啟 TCP syncookies 后，內(nèi)核選項(xiàng)
net.ipv4.tcp_max_syn_backlog 也就無效了。

通過下面的命令，開啟 TCP SYN Cookies：

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

注意，上述 sysctl 命令修改的配置都是臨時(shí)的，重啟后這些配置就會(huì)丟失。所以，為了保證配置持久化，你還應(yīng)該把這些配置，寫入 /etc/sysctl.conf 文件中。比如：

$cat/etc/sysctl.confnet.ipv4.tcp_syncookies=1net.ipv4.tcp_synack_retries=1net.ipv4.tcp_max_syn_backlog=2048

注意，寫入 /etc/sysctl.conf 的配置，需要執(zhí)行 sysctl -p 命令后，才會(huì)動(dòng)態(tài)生效。

案例結(jié)束后，執(zhí)行 docker rm -f nginx 命令，清理案例開始時(shí)啟動(dòng)的 Nginx 應(yīng)用。

DDoS 到底該怎么防御

實(shí)際上，當(dāng) DDoS 報(bào)文到達(dá)服務(wù)器后，Linux 提供的機(jī)制只能緩解，而無法徹底解決。即使像是 SYN Flood 這樣的小包攻擊，其巨大的 PPS ，也會(huì)導(dǎo)致 Linux 內(nèi)核消耗大量資源，進(jìn)而導(dǎo)致其他網(wǎng)絡(luò)報(bào)文的處理緩慢。

雖然可以調(diào)整內(nèi)核參數(shù)，緩解 DDoS 帶來的性能問題，卻也會(huì)像案例這樣，無法徹底解決它。

類此C10K，C10M問題，Linux 內(nèi)核中冗長的協(xié)議棧，在 PPS 很大時(shí)，就是一個(gè)巨大的負(fù)擔(dān)。對(duì) DDoS 攻擊來說，也是一樣的道理。

所以，當(dāng)時(shí)提到的 C10M 的方法，用到這里同樣適合。比如，你可以基于 XDP 或者 DPDK，構(gòu)建 DDoS 方案，在內(nèi)核網(wǎng)絡(luò)協(xié)議棧前，或者跳過內(nèi)核協(xié)議棧，來識(shí)別并丟棄 DDoS 報(bào)文，避免 DDoS 對(duì)系統(tǒng)其他資源的消耗。

不過，對(duì)于流量型的 DDoS 來說，當(dāng)服務(wù)器的帶寬被耗盡后，在服務(wù)器內(nèi)部處理就無能為力了。這時(shí)，只能在服務(wù)器外部的網(wǎng)絡(luò)設(shè)備中，設(shè)法識(shí)別并阻斷流量（當(dāng)然前提是網(wǎng)絡(luò)設(shè)備要能扛住流量攻擊）。比如，購置專業(yè)的入侵檢測(cè)和防御設(shè)備，配置流量清洗設(shè)備阻斷惡意流量等。

DDoS 并不一定是因?yàn)榇罅髁炕蛘叽?PPS，有時(shí)候，慢速的請(qǐng)求也會(huì)帶來巨大的性能下降（這種情況稱為慢速 DDoS）。

比如，很多針對(duì)應(yīng)用程序的攻擊，都會(huì)偽裝成正常用戶來請(qǐng)求資源。這種情況下，請(qǐng)求流量可能本身并不大，但響應(yīng)流量卻可能很大，并且應(yīng)用程序內(nèi)部也很可能要耗費(fèi)大量資源處理。

這時(shí)，就需要應(yīng)用程序考慮識(shí)別，并盡早拒絕掉這些惡意流量，比如合理利用緩存、增加 WAF（Web Application Firewall）、使用 CDN 等等。