Tải bản đầy đủ (.docx) (74 trang)

Triển khai hệ thống mạng an toàn với firewall ASA

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.31 MB, 74 trang )

Mục lục
LỜI CẢM ƠN
Sau gần 6 tháng nỗ lực tìm hiều và thực hiện, đồ án “Triển khai hệ thống mạng
an toàn với firewall ASA” đã được hoàn thành, ngoài sự cố gắng hết mình của bản
thân, chúng tôi còn nhận được nhiều sự động viên,khích lệ từ gia đình, thầy cô và bạn
bè.
Đây là một đề tài khá hay mang tính thiết thực cao. Tuy đã cố gắng hết sức song
chắc chắn đề tài này không tránh khỏi những thiết sót. Rất mong nhận được sự thông
cảm và chỉ bảo tận tình của các Thầy cô và các bạn.
Chúng tôi xin bày tỏ lòng biết ơn chân thành nhất đến Thầy Mai Cường Thọ đã
tận tâm chỉ bảo và hướng dẫn tận tình trong suốt thời gian tôi thực hiện đề tài này.
Tôi cũng xin chân thành cảm ơn quý Thầy cô trong Khoa Công nghệ thông tin, trường
Đại học Nha Trang đã tận tình giảng dạy, hướng dẫn, giúp đỡ và tạo điều kiện cho tôi
thực hiện tốt đề tài này.
Xin cảm ơn tất cả các bạn bè đã và đang giúp đỡ động viên tôi trong quá trình
học tập và hoàn thành đồ án.
Mặc dù đã cố gắn hết sức để hoàn thành đồ án này,nhưng chắc chắn sẽ không
tránh khỏi những sai sót.Chúng tôi rất mong nhận được sự thông cảm và đóng góp, chỉ
bảo tận tình của quý thầy cô và bạn bè!
Nha Trang, ngày 26, tháng 6 năm 2013
Sinh viên thực hiện: Nguyễn Lương

LỜI MỞ ĐẦU
Trong thời kì hội nhập, khi nhu cầu trao đổi dữ liệu qua hệ thống mạng máy tính
ngày càng tăng cao, Internet càng trở nên vô cùng quan trọng, ảnh hưởng đến tất cả các
lĩnh vực kinh tế xã hội, an ninh quốc phòng của quốc gia. Thực tế ở Việt Nam, Internet
đã được ứng dụng và phát triển rộng rãi (phổ cập tới xấp xỉ 25% dân số), dẫn đến số tội
phạm công nghệ cao ngày càng nhiều, có không ít cuộc tấn công trên mạng gây ra hậu
quả hết sức nghiêm trọng, làm tê liệt hệ thống giám sát an ninh hay phá hoại cơ sở dữ
liệu quốc gia, đánh cắp thông tin mật Nhà nước… Đối với doanh nghiệp, vấn đề bảo đảm
an ninh, an toàn thông tin trên mạng là mối quan tâm hàng đầu của hầu hết công ty, tổ


Page 1


chức và các nhà cung cấp dịch vụ. Cùng với sự bùng nổ khoa học kỹ thuật, các phương
thức tấn công ngày càng tinh vi hơn khiến hệ thống an ninh mạng trở nên mất hiệu qủa.
Bill Archer, Chủ tịch hãng AT&T tại châu Âu, phát biểu "Chúng tôi nhận thấy
mật độ tấn công trong vòng 6 tháng qua đã dày hơn rất nhiều so với hai năm trước".
Đặc biệt ở Việt Nam, vấn đề trên càng phải đầu tư, xem xét hơn bao giờ hết. Theo
khảo sát của Trung tâm ứng cứu khẩn cấp máy tính Việt Nam (VNCERT) dựa vào các
tiêu chuẩn an toàn thông tin thì 40% doanh nghiệp Việt Nam không có hệ thống tường
lửa, 70% không có quy trình xử lý sự cố an toàn thông tin và 85% không có chính sách
về an ninh mạng. Hơn nữa, theo phân tích của Kaspersky, năm 2010, Việt Nam đứng thứ
5 thế giới trong số những quốc gia chịu nhiều thiệt hại nhất do tấn công trên mạng
(sau Ấn Độ và Mỹ, xếp đầu bảng là Trung Quốc và Nga). Việc xây dựng hệ thống an
ninh mạng sao cho vừa đảm bảo an toàn, bảo mật thông tin vừa tận dụng hiệu năng
mạng đang trở thành câu hỏi đau đầu đối với các tổ chức doanh nghiệp không những ở
Việt Nam mà còn trên toàn thế giới. Nhận thấy những nguy cơ đó, xuất phát từ niềm
say mê nghiên cứu các kỹ thuật ảo mật mạng, nhóm chúng tôi quyết định chọn đề tài
“Triển khai hệ thống mạng an toàn với Firewall ASA”, với mong muốn đem lại cho
doanh nghiệp mô hình đáp ứng được các yêu cầu về bảo mật mà vẫn đảm bảo hiệu năng
hoạt động mạng. Qua đó, chúng tôi cũng trang bị cho mình thêm nhiều kiến thức để
chuẩn bị thử sức với thách thức mới ngoài xã hội.

A.Tổng quan về đề tài
Mụ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 truys 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
Page 2


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.

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.
Page 3


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.

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
Page 4


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
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
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
Page 5


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
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
Ddo S 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
Page 6


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ế
để 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
Page 7


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.
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. 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
an ninh cho tổ chức.
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.

Truy cập vật lý
Truy cập quản trị
Nâng cấp phần mềm
Tậ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ệ
Page 8


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

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
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 thành bảy phần:
Page 9




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à những 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:
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 phải được sử dụng và nơi lọc được áp dụng.
Page 10


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.
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
Page 11


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ử
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
Page 12





Yêu cầu cấu hình an toàn
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ỳ.

Page 13


II. Radius
1. Tổng quan về Radius:
AAA

AAA cho phép các nhà quản trị mạng biết được các thông tin quan trọng về tình
hình cũng như mức độ an toàn trong mạng. Nó cung cấp việc xác thực
(Authentication) người dùng nhằm bảo đảm có thể nhận dạng đúng người dùng. Một
khi đã nhận dạng người dùng, ta có thể giới hạn ủy quyền (Authorization) mà người
dùng có thể làm. Khi người dùng sử dụng mạng, ta có thể giám sát tất cả những gì mà
họ làm. AAA với ba phần xác thực (Authentication), ủy quyền (Authorization) và kế
toán (Accounting) là các phần riêng biệt mà ta có thể sử dụng trong dịch vụ mạng, cần
thiết để mở rộng và bảo mật mạng.

Page 14


AAA có thể dùng để tập hợp thông tin từ nhiều thiết bị trên mạng. Ta có thể kích
hoạt các dịch vụ AAA trên router, switch, wirewall, các thiết bị VPN, server…
Các dịch vụ AAA bao gồm ba phần xác thực (Authentication), ủy quyền
(Authorization) và kế toán (Accounting). Ta sẽ tìm hiểu sự khác nhau của ba phần này
và cách thức chúng làm việc như thế nào.
1.1.1. Xác thực (Authentication)
Xác thực dùng để nhận dạng (identify) người dùng. Trong suốt quá trình xác thực,
username và password của người dùng được kiểm tra và đối chiếu với cơ sở dữ liệu
lưu trong AAA server. Tất nhiên tùy thuộc vào giao thức mà AAA hổ trợ mã hóa đến

đâu, ít nhất thì cũng mã hóa username và password.
Xác thực sẽ xác định người dùng là ai. Ví dụ: Người dùng có username là HOA và
mật khẩu là Hoa@nIT sẽ là hợp lệ và được xác thực thành công với hệ thống. Sau khi
xác thực thành công thì người dùng đó có thể truy cập được vào mạng. Tiến trình này
chỉ là một trong các thành phần để điều khiển người dùng với AAA. Một khi username
và password được chấp nhận, AAA có thể dùng để định nghĩa thẩm quyền mà người
dùng được phép làm trong hệ thống.
1.1.2. Ủy quyền (Authorization)
Ủy quyền cho phép các nhà quản trị điều khiển việc cấp quyền trong một khoảng
thời gian, hay trên từng thiết bị, từng nhóm, từng người dùng cụ thể hay trên từng giao
thức. AAA cho phép nhà quản trị tạo ra các thuộc tính mô tả các chức năng của người
dùng được phép thao tác vào tài nguyên. Do đó người dùng phải được xác thực trước
khi ủy quyền cho người đó.
Ủy quyền trong AAA làm việc giống như một tập các thuộc tính mô tả những gì
mà người dùng đã được xác thực có thể có
Ví dụ: Người dùng HOA sau khi đã xác thực thành công có thể chỉ được phép truy
cập vào server HOAPHATIT_SERVER thông qua FTP. Những thuộc tính này được so
sánh với thông tin chứa trong cơ sở dữ liệu của người dùng đó và kết quả được trả về
AAA để xác định khả năng cũng như giới hạn thực tế của người đó. Điều này yêu cầu
cơ sở dữ liệu phải giao tiếp liên tục với AAA server trong suốt quá trình kết nối đến
thiết bị truy cập từ xa (RAS).
Ủ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.

Page 15


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 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
nhà quản trị hệ thống định nghĩa những quy tắc này.

Máy chủ AAA sẽ phân tích yêu cầu và cấp quyền truy cập bất cứ yêu cầu nào có
thể, có hoặc không phải là toàn bộ yêu 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 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).
Kiểm toán cho phép nhà quản trị có thể thu thập thông tin như thời gian bắt đầu,
thời gian kết thúc người dùng truy cập vào hệ thống, các câu lệnh đã thực thi, thống kê
lưu lượng, việc sử dụng tài nguyên và sau đó lưu trữ thông tin trong hệ thống cơ sở dữ
liệu quan hệ. Nói cách khác kiểm toán cho phép giám sát dịch vụ và tài nguyên được
người dùng sử dụng. Ví dụ: Thống kê cho người dùng có tên truy cập là HOA đã truy
cập vào HOAPHATIT_SERVER bằng giao thức FTP với số lần là 5 lần. Điểm chính
trong kiểm toán đó là cho phép người quản trị giám sát tích cực và tiên đoán được dịch
vụ và việc sử dụng tài nguyên. Thông tin này có thể được dùng để tính cước khách
hàng, quản lý mạng, kiểm toán sổ sách.
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ủ
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
Page 16



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á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.
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.

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ối
Má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

Page 17


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à 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áy chủ AAA phê duyệt
Máy chủ AAA cuối
Má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ưởng
Máy khách

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
Page 18



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
đế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ỳ.
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.
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 để 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.

(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)

Hình 2-3: Mô tả về cấu trúc gói tin
Page 19


Cấu trúc dự liệu được chia thành 5 khu vực riêng biệt:







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

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, 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,

Page 20


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:
Dài 16 octet. 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 Authenticators như sau: Request-Authenticator và ResponseAuthenticator.
- Request-Authenticator
-

có sẵn trong gói Access-Request và Accounting-

Request
Response-Authenticator có sẵn trong gói Access-Accept, Access-Reject,
Access-challenge, Accouting-Response.

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 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.Trường id phải được đặt một giá trị
duy nhất cho một gói yêu cầu.
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.

Page 21


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.

(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
MD5
user password hoặc CHAP PWD

(Tùy biến)

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.
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 để

Page 22


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.

(2)


Từ định danh (Duy nhất mỗi lần truyền)
Độ dài
(Tiêu đề và tải trọng)

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)

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à
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.

(3)


Từ định danh (Duy nhất mỗi lần truyền)
Độ dài
(Tiêu đề và tải trọng)

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-message

Page 23


Proxy message (cả hai có thể xuất hiện nhiều lần) (Tùy biến)

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

(11)

Từ định danh (Duy nhất mỗi lần truyền)
Độ dài
(Tiêu đề và tải trọng)

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: state
Reply-message (cả hai có thể gắn nhiều lần)
(Tùy biến)

Page 24


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 (AccountingRequest).

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.

(4)

Từ định danh (Duy nhất)
Độ dài
(Tiêu đề và tải trọng)

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)

Page 25



×