專利名稱：防攻擊的無線控制系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及無線局域網(wǎng)(WLAN)領(lǐng)域，更具體地說，涉及一種WLAN中基于瘦無線接 入點(AP)架構(gòu)的防攻擊無線控制系統(tǒng)。
背景技術(shù)：
無線接入點(AP，ACCeSS Point)也稱無線網(wǎng)橋、無線網(wǎng)關(guān)。所謂“瘦”AP的傳輸機 制相當(dāng)于有線網(wǎng)絡(luò)中的集線器，在無線局域網(wǎng)中不停地接收和傳送數(shù)據(jù)，任何一臺裝有無 線網(wǎng)卡的PC均可通過AP來分享有線局域網(wǎng)絡(luò)甚至廣域網(wǎng)絡(luò)的資源。理論上，當(dāng)網(wǎng)絡(luò)中增加 一個無線AP之后，即可成倍地擴展網(wǎng)絡(luò)覆蓋直徑，還可使網(wǎng)絡(luò)中容納更多的網(wǎng)絡(luò)設(shè)備。每 個無線AP基本上都擁有一個以太網(wǎng)接口，用于實現(xiàn)無線與有線的連接。所謂“胖” AP與純 AP不同，除無線接入功能外，一般還具備WAN、LAN兩個接口，大多數(shù)胖AP還支持DHCP服務(wù) 器、DNS和MAC地址克隆、VPN接入、防火墻等安全功能。WLAN的產(chǎn)品架構(gòu)已經(jīng)從單一自治的AP(胖AP)演進(jìn)到由無線控制器(AC)和AP(瘦 AP)共同構(gòu)成的集中控制體系。這種演進(jìn)的目的是將訪問控制將訪問控制，包括鑒別、保密 通信、移動管理、射頻管理等從單一 AP上分離，由AC加以集中控制。CAPWAP 協(xié)議是 Internet 工程任務(wù)組(IETF，Internet Engineering Task Force) 提出的一種WLAN集中控制體系結(jié)構(gòu)框架協(xié)議，該協(xié)議使AC能夠集中控制AP，并且能夠?qū)?AP的信道/功率/漫游/安全策略等進(jìn)行統(tǒng)一控制管理。這種架構(gòu)的特點是成本低，管理 簡單，網(wǎng)絡(luò)安全性高。在現(xiàn)有的采用CAPWAP協(xié)議的基于瘦AP架構(gòu)的WLAN中，AC對capwap發(fā)現(xiàn)請求 (capwap discovery request)報文進(jìn)行限速處理，在固定時間內(nèi)只處理固定個數(shù)的capwap 發(fā)現(xiàn)請求報文，確保不會由于處理大量的capwap發(fā)現(xiàn)請求而加大AC性能壓力，影響其它業(yè) 務(wù)模塊正常運行。但是這種架構(gòu)的WLAN無法抵御發(fā)現(xiàn)請求DOS攻擊。例如，惡意攻擊者可向AC發(fā) 送大量capwap發(fā)現(xiàn)請求。AC必須一一處理每條發(fā)現(xiàn)請求，從而導(dǎo)致AC無法正常處理來自 AP的發(fā)現(xiàn)請求，造成AC的性能惡化直至無法工作。

發(fā)明內(nèi)容
本發(fā)明的示例性實施例克服了上述的缺點和其他上面沒有描述的缺點。同樣地， 本發(fā)明無需克服上述缺點，而且本發(fā)明的示例性實施例可以不克服上述的任何問題。根據(jù)本發(fā)明的一方面，提供了一種用于瘦AP架構(gòu)的防攻擊無線控制器，包括協(xié) 議處理單元，與無線接入點AP按照預(yù)定協(xié)議進(jìn)行通信；防攻擊單元，通過口令機制來驗證 AP的注冊請求的合法性，更新防攻擊表，并將合法的AP的注冊請求上送給協(xié)議處理單元， 其中，所述防攻擊表中記錄了 AP的IP地址、為AP分配的口令以及AP的認(rèn)證狀態(tài)。根據(jù)本發(fā)明的一方面，還提供了一種用于瘦AP架構(gòu)的 防攻擊無線控制系統(tǒng)，包 括DHCP服務(wù)器，為AP分配IP地址，在為AP分配IP地址后將AP的信息通知給與AP對應(yīng)的無線控制器，通知AP向無線控制器發(fā)送注冊請求；無線控制器，包括協(xié)議處理單元，與 無線接入點AP按照預(yù)定協(xié)議進(jìn)行通信；防攻擊單元，通過口令機制來驗證AP的注冊請求 的合法性，更新用于記錄AP合法性狀態(tài)的防攻擊表，并將合法的AP的注冊請求上送給協(xié)議 處理單元，其中，所述防攻擊表中記錄了 AP的IP地址、為AP分配的口令以及AP的認(rèn)證狀 態(tài)，防攻擊單元根據(jù)注冊請求的口令和認(rèn)證狀態(tài)來驗證注冊請求是否合法；硬件ACL單元， 從DHCP服務(wù)器獲得由DHCP服務(wù)器分配了 IP地址的AP的信息，并僅允許將該AP所發(fā)起的 注冊請求上送給防攻擊單元。根據(jù)本發(fā)明的另一方面，還提供了一種防攻擊的無線控制系統(tǒng)，包括DHCP服務(wù) 器，為無線接入點AP分配IP地址，將在為AP分配IP地址后將AP的信息通知給與AP對 應(yīng)的第一無線控制器，通知AP向所述對應(yīng)的第一無線控制器發(fā)送注冊請求；第二無線控制 器，用于與通過第一無線控制器驗證的AP按照預(yù)定協(xié)議進(jìn)行通信；第一無線控制器，包括 防攻擊單元，通過口令機制來驗證AP的注冊請求的合法性，更新用于記錄AP合法性狀態(tài)的 防攻擊表，并將合法的AP的注冊請求上送給第二無線控制器，其中，所述防攻擊表中記錄 了 AP的IP地址、為AP分配的口令以及AP的認(rèn)證狀態(tài)；硬件ACL單元，從DHCP服務(wù)器獲得 由DHCP服務(wù)器分配了 IP地址的AP的信息，并僅允許將該AP所發(fā)起的注冊請求上送給防 攻擊單元。根據(jù)本發(fā)明的另一方面，還提供了一種防攻擊的無線控制系統(tǒng)，包括第二無線控 制器，用于與通過第一無線控制器驗證的AP按照預(yù)定協(xié)議進(jìn)行通信；第一無線控制器，包 括防攻擊單元，通過口令機制來驗證無線接入點AP的注冊請求的合法性，更新用于記錄 AP合法性狀態(tài)的防攻擊表，并將合法的AP的注冊請求發(fā)送給第二無線控制器，其中，所述 防攻擊表中記錄了 AP的IP地址、為AP分配的口令以及AP的認(rèn)證狀態(tài)。


通過下面結(jié)合附圖對實施例的詳細(xì)描述，本發(fā)明的上述和/或其他方面將會變得 清楚和更容易理解，其中圖1是示出根據(jù)本發(fā)明實施例的無線控制器(AC)的結(jié)構(gòu)模型的示意圖。圖2是根據(jù)本發(fā)明實施例的無線控制器的結(jié)構(gòu)模型的另一示意圖。圖3示出的是根據(jù)本發(fā)明實施例的基于路由器架構(gòu)的防攻擊系統(tǒng)及其操作步驟 的示意圖。圖4示出的是根據(jù)本發(fā)明實施例的基于交換機的防攻擊系統(tǒng)及其操作步驟的示 意圖。圖5是示出根據(jù)本發(fā)明實施例的基于交換機的集群模型的防攻擊系統(tǒng)及其操作 的示意圖。圖6是示出根據(jù)本發(fā)明實施例的基于路由器的集群模型的防攻擊系統(tǒng)及其操作 的示意圖。
具體實施例方式下面將參照附圖詳細(xì)描述根據(jù)本發(fā)明實施例的基于瘦AP架構(gòu)的防攻擊方法。在 整個附圖中，相同的標(biāo)號用于表示相同或相似的部分。為了清楚和簡明，會省略已知功能和結(jié)構(gòu)的詳細(xì)描述以避免使得本發(fā)明的主題模糊。圖1是示出根據(jù)本發(fā)明實施例的無線控制器(AC)的結(jié)構(gòu)模型的示意圖。根據(jù)本 發(fā)明的AC —般可基于交換機或者路由器架構(gòu)。如圖1所示，基于交換機架構(gòu)的AC的結(jié)構(gòu) 從上至下包括五層應(yīng)用層、OS協(xié)議棧層、驅(qū)動層、收包中斷層和交換芯片層。報文從最底 層逐層上報。如果是嵌入式系統(tǒng)，則應(yīng)用層可融入OS協(xié)議棧中?；诼酚善骷軜?gòu)的AC相 對于基于交換機架構(gòu)只是少了最底層的交換芯片。對于特定的協(xié)議處理，AC的結(jié)構(gòu)可以簡化為如圖2所示的結(jié)構(gòu)示意圖。如圖2所 示，基于交換機架構(gòu)的AC包括協(xié)議處理單元、協(xié)議防攻擊單元和硬件訪問控制列表(ACL) 單元。其中，硬件ACL單元的功能由交換芯片完成。協(xié)議防攻擊單元在收包中斷層中實現(xiàn)。 協(xié)議處理單元(以下簡稱為防攻擊單元)在應(yīng)用層或OS協(xié)議棧層中實現(xiàn)。相對于基于交 換機架構(gòu)的AC，基于路由器架構(gòu)的AC可以不包括硬件ACL單元。在本發(fā)明中，WLAN的組網(wǎng) 形式可包括兩種模型單機模型和集群模型。每一種模型都可包括基于交換機的架構(gòu)和基 于路由器的架構(gòu)。下面將分別介紹基于交換機和路由器的單機模型的防攻擊系統(tǒng)以及基于 交換機和路由器的集群模型的防攻擊系統(tǒng)。圖3示出的是根據(jù)本發(fā)明實施例的基于路由器架構(gòu)的防攻擊系統(tǒng)及其操作步驟的示意圖。圖3的防攻擊系統(tǒng)包括AP和AC。在以下說明中，AP與AC之間采用CAPWAP協(xié) 議進(jìn)行通信。應(yīng)理解，雖然本發(fā)明以CAPWAP協(xié)議作為示例進(jìn)行描述，但是本領(lǐng)域的技術(shù)人 員應(yīng)理解本發(fā)明可應(yīng)用于使用其他無線通信協(xié)議進(jìn)行通信的AP和AC架構(gòu)。如圖3所示，根據(jù)本發(fā)明實施例的AC包括協(xié)議處理單元和防攻擊單元。其中，協(xié) 議處理單元用于按照預(yù)定的CAPWAP協(xié)議處理與AP交換的通信數(shù)據(jù)。防攻擊單元通過口令 (challenge)機制來驗證AP的合法性，更新用于記錄AP合法性狀態(tài)的防攻擊表，并將合法 的AP的通信請求上送給協(xié)議處理單元。也就是說，僅當(dāng)AP的通信請求通過了防攻擊單元 的驗證之后，才將注冊請求上送給協(xié)議處理單元并按照協(xié)議進(jìn)行處理。下面將詳細(xì)介紹根 據(jù)本發(fā)明實施例的基于路由器架構(gòu)的防攻擊系統(tǒng)的操作。首先，在步驟110，AP向AC發(fā)起用于注冊的capwap發(fā)現(xiàn)請求(capwapdiscovery request)。接下來，在步驟120，AC的防攻擊單元使用口令機制來驗證該AP的capwap發(fā)現(xiàn)請 求的合法性，并更新防攻擊表。下面將具體地介紹根據(jù)本發(fā)明實施例的口令機制和防攻擊表。防攻擊單元上保存了一個防攻擊表(表A)，該表格初始為空，表項內(nèi)容包括請求 者IP地址、請求者口令(challenge)和認(rèn)證狀態(tài)。請求者IP指示向AC發(fā)送capwap發(fā)現(xiàn) 請求的IP地址。在本實施例中，請求者口令是AC為請求者分配的隨機數(shù)字。當(dāng)然，本領(lǐng)域 的技術(shù)人員應(yīng)理解，可以采用其他口令機制來驗證請求者的合法性。認(rèn)證狀態(tài)指示請求者 的認(rèn)證狀態(tài)，其值可表示未認(rèn)證、認(rèn)證中和已認(rèn)證。表 A 防攻擊單元接收到capwap發(fā)現(xiàn)請求之后，檢查該請求中是否攜帶了 口令，即，是 否攜帶了隨機數(shù)。如果防攻擊單元確定capwap發(fā)現(xiàn)請求中沒有攜帶口令，則防攻擊單元 使用capwap發(fā)現(xiàn)請求的源IP地址來查找表A。如果沒有查找到與該源IP地址對應(yīng)的表 項，則生成與該請求的源IP對應(yīng)的表項，將其認(rèn)證狀態(tài)設(shè)置為未認(rèn)證，并設(shè)置一個超時時 間(例如，3秒)。防攻擊單元隨機生成一個隨機數(shù)作為口令，并在步驟130向請求者AP回 復(fù)capwap發(fā)現(xiàn)響應(yīng)(capwap discovery response),其中，在該響應(yīng)中包括該隨機數(shù)。如果 超過設(shè)置的時間之后AP沒有重新發(fā)送攜帶口令的capwap發(fā)現(xiàn)請求，即，該表項的認(rèn)證狀態(tài) 未變?yōu)椤罢J(rèn)證中”，則防攻擊單元刪除該表項。如果防攻擊單元檢查到與請求的源IP地址相 應(yīng)的表項，則執(zhí)行以下操作(1)如果該表項的狀態(tài)為“未認(rèn)證”或“認(rèn)證中”，則根據(jù)策略，防攻擊單元可選擇 丟棄該capwap發(fā)現(xiàn)請求或?qū)⒃撜埱笊纤徒o協(xié)議處理單元。由于防攻擊表中已經(jīng)存在與該 源IP地址對應(yīng)的表項，則證明該IP地址已經(jīng)發(fā)送過請求，這個請求可能是AP超時重發(fā)的 請求，也有可能是攻擊者偽裝成AP發(fā)送的請求。因此，可根據(jù)管理員的策略選擇丟棄或者 上送該請求。(2)如果該表項的狀態(tài)是“已認(rèn)證”，則防攻擊單元丟棄該capwap發(fā)現(xiàn)請求(此時 與該源IP地址對應(yīng)的AP已經(jīng)通過認(rèn)證，可認(rèn)為該請求是非法的)。如果防攻擊單元檢查到capwap請求攜帶了口令，則防攻擊單元使用發(fā)送請求者 的源IP查找表A。如果在防攻擊表中沒有查找到與請求者IP對應(yīng)的表項，則防攻擊單元丟 棄該capwap發(fā)現(xiàn)請求。如果在表A中找到了與該源IP對應(yīng)的表項，則防攻擊單元執(zhí)行與 下表對應(yīng)的操作。表 B 從上表可以看出，當(dāng)表項的狀態(tài)為“未認(rèn)證”時，防攻擊單元檢查口令是否匹配。如 果匹配，則進(jìn)行到步驟150，防攻擊單元將capwap發(fā)現(xiàn)請求上送協(xié)議處理單元，修改認(rèn)證狀 態(tài)為“認(rèn)證中”，并設(shè)定一超時時間(例如，30秒)。若超過此超時時間之后協(xié)議處理單元沒 有通知防攻擊單元已經(jīng)與AP建立了通信，即，認(rèn)證狀態(tài)未變?yōu)椤耙颜J(rèn)證”，則協(xié)議處理單元 通知防攻擊單元刪除此表項。如果不匹配，則丟棄capwap發(fā)現(xiàn)請求。而當(dāng)表項的狀態(tài)不是 “未認(rèn)證”時(即，處于“認(rèn)證中”和“已認(rèn)證”時)，防攻擊單元不檢查口令是否匹配，直接丟 棄該capwap發(fā)現(xiàn)請求。通過以上處理，可以抵御攻擊者模擬AP地址進(jìn)行的capwap發(fā)現(xiàn)請求DOS攻擊。接下來，在AP接收到攜帶口令的capwap發(fā)現(xiàn)響應(yīng)之后，解析該響應(yīng)并提取其中的 隨機數(shù)，并在步驟140重新發(fā)送攜帶的隨機數(shù)的capwap發(fā)現(xiàn)請求到AC。然后，防攻擊單元重復(fù)步驟120中的驗證過程，并在步驟150將通過了 口令驗證的 capwap發(fā)現(xiàn)請求上送到協(xié)議處理單元。AC的協(xié)議處理單元接收到capwap發(fā)現(xiàn)請求之后，按照capwap協(xié)議(RFC5415)與 AP進(jìn)行正常的協(xié)議交互。此時，當(dāng)AP進(jìn)入rim (運行)狀態(tài)之后，在步驟160，AC的協(xié)議處 理單元向防攻擊單元下發(fā)指令，將防攻擊表中與AP對應(yīng)的表項的認(rèn)證狀態(tài)修改為已認(rèn)證。最后，如果AC檢測到AP異常下線，或者AC指示AP重啟后，在步驟170，AC的協(xié)議 處理單元向防攻擊單元下發(fā)指令以刪除防攻擊表中與AP對應(yīng)的表項。圖4示出的是根據(jù)本發(fā)明實施例的基于交換機的防攻擊系統(tǒng)及其操作步驟的示 意圖。與圖3的WLAN結(jié)構(gòu)不同，圖4中的瘦AP架構(gòu)的WLAN包括AP、DHCP服務(wù)器和AC。 AC除了圖3所示的協(xié)議處理單元和防攻擊單元之外，還包括硬件ACL單元。硬件ACL單元 用于從DHCP服務(wù)器獲得合法的AP的IP地址，并允許合法的AP發(fā)起注冊請求。DHCP服務(wù) 器可以與AC位于同一物理實體上。DHCP服務(wù)器在其相應(yīng)地址池中配置如表C所示的AC地 址映射表，其中，關(guān)鍵字為DHCP option 60信息。一般情況下，AP與AC為同一廠家，一個 廠家的AC只能管理自己廠家的AP。通過如表C所示的AC地址映射表，可保證當(dāng)同一個廠 家的AP向DHCP服務(wù)器申請地址成功之后，DHCP服務(wù)器能夠?qū)⑸暾埑晒Φ南⑼ㄖ粡S家的AC。表C 在通常情況下，AC的協(xié)議處理單元向硬件ACL單元下發(fā)一條ACL，指示硬件ACL單 元丟棄capwap發(fā)現(xiàn)請求報文。這樣的目的在于保證AC只接收預(yù)定源地址的capwap發(fā)現(xiàn) 請求報文，從而可抵御攻擊者進(jìn)行源地址變化的攻擊。下面將參照圖4詳細(xì)描述根據(jù)本發(fā) 明實施例的基于交換機的防攻擊系統(tǒng)及其操作。首先，在步驟210，AP 將 DHCP 發(fā)現(xiàn)請求(DHCP discovery request)發(fā)送到 DHCP 服務(wù)器。在該請求中攜帶了 DHCP option 60。根據(jù)RFC21329. 13規(guī)范，DHCP option 60可 以被DHCP客戶端用來做為辨識供貨商與DHCP客戶端的兼容性識別。DHCP服務(wù)器收到DHCP發(fā)現(xiàn)請求后，在步驟215，DHCP服務(wù)器向AP回復(fù)DHCP要約 (DHCP offer)。在收到DHCP要約之后，在步驟220，AP向DHCP服務(wù)器發(fā)送DHCPrequest請求以請 求DHCP服務(wù)器為其分配IP地址，在該請求中攜帶了 DHCPoption 60，此處的DHCP option 60的內(nèi)容與步驟210中的DHCP發(fā)現(xiàn)請求攜帶的DHCP option 60的內(nèi)容一致。DHCP服務(wù)器收到DHCP request后，解析出DHCP option 60中的信息，使用DHCP option 60的信息查找AC地址映射表。如果查到與DHCP option 60對應(yīng)的AC地址列表，則 將該AC地址列表以私有格式封裝到DHCP option 43中，為AP分配IP地址(記為AP-IP)， 在步驟225向AP回應(yīng)DHCP ACK并在下一步進(jìn)入步驟230 ；如果未查到，則只分配IP地址 而不攜帶DHCP option43，并在步驟225回應(yīng)DHCP ACK,下一步進(jìn)入步驟240。在步驟230，DHCP服務(wù)器向AC地址列表中每個AC都發(fā)送AP申請地址成功的通 知，通知內(nèi)容包括AP的MAC地址和IP地址。本發(fā)明不對通知使用的方式進(jìn)行具體限定。例 如，如果DHCP服務(wù)器與AC在一個物理實體上，通知方式可以是函數(shù)調(diào)用、進(jìn)程間通信等方 式；如果二者在不同的物理實體上，通知方式可以是遠(yuǎn)過程調(diào)用(RPC)、自定義協(xié)議等。在步驟235，AC的協(xié)議處理單元收到DHCP服務(wù)器的通知后，向硬件ACL單元下發(fā) 一條ACL，允許接收源地址為AP-IP的capwap發(fā)現(xiàn)請求報文。在步驟240，AP向AC發(fā)起capwap發(fā)現(xiàn)請求。注意，AP可以通過解析步驟225中 的DHCP option 43得到AC地址，也可以通過其它方式得到AC地址，這里不做限定。在步 驟245，硬件ACL單元檢查capwap發(fā)現(xiàn)請求，如果該發(fā)現(xiàn)請求的IP地址和MAC地址與步驟 230中DHCP通知的IP地址和MAC地址匹配，則將該capwap發(fā)現(xiàn)請求上送到防攻擊單元。通過以上處理，AC從DHCP獲取了合法AP的IP地址，可以允許AP發(fā)起注冊請求。即，只接收這個AP的capwap發(fā)現(xiàn)請求，其它源地址的capwap發(fā)現(xiàn)請求報文均被丟棄，從而可以抵御攻擊者進(jìn)行源地址變化的capwap發(fā)現(xiàn)請求DOS攻擊。接下來，防攻擊單元按照與圖3類似的處理對AP進(jìn)行進(jìn)一步驗證。防攻擊單元通 過與AP執(zhí)行口令機制來驗證AP的合法性，僅將通過驗證的AP的capwap發(fā)現(xiàn)請求上送給 協(xié)議處理單元，并根據(jù)無線接入點的驗證結(jié)果來更新防攻擊表。與圖3不同的是，每次的 capwap發(fā)現(xiàn)請求還必須通過硬件ACL單元的檢查。具體地，在步驟250，防攻擊單元根據(jù)AP的認(rèn)證狀態(tài)和capwap發(fā)現(xiàn)請求攜帶的口 令是否與防攻擊表中的口令匹配來確定是否丟棄capwap發(fā)現(xiàn)請求，并更新防攻擊表。如果 capwap請求中沒有攜帶口令，則在步驟255，防攻擊單元根據(jù)防攻擊表中是否存在與該請 求的源IP地址對應(yīng)的表項以及表項的認(rèn)證狀態(tài)來確定是否丟棄該請求，或者向請求者AP 回復(fù)包含了分配的口令的capwap發(fā)現(xiàn)響應(yīng)。然后，在步驟260，AP接收到攜帶口令的capwap發(fā)現(xiàn)響應(yīng)之后，解析該響應(yīng)并提取 其中的口令，并將攜帶的口令的capwap發(fā)現(xiàn)請求重新發(fā)送到AC。然后，在步驟265，硬件ACL單元再次檢查capwap發(fā)現(xiàn)請求，將capwap發(fā)現(xiàn)請求上 送到防攻擊單元。在步驟270，防攻擊單元重復(fù)步驟250以將通過驗證的capwap發(fā)現(xiàn)請求上送給協(xié) 議處理單元。AC的協(xié)議處理單元接收到capwap發(fā)現(xiàn)請求之后，按照capwap協(xié)議(RFC5415)與 AP進(jìn)行正常的協(xié)議交互。隨后的處理步驟275、280與圖3的實施例中的步驟160、170相 同，因此將不再進(jìn)行描述。下面將參照圖5和圖6描述根據(jù)本發(fā)明實施例的集群模型的防攻擊系統(tǒng)及其操作 過程。其中，圖5是示出根據(jù)本發(fā)明實施例的基于交換機的集群模型的防攻擊系統(tǒng)及其操 作的示意圖，圖6是示出根據(jù)本發(fā)明實施例的基于路由器的集群模型的防攻擊系統(tǒng)及其操 作的示意圖。如圖5所示，根據(jù)本發(fā)明實施例的集群模型的AC設(shè)備包括兩種類型，一種是防攻 擊AC，另一種是普通AC。防攻擊AC包括防攻擊單元和硬件ACL單元。通常，一個防攻擊AC 可以與多個普通AC對應(yīng)。也就是說，將多個AC的防攻擊功能集中于一個AC上，從而使得 WLAN的組網(wǎng)成本降低。防攻擊AC僅使通過驗證的AP的capwap發(fā)現(xiàn)請求發(fā)送到普通AC。 普通AC被初始設(shè)置為不允許任何AP接入。在圖5中僅示出了一個普通AC。但是本領(lǐng)域的 技術(shù)人員應(yīng)理解，防攻擊AC可以與多個普通AC協(xié)調(diào)工作。首先，在步驟310-325，AP與DHCP服務(wù)器執(zhí)行與圖4的步驟210-225相同的操作。 與圖4中的單機模型不同的是，在本實施例中，DHCP服務(wù)器中的AC地址映射表保存的是防 攻擊AC的地址列表而不是普通AC的地址列表。在步驟310，AP將DHCP發(fā)現(xiàn)請求發(fā)送到DHCP服務(wù)器。在該請求中攜帶了 DHCP option 60。在步驟315，DHCP服務(wù)器向AP回復(fù)DHCP要約。在收到DHCP要約之后，在步驟 320，AP向DHCP服務(wù)器發(fā)送DHCP request請求以請求DHCP服務(wù)器為其分配IP地址，在該 請求中攜帶了與步驟310相同的DHCP option 60。DHCP服務(wù)器收到DHCP request后，解析出DHCP option 60中的信息，使用DHCP option 60的信息查找AC地址映射表。如果查到與DHCP option 60對應(yīng)的AC地址列表，則將該AC地址列表以私有格式封裝到DHCP option 43中，為AP分配IP地址(記為AP-IP)， 在步驟320向AP回應(yīng)DHCP ACK并在下一步進(jìn)入步驟325 ；如果未查到，則只分配IP地址 而不攜帶DHCP option43，并在步驟320回應(yīng)DHCPACK，而下一步AP執(zhí)行步驟340。在步驟330，DHCP服務(wù)器向防攻擊AC發(fā)送AP申請地址成功的通知，在該通知中包 括 AP的IP地址和MAC地址等信息。在步驟335，防攻擊AC向其防攻擊單元下發(fā)一條ACL，允許接收源地址為與DHCP 服務(wù)器通知的IP地址對應(yīng)的AP的capwap發(fā)現(xiàn)請求報文。接下來，在步驟340，AP向防攻擊AC發(fā)起capwap發(fā)現(xiàn)請求。在步驟345，防攻擊AC的硬件ACL單元檢查capwap發(fā)現(xiàn)請求，如果該發(fā)現(xiàn)請求的 IP地址和MAC地址與步驟330中DHCP通知的IP地址和MAC地址匹配，則將該capwap發(fā)現(xiàn) 請求上送到防攻擊單元。防攻擊單元接收到capwap發(fā)現(xiàn)請求之后，防攻擊單元使用chanlIenge機 制來驗 證AP的合法性，將合法的AP通知給普通AC，并更新防攻擊表。具體地，在步驟350，防攻擊單元接收到capwap發(fā)現(xiàn)請求之后，執(zhí)行與下表D對應(yīng) 的動作。表D 首先，防攻擊單元確定該請求是否攜帶了口令。如果沒有攜帶口令，則防攻擊單元 根據(jù)防攻擊表中是否存在與該請求的源IP地址對應(yīng)的表項以及表項的認(rèn)證狀態(tài)來確定是 否丟棄該請求，或者在步驟355向請求者AP回復(fù)包含了分配的口令的capwap發(fā)現(xiàn)響應(yīng)。如果攜帶了口令，則防攻擊單元使用該請求的源IP地址查找防攻擊表。如果沒有 在防攻擊表中找到該IP地址，則丟棄該capwap發(fā)現(xiàn)請求。如果在防攻擊表中找到了該IP地址的表項并且該表項的認(rèn)證狀態(tài)是“未認(rèn)證”， 則確定口令是否匹配；如果匹配，則防攻擊單元向該IP地址的AP回復(fù)capwap發(fā)現(xiàn)響應(yīng)，通 知AP重新向普通AC注冊，將認(rèn)證狀態(tài)修改為“認(rèn)證中”，并設(shè)置超時時間，如果超過此超時 時間認(rèn)證狀態(tài)仍未變?yōu)椤耙颜J(rèn)證”，則從防攻擊表中刪除該AP的表項，通知普通AC禁止該AP 接入；如果不匹配，則丟棄capwap發(fā)現(xiàn)請求。可通過capwap消息元素或者私有消息元素來 通知AP，從而AP在接收到該響應(yīng)之后向普通AC重新發(fā)起注冊請求。接下來，在步驟360，AP接收到攜帶口令的capwap發(fā)現(xiàn)響應(yīng)之后，解析該響應(yīng)并提 取其中的口令，并將攜帶的口令的capwap發(fā)現(xiàn)請求重新發(fā)送到防攻擊AC。然后，在步驟365，硬件ACL單元檢查capwap發(fā)現(xiàn)請求，將capwap發(fā)現(xiàn)請求上送 到防攻擊單元。防攻擊單元重復(fù)步驟350來驗證AP的合法性，并在步驟370將通過驗證的 capwap發(fā)現(xiàn)請求發(fā)送給普通AC并通知AP重新向普通AC注冊。普通AC接收到capwap發(fā)現(xiàn)請求之后，在步驟375與AP完成注冊過程。接下來， 在步驟380，普通AC和AP按照capwap協(xié)議(RFC5415)進(jìn)行正常的協(xié)議交互。隨后，當(dāng)AP進(jìn)入運行狀態(tài)之后，在步驟385，普通AC向防攻擊AC下發(fā)指令將防攻 擊表中與AP對應(yīng)的表項的認(rèn)證狀態(tài)值修改為已認(rèn)證。 最后，如果AC檢測到AP異常下線，或者AC指示AP重啟后，在步驟390，普通AC向 防攻擊AC下發(fā)指令以刪除防攻擊表中與AP對應(yīng)的表項。 圖6示出的是根據(jù)本發(fā)明實施例的根據(jù)本發(fā)明實施例的基于路由器的集群模型 的防攻擊系統(tǒng)及其操作。與圖3中示出的單機模型不同，根據(jù)本發(fā)明實施例的基于路由器 的集群模型的防攻擊系統(tǒng)中的AC包括防攻擊AC和普通AC。防攻擊AC中包括防攻擊單元， 其執(zhí)行與圖3中的防攻擊單元類似的操作，不同的是，該防攻擊單元將通過驗證的capwap 發(fā)現(xiàn)請求發(fā)送給普通AC中的協(xié)議處理單元。普通AC初始被設(shè)置為不允許任何AP接入。
在步驟410，AP向防攻擊AC發(fā)送capwap發(fā)現(xiàn)請求。
接下來，在步驟415，防攻擊AC使用口令機制來驗證該AP的capwap發(fā)現(xiàn)請求的合 法性，并更新防攻擊表。防攻擊AC接收到capwap發(fā)現(xiàn)請求之后，檢查該請求中是否攜帶了 口令，即，是否 攜帶了隨機數(shù)。如果防攻擊AC確定capwap發(fā)現(xiàn)請求中沒有攜帶口令，則防攻擊AC根據(jù)防 攻擊表中是否存在與該請求的源IP地址對應(yīng)的表項以及表項的認(rèn)證狀態(tài)來確定是否丟棄 該請求，或者向請求者AP回復(fù)包含了分配的口令的capwap發(fā)現(xiàn)響應(yīng)。如果超過設(shè)置的時 間之后AP沒有重新發(fā)送攜帶口令的capwap發(fā)現(xiàn)請求，即，該表項的認(rèn)證狀態(tài)未變?yōu)椤罢J(rèn)證 中”，則防攻擊單元刪除該表項。如果請求攜帶了口令，則防攻擊AC使用發(fā)送請求者的源IP查找表A。如果在防攻 擊表中沒有查找到與請求者IP對應(yīng)的表項，則防攻擊AC丟棄該capwap發(fā)現(xiàn)請求。如果在 表A中找到了與該源IP對應(yīng)的表項，則防攻擊AC執(zhí)行與表D對應(yīng)的操作當(dāng)表項的狀態(tài)為“未認(rèn)證”時，防攻擊AC檢查口令是否匹配。如果匹配，則防攻擊 AC向該IP地址的AP回復(fù)capwap發(fā)現(xiàn)響應(yīng)，通知AP重新向普通AC注冊，將認(rèn)證狀態(tài)修改 為“認(rèn)證中”，并設(shè)置超時時間，如果超過此超時時間認(rèn)證狀態(tài)仍未變?yōu)椤耙颜J(rèn)證”，則從防攻 擊表中刪除該AP的表項，通知普通AC禁止該AP接入；如果不匹配，則丟棄capwap發(fā)現(xiàn)請 求。當(dāng)表項的狀態(tài)不是“未認(rèn)證”時(即，處于“認(rèn)證中”和“已認(rèn)證”時)，防攻擊單元
不檢查口令是否匹配，直接丟棄該capwap發(fā)現(xiàn)請求。在AP接收到攜帶口令的capwap發(fā)現(xiàn)響應(yīng)之后，解析該響應(yīng)并提取其中的隨機數(shù)， 并在步驟430重新發(fā)送攜帶的隨機數(shù)的capwap發(fā)現(xiàn)請求到AC。然后，防攻擊AC重復(fù)步驟415中的驗證過程，在步驟440將通過了 口令驗證的AP 的信息通知給普通AC。 接下來，在步驟450，AP向普通AC重新發(fā)起注冊請求，完成注冊過程。在步驟460， AP與普通AC按照capwap協(xié)議進(jìn)行正常的協(xié)議交互。當(dāng)AP進(jìn)入運行狀態(tài)之后，在步驟470， 普通AC向防攻擊AC下發(fā)指令將防攻擊表中與AP對應(yīng)的表項的認(rèn)證狀態(tài)值修改為已認(rèn)證。 最后，如果AC檢測到AP異常下線，或者AC指示AP重啟后，在步驟480，普通AC向防攻擊 AC下發(fā)指令以刪除防攻擊表中與AP對應(yīng)的表項。 雖然已經(jīng)參照本發(fā)明的若干示例性實施例示出和描述了本發(fā)明，但是本領(lǐng)域的技 術(shù)人員將理解，在不脫離權(quán)利要求及其等同物限定的本發(fā)明的精神和范圍的情況下，可以 在形式和細(xì)節(jié)上做出各種改變。
權(quán)利要求
一種防攻擊的無線控制器，包括協(xié)議處理單元，與無線接入點AP按照預(yù)定協(xié)議進(jìn)行通信；防攻擊單元，通過口令機制來驗證AP的注冊請求的合法性，更新防攻擊表，并將合法的AP的注冊請求上送給協(xié)議處理單元，其中，所述防攻擊表中記錄了AP的IP地址、為AP分配的口令以及AP的認(rèn)證狀態(tài)。
2.如權(quán)利要求1所述的無線控制器，其中，所述口令是由防攻擊單元生成的隨機數(shù)。
3.如權(quán)利要求1所述的無線控制器，其中，AP的認(rèn)證狀態(tài)包括未認(rèn)證、認(rèn)證中和已認(rèn) 證，防攻擊單元僅對攜帶了 口令并且處于未認(rèn)證狀態(tài)的注冊請求進(jìn)行驗證。
4.如權(quán)利要求3所述的無線控制器，其中，如果AP的注冊請求中沒有攜帶口令并且防 攻擊表中不存在與該AP對應(yīng)的表項，則防攻擊單元為該AP分配口令，并將包含該口令的響 應(yīng)發(fā)送回到AP以通知AP重新發(fā)送注冊請求。
5.如權(quán)利要求4所述的無線控制器，其中，如果防攻擊單元在發(fā)送了所述響應(yīng)的預(yù)定 時間之后沒有接收到AP重新發(fā)送的注冊請求，則防攻擊單元從防攻擊表中刪除與該AP相 關(guān)的表項。
6.如權(quán)利要求1所述的無線控制器，其中，在AP的注冊請求被上送給協(xié)議處理單元之 后，防攻擊單元將AP的認(rèn)證狀態(tài)修改為認(rèn)證中，如果在預(yù)定時間之后該AP的認(rèn)證狀態(tài)未改 變?yōu)橐颜J(rèn)證，則防攻擊單元刪除防攻擊表中與該AP對應(yīng)的表項。
7.如權(quán)利要求6所述的無線控制器，其中，在AP與無線控制器建立通信之后，如果無線 控制器檢測到AP異常下線，或者無線控制器指示AP重啟后，協(xié)議處理單元向防攻擊單元下 發(fā)指令以刪除防攻擊表中與AP對應(yīng)的表項。
8.如權(quán)利要求1所述的無線控制器，還包括硬件ACL單元，從DHCP服務(wù)器獲得由DHCP服務(wù)器分配了 IP地址的AP的信息，并僅允 許將該AP所發(fā)起的注冊請求上送給防攻擊單元。
9.一種防攻擊的無線控制系統(tǒng)，包括DHCP服務(wù)器，為AP分配IP地址，在為AP分配IP地址后將AP的信息通知給與AP對應(yīng) 的無線控制器，通知AP向無線控制器發(fā)送注冊請求；無線控制器，包括協(xié)議處理單元，與無線接入點AP按照預(yù)定協(xié)議進(jìn)行通信；防攻擊單元，通過口令機制來驗證AP的注冊請求的合法性，更新用于記錄AP合法性狀 態(tài)的防攻擊表，并將合法的AP的注冊請求上送給協(xié)議處理單元，其中，所述防攻擊表中記 錄了 AP的IP地址、為AP分配的口令以及AP的認(rèn)證狀態(tài)；硬件ACL單元，從DHCP服務(wù)器獲得由DHCP服務(wù)器分配了 IP地址的AP的信息，并僅允 許將該AP所發(fā)起的注冊請求上送給防攻擊單元。
10.如權(quán)利要求9所述的無線控制系統(tǒng)，其中，DHCP服務(wù)器通過AP攜帶的option60 消息查找與AP對應(yīng)的無線控制器的地址列表。
11.一種防攻擊的無線控制系統(tǒng)，包括DHCP服務(wù)器，為無線接入點AP分配IP地址，將在為AP分配IP地址后將AP的信息通 知給與AP對應(yīng)的第一無線控制器，通知AP向所述對應(yīng)的第一無線控制器發(fā)送注冊請求；第一無線控制器，包括防攻擊單元，通過口令機制來驗證AP的注冊請求的合法性，更新用于記錄AP合法性狀 態(tài)的防攻擊表，并將合法的AP的注冊請求上送給第二無線控制器，其中，所述防攻擊表中 記錄了 AP的IP地址、為AP分配的口令以及AP的認(rèn)證狀態(tài)；硬件ACL單元，從DHCP服務(wù)器獲得由DHCP服務(wù)器分配了 IP地址的AP的信息，并僅允許將該AP所發(fā)起的注冊請求上送給防攻擊單元；第二無線控制器，用于與通過第一無線控制器驗證的AP按照預(yù)定協(xié)議進(jìn)行通信。
12.如權(quán)利要求11所述的無線控制系統(tǒng)，其中，DHCP服務(wù)器通過AP攜帶的option60 消息查找與AP對應(yīng)的第一無線控制器的地址列表，獲取與AP對應(yīng)的第一無線控制器的地 址。
13.一種防攻擊的無線控制系統(tǒng)，包括 第一無線控制器，包括防攻擊單元，通過口令機制來驗證無線接入點AP的注冊請求的合法性，更新用于記錄 AP合法性狀態(tài)的防攻擊表，并將合法的AP的注冊請求發(fā)送給第二無線控制器，其中，所述 防攻擊表中記錄了 AP的IP地址、為AP分配的口令以及AP的認(rèn)證狀態(tài)；第二無線控制器，用于與通過第一無線控制器驗證的AP按照預(yù)定協(xié)議進(jìn)行通信。
14.如權(quán)利要求13所述的無線控制系統(tǒng)，其中，DHCP服務(wù)器通過AP攜帶的option60 消息查找與AP對應(yīng)的第一無線控制器的地址列表，獲取與AP對應(yīng)的第一無線控制器的地 址。
全文摘要
提供了一種防攻擊的無線控制系統(tǒng)，包括DHCP服務(wù)器，為AP分配IP地址，在為AP分配IP地址后將AP的信息通知給與AP對應(yīng)的無線控制器，通知AP向無線控制器發(fā)送注冊請求；無線控制器，通過口令機制來驗證AP的注冊請求的合法性，更新用于記錄AP合法性狀態(tài)的防攻擊表，并將合法的AP的注冊請求上送給協(xié)議處理單元；硬件ACL單元，從DHCP服務(wù)器獲得由DHCP服務(wù)器分配了IP地址的AP的信息，并僅允許將該AP所發(fā)起的注冊請求上送給防攻擊單元。
文檔編號H04L29/12GK101841813SQ20101014074
公開日2010年9月22日 申請日期2010年4月7日 優(yōu)先權(quán)日2010年4月7日
發(fā)明者劉靖非, 范成龍 申請人:北京傲天動聯(lián)技術(shù)有限公司