802.1X認證協議及漏洞分析

咱們學校使用的是華爲的上網認證系統，應該也有不少學校也是使用這套系統吧。

網上有很詳細的關於802.1x的說明。簡單說一下。802.1x是使用的是EAP協議，在Rfc3748中有關於Eap詳細的說明。不過在具體的實現上面每一公司都不一樣，整體的結構和交互的時序是符合標準的

。發送的數據幀長度是60。可創建如下結構：

typedef  struct  Exauthen
{
       u_char code;
        // 0x01,請求request，switch對的request;
        // 0x02 表示這是你的應答；
        // 0x03 成功 
        // 0x04失敗； 
       u_char id;
        // 序號交換機問你n你就答n
       u_char length[ 2 ];
        // exauthen長度，固然要去掉後面的00的長度
        // 與authen.length的長度同樣
       u_char type;
        // 0x01 identity  0x1504+用戶名，
        // 或者          0x1504+ip+用戶名 填充content 華爲本身弄的，標準中沒有ip的事，後面能夠看出其實這也不過是個雞肋
// 具體要根據AAA服務器的配置
        // 0x07          0x07+密碼+用戶名 填充content 華爲本身定的，Rfc3748沒有這個
// 在新的客戶端中，使用了md5加密密碼
       u_char content[ 37 ]; // 內容，剩的用00填充
       
} Exauthen;
 
typedef  struct  Authen
{ 
 u_char version;
  // 版本,0x01
 u_char type;
  // 類型0x00 eappack 須要填充exauthen,若是是後面兩個就不要了管exauthen；
  // 0x01 start ；0x02 logoff；
 u_char lenght[ 2 ];
  // exauthen長度，固然要去掉後面的00的長度
 Exauthen exauthen;
 
}Authen;
typedef  struct  eap_header
{
       u_char dst[ 6 ];
        // 目的mac地址
       u_char src[ 6 ];
        // 原mac地址
       u_char type[ 2 ];
        // 類型0x888e，沒有這個交換機不任
       Authen authen;
        // eap數據了
 
 
}eap_header;

 

可使用raw_scoket 進行編程，寫一個客戶端，在winxp+sp2下可使用wincap；

具體實現能夠寫一個狀態機類，實現起來比較簡單。

struct  State{
 
        int  state; // 狀態
       pcap_t  * pHandle;
        int  id; // 數據包id
       u_char local[ 6 ];
       u_char gateway[ 6 ];
       u_char brodcast[ 6 ];
       u_char type[ 2 ]; // 0x888e
       State():id( 0 ),state( 0 ) ;
        void  setHandle(pcap_t  * p)
       {
              pHandle = p;
       }
        // State(pcap_t *p):state(0),pHandle(p){}
        bool  start();
     bool  logoff();
        bool  response2();
bool  response3();
void  setState( int  i)
{
       state = i;
       cout << endl << " state:  " << i << endl;
}
        void  changState(eap_header  * h){
 
              Exauthen ex = h -> authen.exauthen;
               if (ex.id < id)  return ; // 過濾重播的數據包
               id = ex.id;
 
               if (state == 1
                      && ex.code == 1 // request
                      && ex.type == 1 // identity
                     ){
              
                     setState( 2 );
                     response2();
              
              } else   if (
                     state == 2
                      && ex.code == 1 // request
                      && ex.type == 7 // reserv??
                     ){
              
                 setState( 3 );
                 response3();
              } else   if (
                     state == 3
                      && ex.code == 3 // succese
                     ){
              setState( 4 );
       
       
              } else   if (state == 4 && ex.code == 1 && ex.type == 1 )
              {
                     response2();
                     setState( 4 );
         
              }
               else   if (ex.code == 4 // failure
                     )
              {
                     setState( 0 );
                     
              }
 
       }
};

在研究過程，也感受到，802.1x的安全性的確很是的高，ieee的確牛，幾乎沒有什麼可突破的。發現有兩個漏洞，

一：在發送 log_off數據時，不須要驗證信息，連id都不要。就可使用別人的mac構造log_off數據包，讓對方下線。對於同一個物理端口下，是能夠實現。對於不一樣端口，是否可行沒有實驗。固然對於不一樣交換機是確定不可行的（不明白的想想）。

二：華爲802.1x技術方案，有一個特色是：用戶賬號+ip地址，來進行驗證。能夠發現一個問題，驗證時使用的ip能夠和真實使用的ip不一樣。就是說咱們可使用非法的ip處處亂逛了，這對網絡安全構成巨大的危險，「城堡經常是從內部攻破的」。那爲何不在轉發ip數據時驗證呢？可能會有這樣的疑問。若是是這樣的話802.1x就不是802.1x了，他的優點就一點都沒了，又回到原來的老路上面去了。這也這也正是我爲何說「用戶賬號+ip地址」是雞肋的緣由了。一項技術自己確定具備其侷限性，咱們不能要求他解決全部的網絡安全問題，這是不大可能的，即便達到了也是事倍功半的。

下面轉貼貼網上找來的資料，講了不錯，第二點我上面講了：

///////////////////

  隨着人們對網絡邊緣安全的重視，802.1x認證逐漸被廣大用戶接受並使用，尤爲在產業園區和高校宿舍區。做爲年輕的優秀解決方案，她真的完美嗎?

　　在講述其缺陷以前，有必要來了解一下802.1認證的特色:

　　802.1x的邊緣安全是由啓用802.1x功能的交換機來實現的。其每一個物理端口內部又分爲受控端口和非受控端口，非受控端口只負責處理認證數據包，受控端口負責處理業務數據。登錄前，用戶只能經過非受控端口發送和接收認證數據包(802.1x格式)，而其餘格式的數據包則沒法經過受控端口;登錄後，受控端口對用戶開放，接受數據的傳輸。

　　認證時，首先客戶端軟件發送請求，交換機把接收到的認證信息傳遞給中心的認證服務器。認證服務器負責信息的核對(好比用戶名、密碼、MAC、IP等的核對)。認證結束後，除了每隔一段時間處理次在線確認數據包外，用戶的正常網絡應用與802.1x沒有任何關係，這就是所謂的認證流和業務流的分離。

　　在開發802.1x客戶端的過程當中，發現了幾處缺陷:

　　(1)免撥號，就能夠交換機範圍內通信

　　根源:802.1x認證體系中，認證流與業務流是分離的。認證流具備不認證也能夠通信的能力(但不具備跨網段的能力)。

　　實現:若是用戶把自定義的數據格式代替了EAP認證報文，並按須要改動一下目標MAC，而交換機仍然把此數據包當成合格的802.1x認證包處理，但把它發給了指定的MAC。這樣，就能夠在不撥號的狀況下進行數據傳輸。

　　爲了演示此缺陷，我特意作了一個程序(點此下載 說明:須要安裝WinPcap) 。802.1x的用戶或廠商能夠下載在同一交換機、不一樣端口的環境下進行測試。

　　後果:影響並非很大。在同一個交換機的通信原本就是應該免費。因爲客戶端必須由相應的軟件來分析自定義的數據包，因此自己不會產生安全隱患。

　　(2)IP綁定的缺陷

　　根源:根源依舊是認證流與業務流的分離。標準802.1協議是不支持IP綁定的，但幾乎全部廠商根據本身的產品進行了擴展，使其協議(私有)支持IP綁定.。其原理是把IP加入到EAP數據包裏而後與認征服務器覈實，肯定是否正確。

　　實現:認證數據包採用本身的IP(運營商分配的)騙過服務器的認證，而正常的數據通信仍然採用真實IP。

　　後果:一方面，此缺陷能夠形成IP管理混亂;另外一方面，網絡的監控系統將失靈，雖然仍然能夠對IP進行監控，但沒法知道IP對應了哪一個用戶。這一點，對運營商來講是一個巨大的挑戰。

　　目前，各廠商所稱道802.1x的優點和安全性很大程度上依賴於私有撥號客戶端。若是一旦客戶端被破解，或者被仿造，那麼不少功能將形如虛設，好比限制代理服務器的使用、綁定IP、客戶端版本的限制等。不少廠商的802.1x校園網介紹中，幾乎有一句相似的話:學生能力有限，很難對客戶端進行破解。但這點着實讓人笑話，事實能夠證實:自802.1x流行之後，幾乎每一個運營商的客戶端都出現了破解版本，並且不少出於高校學生之手。對於某些學生來講，即便經過數據抓包，克隆出徹底同樣的客戶端也是易如反掌的。

　　在社會對網絡安全日趨重視的今天，802.1x產品的開發者更應該注重協議安全的研究，而不是把賭注下在用戶的能力上。