Hoạt động của Radius Server và WebAdmin trên WAN đơn giản - Chương 4 potx

33 Chương IV: GIAO THỨC RADIUS Có hai giao thức RADIUS mô tả về:  [Giao thức RADIUS1] Xác nhận quyền (authentication), phân quyền (authorization), thông tin cấu hình giữa máy chủ quản lý truy cập mạng (Network Access Server - NAS) mà có các yêu cầu cần xác nhận và máy chủ xác nhận quyền dùng chung (Shared Authentication Server).  [Giao thức RADIUS2] Thông tin về tài khoản giữa NAS và máy chủ quản lý tài khoản dùng chung (Shared Accounting Server).  RADIUS được xây dựng dựa trên giao thức lớp transport nào? Một câu hỏi thường được đặt ra là tại sao RADIUS lại sử dụng giao thức UDP thay vì TCP ở lớp transport. UDP được chọn vì một số chỉ tiêu kỹ thuật nghiêm ngặt được đặt ra. RADIUS thật ra là một giao dòch (transaction) được xây dựng dựa trên giao thức có các tính chất chính như sau: 1. Nếu như yêu cầu (request) gởi tới máy chủ xác nhận quyền sơ cấp (primary authentication server) thất bại, thì yêu cầu này phải được gởi tới máy chủ sơ cấp (secondary server). Để thực hiện yêu cầu này, một bản sao yêu cầu phải được lưu trên lớp transport để cho phép việc truyền luân phiên. Điều này có nghóa là phải có timers cho việc truyền lại (retransmission). 34 2. Các đòi hỏi về thời gian của RADIUS rất khác biệt so với TCP. Một mặt, RADIUS không yêu cầu "câu trả lời" (responsive) về việc dò tìm dữ liệu bò mất. User sẳn sàng chờ trong nhiều giây để cho việc xác nhận quyền (authentication) được hoàn tất. Việc truyền lại thường xảy ra đối với TCP dựa trên thời gian truyền nhận trung bình (average round trip time) không cần thiết nữa, kể cả thời gian hao tốn cho việc nhận biết phản hồi về (acknowledgement overhead). Mặt khác, user không thể chờ đợi quá lâu trong nhiều phút cho việc xác nhận quyền. Việc phải chờ quá hai phút để dữ liệu được truyền đi tin cậy là không hữu ích. Việc sử dụng luân phiên nhanh chóng server sẽ cho phép user truy cập được vào mạng trước khi họ "bỏ cuộc". 3. Trạng thái rất tự do của RADIUS đã đơn giản hóa việc sử dụng UDP. Các clients và servers có thể đăng ký vào hoặc ra khỏi mạng; Hệ thống bò khởi động lại vì một lý do nào đó; Nguồn điện bò mất… Các sự kiện bất thường (anomalous events) này nói chung sẽ không gây nguy hiểm nếu như có những timeouts tốt và xác đònh được các cầu nối TCP đã bò đứt. Tuy nhiên UDP hoàn toàn bỏ qua các sự cố đặt biệt này; Các clients và servers có thể mở một "chuyến vận chuyển dữ liệu" UPD ngay lập tức và để nó tự nhiên truyền trên mạng với các sự kiện có thể có. 4. UPD đơn giản hóa việc thực hiện (implementation) server. những phiên bản trước, server được thực hiện đơn luồng (single threaded), có nghóa là mỗi lúc chỉ có 1 yêu cầu được nhận, xử lý và trả về. Điều này không thể quản lý được trong môi trường kỹ thuật an toàn quay vòng (back-end security mechanism) dùng thời gian thực (real-time) (1 hoặc nhiều giây). Hàng đợi yêu cầu của server sẽ bò đầy, và trong một môi trường có hàng trăm người được yêu cầu xác nhận quyền trong mỗi phút, thời gian quan vòng của yêu cầu (request turn- 35 around time) sẽ lớn hơn nhiều so với thời gian mà user mong đợi (Việc tìm tiếp trong một cơ sở dữ liệu hoặc trên một DNS chiếm mất trên 30 giây). Do vậy, giải pháp được chọn là thực hiện server chế độ đa luồng (multi-threaded) với UDP. Những quá trình (processes) độc lập sẽ được sinh ra (spowned out) trên server ứng với mỗi yêu cầu (request) và những quá trình này sẽ trả lời trực tiếp với các NAS khách bằng gói UDP tới lớp truyền dẫn chính (original transport) của client. II. Giao thức RADIUS1: 1. Cơ chế hoạt động (operation) Khi một client được đònh cấu hình để sử dụng RADIUS, thì bất cứ user nào của client đều giới thiệu những thông tin xác nhận quyền (authentication information) với client. Đó có thể là dấu nhắc lệnh đăng ký vào mạng (login prompt) yêu cầu user nhập tên và mật khẩu vào. User có thể lựa chọn việc sử dụng protocol thích hợp để thực hiện giới thiệu những thông tin này bằng các gói dữ liệu (packets), chẳng hạn như PPP (Point to Point Protocol). Mỗi lần client nhận được thông tin như vậy, nó có thể chọn dùng RADIUS để xác nhận quyền. Client sẽ tạo ra một "yêu cầu truy cập" (Access-Request) chứa các thuộc tính như tên, mật khẩu của user, số hiệu (ID) của client và số hiệu cổng (port ID) mà user sẽ truy cập vào. Mật khẩu khi nhập vào sẽ được ẩn (phương pháp dựa trên giải thuật RSA Message Digest Algorithm MD5). "Yêu cầu truy cập" (Access-Request) sẽ được gửi cho RADIUS thông qua mạng. Nếu không có trả lời trong một khoảng thời gian quy ước thì yêu cầu sẽ được gửi lại. Client cũng có thể chuyển (forward) yêu cầu cho các server dự phòng trong trường hợp server chính bò tắt hoặc hư hỏng hoặc hoạt động theo kiểu round-robin. 36 Mỗi khi RADIUS server nhận được yêu cầu, nó sẽ xác nhận client gởi. Những yêu cầu từ các client nào không chia sẽ thông tin bảo mật (shared secret) với RADIUS sẽ không được xác nhận và trả lời (silently discarded). Nếu client là hợp lệ, RADIUS server sẽ tìm kiếm trong cơ sở dữ liệu (CSDL) user có cùng tên trong yêu cầu. Chỉ mục của user (user entry) trong CSDL sẽ chứa danh sách các đòi hỏi cần thiết cho phép user truy cập vào mạng. RADIUS luôn luôn xác nhận mật khẩu của user và có thể cả số hiệu của client và port mà user được phép truy cập. RADIUS server có thể yêu cầu các server khác xác nhận yêu cầu. Lúc đó RADIUS đóng vai trò của một client. Nếu bất cứ điều kiện nào không được thỏa, RADIUS server sẽ gởi một trả lời "từ chối truy cập" (Access-Reject) biểu thò rằng yêu cầu của user là không hợp lệ. Server có thể kèm một thông báo dạng văn bản (text message) trong Access-Reject để client có thể hiển thò cho user. Không có một thuộc tính nào khác được phép chưa trong Access-Reject. Nếu tất cả các điều kiện đều được thỏa và RADIUS server muốn đưa ra một yêu cầu đòi hỏi user phải trả lời, thì RADIUS sẽ gởi một trả lời "đòi hỏi truy cập" (Access-Challenge), nó có thể dưới dạng một thông báo dạng văn bản được hiển thò cho user bởi client hoặc là một thuộc tính trạng thái (State attribute). Client sẽ nhận Access-Challenge, và nếu nó được trang bò challenge/response, nó sẽ hiển thò thông báo nhắc nhở user trả lời yêu cầu. Sau đó client sẽ gửi lại (re-submit) "yêu cầu truy cập" gốc (original Access-Request) với một số hiệu yêu cầu (request ID) mới, nhưng thuộc tính tên - mật khẩu được lấy từ thông tin vừa mới nhập vào, và kèm luôn cả thuộc tính trạng thái từ Access-Challenge. RADIUS server có thể trả lời "yêu cầu truy cập" mới bằng "chấp nhận truy cập" (Access-Accept), "từ chối truy cập" (Access- Reject) hoặc một "đòi hỏi truy cập" (Access-Challenge) khác. Nếu cuối cùng tất cả các điều kiện được thỏa, thì danh sách các giá trò cấu hình cho user được 37 đặt vào trả lời "chấp nhận truy cập" (Access-Accept). Các giá trò này bao gồm kiểu của dòch vụ (ví dụ: SLIP, PPP, Login user) và các giá trò cần thiết để cấp phát dòch vụ này. Tỉ dụ như đối với SLIP hay PPP, các giá trò này có thể là đại chỉ IP, đòa chỉ mạng con (subnet mask), MTU, phương pháp nén và số hiệu lọc gói (filtering packet ID). chế độ ký tự (character mode), các giá trò này có thể là giao thức (protocol) và tên máy chủ (host). 2. Dạng của gói (packet format) Một cách chính xác, một gói RADIUS được bao bọc trong trường dữ liệu của gói UDP (UDP data field), và trường đòa chỉ đích (UDP Destination Port field) có số hiệu cổng là 1645. Khi gói trả lời được tạo ra, số hiệu cổng của đòa chỉ nguồn và đích được bảo lưu. Một gói dữ liệu của RADIUS được đònh dạng như sau (các trường được gởi đi từ trái sang phải). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authenticator | | | | | 38 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes +-+-+-+-+-+-+-+-+-+-+-+-+- a. Trường mã (code): 1 byte Xác đònh kiểu của gói RADIUS. Gói có mã không hợp lệ sẽ không được xác nhận và trả lời (silently discarded). (decimal) 1 Access-Request 2 Access-Accept 3 Access-Reject 4 Accounting-Request 5 Accounting-Response 1. Access-Challenge 12 Status-Server (experimental - thực tế) 1. Status-Client (experimental - thực tế) 1. Reserved (dự trữ) 3 39 Accounting-Request/ Accounting-Response sẽ được trình bày ở giao thức RADIUS2. b. Trường danh hiệu (Identifier): 1 byte Dùng so trùng yêu cầu (request) và trả lời (reply). c. Trường độ dài (length): 2 bytes Biểu thò độ dài của gói bao gồm các trường mã (code), danh hiệu (identifier), độ dài (length), xác nhận (authenticator), thuộc tính (attribute). Những byte nằm ngoài khoảng quy đònh bởi trường length sẽ được coi là những byte thừa, và sẽ bò bỏ qua khi nhận. Nếu gói ngắn hơn giá trò trường length, nó sẽ không được xác nhận và trả lời (silently discarded). Giá trò nhỏ nhất của trường length là 20, giá trò lớn nhất là 4096. d. Trường xác nhận (authentication): 16 bytes Giá trò của trường xác nhận được dùng để xác nhận sự trả lời từ RADIUS server và nó được dùng trong thuật toán ẩn mật khẩu (password hiding algorithm). MSB (the most significant byte) sẽ được gởi trước.  Bộ xác nhận yêu cầu (Request Authenticator) Trong các gói "yêu cầu truy cập" (Access-Request), giá trò của trường xác nhận (authenticator field) là một số ngẫu nhiên 16 byte được gọi là bộ xác nhận yêu cầu (request authenticator). Giá trò này phải không thể được dự đoán trước (unpredictable) và duy nhất (unique) trong suốt thời gian sống của "thông tin bí mật" (secret) (mật khẩu dùng chung giữa client và RADIUS server); Vì nếu có sự lặp lại của giá trò này có nghóa là một nhân vật nào đó (attaker) có thể trả lời câu hỏi này không cần sự xác nhận của RADIUS 40 server. Do đó bộ xác nhận yêu cầu nên có giá trò toàn cục (global) và duy nhất theo thời gian (temporal uniqueness). Mặc dù giao thức RADIUS không có khả năng ngăn cản sự nghe lén phiên xác nhận (authenticated session) qua đường dây, nhưng việc sinh ra các giá trò không thể dự đoán trước cho bộ xác nhận yêu cầu có thể hạn chế rất nhiều sự kiện này. NAS và RADIUS server chia sẻ "thông tin bí mật". Thông tin bí mật dùng chung này có được sau khi giá trò của "bộ xác nhận yêu cầu" được đưa vào bộ băm một chiều MD5 (one-way MD5 hash) để tạo ra một giá trò số 16 byte. Giá trò này được XOR với mật khẩu mà user nhập vào, kết quả sẽ được đặt vào thuộc tính User-Password trong gói Access- Request.  Trường xác nhận trong gói "trả lời" (Response Authenticator) Giá trò của trường xác nhận (authenticator field) trong các gói Access-Request, Access- Reject, Access-Challenge được gọi là bộ xác nhận trả lời (Response Authenticator). Giá trò này được tính bởi băm một chiều MD5 chuỗi các byte của các trường mã, danh hiệu, độ dài, xác nhận của gói "yêu cầu truy cập", và cộng thêm các thuộc tính trả lời và thông tin bí mật dùng chung. ResponseAuth= MD5(Code+ID+Length+RequestAuth+Attributes+Secret) b. Trường thuộc tính (Attributes) Có những thuộc tính có nhiều phiên bản (instances). Những thuộc tính cùng loại được giữ nguyên thứ tự. Đối với mỗi loại gói chỉ cho phép các thuộc tính nhất đònh mà thôi. 3. Kiểu của gói (packet types) Kiểu của gói được xác đònh bởi trường mã (code field) chiếm byte đầu tiên của gói RADIUS. 3.1- Gói "yêu cầu truy cập" (Access-Request) 41 Gói Access-Request được gởi tới RADIUS server. Nó chuyên chở thông tin dùng để xác đònh xem user có được phép truy cập vào NAS và các dòch vụ được chỉ đònh hay không. Trường mã của gói phải có giá trò 1. Gói Access-Request phải chứa thuộc tính User-Name, User- Password hoặc CHAP-Password , và có thể chứa các thuộc tính NAS-IP-Address, NAS- Identifier, NAS-Port, NAS-Port-Type. Trường danh hiệu (Identifier field) phải được thay đổi khi nội dung của trường thuộc tính bò thay đổi hoặc là đã nhận được trả lời hợp lệ cho yêu cầu trước đó. Trong trường hợp phải gởi lại gói (retransmission), trường danh hiệu không được thay đổi. 3.2- Gói "chấp nhận truy cập" (Access-Accept) Gói Access-Accept được gởi trả bởi RADIUS server khi tất cả các giá trò thuộc tính của gói Access-Request . Nó cung cấp thông tin cấu hình cần thiết để cấp phát các dòch vụ cho user. Trường mã của gói phải có giá trò 2. Gói Access-Accept nhận được ở NAS phải có trường danh hiệu trùng khớp với gói Access-Request tương ứng đã gởi trước đó và phải có trường xác nhận (Response Authenticator) phù hợp với thông tin bí mật dùng chung (shared secret). 3.3- Gói "từ chối truy cập" (Access-Reject) Gói Access-Reject được gởi trả từ RADIUS server khi có giá trò thuộc tính không được thỏa. Trường mã của gói phải có giá trò 3. Gói có thể chứa 1 hoặc nhiều thuộc tính Reply-Message với một thông báo dạng văn bản mà NAS sẽ hiển thò nó với user. Trường danh hiệu của gói Access-Reject chính là bản sao của gói Access-Request tương ứng. 3.4- Gói "đòi hỏi truy cập" (Access-Challenge) Gói Access-Challenge được RADIUS server gởi đến user đòi hỏi thêm thông tin cần thiết mà user phải trả lời. Trường mã của gói phải có giá trò 11. Gói có thể chứa 1 hoặc nhiều thuộc tính Reply-Message và có thể có 1 thuộc tính State. Các thuộc tính khác không được xuất hiện 42 trong gói Access-Challenge. Trường danh hiệu của gói Access-Challenge phải trùng khớp với gói Access-Request tương ứng đã gởi trước đó và phải có trường xác nhận (Response Authenticator) phù hợp với thông tin bí mật dùng chung (shared secret). Nếu NAS không được trang bò challenge/response thì gói Access-Challenge nhận được sẽ coi như là gói Access- Reject. Nếu NAS được trang bò chức năng challenge /response và gói Access-Challenge nhận được là hợp lệ thì NAS sẽ hiển thò thông báo và yêu cầu user trả lời thông tin mà RADIUS server yêu cầu. Sau đó NAS sẽ gởi gói Access-Request gốc nhưng với danh hiệu yêu cầu (request ID) và xác nhận yêu cầu (request authenticator) mới, đồng thời thuộc tính User- Password cũng được thay thế bởi thông tin trả lời của user (đã được mã hóa) và có thể bao gồm cả thuộc tính State từ gói Access-Challenge. 4. Các thuộc tính (attributes) Các thuộc tính của RADIUS, chứa trong các gói yêu cầu-trả lời, mang thông tin xác nhận quyền, phân quyền, cấu hình cần thiết để cấp phát các dòch vụ cho user. Giá trò trường độ dài của gói RADIUS sẽ quy đònh điểm kết thúc của các thuộc tính trong gói. Dạng của thuộc tính như sau: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- [...]... trong tài liệu draft-ietf -radius- radius-05) RADIUS server và client có thể bỏ qua các thuộc tính có kiểu không xác đònh Ví dụ: Kiểu Mô tả 1 User-Name 2 User-Password 3 CHAP-Password 4 NAS-IP-Address 5 NAS-Port 6 Service-Type 7 Framed-Protocol 8 Framed-IP-Address 9 Framed-IP-Netmask 10 Framed-Routing 11 Filter-Id 12 Framed-MTU 43 ……………  Trường độ dài (Length): 1 byte Biểu thò độ dài của thuộc tính cho... /usr/local/sbin/radiusd radiusd File /etc/services radius 1 645 /udp radacct 1 646 /udp # radius deamon # radius accounting deamon 2 Sử dụng: - Khởi động Radius Server cd /usr/local/sbin /radiusd -d /usr/local/etc/raddb -p 1 645 -x -x& - Kiểm tra Radius Server có hoạt động không: cd /usr/local/sbin /radcheck –d /usr/local/etc/raddb –p 1 645 –x (ví dụ lnsrv.quantic.ac.vn) - Kiểm tra Radius client /radpwtst... ftp://ftp.gams.at/radiusd-2 _4_ 23_6_ver2.tar.gz Cấu trúc thư mục của RADIUS như sau: - radcheck - phần kiểm tra RADIUS ( tương tự lệnh ping) - radiusd - thực thi RADIUS Server 48 - radpwtst - phần kiểm tra RADIUS Client - dnscheck - phần kiểm tra ánh xạ DNS - /raddb gồm các file sau: authfile: file ánh xạ kiểu authenticate clients : file chứa các thông tin client như đòa chỉ IP của client và khoá Key để... Login-TCP-Port = 23 dien Password = "dien", Authentication-Type = Unix-PW Service-Type = Login, Login-Service = Telnet, Login-IP-Host = 199.200.201.9, Login-TCP-Port = 23 test Password = "abc123" Service-Type = Framed, Framed-Protocol = PPP, Framed-IP-Address = 199.200.201.9 DEFAULT Authentication-Type = Realm Filter-Id = "unlim" 51 File /etc/inetd.conf radius dgram udp wait root /usr/local/sbin/radiusd... dạng Access-Request tới RADIUS server cho user tên jerry đăng ký truy cập tại port 4 có dạng như sau: 44 Code = 1 (Access-Request) ID = 0 Request Authenticator = số 16 byte ngẫu nhiên Attributes : User-Name = "jerry" User-Password = [mật khẩu16 byte XOR MD5("thông tin bí mật chung", "bộ xác nhận quyền")] NAS-IP-Address = 199.200.201.9 NAS-Port = 4  Giả sử RADIUS server xác nhận quyền của jerry và gởi... jerry tới máy chủ 199.200.201 .4 Code = 2 (Access-Accept) ID = 0 (giống như trong Access-Request) Response Authenticator = [16 byte băm MD-5 (code=2, Id=0, Request Authenticator của yêu cầu ở trên, các thộc tính trả lời, "thông tin bí mật dùng chung"] Attributes: Service-Type = Login-User Login-Service = Telnet 45 Login-Host = 199.200.201 .4 III Giao thức RADIUS2 : 1 Cơ chế hoạt động (operation) Khi client... UserPassword, CHAP-Password, Reply-Message, State Một số thuộc tính phải luôn có mặt trong gói Accounting-Request như: NAS-IP-Address, NAS-Identifier và một số thuộc tính khác nên có mặt như: NAS-Port, NAS-Port-Type Một số chi tiết cụ thể khác có thể tham khảo thêm trong tài liệu draft-ietf -radius- accounting05 hoặc http://www.ascend.com hoặc http://www.livingston.com IV Phương pháp mã hóa (encryption) và giải... trong RADIUS Thuộc tính User-Password chứa trong các gói Access-Request hoặc Access-Challenge, đặc trưng cho mật khẩu (password) của user, sẽ được ẩn trong khi truyền tới RADIUS server Mật khẩu sẽ được thêm vào các ký tự NULL sao cho độ dài là bội của 16 byte Băm MD5 một chiều (One-way MD5 hash) sẽ được xây dựng từ chuỗi các byte của "thông tin bí mật chung" (shared secret) giữa NAS - RADIUS server và. .. /usr/local/etc/radd –p 1 645 –s lns.quantic.ac.vn –u PPP –w abc123 –x test /radpwtst –d /usr/local/etc/radd –p 1 645 –s lns.quantic.ac.vn –w abc123 –x quantic 52 V Giải thuật của RADIUS server Giải thuật của RADIUS server sau đây được trình bày dựa trên mã nguồn của Livingston Enterprises, Inc (ftp://ftp.livingston.com/ hoặc ftp://ftp.gams.at/ ) Quá trình mã hoá và giải mã gói giữa Radius Client và Server được mô... dưới đây là các thông số đã được sửa chữa khi cài đặt RADIUS trên hệ điều hành Linux 4. 2 File clients: #Client Name Key user/authfile prefix # - -4 9 9 testingabc123 File Authfile: DEFAULT _RADIUS_ SERVER lnsrv.quantic.ac.vn #Realm [(alias[,alias])] [-prot] Type REALM/DNS address # - - - Filter ID - # Authentication requests for realm "umich.edu" which . 1 2 3 4 5 6 7 8 9 0 1 +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ -+ | Code | Identifier | Length | +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ -+ |. | | | 38 +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ -+ | Attributes +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +- a. Trường mã (code): 1 byte Xác đònh kiểu của gói RADIUS. Gói có. 3 4 5 6 7 8 9 0 +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - | Type | Length | Value +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - +-+ - 43  Trường kiểu (Type): 1 byte Đặc trưng cho 256 loại