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

2 alpha Ref: http://afrodita.co) Universidad del Cauca – Colombia 14th – April – 2005 Version 0.unicauca.edu.co) Charles Edward Bedón (cbedon@unicauca.edu.edu. 2 .NHỮNG MÔ HÌNH CỦA SNORT Tác giả: Andrés Felipe Arboleda (aarboleda@unicauca.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.

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ất cả những mô hình tuần tự được sắp xếp bằng cách thực hiện.2. 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.1..0. Tài liệu này không mô tả chi tiết mã nguồn của Snort. Những mô hình này đã kiểm tra ở Snort 2. 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. 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.. thực hiện bắt lệnh sau: snort -d -l <path to log directory> -c <path to configuration file> 3 . nói cách khác.

Snort sẽ cảnh báo nếu nó tìm thấy những header không đúng cấu trúc. 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). 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).. 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... 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ỉ. nó làm ở tầng tiếp theo. Sau đó. chiều dài TCP bất thường.2.. 4 . 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.

Cú pháp này bao gồm: những giao thức.) 5 . những tập tin bên ngoài (external files)... địa chỉ. 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. 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 Bộ dò tìm (Detection Engine): thường dùng của những bổ sung bộ dò... những CSDL. những nhật ký – logs) cho người dùng truy xuất chúng bằng nhiều cách (console. 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. 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.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. 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.

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 .

sự hoạt hóa (activation) hay động (dynamic). 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). tiền xử lý (preprocessor). ghi nhật ký (log) .  Hàm ProcessHeadNode() Với prototype: ProcessHeadNode(RuleTreeNode *test_node.h Chú ý: Tham khảo thêm câu hỏi “3.17 How does rule ordering work?” of [SnortFAQ 03]./parser.3. điều đó có nghĩa là bắt đầu cảnh báo (alert). Nếu một luật được thỏa.c  Hàm ParseRulesFile() Hàm này phân tích. 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]./rules. ListHead *list. mỗi dòng tập tin cấu hình (Ví dụ: snort. 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 . 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 . những plug-in kết xuất.  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. bởi 1 chu kỳ. var. Nếu dòng là một luật hợp lệ (không phải là một chú thích). những chỉ dẫn giống như include. Ban đầu. nói cách khác. nó được đưa qua một bộ phân tích luật (hàm ParseRule() ). 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. pass. 8 . luật được kiểm chứng và đưa vào bộ nhớ bằng hàm ProcessHeadNode().conf).

Hình 5: Những cấu trúc dữ liệu (Data structures) kết hợp với hàm ProcessHeadNode(). 9 . int rule_type.Header ------------------|---------------------. Những RTN giữ dữ liệu trước đây cho bởi Header luật (rule header).1. một con trỏ. 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ớ. Cuối cùng nó được gọi trước đây bằng luật ParseRule().0/24 111 (content:”|00 01 86 a5|”. Ví dụ: alert tcp any any -> 192.Options ------------------------| Ma trận liên kết được minh họa sau đây.  Hàm ParseRuleOptions() Với prototype: ParseRuleOptions(char *rule. trong khi những OTN giữ dữ liệu cho bởi phần tùy chọn luật (Rule Options Section). 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.168.) |------------------. 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(). msg:”mountd access”.

Hình 6: Ma trận đã kết nối (Linked matrix) 10 .

Nó trỏ đến thành phần đầu tiên của danh sách liên kết RuleListNode./parser. 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. tương ứng với 4 giao thức (IP. 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. 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). Pass và Kích hoạt-Activation). UDP và ICMP). Động-Dynamic.4. Nhật ký-Log. nó dùng để xem xét kỹ (go over) tất cả các luật chứa trong bộ nhớ.c. Cuối cùng. mỗi ListHead có 4 con trỏ. TCP. 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. Con trỏ RuleLists là biến toàn cục mô tả trong tập tin . 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 .

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 . prmAddRuleUri() hay prmAddRuleNC() được gọi phụ thuộc vào loại nội dung (content type)./fpcreate.c từ hàm SnortMain(). Trong OTN này chứa một trường gọi là ds_list. Sau khi phân lớp đầu tiên. 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. 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. phụ thuộc vào loại của những cấu trúc này mà nội dung được gán. 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. UriContent hay NoContent). Nội dung được xác định thông qua OTN tương ứng với luật.5. 13 . nó là một mảng con trỏ trỏ đến những cấu trúc dữ liệu khác nhau. 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().

14 .Hình 9: Cấu trúc dữ liệu tương ứng với bộ phát hiện gói tin nhanh.

ip.Nếu chúng ta thấy hàm fpCreateFastPacketDetection(). tiếp theo là bảng port đích (prmDstPort). icmp). 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. chúng ta đã tìm thấy khai báo một PORT_RULE_MAP cho mỗi giao thức (tcp. 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). udp. 15 . Hình 10: Khi một gói tin đến (Mô hình tuần tự 5).

gdb.: Linux (Mandrake 10. .  IDE: Kdevelop v3.1 Official). 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.4  S.1.. 6.Hình 11: Khi một gói tin đến (Mô hình tuần tự 6).) 16 .0 (GNU tools: make..

751 bytes  Số lượng của những tập tin .417 7.779 360 18.615 11.2.498 5.887 87.724 4.) Total size of files 135 154 99.c files 26.521 ./ .317 ./preprocessors .974 126 11.675 5./preprocessors/flow ./output-plugins .h files Number of source code lines (approx./preprocessors/HttpInspect .317 2’471./parser .013 99.c files Number of .821 756 362 48 951 835 923 1.c và .c 17 .h code lines code lines in lines in .794 10.808 14.417 312 17./sfutil .561 2.7.c of files 41 28 11 1 19 16 19 18 1 154 Number of Number in ./detection-plugins .173 7.0  Thông tin chung Number of ./win32/WIN32-Code TOTALS: of files 27 28 11 1 18 13 14 17 6 135 .333 6.796 of Total code and .h trong một thư mục Number Number Directory .h files 32. NHỮNG THỐNG KÊ MÃ NGUỒN (SOURCE CODE STATISTICS)  Với Snort 2.h files 5.885 12.587 1.

Sign up to vote on this title
UsefulNot useful