Bao Mat Mang

1

Mục lục

A.Tổng quan về đề tài.................................................................................................................4B. Cấu trúc của đề tài..................................................................................................................5I.Tổng quan về an ninh mạng:....................................................................................................6

1.Mục tiêu an ninh mạng........................................................................................................62.Các phương thức tấn công...................................................................................................6

2.1 Virus..............................................................................................................................62.2 Worm............................................................................................................................72.3 Trojan horse..................................................................................................................72.4 Từ chối dịch vụ.............................................................................................................82.5. Distributed Denial-of-Service......................................................................................82.6. Spyware........................................................................................................................92.7. Phishing.......................................................................................................................92.8. Dựa vào yếu tố con người..........................................................................................10

3. Các chính sách an ninh mạng............................................................................................103.1. Các chính sách an ninh văn bản................................................................................103.2. Chính sách quản lý truy cập:......................................................................................133.3. Chính sách lọc:...........................................................................................................133.4. Chính sách định tuyến:...............................................................................................143.5. Chính sách Remote-access/VPN................................................................................143.6. Chính sách giám sát / ghi nhận:................................................................................153.7. Chính sách vùng DMZ...............................................................................................153.8. Chính sách có thể áp dụng thông thường:..................................................................16

II. Radius...................................................................................................................................171. Tổng quan về Radius:.......................................................................................................17

1.1. AAA:..........................................................................................................................171.1.1. Xác thực (Authentication).......................................................................................171.1.2. Ủy quyền (Authorization).......................................................................................171.1.3. Kế toán (Accounting)..............................................................................................181.2 Các điểm chính của kiến trúc AAA:...........................................................................18

2. Kiến trúc RADIUS:...........................................................................................................212.1. Sử dụng UDP hay TCP:.............................................................................................212.2. Định dạng gói tin RADIUS:......................................................................................232.2.1. Mã:..........................................................................................................................232.2.2. Từ định danh:..........................................................................................................242.2.3. Độ dài:.....................................................................................................................242.2.4. Bộ xác thực:............................................................................................................242.3. Phân loại gói tin:........................................................................................................252.3.1. Access-Request:......................................................................................................252.3.2. Access-Accept:.......................................................................................................262.3.3. Access-Reject:.........................................................................................................272.3.4. Access-Challenge :..................................................................................................282.3.5. Accounting-Request:...............................................................................................292.3.6. Accounting-Response:............................................................................................302.4. Bí mật chia sẻ:............................................................................................................312.5. Các thuộc tính và giá trị:............................................................................................322.5.1. Các thuộc tính:........................................................................................................322.5.2. Các giá trị:...............................................................................................................35

GVHD: THS Nguyễn Đức Quang SVTH:Nguyễn Đắc Nguyên Long MSSV:106102078 Lê Hoàng Long MSSV:106102079

2

3. Hoạt động:.........................................................................................................................363.1. Quá trính truy cập:.....................................................................................................363.2. Quá trình kế toán:......................................................................................................39

4. RFCs:................................................................................................................................394.1. Nguồn gốc:.................................................................................................................394.2. Bảng RFCs:................................................................................................................404.3.2. RFC 2866:...............................................................................................................424.3.3. RFC 2867:...............................................................................................................434.3.4. RFC 2868:...............................................................................................................444.3.5. RFC 2869:...............................................................................................................45

III. ASA.....................................................................................................................................461. Lịch sử ra đời....................................................................................................................462. Các sản phẩm tường lửa của Cisco:..................................................................................463. Điều khiển truy cập mạng (NAC).....................................................................................47

3.1. Lọc gói (Packet Filtering)..........................................................................................473.2. Lọc nội dung và URL (Content and URL Filtering)..................................................503.2.1. Content Filtering.....................................................................................................503.2.2. ActiveX Filtering....................................................................................................503.3. Chuyển đổi địa chỉ.....................................................................................................513.3.1. Network Address Translation (NAT).....................................................................513.3.2. Port Address Translation (PAT).............................................................................51

4. Giao thức AAA và dịch vụ hỗ trợ của Cisco ASA...........................................................524.1. Remote Authentication Dial-In User Service (Radius).............................................534.2. Định dạng TACACS và các giá trị tiêu đề.................................................................564.3. Rsa SecurID (SID).....................................................................................................584.4. Win NT.......................................................................................................................594.5. Kerberos.....................................................................................................................594.6. Lightweight Directory Access Protocol (LDAP).......................................................59

5. Kiểm tra ứng dụng............................................................................................................616. Khả năng chịu lỗi và dự phòng (failover and redundancy)...............................................62

6.1. Kiến trúc chịu lỗi.......................................................................................................626.2. Điều kiện kích hoạt khả năng chịu lỗi.......................................................................636.3. Trạng thái chịu lỗi......................................................................................................63

7. Chất lượng dịch vụ (QoS).................................................................................................647.1. Traffic Policing..........................................................................................................647.2. Traffic Prioritization..................................................................................................66

8. Phát hiện xâm nhập (IDS).................................................................................................668.1. Network-based intrusion detection systems (NIDS)..................................................678.1.1. Lợi thế của Network-Based IDSs...........................................................................678.1.2. Hạn chế của Network-Based IDSs..........................................................................688.2. Host-based intrusion detection systems (HIDS)........................................................688.2.1. Lợi thế của HIDS....................................................................................................708.2.2. Hạn chế của HIDS..................................................................................................70

IV. Mô phỏng............................................................................................................................701. Mục tiêu của mô phỏng.....................................................................................................702. Mô hình mô phỏng............................................................................................................713. Các công cụ cần thiết để thực hiện mô phỏng..................................................................714. Các bước mô phỏng..........................................................................................................715. Kết quả đạt được...............................................................................................................80


3

V.KẾT LUẬN CHUNG............................................................................................................81VI.HƯỚNG PHÁT TRIỂN CỦA ĐỀ TÀI...............................................................................82

Mục lục hình vẻ


4

A.Tổng quan về đề tàiMục tiêu của việc nghiên cứu về Firewall ASA

+ Việc nghiên cứu giúp cho khả năng tự học ,tìm hiểu và nghiên cứu độc lập ngày

càng tốt hơn

+ Nghiên cứu về hệ thống firewall ASA.

+ Triển khai hệ thống phất hiện, ngăn chặn các lưu lượng ra vào của hệ thống là sự

cần thiết cho các doanh nghiệp có nhu cầu về sự an toàn của hệ thống trước những

hành vi xâm nhập trái phép. Trước sự phát triển của internet và sự hiểu biết của ngày

càng sâu của con người thì việc truy cập và phá hoại hệ thống mạng của một doanh

nghiệp ,công ty nào đó củng theo đà phát triển của internet mà tăng lên rất nhiều.

+ Việc nghiên cứu này đáp ứng cho lãnh vực bảo mật và an ninh của hệ thống.

+ ASA(Adaptive Security Appliance) là một thiết bị tường lửa mạnh tất cả trong

một và được ưa chuộng nhất hiện nay của Cisco.Chính vì vậy mục tiêu của đề tài này

là nhằm nghiên cứu và tìm hiểu cách thức hoạt động,phương pháp cấu hình và ứng

dụng của nó trong việc bảo mật hệ thống mạng.Kết quả đạt được qua việc nghiên cứu

thiết bị này là hiểu được cách thức hoạt động và có khả năng triển khai thiết bị này vào

trong một số hệ thống mạng bất kỳ.

+Nghiên cứu về AAA server.

+Nghiên cứu về cách tổ chức giám sát hoạt động của người dùng cuối như thời

gian bắt đầu hay kết thúc của người dùng (accounting).Bảo mật là vấn đề rất quan

trọng.Với mức độ điều khiển, thật dễ dàng để cài đặt bảo mật và quản trị mạng. có thể

định nghĩa các vai trò (role) đưa ra cho user những lệnh mà họ cần để hoàn thành

nhiệm vụ của họ và theo dõi những thay đổi trong mạng. Với khả năng log lại các sự

kiện, ta có thể có những sự điều chỉnh thích hợp với từng yêu cầu đặt ra.

Tất cả những thành phần này là cần thiết để duy trì tính an toàn, bảo mật cho mạng.

Với thông tin thu thập được, có thể tiên đoán việc cập nhật cần thiết theo thời gian.

Yêu cầu bảo mật dữ liệu, gia tăng băng thông, giám sát các vấn đề trên mạng thông

AAA server.


5

B. Cấu trúc của đề tài.Đề tài được chia làm 6 phần.

I. Tổng quan về an ninh mạng

Chương này mô tả về các nguy cơ an ninh mạng và các chính sách an ninh

nhằm đem lại hiệu qua cho việc bảo mật dữ liệu làm giảm nguy cơ hoặc phát hiện ra

sự tấn công.

II. Radius

Chương này mô tả về kỹ thuật sử dụng để xác thực,ủy quyền,thanh toán nhằm

đem lại hiểu quả cao cho an ninh mạng toàn vẹn và tránh thất thoát dữ liệu.

III. ASA

Chương này giới thiệu về tường lủa cisco asa ,các kỹ thuật được áp dụng cho

tường lửu .

IV. Mô phỏng.

Chương này mô tả quá trình hiện thực cisco asa với mô hình mạng cụ thể cho

thấy tính thực tế và kiểm nghiệm đúng lý thuyết của đề tài này.Chỉ rõ chi tiết quá trình

thực nghiệm.

V. Kết luận chung.

Chương này nêu ra những kết quả của đề tài làm được những gì và những mặc

hạn chế khó khăn chưa thực hiện được của đề tài.

VI. Hướng phát triển của đề tài.


6

I.Tổng quan về an ninh mạng:

1.Mục tiêu an ninh mạng

Việc phát triển ngày càng tăng của mạng internet do sự thuận tiện mà nó đem lại

cho con người tuy nhiên cũng kéo theo nhiều mối nguy hiểm rình rập của những

hacker mạng. Đảm bảo cho người dùng được an toàn khi làm việc trên mạng là mục

tiêu hàng đầu của an ninh mạng:

Bảo đảm mạng nội bộ không bị xâm nhập trái phép.

Các tài liệu và thông tin quan trọng không bị rò rỉ và bị mất.

Các dịch vụ được thực hiện nhanh chóng không bị trì trệ hoặc không được thực

hiện.

Các cuộc mua bán trên mạng diễn ra đúng với yêu cầu người dùng.

Người dùng làm việc trên mạng không bị mạo danh, lừa đảo.

2.Các phương thức tấn công

Virus

Worm

Trojan

Từ chối dịch vụ

Phân phối từ chối dịch vụ

Zombies

Spyware

Phishing

Dựa vào yếu tố con người

2.1 Virus

Một virus máy tính được thiết kế để tấn công một máy tính và thường phá các máy

tính khác và các thiết bị mạng. Một virus thường có thể là một tập tin đính kèm trong

e-mail, và chọn các tập tin đính kèm có thể gây ra các mã thực thi để chạy và tái tạo

virus. Một virus phải được thực hiện hoặc chạy trong bộ nhớ để chạy và tìm kiếm các


7

chương trình khác hoặc máy chủ để lây nhiễm và nhân rộng. Như tên của nó, virus cần

một máy chủ như là một bảng tính hoặc e-mail để đính kèm, lây nhiễm, và nhân rộng.

Có một số hiệu ứng chung của vi rút. Một số virus lành tính, và chỉ cần thông báo cho

nạn nhân của họ rằng họ đã bị nhiễm bệnh. Các virus ác tính tạo ra sự hủy hoại bằng

cách xóa các tập tin và nếu không thì gây ra lỗi cho các máy tính bị nhiễm có chứa tài

sản kỹ thuật số, chẳng hạn như hình ảnh, tài liệu, mật khẩu, và các bản báo cáo tài

chính.

2.2 Worm

Worm là một chương trình phá hoại quét các điểm yếu hoặc lỗ hổng bảo mật trên

các máy tính khác để khai thác các điểm yếu và nhân rộng.Worm có thể tái tạo độc lập

và rất nhanh chóng.

Worm khác với virus trong hai cách chính:

Virus cần một máy chủ để đính kèm và thực hiện, và sâu không yêu cầu một máy

chủ.Virus và sâu thường gây ra các loại khác nhau của sự hủy diệt.

Virus, một khi chúng đang cư trú trong bộ nhớ, thường xóa và sửa đổi các tập tin

quan trọng trên máy tính bị nhiễm bệnh. Tuy nhiên, Worms có xu hướng mạng trung

tâm hơn so với máy tính trung tâm. Worms có thể tái tạo một cách nhanh chóng bằng

cách bắt đầu kết nối mạng để nhân rộng và gửi số lượng lớn dữ liệu. Worms cũng có

thể chứa một hành khách mang theo, hoặc trọng tải dữ liệu, mà có thể giao một máy

tính mục tiêu cho các trạng thái của một zombie. Zombie là một máy tính có bị xâm

phạm và hiện đang được kiểm soát bởi những kẻ tấn công mạng. Zombies thường

được sử dụng để khởi động các cuộc tấn công mạng khác. Một bộ sưu tập lớn các

zombie dưới sự điều khiển của kẻ tấn công được gọi là một "botnet". Botnets có thể

phát triển được khá lớn. Botnet được xác định đã lớn hơn 100.000 máy tính zombie.

2.3 Trojan horse

Một con ngựa Trojan, hoặc Trojan, là phần mềm nguy hại tìm cách ngụy trang

chính nó như là một ứng dụng đáng tin cậy như là một trò chơi hoặc trình bảo vệ màn

hình. Một khi người dùng tin cậy cố gắng để truy cập những gì có vẻ là một trò chơi


8

vô thưởng vô phạt hoặc trình bảo vệ màn hình, các Trojan có thể bắt đầu các hoạt động

gây tổn hại như xóa các tập tin hoặc định dạng lại một ổ đĩa cứng. Trojan thường

không tự sao chép.Những kẻ tấn công mạng cố gắng sử dụng các ứng dụng phổ biến,

chẳng hạn như iTunes của Apple, để triển khai một Trojan. Ví dụ, một cuộc tấn công

mạng sẽ gửi một e-mail với một liên kết có mục đích để tải về một bài hát iTunes miễn

phí. Trojan này sau đó sẽ bắt đầu một kết nối đến một máy chủ web bên ngoài và bắt

đầu một cuộc tấn công một khi người dùng cố gắng để tải về các bài hát miễn phí rõ

ràng.

2.4 Từ chối dịch vụ.

Một cuộc tấn công từ chối dịch vụ (DoS) là một cuộc tấn công mạng có kết quả

trong việc từ chối dịch vụ bằng một ứng dụng yêu cầu như là một máy chủ web. Có

một vài cơ chế để tạo ra một cuộc tấn công DoS. Các phương pháp đơn giản nhất là

tạo ra một lượng lớn những gì xuất hiện để được giao thông mạng hợp lệ. Đây là loại

tấn công DoS mạng cố gắng để làm nghẽn các ống dẫn lưu lượng truy cập mạng để sử

dụng hợp lệ không thể có được thông qua kết nối mạng. Tuy nhiên, loại DoS thông

thường cần phải được phân phối bởi vì nó thường đòi hỏi nhiều hơn một nguồn để tạo

ra các cuộc tấn công.Một cuộc tấn công DoS lợi dụng thực tế là hệ thống mục tiêu như

các máy chủ phải duy trì thông tin trạng thái và có thể có kích thước bộ đệm và dự

kiến nội dung gói tin mạng cho các ứng dụng cụ thể. Một cuộc tấn công DoS có thể

khai thác lỗ hổng này bằng cách gửi các gói có giá trị kích cỡ và dữ liệu mà không như

mong đợi của các ứng dụng nhận được.Một số loại tấn công DoS tồn tại, bao gồm các

cuộc tấn công Teardrop và Ping of Death, mà gửi các gói thủ công mạng khác nhau từ

những ứng dụng dự kiến và có thể gây ra sụp đổ các ứng dụng và máy chủ. Những

cuộc tấn công DoS trên một máy chủ không được bảo vệ, chẳng hạn như một máy chủ

thương mại điện tử, có thể gây ra các máy chủ bị lỗi và ngăn chặn người dùng bổ sung

thêm hàng vào giỏ mua sắm của họ.

2.5. Distributed Denial-of-Service


9

DDoS tương tự như trong ý định của cuộc tấn công DoS, ngoại trừ cuộc tấn công

DDoS tạo ra nhiều nguồn tấn công. Ngoài ra để tăng lượng truy cập mạng từ nhiều kẻ

tấn công phân phối, một cuộc tấn công DDoS cũng đưa ra những thách thức của yêu

cầu bảo vệ mạng để xác định và ngăn chặn mỗi kẻ tấn công phân phối.

2.6. Spyware

Spyware là một lớp các ứng dụng phần mềm có thể tham gia vào một cuộc tấn

công mạng. Spyware là một ứng dụng cài đặt và vẫn còn để ẩn trên máy tính hoặc máy

tính xách tay mục tiêu. Một khi các ứng dụng phần mềm gián điệp đã được bí mật cài

đặt, phần mềm gián điệp bắt thông tin về những gì người dùng đang làm với máy tính

của họ. Một số thông tin bị bắt bao gồm các trang web truy cập, e-mail gửi đi, và mật

khẩu sử dụng. Những kẻ tấn công có thể sử dụng các mật khẩu và thông tin bắt được

để đi vào được mạng để khởi động một cuộc tấn công mạng.

Ngoài việc được sử dụng để trực tiếp tham gia vào một cuộc tấn công mạng, phần

mềm gián điệp cũng có thể được sử dụng để thu thập thông tin có thể được bán một

cách bí mật. Thông tin này, một lần mua, có thể được sử dụng bởi một kẻ tấn công

khác đó là "khai thác dữ liệu" để sử dụng trong việc lập kế hoạch cho một cuộc tấn

công mạng khác.

2.7. Phishing

Phishing là một kiểu tấn công mạng thường bắt đầu bằng cách gửi e-mail để người

dùng không nghi ngờ. Các e-mail lừa đảo cố gắng để trông giống như một thư điện tử

hợp pháp từ một tổ chức được biết đến và đáng tin cậy như là một trang web ngân

hàng, thương mại điện tử. E-mail giả này cố gắng thuyết phục người dùng rằng một

việc gì đó đã xảy ra, chẳng hạn như hoạt động đáng ngờ về tài khoản của họ, và người

sử dụng phải thực hiện theo các liên kết trong e-mail và đăng nhập vào trang web để

xem thông tin người dùng của họ. Các liên kết trong e-mail này thường là một bản sao

giả của ngân hàng hoặc trang web thương mại điện tử thực sự và các tính năng tương

tự nhìn-và-cảm nhận các trang web thực sự. Các cuộc tấn công lừa đảo được thiết kế


10

để lừa người dùng cung cấp thông tin có giá trị như tên người dùng và mật khẩu của

họ.

2.8. Dựa vào yếu tố con người

Kẻ tấn công có thể liên lạc với một người quản trị hệ thống, giả làm một người sử

dụng để yêu cầu thay đổi mật khẩu, thay đổi quyền truy nhập của mình đối với hệ

thống, hoặc thậm chí thay đổi một số cấu hình của hệ thống để thực hiện các phương

pháp tấn công khác.Với kiểu tấn công này không một thiết bị nào có thể ngăn chặn

một cách hữu hiệu, và chỉ có một cách giáo dục người sử dụng mạng nội bộ về những

yêu cầu bảo mật để đề cao cảnh giác với những hiện tượng đáng nghi.Nói chung yếu

tố con người là một điểm yếu trong bất kỳ một hệ thống bảo vệ nào, và chỉ có sự giáo

dục cộng với tinh thần hợp tác từ phía người sử dụng có thể nâng cao được độ an toàn

của hệ thống bảo vệ

3. Các chính sách an ninh mạng

Hai hình thức chính sách bảo mật có liên quan đến bức tường lửa:

Các chính sách an ninh văn bản (đôi khi được gọi là các chính sách an ninh thông

tin) để xác định những mục tiêu an ninh cho các tổ chức (bao gồm cả tường lửa của

họ)

Các chính sách quản lý và lọc nguồn và đích (đôi khi được gọi là chính sách tường

lửa hoặc thiết lập quy tắc tường lửa) để xác định cấu hình thực tế của thiết bị.

3.1. Các chính sách an ninh văn bản

Chính sách an ninh văn bản tồn tại để cung cấp một lộ trình cấp cao về những gì

cần phải được thực hiện để đảm bảo rằng tổ chức này có một chiến lược an ninh được

xác định tốt và ngoài sức tưởng tượng. Đó là một quan niệm sai lầm phổ biến mà một

tổ chức có một chính sách an ninh. Trong thực tế, chính sách bảo mật tổng thể của một

tổ chức thường bao gồm nhiều chính sách bảo mật cá nhân, mà được ghi vào địa chỉ

mục tiêu cụ thể, thiết bị, hoặc các sản phẩm.


11

Mục tiêu của một chính sách an ninh là xác định những gì cần phải được bảo vệ,

những người có trách nhiệm bảo vệ, và trong một số trường hợp như thế nào bảo vệ sẽ

xảy ra. Chức năng này cuối cùng thường tách ra thành một tài liệu thủ tục độc lập như

lọc nguồn, lọc đích, hoặc quản lý truy. Tóm lại, các chính sách bảo mật đơn giản và

chính xác nên vạch ra những yêu cầu cụ thể, quy tắc, và mục tiêu đó phải được đáp

ứng, để cung cấp một phương pháp đo lường của đặc điểm an ninh được chứng thực

của tổ chức.

Để giúp đảm bảo rằng các chính sách bảo mật sẽ làm được điều này, suy nghĩ của

tường lửa trong điều khoản của các lớp bảo mật, với mỗi lớp có một lĩnh vực cụ thể

của hoạt động. Hình 1-1 minh họa các lớp của tường lửa. Như hình bên dưới cho thấy,

các bức tường lửa được chia thành bốn thành phần riêng biệt.

Hình 1-1: Các lớp bảo mật tường lửa.

Tại trung tâm là các lớp toàn vẹn vật lý của tường lửa, mà chủ yếu là liên quan tới

các quyền truy cập vật lý vào tường lửa, để đảm bảo quyền truy cập vật lý vào thiết bị,

chẳng hạn như thông qua một kết nối cứng là cổng console.

Lớp tiếp theo là cấu hình tường lửa tĩnh, mà chủ yếu là liên quan tới truy cập vào

các phần mềm tường lửa được cấu hình tĩnh đang chạy (ví dụ, các hệ điều hành PIX và

cấu hình khởi động). Tại lớp này, chính sách bảo mật cần tập trung vào việc xác định


Truy cập vật lý

Truy cập quản trịNâng cấp phần mềmTập tin cấu hình

Các giao thức định tuyến

Truy cập vào mạng tường lửa bảo vệ

Toàn vẹn vật lý tường lửa

Cấu hình tường lửa tĩnh

Cấu hình tường lửa động

Lưu lượng mạng qua tường lửa

12

các hạn chế sẽ được yêu cầu để hạn chế truy cập quản trị, bao gồm cả bản cập nhật

phần mềm thực hiện và cấu hình tường lửa.

Lớp thứ ba là cấu hình tường lửa động, trong đó bổ sung các cấu hình tĩnh bằng

việc có liên quan tới cấu hình động của tường lửa thông qua việc sử dụng các công

nghệ như giao thức định tuyến, lệnh ARP, giao diện và tình trạng thiết bị, kiểm toán,

nhật ký, và các lệnh tránh. Mục tiêu của chính sách an ninh tại điểm này là để xác định

các yêu cầu xung quanh những gì các loại cấu hình động sẽ được cho phép.

Cuối cùng là lưu lượng mạng qua tường lửa, mà là thực sự những gì mà tường lửa

tồn tại để bảo vệ tài nguyên. Lớp này là có liên quan tới chức năng như ACL và thông

tin dịch vụ proxy. Các chính sách an ninh ở lớp này có trách nhiệm xác định các yêu

cầu như chúng liên quan đến lưu lượng đi qua tường lửa.

Định dạng chính sách an ninh:

Để thực hiện các mục tiêu được xác định trước đó, hầu hết các chính sách bảo mật

tuân theo một định dạng hoặc bố trí cụ thể và các chia sẻ yếu tố thông thường. Nói

chung, hầu hết các chính sách an ninh chia sẻ bảy phần:

Tổng quan: Phần tổng quan cung cấp một giải thích ngắn gọn về những địa chỉ

chính sách.

Mục đích: phần mục đích giải thích tại sao chính sách là cần thiết.

Phạm vi: Phần phạm vi xác định chính sách áp dụng cho những gì và xác định

người chịu trách nhiệm về chính sách.

Chính sách: phần chính sách là bản thân chính sách thực tế.

Thực thi: Phần thực thi định nghĩa cách chính sách cần được thực thi và các hậu

quả của việc không theo các chính sách.

Định nghĩa: Phần định nghĩa bao gồm các định nghĩa của các từ hoặc khái niệm

được sử dụng trong chính sách.

Xem lại lịch sử: Phần xem lại lịch sử là nơi mà các thay đổi chính sách được

ghi lại và theo dõi.

Mỗi tổ chức có yêu cầu an ninh riêng biệt và do đó có chính sách bảo mật riêng độc

đáo của họ. Tuy nhiên, hầu hết không phải tất cả các môi trường đòi hỏi một số chính

sách an ninh chung, bao gồm:


13

Chính sách quản lý truy cập

Chính sách lọc

Chính sách định tuyến

Chính sách Remote-access/VPN

Chính sách giám sát / ghi nhận

Chính sách vùng phi quân sự (DMZ)

Chính sách có thể áp dụng thông thường

3.2. Chính sách quản lý truy cập:

Chính sách quản lý truy cập tồn tại để xác định các phương pháp cho phép và cách

truy cập quản lý tường lửa. Chính sách này có xu hướng giải quyết sự toàn vẹn vật lý

tường lửa và lớp bảo mật cấu hình tường lửa tĩnh. Các chính sách quản lý truy cập cần

phải định nghĩa cho cả hai giao thức quản lý từ xa và cục bộ sẽ được cho phép, cũng

như đó người dùng có thể kết nối với tường lửa và có quyền truy cập để thực hiện

những tác vụ.

Ngoài ra, các chính sách quản lý truy cập cần xác định các yêu cầu đối với các giao

thức quản lý như Network Time Protocol (NTP), syslog, TFTP, FTP, Simple Network

Management Protocol (SNMP), và bất kỳ giao thức khác có thể được sử dụng để quản

lý và duy trì thiết bị.

3.3. Chính sách lọc:

Thay vì định nghĩa bộ quy tắc thực tế tường lửa sẽ sử dụng, các chính sách lọc cần

phải chỉ và xác định chính xác các loại lọc mà phải được sử dụng và nơi lọc được áp

dụng. Chính sách này có xu hướng để giải quyết cấu hình tường lửa tĩnh và chi tiết

trong lớp lưu lượng mạng qua tường lửa. Ví dụ, một chính sách lọc tốt cần phải yêu

cầu cả hai lối vào và đi ra bộ lọc được thực hiện với các bức tường lửa. Các chính sách

lọc cũng cần xác định các yêu cầu chung trong việc kết nối mạng cấp độ bảo mật và

nguồn khác nhau. Ví dụ, với một DMZ, tùy thuộc vào hướng của lưu lượng, các yêu

cầu lọc khác nhau có thể cần thiết, và nó là vai trò của các chính sách lọc để xác định

những yêu cầu.


14

3.4. Chính sách định tuyến:

Các chính sách định tuyến thường không phải là một tài liệu tường lửa trung tâm.

Tuy nhiên, với thiết kế chu vi phức tạp hơn cũng như sử dụng ngày càng tăng của các

bức tường lửa trong mạng nội bộ, tường lửa có thể dễ dàng trở thành một phần của cơ

sở hạ tầng định tuyến. Các chính sách định tuyến cần phải có một phần có quy định cụ

thể bao gồm một tường lửa trong các cơ sở hạ tầng định tuyến và định nghĩa các

phương thức trong đó các định tuyến sẽ xảy ra. Chính sách này có xu hướng để giải

quyết các lớp cấu hình tường tĩnh lửa và cấu hình động tường lửa. Trong hầu hết

trường hợp, các chính sách định tuyến nên ngăn cấm firewall một cách rõ ràng từ việc

chia sẻ bảng định tuyến mạng nội bộ với bất kỳ nguồn bên ngoài. Tương tự như vậy,

các chính sách định tuyến cần xác định các trường hợp trong đó các giao thức định

tuyến động và tuyến đường tĩnh là phù hợp. Các chính sách cũng nên xác định bất kỳ

cơ chế bảo mật giao thức cụ thể cần phải được cấu hình, (ví dụ, việc sử dụng thuật

toán băm để đảm bảo chỉ các nút được chứng thực có thể vượt qua dữ liệu định tuyến).

3.5. Chính sách Remote-access/VPN

Trong lĩnh vực hội tụ hiện nay, sự khác biệt giữa tường lửa và bộ tập trung VPN đã

ngày càng trở nên mờ nhạt. Hầu hết các thị trường tường lửa lớn có thể phục vụ như là

điểm kết thúc cho VPN, và do đó chính sách remote-access/VPN cần thiết xác định

các yêu cầu về mức độ mã hóa và xác thực rằng một kết nối VPN sẽ yêu cầu. Trong

nhiều trường hợp, các chính sách VPN kết hợp với chính sách mã hóa của tổ chức xác

định phương pháp VPN tổng thể sẽ được sử dụng. Chính sách này có xu hướng để giải

quyết các lớp cấu hình tường lửa tĩnh và lưu lượng mạng qua tường lửa.

Các chính sách remote-access/VPN cũng cần xác định các giao thức sẽ được sử

dụng: IP Security (IPsec), Layer 2 Tunneling Protocol (L2TP), hoặc Point-to-Point

Tunneling Protocol (PPTP). Trong hầu hết trường hợp, IPsec được sử dụng riêng biệt.

Giả sử IPsec, chính sách remote-access/VPN cần phải yêu cầu sử dụng của các

preshared keys, chứng thực mở rộng, với việc sử dụng giấy chứng nhận, mật khẩu một

lần, và Public Key Infrastructure (PKI) cho môi trường an toàn nhất. Tương tự như

vậy, các chính sách remote-access/VPN nên xác định những khách hàng sẽ được sử


15

dụng (có nghĩa là, trong xây dựng- Microsoft VPN Client, Cisco Secure VPN Client,

vv).

Cuối cùng, các chính sách remote-access/VPN cần xác định các loại truy cập và

các nguồn lực sẽ được cung cấp để kết nối từ xa và các loại kết nối từ xa sẽ được cho

phép.

3.6. Chính sách giám sát / ghi nhận:

Một trong những yếu tố quan trọng nhất đảm bảo rằng một tường lửa cung cấp

mức bảo mật được mong đợi là thực hiện một hệ thống giám sát tường lửa. Chính sách

giám sát / ghi nhận xác định các phương pháp và mức độ giám sát sẽ được thực hiện.

Tối thiểu, các chính sách giám sát / ghi nhận cần cung cấp một cơ chế để theo dõi hiệu

suất của tường lửa cũng như sự xuất hiện của tất cả các sự kiện liên quan đến an ninh

và các mục đăng nhập. Chính sách này có xu hướng để giải quyết các lớp cấu hình

tường lửa tĩnh.

Chính sách giám sát / ghi nhận cũng nên xác định cách các thông tin phải được thu

thập, duy trì, và báo cáo. Trong nhiều trường hợp, thông tin này có thể được sử dụng

để xác định các yêu cầu quản lý của bên thứ ba và các ứng dụng theo dõi như

CiscoWorks, NetIQ Security Manager, hoặc Kiwi Syslog Daemon.

3.7. Chính sách vùng DMZ:

Các chính sách DMZ là một văn bản diện rộng để xác định tất cả các yếu tố của

không chỉ chính DMZ mà còn các thiết bị trong DMZ. Mục tiêu của chính sách DMZ

là xác định các tiêu chuẩn và yêu cầu của tất cả các thiết bị và kết nối và lưu lượng

giao thông vì nó liên quan đến DMZ. Chính sách này có xu hướng để giải quyết các

lớp cấu hình tường lửa tĩnh và lưu lượng mạng qua tường lửa.

Do sự phức tạp của môi trường DMZ điển hình, các chính sách DMZ là có khả

năng sẽ là một tài liệu lớn nhiều trang. Để giúp đảm bảo rằng các chính sách DMZ

thiết thực và hiệu quả, điển hình là ba tiêu chuẩn cần được xác định rộng rãi cho tất cả

các thiết bị liên quan đến DMZ, kết nối, và lưu lượng giao thông:

Trách nhiệm quyền sở hữu

Yêu cầu cấu hình an toàn


16

Yêu cầu hoạt động và kiểm soát thay đổi

3.8. Chính sách có thể áp dụng thông thường:

Ngoài các chính sách tường lửa cụ thể, có nhiều chính sách có thể áp dụng thông

thường, mặc dù không phải là tường lửa cụ thể (đã ứng dụng trên nhiều thiết bị, không

chỉ là tường lửa) dù sao cũng nên được áp dụng đối với tường lửa. Chúng bao gồm

những điều sau đây:

Chính sách mật khẩu: chính sách mật khẩu của công ty nên được để cập đến không

chỉ xác định truy cập quản trị tường lửa, mà còn để sử dụng trong việc tạo ra preshared

secrets, bảng băm, và các chuỗi cộng đồng.

Chính sách mã hóa: chính sách mã hóa của công ty nên được đề cập đến để xác

định tất cả các hình thức truy cập mã hóa, bao gồm Hypertext Transfer Protocol,

Secure (HTTPS), Secure Sockets Layer (SSL), Secure Shell (SSH), và truy cập IPsec /

VPN.

Chính sách kiểm định: chính sách kiểm định của công ty phải được đề cập để xác

định các yêu cầu kiểm định của tường lửa.

Chính sách đánh giá rủi ro: chính sách đánh giá rủi ro của công ty cần được đề cập

để xác định phương pháp sẽ được sử dụng để xác định các rủi ro liên quan với hệ

thống tất cả thêm, di chuyển, và thay đổi vì nó liên quan đến tường lửa và chu vi mạng

trong toàn thể.

Dưới đây là một số công việc cần thiết cho người quản trị mạng:

Ghi nhận và xem lại nhật ký tường lửa thường xuyên.

Tạo ACL đi vào thật chi tiết, cụ thể.

Bảo vệ vùng DMZ về nhiều phía.

Thận trọng với lưu lượng ICMP.

Giữ mọi lưu lượng quản lý firewall được bảo mật.

Xem lại các quy tắc tường lửa định kỳ.


17

II. Radius

1. Tổng quan về Radius:

1.1. AAA:1.1.1. Xác thực (Authentication)

Xác thực là quá trình xác minh danh tính của một người (hoặc của máy tính). Hình

thức phổ biến nhất của xác thực, bằng cách sử dụng một sự kết hợp của ID đăng nhập

và mật khẩu, trong đó kiến thức của mật khẩu là một biểu tượng mà người dùng có xác

thực. Phân phối các mật khẩu, tuy nhiên, phá hủy các phương pháp xác thực, trong đó

nhắc nhở người sáng tạo của các trang web thương mại điện tử và kinh doanh giao

dịch Internet khác để yêu cầu một bộ xác thực mạnh mẽ hơn, đáng tin cậy hơn. Giấy

chứng nhận kỹ thuật số là một trong những giải pháp ở đây, và trong năm đến mười

năm tiếp theo để nó có thể là sử dụng giấy chứng nhận kỹ thuật số như là một phần

của cơ sở hạ tầng khoá công khai (PKI) sẽ trở thành bộ xác thực được ưa thích trên

Internet.

Các khía cạnh quan trọng của chứng thực là nó cho phép hai đối tượng duy nhất để

hình thành một mối quan hệ tin cậy - cả hai đều giả định là người dùng hợp lệ. Sự tin

tưởng giữa các hệ thống cho phép cho các chức năng quan trọng như các máy chủ

proxy, trong đó một hệ thống chấp nhận một yêu cầu thay mặt cho một hệ thống khác

và cho phép AAA thực thi nối các mạng không đồng nhất hỗ trợ các loại máy khách

và dịch vụ khác nhau. Mối quan hệ tin tưởng có thể trở nên khá phức tạp.

1.1.2. Ủy quyền (Authorization)

Ủy quyền liên quan đến việc sử dụng một bộ quy tắc hoặc các mẫu để quyết định

những gì một người sử dụng đã chứng thực có thể làm trên hệ thống. Ví dụ, trong

trường hợp của một nhà cung cấp dịch vụ Internet, nó có thể quyết định liệu một địa

chỉ IP tĩnh được cho là trái ngược với một địa chỉ DHCP được giao. Các quản trị hệ

thống định nghĩa những quy tắc này.

Cái gọi là "triển khai thông minh" của các máy chủ AAA có logic rằng sẽ phân tích

yêu cầu và cấp quyền truy cập bất cứ điều gì có thể, có hoặc không phải là toàn bộ yêu


18

cầu là hợp lệ. Ví dụ, một máy khách quay số kết nối và yêu cầu nhiều liên kết. Một

máy chủ AAA chung chỉ đơn giản là sẽ từ chối toàn bộ yêu cầu, nhưng một sự thực thi

thông minh hơn sẽ xem xét yêu cầu, xác định rằng máy khách chỉ được phép một kết

nối dial-up, và cấp một kênh trong khi từ chối các yêu cầu khác.

1.1.3. Kế toán (Accounting).

Làm tròn các khuôn khổ AAA là kế toán, mà các tài nguyên giới hạn và văn bản

người dùng tận dụng trong quá trình truy cập. Điều này có thể bao gồm số lượng thời

gian hệ thống hoặc số lượng dữ liệu người dùng đã gửi và/hoặc nhận được trong phiên.

Kế toán được thực hiện bởi ghi nhận thống kê của phiên và thông tin sử dụng và được

sử dụng để kiểm soát ủy quyền, thanh toán, phân tích xu hướng, sử dụng tài nguyên,

và năng lực lập kế hoạch hoạt động.

Dữ liệu kế toán đã sử dụng nhiều. Một quản trị viên có thể phân tích các yêu cầu

thành công để xác định năng lực và dự báo phụ tải hệ thống trong tương lai. Một chủ

doanh nghiệp có thể theo dõi thời gian dành cho các dịch vụ nhất định và hóa đơn cho

phù hợp. Một phân tích bảo mật có thể xem xét các yêu cầu từ chối, xem nếu một mẫu

xuất hiện, và có thể tránh một hacker hoặc người tải miễn phí. Các dữ liệu kế toán là

các tiện ích tuyệt vời cho một quản trị viên máy chủ AAA.

1.2 Các điểm chính của kiến trúc AAA:

Các kiến trúc AAA đơn giản là một cố gắng vạch ra một thiết kế như thế nào mỗi

phần AAA phù hợp với nhau. AAA triển khai thực hiện có thể đơn giản hay phức tạp

như nó cần, chủ yếu là do sự nỗ lực của nhóm chuyên nghiên cứu Internet (IRTF) làm

việc theo nhóm kiến trúc AAA để thực hiện một mô hình như ứng dụng trung lập như

có thể. Nói cách khác, mô hình AAA được thiết kế để làm việc trong môi trường có

yêu cầu người sử dụng khác nhau và đều thay đổi thiết kế mạng. Có một số thuộc tính

quan trọng của mô hình làm nó có thể thực hiện được.

Trước tiên, mô hình AAA phụ thuộc vào sự tương tác máy khách / máy chủ, trong

đó một hệ thống máy khách yêu cầu các dịch vụ hoặc tài nguyên của một hệ thống

máy chủ. Trong triển khai thực hiện đơn giản, những vai trò này thường kẹt - máy chủ


19

không bao giờ hoạt động như các máy khách và ngược lại. Môi trường máy khách /

máy chủ cho phép một thiết kế cân bằng tải tốt, trong đó tính sẵn sàng cao và thời gian

phản hồi rất quan trọng. Máy chủ có thể được phân phối và phân cấp giữa các mạng.

Tương phản này với mô hình mạng đối diện, một mạng ngang hàng (P2P). Với các

mạng P2P, tất cả các hệ thống hiển thị đặc tính của cả hai hệ thống máy khách và máy

chủ, có thể giới thiệu những điểm như độ trễ và chưa sẵn sàng xử lý.

Một khả năng proxy là một biến thể nhỏ về điều này. Một máy chủ AAA có thể

được cấu hình để ủy quyền cho một yêu cầu hoặc vượt qua nó cùng với một máy chủ

AAA, sau đó sẽ làm cho các quy định thích hợp hoặc vượt qua nó cùng một lần nữa.

Về bản chất, một chuỗi proxy được tạo ra, trong đó các máy chủ AAA có những yêu

cầu của cả máy khách và các máy chủ AAA khác. Khi một máy chủ proxy server

khác, người khởi tạo hiển thị các đặc tính của máy khách. Như vậy, một mối quan hệ

tin cậy đã được tạo ra cho mỗi bước truyền máy khách / máy chủ cho đến khi đạt yêu

cầu thiết bị quy định các nguồn lực cần thiết.

Proxy là một tính năng rất hữu ích của mô hình AAA và có lợi cho doanh nghiệp

và triển khai mạng lưới phân phối, trong đó một số thiết bị AAA có thể được cấu hình

để yêu cầu luôn ủy quyền cho các máy tại các địa điểm khác. Một ví dụ về ủy quyền

tốt nhất là với một thỏa thuận người bán lại ISP. Thường thì một công ty mạng lớn sẽ

đầu tư đáng kể cơ sở hạ tầng mạng và các điểm diễn ra sự hiện diện ở nhiều địa điểm.

Trang bị mạng lưới phân phối, công ty sau đó bán lại cho các ISP nhỏ hơn có nhu cầu

mở rộng phạm vi bảo hiểm của họ và tận dụng lợi thế của một mạng lưới tốt hơn. đại

lý bán lẻ có để cung cấp một số hình thức kiểm soát truy cập trên các nguồn tài nguyên

hữu hình ở mỗi vị trí, nhưng các ISP nhỏ hơn không muốn chia sẻ thông tin cá nhân về

người dùng của mình với các đại lý bán lẻ. Trong trường hợp này, một máy AAA

proxy được đặt tại mỗi điểm của đại lý bán lẻ của sự hiện diện, và những máy sau đó

giao tiếp với các thiết bị NAS thích hợp tại các ISP nhỏ hơn.

Máy khách yêu cầu dịch vụ và nguồn tài nguyên từ một máy chủ AAA (và trong

trường hợp này, máy khách có thể bao gồm AAA proxy) có thể giao tiếp với nhau

bằng cách sử dụng hoặc là một giao dịch hop-to-hop hoặc một giao dịch end-to-end.


20

Sự phân biệt là nơi mà các mối quan hệ tin cậy nằm trong chuỗi giao dịch. Xem xét

các trường hợp sau đây để có được một hình ảnh tốt hơn.

Trong một giao dịch hop-to-hop, một máy khách gửi một yêu cầu ban đầu cho một

thiết bị AAA. Tại thời điểm này, có một mối quan hệ tin cậy giữa máy khách và máy

chủ AAA tuyến đầu. Máy đó xác định yêu cầu cần phải được chuyển tiếp đến một máy

chủ khác ở một vị trí khác nhau, do đó, nó hoạt động như một proxy và địa chỉ liên lạc

một máy chủ AAA. Bây giờ các mối quan hệ tin tưởng là với hai máy chủ AAA, với

các máy tính tiền tuyến hoạt động như các máy khách và máy AAA thứ hai đóng vai

trò là máy chủ. Điều quan trọng cần lưu ý rằng mối quan hệ tin tưởng không phải là

vốn đã hiểu ngầm, có nghĩa là các máy khách ban đầu và các máy AAA thứ hai không

có một mối quan hệ tin tưởng. Hình 2-1 cho thấy sự tin tưởng là tuần tự và độc lập với

nhau.

HÌNH 2-1:MỐI QUAN HỆ TIN TƯỞNG ĐỘC LẬP TRONG MỘT GIAO DỊCH HOP-TO-HOP

Khác với mô hình hop-to-hop là phương pháp giao dịch end-to-end. Sự khác biệt

chính là, một lần nữa, nơi mà các mối quan hệ tin cậy nằm trong mô hình này, đó là

giữa máy khách yêu cầu và máy chủ AAA mà cuối cùng cho phép các yêu cầu. Trong

một mô hình end-to-end, chuỗi proxy vẫn còn rất nhiều chức năng như là mô hình


TRUSTTRUST

Máy chủ AAA phê duyệt

Mối quan hệ tin tưởng Mối quan hệ tin tưởng

Mối quan hệ tin tưởng

Máy chủ AAA cuốiMáy chủ AAA trung gian

Ở đây không có mối quan hệ tin tưởng nào giữa máy khách và máy chủ AAA trung gian và máy chủ AAA cuối

Máy khách

Yêu cầu Proxies Yêu cầu Proxies

21

không có nghĩa là các giao dịch end-to-end: đó là mối quan hệ tin tưởng. Bởi vì nó là

thiết kế không đáng kể để truyền thông tin nhạy cảm trong các yêu cầu proxy, một số

có ý nghĩa khác của chứng thực một yêu cầu và xác nhận tính toàn vẹn dữ liệu là cần

thiết khi nhảy yêu cầu ban đầu thông qua các bước nhảy trong chuỗi proxy. Thông

thường nhất, giấy chứng nhận kỹ thuật số và PKI xác nhận khác được sử dụng trong

các tình huống này. RFC 2903 và 2905 mô tả các yêu cầu của việc thực hiện an ninh

end-to-end, được thể hiện trong hình 2-2.

HÌNH 2-2:MỐI QUAN HỆ TIN TƯỞNG MÁY KHÁCH/MÁY CHỦ TRONG MÔ HÌNH END-TO-END

2. Kiến trúc RADIUS:

2.1. Sử dụng UDP hay TCP:

RADIUS đã chính thức được giao cổng UDP 1812 cho RADIUS Authentication và

1813 cho RADIUS Accounting bởi Internet Assigned Numbers Authority (IANA).

Tuy nhiên, trước khi IANA phân bổ các cổng 1812 và 1813, cổng 1645 và 1646 (xác

thực và kế toán tương ứng) đã được sử dụng không chính thức và trở thành các cổng

mặc định do nhiều máy chủ và máy khách RADIUS triển khai trong thời gian này.

Truyền thống của việc sử dụng 1645 và 1646 để tiếp tục tương thích ngược trở lại cho


TRUSTTRUST

Máy chủ AAA phê duyệt Máy chủ AAA cuốiMáy chủ AAA trung gian

Yêu cầu Proxies Yêu cầu Proxies

Không có mối quan hệ tin tưởng nào giữa các máy chủ Proxy

Mối quan hệ tin tưởngMáy khách

22

đến ngày nay. Vì lý do này nhiều máy chủ RADIUS triển khai giám sát cả hai bộ cổng

UDP cho các yêu cầu RADIUS. Các máy chủ RADIUS Microsoft mặc định 1812 và

1813 nhưng mặc định các thiết bị Cisco là cổng truyền thống1645 và 1646. Các máy

chủ RADIUS Juniper Networks lắng nghe trên cả hai cổng chính thức và không chính

thức 1645, 1812, 1646 và 1813 mặc định nhưng có thể được cấu hình với các cổng bất

kỳ.

Đối với yêu cầu hoạt động hoàn toàn, UDP được chọn chủ yếu bởi RADIUS có

một vài đặc tính cố hữu là đặc trưng của UDP: RADIUS yêu cầu không truy vấn tới

một máy chủ xác thực chính được chuyển hướng đến một máy chủ thứ cấp, và để làm

điều này, một bản sao của yêu cầu ban đầu phải tồn tại trên tầng giao vận trong mô

hình OSI. Điều này, có hiệu lực, nhiệm vụ sử dụng các bộ định giờ phát lại.

Các giao thức đặt cược vào sự kiên nhẫn của người dùng chờ đợi một phản ứng.

Nó giả định một số mặt trung bình giữa nhanh như chớp và chậm như mật đường. Các

RFC RADIUS mô tả là tốt nhất: "Tại một mức độ cao, RADIUS không đòi hỏi một"

đáp trả" phát hiện dữ liệu bị mất. Người sử dụng sẵn sàng chờ đợi vài giây cho việc

chứng thực hoàn thành. Phát lại TCP thường (dựa trên trung bình thời gian đi vòng)

không được yêu cầu, cũng không phải là các chi phí xác nhận của TCP. Ở mức độ cao

khác, người dùng không sẵn sàng chờ đợi vài phút để xác thực. Do đó việc cung cấp

đáng tin cậy của dữ liệu TCP hai phút sau đó không hữu ích. Việc sử dụng nhanh hơn

của máy chủ thay thế cho phép người dùng truy cập trước khi bỏ cuộc."

Kể từ khi RADIUS là không quốc tịch , UDP có vẻ tự nhiên, như UDP cũng là

không quốc tịch. Với TCP, máy và máy chủ phải có mã đặc biệt hoặc cách giải quyết

hành chính để giảm thiểu những ảnh hưởng của tổn thất điện năng, khởi động lại, lưu

lượng mạng lớn, và ngừng hoạt động của hệ thống. UDP ngăn ngừa được vấn đề hóc

búa này vì nó cho phép một phiên mở và vẫn mở trong suốt toàn bộ giao dịch.

Để cho phép hệ thống nặng nề sử dụng và giao thông trên mặt sau, mà đôi khi có

thể trì hoãn các truy vấn và tìm kiếm hơn 30 giây hoặc nhiều hơn, nó đã được xác định

rằng RADIUS là đa luồng. UDP cho phép RADIUS sản sinh để phục vụ nhiều yêu cầu

tại một thời điểm, và mỗi phiên đầy, khả năng giao tiếp không có giới hạn giữa các

thiết bị mạng và máy khách. Vì vậy, UDP là phù hợp.


23

Nhược điểm duy nhất khi sử dụng UDP là các nhà phát triển phải tự tạo và quản lý

giờ phát lại, khả năng này được xây dựng vào TCP. Tuy nhiên, nhóm RADIUS cảm

thấy rằng đây là một nhược điểm ít ảnh hưởng hơn so với sự tiện lợi và đơn giản của

việc sử dụng UDP. Và vì thế UDP được sử dụng.

2.2. Định dạng gói tin RADIUS:

Các giao thức RADIUS sử dụng gói tin UDP để vượt qua được truyền đi giữa máy

trạm và máy chủ. Giao thức giao tiếp trên cổng 1812, đó là một thay đổi từ tài liệu gốc

RFC RADIUS. Các phiên bản đầu tiên xác định rằng truyền thông RADIUS đã diễn ra

trên cổng 1645, nhưng sau này đã phát hiện xung đột với dịch vụ "Datametrics".

RADIUS sử dụng một cấu trúc gói tin có thể đoán trước để giao tiếp, được thể hiện

trong hình 2-3.

HÌNH 2-3:MỘT MÔ TẢ VỀ CẤU TRÚC GÓI TIN DỮ LIỆU RADIUSCấu trúc dự liệu được chia thành 5 khu vực riêng biệt:

Mã

Từ định danh

Độ dài

Bộ xác thực

Các thuộc tính và các giá trị

2.2.1. Mã:

Trường mã dài một octet và dùng để phân biệt các loại tin nhắn RADIUS được gửi

trong gói đó. Các gói tin với các lĩnh vực mã không hợp lệ được ném đi mà không

thông báo. Mã số hợp lệ là:

1 - Access-Request

2 - Access-Accept

3 - Access-Reject


Mã(1)

Từ định danh (1)

Độ dài(2)

Bộ xác thực(16)

Các thuộc tính và giá trị(Tùy biến)

24

4 - Accounting-Request

5 - Accounting-Response

11 - Access-Challenge

12 - Tình trạng máy chủ

13 - Tình trạng máy khách

255 - Dành riêng

2.2.2. Từ định danh:

Các từ định danh là khu vực dài 1 octet và được sử dụng để thực hiện luồng, hoặc

tự động liên kết các yêu cầu ban đầu và trả lời tiếp theo. Máy chủ RADIUS nói chung

có thể ngăn chặn bản sao tin nhắn bằng cách kiểm tra các yếu tố như địa chỉ IP nguồn,

cổng UDP nguồn, khoảng thời gian giữa các tin nhắn nghi ngờ, và các lĩnh vực nhận

dạng.

2.2.3. Độ dài:

Các khu vực có chiều dài là hai octet và được sử dụng để chỉ định độ dài gói tin

RADIUS được phép. Giá trị trong lĩnh vực này được tính bằng cách phân tích mã,

nhận dạng, chiều dài, thẩm định, và các lĩnh vực thuộc tính và việc tìm kiếm tổng hợp

của chúng. Các lĩnh vực được kiểm tra chiều dài khi một máy chủ RADIUS nhận được

một gói tin để đảm bảo toàn vẹn dữ liệu. Giá trị hợp lệ chiều dài khoảng từ 20 đến

4096.

Các đặc điểm kỹ thuật RFC đòi hỏi những hoạt động nhất định của các máy chủ

RADIUS có liên quan đến chiều dài dữ liệu không chính xác. Nếu máy chủ RADIUS

nhận được một hộp với một tin nhắn dài hơn so với lĩnh vực chiều dài, nó sẽ bỏ qua tất

cả các dữ liệu qua các điểm cuối được chỉ định trong lĩnh vực chiều dài. Ngược lại,

nếu máy chủ nhận được một tin nhắn ngắn hơn so với độ dài lĩnh vực báo cáo, máy

chủ sẽ loại bỏ các tin nhắn.

2.2.4. Bộ xác thực:


25

Các khu vực thẩm định, thường dài 16 octet, là lĩnh vực mà trong đó sự toàn vẹn

của tải trọng của tin nhắn được kiểm tra và xác minh. Trong lĩnh vực này, các octet

quan trọng nhất được truyền trước bất kỳ octet khác – một giá trị được sử dụng để trả

lời xác thực từ máy chủ RADIUS. Giá trị này cũng được sử dụng trong cơ chế để che

giấu mật khẩu.

Có hai loại hình cụ thể của các giá trị xác thực: các giá trị yêu cầu và đáp ứng. Yêu

cầu các bộ xác thực được sử dụng với các gói yêu cầu xác thực và Accounting-

Request. Trong các giá trị yêu cầu, lĩnh vực này dài 16 octet và được tạo ra trên cơ sở

hoàn toàn ngẫu nhiên để ngăn chặn bất kỳ cuộc tấn công. Trong khi RADIUS không

làm một điều khoản để bảo vệ thông tin liên lạc đối với nghe lén và bắt gói tin, các giá

trị ngẫu nhiên kết hợp với một mật khẩu mạnh làm cho tấn công và rình mò khó khăn.

Việc xác thực đáp trả được sử dụng trong gói Access-Accept, Access-Reject, và

Access-Challenge . Giá trị được tính bằng cách sử dụng mã băm MD5 một chiều được

tạo ra từ các giá trị của mã này, nhận dạng, chiều dài, và yêu cầu chứng thực các vùng

của tiêu đề gói tin, tiếp theo là trọng tải gói dữ liệu và bí mật được chia sẻ.

2.3. Phân loại gói tin:

Có bốn loại gói tin RADIUS có liên quan đến các giai đoạn thẩm định và ủy quyền

của các giao dịch AAA và hai gói tin liên quan tới quá trình kế toán:

Access-Request

Access-Accept

Access-Reject

Access-Challenge

Accounting-Request

Accounting-Response

2.3.1. Access-Request:

Các gói tin Access-Request được sử dụng bởi người tiêu dùng dịch vụ khi được đề

nghị một dịch vụ cụ thể từ mạng. Máy khách gửi một gói tin yêu cầu đến máy chủ

RADIUS với một danh sách các dịch vụ yêu cầu. Các yếu tố quan trọng trong việc


26

truyền này là trường mật mã trong tiêu đề gói: nó phải được đặt là 1, giá trị duy nhất

của các gói yêu cầu. Các RFC cho thấy các gói trả lời phải được gửi đến tất cả các gói

yêu cầu hợp lệ, trả lời là xác thực hay từ chối.

Các tải trọng của gói tin Access-Request nên bao gồm các thuộc tính tên người

dùng để xác định những người cố gắng truy cập vào các tài nguyên mạng. Trọng tải

được yêu cầu phải có các địa chỉ IP hoặc tên tiêu chuẩn của các thiết bị mạng mà từ đó

nó được yêu cầu dịch vụ. Nó cũng có chứa một mật khẩu người dùng, mật khẩu dựa

trên một CHAP, hoặc một định danh, nhưng không phải cả hai loại mật khẩu. Các mật

khẩu người dùng phải được băm bằng cách sử dụng MD5.

Về cơ bản, các gói dữ liệu mới cần phải được tạo ra bất cứ khi nào thuộc tính được

thay đổi, kể từ khi xác định các thông tin được thay đổi. Các thuộc tính với những bí

mật được chia sẻ, cần phải được đảo ngược bởi các máy chủ proxy (để có được những

thông tin tải trọng ban đầu) và sau đó mã hóa một lần nữa với bí mật mà máy chủ

proxy chia sẻ với máy chủ từ xa.

Cấu trúc gói tin Access-Request được thể hiện trong hình 2-4.

Hình 2-4: Một gói tin Access-Request điển hình

2.3.2. Access-Accept:

Các gói tin Access-Accept được gửi bởi máy chủ RADIUS tới máy khách để xác

nhận rằng yêu cầu của máy khách được chấp nhận. Nếu tất cả các yêu cầu trong các tải

trọng Access-Request được chấp nhận, sau đó các máy chủ RADIUS phải thiết lập

trường mật mã gói tin trả lời là 2. Các máy khách khi nhận được gói chấp nhận, phù

hợp nó với các gói tin trả lời bằng cách sử dụng trường nhận dạng. Các gói không theo

tiêu chuẩn này được bỏ đi.


Mã(1)

Từ định danh (Duy nhất)

Độ dài(Tiêu đề và tải trọng)

Bộ xác thực (Yêu cầu)(Ngẫu nhiên)

Các thuộc tính: username NAS ID hoặc name (Tùy biến)

MD5 user password hoặc CHAP PWD

27

Tất nhiên, để đảm bảo rằng các gói tin yêu cầu và chấp nhận phù hợp như đã nói,

để đảm bảo các đáp trả chấp nhận được gửi trong các gói tin trả lời yêu cầu tương ứng,

trường định danh trong tiêu đề gói Access-Accept phải có một giá trị giống hệt giá trị

của trường định danh trong gói Access-Request.

Các gói tin Access-Accept có thể chứa nhiều hay ít thông tin thuộc tính như là nó

cần phải bao gồm. Nhiều khả năng các thông tin thuộc tính trong gói này sẽ mô tả các

loại hình dịch vụ đã được xác thực và ủy quyền để máy khách có thể đặt mình lên để

sử dụng các dịch vụ. Tuy nhiên, nếu không có thông tin thuộc tính được bao gồm, máy

khách giả định rằng các dịch vụ nó yêu cầu là những thứ được chấp nhận.

Cấu trúc gói tin Access-Accept được hiển thị trong hình 2-5.

Hình 2-5: Gói tin Access-Accept điển hình

2.3.3. Access-Reject:

Máy chủ RADIUS được yêu cầu gửi một gói tin Access-Reject lại cho máy khách

nếu nó phải từ chối bất kỳ dịch vụ được yêu cầu trong các gói tin Access-Request. Sự

từ chối này có thể được dựa trên chính sách hệ thống, đặc quyền chưa đầy đủ, hoặc bất

kỳ các tiêu chuẩn khác - phần lớn điều này là một chức năng của các thực hiện cá

nhân. Gói Access-Reject có thể được gửi tại bất kỳ thời gian trong một phiên, làm cho

chúng lý tưởng cho việc thi hành giới hạn thời gian kết nối. Tuy nhiên, không phải tất

cả thiết bị hỗ trợ nhận được gói Access-Reject trong một kết nối được thiết lập sẵn.

Các tải trọng cho loại gói tin được giới hạn trong hai thuộc tính cụ thể: các thuộc

tính tin nhắn trả lời và thuộc tính trạng thái Proxy. Trong khi các thuộc tính này có thể

xuất hiện nhiều hơn một lần trong tải trọng của gói tin, ngoài trừ bất kỳ thuộc tính nhà


Mã(2)

Từ định danh (Duy nhất mỗi

lần truyền)


Bộ xác thực (Phản hồi)= Mã + ID + độ dài + bộ xác thực yêu cầu + thuộc tính và khóa bí mật

Các thuộc tính: Hoàn toàn không bắt buộc Các dịch vụ ủy quyền

(Tùy biến)

28

cung cấp cụ thể, không có các thuộc tính khác được cho phép, theo các đặc điểm kỹ

thuật RFC, để được bao gồm trong gói tin.

Cấu trúc gói tin Access-Reject được thể hiện trong hình 2-6.

Hình 2-6: Gói tin Access-Reject điển hình

2.3.4. Access-Challenge :

Nếu một máy chủ nhận thông tin trái ngược nhau từ người sử dụng, yêu cầu nhiều

thông tin hơn, hay đơn giản là muốn làm giảm nguy cơ chứng thực gian lận, nó có thể

phát hành một gói tin Access-Challenge cho máy khách. Máy khách, khi nhận được

gói tin Access-Challenge , sau đó phải ra một gói Access-Request mới bao gồm các

thông tin thích hợp.

Cần lưu ý rằng một số máy khách không hỗ trợ các quá trình thử thách / đáp ứng

như thế này, trong trường hợp đó, máy khách xử lý các gói tin Access-Challenge như

là một gói tin Access-Reject. Một số máy khách, tuy nhiên, hỗ trợ thử thách, và lúc đó

tin nhắn có thể được trao cho người sử dụng tại máy khách yêu cầu thêm thông tin xác

thực, nó không cần thiết trong tình hình đó đặt ra một vòng các gói tin yêu cầu / đáp

trả khác.

Giống như các gói tin Access-Reject, chỉ có hai thuộc tính tiêu chuẩn có thể được

bao gồm trong một gói tin Access-Challenge : thuộc tính trạng thái và tin nhắn trả lời.

Bất kỳ các thuộc tính nhà cung cấp cụ thể cần thiết có thể được bao gồm là tốt. Các

thuộc tính tin nhắn trả lời có thể được bao gồm trong gói nhiều lần, nhưng các thuộc

tính trạng thái được giới hạn trong một trường hợp duy nhất. Các thuộc tính trạng thái

được sao chép không thay đổi vào gói Access-Request được trả về cho máy chủ thử

thách.


Mã(3)


lần truyền)


Bộ xác thực (Phản hồi)= MD5(Mã + ID + độ dài + bộ xác thực yêu cầu + thuộc tính và khóa bí mật)

Các thuộc tính: Không bắt buộc Giới hạn: reply-messageProxy message (cả hai có thể xuất hiện nhiều lần)

(Tùy biến)

29

Cấu trúc gói tin Access-Challenge được thể hiện trong hình 2-7.

Hình 2-7: Gói tin Access-Challenge điển hình

2.3.5. Accounting-Request:

Các gói Accounting-Request được gửi từ một máy khách (thường là một máy chủ

truy cập mạng (NAS) hoặc proxy của nó) tới một máy chủ kế toán RADIUS, và truyền

đạt thông tin sử dụng để cung cấp kế toán cho một dịch vụ cung cấp cho người dùng.

Các máy khách truyền một gói tin RADIUS với trường mã thiết lập là 4 (Accounting-

Request).

Khi nhận được một Accounting-Request, máy chủ phải trả lời bằng gói

Accounting-Response nếu nó ghi lại các gói tin kế toán thành công, và không phải trả

lời bất kỳ gói nào nếu nó ghi lại các gói tin kế toán thất bại.

Bất kỳ thuộc tính hợp lệ trong một gói Access-Request hoặc Access-Accept

RADIUS là hợp lệ trong một gói Accounting-Request RADIUS, ngoại trừ các thuộc

tính sau đây không phải có mặt trong một Accounting-Request: mật khẩu người dùng,

mật khẩu CHAP, tin nhắn trả lời, trạng thái. Hoặc địa chỉ IP NAS hoặc nhận dạng

NAS phải được hiện diện trong một gói Accounting-Request RADIUS. Nó nên chứa

một thuộc tính cổng NAS hoặc loại cổng NAS hoặc cả hai trừ khi các dịch vụ không

liên quan đến một cổng hoặc NAS không phân biệt giữa các cổng của nó.

Nếu các gói tin Accounting-Request bao gồm một địa chỉ IP khung, thuộc tính đó

phải chứa địa chỉ IP của người dùng. Nếu Access-Accept sử dụng các giá trị đặc biệt

cho địa chỉ IP khung nói với NAS để chuyển nhượng hoặc thương lượng một địa chỉ

IP cho người dùng, các địa chỉ IP khung (nếu có) trong Accounting-Request phải có

các địa chỉ IP thực tế được giao hoặc thương lượng.


Mã(11)


lần truyền)


Bộ xác thực (Phản hồi)

Các thuộc tính: Không bắt buộc Giới hạn: stateReply-message (cả hai có thể gắn nhiều lần)(Tùy biến)

30

Hình 2-8: Gói tin Accounting-Request điển hình

Mã: 4 – Accounting-Request.

Định danh: Các trường nhận dạng phải được thay đổi bất cứ khi nào nội dung

của trường thuộc tính thay đổi, và bất cứ khi nào trả lời hợp lệ đã được nhận cho một

yêu cầu trước đó. Đối với việc truyền lại nơi mà nội dung giống hệt nhau, việc phải

nhận dạng không thay đổi.

Lưu ý rằng nếu Acct-Delay-Time được bao gồm trong các thuộc tính của một giá

trị Accounting-Request sau đó giá trị Acct-Delay-Time sẽ được cập nhật khi gói dữ

liệu được truyền lại, thay đổi nội dung của các trường thuộc tính và đòi hỏi một nhận

dạng mới và xác thực yêu cầu.

Xác thực yêu cầu: Các xác thực yêu cầu của một Accounting-Request chứa một

giá trị mảng băm MD5 16 octet tính theo phương pháp mô tả trong "Xác thực yêu cầu"

ở trên.

Thuộc tính: Các trường thuộc tính thay đổi trong chiều dài, và có một danh sách

các thuộc tính.

2.3.6. Accounting-Response:

Gói tin Accounting-Response được gửi bởi máy chủ kế toán RADIUS cho máy

khách để xác nhận rằng các Accounting-Request đã được nhận và ghi nhận thành

công. Nếu Accounting-Request đã được ghi lại thành công sau đó máy chủ kế toán

RADIUS phải chuyển một gói tin với các trường mã thiết lập là 5 (Accounting-

Response). Khi gói tin Accounting-Response được tiếp nhận bởi máy khách, trường

nhận dạng trùng khớp với một Accounting-Request chờ xử lý. Trường phải xác thực

phản hồi phải chứa các phản hồi chính xác cho các Accounting-Request chờ xử lý. Gói

tin không hợp lệ được âm thầm bỏ đi.


Mã(4)



Bộ xác thực (Yêu cầu)

Các thuộc tính: Chứa danh sách các thuộc tính (Tùy biến)

31

Một gói Accounting-Response RADIUS không bắt buộc phải có những thuộc tính

trong đó.

Hình 2-9: Gói tin Accounting-Response điển hình

Mã: 5 – Accounting-Response.

Định danh: Các trường nhận dạng là một bản sao của trường nhận dạng của gói

Accounting-Request đã dẫn đến gói Accounting-Response này.

Xác thực phản hồi: Các xác thực phản hồi của một gói Accounting-Response

chứa một giá trị mảng băm MD5 16 octet tính theo phương pháp mô tả trong "Xác

thực phản hồi" ở trên.

Thuộc tính: Các trường thuộc tính thay đổi trong chiều dài, và có một danh sách

trống hay nhiều thuộc tính.

2.4. Bí mật chia sẻ:

Để tăng cường an ninh và tăng tính toàn vẹn giao dịch, giao thức RADIUS sử dụng

khái niệm bí mật chia sẻ. Bí mật chia sẻ là những giá trị tạo ra một cách ngẫu nhiên mà

cả hai máy khách và máy chủ đều biết (vì thế mà gọi "chia sẻ"). Những bí mật chia sẻ

được sử dụng trong tất cả các hoạt động có yêu cầu dữ liệu ẩn và giá trị che giấu. Giới

hạn kỹ thuật duy nhất là những bí mật chia sẻ phải có chiều dài lớn hơn 0, nhưng RFC

khuyến cáo rằng các bí mật ít nhất là 16 octet. Một bí mật có độ dài đó là hầu như

không thể bẻ với phương pháp vét cạn.

Bí mật chia sẻ (thường chỉ gọi là "bí mật") là duy nhất với một cặp máy khách và

máy chủ RADIUS nói riêng. Ví dụ, nếu một người sử dụng đăng ký nhiều nhà cung

cấp dịch vụ Internet để truy cập quay số, người dùng này đã gián tiếp tạo các yêu cầu

tới nhiều máy chủ RADIUS. Những bí mật chia sẻ giữa thiết bị NAS máy khách tại


Mã(5)



Bộ xác thực (Phản hồi)

Các thuộc tính: Chứa hoặc không chứa danh sách các thuộc tính (Tùy biến)

32

các ISP A, B, và C được sử dụng để giao tiếp với các máy chủ RADIUS tương ứng

không phù hợp.

Trong khi một số triển khai RADIUS quy mô lớn hơn có thể tin rằng bảo vệ an

ninh giao dịch bằng cách sử dụng một sự thay đổi bí mật chia sẻ tự động là một bước

đi thận trọng, có một khó khăn tiềm ẩn khá lớn: không có sự bảo đảm các máy khách

và các máy chủ có thể đồng bộ hóa với các bí mật chia sẻ mới trong thời gian thích

hợp nhất. Và ngay cả khi nó đã được chắc chắn rằng các đồng bộ hóa đồng thời có thể

xảy ra, nếu còn tồn tại các yêu cầu tới các máy chủ RADIUS và máy khách đang bận

xử lý (và, do đó, nó bỏ lỡ thời cơ để đồng bộ hóa các bí mật mới), sau đó những yêu

cầu còn tồn tại sẽ bị từ chối bởi máy chủ.

2.5. Các thuộc tính và giá trị:2.5.1. Các thuộc tính:

Hình 2-10: Mẫu truyền các cặp giá trị thuộc tính (AVP) tiêu chuẩn

Số thuộc tính: Con số này biểu thị các loại thuộc tính trình bày trong gói. Tên

của thuộc tính không được thông qua trong gói - chỉ có số. Nói chung, số thuộc tính có

thể trong khoảng 1-255, với một số cụ thể phục vụ như là một "cửa ngõ" của các loại

cho các nhà cung cấp để cung cấp các thuộc tính cụ thể của mình.

Chiều dài thuộc tính: Trường này mô tả chiều dài của trường thuộc tính, mà cần

phải từ 3 trở lên. Trường này theo cách tương tự như các lĩnh vực chiều dài của tiêu đề

gói tin RADIUS.

Giá trị: Chứa đặc điểm hoặc đặc tính của chính thuộc tính đó, trường này cần

thiết cho mỗi thuộc tính trình bày, thậm chí nếu giá trị bản thân nó là bằng không. Độ

dài này sẽ thay đổi dựa trên bản chất vốn có của các thuộc tính của nó.


Số1-

255

Độ dài>3

Giá trịPhụ thuộc vào số thuộc tính

Các thuộc tính

Tiêu đề

Tải trọng AVP

Gói RADIUS

33

Cơ cấu AVP thể hiện trong hình 2-6 bao gồm một tập liên tục các byte chứa ít nhất

ba octet, với các octet đầu tiên là loại, thứ hai là chiều dài, và octet cuối cùng là giá trị

của các thuộc tính của chính nó.

Các máy chủ RADIUS biết đầy đủ về một thuộc tính có tên gọi chính thức của nó

không cần được truyền đi trong gói. Các mã số (số thuộc tính) là đủ để suy ra loại

thông tin được truyền đi trong giá trị cụ thể đó.

Các loại thuộc tính:

Có 6 loại như được nêu trong RFC:

Số nguyên (INT): là những giá trị có chứa số nguyên. Một thuộc tính như Idle

Timeout có thể được thiết lập giá trị số nguyên là 15.

Liệt kê (ENUM): dữ liệu đó là của các loại liệt kê bao gồm một số nguyên, nhưng

giá trị này dựa trên một tập hợp cấu hình người sử dụng của dãy nhiều giá trị và nhiều

ý nghĩa. Có thể gặp phải các giá trị liệt kê được gọi là giá trị số nguyên theo ngữ nghĩa,

trong khi không theo ngữ nghĩa giá trị nguyên chỉ đơn giản là loại số nguyên.

Địa chỉ IP (IPADDR): loại dữ liệu này là một số 32-bit được thiết kế để thông qua

một địa chỉ IP chính xác. Trong khi RADIUS theo mặc định sẽ xem xét một địa chỉ IP

theo giá trị, một số triển khai thực hiện có thể được cấu hình để xử lý nó với một giá

trị định sẵn, chẳng hạn như một subnet mask riêng. Ngoài ra, một phần mở rộng gần

đây để các giao thức RADIUS cho phép các địa chỉ IPv6 được sử dụng trong loại này.

Chuỗi ký tự (STRING): Chuỗi ký tự thường được xác định là chuỗi in UTF-8 có

thể được đọc theo giá trị. Dữ liệu được truyền dưới dạng một dãy ký tự có thể bị chặn

hay không bị chặn, bất cứ cái nào là thích hợp.

Ngày tháng (DATE): là một con số không dấu 32-bit đại diện cho giây trôi qua kể

từ ngày 1 tháng 1 năm 1970.

Nhị phân (BINARY): Thường riêng biệt với một sự thực thi, các giá trị nhị phân

("0" hoặc "1") được đọc theo giá trị.

Các thuộc tính nhà cung cấp cụ thể:

Như với hầu hết các giao thức RADIUS, có nhiều sự linh hoạt đối với các loại

thuộc tính nhà cung cấp cụ thể xảy ra trong nhiều thực hiện khác nhau. Phần lớn thuộc

tính này tạo ra là để trực tiếp hỗ trợ các tính năng đặc biệt, các đặc trưng không chuẩn


34

hoặc gia tăng giá trị mà một số thiết bị máy khách RADIUS đặc biệt có khả năng cung

cấp. Tất nhiên, có lẽ bởi vì trong thực tế là một tiêu chuẩn, một số nhà cung cấp - đặc

biệt là Robotics/3Com Hoa Kỳ - không theo đặc tả RFC.

Các giao thức RADIUS định nghĩa một AVP cụ thể như là một "cửa ngõ" AVP

trong đó các thuộc tính nhà cung cấp cụ thể, hoặc VSAs, có thể được đóng gói. VSA

được thực hiện ở tải trọng giá trị của AVP tiêu chuẩn 26, được gọi là nhà cung cấp cụ

thể. Hình 2-11 cho thấy AVP tiêu chuẩn và làm thế nào thông tin được thực hiện trong

VSA.

Hình 2-11: Sự truyền đi của 1 VAS bên trong 1 AVP tiêu chuẩn.

ID nhà cung cấp

Phần này của VSA gồm bốn octet mà đại diện cho nhà phát triển / thiết kế / chủ sở

hữu của VSA. Những mã số tiêu chuẩn được quy định trong tài liệu RFC 1700 là "Các

số được gán”. Cụ thể hơn, các nhà cung cấp cá nhân được mã hoá với con số duy nhất

được gọi là mã doanh nghiệp tư nhân quản lý mạng hoặc NMPECs.

Thứ tự của các nội dung trường ID nhà cung cấp được dựa trên một tiêu chuẩn

nghiêm ngặt, với byte cao nhất để giá trị 4 octet được thiết lập về 0, và sau đó 3 byte

cuối cùng đặt vào mã NMPEC.

Loại nhà cung cấp

Trường loại nhà cung cấp, dài một octet, chức năng hành xử theo cách tương tự

như số thuộc tính trong một AVP tiêu chuẩn. Các loại nhà cung cấp là những giá trị

với phạm vi từ 1 đến 255, và tầm quan trọng và ý nghĩa của từng giá trị được biết đến

bên trong các máy chủ RADIUS.

Chiều dài


Số26

Độ dàiX

Giá trị

ID262

Số47

Độ dàiX

Giá trị… VAS bên trong

tải trọng

Tải trọng gói RADIUS

35

Trường này là một con số một octet cho biết chiều dài của toàn bộ VSA, với chiều

dài tối thiểu của toàn bộ VSA là 7. Một lần nữa, hoạt động của trường này là tương tự

như lĩnh vực chiều dài trong một tiêu chuẩn, RFC định nghĩa AVP.

Giá trị

Các trường giá trị được yêu cầu phải dài ít nhất một octet và chứa dữ liệu được cụ

thể cho các chính VSA đó. Hầu hết các giá trị này được đọc, hiểu, và phân tích bởi

máy khách và máy chủ RADIUS trên đầu thu nhận thức của các tính năng đặc biệt và

khả năng phi tiêu chuẩn mà triển khai thực hiện cụ thể của chúng có hỗ trợ.

2.5.2. Các giá trị:

Tất cả các thuộc tính phải có giá trị, thậm chí nếu giá trị của thuộc tính này là vô

giá trị. Giá trị đại diện cho các thông tin mà mỗi thuộc tính riêng biệt được thiết kế để

chuyển tải. Chúng mang theo "phần cốt lõi" của thông tin. Giá trị phải phù hợp với các

quy tắc loại thuộc tính. Bảng 2-8 cho thấy ví dụ của từng loại thuộc tính và trường giá

trị dự kiến tải trọng cho từng loại.

Loại thuộc

tính

Chiều dài

(Octet)

Kích thước /

Phạm vi

Ví dụ tải trọng

Số nguyên

(INT)

4 32 bit

Không dấu

6

256

2432

65536

Liệt kê

(ENUM)

4 32 bit

Không dấu

3 = Callback-Login

4 = Callback-Framed

13 = Framed-

Compression

26 = Vendor-Specific

Chuỗi

(String)

1-253 Tùy biến

"HUTECH"

"Long"

"206.229.254.2"


36

"google.com"

Địa chỉ IP

(IPADDR)

4 32 bit

0xFFFFFE

0xC0A80102

0x1954FF8E

0x00000A

Ngày tháng

(DATE)

4 32 bit

Không dấu

0xC0A80102

0xFFFFFE

0x00000A

0x1954FF8E

Nhị phân

(BINARY)

1 1 bit 0

1

Mỗi thuộc tính giá trị được liệt kê trong RFC RADIUS.

3. Hoạt động:

3.1. Quá trính truy cập:

Khi một máy khách được cấu hình để sử dụng RADIUS, bất kỳ người sử dụng của

máy khách đưa ra thông tin xác thực cho máy khách. Điều này có thể được tùy biến

với một đăng nhập nhanh chóng, nơi người dùng sẽ nhập tên người dùng và mật khẩu

của họ. Máy khách tạo ra một "Access-Request" có chứa các thuộc tính như tên của

người dùng, mật khẩu của người dùng, các ID của máy khách và ID cổng mà người

dùng đang truy cập. Khi có mật khẩu, nó được ẩn bằng cách sử dụng một phương pháp

dựa trên MD5.

Các Access-Request được gửi tới máy chủ RADIUS qua mạng. Nếu không có phản

hồi được trả về trong một khoảng thời gian, yêu cầu được gửi lại một số lần. Các máy

khách cũng có thể chuyển tiếp yêu cầu tới một máy chủ thay thế hoặc các máy chủ

trong trường hợp máy chủ chính bị ngừng hoạt động hoặc không thể truy cập. Một

máy chủ thay thế có thể được sử dụng hoặc sau khi một số cố gắng truy cập tới các

máy chủ chính bị lỗi, hoặc trong một kiểu vận hành lần lượt.


37

Một khi các máy chủ RADIUS nhận được yêu cầu, nó xác nhận hợp lệ của máy

khách gửi. Một yêu cầu từ máy khách mà các máy chủ RADIUS không có một bí mật

được chia sẻ phải được âm thầm bỏ đi. Nếu máy khách là hợp lệ, máy chủ RADIUS

tra cứu một cơ sở dữ liệu của người dùng để tìm người sử dụng có tên phù hợp với yêu

cầu. Mục người sử dụng trong cơ sở dữ liệu chứa một danh sách các yêu cầu đó phải

được đáp ứng để cho phép người sử dụng truy cập. Điều này luôn luôn bao gồm xác

minh mật khẩu, nhưng cũng có thể chỉ định các máy khách hoặc cổng mà người dùng

được phép truy cập.

Máy chủ RADIUS có thể làm cho yêu cầu của các máy chủ khác đáp ứng các yêu

cầu, trong trường hợp nó hoạt động như một máy khách.

Nếu bất kỳ thuộc tính Proxy-State được đưa ratrong các Access-Request, chúng

phải được sao chép chưa sửa đổi và đặt vào các gói tin trả lời. Các thuộc tính khác có

thể được đặt trước, sau, hoặc thậm chí giữa các thuộc tính Proxy-State.

Nếu điều kiện nào không được đáp ứng, máy chủ RADIUS gửi một phản hồi

"Access-Reject" cho biết yêu cầu người sử dụng này không hợp lệ. Nếu muốn, các

máy chủ có thể bao gồm các tin nhắn văn bản trong Access-Reject có thể được hiển thị

bởi các máy khách cho người dùng. Không có thuộc tính khác (trừ Proxy-State) được

phép trong một Access-Reject.

Nếu tất cả các điều kiện được đáp ứng và các máy chủ RADIUS muốn ra một

thách thức mà người dùng phải đáp ứng, các máy chủ RADIUS gửi một phản hồi

"Access-Challenge". Nó có thể bao gồm các tin nhắn văn bản được hiển thị bởi các

máy khách cho người sử dụng phản hồi cho thách thức này, và có thể bao gồm một

thuộc tính trạng thái.

Nếu máy khách nhận được một Access-Challenge và hỗ trợ thách thức / phản ứng

nó có thể hiển thị các tin nhắn văn bản, nếu có, cho người sử dụng, và sau đó nhắc nhở

người dùng về một phản hồi. Máy khách sau đó nộp lại bản gốc Access-Request của

nó với một ID yêu cầu mới, với các thuộc tính người dùng mật khẩu thay thế bằng các

phản hồi (đã mã hóa), và bao gồm cả các thuộc tính trạng thái từ các Access-

Challenge, nếu có. Chỉ có 0 hoặc 1 thể hiện của thuộc tính trạng thái có mặt trong yêu


38

cầu. Máy chủ có thể đáp ứng với Access-Request mới này với một Access-Accept,

một Access-Reject, hoặc một Access-Challenge khác.

Nếu có đủ điều kiện, danh sách các giá trị cấu hình cho người sử dụng được đặt

vào một phản hồi "Access-Accept". Những giá trị này bao gồm các loại hình dịch vụ

(ví dụ: SLIP, PPP, người dùng đăng nhập) và tất cả các giá trị cần thiết để cung cấp

các dịch vụ mong muốn. Đối với SLIP và PPP, điều này có thể bao gồm giá trị như địa

chỉ IP, subnet mask, MTU, nén mong muốn, và nhận dạng lọc gói mong muốn. Đối

với những người dùng chế độ ký tự, điều này có thể bao gồm giá trị như giao thức và

máy chủ mong muốn.

Trong xác thực thách thức / phản hồi, người sử dụng được cho một số không thể

đoán trước và thách thức để mã hóa nó và trả lại kết quả. Người được ủy quyền đều

được trang bị các thiết bị đặc biệt như thẻ thông minh hoặc các phần mềm tạo thuận

lợi cho tính toán của các phản hồi chính xác một cách dễ dàng. Người sử dụng trái

phép, thiếu thiết bị thích hợp hoặc phần mềm và không biết khóa bí mật cần thiết để

cạnh tranh như một thiết bị hoặc phần mềm, chỉ có thể đoán phản hồi.

Các gói tin Access-Challenge thường có chứa một tin nhắn trả lời bao gồm một

thách thức để được hiển thị cho người dùng, chẳng hạn như một giá trị số không bao

giờ được lặp lại.

Người sử dụng sau đó đi vào các thách thức trong thiết bị của mình (hoặc phần

mềm) và tính toán một phản hồi, người dùng nhập vào máy khách rồi máy đó chuyển

tiếp nó tới máy chủ RADIUS thông qua một Access-Request thứ hai. Nếu phản hồi

trùng khớp với phản hồi mong muốn máy chủ RADIUS trả lời với một Access-Accept,

nếu không một Access-Reject sẽ được trả về máy khách.

Hình 2-12: Quá trình xác thực RADIUS đơn giản.

1) Người dùng cố gắng truy cập vào Cisco ASA.


4

56

12

3

ASA Máy chủ Radius ACS Người dùng

39

2) Cisco ASA yêu cầu người dùng nhập tên và mật khẩu.

3) Người dùng nhập vào thông số của mình và gửi cho cisco ASA.

4) Cisco ASA gửi gói Access-Request tới máy chủ RADIUS.

5) Nếu thông số người dùng nhập có trong cơ sở dữ liệu tại máy chủ

RADIUS, máy chủ RADIUS sẽ gửi gói Access-Accept về cho Cisco ASA, nếu

thông số người dùng nhập không có thì máy chủ RADIUS sẽ gửi gói Access-Reject về

cho cisco ASA.

6) Cisco ASA sẽ phản hồi về cho máy khách biết được phép hay không được phép

truy cập vào 1 dịch vụ cụ thể.

3.2. Quá trình kế toán:

Khi một máy khách được cấu hình để sử dụng RADIUS kế toán, khi bắt đầu cung

cấp dịch vụ nó sẽ tạo ra một gói tin bắt đầu kế toán mô tả các loại hình dịch vụ được

cung cấp và người sử dụng nó đang được chuyển tới, và sẽ gửi tới máy chủ kế toán

RADIUS, trong đó sẽ gửi lại một xác nhận rằng gói tin đã được nhận. Khi kết thúc

cung cấp dịch vụ máy khách sẽ tạo ra một gói kết thúc kế toán mô tả các loại hình dịch

vụ đã được giao và thông số tùy ý như là thời gian trôi qua, octet vào và ra, hoặc các

gói dữ liệu vào và ra. Nó sẽ gửi tới máy chủ kế toán RADIUS, và sẽ gửi phản hồi một

xác nhận rằng gói tin đã được nhận.

Accounting-Request (dù cho bắt đầu hoặc kết thúc) được gửi tới máy chủ kế toán

RADIUS qua mạng. Nó khuyến cáo các khách hàng tiếp tục cố gắng gửi gói tin

Accounting-Request cho đến khi nhận được một xác nhận, bằng cách sử dụng một số

hình thức chờ để truyền. Nếu không có phản hồi được trả về trong một khoảng thời

gian, yêu cầu được gửi lại một số lần. Máy khách cũng có thể chuyển tiếp yêu cầu tới

một máy chủ thay thế hoặc các máy chủ trong trường hợp máy chủ chính ngừng hoạt

động hoặc không thể truy cập. Một máy chủ thay thế có thể được sử dụng hoặc sau khi

một số cố gắng đến các máy chủ chính bị lỗi, hoặc trong một kiểu vận hành lần lượt.

Máy chủ kế toán RADIUS có thể làm cho yêu cầu của các máy chủ khác đáp ứng

các yêu cầu, trong trường hợp nó hoạt động như một máy khách.


40

Nếu máy chủ kế toán RADIUS không thể thành công ghi lại các gói tin kế toán, nó

không phải gửi một xác nhận Accounting-Response cho máy khách.

4. RFCs:

4.1. Nguồn gốc:

RADIUS ban đầu được quy định trong một RFI bởi Merit Network vào năm 1991

để kiểm soát truy cập quay số tới NSFNET. Livingston Enterprises trả lời cho RFI với

mô tả của một máy chủ RADIUS. Merit Network quyết định liện hệ với Livingston

Enterprises giao hàng loạt PortMaster của các Network Access Server và máy chủ

RADIUS ban đầu cho Merit. RADIUS sau đó (1997) được xuất bản như RFC 2058 và

RFC 2059 (phiên bản hiện tại là RFC 2865 và RFC 2866).

Bây giờ, tồn tại một số máy chủ RADIUS thương mại và mã nguồn mở. Các tính

năng có thể khác nhau, nhưng hầu hết có thể thấy sử dụng trong các tập tin văn bản,

máy chủ LDAP, cơ sở dữ liệu khác nhau... Tài liệu kế toán có thể được ghi vào tập tin

văn bản, cơ sở dữ liệu khác nhau, chuyển tiếp đến máy chủ bên ngoài... SNMP thường

được sử dụng để giám sát từ xa và kiểm tra xem một máy chủ RADIUS còn hoạt động

hay không. Các máy chủ RADIUS proxy được sử dụng để tập trung quản lý và có thể

viết lại các gói tin RADIUS (đối với lý do bảo mật, hoặc để Chuyển đổi giữa các nhà

cung cấp).

Các giao thức Diameter là kế hoạch thay thế cho RADIUS. Diameter sử dụng

SCTP hoặc TCP trong khi RADIUS sử dụng UDP là lớp vận chuyển.

4.2. Bảng RFCs:

RFC Tiêu đề Ngày

RFC

2548

Microsoft Vendor-specific RADIUS Attributes 3/199

9

RFC

2865

Remote Authentication Dial In User Service (RADIUS) 6/200

0

RFC RADIUS Accounting 6/200GVHD: THS Nguyễn Đức Quang SVTH:Nguyễn Đắc Nguyên Long MSSV:106102078 Lê Hoàng Long MSSV:106102079

41

2866 0

RFC

2867

RADIUS Accounting Modifications for Tunnel Protocol

Support

6/200

0

RFC

2868

RADIUS Attributes for Tunnel Protocol Support 6/200

0

RFC

2869

RADIUS Extensions 6/200

0

RFC

3162

RADIUS and IPv6 8/200

1

RFC

3579

RADIUS Support for EAP 9/200

3

RFC

5080

Common RADIUS Implementation Issues and Suggested

Fixes

12/20

07

RFC

5997

Use of Status-Server Packets in the RADIUS Protocol 8/201

0

4.3. Sơ lược về RADIUS RFCs:

4.3.1. RFC 2865:

RFC 2865 – Remote Authentication Dial In User Service: chủ yếu mô tả về cơ chế

xác thực và ủy quyền khi người dùng muốn truy cập.

Trong RFC có giới thiệu cấu trúc các gói tin cần dùng để thực hiện xác thực và ủy

quyền cho người dùng truy cập và các thuộc tính dùng để mô tả trong các gói tin.

Đồng thời cũng trình bày về cơ chế hoạt động và các trường hợp xảy ra khi người

dùng muốn truy cập.

Một số thay đổi so với bản RFC 2138 trước đó:

Strings nên sử dụng UTF-8 thay vì US-ASCII và nên được xử lý như là dữ liệu

8-bit.

Integers và dates bây giờ được xác định là giá trị 32 bit không dấu.

Danh sách cập nhật các thuộc tính có thể được bao gồm trong Access-

Challenge để phù hợp với các bảng thuộc tính.


42

User-Name đề cập đến các nhận dạng truy cập mạng.

User-Name bây giờ có thể được gửi trong Access-Accept để sử dụng với kế

toán và đăng nhập từ xa.

Giá trị them vào cho Service-Type, Login-Service, Framed-Protocol, Framed-

Compression, và NAS-Port-Type.

NAS-Port có thể sử dụng tất cả 32 bit.

Các ví dụ hiện nay bao gồm hiển thị hệ thập lục phân của các gói dữ liệu.

Cổng UDP nguồn phải được sử dụng kết hợp với bộ nhận dạng yêu cầu khi xác

định các bản sao.

Nhiều thuộc tính phục có thể được cho phép trong thuộc tính Vendor-Specific.

Một Access-Request bây giờ yêu cầu chứa NAS-IP-Address hoặc NAS-

Identifier (hoặc có thể chứa cả hai).

Thêm ghi chú dưới "Operations" với nhiều thông tin hơn về proxy, truyền lại,

và duy trì kết nối.

Nếu nhiều thuộc tính với các loại tương tự có mặt đồng thời, thứ tự các thuộc

tính cùng loại phải được duy trì bởi bất kỳ proxy nào.

Làm rõ Proxy-State.

Làm rõ các thuộc tính không phải phụ thuộc vào vị trí trong gói tin, miễn là

thuộc tính của các loại tương tự đang được giữ theo thứ tự.

Thêm vào phần lời khuyên của IANA.

Cập nhật phần "Proxy" trong "Operations".

Framed-MTU có thể được gửi trong Access-Request như là một gợi ý.

Cập nhật lời khuyên bảo mật.

Các chuỗi văn bản xác định như là một tập hợp con của chuỗi, để làm rõ việc sử

dụng UTF-8.

4.3.2. RFC 2866:

RFC 2866 - RADIUS Accounting: mô tả về quá trình kế toán cho máy chủ

RADIUSvà là bản cập nhật cho RFC 2865.


43

Cũng như RFC 2865, RFC 2866 cũng giới thiệu về các gói tin được dùng trong quá

trình kế toán và các thuộc tính trong các gói tin đó và cũng mô tả về quá trình kế toán

được diễn ra khi có yêu cầu thực hiện kế toán.

Một số thay đổi so với RFC 2139:

Thay thế US-ASCII bằng UTF-8.

Thêm ghi chú trong Proxy.

Framed-IP-Address nên chứa địa chỉ IP thực tế của người sử dụng.

Nếu Acct-Session-ID đã được gửi trong một Access-Request, nó phải được sử

dụng trong Accounting-Request cho phiên giao dịch đó.

Các giá trị mới được thêm vào Acct-Status-Type.

Thêm vào phần lời khuyên của IANA.

Cập nhật tài liệu tham khảo.

Các chuỗi văn bản xác định như là một tập hợp con của chuỗi, để làm rõ việc sử

dụng UTF-8.

4.3.3. RFC 2867:

RFC 2867 - RADIUS Accounting Modifications for Tunnel Protocol Support: mô

tả về việc cải biến cơ chế RADIUS Accounting để hổ trợ cho giao thức đường hầm,

cập nhật thêm cho RFC 2866.

Nhiều ứng dụng giao thức đường hầm như là PPTP và L2TP bao hàm truy cập

mạng quay số. Một số, như là việc cung cấp truy cập an toàn cho mạng nội bộ công ty

thông qua mạng Internet, được đặc trưng bởi đường hầm chủ động: đường hầm được

tạo ra theo yêu cầu của người sử dụng cho một mục đích cụ thể. Các ứng dụng khác

gồm các đường hầm bắt buộc: đường hầm được tạo ra mà không có bất kỳ hành động

từ người sử dụng và không có bất kỳ sự lựa chọn cho phép người dùng trong vấn đề

này, như một dịch vụ của nhà cung cấp dịch vụ Internet (ISP). Thông thường, các ISP

cung cấp một dịch vụ muốn thu thập dữ liệu về để thanh toán, quy hoạch mạng... Một

cách để thu thập dữ liệu sử dụng trong các mạng quay số là dùng phương tiện

RADIUS Accounting. Việc sử dụng RADIUS Accounting cho phép dữ liệu sử dụng

quay số được thu thập tại một vị trí trung tâm, hơn là được lưu trữ tại mỗi NAS.


44

Để thu thập dữ liệu sử dụng về đường hầm, thuộc tính RADIUS mới là cần thiết,

tài liệu này xác định những thuộc tính này. Ngoài ra, một số giá trị mới cho các thuộc

tính Acct-Status-Type được đề xuất. Kiến nghị cụ thể và ví dụ về việc áp dụng các

thuộc tính này cho giao thức L2TP được mô tả trong RFC 2809.

Các giá trị Acct-Status-Type mới:

Tunnel-Start: giá trị là 9, dùng để đánh dấu việc tạo một đường hầm mới với

nút khác.

Tunnel-Stop: giá trị là 10, , dùng để đánh dấu việc hủy một đường hầm từ hoặc

tới nút khác.

Tunnel-Reject: giá trị là 11, , dùng để đánh dấu việc từ chối tạo một đường hầm

với nút khác.

Tunnel-Link-Start: giá trị là 12, dùng để đánh dấu sự tạo thành của một liên kết

đường hầm.

Tunnel-Link-Stop: giá trị là 13, dùng để đánh dấu sự phá hủy một lien kết

đường hầm.

Tunnel-Link-Reject: giá trị là 14, dùng để đánh dấu việc từ chối tạo nên một

liên kết mới trong một đường hầm đang tồn tại.

Và 2 thuộc tính mới:

Acct-Tunnel-Connection: Thuộc tính này có thể được sử dụng để cung cấp một

phương tiện để nhận diện ra một phiên đường hầm cho mục đích kiểm toán.

Acct-Tunnel-Packets-Lost: Thuộc tính này chỉ ra số gói dữ liệu bị mất trên một

liên kết được đưa.

4.3.4. RFC 2868:

RFC 2868 - RADIUS Attributes for Tunnel Protocol Support: mô tả các thuộc tính

RADIUS hỗ trợ cho giao thức đường ống, cập nhật them cho RFC 2865.

Các thuộc tính RADIUS mới là cần thiết để chuyển các thông tin đường hầm từ

máy chủ RADIUS tới điểm cuối của đường hầm.

Các thuộc tính mới:


45

Tunnel-Type: Thuộc tính này chỉ ra giao thức đường hầm sẽ được sử dụng

hoặc các giao thức đường hầm đang được sử dụng.

Tunnel-Medium-Type: Thuộc tính này chỉ ra phương tiện được sử dụng để tạo

đường hầm theo các giao thức (như là L2TP), điều này có thể có tác dụng trên nhiều

phương tiện vận chuyển.

Tunnel-Client-Endpoint: Thuộc tính này chứa địa chỉ của người khởi xướng

cuối của đường hầm.

Tunnel-Server-Endpoint: Thuộc tính này chứa địa chỉ của máy chủ cuối của

đường hầm.

Tunnel-Password: Thuộc tính này chứa mật khẩu dùng để xác thực tới máy chủ

truy cập từ xa.

Tunnel-Private-Group-ID: Thuộc tính này chỉ ra ID nhóm cho một phiên hầm

cụ thể.

Tunnel-Assignment-ID: Thuộc tính này được sử dụng để chỉ ra người khởi

xướng đường hầm một đường hầm cụ thể để phân công một phiên.

Tunnel-Preference: Khi máy chủ RADIUS gởi trả nhiều hơn một bộ thuộc tính

đường hầm về cho người khởi xướng đường hầm, thuộc tính này được gán vào trong

mỗi bộ thuộc tính đường hầm để thiết lập độ ưu tiên cho mỗi đường hầm.

Tunnel-Client-Auth-ID: Thuộc tính này ghi rõ tên người khởi xướng đường

hầm sử dụng trong giai đoạn xác nhận khởi tạo đường hầm.

Tunnel-Server-Auth-ID: Thuộc tính này ghi rõ tên người tận cùng đường hầm

sử dụng trong giai đoạn xác nhận khởi tạo đường hầm.

4.3.5. RFC 2869:

RFC 2869 – RADIUS Extensions: đưa ra gợi ý về một số thuộc tính bổ sung có thể

được thêm vào RADIUS để thực hiện nhiều chức năng hữu ích khác nhau. Những

thuộc tính không có trường mở rộng trải qua trước đóđược nêu ra và do đó bị coi là

thử nghiệm.

Extensible Authentication Protocol (EAP) là một phần mở rộng PPP cung cấp hỗ

trợ cho các phương pháp xác thực bổ sung bên trong PPP. RFC này mô tả cách mà


46

thuộc tính EAP-Message và Message-Authenticator được sử dụng để cung cấp EAP hỗ

trợ bên trong RADIUS.

Tất cả các thuộc tính được bao gồm chiều dài biến Type-Length-Value 3-tuples.

Giá trị thuộc tính mới có thể được thêm vào mà không lo ngại làm xáo trộn triển khai

hiện có của giao thức.

III. ASA

1. Lịch sử ra đời.

Thiết bị phần cứng đảm nhận vai trò bảo vệ hạ tầng mạng bên trong,trước đây

thương hiệu PIX Firewall của hãng Cisco Systems đã giành được một trong những vị

trí hàng đầu của lĩnh vực này.Tuy nhiên,theo đà phát triển của công nghệ và xu hướng

tích hợp đa chức năng trên các kiến trúc phần cứng hiện nay (gọi là Appliance) hãng

Cisco Systems cũng đã nhanh chóng tung ra dòng sản phẩm bảo mật đa năng Cisco

ASA (Adaptive Security Appliance).Dòng thiết bị này ngoài việc thừa hưởng các ính

năng ưu điểm của công nghệ dùng trên Cisco PIX Firewall,Cisco IPS 4200 và Cisco

VPN 3000 Concentrator, còn được tích hợp đồng thời 3 nhóm chức năng chính cho

một hạ tầng bảo vệ là Firewall, IPS và VPN.Thông qua việc tích hợp những tính năng

như trên,Cisco ASA sẽ chuyển giao một giải pháp hiệu quả trong việc bảo mật hoá các

giao tiếp kết nối mạng,nhằm có thể chủ động đối phó trên diện rộng đối với các hình

thức tấn công qua mạng hoặc các hiểm họa mà tổ chức,doanh nghiệp thường phải

đương đầu.

Đặc tính nổi bật của thiết bị ASA là:

+ Đầy đủ các đặc điểm của Firewall,IPS,anti-X và công nghệ VPN IPSec/SSL .

+ Có khẳ năng mở rộng thích nghi nhận dạng và kiến trúc Mitigation Services.

+ Giảm thiểu chi phí vận hành và phát triển.

2. Các sản phẩm tường lửa của Cisco:

Cisco PIX Firewalls đã luôn luôn đóng vai trò quan trọng trong chiến lược bảo mật

của Cisco.Các mô hình tường lửa khác nhau của Cisco cung cấp các giải pháp bảo mật

cho các doanh nghiệp vừa và nhỏ.


47

Các sản phẩm tường lửa trước đây của Cisco bao gồm:

+ Cisco PIX Firewalls.

+ Cisco FWSM(Firewall Service Module)

+ Cisco IOS Firewall.

3. Điều khiển truy cập mạng (NAC)

Cisco Adaptive Security Appliances (ASA) có thể giúp bảo vệ một hoặc nhiều

mạng từ những kẻ xâm nhập và tấn công. Kết nối giữa các mạng này có thể được kiểm

soát và theo dõi bằng cách sử dụng các tính năng mạnh mẽ mà Cisco ASA cung cấp.có

thể đảm bảo rằng tất cả lưu lượng truy cập từ các mạng tin cậy cho dến mạng không

tin cậy(và ngược lại) đi qua các tường lửa dựa trên chính sách an ninh của tổ chức.

3.1. Lọc gói (Packet Filtering)

Cisco ASA có thể bảo vệ mạng bên trong(inside), các khu phi quân sự (DMZs) và

mạng bên ngoài(outside) bằng cách kiểm tra tất cả lưu lượng đi qua nó. Có thể xác

định chính sách và quy tắc cho những lưu lượng được cho phép hoặc không cho phép

đi qua interface. Các thiết bị bảo mật sử dụng access control lists (ACL) để giảm lưu

lượng truy cập không mong muốn hoặc không biết khi nó cố gắng để vào mạng đáng

tin cậy. Một ACL là danh sách các quy tắc an ninh, chính sách nhóm lại với nhau cho

phép hoặc từ chối các gói tin sau khi nhìn vào các tiêu đề gói(packet headers) và các

thuộc tính khác. Mỗi phát biểu cho phép hoặc từ chối trong ACL được gọi là một

access control entry (ACE). Các ACE có thể phân loại các gói dữ liệu bằng cách kiểm

tra ở layer 2,layer 3 và Layer 4 trong mô hình OSI bao gồm:

Kiểm tra thông tin giao thức layer 2: ethertypes.

Kiểm tra thông tin giao thức layer 3:ICMP, TCP, or UDP,kiểm tra địa chỉ IP

nguồn và đích .

Kiểm tra thông tin giao thức layer 4: port TCP/UDP nguồn và đích .

Khi một ACL đã được cấu hình đúng, có thể áp dụng vào interface để lọc lưu

lượng. Các thiết bị an ninh có thể lọc các gói tin theo hướng đi vào(inbound) và đi

ra(outbound) từ interface. Khi một ACL được áp dụng đi vào interface, các thiết bị an


48

ninh kiểm tra các gói chống lại các ACE sau khi nhận được hoặc trước khi truyền đi.

Nếu một gói được cho phép đi vào, các thiết bị an ninh tiếp tục quá trình này bằng

cách gửi nó qua các cấu hình khác. Nếu một gói tin bị từ chối bởi các ACL, các thiết bị

an ninh loại bỏ các gói dữ liệu và tạo ra một thông điệp syslog chỉ ra rằng như một sự

kiện đã xảy ra. Trong hình 3-1, người quản trị thiết bị an ninh đã được áp dụng cho

outside interface một inbound ACL chỉ cho phép lưu lượng

HTTP tới 20.0.0.1. Tất cả các lưu lượng khác sẽ bị bỏ tại interface của các thiết bị

an ninh.

Hình 3-1:Mô tả quá trình lọc gói của tường lửa

Nếu một outbound ACL được áp dụng trên một interface, các thiết bị an ninh xử lý

các gói dữ liệu bằng cách gửi các packet thông qua các quá trình khác nhau (NAT,

QoS, và VPN) và sau đó áp dụng các cấu hình ACE trước khi truyền các gói dữ liệu

này. Các thiết bị an ninh truyền các gói dữ liệu chỉ khi chúng được phép đi ra ngoài.

Nếu các gói dữ liệu bị từ chối bởi một trong các ACE, các thiết bị an ninh loại bỏ các

gói dữ liệu và tạo ra một thông điệp syslog chỉ ra rằng như một sự kiện đã xảy ra.

Trong hình 3-1, người quản trị thiết bị an ninh đã được áp dụng outbound ACL cho

inside interface chỉ cho phép lưu lượng HTTP tới 20.0.0.1.Tất cả các lưu lượng khác

sẽ bị bỏ tại interface của các thiết bị an ninh.

Các loại Access Control List:

Có năm loại ACL khác nhau đã cung cấp một cách linh hoạt và khả năng mở rộng

để lọc các gói trái phép bao gồm:

+ Standard ACL


Máy chủ Web Tường lửa ASAInternet Máy A

20.0.0.0/8 209.165.200.224/27

Bên trong Bên ngoài

Đánh rớt tất cả những lưu lượng khác

Cho phép lưu lượng truy cập tới 20.0.0.1

1 2 1

209.165.201.1

49

+ Extended ACL

+ IPV6 ACL

+ Ethertype ACL

+ WebVPN ACL

Standard ACL: Chuẩn Standard ACL được sử dụng để xác định các gói dữ liệu dựa

trên địa chỉ IP đích.Các ACL ở đây có thể được sử dụng để phân chia các luồng lưu

thông trong truy cập từ xa VPN và phân phối lại các luồng này bằng sơ đồ định

tuyến.Chuẩn Standard ACL chỉ có thể được sử dụng để lọc các gói khi và chỉ khi các

thiết bị bảo mạng hoạt động ở chế độ định tuyến,ngăn truy cập từ mạng con này đến

mạng con khác.

Extended ACL:Chuẩn Extended là một chuẩn phổ biết nhất,có thể phân loại các

gói dữ liệu dựa trên các đặc tính sau:

Địa chỉ nguồn và địa chỉ đích.

Giao thức lớp 3.

Địa chỉ nguồn hoặc địa chỉ của cổng TCP và UDP.

Điểm đến ICMP dành cho các gói ICMP.

Một chuẩn ACL mở rộng có thể được sử dụng cho quá trình lọc gói,phân loại

các gói QoS,nhận dạng các gói cho cơ chế NAT và mã hóa VPN.

IPV6 ACL:Một IPV6 ACL có chức năng tương tự như chuẩn Extended

ACL.Tuy nhiên chỉ nhận biết các lưu lượng là địa chỉ IPV6 lưu thông qua thiết bị bảo

mật ở chế độ định tuyến.

Ethertype ACL: Chuẩn Ethertype có thể được sử dụng để lọc IP hoặc lọc gói tin

bằng cách kiểm tra đoạn mã trong trường Ethernet ở phần đầu lớp 2.Một Ethertype

ACL chỉ có thể được cấu hình chỉ khi các thiết bị bảo mật đang chạy ở chế độ trong

suốt ( transparent ). Lưu ý rằng ở chuẩn này các thiết bị bảo mật không cho phép dạng

IPV6 lưu thông qua,ngay cả khi được phép đi qua IPV6 Ethertype ACL.

WebVPN ACL: Một WebVPN ACL cho phép người quản trị hệ thống hạn chế lưu

lượng truy cập đến từ luồng WebVPN.Trong trường hợp có một ACL WebVPN được

xác định nhưng không phù hợp một gói tin nào đó,mặc định gói tin đó sẽ bị loại

bỏ.Mặc khác,nếu không có ACL xác định,các thiết bị bảo mật sẽ cho phép lưu thông


50

qua nó.ACL xác định lưu lượng truy cập bằng cách cho phép hoặc loại bỏ gói tin khi

nó cố gắng đi qua thiết bị bảo mật.Một ACE đơn giản là cho phép tất cả các địa chỉ IP

truy cập từ một mạng này đến mạng khác,phức tạp hơn là nó cho phép lưu thông từ

một địa chỉ IP cụ thể ở một cổng riêng biệt đến một cổng khác ở địa chỉ đích.Một ACE

được thiết kế bằng cách sử dụng các lệnh điều khiển truy cập để thiết lập cho thiết bị

bảo mật.

3.2. Lọc nội dung và URL (Content and URL Filtering)

Theo truyền thống firewall chặn các gói dữ liệu bằng cách kiểm tra thông tin gói ở

layer 3 hoặc Layer 4. Cisco ASA có thể nâng cao chức năng này bằng cách kiểm tra

nội dung thông tin một vài giao thức ở layer 7 như HTTP, HTTPS, và FTP. Căn cứ

vào chính sách bảo mật của một tổ chức, các thiết bị an ninh có thể cho phép hoặc

chặn các packet chứa nội dụng không cho phép. Cisco ASA hỗ trợ hai loại lớp ứng

dụng lọc:

Content Filtering

URL Filtering

3.2.1. Content Filtering

Việc kích hoạt Java hoặc ActiveX trong môi trường làm việc có thể khiến người

dùng ngây thơ để tải về tập tin thực thi độc hại có thể gây ra mất mát các tập tin hoặc

hư hại các tập tin trong môi trường sử dụng. Một chuyên gia an ninh mạng có thể vô

hiệu hoá Java và xử lý ActiveX trong trình duyệt, nhưng điều này không phải là một

giải pháp tốt nhất. Có thể chọn một cách khác là sử dụng một thiết bị mạng như Cisco

ASA để loại bỏ các nội dung độc hại từ các gói tin. Sử dụng tính năng lọc nội dung

cục bộ, các thiết bị an ninh có thể kiểm tra các tiêu đề HTTP và lọc ra các ActiveX và

Java applet khi các gói dữ liệu cố gắng để đi qua thông qua từ máy không tin cậy.

Cisco ASA có thể phân biệt giữa các applet tin cậy và applet không tin cậy. Nếu một

trang web đáng tin cậy gửi Java hoặc ActiveX applet, các thiết bị bảo mật có thể

chuyển đến các máy chủ yêu cầu kết nối. Nếu các applet được gửi từ các máy chủ web

không tin cậy, thiết bị bảo mật có thể sửa đổi nội dung và loại bỏ các đính kèm từ các


51

gói tin. Bằng cách này, người dùng cuối không phải là quyết định đến các applet được

chấp nhận hoặc từ chối. Họ có thể tải về bất kỳ applet mà không phải lo lắng.

3.2.2. ActiveX Filtering

ActiveX có thể gây ra vấn đề tiềm năng nguy hại trên các thiết bị mạng nếu mã độc

ActiveX được tải về trên máy. Các mã ActiveX được đưa vào các trang web bằng cách

sử dụng thẻ HTML <OBJECT> và </ OBJECT>. Các thiết bị an ninh tìm kiếm các thẻ

cho lưu lượng có nguồn gốc trên một cổng cấu hình sẵn. Nếu các thiết bị an ninh phát

hiện các thẻ này, nó thay thế chúng bằng các thẻ chú thích . Khi trình duyệt

nhận được các gói dữ liệu HTTP với , nó bỏ qua các nội dung thực tế bằng

cách giả sử rằng nội dung là ý kiến của tác giả.

Lưu ý

Các thiết bị an ninh không thể nhận xét ra các thẻ HTML nếu chúng được phân

chia giữa nhiều gói mạng.

3.3. Chuyển đổi địa chỉ.3.3.1. Network Address Translation (NAT)

NAT hay còn gọi là Network Address Translation là một kỉ thuật được phát minh

lúc khởi đầu dùng để giải quyết vấn đề IP shortage, nhưng dần dần nó chứng tỏ nhiều

ưu điểm mà lúc phát minh ra nó người ta không nghĩ tới, một trong những lợi điểm

của NAT ngày nay được ứng dụng nhiều nhất là NAT cho phép:

Chia sẽ kết nối internet với nhiều máy bên trong LAN với một địa chỉ IP của

WAN

Firewall, nó giúp dấu tất cả IP bên trong LAN với thế giới bên ngoài, tránh sự

dòm ngó của hackers.

Tính linh hoạt và sự dễ dàng trong việc quản lý

NAT giúp cho các home user và các doanh nghiệp nhỏ có thể tạo kết nối với

internet một cách dễ dàng và hiệu quả cũng như giúp tiết kiệm vốn đầu tư.

3.3.2. Port Address Translation (PAT).

52

Đây là dạng NAT phổ thông mà thường gặp và sử dụng ngày nay trong các thiết bị

phần cứng hay phần mềm routing như router hay các phần mềm chia sẽ internet như

ISA, ICS hay NAT server mà lát nữa đây chúng ta sẽ có dịp tìm hiểu cách thiết lập

nó.Dạng NAT này hay còn được gọi với một cái tên dynamic nat. Với dạng NAT này

tất cả các IP trong mạng LAN được dấu dưới một địa chỉ NAT-IP, các kết nối ra bên

ngoài đều được tạo ra giả tạo tại NAT trước khi nó đến được địa chỉ internet.NAT

rule: Giả trang internet IP address 138.201 sử dụng địa chỉ NAT router Mỗi packets

được gởi ra ngoài IP nguồn sẽ được thay thế bằng NAT-IP là 195.112 và port nguồn

được thay thế bằng một cổng nào đó chưa được dùng ở NAT, thông thường là các

cổng lớn hơn 1204. Nếu một packet được gởi đến địa chỉ của router và port của

destination nằm trong khoảng port dùng để masquerading thì NAT sẽ kiểm tra địa chỉ

IP này và port với masquerading table của NAT nếu là gởi cho một host bên trong

LAN thì gói tin này sẽ được NAT gắn vào địa chỉ IP và port của host đó và sẽ chuyển

nó đến host đó.

4. Giao thức AAA và dịch vụ hỗ trợ của Cisco ASA

AAA là từ viết tắt: Authentication, Authorization, Accounting. AAA cung cấp các

giải pháp khác nhau để điều khiển kiểm soát truy cập đến các thiết bị mạng. Các dịch

vụ sau đây được bao gồm trong kiến trúc AAA là:

Authentication (Xác thực): Quá trình xác thực người dùng dựa trên đặc tính của họ

và các thông tin được xác định trước, chẳng hạn như mật khẩu và các cơ chế khác như

giấy chứng nhận kỹ thuật số.

Authorization (Ủy quyền): Là phương pháp mà một thiết bị mạng tập hợp một tập

các thuộc tính điều chỉnh đúng với nhiệm mà người sử dụng được ủy quyền thực hiện.

Những thuộc tính thiết lập nên quyền hạn mà người sử dụng được phép hoặc không

cho phép . Các kết quả được trả lại cho các thiết bị mạng để xác định quyền hạn của

người dùng mà cơ sở dữ liệu của người dùng có thể được đặt trên ASA hoặc nó có thể

được lưu trữ trên một máy chủ RADIUS hoặc TACACS +.

Accounting (Kế toán): Quá trình thu thập và gửi thông tin người dùng đến một máy

chủ AAA được ghi lại để theo dõi các lần đăng nhập (khi người dùng đăng nhập và


53

đăng xuất) và các dịch vụ mà người dùng truy cập. Thông tin này có thể được sử dụng

để thanh toán, kiểm tra, và mục đích báo cáo.

Cisco ASA có thể được cấu hình để duy trì một cơ sở dữ liệu người dùng nội bộ

hoặc sử dụng một máy chủ bên ngoài để xác thực.

Hình 3-2: Mô tả kiến trúc cơ bản cho NAS/RADIUS/TACACS+/AAA

Sau đây là các giao thức chứng thực AAA và các máy chủ được lưu trữ cơ sỡ dữ

liệu nằm bên ngoài:

Remote Authentication Dial-In User Service (Radius).

Terminal Access Controller Access-Control System (Tacacs+).

Rsa SecurID(SID).

Win NT.

Kerberos.

Lightweight Directory Access Protocol (LDAP).

4.1. Remote Authentication Dial-In User Service (Radius).

RADIUS là một giao thức xác thực sử dụng rộng rãi được định nghĩa trong RFC

2865. "Remote Authentication Dial-In User Service (RADIUS)." RADIUS hoạt động

trong một mô hình khách hàng / máy chủ. Một khách hàng RADIUS thường được gọi

là một máy chủ truy cập mạng (network access server :NAS).một máy NAS có trách

nhiệm truyền thông tin người dùng tới máy chủ RADIUS. Cisco ASA hoạt động như


54

là một NAS và xác thực người dùng dựa trên phản ứng của máy chủ RADIUS. Cisco

ASA hỗ trợ một vài máy chủ RADIUS sau:

CiscoSecure ACS

Cisco Access Registrar.

Livingston.

Merit.

Funk Steel Belted.

Microsoft Internet Authentication Server.

Đối với mạng xác thực, một khóa bí mật được trao đổi giữa các máy chủ

AAA/RADIUS và khách hàng AAA. Các khóa bí mật được chia sẻ là không bao giờ

được gửi qua liên kết thiết bị để đảm bảo tính toàn vẹn. Khi RADIUS xác thực người

sử dụng, phương pháp xác thực có thể được sử dụng rất nhiều, RADIUS hỗ trợ xác

thực qua Point-to-Point Protocol Challenge Handshake Authentication Protocol (PPP

CHAP) và PPP Password Authentication Protocol (PAP),RADIUS là một giao thức

mở rộng cho phép các nhà cung cấp khả năng thêm giá trị thuộc tính mới mà không

tạo ra một vấn đề đối với các thuộc tính giá trị hiện tại. Một khác biệt lớn giữa

TACACS và RADIUS là RADIUS không xác thực và ủy quyền riêng biệt. RADIUS

cũng cung cấp cho kế toán tốt hơn.

RADIUS hoạt động theo giao thức UDP. RADIUS sử dụng các cổng 1645 và 1812

để xác thực và 1646 và 1813 cho kế toán. Các cổng 1812 và 1813 được tạo ra trong

việc triển khai RADIUS mới hơn. Việc sử dụng các cổng RADIUS 1645 trong lúc

triển khai đạ gây ra xung đột với các dịch vụ "datametrics". Do đó, cổng chính thức là

1812.Giao thức RADIUS được xem là một dịch vụ kết nối. Các vấn đề liên quan đến

máy chủ sẵn sàng, phát lại, và hết giờ được xử lý trên thiết bị chứ không phải là giao

thức truyền tải. Chức năng này khác với TACACS + độ tin cậy trong giao thức phụ

thuộc vào giao thức TCP.

Hoạt động RADIUS

Sau đây là quá trình hoạt động RADIUS quản lý đăng nhập:

Bước 1. Một thông tin đăng nhập người dùng tạo ra một truy vấn (Access-Request)

từ AAA khách hàng đến máy chủ RADIUS.


55

Bước 2. Một phản ứng cho phép hoặc loại bỏ(Access-Accept hoặc Access-Reject)

được trả về từ máy chủ.

Các gói tin Access-Request chứa tên người dùng, mật khẩu mã hóa, địa chỉ IP của

khách hàng AAA, và cổng định dạng gói tin RADIUS:

Hình 3-3 Định dạng gói tin Radius

Mỗi gói tin RADIUS gồm các thông tin sau đây:

+ Code: 1 octet, định nghĩa loại packet

+ Identifier: 1 octet, Kiểm tra yêu cầu, trả lời và phát hiện trùng lặp yêu cầu từ

RADIUS server.

+ Length: 2 octet, xác định độ dài của toàn bộ gói.

+ Request Authenticator: 16 octet, Các octet quan trọng nhất được truyền đi đầu

tiên, nó xác nhận trả lời từ máy chủ RADIUS. Hai loại authenticators như sau:

-Request-Authenticator có sẵn trong gói Access-Request và Accounting-Request

-Response-Authenticator có sẵn trong các gói Access-Accept, Access-Reject,

Access-Challenge, Accounting-Response.

+ Attributes: Thuộc tính bổ sung vào RADIUS hỗ trợ nhà cung cấp cụ thể.

Các máy chủ RADIUS nhận được yêu cầu xác thực người dùng và sau đó trả về

thông tin cấu hình cần thiết cho khách hàng để hỗ trợ các dịch vụ cụ thể cho người

dùng. Các máy chủ RADIUS thực hiện điều này bằng cách gửi Internet Engineering

Task Force (IETF) hoặc các thuộc tính nhà cung cấp cụ thể. (Các thuộc tính RADIUS

chứng thực được định nghĩa trong RFC 2865.)

Cisco ASA hoạt động như là một NAS và máy chủ RADIUS là một Cisco Secure

Access Control Server (ACS).


Code Identifier Length

Request Authenticator

Attributes

56

Người dùng cố gắng để kết nối với Cisco ASA (để quản trị,vpn,thực hiện tính năng

cut-though proxy).

Các Cisco ASA nhắc nhở người dùng, yêu cầu tên người dùng và mật khẩu của

mình.

Người sử dụng gửi thông tin của mình cho ASA Cisco.

Các Cisco ASA gửi yêu cầu xác thực (Access-Request) đến máy chủ RADIUS.

Các máy chủ RADIUS gửi một message Access-Accept nếu người dùng là xác

thực thành công hoặc một Access-Reject nếu người dùng không xác thực thành công.

Cisco ASA đáp ứng cho người sử dụng và cho phép truy cập vào các dịch vụ cụ

thể.

Lưu ý: Các máy chủ RADIUS cũng có thể gửi các thuộc tính nhà cung cấp cụ thể

cho Cisco ASA tùy thuộc vào việc thực hiện và các dịch vụ sử dụng. Những thuộc tính

này có thể chứa thông tin như địa chỉ IP để gán các thông tin khách hàng và ủy quyền.

RADIUS server xác thực và ủy quyền kết hợp các giai đoạn thành một yêu cầu duy

nhất và chu kỳ liên kết đáp ứng.

4.2. Terminal Access Controller Access-Control System (Tacacs+)

TACACS + là một giao thức bảo mật AAA cung cấp xác thực tập trung của người

dùng đang cố gắng để truy cập vào NAS, giao thức TACACS + hỗ trợ cho AAA một

cách linh hoạt hơn. TACACS + sử dụng cổng 49 và chạy trên nền UDP hoặc TCP.

Cisco ASA sử dụng giao thức TCP để giao tiếp TACACS+ .

4.2. Định dạng TACACS và các giá trị tiêu đề

Các ID TACACS định nghĩa một tiêu đề 12-byte xuất hiện trong tất cả các gói

TACACS. tiêu đề này luôn luôn được gửi ở định dạng văn bản rõ ràng.

1 2 3 4 5 6 7 8 1 2 3 4 5 6 7

8

1 2 3 4 5 6

7 8

1 2 3 4 5 6

7 8

Major_ver

sion

Minor_ver

sion

Type Seq_no Flags

Session_id

Length


57

Hình 3-4: Định dạng gói tin

Major_version Đây là số phiên bản chính của TACACS. giá trị xuất hiện trong tiêu

đề như TAC_PLUS_MAJOR_VER = 0xc.

Minor_version:cung cấp số serial cho giao thức TACACS. Nó cũng cung cấp cho

khả năng tương thích của giao thức. Một giá trị mặc định, cũng như phiên bản một,

được định nghĩa cho một số lệnh. Những giá trị này xuất hiện trong tiêu đề TACACS

như TAC_PLUS_MINOR_VER_DEFAULT = 0x0

TAC_PLUS_MINOR_VER_ONE = 0x1.

Nếu một máy chủ AAA chạy TACACS nhận được một gói TACACS xác định

một phiên bản nhỏ hơn khác phiên bản hiện tại, nó sẽ gửi một trạng thái lỗi trở lại và

yêu cầu các minor_version với phiên bản gần nhất được hỗ trợ.

Loại này phân biệt các loại gói tin. Chỉ có một số loại là hợp pháp. Các loại gói

hợp pháp như sau:

- TAC_PLUS_AUTHEN = 0x01 đây là loại gói nghĩa xác thực.

- TAC_PLUS_AUTHOR-0x02 đây là loại gói tin mà nghĩa ủy quyền.

- TAC_PLUS_ACCT = 0x03 đây là loại gói tin mà nghĩa kế toán.

Seq_no : xác định số thứ tự cho các phiên làm việc. TACACS có thể khởi tạo một

hoặc nhiều phiên TACACS cho mỗi khách hàng AAA.

Flags:có 2 cờ

+TAC_PLUS_UNENCRYPTED_FLAG :xác định mã hóa củagói TACACS. Giá

trị 1 là chưa mã hóa, giá trị 0 là gói tin đã được mã hóa.

+TAC_PLUS_SINGLE_CONNECT_FLAG:Xác định ghép hoặc không ghép các

phiên tacacs trên một kết nối tcp.

Session_id Đây là một giá trị ngẫu nhiên đó chỉ định các phiên hiện tại giữa khách

hàng và máy chủ AAA chạy TACACS. Giá trị này vẫn giữ nguyên trong suốt thời gian

của phiên làm việc

Lengh: tổng chiều dài của gói TACACS, không bao gồm tiêu đề 12-byte.


58

Khái niệm xác thực TACACS + cũng tương tự như RADIUS. NAS sẽ gửi một yêu

cầu chứng thực với TACACS + server .Các máy chủ cuối cùng sẽ gửi bất kỳ thông

điệp sau đây trở về NAS:

ACCEPT - Người dùng đã được xác thực thành công và các dịch vụ yêu cầu sẽ

được cho phép. Nếu như cơ chế cấp quyền được yêu cầu,tiến trình cấp quyền sẽ được

thực thi.

REJECT - xác thực người dùng đã bị từ chối. Người sử dụng có thể được nhắc để

thử lại chứng thực tùy thuộc vào TACACS + server và NAS.

ERROR - Một số lỗi xảy ra trong quá trình xác thực. Nguyên nhân gây ra lỗi có thể

ở vấn đề kết nối hoặc vi phạm cơ chế bảo mật.

CONTINUE - Người dùng được nhắc nhở để cung cấp thông tin xác thực hơn.

Sau khi quá trình xác thực đã hoàn tất, nếu uỷ quyền được yêu cầu TACACS +

server với sẽ xử lý giai đoạn kế tiếp nếu xác thực thành công.

4.3. Rsa SecurID (SID)

RSA SecurID (SID) là một giải pháp bảo mật được cung cấp bởi công ty bảo mật

RSA. RSA ACE/Server là thành phần quản trị của giải pháp SID. Nó cung cấp mật

khẩu trong thời gian nhất định. Cisco ASA hỗ trợ xác thực SDI mà chỉ dành cho xác

thực người dùng VPN. Tuy nhiên nếu SDI sử dụng một máy chủ xác thực, thì khi đó

giống như dùng CiscoSecure ACS dành cho Windown NT, máy chủ đó có thể sử dụng

xác thực bên ngoài đối với dịch vụ SID và proxy để đảm bảo các yêu cầu xác thực đối

với tất cả các dịch được hỗ trợ bởi Cisco ASA. Cisco ASA và SDI sử dụng UDP cổng

5500 cho quá trình truyền thông.Giải pháp SDI cung cấp mật khẩu cho người dùng

mỗi 60 giây theo cơ chế vòng tròn. Các mật khẩu đó được tạo ra khi người dùng nhập

vào số pin và được đồng bộ hóa với máy chủ để cung cấp cơ chế xác thực. Máy chủ

SDI có thể được cấu hình để yêu cầu người dùng nhập vào số bin mới khi đang xác

thực.

Cơ chế xác thực đó được thể hiện ở hình 3-5:


3 4

1

2

59

Hình 3-5: Cơ chế xác thực

1.Người dùng thực hiện kết nối với thiết bị bảo mật Cisco ASA.

2.Cisco ASA bắt đầu thực hiện cơ chế xác thực.

3.Người sử dụng cung cấp thông tin Username and Password.

4.Cisco ASA chuyển tiếp các yêu cầu xác thực đến máy chủ SDI.

5.Nếu như mã bin mới được chấp thuận,máy chủ SDI xác thực người dung và yêu

cầu một Pin mới để sử dụng khi tới một phiên xác thực người dung kế tiếp.

6.Cisco ASA yêu cầu người dùng cấp một Pin mới.

7.Người dùng nhập vào Pin mới.

8.Cisco ASA gửi thông tin Pin mới đến máy chủ SDI.

4.4. Win NT

Cisco ASA hỗ trợ Windown NT xác thực các kết nối truy cập từ xa VPN.Nó giao

tiếp với máy chủ Windown NT sử dụng TCP cổng 139.Giống như SDI,có thể sử dụng

một máy chủ Radius/Tacacs+,và cũng giống như CiscoSecure ACS có thể ủy quyền

xác thực đến Windown NT cho các dịch vụ được hỗ trợ bởi Cisco ASA.

4.5. Kerberos

Là một giao thức được xây dựng để nâng cao độ an toàn khi xác thực trong môi

trường mạng phân tán.Cisco ASA có thể xác thực người dùng VPN thông qua các thư

mục Windown bên ngoài,mà sử dụng Kerberos để xác thực.Có thể sử dụng hệ điều

hành Unix hoặc Linux để chạy máy chủ xác thực Kerberos.Được hỗ trợ để xác thực

các máy khách VPN.Cisco ASA giao tiếp với thư mục tích cực và,hoặc máy chủ

Kerberos sử dụng UDP cổng 88.

4.6. Lightweight Directory Access Protocol (LDAP)


56

7 8

60

Cisco ASA hỗ trợ giao thức LDAP ủy quyền kết nối truy cập từ xa VPN.Giao thức

xác thực LDAP được đề rõ trong RFC 3377 và RFC 3771.LDAP cung cấp các dịch vụ

ủy quyền khi truy cập đến cơ sở dữ liệu của người dùng với thông tin cây thư

mục.Cisco ASA giao tiếp với máy chủ LDAP thông qua TCP cổng 389. LDAP chỉ

cung cấp các dịch vụ ủy quyền.Vì vậy một giao thức riêng biệt nào đó cần phải xác

thực dịch vụ. LDAP là một chuẩn giao thức truy cập thư mục đơn giản, hay là một

ngôn ngữ để client và severs sử dụng để giao tiếp với nhau.LDAP là một giao thức

“lightweight ” có nghĩa là đây là một giao thức có tính hiệu quả, đơn giản và dễ dàng

để cài đặt. trong khi chúng sử dụng các hàm ở mức cao. Điều này trái ngược với giao

thức “heavyweight” như là giao thức truy cập thư mục X.500 (DAP) sử dụng các

phương thức mã hoá quá phức tạp. LDAP sử dụng các tập các phương thức đơn giản

và là một giao thức thuộc tầng ứng dụng.

Phương thức hoạt động của LDAP

Mô hình LDAP client/server:

Đầu tiên xem xét LDAP như là giao thức giao tiếp client/server. Giao thức

client/sever: là một mô hình giao thức giữa một chương trình client chạy trên một máy

tính gởi một yêu cầu qua mạng đến cho một máy tính khác đang chạy một chương

trình sever (phục vụ), chương trình này nhận lấy yêu cầu và thực hiện sau đó trả lại kết

quả cho chương trình client. Ý tưởng cơ bản của giao thức client/server là công việc

được gán cho những máy tính đã được tối ưu hoá để làm thực hiện công việc đó.Ví dụ

tiêu biểu cho một máy server LDAP có rất nhiều RAM(bô nhớ) dùng để lưu trữ nội

dung các thư mục cho các thao tác thực thi nhanh và máy này cũng cần đĩa cứng và

các bộ vi xử lý ở tốc độ .

LDAP Là một giao thức hướng thông điệp.Do client và sever giao tiếp thông qua

các thông điệp, Client tạo một thông điệp (LDAP message) chứa yêu cầu và gởi đến

cho server. Server nhận được thông điệp và sử lý yêu cầu của client sau đó gởi trả cho

client cũng bằng một thông điệp LDAP. Ví dụ: khi LDAP client muốn tìm kiếm trên

thư mục, client tạo LDAP tìm kiếm và gởi thông điệp cho server. Sever tìm trong cơ

sở dữ liệu và gởi kết quả cho client trong một thông điệp LDAP.

Quá trình kết nối giữa LDAP server và client:


61

LDAP client và server thực hiện theo các bước sau:

Client mở một kết nối TCP đến LDAP server và thực hiện một thao tác bind. Thao

tác bind bao gồm tên của một directory entry và uỷ nhiệm thư sẽ được sử dụng trong

quá trình xác thực, uỷ nhiệm thư thông thường là pasword nhưng cũng có thể là chứng

chỉ điện tử dùng để xác thực client.

Sau khi thư mục có được sự xác định của thao tác bind, kết quả của thao tác bind

được trả về cho client.

Hình 3-6: Quá trình kết nối giữa Client và Server

Mô hình kết nối giữa Client / Server

1. Mở kết nối và bind tới server.

2. Client nhận kết quả bind.

3. Client phát ra các yêu cầu tìm kiếm.

4. Server thực hiện xử lý và trả về kết quả 1 cho client.

5. Server trả về kết quả 2 cho client.

6. Server gởi thông điệp kết thúc việc tìm kiếm.


LDAP ServerLDAP Client

1. Mở kết nối và bind tới server

2. Kết quả của thao tác bind

3. Hoạt động tìm kiếm

4. Trả về kết quả 1

5. Trả về kết quả 2

6. Kết thúc phiên làm việc

7.Thao tác unbind8. Đóng kết nối

62

7. Client phát ra yêu cầu unbind, với yêu cầu này server biết rằng client muốn huỷ bỏ

kết nối.

8. Server đóng kết nối

5. Kiểm tra ứng dụng

Cơ chế kiểm tra ứng dụng của Cisco sử dụng để kiểm tra độ an ninh của các ứng

dụng và dịch vụ trong hệ thống. Các công cụ kiểm tra trạng thái thông tin về mỗi kết

nối đi qua các interface của thiết bị an ninh và đảm bảo chúng là hợp lệ. Trạng thái

ứng dụng kiểm tra xem xét không chỉ các tiêu đề gói tin mà còn lọc nội dung của gói

tin thông qua tầng ứng dụng. Một số ứng dụng yêu cầu xử lý đặc biệt đối với các gói

dữ liệu khi chúng đi qua thiết bị Layer 3. Bao gồm các ứng dụng và giao thức được

nhúng vào địa chỉ IP trong quá trình truyền tải dữ liệu của gói tin hoặc mở ra một kênh

thứ hai cho phép

6. Khả năng chịu lỗi và dự phòng (failover and redundancy)

6.1. Kiến trúc chịu lỗi

Khi hai ASA được thiết lập trong chế độ failover, một trong Cisco ASA được gọi

là các chủ động (active ) có trách nhiệm tạo ra trạng thái và chuyển đổi địa chỉ, chuyển

giao các gói dữ liệu, và giám sát các hoạt động khác,một ASA khác gọi là chế độ

chờ(standby),có trách nhiệm theo dõi tình trạng chế độ chủ động. Chế độ chủ động và

chế độ chờ trao đổi thông tin chịu lỗi với nhau thông qua một đường link kết nối này

được biết như là một link chịu lỗi (link failover).Khi có sự cố xảy ra trên chế độ chủ

động thì chế độ chờ sẽ thực hiện vai trò của chế độ chủ động cho đến khi chế độ chủ

động khôi phục lại trạng thái.

Đường chịu lỗi giữa hai ASA trao đổi các thông tin:

Trạng thái chủ động hoặc trạng thái chờ

Trạng thái liên kết mạng

Thông điệp hello

Trao đổi địa chỉ MAC

Cấu hình đồng bộ hóaGVHD: THS Nguyễn Đức Quang SVTH:Nguyễn Đắc Nguyên Long MSSV:106102078 Lê Hoàng Long MSSV:106102079

63

Hình 3-7:minh họa liên kết chịu lỗi

6.2. Điều kiện kích hoạt khả năng chịu lỗi

Khả năng chịu lỗi xảy ra

Khi người quản trị thiết lập chuyển đổi từ chế độ chủ động sang chế độ chờ

Khi ASA đang đảm nhiệm ở chế độ chờ không nhận được gói tin keepalive từ chế

độ chủ động, sau hai lần không thấy liên lạc từ chế độ chủ động thì chế độ chờ xem

chế độ chủ động đã bị lỗi và chuyển sang đóng vai trò như chế độ chủ động cho đến

khi chế độ chủ động hoạt động trở lại.

Khi một liên kết trên một cổng nhận được lệnh down .

Kiểm tra trạng thái của cổng chịu lỗi

Để biết được trạng thái chịu lỗi thông qua liên kết giữa chế độ chủ động và chế độ

chờ trao đổi thông điệp hello cứ mỗi 15 giây.Thông diệp hello bao gồm các trạng thái

hoạt động của các liên kết được cấu hình.Trước khi chuyển sang từ chế độ chờ sang

chủ động ASA kiểm tra bốn trạng thái sau :

Kiểm tra trạng thái up/down trên từng cổng nếu không hoạt động sẽ xủ lý quá

trình chịu lỗi.

Kiểm tra sự hoạt động của hệ thống nếu sau năm giây mà không nhân được bất

kỳ gói tin nào sẽ chuyển sang chế độ chịu lỗi bắt đầu.

Kiểm tra sự hoạt động của hệ thống bằng cách gửi gói ARP sau năm giây

không nhận được tín hiệu trả lởi xem như cổng đó bị lỗi và xủ lý quá trình chịu lỗi.


Liên kết chịu lỗi

64

Kiểm tra sự hoạt động của hệ thống bằng cách ping broadcast thử nghiệm nếu

sau năm giây không nhận được tín hiệu trả lởi xem như cổng đó bị lỗi và xủ lý quá

trình chịu lỗi..

6.3. Trạng thái chịu lỗi

Khi kết nối được thiết lập thông qua cisco ASA ,cisco ASA sẽ cập nhật bảng kết

nối.Trong mục kết nối bao gồm:địa chị nguốn,địa chỉ đích,giao thức,trạng thái kết

nối,gắn với interface nào và số byte truyền. Tùy thuộc vào cấu hình failover, Cisco

ASA có một trong những trạng thái sau đây:

Stateless failover:Duy trì kết nối nhưng không đồng bộ với trạn thái chờ.Trong

trường hợp này trạng thái hoạt động sẽ không gửi các bảng cập nhật trạng thái cho chế

độ chờ.Khi trạng thái hoạt động bị lỗi thi trạng thái chờ sẽ được kích hoát và phải thiết

lập lại các kết nối,tất cả các lưu lượng đều bị phá vỡ

Stateful failover:Duy trì kết nối và đồng bộ với chế độ chờ . Ở trường hợp này các

trạng thái kết nối đều được đồng bộ từ trạng thái hoạt động sang trạng thái chờ và khi

trạng thái chờ được kích hoạt sẽ không phải thiết lập dại các bảng kết nối vì đã tồn tại

trong cơ sở dữ liệu của nó.

7. Chất lượng dịch vụ (QoS)

Trong một mạng IP chuẩn, tất cả các gói dữ liệu được xử lý giống nhau theo một

cách tốt nhất. Các thiết bị mạng thường bỏ qua tầm quan trọng và thời gian của các dữ

liệu được truyền qua mạng. Để ưu tiên cho các gói dữ liệu quan trong hay đáp ứng

được thời gian thực của gói thoại và video áp dụng chính sách quản lý chất lượng dịch

vụ cho từng loại gói .Có nhiều cớ chế quản lý dịch vụ khác nhau mà có sẵn trong các

thiết bị của cisco như:

Traffic policing

Traffic prioritization

Traffic shaping

Traffic marking

Tuy nhiên cisco ASA chỉ hỗ trợ hai loại là traffic policing,traffic prioritization


65

7.1. Traffic Policing

Chính sách lưu lượng được biết như là sự giới hạn lưu lượng cho phép kiểm soát

tốc độ tối đa đủ điều kiện để đi qua interface .Các lưu lượng nào nằm trong cấu hình

qui định thì được phép thông qua và các lưu lượng vượt ngưỡng giới hạn đều bị đánh

rớt hết.Trong cisco ASA khi một lưu lượng không được định nghĩa ưu tiên sẽ được xử

lý thông qua đánh giá giới hạn gói tin nếu phù hợp với mức cấu hình QoS thì cho phép

truyền,nếu không đủ mức cho phép gói tin sẽ chờ bổ sung hoặc điều chỉnh chính sách

cho phép thấp xuống nếu phù hợp với cấu hình gói tin sẽ được đưa vào hang đợi

không ưu tiên “nonpriority”.

Hình 3-8: Minh họa cách một gói được xử lý trong các thiết bị an ninh khi đi qua

các công cụ QoS.

Khi rời khỏi cơ chế QoS gói tin sẽ được chuyển đến interface cho việc chuyển đổi

dữ liệu.Thiết bị an ninh thực hiện QoS cho mỗi gói mức độ khác nhau để đảm bảo cho

việc truyền nhận mà nói tin không có trong danh sách ưu tiên.Quá trình xử lý gói tin

dựa vào độ sâu của hàng đợi ưu tiên thấp và các điều kiện của vòng truyền.Vòng

truyền sẽ có không gian bộ đệm được thiết bị an ninh sử dụng để giử các gói tin trước

khi truyền chúng cho các cấp độ điều khiển.Nếu có tắc nghẽn xảy ra thì các gói tin

trong hàng đợi được chuyển xuống hàng đợi ưu tiên thấp cho tới khi gói tin ở hàng đợi

ưu tiên cao trống,nếu hàng đợi ưu tiên cao có lưu lượng truy cập thì sẽ được phục vụ


Ưu tiên

Không ưu tiên

Không ưu tiên

Xắp xếp ưu tiên

Đánh giá giới hạn

Xô

int

erf

ac e

Không phù hợp

66

trước.Thông qua việc giới hạn lưu lượng thiết bị an ninh thực hiện một cơ chế nhỏ giọt

khi gói tin không phù hợp với thông tin cấu hình QoS.Cisco ASA ghi lai sự kiện này

thông qua máy chủ lưu trữ syslog hoặc tại trên thiết bị.

7.2. Traffic Prioritization

Lưu lượng ưu tiên còn được gọi là lớp dịch vụ hoặc là hàng đợi có độ trễ

thấp ,được sử dụng để cung cấp cho độ ưu tiên cho gói tin quan trọng được phép

truyền đi trước ,nó gán mức ưu tiên cho mỗi loại gói khác nhau có độ ưu tiên khác

nhau .bất lợi cho những gói có mức ưu tiên thấp dễ bị tắc nghẽn.Trên thiết bị an ninh

cisco ASA hai loại ưu tiên được hỗ trợ là “priority” và “nonpriority”.Priority có nghĩa

là gói tin được ưu tiên trong lưu lượng truy cập thường xuyên, trong khi QoS

nonpriority có nghĩa là các gói dữ liệu được xử lý bởi các giới hạn tốc độ,

Khi giao thông được phân loại là ưu tiên, nó sẽ được nhanh chóng chuyển tiếp mà

không thông qua các giới hạn về tốc độ. Giao thông sau đó được gắn cờ và chuyển vào

những hàng đợi ưu tiên truyền ra ngoài khỏi thiết bị an ninh. Để đảm bảo việc chuyển

tiếp lưu lượng được ưu tiên ở các interface,thiết bị an ninh sẽ đánh cờ trên mỗi hàng

đợi ưu tiên và gửi chúng ra truyền trực tiếp nếu có tắc nghẽn các lưu lượng đưa vào

trong hàng đợi ưu tiên cao và được truyền đi ngay khi vòng truyền sẵn sang. .

8. Phát hiện xâm nhập (IDS)

Đối với an ninh, hệ thống phát hiện xâm nhập (IDS) là thiết bị cố gắng phát hiện

ra kẻ tấn công truy cập trái phép vào mạng hay một máy chủ để tạo ra sự cố rớt mạng

hoặc để ăn cắp thông tin. IDS cũng phát hiện tấn công DDoS, sâu, và đợt bùng phát

virus. Số lượng và sự phức tạp của các mối đe dọa an ninh đã tăng vọt trong những

năm gần đây. Để đạt được hiệu quả an ninh mạng chống xâm nhập rất quan trọng cần

phải duy trì ở mức độ bảo vệ. Thận trọng,an toàn, tránh rủi ro và giảm chi phí thiệt hại

vì sự gián đoạn của hệ thống thiết bị tường lửa asa của cisco hỗ trợ hai loại khác nhau

của hệ thống phát hiện xâm nhập:

Network-based intrusion detection systems (NIDS).

Host-based intrusion detection systems(HIDS).


67

8.1. Network-based intrusion detection systems (NIDS)

Đối hệ thống mạng các hệ thống phát hiện xâm nhập được thiết kế để xác định

chính xác, phân loại, và bảo vệ chống lại mối đe dọa đã và chưa biết nhắm mục tiêu

một hệ thống. Những mối đe dọa bao gồm sâu, tấn công DoS, và phát hiện bất kỳ lỗ

hổng khác… Một số phương pháp phát hiện được triển khai rộng rãi với các đặc diểm

sau:

Trạng thái và ghi lại mẫu trạng thái

Phân tích giao thức

Phân tích dựa trên sự bình thường

Phân tích dựa trên sự bất thường

Hệ thống IDS dựa trên mạng sử dụng bộ dò và bộ bộ cảm biến cài đặt trên toàn

mạng. Những bộ dò này theo dõi trên mạng nhằm tìm kiếm những lưu lượng trùng với

những mô tả sơ lược được định nghĩa hay là những dấu hiệu. Những bộ bộ cảm biến

thu nhận và phân tích lưu lượng trong thời gian thực. Khi ghi nhận được một mẫu lưu

lượng hay dấu hiệu, bộ cảm biến gửi tín hiệu cảnh báo đến trạm quản trị và có thể

được cấu hình nhằm tìm ra biện pháp ngăn chặn những xâm nhập xa hơn. NIDS là tập

nhiều sensor được đặt ở toàn mạng để theo dõi những gói tin trong mạng so sánh với

với mẫu đã được định nghĩa để phát hiện đó là tấn công hay không.

Được đặt giữa kết nối hệ thống mạng bên trong và mạng bên ngoài để giám sát

toàn bộ lưu lượng vào ra. Có thể là một thiết bị phần cứng riêng biệt được thiết lập sẵn

hay phần mềm cài đặt trên máy tính. Chủ yếu dùng để đo lưu lượng mạng được sử

dụng. Tuy nhiên có thể xảy ra hiện tượng nghẽn cổ chai khi lưu lượng mạng hoạt động

ở mức cao.

8.1.1. Lợi thế của Network-Based IDSs

Quản lý được cả một network segment (gồm nhiều host)

"Trong suốt" với người sử dụng lẫn kẻ tấn công

- Cài đặt và bảo trì đơn giản, không ảnh hưởng tới mạng

- Tránh DOS ảnh hưởng tới một host nào đó.

- Có khả năng xác định lỗi ở tầng Network (trong mô hình OSI)


68

- Độc lập với OS

8.1.2. Hạn chế của Network-Based IDSs

Có thể xảy ra trường hợp báo động giả (false positive), tức không có intrusion

mà NIDS báo là có intrusion.

Không thể phân tích các traffic đã được encrypt (vd: SSL, SSH, IPSec…)

NIDS đòi hỏi phải được cập nhật các signature mới nhất để thực sự an toàn

- Có độ trễ giữa thời điểm bị attack với thời điểm phát báo động. Khi báo động được

phát ra, hệ thống có thể đã bị tổn hại.

Không cho biết việc attack có thành công hay không.

Một trong những hạn chế là giới hạn băng thông. Những bộ dò mạng phải nhận

tất cả các lưu lượng mạng, sắp xếp lại những lưu lượng đó cũng như phân tích chúng.

Khi tốc độ mạng tăng lên thì khả năng của đầu dò cũng vậy. Một giải pháp là bảo đảm

cho mạng được thiết kế chính xác để cho phép sự sắp đặt của nhiều đầu dò. Khi mà

mạng phát triển, thì càng nhiều đầu dò được lắp thêm vào để bảo đảm truyền thông và

bảo mật tốt nhất.

Một cách mà các kẻ xâm nhập cố gắng nhằm che đậy cho hoạt động của họ khi

gặp hệ thống IDS dựa trên mạng là phân mảnh những gói thông tin của họ. Mỗi giao

thức có một kích cỡ gói dữ liệu giới hạn, nếu dữ liệu truyền qua mạng lớn hơn kích cỡ

này thì gói dữ liệu đó sẽ được phân mảnh. Phân mảnh đơn giản chỉ là quá trình chia

nhỏ dữ liệu ra những mẫu nhỏ. Thứ tự của việc sắp xếp lại không thành vấn đề miễn là

không xuất hiện hiện tượng chồng chéo. Nếu có hiện tượng phân mảnh chồng chéo, bộ

cảm biến phải biết quá trình tái hợp lại cho đúng. Nhiều hacker cố gắng ngăn chặn

phát hiện bằng cách gởi nhiều gói dữ liệu phân mảnh chồng chéo. Một bộ cảm biến sẽ

không phát hiện các hoạt động xâm nhập nếu bộ cảm biến không thể sắp xếp lại những

gói thông tin một cách chính xác.

8.2. Host-based intrusion detection systems (HIDS)

Bằng cách cài đặt một phần mềm trên tất cả các máy tính chủ, IDS dựa trên máy

chủ quan sát tất cả những hoạt động hệ thống, như các file log và những lưu lượng


69

mạng thu thập được. Hệ thống dựa trên máy chủ cũng theo dõi OS, những cuộc gọi hệ

thống, lịch sử sổ sách (audit log) và những thông điệp báo lỗi trên hệ thống máy chủ.

Trong khi những đầu dò của mạng có thể phát hiện một cuộc tấn công, thì chỉ có hệ

thống dựa trên máy chủ mới có thể xác định xem cuộc tấn công có thành công hay

không. Thêm nữa là, hệ thống dựa trên máy chủ có thể ghi nhận những việc mà người

tấn công đã làm trên máy chủ bị tấn công (compromised host).

Không phải tất cả các cuộc tấn công được thực hiện qua mạng. Bằng cách giành

quyền truy cập ở mức vật lý (physical access) vào một hệ thống máy tính, kẻ xâm nhập

có thể tấn công một hệ thống hay dữ liệu mà không cần phải tạo ra bất cứ lưu lượng

mạng (network traffic) nào cả. Hệ thống dựa trên máy chủ có thể phát hiện các cuộc

tấn công mà không đi qua đường công cộng hay mạng được theo dõi, hay thực hiện từ

cổng điều khiển (console), nhưng với một kẻ xâm nhập có hiểu biết, có kiến thức về hệ

IDS thì hắn có thể nhanh chóng tắt tất cả các phần mềm phát hiện khi đã có quyền truy

cập vật lý.

Một ưu điểm khác của IDS dựa trên máy chủ là nó có thể ngăn chặn các kiểu tấn

công dùng sự phân mảnh hoặc TTL. Vì một host phải nhận và tái hợp các phân mảnh

khi xử lí lưu lượng nên IDS dựa trên host có thể giám sát chuyện này.

HIDS thường được cài đặt trên một máy tính nhất đinh. Thay vì giám sát hoạt động

của một network segment, HIDS chỉ giám sát các hoạt động trên một máy tính. HIDS

thường được đặt trên các host xung yếu của tổ chức, và các server trong vùng DMZ -

thường là mục tiêu bị tấn công đầu tiên. Nhiêm vụ chính của HIDS là giám sát các

thay đổi trên hệ thống, bao gồm (not all):

- Các tiến trình.

- Các mục của Registry.

- Mức độ sử dụng CPU.

- Kiểm tra tính toàn vẹn và truy cập trên hệ thống file.

- Một vài thông số khác.

Các thông số này khi vượt qua một ngưỡng định trước hoặc những thay đổi khả

nghi trên hệ thống file sẽ gây ra báo động.


70

8.2.1. Lợi thế của HIDS

- Có khả năng xác đinh user liên quan tới một sự kiện (event).

- HIDS có khả năng phát hiện các cuộc tấn công diễn ra trên một máy, NIDS

không có khả năng này.

- Có thể phân tích các dữ liệu mã hoá.

- Cung cấp các thông tin về host trong lúc cuộc tấn công diễn ra trên host này.

8.2.2. Hạn chế của HIDS

- Thông tin từ HIDS là không đáng tin cậy ngay khi sự tấn công vào asa thành

công.

- Khi tường lửa asa bị "hạ" do tấn công, đồng thời HIDS cũng bị "hạ".

- HIDS phải được thiết lập trên từng host cần giám sát .

- HIDS không có khả năng phát hiện các cuộc dò quét mạng (Nmap, Netcat…).

- HIDS cần tài nguyên trên host để hoạt động.

- HIDS có thể không hiệu quả khi bị DOS.

IV. Mô phỏng

1. Mục tiêu của mô phỏng

Mô phỏng giúp thấy được tính năng và thấy rõ được nguyên lý hoạt động củng như

các bước cấu hình AAA server . Thực hiện tính năng remote từ xa thông qua vpn trên

ASA chứng thực với giao thức Radius.


71

2. Mô hình mô phỏng

3. Các công cụ cần thiết để thực hiện mô phỏng

Hệ diều hành window xp và window 2003 server cài AD.

Phần mềm giả lập GNS3.Fidder

Tool ASDM,VPN client của cisco.

Máy PC phải cài gói java để hộ trợ cho ASDM.

Cài phần mềm ACS 4.2

4. Các bước mô phỏng

1. Chạy phần mềm ACS 4.2

Chọn “Network Configuration” bên trái , bấm vào “Add Entry” trong phần aaa

client.


72

Tạo thêm aaa server

1. Chọn menu “interface configuration”=>Adcance options


73

Đánh dấu vào 2 mục

2. Chọn menu “share profile components”=>Downloadable IP ACLs


74

Định nghĩa cho phép khách vpn tới mạng lan bên trong

Tạo một acl cho phép khách truy cập hệ thống

3. Tạo ra group :vpnclientgroup và cho phép group tải acl đã định nghĩa

4. Tạo user và cho phép user tải acl đã định nghĩa.GVHD: THS Nguyễn Đức Quang SVTH:Nguyễn Đắc Nguyên Long MSSV:106102078 Lê Hoàng Long MSSV:106102079

75

User có thể tạo mới hoặc lấy ở trong database window

5. Chọn finish.

6. Vào user=dial-in chọn allow.


76

Cấu hình trên ASA cho phép vpn chứng thức với AAA(Radius) Server.

Bước 1:Đặt dãy ip cho phép người dung từ xa kết nối vào hệ thống

ip local pool mypool 172.16.1.100-172.16.1.200 mask 255.255.255.0

!

Bước 2: Tạo một ACL cho phép dãy ip người dùng từ xa kết nối vào hệ thống

access-list vpnclientgroup standard permit 192.168.1.0 255.255.255.0

access-list inside_nat0_outbound extended permit ip 192.168.1.0 255.255.255.0

172.16.1.0 255.255.255.0

nat (inside) 0 access-list inside_nat0_outbound

Bước 3: Thiết lập chứng thực user group tại máy chủ bên trong

aaa-server vpnclientgroup protocol radius

aaa-server vpnclientgroup host 192.168.1.2

key 123456

Bước 4:Thiết lập chính sách đối với người dùng từ xa

group-policy vpnclientgroup internal

group-policy vpnclientgroup attributes

dns-server value 192.168.1.2

vpn-tunnel-protocol IPSec

split-tunnel-policy tunnelspecified

split-tunnel-network-list value vpnclientgroup

default-domain value da.com

Bước 5:Tạo một đường hầm cho phép kết nối với chính sách dành cho người

dùng và phương thức chứng thực và khóa chia sẽ

tunnel-group vpnclientgroup type ipsec-ra

tunnel-group vpnclientgroup general-attributes

address-pool mypool

authentication-server-group vpnclientgroup

default-group-policy vpnclientgroup

tunnel-group vpnclientgroup ipsec-attributes

pre-shared-key 123456


77

Bước 6: Xác định phương thức mã hóa và chứng thực chuyển đổi dữ liệu được

mã hóa và chứng thực thông qua đường truyền

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto dynamic-map outside_dyn_map 20 set pfs

crypto dynamic-map outside_dyn_map 20 set transform-set ESP-3DES-SHA

crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map

crypto map outside_map interface outside

crypto isakmp enable outside

crypto isakmp policy 10

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 86400

Cấu hình máy khách

Tiếp theo cấu hình khách remote access tới ASA vào truy cập máy chủ web,ftp

trong nội bộ .

Mở phần mền Ugent VPN của cisco và điền thông tin group và pre share key để kết

nối


78

Hiện lên thông báo yều cấu cung cấp username và password truy cập vào mạng nội

bộ

Mở wireshark lên bắt gói radius


79

Mở ACS vào menu “reports and activity” chọn Radius accouting để xem


80

5. Kết quả đạt được

Thông qua quá trình mô phỏng hiểu rõ hơn về quá trình xác thực radius giống như

mô tả trong lý thuyết.

Nắm rõ về hoạt động củng như các tính năng của tường lửa cisco asa.

Giả lập được firewall asa trên nền gns3.

Quản lý giám sát được người dùng truy cập vào hệ thống thông qua cơ chế vpn.

Đáp ứng an toàn thông tin dữ liệu dưới vụ bảo vệ của firewall với các cơ chế mã

hóa,xác thực,quyền hạn truy cập.


81

V.KẾT LUẬN CHUNGRadius là một giao thức chứng thực người dùng đầu cuối nhằm đảm bảo cho sự an

toàn thông tin tuy nhiên nó vẫn chưa phải là một giao thức hoàn hảo với một số lổ

hỏng sau:

Cho phép kẽ tấn công thỏa hiệp giao dịch

Thuật toán mã hóa user/password không an toàn

Có thể bị tấn công theo cách yêu càu chứng thực gói tin Radius.

o Lặp đi lặp lại yêu cầu xác thực và thuộc tính người dùng-mật khẩu

o Chia sẽ khóa bí mật.

Tường lửa cisco asa là một thiết bị để đảm bảo an toàn thông tin ,bảo mật hệ thống

tuy nhiên vẫn còn mắc phải một số hổ hỏng ,không có gì là an toàn tuyệt đối tuy nhiên

để khắc phục hạn chế rủi ro nên thường xuyên cập nhật các bản vá lỗi củng như các

phiên bản mới từ trang chủ cisco.

Do thời gian hạn hẹp và nguồn nhân lực có hạn nên đề tài không tránh khỏi thiếu

sót mong là trong thời gian tới sẽ khắc phục để đồ án được hoàn chỉnh hơn.


82

VI.HƯỚNG PHÁT TRIỂN CỦA ĐỀ TÀITiếp nhận ý kiến của giáo viên hướng dẩn ,hội đồng phản biện và các ý kiến của

bạn bè để bổ sung chỉnh sửa khắc lại đồ án những chỗ chưa hay ,sai sót hoặc phát huy

thế mạnh của đồ án

Tìm hiểu và triển khai phương thức xác thực an toàn hơn.

Cập nhật khắc phục lỗi của tường lửa cisco asa.

Tiếp cận môi trường thực tế,hiện thực mô phỏng trên môi trường thiết bị thật.

Triển khai mô hình mạng hoàn chỉnh và thực tế đáp ứng nhu cầu của công ty doanh

nghiệp.


83

Tài liệu tham khảo: RFC 2865: Remote Authentication Dial In User Service (RADIUS)

Link: http://www.ietf.org/rfc/rfc2865.txt RFC 2866: RADIUS Accounting

Link: http://www.ietf.org/rfc/rfc2866.txt Firewall Fundamentals by Wes Noonan, Ido Dubrawsky

Publisher: Cisco Press - 2/6/2006 RADIUS by Jonathan Hassell

Publisher: O’Reilly – 10/2002 Cisco ASA and PIX Firewall Handbook by Dave Hucaby

Publisher: Cisco Press – 7/1/2005 Cisco ASA: All-in-one Firewall, IPS and VPN Adaptive Security Appliance

by Jazib Frahim, Omar Santos

Publisher: Cisco Press – 21/10/2005 Cisco ASA: All-in-one Firewall, IPS, Anti-X and VPN Adaptive Security

Appliance (Second Edition) by Jazib Frahim, Omar Santos

Publisher: Cisco Press – 21/10/2005 Cisco Access Control Security: AAA Administrative Services by Brandon

Carroll

Publisher: Cisco Press – 27/5/2004


http://www.ietf.org/rfc/rfc2866.txt

http://www.ietf.org/rfc/rfc2865.txt

Bao Mat Mang

Documents

Transcript of Bao Mat Mang