本節內容
一、TCP協議淺談
1、HTTP連接
HTTP(HyperText Transfer Protocol,超文本傳輸協議)是互聯網上應用最為廣泛的一種網絡協議,是用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議,所有的WWW文件都必須遵守這個標准。
HTTP協議是一個客戶端和服務器端請求和應答的標准,是建立在TCP協議之上的一種應用。
HTTP連接最顯著的特點是客戶端發送的每次請求都需要服務器回送響應,在請求結束后,會主動釋放連接。從建立連接到關閉連接的過程稱為“一次連接”。
- 在HTTP 1.0中,客戶端的每次請求都要求建立一次單獨的連接,在處理完本次請求后,就自動釋放連接。
- 在HTTP 1.1中則可以在一次連接中處理多個請求,並且多個請求可以重疊進行,不需要等待一個請求結束后再發送下一個請求。
由於HTTP在每次請求結束后都會主動釋放連接,因此HTTP連接是一種
短連接
,要保持客戶端程序的在線狀態,需要不斷地向服務器發起連接請求。通常的做法是即使不需要獲得任何數據,客戶端也保持每隔一段固定的時間向服務器發送一次
保持連接
的請求,服務器在收到該請求后對客戶端進行回復,表明知道客戶端
在線
。若服務器長時間無法收到客戶端的請求,則認為客戶端
,若客戶端長時間無法收到服務器的回復,則認為網絡已經斷開。
2、SOCKET原理
套接字(socket)是通信的基石,是支持TCP/IP協議的網絡通信的基本操作單元。它是網絡通信過程中端點的抽象表示,包含進行網絡通信必須的五種信息:
- 連接使用的協議
- 本地主機的IP地址
- 本地進程的協議端口
- 遠程主機的IP地址
- 遠程進程的協議端口
應用層通過傳輸層進行數據通信時,TCP會遇到同時為多個應用程序進程提供並發服務的問題。多個TCP連接或多個應用程序進程可能需要通過同一個TCP協議端口傳輸數據。為了區別不同的應用程序進程和連接,許多計算機操作系統為應用程序與TCP/IP協議交互提供了套接字(Socket)接口。應用層可以和傳輸層通過Socket接口,區分來自不同應用程序進程或網絡連接的通信,實現數據傳輸的並發服務。
3、TCP介紹
(1) TCP簡介
TCP(Transmission Control Protocol,傳輸控制協議)是一種面向連接的、可靠的、基於字節流的傳輸層通信協議,由IETF的RFC 793定義。在簡化的計算機網絡OSI(Open System Interconnection,開放式系統互聯)模型中,它完成第四層傳輸層所指定的功能,用戶數據報協議(UDP)是同一層內另一個重要的傳輸協議。在因特網協議族(Internet protocol suite)中,TCP層是位於IP層之上,應用層之下的中間層。不同主機的應用層之間經常需要可靠的、像管道一樣的連接,但是IP層不提供這樣的流機制,而是提供不可靠的包交換。
OSI七層模型:
我們需要知道TCP工作在網絡OSI的七層模型中的第四層——Transport層,IP在第三層——Network層,ARP在第二層——Data Link層。在第二層上的數據,我們把它叫Frame,在第三層上的數據叫Packet,第四層的數據叫Segment。同時,我們需要簡單的知道,數據從應用層發下來,會在每一層都會加上頭部信息,進行封裝,然后再發送到數據接收端。這個基本的流程你需要知道,就是每個數據都會經過數據的封裝和解封裝的過程。OSI七層模型中,每一層的作用和對應的協議如下:
TCP/IP四層、五層模型與OSI七層協議模型:
(2) TCP報文段的首部格式
上圖就是TCP協議頭部的格式,其每個字段的詳細說明如下:
- Source Port和Destination Port:分別占用16位,表示源端口號和目的端口號,用於區別主機中的不同進程,而IP地址是用來區分不同的主機的。源端口號和目的端口號配合上IP首部中的源IP地址和目的IP地址就能唯一的確定一個TCP連接。
- Sequence Number(序號):用來標識從TCP發端向TCP收端發送的數據字節流,它表示在這個報文段中的的第一個數據字節在數據流中的序號,主要用來解決網絡報亂序的問題。
- Acknowledgment Number(確認號):32位確認序列號包含發送確認的一端所期望收到的下一個序號,因此確認序號應當是上次已成功收到數據字節序號加1。不過,只有當標志位中的ACK標志(下面介紹)為1時該確認序列號的字段才有效。主要用來解決丟包的問題
- Offset(數據偏移):給出首部中32 bit字的數目,需要這個值是因為任選字段的長度是可變的。這個字段占4bit(最多能表示15個32bit的的字,即4*15=60個字節的首部長度),因此TCP最多有60字節的首部。然而,沒有任選字段,正常的長度是20字節。
- TCP Flags:TCP首部中有6個標志比特,它們中的多個可同時被設置為1,主要是用於操控TCP的狀態機的,依次為URG,ACK,PSH,RST,SYN,FIN。
- Window:窗口大小,也就是有名的滑動窗口,用來進行流量控制。
TCP Flags每個標志位的解釋:
- URG:表示TCP包的緊急指針域(后面馬上就要說到)有效,用來保證TCP連接不被中斷,並且督促中間層設備要盡快處理這些數據。
- ACK:表示應答域有效,就是說前面所說的TCP應答號將會包含在TCP數據包中;有兩個取值:0和1,為1的時候表示應答域有效,反之為0。
- PSH:表示Push操作。所謂Push操作就是指在數據包到達接收端以后,立即傳送給應用程序,而不是在緩沖區中排隊。
- RST:表示連接復位請求。用來復位那些產生錯誤的連接,也被用來拒絕錯誤和非法的數據包。
- SYN:表示同步序號,用來建立連接。SYN標志位和ACK標志位搭配使用,當客戶端請求連接時,SYN=1,ACK=0;連接被服務端響應的時候,SYN=1,ACK=1。這個標志的數據包經常被用來進行端口掃描,掃描者發送一個只有SYN的數據包,如果對方主機響應了一個數據包回來 ,就表明這台主機存在這個端口。但是由於這種掃描方式只是進行TCP三次握手的第一次握手,因此這種掃描的成功表示被掃描的機器不很安全,一台安全的主機將會強制要求一個連接嚴格的進行TCP的三次握手。
- FIN:表示發送端已經達到數據末尾,也就是說雙方的數據傳送完成,沒有數據可以傳送了,發送FIN標志位的TCP數據包后,連接將被斷開。這個標志的數據包也經常被用於進行端口掃描。
4、TCP連接的三次握手與四次揮手
(1) 介紹
根據3中介紹我們可以得到三個重要的標志位:
- ACK : TCP協議規定,只有ACK=1時有效,也規定連接建立后所有發送的報文的ACK必須為1。
- SYN(SYNchronization): 在連接建立時用來同步序號。當SYN=1而ACK=0時,表明這是一個連接請求報文。對方若同意建立連接,則應在響應報文中使SYN=1和ACK=1. 因此, SYN置1就表示這是一個連接請求或連接接受報文。
- FIN(finis):用來釋放一個連接。當FIN = 1時,表明此報文段的發送方的數據已經發送完畢,並要求釋放連接。
TCP狀態轉換圖:
TCP連接過程圖:
名詞解釋:
1) 三次握手
三次握手過程說明如下:
- 第一次握手:建立連接。客戶端發送連接請求報文段,將SYN位置為1,Sequence Number為x。然后,客戶端進入
SYN_SEND
狀態,等待服務器的確認。 - 第二次握手:服務器收到SYN報文段。服務器收到客戶端的SYN報文段,需要對這個SYN報文段進行確認,設置Acknowledgment Number為x+1(Sequence Number+1)。同時,自己自己還要發送SYN請求信息,將SYN位置為1,Sequence Number為y;服務器端將上述所有信息放到一個報文段(即SYN+ACK報文段)中,一並發送給客戶端,此時服務器進入
SYN_RECV
狀態。 - 第三次握手:客戶端收到服務器的SYN+ACK報文段。然后將Acknowledgment Number設置為y+1,向服務器發送ACK報文段,這個報文段發送完畢以后,客戶端和服務器端都進入
ESTABLISHED
狀態,完成TCP三次握手。
2) 四次揮手
完成了三次握手,客戶端和服務器端就可以開始傳送數據。當數據傳送完畢,就需要斷開TCP連接,斷開連接的四次揮手過程說明如下:
- 第一次揮手:主機1(可以是客戶端,也可以是服務器端)設置Sequence Number和Acknowledgment Number,向主機2發送一個FIN報文段。此時,主機1進入
FIN_WAIT_1
狀態,這表示主機1沒有數據要發送給主機2了。 - 第二次揮手:主機2收到了主機1發送的FIN報文段,向主機1回一個ACK報文段,Acknowledgment Number為Sequence Number加1,主機1進入
FIN_WAIT_2
狀態。主機2告訴主機1,我同意你的關閉連接請求,主機2進入CLOSE_WAIT
狀態。 - 第三次揮手:主機2在確認沒有要向主機1發送的信息后,向主機1發送FIN報文段,請求關閉連接,此時主機2進入
LAST_ACK
狀態。 - 第四次揮手:主機1收到主機2發送的FIN報文段,向主機2發送ACK報文段,然后主機1進入
TIME_WAIT
狀態。主機2收到主機1的ACK報文段以后,就關閉連接。此時,主機1等待2MSL后依然沒有收到回復,則證明主機2已正常關閉。那好,主機1也可以關閉連接了。
2MSL是什么?MSL(Maximum Segment Lifetime)即報文最大生存時間,RFC 793中規定MSL為2分鍾,實際應用中常用的是30秒、1分鍾和2分鍾等。2MSL即兩倍的MSL。
TCP的TIME_WAIT狀態也稱為2MSL等待狀態,當TCP的一端發起主動關閉,在發出最后一個ACK包后,即第3次握手完成后發送了第四次握手的ACK包后就進入了TIME_WAIT狀態,必須在此狀態上停留兩倍的MSL時間,等待2MSL時間主要目的是怕最后一個ACK包對方沒收到,那么對方在超時后將重發第三次握手的FIN包,主動關閉端接到重發的FIN包后可以再發一個ACK應答包。在TIME_WAIT狀態時兩端的端口不能使用,要等到2MSL時間結束才可繼續使用。當連接處於2MSL等待階段時任何遲到的報文段都將被丟棄。不過在實際應用中可以通過設置SO_REUSEADDR選項達到不必等待2MSL時間結束再使用此端口。
(2) 作用
1) 為什么要三次握手
在謝希仁著《計算機網絡》第四版中講“三次握手”的目的是“為了防止已失效的連接請求報文段突然又傳送到了服務端,因而產生錯誤”。在另一部經典的《計算機網絡》一書中講“三次握手”的目的是為了解決“網絡中存在延遲的重復分組”的問題。在謝希仁著《計算機網絡》書中同時舉了一個例子,如下圖:
簡單的來說就是為了防止服務器一直等待其實已經失效的連接,造成資源的浪費。
2) 為什么要四次揮手
TCP協議是一種面向連接的、可靠的、基於字節流的運輸層通信協議。TCP是全雙工模式,這就意味着,當主機1發出FIN報文段時,只是表示主機1已經沒有數據要發送了,主機1告訴主機2,它的數據已經全部發送完畢了;但是,這個時候主機1還是可以接受來自主機2的數據;當主機2返回ACK報文段時,表示它已經知道主機1沒有數據發送了,但是主機2還是可以發送數據到主機1的;當主機2也發送了FIN報文段時,這個時候就表示主機2也沒有數據要發送了,就會告訴主機1,我也沒有數據要發送了,之后彼此就會愉快的中斷這次TCP連接。
四次揮手中狀態變化:
- FIN_WAIT_1: FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。當TCP連接在ESTABLISHED狀態時,想主動關閉連接的一方(在這里稱其為A)向對方(在這里稱其為B)發送了FIN報文,此時A進入到FIN_WAIT_1狀態。而當B回應ACK報文后,A則進入到FIN_WAIT_2狀態。當然在實際的正常情況下,無論對方何種情況下,都應該馬上回應ACK報文,所以FIN_WAIT_1狀態一般是比較難見到的,而FIN_WAIT_2狀態還有時常常可以用netstat命令看到。
- FIN_WAIT_2:上面已經詳細解釋了這種狀態,實際上FIN_WAIT_2狀態下的TCP連接表示半連接,即有一方要求close連接,另外還告訴對方,我暫時還有點數據需要傳送給你(ACK信息),稍后再關閉連接。
- CLOSE_WAIT:這種狀態的含義其實是表示在等待關閉。當A(主動關閉連接的一方)發送FIN報文給B時,B會回應一個ACK報文給A(B確認收到了A關閉連接請求),此時B進入到CLOSE_WAIT狀態。CLOSE_WAIT狀態下B察看是否還有數據要發送給A,如果沒有的話,那么B發送FIN報文給A,表示我沒有數據要發送了,可以關閉連接。
- LAST_ACK:B(被動關閉連接一方)在發送FIN報文后,最后等待A的ACK報文(A確認收到了B的關閉連接請求)。當收到ACK報文后,也即可以進入到CLOSED可用狀態了。
- TIME_WAIT:A(主動關閉連接的一方)收到了B的FIN報文,並發送出了ACK報文,等2MSL后即可回到CLOSED可用狀態了。如果A在FINWAIT1狀態下,收到了B同時帶FIN標志和ACK標志的報文時,可以直接進入到TIME_WAIT狀態,而無須經過FIN_WAIT_2狀態。
- CLOSED::表示連接斷開。
二、DDOS
1、什么是DDOS
DoS(Denial of Service,拒絕服務),造成DoS的攻擊行為被稱為DoS攻擊,其目的是使計算機或網絡無法提供正常的服務。最常見的DoS攻擊有計算機網絡帶寬攻擊和連通性攻擊。
DDoS(Distributed Denial of Service,分布式拒絕服務),指借助於客戶/服務器技術,將多個計算機聯合起來作為攻擊平台,對一個或多個目標發動DDoS攻擊,從而成倍地提高拒絕服務攻擊的威力。通常,攻擊者使用一個偷竊帳號將DDoS主控程序安裝在一個計算機上,在一個設定的時間主控程序將與大量代理程序通訊,代理程序已經被安裝在網絡上的許多計算機上。代理程序收到指令時就發動攻擊。利用客戶/服務器技術,主控程序能在幾秒鍾內激活成百上千次代理程序的運行。
DRDoS(Distributed Reflection Denial of Service,分布反射式拒絕服務)是DDoS攻擊的變形。
2、攻擊原理
(1) 各種攻擊的原理
DoS攻擊、DDoS攻擊和DRDoS攻擊都是利用TCP三次握手的漏洞進行攻擊的。
1) SYN攻擊
SYN攻擊是當前網絡上最為常見DDos攻擊,也是最為經典的拒絕服務攻擊,它利用了TCP協議實現上的一個缺陷,通過向網絡服務所在端口發送大量的偽造源地址的攻擊報文,就可能造成目標服務器中的半開連接隊列被占滿,從而阻止其它合法用戶進行訪問。這種攻擊早在1996年就被發現,但至今仍然顯示出強大的生命力。很多操作系統,甚至防火牆、路由器都無法有效地防御這種攻擊,而且由於它可以方便地偽造源地址,追查起來非常困難。它的數據包特征通常是,源發送了大量的SYN包,並且缺少三次握手的最后一步握手ACK回復。
DDoS攻擊它的原理說白了就是群毆,用好多的機器對目標機器一起發動DoS攻擊,但這不是很多黑客一起參與的,這種攻擊只是由一名黑客來操作的。這名黑客不是擁有很多機器,他是通過他的機器在網絡上占領很多的"肉雞",並且控制這些"肉雞"來發動DDoS攻擊,要不然怎么叫做分布式呢。還是剛才的那個例子,你的機器每秒能發送10個攻擊數據包,而被攻擊的機器每秒能夠接受100的數據包,這樣你的攻擊肯定不會起作用,而你再用10台或更多的機器來對被攻擊目標的機器進行攻擊的話,那結果就可想而知了。
2) DRDoS攻擊
在介紹DRDoS攻擊之前,我們先來了解下Smurf攻擊。Smurf攻擊的作用原理是基於廣播地址與回應請求的。一台計算機向另一台計算機發送一些特殊的數據包如ping請求時,會接到它的回應;如果向本網絡的廣播地址發送請求包,實際上會到達網絡上所有的計算機,這時就會得到所有計算機的回應。這些回應是需要被接收的計算機處理的,每處理一個就要占用一份系統資源,如果同時接到網絡上所有計算機的回應,接收方的系統是有可能吃不消的,就象遭到了DDoS攻擊一樣。不過是沒有人笨到自己攻擊自己,不過這種方法被黑客加以改進就具有很大的威力了。黑客向廣播地址發送請求包,所有的計算機得到請求后,卻不會把回應發到黑客那里,而是發到被攻擊主機。這是因為黑客冒充了被攻擊主機。黑客發送請求包所用的軟件是可以偽造源地址的,接到偽造數據包的主機會根據源地址把回應發出去,這當然就是被攻擊主機的地址。黑客同時還會把發送請求包的時間間隔減小,這樣在短時間能發出大量的請求包,使被攻擊主機接到從被欺騙計算機那里傳來的洪水般的回應,就像遭到了DDoS攻擊導致系統崩潰。黑客借助了網絡中所有計算機來攻擊受害者,而不需要事先去占領這些被欺騙的主機,這就是Smurf攻擊。
DRDoS分布反射式拒絕服務攻擊這是DDoS攻擊的變形,它與DDoS的不同之處就是DrDoS不需要在攻擊之前占領大量的"肉雞"。它的攻擊原理和Smurf攻擊原理相近,不過DRDoS是可以在廣域網上進行的,而Smurf攻擊是在局域網進行的。DRDoS攻擊利用與Smurf攻擊原理,黑客同樣利用特殊的發包工具,首先把偽造了源地址的SYN連接請求包發送到那些被欺騙的計算機上,根據TCP三次握手的規則,這些計算機會向源IP發出SYN+ACK或RST包來響應這個請求。同Smurf攻擊一樣,黑客所發送的請求包的源IP地址是被攻擊主機的地址,這樣受欺騙的主機就都會把回應發到被攻擊主機處,造成被攻擊主機忙於處理這些回應而癱瘓。
(2) DDoS如何攻擊
目前最流行也是最好用的攻擊方法就是使用SYN-Flood進行攻擊,
SYN-Flood
也就是
SYN洪水攻擊
。SYN-Flood不會完成TCP三次握手的第三步,也就是不發送確認連接的信息給服務器。這樣,服務器無法完成第三次握手,但服務器不會立即放棄,服務器會不停的重試並等待一定的時間后放棄這個未完成的連接,這段時間叫做
SYN timeout
,這段時間大約
30秒-2分鍾
左右。若是一個用戶在連接時出現問題導致服務器的一個線程等待1分鍾並不是什么大不了的問題,但是若有人用特殊的軟件大量模擬這種情況,那后果就可想而知了。一個服務器若是處理這些大量的半連接信息而消耗大量的系統資源和網絡帶寬,這樣服務器就不會再有空余去處理普通用戶的正常請求(因為客戶的正常請求比率很小)。這樣這個服務器就無法工作了,這種攻擊就叫做SYN-Flood攻擊。
使用netstat命令可以看到有大量處於
SYN_RECV
狀態的TCP連接:
[root@s35 ~]# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' LAST_ACK 5 SYN_RECV 3000 ESTABLISHED 1597 FIN_WAIT1 51 FIN_WAIT2 504 TIME_WAIT 1057
3、防護方法
到目前為止,進行DDoS攻擊的防御還是比較困難的。首先,這種攻擊的特點是它利用了TCP/IP協議的漏洞,除非你不用TCP/IP,才有可能完全抵御住DDoS攻擊。不過這不等於我們就沒有辦法阻擋DDoS攻擊,我們可以盡力來減少DDoS的攻擊。下面就是一些防御方法:
1. 及早發現系統存在的攻擊漏洞,及時安裝系統補丁程序。對一些重要的信息(例如系統配置信息)建立和完善備份機制。對一些特權賬號(例如管理員賬號)的密碼設置要謹慎。通過這樣一系列的舉措可以把攻擊者的可乘之機降低到最小。
2. 在網絡管理方面,要經常檢查系統的物理環境,禁止那些不必要的網絡服務和端口。建立邊界安全界限,確保輸出的包受到正確限制。經常檢測系統配置信息,並注意查看每天的安全日志(網絡設備和主機/服務器)。
3. 利用網絡安全設備(例如:防火牆)來加固網絡的安全性,配置好這些設備的安全規則,過濾掉所有可能的偽造數據包。
- 禁止對主機的非開放服務的訪問
- 限制特定IP地址的訪問
- 啟用防火牆的防DDoS的屬性
- 嚴格限制對外開放的服務器的向外訪問
- 運行端口映射程序禍端口掃描程序,要認真檢查特權端口和非特權端口
4. 限制同時打開的SYN半連接數目。
5. 縮短SYN半連接的time out 時間。
6. 與網絡服務提供商協調工作,讓網絡服務提供商幫助實現路由的訪問控制和對帶寬總量的限制。
7. 建立抗DDoS攻擊盾機,當用戶發現自己正在遭受DDoS攻擊時,將攻擊導向盾機。
8. 當用戶發現自己正在遭受DDoS攻擊時,應當啟動自己的應對策略,盡可能快地追蹤攻擊包,並且及時聯系ISP和有關應急組織,分析受影響的系統,確定涉及的其他節點,從而阻擋從已知攻擊節點的流量。
9. 如果用戶是潛在的DDoS攻擊受害者,並且用戶發現自己的計算機被攻擊者用作主控端和代理端時,用戶不能因為自己的系統暫時沒有受到損害而掉以輕心。攻擊者一旦發現用戶系統的漏洞,這對用戶的系統是一個很大的威脅。所以用戶只要發現系統中存在DDoS攻擊的工具軟件要及時把它清除,以免留下后患。
4、其他攻擊方式了解
(1) ACK Flood攻擊
ACK Flood攻擊是在TCP連接建立之后,所有的數據傳輸TCP報文都是帶有ACK標志位的,主機在接收到一個帶有ACK標志位的數據包的時候,需要檢查該數據包所表示的連接四元組是否存在,如果存在則檢查該數據包所表示的狀態是否合法,然后再向應用層傳遞該數據包。如果在檢查中發現該數據包不合法,例如該數據包所指向的目的端口在本機並未開放,則主機操作系統協議棧會回應RST包告訴對方此端口不存在。
(2) UDP Flood攻擊
UDP Flood是日漸猖厥的流量型DoS攻擊,原理也很簡單。常見的情況是利用大量UDP小包沖擊DNS服務器或Radius認證服務器、流媒體視頻服務器。 100k pps的UDP Flood經常將線路上的骨干設備例如防火牆打癱,造成整個網段的癱瘓。由於UDP協議是一種無連接的服務,在UDP FLOOD攻擊中,攻擊者可發送大量偽造源IP地址的小UDP包。但是,由於UDP協議是無連接性的,所以只要開了一個UDP的端口提供相關服務的話,那么就可針對相關的服務進行攻擊。
(3) ICMP Flood攻擊
ICMP Flood 的攻擊原理和ACK Flood原理類似,屬於流量型的攻擊方式,也是利用大的流量給服務器帶來較大的負載,影響服務器的正常服務。由於目前很多防火牆直接過濾ICMP報文,因此ICMP Flood出現的頻度較低
(4) Connection Flood攻擊
Connection Flood是典型的並且非常有效的利用小流量沖擊大帶寬網絡服務的攻擊方式,,這種攻擊方式目前已經越來越猖獗。這種攻擊的原理是利用真實的IP地址向服務器發起大量的連接,並且建立連接之后很長時間不釋放,占用服務器的資源,造成服務器服務器上殘余連接(WAIT狀態)過多,效率降低,甚至資源耗盡,無法響應其他客戶所發起的連接。
其中一種攻擊方法是每秒鍾向服務器發起大量的連接請求,這類似於固定源IP的SYN Flood攻擊,不同的是采用了真實的源IP地址。通常這可以在防火牆上限制每個源IP地址每秒鍾的連接數來達到防護目的。但現在已有工具采用慢速連接的方式,也即幾秒鍾才和服務器建立一個連接,連接建立成功之后並不釋放並定時發送垃圾數據包給服務器使連接得以長時間保持。這樣一個IP地址就可以和服務器建立成百上千的連接,而服務器可以承受的連接數是有限的,這就達到了拒絕服務的效果。
(5) HTTP Get攻擊
用MSSQLServer、MySQLServer、Oracle等數據庫的網站系統而設計的,特征是和服務器建立正常的TCP連接,並不斷的向腳本程序提交查詢、列表等大量耗費數據庫資源的調用,典型的以小博大的攻擊方法。一般來說,提交一個GET或POST指令對客戶端的耗費和帶寬的占用是幾乎可以忽略的,而服務器為處理此請求卻可能要從上萬條記錄中去查出某個記錄,這種處理過程對資源的耗費是很大的,常見的數據庫服務器很少能支持數百個查詢指令同時執行,而這對於客戶端來說卻是輕而易舉的,因此攻擊者只需通過Proxy代理向主機服務器大量遞交查詢指令,只需數分鍾就會把服務器資源消耗掉而導致拒絕服務,常見的現象就是網站慢如蝸牛、ASP程序失效、PHP連接數據庫失敗、數據庫主程序占用CPU偏高。這種攻擊的特點是可以完全繞過普通的防火牆防護,輕松找一些Proxy代理就可實施攻擊,缺點是對付只有靜態頁面的網站效果會大打折扣,並且有些Proxy會暴露攻擊者的IP地址。
(6) UDP DNS Query Flood攻擊
UDP DNS Query Flood攻擊采用的方法是向被攻擊的服務器發送大量的域名解析請求,通常請求解析的域名是隨機生成或者是網絡世界上根本不存在的域名,被攻擊的DNS 服務器在接收到域名解析請求的時候首先會在服務器上查找是否有對應的緩存,如果查找不到並且該域名無法直接由服務器解析的時候,DNS 服務器會向其上層DNS服務器遞歸查詢域名信息。域名解析的過程給服務器帶來了很大的負載,每秒鍾域名解析請求超過一定的數量就會造成DNS服務器解析域名超時。
根據微軟的統計數據,一台DNS服務器所能承受的動態域名查詢的上限是每秒鍾9000個請求。而我們知道,在一台P3的PC機上可以輕易地構造出每秒鍾幾萬個域名解析請求,足以使一台硬件配置極高的DNS服務器癱瘓,由此可見DNS 服務器的脆弱性。同時需要注意的是,蠕蟲擴散也會帶來大量的域名解析請求。
參考:
http://www.cnblogs.com/ziqian9206/p/7159044.html
http://netsecurity.51cto.com/art/201710/553893.htm