11避免拒絕服務(wù)攻擊-文庫(kù)吧資料
2025-03-02 23:40本頁(yè)面
【正文】 攻擊為例，一般情況 下，可以一些簡(jiǎn)單步驟來(lái)判斷系統(tǒng)是否正在遭受 TCP SYN Flood 攻擊，如： 1：由正?？蛻舳藞?bào)告，發(fā)現(xiàn)服務(wù)端無(wú)法提供正常的 TCP 服務(wù)，連接請(qǐng)求經(jīng)常被 拒絕或超時(shí)。 如果客戶端攻擊者的 IP 地址經(jīng)過(guò)偽造，這種方法就不奏效了。該方法中，當(dāng)有一 個(gè)請(qǐng)求到達(dá)時(shí)，給該請(qǐng)求連接的 IP 地址分配一個(gè) Cookie，如果在短時(shí)間之內(nèi)，該 IP 地址重復(fù)發(fā)送 SYN 報(bào)文，就可以認(rèn)為該 IP 地址是一個(gè)攻擊者，將其加入到黑名單， 凡是被加入到黑名單中的 IP 地址，傳送的數(shù)據(jù)包直接被丟棄。但是，該方法僅在對(duì)方攻擊頻度不高的情況下生效， 2：設(shè)置黑名單。因此，如果將 SYN Timeout 時(shí)間縮短，就有可能讓某些連接在短時(shí)間之內(nèi)被放棄，可以降低服務(wù)器負(fù)擔(dān)。 從開(kāi)發(fā)角度講，要防御此種攻擊，有幾種簡(jiǎn)單的解決方法： 1：縮短 SYN Timeout 時(shí)間。 SYN Flood 攻擊中，攻擊者就是大量模擬了這種情況，此時(shí)，服務(wù)器在短時(shí)間內(nèi) 必須消耗資源來(lái)維護(hù)一個(gè)很大的未完成的連接的集合，并且還要對(duì)這個(gè)集合不斷進(jìn)行 遍歷和檢查，會(huì)消耗非常多的 CPU 時(shí)間和內(nèi)存；此外，服務(wù)器還要不斷對(duì)各個(gè)客戶 端發(fā)出 SYN+ACK 報(bào)文進(jìn)行重試，當(dāng)攻擊足夠兇猛時(shí)，服務(wù)器的 TCP/IP 棧如果不夠 強(qiáng)大就會(huì)造成崩潰；即使沒(méi)有崩潰，服務(wù)器也會(huì)忙于處理這些偽造的請(qǐng)求，當(dāng)客戶的 正常請(qǐng)求到達(dá)時(shí)，它也難以處理。 攻擊者就是利用這個(gè)缺陷，可以對(duì)服務(wù)器進(jìn)行攻擊。 但是此時(shí)，由于客戶端停電了，客戶端就無(wú)法執(zhí)行第三步，也就是說(shuō)服務(wù)器端無(wú)法收到客戶端的 ACK 報(bào)文 (第三次握手無(wú)法完成 )，怎么處理？ TCP 協(xié)議中，這種情況下服務(wù)器端一般再次發(fā)送 SYN+ACK 給客戶端，經(jīng)過(guò)一 段時(shí)間，如果還是沒(méi)有響應(yīng)，則將該連接視為無(wú)效的連接，并且丟棄；通俗地說(shuō)，就是服務(wù)器等待，超過(guò)一定時(shí)間，放棄連接。其中，建立 TCP連接的過(guò)程在 TCP協(xié)議中被稱為三次握手 (Threeway Handshake)，其過(guò)程如圖所示： 該圖中， HOSTA向 HOSTB發(fā)出鏈接請(qǐng)求，可以認(rèn)為 HOSTA為客戶端，HOSTB為服務(wù)器端，其流程如下： 1：客戶端向服務(wù)器端發(fā)送一個(gè) TCP報(bào)文 (同步報(bào)文或稱 SYN報(bào)文 )，該報(bào)文包含 SYN(同步 )標(biāo)志， SYN報(bào)文中同時(shí)指明了客戶端使用的端口以及TCP連接的初始序號(hào) (seq=x)； 2：服務(wù)器端在收到客戶端的 SYN報(bào)文后，將返回一個(gè) SYN(同步 )+ACK(確認(rèn) )標(biāo)志的報(bào)文給客戶端，表示客戶端的請(qǐng)求被服務(wù)器端接受；從圖中可以看出，此處 seq=y， ACK=x+1； 3：客戶端收到服務(wù)器端的 SYN(同步 )+ACK(確認(rèn) )標(biāo)志的報(bào)文之后，也返回一個(gè)含有 ACK標(biāo)志 (ack=y+1)的報(bào)文給服務(wù)器端，到此一個(gè) TCP連接完成。在該攻擊方法中，利用了 TCP協(xié)議缺陷，向服務(wù)器端發(fā)送大量的 TCP連接請(qǐng)求，而這些連接請(qǐng)求是偽造的，從而使得被攻擊方資源耗盡 (CPU滿負(fù)荷或內(nèi)存不足 )。本節(jié)以 SYN Flood為例，來(lái)說(shuō)明這種攻擊的原理和解決方法。 //數(shù)據(jù)檢查 bool ReassemblePackets(含有多個(gè) _iphdr的集合 ) { //Step1:獲取最后一個(gè)包，找到其偏移量 //Step2:獲得該包的長(zhǎng)度 //Step3:用偏移量加上該包長(zhǎng)度，看是否大于 65535 //Step4:決定該包是否被丟棄 } 資源不足攻擊 資源不足攻擊，顧名思義，是指攻擊者能夠消耗特定的資源，使得系統(tǒng)資源不足。 怎樣避免這樣的問(wèn)題？很明顯，應(yīng)該在編程的過(guò)程中進(jìn)行充足的考慮(比如在數(shù)據(jù)組裝時(shí)進(jìn)行充分的檢查 )，并且認(rèn)真進(jìn)行測(cè)試，使得數(shù)據(jù)包的長(zhǎng)度在 65535之內(nèi)。 這樣就可能出現(xiàn)一個(gè)問(wèn)題：在整個(gè)數(shù)據(jù)包所包含的最后一個(gè)字節(jié)處，最后一個(gè)數(shù)據(jù)段可以被添加到整個(gè)數(shù)據(jù)包中，數(shù)據(jù)包的長(zhǎng)度就會(huì)超過(guò)最大值是 65535。 此時(shí)如何實(shí)現(xiàn)“ Ping Of Death”攻擊呢？這里首先要將在結(jié)構(gòu)體ip_header的結(jié)構(gòu)進(jìn)行一下解釋。 //32位目的 IP地址 }。 //16位 IP首部校驗(yàn)和 unsigned int s
物理相關(guān)推薦
鄂ICP備17016276號(hào)-1