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产品的开发者更应该注重协议安全的研究，而不是把赌注下在用户的能力上。