Linux RADIUS EAP-TLS 認證與負載平衡組態

在 Linux 環境下，RADIUS 伺服器搭配 EAP-TLS 認證機制，能有效提升網路安全性，特別是在無線和有線網路的存取控制方面。EAP-TLS 利用數位憑證進行雙向驗證，確保使用者端和伺服器身份的合法性，有效防止中間人攻擊和其他安全威脅。此外，文章也介紹瞭如何在 Cisco 無線控制器和交換機上組態 802.1x/EAP-TLS，並提供相關的程式碼範例和注意事項，方便實務操作。同時，文章也探討了負載平衡技術，包括 RRDNS 和 HAProxy，並比較了它們的特性和適用場景，以及如何在 Linux 系統上組態和使用這些技術，以提升系統的可用性和效能。最後，文章也強調了負載平衡器本身的安全性，提醒管理員需要注意相關的安全措施，以確保系統的整體安全。

RADIUS 服務於 Linux 的應用：EAP-TLS 認證組態詳解

EAP-TLS 認證機制解析

EAP-TLS 是一種擴充套件 RADIUS 協定功能的方法，主要用於增強身份驗證的安全性。EAP-TLS 結合了 TLS（Transport Layer Security）協定，使用數位憑證進行雙向認證，確保客戶端和伺服器雙方的身份真實性。

EAP-TLS 工作原理

1. 客戶端（Supplicant） 向 RADIUS 伺服器提供其身份資訊，通常使用使用者或裝置憑證。
2. RADIUS 伺服器 驗證客戶端的憑證，並根據預設規則決定是否允許存取。
3. 客戶端 也會驗證 RADIUS 伺服器的身份，確保伺服器憑證中的 Common Name (CN) 與伺服器名稱相符，並且該憑證由可信的 CA 簽發。
4. 完成雙向認證後，客戶端與網路裝置（如交換機或無線存取點）之間建立安全的網路連線。

此流程確保了雙方身份的真實性，並防止惡意 RADIUS 伺服器的佈署（如 “Evil Twin” 無線攻擊）。

無線網路中使用 802.1x/EAP-TLS 認證

在大多數企業環境中，EAP-TLS 與 802.1x 協定結合使用，以控制對無線或有線網路的存取。EAP-TLS 提供了比其他無線認證方法更強的安全性，因為它根據憑證進行雙向認證。

在 Cisco 無線控制器上的組態步驟

1. 定義 RADIUS 伺服器：在無線控制器的 GUI 中組態 RADIUS 伺服器的 IP 地址和分享金鑰，用於認證和計費。

   圖 9.6 – 無線控制器上的 RADIUS 伺服器組態
   

2. 組態 SSID 使用 802.1x 認證：在 SSID 定義中選擇 802.1x 作為認證方法。

   圖 9.7 – 組態 SSID 使用 802.1x 認證
   

3. 將 RADIUS 伺服器與 SSID 繫結：在 AAA 伺服器設定中，將已組態的 RADIUS 伺服器與 SSID 相關聯，用於處理認證和計費請求。

   圖 9.8 – 為 802.1x 認證和計費分配 RADIUS 伺服器
   

重點注意事項

• 所有相關裝置和使用者需要預先安裝必要的憑證，包括 RADIUS 伺服器憑證和客戶端憑證。
• CA 需要被所有裝置和使用者信任，通常使用私有的 CA 以便於管理和控制。
• 在認證過程中，客戶端和 RADIUS 伺服器不會直接與 CA 通訊。

有線網路中使用 802.1x/EAP-TLS 認證

在有線網路環境中，802.1x/EAP-TLS 也可用於對工作站進行身份驗證。以下展示了在 Cisco 交換機上的組態範例。

組態範例

Switch(config)# interface gigabitEthernet 0/1
Switch(config-if)# switchport mode access
Switch(config-if)# authentication port-control auto
Switch(config-if)# dot1x pae authenticator

詳細解說：

1. interface gigabitEthernet 0/1：選擇需要組態的介面。
2. switchport mode access：將介面設定為存取模式。
3. authentication port-control auto：啟用介面的802.1x身份驗證功能。
4. dot1x pae authenticator：將裝置組態為802.1x認證者。

安全考量

• 為了提高安全性，建議所有裝置（包括電話和電腦）都進行 EAP-TLS 認證，而不僅僅是信任特定裝置（如語音 VLAN 中的電話）。
• 如果僅信任特定 VLAN，可能會被攻擊者利用，透過偽造 VLAN 標籤繞過安全控制。

RADIUS 服務於 Linux 的應用實務

設定範例交換器組態

首先，我們定義 RADIUS 伺服器和群組（這部分應該與管理存取的部分相類別似）。交換器的組態允許 802.1x 認證，包括多個全域命令，設定 RADIUS 伺服器和 RADIUS 群組，並將 802.1x 認證連結回 RADIUS 組態。這些命令在以下程式碼片段中說明：

radius server RADIUS01
 address ipv4 <radius server ip 01> auth-port 1812 acct-port 1813
 key <some key>
radius server RADIUS02
 address ipv4 <radius server ip 02> auth-port 1812 acct-port 1813
 key <some key>
aaa group server radius RADIUSGROUP
 server name RADIUS01
 server name RADIUS02
! 預設啟用所有埠的 dot1x 認證
dot1x system-auth-control
! 為網路存取設定 RADIUS 認證和計費
aaa authentication dot1x default group RADIUSGROUP
aaa accounting dot1x default start-stop group RADIUSGROUP

內容解密：

1. RADIUS 伺服器組態：組態了兩個 RADIUS 伺服器（RADIUS01 和 RADIUS02），並指定了它們的 IP 地址、驗證埠（1812）和計費埠（1813），以及分享金鑰。
2. RADIUS 群組組態：建立了一個名為 RADIUSGROUP 的 RADIUS 群組，並將兩個 RADIUS 伺服器新增到該群組中，以實作冗餘和負載平衡。
3. 啟用 dot1x 認證：透過 dot1x system-auth-control 命令，全域啟用了 802.1x 認證。
4. RADIUS 認證和計費設定：使用 aaa authentication dot1x 和 aaa accounting dot1x 命令，設定了使用 RADIUSGROUP 進行 802.1x 認證和計費。

組態交換器埠

接下來，我們組態交換器的埠。一個典型的交換器埠組態了 802.1x 認證，用於 VLAN 101 上的工作站，使用工作站和/或使用者證書（之前發出的），並且不對 VOIP 電話（在 VLAN 105 上）進行認證。

! 設定某個介面的示例組態
interface GigabitEthernet1/0/1
 switchport access vlan 101
 switchport mode access
 dot1x pae authenticator
 dot1x port-control auto
!

內容解密：

1. 介面組態：將介面組態為存取模式，並分配給 VLAN 101。
2. 啟用 802.1x 認證：透過 dot1x pae authenticator 和 dot1x port-control auto 命令，在該介面上啟用了 802.1x 認證。

新增多因素認證（MFA）

為了增強安全性，我們可以新增多因素認證（MFA），例如使用 Google Authenticator。首先，我們需要安裝一個允許與 Google Authenticator 整合的套件：

$ sudo apt-get install libpam-google-authenticator -y

接下來，我們需要在 FreeRADIUS 中組態使用 PAM（可插拔認證模組）進行使用者認證：

# 在 /etc/freeradius/3.0/sites-enabled/default 中取消 pam 行的註解
pam

然後，編輯 /etc/pam.d/radiusd 檔案，新增 Google Authenticator 的相關組態：

#@include common-auth
#@include common-account
#@include common-password
#@include common-session
auth requisite pam_google_authenticator.so forward_pass secret=/etc/freeradius/${USER}/.google_authenticator user=<freeraduser>
auth required pam_unix.so use_first_pass

內容解密：

1. 安裝 Google Authenticator 套件：安裝了 libpam-google-authenticator 以支援 MFA。
2. 組態 FreeRADIUS 使用 PAM：修改了 FreeRADIUS 的組態，以使用 PAM 進行使用者認證。
3. 編輯 PAM 組態：在 /etc/pam.d/radiusd 中增加了 Google Authenticator 的 PAM 組態，以實作 MFA。

負載平衡服務於Linux系統的應用

隨著現代網路服務需求的日益增長，負載平衡技術在資料中心中的佈署變得越來越普遍和重要。在本章中，我們將探討Linux系統上的負載平衡服務，特別是以HAProxy為例，來展示如何有效地分配客戶端的工作負載到多個後端伺服器上。這不僅可以讓單一IP位址擴充套件到單一伺服器的容量限制之外，還能在伺服器故障或維護期間提供冗餘保障。

負載平衡簡介

負平衡是一種技術，能夠將工作負載分配到多個運算資源上，以提高系統的整體效能和可靠性。在Linux系統上，有多種負載平衡解決方案可供選擇，其中HAProxy是一種非常流行且功能強大的開源軟體。

負載平衡演算法

負載平衡演算法是決定如何將請求分配到後端伺服器的關鍵。常見的演算法包括輪詢（Round-Robin）、最少連線（Least Connections）和來源IP雜湊（Source IP Hash）等。選擇合適的演算法對於確保負載平衡的有效性和後端伺服器的穩定執行至關重要。

輪詢演算法範例

def round_robin(servers):
    index = 0
    while True:
        yield servers[index]
        index = (index + 1) % len(servers)

# 使用範例
servers = ['Server1', 'Server2', 'Server3']
rr = round_robin(servers)
for _ in range(7):
    print(next(rr))

內容解密：

此範例展示了一個簡單的輪詢演算法實作。它透過生成器函式round_robin來迴圈傳回伺服器列表中的每個伺服器，從而實作輪詢效果。這種演算法簡單易用，但可能不適合所有場景，因為它沒有考慮到伺服器的實際負載或回應時間。

伺服器和服務健康檢查

健康檢查是負載平衡系統中的一個重要組成部分，用於檢測後端伺服器的健康狀態和服務可用性。HAProxy支援多種健康檢查方法，包括TCP檢查、HTTP檢查等。

資料中心負載平衡設計考量

在設計資料中心的負載平衡方案時，需要考慮多個因素，包括但不限於可擴充套件性、冗餘性、效能和安全性。合理的設計可以確保系統的高用性和高效執行。

構建HAProxy NAT/代理負載平衡器

HAProxy不僅可以用作負載平衡器，還可以用作反向代理和SSL終止點。下面是一個基本的HAProxy組態範例，用於構建一個簡單的負載平衡器。

frontend http
    bind *:80
    default_backend webservers

backend webservers
    mode http
    balance roundrobin
    server Server1 192.168.1.101:80 check
    server Server2 192.168.1.102:80 check

內容解密：

此組態定義了一個名為http的前端，監聽80埠，並將所有請求轉發到名為webservers的後端。後端使用輪詢演算法來分配請求到兩台後端伺服器（Server1和Server2）上。check關鍵字表示HAProxy將對這些伺服器進行健康檢查。

負載平衡器安全性的最後說明

負載平衡器本身也需要適當的安全措施來保護。例如，使用SSL/TLS加密傳輸資料、限制對管理介面的存取、以及定期更新和修補負載平衡軟體等，都是非常重要的。

負載平衡器服務於 Linux 的應用

技術需求

在本章中，我們將探討負載平衡器的功能。隨著我們在後續章節中逐步深入範例，您可以在目前的 Ubuntu 主機或虛擬機器上跟隨並實施我們的範例組態。然而，要使我們的負載平衡範例真正運作起來，您需要具備以下幾點：

• 至少兩個目標主機來實作負載平衡
• 目前 Linux 主機上的另一個網路介面卡
• 另一個子網路來託管目標主機和這個新的網路介面卡

此組態有一個對應的圖表，即圖 10.2，該圖將在本章後面展示，闡述了當我們完成組態後，所有這些元件如何協同工作。

內容解密：

這段描述了進行負載平衡實驗所需的基礎設施，包括多個目標主機、額外的網路介面卡和子網路。這種組態增加了實驗環境的複雜度。圖表 10.2 將會展示最終的組態架構。

負載平衡簡介

負平衡最簡單的形式是將客戶端的負載分散到多台伺服器上。這些伺服器可以位於一個或多個位置，並且分配負載的方法可能會有所不同。事實上，如何成功地均勻分配負載也可能有很大差異（主要取決於所選擇的方法）。讓我們來探討一些更常見的負載平衡方法。

迴圈 DNS（RRDNS）

您只需使用 DNS 伺服器就可以實作簡單的負載平衡，這被稱為迴圈 DNS（RRDNS）。在這種組態中，當客戶端請求解析 a.example.com 主機名時，DNS 伺服器將傳回伺服器 1 的 IP；然後，當下一個客戶端請求時，它將傳回伺服器 2 的 IP，依此類別推。這是最簡單的負載平衡方法，無論是對於同地伺服器還是不同位置的伺服器都同樣有效。它也可以在不對基礎設施進行任何更改的情況下實施——不需要新增元件，也不需要更改組態。

簡單的迴圈 DNS 負載平衡

內容解密：

此圖示展示了迴圈 DNS 如何將客戶端的請求分配到不同的伺服器。客戶端向 DNS 伺服器請求主機名，DNS 伺服器以迴圈方式傳回不同的伺服器 IP 地址。

組態 RRDNS

組態 RRDNS 很簡單——在 BIND 中，只需為目標主機名組態多個 A 記錄，並對應多個 IP。連續的 DNS 請求將按順序傳回每個 A 記錄。建議在這種組態中縮短網域名稱的 Time-To-Live（TTL），如果需要的話，因為您希望能夠在短時間內將任何一台伺服器下線——如果您的 TTL 是 8 小時，那就不太合適。此外，您可以設定傳回順序為迴圈（預設值，按順序傳回重複的 A 記錄）、隨機或固定（總是以相同的順序傳回比對的記錄）。更改傳回順序的語法如下（這裡顯示的是預設設定，即迴圈）：

options {
    rrset-order {
        class IN type A name "mytargetserver.example.com" order cyclic;
    };
};

內容解密：

這段程式碼展示瞭如何在 BIND 中組態 RRDNS 的傳回順序。rrset-order 選項允許您指定傳回 A 記錄的順序。這裡設定的是預設的迴圈順序。

RRDNS 的問題

這種組態存在幾個問題：

• 無法有效地整合任何形式的健康檢查——所有伺服器是否正常運作？服務是否啟動？主機是否啟動？
• 無法檢視是否有任何 DNS 請求隨後真正連線到服務。有各種原因可能會發出 DNS 請求，而互動可能就此結束，沒有後續連線。
• 也無法監控會話何時結束，這意味著無法將下一個請求傳送到使用最少的伺服器——它只是所有伺服器之間穩定的、均勻的輪換。因此，在任何工作日的開始，這可能看起來是一個不錯的模型，但隨著一天的進展，總會有會話時間較長和極短的情況（或者根本沒有發生會話），因此常見的是伺服器負載隨著一天的進展而變得“不均衡”。
• 由於同樣的原因，如果叢集中的一台伺服器因維護或意外中斷而被關閉，則無法使其還原到相同的會話計數。
• 透過一些 DNS 踩點，攻擊者可以收集所有叢整合員的真實 IP，然後評估或單獨攻擊它們。如果其中任何一個特別脆弱或有額外的 DNS 條目標識其為備份主機，這使得攻擊者的任務更加容易。
• 將任何目標伺服器下線都可能成為問題——DNS 伺服器將繼續按照請求順序提供該地址。即使記錄被編輯，下游客戶端和 DNS 伺服器也會快取其解析的 IP，並繼續嘗試連線到已關閉的主機。
• 下游 DNS 伺服器（即網際網路上的那些）將在區域的 TTL 期間快取它們獲得的記錄。因此，任何這些 DNS 伺服器的客戶端都將被傳送到相同的目標伺服器。

內容解密：

這段分析闡述了 RRDNS 的幾個主要缺點，包括缺乏健康檢查、無法監控會話結束、容易受到攻擊等。這些缺點使得 RRDNS 不適合作為長期的、生產環境下的解決方案。

第七層負載平衡：入站代理

在此架構中，客戶端的會話在代理伺服器處終止，並在代理內部介面和真實伺服器 IP 之間啟動新的會話。

入站代理負載平衡

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Linux RADIUS EAP-TLS 認證與負載平衡組態

package "安全架構" {
    package "網路安全" {
        component [防火牆] as firewall
        component [WAF] as waf
        component [DDoS 防護] as ddos
    }

    package "身份認證" {
        component [OAuth 2.0] as oauth
        component [JWT Token] as jwt
        component [MFA] as mfa
    }

    package "資料安全" {
        component [加密傳輸 TLS] as tls
        component [資料加密] as encrypt
        component [金鑰管理] as kms
    }

    package "監控審計" {
        component [日誌收集] as log
        component [威脅偵測] as threat
        component [合規審計] as audit
    }
}

firewall --> waf : 過濾流量
waf --> oauth : 驗證身份
oauth --> jwt : 簽發憑證
jwt --> tls : 加密傳輸
tls --> encrypt : 資料保護
log --> threat : 異常分析
threat --> audit : 報告生成

@enduml

內容解密：

此圖示展示了入站代理如何終止客戶端的會話並與後端伺服器建立新的會話。這種方式可以提供更好的負載平衡和安全性。