專利名稱：一種客戶端驗證方法及裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及網(wǎng)絡(luò)安全技術(shù)，尤其涉及一種客戶端驗證方法及裝置。
背景技術(shù)：
隨著網(wǎng)絡(luò)通信技術(shù)的進(jìn)步，各種網(wǎng)絡(luò)攻擊引發(fā)的網(wǎng)絡(luò)安全問題日益受到人們的關(guān)注。越來越多的企業(yè)以及運營商開始使用諸如防火墻等網(wǎng)絡(luò)安全設(shè)備為網(wǎng)絡(luò)通信提供保護(hù)措施。偽造IP地址(又可稱為偽造客戶端)的攻擊行為是非常常見的網(wǎng)絡(luò)攻擊，這種攻擊的特點是會消耗大量的服務(wù)器資源，以致服務(wù)器沒有足夠的資源去響應(yīng)其他客戶端的訪問請求。其中 Dos (Denial of Service，拒絕服務(wù)攻擊)以及DDos (Distributed Denial of krvice，分布式拒絕服務(wù)攻擊)是常見的偽造IP地址的網(wǎng)絡(luò)攻擊行為?，F(xiàn)有技術(shù)大量著手于研究Dos以及DDos等攻擊行為在攻擊模式上的特點，比如通過報文速率統(tǒng)計，甚至分布式的報文速率統(tǒng)計來應(yīng)對這些攻擊行為。然而現(xiàn)有技術(shù)的處理方式仍然有其局限性，攻擊者仍然可以通過巧妙安排攻擊模型，比如攻擊的速率等來適應(yīng)這些安全措施。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明一種客戶端驗證裝置，其應(yīng)用于網(wǎng)絡(luò)安全設(shè)備中，用于驗證經(jīng)由所述網(wǎng)絡(luò)安全設(shè)備接入網(wǎng)絡(luò)的客戶端，其中該裝置包括報文檢查單元，用于檢查網(wǎng)絡(luò)安全設(shè)備接收到的報文是否為ICMP端口不可達(dá)報文，如果是，則轉(zhuǎn)客戶端判決單元處理；如果否，則進(jìn)一步檢查發(fā)出報文的客戶端是否存在于客戶端列表中，如果不在，則轉(zhuǎn)驗證發(fā)起單元處理；驗證發(fā)起單元，用于構(gòu)造UDP報文并向客戶端發(fā)出，其中該UDP報文目的端口為客戶端未開放的UDP端口，該UDP報文的UDP頭部攜帶有預(yù)設(shè)的驗證信息；以及客戶端判決單元，用于檢查該ICMP端口不可達(dá)報文是否攜帶有所述預(yù)設(shè)的驗證信息，如果是，則將發(fā)出該報文的客戶端加入到客戶端列表中作為信任客戶端。優(yōu)選地，所述UDP報文的目的端口為非知名端口或者端口號大于50000。優(yōu)選地，還包括老化處理單元，用于在預(yù)定的客戶端老化時間到達(dá)時將客戶端列表中的客戶端刪除。優(yōu)選地，所述驗證信息是與該客戶端相對應(yīng)的Cookie認(rèn)證信息。優(yōu)選地，所述客戶端判決單元進(jìn)一步用于在檢查到所述ICMP端口不可達(dá)報文沒有攜帶所述預(yù)設(shè)的驗證信息時，將所述客戶端加入客戶端列表中作為不信任客戶端。本發(fā)明還提供一種客戶端驗證方法，其應(yīng)用于網(wǎng)絡(luò)安全設(shè)備中，用于驗證經(jīng)由所述網(wǎng)絡(luò)安全設(shè)備接入網(wǎng)絡(luò)的客戶端，其中該方法包括A，檢查網(wǎng)絡(luò)安全設(shè)備接收到的報文是否為ICMP端口不可達(dá)報文，如果是，則轉(zhuǎn)步驟C ；如果否，則進(jìn)一步檢查發(fā)出報文的客戶端是否在客戶端列表中，如果不在，則步驟B ；
步驟B，用于構(gòu)造UDP報文并向客戶端發(fā)出，其中該UDP報文目的端口為客戶端未開放的UDP端口，該UDP報文的UDP頭部攜帶有預(yù)設(shè)的驗證信息；步驟C，檢查該ICMP端口不可達(dá)報文是否攜帶有所述預(yù)設(shè)的驗證信息，如果是，則將發(fā)出該報文的客戶端加入到客戶端列表中作為信任客戶端。優(yōu)選地，所述UDP報文的目的端口為非知名端口或者端口號大于50000。優(yōu)選地，還包括D，在預(yù)定的客戶端老化時間到達(dá)時將客戶端列表中的客戶端刪除。優(yōu)選地，驗證信息是與該客戶端相對應(yīng)的Cookie認(rèn)證信息。優(yōu)選地，所述客戶端列表包括信任列表以及不信任列表，步驟C進(jìn)一步包括在檢查到所述ICMP端口不可達(dá)報文沒有攜帶所述預(yù)設(shè)的驗證信息時，將所述客戶端加入不信任列表；在檢查到所述ICMP端口不可達(dá)報文攜帶所述預(yù)設(shè)的驗證信息時，將所述客戶端加入不信任列表。


圖1是本發(fā)明一般處理流程圖。圖2是本發(fā)明客戶端驗證裝置的邏輯結(jié)構(gòu)圖。圖3是ICMP報文封裝在IP報文中的格式圖。圖4是ICMP報文格式圖。圖5是本發(fā)明UDP報文格式圖。圖6是ICMP端口不可達(dá)報文格式圖。圖7是本發(fā)明攜帶有認(rèn)證信息的ICMP端口不可達(dá)報文格式圖。
具體實施例方式本發(fā)明提出一種客戶端驗證的方法及裝置來解決客戶端偽造的問題。請參考圖1， 其顯示了本發(fā)明一般的處理流程。首先，一個新的客戶端(client)接入網(wǎng)絡(luò)后根據(jù)自己的應(yīng)用需求發(fā)出報文來訪問各種服務(wù)器Gerver)。位于服務(wù)器與客戶端之間的網(wǎng)絡(luò)安全設(shè)備 (Dev)會構(gòu)造一個帶有驗證信息的UDP報文發(fā)給客戶端。如果網(wǎng)絡(luò)安全設(shè)備能夠收到帶有同樣驗證信息的ICMP回應(yīng)報文，則證明客戶端是真實存在的，其IP地址并不是偽造的，；否則說明客戶端的IP地址是偽造的。以下結(jié)合圖2至圖7，以網(wǎng)絡(luò)安全設(shè)備通過CPU執(zhí)行內(nèi)存中的計算機(jī)軟件為例進(jìn)行介紹，然而本發(fā)明顯然不局限于純計算機(jī)軟件的實現(xiàn)方式，其完全可以通過軟硬結(jié)合甚至包括固件的組合方式加以實現(xiàn)。請參考圖2，本發(fā)明客戶端驗證裝置10位于所述網(wǎng)絡(luò)安全設(shè)備中，其包括報文檢查單元11、驗證發(fā)起單元12、客戶端判決單元13以及老化處理單元14。上述各個單元在通過CPU運行軟件代碼實現(xiàn)，并執(zhí)行如下流程。步驟101，檢查網(wǎng)絡(luò)安全設(shè)備接收到的報文是否為ICMP端口不可達(dá)報文，如果是， 則轉(zhuǎn)步驟103 ；如果否，則進(jìn)一步檢查發(fā)出報文的客戶端是否在客戶端列表中，如果不在， 則步驟102 ；本步驟由報文檢查單元11執(zhí)行。如前所述，本發(fā)明是通過檢查接收到的ICMP端口不可達(dá)報文來確定客戶端是否是真實的，所以對于所有的報文都需要先檢查其是否為ICMP端口不可達(dá)報文。如果是ICMP端口不可達(dá)報文，則需要在步驟103做特別處理。如果不是ICMP端口不可達(dá)報文，則進(jìn)入步驟102的一般處理程序。請參考圖3以及圖4，ICMP報文一般包括查詢報文以及差錯報文，ICMP端口不可達(dá)報文屬于差錯報文的一種，其在ICMP協(xié)議定義中是報文類型為3，代碼為3。報文檢查單元即通過檢查協(xié)議類型，報文類型以及代碼類型即可找到ICMP報文，關(guān)于特定報文的識別現(xiàn)有技術(shù)已經(jīng)有較好的教導(dǎo)，不再一一贅述。當(dāng)一個新的客戶端接入網(wǎng)絡(luò)并發(fā)起對遠(yuǎn)端主機(jī)(如服務(wù)器)的訪問時，其第一個報文到達(dá)網(wǎng)絡(luò)安全設(shè)備時。報文檢查單元11遍歷客戶端列表(以客戶端IP地址列表為例)會發(fā)現(xiàn)客戶端的IP地址并不存在于所述客戶端列表中，如此表明該客戶端的IP地址是真實的還是偽造的無法確定。因此轉(zhuǎn)入步驟102對客戶端的真?zhèn)芜M(jìn)行驗證。步驟102，用于構(gòu)造UDP報文并向客戶端發(fā)出，其中該UDP報文目的端口為客戶端未開放的UDP端口，該UDP報文的UDP頭部攜帶有預(yù)設(shè)的驗證信息；本步驟由驗證發(fā)起單元 12執(zhí)行。UDP協(xié)議有一個規(guī)則，如果主機(jī)收到一份UDP數(shù)據(jù)報文，但該報文的目的端口與主機(jī)上正在使用的進(jìn)程不相符，那么主機(jī)UDP協(xié)議棧會返回一個ICMP端口不可達(dá)報文。這個規(guī)則是UDP協(xié)議本身為了防止通信雙方發(fā)現(xiàn)錯誤時的通知機(jī)制，而本發(fā)明則巧妙地利用這個規(guī)則來向客戶端發(fā)起驗證流程。請參考圖5，驗證發(fā)起單元12首先要構(gòu)造一個對于一個客戶端接收來說極其有可能出錯的UDP數(shù)據(jù)報文，其是用來觸發(fā)客戶端發(fā)出ICMP端口不可達(dá)報文的。根據(jù)前面所述的規(guī)則，本發(fā)明要構(gòu)造的UDP數(shù)據(jù)報文可以攜帶一個對客戶端的進(jìn)程來說是一個不存在的 UDP目的端口?？紤]到實際的情況，通常對于剛剛接入網(wǎng)絡(luò)的客戶端來說，其上開啟的進(jìn)程通常很少，這樣一來UDP報文的構(gòu)建方式有很多。比如說，隨機(jī)選擇一個目的端口，因為端口取值范圍是0到65535 ；其導(dǎo)致客戶端發(fā)現(xiàn)UDP端口不存在的概率將非常高，再比如說， 選擇一個不常用的非知名端口 ；再比如說，選擇一個值很大的端口(比如端口 60000)，一般來說即便客戶端的進(jìn)程使用了一些端口，其通常不會使用端口值很大的端口，再比如說，選擇一個端口段(如大于等于50000)。以上列舉的是較為常見的方式，本領(lǐng)域普通技術(shù)人員完全可以根據(jù)協(xié)議的定義來“刻意”制造各種可能的UDP端口不存在的錯誤。進(jìn)一步來說，考慮到攻擊者可能會依葫蘆畫瓢不斷地用偽造的IP地址(即不真實的客戶端)發(fā)送ICMP端口不可達(dá)報文，以欺騙網(wǎng)絡(luò)安全設(shè)備；本發(fā)明進(jìn)一步在構(gòu)造UDP報文的時候，需要在UDP頭部(比如源端口字段)填寫特定的驗證信息，現(xiàn)有技術(shù)已經(jīng)給出了很多驗證信息的生成手段，本發(fā)明采用一種較佳的方式是寫入認(rèn)證信息Cookie的方式，其目標(biāo)是確保U DP報文所攜帶的認(rèn)證信息是唯一，且與客戶端相對應(yīng)；其中Cookie可以根據(jù) IP地址信息按照預(yù)定的算法計算出來。對于本發(fā)明來說，驗證信息設(shè)置在UDP頭部，因為本發(fā)明巧妙利用了協(xié)議的規(guī)定，即一旦UDP報文出現(xiàn)端口錯誤的情況，該出錯報文的UDP頭部將會被攜帶在ICMP不可達(dá)報文中返回來。步驟103，檢查該ICMP端口不可達(dá)報文是否攜帶有所述預(yù)設(shè)的驗證信息，如果是， 則將發(fā)出該報文的客戶端加入到客戶端列表中作為信任客戶端；本步驟由客戶端判決單元 13執(zhí)行。由于步驟102已經(jīng)構(gòu)造了 UDP報文并發(fā)送給客戶端，如果客戶端是真實存在的(在本實施方式中即IP地址是客戶端自身的IP地址)，客戶端收到該報文后發(fā)現(xiàn)該報文的端口與其上運行的進(jìn)程不符合，客戶端協(xié)議棧會自動返回ICMP端口不可達(dá)報文。但是如果客戶端不是真實存在的，即其IP地址沒有對應(yīng)的客戶端的，其實是攻擊者偽造出來的，那么多數(shù)情況下，其并不會回應(yīng)。但是考慮到部分攻擊者可能會刻意構(gòu)造ICMP端口不可達(dá)報文進(jìn)行回應(yīng)，因此上述報文經(jīng)過步驟101被確定為ICMP端口不可達(dá)報文后則送入本步驟進(jìn)行判決。請參考圖 6和圖7，而這個ICMP端口不可達(dá)報文會根據(jù)協(xié)議要求，將安全設(shè)備發(fā)出的UDP報文的UDP 首部攜帶在其中。由于驗證信息就在UDP首部中，因此判決單元收到之后可以將驗證信息提取出來與其在步驟102發(fā)出的驗證信息做比對，如果兩者相同，則客戶端是真實的，可以將該客戶端的IP地址加入到客戶端列表作為信任客戶端，即通常所說的白名單。由于大部分攻擊者并不會回應(yīng)，因此攻擊者偽造的IP地址并不會被加入到客戶端列表中。進(jìn)一步來說，如果發(fā)現(xiàn)驗證信息不同，說明是攻擊者放入的，也可以將其加入客戶端列表，但作為不信任客戶端，即我們通常所說的黑名單。需要補(bǔ)充說明的是，步驟101中如果檢查到發(fā)出報文的客戶端已經(jīng)在客戶端列表，對于信任客戶端則繼續(xù)其他安全處理或者轉(zhuǎn)發(fā)給服務(wù)器，對于不信任客戶端則可以選擇丟棄該報文。步驟104，在將客戶端加入客戶端列表中時，為其創(chuàng)建定時器，在預(yù)定的老化時間到達(dá)時(即定時器超時)，刪除該客戶端對應(yīng)的表項。本步驟由老化處理單元14執(zhí)行。無論是信任客戶端還是不信任客戶端，在客戶端列表中其均需要一個老化時間， 對于信任客戶端其有可能下線，其使用過的IP地址可能被攻擊者利用起來；同樣對于不信任客戶端的IP地址，其有可能被后來新上線的真實客戶端所使用。因此都可以設(shè)置老化時間以在防攻擊以及保護(hù)用戶體驗上取得平衡。本發(fā)明巧妙地利用ICMP協(xié)議來驗證客戶端的真?zhèn)涡?，在兼容?biāo)準(zhǔn)協(xié)議的基礎(chǔ)上實現(xiàn)網(wǎng)絡(luò)安全防護(hù)效果，并不需要客戶端有相應(yīng)的應(yīng)用支持本發(fā)明，整個過程對于客戶端之前的用戶來說是無法感知的，因此其實施成本很低，適用范圍很廣。以上所述僅僅為本發(fā)明較佳的實現(xiàn)方式，任何基于本發(fā)明精神所做出的等同的修改皆應(yīng)涵蓋于本發(fā)明的權(quán)利要求范圍中。
權(quán)利要求
1.一種客戶端驗證裝置，其應(yīng)用于網(wǎng)絡(luò)安全設(shè)備中，用于驗證經(jīng)由所述網(wǎng)絡(luò)安全設(shè)備接入網(wǎng)絡(luò)的客戶端，其中該裝置包括報文檢查單元，用于檢查網(wǎng)絡(luò)安全設(shè)備接收到的報文是否為ICMP端口不可達(dá)報文，如果是，則轉(zhuǎn)客戶端判決單元處理；如果否，則進(jìn)一步檢查發(fā)出報文的客戶端是否存在于客戶端列表中，如果不在，則轉(zhuǎn)驗證發(fā)起單元處理；驗證發(fā)起單元，用于構(gòu)造UDP報文并向客戶端發(fā)出，其中該UDP報文目的端口為客戶端未開放的UDP端口，該UDP報文的UDP頭部攜帶有預(yù)設(shè)的驗證信息，以及客戶端判決單元，用于檢查該ICMP端口不可達(dá)報文是否攜帶有所述預(yù)設(shè)的驗證信息， 如果是，則將發(fā)出該報文的客戶端加入到客戶端列表中作為信任客戶端。
2.根據(jù)權(quán)利要求1所述的裝置，其特征在于，所述UDP報文的目的端口為非知名端口或者端口號大于50000。
3.根據(jù)權(quán)利要求1所述的裝置，其特征在于，還包括老化處理單元，用于在預(yù)定的客戶端老化時間到達(dá)時將客戶端列表中的客戶端刪除。
4.根據(jù)權(quán)利要求1所述的裝置，其特征在于，所述驗證信息是與該客戶端相對應(yīng)的 Cookie認(rèn)證信息。
5.根據(jù)權(quán)利要求1所述的裝置，其特征在于，所述客戶端判決單元進(jìn)一步用于在檢查到所述ICMP端口不可達(dá)報文沒有攜帶所述預(yù)設(shè)的驗證信息時，將所述客戶端加入客戶端列表中作為不信任客戶端。
6.一種客戶端驗證方法，其應(yīng)用于網(wǎng)絡(luò)安全設(shè)備中，用于驗證經(jīng)由所述網(wǎng)絡(luò)安全設(shè)備接入網(wǎng)絡(luò)的客戶端，其中該方法包括A，檢查網(wǎng)絡(luò)安全設(shè)備接收到的報文是否為ICMP端口不可達(dá)報文，如果是，則轉(zhuǎn)步驟C; 如果否，則進(jìn)一步檢查發(fā)出報文的客戶端是否在客戶端列表中，如果不在，則步驟B ；步驟B，其中該UDP報文目的端口為客戶端未開放的UDP端口，該UDP報文的UDP頭部攜帶有預(yù)設(shè)的驗證信息；步驟C，檢查該ICMP端口不可達(dá)報文是否攜帶有所述預(yù)設(shè)的驗證信息，如果是，則將發(fā)出該報文的客戶端加入到客戶端列表中作為信任客戶端。
7.根據(jù)權(quán)利要求6所述的方法，其特征在于，所述UDP報文的目的端口為非知名端口或者端口號大于50000。
8.根據(jù)權(quán)利要求6所述的方法，其特征在于，還包括D，在預(yù)定的客戶端老化時間到達(dá)時將客戶端列表中的客戶端刪除。
9.根據(jù)權(quán)利要求6所述的方法，其特征在于，驗證信息是與該客戶端相對應(yīng)的Cookie 認(rèn)證信息。
10.根據(jù)權(quán)利要求6所述的方法，其特征在于，所述客戶端列表包括信任列表以及不信任列表，步驟C進(jìn)一步包括在檢查到所述ICMP端口不可達(dá)報文沒有攜帶所述預(yù)設(shè)的驗證信息時，將所述客戶端加入不信任列表；在檢查到所述ICMP端口不可達(dá)報文攜帶所述預(yù)設(shè)的驗證信息時，將所述客戶端加入不信任列表。
全文摘要
本發(fā)明提供一種客戶端驗證方法及裝置，其應(yīng)用于網(wǎng)絡(luò)安全設(shè)備中，用于驗證經(jīng)由所述網(wǎng)絡(luò)安全設(shè)備接入網(wǎng)絡(luò)的客戶端。其處理流程包括構(gòu)造UDP報文并向客戶端發(fā)出，其中該報文的UDP頭部攜帶有預(yù)設(shè)的驗證信息；然后檢查客戶端返回的ICMP端口不可達(dá)報文是否攜帶有所述預(yù)設(shè)的驗證信息，如果是，則將發(fā)出該報文的客戶端加入到客戶端列表中作為信任客戶端。本發(fā)明在兼容現(xiàn)有標(biāo)準(zhǔn)協(xié)議的基礎(chǔ)上，實現(xiàn)了用戶客戶端真?zhèn)蔚呐袛?，有效了提高了網(wǎng)絡(luò)安全防護(hù)的效果。
文檔編號H04L29/06GK102231748SQ201110219058
公開日2011年11月2日 申請日期2011年8月2日 優(yōu)先權(quán)日2011年8月2日
發(fā)明者汪慶權(quán) 申請人:杭州迪普科技有限公司