企業辦公網接入認證技術詳解

【網絡接入認證】在企業辦公網場景中最常用到的就是802.1X認證和Portal認證。本文將對802.1X認證技術和Portal認證技術進行詳細講解。

發布時間：2019-04-12
點擊量：
點贊：

分享至

我想評論

背景

辦公網承載著企業內部眾多關鍵業務系統，如果終端連接到網絡中便可直接訪問辦公網絡資源，會帶來網絡被攻擊的風險，企業內部資料有可能被具有非法意圖的攻擊者竊取。如何保證用戶接入網絡的合規與合法性，早已成為業界關注的焦點。網絡接入認證技術就是在這樣的背景下產生的。

多種網絡接入認證方式

接入認證的方式有很多種，在園區網中常見的有以下四種：

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+隨機驗證碼）等。此外，還能通過認證獲得不同的訪問權限。我們可以根據實際需求應用不同的認證方案，關于這些擴展技術方案的實現方式，我們將會在后續的文章中和大家分享。

本期作者：李瑩
銳捷網絡互聯網系統部行業咨詢