麻豆小视频在线观看_中文黄色一级片_久久久成人精品_成片免费观看视频大全_午夜精品久久久久久久99热浪潮_成人一区二区三区四区

首頁 > 學院 > 安全知識 > 正文

對DDoS攻擊實例之SYN Flood攻擊的詳細內容講述

2020-04-09 19:56:19
字體:
來源:轉載
供稿:網友

 此文章主要介紹的是DDoS攻擊實例  SYN Flood攻擊,我們大家都知道SYN-Flood是目前使用最廣泛的DDoS攻擊手段,早先的DoS的手段在向分布式這一階段發展的時候也經歷了千軍萬馬過獨木橋的過程。

SYN-Flood的攻擊效果最好,應該是眾黑客不約而同選擇它的原因吧。那么我們一起來看看SYN-Flood的詳細情況。

SYN-Flood是目前最流行的DDoS攻擊手段,早先的DoS的手段在向分布式這一階段發展的時候也經歷了浪里淘沙的過程。SYN-Flood的攻擊效果最好,應該是眾黑客不約而同選擇它的原因吧。那么我們一起來看看SYN-Flood的詳細情況。

 

Syn Flood原理 - 三次握手

Syn Flood利用了TCP/IP協議的固有漏洞。面向連接的TCP三次握手是Syn Flood存在的基礎。

TCP連接的三次握手

如圖二,在第一步中,客戶端向服務端提出連接請求。這時TCP SYN標志置位。客戶端告訴服務端序列號區域合法,需要檢查。客戶端在TCP報頭的序列號區中插入自己的ISN。服務端收到該TCP分段后,在第二步以自己的ISN回應(SYN標志置位),同時確認收到客戶端的第一個TCP分段(ACK標志置位)。在第三步中,客戶端確認收到服務端的ISN(ACK標志置位)。到此為止建立完整的TCP連接,開始全雙工模式的數據傳輸過程。

Syn Flood攻擊者不會完成三次握手

假設一個用戶向服務器發送了SYN報文后突然死機或掉線,那么服務器在發出SYN+ACK應答報文后是無法收到客戶端的ACK報文的(第三次握手無法完成),這種情況下服務器端一般會重試(再次發送SYN+ACK給客戶端)并等待一段時間后丟棄這個未完成的連接,這段時間的長度我們稱為SYN Timeout,一般來說這個時間是分鐘的數量級(大約為30秒-2分鐘);

一個用戶出現異常導致服務器的一個線程等待1分鐘并不是什么很大的問題,但如果有一個惡意的攻擊者大量模擬這種情況,服務器端將為了維護一個非常大的半連接列表而消耗非常多的資源----數以萬計的半連接,即使是簡單的保存并遍歷也會消耗非常多的CPU時間和內存,何況還要不斷對這個列表中的IP進行SYN+ACK的重試。

實際上如果服務器的TCP/IP棧不夠強大,最后的結果往往是堆棧溢出崩潰---即使服務器端的系統足夠強大,服務器端也將忙于處理攻擊者偽造的TCP連接請求而無暇理睬客戶的正常請求(畢竟客戶端的正常請求比率非常之小),此時從正常客戶的角度看來,服務器失去響應,這種情況我們稱做:服務器端受到了SYN Flood攻擊(SYN洪水攻擊)。

下面是我在實驗室中模擬的一次Syn Flood攻擊的實際過程

這一個局域網環境,只有一臺攻擊機(PIII667/128/mandrake),被攻擊的是一臺Solaris 8.0 (spark)的主機,網絡設備是Cisco的百兆交換機。這是在攻擊并未進行之前,在Solaris上進行snoop的記錄,snoop與tcpdump等網絡監聽工具一樣,也是一個很好的網絡抓包與分析的工具。可以看到攻擊之前,目標主機上接到的基本上都是一些普通的網絡包。 …

? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes

? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes

? -> (multicast) ETHER Type=0000 (LLC/802.3), size = 52 bytes

? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes

192.168.0.66 -> 192.168.0.255 NBT Datagram Service Type=17 Source=GU[0]

192.168.0.210 -> 192.168.0.255 NBT Datagram Service Type=17 Source=ROOTDC[20]

192.168.0.247 -> 192.168.0.255 NBT Datagram Service Type=17 Source=TSC[0]

? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes

192.168.0.200 -> (broadcast) ARP C Who is 192.168.0.102, 192.168.0.102 ?

? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes

? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes

192.168.0.66 -> 192.168.0.255 NBT Datagram Service Type=17 Source=GU[0]

192.168.0.66 -> 192.168.0.255 NBT Datagram Service Type=17 Source=GU[0]

192.168.0.210 -> 192.168.0.255 NBT Datagram Service Type=17 Source=ROOTDC[20]

? -> (multicast) ETHER Type=0000 (LLC/802.3), size = 52 bytes

? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes

? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes

接著,攻擊機開始發包,DDoS開始了…,突然間sun主機上的snoop窗口開始飛速地翻屏,顯示出接到數量巨大的Syn請求。這時的屏幕就好象是時速300公里的列車上的一扇車窗。這是在Syn Flood攻擊時的snoop輸出結果: …

 

127.0.0.178 -> lab183.lab.net AUTH C port=1352

127.0.0.178 -> lab183.lab.net TCP D=114 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net TCP D=115 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net UUCP-PATH C port=1352

127.0.0.178 -> lab183.lab.net TCP D=118 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net NNTP C port=1352

127.0.0.178 -> lab183.lab.net TCP D=121 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net TCP D=122 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net TCP D=124 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net TCP D=125 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net TCP D=126 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net TCP D=128 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net TCP D=130 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net TCP D=131 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net TCP D=133 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net TCP D=135 S=1352 Syn Seq=674711609 Len=0 Win=65535

這時候內容完全不同了,再也收不到剛才那些正常的網絡包,只有DDoS包。大家注意一下,這里所有的Syn Flood攻擊包的源地址都是偽造的,給追查工作帶來很大困難。這時在被攻擊主機上積累了多少Syn的半連接呢?我們用netstat來看一下:

# netstat -an | grep SYN

192.168.0.183.9 127.0.0.79.1801 0 0 24656 0 SYN_RCVD

192.168.0.183.13 127.0.0.79.1801 0 0 24656 0 SYN_RCVD

192.168.0.183.19 127.0.0.79.1801 0 0 24656 0 SYN_RCVD

192.168.0.183.21 127.0.0.79.1801 0 0 24656 0 SYN_RCVD

192.168.0.183.22 127.0.0.79.1801 0 0 24656 0 SYN_RCVD

192.168.0.183.23 127.0.0.79.1801 0 0 24656 0 SYN_RCVD

192.168.0.183.25 127.0.0.79.1801 0 0 24656 0 SYN_RCVD

192.168.0.183.37 127.0.0.79.1801 0 0 24656 0 SYN_RCVD

192.168.0.183.53 127.0.0.79.1801 0 0 24656 0 SYN_RCVD

其中SYN_RCVD表示當前未完成的TCP SYN隊列,統計一下:

# netstat -an | grep SYN | wc -l

5273

# netstat -an | grep SYN | wc -l

5154

# netstat -an | grep SYN | wc -l

5267

…..

共有五千多個Syn的半連接存儲在內存中。這時候被攻擊機已經不能響應新的服務請求了,系統運行非常慢,也無法ping通。

上述的相關內容就是對對DDoS攻擊實例之SYN Flood攻擊的詳細內容講述的描述,希望會給你帶來一些幫助在此方面。

文章轉自 ddos教程 http://www.blddos.com/gonggao/2012/1016/9.html

 

發表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發表
主站蜘蛛池模板: 久久精品欧美视频 | 91网在线播放 | 视频一区二区中文字幕 | 欧美1—12sexvideos | av电影在线观看网址 | 精品国产一区二区三区天美传媒 | 国产精品99久久久久久久 | 精品国产乱码一区二区三区四区 | www.99热视频| 草草在线视频 | 亚洲成人免费电影 | 91久久久久久亚洲精品禁果 | 精品国产乱码久久久久久久久 | 欧美国产一区二区三区 | 看免费5xxaaa毛片 | 爱福利视频网 | 黄污在线观看 | 91资源在线观看 | 56av国产精品久久久久久久 | 精品午夜久久 | 美女毛片在线观看 | 91情侣偷在线精品国产 | 国产精品视频二区不卡 | 羞羞视频免费观看入口 | 午夜精品老牛av一区二区三区 | 高清国产免费 | 久久国产精品久久久久久 | 国产精品一区二区三区在线播放 | 国产成人高清在线观看 | www国产成人免费观看视频 | 国产欧美精品一区二区三区四区 | 精品国产乱码久久久久久丨区2区 | 久久久av亚洲男天堂 | 97人操| 国产91久久精品 | 国产高清自拍一区 | 精品国产一区二区三区天美传媒 | 欧美一区二区三区中文字幕 | 久久影城| 亚洲成人精品区 | 毛片免费在线观看视频 |