1. 為什麼存在IP碎片
鏈路層具有最大傳輸單元MTU這個特性,它限制了數據幀的最大長度,不同的網路類型都有一個上限值。乙太網的MTU是1500,你可以用 netstat -i 命令查看這個值。如果IP層有數據包要傳,而且數據包的長度超過了MTU,那么IP層就要對數據疊詢櫻包進行分片(fragmentation)操作,使每一片的長度都小於或等於MTU。
我們假設要傳輸一個UDP數據包,乙太網的MTU為1500位元組,一般IP首部為20位元組,UDP首部為8位元組,數據的淨荷(payload)部分預留是1500-20-8=1472位元組。如果數據部分大於1472位元組,就會出現分片現象。
IP首部包含了分片和重組所需的信息:
Identification R DF MF fragment Offset
Identification:傳送端傳送的IP數據包標識欄位都是一個唯一值,該值在分片時被複製到每個片中。
R:保留未用。
DF:Don‘t Fragment,“不分片”位,如果將多戶艱灶這一比特置1 ,IP層將不對數據報進行分片。
MF:More Fragment,“更多的片”,除了最後一片外,烏棗其他每個組成數據報的片都要把該比特置1。
Fragment Offset:該片偏移原始數據包開始處的位道罪永宙置。偏移的位元組數是該值乘以8。
另外,當數據報被分片嬸殼櫃後,每個片的總長度值要改為該片的長度值。
每一IP分片都各自路由,到達目的主機後在IP層重組,請放心,首部中的數據能夠正確完成分片的重組。你不禁要問,既然分片可以被重組,那么所謂的碎片攻擊是如何產生的呢?
2. IP碎片攻擊
IP首部有兩個位元組表示整個IP數據包的長度,所以IP數據包最長只能為0xFFFF,就是65535位元組。如果有意傳送總長度超過65535的IP碎片,一些老的系統核心在處理的時候就會出現問題,導致崩潰或者拒絕服務。另外,如果分片之間偏移量經過精心構造,一些系統就無法處理,導致當機。所以說,漏洞的起因是出在重組算法上。
下面我們逐個分析一些著名的碎片攻擊程式,來了解如何人為製造IP碎片來攻擊系統。
3. ping o‘ death
ping o‘ death是利用
ICMP協定的一種碎片攻擊。攻擊者傳送一個長度超過65535的Echo Request數據包,目標主機在重組分片的時候會造成事先分配的65535位元組
緩衝區溢出,系統通常會崩潰或掛起。ping不就是傳送ICMP Echo Request數據包的嗎?讓我們嘗試攻擊一下吧!不管IP和ICMP首部長度了,數據長度反正是多多益善,就65535吧,傳送一個包:
# ping -c 1 -s 65535 192.168.0.1
Error: packet size 65535 is too large. Maximum is 65507
不走運,看來Linux自帶的ping不允許我們做壞事。:(
65507是它計算好的:65535-20-8=65507。Win2K下的ping更摳門格拔拜,數據只允許65500大小。所以你必須找另外的程式來發包,但是新版本的作業系統已經搞定這個缺陷了,所以你還是繼續往下閱讀本文吧。
順便提一下,記得99年有“愛國主義黑客”(“紅客”的前輩)發動全國網民在某一時刻開始ping某美國站點,試圖ping死遠程伺服器。這其實是一種Pingflood攻擊,用大量的Echo Request包減慢主機的回響速度和阻塞目標網路,原理和ping o‘ death是不一樣的,這點要分清楚。
4. jolt2
jolt2.c是在一個死循環中不停的傳送一個ICMP/UDP的IP碎片,可以使Windows系統的機器死鎖。我測試了沒打SP的Windows 2000,CPU利用率會立即上升到100%,滑鼠無法移動。
我們用Snort分別抓取采她求探用ICMP和UDP協定傳送的數據包。
傳送的ICMP包:
01/07-15:33:26.974096 192.168.0.9 -> 192.168.0.1
ICMP TTL:255 TOS:0x0 ID:1109 IpLen:20 DgmLen:29
Frag Offset: 0x1FFE Frag Size: 0x9
08 00 00 00 00 00 00 00 00 .........
傳送的UDP包:
01/10-14:21:00.298282 192.168.0.9 -> 192.168.0.1
UDP TTL:255 TOS:0x0 ID:1109 IpLen:20 DgmLen:29
Frag Offset: 0x1FFE Frag Size: 0x9
04 D3 04 D2 00 09 00 00 61 ........a
從上面的結果可以看出:
* 分片標誌位MF=0,說明是最後一個分片。
* 偏移量為0x1FFE,計算重組後的長度為 (0x1FFE * 8) + 29 = 65549 >65535,溢出。
* IP包的ID為1109,可以作為IDS檢測的一個特徵。
* ICMP包:
類型為8、代碼為0,是Echo Request;
校驗和為0x0000,程式沒有計算校驗,所以確切的說這個ICMP包是非法的。
* UDP包:
目的連線埠由用戶在命令參數中指定;
源連線埠是目的連線埠和1235進行OR的結果;
校驗和為0x0000,和ICMP的一樣,沒有計算,非法的UDP。
淨荷部分只有一個字元‘a‘。
jolt2.c應該可以偽造源IP位址,但是源程式中並沒有把用戶試圖偽裝的IP位址賦值給src_addr,不知道作者是不是故意的。
jolt2的影響相當大,通過不停的傳送這個偏移量很大的數據包,不僅死鎖未打補丁的Windows系統,同時也大大增加了網路流量。曾經有人利用jolt2模擬網路流量,測試IDS在高負載流量下的攻擊檢測效率,就是利用這個特性。
5. teardrop
teardrop也比較簡單,默認傳送兩個UDP數據包,就能使某些Linux核心崩
潰。Snort抓取的結果如下:
第一個:
01/08-11:42:21.985853 192.168.0.9 -> 192.168.0.1
UDP TTL:64 TOS:0x0 ID:242 IpLen:20 DgmLen:56 MF
Frag Offset: 0x0 Frag Size: 0x24
A0 A8 86 C7 00 24 00 00 00 00 00 00 00 00 00 00
.....$..........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00 00 00 00 ....
* MF=1,偏移量=0,分片IP包的第一個。
* 結構圖:
IP UDP Data
第二個:
01/08-11:42:21.985853 192.168.0.9 -> 192.168.0.1
UDP TTL:64 TOS:0x0 ID:242 IpLen:20 DgmLen:24
Frag Offset: 0x3 Frag Size: 0x4
A0 A8 86 C7 ....
* MF=0,偏移量=0x3,偏移位元組數為 0x3 * 8 = 24,最後一個分片。
* 結構圖:
IP Data
如果修改原始碼,第二片IP包的偏移量也可以為0x4,偏移位元組數就是
0x4 * 8 = 32。
下面的結構圖表示了接收端重組分片的過程,分別對應於偏移位元組數為24
和32兩種情況:
IP UDP Data
Data
Data
可以看出,第二片IP包的偏移量小於第一片結束的位移,而且算上第二片IP包的Data,也未超過第一片的尾部,這就是重疊現象(overlap)。老的Linux核心(1.x - 2.0.x)在處理這種重疊分片的時候存在問題,WinNT/95在接收到10至50個teardrop分片時也會崩潰。你可以閱讀teardrop.c的原始碼來了解如何構造並傳送這種數據包。
6. 如何阻止IP碎片攻擊
* Windows系統請打上最新的Service Pack,Linux核心已經不受影
響。
* 如果可能,在網路邊界上禁止碎片包通過,或者用IPTABLES限制每秒通
過碎片包的數目。
* 如果防火牆有重組碎片的功能,請確保自身的算法沒有問題,否則被
DoS就會影響整個網路。
* Win2K系統中,自定義IP安全策略,設定“碎片檢查”。
7. 更多資料
TCP/IP Illustracted Volume 1 : The Protocols
Microsoft Security Bulletin MS00-029:
BugTraq Mailing List, "Analy
sis of jolt2.c(MS00-029)":
# ping -c 1 -s 65535 192.168.0.1
Error: packet size 65535 is too large. Maximum is 65507
不走運,看來Linux自帶的ping不允許我們做壞事。:(
65507是它計算好的:65535-20-8=65507。Win2K下的ping更摳門,數據只允許65500大小。所以你必須找另外的程式來發包,但是新版本的作業系統已經搞定這個缺陷了,所以你還是繼續往下閱讀本文吧。
順便提一下,記得99年有“愛國主義黑客”(“紅客”的前輩)發動全國網民在某一時刻開始ping某美國站點,試圖ping死遠程伺服器。這其實是一種Pingflood攻擊,用大量的Echo Request包減慢主機的回響速度和阻塞目標網路,原理和ping o‘ death是不一樣的,這點要分清楚。
4. jolt2
jolt2.c是在一個死循環中不停的傳送一個ICMP/UDP的IP碎片,可以使Windows系統的機器死鎖。我測試了沒打SP的Windows 2000,CPU利用率會立即上升到100%,滑鼠無法移動。
我們用Snort分別抓取採用ICMP和UDP協定傳送的數據包。
傳送的ICMP包:
01/07-15:33:26.974096 192.168.0.9 -> 192.168.0.1
ICMP TTL:255 TOS:0x0 ID:1109 IpLen:20 DgmLen:29
Frag Offset: 0x1FFE Frag Size: 0x9
08 00 00 00 00 00 00 00 00 .........
傳送的UDP包:
01/10-14:21:00.298282 192.168.0.9 -> 192.168.0.1
UDP TTL:255 TOS:0x0 ID:1109 IpLen:20 DgmLen:29
Frag Offset: 0x1FFE Frag Size: 0x9
04 D3 04 D2 00 09 00 00 61 ........a
從上面的結果可以看出:
* 分片標誌位MF=0,說明是最後一個分片。
* 偏移量為0x1FFE,計算重組後的長度為 (0x1FFE * 8) + 29 = 65549 >65535,溢出。
* IP包的ID為1109,可以作為IDS檢測的一個特徵。
* ICMP包:
類型為8、代碼為0,是Echo Request;
校驗和為0x0000,程式沒有計算校驗,所以確切的說這個ICMP包是非法的。
* UDP包:
目的連線埠由用戶在命令參數中指定;
源連線埠是目的連線埠和1235進行OR的結果;
校驗和為0x0000,和ICMP的一樣,沒有計算,非法的UDP。
淨荷部分只有一個字元‘a‘。
jolt2.c應該可以偽造源IP位址,但是源程式中並沒有把用戶試圖偽裝的IP位址賦值給src_addr,不知道作者是不是故意的。
jolt2的影響相當大,通過不停的傳送這個偏移量很大的數據包,不僅死鎖未打補丁的Windows系統,同時也大大增加了網路流量。曾經有人利用jolt2模擬網路流量,測試IDS在高負載流量下的攻擊檢測效率,就是利用這個特性。
5. teardrop
teardrop也比較簡單,默認傳送兩個UDP數據包,就能使某些Linux核心崩
潰。Snort抓取的結果如下:
第一個:
01/08-11:42:21.985853 192.168.0.9 -> 192.168.0.1
UDP TTL:64 TOS:0x0 ID:242 IpLen:20 DgmLen:56 MF
Frag Offset: 0x0 Frag Size: 0x24
A0 A8 86 C7 00 24 00 00 00 00 00 00 00 00 00 00
.....$..........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00 00 00 00 ....
* MF=1,偏移量=0,分片IP包的第一個。
* 結構圖:
IP UDP Data
第二個:
01/08-11:42:21.985853 192.168.0.9 -> 192.168.0.1
UDP TTL:64 TOS:0x0 ID:242 IpLen:20 DgmLen:24
Frag Offset: 0x3 Frag Size: 0x4
A0 A8 86 C7 ....
* MF=0,偏移量=0x3,偏移位元組數為 0x3 * 8 = 24,最後一個分片。
* 結構圖:
IP Data
如果修改原始碼,第二片IP包的偏移量也可以為0x4,偏移位元組數就是
0x4 * 8 = 32。
下面的結構圖表示了接收端重組分片的過程,分別對應於偏移位元組數為24
和32兩種情況:
IP UDP Data
Data
Data
可以看出,第二片IP包的偏移量小於第一片結束的位移,而且算上第二片IP包的Data,也未超過第一片的尾部,這就是重疊現象(overlap)。老的Linux核心(1.x - 2.0.x)在處理這種重疊分片的時候存在問題,WinNT/95在接收到10至50個teardrop分片時也會崩潰。你可以閱讀teardrop.c的原始碼來了解如何構造並傳送這種數據包。
6. 如何阻止IP碎片攻擊
* Windows系統請打上最新的Service Pack,Linux核心已經不受影
響。
* 如果可能,在網路邊界上禁止碎片包通過,或者用IPTABLES限制每秒通
過碎片包的數目。
* 如果防火牆有重組碎片的功能,請確保自身的算法沒有問題,否則被
DoS就會影響整個網路。
* Win2K系統中,自定義IP安全策略,設定“碎片檢查”。
7. 更多資料
TCP/IP Illustracted Volume 1 : The Protocols
Microsoft Security Bulletin MS00-029:
BugTraq Mailing List, "Analy
sis of jolt2.c(MS00-029)":