實驗 Attacks on TCP/IP Protocols

時間 2019-12-01

原文原文鏈接

-------html

轉載請註明出處，博客園-lasgalen-http://www.cnblogs.com/lasgalen/p/4555648.html linux

-------web

1 實驗目的

進行這個實驗的目的是得到TCP/IP協議缺陷和基於這些缺陷的攻擊的經驗。在TCP/IP協議上的缺陷是一種在協議設計和實現出現的漏洞。這給咱們上了很寶貴的一課，關於爲何安全應當在一開始的時候就被考慮設計，而不是在過後加入。此外，學習這些缺陷，幫助學生理解在網絡安全上的挑戰和爲何許多網絡安全測評是必須的。TCP/IP協議的缺陷在幾個不一樣的層次發生。算法

2 實驗環境

三臺機器的操做系統爲 Ubuntu，版本號12.04。ubuntu

由於實驗中間虛擬機的虛擬網絡鏈接出現問題，從新加載了網絡模塊，所以在任務一中使用的是表1的IP和MAC地址。任務2、三中因爲改變了拓撲結構，使用的是表3的IP地址。緩存

表1 任務一中的IP和MAC地址安全

	A服務器	B網絡	Cssh
IP	..65.132	..65.133	..65.134
MAC	::::11:11	::::01:aa	::::fc:0e

表2 任務3、四中的IP和MAC地址

	A	B	C
IP	..47.128	..47.129	..47.130
MAC	::::11:11	::::01:aa	::::fc:0e

表3 任務2、五中的IP和MAC地址

Eth0：*.*.220.128

Eth1：*.*.205.129

Eth0：*.*.220.129

Eth0：*.*.205.128

MAC

*:*:*:*:11:11

*:*:*:*:01:aa

*:*:*:*:fc:0e

首先安裝僞造、發送數據包須要的工具netwox，語句

sudo apt-get install netwox

而後安裝用於抓取查看數據包的軟件wireshark，仍然使用終端安裝

sudo apt-get install wireshark

Wireshark也能夠在軟件中心經過圖形界面進行下載安裝。

打開wireshark以後，在左上角出現找不到網卡的狀況，如圖2.1。

圖2.1

爲了解決這個問題，我在網絡上進行搜索，參考了下面網頁的步驟，詳細過程如圖2.二、圖2.3。

http://www.dickson.me.uk/2012/09/17/installing-wireshark-on-ubuntu-12-04-lts/

把下圖的YOUR_USER_NAME 改成 ***(用戶帳號)。

圖2.2

圖2.3

重啓系統以後，再打開wireshark，發現能夠找到網卡。

繼續安裝vsftpd和openbsd-inetd。

根據實驗指導書中的步驟，首先開啓vsftpd，出現問題

vsftpd:unrecongnized service

Vsftpd服務沒有找到，說明系統中並無安裝相應的軟件包。所以，我使用以下命令來安裝vsftpd服務。

sudo apt-get install vsftpd

安裝到最後出現提示「vsftpd start/running, process 3283」，說明安裝完成後服務已經自動啓動，運行端口號3283。

繼續安裝openbsd-inetd，出現了安裝vsftpd出現的一樣的問題。解決方法與上面相同，安裝openbsd-inetd服務

sudo apt-get install openbsd-inetd

安裝到最後出現提示，網絡超級服務沒有打開。

Setting up openbsd-inetd (0.20091229-1ubuntu1) ...
 * Stopping internet superserver inetd                                  [OK]      
 * Not starting internet superserver : no services enabled

抱着僥倖的心理再次嘗試開啓openbsd-inetd服務，發現仍然找不到服務。網上查閱相關資料後得知，還須要安裝一個telnetd軟件包。

sudo apt-get install telnetd

安裝完成以後還須要一些操做來打開這個服務。

sudo gedit /etc/inetd.conf
//添加
//telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd

sudo /etc/init.d/openbsd-inetd restart
//出現
//* Restarting internet superserver inetd

netstat -a | grep telnet
//出現
//tcp 0 0 *:telnet *:* LISTEN

到此爲止，全部須要的實驗環境配置已經完成，能夠開始實驗。

3 實驗原理

實驗是七選五，所以我選擇了下面五個任務。

-------

轉載請註明出處，博客園-lasgalen-http://www.cnblogs.com/lasgalen/p/4555648.html

-------

3.1 ARP欺騙

ARP緩存是ARP協議的重要的一部分。做爲一個ARP協議執行結果，一旦一個在MAC地址和IP地址之間的映射被決定，這個映射就被緩存。所以，若是影射已經存在在緩存中，就沒有必要再重複ARP協議。然而，由於ARP協議是無狀態的，緩存能夠被輕易的經過惡意的ARP信息修改。這樣的一種攻擊叫作ARP欺騙。

在這樣一個攻擊中，攻擊者使用欺騙ARP信息來哄騙受害者接受一個無效的MAC-IP映射，而且在緩存中保存這個映射。取決於攻擊者的目的不一樣，這裏可能出現各類類型的後果。例如，攻擊者將一個不存在的MAC地址關聯受害者的默認網關的IP地址，經過此來啓動一個Dos攻擊。

3.2 ICMP重定向攻擊

ICMP重定向被路由器用來向更新主機的路由信息，最開始只有最少的路由信息。當一臺主機接收到一個ICMP重定向信息，他將會根據接收到的信息來修改路由表。由於缺乏確認，若是攻擊者但願受害者設置它的路由信息爲一個特別形式，他們能夠發送欺騙ICMP重定向信息給受害者，而且欺騙受害者修改它的路由表。

3.3 SYN洪流攻擊

SYN洪流攻擊是Dos攻擊的一種形式，攻擊者發送許多SYN請求給受害者的TCP端口，可是攻擊者沒有完成三次握手的意向。攻擊者或者使用虛假的IP地址，或者不繼續過程。在這個攻擊中，攻擊者可使受害者的用於半開鏈接的隊列溢出，例如，一個完成SYN，SYN-ACK但沒有收到最後的ACK回覆的鏈接。當這個隊列滿了的時候，受害者不可以在進行更多的鏈接。

SYN 緩存策略：SYN緩存是是對抗SYN洪流攻擊的一種防護機制。若是機器檢測到它正在被SYN洪流攻擊，這種機制將會kick in。

3.4 在telnet和ssh鏈接上的TCP RST攻擊

TCP RST攻擊能夠終止一個在兩個受害者之間已經創建的TCP鏈接。例如，若是這裏有一個在A和B之間已經創建的telnet鏈接，攻擊者能夠僞造一個A發向B的RST包，打破這個存在的鏈接。

3.5 ICMP盲目鏈接重置和源端關閉攻擊

ICMP信息一樣能夠被用於達成鏈接重置攻擊。爲了達到這個目的，攻擊者發送一條顯示「硬錯誤」的ICMP的錯誤信息給TCP鏈接兩端的任意一方。鏈接將會被當即中斷，由於在RFC1122中主機在接收到這樣一個TCMP錯誤包時，應當當即中斷相關的鏈接。RFC1122定義「硬錯誤」爲一個目的不可達且協議無效、端口無效、標誌位缺失和DF位設置的ICMP錯誤信息

ICMP源端關閉信息被擁塞路由器用於告知TCP發送者減緩發送包的速度。攻擊者能夠制定這樣的信息來實施對TCP發送者的拒絕服務攻擊。

4 實驗內容

4.1 ARP欺騙

ARP。當發送方B須要向接收方C發送一個數據時，B會從本身的ARP表中經過C的IP地址來查找相應的C的MAC地址。若是C的MAC地址不在B的ARP表中，B就向全網發廣播包，要求C主機返回它的MAC地址。當B接收到C返回的MAC地址時，B就將更新它的ARP表。同時，C主機也將B主機和它對應的MAC地址記錄到C的ARP表中。ARP表的更新採用牛奶原則，也就是說，ARP表將無條件接受最後一次收到的ARP包做爲ARP更新的數據。鑑於此，攻擊者A能夠利用一些工具僞造一個ARP包，將C的IP對應的MAC地址修改成本身的MAC地址，並將這個數據包發送給B。B在更新了ARP表以後，新的發往C的數據包就會被髮送到A。其流程示意如表4.1.1。

表4.1.1 ARP包的信息

	源IP	源MAC	目的IP	目的MAC
正常狀況
B主機廣播包，請求C的MAC信息	..65.133	::::01:aa	..65.255	ff:ff:ff:ff:ff:ff
C向B返回本身的MAC信息	..65.134	::::fc:0e	..65.133	::::01:aa
A做爲攻擊機，對B和C進行ARP欺騙
B主機廣播包，請求C的MAC信息	..65.133	::::01:aa	..65.255	ff:ff:ff:ff:ff:ff
C向B返回本身的MAC信息	..65.134	::::fc:0e	..65.133	::::01:aa
A向B返回ARP欺騙信息	..65.134	::::11:11	..65.133	::::01:aa
A向C返回ARP欺騙信息	..65.133	::::11:11	..65.134	::::fc:0e

注意，在欺騙過程當中，ARP欺騙信息的包要屢次重複發送，由於要保證ARP欺騙信息在正確的ARP信息以後被髮送到被攻擊機。

詳細的實驗過程以下：

查詢netwox說明後得知，33號工具用於僞造ARP包。使用命令查看該工具的詳細使用方法。

netwox 33 --help2
//以後的不一樣號的工具均可以用這個命令來查看使用方法及參數信息

在進行攻擊以前，先在三臺主機上互相ping。而後使用arp –a命令查看ARP表，圖4.1.1是A的ARP表，圖4.1.2是B的ARP表，圖4.1.3是C的ARP表。

圖4.1.1 攻擊機A的ARP表

圖4.1.2 被攻擊機B的ARP表

圖4.1.3 被攻擊機C的ARP表

以後，在三臺主機所有開啓的狀況下，攻擊機A發動攻擊如圖4.1.4。

圖4.1.4

以後在B主機上查看ARP表，發現C主機對應的MAC地址已經被更改。如圖4.1.5。

圖4.1.5

以後，使用一樣的方法，給C主機發送ARP欺騙包。

這樣，B發送給C的數據將會被鏈路層轉發到A，而C發送給B的數據也將會被鏈路層轉發到A。可是這種狀況下，A若是想插入到BC的通訊間，必需要再次將收到的包進行轉發，並假裝源地址。

並且，A若是想持續這種攻擊，就必須保證ARP欺騙包的發送頻率大於正確的ARP包的發送頻率，不然被攻擊機的ARP表將會被更新，且在下一個ARP欺騙信息到來以前一直保持正確的MAC--IP映射關係，在這期間，A將不能收到想獲得的包。

4.2 ICMP重定向攻擊

在這個任務及第五個任務中，我在虛擬機上搭建了以下網絡拓撲結構，如圖4.2.1。

圖4.2.1

在三臺機器上搭建的路由指令

　 A的路由配置指令

sudo ifconfig eth0 *.*.220.128 netmask 225.225.225.0

sudo ifconfig eth1 *.*.205.129 netmask 255.255.255.0

sudo route add -net *.*.220.0/24 gw *.*.220.128

sudo route add -net *.*.205.0/24 gw *.*.205.129

sudo sysctl -w net.ipv4,ip_forward=1

　 B的路由配置指令

sudo ifconfig eth0 *.*.205.128 netmask 255.255.255.0

sudo route add default gw *.*.220.128

sudo sysctl -w net.ipv4.ip_forward=1

　 C的路由配置指令

sudo ifconfig eth0 *.*.205.128 netmask 255.255.255.0

sudo route add default gw *.*.205.129

sudo sysctl -w net.ipv4.ip_forward=1

　 B的網關是*.*.220.128，C的網關是*.*.205.129。經過traceroute指令能夠跟蹤包通過的主機和路由器，看到詳細的轉發過程，這可以更好的看出網關的做用。

在我設計的ICMP重定向攻擊中，我想讓主機B沒法聯網，即B鏈接任何主機時，都將失敗。

所以，我須要將B的網關地址改成*.*.220.0/24網段中一個未被使用的IP地址，這樣，B向網絡中發送的全部包，都將被髮送到這個「黑洞」中，得不到回覆，至關於不能鏈接網絡。這個IP地址我選擇了*.*.220.130。同時，爲了避免讓B發現這次攻擊是A發起的，要將源地址改成*.*.220.131。

使用netwox86號工具能夠完成這個攻擊。攻擊機A指令

sudo netwox 86 -f "host *.*.220.129" -g *.*.220.130 -c 1 -i *.*.220.131

-f 「host 被攻擊機的IP」 –g 但願對方網關修改後的IP –c 類型 –i 源IP

這個指令只有在按下ctrl+c時纔會結束，不然一直髮送ICMP包。

此時，在被攻擊機B中使用WIRESHRK監聽eth0，發現不斷收到ICMP包，如圖4.2.2。

圖4.2.2

從上圖能夠看出發送包的類型是ICMP，源IP地址是*.*.220.131，目標IP地址是*.*.220.129，網關地址是*.*.220.130。

4.3 SYN洪泛攻擊

若是一個TCP鏈接沒有完成三次握手，它將被放入半開鏈接隊列，而半開鏈接隊列有最大長度，若是鏈接數量達到最大容量時，新的鏈接就不可以被創建。SYN洪泛攻擊就是經過未完成的TCP請求來試圖充滿半開鏈接隊列，使得正常的鏈接不可以被創建，達到攻擊的效果。

在這個實驗中，使用telnet服務做爲攻擊目標，在23號端口發起SYN洪泛攻擊。

首先，嘗試在主機B和C之間創建telnet鏈接，說明網絡聯通。主機B遠程登陸主機C的帳戶，如圖4.3.1。

圖4.3.1

在主機C上，經過命令netstat –na | grep tcp 命令查看當前的TCP相關端口的狀態，發現23號端口處於聯通狀態，如圖4.3.2標黃部分。

圖4.3.2

在主機C上查看C的半開鏈接隊列的最大長度爲128，緩衝保護開啓。如圖4.3.3。

圖4.3.3

在主機B中使用exit命令斷開與C的telnet鏈接。以後在主機A中使用netwox76號工具發動針對主機C23號端口的SYN攻擊。

sudo netwox 76 -i "*.*.47.130" -p "23"

注意，這個命令會一直執行直到按ctrl+C中止。

回到主機B中，嘗試與主機C進行telnet遠程鏈接，如圖4.3.4。

圖4.3.4

從上圖及實驗過程能夠看出，雖然鏈接的速度很慢，可是是能夠鏈接上的。我在主機B上開啓了兩個終端，同時試圖進行telnet鏈接。

到主機C中查看端口鏈接狀況，如圖4.3.5和圖4.3.6。發現，隊列中充斥着大量半開鏈接，目的端口號都是C機的23號端口，可是源主機IP和端口卻不一致，並且端口號都是不經常使用端口，能夠判斷出，這極有多是一次SYN攻擊。

圖4.3.5

圖4.3.6

從第二張圖能夠看出，大部分的鏈接都是SYN半開鏈接，可是在最後有一個B主機的成功完成的telnet鏈接，圖中黃色部分。

而後，在主機C中關閉緩衝保護，如圖4.3.7。

圖4.3.7

在主機A上重複SYN洪泛攻擊。在主機B上嘗試鏈接主機C。如圖4.3.8。

圖4.3.8

發現一直停留在嘗試鏈接這一步，說明此時已經不可以訪問主機C的23號端口了。

在主機C中查看端口鏈接狀況，如圖4.3.9。

圖4.3.9

發現所有是未知主機和不經常使用端口創建的SYN半開鏈接，沒有B主機的任何鏈接存在。

4.4在telnet和ssh鏈接上的TCP RST攻擊

首先完成主機B與主機C的telnet鏈接，如圖4.4.1。

圖4.4.1

在C上查看端口鏈接狀況，如圖4.4.2，已經完成主機B與主機C23端口的鏈接。

圖4.4.2

這時，在主機A中經過netwox78號工具發起針對B主機的RST攻擊。

sudo netwox 78 -i "*.*.47.129"

回到B主機中，發現沒有什麼變化，可是當回車以後，出現鏈接已經被其餘主機斷開，並退回到主機B的帳戶下（個人主機B和主機C中的帳戶都是chengli*，所以在圖片中分不大清）。如圖4.4.3。

圖4.4.3

在主機C中查看此時的鏈接狀況，如圖4.4.4。能夠看出BC主機的23端口的鏈接已經被斷開，處於監聽狀態。

圖4.4.4

注意，此時主機A的攻擊並無中止。

回到主機B中，再次嘗試鏈接主機C，發現最開始是鏈接上了，可是還沒來得及顯示後續內容，鏈接就被中斷。如圖4.4.5。

圖4.4.5

4.5 ICMP盲目鏈接重置和源端關閉攻擊

實驗中使用的是任務4.2中的拓撲結構及IP地址。

首先在B和C見創建telnet鏈接

A是攻擊機，A試圖僞造一個ICMP錯誤信息的包，發送給B或C（實驗中發送給了B），來終止BC見的鏈接。

sudo netwox 82 -f "host *.*.220.129 and tcp port 23" -i *.*.205.128

接下來，在C主機中查看端口鏈接信息，如圖4.5.1，發現鏈接並無終止。

圖4.5.1

在B機中查看wireshark抓取的eth0的流量，如圖4.5.2，發現ICMP錯誤信息包B收到了。

圖4.5.2

出現這種狀況的緣由多是在高版本的ubuntu中已經制訂了一些策略來防止這些攻擊。

-------

轉載請註明出處，博客園-lasgalen-http://www.cnblogs.com/lasgalen/p/4555648.html

-------

5 實驗思考問題

5.1 ISN 初始序列號

當TCP鏈接正在創建時，服務器用一個惟一的32位初始序列號的應答報文來確認用戶請求，TCP協議規範要求美妙更換序列號25萬次，但大多數實際系統更換頻率遠小於此，並且下一次更換的數字每每是可預測的[1]。這個增長值在許多版本比較舊的操做系統中都是一個常量，在FreeBSD4.3中是125000次每秒[2]，PacketShaper的序列號每秒增長128000，每次鏈接增長64000[3]。還可以找到不少類似的例子。

因此初始序列號的可預測性是其增長值固定、更新頻率固定所致使的。

如今有不少ISN的生成算法，試圖經過增長ISN的隨機性來解決這個問題。RFC1948中提出了一個較好的初始化序列號ISN隨機生成算法：ISN = M + F(localhost, localport, remotehost, remoteport)。M是一個計時器，這個計時器每隔4毫秒加1。F是一個Hash算法，根據源IP、目的IP、源端口、目的端口生成一個隨機數值。

可是，嚴格符合RFC1948的ISN生成方法有一個潛在的危機：一個攻擊者若是之前合法擁有過一個IP地址，他經過對ISN進行大量的採樣，能夠估計到隨後的ISN的變化規律。在之後，儘管這個IP地址已經不屬於此攻擊者，但他仍然能夠經過猜想ISN來進行IP欺騙。ISN自身的值是按照一個常數值穩定增長的,因此F()須要保持相對的穩定性。而根據Bellovin 所提出的，這是一個系統特定的值，這些值並不會常常變。

若是Hash函數在實現上存在漏洞，攻擊者就能夠經過大量的採樣，來分析，其中，源IP地址，源端口，目的IP地址，目的端口都是不變的，這減小了攻擊者分析的難度。

Linux TCP的ISN生成器避免了這一點。它每５分鐘計算一次值,把泄漏的風險降到了最低。

有一個方法能夠作得更好，取M = M + R(t)，ISN = M + F(sip, sport, dip, dport, )。其中，R(t) 是一個關於時間的隨機函數。頗有必要這樣作，由於它使攻擊者猜想ISN的難度更大了（弱點在理論上仍是存在的）。

構造TCP ISN生成器的一些更直接的方法是：簡單地選取一些隨機數做爲ISN。這就是給定一個32位的空間，指定ISN = R(t)。(假設R()是徹底的非僞隨機數生成函數)。當然，對於徹底隨機的ISN值，攻擊者猜想到的可能性是１／２³²，隨之帶來的一個問題是ISN空間裏面的值的互相重複。這違反了許多RFC(RFC 793, RFC 1185, RFC 1323, RFC1948等)的假設----ISN單調增長。這將對TCP協議的穩定性和可靠性帶來不可預計的問題。

其它一些由Niels Provos（來自OpenBSD 組織）結合徹底隨機方法和RFC 1948解決方案：ISN = ((PRNG(t)) << 16) + R(t)。其中，PRNG(t) 是一組隨機指定的連續的１６位數字　　0x00000000 -- 0xffff0000，R(t) 是16位隨機數生成器（它的高位msb設成０）0x00000000 -- 0x0000ffff。上面的公式被用於設計OpenBsd的ISN生成器，相關的源代碼能夠從下面的網址得到http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/tcp_subr.c。

Provos的實現方法有效地生成了一組在給定時間內的不會重複的ISN的值，每兩個ISN值都至少相差32K,這不但避免了隨機方法形成的ISN的值的衝突，並且避免了由於哈希函數計算帶來的性能上的降低，可是，它太依賴於系統時鐘，一旦系統時鐘狀態給攻擊者知道了，就存在着系統的全局ISN狀態泄密的危機。[4]

5.2 TCP窗口長度

爲了限制任一時刻可發送的數據量，併爲接收端提供流量控制，TCP 對等方使用窗口實現這些目的。該窗口是接收端容許發送端發送的字節流的數據範圍。發送端只能發送位於窗口內的字節流中的字節。該窗口隨着發送端的出站字節流和接收端的入站字節流而滑動。爲了表示接收窗口的大小，TCP 報頭包含了一個 16 位的「窗口」字段。接收窗口是用於控制可從發送端傳送給接收端的未確認數據數量的窗口。

爲了提供可適應高速傳輸路徑的更大窗口尺寸，RFC 1323定義了容許接收端通告大於 65,535 字節的窗口大小的窗口縮放。「TCP 窗口縮放」選項包括一個窗口縮放因子，該因子與 TCP 報頭中的 16 位窗口字段結合時，能夠將接收窗口大小最大增長到 1GB。

5.3 源端口號

在網上，這方面的資料不是不少。從我閱讀的資料的信息來看，源端口可預測與不可預測是這樣的：

A試圖經過X鏈接到B。則當鏈接到B時，A必須使用可預測可知的端口來確保A繼續按照X能預測的方式來分配端口。AX之間創建兩個鏈接，若是X收到的A的端口號是連續的，或者有必定的規律，則源端口是可預測的。不然，不可預測。一樣X要用一樣的方法對B進行檢測。若是嘗試了兩種端口預測方法後，X不能可靠地預測A分配的端口，這時X必須假定A是隨機的分配端口。以後就能夠用協議進行AXB的鏈接了。這一點在NAT上被使用。[5]

6 實驗總結

這個實驗讓我學會了netwox工具的使用方法，加深了對Dos等類型的攻擊的理解，對linux系統中的一些防護這類攻擊的策略有了必定的認識。

除此以外，我對ubuntu的網絡路由配置，進行學習，，並選擇搭建了一個合適的網絡拓撲結構。

此次實驗的大部分任務都完成的比較順利，可是在幾個攻擊上始終沒有出現理想的效果。開始時覺得是本身的指令有問題，或者是環境哪裏沒配置對。後來經過反覆的學習、比較，查找相關資料，發現是ubuntu已經有預防這類攻擊的策略，所以我可以收到包，可是相關內容並無被改變。

和上一個實驗同樣，我會把報告修改以後放在博客中，由於我以爲裏面的一些小問題我仍是不太明白，須要保留下來，之後研究學習一下。

[1] 呂豔麗,李肖堅.初始序列號生成算法的安全性研究.計算機研究與發展,2005,42(11);1940-1945

[2] 黃兆勤. 關於TCP/IP序列號生成方法的研究.http://blog.sina.com.cn/s/blog_4b5039210100gku7.html.

[3] 連天科技.Packeteer PacketShaper TCP協議棧可預測初始序列號漏洞.http://www.ltsec.com/show.aspx?id=745&cid=37.

[4] 滲透與攻擊.http://www.cnblogs.com/justwannaloveyou/archive/2010/12/03/1895097.html.

[5] 參考學習文章：P2P 之 TCP穿透NAT的原理，P2P穿透UDP/TCP原理

-------

轉載請註明出處，博客園-lasgalen-http://www.cnblogs.com/lasgalen/p/4555648.html

-------

相關標籤/搜索