背 景
办公网承载着企业内部众多关键业务系统,如果终端连接到网络中便可直接访问办公网络资源,会带来网络被攻击的风险,企业内部资料有可能被具有非法意图的攻击者窃取。如何保证用户接入网络的合规与合法性,早已成为业界关注的焦点。网络接入认证技术就是在这样的背景下产生的。
多种网络接入认证方式
接入认证的方式有很多种,在园区网中常见的有以下四种:
1、802.1X(Port-Based Network Access Control)认证:
• 是一个基于端口的网络存取控制标准,为LAN提供点对点式的安全接入;
• 802.1X的最终目的就是确认一个物理端口或Wi-Fi连接是否可用,如果认证成功就允许使用该物理端口或Wi-Fi连接。
2、Portal认证:
• 也称Web认证,是一种对用户访问网络的权限进行控制的认证方法;
• 当用户需要访问认证服务器以外的其它网络资源时,就必须通过浏览器在Portal服务器上进行身份认证,只有认证通过后才可以访问相关网络资源。
3、PPPoE(Point-to-Point Protocol Over Ethernet)认证:
• 从窄带技术演化而来,PPP最早就是专门为电话线上网而设计的,当宽带普及后,为了兼容以前的电话线用户习惯,故在宽带网络中继承了PPP技术;
• 当客户端要通过PPPoE上网时,它必须首先进行发现阶段以识别对端的以太网MAC地址,并建立一个PPPoE ID,这样才能成功建立一个会话,从而访问网络资源。
4、IPoE认证:
• 又称DHCP+认证,使用DHCP配合其他技术实现认证,如DHCP+OPTION扩展字段进行认证;
• IPoE认证基于上网用户的物理位置(唯一的VLAN ID/PVC ID)对用户进行认证和计费,用户上网时无需输入用户名和密码。
在企业办公网场景中最常用到的就是802.1X认证和Portal认证。本文将对802.1X认证技术和Portal认证技术进行详细讲解。
802.1X认证技术详解
802.1X认证系统构成
如图1所示,802.1X认证系统由恳请者、认证者、认证服务器三个角色构成。在实际应用中,三者分别对应为:客户端(Client)、网络接入控制设备(Network Access Server,NAS)、RADIUS Server。
▲图1:802.1X认证系统构成
• 恳请者
恳请者是客户端所扮演的角色;
它请求对网络的访问,并对认证者的请求报文进行应答;
恳请者必须运行符合802.1X客户端标准的软件(目前各操作系统均已集成支持)。
• 认证者
认证者在客户端与认证服务器之间,一般是交换机、AP等接入设备;
认证者设备也称为NAS,它要负责把从客户端收到的认证信息封装成RADIUS格式的报文并转发给RADIUS Server,同时要把从RADIUS Server收到的信息进行解析后转发给客户端;
认证者设备有两种类型的端口:受控端口(Controlled Port)和非受控端口(Uncontrolled Port):
• 连接在受控端口的用户只有通过认证才能访问网络资源;
• 连接在非受控端口的用户无须经过认证便可以直接访问网络资源。非受控端口主要是用来连接认证服务器,以便保证服务器与设备的正常通讯。
• 认证服务器
认证服务器通常为RADIUS服务器,和认证者配合完成认证;
认证服务器保存了用户名和密码,以及相应的授权信息;
一台服务器可以对多台认证者提供认证服务,这样就可以实现对用户的集中管理。
802.1X认证状态机
认证通过前(非授权状态)
▲图2:认证通过前的端口状态
如图2,端口未认证,受控端口开路,只允许EAPOL(Extensible Authentication Protocol over LAN)报文和广播报文(DHCP,ARP)通过端口,不允许其它业务流通过。
• 认证通过后(授权状态)
▲图3:认证通过后的端口状态
如图3,认证通过后,受控端口闭合,用户的业务流可以顺利通过。
• 认证状态的保持
认证者可以定时要求客户端重新认证,时间可配置,重新认证的过程对用户是无感知的,即用户不需要重新输入密码。
• 下线方式
1) 物理端口Down——拔插网线、关机、断开Wi-Fi等;
2) 重新认证不通过或超时;
3) 用户主动下线;
4) 网管强制下线。
802.1X认证基础协议
▲图4:设备间的报文交互
如图4,客户端和认证者之间用EAPoL格式封装EAP协议传送认证信息;认证者与认证服务器之间通过RADIUS协议传送信息。
• EAPoL协议
802.1x协议定义了一种报文封装格式,这种报文称为EAPoL(EAP over LANs局域网上的扩展认证协议)报文,主要用于在客户端和认证系统之间传送EAP协议报文,以允许EAP协议报文在LAN上传送。
▲图5:EAPoL报文格式
EAPoL报文格式如图5,下面将对报文各字段进行解释:
● PAE(Port Access Entity)Ethernet Type:2字节,表示协议类型,为0x888E;
● Protocol Version:1字节,表示EAPOL帧的发送方所支持的协议版本号;
● Type:1字节,表示EAPoL数据帧类型,具体类型如图6所示;
▲图6:EAPoL数据帧类型
● Length:2字节,表示数据长度,也就是“Packet Body”字段的长度,单位为字节。如果为0,则表示没有后面的数据域;
• EAPoL-Start和EAPoL-Logoff报文的Length值都为0
● Packet Body:表示数据内容,根据不同的Type有不同的格式。
• EAP协议
当EAPoL数据帧格式Type域为EAP-Packet时,Packet Body为EAP数据报文。
▲图7:EAP报文格式
EAP报文格式如图7,下面将对报文各字段进行解释:
●Code:一个字节,指明EAP包的类型,共有4种,定义如下:
1--------Request
2--------Response
3--------Success
4--------Failure
由于该字段值只定义了1到4,如果EAP报文的该字段为其它值,则应被认证者和客户端丢弃;
● Identifier:一个字节,用于应答报文和请求报文之间进行匹配;
● Length:两个字节,EAP包的长度,包含Code、Identifier、Length和Data域,单位为字节;
● Data:EAP数据包内容,长度为零个或多个字节,由Code类型决定。Request和Response类型报文的Data域格式如图8所示:
▲图8:Request/Response Data域格式
Type:1个字节,标识EAP的认证类型,Type字段目前定义的值及其简要说明如下:
• Type=1 ----Identifier(用来询问对端的身份)
• Type=2 ----Notification(非必须的一个消息,传送一些警告消息,比如提示密码将要超期、OTP的顺序号码接近零以及认证失败的警告等)
• Type=3 ----Nak (Response Only)(Request报文中的认证类型不可接受时回复该类型的报文)
• Type=4 ----MD5-Challenge(类似于CHAP中的MD5-Challenge,使用MD5算法)
• Type=5 ----One-Time Password (OTP,一种密码交互的方式)
• Type=6 ----Generic Token Card(通用令牌卡类型,适用于各种需要用户输入信息的令牌卡的实现)
• Type=254 ----Expanded Types(供厂商支持自己的扩展类型)
Type=255 ----Experimental use(在实验新的类型时使用)
Type Data:该字段的内容由Type字段的值决定。
• RADIUS协议
RADIUS是AAA(Authentication、Authorization、Accounting)协议的一个实现,RADIUS协议规定了NAS与RADIUS服务器之间如何传递用户信息和记账信息,RADIUS服务器负责接收用户的连接请求,完成验证,并把传递服务给用户所需的配置信息返回给NAS。
▲图9:RADIUS报文格式
RADIUS报文格式如图9,下面将对报文各字段进行解释:
● Code:代指数据包的编号,标识了该数据包是什么类型的,如果是未知类型的数据包就会被默认丢弃,目前大致有以下几种常用编号:
1----Access-Request(接入请求,认证用)
2----Access-Accept (同意接入,认证用)
3----Access-Reject (拒绝接入,认证用)
4----Accounting-Request(计费请求,计费用)
5----Accounting-Response (计费响应,计费用)
11----Access-Challenge (接入挑战,认证用)
● Identifier:RADIUS报文标识;
● Length:RADIUS报文长度;
● Authenticator:用于RADIUS Client 和Server之间消息认证的有效性,和密码隐藏算法。
• 在Access-Request数据包中,Authenticator的值是16字节随机数,被称为请求认证器,认证字的值要不能被预测并且在一个共享密钥的生命期内唯一;
• 在Access-Accept、Access-Reject和Access-Challenge数据包中的Authenticator被称为响应认证器,值定义为MD5(Code + ID + Length + RequestAuth + Attributes + Secret)。
● Attributes:存储用户的信息,如用户名,IP地址等。
802.1X认证流程详解
802.1X认证过程如图10:
▲图10:802.1X认证过程
1. 当用户访问网络时打开(Windows自带客户端可自动打开)802.1x客户端程序,根据提示输入已经在RADIUS服务器中创建的用户名和密码,发起连接请求,此时,客户端程序将向设备端发出认证请求帧(EAPoL-Start),启动认证过程;
2. NAS收到该报文后,发送一个EAP-Request报文响应客户端的认证请求,要求用户提供用户名信息;
3. 客户端收到EAP-Request之后响应一个EAP-Response报文,将用户名封装在EAP报文中发给NAS;
4. NAS将客户端送来的EAP-Request报文与自己的设备IP、端口等相关信息一起封装在RADIUS Access-Request报文中发给认证服务;
5. 认证服务器收到RADIUS Access-Request报文后进行验证,如果该用户的相关信息有效,则对该用户发起一次认证挑战(RADIUS Access-Challenge),要求用户提供密码;
6. NAS收到这条RADIUS Access-Challenge报文后,将挑战请求用EAP-Challenge Request转发给客户端;
7. 客户端接到挑战请求后,将用户密码进行MD5加密处理,并封装在EAP-Challenge Response中返回给NAS;
8. NAS将用户的EAP-Challenge Response封装为RADIUS Access-Request报文转发给认证服务器;
9. 认证服务器对用户的密码进行验证,如果验证失败,服务器将返回一条RADIUS Access-Reject报文,拒绝用户的认证请求;如果验证通过,则发送一条RADIUS Access-Accept报文给交换机;
10. NAS在接到认证服务器发来的RADIUS Access-Accept之后,解除对客户端的访问控制,同时发送一条EAP-Success报文给客户端通知其认证已经成功;
11. NAS向认证服务器发送一条RADIUS Accounting-Request(Start)报文,申请对该用户进行记账;
12. 认证服务器接到请求后开始记账,并向NAS返回一条RADIUS Accounting-Response报文,告知记账操作已经开始;
13. 用户下线时,客户端向NAS发送一条EAPoL-Logoff报文,申请下线;
14. NAS向认证服务器发送RADIUS Accounting-Request(Stop)请求,申请对该用户停止记账;
15. 认证服务器收到请求后停止记账,同时响应一条RADIUS Accounting-Response报文;
16. NAS发送一条EAPoL Failure消息给客户端提示下线成功,并打开对该用户的访问控制。
Portal认证技术详解
Portal认证,以其轻量、易部署等特点,受到很多企业用户的欢迎。Portal认证业务可以为管理者提供方便的管理功能,如要求所有用户在门户网站进行认证,门户网站可以开展企业个性化信息推广业务等,为信息传播提供一个良好的载体。
Portal认证系统构成
▲图11:Portal认证系统
• Client
认证客户端,通常是一个浏览器,运行HTTP协议,用户通过浏览器上网时浏览器将发出HTTP请求。
• NAS
在网络拓扑中一般是接入层设备,和用户终端设备直接相连;
在NAS上需要启动Portal认证功能,NAS接收Portal Server发过来的用户认证信息,并向RADIUS Server发起认证请求,根据认证结果设置用户是否可以上网,同时向Portal Server反馈认证结果。
• Portal 服务器
提供Portal认证页面,和NAS交互认证客户端的认证信息;
Portal 服务器向客户端推送认证页面,用户在认证页面上填入帐号、密码等信息,提交到Portal服务器,Portal服务器提取其中的账号信息,并将此信息发送到NAS,同时根据NAS反馈的认证结果,通过页面反馈给用户;
Portal服务器可分为内置Portal服务器和外置Portal服务器两种。
• 通常交换机/AC会内置Portal服务器。受限于接入设备存储空间、功能和性能,内置Portal服务器只适合功能简单、接入人数少的场景;
• 如果需要实现微信接入、短信接入等复杂的功能,考虑到接入设备性能和认证体验,需要具有独立于接入设备之外的硬件服务器来承载Portal认证业务。
• RADIUS服务器
与NAS进行交互,提供基于RADIUS协议的用户认证,从而完成对用户的认证、计费和授权。
Portal认证状态机
• 认证通过前
客户端通过手动配置或DHCP获取的一个公网IP进行认证,通过认证前用户的所有HTTP请求都重定向(利用的是HTTP协议中的302报文的特性)到Portal服务器。
• 认证通过后
接入设备会打开端口,允许用户访问被管理员授权的互联网资源。
• 认证状态的保持
客户端和Portal 服务器定时发送心跳报文交互,对于客户端来说,4个心跳报文没有收到答复,就认为自己已经下线,重新发起认证;对于Portal服务器,在指定的时间内没有收到心跳报文,就认为用户下线,并通知接入设备将用户下线。但在实际应用中,以锐捷的交换机(交换机做NAS)为例,如果在一定时间内没有收到流量即认为用户下线。
• 下线方式
1) 物理端口Down——拔插网线、关机、断开Wi-Fi等;
2) 重新认证不通过或超时;
3) 用户主动下线;
4) 网管强制下线。
Portal认证基础协议
• Portal协议
Portal协议是一种私有协议,承载于TCP上。Portal协议目前有两个版本:Portal v1.0和Portal v2.0,v2.0协议是对原有v1.0协议存在的漏洞和不合理处进行部分完善:
1. 修改了报文格式,在AttrNum字段之后增加了16个字节的Authenticator字段;
2. 增加对所有协议报文的校验,包括上线流程、下线流程和查询流程;
3. 修改了TextInfo属性,使其完全符合TLV【Tag(标签),Length(长度),Value(值)】格式。
若v1.0与v2.0有冲突的地方,目前均以v2.0版本为准。
▲图12:Portal报文格式
Portal报文如图12,下面将对各字段进行解释:
● Ver:协议的版本号,长度为 1 字节,Ver = 0x01或0x02;
● Type:定义报文的类型,长度为 1 字节;
● Pap/Chap :Pap/Chap字段定义此用户的认证方式,长度为 1 字节,只对Type值为 0x03 的认证请求报文有意义:
• Chap方式认证---值为0x00
• Pap 方式认证---值为0x01
● Rsv:Rsv目前为保留字段,长度为 1 字节,在所有报文中值为 0;
● SerialNo:报文的序列号,长度为 2 字节,由PortalServer随机生成,该字段作用主要用于区别同类型但不同认证流程中的报文;
● ReqID:2个字节,由认证设备随机生成,该字段作用主要用于区别同类型但不同认证流程中的报文,该字段对于PAP认证无意义,在Chap认证中,该字段低8位作为Chap_Password 生成过程中MD5函数的输入;
● UserIP:Portal用户的IP地址,长度为 4 字节,其值由PortalServer根据其获得的IP地址填写,在所有的报文中此字段都要有具体的值;
● UserPort:该字段目前没有用到,长度为 2 字节,在所有报文中其值为0;
● ErrCode:该字段和Type字段一起表示一定的意义,长度为 1字节,各组合意义如下表:
▲表1: ErrCode值表
说明:其中type类型为9、10的两个报文其ErrCode的定义为v2.0新增定义。
● AttrNum:表示其后边可变长度的属性字段属性的个数,长度为 1 字节,即最多可携带属性255个属性。
Portal认证流程详解
Portal认证流程如下:
▲图13:Portal认证流程
1. 用户通过标准的DHCP协议获取到规划的IP地址;
2. 用户打开IE,访问某个网站,发起HTTP请求;
3. NAS截获用户的HTTP请求,由于用户没有认证过,就强制到Portal服务器;
4. Portal服务器向用户终端推送Web认证页面;
5. 用户在认证页面上填入帐号、密码等信息,提交到Portal服务器;
6. Portal服务器将接收到的用户认证信息发给NAS;
7. NAS向RADIUS服务器发起RADIUS认证;
8. RADIUS服务器根据用户信息判断用户是否合法,向NAS返回认证结果报文;
9. NAS返回认证结果给Portal服务器;
10. Portal服务器根据认证结果,推送认证结果页面;
11. Portal服务器回应NAS收到认证结果报文,如果认证失败,则流程到此结束;
12. 认证如果成功,NAS发起计费开始请求给RADIUS服务器;
13. RADIUS服务器回应计费开始响应报文,并将响应信息返回给NAS,用户上线完毕,开始上网;
14. 在用户上网过程中,为了保护用户计费信息,每隔一段时间NAS就向RADIUS服务器发送记账更新报文;
15. RADIUS服务器回应实时计费确认报文给NAS。
总 结
本文对802.1X 和Portal 认证进行了工作原理和认证流程的详细阐述。简单的说,802.1X认证的最终目的,就是确定一个端口(物理端口或Wi-Fi连接)是否能被放通,从而实现对接入实体的管控。对于一个端口,如果认证成功就打开这个端口,并提供网络服务;如果认证失败就使这个端口保持关闭,不提供网络服务。Portal认证的本质其实和802.1X一样,都是基于认证结果判断接口是否可用。相对于802.1X认证来说,Portal更轻量化,无需安装客户端软件,浏览器即可完成认证。同时,由于Portal服务器和用户浏览器有页面交互,用户可以根据实际需求对认证页面进行定制,将认证主页建设为企业网内部员工信息发布平台。
值得注意的是,现在很多认证方案都是基于这两种认证的,比如双因子认证(用户名密码+短信验证码)、无感知认证(802.1X+MAC或Portal+MAC)、证书认证(802.1X+证书或Portal+证书)、OTP认证(802.1X+随机验证码或Portal+随机验证码)等。此外,还能通过认证获得不同的访问权限。我们可以根据实际需求应用不同的认证方案,关于这些扩展技术方案的实现方式,我们将会在后续的文章中和大家分享。
本期作者:李莹
锐捷网络互联网系统部行业咨询
往期精彩回顾
- 【第一期】浅谈物联网技术之通信协议的纷争
- 【第二期】如何通过网络遥测(Network Telemetry)技术实现精细化网络运维?
- 【第三期】畅谈数据中心网络运维自动化
- 【第四期】基于Rogue AP反制的无线安全技术探讨
- 【第五期】流量可视化之ERSPAN的前世今生
- 【第六期】如何实现数据中心网络架构“去”堆叠
- 【第七期】运维可视化之INT功能详解
- 【第八期】浅析RDMA网络下MMU水线设置
- 【第九期】第七代无线技术802.11ax详解
- 【第十期】数据中心自动化运维技术探索之交换机零配置上线
- 【第十一期】 浅谈数据中心100G光模块
- 【第十二期】数据中心网络等价多路径(ECMP)技术应用研究
- 【第十三期】如何为RDMA构建无损网络
- 【第十四期】基于EVPN的分布式VXLAN实现方案
- 【第十五期】数据中心自动化运维技术探索之NETCONF
- 【第十六期】一文读懂网络界新贵Segment Routing技术化繁为简的奥秘
- 【第十七期】浅谈UWB(超宽带)室内定位技术
- 【第十八期】PoE以太网供电技术详解
- 【第十九期】机框式核心交换机硬件架构演进
- 【第二十期】 IPv6基础篇(上)——地址与报文格式
- 【第二十一期】IPv6系列基础篇(下)——邻居发现协议NDP
- 【第二十二期】IPv6系列安全篇——SAVI技术解析
- 【第二十三期】IPv6系列安全篇——园区网IPv6的接入安全策略
- 【第二十四期】Wi-Fi 6真的很“6”(概述篇)——不只是更高的传输速率
- 【第二十五期】 Wi-Fi 6真的很“6”(技术篇) ——前方高能,小白慎入
- 【第二十六期】IPv6系列应用篇——数据中心IPv4/IPv6双栈架构探讨
- 【第二十七期】你不可忽视的园区网ARP安全防护
相关推荐:
更多技术博文
-
全调度以太网(GSE),中国智算网络新标准
GSE网络作为一种全调度以太网技术,专为大规模AI训练集群设计,通过按需调度实现无损性能,提供灵活快速的部署方案,构建开放生态,显著提升智算效率和运维体验。
-
#知识百科
-
-
以太和PON,谁能更好地支撑办公室横向流量业务?
了解以太彩光与PON的区别,解析办公资源共享难题,锐捷极简以太彩光方案助您高效适配办公网,共享打印无压力!
-
#交换机
-
-
场景无线 驱动高效办公!锐捷新一代企业无线办公解决方案全新发布!
面对企业数智化转型中的无线办公网络挑战,锐捷新一代企业无线办公解决方案通过全场景AP、智能调度与云端智能运维等技术,实现网络性能、用户体验与运维效率的全面提升。
-
#无线网
-
#办公网
-
-
以太彩光和PON,运维管理谁技高一筹?
锐捷网络提供极简以太全光方案,简化配置流程,降低学习成本,让全光网络升级更平滑。
-
#交换机
-