1.802.1X 前端
IEEE802 LAN/WAN委員會爲解決無線局域網網絡安全問題,提出了802.1X協議。後來,802.1X協議做爲局域網端口的一個普通接入控制機制在以太網中被普遍應用,主要解決以太網內認證和安全方面的問題。算法
802.1X協議是一種基於端口的網絡接入控制協議(port based network access control protocol)。「基於端口的網絡接入控制」是指在局域網接入設備的端口這一級對所接入的用戶設備進行認證和控制。數據庫
鏈接在端口上的用戶設備若是能經過認證,就能夠訪問局域網中的資源;若是不能經過認證,則沒法訪問局域網中的資源。後端
2.802.1X的體系結構 瀏覽器
802.1X系統爲典型的Client/Server結構,如圖 1所示,包括三個實體:客戶端(Client)、設備端(Device)和認證服務器(Server)。安全
1)客戶端是位於局域網段一端的一個實體,由該鏈路另外一端的設備端對其進行認證。客戶端通常爲一個用戶終端設備,用戶能夠經過啓動客戶端軟件發起802.1X認證。服務器
客戶端必須支持EAPOL(Extensible Authentication Protocol over LAN,局域網上的可擴展認證協議)。網絡
2) 設備端是位於局域網段一端的另外一個實體,對所鏈接的客戶端進行認證。設備端一般爲支持802.1X協議的網絡設備,它爲客戶端提供接入局域網的端口,該端口能夠是物理端口,也能夠是邏輯端口。session
3) 認證服務器是爲設備端提供認證服務的實體。認證服務器用於實現對用戶進行認證、受權和計費,一般爲RADIUS(Remote Authentication Dial-In User Service,遠程認證撥號用戶服務)服務器。dom
3.802.1X的認證方式
802.1X認證系統使用EAP(Extensible Authentication Protocol,可擴展認證協議),來實現客戶端、設備端和認證服務器之間認證信息的交換。
在客戶端與設備端之間,EAP協議報文使用EAPOL封裝格式,直接承載於LAN環境中。
在設備端與RADIUS服務器之間,可使用兩種方式來交換信息。一種是EAP協議報文由設備端進行中繼,使用EAPOR(EAP over RADIUS)封裝格式承載於RADIUS協議中;
另外一種是EAP協議報文由設備端進行終結,採用包含PAP(Password Authentication Protocol,密碼驗證協議)或CHAP(Challenge Handshake Authentication Protocal,質詢握手驗證協議)屬性的報文與RADIUS服務器進行認證交互。
4.802.1X的基本概念
1)受控/非受控端口
設備端爲客戶端提供接入局域網的端口,這個端口被劃分爲兩個邏輯端口:受控端口和非受控端口。任何到達該端口的幀,在受控端口與非受控端口上都可見。
非受控端口始終處於雙向連通狀態,主要用來傳遞EAPOL協議幀,保證客戶端始終可以發出或接收認證報文。
受控端口在受權狀態下處於雙向連通狀態,用於傳遞業務報文;在非受權狀態下禁止從客戶端接收任何報文。
2)受權/非受權狀態
設備端利用認證服務器對須要接入局域網的客戶端執行認證,並根據認證結果(Accept或Reject)對受控端口的受權/非受權狀態進行相應地控制。
用戶能夠經過在端口下配置的接入控制的模式來控制端口的受權狀態。端口支持如下三種接入控制模式:
強制受權模式(authorized-force):表示端口始終處於受權狀態,容許用戶不經認證受權便可訪問網絡資源。
強制非受權模式(unauthorized-force):表示端口始終處於非受權狀態,不容許用戶進行認證。設備端不對經過該端口接入的客戶端提供認證服務。
自動識別模式(auto):表示端口初始狀態爲非受權狀態,僅容許EAPOL報文收發,不容許用戶訪問網絡資源;若是認證經過,則端口切換到受權狀態,容許用戶訪問網絡資源。這也是最多見的狀況。
3)受控方向
在非受權狀態下,受控端口能夠被設置成單向受控和雙向受控。
實行雙向受控時,禁止幀的發送和接收;
實行單向受控時,禁止從客戶端接收幀,但容許向客戶端發送幀。
5.802.1X的認證觸發方式
1)客戶端主動觸發方式
客戶端主動向設備端發送EAPOL-Start報文來觸發認證,該報文目的地址爲IEEE 802.1X協議分配的一個組播MAC地址:01-80-C2-00-00-03。
另外,因爲網絡中有些設備不支持上述的組播報文,使得認證設備沒法收到客戶端的認證請求,所以設備端還支持廣播觸發方式,即,能夠接收客戶端發送的目的地址爲廣播MAC地址的EAPOL-Start報文。這種觸發方式須要可能須要802.1X客戶端的配合。
2)設備端主動觸發方式
設備會每隔N秒(例如30秒)主動向客戶端發送EAP-Request/Identity報文來觸發認證,這種觸發方式用於支持不能主動發送EAPOL-Start報文的客戶端,例如Windows XP自帶的802.1X客戶端。
6.802.1X的認證過程
802.1X系統支持EAP中繼方式和EAP終結方式與遠端RADIUS服務器交互完成認證。如下關於兩種認證方式的過程描述,都以客戶端主動發起認證爲例。
1)EAP中繼方式
這種方式是IEEE 802.1X標準規定的,將EAP(可擴展認證協議)承載在其它高層協議中,如EAP over RADIUS,以便擴展認證協議報文穿越複雜的網絡到達認證服務器。
通常來講,EAP中繼方式須要RADIUS服務器支持EAP屬性:EAP-Message和Message-Authenticator,分別用來封裝EAP報文及對攜帶EAP-Message的RADIUS報文進行保護。
下面以EAP-MD5方式爲例介紹基本業務流程,
認證過程以下:
(1) 當用戶有訪問網絡需求時打開802.1X客戶端程序,輸入已經申請、登記過的用戶名和密碼,發起鏈接請求(EAPOL-Start報文)。此時,客戶端程序將發出請求認證的報文給設備端,開始啓動一次認證過程。
(2) 設備端收到請求認證的數據幀後,將發出一個請求幀(EAP-Request/Identity報文)要求用戶的客戶端程序發送輸入的用戶名。
(3) 客戶端程序響應設備端發出的請求,將用戶名信息經過數據幀(EAP-Response/Identity報文)發送給設備端。設備端將客戶端發送的數據幀通過封包處理後(RADIUS Access-Request報文)送給認證服務器進行處理。
(4) RADIUS服務器收到設備端轉發的用戶名信息後,將該信息與數據庫中的用戶名錶對比,找到該用戶名對應的密碼信息,用隨機生成的一個加密字對它進行加密處理,
同時也將此加密字經過RADIUS Access-Challenge報文發送給設備端,由設備端轉發給客戶端程序。
(5) 客戶端程序收到由設備端傳來的加密字(EAP-Request/MD5 Challenge報文)後,用該加密字對密碼部分進行加密處理(此種加密算法一般是不可逆的),生成EAP-Response/MD5 Challenge報文,並經過設備端傳給認證服務器。
(6) RADIUS服務器將收到的已加密的密碼信息(RADIUS Access-Request報文)和本地通過加密運算後的密碼信息進行對比,若是相同,則認爲該用戶爲合法用戶,反饋認證經過的消息(RADIUS Access-Accept報文和EAP-Success報文)。
(7) 設備收到認證經過消息後將端口改成受權狀態,容許用戶經過端口訪問網絡。在此期間,設備端會經過向客戶端按期發送握手報文的方法,對用戶的在線狀況進行監測。
缺省狀況下,兩次握手請求報文都得不到客戶端應答,設備端就會讓用戶下線,防止用戶由於異常緣由下線而設備沒法感知。
(8) 客戶端也能夠發送EAPOL-Logoff報文給設備端,主動要求下線。設備端把端口狀態從受權狀態改變成未受權狀態,並向客戶端發送EAP-Failure報文。
2)EAP終結方式
這種方式將EAP報文在設備端終結並映射到RADIUS報文中,利用標準RADIUS協議完成認證、受權和計費。設備端與RADIUS服務器之間能夠採用PAP或者CHAP認證方法。如下以CHAP認證方法爲例介紹基本業務流程
EAP終結方式與EAP中繼方式的認證流程相比,不一樣之處在於用來對用戶密碼信息進行加密處理的隨機加密字由設備端生成,以後設備端會把用戶名、隨機加密字和客戶端加密後的密碼信息一塊兒送給RADIUS服務器,進行相關的認證處理。
7.802.1X的接入控制方式
設備不只支持協議所規定的基於端口的接入認證方式,還對其進行了擴展和優化,支持基於MAC的接入控制方式。
當採用基於端口的接入控制方式時,只要該端口下的第一個用戶認證成功後,其它接入用戶無須認證就可以使用網絡資源,可是當第一個用戶下線後,其它用戶也會被拒絕使用網絡。
採用基於MAC的接入控制方式時,該端口下的全部接入用戶均須要單獨認證,當某個用戶下線時,也只有該用戶沒法使用網絡。
8.802.1X的定時器
802.1X認證過程當中會啓動多個定時器以控制接入用戶、設備以及RADIUS服務器之間進行合理、有序的交互。802.1X的定時器主要有如下幾種:
1)用戶名請求超時定時器(tx-period):該定時器定義了兩個時間間隔。其一,當設備端向客戶端發送EAP-Request/Identity請求報文後,設備端啓動該定時器,若在tx-period設置的時間間隔內,設備端沒有收到客戶端的響應,則設備端將重發認證請求報文;
其二,爲了兼容不主動發送EAPOL-Start鏈接請求報文的客戶端,設備會按期組播EAP-Request/Identity請求報文來檢測客戶端。tx-period定義了該組播報文的發送時間間隔。
2)客戶端認證超時定時器(supp-timeout):當設備端向客戶端發送了EAP-Request/MD5 Challenge請求報文後,設備端啓動此定時器,若在該定時器設置的時長內,設備端沒有收到客戶端的響應,設備端將重發該報文。
3) 認證服務器超時定時器(server-timeout):當設備端向認證服務器發送了RADIUS Access-Request請求報文後,設備端啓動server-timeout定時器,若在該定時器設置的時長內,設備端沒有收到認證服務器的響應,設備端將重發認證請求報文。
4)握手定時器(handshake-period):此定時器是在用戶認證成功後啓動的,設備端以此間隔爲週期發送握手請求報文,以按期檢測用戶的在線狀況。若是配置發送次數爲N,則當設備端連續N次沒有收到客戶端的響應報文,就認爲用戶已經下線。
5)靜默定時器(quiet-period):對用戶認證失敗之後,設備端須要靜默一段時間(該時間由靜默定時器設置),在靜默期間,設備端不處理該用戶的認證請求。
6)週期性重認證定時器(reauth-period):若是端口下開啓了週期性重認證功能,設備端以此定時器設置的時間間隔爲週期對該端口在線用戶發起重認證。
9.和802.1X配合使用的特性
1)VLAN下發
802.1X用戶在服務器上經過認證時,服務器會把受權信息傳送給設備端。若是服務器上配置了下發VLAN功能,則受權信息中含有受權下發的VLAN信息,設備根據用戶認證上線的端口鏈路類型,按如下三種狀況將端口加入下發VLAN中。
端口的鏈路類型爲Access,當前Access端口離開用戶配置的VLAN並加入受權下發的VLAN中。
端口的鏈路類型爲Trunk,設備容許受權下發的VLAN經過當前Trunk端口,而且端口的缺省VLAN ID爲下發VLAN的VLAN ID。
端口的鏈路類型爲Hybrid,設備容許受權下發的VLAN以不攜帶Tag的方式經過當前Hybrid端口,而且端口的缺省VLAN ID爲下發VLAN的VLAN ID。
須要注意的是,若當前Hybrid端口上配置了基於MAC的VLAN,則設備將根據認證服務器下發的受權VLAN動態地建立基於用戶MAC的VLAN,而端口的缺省VLAN ID並不改變。
受權下發的VLAN並不改變端口的配置,也不影響端口的配置。可是,受權下發的VLAN的優先級高於用戶配置的VLAN,即經過認證後起做用的VLAN是受權下發的VLAN,用戶配置的VLAN在用戶下線後生效。
2)Guetst VLAN
Guest VLAN功能容許用戶在未認證的狀況下,能夠訪問某一特定VLAN中的資源,好比獲取客戶端軟件,升級客戶端或執行其餘一些用戶升級程序。這個VLAN稱之爲Guest VLAN。
根據端口的接入控制方式不一樣,能夠將Guest VLAN劃分基於端口的Guest VLAN和基於MAC的Guest VLAN。
1)PGV(Port-based Guest VLAN)
在接入控制方式爲portbased的端口上配置的Guest VLAN稱爲PGV。若在必定的時間內(默認90秒),配置了PGV的端口上無客戶端進行認證,則該端口將被加入Guest VLAN,全部在該端口接入的用戶將被受權訪問Guest VLAN裏的資源。
端口加入Guest VLAN的狀況與加入受權下發VLAN相同,與端口鏈路類型有關。
當端口上處於Guest VLAN中的用戶發起認證且失敗時:若是端口配置了Auth-Fail VLAN,則該端口會被加入Auth-Fail VLAN;若是端口未配置Auth-Fail VLAN,則該端口仍然處於Guest VLAN內。
當端口上處於Guest VLAN中的用戶發起認證且成功時,端口會離開Guest VLAN,以後端口加入VLAN狀況與認證服務器是否下發VLAN有關,具體以下:
若認證服務器下發VLAN,則端口加入下發的VLAN中。用戶下線後,端口離開下發的VLAN回到初始VLAN中,該初始VLAN爲端口加入Guest VLAN以前所在的VLAN。
若認證服務器未下發VLAN,則端口回到初始VLAN中。用戶下線後,端口仍在該初始VLAN中。
2)MGV(MAC-based Guest VLAN)
在接入控制方式爲mac based的端口上配置的Guest VLAN稱爲MGV。配置了MGV的端口上未認證的用戶被受權訪問Guest VLAN裏的資源。
當端口上處於Guest VLAN中的用戶發起認證且失敗時:若是端口配置了Auth-Fail VLAN,則認證失敗的用戶將被加入Auth-Fail VLAN;若是端口未配置Auth-Fail VLAN,則該用戶將仍然處於Guest VLAN內。
當端口上處於Guest VLAN中的用戶發起認證且成功時,設備會根據認證服務器是否下發VLAN決定將該用戶加入到下發的VLAN中,或回到加入Guest VLAN以前端口所在的初始VLAN。
3)Auth-Fail VLAN
Auth-Fail VLAN功能容許用戶在認證失敗的狀況下能夠訪問某一特定VLAN中的資源,這個VLAN稱之爲Auth-Fail VLAN。
須要注意的是,這裏的認證失敗是認證服務器因某種緣由明確拒絕用戶認證經過,好比用戶密碼錯誤,而不是認證超時或網絡鏈接等緣由形成的認證失敗。
與Guest VLAN相似,根據端口的接入控制方式不一樣,能夠將Auth-Fail VLAN劃分爲基於端口的Auth-Fail VLAN和基於MAC的Auth-Fail VLAN。
1)PAFV(Port-based Auth-Fail VLAN)
在接入控制方式爲portbased的端口上配置的Auth-Fail VLAN稱爲PAFV。在配置了PAFV的端口上,如有用戶認證失敗,則該端口會被加入到Auth-Fail VLAN,全部在該端口接入的用戶將被受權訪問Auth-Fail VLAN裏的資源。
端口加入Auth-Fail VLAN的狀況與加入受權下發VLAN相同,與端口鏈路類型有關。
當端口上處於Auth-Fail VLAN中的用戶再次發起認證時:若是認證失敗,則該端口將會仍然處於Auth-Fail VLAN內;若是認證成功,則該端口會離開Auth-Fail VLAN,以後端口加入VLAN狀況與認證服務器是否下發VLAN有關,具體以下:
若認證服務器下發VLAN,則端口加入下發的VLAN中。用戶下線後,端口會離開下發的VLAN回到初始VLAN中,該初始VLAN爲端口加入任何受權VLAN以前所在的VLAN。
若認證服務器未下發VLAN,則端口回到初始VLAN中。用戶下線後,端口仍在該初始VLAN中。
2)MAFV(MAC-based Auth-Fail VLAN)
在接入控制方式爲macbased的端口上配置的Auth-Fail VLAN稱爲MAFV。在配置了MAFV的端口上,認證失敗的用戶將被受權訪問Auth-Fail VLAN裏的資源。
當Auth-Fail VLAN中的用戶再次發起認證時,若是認證成功,則設備會根據認證服務器是否下發VLAN決定將該用戶加入到下發的VLAN中,或回到加入Auth-Fail VLAN以前端口所在的初始VLAN。
4)ACL下發
ACL(Access Control List,訪問控制列表)提供了控制用戶訪問網絡資源和限制用戶訪問權限的功能。當用戶上線時,若是RADIUS服務器上配置了受權ACL,則設備會根據服務器下發的受權ACL對用戶所在端口的數據流進行控制;
在服務器上配置受權ACL以前,須要在設備上配置相應的規則。管理員能夠經過改變服務器的受權ACL設置或設備上對應的ACL規則來改變用戶的訪問權限。
5)指定端口的強制認證域
指定端口的強制認證域(mandatory domain)爲802.1X接入提供了一種安全控制策略。全部從該端口接入的802.1X用戶將被強制使用該認證域來進行認證、受權和計費,能夠防止用戶經過惡意假冒其它域帳號來接入網絡。
另外,對於採用證書的EAP中繼方式的802.1X認證來講,接入用戶的客戶端證書決定了用戶的域名。
所以,即便全部端口上客戶端的用戶證書隸屬於同一證書頒發機構,即輸入的用戶域名相同,管理員也能夠經過配置強制認證域對不一樣端口指定不一樣的認證域,從而增長了管理員部署802.1X接入策略的靈活性。
10.802.1X支持EAD快讀部署配置
1)概述
EAD(Endpoint Admission Defense,端點准入防護)做爲一個網絡端點接入控制方案,它經過安全客戶端、安全策略服務器、接入設備以及第三方服務器的聯動,增強了對用戶的集中管理,提高了網絡的總體防護能力。
可是在實際的應用過程當中EAD客戶端的部署工做量很大,例如,須要網絡管理員手動爲每個EAD客戶端下載、升級客戶端軟件,這在EAD客戶端數目較多的狀況下給管理員帶來了操做上的不便。
802.1X認證支持的EAD快速部署就能夠解決以上問題,可爲全部接入網絡的終端用戶提供自動下載並安裝EAD客戶端的方便途徑。
2)實現機制
802.1X支持的EAD快速部署是經過如下兩個功能的配合工做實現的:
(1) 用戶受限訪問
802.1X認證成功以前(包括認證失敗),終端用戶只能訪問一個特定的IP地址段。該IP地址段中能夠配置一個或多個特定服務器,用於提供EAD客戶端的下載升級或者動態地址分配等服務。
(2) 用戶HTTP訪問URL重定向
終端用戶在802.1X認證成功以前(包括認證失敗),若是使用瀏覽器訪問網絡,設備會將用戶訪問的URL重定向到已配置的URL(例如,重定向到EAD客戶端下載界面),
這樣只要用戶打開瀏覽器,就必須進入管理員預設的界面。提供重定向URL的服務器必須位於用戶受限訪問的特定網段內。
11.思科交換機802.1X配置
aaa new-model #啓用3A
aaa authentication login default line none #建立缺省登陸認證列表。採用line password。
aaa authentication dot1x default group radius #AAA缺省經過802.1X,使用radius認證服務。
aaa authorization network default group radius #AAA缺省經過radius網絡受權。
dot1x system-auth-control #全局啓用802.1X。
dot1x guest-vlan supplicant #容許客戶端切換到guest-vlan(可選配置)。
authentication mac-move permit #啓用mac-move(可選,在hub接入場景中適用)
radius-server host 192.168.1.1 auth-port 1812 acct-port 1813 test username yy idle-time 1 key leagsoft #指定radius服務器IP地址,認證和受權端口及安全字。(添加測試radius在交換機的狀態,IOS15.0以上支持)
radius-server host 172.16.1.1 auth-port 1812 acct-port 1813 test username yy idle-time 1 key leagsoft #指定備radius服務器。(添加測試radius在交換機的狀態,IOS15.0以上支持)
radius-server retry method reorder #將dead的radius優先級下降,缺省狀況是不調整的
radius-server retransmit 2 #radius服務器重傳次數(缺省爲3次)
radius-server timeout 3 #指定認證包的超時,缺省爲5秒。
radius-server deadtime 3 #3分鐘連不上radius測認爲服務器宕機缺省爲5分鐘。
radius-server vsa send authentication #發起認證的時候CISCO加上本身的特別屬性。
interface FastEthernet0/1 #
switchport access vlan 10 #
switchport mode access #
authentication event server dead action reinitialize VLAN 10 #當radius服務器down掉時接入vlan 10(逃生)。
authentication event server alive action reinitialize #當Radius Server 恢復時,自動從新認證
authentication host-mode multi-auth # 端口配置多認證模式,不支持vlan切換(按需配置),單主機模式,multi-host多主機模式(其中一臺認證經過全放行),multi-domain多域模式(IP電話場景應用)。
authentication port-control autosingle-host # 當端口接入設備時自動進行認證。
authentication periodic # 容許端口進行重認證。
authentication timer restart 360 # 受權失敗時,360秒自動重認證(缺省爲60秒)。
authentication timer reauthenticate server # 重認證時間由Radius動態控制(不配置爲1小時)。
authentication timer inactivity server # 閒置超時由Radius動態控制(可選)。
mab eap # 端口開啓MAB認證功能。
dot1x pae authenticator # 接口開啓802.1X認證功能。
dot1x timeout tx-period 5 # 在接口設置重認證週期爲5秒。(可選)
dot1x max-req 1 # 在接口設置最大認證嘗試次數。(可選)
dot1x max-reauth-req 1 # 在接口設置重認證嘗試次數。(可選)
spanning-tree portfast # 設置該端口爲快速端口。
如下配置與802.1x下發ACL有關(注:12.2以上支持)
ip device tracking # 使DHCP與ARP觸發認證
ip http server # 全局下開啓HTTP服務,下發ACL重定向依賴該服務。
ip access-list extended quarantine_url_redir_acl # 新建quarantine_url_redir_acl用於重定向流量匹配條件
deny tcp any host 192.168.1.1 eq 443 # 不重定向來自服務器IP的443端口流量
deny tcp any host 192.168.1.1 eq www # 不重定向來自服務器IP的80端口流量
permit tcp any any eq www # 重定向來自全部主機的80端口流量
permit tcp any any eq 443 # 重定向來自全部主機的443端口流量
查看:Show authentication sessions interface f0/1 Show authentication sessions interface f0/1 details
參考:http://www.h3c.com/cn/d_200812/624138_30003_0.htm#_Toc227664913