MỤC LỤC
1.
2.
3.
4.
5.
6.
7.
GIỚI THIỆU ........................................................................................................................... 3
THAO TÁC CHUNG.............................................................................................................. 4
PHÂN TÍCH TẬP TIN LUẬT (RULES FILE PARSING) ...................................................... 8
CẤU TRÚC DỮ LIỆU SAU KHI PHÂN TÍCH (DATA STRUCTURES AFTER PARSING)..
.............................................................................................................................................. 11
KHỞI TẠO CỦA BỘ PHÁT HIỆN GÓI TIN NHANH......................................................... 13
NHỮNG CÔNG CỤ VÀ NHỮNG TÀI NGUYÊN (TOOLS AND RESOURCES)............... 16
NHỮNG THỐNG KÊ MÃ NGUỒN (SOURCE CODE STATISTICS)................................. 17
1
NHỮNG MÔ HÌNH CỦA SNORT
Tác giả: Andrés Felipe Arboleda ([email protected])
Charles Edward Bedón ([email protected])
Universidad del Cauca – Colombia
14th – April – 2005
Version 0.2 alpha
Ref: http://afrodita.unicauca.edu.co/~cbedon/snort/snort.html
Biên soạn và cập nhật: Lê Tiến
Ngày cập nhật: 31/08/07.
2
1. GIỚI THIỆU
Mục đích giới thiệu những mô hình này về những hàm của Snort. Những đối tượng
từ mô hình tuần tự UML (những hình chữ nhật ở phía trên trong các mô hình) chỉ rõ những
tập tin chứa mã nguồn và những thông điệp (những mũi tên) giới thiệu những cách gọi hàm
với những tập tin mã nguồn tương ứng.
Tất cả những mô hình tuần tự được sắp xếp bằng cách thực hiện, nói cách khác, Snort
thực hiện bắt đầu với mô hình được minh họa trong hình 1 hình 2...
Tài liệu này không mô tả chi tiết mã nguồn của Snort, nó chỉ đưa ra những bản đồ
cho những người phát triển muốn biết cách đọc mã nguồn của Snort.
Những mô hình này đã kiểm tra ở Snort 2.2.0, thực hiện bắt lệnh sau:
snort -d -l -c
3
2. THAO TÁC CHUNG
Hình 1: Mô hình khối Snort
Mỗi module được mô tả như sau:
o Module giải mã (Decoder): chuyển những gói tin bắt được thành những cấu
trúc và những định danh liên kết những tầng giao thức. Sau đó, nó làm ở tầng
tiếp theo, mã hóa IP TCP hay UDP hay loại giao thức khác lấy những
thông tin hữu ích như những cổng và những địa chỉ... Snort sẽ cảnh báo nếu
nó tìm thấy những header không đúng cấu trúc, chiều dài TCP bất thường...
o Tiền xử lý (Preprocessor): Chúng có thể được xem như dạng bộ lọc mà xác
định những thuộc tính muốn đưa vào kiểm tra sau đó (trong những mô hình kế
tiếp như: Bộ dò tìm (Detection Engine), như nghi ngờ những kết nối thử đến
những cổng TCP/UDP hay rất nhiều gói tin UDP gởi đến trong một khoảng
thời gian ngắn (Hiện tượng: Dò cổng – Port Scan). Hàm tiền xử lý lấy các
hàm có khả năng nguy hiểm cho bộ dò (Detection Engine) bằng cách cố gắng
tìm những mẫu đã biết.
4
Những tập tin chứa những luật (Rules Files): Có những tập tin chứa
danh sách những luật với của pháp cho trước. Cú pháp này bao gồm: những
giao thức, địa chỉ, kết xuất gắn kết liên đới (output plug-ins associated)...
Những tập tin luật đó được cập nhật giống như những tập tin định nghĩa virus.
o Những plug-in cho bộ dò (Detection Plug-ins): Những module đó được
tham chiếu từ những định nghĩa của nó trong những tập tin chứa luật, và
chúng được dùng để xác định những mẫu tấn công bất cứ khi nào một luật
được thỏa.
o Bộ dò tìm (Detection Engine): thường dùng của những bổ sung bộ dò; nó
khớp (match) những gói tin tương phản những luật trước đây đã nạp vào bộ
nhớ kể từ lúc Snort khởi tạo.
o Những plug-in kết xuất (output plug-ins): Những module này cho phép định
dạng những thông báo (những cảnh báo, những nhật ký – logs) cho người
dùng truy xuất chúng bằng nhiều cách (console, những tập tin bên ngoài
(external files), những CSDL...)
5
Hình 2: Snort khởi tạo (Mô hình tuần tự 1)
Hình 3: Snort khởi tạo (Mô hình tuần tự 2)
6
Hình 4: Phân tích (Parse) tập tin luật (Mô hình tuần tự 3).
7
3. PHÂN TÍCH TẬP TIN LUẬT (RULES FILE PARSING)
Chú ý: Những hàm tiếp theo với tập tin ./parser.c
Hàm ParseRulesFile()
Hàm này phân tích, bởi 1 chu kỳ, mỗi dòng tập tin cấu hình (Ví dụ: snort.conf). Nếu
dòng là một luật hợp lệ (không phải là một chú thích), nó được đưa qua một bộ phân tích
luật (hàm ParseRule() ).
Hàm ParseRule()
Hàm này được thực thi một lần cho mỗi luật hợp lệ trong tập tin cấu hình. Ban đầu,
nó tìm những dòng không phải là những luật phát hiện xâm nhập(detection rules), nói cách
khác, những chỉ dẫn giống như include, var, tiền xử lý (preprocessor), những plug-in kết
xuất, nó gọi những hàm khởi tạo cho mỗi một luật phát hiện xâm nhập.
Nếu một luật được thỏa, điều đó có nghĩa là bắt đầu cảnh báo (alert), ghi nhật ký
(log) , pass, sự hoạt hóa (activation) hay động (dynamic), luật được kiểm chứng và đưa vào
bộ nhớ bằng hàm ProcessHeadNode().
Những luật phát hiện (Detection rules) được chứa trong bộ nhớ bên trong những cấu
trúc RuleTreeNode (RTN) và OptTreeNode (OTN) như những cấu trúc được khai báo
trong tập tin ./rules.h
Chú ý: Tham khảo thêm câu hỏi “3.17 How does rule ordering work?” of
[SnortFAQ 03].
Hàm ProcessHeadNode()
Với prototype: ProcessHeadNode(RuleTreeNode *test_node, ListHead *list,
protocol)
Nó dùng một con trỏ RTN với test_node và những gắn kết vào cuối những dãy RTN
của giao thức tương ứng trong ListHead trỏ bởi danh sách [Schildt 90].
8
Hình 5: Những cấu trúc dữ liệu (Data structures) kết hợp với hàm
ProcessHeadNode().
Hàm ParseRuleOptions()
Với prototype: ParseRuleOptions(char *rule, int rule_type, int protocol)
Nó tạo những OTN và những gắn kết (attaches) chúng với RTN trỏ bởi biết toàn cục
rtn_tmp mà được đặt bởi hàm ProcessHeadNode().
Cuối cùng nó được gọi trước đây bằng luật ParseRule().
Trong cách này lấy cấu trúc những RTN và những OTN liên kết ma trận ( chúng ta
gọi ma trận liên kết đến một cấu trúc liên kết đã kết nối 2 chiều) mà đặt những luật được
chứa trong bộ nhớ. Những RTN giữ dữ liệu trước đây cho bởi Header luật (rule header),
trong khi những OTN giữ dữ liệu cho bởi phần tùy chọn luật (Rule Options Section).
Ví dụ:
alert tcp any any -> 192.168.1.0/24 111 (content:”|00 01 86 a5|”; msg:”mountd access”;)
|------------------- Header ------------------|---------------------- Options ------------------------|
Ma trận liên kết được minh họa sau đây. Trong hình mỗi ô vuông đại diện cho một
cấu trúc dữ liệu và mỗi mũi tên, một con trỏ.
9
Hình 6: Ma trận đã kết nối (Linked matrix)
10
4. CẤU TRÚC DỮ LIỆU SAU KHI PHÂN TÍCH (DATA
STRUCTURES AFTER PARSING)
Sau khi tập tin luật được phân tích, những luật này được chứa trong những RTN và
OTN theo cấu trúc sau:
Hình 7: Cách lưu trữ những luật.
Con trỏ RuleLists là biến toàn cục mô tả trong tập tin ./parser.c, nó dùng để xem xét
kỹ (go over) tất cả các luật chứa trong bộ nhớ. Nó trỏ đến thành phần đầu tiên của danh sách
liên kết RuleListNode. Mỗi node của danh sách có một con trỏ ListHead, mỗi loại luật có
một cấu trúc (Cảnh báo-Alert, Động-Dynamic, Nhật ký-Log, Pass và Kích hoạt-Activation).
Cuối cùng, mỗi ListHead có 4 con trỏ, tương ứng với 4 giao thức (IP, TCP, UDP và
ICMP), mỗi con trỏ trỏ đến một ma trận liên kết những RTN và những OTN (nơi chứa các
luật).
11
Hình 8: Khởi tạo bộ phát hiện gói tin nhanh - Mô hình tuần tự 4
(Fast packet detection engine initialization)
12
5. KHỞI TẠO CỦA BỘ PHÁT HIỆN GÓI TIN NHANH
(INITIALIZATION OF THE FAST PACKET DETECTION ENGINE)
Khởi tạo bắt đầu bằng cách gọi hàm fpCreateFastPacketDetection() trong tập tin
./fpcreate.c từ hàm SnortMain(). Hàm fpCreateFastPacketDetection() xem xét kỹ tất cả
các luật đã có trong bộ nhớ dùng biến toàn cục RuleLists với con trỏ RuleListNode, mỗi
luật được phân lớp tương ứng với nội dung của nó (Content, UriContent hay NoContent).
Nội dung được xác định thông qua OTN tương ứng với luật. Trong OTN này chứa một
trường gọi là ds_list, nó là một mảng con trỏ trỏ đến những cấu trúc dữ liệu khác nhau, phụ
thuộc vào loại của những cấu trúc này mà nội dung được gán.
Sau khi phân lớp đầu tiên, nó được xác định nếu luật là kỹ thuật 2 chiều và một trong
các hàm prmAddRule(), prmAddRuleUri() hay prmAddRuleNC() được gọi phụ thuộc
vào loại nội dung (content type). Những hàm này sắp xếp những luật vào trong những bảng
tương ứng với cổng nguồn (source-port) và cổng đích (destination-port) trong luật. Mục
tiêu của cách này là làm cho việc so sánh những gói tin với những luật nhanh hơn.
13
Hình 9: Cấu trúc dữ liệu tương ứng với bộ phát hiện gói tin nhanh.
14
Nếu chúng ta thấy hàm fpCreateFastPacketDetection(), chúng ta đã tìm thấy khai
báo một PORT_RULE_MAP cho mỗi giao thức (tcp, udp, ip, icmp), bên trong mỗi
PORT_RULE_MAP có 3 nhóm của PORT_GROUP: một là bảng port nguồn
(prmSrcPort), tiếp theo là bảng port đích (prmDstPort), và cuối cùng là bảng đặc điểm
chung (generic) (prmGeneric) được dùng cho những luật với srcport=any và
dstport=any.
Hình 10: Khi một gói tin đến (Mô hình tuần tự 5).
15
Hình 11: Khi một gói tin đến (Mô hình tuần tự 6).
6. NHỮNG CÔNG CỤ VÀ NHỮNG TÀI NGUYÊN (TOOLS AND
RESOURCES)
Tác giả dùng những công cụ và tài nguyên sau để thử nghiệm:
OpenOffice 1.1.4
S.: Linux (Mandrake 10.1 Official).
IDE: Kdevelop v3.0 (GNU tools: make, gdb, ...)
16
7. NHỮNG
THỐNG
KÊ
MÃ
NGUỒN
(SOURCE
CODE
STATISTICS)
Với Snort 2.2.0
Thông tin chung
Number of .c files
135
Number of .h files
154
Number of source code lines (approx.)
99.317
Total size of files
2’471.751 bytes
Số lượng của những tập tin .c và .h trong một thư mục
Number Number
Directory
of
.c of
Number of Number
.h code
of Total code
lines code lines in lines in .c
files
files
in .c files
.h files
and .h files
./
27
41
26.794
5.821
32.615
./detection-plugins
28
28
10.417
756
11.173
./output-plugins
11
11
7.417
362
7.779
./parser
1
1
312
48
360
./preprocessors
18
19
17.724
951
18.675
./preprocessors/flow
13
16
4.498
835
5.333
./preprocessors/HttpInspect
14
19
5.885
923
6.808
./sfutil
17
18
12.587
1.974
14.561
./win32/WIN32-Code
6
1
1.887
126
2.013
TOTALS:
135
154
87.521
11.796
99.317
17