Information security - Giao thức xác thực Kerberos
Bạn đang xem 20 trang mẫu của tài liệu "Information security - Giao thức xác thực Kerberos", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên
Tài liệu đính kèm:
- information_security_giao_thuc_xac_thuc_kerberos.pdf
Nội dung text: Information security - Giao thức xác thực Kerberos
- HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG TPHCM KHOA CÔNG NGHỆ THÔNG TIN II [\ [\ ĐỀ TÀI: INFORMATION SECURITY GIAO THỨC XÁC THỰC KERBEROS
- HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG HCM KHOA CÔNG NGHỆ THÔNG TIN II Đề tài: INFORMATION SECURITY GIAO THỨC XÁC THỰC KERBEROS Giáo viên hướng dẫn: Thầy Lê Phúc Thành viên nhóm: Nguyễn Duy Cường 406170004 Thân Đoàn Đăng Hải 406170018
- PTIT_D06THA1 Kerberos I. Tổng quan II. Lịch sử phát triển III. Một số khái niệm IV. Mô hình Kerberos V. Cơ chế hoạt động VI. Cài đặt Kerberos VII. Kerberos 5 VIII. Securiry IX. Ưu nhược điểm của Kerberos X. Trust Relationship 2 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 I.Tổng quan: Kerberos là một giao thức mật mã dùng để xác thực trong các mạng máy tính hoạt động trên những đường truyền không an toàn được công khai từ năm 1989. Giao thức Kerberos có khả năng chống lại việc nghe lén hay gửi lại các gói tin cũ và đảm bảo tính toàn vẹn của dữ liệu. Mục tiêu khi thiết kế giao thức này là nhằm vào mô hình client - server và đảm bảo nhận thực cho cả 2 chiều. Tên của giao thức Kerberos được lấy từ tên của con chó ba đầu Cerberus canh gác cổng địa ngục trong thần thoại Hy Lạp Các hệ điều hành Windows 2000, Windows XP và Windows Server 2003 và sau này sử dụng một phiên bản Kerberos làm phương pháp mặc định để xác thực. Hệ điều hành Mac OS X cũng sử dụng Kerberos trong các phiên bản Clients và Server của mình. II.Lịch sử phát triển: Học viện kỹ thuật Massachusetts (MIT) phát triển Kerberos để bảo vệ các dịch vụ mạng cung cấp bởi dự án Athena Giao thức đã được phát triển dưới nhiều phiên bản, trong đó các phiên bản từ 1 đến 3 chỉ dùng trong nội bộ MIT. Các tác giả chính của phiên bản 4, Steve Miller và Clifford Neuman, đã xuất bản giao thức ra công chúng vào cuối thập niên 1980, mặc dù mục đích chính của họ là chỉ phục vụ cho dự án Athena. Phiên bản 5, do John Kohl và Clifford Neuman thiết kế, xuất hiện trong tài liệu (RFC1510) RFC 1510 - The Kerberos Network Authentication Service (V5) vào năm 1993 (được thay thế bởi RFC 4120 vào năm 2005 - RFC 4120 - The Kerberos Network Authentication Service (V5) với mục đích sửa lỗi của phiên bản 4. III.Một số khái niệm : Realm , Principal, instance : * Realm: là một trường hay một lĩnh vực, nó tương tự như 1 domain nhưng không phải 1 domain * Instance: phần chú thích bổ sung thêm * Principal: Mỗi thực thể chứa trong bộ cài đặt Kerberos, bao gồm cả người dùng cá nhân, máy tính, và các dịch vụ đang chạy trên máy chủ, có một principal liên kết với nó. Mỗi principal liên kết với một khoá dài hạn. Khóa này có thể là một mật khẩu hay cụm từ mật khẩu. Các principal là tên duy nhất trên toàn cầu. Để thực hiện việc này, principal được chia thành một cấu trúc thứ bậc. Mỗi principal bắt đầu với một tên người dùng hoặc tên dịch vụ. Tên người dùng hoặc tên dịch vụ này phụ thuộc tùy vào các instance khác nhau. Instance được sử dụng trong hai tình huống: dịch vụ cho principal , và để tạo principal đặc biệt cho việc sử dụng quản trị. Ví dụ, các quản trị viên có thể có hai lãnh 3 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 đạo: một là sử dụng hằng ngày, và một người (một admin "chính") để sử dụng chỉ khi có các nhu cầu đặc quyền quản trị cao. Ví dụ tên người dùng và các tùy chọn, kết hợp với nhau, tạo thành một thực thể duy nhất trong một realm nhất định. Mỗi trình ứng dụng Kerberos định nghĩa một realm quản trị để kiểm soát, điều đó để phân biệt với tất cả các trình ứng dụng Kerberos khác. Kerberos định nghĩa nó như là tên của realm. Theo quy ước, các realm của Kerberos có một DNS domain là 1 domain được chuyển đổi sang chữ hoa.Ví dụ ptit.org trở thành PTIT.ORG Ví dụ: Duy Cường là 1 sinh viên của lớp IT của trường PTIT có domain name là ptit.org thì principal mà Kerberos gán cho Cườnglà: cuong@IT.PTIT.ORG Trong đó IT.PTIT.ORG la Realm, không có instance. *Đối với Kerberos 4: có 2 cấu trúc: + Username[/instance]@REALM + Service/fully-qualified-domain-name@REALM Đăng Hải là 1 sinh viên của lớp IT nằm trong ban quản trị của trường PTIT có domain name: ptit.org thì principal mà Kerberos gán cho Đăng Hải là: hai.admin@IT.PTIT.ORG Ví dụ này cũng như ví dụ trên chỉ khác là có thêm trường instance la admin. *Đối với Kerberos 5: Trong thực tế có 1 số trường hợp 2 máy có cùng tên host nhưng ma ở 2 domain khác nhau.Ví dụ, bạn Đăng Hải ở tổ 1 và bạn Hồng Hải ở tổ 2 của cùng lớp cùng trường. Ta giả sử bạn Đăng Hải thuộc domain it.ptit.org còn bạn Hồng Hải thuộc domain it.ptit.edu .Và 2 bạn đều thuộc cùng 1 realm la IT.PTIT.ORG Vậy đối với Kerberos 4 thì 2 bạn này có cùng principal là hai@IT.PTIT.ORG Trước thực trạng này , người ta đã cho ra đời Kerberos 5, có 2 cấu trúc : - Username[/instance]@REALM - Service/fully-qualified-domain-name@REALM Bây giờ đối với ví dụ trên ta có : + Đối với bạn Đăng Hải : hai/it.ptit.org@IT.PTIT.ORG + Đối với bạn Hồng Hải : hai/it.ptit.edu@IT.PTIT.ORG KDC – Key Distribution Center: Trung tâm phân phối khóa. Key Distribution Center cuả Kerberos(KDC), là một phần của hệ thống Kerberos. Trên lý thuyết KDC bao gồm ba thành phần: - Database của tất cả các principal và các khóa đã mã hóa của nó để gia nhập - Anthentication Server - Ticket Granting Server. Người ta thường gom chúng lại trong một chương trình duy nhất và chạy cùng nhau trong một process duy nhất. Trong 1 realm của Kerberos phải có ít nhất một KDC. Khi nhu cầu đòi hỏi chạy 1 KDC trên 1 máy bình thường, người ta khuyên rằng nên dùng 1 KDC 4 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 riêng biệt. Vì nếu hệ thống mạng có nhiều KDC kết nối nhau thì tất cả các dữ liệu quan trọng, bao gồm các key của các principal trong realm của bạn, đều có trên mỗi KDC trong mạng,điều đó có nghĩa là có nhiều nguy cơ bị tấn công hơn.Ngoài ra, để cho người dùng xác thực thành công đến Kerberos-kích hoạt dịch vụ, ít nhất một KDC phải được hoạt động mọi lúc. Mỗi Key Distribution Center chứa 1 database của tất cả các principal có trong realm này, cũng như các bí mật liên quan của nó. Phần mềm KDC chứa hầu hết các thong tin bổ sung của các principal trong database này, chẳng hạn như thời gian sống của mật khẩu, mật khẩu thay đổi lần cuối cùng là gì, và nhiều thứ khác nữa. Windows 2000 và 2003 giữ cơ sở dữ liệu này trong Active Directory(chứa trong LDAP). Trong một realm có thể chứa nhiều Kerberos KDC , database trên mỗi KDC phải được đồng bộ hóa để đảm bảo thống nhất xác thực. Nếu một máy chủ có dữ liệu để lâu thì sẽ rất dễ thất bại khi tìm cách hợp pháp để xác thực với máy chủ đó, vì nó không update bản sao của các cơ sở dữ liệu của Kerberos. Không có phương pháp tiêu chuẩn đồng bộ hóa được xác định bằng giao thức Kerberos, do đó các nhà cung cấp đã tạo ra các giao thức bản sao riêng của họ SS – Service Server: Máy chủ dịch vụ - mail server, File server, application server. Bất kỳ một Server cung cấp dịch vụ nào đều có thể là Service Server AS-Authentication Server:Máy chủ xác thực Khi 1 user muốn tham gia vào 1 realm của Kerberos thì thay vì user phải xác thực với KDC thì phải xác thực với AS Khi nhận yêu cầu tham gia hệ thống Kerberos của 1 client, AS kiểm tra nhân dạnh của người yêu cầu có nằm trong cơ sở dữ liệu của mình không. Nếu có thì AS gửi 2 gói tin sau tới người sử dụng: Gói tin A: "Khóa phiên TGS/máy khách" được mật mã hóa với khóa bí mật của người sử dụng. Gói tin B: "Vé chấp thuận" (bao gồm chỉ danh người sử dụng (ID), địa chỉ mạng của người sử dụng, thời hạn của vé và "Khóa phiên TGS/máy khách") được mật mã hóa với khóa bí mật của TGS. TGS-Ticket Granting Server:Máy chủ cấp phát vé TGS là bộ phận nhận vé chấp thuận TGT từ user.TGS có nhiệm vụ kiểm tra các vé TGT có giá trị không bằng cách kiểm tra xem nó có được mã hóa bởi key với key của TGT server Kerberos không.Nếu đúng thì gửi cho user vé dịch vụ mà user muốn sử dụng. Ticket: Vé được cấp bởi TGS và máy chủ ứng dụng, cung cấp sự chứng thực cho máy chủ ứng dụng hoặc tài nguyên. Một vé Kerberos là một cấu trúc dữ liệu được mã hóa do KDC tạo ra để share 1 key đã mã hóa của 1 phiên duy nhất.Vé tạo ra có 2 mục đích : xác nhận danh tính của người tham gia và khởi tạo 1 khóa ngắn hạn để 2 bên có thể giao tiếp an toàn (gọi la khóa phiên). Các trường chính mà mọi vé của Kerberos đều có là: - Yêu cầu tên của principal 5 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 - Dịch vụ của principal có tên này là gì - Khi nào thì vé có hiệu lực,khi nào vé hết hiệu lực(Timestamp,Lifetime) - Danh sách IP mà vé có thể được dùng từ đó - Chia sẻ khóa bí mật (session key) của user/ ứng dụng truyền thong 1 vé được tạo bởi KDC được mã hóa để đảm bảo rằng những người không có khóa không mở được nó để chỉnh sửa,như là tăng lifetime của nó lên hoặc tên định danh của client principal Bởi vì Kerberos chỉ xác thực 1 lần khi đăng nhập nên sau khi đăng nhập thì bất kỳ ai ngồi trên máy đó đều có thể tham gia vào hệ thống Kerberos.Vì vậy,vé trong Kerberos có lifetime ngắn , khoảng từ 10-24h .Điều này thuận tiện cho viêc đăng nhập 1 lần trong ngày làm việc của user, hạn chế việc tấn công lấy mất dữ liệu quan trọng. Seasion Key: được sử dụng cho 1 seasion giữa client và server. Ticket cache: Tất cả các vé của Kerberos đều được lưu trong 1 file nằm trong bộ nhớ cache gọi là Credential cache .Microsoft và Apple đã lựa chọn phương án này.Khi đăng nhập vào hệ thống Kerberos thì các vé được lưu trong bộ nhớ cache và khi đăng xuất thì mọi thứ được xóa hết. Các thông tin chứa trong cache gồm : user principal, các vé mà user có trong suốt phiên đăng nhập của họ.VD: $ klist Ticket cache: FILE:/tmp/krb5cc_502_auJKaJ Default principal: jgarman@WEDGIE.ORG Valid starting Expires Service principal 09/10/02 01:48:12 09/10/02 11:48:12 krbtgt/WEDGIE.ORG@WEDGIE.ORG 09/10/02 01:48:14 09/10/02 11:48:12 host/cfs.wedgie.org@WEDGIE.ORG 09/10/02 04:20:42 09/10/02 11:48:12 host/web.wedgie.org@WEDGIE.ORG Trong ví dụ này, bộ nhớ cache cho user principal của jgarman@WEDGIE.ORG được lưu trong tập tin / tmp/krb5cc_502_auJKaJ. Credential cache chỉ có thể được kết hợp với một user principal tại một thời gian, nếu ta muốn truy cập các dịch vụ với một principal của jgarman / admin @ WEDGIE.ORG, ta đã có thể phá hủy vé hiện tại của mình và tái đăng nhập để Kerberos theo jgarman / admin@WEDGIE.ORG. IV.Mô hình Kerberos tiêu biểu : Dưới đây là mô hình hệ thống Kerberos tiêu biểu mà chúng ta thường thấy hiện nay,bao gồm : - Client hay user - Thiết bị truyền thông : router,switch,hub, . - Kerberos System : AS , TGS, database - Server cung cấp dịch vụ :Mail server, may in, 6 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 V.Cơ chế hoạt động: Hoạt động nói chung: Sau đây là mô tả một phiên giao dịch (giản lược) của Kerberos. Trong đó: AS = Máy chủ nhận thực (authentication server), TGS = Máy chủ cấp vé (ticket granting server), SS = Máy chủ dịch vụ (service server). Một cách vắn tắt: người sử dụng nhận thực mình với máy chủ nhận thực AS, sau đó chứng minh với máy chủ cấp vé TGS rằng mình đã được nhận thực để nhận vé, cuối cùng chứng minh với máy chủ dịch vụ SS rằng mình đã được chấp thuận để sử dụng dịch vụ. 1. Người sử dụng nhập tên và mật khẩu tại máy tính của mình (máy khách). 2. Phần mềm máy khách thực hiện hàm băm một chiều trên mật khẩu nhận được. Kết quả sẽ được dùng làm khóa bí mật của người sử dụng. 3. Phần mềm máy khách gửi một gói tin (không mật mã hóa) tới máy chủ dịch vụ AS để yêu cầu dịch vụ. Nội dung của gói tin đại ý: "người dùng XYZ muốn sử dụng dịch vụ". Cần chú ý là cả khoá bí mật lẫn mật khẩu đều không được gửi tới AS. 4. AS kiểm tra nhân dạnh của người yêu cầu có nằm trong cơ sở dữ liệu của mình không. Nếu có thì AS gửi 2 gói tin sau tới người sử dụng: Gói tin A: "Khóa phiên TGS/máy khách" được mật mã hóa với khóa bí mật của người sử dụng. Gói tin B: "Vé chấp thuận" (bao gồm chỉ danh người sử dụng (ID), địa chỉ mạng của người sử dụng, thời hạn của vé và "Khóa phiên TGS/máy khách") được mật mã hóa với khóa bí mật của TGS. 5. Khi nhận được 2 gói tin trên, phần mềm máy khách giải mã gói tin A để có khóa phiên với TGS. (Người sử dụng không thể giải mã được gói tin B vì nó được mã hóa với khóa bí mật của TGS). Tại thời điểm này, người dùng có thể 7 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 nhận thực mình với TGS. 6. Khi yêu cầu dịch vụ, người sử dụng gửi 2 gói tin sau tới TGS: Gói tin C: Bao gồm "Vé chấp thuận" từ gói tin B và chỉ danh (ID) của yêu cầu dịch vụ. Gói tin D: Phần nhận thực (bao gồm chỉ danh người sử dụng và thời điểm yêu cầu), mật mã hóa với "Khóa phiên TGS/máy khách". 7. Khi nhận được 2 gói tin C và D, TGS giải mã D rồi gửi 2 gói tin sau tới người sử dụng: Gói tin E: "Vé" (bao gồm chỉ danh người sử dụng, địa chỉ mạng người sử dụng, thời hạn sử dụng và "Khóa phiên máy chủ/máy khách") mật mã hóa với khóa bí mật của máy chủ cung cấp dịch vụ. Gói tin F: "Khóa phiên máy chủ/máy khách" mật mã hóa với "Khóa phiên TGS/máy khách". 8. Khi nhận được 2 gói tin E và F, người sử dụng đã có đủ thông tin để nhận thực với máy chủ cung cấp dịch vụ SS. Máy khách gửi tới SS 2 gói tin: Gói tin E thu được từ bước trước (trong đó có "Khóa phiên máy chủ/máy khách" mật mã hóa với khóa bí mật của SS). Gói tin G: phần nhận thực mới, bao gồm chỉ danh người sử dụng, thời điểm yêu cầu và được mật mã hóa với "Khóa phiên máy chủ/máy khách". 9. SS giải mã "Vé" bằng khóa bí mật của mình và gửi gói tin sau tới người sử dụng để xác nhận định danh của mình và khẳng định sự đồng ý cung cấp dịch vụ: Gói tin H: Thời điểm trong gói tin yêu cầu dịch vụ cộng thêm 1, mật mã hóa với "Khóa phiên máy chủ/máy khách". 10. Máy khách giải mã gói tin xác nhận và kiểm tra thời gian có được cập nhật chính xác. Nếu đúng thì người sử dụng có thể tin tưởng vào máy chủ SS và bắt đầu gửi yêu cầu sử dụng dịch vụ. 11. Máy chủ cung cấp dịch vụ cho người sử dụng. Hoạt động dựa trên khảo sát gói tin : Al -> AS: ID || TGS ID || TimeStamp1 (TS1) AS: kiểm tra TS1, tạo Seasion key (KAl, TGS) và TGT TGT: (TGS ID || Alice’s ID || Alice’s AD || KAl, TGS || (TS2) || Lifetime2 ) E(TGT, KTGS ) AS -> Al: E(TGT || TGS ID || KAl, TGS || (TS2) || Lifetime2), (KAl)) Alice: D(packet, (KAl)). Kiểm tra TS2 và Lifetime2. Tạo authentication cho TGS: ATGS: E(Alice’s ID || Alice’s AD || (TS3), KAl, TGS ). Al -> TGS: TGT || ATGS || ES ID. TGS: TGT || ATGS || ES ID. D(TGT, KTGS ). TGS: TGS ID || Alice’s ID || Alice’s AD || KAl, TGS || (TS2) || Lifetime2. D(ATGS , KAl, TGS ). → Alice’s ID || Alice’s AD || (TS3). TGS kiểm tra TS3, sinh (KAl, ES), TGT tạo ES ticket E ((ES ID || KAl, ES || Alice’s ID || Alice’s AD || (TS4) || Lifetime4), KES ) TGS -> Al: (AAl) : E((ES ticket || ES ID || KAl, ES ||(TS4)), KAl, TGS ) Alice: D(AAl, KAl ) → ES ticket || ES ID || KAl, ES || (TS4). (AES) : E((Alice’s ID || Alice’s AD || (TS5) , KAl, ES ) Al -> ES: ES ticket || AES . 8 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 ES: D(ES ticket, KES ) → ES ID || KAl, ES || Alice’s ID || Alice’s AD || (TS4) || Lifetime4 . D(AES , KAl, ES ) → Alice’s ID || Alice’s AD || (TS5). ES -> (AAl) với (TS5 + 1) và mã hóa với KAl, ES . ES và Alice tiếp tục trao đổi với thông tin đã được mã hóa KAl, ES . VI. Cài đặt Kerberos Các bước cài đặt Kerberos có các bước chính sau: 1. Kế hoạch cài đặt: Chọn nền tảng và hệ điều hành Việc chọn nền tảng và hệ điều hành dành cho bạn nếu bạn sử dụng Window domain controller như 1 hệ thống KDC. Tuy nhiên nếu bạn sử dụng trên nền UNIX KDC thì bạn phải xem xét nền tảng bạn sẽ chạy KDCs. Các mối quan tâm thực sự khi lựa chọn một nền tảng để chạy Kerberos KDCs của bạn là sự đáng tin cậy. Chúng tôi mạnh mẽ khuyến cáo rằng một đĩa riêng biệt (hoặc tốt hơn, một bộ đĩa RAID) được sử dụng để lưu giữ cơ sở dữ liệu Kerberos, và một phân vùng riêng biệt được sử dụng để giữ tất cả các file log. Giữ tập tin đăng nhập vào một phân vùng riêng biệt. Chọn một KDC package Có nhiều KDCs khác nhau có sẵn từ các nhà cung cấp khác nhau, cả thương mại và mã nguồn mở. Mỗi sự thực thi KDC là khác nhau, với những lợi thế và bất lợi khác nhau MIT Chúng tôi sẽ bắt đầu với MIT. Nhiều tổ chức lớn, chủ yếu là các trường đại học, sử dụng MIT KDCs để xử lý xác thực. MIT Kerberos có một cơ sở hỗ trợ lớn và nó được sử dụng trong nhiều môi trường, giúp giải quyết lỗi trên hệ thống. MIT Kerberos có hỗ trợ các loại Kerberos mã hóa tiêu chuẩn, đáng chú ý là 3 DES. Ngoài ra, phiên bản mới nhất của MIT Kerberos, hỗ trợ kiểu mã hóa RC4 được sử dụng bởi dịch vụ Microsoft Active Directory Kerberos cũng như (AES). MIT là một sự lựa chọn tuyệt vời vì sự hỗ trợ rộng và khả năng tương thích ứng dụng. Heimdal Cũng như MIT, có hỗ trợ đầy đủ cho 5 Kerberos, Kerberos 4 Có một số cải tiến hơn MIT Kerberos. Trước tiên, Heimdal hỗ trợ sự truyền cơ sở dữ liệu gia tăng, cho phép Heimdal KDCs chỉ gửi phần thay đổi của cơ sở dữ liệu của máy chủ Kerberos đến các máy chủ khi nó được cập nhật, thay vì toàn bộ cơ sở dữ liệu truyền mỗi khi một bản cập nhật được thực hiện. Ngoài ra, Heimdal tích hợp hỗ trợ cho AFS-Kerberos 5 khả năng tương tác. Heimdal được tích hợp với một số miễn phí hệ điều hành, bao gồm cả BSDs: OpenBSD, NetBSD, và FreeBSD. Heimdal là một sự lựa chọn tốt nếu bạn đang lập kế hoạch sử dụng Unix KDC. Windows domain controllers Việc thực thi Kerberos có trong Windows 2000 về sau. 2. KDC Installation Các bước thiết lập KDC của MIT và Heimdal Thiết lập sự phân phối 9 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 Tạo 1 lãnh địa Khởi động máy chủ Kiểm tra Thêm các KDCs phụ Window domain controller Tạo 1 lãnh địa: trên Window server 2008 Vào Start -> Run -> cmd -> gõ lệnh dcpromo Hộp thoại Welcome to the Active Directory Domain Services Installation Wizard: chọn “Use advanced mode installation” >Next Hộp thoại Choose a Deployment Configuration: chọn “Create a new domain in a new forest” > Next 10 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 Hộp thoại Name the Forest RootDomain: Nhập tên cuong.net > Next Hệ thống sẽ kiểm tra tên miền vừa nhập Hộp thoại Domain NetBIOS Name =>Next 11 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 Hộp thoại Set Forest Functional Level: chӑn Windows Server 2008 => Next Hộp thoại Additional Domain Controller Options:chọn “DNS server” => Next 12 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 Hộp thoại Active Directory Domain Services Installation Wizard: Yes Hộp thọa Location for Database Log Files, and SYSVOL: Next Hộp thoại Directory Services Restore Mode Administrator Password: Nhập pass > Next 13 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 Hộp thoại Summary: Hệ thống làm việc Finish: 3. DNS and Kerberos Sự tham gia của DNS trong hệ thống Kerberos là rất cần thiết, hỗ trợ các nhiều chức năng trong lãnh địa ker của bạn. 14 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 Kerberos có thể sử dụng giao thức DNS là một địa điểm dịch vụ, bằng cách sử dụng bản ghi DNS SRV như được định nghĩa trong RFC 2052. Ngoài ra, Kerberos có thể sử dụng một bản ghi TXT để định vị lĩnh vực thích hợp cho một máy chủ cho hay tên miền. Với những bản ghi DNS, Kerberos client có thể tìm thấy KDCs thích hợp mà không cần sử dụng một tập tin cấu hình. Windows sẽ thiết lập các bản ghi SRV cần thiết tự động khi một miền Active Directory được tạo ra. Những người sử dụng Unix cho KDCs của họ có thể tạo các mục nhập DNS bằng tay trong khu tập của họ như là một sự thuận tiện cho khách hàng. VII.Kerberos 5 : Qua chương V chúng ta đã biết về cơ chế hoạt động của Kerberos,ở phần này chúng tôi xin giới thiệu thêm những chức năng bổ sung mà Kerberos 5 có và những lựa chọn có thể khi chúng ta sử dụng Kerberos 5 : 1.A little changing: Không như phiên bản trước là Kerberos 4 , Kerberos 5 sử dụng ASN.1 (Abstract Syntax Notation One) . Nó định nghĩa một phương pháp để mô tả các định nghĩa giao thức trong một ký hiệu trừu tượng , và sau đó cung cấp một số phương pháp để chuyển đổi các định nghĩa trừu tượng vào một dòng của byte để truyền trên một mạng lưới truyền thông. Một số giao thức sử dụng ASN.1 để xác định các giao thức của họ như Kerberos 5, SNMP và LDAP.Ví dụ trong Kerberos 5: Realm ::= GeneralString PrincipalName ::= SEQUENCE { name-type[0] INTEGER, name-string[1] SEQUENCE OF GeneralString } Chức năng AS và TGS là vẫn giữ nguyên trong Kerberos 5 nhưng tên của TGS thay đổi một chút.Ngoài sự thay đổi đó, Kerberos 5 còn loại trừ sự mã hóa đôi mà xuất hiện trong AS và TGS của KDC khi trả lời(so với Kerberos 4).Sự thay đổi này không làm giảm đi tính an toàn mà ngược lại còn cải thiện hiệu quả và hiệu suất. 3.Multichoice for encryption: Kerberos 5 đã cung cấp nhiều sự lựa chọn cho việc mã hóa như DEC , triple DEC , AES , .Chúng ta có thể lựa chọn cách mã hóa phù hợp cho tưng quá trinh trao đổi .Nhưng có 1 vấn đề đặt ra là làm sao để các thành phần trong hệ thống Kerberos hiểu được nhau.Đối với từng loại message sau mà chúng ta có cách riêng để mã hóa nó: *Ticket: mỗi ticket chỉ được phát hành và mã hóa từ 1 server dịch vụ nào đó, và được giãi mã bằng key của server.Vì vậy ticket có thể được mã hóa bằng phương pháp mã hóa an toàn nhất mà server hỗ trợ. *Reply: là 1 message mà KDC gửi cho client và client phải giải mã nó bằng khóa của mình.Vì vậy ticket phải được mã hóa bằng các phương pháp mà client hỗ trợ 15 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 *Session key: session key được chia sẻ giữa client và sever ứng dụng, nên session key phải được mã hóa bằng phương pháp mà cả client và server đều hỗ trợ. Hệ thống Kerberos (user , server ứng dụng và KDC) phải hỗ trợ ít nhất 1 phương pháp mã hóa giống nhau để có thể giao tiếp được . Khi 1 principal được tạo trên KDC thì nó tự lưu cho mình 1 bản copy của tất cả các key mã hóa từ các phương thức mã hóa mà nó hỗ trợ.Vì vậy KDC có thể đáp ứng nhanh được. 4.Ticket option: Kerberos 5 bao gồm những đặc tính tiên tiến mà cho phép user có nhiều quyền điều khiển hơn thông qua Kerberos vé của họ : *Forwardable tickets: (thường là TGT ,được dùng khá phổ biến) khi cờ TKT_FLG_FORWARDABLE được bật lên ở 1 ticket dưới sự cho phép của admin thì user có thể dùng ticket này để yêu cầu 1 ticket mới nhưng phải khác địa chỉ IP. Nói cách khác, user có thể dùng giấy ủy nhiệm của mình để tạo 1 giấy ủy nhiệm có giá trị cho máy khác. Ngay sau khi user chứng thực xong với AS,user có thể yêu cầu 1 TGT mới trước khi sử dụng phần mềm Kerberos. Được sử dụng nhiều trong chương trình remote login như telnet , rlogin , rsh *Renewable tickets: trong Kerberos thì lifetime của 1 ticket thường la ngắn để hạn chế việc đánh cắp vé của hacker,nhưng như vậy là khá bất tiện với user dùng dài lầu.Từ thực tế đó Kerberos 5 đã hỗ trợ Renewable tickets. Renewable tickets cũng có hạn dùng như vé thường nhưng user có thể gia hạn lâu hơn vé thường . Khi user đang sở hữu 1 ticket còn hạn thì có thể gửi 1 yêu cầu đến KDC để xin 1 Renewable tickets với 1 hạn sử dụng mới.Nếu mọi thỏa hiệp đều ổn thì KDC sẽ xác nhận vé và trả về 1 vé mới.Quá trình xảy ra như thế cho đến lúc vé hết hạn Lợi ích :- khó lấy cắp vé vì hacker khi cầm 1 vé đã hết hạn cũng chẳng làm được gì. Sau khi user dùng xong vé renew thì user có thể thông báo cho KDC biết mình không cần dùng nữa,KDC sẽ từ chối mọi yêu cầu renew vé. *Postdated tickets: Khi chúng ta có 1 kế hoạch cho tương lai và cần dùng đến hệ thống chứng thực của Kerberos thì chúng ta sẽ sử dụng 1 lựa chọn mới của Kerberos 5 là Postdated tickets. Postdated tickets chỉ có giá trị tại bắt đầu từ 1 thời điểm trong tương lai.Nếu user dùng nó trước đó sẽ bị KDC từ chối.Nó không được dùng phổ biến lắm. 5.Kerberos 5-to-4 translation: Để cung cấp khả năng tương thích với dịch vụ của Kerberos 4, Kerberos 5 phát hành dịch vụ Kerberos 5-to-4 translation(krb524). Dịch vụ này cung cấp một cách thức để client của Kerberos 5 có thể giao tiếp với các dịch vụ của Kerberos 4. Nó không cung cấp một cách để client của Kerberos 4 giao tiếp với dịch vụ hoặc KDC của Kerberos 5 . 16 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 Khi một client của Kerberos 5 muốn dùng dịch vụ mà nó chỉ hiểu vé của Kerberos 4 thì thư viện của Kerberos lien lạc với thiết bị chạy krb524 daemon để cung cấp giấy ủy nhiệm phù hợp với Kerberos 4.Khi krb524 daemon nhận được yêu cầu của client ,nó sẽ giải mã service ticket với service key, sau đó giải nén session key bên trong và tạo 1 service ticket mới của Kerberos 4 với session key vừa có được. Chú ý: session key trong Kerberos 5 nhất thiết được mã hóa bởi single DES.Bởi vì krb524 daemon chỉ sao chép key đó và đóng gói lại, và Kerberos 4 chỉ hiểu được single DES Máy chạy krb524 daemon không nhất thiết phải nằm trên KDC.Ví dụ trong windown domain controller không hỗ trợ krb524 daemon nên muốn sử dụng nó ta phải cài đặt 1 máy chạy krb524 daemon riêng. 6. Pre-Authentication: Để làm khó khăn thêm khả năng tấn công bằng offline dictionary và bruce- force Kerberos 5 đã cài đặt Pre-Authentication. Pre-Authentication yêu cầu những người yêu cầu chứng minh danh tính của họ trước khi KDC cấp ticket cho 1 principal riêng biệt. Có nhiều cách để thực hiện Pre-Authentication nhưng mã hóa timestamp lá cách phổ biến nhất. Tùy theo chính sách của KDC mà hệ thống có chạy Pre-Authentication hay không. KDC yêu cầu Pre-Authentication ,nếu client muốn có ticket mà không thông qua Pre-Authentication thì KDC sẽ gửi thông báo lỗi KRB_ERROR thay vì gửi AS_REP đến client.Client sẽ tạo ra dữ liệu cần thiết cho quá trinh Pre-Authentication của mình, sau đó gửi lai AS_REQ đính kèm với phần dữ liệu vừa được tạo ra đó .Nếu KDC chấp nhận thì KDC gửi lại AS_REP kèm theo ticket.Nếu không , KDC gửi lại KRB_ERROR và client không nhận được ticket. 7. String-to-Key Transformation: Chức năng là để chuyển đổi chuỗi ký tự password dạng plaintext thành cyphertext.Điều khác so với Kerberos 4 là Kerberos 5 hỗ trợ bất kỳ thuật toán nào với kích thước key là bất kỳ.Ngoài ra trước khi mã hóa , Kerberos 5 còn thêm vào 1 thành phần gọi là salt vào password của user,làm cho nó tăng thêm sức đề kháng với bruce-force.Salt thì tùy theo KDC chọn nhưng thường la tên của principal. 8. Password Changing: Trước đây ở phiên bản 4 thì người ta dùng administrative protocol cho việc thay đổi password nhưng nó lại gây ra phiền toái khi giữa các thiết bị xài administrative protocol khác nhau. Một tiêu chuẩn cho các giao thức Kerberos 5 thay đổi mật khẩu đã được đề xuất như là một dự thảo Internet trong năm 1998, được giao thức thay đổi mật khẩu Horowitz. Các phiên bản mới của MIT (1,2 trở lên) và Heimdal Kerberos, cũng như Windows 2000 và năm 2003(dựa Active Directory) đều hỗ trợ giao thức thay đổi mật khẩu Horowitz . Sau này 1 dự thảo mới đã thay thế giao thức thay đổi mật khẩu Horowitz.Đó là Kerberos Set/Change Password Version 2.Protocol này cung cấp khả năng cho các quản trị viên để đặt lại mật khẩu người dùng khác, cũng như cho phép người dùng thay đổi mật khẩu của chính họ.Thêm vào đó, nó cho phép gửi lại nhưng thông tin chi tiết hơn cho client khi 1 mật khẩu bị từ chối. 17 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 VIII. Securiry Điều quan trọng là nhận ra rằng Kerberos thực hiện trên mạng của bạn không đảm bảo an ninh hoàn hảo. Trong khi Kerberos là rất an toàn trong một ý thức lý thuyết, có rất nhiều vấn đề an ninh thực tế để được xem xét. Ngoài ra, điều quan trọng là hãy nhớ rằng Kerberos chỉ cung cấp một dịch vụ chứng thực; nó không ngăn cản thỏa hiệp gây ra do lỗi phần mềm máy chủ, quản trị viên cấp giấy phép cho người sử dụng trái phép, hoặc các mật khẩu kém chọn. Có nhiều đánh giá Kerberos là an toàn nhất có thể, tuy nhiên, vẫn còn những vấn đề an ninh cần chú ý. 1. Kerberos Attacks Thật không thể dễ dàng để hacker có thể tấn công hệ thống Kerberos KDC. Nhưng, có một số cuộc tấn công điện tử có thể thỏa hiệp sự bảo mật của hệ thống Kerberos của bạn. Liệt kê dưới đây là kịch bản thỏa hiệp tiềm năng, và hiệu quả về tính an toàn của hệ thống Kerberos. Root compromise of a Kerberos KDC machine. Một thỏa hiệp gốc của 1 máy chủ KDC cho phép kẻ tấn công toàn quyền kiểm soát toàn bộ hệ thống xác thực Kerberos. Mặc dù các cơ sở dữ liệu kerberos được mã hóa trên ổ cứng với khóa kerberos master, khóa master được giữ trên ổ cứng KDC vì thế không có bất kì sự can thiệp bằng tay nào được yêu cầu (nhập password master) khi server KDC bắt đầu. Compromise of a Kerberos administrator's credentials: Nếu 1 hacker lấy được mật khẩu của người quản trị, hacker có thể hoàn thành tấn công trên toàn bộ database kerberos. Root compromise of a server machine: Để giao thức Kerberos làm việc, 1 dịch vụ phải có truy cập đến 1 dịch vụ chính. Các dich vụ chính nằm trên hệ thống tập tin của máy chủ, hoặc nằm trên 1 keytab được thực thi bởi Unix, hoặc LSA bí mật trong những sự thi hành Microsoft. Nếu một kẻ tấn công lấy được quyền truy cập vào một máy chủ, tất cả các dịch vụ Kerberized đang chạy trên máy bị tổn hại. Root compromise of a client machine. Một thỏa hiệp gốc của một máy client sẽ cung cấp cho kẻ tấn công với tất cả các vé đã được lưu trên máy đó. Khi các vé có giới hạn thởi gian, nó không phải là một thỏa hiệp quan trọng như một kẻ tấn công lấy mật khẩu của người dùng. Tuy nhiên, với sự truy cập gốc đến máy client, những kẻ tấn công bí mật có thể cài đặt một sniffer để nắm bắt một mật khẩu người dùng khi đăng nhập vào máy tính của họ. Compromise of user credentials. Có 2 khả năng trong kịch bản này: hoặc bộ nhớ lưu vé người dùng đã bị lộ, hoặc mật khẩu của người dùng bị thỏa hiệp. Nếu hacker lấy được bộ nhớ các vé chưa được mã hóa, các vé chứa trong bộ nhớ cache mà chỉ có hiệu lực trong khoảng thời gian quy định trong vé. Mặt khác, nếu kẻ tấn công sử dụng lại mật khẩu của người dùng, những kẻ tấn công có thể mạo danh người dùng đó cho đến khi người dùng thay đổi mật khẩu của mình. Từ danh sách trên, thực tế là một trong những nền tảng rằng tất cả những kịch bản có tầm quan trọng trong việc giữ tất cả các máy trong mạng của bạn an toàn. Cài đặt Kerberos trên mạng của bạn không làm giảm tầm quan trọng của việc giữ tất cả các máy móc, máy tính người dùng an toàn từ tấn công bên 18 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 ngoài. Những thỏa hiệp của bất kì 1 máy nào trong mạng sẽ có một số hiệu ứng bất lợi về bảo mật của hệ thống xác thực Kerberos của bạn. 2. Other Attacks: Denial of service The "insider" Social engineering and password exposure Security holes in the Kerberos software itself 3.Vấn đề giao thức bảo mật Dictionary and Brute-Force Attacks Trong giao thức Kerberos 4 bản gốc, các KDC tạo một TGT được mã hóa cho khách hàng nào có yêu cầu nó. TGT được mã hóa với khóa bí mật của người dùng. An ninh của toàn bộ hệ thống phụ thuộc vào việc không thể giải mã thông điệp này, vì nếu một kẻ tấn công có thể lấy chìa khóa được sử dụng để mã hóa các tin nhắn, giờ đây anh đã mật khẩu của người dùng và có thể mạo danh người dùng đó theo ý thích. Do đó, nếu một kẻ tấn công muốn có được mật khẩu của người dùng, nó có thể yêu cầu các KDC cho một TGT hợp lệ với tên người dùng nạn nhân. Trong khi không có cách để phá vỡ những phương pháp mã hóa được sử dụng trong Kerberos vé trực tiếp, những kẻ tấn công sau đó có thể tiếp tục brute-force giải mã của TGT bằng cách tung ra một cuộc tấn công từ điển ngoại tuyến. Trong một cuộc tấn công từ điển, kẻ tấn công có một nguồn cấp dữ liệu là danh sách các mật khẩu thường được sử dụng, hoặc một từ điển, với một chương trình bẻ. Đối với mỗi mục trong từ điển, một chương trình cố gắng giải mã thông điệp bằng cách sử dụng mật khẩu. Nếu đạt được thực hiện, chương trình báo cáo lại cho kẻ tấn công của người sử dụng mật khẩu. Khi chuyển đổi từ mật khẩu của người dùng sang khóa mật mã được biết đến, nó là tầm thường cho một kẻ tấn công để xây dựng một chương trình mà có thể dịch các mật khẩu thường thành những khoá mật mã Kerberos. Sau đó, kẻ tấn công thu thập một số lượng lớn TGTs hợp lệ từ các KDC và tiếp tục công việc bẻ các TGTs off-line; với từng cố gắng giải mã, anh ta không có liên hệ với các KDC. Thay vào đó, một khi các TGTs được yêu cầu từ các KDC, không giao tiếp hơn nữa là cần thiết để tấn công các mật khẩu. Các mã hóa được sử dụng trong Kerberos v4, cũng như loại mã hóa phổ biến nhất trong Kerberos v5, là DES. Single DES, thiết kế vào cuối những năm 1970, có chiều dài 56-bit. Khi Kerberos được thiết kế (trong cuối những năm 1980), brute-forcing một khóa 56-bit đã không thực hiện được bởi tốc độ của các bộ vi xử lý có sẵn. Theo tiêu chuẩn hiện nay, với 56-bit, không gian chính của DES được xem là tương đối không an toàn. Năm 1998, Electronic Frontier Foundation đã chứng minh rằng với vốn đầu tư $ 200.000, một kẻ tấn công có thể xác dựng một " DES cracker" mà có thể brute-force khoá mật mã từ một tin nhắn DES trong vòng một 1 ngày. Với bộ xử lí hiện nay (năm 2002), thời gian để giải mã một thông điệp được mã hóa bằng cách sử dụng DES trong phạm vi một vài giờ. Rất may, trong Kerberos v5, một số tính năng giao thức mới được giới thiệu để giảm thiểu nguy cơ này. Đầu tiên là hỗ trợ loại mã hóa mở rộng, cho phép đối với việc bổ sung các kỹ thuật mã hóa mạnh hơn. Ngoài ra, giai đoạn tiền xác thực đã được bổ sung, các client phải chứng thực danh tính trước khi KDC cung cấp vé cho client. Tiền xác thực hạn chế được 19 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 các vấn đề của tấn công offline brute-force, hay tấn công từ điển. Thay vào đó, 1 hacker từ xa phải liên lạc với KDC mỗi khi hacker cố gắng tìm 1 mật khẩu mới. Tuy nhiên, các phương pháp mã hóa mới trong Ker v5 và đặc tính tiền xác thực không hoàn toàn chống lại được tấn công từ điển hay brute-force. Các phương pháp mã hóa mới chắc chắn sẽ khiến cho các tấn công brute- force ít khả thi bằng cách gia tăng sự khó khăn của brute-forcing tin nhắn mã hóa. Tuy nhiên, tất cả các máy chủ, client, và KDCs trên mạng phải hỗ trợ loại mã hóa mới. Nếu, ví dụ, bạn có nhiều client và triển khai máy chủ Kerberos khác nhau được cài đặt trên mạng của bạn (ví dụ, một bộ máy chủ của MIT Kerberos cùng với một số client của Windows), bạn chỉ có thể sử dụng một loại mã hóa thông thường được hỗ trợ bởi tất cả các máy trong mạng của bạn . MIT hỗ trợ triple DES, nhưng Windows không, để truyền thông giữa Windows và MIT Kerberos sẽ bị giới hạn lại DES. Việc phát hành phiên bản 1,3 sắp tới của MIT Kerberos 5 sẽ hỗ trợ các thuật toán mã hóa RC4 được sử dụng bởi Windows, và do đó tăng cường mã hóa được sử dụng cho truyền thông giữa hai thực thi. Với giao thức tiền xác thực, hacker đã không còn nhiều khả năng. vé được mã hóa theo yêu cầu từ các KDC. Tuy nhiên, kẻ tấn công có thể sử dụng một mạng lưới "sniffer" để có được KDC responses khi chúng được gởi đến client. Những responses sẽ bao gồm vé được mã hóa với khóa người dùng. Trong khi các cuộc tấn công trở nên khó khăn hơn do việc tăng cường độ bảo mật, thì đó là 1 vấn đề tiềm năng. Ngoài ra, hầu hết sự thực thi Kerberos đều không bắt buộc sử dụng tiền xác thực là mặc định, phủ định khả năng bảo mật của tiến xác thực. Replay Attacks Vì tất cả các giao thức trao đổi là các tin nhắn được gởi qua một mạng máy tính, kẻ tấn công có thể lắng nghe các tin nhắn một mạng lưới trao đổi xác thực thành công, tạo một bản sao của tin nhắn, và phát lại chúng ở lần sau. Những kẻ tấn công không cần phải đoán mật khẩu của người dùng hoặc giải mã thông điệp nào trong tấn công này. Kể từ khi cuộc tấn công replay yêu cầu truy cập để nghe tất cả các tin nhắn trong mạng cũng như khả năng gửi tin nhắn giả, một cuộc tấn công replay là một cuộc tấn công chủ động. Chúng tôi thấy rằng Alice thành công lấy được vé để xác thực tới máy chủ thư của cô. Bob, kẻ tấn công, bí mật nghe tất cả lưu lượng mạng giữa Alice, máy chủ thư, và KDC Kerberos. Bob không thể trực tiếp sử dụng TGT mà Alice yêu cầu ở bước trước, TGT phải được giải mã với mật khẩu của Alice, Bob không biết mật khẩu đó. Tuy nhiên, khi Alice gửi vé được mã hóa của mình và nhận thực, Bob có thể chặn thư đó và phát lại nó để mạo danh Alice đến máy chủ thư. Vé này được mã hóa với khóa máy chủ thư, và nhận thực được mã hóa với khóa phiên chia sẻ giữa Alice và máy chủ thư. Khi máy chủ thư nhận vé và nhận thực, nó giải mã vé bằng khóa của mình, lấy khóa từ phiên giao vé, và sử dụng khóa phiên để giải mã nhận thực. Nếu tất cả việc giải mã thành công, thì xác thực thành công. Kerberos được thiết lập bảo vệ chống lại tấn công replay attacks. Là quản trị, bạn không phải lo lắng về sự kích hoạt những sự bảo vệ này; chúng được thiết lập trong sự thực thi Kerberos mà bạn đang sử dụng. Những sự bảo vệ đó là: 20 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 - Address field in tickets: khi 1 client yêu cầu vé từ KDC, nó sẽ liệt kê các địa chỉ mạng có các vé hợp lệ. Ví dụ, nếu địa chỉ IP của máy trạm là 192.168.1.1, các máy trạm sẽ điền địa chỉ này vào trong trường địa chỉ ở vé yêu cầu, và KDC sẽ sao chép vào trong vé và trả lại cho máy trạm. sự bảo vệ này giải quyết vấn đề hacker cố gắng gởi lại vé hợp lệ trên một máy trạm không được liệt kê trong trường địa chỉ của vé. Tuy nhiên, bảo vệ này là không đủ để ngăn chặn các replay attacks; trường địa chỉ có thể được để trống, và vé sẽ có giá trị cho tất cả các địa chỉ. Hoặc, nếu kẻ tấn công có quyền truy cập vào một máy được liệt kê trong trường địa chỉ, nó có thể đăng nhập và phát lại các vé từ đó. - Time-based authenticators: việc an ninh trên nền địa chỉ là hoàn hảo, Kerberos sử dụng một đề án để ngăn chặn replay attacks. Mỗi khi một khách hàng muốn sử dụng một dịch vụ Kerberized, cô đã tạo ra một nhận thực, được gửi cùng với vé vào dịch vụ để xác thực. Nhận thực chứa một timestamp, được mã hóa với khóa phiên tạo ra bởi các KDC cho việc thực hiện trao đổi vé. Khi dịch vụ nhận được nhận thực, nó sẽ kiểm tra các dấu thời gian với đồng hồ hệ thống của mình. Nếu có sự chênh lệch 5 phút, các dịch vụ sẽ từ cấp bán vé và từ chối xác thực người dùng. Khoảng thời gian 5 phút được thiết kế cho phép 1 vài sự biến đổi nào đó giữa sự khác nhau giữa các đồng hồ trong mạng. Tuy nhiên, 5 phút có thể là nhiều để hacker có thể gởi lại các vé hợp lệ, đặc biệt là nếu hacker sử dụng một chương trình tự động để bắt và phát lại vé. - Replay caches: cách cuối cùng của sự phòng thủ mà Kerberos chống lại replay attack là Replay caches. Cả Kerberos v4 và v5 đều bao gồm các giao thức dựa trên thời gian nhận thực. Kerberos v5 sử dụng bộ nhớ replay caches để tránh kẻ tấn công sử dụng lại vé trong khoảng thời gian ngắn mà nhận thực cho là hợp lệ. Mỗi dịch vụ Kerberized duy trì một bộ nhớ cache của nhận thực mà nó vừa nhận được. Khi dịch vụ nhận được nhận thực, nó sẽ kiểm tra bộ nhớ replay caches. Nếu dịch vụ tìm thấy một bản sao của nhận thực đã có trong bộ nhớ cache, nó từ chối yêu cầu. Nếu không, dịch vụ chấp nhận yêu cầu và bổ sung xác thực vào trong bộ nhớ replay caches cho các yêu cầu hợp lệ lần sau. Man-in-the-Middle Attacks Cuối cùng, man-in-the-middle ảnh hưởng đến các giao thức xác minh chứng thực. Man-in-the-middle là cách tấn công chủ động, nghĩa là kẻ tấn công phải có khả năng đọc tất cả các tin nhắn trên mạng cũng như gửi đi những thông điệp tùy ý của mình. Mục đích của tấn công này là mạo danh máy chủ, kết quả là người dùng nghĩ rằng mình đã kết nối với máy chủ hợp pháp, nhưng thực tế thì đang nói chuyện với kẻ tấn công. Một khi kẻ tấn công có kiểm soát được phiên, thì có thể dễ dàng hành động (qua tin nhắn giữa người sử dụng và máy chủ hợp pháp, mà không sửa đổi), hoặc cô sửa đổi, hoặc xóa thông điệp giữa người sử dụng và máy chủ. Những kẻ tấn công là một phần của cuộc đàm thoại giữa người sử dụng và máy chủ hợp pháp, và có thể sửa đổi bất kỳ thông điệp mà đi qua chúng. Tin tốt lành là giao thức Kerberos đã được xây dựng trong bảo vệ chống lại man-in-the-middle. Một khi Kerberos thực hiện sự chứng thực 21 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 lẫn nhau, bởi xác thực không chỉ để xác minh người dùng mà còn xác minh máy chủ, man in the middle bị cản trở. Để chống lại tấn công này, một số cơ chế để xác nhận khoá mật mã của máy chủ phải tồn tại. Những giao thức khác sử dụng sự xác minh bằng tay, hoặc xác thực chữ kí. Kerberos sử dụng một bản sao của tất cả các khóa cho cả dịch vụ và người dùng được lưu trên các KDC để đảm bảo bảo vệ chống lại MITM attack. Khóa phiên tạo ra bởi các KDC và sau đó được gửi đến dịch vụ được mã hóa với khóa của dịch vụ, kẻ tấn công không thể phục hồi phiên làm việc mà không có khóa bí mật của dịch vụ. Một máy client sau đó có thể phát hiện xem máy chủ anh ta nói đến là hợp pháp bằng cách yêu cầu xác thực lẫn nhau, nơi mà các máy chủ phải chứng minh danh tính của mình bằng cách khôi phục các khóa phiên, mã hóa một responses, và gửi nó trở lại cho client. Nếu máy chủ không phải là hợp lệ, và không có một bản sao của chính dịch vụ, và máy chủ không thể gửi lại tin nhắn hợp lệ được mã hóa, và client ngắt kết nối. Trong khi Kerberos cung cấp khả năng thực hiện sự chứng thực lẫn nhau, những ứng dụng phải có mã để cho phép sự bảo vệ đó. Ngoài ra, nhiều ứng dụng, chẳng hạn như các mô đun PAM có sẵn để xác thực với mật khẩu Kerberos, không sử dụng quá trình xác thực dựa trên nền vé. Thay vào đó, chúng giữ 1 mật khẩu trên mạng (hy vọng được mật mã) và xác minh nó ở bên máy chủ bằng cách yêu cầu các KDC cho một TGT và sau đó giải mã các TGT. Đây là nơi tấn công MITM có thể được gắn kết với Kerberos. Trong trường hợp này, kẻ tấn công muốn đặt mình ở giữa máy chủ và KDC, vì vậy mà hacker có thể làm giả máy chủ ứng dụng. Các KDC requests and responses là các tin nhắn UDP đơn giản, thật là dễ dàng để một hacker đưa ra những thông báo giả mạo mà ngụ ý đến từ địa chỉ IP thực sự của KDC. Như vậy, tấn công được thực hiện thông qua các thủ tục sau đây: - Những kẻ tấn công tạo một mật khẩu để sử dụng cho tài khoản mà chúng mong muốn được truy cập vào. - Những kẻ tấn công sau đó thiết lập một chương trình để lắng nghe các yêu cầu trên mạng, để xem khi nào client yêu cầu một TGT cho người sử dụng A. Khi nhận được 1 TGT, chương trình sẽ gởi TGT- responses trả lại cho yêu cầu và được mã hóa với password đã chọn. - Sau đó, kẻ tấn công truy nhập vào server, tạo username A và pass đã chọn. Vào thời điểm đó, chương trình sẽ gửi tới máy chủ TGT được mã hóa với mật khẩu mà những kẻ tấn công đã chọn thay vì mật khẩu thực. - Nếu máy chủ nhận được responses giả trước, nó sẽ giải mã thành công TGT từ mật khẩu phù hợp. Để ngăn chặn cuộc tấn công này, máy chủ phải lấy khóa dịch vụ máy chủ của mình từ keytab, sau đó yêu cầu 1 khóa dịch vụ từ KDC dùng TGT đang tồn tại đại diện cho người sử dụng. Chỉ máy chủ và KDC biết khóa dịch vụ máy chủ, một kẻ tấn công từ bên ngoài không thể tạo một thông điệp giả mạo và tài khoản bị từ chối truy cập 4. Firewall, NAT và Kerberos 22 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 Vì Kerberos dựa chủ yếu vào các hoạt động đúng đắn của DNS và các giao thức bao gồm địa chỉ IP, tường lửa và NAT. Phổ biến nhất là thiết lập mà các máy client được đặt ở bên ngoài của một bức tường lửa công ty, và các KDCs và máy chủ ứng dụng nằm bên trong tường lửa. Để các client bên ngoài có được vé cho các lĩnh vực Kerberos, một số cổng cần phải được mở thông qua các bức tường lửa đến KDCs của bạn. Kerberos Network Ports Remote Local port Machine port Description (server) (client) 88/udp Above All KDCs Kerberos 5 ticket service 88/tcp 1024 Above Kerberos 5 administration All KDCs 749/tcp 1024 service (MIT and Heimdal) Master/Administrative Above Kerberos 5 password 464/udp changing service (older KDC 1024 password-changing protocol) Thật ra thì chỉ duy nhất 1 port cần mở để hệ thống Ker hoạt động là port 88. Các port khác có thể được mở để cung cấp các dịch vụ khác đến client bên ngoài tường lửa Kerberos and NAT KDC và máy chủ ứng dụng phía sau tường lửa, với các client sử dụng NAT 23 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 Network Address Translation, hoặc NAT, cho phép nhiều máy tính chia sẻ một địa chỉ IP duy nhất. Trong một thiết lập NAT, các máy client bên trong dịch vụ NAT có sự riêng tư, không định tuyến địa chỉ IP. NAT cung cấp 1 vấn đề cho Kerberos vì các vé yêu cầu đều chứa địa chỉ IP của người yêu cầu. Vì các client yêu cầu vé trong trường hợp sử dụng NAT, nên các địa chỉ IP client cung cấp đến KDC sẽ không trong bảng định tuyến. Vì các địa chỉ riêng tư của client không phụ hợp với địa chỉ public của NAT nên các dịch vụ Kerberized sẽ không cấp bất kì vé nào cho khách hàng. Ví dụ: ở hình trên Thiết bị NAT có public IP: 132.68.153.28 Mạng nội bộ có giá trị IP trong RFC 1918 là 192.168.1.0 to 192.168.1.255 Một client (sử dụng dịch vụ NAT) có địa chỉ IP là 192.168.1.2 yêu cầu 1 TGT đến KDC bên trong hệ thống tường lửa. 1 vé TGT có giá trị cho địa chỉ IP client 192.168.1.2 không phù hợp với địa chỉ 132.168.153.28 của NAT, nên yêu cầu của client không được thực hiện. Việc sử dụng các vé không có trường địa chỉ (để hỗ trợ cho các thiết bị NAT) sẽ làm giảm đi tính bảo mật. Kẻ tấn công có thể tạo một bản sao lưu bộ nhớ caches ticket và việc tấn công replay attack có thể dễ dàng hơn. Auditing Windows domain controllers Mặc dù có 1 chắc chắn rằng máy tính của bạn đã được an toàn tấn công từ bên ngoài, bạn cũng cần phải giám sát định kì hoạt động của KDC. Tùy thuộc vào nhà cung cấp KDC, số lượng truy cập theo măc định có thể khác nhau từ không (cấu hình mặc định của window 2000) đến rất nhiều (MIT và Hiemdal) Việc đăng nhập được thiết lập trong sự thực thi KDC không chỉ với mục đích giám sát, mà nó còn đòng vai trò gỡ rối trong suốt quá trình hoạt động của hệ thống Kerberos. Sự đăng nhập của một user vào máy chủ Windown Domain Controller trong Window server 2008: Domain: CUONG.NET Client name: admin Sử dụng phần mềm Kerbtray và Klist 24 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 25 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 IX. Ưu nhược điểm của giao thức Ưu điểm Kerberos là một giao thức mật mã dùng để xác thực trong các mạng máy tính hoạt động trên những đường truyền không an toàn, là giao thức mặc định trong các hệ điều hành Window, Mac OS, Unix Được đánh giá là giao thức an toàn. Mật khẩu không được truyền trực tiếp trên đường truyền mạng, hạn chế tối đa các tấn công. Giao thức được mã hóa theo các chuẩn mã hóa cao cấp như Triple DES, RC4, AES nên rất an toàn. Theo cơ chế Single-Sign-on, đăng nhập một lần, hạn chế việc tấn công làm mất dữ liệu Vé bị đánh cắp rất khó tái sử dụng Thay vì gởi các thông tin gốc và mật khẩu trên mạng, Kerberos sử dụng vé đã mã hóa để chứng minh danh tính của cả người sử dụng và máy chủ, hệ thống xác thực người dùng và người dùng xác thực lại server. Nhược điểm Toàn bộ hệ thống làm việc dựa trên sự an toàn của hệ thống KDC, nếu hệ thống bị tấn công thì toàn bộ các thành phần trong hệ thống bị tê liệt, KDC là hiểm họa chính của sự tấn công. Đòi hỏi các máy tính trong hệ thống phải đồng bộ vệ thời gian (không chênh lệch với nhau quá 5 phút) Với cơ chế đăng nhập một lần trên một máy tính, nếu máy tính đó rơi vào tay attackers thì toàn bộ dữ liệu người dùng bị đánh cắp, và gây nguy cơ cho toàn bộ hệ thống. X. Trust Relationship Trust relationship là một liên kết luận lý được thiết lập giữa các hệ thống domain, giúp cho cơ chế chứng thực giữa các hệ thống domain có thể được thừa hưởng lẫn nhau. Trust relationship giải quyết bài toán “single sign-on” - logon chứng thực một lần duy nhất cho tất cả mọi hoạt động trên các domain, dịch vụ triển khai trên 1 domain có thể được truy cập từ user thuộc domain khác. Trong một trust relationship cần phải có 2 domain. Domain được tin tưởng gọi là trusted domain, còn domain tin tưởng domain kia gọi là trusting domain. Cơ chế trust relationship giúp đảm bảo các đối tượng (user, ứng dụng hay chương trình) được tạo ra trên một trusted domain có thể được chứng thực đăng nhập hay truy cập tài nguyên, dịch vụ trên trusting domain. Tuy nhiên, trên hệ thống Windows hỗ trợ đến 6 loại trust relationship với các đặc tính và ứng dụng khác nhau. Bài này sẽ giúp các bạn hiểu hơn về đặc tính cũng như ứng dụng từng loại để triển khai trên hệ thống cho hợp lí. 26 | G i a o t h ức xác thực Kerberos
- PTIT_D06THA1 Các loại trust relationship Một trust relationship trên Windows Server 2003 bao gồm 3 đặc tính sau: - Explicitly or Implicitly (tường minh hay ngầm định) - Transitive or Non-transitive (có tính bắc cầu hay không có tính bắc cầu) - Trust direction (chiều của liên kết) Các loại trust relationship: có 6 loại - Tree/root trust - Parent/child trust - Shortcut trust - Realm trust - External trust - Forest trust Để các users thuộc domain này có thể truy cập tai nguyên trên cac máy server thuộc domain khác ( các domain có trust relationship với nhau) thì để xác thực các users đó, các hệ thống domain đều phải dùng giao thức xác thực Kerberos để xác thực. Tài liệu tham khảo: Kerberos: The Definitive Guide (Jason Garman/O'Reilly) Garman/dp/0596004036/ref=sr_1_1/202-9173258- 1666237?ie=UTF8&s=books&qid=1182273864&sr=8-1 MIT: Designing an Authentication System: A Dialogue in Four Scenes Microsoft: step.mspx 27 | G i a o t h ức xác thực Kerberos