本發(fā)明涉及無線局域網(wǎng)技術領域，尤其涉及一種躲避系統(tǒng)類型檢測的方法及裝置。

背景技術：

dhcp(dynamichostconfigurationprotocol，動態(tài)主機配置協(xié)議)是一種采用客戶端/服務器模型基于udp協(xié)議工作的一種局域網(wǎng)網(wǎng)絡協(xié)議。主要作用是集中的管理、分配ip地址，使網(wǎng)絡環(huán)境中的主機動態(tài)的獲得ip地址、gateway地址、dns服務器地址等信息。dhcp協(xié)議采用客戶端/服務器模型，主機地址的動態(tài)分配任務由網(wǎng)絡主機驅動。當dhcp服務器接收到來自網(wǎng)絡主機申請地址的信息時，才會向網(wǎng)絡主機發(fā)送相關的地址配置等信息，以實現(xiàn)網(wǎng)絡主機地址信息的動態(tài)配置。

dhcpoption主要是針對不同廠商的設備在不同環(huán)境的應用下所配置的特殊信息。dhcpoptions選項的取值范圍為1～255，其中，option55為設置請求參數(shù)列表選項，客戶端利用該選項指明需要從服務器獲取哪些網(wǎng)絡配置參數(shù)，dhcp服務器回應的dhcp報文中，該選項內容為客戶端請求的參數(shù)對應的選項值。option12是hostname，通常會設置為產(chǎn)品類型和序列號。

在當前的操作系統(tǒng)中，終端一般會根據(jù)慣例設計dhcp報文中的option55中parameterrequestlist的順序來標識自己的os類型，比如通過option55，我們就能獲知終端的os是ios、android還是windows，這樣的話，在不知不覺中，這種信息就被ap搜集了，造成信息的泄露，因為所有的終端關聯(lián)上ap之后，dhcp交互是必須的過程。

技術實現(xiàn)要素：

本發(fā)明提供一種躲避系統(tǒng)類型檢測的方法，解決了現(xiàn)有技術中終端類型在dhcp交互過程中容易泄露的技術問題。

本發(fā)明的躲避系統(tǒng)類型檢測的方法包括：

s100獲取待發(fā)送的dhcp請求報文；

s200調整所述待發(fā)送的dhcp請求報文中option55的請求參數(shù)的順序，生成第一dhcp請求報文；

s300發(fā)送所述第一dhcp請求報文，實現(xiàn)與dhcp服務器交互。

終端在發(fā)送dhcp報文之前，會調整待該dhcp報文中option55的請求參數(shù)的順序，生成新的報文，新報文依然合法，可以被dhcp服務器處理，同時也規(guī)避了終端的系統(tǒng)類型被認出。

進一步地，所述待發(fā)送的dhcp請求報文中option55的請求參數(shù)及其排列順序是根據(jù)dhcp客戶端的系統(tǒng)類型及其版本進行設置。

進一步地，所述步驟s200包括：

s210將所述待發(fā)送的dhcp請求報文中option55的請求參數(shù)的順序隨機化，生成第一dhcp請求報文。

進一步地，所述步驟s200包括:

s230按照預設規(guī)則，將所述待發(fā)送的dhcp請求報文中option55的的請求參數(shù)進行排序，生成第一dhcp請求報文。

進一步地，在所述步驟s300之前還包括：

s250查看所述第一dhcp請求報文中option12選項中是否含有系統(tǒng)類型字段，若是進入步驟s400，否則進入步驟s300；

s400修改所述第一dhcp請求報文中option12選項中的系統(tǒng)類型字段，生成第二dhcp請求報文；

s500發(fā)送所述第二dhcp請求報文，實現(xiàn)與dhcp服務器交互。

另一方面，本發(fā)明還公開了一種躲避系統(tǒng)類型檢測的裝置，包括：獲取模塊、順序調整模塊、及發(fā)送模塊；所述順序調整模塊分別與所述獲取模塊、所述發(fā)送模塊相連，其中：所述獲取模塊獲取待發(fā)送的dhcp請求報文；所述順序調整模塊調整所述待發(fā)送的dhcp請求報文中option55的請求參數(shù)的順序，生成第一dhcp請求報文；所述發(fā)送模塊發(fā)送所述第一dhcp請求報文，實現(xiàn)與dhcp服務器交互。

進一步地，所述獲取模塊獲取的所述待發(fā)送的dhcp請求報文中，option55的請求參數(shù)及其排列順序是根據(jù)dhcp客戶端的系統(tǒng)類型及其版本進行設置。

進一步地，所述順序調整模塊包括：隨機化子模塊，用于將所述待發(fā)送的dhcp請求報文中option55的請求參數(shù)的順序隨機化，生成第一dhcp請求報文。

進一步地，所述順序調整模塊包括：規(guī)則預設子模塊、及與所述規(guī)則預設子模塊相連的排序子模塊，其中：所述規(guī)則預設子模塊根據(jù)用戶的指令設置排序規(guī)則；所述排序子模塊根據(jù)所述規(guī)則預設子模塊預設的規(guī)則對所述待發(fā)送的dhcp請求報文中option55的請求參數(shù)進行排序，生成第一dhcp請求報文。

進一步地，所述躲避系統(tǒng)類型檢測的裝置還包括：查找模塊、操作模塊，所述查找模塊分別與所述操作模塊、順序調整模塊、及發(fā)送模塊相連，所述操作模塊還與所述發(fā)送模塊相連，其中：所述順序調整模塊調整所述待發(fā)送dhcp請求報文中option55的請求參數(shù)順序，生成第一dhcp請求報文后，所述查找模塊查看所述第一dhcp請求報文的option12選項中是否含有系統(tǒng)類型字段，若是，則控制所述操作模塊修改所述第一dhcp請求報文的option12選項中的系統(tǒng)類型字段，生成第二dhcp請求報文，并通過所述發(fā)送模塊發(fā)送所述第二dhcp請求報文，實現(xiàn)與dhcp服務器交互；若所述查找模塊在所述第一dhcp請求報文的option12選項中未查找到系統(tǒng)類型字段，則所述發(fā)送模塊發(fā)送所述第一dhcp請求報文，實現(xiàn)與dhcp服務器交互。

本發(fā)明通過改變dhcp請求報文中的option55的請求參數(shù)順序，避免了終端類型的泄露，保護了用戶的隱私，同時又不影響終端從dhcp服務器獲取相應的網(wǎng)絡配置。此外，本發(fā)明還通過進一步檢測option12選項的字段，避免因維修該主機名造成的系統(tǒng)類型的信息泄露。

附圖說明

為了更清楚地說明本發(fā)明實施例中的技術方案，下面將對實施例描述中所需要使用的附圖作簡要介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領域的普通技術人員來講，在不付出創(chuàng)造性勞動性的前提下，還可以根據(jù)這些附圖獲得其他的附圖。

圖1為本發(fā)明一種躲避系統(tǒng)類型檢測的方法實施例一的流程圖；

圖2為本發(fā)明一種躲避系統(tǒng)類型檢測的方法另一實施例的流程圖；

圖3為本發(fā)明一種躲避系統(tǒng)類型檢測的裝置實施例一的框圖；

圖4為本發(fā)明一種躲避系統(tǒng)類型檢測的裝置另一實施例的框圖；

圖5為本發(fā)明一種躲避系統(tǒng)類型檢測的裝置另一實施例的框圖；

圖6為本發(fā)明一種躲避系統(tǒng)類型檢測的裝置另一實施例的框圖。

具體實施方式

為了使本發(fā)明的目的、技術方案和優(yōu)點更加清楚，下面將結合附圖對本發(fā)明作進一步地詳細描述，顯然，所描述的實施例僅僅是本發(fā)明一部份實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領域普通技術人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其它實施例，都屬于本發(fā)明保護的范圍。

本發(fā)明公開了一種躲避系統(tǒng)類型檢測的方法，實施例一如圖1所示，包括：

s100獲取待發(fā)送的dhcp請求報文；

s200調整所述待發(fā)送的dhcp請求報文中option55的請求參數(shù)的順序，生成第一dhcp請求報文；

s300發(fā)送所述第一dhcp請求報文，實現(xiàn)與dhcp服務器交互。

在當前的os系統(tǒng)中，一般根據(jù)慣例會設計特殊的dhcp報文中的option55中parameterrequestlist的順序來標識自己的os類型，一般通過option55，我們就能獲知終端的系統(tǒng)類型是ios、android還是windows，這樣的話，在不知不覺中，這種信息就被ap搜集了，因為所有的終端關聯(lián)上ap之后，dhcp交互是必須的過程。

本發(fā)明通過改進dhcp報文中的option55中parameterrequestlist的順序的設計來規(guī)避終端的系統(tǒng)類型被收集。由于option55中的parameterrequestlist的內容是不需要順序的，比如1，2，3和2，1，3都是合法的報文，只不過1，2，3標識一種終端的操作系統(tǒng)類型，2，1，3標識另外一種終端的操作系統(tǒng)類型。所以在每次發(fā)送dhcp報文時，把其中的option55中parameterrequestlist的順序改變調整，這樣的話，報文依然合法，可以被dhcpserver處理，同時也規(guī)避了終端的系統(tǒng)類型被中間的ap或其他路由器等中轉設備認出。

客戶終端在構造dhcp請求報文時，一般根據(jù)自身的系統(tǒng)類型和版本號會設置dhcp請求報文中option55的請求參數(shù)，也就是說一般根據(jù)option55的請求參數(shù)及排列順序就可以看出是哪個系統(tǒng)類型及版本。我們以android系統(tǒng)，版本4.4.2為例，對應的option55的請求參數(shù)及排列順序為：1,33,3,6,15,28,51,58,59。如果是ios系統(tǒng)，版本號為10.3.1，則對應的option55的請求參數(shù)及排列順序為：1,121,3,6,15,119,252。因此，如果不采用本發(fā)明方法的話，dhcp服務器在接收到客戶終端發(fā)送的dhcp請求報文后，根據(jù)報文中option55請求參數(shù)及其順序，便可知道dhcp客戶端的系統(tǒng)類型及版本號，造成了隱私信息的泄露。而本發(fā)明則是在在dhcp客戶終端發(fā)送dhcp請求報文前，先將該待發(fā)送的dhcp請求報文中的option55的請求參數(shù)的順序進行打亂，比如，將待發(fā)送的dhcp請求報文中，option55的請求參數(shù)排列順序由1,33,3,6,15,28,51,58,59變成33,6,1,15,59,58,3,28,51。如此不改變請求參數(shù)，只是將各參數(shù)的排列順序打亂，并不影響dhcp客戶終端從dhcp服務器獲取網(wǎng)絡配置，卻使得dhcp服務器無法從option55中獲知終端系統(tǒng)類型，達到了保護隱私，避免終端系統(tǒng)類型被dhcp服務器搜集。

本發(fā)明的另一實施例，在上述實施例1的基礎上，上述步驟s200中，改變option55的請求參數(shù)的順序的技術手段有很多種，比如，將所述待發(fā)送的dhcp請求報文中option55的請求參數(shù)的順序隨機化，在每次發(fā)送dhcp報文時，把其中的option55中parameterrequestlist的順序隨機化，這樣的話，報文依然合法，可以被dhcpserver處理，同時也規(guī)避了sta(終端)的os類型被中間的ap或其他路由器等中轉設備認出。具體的，包括步驟：

(1)sta關聯(lián)上ap的的ssid。

(2)sta把dhcpoption55中parameterrequestlist的順序用隨機數(shù)隨機化，生產(chǎn)新的dhcp報文。

(3)sta用新的dhcp報文和dhcpserver交互。

(4)在今后的任何dhcp交互中，option55中parameterrequestlist都要重新隨機化。

除了上述實施例中采用隨機化的方法改變option55的請求參數(shù)的順序外，我們還可以通過設置預設規(guī)則，然后根據(jù)預設規(guī)則將獲取的待發(fā)送的dhcp請求報文中option55的請求參數(shù)進行排序，生成第一dhcp請求報文，比如，我們可以設置預設規(guī)則將option55的請求參數(shù)按照從大到小的順序進行排序，我們以iphone6為例，客戶端根據(jù)iphone6的操作系統(tǒng)(ios)及version：10.3.2設置option55的請求參數(shù)順序為：1,121,3,6,15,119,252；按照我們預設的從大到小的排序規(guī)則的話，則在獲取到待發(fā)送的dhcp請求報文后，將該報文中option55的原請求參數(shù)順序改為：252,121,119,15,6,3,1。這樣一來，dhcp客戶端在收到該變了option55請求參數(shù)順序的新的dhcp報文后，便無法據(jù)此獲得接入終端的系統(tǒng)類型了。預設規(guī)則的設置可以根據(jù)用戶的需求或指令進行設置。

本發(fā)明的另一實施例，如圖2所示，包括：

s100獲取待發(fā)送的dhcp請求報文；

s200調整所述待發(fā)送的dhcp請求報文中option55的請求參數(shù)的順序，生成第一dhcp請求報文；

s250查看所述第一dhcp請求報文中option12選項中是否含有系統(tǒng)類型字段，若是進入步驟s400，否則進入步驟s300；

s300發(fā)送所述第一dhcp請求報文，實現(xiàn)與dhcp服務器交互；

s400修改所述第一dhcp請求報文中option12選項中的系統(tǒng)類型字段，生成第二dhcp請求報文；

s500發(fā)送所述第二dhcp請求報文，實現(xiàn)與dhcp服務器交互。

在上述任一實施例的基礎上，除了對option55進行請求參數(shù)的順序改變外，還針對option12選項的字段進行查看，如果option12選項含有系統(tǒng)類型字段，則對其進行修改或者刪除。option12是主機名字段，通常會設置為產(chǎn)品類型和序列號，比如某廠商android手機的option12字段為“android-9dc35f21ged653”，那么通過option12選項的字段就可以大致確定這個終端系統(tǒng)類型是android。option12字段對于大部分原始終端來說管用，但是當用戶修改了終端命名信息后(比如用戶可以更改為任何的名字，比如android手機是andorid-45342323，而用戶可以修改為12345)，那么option12選項的字段就相應的變更為12345，就不知道如何判別類別了。因此，如果用戶修改了終端的主機名，那么option12選項中就不會出現(xiàn)終端系統(tǒng)類型字段，如果用戶還沒有修改主機名，那么終端在發(fā)送dhcp請求報文前，除了調整option55的請求參數(shù)順序外，還會修改option12的系統(tǒng)類型字段，這個修改命名可以讓用戶來指定命令，也可以自動命名。后續(xù)的每次dhcp交互，option22選項便可均以修改后的系統(tǒng)類型字段來構建。

基于相同的技術構思，另一方面，本發(fā)明還公開了一種躲避系統(tǒng)類型檢測的裝置，該裝置可以采用本發(fā)明的躲避系統(tǒng)類型檢測的方法，具體的，本發(fā)明躲避系統(tǒng)類型檢測的裝置實施例一如圖3所示，該監(jiān)測裝置包括：獲取模塊10、順序調整模塊20、及發(fā)送模塊30；所述順序調整模塊20分別與所述獲取模塊10、所述發(fā)送模塊30相連，其中：所述獲取模塊10獲取待發(fā)送的dhcp請求報文；所述順序調整模塊20調整所述待發(fā)送的dhcp請求報文中option55的請求參數(shù)的順序，生成第一dhcp請求報文；所述發(fā)送模塊30發(fā)送所述第一dhcp請求報文，實現(xiàn)與dhcp服務器交互。

本發(fā)明的躲避系統(tǒng)類型檢測的裝置一般集成在終端上，通過改變dhcp請求報文中option55的請求參數(shù)的順序來避免終端的系統(tǒng)類型被中間的ap或其他路由器等中轉設備認出。雖然改變了option55的請求參數(shù)的順序，但并不影響配置，由于請求參數(shù)沒有改變，還是那些參數(shù)，只是順序調換了，dhcp服務器還可以根據(jù)請求的參數(shù)配置與請求參數(shù)對應的選項值。未改變順序之前，option55的請求參數(shù)順序標識了請求終端的系統(tǒng)類型，而通過改進dhcp報文中option55中的請求參數(shù)的順序則可以規(guī)避終端的系統(tǒng)類型被收集。

上述實施例中，所述獲取模塊10獲取的所述待發(fā)送的dhcp請求報文中，option55的請求參數(shù)及其排列順序是根據(jù)dhcp客戶端的系統(tǒng)類型及其版本進行設置。

本裝置的另一實施例，如圖4所示，在上述實施例一的基礎上，所述順序調整模塊20包括：隨機化子模塊21，用于將所述待發(fā)送的dhcp請求報文中option55的請求參數(shù)的順序隨機化，生成第一dhcp請求報文。

通過隨機化子模塊21來隨機化option55的請求參數(shù)的順序，使得終端的系統(tǒng)類型不被泄露。后續(xù)的任何dhcp交互中，option55中的請求參數(shù)都要重新隨機化。具體的，終端上集成了本發(fā)明的檢測裝置后，終端關聯(lián)上ap的ssid后，終端通過隨機化子模塊21把dhcp請求報文中的option55中請求參數(shù)的順序隨機化，生成新的dhcp報文；該終端采用新的dhcp報文和dhcp服務器交互，在今后的任何dhcp交互中，option55中parameterrequestlist都要重新隨機化。

本發(fā)明躲避系統(tǒng)類型檢測的裝置另一實施例如圖5所示，在上述實施例一的基礎上，所述順序調整模塊20包括：規(guī)則預設子模塊22、及與所述規(guī)則預設子模塊22相連的排序子模塊23，其中：所述規(guī)則預設子模塊22根據(jù)用戶的指令設置排序規(guī)則；所述排序子模塊23根據(jù)所述規(guī)則預設子模塊22預設的規(guī)則對所述待發(fā)送的dhcp請求報文中option55的請求參數(shù)進行排序，生成第一dhcp請求報文。

本裝置通過根據(jù)預設規(guī)則來排序的方法調整option55的請求參數(shù)的順序。

本發(fā)明躲避系統(tǒng)類型檢測的裝置的最后一個實施例，如圖6所示，在上述任一實施例的基礎上，所述躲避系統(tǒng)類型檢測的裝置還包括：查找模塊40、操作模塊50，所述查找模塊40分別與所述操作模塊50、順序調整模塊20、及發(fā)送模塊30相連，所述操作模塊50還與所述發(fā)送模塊30相連，其中：所述順序調整模塊20調整所述待發(fā)送dhcp請求報文中option55的請求參數(shù)順序，生成第一dhcp請求報文后，所述查找模塊40查看所述第一dhcp請求報文的option12選項中是否含有系統(tǒng)類型字段，若是，則控制所述操作模塊50修改所述第一dhcp請求報文的option12選項中的系統(tǒng)類型字段，生成第二dhcp請求報文，并通過所述發(fā)送模塊30發(fā)送所述第二dhcp請求報文，實現(xiàn)與dhcp服務器交互；若所述查找模塊40在所述第一dhcp請求報文的option12選項中未查找到系統(tǒng)類型字段，則所述發(fā)送模塊30發(fā)送所述第一dhcp請求報文，實現(xiàn)與dhcp服務器交互。

本實施例中，除了調整dhcp報文中的option55的請求參數(shù)的順序外，還進一步查看option12中是否含有系統(tǒng)類型字段，一般終端未修改過的話，主機名稱會顯示出類型及型號，因此，可能會泄露系統(tǒng)類型，故本裝置還會查看dhcp報文中option12字段中是否含有系統(tǒng)類型字段，比如是否含有android、ios、windows等系統(tǒng)類型字段，如果有的話就還需要修改，當然可以提示讓用戶修改主機名，或者自行修改主機名，修改規(guī)則可系統(tǒng)自設或根據(jù)用戶需求預設。修改完后，dhcp服務器就不會知曉終端的系統(tǒng)類型了。

盡管已描述了本發(fā)明的優(yōu)選實施例，但本領域內的技術人員一旦得知了基本創(chuàng)造性概念，則可對這些實施例作出另外的變更和修改。所以，所附權利要求意欲解釋為包括優(yōu)選實施例以及落入本發(fā)明范圍的所有變更和修改。

顯然，本領域的技術人員可以對本發(fā)明進行各種改動和變型而不脫離本發(fā)明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權利要求及其等同技術的范圍之內，則本發(fā)明也意圖包含這些改動和變型在內。