802.1X认证协议及漏洞分析
{
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;
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.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产品的开发者更应该注重协议安全的研究，而不是把赌注下在用户的能力上。