專利名稱：一種dhcp防攻擊方法及裝置的制作方法
技術領域：
本發(fā)明 涉及網絡安全技術，尤其涉及一種DHCP防攻擊方法及裝置。
背景技術：
IP網絡是目前也是未來相當長一段時間內最為流行的網絡組織方式。IP網絡中的所有設備如果要同其它設備通信，就必須有唯一的身份，即IP地址。目前給設備配置IP地址的方法有PPP協(xié)議的自協(xié)商方式、用戶自己配置、管理員統(tǒng)一分配配置方式，但是這些配置方式存在著共同缺陷，即需要管理員針對每個設備進行配置。當網絡規(guī)模較大及拓撲結構復雜或者網絡拓撲結構動態(tài)變化頻繁時，或者許多終端設備需要更多的啟動配置信息時，管理員的配置工作將力不從心，于是新的終端設備配置方式應運而生，即DHCP(DynamicHost Configuration Protocol)動態(tài)主機配置協(xié)議。該協(xié)議采用CS模式(客戶端-服務器模式)，DHCP服務器集中管理IP地址等網絡配置信息，DHCP客戶端從DHCP服務器請求各自配置信息，從而實現(xiàn)網絡設備的自動配置。然而如果網絡中存在非法DHCP服務器，其可能會提供虛假配置信息，由于DHCP客戶端沒有采取任何安全措施，很可能綁定到錯誤的配置信息，導致設備不能正常訪問網絡；甚至可能引發(fā)泄密等風險。

發(fā)明內容
有鑒于此，本發(fā)明提供一種DHCP防攻擊裝置，應用于作為DHCP客戶端的網絡設備上，該裝置包括信息緩存單元以及比較分析單元，其中信息緩存單元，用于保存DHCP客戶端接收到的DHCP Offer報文和/或DHCP ACK報文攜帶的信息，其中該信息至少包括報文的源IP地址以及服務器標識；比較分析單元，用于比較同一個報文的源IP地址與服務器標識是否一致，如果不一致則確定該報文是攻擊者發(fā)送的。本發(fā)明還提供一種DHCP防攻擊方法，應用于作為DHCP客戶端的網絡設備上，該方法包括以下步驟A、保存DHCP客戶端接收到的DHCP Offer報文和/或DHCP ACK報文攜帶的信息，其中該信息至少包括報文的源IP地址以及服務器標識；B、比較同一個報文的源IP地址與服務器標識是否一致，如果不一致則確定該報文是攻擊者發(fā)送的。本發(fā)明充分利用DHCP交互過程的特點來防范DHCP攻擊，通過各種手段大幅度降低了 DHCP客戶端被攻擊的可能性。即便攻擊者的DHCP ACK報文被DHCP客戶端所接受，本發(fā)明仍然有一種或多種的輔助手段來幫助用戶識別出攻擊行為。


圖I是一個典型的DHCP的交互過程示意圖。
圖2是本發(fā)明一種實施方式中DHCP防攻擊裝置的邏輯結構圖。
具體實施例方式請參考圖1，一般情況下，需要進行配置的網絡設備可以通過與DHCP服務器進行兩次報文交互實現(xiàn)自身配置。本發(fā)明所說的網絡設備并非狹義的交換機及路由器等設備，而是涵蓋一切網絡中所有需要獲取IP地址以及相關網絡配置的節(jié)點。在與DHCP服務器交互的過程中，首先作為DHCP客戶端的網絡設備向網絡中發(fā)送廣播的DHCP Discover報文，攜帶DHCP客戶端關心的配置信息列表，DHCP服務器根據(jù)DHCP客戶端請求的配置信息列表，在DHCP Offer報文填充自身管理的IP地址資源及其它配置信息，以廣播(多數(shù)情況)或者單播(少數(shù)情況)的方式回送給DHCP客戶端。由于網絡中可能存在多個DHCP服務器，因此DHCP客戶端可能會收到多個DHCPOffer報文。DHCP客戶端可以從中選取某個DHCP服務器發(fā)送DHCP Offer報文(通常是第一個到達的DHCP Offer報文)。接下來DHCP客戶端構建DHCP Request報文，指定服務器 標識(一般是DHCP服務器的IP地址)，向網絡中廣播此報文，這樣網絡中多個DHCP服務器都可能會受到只有匹配上服務器標識的DHCP服務器才會回應一個DHCP ACK報文(報文內容基本等同于DHCP Offer報文)，DHCP客戶端以此報文內容綁定配置信息，完成自身配置。本發(fā)明利用DHCP交互過程的特點來協(xié)助網絡設備檢測出DHCP攻擊。請參考圖2，以計算機程序實現(xiàn)為例，本發(fā)明一種實施方式中的DHCP防攻擊裝置包括信息緩存單元以及分析比較單元；該裝置運行于作為DHCP客戶端的網絡設備上，且在客戶端一次DHCP過程中執(zhí)行如下步驟步驟101，信息緩存單元在DHCP客戶端收到DHCP Offer報文時將該DHCPOffer報文攜帶的各種信息進行緩存，緩存的信息至少包括Option字段中的服務器標識(ServerID)以及該DHCP Offer報文的源IP地址；步驟102，信息緩存單元在DHCP客戶端收到DHCP ACK報文時將該DHCP ACK報文攜帶的各種信息進行緩存，緩存的信息至少包括Option字段中的服務器標識(ServerID)以及該DHCP ACK報文的源IP地址；在DHCP交互過程中，DHCP Offer報文以及DHCP ACK報文是由DHCP服務器發(fā)送的，本發(fā)明需要將這兩個報文的相關信息保存下來(甚至可以整個報文都保存下來)進行后續(xù)的分析。通常情況下，除了報文源IP地址以及Option字段(通常為0ption54)的ServerID,還可以保存報文的源MAC地址、DHCP ACK報文攜帶的DNS服務器地址、DHCP ACK報文攜帶的網關IP地址等。步驟103，比較分析單元比較DHCP Offer報文中攜帶的服務器標識與DHCP Offer報文的源IP地址，如果兩者不一致則確定網絡中存在DHCP攻擊，并將該DHCP Offer報文的源IP地址作為攻擊源報告給用戶；步驟104，比較分析單元比較DHCP ACK報文中的服務器標識與DHCPACK報文的源IP地址，如果兩者不一致則確定網絡中存在DHCP攻擊，并將該DHCP ACK報文的源IP地址作為攻擊源報告給用戶；DHCP攻擊者可能會采用構造DHCP Offer或DHCP ACK報文的方式，攻擊者可能會大量發(fā)送其構造的DHCP Offer或DHCP ACK報文，很多時候其構造的報文載荷部分都是一樣的，尤其是ServerID可能是隨意填寫的與攻擊者的源IP地址并不一致。因此本發(fā)明可以通過比較DHCP Offer報文或DHCP ACK報文中源IP地址與ServerID的一致性來判斷該報文是否為攻擊者發(fā)送，如果不一致則可以確定為攻擊者發(fā)送的DHCP Offer報文或DHCPACK報文。步驟105，在DHCP Offer報文中的服務器標識與DHCP Offer報文的源IP地址相同且DHCP ACK報文中的服務器標識與DHCP ACK報文的源IP地址相同時，比較分析單元進一步比較DHCP ACK報文與接受的DHCP Offer報文攜帶的服務器標識和/或源MAC地址是否一致，如果任意一個不一致則確定該DHCP ACK報文是攻擊者發(fā)送的，并將比較結果報告
給用戶。步驟106，比較分析單元向DHCP ACK報文攜帶的網關IP地址發(fā)送ARP請求報文，如果預定時間內沒有收到相應的ARP應答，則確定該DHCP ACK報文是攻擊者發(fā)送的；步驟107，比較分析單元向DHCP ACK報文中攜帶的DNS服務器IP地址發(fā)送針對預 定域名的解析請求，如果在預定時間內沒有收到解析結果或者收到的解析結果與預先保存的該預定域名的解析結果不一致，則確定該DHCP ACK報文是攻擊者發(fā)送的。步驟108，比較分析單元進一步判斷DHCP ACK報文中分配給DHCP客戶端的IP地址與該DHCP ACK報文的源IP地址是否在同一網段，如果是且網絡中存在DHCP中繼時確定該DHCP ACK報文是攻擊者發(fā)送的；如果否且網絡中不存在DHCP中繼時確定該DHCP ACK報文是攻擊者發(fā)送的。高明的攻擊者可能會在構造報文的過程中確保報文的源IP地址與Server ID保持一致，以期望騙過防攻擊機制。本發(fā)明對此有進一步的防范措施，攻擊者的特點往往是大量構造相同或者相近的報文以企圖插入到正常的DHCP交互過程中來。假設攻擊者發(fā)送的DHCP ACK報文先于合法DHCP服務器到達DHCP客戶端，那么DHCP客戶端可能被欺騙?？紤]到這種情形，本發(fā)明可以進一步做驗證。如前所述，DHCP客戶端可能會接收到多個DHCPOffer報文，但通常只有一個(一般是第一個到達的)DHCP Offer報文會被DHCP客戶端接受，而本次DHCP過程中后續(xù)到來的DHCP ACK報文通常也是發(fā)送這個被接受的DHCP Offer報文的DHCP服務器發(fā)出的，也就是說DHCPACK報文以及DHCP Offer報文是同一個DHCP服務器發(fā)出的。由于信息緩存單元緩存了被接受的DHCP Offer報文的ServerID以及源MAC地址，此時可以將DHCP ACK報文的ServerID和/或源MAC地址拿出來與DHCP Offer報文的做對比。假設同時對比ServerID以及源MAC地址，如果ServerID或源MAC地址有任何一個不相同，說明DHCP Offer報文與DHCP ACK報文是不同的DHCP服務器發(fā)出的，不符合正常的DHCP交互流程，因此可以判定存在網絡攻擊。值得注意的是，由于攻擊者并不知道到底哪個DHCP Offer報文會被DHCP客戶端所接受，因為哪個DHCP服務器發(fā)送的DHCP Offer報文會第一個到達DHCP客戶端是無法預計的，其受制于DHCP服務器負荷以及中間網絡狀況等多種未知因素，因此即便攻擊者知曉所有DHCP服務器的IP地址，也無法進行有針對性的攻擊來規(guī)避上述比較DHCP Offer報文與DHCP ACK報文的機制。進一步來說，考慮到DHCP服務器的數(shù)量是有限的，攻擊者雖然難度大大加大，且效果大打折扣，但理論上仍然有少數(shù)攻擊行為會成功的可能性。為了進一步規(guī)避攻擊成功所帶來的危害，本發(fā)明的分析比較單元進一步向DHCP ACK報文中的網關IP地址發(fā)起ARP請求，看看是否能夠正常收到ARP應答，也就是說確定一下對方的MAC地址是不是像正常的節(jié)點那樣是一個可達的MAC地址。由于攻擊者構造的網關IP地址通常是虛構的，不會有完整的協(xié)議棧(否則將大量消耗攻擊者的資源)，因此不會對ARP請求進行應答。因此針對DHCPACK報文攜帶的網關IP地址進行ARP驗證，可以進一步規(guī)避攻擊者成功的可能性?；谕瑯拥臉嬎迹景l(fā)明的分析比較單元，還可以根據(jù)向DHCP ACK報文中攜帶的DNS服務器IP地址發(fā)起DNS解析進行DNS服務器有效性的驗證。網絡設備上可以預先配置一個域名的解析結果，比如一個公共域名(如WWW. gov. cn)的解析結果,然后想這個預定的域名發(fā)起解析，如果解析結果不正確(即與預先保存的解析結果不同)，則可以確定DNS服務器無效，相應地可以確定DHCP ACK報文是攻擊者發(fā)送的。此外，如果DHCP服務器相對于DHCP客戶端來說工作在另一個廣播域中，此時需要DHCP中繼中轉DHCP Discover報文。因此采取比較報文源IP同分配給用戶的IP地址是否在同一網段可以用來識別攻擊報文。如果網絡中存在中繼，則上述兩個IP地址不能在同一網段，否則必須為同一網段。這種識別攻擊的手段通常應用在客戶端所在廣播域中不存在多臺可做網關設備的三層設備的組網環(huán)境中。 本發(fā)明充分利用DHCP交互過程的特點來防范DHCP攻擊，通過各種手段大幅度降低了 DHCP客戶端被攻擊的可能性。即便攻擊者的DHCP ACK報文被DHCP客戶端所接受，本發(fā)明仍然有一種或多種的輔助手段來幫助用戶識別出攻擊行為。以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明，凡在本發(fā)明的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本發(fā)明保護的范圍之內。
權利要求
1.ー種DHCP防攻擊裝置，應用于作為DHCP客戶端的網絡設備上，該裝置包括信息緩存單元以及比較分析単元，其特征在于 信息緩存單元，用于保存DHCP客戶端接收到的DHCP Offer報文和/或DHCP ACK報文攜帯的信息，其中該信息至少包括報文的源IP地址以及服務器標識； 比較分析単元，用于比較同一個報文的源IP地址與服務器標識是否一致，如果不一致則確定該報文是攻擊者發(fā)送的。
2.如權利要求I所述的裝置，其特征在于，所述比較分析単元，進ー步用于比較被DHCP客戶端接受的DHCP Offer報文與本次DHCP過程中收到的DHCP ACK報文的服務器標識是否一致；如果不一致則確定該DHCP ACK報文是攻擊者發(fā)送的；和/或 進ー步用于比較被DHCP客戶端接受的DHCP Offer報文與DHCP ACK報文的源MAC地址是否一致，如果不一致則確定該DHCP ACK報文是攻擊者發(fā)送的。
3.如權利要求I所述的裝置，其特征在于，所述比較分析單元進一步用于向DHCPACK報文中攜帯的網關IP地址發(fā)送ARP請求，如果在預定的時間內沒有收到相應的ARP應答，則確定該DHCP ACK報文是攻擊者發(fā)送的。
4.如權利要求I所述的裝置，其特征在于，所述比較分析單元進一步用于向DHCPACK報文中攜帯的DNS服務器IP地址發(fā)送針對預定域名的域名解析請求，如果在預定時間內沒有收到解析結果或者收到的解析結果與預先保存的該預定域名的解析結果不一致，則確定該DHCP ACK報文是攻擊者發(fā)送的。
5.如權利要求I所述的裝置，其特征在于，所述比較分析單元進一步用于判斷DHCPACK報文中分配給DHCP客戶端的IP地址與該DHCP ACK報文的源IP地址是否在同一網段，如果是且網絡中存在DHCP中繼時確定該DHCP ACK報文是攻擊者發(fā)送的；如果否且網絡中不存在DHCP中繼時確定該DHCP ACK報文是攻擊者發(fā)送的。
6.ー種DHCP防攻擊方法，應用于作為DHCP客戶端的網絡設備上，其特征在于，該方法包括以下步驟 A、保存DHCP客戶端接收到的DHCPOffer報文和/或DHCP ACK報文攜帶的信息，其中該信息至少包括報文的源IP地址以及服務器標識； B、比較同一個報文的源IP地址與服務器標識是否一致，如果不一致則確定該報文是攻擊者發(fā)送的。
7.如權利要求6所述的方法，其特征在于，所述步驟B進ー步包括比較被DHCP客戶端接受的DHCP Offer報文與本次DHCP過程中收到的DHCPACK報文的服務器標識是否一致；如果不一致則確定該DHCP ACK報文是攻擊者發(fā)送的；和/或 進ー步用于比較被DHCP客戶端接受的DHCP Offer報文與DHCP ACK報文的源MAC地址是否一致，如果不一致則確定該DHCP ACK報文是攻擊者發(fā)送的。
8.如權利要求6所述的方法，其特征在于，所述步驟B進ー步包括向DHCPACK報文中攜帯的網關IP地址發(fā)送ARP請求，如果在預定的時間內沒有收到相應的ARP應答，則確定該DHCP ACK報文是攻擊者發(fā)送的。
9.如權利要求6所述的方法，其特征在于，所述步驟B進ー步包括向DHCPACK報文中攜帯的DNS服務器IP地址發(fā)送針對預定域名的域名解析請求，如果在預定時間內沒有收到解析結果或者收到的解析結果與預先保存的該預定域名的解析結果不一致，則確定該DHCPACK報文是攻擊者發(fā)送的。
10.如權利要求6所述的方法，其特征在于，所述步驟B進ー步包括判斷DHCP ACK報文中分配給DHCP客戶端的IP地址與該DHCP ACK報文的源IP地址是否在同一網段，如果是且網絡中存在DHCP中繼時確定該DHCP ACK報文是攻擊者發(fā)送的；如果否且網絡中不存在DHCP中繼時確定該DHCP ACK報文是攻擊者發(fā)送的。
全文摘要
本發(fā)明提供一種DHCP防攻擊方法，應用于作為DHCP客戶端的網絡設備上，該方法包括A、保存DHCP客戶端接收到的DHCP Offer報文和/或DHCP ACK報文攜帶的信息，其中該信息至少包括報文的源IP地址以及服務器標識；B、比較同一個報文的源IP地址與服務器標識是否一致，如果不一致則確定該報文是攻擊者發(fā)送的。本發(fā)明充分利用DHCP交互過程的特點來防范DHCP攻擊，通過各種手段大幅度降低了DHCP客戶端被攻擊的可能性。
文檔編號H04L29/12GK102801716SQ20121027195
公開日2012年11月28日 申請日期2012年8月1日 優(yōu)先權日2012年8月1日
發(fā)明者余剛 申請人:杭州迪普科技有限公司