IP分片是在網絡上傳輸IP報文時常採用的一種技術手段，但是其中存在一些安全隱患。Ping of Death, teardrop等***可能導致某些系統在重組IP分片的過程中宕機或者重新啓動。最近，一些IP分片***除了用於進行拒絕服務***之外，還經常用於躲避防火牆或者網絡***檢測系統的一種手段。部分路由器或者基於網絡的***檢測系統（NIDS），由於IP分片重組能力的欠缺，導致無法進行正常的過濾或者檢測。在本文中將從 IP分片的基本概念介紹入手，詳細探討基於IP分片的***和迂迴***檢測系統所採用的一些手段。
IP分片的理解
IP協議在傳輸數據包時，將數據報文分爲若干分片進行傳輸，並在目標系統中進行重組。這一過程稱爲分片（ fragmentation）。 IP 分片（Fragmentation）發生在要傳輸的IP報文大小超過最大傳輸單位MTU(Maximum Transmission Unit)的情況。比如說，在以太網（Ethernet）環境中可傳輸最大IP報文大小（MTU）爲1500字節。如果要傳輸的報文大小超過1500字節，則需要分片之後進行傳輸。由此可以看出，IP分片在網絡環境中是經常發生的事件。但是，如果經過人爲的惡意操作的分片，將會導致拒絕服務***或者迂迴路由器、防火牆或者網絡***檢測系統（NIDS）的一種***手段。
爲到達目標主機之後能夠正常重組，各分片報文具有如下信息：
* 各IP分片基於IP分片識別號進行重組，識別號相同的重組爲相同的IP報文。IP分片識別號長度爲16位，叫做“IP identification number”或者“fragment ID”。
* 各分片具有從原始報文進行分片之前的分片偏移量以確定其位置。
* 各分片具有分片數據長度，其中20字節IP包頭不包含在該數據長度中。即，傳輸1500字節的數據時，實際數據長度爲1480(1500-20)字節。
* 當每個分片之後還存在後續的分片時，該分片的ME(More Fragment)標誌位爲1。
爲了更加深入地瞭解IP分片原理，下面觀察一下4,000字節的 ICMP 數據傳輸時的分片情況。
首先發送4000字節的 ICMP數據。(通常 ping 報文傳輸大小爲56字節的ICMP報文。爲了測試，我們利用 -s 選項發送4000字節的 ICMP報文以便發生分片。)
［root@linux /root]# ping -s 4000 192.168.0.25
4008 bytes from 192.168.0.25: icmp_seq=0 ttl=254 time=20.7 ms
4008 bytes from 192.168.0.25: icmp_seq=1 ttl=254 time=20.1 ms
利用 tcpdump 進行抓包分析結果如下。
20:55:56.548630 linux.test.com >
test.com.cn: (frag 30338:1048@2960)
20:55:56.558095 linux.test.com >
test.com.cn: (frag 30338:1480@1480+)
20:55:56.565466 linux.test.com >
test.com.cn: icmp: echo request (frag 30338:1480@0+)
傳輸之前的數據報文長度爲20字節，IP報頭+ 8字節，ICMP報頭+ 4000字節，ICMP之和爲4028字節。由於數據長度超過以太網的MTU 1500字節，因此必須進行分片傳輸。上圖是通過以太網傳輸的3個分片的情況。
上一篇《基於IP分片的***方法（一）》講了IP分片的理解。本文就通過Tcpdump進行監聽並分析分片的整個過程和基於分片的***技術做討論。
下面通過Tcpdump進行監聽並分析分片的整個過程。
首先第一個分片中包含20字節的IP報頭和8字節的ICMP報頭及1472(=1500-20-8)字節的 ICMP數據。
其中IP 報頭中包含如下內容。
Protocol = ICMP
Fragment ID = 30338
More Fragments Flag = 1
Fragment Offset = 0
Data Length = 1480
下面由tcpdump監聽到的分片內容中，30338代表fragment ID。1480代表數據長度，0代表分片偏移量，+代表MF標誌位爲 1。
20:55:56.565466 linux.test.com > test.com.cn: icmp: echo request (frag 30338:1480@0+)
IP 報頭中封裝的數據可能爲TCP、UDP或者ICMP等IP協議數據。在這裏發送的是ICMP報文，通過 tcpdump 中監聽到的 ICMP報頭信息中可以看出該報文爲 ICMP echo request報文。
第二個分片由20字節的IP報頭和1480字節的ICMP數據組成。所有的分片中都包含20字節的IP報頭，第二個分片的IP報頭中包含如下信息。
Protocol = ICMP
Fragment ID = 30338
More Fragments Flag = 1
Fragment Offset = 1480
Data Length = 1480
可以看出該分片的偏移量爲1480，但是不包含ICMP報頭，因此無法獲知ICMP報文類型。
從tcpdump監聽到的數據中可以看出，除了第一個分片中包含"ICMP echo request"報文類型之外，後續的分片中看不到相應的報文類型。對於TCP及UDP數據也存在類似的情況。只有第一個分片中包含TCP、UDP及 ICMP報頭，因此對於數據包過濾設備來說，可能只阻斷第一個分片，因此需要根據分片 ID來維持各會話的狀態。智能的包過濾系統可以阻斷含有相同分片識別號的所有數據包。
最後一個分片由20字節的IP報頭和剩餘的ICMP數據組成。相應的IP報頭中包含如下信息。
Protocol = ICMP
Fragment ID = 30338
More Fragments Flag = 0
Fragment Offset = 2960
Data Length = 1048
因爲不存在後續的分片，因此MF 標誌位爲0。
我們觀察了一下4000字節的ICMP數據傳輸時，分片的整個過程。
基於分片的***技術
如上所述，IP報文分片是一個正常的過程，但是一些***者恰恰利用分片過程中的一些漏洞，迂迴防火牆或者***檢測系統進行各種***。
Tiny fragment ***
所謂Tiny fragment***是指通過惡意操作，發送極小的分片來繞過包過濾系統或者***檢測系統的一種***手段。
***者通過惡意操作，可將TCP報頭(通常爲20字節)分佈在2個分片中，這樣一來，目的端口號可以包含在第二個分片中。
對於包過濾設備或者***檢測系統來說，首先通過判斷目的端口號來採取允許/禁止措施。但是由於通過惡意分片使目的端口號位於第二個分片中，因此包過濾設備通過判斷第一個分片,決定後續的分片是否允許通過。但是這些分片在目標主機上進行重組之後將形成各種***。通過這種方法可以迂迴一些***檢測系統及一些安全過濾系統。目前一些智能的包過濾設備直接丟掉報頭中未包含端口信息的分片。
通過大家熟知的nmap工具也可以進行一定的Tiny fragment***。通過nmap的-f選項可以將TCP報頭分在多個小碎片中。
[root@linux /root]# nmap -f -sS -p 23 192.168.0.25
Starting nmap V. 2.54BETA1 by [email][email protected][/email] ( [url]www.insecure.org/nmap/[/url] )
Interesting ports on test.com.cn (192.168.0.25):
23/tcp open telnet
Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds
此時通過tcpdump監聽的結果如下。
02:57:25.633885 truncated-tcp 16 (frag 19350:16@0+)
02:57:25.634375 linux.test.com > test.com.cn: (frag 19350:4@16)
02:57:25.635071 test.com.cn.telnet > linux.test.com.34326:
－ S 1348389859:1348389859(0) ack 3078700240 win 32696 (DF)
02:57:25.639159 linux.test.com.34326 > test.com.cn.telnet:
－ R 3078700240:3078700240(0)win 0
可以看出通過nmap成功執行了TCP SYN掃描。但是第一個分片大小爲16字節，小於TCP報頭長度20字節，而TCP報頭的剩餘 4字節包含在第二個分片中。