Upload
tikivn
View
3.390
Download
19
Embed Size (px)
DESCRIPTION
Khóa luận 2008 - Khoa Đào Tạo Chất Lượng Cao - ĐH Sư Phạm Kỹ Thuật TP - HCM
Citation preview
i
Tp. Hồ Chí Minh, ngày … tháng … năm 2013
NHIỆM VỤ ỐT NGHIỆP
Họ và tên sinh viên: ................................................. MSSV: ......................................
Chuyên ngành: ........................................................ Lớp: .........................................
Giáo viên hướng dẫn: ................................................................................................
Ngày giao đề tài:.................................... Ngày nộp đề tài:........................................
1. Tên đề tài:
...............................................................................................................................................
...............................................................................................................................................
2. Các số liệu, tài liệu ban đầu
...............................................................................................................................................
...............................................................................................................................................
3. Nội dung thuyết minh và tính toán
...............................................................................................................................................
...............................................................................................................................................
...............................................................................................................................................
...............................................................................................................................................
...............................................................................................................................................
4. Sản phẩm
...............................................................................................................................................
...............................................................................................................................................
Trường Đại Học Sư Phạm Kỹ Thuật Tp.HCM
Khoa Đào Tạo Chất Lượng Cao
-----***----
Cộng Hòa Xã Hội Chủ Nghĩa Việt Nam
Độc lập – Tự do – Hạnh phúc
----***----
Trưởng ngành
Giáo viên hướng dẫn
ii
NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
Giáo viên hướng dẫn
iii
NHẬN XÉT CỦA GIÁO VIÊN PHẢN BIỆN
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
..................................................................................................................................................
Giáo viên phản biện
1
LỜI CẢM ƠN
Sau nhiều tháng tìm hiểu, nghiên cứu và cài đặt, đề tài “Tìm hiểu và xây dựng hệ
thống phòng chống và phát hiện xâm nhập sử dụng Snort/Snortsam” về cơ bản
đã hoàn thành. Trong thời gian thực hiện đề tài em đã nhận được nhiều sự giúp đỡ
từ bạn bè, các anh chị và thầy cô.
Em xin chân thành gửi lời cảm ơn đến sự giúp đỡ, sự động viên và ủng hộ tinh thần
của gia đình và bè bạn để hoàn thành đề tài này.
Em cũng xin chân thành cảm ơn quý thầy cô tại trường Đại học Sư Phạm Kỹ
Thuật Tp. Hồ Chí Minh, và Khoa Đào tạo Chất lượng cao đã tạo điều kiện cho
em được nghiên cứu và học tập. Đặc biệt em xin chân thành cảm ơn thầy Nguyễn
Đăng Quang đã luôn nhiệt tình nhắc nhở, đốc thúc em làm việc chăm chỉ, thầy chỉ
bảo và gửi em nhiều bài báo cáo để em có thể tham khảo và hoàn thành đề tài. Thầy
đã có những góp ý về cả nội dung và trình bày để em có thể hoàn thành bài báo cáo
một cách tốt nhất
Mặc dù đã rất cố gắng để hoàn thành đề tài một cách tốt nhất, nhưng chắc chắn đề
tài sẽ vẫn còn tồn tại những thiếu sót. Em luôn mong mỏi nhận được các góp ý, các
thảo luận về các vấn đề này.
Sinh viên thực hiện
Nguyễn Văn Quang
2
TÓM TẮT
Xây dựng hệ thống phòng chống và phát hiện xâm nhập là một giải pháp nhằm
nâng cao tính bảo mật của hệ thống. Xây dựng hệ thống phát hiện xâm nhập không
nhằm mục đích thay thế hệ thống tường lửa mà chỉ giúp bổ sung, thu thập thật nhiều
thông tin cho quá trình ngăn chặn các cuộc tấn công.
Ngoài các khái niệm, kỹ thuật phát hiện hiện xâm nhập của một hệ thống phát hiện
xâm nhập. Khóa luận còn tìm hiểu về một hệ thống phát hiện xâm nhập dựa trên
mạng là Snort và một mô-đun SnortSam kết hợp với iptables nhằm mục đích ngăn
chặn tấn công.
Mục tiêu chính của khóa luận là hiểu rõ nhất về cấu trúc của tập luật Snort. Hình
thành tư duy phân tích hệ thống thay vì triển khai hệ thống. Từ đó xây dựng ra các
tập luật cho những tình huống cụ thể của từng hệ thống.
Nội dung chính của khóa luận có thể chia thành 3 phần chính:
Phần 1: Bao gồm các nội dung chính về hệ thống phát hiện xâm nhập, mô hình, kỹ
thuật phát hiện…
Phần 2: Chi tiết kỹ thuật về hệ thống phát hiện xâm nhập mạng Snort/SnortSam.
Kiến trúc của hệ thống Snort, cấu trúc luật của Snort.
Phần 3: Phân tích một vài dạng tấn công, phân tích các luật tương ứng. Demo hệ
thống.
Từ khóa: phát hiện xâm nhập, hệ thống phát hiện xâm nhập, phát hiện dựa trên sự
bất thường, phát hiện dựa trên mẫu, Snort, SnortSam, SYN Flood, Apache Killer…
3
ABSTRACT
For enchanced security of system, we implement a intrusion detection system and
intrusion prevention system for our system. Deploy IDS/IPS don’t replace firewall
system so supplenment and collected many infomations for prevention attacks.
Graduation thesis is researched about define, intrusion detection technology of
intrusion detection system (IDS). It still is researched about Snort, SnortSam with
iptables for prevention attacks.
Main objectives of graduation thesis is system administrator have knowledge about
rule syntax, analytics system. Build own Snort rule for him system.
Content of graduation thesis include three main part:
Part 1: Intrusion detection, network diagram, intrusion detection technology.
Part 2: Snort/SnortSam, Snort architecture, Snort rule syntax.
Part3: Analytics a few attacks, analytics a few rules for attack and demo.
Keywords: intrusion detection, intrusion detection system, anomaly based intrusion
detection, misuse/signature based intrusion detection, Snort, SnortSam, SYN Flood,
Apache Killer.
4
MỤC LỤC
DANH MỤC HÌNH VẼ ..................................................................................................... 7
DANH MỤC TỪ VIẾT TẮT ............................................................................................ 9
PHẦN I: ĐẶT VẤN ĐỀ...................................................................................................10
PHẦN II: GIẢI QUYẾT VẤN ĐỀ ................................................................................... 3
CHƯƠNG 1: HỆ THỐNG PHÁT HIỆN XÂM NHẬP (IDS) ...................................... 5
1.1. Giới thiệu .................................................................................................................. 5
1.2. Hệ thống phát hiện xâm nhập là gì? ...................................................................... 5
1.2.1. Network-based IDS........................................................................................... 7
1.2.2. Host-based IDS.................................................................................................. 8
1.3. Các kỹ thuật phát hiện xâm nhập ........................................................................10
1.3.1. Anomaly Based Intrusion Detection .............................................................10
1.3.2. Misuse/Signature Based Intrusion Detection...............................................12
1.4. Đặt IDS trong hệ thống mạng...............................................................................13
CHƯƠNG 2: GIỚI THIỆU VỀ SNORT/SNORTSAM ...............................................15
2.1. Snort là gì? ..............................................................................................................15
2.2. Triển khai hệ thống Snort .....................................................................................15
2.2.1. Yêu cầu phần cứng ..........................................................................................16
2.2.2. Hệ điều hành và các gói phần mềm khác .....................................................17
2.3. Đặc điểm của Snort................................................................................................17
2.3.1. Packet Sniffer (Decoder) ................................................................................19
2.3.2. Preprocessors ...................................................................................................20
2.3.3. Detection Engine .............................................................................................21
5
2.3.4. Thành phần cảnh báo/logging........................................................................23
2.4. Các chế độ hoạt động của Snort ...........................................................................24
2.4.1 Chế độ sniffer và chế độ log ...........................................................................24
2.4.2 Chế độ NIDS .....................................................................................................25
2.5. Giới thiệu về SnortSam .........................................................................................26
2.5.1. Snort Output Plug-in .......................................................................................27
2.5.2. Blocking Agent ................................................................................................28
CHƯƠNG 3: PREPROCESSORS VÀ OUTPUT PLUG-INS....................................30
3.1. Preprocessors ..........................................................................................................30
3.1.1. Frag3 .................................................................................................................31
3.1.2. Stream5 .............................................................................................................35
3.1.4. HTTP Inspect ...................................................................................................39
3.2. Output ......................................................................................................................40
CHƯƠNG 4: LUẬT TRONG SNORT ..........................................................................42
4.1. Rule Header ............................................................................................................43
4.1.1. Rule Action ......................................................................................................43
4.1.2. Protocol.............................................................................................................44
4.1.3. IP Address ........................................................................................................44
4.1.4. Port ....................................................................................................................44
4.1.5. Điều hướng.......................................................................................................45
4.1.6. Activate/Dynamic rule ....................................................................................45
4.2. Rule Options ...........................................................................................................46
4.2.1. General ..............................................................................................................46
4.2.2. Payload .............................................................................................................48
6
4.2.3. Non-Payload ....................................................................................................51
4.2.3. Post-detection ..................................................................................................57
CHƯƠNG 5: PHÂN TÍCH MỘT SỐ LUẬT TRONG SNORT .................................61
5.1. Khảo sát luật scan ..................................................................................................61
5.2 Win.Trojan.Ibabyfa.dldr .........................................................................................64
5.3. TCP-SYN Flood .....................................................................................................65
5.4 Apache Killer (CVE-2011-3192) ..........................................................................67
CHƯƠNG 6: CÀI ĐẶT VÀ CẤU HÌNH SNORT .......................................................71
6.1 Sơ đồ hệ thống .........................................................................................................71
6.2. Cài đặt Snort và SnortSam ....................................................................................72
6.3. Thử nghiệm các kiểu tấn công .............................................................................83
KẾT QUẢ ĐẠT ĐƯỢC ...................................................................................................86
PHẦN KẾT LUẬN ...........................................................................................................88
TÀI LIỆU THAM KHẢO................................................................................................91
7
DANH MỤC HÌNH VẼ
Hình 1.1: OSSEC được triển khai trên các Server. ..................................................... 9
Hình 1.2: Các mẫu khác thường. .................................................................................10
Hình 1.3: Phân tích chuyển trạng thái.........................................................................12
Hình 1.4: Các vị trí đặt IDS trong hệ thống mạng. ...................................................14
Hình 2.1: Kiến trúc của Snort. .....................................................................................18
Hình 2.2: Các gói tin đi vào Sniffer. ...........................................................................19
Hình 2.3: Giải mã gói tin. .............................................................................................20
Hình 2.4: Quá trình xử lí ở Preprocessors. .................................................................21
Hình 2.5: Gói tin được xử lý ở Detection Engine bằng các luật. ............................22
Hình 2.6: Thành phần cảnh báo và logging. ..............................................................24
Hình 3.1: Quá trình tiền xử lý. .....................................................................................31
Hình 3.2: Phân loại các hệ điều hành..........................................................................34
Hình 3.3: Ý nghĩa các tham số cấu hình toàn cục. ....................................................36
Hình 3.4: Ý nghĩa các tham số cấu hình TCP. ...........................................................38
Hình 3.5: Ý nghĩa các tham số cấu hình UDP. ..........................................................38
Hình 3.6: Ý nghĩa các tham số cấu hình ICMP. ........................................................38
Hình 3.7: Ý nghĩa các tham số cấu hình IP. ...............................................................38
Hình 4.1: Cấu trúc luật trong Snort. ............................................................................43
Hình 4.2: Bảng reference..............................................................................................47
Hình 4.3: Bảng ipopts. ..................................................................................................52
Hình 4.4: Bảng flag .......................................................................................................53
Hình 4.5: Bảng Type của ICMP Header.....................................................................55
8
Hình 4.6: Giá trị Code của ICMP Header ..................................................................56
Hình 4.7: Tham số của từ khóa detection_filter. .......................................................59
Hình 5.1: Giao thức bắt tay ba bước. ..........................................................................66
Hình 5.2: SYN Flood ....................................................................................................66
Hình 5.3: HTTP Request bình thường. .......................................................................68
Hình 5.4: HTTP Request tạo bởi Apache Killer........................................................68
Hình 6.1: Mô hình triển khai trong thực tế với một vùng DMZ. ............................71
Hình 6.2: Mô hình thực nghiệm. .................................................................................71
Hình 6.2: Bảng danh sách các máy trong hệ thống mạng. .......................................71
Hình 6.3: Mô hình xử lý của Snort, MySQL, Base...................................................72
9
DANH MỤC TỪ VIẾT TẮT
CNSS Committee on National Security Systems
IDS Intrusion Detection System
IPS Intrusion Prevention System
NIDS Netword-base IDS
HIDS Host-based IDS
ICMP Internet Control Message Protocol
IP Internet Protocol
TCP Transmission Control Protocol
UDP User Datagram Protocol
DoS Denial-of-Service
DDoS Distributed Denial-of-Service
GNU/GPL GNU General Public License
ACID Analysis Console for Intrusion Databases
BASE Basic Analysis and Security Engine
ISP Internet Service Provider
FDDI Fiber Distributed Data Interface
ACL Access Control List
HTTP Hypertext Transfer Protocol
10
PHẦN I
ĐẶT VẤN ĐỀ
1
Tính cấp thiết của đề tài.
Xã hội ngày càng phát triển, Internet trở thành một phần không thể thiếu đối với
từng cá nhân, doanh nghiệp, các tổ chức, trường học cũng như chính phủ. Internet
du nhập vào Việt Nam được hơn 15 năm, đã trở thành công cụ, phương thức giúp
cho các doanh nghiệp tiếp cận với khách hàng, cung cấp dịch vụ, quản lý dữ liệu
của tổ chức một cách hiệu quả và nhanh chóng.
Cùng với sự phát triển theo chiều hướng tốt, các cuộc tấn công và xâm nhập mạng
của những kẻ xấu cũng phát triển theo. Không chỉ trên thế giới mà ở Việt Nam vấn
đề “an toàn thông tin” đã và đang trở thành vấn đề nóng bỏng. Sự đa dạng và phức
tạp trong các loại hình tấn công đã gây ra nhiều khó khăn cho việc ngăn chặn và
phòng chống.
Thương mại điện tử ở Việt Nam càng phát triển thì càng trở thành mục tiêu của
nhiều attacker hơn. Thương mại điện tử đã trở thành mục tiêu có nhiều giá trị thu
lợi hơn, hấp dẫn các attacker bỏ nhiều công sức hơn trong việc xâm nhập và phá
hoại.
Một hệ thống phòng chống và phát hiện xâm nhập sẽ giúp người quản trị có thể
luôn luôn theo dõi và thu thập nhiều thông tin đáng giá cho quá trình chống lại các
hình thức tấn công và xâm nhập đó.
Mục tiêu nghiên cứu.
Nghiên cứu chung về hệ thống phát hiện xâm nhập, các đặc điểm, kiến trúc của một
hệ thống phát hiện xâm nhập, đặc biệt là các kỹ thuật phát hiện xâm nhập đang
được áp dụng.
Nghiên cứu về hệ thống phát hiện xâm nhập Snort, cách cài đặt, cấu hình, triển khai
trong hệ thống mạng.
Phân tích các dấu hiệu của các hình thức tấn công, hình thành nên các luật tương
ứng với đặc điểm của các dạng tấn công và xâm nhập đó
Nghiên cứu, triển khai SnortSam như một add-on của Snort nhằm chặn các cuộc
xâm nhập được chỉ định.
2
Đối tượng nghiên cứu.
Đối tượng nghiên cứu của đề tài là hệ thống phát hiện xâm nhập nói chung. Hệ
thống phát hiện xâm nhập Snort, add-ons của Snort là SnortSam.
Nghiên cứu và hình thành các tập luật đối với các dạng tấn công, xâm nhập cụ thể.
Phương pháp nghiên cứu.
Nghiên cứu về lý thuyết phát hiện xâm nhập thông qua các tài liệu các bài báo cáo.
Nghiên cứu lý thuyết về Snort thông qua tài liệu từ trang chủ của Snort, tài liệu
hướng dẫn cho người sử dụng từ Sourcefire và các nguồn tài liệu khác.
Nghiên cứu về SnortSam thông qua tài liệu và hướng dẫn sử dụng từ trang chủ của
SnortSam.
Triển khai hệ thống trên máy ảo Virtualbox, xây dựng hệ thống mạng đơn giản mô
tả một hệ thống mạng nhỏ trong thực tế. Triển khai các dịch vụ như trong mô hình
mạng cỡ nhỏ.
Tìm hiểu về các phương thức xâm nhập, tấn công và khai thác lỗ hổng, công cụ và
cách thức thực hiện.
Triển khai tấn công, xâm nhập, khai thác lỗ hổng. Sau đó đọc log, phân tích gói tin
bắt được, chuyển hóa thành các luật nhằm phát hiện và ngăn chặn.
3
PHẦN II
GIẢI QUYẾT VẤN ĐỀ
4
Nội dung
Các nội dung chính trong phần này bao gồm: hệ thống phát hiện xâm nhập, Snort,
SnortSam, cấu trúc và cách viết các luật trong Snort. Cài đặt triển khai Snort trong
hệ thống mạng, demo tấn công và phát hiện.
Chương 1, “Hệ thống phát hiện xâm nhập (IDS)”, tổng quan về hệ thống phát hiện
xâm nhập, kỹ thuật phát hiện xâm nhập, phân loại các hệ thống phá hiện xâm nhập.
Đặt hệ thống IDS trên hệ thống mạng như thế nào.
Chương 2, “Giới thiệu về Snort/S nortSam”.
Chương 3, “Preprocessors và Output Plug-ins”, tiền xử lý trong Snort và phần
output.
Chương 4, “Luật trong Snort”, cấu trúc của một luật trong Snort.
Chương 5, “Phân tích một số luật trong Snort”, trình bày một số dạng tấn công và
tập luật kèm theo.
Chương 5, “Cài đặt và cấu hình Snort/SnortSam”.
Chương 6, “Demo phát hiện xâm nhập và phòng chống dựa trên Snort/SnortSam”.
5
CHƯƠNG 1
HỆ THỐNG PHÁT HIỆN XÂM NHẬP (IDS)
1.1. Giới thiệu
Kỹ thuật phát hiện xâm nhập không phải là một kỹ thuật mới. Vì nó đã được áp
dụng nhiều trong các lĩnh vực khác nhau chứ không chỉ riêng lĩnh vực an toàn thông
tin của mạng máy tính. Ví dụ đơn giản nhất mà có thể thấy về kỹ thuật phát hiện
xâm nhập đó là hệ thống cảnh báo bằng chuông trên ô tô con. Nguyên lý hoạt động
rất đơn giản, hệ thống được bật nên và nếu có ai đó chạm vào chiếc ô tô thì còi sẽ
hú để cảnh báo rằng có kẻ đang xâm nhập.
Tương tự như các hệ thống tường lửa, hệ thống phát hiện xâm nhập được xây dựng
để bảo vệ các tài nguyên của hệ thống mạng trước những attacker không mong
muốn. Vậy tại sao lại cần một IDS trong khi đã có một hệ thống tường lửa rồi? Như
trong đề tài “Tìm hiểu về Firewall và triển khai trên ClearOS” ta đã biết rằng
giống như trong thế giới thực tường lửa được dựng lên giống như con người xây
tường, thuê vệ sĩ, mua khóa cửa để ngăn cản kẻ trộm xâm nhập vào hệ thống của
mình. Tuy nhiên dù có bảo vệ như thế nào cũng không đảm bảo rằng chúng ta có
thể biết hết các phương pháp mà kẻ trộm có thể tấn công được. Vì vậy ngoài hệ
thống ngăn chặn kẻ xâm nhập ra (tường lửa) còn có thể triển khai các hệ thống cảnh
báo như chuông báo động, camera quan sát, hệ thống cảnh báo...
Tương tự như vậy trong hệ thống mạng, không ai có thể chắc chắn rằng các phần
cứng và các chế độ bảo vệ khác có thể chặn được hết các cuộc tấn công cũng như
biết được hết các phương pháp của attacker. Chính vì vậy mà cần xây dựng một hệ
thống IDS để phát hiện các dấu hiệu bất thường, cảnh báo khi có biểu hiện bất
thường và giám sát các hoạt động ra vào hệ thống để phân tích và ngăn chặn kịp
thời (Monitor and Logging).
1.2. Hệ thống phát hiện xâm nhập là gì?
6
Theo định nghĩa trong tài liệu CNSSI-4009 của Ủy ban An ninh Quốc gia của Hoa
Kỳ thì “intrusion” nghĩa là “hành động truy cập trái phép bằng cách vượt qua cơ
chế bảo mật của hệ thống”.
“Computer Intrusion” là hành động cố tình truy cập vào một máy tính mặc dù
không có sự cho phép hoặc tìm cách vượt qua quyền truy cập (đã có) để có thêm
quyền truy cập vào các tài nguyên khác và thu thập thông tin.
“Intrusion Detection” là quá trình theo dõi các sự kiện xảy ra trong một hệ thống
máy tính hoặc trong một hệ thống mạng. Sau đó phân tích các dấu hiệu của các sự
cố có thể xảy ra. Các sự cố đó có thể là hành động vi phạm các chính sách bảo mật
hoặc các tiêu chuẩn về an ninh của hệ thống hoặc cũng có thể là các mối đe dọa đến
hệ thống của doanh nghiệp. Nguyên nhân xảy ra các sự cố này có thể là do các phần
mềm độc hại như virus, worm, trojan, spyware... cũng có thể là hành động cố ý xâm
nhập từ Internet hoặc vượt quá quyền truy cập thông thường. Tuy vậy cũng có
những nguyên nhân khách quan ví dụ như người sử dụng gõ nhầm địa chỉ của một
máy tính và cố gắng truy cập vào một hệ thống mà mình không được phép.
Intrusion Detection Systems (IDS) có thể là một thiết bị phần cứng (các thiết bị
phát hiện xâm nhập của Cisco (Cisco IDSM-2 hoặc Cisco IPS 4200 Series
Sensors)) hoặc cũng có thể là một ứng dụng phần mềm giúp giám sát máy tính, hệ
thống mạng trước các hành động đe dọa đến hệ thống hoặc vi phạm chính sách an
ninh và báo cáo lại cho người quản trị hệ thống. Một hệ thống phát hiện xâm nhập
cài đặt trên hệ thống mạng giống như một hệ thống cảnh báo chống trộm (burglar
alarm) trong một ngôi nhà.
Một số hệ thống phát hiện xâm nhập còn kiêm luôn cả chức năng ngăn chặn các
mối đe dọa đó tuy nhiên điều đó có thể không cần thiết và cũng không phải là chức
năng chính của của một hệ thống giám sát.
Một hệ thống phát hiện xâm nhập cơ bản sẽ “xác định” các mối nguy hại, “ghi” lại
thông tin về chúng và sau đó “báo cáo” lại các thông tin đó.
Nói ngắn gọn về chức năng của một hệ thống phát hiện xâm nhập đó là “giám sát”
(lưu lượng mạng), “cảnh báo” (báo cáo tình trạng mạng cho hệ thống và người quản
7
trị), “bảo vệ” (dùng các thiết lập mặc định và cấu hình từ người quản trị mà có
những hành động chống lại sự xâm nhập)
IDS có thể được phân loại theo chức năng thành 2 loại là Network-based IDS và
Host-based IDS. Mỗi loại có một cách tiếp cận riêng biệt để theo dõi và bảo vệ dữ
liệu và mỗi loại cũng có những ưu nhược điểm riêng.
1.2.1. Network-based IDS
Hệ thống phát hiện xâm nhập dựa trên mạng hoạt động như một thiết bị độc lập trên
mạng. Nó thường được đặt ở các segment mạng hoặc các điểm kết nối giữa các
vùng mạng khác nhau. Nhờ đó nó có thể giám sát lưu lượng mạng từ nhiều host
khác nhau trong vùng mạng đó. NIDS có thể là một thiết bị phần cứng hoặc phần
mềm.
Về cấu trúc thì NIDS thường bao gồm một tập hợp các cảm biến (sensors) được
đặt ở các điểm khác nhau trong hệ thống mạng. Các cảm biến này sẽ thực hiện giám
sát lưu lượng mạng, thực hiện phân tích cục bộ lưu lượng mạng đó và báo cáo về
cho trung tâm quản lý (Center Management Console).
Một số NIDS: Snort, Suricata, các NIDS của Cisco, Juniper...
Ưu điểm của NIDS:
Quản lý được cả một network segment (gồm nhiều host). Chi phí thấp vì
có thể giám sát cả một hệ thống mạng lớn với chỉ vài thiết bị (mạng được
thiết kế tốt).
“Trong suốt” đối với cả người dùng và các attacker.
Cài đặt và bảo trì đơn giản, không ảnh hưởng tới mạng.
Nhược điểm của NIDS:
NIDS có thể gặp khó khăn trong việc xử lý tất cả các gói tin trên một
mạng có kích thước lớn và mật độ lưu thông cao. Điều này dẫn đến NIDS
có thể sẽ không thể phát hiện ra một cuộc tấn công khi mạng đang ở trạng
thái over-whelming (quá tải).
8
Bị hạn chế bởi switch. Trên các mạng chuyển mạch hiện đại, các switch
được sử dụng nhiều để chia mạng lớn thành các segment nhỏ để dễ quản
lý. Vì thế dẫn đến NIDS không thể thu thập được thông tin trong toàn hệ
thống mạng. Do chỉ kiểm tra trên segment mà nó kết nối trực tiếp nên nó
không thể phát hiện tấn công trên một segment khác. Vấn đề này dẫn đến
việc doanh nghiệp phải mua một số lượng lớn cảm biến nếu muốn bao
phủ toàn hệ thống mạng của họ, làm tăng chi phí.
NIDS không thể phân tích được các thông tin đã bị mã hóa (SSL, SSH...).
Một số hệ thống NIDS có thể gặp khó khăn với dạng tấn công phân mảnh
gói dự liệu (fragmenting packets).
NIDS không thể phân biệt được một cuộc tấn công thành công hay thất
bại. Nó chỉ có thể phân biệt được có một cuộc tấn công đã được khởi
xướng. Điều này nghĩa là để biết được cuộc tấn công đó thành công hay
thất bại người quản trị phải điều tra các máy chủ và xác định nó có bị
xâm nhập hay không?
1.2.2. Host-based IDS
Hệ thống phát hiện xâm nhập dựa trên máy chủ hoạt động trên một máy trạm đơn.
HIDS sẽ sử dụng các tài nguyên của máy chủ đó để theo dõi lưu lượng truy cập và
phát hiện các cuộc tấn công nếu có. Bằng cách này HIDS có thể theo dõi được tất cả
các hoạt động trên host đó như tập tin log và những lưu lượng mạng ra vào host đó.
Ngoài ra nó còn theo dõi hệ điều hành, lịch sử sổ sách, các thông điệp báo lỗi của
máy chủ.
Không phải hầu hết các cuộc tấn công đều thông qua hệ thống mạng, nên không
phải lúc nào NIDS cũng có thể phát hiện được cuộc tấn công trên một host. Ví dụ,
kẻ tấn công có quyền physical access, từ đó có thể xâm nhập vào host đó mà không
cần tạo ra bất cứ network traffic nào.
Một ưu điểm của HIDS so với NIDS đó là nó có thể ngăn chặn các cuộc tấn công
phân mảnh (Fragmentation Attacks). Bởi vậy nên HIDS thường được cài đặt trên
9
các trên các máy chủ xung yếu của tổ chức, các server trong vùng DMZ (do là mục
tiêu tấn công chính).
HIDS cũng thường theo dõi những gì thay đổi trên hệ thống như các thuộc tính của
hệ thống tập tin, các thuộc tính (kích thước, vị trí, quyền…) của tập tin, phát hiện
tập tin mới được tạo ra hay xóa đi.
Một số HIDS: Symantec ESM, OSSEC, Tripwire ...
Hình 1.1: OSSEC được triển khai trên các Server.
Ưu điểm của HIDS:
■ Phát hiện các cuộc tấn công nên các máy chủ mà NIDS không thể phát
hiện ra.
■ Có thể giám sát các luồng traffic đã bị mã hóa.
■ Không bị ảnh hưởng bởi các thiết bị chuyển mạch (switch).
Nhược điểm của HIDS:
■ Khó quản lý hơn do phải cài lên tất cả các host cần bảo vệ nên việc cấu
hình, quản lý, cập nhật là một khối lượng lớn công việc cần thực hiện.
■ NIDS không thể phát hiện việc quét mạng (network scan bằng nmap) do
chỉ giám sát trên host mà nó được cài đặt.
■ Có thể bị vô hiệu hóa bởi tấn công từ chối dịch vụ (DoS).
10
■ Chiếm tài nguyên hệ thống: Do cài đặt trên máy cần bảo vệ nên nó sẽ sử
dụng tài nguyên của hệ thống như RAM, CPU, Hard Disk dẫn đến có thể
làm giảm hiệu suất của việc giám sát.
■ HIDS sẽ “chết” khi hệ điều hành của host đó bị “chết”.
1.3. Các kỹ thuật phát hiện xâm nhập
Ở phần này sẽ tìm hiểu về những kỹ thuật được sử dụng trên IDS để phát hiện ra
các cuộc xâm nhập. Về cơ bản có 2 kỹ thuật được sử dụng để phát hiện sự xâm
nhập đó là:
Phát hiện sự bất thường (Anomaly Based ID)
Phát hiện sự lạm dụng/dấu hiệu (Misuse/Signature Based ID).
1.3.1. Anomaly Based Intrusion Detection
Đầu tiên, “dị thường” (anomaly) còn được biết đến như sự sai khác, sự riêng biệt
với những mẫu có sẵn trong dữ liệu hoặc không phù hợp với những khái niệm, hành
vi thông thường của hệ thống. Hình dưới là một ví dụ về sự khác thường của O1,
O2, O3 về cả hành vi và cấu tạo so với N1 và N2.
Hình 1.2: Các mẫu khác thường.
Kỹ thuật phát hiện dựa trên sự bất thường được thiết kế nhằm phát hiện các “mẫu
hành vi” (patterns of behavior) khác xa với những hành vi thông thường sau đó gắn
cờ là có thể xâm nhập đối với những hành vi này.
Ưu điểm:
11
■ Một IDS được xây dựng dựa tên kỹ thuật phát hiện bất thường có thể phát
hiện ra các hành vi “không bình thường” và do đó nó có thể phát hiện ra
triệu chứng của các cuộc tấn công mà không cần biết chi tiết, cụ thể về
loại tấn công đó. Nói đơn giản là nó có thể phát hiện ra các cuộc tấn công
chưa từng được biết đến.
■ Phát hiện sự bất thường có thể được sử dụng để cung cấp các thông tin,
mà các thông tin này có thể được xây dựng các dấu hiệu (signature) sử
dụng trong kỹ thuật misuse detector.
Nhược điểm:
■ Phương pháp tiếp cận sự bất thường thường tạo ra một số lượng lớn các
báo động sai do không thể đoán được hành vi của người sử dụng và hệ
thống mạng.
■ Phương pháp tiếp cận sự bất thường yêu cầu phải thường xuyên được
“đào tạo” từ các bản ghi của hệ thống nhằm biết được đâu là các hành vi
bình thường.
Phát hiện xâm nhập dựa trên sự bất thường rất hữu hiệu trong việc phát hiện các
cuộc tấn công như:
■ Lạm dụng giao thức và cổng dịch vụ.
■ Tấn công từ chối dịch vụ.
■ Buffer Overflow.
Các biện pháp và kỹ thuật được sử dụng trong phát hiện bất thường bao gồm:
■ Phát hiện giao thức bất thường (Protocol Anomaly Detection). Giao thức
bất thường nghĩa là những trường hợp vi phạm các định dạng, các tiêu
chuẩn các hành vi đã được quy định thành chuẩn Internet từ trước đó. Ví
dụ: Kích thước gói tin ICMP tối đa là 65,535 bytes attacker cố tình gửi
một gói tin có kích thước lớn hơn kích thước tiêu chuẩn đó nhằm gây ra
lỗi tràn bộ đệm.
12
■ Phát hiện xâm nhập dựa trên quá trình tự học: Quá trình này gồm 2 bước,
bước 1 sau khi hệ thống được thiết lập thì cho hệ thống chạy tự do và tạo
hồ sơ về các hoạt động mạng với trạng thái bình thường. Sau thời gian
khởi tạo, hệ thống sẽ đi vào quá trình làm việc, hệ thống sẽ tiến hành theo
dõi và phát hiện các hoạt động bất thường dựa trên việc so sánh trạng thái
hiện tại với trạng thái hồ sơ được tạo.
■ Phát hiện xâm nhập dựa trên sự thống kê bất thường (Statistical Anomaly
Based Intrusion Detection). Kỹ thuật này nhấn mạnh việc đo đếm các hoạt
động bình thường trên mạng. Ví dụ đăng nhập quá số lần quy định, số tiến
trình hoạt động quá mức trên CPU, số lượng gói tin được gửi quá mức…
1.3.2. Misuse/Signature Based Intrusion Detection
Bằng cách so sánh dấu hiệu của các đối tượng đang quan sát với dấu hiệu của các
hình thức xâm nhập đã biết trước. Hai kỹ thuật được sử dụng trong phương phát
phát hiện xâm nhập dựa trên dấu hiệu là:
■ Expression matching (biểu thức phù hợp).
■ State transition analysis (phân tích chuyển trạng thái).
Hình 1.3: Phân tích chuyển trạng thái.
13
Ưu điểm:
■ Ít báo sai và đặc biệt là rất hiệu quả đối với các hình thức xâm nhập đã
được biết đến.
■ Nhanh chóng và đáng tin cậy trong việc xác định công cụ và kỹ thuật tấn
công. Từ đó người quản trị hệ thống có thể nhanh chóng đưa ra các biện
pháp xử lý kịp thời.
Nhược điểm:
■ Để hiệu quả trong việc phát hiện xâm nhập thì phương pháp này phải
thường xuyên cập nhật dấu hiệu của các hình thức xâm nhập mới.
■ Các dấu hiệu dùng để phát hiện nếu không được thiết kế chặt chẽ thì có
thể sẽ không thể phát hiện ra các cuộc tấn công “biến thể”.
1.4. Đặt IDS trong hệ thống mạng
Vấn đề cần quan tâm khi sử dụng IDS đó là đặt nó ở đâu trong hệ thống mạng sao
cho các cảm biến được đặt có thể nhìn thấy tất cả các lưu lượng di chuyển trên hệ
thống mạng.
Để biết nên đặt các cảm biến ở đâu có thể trả lời một vài câu hỏi như sau:
Các tài nguyên cần bảo vệ là gì?
Hệ thống mạng được thiết kế như thế nào, đồ hình mạng thiết kế theo
kiểu bus, vòng hay kiểu sao hay kiểu kết hợp…?
Muốn đặt cảm biến trước tường lửa (lọc trước) hay sau tường lửa (không
lọc)?
Hệ thống mạng sử dụng thiết bị gì hub, switch?
Router định tuyến đặt như thế nào trong hệ thống mạng?
Tóm lại, nên đặt cảm biến ở nơi nào mà nó có thể thấy được lượng traffic càng
nhiều càng tốt. Đó có thể là vị trí kết nối giữa các segment với nhau.
Một điểm lưu ý là các IDS trong mô hình dưới được gắn vào các hub để đảm bảo
không bỏ sót bất cứ lưu lượng mạng nào. Tuy nhiên có thể gắn các IDS này vào
14
“port giám sát” trên switch (span port, port monitoring), khi dữ liệu đi qua switch
nó sẽ gửi một bản sao tới các IDS.
Hình 1.4: Các vị trí đặt IDS trong hệ thống mạng.
15
CHƯƠNG 2
GIỚI THIỆU VỀ SNORT/SNORTSAM
2.1. Snort là gì?
Snort là một hệ thống phòng chống và phát hiện xâm nhập dựa trên mạng (IPS/IDS)
nguồn mở được phát triển bởi Sourcefire. Kết hợp việc kiểm tra dấu hiệu, giao thức
và dấu hiệu bất thường, Snort đã được triển khai rộng khắp trên toàn thế giới. Với
hàng triệu lượt download và hơn 400.000 lượt người dùng đăng ký, Snort đã trở
thành tiêu chuẩn của hệ thống phòng chống và phát hiện xâm nhập.
Chức năng chính của Snort đó là packet sniffing, packet logging và network-based
intrusion detection.
Tại sao Snort lại trở nên phổ biến như vậy.
Dễ dàng cấu hình: Snort làm việc như thế nào, tập tin cấu hình ở đâu, các
luật như thế nào người quản trị đều có thể biết và cấu hình theo ý mình
được. Kể cả việc tạo ra các luật mới.
Snort là phần mềm mã nguồn mở: Snort được phát hành dưới giấy phép
GNU/GPL điều này có nghĩa là bất cứ ai cũng có thể sử dụng Snort một
cách miễn phí dù đó là doanh nghiệp hay người dùng cá nhân. Ngoài ra vì
là phần mềm mã nguồn mở nên Snort có một cộng đồng người sử dụng
lớn, sẵn sàng hỗ trợ nếu có bất cứ thắc mắc gì.
Chạy trên nhiều nền tảng khác nhau: Không chỉ chạy trên các hệ điều
hành nguồn mở như GNU/Linux mà Snort còn có thể chạy được trên các
nền tảng thương mại như Microsoft Windows, Solaris, HP-UX...
Snort thường xuyên được cập nhật: Các luật của Snort thường xuyên
được bổ sung và cập nhật các hình thức xâm nhập mới. Người sử dụng có
thể dễ dàng tải về từ http://www.snort.org.
2.2. Triển khai hệ thống Snort
16
2.2.1. Yêu cầu phần cứng
Rất khó để đưa ra một yêu cầu chung nhất cho phần cứng đề cài đặt Snort vì điều
này còn phụ thuộc vào nhiều yếu tố khác nhau. Hai yếu tố cần quan tâm đến việc
lựa chọn phần cứng cho hệ thống Snort đó là lưu lượng traffic trên hệ thống và yêu
cầu xử lí, lưu trữ đối với hệ thống Snort. Yêu cầu phần cứng của hệ thống đối với
một doanh nghiệp lớn như các ISP sẽ khác rất nhiều so với một mạng small home.
Để xác định phần cứng để cài đặt Snort cho hệ thống có thể trả lời một vài câu hỏi
sau để xác định được điều đó:
Hệ thống mạng là mạng small home, small bussiness, large enterprise hay
là một ISP.
Lưu lượng traffic thông thường trong hệ thống là bao nhiêu?
Lưu lượng traffic giữa hệ thống internal và mạng Internet bên ngoài là
khoảng bao nhiêu? Và ngược lại?
Nơi lưu trữ các cảnh báo (alerts) của Snort là ở đâu?
Thời gian lưu trữ các cảnh báo này là bao lâu?
Có muốn lưu trữ các gói tin liên quan đến các cảnh báo này hay không?
Tuy Snort không có bất kỳ yêu cầu phần cứng đặc biệt nào tuy nhiên nếu phần cứng
mạnh thì sẽ một số lợi điểm. Vì Snort là một hệ thống phát hiện xâm nhập dựa trên
mạng nên nếu có một đĩa cứng có dung lượng lưu trữ lớn và tốc độ quay nhanh thì
hệ thống Snort sẽ hoạt động một cách trơn tru hơn. Ví dụ đối với một mạng doanh
nghiệp có thể chia phân vùng /var với dung lượng là 100 GB. Ngoài ra nếu có yêu
cầu cao thì có thể sử dụng RAID để lưu trữ.
Bạn sẽ cần một card mạng (NIC) có tốc độ cao để việc sniffer các gói tin trở nên dễ
dàng hơn. Ví dụ nếu tốc độ card mạng dưới 100Mb/s thì nên sử dụng một card
mạng ở tốc độ 100Mb/s. Nếu tốc độ card mạng quá thấp thì Snort có thể “bỏ lỡ”
một vài gói tin và dẫn đến thông tin thu thập bị sai khác. Ngoài ra nên có thêm một
card mạng khác kết nối tới người quản trị thông qua giao thức SSH hoặc qua Web
Interface, tránh việc sử dụng chung với card mạng sniffer gói tin.
17
Nếu hệ thống mạng lớn, số lượng cảm biến (sensor) nhiều nên cân nhắc việc tăng
RAM cho hệ thống để hệ thống không bị lag khi xử lí qua nhiều thông tin gửi về.
2.2.2. Hệ điều hành và các gói phần mềm khác
Snort có thể chạy trên nhiều nền tảng hệ điều hành khác nhau. Snort có thể chạy
trên các nền tảng x86 như GNU/Linux, FreeBSD, OpenBSD, NetBSD và Windows.
Ngoài ra nó còn hỗ trợ cả kiến trúc Sparc với các nền tảng hệ điều hành như:
Solaris, MacOS-X, HP-UX...
Ngoài hệ điều hành, nếu có ý định compile Snort từ source code thì cần đảm bảo
các phần mềm sau đã được cài đặt trên hệ thống.
autoconf và automake.
gcc.
lex và yacc hoặc GNU flex và bison.
libpcap.
Hầu hết các phần mềm này đều có thể download tại http://www.gnu.org/ và libpcap
có thể download tại http://www.tcpdump.org
Ngoài ra nếu có ý định cài các Snort add-on hoặc các công cụ quản lý ví dụ như một
add-on phổ biến đó Analysis Console for Intrusion Detection (ACID) Web interface
thì cần cài đặt thêm Apache Web Server (nên sử dụng giao thức SSL để bảo mật),
PHP và cơ sở dữ liệu để lưu trữ các cảnh báo thì cần cài MySQL hoặc PostgreSQL.
Một vài add-on phổ biến:
ACID.
Oinkmaster.
SnortSnarf.
SnortReport.
Snorby.
Nếu quản trị từ xa thông qua giao thức SSH thì cần cấu hình SSH.
2.3. Đặc điểm của Snort
18
Ở chế độ NIDS, sau khi các gói tin đi vào và vượt qua packet sniffer, dữ liệu sẽ
được gửi thông qua bất kỳ preprocessor nào được cấu hình trong snort.conf . Dữ
liệu tiếp tục đi qua detection engine, kiểm tra xem có phù hợp với các luật trong tập
tin snort.conf hay không? Các gói phù hợp sẽ được gửi đến thành phần cảnh báo và
ghi lại (alert and logging) vượt qua bất kỳ output plug-in đã được chọn, sau đó nó sẽ
được ghi lại (log) hoặc cảnh báo tùy theo cấu hình.
Kiến trúc của Snort gồm 4 phần cơ bản sau:
The Sniffer (Packet Decoder).
The Preprocessors.
The Detection Engine.
The Output.
Hình dưới đây cung cấp một cái nhìn dễ hiểu về kiến trúc và quy trình xử lý của
Snort. Tưởng tượng nó như một máy phân loại đồng xu.
Hình 2.1: Kiến trúc của Snort.
Tiền xu được đưa vào (packet được đưa vào từ trục mạng chính)
Tiền xu được gửi thông qua một cái máng để xác định xem nó có phải là
xu hay không và có giữ nó lại hay không (preprocessors)
Tiếp đến tiền xu được sắp xếp theo loại. Ví dụ phân loại theo giá trị của
đồng xu (Detection Engine).
Cuối cùng nhiệm vụ của người quản trị là xác định xem làm gì với nó
(ghi lại và lưu vào cơ sở dữ liệu).
19
Preprocessors, detection engine và alert system đều là các plug-ins. Điều này giúp
cho cho việc chỉnh sửa hệ thống theo mong muốn của người quản trị một cách dễ
dàng.
2.3.1. Packet Sniffer (Decoder)
Packet Sniffer là một thiết bị phần cứng hoặc phần mềm được đặt vào trong mạng.
Chức năng của nó tương tự như việc nghe lén trên điện thoại di động, nhưng thay vì
hoạt động trên mạng điện thoại nó nghe lén trên mạng dữ liệu. Bởi vì trong mô hình
mạng có nhiều giao thức cao cấp như TCP, UDP, ICMP... nên công việc của packet
sniffer là nó phải phân tích các giao thức đó thành thông tin mà con người có thể
đọc và hiểu được. Packet Sniffer có thể được sử dụng với các mục đích như:
Phân tích mạng và troubleshooting.
Performance network and bechmarking.
Nghe lén mật khẩu clear-text và những dữ liệu khác.
Mã hóa lưu lượng mạng có thể tránh được việc sniffer các gói tin. Tùy vào mục
đích mà packet sniffer có thể sử dụng cho mục đích tốt hoặc xấu.
Hình 2.2: Các gói tin đi vào Sniffer.
Khi Snort đã nhận các gói tin từ quá trình sniffer nó sẽ đi vào quá trình giải mã.
Chính xác thì nơi mà gói tin đi vào bộ giải mã phụ thuộc vào lớp liên kết mà trước
đó đọc được. Snort hỗ trợ một số lớp liên kết từ pcap: Ethernet, 802.11, Token ring,
FDDI, Cisco HDLC, SLIP, PPP và OpenBSD’s PF. Ở trên lớp liên kết Snort hỗ trợ
giải mã các giao thức khác nhau, bao gồm IP, ICMP, TCP, UDP (chi tiết trong mã
nguồn src/decode.c)
20
Bất kể là lớp liên kết nào đang được sử dụng, tất cả các bộ giải mã sẽ đều làm việc
theo một kiểu chung. Đối với trường hợp các lớp cụ thể, con trỏ trong cấu trúc của
gói tin sẽ được thiết lập trỏ tới một phần khác của gói tin. Dựa vào các thông tin đã
giải mã được, nó sẽ gọi các lớp cao hơn và giải mã cho đến khi không còn bộ giải
mã nào nữa.
Hầu hết các mạng hiện nay triển khai Snort là mạng Ethernet nên sẽ xét thử một ví
dụ giải mã một gói tin trong mạng này. Đầu tiên khi gói tin đi vào nó sẽ phải đi qua
chức năng DecodeEthPkt. Sau đó, overlaying cấu trúc Ethernet lên đầu của phần dữ
liệu, địa chỉ MAC nguồn và đích và loại tầng tiếp theo (ether_type) sẽ được biết.
Dựa trên giá trị ether_type, bộ giiar mã tiếp theo sẽ được gọi. Giả sử giá trị của
ether_type là 2048 (ETHERNET_TYPE_IP) thì tầng tiếp theo là tầng IP và nên gọi
bộ giải mã DecodeIP và tiếp tục đến khi không còn bộ giải mã nào.
DecodeIPv6
IPv6
DecodeEthPkt
Ethernet
DecodeIP
IP
DecodeARP
ARP
DecodeIPX
IPX
DecodeIPOptions
IP Options
DecodeTCP
TCPDecodeUDP DecodeICMP
DecodeVLAN
802.1Q
DecodePPPoEPkt
PPP Over Ethernet
DecodeTCPOptions
TCP Options
DecodeIPOnly
Embedded IP
Hình 2.3: Giải mã gói tin.
2.3.2. Preprocessors
21
Preprocessors là plug-in cho phép phân tích cú pháp dữ liệu theo những cách khác
nhau. Nếu chạy Snort mà không có bất cứ cấu hình nào về preprocessors trong tập
tin cấu hình sẽ chỉ thấy từng gói dữ liệu riêng rẽ trên mạng. Điều này có thể làm
IDS bỏ qua một số cuộc tấn công, vì nhiều loại hình tấn công hiện đại cố tình phân
mảnh dữ liệu hoặc có tình đặt phần độc hại lên một gói tin và phần còn lại lên gói
tin khác (kỹ thuật lẩn trốn).
Dữ liệu sẽ được đưa vào Preprocessors sau khi đi qua bộ giải mã gói tin (packet
decoder). Snort cung cấp một loạt các Preprocessors ví dụ như: Frag3 (một module
chống phân mảnh gói tin IP), sfPortscan (module được thiết kế chống lại các cuộc
trinh sát, như scan port, xác định dịch vụ, scan OS), Stream5 (module tái gộp các
gói tin ở tầng TCP)
Ở thời điểm hiện tại Snort có 10 preprocesstor được mô tả trong hướng dẫn của
Snort tại địa chỉ (http://manual.snort.org/node17.html).
Hình 2.4: Quá trình xử lí ở Preprocessors.
2.3.3. Detection Engine
Đầu vào là các gói tin đã được sắp xếp ở quá trình preprocessors. Detection engine
là một phần của hệ thống phát hiện xâm nhập dựa trên dấu hiệu. Detection engine sẽ
lấy dữ liệu từ preprocessors và kiểm tra chúng thông qua các luật. Nếu các luật đó
22
khớp với dữ liệu trong gói tin, nó sẽ được gửi tới hệ thống cảnh báo, nếu không nó
sẽ bị bỏ qua như hình phía dưới.
Để dễ hình dung có thể hiểu ví dụ về việc phân loại đồng xu. Thông thường có các
đồng xu: 1 xu, 2 xu, 5 xu. Nếu xuất hiện tiền giấy 10 xu thì nó sẽ bi bỏ đi.
Các luật có thể được chia thành 2 phần:
Phần Hearder: gồm các hành động (log hay alert), loại giao thức (TCP,
UDP, ICMP...), địa chỉ IP nguồn, địa chỉ IP đích và port.
Phần Options: là phần nội dung của gói tin được tạo ra để phù hợp với
luật.
Luật là phần quan trọng mà bất cứ ai tìm hiểu về Snort cần phải nắm rõ. Các luật
trong Snort có một cú pháp cụ thể. Cú pháp này có thể liên quan đến giao thức, nội
dung, chiều dài, hearder và một vài thông số khác. Một khi hiểu được cấu trúc các
luật trong Snort, người quản trị có thể dễ dàng tinh chỉnh và tối ưu hóa chức năng
phát hiện xâm nhập của Snort. Từ đó có thể định nghĩa các luật phù hợp với từng
môi trường và hệ thống mạng.
Hình 2.5: Gói tin được xử lý ở Detection Engine bằng các luật.
23
2.3.4. Thành phần cảnh báo/logging
Cuối cùng sau khi các luật đã phù hợp với dữ liệu, chúng sẽ được chuyển tới thành
phần cảnh báo và ghi lại (alert and loggin component). Cơ chế log sẽ lưu trữ các gói
tin đã kích hoạt các luật còn cơ chế cảnh báo sẽ thông báo các phân tích bị thất bại.
Giống như Preprocessors, chức năng này được cấu hình trong tập tin snort.conf, có
thể chỉ định cảnh báo và ghi lại trong tập tin cấu hình nếu muốn kích hoạt.
Dữ liệu là giá trị cảnh báo, nhưng có thể chọn nhiều cách để gửi các cảnh báo này
cũng như chỉ định nơi ghi lại các gói tin. Có thể gửi cảnh báo thông qua SMB
(Server Message Block) pop-up tới máy trạm Windows, ghi chúng dưới dạng
logfile, gửi qua mạng thông qua UNIX socket hoặc thông qua giao thức SNMP.
Cảnh báo cũng có thể lưu trữ dưới dạng cơ sở dữ liệu SQL như MySQL hoặc
PostgerSQL. Thậm chí một vài hệ thống của các hãng thứ 3 có thể gửi cảnh báo
thông qua SMS tới điện thoại di động.
Có rất nhiều các add-on giúp người quản trị nhận các cảnh báo cũng như phân tích
các dữ liệu một cách trực quan.
The Analysis Console for Intrusion Detection (ACID): được biết như
một add-on phân tích cú pháp log dựa trên PHP, search engine và là một
front-end phân tích log của Snort.
http://www.andrew.cmu.edu/user/rdanyliw/snort/
SGUIL (Snort GUI for Lamerz) là một công cụ phân tích tuyệt với khác.
Oinkmaster: là một Pert script giúp cập nhật các luật của Snort và
comment nếu không muốn sau mỗi lần cập nhật.
IDS Policy Manager là một giao diện quản lý dành cho Windows XP.
SnortSnarf: Là một chương trình viết bằng Pert giúp tạo và cung cấp các
bản báo cáo log gần đây một cách tổng hợp dưới dạng HTML.
Swatch: http://swatch.sourceforge.net là một công cụ giám sát syslog
theo thời gian thực và gửi cảnh báo bằng email.
24
BASE: http://sourceforge.net/projects/secureideas/ Basic Analysis and
Security Engine là một plug-in phân tích và truy vấn các cảnh báo của
Snort rất đáng giá.
Hình 2.6: Thành phần cảnh báo và logging.
2.4. Các chế độ hoạt động của Snort
2.4.1 Chế độ sniffer và chế độ log
Để chạy Snort ở chế độ sniffer sử dụng tham số -v.
$ snort –v
Tùy chọn này chỉ cho phép hiển thị các IP và TCP/UDP/ICMP header, ngoài ra
không còn thêm gì khác. Nếu muốn hiển thị thêm dữ liệu ở tầng ứng dụng phải
thêm tùy chọn –d.
$ snort –vd
25
Tùy chọn này sẽ cho phép hiển thị cả phần dữ liệu và tiêu đề của gói tin. Nếu muốn
hiển thị nhiều hơn các thông tin khác ví dụ như phần header ở tầng data-link thêm
tùy chọn –e.
$ snort –vde hoặc $ snort –d –v –e
Ưu điểm của snort so với các ứng dụng bắt gói tin khác là:
Có thể lưu các tập tin log sau khi sniffer gói tin xuống cơ sở dữ liệu như
MySQL hoặc PostgreSQL.
Tập tin log có thể hiện thị ở dạng ASCII theo từng địa chỉ IP riêng biệt, giúp
dễ dàng phân tích.
Ngoài ra tập tin log cũng có thể được lưu trữ dưới dạng tập tin nhị phân theo
định dạng của tcpdump.
Để chạy Snort ở chế độ logger sử dụng tham số -l.
$ snort –dev –l /home/user/log
Câu lệnh trên cho phép sau khi bắt các gói tin, lưu trữ chúng dưới dạng tập tin log.
Ngoài ra có thể lưu trữ các tập tin log dựa trên các địa chỉ IP truy cập. Ví dụ câu
lệnh sau sẽ cho phép ta bắt, in ra màn hình và lưu trữ lại các gói tin TCP/IP cũng
với tiêu đề ở tầng data-link, dữ liệu của gói tin của tất cả các gói tin đi vào từ địa chỉ
của lớp mạng C.
$ snort –dev –l /hom/user/log -h 192.168.1.0/24
Trường hợp muốn chạy snort ở chế độ logger lưu trữ các tập tin log ở dạng nhị phân
có thể sử dụng tùy chọn –b, và sử dụng tùy chọn –r để đọc các tập tin nhị phân được
ghi lại.
$ snort –l /log –b
$ snort –dv –r packet.log
2.4.2 Chế độ NIDS
Để khởi chạy Snort ở chế độ phát hiện xâm nhập mạng không cần bắt tất cả các gói
tin.
26
$/snort -dev -l ./log -h 192.168.1.0/24 -c snort.conf
Tham số -c được sử dụng để chỉ định tập tin cấu hình của snort. Mặc định các tập
tin log sẽ được lưu trữ tại /var/log/snort. Khi chạy ở chế độ NIDS có thể
bỏ tùy chọn –v để tăng tốc độ, do không cần thiết phải bắt các gói tin và in ra màn
hình.
2.5. Giới thiệu về SnortSam
Chức năng của Snort chỉ là phát hiện xâm nhập và cảnh báo cho người quản trị biết
về những xâm nhập đó, nó không thể ngăn chặn các cuộc tấn công đó. Để thực hiện
được chức năng ngăn chặn một cách chủ động (active response) có thể sử dụng các
plug-in dành cho Snort như SnortSam, Fwsnort hay snort_inline để làm điều này.
Các plug-in đó sẽ thay đổi hoặc chặn các lưu lượng mạng dựa trên địa chỉ IP
(SnortSam), dựa trên giao thức ở tầng Transport (Fwsnort) hay ở tầng Application
(Snort_inline).
Một điểm cần lưu ý là một hệ thống ngăn chặn xâm nhập ngoài việc ngăn chặn các
gói tin đi vào hệ thống nó còn có thể thay đổi trực tiếp các gói tin đó khi chúng
được chuyển qua mạng. Bởi vậy Fwsnort và snort_inline được xếp vào hệ thống
ngăn chặn xâm nhập (IPS) còn SnortSam chỉ được xếp vào hệ thống phản ứng chủ
động (Active Response System)
Nội dung phần này sẽ tìm hiểu về SnortSam một plug-in của Snort cho phép tự
động chặn các địa chỉ IP dựa trên các tường lửa như:
Checkpoint Firewall-1
Cisco PIX firewalls
Cisco Routers (sử dụng ACL)
Former Netscreen, now Juniper firewalls
IP Filter (ipf), trên các dòng Unix-like OS ví dụ FreeBSD
FreeBSD's ipfw2 (phiên bản 5.x)
OpenBSD's Packet Filter (pf)
27
Linux IPchains
Linux IPtables
Linux EBtables
WatchGuard Firebox firewalls
8signs firewalls trên Windows
MS ISA Server firewall/proxy trên Windows
CHX packet filter
Ali Basel's Tracker SNMP thông qua SNMP-Interface-down plug-in.
SnortSam bao gồm hai phần riêng biệt. Một phần là một tập hợp của các sửa đổi
trong tập tin mã nguồn, mở rộng Snort bằng cách thêm một mô-đun output mới đó
là: alert_fwsam. Phần còn lại là một tác nhân sẽ giao tiếp trực tiếp với tường lửa gọi
là agent. Tác nhân này có thể đặt ngay trên chính các tường lửa nếu tường lửa đó là
iptables, hoặc trên pf nếu hệ thống là BSD hoặc trên Checkpoint’s Firewall-1 nếu
hệ thống là Windows. Đối với các tường lửa phần cứng như Cisco PIX thì tác nhân
này của SnortSam phải đặt trên một máy riêng biệt rành riêng để giao tiếp với PIX.
Về phương thức hoạt động. Snort sẽ giám sát các luồng lưu lượng trên mạng, và khi
một luật của Snort được kích hoạt (gặp một traffic phù hợp), Snort sẽ gửi đầu ra cho
mô-đun fwsam. Mô-đun fwsam sau đó sẽ gửi một tin nhắn mã hóa tới cho agent
được đặt trên tường lửa. Agent này sẽ kiểm tra xem tin nhắn đó có phải được gửi
tới từ một nguồn có thẩm quyền hay không, nếu đúng nó sẽ giải mã thông điệp vừa
nhận được và kiểm tra xem các địa chỉ IP nào được yêu cầu chặn. SnortSam sẽ rà
soát xem các địa chỉ IP đó có nằm trong danh sách trắng (white-list) hay không.
Nếu IP đó không nằm trong danh sách trắng, SnortSam sẽ yêu cầu tường lửa chặn
địa chỉ IP đó trong một khoảng thời gian đã được định nghĩa từ trước.
2.5.1. Snort Output Plug-in
Phần Output yêu cầu chỉnh sửa cả ở tập tin cấu hình và luật của Snort. Phần output
này sẽ giao tiếp với agent trên tường lửa thông qua giao thức TCP hoạt động ở port
898. Phần output plug-in này hỗ trợ mã hóa giao tiếp với phần agent với một khóa
28
đã được định nghĩa trước trong tập tin cấu hình. Thuật toán mã hóa SnortSam đang
sử dụng là Twofish.
Đối với tập tin cấu hình snort.conf thêm dòng này vào:
output alert_fwsam: 192.168.10.1/sn0r3sam
Đối với các luật sẽ thêm tùy chọn fwsam và thời gian vào sau mỗi luật. Ví dụ, muốn
chặn một địa chỉ IP nào đó với khoảng thời gian là một giờ sẽ thêm chuỗi
:fwsam:src, 1 hour;”
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:"WEB-CGI /wwwboard/passwd.txt access";
flow:to_server,established;
uricontent:"/wwwboard/passwd.txt"; nocase;
reference:arachnids,463; reference:cve,CVE 1999-0953;
reference:nessus,10321; reference:bugtraq,649;
classtype:attempted-recon; sid:807; rev:7; fwsam: src, 1
hour;)
2.5.2. Blocking Agent
Phần này sẽ có trách nhiệm tương tác trực tiếp với các tường lửa thay cho phần
output plug-in trên Snort. Nếu Snort phát hiện một cuộc tấn công phù hợp với bất
kỳ một quy tắc nào như trong ví dụ trên nó sẽ thiết lập một phiên mã hóa TCP để
gửi một thông điệp chứa các IP nguồn từ các gói tin gây ra cảnh báo + thời gian mà
địa chị IP đó bị cấm.
Vì phiên mã hóa TCP đó sẽ giao tiếp thông qua port 898 (hoặc bất cứ port nào được
cấu hình) nên cầm đảm bảo là tường lửa cho phép giao tiếp trên port này. Trạng thái
của tất cả các địa chỉ IP bị cấm sẽ được đặt trong tập tin /var/log/snortsam.state.
Tập tin cấu hình của SnortSam đặt tại /etc/snortsam.conf dưới đây là một số tùy
chọn quan trọng có thể được sử dụng trong tập tin cấu hình.
accept: Cho phép các cảm biến cụ thể của Snort có thể giao tiếp với phần
agent trên tường lửa. Nhiều cảm biến cũng có thể được cấu hình với tùy chọn
này cùng với các khóa dùng để mã hóa riêng: accept <host>/<mask>,<key>
29
defautlkey: Thiết lập khóa mặc định được sử dụng cho tất cả các cảm biến.
port: Thiết lập port lắng nghe từ các cảm biến của Snort. Mặc định là port
TCP 898.
dontblock: Chỉ định một host hoặc một mạng mà SnortSam sẽ bỏ qua ngay
cả khi phát hiện một cuộc tấn công từ nguồn này.
logfile: Chỉ định đường dẫn lưu logfile mà SnortSam sẽ ghi. Tập này cũng
liệt kê tất cả các địa chỉ IP mà SnortSam đã chặn kèm theo thời gian chặn.
daemon: Chạy agent như một dịch vụ.
bindip: Giới hạn phần agent trên tường lửa lắng nghe trên một địa chỉ IP với
một card mạng nhất định. Điều này làm giảm khả năng tấn công các agent vì
giới hạn số đường kết nối tới các agent đó.
<firewall><interface>: Chỉ định loại tường lửa cụ thể mà agent đang chạy
trên đó và cổng giao tiếp mà các luật nên thêm vào.
keyinterval <time>: Tùy chọn này cho phép các agent yêu cầu hoặc tạo các
khóa mã hóa mới sau mỗi khoảng thời gian nào đó. Mặc định nếu không
thiết lập là 4 tiếng.
email <smtpserver>:<port> <recipient> <sender>: Tùy chọn này cho
phép xác định máy chủ email. Khi một địa chỉ nào đó bị block, SnortSam sẽ
gửi thông báo tới địa chỉ email được cấu hình.
Ví dụ:
accept 192.168.20.3, sn0r3sam
bindip 192.168.20.1
iptables eth0
logfile /var/log/snortsam.log
daemon
30
CHƯƠNG 3
PREPROCESSORS VÀ OUTPUT PLUG-INS
3.1. Preprocessors
Như trong chương phía trên, chúng ta đã có những hiểu biết cơ bản về cấu trúc và
cách làm việc của Snort. Ngoài ra cũng có cái nhìn tổng quát về preprocessors trong
Snort. Vậy chức năng chính của preprocessor là gì?
Preprocessors được giới thiệu lần đầu trong phiên bản 1.5 của Snort. Ban đầu nó
được biết đến với chức năng bình thường hóa các giao thức mạng. Ngày nay,
preprocessor không chỉ đảm nhiệm chức năng bình thường hóa các giao thức nữa
mà nó còn có thể phát hiện xâm nhập dựa trên sự bất thường và tạo ra những
cảnh báo riêng. Trong thực tế Snort nổi bật với chức năng phát hiện xâm nhập dựa
theo mẫu và các dấu hiệu có sẵn. Các plug-in preprocessors được bổ sung vào ngoài
mục đích tạo đầu ra cho detection engine mà nó còn có chức năng tạo ra các cảnh
báo thông qua việc phát hiện các điểm bất thường trong các lưu lượng mạng đi vào
hệ thống.
Phần này sẽ tìm hiểu một vài tiền xử lý quan trọng, đặc biệt là các tiền xử lý tái hợp
các gói tin, một hình thức có thể giúp các attacker lẩn trốn khỏi các hệ thống phát
hiện xâm nhập.
Các preprocessors cực kỳ hữu ích khi phát hiện các cuộc tấn công phân mảnh gói
tin nhằm mục đích đánh lừa hệ thống phát hiện xâm nhập như Tiny Fragment
Attack, Overlaping Fragment Attack, Teardrop Fragment Attack.
31
Hình 3.1: Quá trình tiền xử lý.
3.1.1. Frag3
32
Trong tiền xử lý frag3 có một khái niệm mới được đưa ra đó là “target-based”. Ý
tưởng của thuật ngữ này như sau: Một IDS được đặt trong hệ thống mạng, nhưng
IDS này hoàn toàn không biết được các hệ điều hành trên các máy trạm trong hệ
thống mạng mà nó theo dõi. Các gói tin phân mảnh sau đó được ghép lại tại các
máy trạm này. Vấn đề đặt ra là nếu các attacker biết được mục tiêu của chúng là
một máy trạm cài đặt hệ điều hành Linux. Chúng cố tình phân mảnh dữ liệu sao cho
nếu tái hợp các mảnh này trên hệ điều hành Windows thì không có bất cứ hiệu ứng
gì, nhưng nếu hệ điều hành Linux tái hợp các phân mảnh đó thì sẽ gây ra một lỗ
hổng có thể khai thác được.
Điều quan trọng là nếu IDS được điều chỉnh để tái hợp các phân mảnh như trên hệ
điều hành Windows thì IDS sẽ không thể phát hiện được cuộc tấn công như trên. Và
attacker đã đánh lừa được IDS và xâm nhập vào được hệ thống mạng mà không gặp
bất trắc gì.
Ý tưởng đặt ra là cấu hình sao cho IDS có thể kiểm soát được các hệ điều hành cài
đặt trên các máy trạm trong hệ thống mạng. Nếu có bất kỳ gói tin nào được gửi tới
máy trạm đó, IDS sẽ phân tích và tái hợp các phân mảnh như hệ điều hành tại máy
trạm đó.
Cấu hình: Có hai chỉ thị tiền xử lý trong việc cấu hình Frag3 đó là cấu hình toàn cục
và cấu hình động cơ. Có thể có nhiều cấu hình động cơ nhưng chỉ duy nhất một cầu
hình toàn cầu.
Cấu hình toàn cầu:
Tên tiền xử lý: frag3_global
Các tùy chọn (các tùy chọn này được phân cách bằng dấu phẩy “,”)
- max_frags <number>: Số lượng tối đa các phân mảnh được theo
dõi đồng thời. Mặc định là 8192.
- memcap <bytes>: Bộ nhớ tự quản, mặc định là 4MB. Con số này
thể hiện bộ nhớ lớn nhất mà Frag3 được phép sử dụng.
- prealloc_memcap <bytes>:
- prealloc_frags <number>:
33
- disabled:
Cấu hình động cơ:
Tên tiền xử lý: frag3_engine
Các tùy chọn (cách nhau bởi khoảng trắng)
- timeout <seconds>: Thời gian timeout của phân mảnh. Những
phân mảnh tồn tại trên hệ thống sau thời gian này sẽ bị hủy. Mặc định là
60s.
- min_ttl <value>: Giá trị TTL tối thiểu chấp nhận được cho một
phân mảnh gói tin. Mặc định là 1, chấp nhận giá trị từ 1-255.
- detect_anomalies: Phát hiện các phân mảnh dị thường.
- bind_to <ip_list>: Danh sách các địa chỉ IP bị ràng buộc với
cấu hình này. Tiền xử lý này sẽ chỉ xử lý với các địa chỉ đích có trong
danh sách này. Mặc định là tất cả.
- overlap_limit <number>: Giới hạn số phân mảnh chồng chéo
trên mỗi gói tin. Mặc định giá trị là “0” nghĩa là không giới hạn. Yêu cầu
tùy chọn detect_anomalies phải được thiết lập trước đó.
- min_fragment_length <number>: Định nghĩa kích thước nhỏ
nhất của một phân mảnh (kích thước phần payload) được chấp nhận.
Những phân mảnh có kích thước nhỏ hơn hoặc bằng sẽ bị coi là độc hại
và sẽ có một hành động xử lý. Mặc định giá trị là “0” không giới hạn, giá
trị tối thiểu là “0”. Tùy chọn này cũng yêu cầu tùy chọn
detect_anomalies được thiết lập trước.
- policy <type>: Lựa chọn chế độ chống phân mảnh dựa trên mục
tiêu. Gồm các loại như first, last, bsd, bsd-right, linux, windows và
solaris. Mặc định là bsd.
34
Platform Type Platform Type
AIX 2 BSD Linux 2.4 (RedHat
7.1-7.3)
Linux
AIX 4.3 8.9.3 BSD MacOS First
Cisco IOS Last OpenBSD Linux
FreeBSD BSD OS/2 BSD
HP JetDirect BSD-right OSF1 V4.0,5.0,5.1 BSD
HP-UX B.10.20 BSD SunOS 4.1.4 BSD
HP-UX 11.00 First SunOS
5.5.1,5.6,5.7,5.8
First
IRIX 6.2, 6.3 BSD Tru64 Unix
V5.0A,V5.1
BSD
IRIX64 6.4 BSD Windows
(95/98/NT4/W2K/XP)
Windows
Hình 3.2: Phân loại các hệ điều hành.
Output: Frag3 có khả năng phát hiện tám loại khác nhau của dị thường. Phần output
dựa trên các gói tin và làm việc với tất cả các chế độ output khác của Snort. Các
cảnh báo output này có thể tìm thấy trong
/preproc_rules/preprocessor.rules của tập tin mã nguồn Snort với
gid=123.
Ví dụ:
preprocessor frag3_global: prealloc_nodes 8192
preprocessor frag3_engine: policy linux, bind_to
192.168.1.0/24
preprocessor frag3_engine: policy first, bind_to
[10.1.47.0/24,172.16.8.0/24]
preprocessor frag3_engine: policy last, detect_anomalies
35
3.1.2. Stream5
Tiền xử lý Stream5 cũng là một mô-đun tái hợp TCP dựa trên mục tiêu. Nó có khả
năng theo dõi các phiên của cả giao thức TCP và UDP. Với tiền xử lý này, các luật
“flow” và “flowbits” có thể được sử dụng cho cả lưu lượng TCP và UDP.
Stream5 cũng tương tự như Frag3, tức là IDS sẽ xử lý các luồng dữ liệu dựa vào
mục tiêu. Stream5 sẽ xử lý việc chồng chéo dữ liệu và các dấu hiệu bất thường của
kết nối TCP.
Một số ví dụ về việc nhận dạng sự bất thường trên giao thức TCP như: dữ liệu tồn
tại trong gói SYN, dữ liệu nhận được vượt quá kích thước của cửa sổ TCP.
a. Cấu hình toàn cục
preprocessor stream5_global: <tùy chọn>
Tùy chọn Mô tả
track_tcp <yes|no> Theo dõi phiên TCP. Mặc định là “yes”
max_tcp <num
sessions>
Số phiên TCP tối đa được đồng thời theo dõi. Mặc
định là “262144”, tối đa là “1048576”, tối thiểu là
“1”.
memcap <num bytes>
Bộ nhớ cho lưu trữ gói tin TCP. Mặc định là
"8388608" (8MB), tối đa là "1073741824" (1GB), tối
thiểu là "32768" (32KB).
track_udp <yes|no> Theo dõi phiên UDP. Mặc định là “yes”.
max_udp <num
sessions>
Số phiên UDP tối đa được đồng thời theo dõi. Mặc
định là "131072", tối đa là "1048576", tối thiểu là
"1".
track_icmp <yes|no> Theo dõi phiên ICMP. Mặc định là “no”.
max_icmp <num
sessions>
Số phiên ICMP tối đa được đồng thời theo dõi. Mặc
định là "65536", tối đa là "1048576", tối thiểu là "1".
track_ip <yes|no> Theo dõi phiên IP. Mặc định là “no”
36
max_ip <num sessions> Số phiên IP tôi đa được đồng thời theo dõi. Mặc định
là "16384", tối đa là "1048576", tối thiểu là "1".
disabled Tùy chọn vô hiệu hóa stream5, mặc định tùy chọn
này được tắt.
flush_on_alert Tương thích ngược. Đẩy ra một TCP stream khi một
cảnh báo được tạo ra. Mặc định được tắt.
show_rebuilt_packets In/hiển thị các gói tin sau khi được xây dựng lại
(debug). Mặc định được tắt.
prune_log_max <num
bytes>
In ra một thông báo khi một phiên chấm dứt hoặc
tiêu tốn nhiều hơn số bytes được quy định. Mặc định
là "1048576" (1MB), tối thiểu là "0" (disabled) hoặc
nếu không bị vô hiệu hóa thì tối thiểu là "1024" và
tối đa là “1073741824".
Hình 3.3: Ý nghĩa các tham số cấu hình toàn cục.
b. Cấu hình cho giao thức TCP
preprocessor stream5_tcp: <tùy chọn>
Tùy chọn Mô tả
bind_to <ip_addr> Dãy địa chỉ IP sẽ được áp dụng chính sách này.
Mặc định là bất kỳ địa chỉ nào.
timeout <num seconds> Thời gian chờ của một phiên. Mặc định là “30”,
tối thiểu là “1” và tối đa là “86400” (khoảng 1
ngày).
policy <policy_id> Chính sách này áp dụng cho hệ điều hành mục
tiêu nào.
overlap_limit <number> Giới hạn số lượng gói tin chồng chéo nhau trên
một phiên. Mặc định là “0” (không giới hạn) tối
đa là "255".
max_window <number> Số TCP window tối đa cho phép. Mặc định là
37
“0” (không giới hạn) và tối đa là "1073725440"
(65535 dịch trái 14). Tùy chọn này được sử dụng
để chống DoS.
require_3whs [<number
seconds>]
Một phiên thiết lập chỉ hoàn thành khi thực hiện
quá trình bắt tay 3 bước, mặc định nó được tắt.
Số giây chỉ thời gian gia hạn của một phiên hiện
tại. Tối thiểu là “0” (không xem xét thời gian
thiết lập) và tối đa là “86400”.
detect_anomalies Phát hiện và cảnh báo sự bất thường của giao
thức TCP. Mặc định nó được tắt.
check_session_hijacking Kiểm tra kiểu tấn công TCP Session Hijacking
bằng cách kiểm tra địa chỉ MAC của hai đầu kết
nối có giống trong quá trình bắt tay ba bước hay
không.
dont_store_large_packets Không lưu các gói tin quá lớn vào buffer trong
quá trình tái phân mảnh.
dont_reassemble_async Không đợi các gói tin để tái hợp nếu lưu lượng
mạng không được tìm thấy ở cả hai hướng.
max_queued_bytes <bytes> Hạn chế số bytes đợi cho việc tái phân mảnh trên
một phiên TCP. Mặc định là "1048576" (1MB).
Giá trị "0" có nghĩa là không giới hạn và giá trị
tối thiểu khác “0” là “1024”, tối đa là
"1073741824" (1GB).
max_queued_segs <num> Hạn chế số segments đợi cho việc tái phân mảnh
trên một phiên TCP. Mặc định là “2621”. Giá trị
"0" nghĩa là không giới hạn, tối thiểu là “2” và
tối đa là "1073741824" (1GB).
ports
<client|server|both>
<all|number(s)>
Chỉ định danh sách các port ở client, server hoặc
cả hai phía trong việc tái phân mảnh gói tin. Mặc
định là các port: 21 23 25 42 53 80 110 111 135
136 137 139 143 445 513 514 1433 1521 2401
3306.
38
protocol
<client|server|both>
<all|service name(s)>
Chỉ định danh sách các dịch vụ ở client, server
hoặc cả hai phía trong việc tái phân mảnh gói tin.
Mặc địch là các dịch vụ: ftp telnet smtp
nameserver dns http pop3 sunrpc dcerpc netbios-
ssn imap login shell mssql oracle cvs mysql.
Hình 3.4: Ý nghĩa các tham số cấu hình TCP.
c. Cấu hình cho giao thức UDP
preprocessor stream5_udp: [timeout <number secs>],
[ignore_any_rules]
Tùy chọn Mô tả
timeout <num seconds> Thời gian chờ của một phiên. Mặc định là
“30”, tối thiểu là “1” và tối đa là “86400”.
ignore_any_rules Không xử lý bất kỳ luật nào any → any.
Mặc định được tắt.
Hình 3.5: Ý nghĩa các tham số cấu hình UDP.
d. Cấu hình cho giao thức ICMP
preprocessor stream5_icmp: [timeout <number secs>]
Tùy chọn Mô tả
timeout <num seconds> Thời gian chờ của một phiên. Mặc định là
“30”, tối thiểu là “1” và tối đa là “86400”.
Hình 3.6: Ý nghĩa các tham số cấu hình ICMP.
e. Cấu hình cho giao thức IP
preprocessor stream5_ip: [timeout <number secs>]
Tùy chọn Mô tả
timeout <num seconds> Thời gian chờ của một phiên. Mặc định là
“30”, tối thiểu là “1” và tối đa là “86400”.
Hình 3.7: Ý nghĩa các tham số cấu hình IP.
39
Ví dụ 1:
preprocessor stream5_global: max_tcp 8192, track_tcp yes,
track_udp yes, track_icmp no
preprocessor stream5_tcp: policy first,
use_static_footprint_sizes
preprocessor stream5_udp: ignore_any_rules
Ví dụ 2:
preprocessor stream5_global: track_tcp yes
preprocessor stream5_tcp: bind_to 192.168.1.0/24, policy
windows
preprocessor stream5_tcp: bind_to 10.1.1.0/24, policy linux
preprocessor stream5_tcp: policy solaris
3.1.3. sfPortscan
Mô-đun sfPortscan được phát triển bởi Sourcefire, nó được thiết kế nhằm phát hiện
các hình thức thăm dò hệ thống trước khi tấn công. Trong giai đoạn trinh sát hệ
thống, attacker sẽ xác định các giao thức mạng, dịch vụ máy chủ hoặc hệ điều hành
mục tiêu. Giai đoạn chưa phải là giai đoạn xâm nhập nhưng attacker có thể thu thập
được nhiều thông tin hữu ích chuẩn bị cho quá trình xâm nhập. Một công cụ quét
cổng cực kỳ mạnh mẽ và phổ biến hiện nay đó nà Nmap. Nmap đầy đủ các kỹ thuật
quét cổng hiện nay và sfPortscan được thiết kế nhằm chống lại những kỹ thuật quét
cổng từ Nmap.
3.1.4. HTTP Inspect
HTTP đã trở thành một trong những giao thức phổ biến và thông dụng trên Internet.
Nên đây mà một giao thức rất được các attacker ưa chuộng. Attacker có thể sử dụng
sự linh hoạt của các Web server để cố gắng ẩn thân và che dấu hành vi tấn công
trước các NIDS. Ví dụ trong mẫu sau, các mẫu phát hiện như trong Snort sẽ chỉ có
thể phát hiện được dạng foo/bar mà không thể phát hiện được foo\bar.
http://www.abc/foo/bar/xyz.php
40
http://www.abc/foo\bar\xyz.php
Ngoài ra Attacker còn có thể sử dụng vô số các kỹ thuật mã hóa dựa trên mã hex
với uft-8. http_inspect sẽ chỉ xử lý trên từng gói tin, điều này có nghĩa là những
chuỗi mà nó xử lý phải được tái hợp trước đó bằng tiền xử lý stream5.
Ví dụ dưới đây về các phương thức GET, chúng đều có chung một chức năng giống
hệ nhau, được các webserver xử lý giống hệ nhau.
GET /../../../../etc/passwd HTTP /1.1
GET %2f..%2f..%2f..%2f..%2fetc%2 fpasswd HTTP /1.1
GET
%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%65%74%63%2f%70%61%73%
73%77%64
HTTP /1.1
Trên đây là một ví dụ về tấn công “directory traversal”, hay còn gọi với các tên
khác như “dot-dot-slash”, “directory clumbing”. Là hình thức tấn công truy cập đến
những file và thư mục mà được lưu bên ngoài webroot. Một hệ thống phát hiện xâm
nhập hiểu được phương thức GET của giao thức HTTP nên nó sẽ cho phép request
này. Tuy nhiên vấn đề là có vô hạn cách mã hóa các chuỗi độc hại dẫn đến việc nếu
ta cấu hình một IDS nhằm phát hiện chuỗi độc hại này dựa trên “signature” thì
không thể đảm bảo sẽ phát hiện được hết. Một cách khác đó là bình thường hóa
chuỗi này, sau đó so sánh nó với một danh sách “known bad” để phát hiện.
3.2. Output
Mô-đun ouput được thêm vào Snort từ phiên bản 1.6. Chúng cho phép Snort có
nhiều cấu hình linh hoạt hơn trong việc định dạng và trình bày dữ liệu đầu ra cho
người quản trị hệ thống. Các mô-đun output này sẽ được khởi chạy khi một sự kiện
cảnh báo hoặc yêu cầu ghi log được gọi, sau quá trình tiền xử lý và phát hiện thông
qua detection engine.
Trong tập tin cấu hình của Snort ta có thể cấu hình nhiều mô-đun đầu ra khác nhau
và các mô-đun này sẽ được gọi thứ tự khi có một sự kiện nào đó xảy ra. Mặc định
41
các cảnh báo và các tập tin log sẽ được ghi vào thư mục /var/log/snort hoặc
bất kỳ thư mục nào mà người quản trị cấu hình.
Snort hỗ trợ nhiều mô-đun output khác nhau bao gồm:
alert_syslog: Cấu hình này cho phép Snort sẽ gửi thông báo tới syslog.
alert_fast: Các cảnh báo của Snort sẽ được in ra một cách nhanh chóng nhất.
Đây là một phương pháp ghi các cảnh báo nhanh hơn hẳn so với alert_full vì nó
không cần in ra tất cả phần header của gói tin và bởi vì nó chỉ in ra trong một tập tin
duy nhât.
alert_full: Các cảnh báo sẽ được in ra với đầy đủ phần header của các gói
tin. Mặc định thông tin sẽ được lưu tại /var/log/snort hoặc một thư mục được chỉ
định. Snort sẽ tạo ra các thư mục con chứa các cảnh báo ứng với mỗi IP, điều này
làm cho hoạt động của Snort chậm đi do đó nó không được khuyến khích sử dụng.
alert_unixsock: Tùy chọn này yêu cầu thiết lập một UNIX domain socket và
gửi cảnh báo tới nó. Các chương trình hoặc các tiến trình mở rộng sẽ lắng nghe trên
socket đó giúp cho việc nhận các cảnh báo các các gói dữ liệu trong thời gian thực.
log_tcpdump: Tùy chọn cấu hình này cho phép Snort ghi các tập tin log ở định
dạng tập tin của chương trình tcpdump. Điều này đặc biệt hữu ích trong việc tổng
hợp và phân tích các thông tin với số lượng lớn. Có rất nhiều công cụ có thể đọc
được định dạng này lên nó rất hữu ích.
csv: Đây là một định dạng lưu trữ dạng text với các trường được phân cách nhau
bởi dấu phẩy. Định dạng này giúp ta có thể dễ dàng import vào các cơ sở dữ liệu.
unified và unified2: Là hai định dạng đầu ra thống nhất, phiên bản unified2
là phiên bản cải tiến của unified. Ưu điểm của phương pháp lưu trữ với các định
dạng đầu ra thống nhất đó là: cho phép dễ dàng trong việc lưu trữ và quản lý, có tốc
độ nhanh hơn hẳn so với các phương pháp khác, tập tin xuất ra khó có thể chỉnh sửa
nội dung.
log_null: Tùy chọn này hữu ích trong một số trường hợp muốn tạo ra một vài
quy tắc cảnh báo lưu lượng truy cập mạng mà không muốn ghi ra các tập tin log.
42
CHƯƠNG 4
LUẬT TRONG SNORT
Giới thiệu
“Luật” trong Snort ta có thể hiểu một cách đơn giản nó giống như các quy tắc và
luật lệ trong thế giới thực. Nghĩa là nó sẽ có phần mô tả một trạng thái và hành động
gì sẽ xảy ra khi trạng thái đó đúng. Một trong những điểm đáng giá nhất của Snort
đó là khả năng cho phép người sử dụng có thể tự viết các luật của riêng mình hoặc
tùy biến các luật có sẵn cho phù hợp với hệ thống mạng của mình. Ngoài một cơ sở
dữ liệu lớn mà người sử dụng có thể download từ trang chủ của Snort , người quản
trị có thể tự phát triển các luật cho hệ thống của mình. Thay vì phải phụ thuộc vào
nhà cung cấp, một cơ quan bên ngoài, hoặc phải cập nhật khi có một cuộc tấn công
mới hay một phương pháp khai thác lỗ hổng mới được phát hiện. Người quản trị có
thể viết riêng một luật dành cho hệ thống của mình khi nhìn thấy các lưu lượng
mạng bất thường và so sánh với bộ luật được cộng đồng phát triển. Ưu điểm của
việc tự viết các luật là có thể tùy biến và cập nhật một cách cực kỳ nhanh chóng khi
hệ thống mạng có sự bất thường.
Ví dụ: “Nếu có người cố gắng mở cửa ô tô thì còi sẽ hú.”.
Phân tích ở đây ta hành động “còi hú” sẽ được thực hiện nếu có dấu hiệu là “có
người cố gắng mở cửa ô tô”.
Trong hệ thống mạng cũng vậy, ta không thể sử dụng ngôn ngữ tự nhiên hằng ngày
để mô tả dấu hiệu hay trạng thái của hệ thống mạng được. Ví dụ: Nếu có một kết nối
SSH có địa chỉ IP Public kết nối tới máy chủ web thì chặn lại . Mặc dù đây là một
mô tả khá cụ thể, tuy nhiên Snort lại không thể hiểu được. Luật trong Snort sẽ giúp
ta dễ dàng mô tả dấu hiệu này theo ngôn ngữ mà Snort có thể hiểu được.
Để biết cách viết một luật từ các dữ liệu của hệ thống ta cần phải hiểu cấu trúc của
luật trong Snort như thế nào. Một luật trong Snort được chia thành hai phần đó là
43
phần header và options. Phần header bao gồm: rule action, protocol, địa chỉ ip
nguồn, địa chỉ ip đích, subnetmask, port nguồn, port đích. Phần options bao gồm
các thông điệp cảnh báo, thông tin các phần của gói tin sẽ được kiểm tra để xác định
xem hành động nào sẽ được áp dụng.
4.1. Rule Header
Rule Header
Hình 4.1: Cấu trúc luật trong Snort.
4.1.1. Rule Action
Phần Header sẽ chứa các thông tin xác định ai, ở đâu, cái gì của một gói tin, cũng
như phải làm gì nếu tất cả các thuộc tính trong luật được hiện lên. Mục đầu tiên
trong một luật đó chính là phần rule action, rule action sẽ nói cho Snort biết phải
làm gì khi thấy các gói tin phù hợp với các luật đã được quy định sẵn. Có 5 hành
động mặc định trong Snort đó là: alert (cảnh báo), log (ghi lại log), pass (cho qua),
active (kích hoạt), dynamic. Ngoài ra nếu chạy Snort ở chế độ inline còn có thêm
các tùy chọn bổ sung như drop, reject và sdrop.
alert - tạo ra cảnh báo sử dụng phương pháp đã lựa chọn trước và sau đó
ghi log lại các gói tin.
log - ghi log lại các gói tin.
pass - bỏ qua gói tin đó.
active - cảnh báo và sau đó bật một dynamic rule khác để kiểm tra thêm
điều kiện của gói tin.
dynamic - duy trì trạng thái “nhàn rỗi” cho đến khi được kích hoạt bởi
một active rule sau đó hành động như một log rule
Rule
Action Protocol Src/Des Port
Rule Option
44
drop - chặn gói tin đó và ghi log lại.
reject - chặn gói tin, ghi log lại và gửi trả về một thông điệp.
sdrop - chặn gói tin nhưng không ghi log lại.
hành động do user tự định nghĩa.
4.1.2. Protocol
Trường tiếp theo trong luật đó là protocol. Có 4 giao thức mà Snort hiện đang phân
tích các hành vi bất thường đó là TCP, UDP, ICMP và IP.
4.1.3. IP Address
Mục tiếp theo của phần header đó là địa chỉ IP. Các địa chỉ này dùng để kiểm tra
nơi đi và nơi đến của một gói tin. Địa chỉ ip đó có thể là địa chỉ của một máy đơn
hoặc cũng có thể là địa chỉ của một lớp mạng. Từ khóa “any” được sử dụng để định
nghĩa một địa chỉ bất kỳ.
Một địa chỉ ip sẽ được viết dưới dạng ip_address/netmask. Điều này có nghĩa là nếu
netmask là /24 thì lớp mạng đó là lớp mạng C, /16 là lớp mạng B hoặc /32 là chỉ
một máy đơn. Ví dụ: địa chỉ 192.168.1.0/24 có nghĩa là một dải máy có địa chỉ IP từ
192.168.1.1-192.168.1.255.
Trong hai địa chỉ IP trong một luật Snort thì sẽ có một địa chỉ IP nguồn và một địa
chỉ IP đích. Việc xác định đâu là địa chỉ nguồn, đâu là địa chỉ đích phụ thuộc vào
“→”.
Ngoài ra toán tử phủ định có thể được áp dụng cho việc định địa chỉ IP. Có nghĩa là
khi sử dụng toán tử này thì Snort sẽ bỏ qua việc kiểm tra địa chỉ của gói tin đó.
Toán tử đó là “!”. Ngoài ra ta có thể định nghĩa một danh sách các địa chỉ IP bằng
cách viết liên tiếp chúng cách nhau bởi một dấu “,”.
Ví dụ:
alert tcp any any → ![192.168.1.0/24, 172.16.0.0/16] 80
(msg:\ “Cho phep truy cap”)
4.1.4. Port
45
Port có thể được định nghĩa bằng nhiều cách. Với từ khóa “any” giống như địa chỉ
IP để chỉ có thể sử dụng bất kỳ port nào. Gán một port cố định ví dụ như gán kiểm
tra ở port 80 http hoặc port 22 ssh. Ngoài ra ta cũng có thể sử dụng toán tử phủ định
để bỏ qua một port nào đó hoặc liệt kê một dải các port.
Ví dụ:
log udp any any → 192.168.1.0/24 1:1024 - port bất kỳ tới dãy port từ 1
- 1024.
log udp any any → 192.168.1.0/24 :6000 - port bất kỳ tới dãy port nhỏ
hơn 6000.
log udp any any → 192.168.1.0/24 500: - port bất kỳ tới dãy port lớn
hơn 500.
log udp any any → 192.168.1.0/24 !6000:6010 - port bất kỳ tới bất kỳ
port nào, bỏ qua dãy port từ 6000 – 6010.
4.1.5. Điều hướng
Toán tử hướng “→” chỉ ra đâu là hướng nguồn, đâu là hướng đích. Phần địa chỉ IP
và port ở phía bên trái của toán tử được coi như là địa chỉ nguồn và port nguồn,
phần bên phải được coi như địa chỉ đích và port đích. Ngoài ra còn có toán tử “<>”
Snort sẽ xem cặp địa chỉ/port nguồn và đích là như nhau. Nghĩa là nó sẽ ghi/phân
tích ở cả hai phía của cuộc hội thoại.
Ví dụ:
log tcp !192.168.1.0/24 any <> 192.168.1.0/24 23
4.1.6. Activate/Dynamic rule
Cặp luật này cung cấp cho Snort một khả năng rất mạnh mẽ. Active rule giống như
alert rule nhưng khác một điểm là nó có thêm trường: activates. Dynamic rule giống
như log rule nhưng nó có thế trường: activated_by và count.
Ví dụ:
46
activate tcp !$HOME_NET any → $Home_Net 143 (flags:PA;
content: “|E8C0FFFFFF|/bin”; activates:1; msg:”IMAP buffer
overflow!”;)
dynamic tcp !$HOME_NET any → $HOME_NET 143 (activated_by:1;
count:50;)
4.2. Rule Options
Rule options chính là trung tâm của việc phát hiện xâm nhập. Nội dung chứa các
dấu hiệu để xác định một cuộc xâm nhập. Nó nằm ngay sau phần Rule Header và
được bọc bởi dấu ngoặc đơn “()”. Tất cả các rule options sẽ được phân cách nhau
bởi dấu chấm phẩy “;”, phần đối số sẽ được tách ra bởi dấy hai chấm “:”.
Có 4 loại rule options chính bao gồm:
- General: Tùy chọn này cung cấp thông tin về luật đó nhưng không có bất cứ
ảnh hưởng nào trong quá trình phát hiện.
- Payload: Tùy chọn liên quan đến phần tải trong một gói tin.
- Non-payload: Bao gồm các tùy chọn không liên quan đến phần tải của gói
tin (header).
- Post-detection : Các tùy chọn này sẽ gây ra những quy tắc cụ thể sau khi
một luật đã được kích hoạt.
4.2.1. General
a. msg
msg là một từ khóa phổ biến và hữu ích được sử dụng khi muốn gán thêm một
chuỗi văn bản vào log và cảnh báo. Chuỗi văn bản đó sẽ được bọc trong dấu ngoặc
kép “”. Nếu muốn thể hiện ký tự đặc biệt thì thêm dấu \ đằng trước.
Ví dụ:
msg: “Chuỗi văn bản được đặt ở đây.”
b. reference
reference là một từ khóa được sử dụng khi muốn tham chiếu thông tin từ một hệ
thống khác trên Internet.
47
System URL Prefix
bugtraq http://www.securityfocus.com/bid
cve http://cve.mitre.org/cgi-
bin/cevname.cgi?name=
nessus http://cgi.nessus.org/plugins/dump.php3?id=
arachnids http://www.whitehats.com/info/IDS (down)
mcafee http://vil.nai.com/vil/content/v_
osvdb http://osvdb.org/show/osvdb
url http://
Hình 4.2: Bảng reference.
Cấu trúc:
reference:<id system>, <id>; [reference:<id system>, <id>;]
Ví dụ:
alert tcp any any -> any 7070 (msg:"IDS411/dos-realaudio";
flags:AP;content:"|fff4 fffd 06|";\
reference:arachnids,IDS411;)
alert tcp any any -> any 21 (msg:"IDS287/ftp-wuftp260-
venglin-linux"; flags:AP; content:"|31c031db 31c9b046 cd80
31c031db|"; reference:arachnids,IDS287;
reference:bugtraq,1387; reference:cve,CAN-2000-1574;)
c. sid
Từ khóa sid được sử dụng để xác định duy nhất một luật trong Snort. Tùy chọn này
cho phép output plug-in có thể định danh các luật một cách dễ dàng. Tùy chọn này
nên được sử dụng với từ khóa rev.
<100, sẽ được sử dụng trong tương lai.
100 – 999,999 các luật được chứa trong các hệ thống Snort phân tán.
48
>= 1000, 000 sử dụng cho các luật cục bộ.
d. rev
Từ khóa rev được sử dụng để định danh các sửa đổi trong luật của Snort. Từ khóa
này thường được sử dụng để phân biệt các phiên bản luật khác nhau.
e. classtype
Từ khóa classtype dùng để phân loại các hình thức tấn công kèm theo độ ưu tiên
của loại tấn công đó. Các hình thức đó được định nghĩa trong tập tin
classification.config.
config classification: <name>, <description>, <priority>
config classification: web-application-attack,Web Application
Attack,1
config classification: network-scan, Detection of a Network
Scan,3
config classification: misc-activity,Misc activity,3
f. priority
Được sử dụng để gán mức độ nghiêm trọng của một quy tắc. Trường classtype gán
giá trị ưu tiên mặc định của một loại tấn công tuy nhiên ta có thể ghi đè độ ưu tiên
với từ khóa này.
Cấu trúc:
priority:<priority integer>;
Ví dụ:
alert tcp any any -> any 80 (msg:"WEB-MISC phf attempt";\
flags:A+; content:"/cgi-bin/phf"; priority:10;)
4.2.2. Payload
a. content
Từ khóa content cho phép người sử dụng thiết lập các luật cho phép tìm kiếm các
chuỗi cụ thể trong phần tải của gói tin và kích hoạt các cảnh báo dựa trên các dữ
49
liệu đó. Nội dung có thể ở dạng ASCII, mã nhị phân hoặc sự kết hợp của cả hai. Dữ
liệu nhị phân phải được bọc trong ký tự “| |” (đường ống) và được biểu diễn ở dạng
số thập lục phân.
Ví dụ:
alert tcp any any -> any 139 (content:"|5c
00|P|00|I|00|P|00|E|00 5c|";)
alert tcp any any -> any 80 (content:!"GET";)
b. nocase
Sử dụng kết hợp với từ khóa content để tìm kiếm các nội dung mà không phân biệt
chữ hoa chữ thường.
c. rawbyte
Từ khóa rawbytes cho phép các luật xem xét các gói dữ liệu thô chưa được giải mã.
Ví dụ:
alert tcp any any -> any 21 (msg:"Telnet NOP"; content:"|FF \
F1|"; rawbytes;)
d. depth
Từ khóa depth được sử dụng để xác định khoảng cách bao xa mà luật đó sẽ tìm
kiếm tới. Tối thiểu là 1 và tối đa là 65535. Được sử dụng kết hợp với từ khóa
content để giới hạn nội dung tìm kiếm, kết hợp với từ khóa offset thì ta sẽ xác định
được một khoảng dữ liệu để so sánh với mẫu trong content.
e. offset
Từ khóa offset được sử dụng để xác định điểm bắt đầu tìm kiếm “mẫu” trong một
gói tin. Từ khóa này cho phép giá trị từ -65535 tới 65535. Từ khóa offset được sử
dụng kết hợp với từ khóa content để giới hạn khoảng không gian tìm kiếm.
Ví dụ:
alert tcp 192.168.1.0/24 any -> any any (content: \"HTTP";
offset: 4; depth: 40; msg: "HTTP matched";)
50
Có một sự thú vị ở hai luật sau:
content:"GET"; offset:0; content:"downloads"; offset:13;
content:"GET"; content:"downloads";
f. distance
Từ khóa distance được sử dụng trong trường hợp muốn bỏ qua bao nhiêu byte từ
nội dung tìm kiếm trước đó.
Ví dụ:
content:"GET"; depth:3; content:"downloads"; distance:10;
Luật trên có ý nghĩa là sau khi tìm được chuỗi “GET” trong 3 byte đầu tiên của
trường dữ liệu, luật sẽ di chuyển thêm 10 byte so với vị trí cuối cùng của “GET” và
sau đó mới tìm kiếm “download”.
g. within
Từ khóa within được sử dụng để đảm bảo rằng có nhiều nhất N byte giữa các mẫu
nội dung tìm kiếm. Nó gần giống với từ khóa depth nhưng nó không bắt đầu từ đầu
của gói tin như depth mà bắt đầu từ “mẫu” trước đó.
Ví dụ:
content:"GET"; depth:3 content:"download"; distance:10 \
within:9;
Luật này tương tự như luật trên, tìm “GET” trong 3 byte đầu tiên của trường dữ
liệu, di chuyển thêm 10 byte bắt đầu từ “GET” và tìm khớp “download”. Tuy nhiên,
“download” phải xuất hiện trong 9 byte tiếp theo.
h. uricontent
Tương tự như từ khóa content ngoại trừ việc nó được sử dụng để tìm kiếm chuỗi
trong trường URI.
Ví dụ:
log tcp any any -> any 80 (content: "Logging PHF"; \
uricontent:"/cgibin/phf";)
51
i. pcre (http://www.pcre.org/)
PCRE là từ viết tắt của Perl Compatible Regular Expressions có thể dịch là biểu
thức chính quy tương thích với Perl. Perl là một ngôn ngữ kết xuất và báo cáo thực
dụng dùng để xử lí và thao tác trên các chuỗi ký tự.
Ví dụ:
alert tcp any any -> any 80 (content:"/foo.php?id="; \
pcre:"/\/foo.php?id=[0-9]{1,10}/iU";)
Luật trên thực hiện một tìm kiếm trong HTTP URI mà không phân hoa thường phần
phía sau của chuỗi foo.php?id=<some numbers>.
4.2.3. Non-Payload
a. ttl
Từ khóa ttl được sử dụng để kiểm tra giá trị time-to-live trong IP Header. Từ khóa
ttl được sử dụng để phát hiện một hành động cố gắng traceroute mạng.
Cấu trúc:
ttl:[<, >, =, <=, >=]<number>;
ttl:[<number>]-[<number>];
Ví dụ:
ttl:<3
b. tos
Từ khóa tos được sử dụng để kiểm tra trường ToS (type of service) trong IP Header.
Ví dụ:
tos:!4;
c. id
Từ khóa id được sử dụng để kiểm tra các giá trị cụ thể trong trường ID của IP
Header. Một vài công cụ (khai thác lỗi, scan…) thường thiết lập các giá trị đặc biệt
cho các mục đích khai thác ví dụ như giá trị 31337 thường được attacker sử dụng.
52
d. ipopts
Từ khóa ipopts được sử dụng để kiểm tra trường IP Option trong IP Header. Trường
này có kích thức 20 bit và có các giá trị sau:
rr Record Router
eol End of list
nop No Op
ts Time Stamp
sec IP Security
esec IP Extended Security
lssr Loose Source Routing
lssre Loose Source Routing (For MS99-038 and CVE-
1999-0909)
ssrr Strict Source Routing
satid Stream identifier
any any IP options are set
Hình 4.3: Bảng ipopts.
Cấu trúc:
ipopts:<rr|eol|nop|ts|sec|esec|lsrr|lsrre|ssrr|satid|any>;
Ví dụ: Luật này sẽ kiểm tra giá trị IP Option là Loose Source Routing
ipopts:lsrr;
e. fragbits
Trường này được sử dụng để kiểm tra sự phân mảnh và bit reserved trong trường 3
bit Flags của IP Header. 2 bit được dùng để điều khiển sự phân mảnh có giá trị D
(Don’t Fragment) và M (More Fragment) và 1 bit có giá trị R (Reserved). Các bổ từ
sau được sử dụng thêm để thiết lập các giá trị phù hợp.
53
+: Phù hợp với một hoặc nhiều bit đã quy định.
*: Phù hợp nếu các bit đã quy định được thiết lập.
!: Phù hợp nếu các bit quy định không được thiết lập.
Ví dụ:
fragbits:MD+;
Luật này kiểm tra phù hợp nếu trường fragbits có giá trị MD.
f. dsize
Từ khóa dsize được sử dụng để kiểm tra kích thước của phần dữ liệu trong gói tin.
Lí do là attacker có thể thay đổi kích thước của phần dữ liệu này gây ra lỗi tràn bộ
đệm.
Cấu trúc:
dsize:min<>max;
dsize:[<|>]<number>;
Ví dụ:
dsize:300<>400;
g. flag
Từ khóa flag được sử dụng để kiểm tra các bit trong trường TCP Flag của TCP
Header. Các bit này gồm:
F FIN - Finish (LSB in TCP Flags byte)
S SYN - Synchronize sequence numbers
R RST - Reset
P PSH – Push
A ACK – Acknowledgment
U URG – Urgent
Hình 4.4: Bảng flag
54
Ví dụ:
alert tcp any any -> 192.168.1.0/24 any (flags: SF;
msg:"SYNC-FIN packet detected";)
Luật này cảnh báo khi kiểm tra trường TCP Flag và thấy cờ SYN và cờ FIN.
h. flow
Từ khóa flow được sử dụng để áp dụng một luật nên các gói tin di chuyển theo một
hướng cụ thể. Các tùy chọn của từ khóa này bao gồm:
to_client, to_server, from_client, from_server, established,
not_established, stateless, no_stream, only_stream, no_frag,
only_frag.
Ví dụ:
alert tcp !$HOME_NET any -> $HOME_NET 21 (msg:"cd incoming \
detected"; flow:from_client; content:"CWD incoming"; nocase;)
i. sed
Từ khóa sed được sử dụng để kiểm tra giá trị sequence number của TCP Header .
j. ack
Từ khóa ack được sử dụng để kiểm tra giá trị acknowledge number của TCP
Header.
k. window
Từ khóa window được sử dụng để kiểm tra kích cỡ của cửa sổ trong TCP Header.
l. itype
Từ khóa itype được sử dụng để kiểm tra giá trị trong trường Type của ICMP
Header. Trường này có độ dài 8 bit chứa tất cả 0-255 giá trị.
Type Name Reference
0 Echo Reply [RFC792]
3 Destination Unreachable [RFC792]
4 Source Quench [RFC792]
55
5 Redirect [RFC792]
6 Alternate Host Address [JBP]
7 Unassigned [JBP]
8 Echo [RFC792]
9 Router Advertisement [RFC1256]
10 Router Selection [RFC1256]
11 Time Exceeded [RFC792]
12 Parameter Problem [RFC792]
13 Timestamp [RFC792]
14 Timestamp Reply [RFC792]
15 Information Request [RFC792]
16 Information Reply [RFC792]
17 Address Mask Request [RFC950]
18 Address Mask Reply [RFC950]
19 Reserved (for Security) [Solo]
20-29 Reserved (for Robustness Experiment) [ZSu]
30 Traceroute [RFC1393]
31 Datagram Conversion Error [RFC1475]
32 Mobile Host Redirect [David Johnson]
37 Domain Name Request [RFC1788]
38 Domain Name Reply [RFC1788]
39 SKIP [Markson]
40 Photuris [RFC2521]
Hình 4.5: Bảng Type của ICMP Header
m. icode
Từ khóa icode được sử dụng để kiểm tra giá trị trong trường Code của ICMP
Header. Trường này cũng có độ dài là 8 bit. Chi tiết về giá trị của trường code có
thể xem ở hình phía dưới.
56
Hình 4.6: Giá trị Code của ICMP Header
57
n. icmp_id
Từ khóa icmp_id được sử dụng để kiểm tra giá trị ID của ICMP Header.
o. icmp_seq
Từ khóa icmp_seq được sử dụng để kiểm tra giá trị sequence của ICMP Header.
p. rpc
Từ khóa rpc được sử dụng để phát hiện các yêu cầu dựa trên RPC. Nó sử dụng 3 đối
số đó là: số ứng dụng, số thủ tục và số phiên bản.
q. ip_proto
Từ khóa ip_proto được sử dụng để kiểm tra trường protocol trong IP Header. Danh
sách tên và số hiệu của các giao thức có thể xem ở /etc/protocols hoặc trong
rfc1700.
Ví dụ:
alert ip any any -> any any (ip_proto:igmp;).
r. sameip
Từ khóa sameip được sử dụng để kiểm tra xem địa chỉ nguồn và địa chỉ đích có
giống nhau hay không.
4.2.3. Post-detection
a. logto
Từ khóa logto được sử dụng để ghi log vào các tập tin đặc biệt. Điều này sẽ rất hữu
ích khi ta kết hợp với các dữ liệu từ các công cụ khác như wireshark để phân tích.
Ví dụ:
alert icmp any any -> any any (logto:logto_log; ttl: 100;)
Luật này sẽ ghi log lại tất cả các gói tin ICMP mà trường TTL của nó có giá trị bằng
100 và lưu vào tập tin logto_log (không cần chỉ đường dẫn tuyệt đối, mặc định lưu
vào /var/log/snort).
b. session
58
Từ khóa session được sử dụng để trích xuất người dùng từ một phiên TCP (TCP
Session). Có 3 tham số được sử dụng đó là printable sẽ chỉ in ra các dữ liệu thông
thường mà người sử dụng có thể nhìn thấy hoặc gõ được. Binary được sử dụng để
in các dữ liệu ở dạng nhị phân. All sẽ thay thế tất cả các ký tự non-printable bằng
các giá trị thập lục phân tương đương.
Ví dụ:
log tcp any any <> any 23 (session:printable;)
c. resp
Từ khóa resp là một từ khóa rất quan trọng nó cho phép chủ động tạo ra những phản
hồi tiêu diệt các phiên vi phạm. Hoạt động ở cả chế độ nội tuyến và chế độ thụ
động.
d. react
Từ khóa react cho phép tạo ra các phản hồi bao gồm gửi một website hoặc một nội
dung nào đó tới client và sau đó đóng kết nối lại. Hoạt động cả ở chế độ nội tuyến
và chế độ thụ động.
e. tag
Từ khóa tag cho phép các luật ghi log nhiều hơn một gói tin khi luật đó được kích
hoạt. Khi một luật được kích hoạt lưu lượng truy cập liên quan đến địa chỉ nguồn và
đích sẽ được gắn “tag”. Lưu lượng được tag là các luồng lưu lượng được ghi log
giúp cho quá trình phân tích và phản hồi lại các cuộc tấn công.
Ví dụ:
alert tcp any any -> any 23 (flags:S,CE;
tag:session,10,seconds;)
Luật này sẽ ghi log 10 giây đầu tiên của session mà luật này được kích hoạt.
f. detection_filter
Từ khóa detection_filter định nghĩa một mức được thực thi bởi địa chỉ nguồn hoặc
địa chỉ đích trước khi một luật phát sinh một sự kiện. Cấu trúc của từ khóa
detection_filter như sau:
59
detection_filter: \
track <by_src|by_dst>, \
count <c>, seconds <s>;
Tùy chọn Mô tả
track
by_src|by_dst
Mức theo dõi địa chỉ nguồn hoặc địa chỉ đích
count c Số tối đa phù hợp với luật cho phép trước khi
giới hạn detection_filter được thực thi. Giá
trị “c” phải khác 0.
seconds s Khoảng thời gian mà giá trị count được tính
lũy. Giá trị “s” phải khác 0.
Hình 4.7: Tham số của từ khóa detection_filter.
Thông thường từ khóa detection_filter là bước cuối cùng trong quá trình phát hiện
xâm nhập.
Ví dụ:
drop tcp 10.1.2.100 any -> 10.1.1.100 22 ( \
msg:"SSH Brute Force Attempt"; flow:established,to_server; \
content:"SSH"; nocase; offset:0; depth:4; \
detection_filter:track by_src, count 30, seconds 60; \
sid:1000001; rev:1;)
Ở ví dụ trên mô tả một hành động tấn công SSH Brute Force. Luật này sẽ được thực
thi khi mà attacker cố gắng đăng nhập nhưng thất bại từ địa chỉ nguồn 10.1.2.100
trong thời gian 60s và sau 30 lần đăng nhập thất bại.
g. threshold
Từ khóa threshold được sử dụng để quy định một giới hạn nào đó mà các luật của
Snort đưa ra cảnh báo. Từ khóa này được đưa ra để nhằm tránh các attacker có thể
tấn công hệ thống một cách có chủ đích để kích hoạt Snort liên tục tạo ra các cảnh
60
báo và làm cho hệ thống quá tải. Từ khóa threshold có hay tùy chọn chính đó là
limit và threshold.
Limit nghĩa là quy định trong một khoảng thời gian bao nhiêu lâu thì bao nhiêu cảnh
báo được kích hoạt.
Ví dụ:
alert tcp $external_net any -> $http_servers
$http_ports(msg:"web-misc robots.txt access"; flow:to_server,
established; uricontent:"/robots.txt"; nocase;
reference:nessus,10302; classtype:web-application-activity;
threshold:type limit, track by_src, count 1 , seconds 60;
sid:1000852; rev:1;)
Luật trên có ý nghĩa là trong khoảng thời gian 60s nếu có bất kỳ traffic nào phù hợp
với luật trên thì cũng chỉ tạo một cảnh báo duy nhất.
Threshold nghĩa là trong một khoảng thời gian bao nhiêu lâu, bao nhiêu lần vi phạm
thì một cảnh báo sẽ được tạo ra.
Ví dụ:
alert tcp $external_net any -> $http_servers
$http_ports(msg:"web-misc robots.txt access"; flow:to_server,
established; uricontent:"/robots.txt"; nocase;
reference:nessus,10302; classtype:web-application-activity;
threshold:type threshold, track by_dst, count 10 , seconds 60
; sid:1000852; rev:1;)
Luật trên có ý nghĩa là ở lần vi phạm thứ 10 trong khoảng thời gian 60s thì cảnh báo
sẽ được tạo ra. Nếu có ít hơn 10 lần vi phạm trong vòng 60s thì sẽ không có bất cứ
cảnh báo nào được tạo ra. Luật trên rất hữu hiệu trong các tình huống attacker cố
gắng brute force để đăng nhập vào hệ thống.
61
CHƯƠNG 5
PHÂN TÍCH MỘT SỐ LUẬT TRONG SNORT
5.1. Khảo sát luật scan
Quá trình scanning thực chất là quá trình thu thập các thông tin về hệ thống một
cách trực tiếp. Các bước thực hiện bao gồm: Xác định hệ thống có đang “sống” hay
không -> Kiểm tra xem các port nào đang được mở -> Xác định các dịch vụ đang
chạy trên hệ thống tương ứng với các port đang mở đó -> Xác định banner của từng
dịch vụ, hệ điều hành và phiên bản tương ứng với các dịch vụ đó -> Kiểm tra lỗi
của các dịch vụ đang chạy -> Chuẩn bị tấn công.
Một công cụ mạnh mẽ thường được sử dụng đó là nmap. Nmap hỗ trợ nhiều kiểu
scan khác nhau như: TCP, Null, Xmas, SYN, FIN scan hoặc các kỹ thuật xác định
phiên bản hệ điều hành.
5.1.1. FIN Scan
Luật dưới đây được viết để phát hiện kỹ thuật FIN Scan. FIN Scan là kỹ thuật mà
nmap sẽ gửi một loạt các gói tin đến mục tiêu với cờ duy nhất cờ FIN được thiết lập
ở trường flags của IP Header.
Cú pháp: nmap –sF <target>
msg: "BLEEDING-EDGE SCAN NMAP -f -sF"; tùy chọn này thể
hiện thông báo kỹ thuật FIN Scan với tùy chọn –f có nghĩa là gửi các gói tin
phân mảnh.
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:
"BLEEDING-EDGE SCAN NMAP -f -sF"; fragbits: !M; dsize: 0;
flags: F; ack: 0; window: 2048; reference:arachnids,162;
classtype: attempted-recon; sid: 2000543; rev:3; )
62
fragbits: !M; Trường Flag của IP Header sẽ khớp với luật nếu có giá
trị khác với giá trị “M”.
dsize: 0; Kích thước phần dữ liệu của phân mảnh bằng 0.
flags: F; Trường TCP Flag trong TCP Header có giá trị F (cờ FIN được
thiết lập).
ack: 0; window: 2048; Số ack có giá trị bằng 0 và số lượng bytes dữ
liệu trong vùng cửa số phát của TCP Header.
reference:arachnids,162; Tham chiếu tới website
http://www.whitehats.com/info/IDS mục 162.
classtype: attempted-recon; Phân loại luật này vào mục
attempted-recon.
sid: 2000543; rev:3; Số hiệu của luật này là 2000543 và là lần cập
nhật thứ 3.
5.1.2. NULL Scan
Luật dưới đây được viết để phát hiện kỹ thuật Null Scan bằng nmap. Null Scan là
một kỹ thuật tương tự như FIN Scan nhưng thay vì gán cờ FIN trong trường flags
của IP Header thì Null Scan không gán cờ gì cho trường này.
Cú pháp: nmap –sN <target>
msg: "BLEEDING-EDGE SCAN NMAP -f -sN"; tùy chọn này thể
hiện thông báo kỹ thuật Null Scan với tùy chọn –f có nghĩa là gửi các gói tin
phân mảnh.
fragbits: !M; Trường Flag của IP Header sẽ khớp với luật nếu có giá
trị khác với giá trị “M”.
dsize: 0; Kích thước phần dữ liệu của phân mảnh bằng 0.
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:
"BLEEDING-EDGE SCAN NMAP -f -sN"; fragbits: !M; dsize: 0;
flags: 0; ack: 0; window: 2048; reference:arachnids,162;
classtype: attempted-recon; sid: 2000544; rev:3; )
63
flags: 0; Trường TCP Flag trong TCP Header có giá trị 0 (không có cờ
nào được thiết lập).
ack: 0; window: 2048; Số ack có giá trị bằng 0 và số lượng bytes dữ
liệu trong vùng cửa số phát của TCP Header.
reference:arachnids,162; Tham chiếu tới website
http://www.whitehats.com/info/IDS mục 162.
classtype: attempted-recon; Phân loại luật này vào mục
attempted-recon.
sid: 2000544; rev:3; Số hiệu của luật này là 2000543 và là lần cập
nhật thứ 3.
5.1.3. XMAS Scan
XMAS Scan sẽ gửi các gói tin với 3 cờ được thiết lập đó là FIN, URG và PUSH.
Nếu cổng dịch vụ đó mở thì không có sự phản hồi nào. Nhưng nếu cổng dịch vụ đó
đóng thì gói tin với cờ RST/ACK được gửi phản hồi.
Cú pháp: nmap –sX <target>
msg: "BLEEDING-EDGE SCAN NMAP -f -sX"; tùy chọn này thể
hiện thông báo kỹ thuật Xmas Scan với tùy chọn –f có nghĩa là gửi các gói
tin phân mảnh.
fragbits: !M; Trường Flag của IP Header sẽ khớp với luật nếu có giá
trị khác với giá trị “M”.
dsize: 0; Kích thước phần dữ liệu của phân mảnh bằng 0.
flags: FPU; Trường TCP Flag trong TCP Header có giá trị FPU (gán 3
cờ FIN, URG và PUSH).
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:
"BLEEDING-EDGE SCAN NMAP -f -sX"; fragbits: !M; dsize: 0;
flags: FPU; ack: 0; window: 2048; reference:arachnids,162;
classtype: attempted-recon; sid: 2000546; rev:3; )
64
ack: 0; window: 2048; Số ack có giá trị bằng 0 và số lượng bytes dữ
liệu trong vùng cửa số phát của TCP Header.
reference:arachnids,162; Tham chiếu tới website
http://www.whitehats.com/info/IDS mục 162.
classtype: attempted-recon; Phân loại luật này vào mục
attempted-recon.
sid: 2000545; rev:3; Số hiệu của luật này là 2000543 và là lần cập
nhật thứ 3.
5.2 Win.Trojan.Ibabyfa.dldr
Win.Trojan.Ibabyfa.dldr hay được gọi với tên khác như Trojan:Win32/Sisron
(Microsoft) hay HEUR:Trojan.Win32.Generic (Kaspersky) là một trojan nguy hiểm
nằm trong top 10 trojan nguy hiểm nhất vào tháng 6 năm 2009 được phát hiện trên
nền tảng Windows.
Trojan này đều có những đặc điểm của các phần mềm độc hại như:
Mở cổng dịch vụ cho phép truy cập từ xa, điều khiển từ xa hệ thống bị lây
nhiễm mà không cần chứng thực.
Thực thi các ứng dụng mà không cần sự đồng ý của người dùng.
Cải trang thành các hành vi nguy hiểm bằng quá trình và lỗi trong bộ nhớ.
Vô hiệu hóa các ứng dụng bảo mật.
Cố gắng lây lan bằng cách sử dụng chức năng Autorun.
Copy chính nó vào các thư mục được bảo vệ.
Sửa đổi hệ thống để tự động thực thi khi hệ điều hành khởi động.
Cố gắng vượt qua hệ thống bảo mật bằng cách chỉnh sửa quyền truy cập trên
firewall.
Cài đặt một trình điều khiển.
Luật thứ 23938 trong tập luật của Snort có chức năng cảnh báo nếu trong hệ thống
mạng nội bộ bị nhiễm trojan này và cố gắng kết nối ra ngoài.
65
msg: "MALWARE-CNC Win.Trojan.Ibabyfa.dldr runtime
detection"; Tùy chọn xuất ra thông báo khi luật được kích hoạt.
flow:to_server,established; Hướng kết nối là tới phía server và
trạng thái kết nối là established.
content:"-first-logfile"; Luật sẽ được kích hoạt nếu nội dung
phần dữ liệu trong gói tin gửi đi bởi Trojan có đoạn "- f i r s t - l o g f i l e".
content:"Username-"; within:32; distance:55; Sau khi tìm
thấy chuỗi "- f i r s t - l o g f i l e" di chuyển từ cuối nội dung trên thêm 55
bytes nữa và phải tìm thấy chuỗi "Username-" trong vòng 32 bytes tiếp theo.
content:"Computer Name-"; distance:0; Sau nội dung
"Username-" bắt đầu tìm kiếm ngay chuỗi "Computer Name-".
content:"Files Copied to"; distance:0; Sau nội dung
"Computer Name-" tìm kiếm ngay chuỗi "Files Copied to".
5.3. TCP-SYN Flood
SYN Flood là một dạng tấn công từ chối dịch vụ dựa vào đặc tính hướng kết nối
của giao thức TCP. Thông thường trước khi giao tiếp với máy chủ, giao thức TCP
sẽ yêu cầu thiết lập một kênh đáng tin cậy thông qua giao thức bắt tay ba bước.
alert tcp $HOME_NET any -> $EXTERNAL_NET [25,587]
msg:"MALWARE-CNC Win.Trojan.Ibabyfa.dldr runtime
detection"; flow:to_server,established; content:"- f i r s
t - l o g f i l e"; content:"Username-"; within:32;
distance:55; content:"Computer Name-"; distance:0;
content:"Files Copied to"; distance:0;
reference:url,www.virustotal.com/latest-
report.html?resource=bf25f7588c58cd4b7cc5ac04ebfd00c5;
classtype:trojan-activity; sid:23938; rev:3;
66
Hình 5.1: Giao thức bắt tay ba bước.
B1: Client sẽ gửi một gói tin với cờ SYN tới server.
B2: Nếu server nhận được gói tin với cờ SYN thì server sẽ trả về một gói tin
với cờ SYN-ACK để xác nhận.
B3: Client gửi một gói tin với cờ ACK tới server để xác nhận đã nhận gói tin
SYN-ACK và quá trình truyền dữ liệu được bắt đầu.
Đối với SYN Flood attacker sẽ gửi hàng loạt các gói tin với cờ SYN được thiết lập.
Attacker sẽ không trả lời gói tin SYN-ACK bằng gói tin ACK để hoàn thành quá
trình bắt tay ba bước mà thay vào đó tiếp tục gửi các gói tin với cờ SYN. Server lúc
nãy sẽ ở trạng thái “chờ” và do số lượng gói tin gửi tới quá lớn dẫn đến hao tốn tài
nguyên và bộ nhớ cho các kết nối này. Và dẫn tới server bị lỗi tràn bộ đệm hoặc bị
treo, khởi động lại hoặc không thể cung cấp dịch vụ cho người dùng thông thường.
Hình 5.2: SYN Flood
67
Luật dưới đây được cung cấp bởi Bleeding Edge Threat nhằm phát hiện loại tấn
công SYN Flood trên dịch vụ NETBIOS (139) trên hệ điều hành Windows.
alert tcp $EXTERNAL_NET any -> $HOME_NET 139: Một cảng
báo sẽ được tạo ra đối với một kết nối từ mạng phía bên ngoài ở port bất kỳ
tới mạng nội bộ ở port 139 (NETBIOS) của giao thức TCP.
msg:"EXTERNAL NETBIOS TCP-SYN"; Xuất hiện thông báo về loại
tấn công TCP-SYN ở dịch vụ NETBIOS.
flags: S; Chỉ áp dụng với các gói tin được thiết lập cờ SYN.
threshold: type threshold, track by_dst, count 1000,
seconds 180; Thiết lập một ngưỡng cảnh báo, và theo dõi ở phía đích
(mạng HOME_NET). Các tùy chọn này có ý nghĩa là nếu trong khoảng thời
gian 180s nếu có 1000 gói tin được thiết lập cờ SYN gửi tới thì luật này sẽ
được ứng động.
5.4 Apache Killer (CVE-2011-3192)
Một lỗ hổng bảo mật trên phần mềm máy chủ web Apache đã được phát hiện vào
tháng 8 năm 2011. Theo cảnh báo từ Apache Foundation thì attacker có thể khai
thác lỗ hổng này nhằm mục đích tấn công từ chối dịch vụ làm tê liệt các máy chủ
web đang sử dụng các phiên bản Apache 2.0 (dưới phiên bản 2.0.65) và phiên bản
2.2 (dưới phiên bản 2.2.20).
Lỗ hổng này có thể được khai thác thông qua công cụ Apache Killer được phát tán
trên mạng Internet. Đây là một lỗ hổng thực sự nguy hiểm vì theo thống kê của
Netcaft thì hiện tại trên thế giới có trên 55% máy chủ web sử dụng Apache.
alert tcp $EXTERNAL_NET any -> $HOME_NET 139
(msg:"EXTERNAL NETBIOS TCP-SYN"; flags: S; sid: 0002;
classtype: unusual-client-port-connection; threshold:
type threshold, track by_dst, count 1000, seconds 180;)
68
Mã nguồn của Apache Killer được viết bằng ngôn ngữ Perl và có thể dễ dành
download tại địa chỉ: http://www.exploit-db.com/download/17696. Script này sẽ
yêu cầu một vài dãy bytes chồng chéo trong phần dữ liệu trong một request (khoảng
1300).
Hình 5.3: HTTP Request bình thường.
Hình 5.4: HTTP Request tạo bởi Apache Killer.
Cú pháp: perl 17696.pl <địa chỉ web server> 50
Luật dưới đây được cung cấp bởi emergingthreat giúp cảnh báo khi attacker khai
thác lỗ hổng thông qua công cụ Apache Killer.
69
alert tcp $EXTERNAL_NET any -> $HOME_NET
$HTTP_PORTS; Chỉ hướng tấn công là từ mạng phía bên ngoài vào mạng
nội bộ ở cổng http.
flow:established,to_server; Hướng kết nối tới server, trạng thái
kết nối là established.
content:"Range|3a|bytes=0-,5-0,5-1,5-2,5-3,5-4,5-
5,5-6,5-7,5-8,5-9,5-10,5-11,5-12,5-13,5-14"; Chuỗi nội
dung nhận dạng dạng tấn công này.
http_header; fast_pattern:only; chuỗi nội dung phía trên được
kiểm tra trong HTTP Header.
reference:url,seclists.org/fulldisclosure/2011/Aug/
175; Tham chiếu đến nội dung chi tiết.
5.5. Microsoft Security Bulletin MS12-020
Đây là một lỗ hổng liên quan đến dịch vụ Remote Desktop được sử dụng bởi
Termial Service (dịch vụ giúp điều khiển từ xa) trên cổng 3389 trên nền tảng hệ
điều hành Windows được phát hiện vào tháng 3/2012. Lỗ hổng này được các
attacker khai thác nhằm khiến hệ thống bị lỗi dần đến khởi động lại hoặc lỗi mà
hình xanh. Lỗ hổng bảo mật này ảnh hưởng lên nhiều phiên bản khác nhau từ
Windows XP, Windows Server 2003, Windows 7 và Windows Server 2008.
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS
(msg:"ET SCAN Kingcope KillApache.pl Apache mod_deflate
DoS attempt"; flow:established,to_server;
content:"Range|3a|bytes=0-,5-0,5-1,5-2,5-3,5-4,5-5,5-6,5-
7,5-8,5-9,5-10,5-11,5-12,5-13,5-14"; http_header;
fast_pattern:only;
reference:url,seclists.org/fulldisclosure/2011/Aug/175;
classtype:attempted-dos; sid:2013472; rev:2;)
70
Chi tiết về lỗ hổng này được cung cấp tại địa chỉ: http://technet.microsoft.com/en-
us/security/bulletin/ms12-020. Mã khai thác của lỗ hổng bảo mật này có thể
download tại địa chỉ: http://www.exploit-db.com/exploits/18606/.
Cú pháp: nc SERVER 3389 < termdd_1.dat
Luật Snort:
alert tcp any any -> $HOME_NET 3389; Cảnh báo truy cập từ
vùng mạng bất kỳ tới mạng HOME_NET ở cổng 3389.
flow:to_server,established; Hướng tới phía Server, trạng thái
kết nối established.
content:"|03 00|"; depth:2;03=ETX (End of Text), 00=NULL
char. Tìm nội dụng này trong khoảng từ byte thứ 0 tới byte thứ 2
content:"|7f 65 82 01 94|"; distance:24; within:5;
7f=Delete, 65=e, 82=, (dấu phẩy), 01=SOH (Start of Heading), 94=” (dấu
ngoặc kép bên phải). Từ mẫu trên bỏ qua 24 bytes, tìm kiếm nội dung "|7f
65 82 01 94|" trong vòng 5 bytes.
content:"|30 19|"; distance:9; within:2; 03=ETX (End of
Text), 19=EM (End of Medium). Từ mẫu trên bỏ qua 9 bytes và tìm kiếm nội
dung "|30 19|" trong vòng 2 bytes.
alert tcp any any -> $HOME_NET 3389 (msg:"ET EXPLOIT
Microsoft RDP Server targetParams Exploit Attempt";
flow:to_server,established; content:"|03 00|"; depth:2;
content:"|7f 65 82 01 94|"; distance:24; within:5;
content:"|30 19|"; distance:9; within:2;
byte_test:1,<,6,3,relative;
reference:url,msdn.microsoft.com/en-
us/library/cc240836.aspx; reference:cve,2012-0002;
classtype:attempted-admin; sid:2014383; rev:2; fwsam:src;
71
CHƯƠNG 6: CÀI ĐẶT VÀ CẤU HÌNH SNORT
6.1 Sơ đồ hệ thống
Hình 6.1: Mô hình triển khai trong thực tế với một vùng DMZ.
Hình 6.2: Mô hình thực nghiệm.
Card 1 (eth0) Card 2 (eth1)
Attacker IP: 1.2.3.4/24
Gateway: 1.2.3.5
Snort/SnortSam IP: 1.2.3.5/24 IP: 10.0.0.1/24
Web Server IP: 10.0.0.100/24
Hình 6.2: Bảng danh sách các máy trong hệ thống mạng.
72
Hệ thống bao gồm:
CentOS 6.2 x86_64 , Snort 2.9.3.1, Barnyard2-1.10 and BASE 1.4.5.
Mô hình xử lý như sau:
Hình 6.3: Mô hình xử lý của Snort, MySQL, Base.
6.2. Cài đặt Snort và SnortSam
Các gói chính:
pcre, pcre-devel.
flex.
bison
zlib, zlib-devel.
gcc, gcc-c++, make
daq-1.1.1
libdnet
snortrules-snapshot-2931
snort-2.9.3.1
73
barnyard2-1.9
Cơ sở dữ liệu: MySQL:
mysql, mysql-server.
mysql-devel
Gói hỗ trợ quản trị:
httpd.
php and php-devel.
php-cli
php-pear
php-gd
php-mysql
Công cụ quản trị:
base-1.4.5
adodb517
php-image-graph và php-image-canvas
6.2.1. Cài đặt các gói bắt buộc và Snort
Tạo thư mục cho việc cài đặt:
# cd /usr/src
# mkdir snorttemp
# cd snorttemp
Tải tất cả các gói về:
# wget http://www.snort.org/dl/snort-current/snort-
2.9.3.1.tar.gz
# wget http://www.tcpdump.org/release/libpcap-1.3.0.tar.gz
# wget http://www.snort.org/sub-rules/snortrules-snapshot-
2931.tar.gz/<oinkcode> -O snortrules-2931.tar.gz
74
# wget http://www.snort.org/dl/snort-current/daq-1.1.1.tar.gz
# wget http://libdnet.googlecode.com/files/libdnet-1.12.tgz
# wget
http://www.securixlive.com/download/barnyard2/barnyard2-
1.9.tar.gz
Giải nén các gói:
# ls
# tar -xzvf daq-1.1.1.tar.gz
# tar -xzvf libdnet-1.12.tgz
# tar -xzvf libpcap-1.3.0.tar.gz
# tar -xzvf snort-2.9.3.1.tar.gz
# tar -xzvf snortrules-2931.tar.gz
# tar -xzvf barnyard2-1.9.tar.gz
Kiểm tra các gói đã giải nén và sau bước này có thể xóa các tập tin nén vừa được tải
về.
Cài đặt libpcap.
# cd libpcap-1.3.0
# ./configure
# make
# make install
# cd /usr/lib64/
# rm libpcap.so.1
# rm libpcap.so.1.0.0
# ln -s /usr/local/lib/libpcap.so.1.3.0
/usr/lib64/libpcap.so.1.3.0
# ln -s /usr/lib64/libpcap.so.1.3.1 /usr/lib64/libpcap.so.1
# ln -s /usr/lib64/libpcap.so.1 /usr/lib64/libpcap.so
Cài đặt libdnet:
# cd libdnet-1.12
75
# ./configure && make && make install
Cài đặt daq:
# cd daq-1.1.1
# ./configure && make && make install
Cài đặt Snort từ mã nguồn.
# cd snort-2.9.3.1
# ./configure --enable-zlib -–enable-sourcefire && make &&
make install
# groupadd snort
# useradd –g snort snort –s /sbin/nologin
Tạo các thư mục.
# mkdir /etc/snort
# mkdir /etc/snort/rules
# mkdir /etc/snort/preproc_rules
# mkdir /etc/snort/so_rules
# mkdir /usr/local/lib/snort_dynamicrules
# mkdir /var/log/snort
# chown –R snort:snort /var/log/snort
Copy các tập tin cần thiết và các luật.
# cd snort-2.9.3.1/etc
# cp * /etc/snort
# cd ../../
# cd rules
# cp * /etc/snort/rules
# cd ../preproc_rules
# cp * /etc/snort/preproc_rules
76
# cp ../so_rules/precompiled/RHEL-6-0/x86_64/2.9.3.1/*
/usr/local/lib/snort_dynamicrules
# touch /etc/snort/rules/white_list.rules
/etc/snort/rules/black_list.rules
Chỉnh sửa tập tin cấu hình
# vi /etc/snort/snort.conf
Tập tin cấu hình của Snort về cơ bản sẽ được chia thành từng phần như sau.
Thiết lập các biến mạng.
Cấu hình bộ giải mã.
Cấu hình cơ bản bộ phát hiện xâm nhập (detection engine).
Cấu hình nạp các thư viện động.
Cấu hình các tiền xử lý (preprocessors)
Cấu hình các output plug-ins..
Tùy chỉnh các thiết lập về các luật.
Tùy chỉnh tiền xử lý và và bộ giải mã luật. (preprocessors and decode rule).
Tùy chỉnh các thiết lập chia sẻ đối tượng luật.
Sửa đổi những dòng sau đây.
ipvar HOME_NET 172.16.0.0/24
ipvar EXTERNAL_NET !$HOME_NET
var RULE_PATH /etc/snort/rules
var SO_RULE_PATH /etc/snort/so_rules
var PREPROC_RULE_PATH /etc/snort/preproc_rules
output unified2: filename snort.log, limit 128
dynamicpreprocessor directory
/usr/local/lib/snort_dynamicpreprocessor
77
dynamicengine
/usr/local/lib/snort_dynamicengine/libsf_engine.so
dynamicdetection directory /usr/local/lib/snort_dynamicrules
Start và kiểm thử hệ thống.
# cd /usr/local/bin
# snort –V
Trường hợp bị lỗi liên quan đến các thư viện chạy lệnh sau và thử lại Snort.
# ldconfig
# snort -V
# snort -c /etc/snort/snort.conf --dump-dynamic-
rules=/etc/snort/so_rules
6.2.3. Cấu hình MySQL Server
# cd /usr/bin
# /etc/init.d/mysqld start
# mysqladmin –u root password ‘password’
# mysql -u root -p # Hệ thống sẽ nhắc nhở đặt password trong quá trình cài
đặt
mysql> create database snort; # Tạo cơ sở dữ liệu để lưu trữ các tập tin
log của snort.
mysql> CREATE USER snort@localhost; # Tạo user mới cho snort.
mysql> SET PASSWORD for
snort@localhost=PASSWORD('snortpass'); # Tạo password cho Snort
user.
mysql> GRANT INSERT, SELECT on root.* to snort@localhost; #
Gán quyền cho user.
mysql> GRANT CREATE, INSERT, SELECT, DELETE, UPDATE on
snort.* to snort@localhost;
78
mysql> exit # đăng xuất
# cd /usr/bin # Di chuyển vô thư mục cài đặt MySQL.
# mysql -D snort -u root -p < /usr/src/snorttemp/barnyard2-
1.9/schemas/create_mysql
Chạy câu lệnh sau để tạo bảng dữ liệu, nhập mật khẩu khi được yêu cầu.
Kiểm tra bảng dữ liệu vừa được tạo.
# mysql -u root -p (nhập mật khẩu khi được yêu cầu)
mysql> use snort;
mysql> show tables;
exit;
6.2.4. Cài đặt và cấu hình Barnyard2
Cài đặt Barnyard2 từ mã nguồn.
# ./configure --with-mysql -–with-mysql-
libraries=/usr/lib64/mysql && make && make install
Bước tiếp theo là tạo các thư mục và di chuyển tập tin cấu hình. Giả sử đang đứng ở
thư mục chứa mã nguồn Barnyard2.
# cp etc/barnyard2.conf /etc/snort # Copy tập tin cấu hình của
Barnyard2 đặt vào thư mục cấu hình của Snort.
# mkdir /var/log/barnyard2
# chmod 666 /var/log/barnyard2
# touch /var/log/snort/barnyard2.waldo
# cp sid-msg.map /etc/snort # Với tập tin sid-msg.map nằm trong thư
mục etc của gói luật tải về.
Bước tiếp theo là chỉnh sửa tập tin cấu hình của Barnyard2 để chương trình có thể
ghi dữ liệu xuống MySQL. Lưu ý là tập tin cấu hình của Barnyard2 gồm có phần
chính đó là: phần khai báo biến, phần cấu hình input và cấu hình output.
79
# vi /etc/snort/barnyard2.conf
Xác định vị trí đến các tập tin quan trọng của Snort.
config reference_file: /etc/snort/reference.config
config classification_file: /etc/snort/classification.config
config gen_file: /etc/snort/gen-msg.map
config sid_file: /etc/snort/sid-msg.map
Cấu hình thư mục sẽ chứa các output log.
config logdir: /var/log/barnyard2
Cấu hình phần hostname và card mạng.
config hostname: localhost
config interface: eth0
Chỉnh sửa đường dẫn đến tập tin waldo.
config waldo_file: /var/log/snort/barnyard2.waldo
Cấu hình phần output ghi ra cơ sở dữ liệu MySQL.
Comment tùy chọn alert_fast vì mặc định Barnyard2 sẽ bật tùy chọn này.
Thêm một dòng mới để ghi vô cơ sở dữ liệu.
output database: log, mysql, user=snort password=snortpass
dbname=snort host=localhost
Chạy Snort và Barnyard2.
# cd /usr/local/bin
# snort –u snort –g snort-c /etc/snort/snort.conf –i eth0
# barnyard2 -c /etc/snort/barnyard2.conf -d /var/log/snort/ -
f snort.log -w /var/log/snort/barnyard2waldo
Để Snort và Barnyard2 tự động khởi động khi khởi động máy. Thêm vào trong file
rc.local đoạn sau.
80
/usr/local/bin/snort -u snort -g snort -c
/etc/snort/snort.conf -i eth0
/usr/local/bin/barnyard2 -c /etc/snort/barnyard2.conf -d
/var/log/snort -f snort.log -w /var/log/snort/barnyard2.waldo
6.2.5. Cài đặt BASE
Về cơ bản việc cấu hình đã xong, tuy nhiên để cho việc phân tích log và theo dõi
các cảnh báo được thuận tiện ta sẽ cài thêm BASE. BASE là một plug-in chạy trên
nền web vì vậy ta sẽ cần cài đặt và cấu hình web server hỗ trợ php.
Cài đặt BASE:
# wget
http://downloads.sourceforge.net/project/secureideas/BASE/bas
e-1.4.5/base-1.4.5.tar.gz
# wget http://sourceforge.net/projects/adodb/files/adodb-
php5-only/adodb-517-for-php5/adodb517.tgz
# tar -xzvf base-1.4.5.tar.gz
# tar -xzvf adodb517.tgz
# cp -r adodb5 /var/www
# cp -r base-1.4.5 /var/www/html/base
# cd /var/www/html/base
# cp base_conf.php.dist base_conf.php
# vi base_conf.php
...
$BASE_urlpath = "/base";
$DBlib_path = "/var/www/adodb5/";
$DBtype = "mysql";
$alert_dbname = "snort";
$alert_host = "localhost";
$alert_port = "3306";
81
$alert_user = "snort";
$alert_password = "snortpass";
...
Truy cập vào http://ip-address/base/base_main.php để thiết lập BASE.
Để hỗ trợ BASE hiển thị ở chế độ đồ họa ta cần cài đặt thêm các gói sau:
# cd /usr/bin
# pear install image_graph-alpha
# pear install Numbers_Roman
# pear install Numbers_Words-beta
# pear install image_canvas-alpha
# apachectl restart
6.2.6. Cài đặt SnortSam
Tải source libtool về và cài đặt. http://ftpmirror.gnu.org/libtool/libtool-2.4.2.tar.gz
# tar –xzvf libtool-2.4.2.tar.gz
# cd libtool-2.4.2
# ./configure –prefix=/usr
# make && make install
Tải mã nguồn của SnortSam về tại địa chỉ
http://www.snortsam.net/files/snortsam/snortsam-src-2.70.tar.gz
# tar –xzvf snortsam-src-2.70.tar.gz
# chmod +x makesnortsam.sh
# ./makesnortsam.sh
Thêm SnortSam như một plug-in của Snort.
Tải tập tin patch của snortsam tại
# cd snort-2.9.3.1 # Thư mục tập tin mã nguồn của Snort.
82
# patch -p1 < ../snortsam-2.9.3.1.diff
# sh ./autojunk.sh
# ./configure –enable-zlib –enable-sourcefire
# make && make install
Copy tập tin nhị phân của snortsam vào /usr/local/bin
Việc cài đặt và biên dịch đã hoàn tất. Tiếp theo sẽ cần cấu hình SnortSam.
# cp <path_to>/snortsam-src/etc/snortsam.conf.example
/etc/snortsam.conf
# vi /etc/snortsam.conf
...
port <666>
accept <host>/<mask>,<key>
fwsam <host>
iptables <adapter> <logoption>
email <smtpserver>:<port> <recipient> <sender>
...
Cấu hình lại Snort, sẽ phải cấu hình ở hai nơi đó là file cấu hình snort.conf và
các luật mà muốn ứng động SnortSam.
Snort.conf
Thêm dòng này vào trong tập tin cấu hình của snort.
output alert_fwsam: {SnortSam Station}:{port}/{password}
Dòng này sẽ xác định địa chỉ IP mà SnortSam đang chạy, port lắng nghe và mật
khẩu. Mật khẩu ở đây là defaultkey được cấu hình trong snortsam.conf nếu
không cấu hình có thể bỏ qua.
Rule file
Thêm fwsam: who,time; vào cuối mỗi luật.
83
who: src, source, dst, dest, destination IP address.
time: 'days', 'months', 'weeks', 'years', 'minutes',
'seconds', 'hours'.
Ngoài ra các giá trị ‘0’ hoặc 'PERManent', 'INFinite', hoặc 'ALWAYS’ sẽ chặn vĩnh
viễn.
Ví dụ:
alert tcp any any -> $HTTP_SERVERS 80 (msg:"WEB-MISC http
directory traversal"; flags: A+; content:
"..\\";reference:arachnids,298;)
Luật này sẽ thông báo với SnortSam chặn địa chỉ truy cập tới Webserver trong vòng
15 phút.
alert tcp any any -> $HTTP_SERVERS 80 (msg:"WEB-MISC http
directory traversal"; flags: A+; content:
"..\\";reference:arachnids,298; fwsam: 15 minutes;)
6.3. Thử nghiệm các kiểu tấn công
6.3.1. Scan Port
Các dạng scan port thường gặp như XMAS Scan, Null Scan, FIN Scan. Attacker sẽ
đứng phía bên ngoài scan hệ thống mạng nhằm thu thập các thông tin về cổng dịch
vụ được mở, phiên bản hệ điều hành, phiên bản các phần mềm trên máy chủ.
Luật Snort:
alert tcp any any -> $HOME_NET any (msg:”FIN Scan”; flags: F;
sid: 1000001; fwsam:src, 1 minutes;)
alert tcp any any -> $HOME_NET any (msg:”Xmas Scan”; flags:
FPU; sid: 1000002; fwsam:src, 1 minutes;)
alert tcp any any -> $HOME_NET any (msg:”NULL Scan”; flags:
0; sid: 1000003; fwsam:src, 1 minutes;)
Khi Snort phát hiện ra các dạng scan này, sẽ gửi cảnh báo tới cho agen SnortSam
trên firewall và yêu cầu firewall chặn các địa chỉ này trong vòng 1 phút.
84
6.3.2 Apache Killer
Luật Snort:
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ET
SCAN Kingcope KillApache.pl Apache mod_deflate DoS attempt";
flow:established,to_server; content:"Range|3a|bytes=0-,5-0,5-
1,5-2,5-3,5-4,5-5,5-6,5-7,5-8,5-9,5-10,5-11,5-12,5-13,5-14";
http_header; fast_pattern:only;
reference:url,seclists.org/fulldisclosure/2011/Aug/175;
classtype:attempted-dos; sid:2013472; rev:2; fwsam:src, 1
minutes;)
Attacker khai thác lỗ hổng trên các phiên bản Apache 2.0 (nhỏ hơn 2.0.65) và 2.2
(nhỏ hơn 2.2.20) nhằm tấn công từ chối dịch vụ làm tiêu tốn nhiều tài nguyên của
hệ thống, khiến hệ thống bị treo.
Luật trên khi nhận được cảnh báo của Snort, iptables sẽ chặn địa chỉ nguồn trong
vòng 1 phút.
6.3.3 Ping of Death
Attacker gửi các gói tin ICMP có kích thước lớn tới máy chủ nhằm chiếm đường
truyền và ngăn việc cung cấp dịch vụ của máy chủ. Luật Snort sẽ kiểm tra kích
thước của các gói tin ICMP được gửi tới
alert icmp any any -> $HOME_NET any (msg:”Large ICMP Packet”;
dsize: >200; sid: 1000004; fwsam:src, 1 minutes;)
6.3.4 MS12-020
Lỗ hổng được attacker khai thác qua dịch vụ Terminal Service (3389) làm hệ thống
bị shutdown đột ngột.
alert tcp any any -> $HOME_NET 3389 (msg:"ET EXPLOIT
Microsoft RDP Server targetParams Exploit Attempt";
flow:to_server,established; content:"|03 00|"; depth:2;
content:"|7f 65 82 01 94|"; distance:24; within:5;
content:"|30 19|"; distance:9; within:2;
85
byte_test:1,<,6,3,relative;
reference:url,msdn.microsoft.com/en-us/library/cc240836.aspx;
reference:cve,2012-0002; classtype:attempted-admin;
sid:2014383; rev:2; fwsam:src; 1 minutes;)
6.3.5 SQL Injection
Mô hình sử dụng web application để demo dạng tấn công SQL Injection bằng cách
truyền vào tham số ‘ or 1=1;#.
alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg:"[The system
detected Sql Injection Attack-1]";
flow:to_server,established;
uricontent:"/?id";nocase;pcre:"/(((\?id=)|(\?id%3D))(\w*)(((\
')|(\%27))((\w+)|(\W+)|(\D+)|(\d+))))/ix"; classtype:web-
application-attack; sid:1000015; rev:1; fwsam:src; 1
minutes;)
86
KẾT QUẢ ĐẠT ĐƯỢC
Tính khoa học:
Đạt được các mục tiêu của đề tài như kiến thức về hệ thống phát hiện xâm nhập, các
kỹ thuật phát hiện xâm nhập.
Tìm hiểu được kiến trúc và cách thức hoạt động của Snort/SnortSam. Cách phân
tích các tập tin log, các cảnh báo, dựa vào đó viết các luật phù hợp để phát hiện và
ngăn chặn xâm nhập.
Phân tích được một số trường hợp tấn công, phân tích được một số tập luật của các
dạng tấn công phổ biến.
Demo triển khai thử trong hệ thống mô hình.
Khả năng triển khai ứng dụng thực tế:
An toàn thông tin ở Việt Nam đang trở thành một vấn đề nóng bỏng nhất qua hàng
loạt các vụ việc các hệ thống lớn bị tấn công. Snort là hệ thống phát hiện xâm nhập
có số lượng người sử dụng rất lớn trên thế giới. Snort là phần mềm nguồn mở nên
chi phí mua bản quyền là bằng 0, chỉ phải bỏ tiền để mua đầy đủ các luật hơn từ
phía Sourcefire nếu cần thiết.
Ngoài ra hệ thống để cài đặt Snort cũng không yêu cầu cao, chỉ cần một máy chủ
tầm trung là có thể triển khai được Snort. Nên chi phí triển khai là t hấp hơn rất
nhiều so với các hệ thống phần cứng khác.
Snort có đầy đủ các tính năng kỹ thuật trong việc phát hiện xâm nhập dựa trên mẫu
và dựa trên sự bất thường.
Hoàn toàn có khả năng triển khai tốt cho bất cứ hệ thống nào trong thực tế.
Hiệu quả kinh tế - xã hội:
87
Nếu người quản trị hệ thống có kỹ năng tốt, hệ thống không cần thiết phải trả thêm
29.99$ cho người dùng cá nhân hoặc từ 399.00-499.00$ cho doanh nghiệp mỗi năm
cho việc mua thêm các bộ luật.
Chi phí thấp cho một hệ thống tốt, có đầy đủ chức năng của một hệ thống phát hiện
xâm nhập.
Kết hợp với các hệ thống nguồn mở khác như netfilter/iptables, hệ thống giám sát
như Nagios, mod_security cho ứng dụng web có thể xây dựng một hệ thống tốt có
khả năng ngăn chặn các cuộc tấn công, phân tích, theo dõi và nâng cao hiệu suất của
dịch vụ với chi phí cực kỳ thấp.
Hạn chế:
Một vài hạn chế vẫn còn tồn tại trong đề tài
Chưa cấu hình đầy đủ các luật trong iptables.
Chưa demo được các dạng tấn công trong vùng mạng nội bộ ví dụ như ARP
Spoofing hay Sniffer gói tin trong mạng nội bộ.
88
PHẦN KẾT LUẬN
89
Kết luận
Đề tài đã đạt được một số mục tiêu như hiểu về cách thức hoạt động và cách thức
phát hiện xâm nhập của hệ thống IDS. Cách bố trị một hệ thống phát hiện xâm nhập
trong hệ thống mạng ra làm sao?
Nghiên cứu và hiểu cấu trúc và cách thức xử lý gói tin của Snort cũng như
SnortSam. Hiểu rõ cấu trúc của một tập luật trong Snort. Cách thức viết một luật
cho những yêu cầu cụ thể. Phân tích dữ liệu để viết luật.
Cài đặt và cấu hình thành công hệ thống, demo các hình thức xâm nhập đơn giản.
Tác giả gặp một chút khó khăn trong việc triển khai mô hình trên máy ảo, sự phức
tạp của mô hình mạng khó thể hiện trên hệ thống ảo.
Tác giả gặp khó khăn trong việc demo các loại hình tấn công mới hiện nay, việc
demo các dạng tấn công còn ở dạng đơn giản do mục đích chỉ thử phản ứng của
Snort.
Phiên bản mới nhất của Snort chưa có gói patch SnortSam phù hợp.
Tác giả muốn tập trung vào việc hình thành nên các luật tương ứng với các dạng tấn
công thay vì cài đặt cấu hình và triển khai. Theo tìm hiểu của tác giả, việc khó khăn
nhất của xây dựng một hệ thống Snort/SnortSam không phải ở quá trình cài đặt, cấu
hình hay demo mà quá trình khó khăn nhất nằm ở phía người quản trị. Dù một hệ
thống Snort/SnortSam có tốt đến đâu nhưng nếu người quản trị không có kỹ năng
phân tích log, phân tích trạng thái của hệ thống, không nắm rõ cấu trúc của luật thì
không thể hình thành nên được các tập luật đối với môi trường doanh nghiệp được
triển khai.
Kết luật cuối cùng là việc xây dựng hệ thống phát hiện xâm nhập có tốt hay không
nằm ở phía người quản trị hệ thống. Snort/SnortSam cũng chỉ là một công cụ và
không thể phó mặc hoàn toàn vấn đề bảo mật hệ thống cho các hệ thống này.
Đề nghị
90
Nếu được tác giả hi vọng được triển khai trên một hệ thống thật, hệ thống cung cấp
đầy đủ các dịch vụ cần thiết cho người dùng cũng như có vùng mạng nội bộ cần
thiết.
Ngoài ra tác giả có khảo sát qua việc cảnh báo theo thời gian thực thông qua các
email và SMS nhưng tác giả nhận thấy một nhược điểm của ý định này đó là một
ngày hệ thống tạo ra quá nhiều cảnh báo thì việc gửi email và SMS sẽ trở nên quá
tải. Đối với người quản trị họ luôn phải kiểm tra hệ thống một cách thường xuyên
nên tác giả cho rằng ý định này không có nhiều ưu điểm.
Thay vì sử dụng các hệ thống email và SMS, tác giả đề nghị dựng một máy trạm
riêng phục vụ cho mục đích phân tích log. Log này không chỉ nhận từ Snort mà có
thể nhận từ các dịch vụ web, từ log của hệ thống hoặc nhận log thông qua syslog-
ng. Trong thời gian nghiên cứu tác giả có khảo sát và biết được 2 công cụ cực kỳ
mạnh mẽ trong việc phân tích log đó là Splunk và Aanval SAS™. Đây là 2 công cụ
có phí nhưng cực kỳ mạnh mẽ và đáng giá.
Ngoài Snort/SnortSam hệ thống có thể sử dụng các công cụ và các giải pháp nguồn
mở khác như iptables cho firewall, mod_security chuyên biệt cho web server
Apache, các giải pháp monitoring khác như Nagios, ZenOSS…
91
TÀI LIỆU THAM KHẢO
[1] Andrew T. Baker, Brian Caswell & Mike Poor (2004), Snort 2.1 Intrusion
Detection Second Edition, Syngress Publishing, Inc.
[2] Andrew R. Bakeer & Joel Esler (2007), Snort IDS and IPS Toolkit. Syngress
Publishing, Inc.
[3] David Gullett (2012), Snort 2.9.3 and Snort Report 1.3.3 on Ubuntu 12.04 LTS
Install Guide, Symmetrix Technologies.
[4] Karthikeyan .K.R & A. Indra (2010), Intrusion Detection Tools and Techniques
A Survey, International Journal of Computer Theory and Engineering, Vol.2, No.6.
[5] Rebecca Bace and Peter Mell (2011), NIST Special Publicationon Intrusion
Detection Systems, National Institute of Standards and Technology.
[6] The Snort Team (2012), Snort® User Manual 2.9.3, The Snort Project.
[7] University of Marland University College (2012), Installing Snort from Source
Code on Linux, http://polaris.umuc.edu/~sgantz/Install.html
[8] Hacker Vietnam Association (2005), Ký sự các vụ DDoS đến HVA,
http://www.hvaonline.net/hvaonline/posts/list/112.hva
[9] BleedingSnort (2009), Bộ luật cung cấp bởi BleedingSnort,
http://www.bleedingsnort.com/
92
PHỤ LỤC
1.Luật iptables cho mô hình demo
### Shell script for publish web server
### iptables and snort/snortsam
#! /bin/bash
ipt=/sbin/iptables
echo "1" > /proc/sys/net/ipv4/ip_forward
# flush config iptables
$ipt -t filter -F
$ipt -t nat -F
$ipt -t mangle -F
$ipt -t filter -X
$ipt -t nat -X
$ipt -t mangle -X
$ipt -t filter -Z
$ipt -t nat -Z
$ipt -t mangle -Z
# change policy
$ipt -P INPUT ACCEPT
$ipt -P OUTPUT ACCEPT
$ipt -P FORWARD ACCEPT
$ipt -t nat -P PREROUTING ACCEPT
$ipt -t nat -P POSTROUTING ACCEPT
# publish wwww
$ipt -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -d
1.2.3.5/24 -j DNAT --to-destination 10.0.0.100:80
$ipt -t nat -A POSTROUTING -p tcp --dport 80 -o eth1 -s
1.2.3.5/24 -j SNAT --to-source 10.0.0.1
93
$ipt -t nat -A PREROUTING -p tcp --dport 443 -i eth0 -d
1.2.3.5/24 -j DNAT --to-destination 10.0.0.100:443
$ipt -t nat -A POSTROUTING -p tcp --dport 443 -o eth1 -s
1.2.3.5/24 -j SNAT --to-source 10.0.0.1
$ipt -t nat -A PREROUTING -p tcp --dport 3389 -i eth0 -d
1.2.3.5/24 -j DNAT --to-destination 10.0.0.100:3389
$ipt -t nat -A POSTROUTING -p tcp --dport 3389 -o eth1 -s
1.2.3.5/24 -j SNAT --to-source 10.0.0.1