DDoS攻擊原理及防護(hù)方法論
原創(chuàng)【51CTO.com獨(dú)家特稿】從07年的愛(ài)沙尼亞DDoS信息戰(zhàn),到今年廣西南寧30個(gè)網(wǎng)吧遭受到DDoS勒索,再到新浪網(wǎng)遭受DDoS攻擊無(wú)法提供對(duì)外服務(wù)500多分鐘。DDoS愈演愈烈,攻擊事件明顯增多,攻擊流量也明顯增大,形勢(shì)十分嚴(yán)峻,超過(guò)1G的攻擊流量頻頻出現(xiàn),CNCERT/CC掌握的數(shù)據(jù)表明,最高時(shí)達(dá)到了12G,這樣流量,甚至連專(zhuān)業(yè)的機(jī)房都無(wú)法抵擋。更為嚴(yán)峻的是:利用DDoS攻擊手段敲詐勒索已經(jīng)形成了一條完整的產(chǎn)業(yè)鏈!并且,攻擊者實(shí)施成本極低,在網(wǎng)上可以隨便搜索到一大堆攻擊腳本、工具工具,對(duì)攻擊者的技術(shù)要求也越來(lái)越低。相反的是,專(zhuān)業(yè)抗DDoS設(shè)備的價(jià)格十分昂貴,而且對(duì)于攻擊源的追查難度極大,防護(hù)成本遠(yuǎn)遠(yuǎn)大于攻擊成本。
本文將對(duì)DDoS攻擊的原理做一個(gè)剖析,并提供一些解決方法。
一. DDoS攻擊
什么是DDoS?DDoS是英文Distributed Denial of Service的縮寫(xiě),意即"分布式拒絕服務(wù)",DDoS的中文名叫分布式拒絕服務(wù)攻擊,俗稱(chēng)洪水攻擊。首先,我們來(lái)了解一下相關(guān)定義。
服務(wù):系統(tǒng)提供的,用戶(hù)在對(duì)其使用中會(huì)受益的功能
拒絕服務(wù):任何對(duì)服務(wù)的干涉如果使其可用性降低或者失去可用性均稱(chēng)為拒絕服務(wù)。
拒絕服務(wù)攻擊:是指攻擊者通過(guò)某種手段,有意地造成計(jì)算機(jī)或網(wǎng)絡(luò)不能正常運(yùn)轉(zhuǎn)從而不能向合法用戶(hù)提供所需要的服務(wù)或者使得服務(wù)質(zhì)量降低
分布式拒絕服務(wù)攻擊:處于不同位置的多個(gè)攻擊者同時(shí)向一個(gè)或者數(shù)個(gè)目標(biāo)發(fā)起攻擊,或者一個(gè)或多個(gè)攻擊者控制了位于不同位置的多臺(tái)機(jī)器并利用這些機(jī)器對(duì)受害者同時(shí)實(shí)施攻擊,由于攻擊的發(fā)出點(diǎn)是分布在不同地方的,這類(lèi)攻擊稱(chēng)為分布式拒絕服務(wù)攻擊。
![]() |
圖 |
如圖所示,DDoS攻擊將造成網(wǎng)絡(luò)資源浪費(fèi)、鏈路帶寬堵塞、服務(wù)器資源耗盡而業(yè)務(wù)中斷。這種攻擊大多數(shù)是由黑客非法控制的電腦實(shí)施的。黑客非法控制一些電腦之后,把這些電腦轉(zhuǎn)變?yōu)橛傻叵戮W(wǎng)絡(luò)遠(yuǎn)程控制的“bots”,然后用這些電腦實(shí)施DDoS攻擊。黑客還以每臺(tái)為單位,低價(jià)出租這些用于攻擊的電腦,真正擁有這些電腦的主人并不知道自己的計(jì)算機(jī)已經(jīng)被用來(lái)攻擊別人。由于有數(shù)百萬(wàn)臺(tái)電腦現(xiàn)在已經(jīng)被黑客變成了“bots”,因此這種攻擊將非常猛烈。被DDoS攻擊時(shí)的現(xiàn)象:
網(wǎng)絡(luò)中充斥著大量的無(wú)用的數(shù)據(jù)包;
制造高流量無(wú)用數(shù)據(jù),造成網(wǎng)絡(luò)擁塞,使受害主機(jī)無(wú)法正常和外界通訊;
利用受害主機(jī)提供的服務(wù)或傳輸協(xié)議上的缺陷,反復(fù)高速的發(fā)出特定的服務(wù)請(qǐng)求,使受害主機(jī)無(wú)法及時(shí)處理所有正常請(qǐng)求;
嚴(yán)重時(shí)會(huì)造成系統(tǒng)死機(jī)。
由于網(wǎng)絡(luò)層的拒絕服務(wù)攻擊有的利用了網(wǎng)絡(luò)協(xié)議的漏洞,有的則搶占網(wǎng)絡(luò)或者設(shè)備有限的處理能力,使得對(duì)拒絕服務(wù)攻擊的防治成為了一個(gè)令管理員非常頭痛的問(wèn)題。尤其是目前在大多數(shù)的網(wǎng)絡(luò)環(huán)境骨干線(xiàn)路上普遍使用的防火墻、負(fù)載均衡等設(shè)備,在發(fā)生DDoS攻擊的時(shí)候往往成為整個(gè)網(wǎng)絡(luò)的瓶頸,造成全網(wǎng)的癱瘓。#p#
二. 數(shù)據(jù)包結(jié)構(gòu)
要了解DDoS的攻擊原理,就要首先了解一下數(shù)據(jù)包的結(jié)構(gòu),才能知根知底,追本溯源。首先來(lái)回顧一下數(shù)據(jù)包的結(jié)構(gòu)。
2.1 IP報(bào)文結(jié)構(gòu)
![]() |
圖 |
2.2 TCP報(bào)文結(jié)構(gòu)
![]() |
圖 |
一個(gè)TCP報(bào)頭的標(biāo)識(shí)(code bits)字段包含6個(gè)標(biāo)志位:
SYN:標(biāo)志位用來(lái)建立連接,讓連接雙方同步序列號(hào)。如果SYN=1而ACK=0,則表示該數(shù)據(jù)包為連接請(qǐng)求,如果SYN=1而ACK=1則表示接受連接
FIN:表示發(fā)送端已經(jīng)沒(méi)有數(shù)據(jù)要求傳輸了,希望釋放連接。
RST:用來(lái)復(fù)位一個(gè)連接。RST標(biāo)志置位的數(shù)據(jù)包稱(chēng)為復(fù)位包。一般情況下,如果TCP收到的一個(gè)分段明顯不是屬于該主機(jī)上的任何一個(gè)連接,則向遠(yuǎn)端發(fā)送一個(gè)復(fù)位包。
URG:為緊急數(shù)據(jù)標(biāo)志。如果它為1,表示本數(shù)據(jù)包中包含緊急數(shù)據(jù)。此時(shí)緊急數(shù)據(jù)指針有效。
ACK:為確認(rèn)標(biāo)志位。如果為1,表示包中的確認(rèn)號(hào)時(shí)有效的。否則,包中的確認(rèn)號(hào)無(wú)效。
PSH:如果置位,接收端應(yīng)盡快把數(shù)據(jù)傳送給應(yīng)用層, 不必等緩沖區(qū)滿(mǎn)再發(fā)送 。
2.3 UDP報(bào)文結(jié)構(gòu)
![]() |
圖 |
2.4 ICMP報(bào)文結(jié)構(gòu)
![]() |
圖 |
![]() |
圖 |
#p#
三. DDoS攻擊方式
3.1 SYN Flood攻擊
SYN-Flood攻擊是當(dāng)前網(wǎng)絡(luò)上最為常見(jiàn)的DDoS攻擊,也是最為經(jīng)典的拒絕服務(wù)攻擊,它利用了TCP協(xié)議實(shí)現(xiàn)上的一個(gè)缺陷,通過(guò)向網(wǎng)絡(luò)服務(wù)所在端口發(fā)送大量的偽造源地址的攻擊報(bào)文,就可能造成目標(biāo)服務(wù)器中的半開(kāi)連接隊(duì)列被占滿(mǎn),從而阻止其他合法用戶(hù)進(jìn)行訪(fǎng)問(wèn)。這種攻擊早在1996年就被發(fā)現(xiàn),但至今仍然顯示出強(qiáng)大的生命力。很多操作系統(tǒng),甚至防火墻、路由器都無(wú)法有效地防御這種攻擊,而且由于它可以方便地偽造源地址,追查起來(lái)非常困難。它的數(shù)據(jù)包特征通常是,源發(fā)送了大量的SYN包,并且缺少三次握手的最后一步握手ACK回復(fù)。
3.1.1 原理
例如,攻擊者首先偽造地址對(duì)服務(wù)器發(fā)起SYN請(qǐng)求(我可以建立連接嗎?),服務(wù)器就會(huì)回應(yīng)一個(gè)ACK+SYN(可以+請(qǐng)確認(rèn))。而真實(shí)的IP會(huì)認(rèn)為,我沒(méi)有發(fā)送請(qǐng)求,不作回應(yīng)。服務(wù)器沒(méi)有收到回應(yīng),會(huì)重試3-5次并且等待一個(gè)SYN Time(一般30秒-2分鐘)后,丟棄這個(gè)連接。
如果攻擊者大量發(fā)送這種偽造源地址的SYN請(qǐng)求,服務(wù)器端將會(huì)消耗非常多的資源來(lái)處理這種半連接,保存遍歷會(huì)消耗非常多的CPU時(shí)間和內(nèi)存,何況還要不斷對(duì)這個(gè)列表中的IP進(jìn)行SYN+ACK的重試。最后的結(jié)果是服務(wù)器無(wú)暇理睬正常的連接請(qǐng)求—拒絕服務(wù)。在服務(wù)器上用netstat –an命令查看SYN_RECV狀態(tài)的話(huà),就可以看到:
![]() |
圖 |
如果我們抓包來(lái)看:
![]() |
圖 |
可以看到大量的SYN包沒(méi)有ACK回應(yīng)。
3.1.2 SYN Flood防護(hù)
目前市面上有些防火墻具有SYN Proxy功能,這種方法一般是定每秒通過(guò)指定對(duì)象(目標(biāo)地址和端口、僅目標(biāo)地址或僅源地址)的SYN片段數(shù)的閥值,當(dāng)來(lái)自相同源地址或發(fā)往相同目標(biāo)地址的SYN片段數(shù)達(dá)到這些閥值之一時(shí),防火墻就開(kāi)始截取連接請(qǐng)求和代理回復(fù)SYN/ACK片段,并將不完全的連接請(qǐng)求存儲(chǔ)到連接隊(duì)列中直到連接完成或請(qǐng)求超時(shí)。當(dāng)防火墻中代理連接的隊(duì)列被填滿(mǎn)時(shí),防火墻拒絕來(lái)自相同安全區(qū)域(zone)中所有地址的新SYN片段,避免網(wǎng)絡(luò)主機(jī)遭受不完整的三次握手的攻擊。但是,這種方法在攻擊流量較大的時(shí)候,連接出現(xiàn)較大的延遲,網(wǎng)絡(luò)的負(fù)載較高,很多情況下反而成為整個(gè)網(wǎng)絡(luò)的瓶頸;
Random Drop:隨機(jī)丟包的方式雖然可以減輕服務(wù)器的負(fù)載,但是正常連接的成功率也會(huì)降低很多;
特征匹配:IPS上會(huì)常用的手段,在攻擊發(fā)生的當(dāng)時(shí)統(tǒng)計(jì)攻擊報(bào)文的特征,定義特征庫(kù),例如過(guò)濾不帶TCP Options 的syn 包等;
早期攻擊工具(例如synkiller,xdos,hgod等)通常是發(fā)送64字節(jié)的TCP SYN報(bào)文,而主機(jī)操作系統(tǒng)在發(fā)起TCP連接請(qǐng)求時(shí)發(fā)送SYN 報(bào)文是大于64字節(jié)的。因此可以在關(guān)鍵節(jié)點(diǎn)上設(shè)置策略過(guò)濾64字節(jié)的TCP SYN報(bào)文,某些宣傳具有防護(hù)SYN Flood攻擊的產(chǎn)品就是這么做的。隨著工具的改進(jìn),發(fā)出的TCP SYN 報(bào)文完全模擬常見(jiàn)的通用操作系統(tǒng),并且IP頭和TCP頭的字段完全隨機(jī),這時(shí)就無(wú)法在設(shè)備上根據(jù)特定的規(guī)則來(lái)過(guò)濾攻擊報(bào)文。這時(shí)就需要根據(jù)經(jīng)驗(yàn)判斷IP 包頭里TTL值不合理的數(shù)據(jù)包并阻斷,但這種手工的方法成本高、效率低。 圖是某攻擊工具屬性設(shè)置。
![]() |
圖 |
SYN Cookie:就是給每一個(gè)請(qǐng)求連接的IP地址分配一個(gè)Cookie,如果短時(shí)間內(nèi)連續(xù)受到某個(gè)IP的重復(fù)SYN報(bào)文,就認(rèn)定是受到了攻擊,以后從這個(gè)IP地址來(lái)的包會(huì)被丟棄。但SYN Cookie依賴(lài)于對(duì)方使用真實(shí)的IP地址,如果攻擊者利用SOCK_RAW隨機(jī)改寫(xiě)IP報(bào)文中的源地址,這個(gè)方法就沒(méi)效果了。
3.1.3 商業(yè)產(chǎn)品的防護(hù)算法
syn cookie/syn proxy類(lèi)防護(hù)算法:這種算法對(duì)所有的syn包均主動(dòng)回應(yīng),探測(cè)發(fā)起syn包的源IP地址是否真實(shí)存在;如果該IP地址真實(shí)存在,則該IP會(huì)回應(yīng)防護(hù)設(shè)備的探測(cè)包,從而建立TCP連接;大多數(shù)的國(guó)內(nèi)外抗拒絕服務(wù)產(chǎn)品采用此類(lèi)算法。
safereset算法:此算法對(duì)所有的syn包均主動(dòng)回應(yīng),探測(cè)包特意構(gòu)造錯(cuò)誤的字段,真實(shí)存在的IP地址會(huì)發(fā)送rst包給防護(hù)設(shè)備,然后發(fā)起第2次連接,從而建立TCP連接;部分國(guó)外產(chǎn)品采用了這樣的防護(hù)算法。
syn重傳算法:該算法利用了TCP/IP協(xié)議的重傳特性,來(lái)自某個(gè)源IP的第一個(gè)syn包到達(dá)時(shí)被直接丟棄并記錄狀態(tài),在該源IP的第2個(gè)syn包到達(dá)時(shí)進(jìn)行驗(yàn)證,然后放行。
綜合防護(hù)算法:結(jié)合了以上算法的優(yōu)點(diǎn),并引入了IP信譽(yù)機(jī)制。當(dāng)來(lái)自某個(gè)源IP的第一個(gè)syn包到達(dá)時(shí),如果該IP的信譽(yù)值較高,則采用syncookie算法;而對(duì)于信譽(yù)值較低的源IP,則基于協(xié)議棧行為模式,如果syn包得到驗(yàn)證,則對(duì)該連接進(jìn)入syncookie校驗(yàn),一旦該IP的連接得到驗(yàn)證則提高其信譽(yù)值。有些設(shè)備還采用了表結(jié)構(gòu)來(lái)存放協(xié)議棧行為模式特征值,大大減少了存儲(chǔ)量。#p#
3.2 ACK Flood攻擊
3.2.1 原理
ACK Flood攻擊是在TCP連接建立之后,所有的數(shù)據(jù)傳輸TCP報(bào)文都是帶有ACK標(biāo)志位的,主機(jī)在接收到一個(gè)帶有ACK標(biāo)志位的數(shù)據(jù)包的時(shí)候,需要檢查該數(shù)據(jù)包所表示的連接四元組是否存在,如果存在則檢查該數(shù)據(jù)包所表示的狀態(tài)是否合法,然后再向應(yīng)用層傳遞該數(shù)據(jù)包。如果在檢查中發(fā)現(xiàn)該數(shù)據(jù)包不合法,例如該數(shù)據(jù)包所指向的目的端口在本機(jī)并未開(kāi)放,則主機(jī)操作系統(tǒng)協(xié)議棧會(huì)回應(yīng)RST包告訴對(duì)方此端口不存在。
這里,服務(wù)器要做兩個(gè)動(dòng)作:查表、回應(yīng)ACK/RST。這種攻擊方式顯然沒(méi)有SYN Flood給服務(wù)器帶來(lái)的沖擊大,因此攻擊者一定要用大流量ACK小包沖擊才會(huì)對(duì)服務(wù)器造成影響。按照我們對(duì)TCP協(xié)議的理解,隨機(jī)源IP的ACK小包應(yīng)該會(huì)被Server很快丟棄,因?yàn)樵诜?wù)器的TCP堆棧中沒(méi)有這些ACK包的狀態(tài)信息。但是實(shí)際上通過(guò)測(cè)試,發(fā)現(xiàn)有一些TCP服務(wù)會(huì)對(duì)ACK Flood比較敏感,比如說(shuō)JSP Server,在數(shù)量并不多的ACK小包的打擊下,JSP Server就很難處理正常的連接請(qǐng)求。對(duì)于A(yíng)pache或者IIS來(lái)說(shuō),10kpps的ACK Flood不構(gòu)成危脅,但是更高數(shù)量的ACK Flood會(huì)造成服務(wù)器網(wǎng)卡中斷頻率過(guò)高,負(fù)載過(guò)重而停止響應(yīng)??梢钥隙ǖ氖?,ACK Flood不但可以危害路由器等網(wǎng)絡(luò)設(shè)備,而且對(duì)服務(wù)器上的應(yīng)用有不小的影響。抓包:
![]() |
圖 |
如果沒(méi)有開(kāi)放端口,服務(wù)器將直接丟棄,這將會(huì)耗費(fèi)服務(wù)器的CPU資源。如果端口開(kāi)放,服務(wù)器回應(yīng)RST。
3.2.2 ACK Flood防護(hù)
利用對(duì)稱(chēng)性判斷來(lái)分析出是否有攻擊存在。所謂對(duì)稱(chēng)型判斷,就是收包異常大于發(fā)包,因?yàn)楣粽咄ǔ?huì)采用大量ACK包,并且為了提高攻擊速度,一般采用內(nèi)容基本一致的小包發(fā)送。這可以作為判斷是否發(fā)生ACK Flood的依據(jù),但是目前已知情況來(lái)看,很少有單純使用ACK Flood攻擊,都會(huì)和其他攻擊方法混合使用,因此,很容易產(chǎn)生誤判。
一些防火墻應(yīng)對(duì)的方法是:建立一個(gè)hash表,用來(lái)存放TCP連接“狀態(tài)”,相對(duì)于主機(jī)的TCP stack實(shí)現(xiàn)來(lái)說(shuō),狀態(tài)檢查的過(guò)程相對(duì)簡(jiǎn)化。例如,不作sequence number的檢查,不作包亂序的處理,只是統(tǒng)計(jì)一定時(shí)間內(nèi)是否有ACK包在該“連接”(即四元組)上通過(guò),從而“大致”確定該“連接”是否是“活動(dòng)的”。#p#
3.3 UDP Flood攻擊
3.3.1 原理
UDP Flood是日漸猖厥的流量型DoS攻擊,原理也很簡(jiǎn)單。常見(jiàn)的情況是利用大量UDP小包沖擊DNS服務(wù)器或Radius認(rèn)證服務(wù)器、流媒體視頻服務(wù)器。 100k pps的UDP Flood經(jīng)常將線(xiàn)路上的骨干設(shè)備例如防火墻打癱,造成整個(gè)網(wǎng)段的癱瘓。由于UDP協(xié)議是一種無(wú)連接的服務(wù),在UDP FLOOD攻擊中,攻擊者可發(fā)送大量偽造源IP地址的小UDP包。但是,由于UDP協(xié)議是無(wú)連接性的,所以只要開(kāi)了一個(gè)UDP的端口提供相關(guān)服務(wù)的話(huà),那么就可針對(duì)相關(guān)的服務(wù)進(jìn)行攻擊。
正常應(yīng)用情況下,UDP包雙向流量會(huì)基本相等,而且大小和內(nèi)容都是隨機(jī)的,變化很大。出現(xiàn)UDP Flood的情況下,針對(duì)同一目標(biāo)IP的UDP包在一側(cè)大量出現(xiàn),并且內(nèi)容和大小都比較固定。攻擊工具:
![]() |
圖 |
53端口的UDP Flood攻擊抓圖:
![]() |
圖 |
UDP Flood大包攻擊(占帶寬,分片):
![]() |
圖 |
3.3.2 UDP Flood防護(hù)
UDP協(xié)議與TCP 協(xié)議不同,是無(wú)連接狀態(tài)的協(xié)議,并且UDP應(yīng)用協(xié)議五花八門(mén),差異極大,因此針對(duì)UDP Flood的防護(hù)非常困難。其防護(hù)要根據(jù)具體情況對(duì)待:
判斷包大小,如果是大包攻擊則使用防止UDP碎片方法:根據(jù)攻擊包大小設(shè)定包碎片重組大小,通常不小于1500。在極端情況下,可以考慮丟棄所有UDP碎片。
攻擊端口為業(yè)務(wù)端口:根據(jù)該業(yè)務(wù)UDP最大包長(zhǎng)設(shè)置UDP最大包大小以過(guò)濾異常流量。
攻擊端口為非業(yè)務(wù)端口:一個(gè)是丟棄所有UDP包,可能會(huì)誤傷正常業(yè)務(wù);一個(gè)是建立UDP連接規(guī)則,要求所有去往該端口的UDP包,必須首先與TCP端口建立TCP連接。不過(guò)這種方法需要很專(zhuān)業(yè)的防火墻或其他防護(hù)設(shè)備支持。#p#
3.4 ICMP Flood攻擊
3.4.1 原理
ICMP Flood 的攻擊原理和ACK Flood原理類(lèi)似,屬于流量型的攻擊方式,也是利用大的流量給服務(wù)器帶來(lái)較大的負(fù)載,影響服務(wù)器的正常服務(wù)。由于目前很多防火墻直接過(guò)濾ICMP報(bào)文,因此ICMP Flood出現(xiàn)的頻度較低。比較下面兩幅圖,就應(yīng)該可以看出是否有ICMP Flood攻擊。
正常ICMP包:
![]() |
圖 |
大包攻擊的時(shí)候:
![]() |
圖 |
3.4.2 ICMP Flood防護(hù)
其防御也很簡(jiǎn)單,直接過(guò)濾ICMP報(bào)文。這里就不做詳細(xì)說(shuō)明。#p#
3.5 Connection Flood攻擊
3.5.1 原理
Connection Flood是典型的并且非常的有效的利用小流量沖擊大帶寬網(wǎng)絡(luò)服務(wù)的攻擊方式,這種攻擊方式目前已經(jīng)越來(lái)越猖獗。這種攻擊的原理是利用真實(shí)的IP地址向服務(wù)器發(fā)起大量的連接,并且建立連接之后很長(zhǎng)時(shí)間不釋放,占用服務(wù)器的資源,造成服務(wù)器服務(wù)器上殘余連接(WAIT狀態(tài))過(guò)多,效率降低,甚至資源耗盡,無(wú)法響應(yīng)其他客戶(hù)所發(fā)起的連接。
其中一種攻擊方法是每秒鐘向服務(wù)器發(fā)起大量的連接請(qǐng)求,這類(lèi)似于固定源IP的SYN Flood攻擊,不同的是采用了真實(shí)的源IP地址。通常這可以在防火墻上限制每個(gè)源IP地址每秒鐘的連接數(shù)來(lái)達(dá)到防護(hù)目的。但現(xiàn)在已有工具采用慢速連接的方式,也即幾秒鐘才和服務(wù)器建立一個(gè)連接,連接建立成功之后并不釋放并定時(shí)發(fā)送垃圾數(shù)據(jù)包給服務(wù)器使連接得以長(zhǎng)時(shí)間保持。這樣一個(gè)IP地址就可以和服務(wù)器建立成百上千的連接,而服務(wù)器可以承受的連接數(shù)是有限的,這就達(dá)到了拒絕服務(wù)的效果。
另外,蠕蟲(chóng)大規(guī)模爆發(fā)的時(shí)候,由于蠕蟲(chóng)代碼則比較簡(jiǎn)單,傳播過(guò)程中會(huì)出現(xiàn)大量源IP地址相同的包,對(duì)于 TCP 蠕蟲(chóng)則表現(xiàn)為大范圍掃描行為。這是在判斷Connection Flood時(shí)需要注意的。
在受攻擊的服務(wù)器上使用netstat –an來(lái)看:
![]() |
圖 |
存在大量連接狀態(tài),來(lái)自少數(shù)的幾個(gè)源。如果統(tǒng)計(jì)的話(huà),可以看到連接數(shù)對(duì)比平時(shí)出現(xiàn)異常。并且增長(zhǎng)到某一值之后開(kāi)始波動(dòng),說(shuō)明此時(shí)可能已經(jīng)接近性能極限。因此,對(duì)這種攻擊的判斷:在流量上體現(xiàn)并不大,甚至可能會(huì)很?。淮罅康腅STABLISH狀態(tài);新建的ESTABLISH狀態(tài)總數(shù)有波動(dòng)。
3.5.2 Connection Flood防護(hù)
主動(dòng)清除殘余連接。
對(duì)惡意連接的IP進(jìn)行封禁。
限制每個(gè)源IP的連接數(shù)。
可以對(duì)特定的URL進(jìn)行防護(hù)。
反查Proxy后面發(fā)起HTTP Get Flood的源。#p#
3.6 HTTP Get攻擊
3.6.1 原理
這種攻擊主要是針對(duì)存在A(yíng)SP、JSP、PHP、CGI等腳本程序,并調(diào)用MSSQLServer、MySQLServer、Oracle等數(shù)據(jù)庫(kù)的網(wǎng)站系統(tǒng)而設(shè)計(jì)的,特征是和服務(wù)器建立正常的TCP連接,并不斷的向腳本程序提交查詢(xún)、列表等大量耗費(fèi)數(shù)據(jù)庫(kù)資源的調(diào)用,典型的以小博大的攻擊方法。一般來(lái)說(shuō),提交一個(gè)GET或POST指令對(duì)客戶(hù)端的耗費(fèi)和帶寬的占用是幾乎可以忽略的,而服務(wù)器為處理此請(qǐng)求卻可能要從上萬(wàn)條記錄中去查出某個(gè)記錄,這種處理過(guò)程對(duì)資源的耗費(fèi)是很大的,常見(jiàn)的數(shù)據(jù)庫(kù)服務(wù)器很少能支持?jǐn)?shù)百個(gè)查詢(xún)指令同時(shí)執(zhí)行,而這對(duì)于客戶(hù)端來(lái)說(shuō)卻是輕而易舉的,因此攻擊者只需通過(guò)Proxy代理向主機(jī)服務(wù)器大量遞交查詢(xún)指令,只需數(shù)分鐘就會(huì)把服務(wù)器資源消耗掉而導(dǎo)致拒絕服務(wù),常見(jiàn)的現(xiàn)象就是網(wǎng)站慢如蝸牛、ASP程序失效、PHP連接數(shù)據(jù)庫(kù)失敗、數(shù)據(jù)庫(kù)主程序占用CPU偏高。這種攻擊的特點(diǎn)是可以完全繞過(guò)普通的防火墻防護(hù),輕松找一些Proxy代理就可實(shí)施攻擊,缺點(diǎn)是對(duì)付只有靜態(tài)頁(yè)面的網(wǎng)站效果會(huì)大打折扣,并且有些Proxy會(huì)暴露攻擊者的IP地址。攻擊工具:
![]() |
圖 |
在遭受攻擊的服務(wù)器上抓包,大量不同IP在請(qǐng)求資源。在實(shí)際情況中,也有可能使用代理地址連接。
![]() |
3.6.2 HTTP Get防護(hù)
對(duì)是否HTTP Get的判斷,要統(tǒng)計(jì)到達(dá)每個(gè)服務(wù)器的每秒鐘的GET 請(qǐng)求數(shù),如果遠(yuǎn)遠(yuǎn)超過(guò)正常值,就要對(duì)HTTP協(xié)議解碼,找出HTTP Get及其參數(shù)(例如URL等)。
然后判斷某個(gè)GET 請(qǐng)求是來(lái)自代理服務(wù)器還是惡意請(qǐng)求。并回應(yīng)一個(gè)帶key的響應(yīng)要求請(qǐng)求發(fā)起端作出相應(yīng)的回饋。如果發(fā)起端并不響應(yīng)則說(shuō)明是利用工具發(fā)起的請(qǐng)求,這樣HTTP Get請(qǐng)求就無(wú)法到達(dá)服務(wù)器,達(dá)到防護(hù)的效果。#p#
3.7 UDP DNS Query Flood攻擊
3.7.1 原理
UDP DNS Query Flood攻擊實(shí)質(zhì)上是UDP Flood的一種,但是由于DNS服務(wù)器的不可替代的關(guān)鍵作用,一旦服務(wù)器癱瘓,影響一般都很大。
UDP DNS Query Flood攻擊采用的方法是向被攻擊的服務(wù)器發(fā)送大量的域名解析請(qǐng)求,通常請(qǐng)求解析的域名是隨機(jī)生成或者是網(wǎng)絡(luò)世界上根本不存在的域名,被攻擊的DNS 服務(wù)器在接收到域名解析請(qǐng)求的時(shí)候首先會(huì)在服務(wù)器上查找是否有對(duì)應(yīng)的緩存,如果查找不到并且該域名無(wú)法直接由服務(wù)器解析的時(shí)候,DNS 服務(wù)器會(huì)向其上層DNS服務(wù)器遞歸查詢(xún)域名信息。域名解析的過(guò)程給服務(wù)器帶來(lái)了很大的負(fù)載,每秒鐘域名解析請(qǐng)求超過(guò)一定的數(shù)量就會(huì)造成DNS服務(wù)器解析域名超時(shí)。
根據(jù)微軟的統(tǒng)計(jì)數(shù)據(jù),一臺(tái)DNS服務(wù)器所能承受的動(dòng)態(tài)域名查詢(xún)的上限是每秒鐘9000個(gè)請(qǐng)求。而我們知道,在一臺(tái)P3的PC機(jī)上可以輕易地構(gòu)造出每秒鐘幾萬(wàn)個(gè)域名解析請(qǐng)求,足以使一臺(tái)硬件配置極高的DNS服務(wù)器癱瘓,由此可見(jiàn)DNS 服務(wù)器的脆弱性。同時(shí)需要注意的是,蠕蟲(chóng)擴(kuò)散也會(huì)帶來(lái)大量的域名解析請(qǐng)求。
3.7.2 UDP DNS Query Flood防護(hù)
在UDP Flood的基礎(chǔ)上對(duì) UDP DNS Query Flood 攻擊進(jìn)行防護(hù)
根據(jù)域名 IP 自學(xué)習(xí)結(jié)果主動(dòng)回應(yīng),減輕服務(wù)器負(fù)載(使用 DNS Cache)
對(duì)突然發(fā)起大量頻度較低的域名解析請(qǐng)求的源 IP 地址進(jìn)行帶寬限制 在攻擊發(fā)生時(shí)降低很少發(fā)起域名解析請(qǐng)求的源 IP 地址的優(yōu)先級(jí)
限制每個(gè)源 IP 地址每秒的域名解析請(qǐng)求次數(shù)
四. 總結(jié)
看完這篇文章,您已經(jīng)了解了7種主流的DDoS攻擊方式,并且也了解了相應(yīng)的解決方法。雖然道高一尺,魔高一丈,新的攻擊方法也在源源不斷出現(xiàn)。但是,只要您掌握了相應(yīng)的原理,破解DDoS攻擊并非難事,不過(guò)其前提是您在掌握原理的基礎(chǔ)上,還需要有相應(yīng)的軟件、硬件來(lái)對(duì)抗。本文的最后,給出幾個(gè)小題目,幫您回憶一下前面所說(shuō)的內(nèi)容。
1. 對(duì)上述方法的總結(jié)。
2. 如果您的主要業(yè)務(wù)是UDP音頻應(yīng)用,為了維護(hù)利益,盡可能降低攻擊對(duì)其業(yè)務(wù)的影響,您平時(shí)應(yīng)該如何關(guān)注?
3. 僵尸網(wǎng)絡(luò)是個(gè)無(wú)堅(jiān)不摧的矛嗎?如何緩解來(lái)自僵尸網(wǎng)絡(luò)的攻擊帶來(lái)的影響?如果一次ACK-Flood的攻擊流量是通過(guò)僵尸網(wǎng)絡(luò)發(fā)出來(lái)的,那么它通常會(huì)帶有什么特征。
【51CTO.COM 獨(dú)家特稿,轉(zhuǎn)載請(qǐng)注明出處及作者!】
【編輯推薦】