Các nhà quản lý của các trang web thương mại điện tử có thể không quan tâm đến việc phát hiện và phân tích một tia quét hoặc giám sát các cuộc tấn công mà được sử dụng để xác định máy ch
TỔNG QUAN VỀ ĐÁNH GIÁ HỆ THỐNG PHÁT HIỆN XÂM NHẬP
Giới thiệu
Trong những năm qua việc sử dụng hệ thống phát hiện xâm nhập (IDS) trong thương mại đã phát triển mạnh mẽ, và IDS hiện đang là thiết bị tiêu chuẩn cho các doanh nghiêp mạng lớn Mặc dù có sự đầu tư khá lớn nhưng phương pháp có sẵn hiện nay lại không toàn diện và nghiêm ngặt để có thể kiểm tra tính hiệu quả của hệ thống này Một số có thể đổ lỗi cho người tiêu dùng không đòi hỏi các biện pháp hiệu quả như vậy trước khi mua IDS Một số cũng có thể đổ lỗi cho các đơn vị nghiên cứu tài trợ không đầu tư nhiều tiền hơn trong lĩnh vực này Nhưng phương pháp đo lường là một ngoại lệ Tuy nhiên, định lượng đo hiệu năng IDS là không có sẵn vì có rất nhiều rào cản nghiên cứu cần phải vượt qua trước khi chúng ta có thể tạo ra các bài kiểm tra như vậy Bài viết này nêu các phép đo định lượng mà chúng ta cần, những trở ngại cản trở sự tiến bộ để phát triển các phép đo, và ý tưởng của chúng tôi cho các nghiên cứu về phương pháp đo lường hiệu năng hệ thống phát hiện xâm nhập để vượt qua những trở ngại này.
Đặc điểm của đánh giá hệ thống phát hiện xâm nhập
Trong phần này chúng tôi liệt kê một bộ các phép đo mà có thể được thực hiện trên hệ thống phát hiện xâm nhập – IDS
Số đo này xác định những tấn công mà một IDS có thể phát hiện dưới điều kiện lý tưởng Đối với các hệ thống dựa trên chữ ký, điều này chỉ đơn giản là sẽ bao gồm việc đếm số lượng chữ ký và lập bản đồ chúng vào một sơ đồ đặt tên tiêu chuẩn Đối với các hệ thống phi chữ ký, người ta cần phải xác định tấn công bên ngoài tập các tấn công đã biết thông qua một phương pháp đặc biệt nào đó Mỗi cuộc tấn công đều có một mục tiêu cụ thể (ví dụ như từ chối dịch vụ, thâm nhập, hoặc quét,…); phần mềm chống đặc biệt chạy trên các phiên bản của một hệ điều hành cụ thể hoặc một giao
7 | P a g e thức chống lại cụ thể; và bằng chứng hay một dấu vết để lại ở địa điểm khác nhau Các cuộc tấn công cũng có thể phụ thuộc vào phần cứng của hệ thống bị tấn công, trên các phiên bản của một giao thức được sử dụng, hoặc trên các phương thức hoạt động được sử dụng Các nhà nghiên cứu nhấn mạnh một loạt các tính năng khác nhau trong nghiên cứu đo lường của họ bao gồm: mục tiêu tấn công; các kiểu dữ liệu nạn nhân mà phải được thu thập để có được bằng chứng của cuộc tấn công; các cuộc tấn công sử dụng kỹ thuật trốn tàng hình IDS và sự kết hợp của các tính năng này Kết quả là một số nhà nghiên cứu thừa nhận rằng mỗi cuộc tấn công có nhiều mục tiêu và phương thức hoạt động, trong khi những người khác xác định mỗi cuộc tấn công có cấu hình mục tiêu và phương thức hoạt động rất cụ thể Chênh lệch này có liên quan đến mức chính xác của độ chi tiết để quan sát các cuộc tấn công làm cho nó khó khăn trong việc đếm số lượng các cuộc tấn công mà một IDS phát hiện và khó khăn để so sánh độ bao phủ của IDS Vấn đề này được làm dịu bớt phần nào nhờ danh sách Common Vulnerabilities and Exposures (CVE), đó là một danh sách chứa hầu như tất cả các lỗ hổng được biết đến Tuy nhiên, cách tiếp cận CVE không giải quyết vấn đề này khi mà các cuộc tấn công phức tạp được sử dụng để khai thác các lỗ hổng tương tự bằng cách sử dụng phương pháp tiếp cận khác nhau để tránh hệ thống IDS Để giải quyết vấn đề này, các nhóm tiêu chuẩn CVE đã bắt đầu một dự án đặt tên cho các cuộc tấn công, nhưng công việc này vẫn đang trong giai đoạn nghiên cứu
Một vấn đề khác với việc đánh giá độ bao phủ của các cuộc tấn công đó là xác định tầm quan trọng của các kiểu tấn công khác nhau Các trang web khác nhau có thể gán giá trị chi phí quản lý thay đổi rộng hơn và tầm quan trọng trong việc phát hiện các kiểu tấn công khác nhau Các nhà quản lý của các trang web thương mại điện tử có thể không quan tâm đến việc phát hiện và phân tích một tia quét hoặc giám sát các cuộc tấn công mà được sử dụng để xác định máy chủ và các nguồn tài nguyên khác trên mạng Thường thì những cuộc tấn công không có ảnh hưởng đến việc kinh doanh
8 | P a g e của họ và thường không thể được ngăn chặn Tuy nhiên, quản lý thương mại điện tử có thể rất quan tâm trong việc phát hiện sự phân tán của tấn công từ chối dịch vụ (DDoS), và trong việc phát hiện thành công thỏa hiệp máy chủ hoặc ẩn trang web Điều nhấn mạnh ở đây là khác với các phương pháp tiếp cận của đa số đánh giá thương mại bao gồm dò và giám sát các cuộc tấn công Các trang web quân sự có thể tập trung nhiều sự chú ý đến một nỗ lực giám sát các cuộc tấn công trong một thực nghiệm để xác định tiền thân của các mối đe dọa nghiêm trọng hơn
Ngoài ra, hầu hết các trang web không thể phát hiện các cuộc tấn công tìm kiếm lỗ hổng thất bại và chúng không còn tồn tại trên một trang web Các cuộc tấn công có thể thất bại vì hoạt động của hệ thống này đã được vá và không còn dễ bị tấn công; vì hệ thống với các hệ điều hành yêu cầu không tồn tại, hoặc vì một tường lửa hoặc các khối thiết bị bảo vệ tấn công quan trọng khác Một số trang web cụ thể có thể giám sát chỉ là một vài trong số hàng ngàn lỗi bảo mật được biết đến hiện nay trong CVE, và chúng sẽ thay đổi tương ứng với các hệ thống được thay thế, vá lỗ hổng, và cấu hình lại và như lỗ hổng mới được phát hiện
1.2.2 Xác suất của báo động giả
Số đo này xác định tỷ lệ dương tính với phát hiện sai được tạo ra bởi một IDS ở một môi trường mang đến trong một khung thời gian cụ thể Một báo động giả hay sai là một cảnh báo gây ra bởi lưu lượng tin bình thường không độc hại Một số nguyên nhân cho Network IDS (NIDS) có chữ ký yếu rằng: cảnh báo trên tất cả các lưu lượng truy cập đến một số hiệu cổng cao được sử dụng bởi một backdoor; tìm kiếm cho sự xuất hiện của một từ phổ biến chẳng hạn như "help" trong 100 byte đầu tiên của SNMP hoặc các kết nối TCP khác; hoặc phát hiện hành vi vi phạm phổ biến của giao thức TCP Chúng cũng có thể được gây ra bởi mạng lưới giám sát bình thường và bảo vệ lưu lượng tin tạo ra bởi công cụ quản lý mạng Khó khăn ở đây là việc đo lường các báo động sai vì một IDS có thể có tỷ lệ dương tính với báo động giả khác
9 | P a g e nhau trong mỗi môi trường mạng và ở đây lại không có những điều như một "tiêu chuẩn mạng" Ngoài ra, rất khó để xác định các khía cạnh của lưu lượng mạng hoặc hoạt động máy chủ sẽ gây ra các báo động giả Kết quả là, có thể rất khó khăn để đảm bảo rằng chúng tôi có thể tạo ra số lượng và kiểu của các báo động sai trong một kiểm thử IDS giống như được tìm thấy trong các mạng thực sự Cuối cùng, IDS có thể được cấu hình và điều chỉnh theo nhiều cách khác nhau để làm giảm tỷ lệ dương tính giả Điều này làm khó khăn trong việc xác định cấu hình của một IDS cho nên được sử dụng cho một kiểm thử dương tính giả đặc biệt
Một đường cong ROC là một tổng hợp các xác suất của các báo động giả và xác suất của các phép đo phát hiện Chúng tôi đề cập đến nó vì tầm quan trọng của nó trong cộng đồng thử nghiệm IDS Đường cong này tóm tắt các mối quan hệ giữa hai trong số những đặc điểm IDS quan trọng nhất đó là: dương tính sai và xác suất phát hiện Trong hình 1, chúng tôi hiển thị đường cong hoạt động đặc trưng thu được (ROC) tạo ra bởi hai hệ thống trong một thử nghiệm IDS
Hình 1 Đường cong ROC- Độ chính xác tỷ lệ phần trăm các tấn công bị phát hiện với tỷ lệ phần trăm báo động sai
Trục x cho thấy tỷ lệ báo động sai được tạo ra trong một bài kiểm tra và trục y cho thấy tỷ lệ phần trăm của các cuộc tấn công phát hiện được tại bất kỳ tỷ lệ phần trăm báo động giả Lưu ý rằng một IDS có thể hoạt động ở bất kỳ điểm nào trên đường cong Trong ví dụ này, hệ thống 1 có thể được điều chỉnh đến một loạt các điểm hoạt động, trong khi hệ thống 2 sẽ là khó khăn để cấu hình vì nó chỉ có một điểm hoạt động thực tế
Theo định nghĩa, đường cong ROC cho thấy xác suất trên trục x và trục y, nhưng đôi khi các đơn vị đo lường cho lưu lượng bình thường là rất khó khăn để xác định Kết quả là, các nhà nghiên cứu đã sử dụng các báo động sai theo mỗi đơn vị thời gian trên trục x Một đơn vị đo là rất cần thiết để xác định số lượng tối đa báo động sai có thể xảy ra trong một khoảng thời gian nhất định Đơn vị đo lường này phụ thuộc rất nhiều vào cách mà tính năng được tách xuất trong một IDS từ các dữ liệu đầu vào sử dụng và rất khó để xác định cho hệ thống phát hiện xâm nhập thương mại và hệ thống hộp đen khác Đối với mục đích đánh giá, nó có lẽ là tốt hơn để vẽ tỷ lệ phát hiện so với báo động giả ở mỗi đơn vị thời gian Những đường cong này không thực sự là đường cong ROC, nhưng chúng truyền đạt thông tin quan trọng khi phân tích và so sánh IDS Trong hình1, cả hai hệ thống là dựa trên NIDS, và các đơn vị đo là tổng số các gói tin truyền qua mạng Các phân tích cho rằng, lúc tồi tệ nhất, một IDS có thể phát hành một cảnh báo cho mỗi gói tin, và số lượng tối đa cảnh báo là tổng số các gói tin truyền đi
Số đo này xác định tỷ lệ của các cuộc tấn công phát hiện được một cách chính xác bởi một IDS ở một môi trường mang lại trong một khung thời gian cụ thể Khó khăn trong việc đo lường tỷ lệ phát hiện là sự thành công của một IDS phần lớn phụ thuộc vào các thiết lập của các cuộc tấn công được sử dụng trong các lần đánh giá Ngoài ra, khả năng phát hiện thay đổi theo tỷ lệ dương tính giả, và một IDS có thể
11 | P a g e được cấu hình hoặc điều chỉnh để ưu tiên cho một trong hai khả năng phát hiện các cuộc tấn công hoặc để giảm thiểu tình trạng dương tính với báo động giả
Hơn nữa, một NIDS có thể tránh bằng phiên bản tàng hình của các cuộc tấn công Một NIDS có thể phát hiện một cuộc tấn công khi nó được đưa ra một cách đơn giản dễ hiểu Kỹ thuật sử dụng để giúp các cuộc tấn công tàng hình bao gồm các gói phân mảnh, sử dụng các loại khác nhau của dữ liệu mã hóa, sử dụng cờ TCP bất thường, mã hóa các gói tin tấn công, tấn công lan rộng qua nhiều phiên mạng, và các cuộc tấn công phát động từ nhiều nguồn khác
1.2.4 Khả năng chống tấn công trực tiếp tại IDS
Việc đo đạc này chứng tỏ khả năng một IDS chịu đựng một nỗ lực của một kẻ tấn công làm gián đoạn các hoạt động chính xác của IDS như thế nào Các cuộc tấn công chống lại một IDS có thể gồm hình thức:
• Gửi một lượng lớn lưu lượng không tấn công với khối lượng vượt quá khả năng xử lý của IDS Với quá nhiều lưu lượng truy cập đến tiến trình, một IDS có thể giảm các gói dữ liệu và không thể phát hiện các cuộc tấn công
Nỗ lực đánh giá IDS hiện có
Các nỗ lực đánh giá IDS khác nhau đáng kể về chiều sâu, phạm vi, phương pháp, và độ tập trung của họ Bảng 1 tóm tắt các đặc điểm của một số nỗ lực đánh giá tại các nước phát triển hơn, liệt kê theo thứ tự thời gian Bảng này cho thấy rằng những đánh giá có độ phức tạp tăng lên vượt thời gian, bao gồm nhiều IDS và nhiều loại tấn công hơn, như tấn công tàng hình và từ chối dịch vụ (DoS) Đánh giá các hệ thống thương mại đã bao gồm các phép đo hiệu suất theo tải trọng lưu lượng cao
Bảng 1 Đặc điểm của các đánh giá IDS
16 | P a g e Đưới đây cung cấp thông tin chi tiết liên quan đến tất cả các đánh giá thể hiện trong Bảng 1
1.3.1 Đại học California tại Davis (UCD)
Những nỗ lực nghiên cứu ban đầu ở Đại học California tại Davis dẫn đến việc nền tảng thử nghiệm IDS đầu tiên tự động phát động các cuộc tấn công bằng cách sử dụng tương tác telnet, FTP,và phiên rlogin Một mạng lưới các hệ thống phát hiện xâm nhập được gọi là Network Security Monitor (NSM) trong đó sử dụng kết hợp từ khoá để phát hiện các cuộc tấn công trong lưu lượng mạng Các đánh giá được sử dụng một vài cuộc tấn công bao gồm cả đoán mật khẩu, truyền tải một tập tin mật khẩu cho một máy chủ từ xa, và khai thác một lỗ hổng trong chương trình mô-đun tải để có được tình trạng sử dụng mạnh trên một máy Unix NSM bỏ lỡ một số các cuộc tấn công cho đến khi từ khóa bổ sung thêm được thêm vào
1.3.2 Phòng thí nghiệm Lincoln MIT (MIT/LL)
MIT / LL đã thực hiện các thử nghiệm IDS định lượng rộng lớn nhất cho đến nay Tài trợ bởi Cơ quan Nghiên cứu Dự án Bộ Quốc phòng Mỹ (DARPA) MIT /
LL tiến hành thử nghiệm IDS quy mô lớn, nghiên cứu vào năm 1998 và 1999 Các nỗ lực đánh giá năm 1999 tạo ra background traffic trực tiếp tương tự như trên một căn cứ không quân có chứa hàng trăm người sử dụng trên hàng ngàn máy chủ Hơn
200 trường hợp của 58 loại tấn công (bao gồm cả các cuộc tấn công tàng hình) được cài vào trong bảy tuần tạo dữ liệu và hai tuần kiểm thử dữ liệu Khác với đánh giá năm 1998 của họ, đánh giá năm 1999 được thiết kế chủ yếu để đánh giá khả năng của hệ thống nhằm phát hiện các cuộc tấn công mới mà không cần đào tạo lần đầu tiên về các trường hợp tấn công Các cuộc tấn công tự động được đưa ra chống
17 | P a g e lại ba máy nạn nhân là UNIX (SunOS, Solaris, Linux), Windows, NT host, và một bộ định tuyến trong sự hỗ trợ của nền lưu lượng truyền (background traffic) Tỷ lệ phát hiện các cuộc tấn công, tỷ lệ báo động giả cho background traffic, và các đường cong ROC đã tạo cho hệ thống IDS hơn 18 nghiên cứu và các loại tấn công bao gồm DoS,thăm dò, remote-to-local, và các cuộc tấn công user-to-super- user Các cuộc tấn công được tính là đã phát hiện nếu một IDS tạo ra một cảnh báo cho các máy tính bị tấn công rằng lưu lượng tin được chỉ thị hoặc các hoạt động trên một máy chủ nạn nhân được tạo ra bởi các cuộc tấn công Một phân tích về cuộc tấn công cũng đã được thực hiện để xác định nếu IDS có thể cung cấp chính xác tên cho các cuộc tấn công cũ và chi tiết cuộc tấn công bao gồm cả các địa chỉ
IP nguồn, cổng được sử dụng, bắt đầu và kết thúc của cuộc tấn công Kết quả chứng minh rằng sự kết hợp giữa mạng và phương pháp tiếp cận dựa trên máy chủ đã cung cấp vùng bao phủ tấn công tốt nhất
1.3.3 Phòng thí nghiệm nghiên cứu không quân (AFRL)
AFRL cũng theo tài trợ của DARPA, tham gia với MIT / LL nghiên cứu đánh giá IDS trong năm 1998 và 1999 Phương pháp của họ là tương tự như MIT / LL (họ sử dụng một số lưu lượng truy cập và hệ tấn công phần mềm MIT / LL) nhưng tập trung vào thử nghiệm IDS trong thời gian thực trong một môi trường mạng phân cấp phức tạp hơn
Hệ thống IDS đã được cài đặt trong một thử nghiệm, background traffic được chạy trong bốn giờ, và các cuộc tấn công đã được đưa ra đối với các host ở giữa background traffic này AFRL mô phỏng một mạng lưới rộng lớn bởi phát triển phần mềm để tự động gán tùy ý địa chỉ IP nguồn đến phiên mạng cá nhân chạy trên máy tính thử nghiệm Các thử nghiệm năm 1998 đánh giá ba nghiên cứu IDS dựa trên chữ ký và một hệ thống chính phủ off-the-shelf (GOTS) cơ bản tương tự như NSM Hệ thống nghiên cứu về căn bản có tỷ lệ báo động giả thấp đáng kể so với hệ thống
GOTS, nhưng phát hiện tấn công tổng thể có độ chính xác vẫn còn khoảng 25% ở mức báo động giả chấp nhận được
Tổng công ty MITRE đã tổ chức Intrusion Detection Fly-Off, một trong những đánh giá đầu tiên của hệ thống phát hiện xâm nhập thương mại và chính phủ Hoạt động này là một cuộc điều tra về các đặc trưng và khả năng của mạng dựa trên IDS Bảy IDS đã được thử nghiệm bằng cách sử dụng một phương pháp hai giai đoạn Giai đoạn I bao gồm các cuộc tấn công tương đối đơn giản bằng cách sử dụng các công cụ như SATAN Giai đoạn này đã cho IDS khai thác một cơ hội để làm quen với các IDS khác, và cho những kẻ tấn công một cơ hội để thực hành tấn công các hệ thống Giai đoạn II được thiết kế để mô phỏng một cuộc tấn công được xác định, liên quan đến các cuộc tấn công tàng hình cả đơn giản và phức tạp hơn Kết quả tính được tạo ra là khả năng thời gian cảnh báo; báo cáo năng lực; phân tích khả năng off- line; khả năng phản ứng; và hệ thống quản lý từ xa
Những phân tích điểm yếu tiết lộ trong việc thực hiện và ổn định của một số hệ thống kiểm thử Hai trong số các hệ thống thương mại được thử nghiệm phát hiện nhiều cuộc tấn công cấp độ thấp hơn so với ba hệ thống chính quyền phát triển, có lẽ vì họ có nhiều chữ ký hơn cho các cuộc tấn công Tuy nhiên hệ thống chính phủ phát triển đã phù hợp hơn để phát hiện và phân tích các cuộc tấn công cấp cao thực hiện trong phiên tương tác Những kẻ tấn công với kiến thức nhất định của các chữ ký được sử dụng trong IDS, đã có thể tạo ra các cuộc tấn công tàng hình không phát hiện được
Từ năm 1999, tạp chí Network Computing đã tài trợ đánh giá các sản phẩm phát hiện xâm nhập thương mại của Neohapsis Laboratories Các đánh giá gần đây nhất bao gồm 13 IDS thương mại và các mã nguồn mở Snort IDS Kết quả định tính tập trung vào đặc điểm thực tế bao gồm cả tính năng dễ sử dụng khung quản lý, ổn định, chi phí hiệu quả, chất lượng chữ ký / chiều sâu, và dễ dàng tùy biến Kết quả định lượng bao gồm số lượng các cuộc tấn công được phát hiện và đôi khi mức độ dung lượng tối đa có thể được xử lý trước khi IDS bắt đầu bỏ các gói dữ liệu, không thực hiện việc kiểm tra chữ ký, hoặc phân mảnh các gói dữ liệu bị thất bại
Nhóm NSS đánh giá IDS và quét các lỗ hổng trong năm 2000 và 2001 Các báo cáo của năm 2001 đánh giá IDS bao gồm 15 sản phẩm IDS thương mại và mã nguồn mở Snort IDS Phần lớn các báo cáo này trình bày chi tiết thông tin cho mỗi IDS trên kiến trúc của nó, dễ dàng cài đặt và cấu hình Mười hai IDS được so sánh bằng cách sử dụng 18 hoặc 66 lỗ hỗng phổ biến có sẵn bao gồm quét cổng, DoS, Distributed DoS, Trojans, Web, FTP, SMTP, POP3, ICMP, và các cuộc tấn công Finger Các cuộc tấn công chỉ được tính là phát hiện khi họ đã được báo cáo "càng đơn giản và rõ ràng càng tốt." Tỷ lệ phát hiện tấn công được đo trên 100 M bit / s , mạng với không có lưu lượng tin và lưu lượng nhỏ (64 byte) trong thế giới thực, và lưu lượng lớn
(1514 byte) các gói tin tiêu thụ lần lượt các giá trị 0%, 25%, 50%, 75% và 100% băng thông mạng
Một xem xét hạn chế hơn trong năm IDS thương mại đã được báo cáo bởi Tạp chí Network World Fusion Đánh giá này đã thảo luận tính năng dễ dàng thiết lập cũng như sử dụng, nhưng nó cũng đánh giá độ phát hiện chính xác sử dụng 27 tấn
20 | P a g e công phổ biến đưa ra đối với ba máy tính nạn nhân Những cuộc tấn công web tàng hình được tạo ra bằng cách sử dụng công cụ tấn công “whisker”.
Những thách thức của Testing IDS
Có một số khía cạnh của các IDS khiến cho việc đánh giá IDS trở nên nhiều thách thức hơn Cụ thể được trình bày dưới đây
1.4.1 Những khó khăn trong việc thu thập Scripts tấn công và phần mềm Victim
Một vấn đề mà đã kìm hãm sự tiến bộ trong lĩnh vực này là khó khăn trong việc thu thập kịch bản tấn công và phần mềm nạn nhân Để thu thập một lượng lớn số kịch bản tấn công là một việc khó khăn và tốn kém Trong khi kịch bản như vậy là phổ biến rộng rãi trên Internet, nhưng vẫn phải mất thời gian để tìm thấy kịch bản có liên quan đến một môi trường thử nghiệm cụ thể Khi một kịch bản được xác định, với một người có kinh nghiệm vững chắc cũng phải mất khoảng một tuần để xem xét các mã, kiểm tra khai thác, xác định nơi các cuộc tấn công bỏ sót bằng chứng, tự động hóa các cuộc tấn công, và tích hợp nó vào một môi trường thử nghiệm Như thể hiện trong Bảng 1, số lượng các kiểu tấn công được sử dụng trong đánh giá thực thi năm
2001 trong phạm vi từ 9 đến 66 Một vấn đề liên quan đó là rất khó khăn (nhưng dường như cần thiết) để thu thập phần mềm nạn nhân phù hợp có liên kết với mỗi kịch bản tấn công Thường thì các kịch bản khác nhau chỉ làm việc với số phiên bản rất cụ thể của phần mềm điều này rất khó khăn để đạt được
Bản thân phần mềm cũng có thể khó khăn để có được bởi vì chi phí đắt hoặc có thể là các phần mềm không thực sự công khai Ngoài ra, phiên bản phần mềm cũ hơn dễ bị tổn thương cũng không dễ dàng có được từ các nhà cung cấp Phần mềm dễ bị tổn thương là rất cần thiết cho những đánh giá và các gói tin tấn công có thể không chỉ đơn giản đưa vào một IDS Nếu không có thông tin về các tính năng được sử
21 | P a g e dụng để phát hiện các cuộc tấn công, cách duy nhất để xác định xem một cuộc tấn công được phát hiện là chạy thành công cuộc tấn công đó
1.4.2 Những yêu cầu khác biệt cho những đánh giá IDS dạng Signature Based và
Mặc dù hầu hết các hệ thống phát hiện xâm nhập thương mại là Signature
Based, nhưng nhiều hệ thống nghiên cứu lại là Anomaly Based, và nếu một phương pháp thử nghiệm IDS có thể làm việc cho cả hai thì nó sẽ là ý tưởng tốt Điều này đặc biệt quan trọng từ khi chúng tôi muốn so sánh hiệu suất của hệ thống nghiên cứu sắp tới để những hệ thống thương mại hiện có
Tuy nhiên, việc tạo ra một đánh giá duy nhất để bao gồm cả hai loại hệ thống đặt ra một số vấn đề Hệ thống Anomaly Based yêu cầu lưu lượng tin thông thường cho quá trình tập huấn mà không bao gồm các cuộc tấn công Theo MIT / LL 1999 đánh giá, kiểu dữ liệu tập huấn đặc biệt này cung cấp để đào tạo các hệ thống phát hiện bất thường (Anomaly ), nhưng nó không có sẵn cho các đánh giá khác Hệ thống
Anomaly Based cũng có thể tìm hiểu các thành phần lạ của phương pháp đánh giá và qua đó thực hiện tốt mà không thực sự phát hiện thấy bất kỳ cuộc tấn công thực sự nào Điều này có thể xảy ra khi tất cả các cuộc tấn công trong một thử nghiệm được phát động từ một user cụ thể, địa chỉ IP, subnet hoặc địa chỉ MAC Tuy nhiên, hệ thống Anomaly có thể tìm hiểu các đặc điểm tế nhị mà khó xác định trước như kích thước cửa sổ gói tin, cổng, tốc độ đánh máy, lệnh set được sử dụng, cờ TCP, hoặc thời hạn kết nối mà cho phép chúng thực hiện một cách giả tạo khá tốt trong các môi trường kiểm thử Trong khi đó mỗi IDS Signature Based lại phát hiện một tập hợp các cuộc tấn công cụ thể
1.4.3 Những yêu cầu khác biệt cho những đánh giá IDS Network Based với Host
Based Đánh giá các IDS host based đặt ra một số khó khăn mà không có khi đánh giá IDS network based Đặc biệt, IDS network based có thể được kiểm tra offline bằng cách tạo ra một tập tin log có chứa lưu lượng TCP và sau đó phát lại lưu lượng này tới các IDS Đây là một điểm thuận lợi bởi tất cả các IDS không phải test tại cùng một thời điểm, và việc lặp lại test cũng dễ làm được
Mặt khác, các IDS host based sử dụng một loạt các yếu tố đầu vào hệ thống để xác định một hệ thống có đang bị tấn công hay không Tập các yếu tố đầu vào này thay đổi giữa các IDS Ngoài ra, IDS host based được thiết kế để theo dõi một máy chủ trái ngược với một nguồn cấp dữ liệu duy nhất ( giống như IDS network based) Điều này trở nên khó khăn để hoạt động lại từ các tập tin log trong danh sách để test một IDS host based
1.4.4 Các phương pháp tiếp cận tới việc sử dụng Background Traffic trong đánh giá IDS i Đánh giá không sử dụng background traffic/logs
Trong thí nghiệm này, một IDS được thiết lập trên một máy chủ hoặc máy mạng mà không hoạt động Sau đó, các cuộc tấn công máy tính của bạn khởi động trên máy chủ hoặc máy mạng này để xác định các IDS có thể phát hiện các cuộc tấn công hay không Kỹ thuật này có thể xác định một tỷ lệ hit IDS nhưng có thể không nói gì về tình trạng dương tính giả Ưu điểm, Cách tiếp cận này rất hữu ích cho việc xác minh rằng một IDS có dấu hiệu cho một tập hợp các cuộc tấn công và rằng IDS có thể dán nhãn đúng cho mỗi tấn công đó Hơn nữa cách tiếp cận này thường ít tốn kém trong việc thực thi hơn so với cách tiếp cận thư viện, hoặc tạo ra background traffic or logs
Tuy nhiên, một nhược điểm là test bằng cách sử dụng chương trình này được dựa trên giả thuyết tiềm ẩn rằng một khả năng IDS phát hiện tấn công là như nhau trên bất kể hoạt động background nào ii Đánh giá sử dụng traffic/logs thực Đây là một phương pháp rất hiệu quả để xác định tỷ lệ hit (tỉ lệ bắt đúng) của một IDS cho một mức độ cụ thể của hoạt động background Đánh giá tỷ lệ hit sử dụng trong kỹ thuật này có thể được đón nhận bởi vì các hoạt động background là có thật và nó chứa tất cả các hoạt động background bất thường và tinh tế Hơn nữa, kỹ thuật này cho phép so sánh các tỷ lệ hit của IDS ở các cấp độ khác nhau
Tuy nhiên, có một số mặt hạn chế để sử dụng kỹ thuật này:
• Phần cứng hiện nay có nhiều khó khăn trong việc phát lại các gói dữ liệu mạng với tốc độ hơn 100 Mb / giây và cố gắng song song hóa kết quả tiến trình này trong các vấn đề sắp xếp trình tự gói tin
• Những thí nghiệm này thường sử dụng một tập hợp nhỏ các máy tính nạn nhân được thiết lập cho mục đích duy nhất là bị tấn công trong thời gian thử nghiệm Một số IDS có thể phát hiện rằng chỉ một số máy bị tấn công và do đó nâng cao một cách giả tạo hiệu năng đánh giá của chúng
• Các hoạt động background thực được sử dụng có thể bao gồm một số bất thường trên mạng, bằng cách nào đó có lợi cho một IDS hơn các IDS khác Điều này có thể xảy ra nếu một mạng thử nghiệm sử dụng giao thức cụ thể được tiến hành sâu hơn bởi một IDS cụ thể IDS xử lý một giao thức chính sau đó có thể bỏ lỡ các cuộc tấn công mà nó phát hiện được.
Giải pháp nghiên cứu đánh giá IDS
1.5.1 Chia sẻ bộ dữ liệu
Có một nhu cầu lớn về bộ dữ liệu đánh giá IDS mà có thể được chia sẻ cởi mở giữa nhiều tổ chức Hiện tại bộ dữ liệu đã được sử dụng thường xuyên bởi các nhà nghiên cứu Nếu không có sự chia sẻ bộ dữ liệu, các nhà nghiên cứu IDS hoặc là phải tiêu hao tài nguyên khổng lồ để tạo bộ dữ liệu độc quyền hoặc là sử dụng bộ dữ liệu khá đơn giản và hạn hẹp cho quá trình đánh giá của họ
1.5.2 Về dấu vết tấn công Ở phần trước chúng tôi đã chỉ ra rằng việc thu thập một lượng lớn các kịch bản tấn công cho mục đích đánh giá là rất khó khăn và tốn kém Chúng ta có thể sử dụng một biện pháp thay thế là sử dụng dấu vết tấn công thay vì dùng tới cuộc tấn công thực sự
Dấu vết tấn công là các tập tin log mà được tạo ra khi một cuộc tấn công được đưa ra và nó xác định chính xác những gì đã xảy ra trong cuộc tấn công Dấu vết như vậy thường bao gồm các tập tin có chứa các gói tin mạng hoặc hệ thống các file tương ứng với một thể hiện của một cuộc tấn công Chúng tôi cần một sự hiểu biết tốt hơn về những lợi thế và bất lợi của việc phát lại các dấu vết đó giống như một một phần của một đánh giá IDS Ngoài ra, có một nhu cầu rất lớn về bộ các dấu vết tấn công để cung cấp bảo mật cho cộng đồng mạng Thông tin như vậy có thể dễ dàng được thêm vào cơ sở dữ liệu hiện có Kết quả là dấu vết cơ sở dữ liệu tổn thương / tấn công có thể giúp các nhà nghiên cứu đánh giá IDS và cũng sẽ cung cấp dữ liệu có giá trị cho các nhà phát triển IDS
1.5.3 Dọn dẹp dữ liệu thực
Dữ liệu thực tế thường không thể được phân phối do các vấn đề riêng tư và nhạy cảm Phương pháp này dùng để loại bỏ các dữ liệu bí mật trong background traffic trong khi vẫn giữ được các tính năng cần thiết của traffic để có thể cho phép sử dụng dữ liệu như vậy trong bài đánh giá IDS Một bước tiến như thế sẽ làm giảm bớt sự cần thiết cho
25 | P a g e các nhà nghiên cứu trong việc dành nhiều công sức tạo ra các môi trường mô phỏng với chi phí cao
1.5.4 Bộ dữ liệu báo động cảm biến
Một số hệ thống xâm nhập tương quan không sử dụng một dòng dữ liệu thô (như mạng hoặc dữ liệu kiểm toán) là đầu vào Nhưng thay vì dựa vào các cảnh báo và thông tin tổng hợp báo cáo từ IDS, chúng ta cần phải phát triển các hệ thống có thể tạo ra các tập tin log cảnh báo thực tế cho hệ thống đánh giá tương quan Một giải pháp là triển khai các cảm biến thực tế và cải thiện dòng cảnh báo kết quả bởi việc thay thế địa chỉ IP
1.5.5 Sử dụng công nghệ mới
Công nghệ phát triển mới trong IDS bao gồm công nghệ “ meta-IDS” ; “IDS appliances” ; và công nghệ “Application-layer”
• Công nghệ “ meta-IDS” cố gắng giảm bớt gánh nặng về quản lý dữ liệu nhà cung cấp phải vượt qua
• “IDS appliances” hứa sẽ tăng khả năng quản lý từ xa mạnh mẽ hơn
• Công nghệ “Application-layer” sẽ lọc lưu lượng tấn công tiềm năng để scanner trên phân đoạn mạng chuyên dụng
Những hướng phát triển mới tập trung vào các công nghệ mới cho các doanh nghiệp hoặc nhà cung cấp dịch vụ và ví dụ đại diện của các nỗ lực nghiên cứu nhằm giải quyết những khó khăn của dương tính giả, tắc nghẽn lưu lượng truyền, và các cuộc tấn công nghiêm trọng từ các cảnh báo phiền phức
KHÁI QUÁT VỀ FTESTER
Giới thiệu Ftester
Ftester là một công cụ dùng để kiểm tra firewall và IDS Ftester gồm hai perl script là ftest và ftestd Trong khi ftest đọc config file và gửi đi các gói tin chứa mã độc, ftestd đóng vai trò một sniffer được đặt sau firewall Việc so sánh các gói tin phát đi và nhận được có thể đánh giá được hiệu xuất của một firewall Ftest và ftestd có thể được kết hợp với nhau để tạo nên các stateful traffic, do đó có thể dùng để test các stateful IDS và firewall.
Thành phần
Ftester gồm hai script Perl
Script ftest đc sử dụng để đưa vào các gói tuỳ ý như được định nghĩa trong file cấu hình ftest.conf Nếu bạn test cách hoạt động của firewall với lưu lượng vào, bạn nên chạy script này trên một máy tính bên ngoài mạng thiết lập firewall Nếu bạn muốn test các hoạt động của firewall đối với lưu lượng ra bạn sẽ cần chạy ftest từ một máy tính trong mạng được bảo vệ bằng firewall của bạn
Một kiểu script khác là ftestd lắng nghe để tìm các gói được đưa vào bằng ftest đi qua firewall mà ban đang test Bạn nên chạy script này trên một máy trong mạng nội bộ nếu bạn test hành vi đi vào của firewall Nếu bạn test hành vi đi ra, bạn sẽ cần chạy nó trên một máy bên ngoài mạng Cả hai script này ghi những gì mà chúng gửi hoặc nhận Sau khi chạy thử, các log tương ứng của chúng có thể được so sánh bằng cách sử dụng script freport để thấy nhanh các gói nào đã có thể đi qua firewall.
Hoạt động
Trước khi sử dụng Fteser bạn cần có một số Môđun Perl như sau: RawIP,Pcap, PcapUtils, Netpacket Nếu bạn đã có Môđun Perl CPAN bạn có thể cài đặt bằng các lệnh sau:
#perl -MCPAN -e "install Net::RawIP"
#perl -MCPAN -e "install Net::PcapUtils"
#perl -MCPAN -e "install Net::Netpacket"
Khi đã chuẩn bị đồ nghề xong thì bạn cần tạo 1 file cấu hình để cho ftest biết các gói nào mà nó sẽ nhận
Sau đây là dạng chung cho một gói TCP hoặc UDP trong ftest.conf trong đó soucre addr và source port là địa chỉ và cổng IP nguồn và dest addr và dest port là địa chỉ và cổng IP đích:
Code: source addr.soucrce port.dest addr.dest port.flags.proto.tos Các dãy địa chỉ có thể được xác định theo định dạng low-high hoặc bằng cách sử dụng ký hiệu CIDR Bạn cũng có thể xác định bằng cách sử dụng định dạng low-high Trường flags là nơi bạn xác định các cờ TCP mà bạn muốn xác lập cho gói Các giá trị hợp lệ cho trường này là cho SYN, A cho ACK, P cho PSH, U cho URG, R cho RST và F cho FIN Trường proto xác định giao thức nào cần sử dụng (TCP or UDP) và ToS chứa số cần được xác lập cho trường Type-of-service (ToS) trong header IP Đôi khi các router sử dụng nội dung của trường này để đưa ra các quyết định về việc ưu tiên hoá lưu lượng
Bạn cũng có thể định nghĩa các gói ICMP theo một cách tương tự Sau đây là dạng chung cho 1 gói ICMP:
Code: source addr.:dest addr.::ICMP:type:code Nhìn ở trên ta thấy khá là phức tạp chứ nhìn kỹ lại thì bạn sẽ nhận ra sự khác biệt chính giữa 2 dạng là việc bỏ qua số cổng và cờ mà ICMP ko sử dụng Thay
28 | P a g e vào đó nó lại kết hợp với Type và code (do đó có sự bổ sung của các trường type và code) Hiện có hơn 40 loại ICMP Các loại ICMP dc sử dụng bởi tiện ích ping, type
8 (echo), type 0 (phản hồi dội), type 30 (traceroute) Các mã ICMP giống như những tập con của ICMP Không phải tất cả các loại ICMP đều có mã ICMP đi kèm mặc dù số mã ICMP gần như cùng số với số loại ICMP
Còn đây là phần chính muốn nói Đây là một ftest.conf kiểm tra tất cả cổng TCP có đặc quyền trên một máy tính có địa chỉ IP 10.1.1.1
192.168.1.10:1025:10.1.1.1.1-1024:S:TCP:0 stop=signal2.168.1.10:1025:10.1.1.1:22:S:TCP:0 stop_signal tạo một payload cho gói để cho ftestd biết rằng việc test đã kết thúc Để test nhanh có thể sử dụng tuỳ chọn -c và xác định một gói để gửi bằng cách sử dụng cú pháp trên VD: Lệnh sau đây gửi một gói có địa chỉ IP và cổng nguồn là 192.168.1.10:1025 đển cổng 22 trên 10.1.1.1.1
#./ftest -c 192.168.1.10:1025:10.1.1.1:22:S:TCP:0 Trước khi khởi động ftest bạn nên khởi động ftestd:
#./ftestd -i eth0 sau đó chạy ftest Code:
Lệnh này sẽ tạo 1 file Log có tên là ftest.log chứa 1 log của 1 gói mà ftest gửi Khi ftestd nhận tín hiệu dừng nó sẽ thoát, sau đó ta có thể tìm thấy log về những gói mà nó nhận trong ftestd.log
Bạn có thể sao chép các log sang một máy tính khác và chạy chúng thông qua freport Nếu bạn đã sử dụng một file cấu hình mà nhóm đã ví dụ ở trên và đã cho phép lưu lượng SSH, SMPTP và HTTP bạn có thể nhận đc 1 báo cáo tương tự như sau:
#./freport ftest.log ftestd.log
ỨNG DỤNG CỦA FTESTER TRONG ĐÁNH GIÁ IDS CỤ THỂ
Để hiểu rõ được ứng dụng của Ftester trong việc đánh giá hệ thống phát hiện xâm nhập cụ thể mời cô và các bạn xem Demo cụ thể của nhóm