用戶身份驗證相關探討

endDatagram =================================

資料來源：本文整理

sFlow 和 NetFlow 的相異點之一，即是 sFlow 提供的不只是 Layer 3 及 Layer 4 的資 料，sFlow 涵蓋的範圍是 Layer 2 至 Layer 7。

2.6 用戶身份驗證相關探討

統計流量是統計網段或是 IP 位址的流量，卻不容易和用戶產生直接的關聯，尤其 是校園或大型組織內部往往採取 DHCP 發放 IP 位址，使得用戶身份的確認更為不易。

本章節將就動態 IP 位址和用戶身份驗證方式等進行探討。

2.6.1 DHCP

DHCP（Dynamic Host Configuration Protocol, 動態主機組態通訊協定）是開放式的 產業標準；定義於 RFC 2131，相關的延伸組態是在 RFC 2132（DHCP Options and BOOTP Vendor Extensions）。

採用 DHCP 可以大幅減少設定 IP 位址相關的管理工作，它可以集中管理 IP 位址，

並將指派的工作自動化，這對於較大型的網路環境是項極其便利的設計。如果沒有動態 指派 IP 位址的功能，用戶端就必須手動一台一台地設定，耗時費力而且日後資訊若有 異動，不但維護不易，管理上更是有所不便。

利用 DHCP 取得 IP 位址的機器，稱為 DHCP Client（DHCP 用戶端），而取得 IP 位 址的過程，則稱之為租用程序（Lease Process）；DHCP 的租用程序分為四個階段，可以

下圖簡示，

Server

(Selected) Client Server

(Not Selected)

1. DHCPDISCOVER

DHCP Client 在網路上廣播自己的名稱（Host Name），以及實體位址（MAC Address），嘗試找尋 DHCP Server（DHCP 伺服器）

2. DHCPOFFER

收到 DHCPDISCOVER 廣播封包的 DHCP Server 會回覆 DHCPOFFER 的封包 給發出 DHCPDISCOVER 的 Client。這個封包內容包括，IP 位址、子網路遮罩

（Subnet Mask）、租用期間；收到 DHCPDISCOVER 的 DHCP Server 會先暫時 保留回覆的 IP 位址，避免將它提供給其它 Client

3. DHCPREQUEST

DHCP Client 在收到第一個回覆的 DHCPOFFER 封包時，會對外廣播

DHCPREQUEST，告訴所有的機器它決定採用這台 DHCP Server 所發出的 IP 位址，並通知其它收到 DHCPDISCOVER 的 DHCP Server，不需要再為它保留 IP 位址

4. DHCPACK

這台第一個回覆DHCPOFFER給DHCP Client的Server，將對Client發出確認的訊 息，允許該Client使用這個IP位址。這個訊息內容尚且包括選擇性的參數，例 如，預設閘道（Default Gateway）、名稱伺服器（DNS Server）等等。

2.6.2 RADIUS

RADIUS（Remote Authentication Dial In User Service, 遠程驗證撥號用戶服務）定義 於 RFC 2865（參考文獻[7]），提供 AAA（Authentication, Authorization, Accounting）功 能，可以作為多個遠端設備驗證、授權、計價的集中式管理協定。遠端設備可以是 VPN

（Virtual Private Network, 虛擬私人網路）設備、無線網路設備、撥接設備等網路存取 設備。它的封包格式於下，

圖 2 - 6 RADIUS Packet Format

資料來源：參考文獻[7]

Code、Identifier 各定義是 8 bits，Length 是 16 bits，Authenticator 有 32 bits，至於 Attributes 則不限長度。

RADIUS 是使用 UDP Port 1812 或是 1645 驗證，UDP Port 1813 或是 1646 計價，

RADIUS 定義的訊息形態簡述於下，

z Access-Request

這個封包會出現在以下情況，

1. Authenticator（驗證者）收到來自用戶（Supplicant）使用系統的請求，而

將這個封包傳送給 RADIUS Server 請求確認用戶身份。

2. Authenticator 利用 PAP（Password Authentication Protocol）傳送未加密的 密碼或是經由 CHAP（Challenge Handshake Authentication Protocol）以 MD5 加密過的密碼給 RADIUS Server。

z Access-Accept

RADIUS Server 確認 Authenticator 是被允許要求驗證的設備（NAS, Network Access Server），並且確認用戶帳號及密碼是合法的，於是回傳 Access-Accept 的訊息給 Authenticator

z Access-Reject

RADIUS Server 發現傳送訊息的 Authenticator 並不是在 NAS 的名單，或是用 戶的帳號及密碼不合法，即回傳此一訊息

z Access-Challenge

RADIUS Server 在收到 Authenticator 傳送過來確認用戶身份的請求訊息時，回 覆 Authenticator 需要用戶的帳號及密碼

整個驗證的過程配合下一小節說明。

RADIUS Accept-Request 的屬性有以下數項和本文相關，

表 2 - 7 RADIUS Accept-Request Attributes

Attribute Description

User-Name (1) Supplicant 送出的用戶帳號

User-Password (2) Supplicant 送出的用戶密碼 NAS-IP-Address (4) Authenticator 的 IP 位址

NAS-Port (5) Authenticator 的連接埠號碼

Called-Station-Id (30) Authenticator 的 MAC 位址 Calling-Station-Id (31) Supplicant 的 MAC 位址

資料來源：參考文獻[7]，本文整理

2.6.3 IEEE 802.1x Port Authentication

IEEE 802.1x Port Authentication 是架構在 RADIUS、RADIUS Extensions（RFC 2869）

和 EAP（Extensible Authentication Protocol, 可擴充式驗證協定, RFC 2284）這些標準，

在於提供網路通訊埠存取的驗證，希冀達到無論是有線或是無線環境網路存取的安全 性。利用 IEEE 802.1x 的技術可以改善網管人員傳統上以 MAC filter 和 ACL（Access Control List）的方式限制用戶的權限，對於較大型的網路環境有其效益。

在 IEEE 802.1x 的環境中，以 MD5 進行加密的驗證過程簡示於下，

圖 2 - 7 IEEE 802.1x Port Authentication 過程示意圖

資料來源：參考文獻[10]，本文整理

1. 一個啟用了 IEEE 802.1x 驗證的請求者（Client/Supplicant）會送出 EAP Start 的 訊息給 Authenticator，此時 Authenticator 發出 EAP-Request/Identity 封包向 Supplicant 表明這是個啟用 IEEE 802.1x 的環境，這個連接埠是需要驗證的

2. Supplicant 收到之後，回覆 EAP-Response/Identity 封包，確認收到這個訊息 3. Authenticator 向 RADIUS 伺服器要求驗證用戶身份

4. RADIUS 伺服器回傳 Access-Challenge 給 Authenticator

5. Authenticator 將 RADIUS 伺服器傳來要求帳號、密碼的封包丟給 Supplicant 6. Supplicant 送出用戶帳號、密碼給 Authenticator，再由 Authenticator 傳給 RADIUS

伺服器確認

7. RADIUS 伺服器回傳確認成功的訊息給 Authenticator

8. Authenticator 將這個連接埠設為已授權過，並回覆 Supplicant EAP-Success 可以 開始存取網路服務了

在整個驗證過程尚未結束之前，Supplicant 連接的網路連接埠是屬於未授權的，除 了 EAP 訊息之外，所有網路服務的封包都無法通過，必須等到驗證成功，連接埠更改 為已授權的，Supplicant 才能存取網路服務。