NetBsd操作系統(tǒng)網(wǎng)絡部分ICMP缺陷的修正

摘要:NetBsd是Unix的變種，作為控制部分的操作系統(tǒng)廣泛應用于網(wǎng)絡設備中，該文報告在使用過程中發(fā)現(xiàn)的網(wǎng)絡部分的缺陷及其修正方法。

關鍵詞:NetBsd; ICMP; 缺陷

中圖分類號:TP393文獻標識碼:A文章編號:1009-3044(2009)14-3645-02

Found a Bug in NetBsd Operating System Network Source and Fix It

XIAO Chen-yang1，2

(1.Changsha Bohua Science and Technology Co.， Ltd.， Changsha 410205， China; 2.College of Life Science， Hunan Normal University， Changsha 410081， China)

Abstract: NetBsd is a free， secure， and highly portable Unix-like Open Source operating system available for many platforms， from large-scale server systems to powerful desktop systems to handheld and embedded devices. We found a bug in NetBsd network source code， and we found a new method to fix it.

Key words: NetBsd; ICMP; BUG

1 引言

我們使用NetBsd作為防火墻設備的控制部分系統(tǒng)軟件。完成防火墻中連接的建立、界面控制。操作系統(tǒng)的功能主要是完成連接跟蹤的建立和維護，基于連接跟蹤的地址轉換(NAT)，是建立在連接跟蹤上的。

我們設計防火墻采用由硬件加速卡和基于X86工控機組成，NetBsd運行于工控機上，硬件加速卡通過PCI-E接口與工控機相連接。

防火墻網(wǎng)絡數(shù)據(jù)流如圖1所示。

1) 網(wǎng)絡數(shù)據(jù)包從硬件加速卡進入，加速卡把新連接上傳到X86硬件由NetBsd的連接跟蹤部分，在內存中建立連接表等。

2) 建立連接后的數(shù)據(jù)流直接由硬件加速卡處理，不再上傳到X86硬件，由于這部分數(shù)據(jù)流不需要上傳到X86硬件，所以網(wǎng)絡數(shù)據(jù)得到快速處理。

3) 通常而言，由于ICMP的數(shù)據(jù)量不大，因此將所有的ICMP的數(shù)據(jù)上傳到X86硬件平臺，由NetBsd處理，而不是由硬件加速卡處理。

綜上所述，本產品對ICMP的處理完全由控制層操作系統(tǒng)來完成。

2 缺陷描述

本產品在使用過程中，發(fā)現(xiàn)了作為控制層操作系統(tǒng)NetBsd的一個缺陷，描述如圖2。

如圖2所示，當在防火墻NAT后面的計算機(A、B)通過防火墻同時向網(wǎng)絡上的發(fā)送Ping請求包，遠端計算機(C)回應ping 回復包，當通過防火墻NAT后有時候會出現(xiàn)Ping回復包丟失的現(xiàn)象，本來應該回復到A的數(shù)據(jù)包，錯誤的傳遞到B計算機。導致A收不到ping回復包。

當NAT后的計算機(A、B)同時向網(wǎng)外的計算機(C)發(fā)送Ping請求包，在遠端計算機(C)正確回復的情況下，經過防火墻后，防火墻會對并不能所收到的回復包，正確分發(fā)到另外的計算機上，導致請求包計算機可能無法正確收到回復包。

3 NetBsd處理流程

ICMP的請求包和回復包格式如圖3所示。

由于ICMP沒有端口(Port)，在NetBsd中將Identifier作為sport的值，而Dport設置為0;由SIP、DIP、sport、dport作為Icmp連接的唯一標識。經過NetBsd 地址轉換后，SIP更換為NAT地址;(sIP、DIP、sport、dport)遠端計算機Reply包(DIP、sIP、sport、dport)，而后根據(jù)sip、sport、dport 在連接表內查詢，查到(SIP、DIP、sport、dport)，而后對替換目的地址;NetBsd的NAT部分對ICMP的處理流程。

1) 操作系統(tǒng)收到ICMP請求報文后，修改源地址為約定IP，并記錄原始SIP、DIP、Sport、Dport;

2) 收到ICMP回復報文后根據(jù)SIP、DIP、Port，從連接跟蹤表中找出真正的目的地址;

3) 根據(jù)找到的連接跟蹤表項，修改目的地址，并作相應的修改，如CheckSum等;

4) 由于ICMP沒有對應的Port，采用的ICMP報文中的部分數(shù)據(jù)作為Sport和Dport。

由于在查詢過程中，sport 的值可能完全一致，在A、B中這三個參數(shù)完全相同，因此可能就指向同一個條目，所以導致數(shù)據(jù)封裝為同一個目的地址，只是收不到回復包。

從分析過程中可以看到問題出現(xiàn)在 三個參數(shù)可能完全相同，DIP不能更改，所以需要在sport、dport 想辦法，我們解決的方法是在sport 加上一個隨機值，修改ICMP數(shù)據(jù)包，而Dport仍然保持不變;并將將增加隨機值保存在對應連接跟蹤表項中。由于對方一般不會修改Identify值，因此在收到回復包后，根據(jù)DIP、SIP、Sport、Dport能夠正確查找到連接表項，根據(jù)表現(xiàn)內容，對目的地址(Dport)進行替換，同時對Identify部分減去記錄的隨機值，獲得原始值。

4 解決方法

4.1 ICMP的數(shù)據(jù)結構

struct icmp {

u_int8_ticmp_type;/* type of message， see below */

u_int8_ticmp_code;/* type sub code */

u_int16_t icmp_cksum;/* ones complement cksum of struct */

union {

u_int8_tih_pptr;/* ICMP_PARAMPROB */

struct in_addr ih_gwaddr;/* ICMP_REDIRECT */

struct ih_idseq {

int16_t icd_id;

int16_t icd_seq;

} ih_idseq;

int32_t ih_void;/* ICMP_UNREACH_NEEDFRAG -- Path MTU Discovery (RFC1191) */

struct ih_pmtu {

int16_t ipm_void;

int16_t ipm_nextmtu;

} ih_pmtu;

struct ih_rtradv {

u_int8_t irt_num_addrs;

u_int8_t irt_wpa;

u_int16_t irt_lifetime;

} ih_rtradv;

} icmp_hun;

4.2 關鍵修改位置

對請求包的處理:

1) 在接收到新ICMP數(shù)據(jù)包后，對Sport、Dport進行修改。

ni.nai_sport = ((icmphdr_t *)fin->fin_dp)->icmp_id;

ni.nai_sport = ((icmphdr_t*)fin->fin_dp)->icmp_id+SOR(R) (sport <65535)

ni.nai.dport = SOR(R)

于是 ICMP數(shù)據(jù)包中Dport和Sport賦予新的值。

2) 根據(jù)SIP、Sport、Dport創(chuàng)建新連接表項;

3) 對ICMP數(shù)據(jù)包進行重新計算;

4) 發(fā)送新組裝的數(shù)據(jù)包。

對回復包的處理:

1) 根據(jù)收到SIP、Sport、Dport查詢出連接表條目;

2) 取出條目中保存的dport，SIP，此時連接表中DIP=回復包中的SIP

3) 對ICMp_id -dport得到ICMP-ID;

4) 將條目中SIP，替換回復包中的DIP;

5) 進行相應的數(shù)據(jù)包計算;

6) 發(fā)送新組裝的數(shù)據(jù)包。

處理流程圖如圖5所示。

至此，數(shù)據(jù)完全替換完畢。

5 小結

我們在使用NetBsd過程中，發(fā)現(xiàn)了此缺陷，相繼做了修正。修正后的版本經過實際網(wǎng)絡運行，反應良好，問題確實得到解決。根據(jù)我們對其他BSD操作系統(tǒng)的考察，發(fā)現(xiàn)都具有同樣的缺陷。因此解決方案具有普遍性。我們已經和BSD維護人員聯(lián)系，遞交了我們修正版本。

參考文獻:

[1] NetBsd官方網(wǎng)站[EB/OL]. http://www.NetBsd.org.