Xây dựng hệ thống IDS - Snort trên hệ điều hành Linux

Snort được xây dựng với mục đích phát hiện xâm nhập vào hệ thống. Snort có khả năng phát hiện một số lượng lớn các kiểu thăm dò, xâm nhập

Giảng viên hướng dẫn : Nguyễn Ngọc Như Hằng Nhóm sinh viên thực hiện :

PHIẾU GIAO ĐỀ TÀI KHÓA LUẬN TỐT NGHIỆP

1. Mỗi sinh viên phải viết riêng một báo cáo

2. Phiếu này phải dán ở trang đầu tiên của báo cáo

1 Họ và tên sinh viên/ nhóm sinh viên được giao đề tài (sĩ số trong nhóm: )

(1) MSSV: khóa:

(2) MSSV: khóa:

(3) MSSV: khóa:

Chuyên ngành: Mạng máy tính Khoa: Khoa Học - Công Nghệ

2 Tên đề tài: Xây dựng hệ thống IDS – Snort trên hệ điều hành Linux

3 Các dữ liệu ban đầu: Snort được xây dựng với mục đích phát hiện xâm nhập vào hệ thống Snort có khả năng phát hiện một số lượng lớn các kiểu thăm dò, xâm nhập khác nhau như : buffer overflow, ICMP, virus…Snort là phần mềm open source cung cấp cho nhà quản trị các thông tin cần thiết để xử lý các sự cố khi bị xâm nhập

4 Các yêu cầu đặc biệt: Hiểu được khái niệm, cách hoạt động của IDS - Snort Cài đặt, cấu hình Snort trên hệ điều hành Ubuntu Kiểm chứng kết quả đạt được sau khi cài đặt thành công

5 Kết quả tối thiểu phải có:

1. Nắm rõ khái niệm về IDS và Snort

2. Cài đặt, cấu hình thành công Snort trên hệ điều hành Ubuntu

3.

4.

Ngày giao đề tài:…… /………./………Ngày nộp báo cáo: ……/…………/

Họ tên GV hướng dẫn 1: Nguyễn Ngọc Như Hằng…….………Chữ ký:

Họ tên GV hướng dẫn 2: ……… ……… Chữ ký:

Ngày … tháng … năm…

Xây dựng hệ thống IDS – Snort trên hệ điều hành Linux 2010

Trích Yếu

Intrusion Detection System (IDS) là hệ thống phòng chống và phát hiện xâm nhậpthông minh nhất hiện nay IDS phát hiện những tín hiệu, biểu hiện, hành vi của ngườixâm nhập trước khi có thể gây thiệt hại đến hệ thống mạng như làm cho dịch vụ mạngngừng hoạt động hay mất dữ liệu Từ đó chúng ta có thể ngăn chặn thông qua các biệnpháp kỹ thuật khác nhau

Đề tài của chúng tôi với mục tiêu là xây đựng một hệ thống Snort – IDS trên hệ điềuhành Ubuntu, hệ thống này với mục đích phát hiện và phòng chống các hành động tấncông và thâm nhập trong mạng Do đó đề tài tập trung nghiên cứu vào phương thứchoạt động và vận hành của hệ thống Snort – IDS đồng thời đưa ra cách cài đặt và thiếtlập một hệ thống IDS hoàn chỉnh trên hệ điều hành Ubuntu Bên cạnh đó chúng tôi đưa

ra giải pháp nhằm tăng cường khả năng hoạt động và vận hành của hệ thống thông quaviệc sử dụng barnyard để tăng cường khả năng ghi lại log của hệ thống và oinkmaster

để tự động liên tục cập nhật rule

Ngoài việc sử dụng hệ thống rule có sẵn, đề tài tìm hiểu cách tạo ra rule theo yêu cầunhằm giám sát và kiểm tra đối với một luồng thông tin cụ thể khi mà hệ thống rule củasnort không thể đáp ứng

Thông qua việc nghiên cứu, đề tài của chúng tôi đưa một cái nhìn tổng quan về hệthống Host-based IDS và Network-based IDS, về sự khác và giống nhau của hai hệthống từ đó có thể ứng dụng trong mô hình mạng thực tế

4

Xây dựng hệ thống IDS – Snort trên hệ điều hành Linux 2010

Mục Lục

5

Xây dựng hệ thống IDS – Snort trên hệ điều hành Linux 2010

Chúng tôi xin chân thành cảm ơn cô Nguyễn Ngọc Như Hằng - giảng viên trực tiếphướng dẫn nhóm chúng tôi thực hiện khóa luận tốt nghiệp này này, đã tận tình hướngdẫn và hỗ trợ và giúp chúng tôi giải quyết khó khăn trong quá trình nghiên cứu đề tàinày Chúng tôi chân thành cảm ơn sự nhiệt tình của cô, cô đã giúp chúng tôi giải đápnhững thắc mắc cũng như cung cấp những tài liệu cần thiết cho quá trình nghiên cứu đềtài của chúng tôi Một lần nữa xin chân thành cảm ơn cô

Chúng tôi xin gửi lời cảm ơn đến những giảng viên của ngành Mạng Máy Tính trườngđại học Hoa Sen đã tận tình giảng dạy và tạo điều kiện cho chúng tôi học tập, nghiêncứu Để từ đó chúng tôi có được một nền tảng kiến thức vững chắc làm tiền đề giúpcho chúng tôi thực hiện tốt đề tài tốt nghiệp của mình

6

Xây dựng hệ thống IDS – Snort trên hệ điều hành Linux 2010

NHẬN XÉT CỦA NGƯỜI HƯỚNG DẪN

Người hướng dẫn ký tên

7

Nhập Đề

Khái niệm tấn công một máy tính bằng việc tác động trực tiếp vào máy đó đã trở thànhquá khứ khi mà ngày nay con người có thể truy cập vào một máy chủ ở cách xa mìnhnửa vòng trái đất để lấy thông tin website, mail… Hacker cũng làm những công việctương tự nhưng họ tận dụng những lỗ hỏng của hệ thống nhằm chiếm quyền sử dụnghay ngăn chặn sự truy cập của người dùng khác vào hệ thống đó

Nhằm ngăn chặn những truy nhập trái phép vào hệ thống người ta sử dụng những thiết

bị bảo mật như Firewall hay các thuật toán mã hóa Thế nhưng đối với những máy chủchạy những dịch vụ như web, mail thì những công cụ bảo mật này vẫn chưa hoàn hảo

vì đây là những máy chủ được mọi người từ bên ngoài truy cập (public server) Hacker

sẽ lợi dụng chính những dịch vụ này để tấn công vào hệ thống Điều đó là nguyên nhândẫn đến sự cần thiết sử dụng công cụ IDS (Intrusion Detection System) với mục đích là

dò tìm và nghiên cứu các hành vi bất thường và thái độ của người sử dụng trong mạng,phát hiện ra các hành vi lạm dụng đặc quyền để giám sát hệ thống mạng

I Nguyên Lý Hoạt Động Của Snort

1 Quá trình khởi động của snort

Quá trình khởi động của snort chia làm 3 giai đoạn

• Các đối số của command-line được phân tích để xác định chế độ chạy củasnort và thiết lập các biến môi trường

• File cấu hình được xử lý, trong file này chứa các thông tin cấu hình về rule,preprocessor, output plug-in…

• Sau khi thông tin cấu hình được đọc, snort bắt đầu thiết lập detection engine,cácthư viện pcap…

1.1 Trình command-line của snort

Command line của snort rất linh hoạt và có nhiều option cho phép người dùng thiếtlập và cấu hình thông qua command line Điều này cho phép người dùng có thể thayđổi cấu hình cấu hình của snort mà không cần phải thay đổi file cấu hình Đồng thời

có thể cho phép nhiều tiến trình snort chia sẽ với nhau một file cấu hình Để xemcác command line option trong snort được xử lý thế nào người dùng có thể xem

hàm ParseCmdLine trong file snort.c Đồng thời qua đó người dùng cũng có thể tạo

thêm các option tùy theo ý muốn Từ phiên bản 2.6 snort đã có hơn 40 commandline options

1.2 Xử lý file cấu hình

File cấu hình chứa các thông số cấu hình cho snort, một số thông số cấu hình sẽkhông được hỗ trợ thông qua command line Các thông số này bao gồm các loạigiátrị cấu hình, preprosessor, các chỉ dẫn cho output, rule và các thông số khác

File cấu hình của snort được định dạng theo từng dòng và được phân tích và chạytheo từng dòng một Snort đọc toàn bộ các line và phân tích từng line như là mộtđối tượng riêng biệt Để thực hiện việc phân tích các rule snort sử dụng hàm

ParseRulesFile trong file parser.c Để phân tích các thành phần còn lại trong file

cấu hình snort tích hợp code dùng cho việc phân tích cho preprocessor, dectectionoption, và các output plug-in vào trong các module đó

1.3 Phân tích các rule

Mỗi rule trong snort bao gồm 2 phần: header và các option Header của rule dùng đểphân biệt loại rule (alert, log, pass…), protocol, source và destination IP, source vàdestination port mà rule đang dùng Phần Option của rule chứa nhiều loại optionkhác nhau quy định các thông tin về rule và khác detect option như sid (snortidentifier), message…Khi rule được phân tích snort sẽ tiến hành xây dựng tất cả cácrule theo dạng cây Phần header của rule dùng để tạo thành rule tree node (RTN) vàphần option sẽ tạo thành option tree node (OTN) Một phần của OTN sẽ bao gồmcác dection option Tất cả các OTN tương ứng với một header sẽ được nhóm lạidưới cùng một RTN.

2 Xử lý gói tin trong snort

Snort bắt đầu với việc tiếp nhận gói tin Sau khi gói tin được snort tiếp nhận, các góitin lúc này được chuyển vào packet decoder

Sau khi được decode, gói tin sẽ được chuyển vào preprocessor để tiêu chuẩn hóa góitin, phân tích, phân tích thống kê và phát hiện các protocol bất thường

Tiếp theo đó gói tin sẽ được chuyển vào detection engine để đối chiếu kiểm tra vớirulebase trong snort.

Cuối cùng gói tin được gửi vào các ouput plug-in để loging và cảnh báo

2.1 Tiếp nhận gói tin

Lúc bắt đầu, snort tiến hành thực hiện chức năng packet processing của nó Snort đi

vào chế độ sniffing mode bằng cách sử dụng hàm InterfaceThread trong file snort.c.

Hàm này khởi động libpcap để lấy các gói tin từ interface Libpcap là một thư việnhỗtrợ nhiều nền tảng khác nhau và cho phép tiếp nhận tất cả các gói tin trực tiếp từinterface Libpcap giúp cung cấp những thông tin cơ bản sau đây cho mỗi gói tin:

• Thời gian mà gói tin được bắt từ interface tính đến phần trăm giây

• Chiều dài gói tin

• Số byte của packet đã bắt được

• Link type của packet (Ethernet, Point to Point…)

• Con trỏ đến nội dung của gói tin

Chức năng xử lý gói tin của snort được thực hiện qua nhiều giai đoạn khác nhau

Đầu tiên snort gọi libpcap bằng hàm pcap_dispatch để xử lý tất cả các gói tin đang chờ Với mỗi gói tin libpcap gọi hàm PcapProcessPacket trong file snort.c để xử lý

gói tin Hàm này khởi tạo lại giá trị counter và số liệu của từng gói tin vàgọi hàm

ProcessPackettrong file snort.c Hàm ProcessPacket xử lý tất cả các chi tiết của

công việc decode gói tin, xuất gói tin ra màn hình (nếu chạy ở chế verbose mode),gọi hàm logging packet (nếu chạy ở log mode) và gọi các preprocessor (nếu chạy ởIDS mode)

Khi chạy snort ở chế độ inline, vấn đề lúc này là không có thư viện nào tươngđương với libpcap cho snort khi chạy ở Sniffer, Packages và Intrusion Detectionmode.Tuy nhiên snort có thể tiếp nhận được gói tin trực tiếp từ iptables thay vì từlibpcap Nhưng do snort hoạt động trên nền tảng pcap, các gói tin sẽ được chuyển

thành định dạng pcap sau đó sẽ gọi hàm PcapProcessPacket.

Khi snort hoàn tất việc xử lý gói tin, snort có thể chuyển gói tin đi với nội dungkhông thay đổi hoặc có thể bị thay đổi, reject gói tin hoặc drop gói tin mà không cầnphản hồi lại Việc xử lý gói tin của snort khi chạy ở chế độ inline sẽ thực hiện phụ

thuộc vào cờ được gán trong lúc snort xử lý gói tin Người dùng có thể xem chi tiết

phương thức xử lý của snort inline trong file inline.c

Snort chỉ có thể có thể xử lý một gói tin tại một thời điểm Mặc dù pcap và API củainline đều có thể buffer các gói tin, nếu snort tốn quá nhiều thời gian để xử lý gói tintrong buffer thì các gói tin này sẽ bị drop Khi gói tin bị drop snort sẽ không có đủthong tin cần thiết để có thể phát hiện hành động tấn công mặc dù ở chế độ inlinedrop gói tin thì đồng nghĩa với việc hành động tấn công cũng bị drop theo Ngoài raviệc này còn làm cho việc kết nối trong mạng gặp vấn đề và giảm khả năng hoạtđộng của mạng, đồng thời làm cho preprocessors (frag3, stream4, stream5…)vì cácpreprocessor này hoạt động dựa trên thông tin thu thập từ nhiều gói tin khác có liênquan với nhau Và nếu một hay nhiều gói tin bị drop snort sẽ tiếp tục chờ những góitin bị mất và thiếu, do đó các gói tin tiếp theo sẽ được đưa vào hang đợi Trong quátrình chờ đợi như vậy snort sẽ tiêu thụ nhiều bộ nhớ và CPU của hệ thống

2.2 Giải mã gói tin

Sau khi snort có được gói tin, gói tin được chuyển qua cho các decoder ở lớp trên vàviệc gói tin được chuyển cho decoder nào sẽ dựa vào loại link layer của gói tin đó.Snort hỗ trợ các loại linklayer sau: Ethernet, 802.11, Token Ring, FDDI, CiscoHDLC, SLIP, PPP và OpenBSD’s PF Đồng thời snort hỗ trợ nhiều protocol sauđây: IP, Internet Control Message Protocol (ICMP),TCP, and User Datagram

Protocol (UDP) Người dùng có thể xem về các decoder trong file decode.c.

Sau khi một link layer đã được xác định và decoder đã được chọn, các con trỏ sẽđược dùng để trỏ đến các phần khác nhau của gói tin Dựa vào thông tin decodeđược, nó sẽ gọi tiếp các decoder cho những lớp tiếp theo cho đến khi nào không còndecoder nào được gọi nữa Trong khi decode snort sẽ kiểm tra tính sự hợp lệ của góitin tại mỗi lớp và sẽ xếp các sự kiện nếu phát hiện một gói tin nào đó bất thường

Quá trình giải mã một gói tin

Trong sơ đồ trên mô phỏng gói tin được đưa vào decoder dành cho ethernet, hàm

DecodeEthPkt được dùng Sau khi decode gói tin, thông tin về source và destination

MAC được làm rõ và dựa vào thông tin về lớp tiếp theo (ether_type) decoder tiếptheo sẽ được gọi Giả sử trong trường hợp giá trị của ether_type lúc này là 2048

(ETHER_TYPE_IP) snort biết được lớp tiếp theo sẽ là IP và gọi hàm DecodeIP.

Quy trình sẽ tiếp tục cho đến khi không còn decoder nào được gọi Trong trườnghợp gói tin có link type là Ethernet thì gói tin sẽ được chuyển vào hàm

DecodeEthPkt, sau đó hàm này sẽ gọi DecodeIP, tiếp sau là DecodeTCP.

Sau khi decode cấu trúc của một gói tin sẽ được làm rõ, lúc nào gói tin chứ nhiềucon trỏ khác nhau trỏ đến những phần khác nhau của gói tin, điều này cho phépsnort có thể truy xuất nhanh đến những thành phần trong gói tin Con trỏ này chophép các thành phần của snort như preprocessor, detection engine và output-plugin

có thực hiện công việc một cách dễ dàng sau này

Trong sự phát triển và cải tiến của snort, một số con trỏ được thêm vào trong gói tincho phép các thành phần khác nhau của snort có thể thông tin cho nhau Lúc nàotrong cấu trúc gói tin lúc này sẽ chứa con trỏ chỉ đến TCP stream tracker, IPfragment tracker và flow tracker

2.3 Preprocessor

Sau khi gói tin được decode nó được chuyển qua preprocessor Preprocessor củasnort đóng một vai trò rất quan trọng với nhiều chức năng khác nhau phát hiện cácprotocol không hợp lệ, phát hiện thông qua các số liệu thu thập được hoặc phát hiệntrực tiếp mà không cần dựa vào rule.

3 Detection Engine

Sau khi được xử lý bởi preprocessor, gói tin lúc nào được chuyển vào detectionengine Detection engine giống như một preprocessor và nó là preprocessor được sửdụng cuối cùng Nhiệm vụ của detection engine là đánh giá gói tin dựa vào các rule

có sẵn trong snort

Để làm điều này snort sử dụng một rule tree có nghĩa là gói tin được so sánh dựavào RTN, nếu một RTN được thỏa mãn nó sẽ tìm tiếp trong các danh sách của cácOTN Quy trình tiếp tục cho đến khi snort tìm đến hết rule tree

Mặc dù vẫn sử dụng chức năng tìm theo danh sách cho chức năng đánh giá và pháthiện các gói tin Nhưng snort không còn dùng cây của các OTN nữa Thay vào đósnort dùng fast pattern matcher, fast pattern matcher xác định một tập hợp các OTN

và OTN nào sẽ được đánh giá Sau đó snort kiểm tra từng OTN và xắp xếp thànhmột hằng đợi gồm các OTN đã khớp với nội dung trong gói tin

3.1 Ghi log và cảnh báo

Sau khi tất cả các preprocessor toàn tất công việc của chúng và gói tin lúc này đãđược đánh giá bởi tập các rule thông qua detection engine Snort bắt đầu công việcghi lại log và đưa ra cảnh báo

Snort không đưa ra cảnh báo ngay lập tức khi gói tin khớp với rule đầu tiên trongtập rule mà sẽ ghi lại sự kiện và cảnh báo đó vào một hàng đợi, sau khi gói tin được

so sánh hết trong tập rule, snort sẽ đánh giá xem cảnh báo nào sẽ được đưa ra

3.2 Hàng đợi các sự kiện cảnh báo

Event queue cung cấp 2 chức năng sau:

• Khả năng điều khiển các rule, rule nào sẽ được chọn nếu có nhiều rule khớpvới nội dung trong gói tin

• Khả năng đưa ra nhiều cảnh báo trên cùng một rule

Ở những phiên bản trước của snort, snort đưa ra cảnh báo ngay từ rule đầu tiên vànhững rule nào có độ ưu tiên thấp sẽ bị bỏ qua Người dùng có thể sắp xếp thứ tựcác rule sẽ được đánh giá, nhưng điều này phức tạp và đòi hỏi phải xây dựng rulelại từ đầu Với event queue thay vì cảnh báo ngay từ rule đầu tiên (hoặc decoder vàpreprocessor có thể đưa ra cảnh báo) lúc này các sự kiện sẽ được xếp vào một hàngđợi Sau khi hàng đợi đã đầy hoặc khi snort đã hoàn thành việc xử lý hết tất cả cácrule Nó sẽ kiểm tra event queue và quyết định những cảnh báo nào sẽ được đưa ra.Người dùng có thể cấu hình trong snort để xắp xếp thứ tự cảnh báo theo rule nàokhớp nhiều nhất với gói tin hoặc theo thứ tự ưu tiên của các rule Nếu người dùngcấu hình snort đưa ra nhiều cảnh báo trên cùng một gói tin thì lúc này snort sẽ tiếnhành kiểm tra hết hàng đợi hoặc cho đến khi nó đưa ra hết số lượng cảnh báo tối đacho phép Theo mặc định snort sẽ đưa ra cảnh báo theo rule nào khớp nhiều nhấtvới tin và đưa ra 3 cảnh báo cho một gói tin Người dùng có thể thay đổi giá trị

event_queue option trong file snort.conf.

3.3 Ngưỡng đưa ra cảnh báo

Sau khi một quyết định về một cảnh báo được đưa ra, snort lúc này sẽ gọi outputplug-in, tuy nhiên có 2 bước mà snort sẽ thực hiện trước khi gọi output plug-in vàxuất ra màn hình

Đầu tiên là thresholding, sau khi quyết định về một cảnh báo được đưa ra,dectection engine lúc này sẽ gọi thành phần thresholding của dectection engine.Với threshold người dùng có thể giới hạn số lượng cảnh báo được gây ra bởi cácrules Threshold có 3 loại mà snort hỗ trợ cho việc cấu hình là: limit, threshold vàđồng thời cả hai Với limiting người dùng có thể hạn chế các sự kiện có thể phátsinh ra từ một rule đối với những rule quá cơ bản có thể phát sinh ra nhiều cảnhbáo Điều này rất hữu dụng khi có một hành động nào đó cố hình kích hoạt hànhđộng cảnh báo của hàng loạt rule và có thể làm hệ thống quá tải

Ví dụ trong file snort.conf ta có thể cấu hình cho phép một địa chỉ IP source có thểchỉ kích hoạt được một cảnh báo trong thời gian 60 giây.

threshold gen_id 1, sig_id 0, type limit, track by_src, count 1, seconds 60

Threshold được dùng để quy định một hành động vi phạm một rule bao nhiêu lầntrước khi rule đưa ra cảnh báo Khi người dùng cấu hình threshold đếm đến 3 chomột hành động login thất bại có nghĩa là, 3 lần đầu tiên cho hành động thất bại sẽkhông đưa ra cảnh báo và sẽ cảnh báo cho lần login thất bại tiếp theo

Khi người dùng theo dòng lệnh dưới đây vào file cấu hình điều có đó nghĩa là mộtsource IP sẽ bị cảnh báo sau lần login thất bại trong vòng 60s

threshold:type threshold, track by_dst, count 5, seconds 60;

Thresholding là loại kết hợp cho cả 2 loại limit và threshold, dạng này quy định mộthành động vị phạm rule bao nhiều lần thì sẽ bị cảnh báo và chỉ đưa cảnh báo vớimột số lượng nhất định

3.4 Ngăn chặn cảnh báo

Sau khi dection engine đưa cảnh báo về một rule và sau khi threshold được sử dụngnhưng trước khi hành động được ghi log lại Bước cuối cùng mà snort phải thựchiện là suppression Suppression ngăn không cho rule đưa ra cảnh báo về một hànhđộng trong mạng cụ thể mà không cần loại bỏ rule đó ra khỏi rule base Thông quaviệc sử dụng suppression người dùng có thể tinh chỉnh tập rule mà không cần vôhiệu hóa rule

Ví dụ: bằng cách cấu hình thông qua file snort.conf người dùng có thể ngăn khôngcho snort đưa ra cảnh báo khi có hành động xảy ra nếu destination ip là 10.1.1.1

suppress gen_id 1, sig_id 1852, track by_dst, ip 10.1.1.1

4 Khảo sát Detection Engine

Hầu hết khả năng nhận dạng và phòng chống tấn công của snort được xây dựng bêntrong rule và tạo thành detection engine Hầu hết công việc của detection enginethực hiện là cảnh báo nào sẽ được đưa ra cho những gói tin vi phạm

Rule option là thành phần chủ yếu được dùng cho việc đánh giá gói tin và phát hiệnxâm nhập Một số rule option có cấu trúc phức tạp và có vai trò quan trọng trongdetection engine như content, bytetest, bytejump, PCRE hay flowbits rule options

4.1 Bộ phận nhận dạng - pattern matcher

Trong các phiên bản trước của snort, snort đánh giá gói tin bằng cách so sánh trựctiếp với rule tree cho đến khi tìm thấy rule được khớp hoặc tất cả các rule đượcđược kiểm tra hết Đây là một cách dễ dàng triển khai và dễ hiểu Tuy nhiên trongmột mạng có lượng traffic lớn và có tốc độ cao thì cần có một phương pháp kiểmtra nhanh hơn

Được phát triển của Marc Norton, một kỹ sư phần mềm của công ty Sourcefire,pattern matcher là thành phần cốt lõi cho dectection engine ngày nay

4.2 Xây dựng pattern matcher

Việc xây dựng pattern matcher bắt đầu mỗi rule tree, mục đích chính của rule tree làgiảm số lượng rule cần được kiểm tra với gói tin, bằng cách giảm số lượng rule thì

sẽ giảm được thời gian tìm kiếm trên rule đối với một gói tin Điều này sẽ làm giảmthời gian snort xử lý gói tin và tăng khả năng hoạt động trên những mạng có tốc độcao

Pattern matcher bắt đầu bằng việc nhóm các rule lại với nhau dựa trên destinationport của rule Sau đó với mỗi destination port, snort xác định trường content stringdài nhất trong content option của rule Khi snort hoàn tất việc tập hợp content string,snort bắt đầu biên dịch pattern mather thông qua nhiều thuật toán khác nhau Khimột gói tin đi vào pattern matcher, một nhóm các pattern sẽ được chọn dựa vàodestination port Sau đó, snort sẽ chọn ra một nhóm các pettern trong các patternban đầu và dựa vào đó chọn ra những rule cần thiết và đánh giá toàn bộ rule

Pattern matcher sẽ giảm thời gian snort xử lý một gói tin, do đó snort có thể xử lýđược nhiều dữ liệu hơn,

Snort hiện nay dùng 3 thuật toán chính trong pattern macher là: Aho-Corasick (ac),modified Wu-Manber (mwm) và low memory key-word trie (lowmem)

Bảng dưới đây là kết quả sau khi test trên cấu hình mặc định của snort 2.6 và rulebase và thời điểm 8/8/2006 cùng với gói dữ liệu dạng pcap có độ lớn là 1.5 GB.Mục memory trong bảng kết quả được tính sau khi snort khởi động, thời gian snortkhởi động và thời gian snort dùng để xử lý hết 1.5 GB data

Kiểm tra với 4.955 rules Kiểm tra với 6.592 rules Thuật toán Bộ nhớ

(MB)

Thời gian khởi động (s)

Thời gian xử

lý gói tin (s)

Bộ nhớ (MB)

Thời gian khởi động (s)

Thời gian xử

lý gói tin (s)

4.3 Dynamic detection engine

Share object rule hay còn gọi là dynamic detection engine cung cấp 2 chức năngchính cho người dùng Thứ nhất share object rule cung cấp chức năng phát hiện nó

có ý nghĩa quan trọng và phức tạp hơn nhũng rule bình thường Share Object Rulecho phép snort cập nhật hành động tấn công một cách nhanh chóng Thứ hai, sharedobject rule cho phép triển khai một loại rule được gọi tên là “black box” rule Vìrule này được biên dịch bên trong một share object nên nó cho phép che dấu nộidung của rule khỏi những người quản trị các sensor

Để sử dụng dược các dynamic detection engine và share rule người dùng cần thêm

lệnh –enable-dynamicplugin khi biên dịch Khi đó khi chạy lệnh make install snort

sẽ cài vào các share object module và xây dựng các share object rule Thêm vào đóngười dùng phải cấu hình snort để load các engine và những module rule cần thiết

• dynamic-engine-lib <file> : load một dynamic engine từ một file chỉ định

• dynamic-detection-lib <file> : load dynamic rule từ một file

• dynamic-detection-lib-dir <path>: load dynamic rule từ tất cả các rule

trong một thư mục

Mỗi option trên tương đương với việc cấu hình trong file snort.conf như sau:

• dynamicengine <file> : load một dynamic engine từ một file chỉ định

• dynamicdetection file <file> : load dynamic rule từ một file

• dynamicdetection directory <path> : load dynamic rule từ tất cả các rule

trong một thư mục

5 Snort Inline Mode

5.1 Các mode chính của snort

• Sniffer mode: ở mode này snort chỉ log lại gói tin và in ra màn hình

• Packet Logger mode: ở mode này snort chỉ log lại gói tin và ghi vào hệ thốngđĩa

• Network Intrusion Detection System (NIDS) mode: đây là mode phức tạpnhất của snort, ở mode này snort phân tích traffic trong mạng, từ đó pháthiện được những hành động thâm nhập hoặc tấn công trong mạng.

• Inline mode :trong mode này snort sẽ tiếp nhận gói tin từ iptables thay vì từlibpcap sau đó sẽ tiến hành xử lý gói tin (DROP, REJECT, SDROP)

5.2 Nguyên lý hoạt động của inline mode

Snort inline nhận gói tin trực tiếp từ ipables thay vì nhận gói tin từ libpcap và sửdụng rules để giúp iptables drop hoặc pass gói tin dựa vào snort rules

Có 3 loại rule trong snort inline:

• drop: rule này sẽ dùng ip tables để drop gói tin và log lại

• reject: rule này sẽ dùng iptables để drop gói tin, log lại sau đó dùng TCPreset gửi lại nếu protocol là TCP hoặc icmp unreachable nếu protocol làUDP

• sdrop: rule này sẽ drop gói tin và không có gì được log lại

Khi sử dụng reject rule, có 2 option được sử dụng đối với TCP reset:

• Sử dụng RAW socket, loại này chỉ được dùng trong trường hợp interfacenhận được gói tin phải được gán IP Nếu trong trường hợp interface không

có địa chỉ IP thì snort chỉ log lại gói tin nhưng sẽ khôn thể gửi reset

• Sử dụng iptables để reset ở địa chỉ layer 2, khi sử dụng option này ta khôngcần sử dụng IP trên bridge interface, đề làm được như vậy ta cần cấu hình

“config layer2_resets” trong file snort.conf:

 Thay thế nội dung gói tin với snort inline

Với snort inline ta có thể dùng rule để thay thế nội dung gói tin:

alert udp any any <> any 53 ( msg: "udp replace"; content: "yahoo"; replace:

"mail" )

II Preprocessor

Preprocessor là một đoạn code được biên dịch vào snort engine nhằm xây dựng lạipacket, traffic flow và kiểm tra traffic trong mạng để phát hiện tấn công và đưa ra cảnhbáo

Protocol Decoder Traffic đầu tiên phải đi vào decoder, để decode các

thông tin ban đầu

Detection Engine Sau cùng gói tin sẽ được chuyển cho detection engine

để tiến hành đánh giá dựa vào các rule

1 Preprocessor frag3

Preprocessor frag3 được phát triển nhằm thay thế cho frag2,frag3 có tốc độ xử lýnhanh hơn frag2, quản lý data phức tạp hơn frag2 và chống những thủ thật nhằmvượt qua frag2

Preprocessor frag3 sử dụng sfxhash data structure và linked lists để quản lý và xử lýdata, điều này giúp cho frag3 tăng khả năng dự báo và tăng tính quyết đoán củafrag3 Khi môi trường mạng có nhiều gói tin bị phân mảnh thì frag3 sẽ hoạt động rấthiệu quả và giúp người quản trị quản trị dễ dàng hơn

Preprocessor frag3 đưa ra khái niệm “target-base” IDS, tức là frag3 sẽ xây dựng lạigói tin bị phân mảnh dựa vào destination host mà gói tin sẽ đến Bởi vì mỗi hệ điềuhành xây dựng lại gói tin theo một các khác nhau và snort không hề biết destinationhost của gói tin mà nó đang ráp mảnh là hệ điều hành gì Một gói tin có thể xem làbình thường với hệ điều hành này, nhưng nó có thể được xem là bất thường với một

hệ điều hành khác Do đó frag3 đưa ra target-based với 7 loại policy dành chonhựng OS như sau:

Linux 2.4.9-31SGI 1.0.2smp Linux

Linux 2.4 (RedHat 7.1-7.3) Linux

MacOS (version unknown) First

OpenBSD (version unknown) Linux

OpenBSD (version unknown) Linux

• memcap <bytes> : Số lượng bộ nhớ lớn nhất là frag3 có thể sử dụng

• prealloc_frags <number> : bộ nhớ phụ, dùng để cấp phát trước cho cácfragment node

• overlap_limit <number>: giới hạn số mảnh bị trùng trong một gói tin, mặcđịnh là 0 (không hạn chế), tối đa là 255, tuy nhiên chức năngdetect_anomalies phải được bật.

• min_fragment_length <number>: quy định kích thước mảnh nhỏ nhất, kíchthước của của một phân mảnh nhỏ hơn hoặc bằng kích thước quy địnhđược coi là mã độc và có thể bị cảnh báo, tuy nhiên chức năngdetect_anomalies phải được bật

• policy <type>: chọn policy phù hợp với hệ thống mà snort đang hoạt động

5.4 frag3 output

Preprocessor frag3 xây dựng lại gói tin từ những phân mảnh sau đó đẩy gói tin theođường mà frag3 đã nhận gói tin từ decoder Gói tin được log lại hoặc có thể đi quapreprocessor và quy trình kiểm tra một lần nữa Điều này có nghĩa là traffic sẽ đượcphân tích hai lần, trước phân mảnh và sau khi phân mảnh

6 Preprocessor stream5

Preprocessor stream5 là một preprocessor dành cho việc thiết lập lại các TCPsession, giống như frag3 stream5 cung cấp chức năng target-based Ngoài rastream5 có thể theo dõi cả TCP và UDP session Preprocessor stream5 thay thế cho

cả stream4 và flow preprocessor Vì stream5 là sự thay thế của stream4, do đó cảhai không thể được sử dụng đồng thời, nếu sử dụng stream5 thì phải gỡ bỏ stream4

và flow preprocessor Với stream5, flow và flowbits trong rule option đều có thể sửdụng

6.1 Chức năng

Transport protocol

Một TCP session được bắt đầu bằng three way handshake protocol và kết thúcbằng cờ FIN và được hai bên xác nhận bằng cờ ACK Với UDP một sessionđược xác định thông qua một chuỗi các gói tin UDP được trao đổi giữa 2 bênthông qua các port ICMP sẽ được theo dõi cho mục đích kiểm tra unreachable

và unavailable service của TCP và UDP

Preprocessor stream5 cũng giống như frag3, stream5 đưa ra khái niệm based để xử lý hiện tượng dữ liệu trùng lắp giữa những gói tin và những giaodịch TCP bất thường Phương pháp dùng để xử lý trùng lắp dữ liệu, TCPTimestamps, Data on SYN, FIN và khởi tạo lại sequence numbers…và policy hỗtrợ bởi stream5 là kết quả của việc mở rộng nghiên cứu trên nhiều hệ điều hànhkhác nhau để có từng policy cụ thể cho từng hệ đều hành

target-Stream API

Preprocessor stream5 hỗ trợ stream API, cho phép các bộ phận kiểm tra tínhhợp lệ của protocol và preprocessor cấu hình việc tập hợp gói tin theo yêu cầucủa ứng dụng ở lớp của application, xác định session nào nên bỏ qua và cập nhậtthông tin nhận dạng về session như protocol, hướng gói tin…

Nhận dạng sự bất thường

Protocol TCP bất thường, thường là những gói tin SYN nhưng có kèm theo datahay dữ liệu nằm ngoài TCP windows size…những chức năng này thường đượccấu hình thông qua tùy chọn detect_anomalies của Stream5 TCP preprocessor

6.2 Cấu hình stream5_global preprocessor

preprocessor stream5_global: \

[track_tcp <yes|no>], [max_tcp <number>], \

[memcap <number bytes>], \

[track_udp <yes|no>], [max_udp <number>], \

[track_icmp <yes|no>], [max_icmp <number>], \

[flush_on_alert], [show_rebuilt_packets], \

[prune_log_max <bytes>], [disabled]

 track_tcp <yes|no>: Track session của TCP, mặc định là yes

 max_tcp <number>: Số TCP session tối đa có thể track cùng lúc Mặc định

là 256000, tối đa là 1052672, tối thiểu là 1

 memcap <number bytes>: bộ nhớ lưu trữ tối đa dành cho gói tin TCP, mặc

định là 8MB, tối đa là 1 GB, tối thiểu là 32 KB

 track_udp <yes|no>: Track TCP session, mặc định là yes

 track_icmp <yes|no>: Track ICMP session, mặc định là yes

 max_icmp <number>: Số icmp session tối đa có thể track cùng lúc, mặc

định là 64000, tối đa là 1052672, tối thiểu là 1

 disable: tắt chức năng tracking của stream6, khi có các chức năng memcap,

max_tcp, max_udp, và max_icmp sẽ tắt theo

 flush_on_alert: xóa TCP stream khi một cảnh báo được đưa ra về stream đó,

mặc định là tắt

 show_rebuilt_packets: in ra màn hình gói tin sau khi rebuilt, mặc định là tắt.

 prune_log_max <num bytes>: in thông điệp khi một session kết thúc mà

session đó tiêu thụ nhiều hơn <num bytes> Mặc định là 1MB và khôngnhiều hơn memcap, tối thiểu là 0

6.3 Cấu hình stream5_tcp preprocessor

preprocessor stream5_tcp: \

[bind_to <ip_addr>], \

[timeout <number secs>], [policy <policy_id>], \

[overlap_limit <number>], [max_window <number>], \

[require_3whs [<number secs>]], [detect_anomalies], \

[check_session_hijacking], [use_static_footprint_sizes], \

[dont_store_large_packets], [dont_reassemble_async], \

[max_queued_bytes <bytes>], [max_queued_segs <number segs>], \

[ports <client|server|both><all|number [number]*>], \

[ignore_any_rules]

 bind_to <ip_addr>: địa chỉ IP sẽ được áp đặt policy này.

 timeout <number secs>: session timeout, mặc định là 30s, tối thiểu là 1s, tối

đa là 86400s

 overlap_limit <number>: hạn chế gói tin trùng lắp trong một session

 max_windows <number>: TCP window tối đa cho phép, mặc định là 0, tối

thiểu là 0, tối đa là 1073725400 Option này được stream5 dùng đề chặnDoS, khi attacker sử dụng windows size rất lớn

 require_3whs [<number secs>]: một session chỉ được thiết lập khi trải qua 3

bước bắt tay của TCP, mặc định là tắt number secs là chỉ thời gian timeout.

 detect_anomolies: phát hiện những kết nối TCP bất bình thường, mặc định là

tắt

 check_session_hijacking: Kiểm tra kiểu tấn công TCP session hijacking,

kiểm tra giá trị MAC address của 2 đầu kết nối có giống như khi 2 bên cóthiết lập session theo bắt tay 3 bước hay không, nếu không có MAC addressthì quá trình kiểm tra được bỏ qua Cảnh báo sẽ được đưa ra khi kết quảkiểm tra địa chỉ MAC 2 bên thất bại Mặc định là tắt

 dont_store_large_packets: không lưu lại những cói tin quá lớn trong session,

mặc định là tắt

 dont_reassemble_async: không đưa vào hàng đợi để build session nếu

hướng đi của gói tin không thuộc hướng nào của session

 max_queued_bytes <bytes>]: hạn chế số byte của hàng đợi cho một TCP

session Mặc định là 1MB, 0 là không hạn chế, nhỏ nhất là 1024, lớn nhất là1073741824

 max_queued_bytes <bytes>: hạn chế số lượng segment trong việc built một

TCP session Mặc định là 2621, 0 là không hạn chế, nhỏ nhất là 2, lớn nhất là

1 GB

 ports <client|server|both><all|number [number]*>: chỉnh định các port của

client, server hay cả client và sever trong việc xây dựng lại session Mặc định

là port client 21 23 25 42 53 80 110 111 135 136 137 139 143 445 513 514

1433 1521 2401 3306 Số lượng port nhỏ nhất là 1, lớn nhất là 65535

 ignore_any_rules: không xử lý rule có source port và destination port là any

khi gói tin có tình vi phạm phần payload trong rule trong khi đó không córule nào kiểm tra được source và destination port của gói tin đó, mặc định làtắt

6.4 Cấu hình stream5_udp preprocessor

Preprocessor stream5_udp: [timeout <number secs>], [ignore_any_rules]

 timeout <number secs>: session timeout, mặc định là 30, min là 1, max là

86400

 ignore_any_rules: không xử lý rule có source port và destination port là any

khi gói tin có tình vi phạm phần payload trong rule trong khi đó không có

rule nào kiểm tra được source và destination port của gói tin đó, mặc định làtắt.

6.5 Cấu hình stream5_icmp preprocessor

Preprocessor stream5_icmp: [timeout <number secs>]

timeout <num seconds> : mặc định là 30, nhỏ nhất là 1, lớn nhất là 86400

7 Một số preprocessor khác

Một số preprocessor khác được snort dùng để xây dựng lại các application protocolnhư arpspoof, sfPortscan, rpc_decode, http_inspect, ftp_telnet, ssh preprocessor…

 http_inspect là decoder tổng quát dành cho protocol HTTP Sau khi nhận

data buffer, http_inspect sẽ decode và xây dựng lại thành một gói tin HTTPđầy đủ Phiên bản hiện tại của http_inspect của chỉ quản lý được các processdạng stateless, điều có nghĩa là http_inspect chỉ xử lý được từng gói tin,http_inspect không để xây dựng được gói tin nếu nó chưa được ráp hoànchỉnh http_inspect cung cấp nhiều tùy chọn cho người dùng cho phép tươngthích với nhiều loại webserver nhưng IIS, apache

 sfPortscan là preprocessor dùng để phát hiện decoy portscan, distributed

portscan, portsweep…

 ftp_telnet cung cấp chức năng stateful inspection cho cả FTP và Telnet

session, ftp_telnet sẽ decode dữ liệu nhận dạng các FTP command và response, telnet escape sequences ftp_telnet làm việc từ hướng server lẫn client ftp_telnet có khả năng xứ lý các tiến trình theo dạng stateless điều đó

có nghĩa là ftp_telnet chỉ xử lý từng gói tin một lúc Mặc định FTP/Telnet sẽ chạy ở stateful inspection mode ftp_telnet rất linh hoạt và cung cấp nhiều

tùy chọn trong việc cấu hình tương tự như http_instpect

 arpspoof dùng để decode gói tin arp và nhận dạng các kiểu tấn công arp,

request arp theo kiểu unicast, sự không thống nhất trong việc ánh xạ ARP vàIP

III Hệ Thống Rule Trong Snort

1 Tổng quan về rule trong snort

 Điểm mạnh của Snort chính là người dùng có khả năng tự viết và thêmvào bộ Rule mặc định của Snort theo ý mình để phát hiện những cuộc tấncông mới mà không phụ thuộc vào nhà sản xuất

 Rule là một tập hợp những chỉ dẫn được đặt ra để tìm những luồng dữliệu trùng khớp với mẫu định trước và thực hiện hành động được chọncho luồng dữ liệu đó

 Mỗi Rule tương ứng với 1 dòng trong file snort.conf

8 Cấu trúc rule

 Rule Header

Action Protocol Address Port Direction Address Port

 Action: hành động thực hiện khi đúng điều kiện và Rule hoàn toàn trùngkhớp với với gói tin đi qua

o Alert: gửi thông điệp báo động khi gói tin đi qua trùng khớp vớiđiều kiện của Rule Báo động có thể gửi đi bằng nhiều cách

o Log: ghi nhận lại gói tin vào cơ sở dữ liệu để có thể phân tích vềsau

o Pass: cho gói tin đi qua không cần kiểm soát, hành động này nhằmtăng tốc độ xử lý của Snort đối với những gói tin không cần thiếthay ứng dụng trong trường hợp đánh giá mức bảo mật của hệthống bẳng cách thử tấn công

o Activate: gửi báo động đồng thời kích hoạt một Rule khác đểkiểm tra thêm điều kiện

o Dynamic: là hành động cho thấy rule này chỉ sẽ được kích hoạtbởi các rule có hành động là Activate

 Protocol: chỉ ra giao thức của gói tin cần xét, đây là điều kiện đầu tiên đểxem gói tin có trùng hợp với Rule hay không Ví dụ: TCP, ICMP, UDP

…

 Address: địa chỉ nguồn và đích của gói tin cần kiểm tra Có thể dùng địachỉ của một host, nhiều host hoặc địa chỉ mạng của một subnet Ví dụ:192.168.1.2, 172.16.1.0/24 …

 Port: chỉ ra port nguồn và port đích của gói tin cần kiểm tra đối với cácgói TCP và UDP

 Direction: chỉ ra hướng đi của gói tin từ nguồn tới đích bằng dấu “->”

“<-” nên trường address nhắc đến ở trên dù đặt trước hay đặt sau đều cóthể là nguồn hoặc đích của gói tin

8.1 Rule option

 Rule Option là thành phần theo sau Rule header và được đặt trong dấungoặc đơn Có thể có một hoặc nhiều rule Option và chúng được chiacách bời dấu chấm phẩy (;) Khi sử dụng nhiều option cùng lúc thì sẽ có

ý nghĩa là phải thỏa tất cả các option đó (toán tử AND) Tất cả các optionđược định nghĩa bằng các keyword, một số rule còn sử dụng thêm cácargument Argument và keyword cách nhau bở dấu hai chấm (:)

Ví dụ: msg: “DOS Detected”;

8.2 Các loại keyword

o ack: dùng để đặt ra điều kiện về trường ACK của gói tin cần xét.Keyword này được sử dụng trong những trường hợp truy tìm những góitin ping thăm dò của hacker với trường ack mang những giá trị đặc biệtnhằm mục đích foot printing

o classtype: dùng để phân loại cái rule nhằm tạo điều kiện thuận lợi trongviệc phân tích và thống kê các ghi nhận của Snort Argument củaclasstype được liệt kê trong file classification.config với định dạng nhưsau:

• config classification: name,description,priority

• (name: được sử dụng cùng với keyword classtype, priority

có thể được điều chỉnh thông qua keyword priority trong option.)

o content: dùng để rà soát thành phần bên trong gói tin dưới dạng ASCIIhay Hecxa

 Ví dụ: content: “GET”; (dùng để tìm chuỗi GET trong gói tin)

o offset: dùng kèm theo với keyword content để chỉ ra vị trí offset đầu tiên

o dsize: dùng để xác định chiều dài phần dữ liệu của gói tin trong nhữngtrường hợp dò tìm tấn công tràn bộ đệm bằng cách gửi những gói tin cóchiều dài dữ liệu bất thường

o flags: dùng để dò tìm bit flag của gói tin theo các argument như sau:

Trên đây là một số keyword thông dụng trong việc viết Rule của Snort, một sốkeyword khác sẽ đề cập tiếp trong phần thực hiện LAB với Snort

9 Thứ tự các rule trong rule base của snort

Rule có thể phân thành 3 loại dựa trên trường Action của Rule: AlertPass Log Khi một gói tin đi vào IDS Snort, nó sẽ được kiểm tra theo thứ tự nêu trên để đảmbảo mọi gói tin đều được kiểm tra thông qua những rule Alert nhằm loại bỏ nhữngmối nguy hại cho hệ thống Tuy nhiên nếu thực hiện theo cơ chế này thì sẽ hao tốn vi

xử lý rất nhiều vì khi hệ thống hoạt động có rất nhiều gói tin đi qua mà phần lớn làcác gói tin bình thường không gây hại Vì thế Snort đã đưa ra một thứ tự khác nhằmgiải quyết tình trạng này đó là: PassAlertLog

Cơ chế này giải quyết được vấn đề vi xử lý tuy nhiên lại nguy hiểm hơn nếu ngườiquản trị không cẩn thận trong việc viết các pass rule khiến cho các gói tin lẽ ra phảibáo động thì lại cho qua dễ dàng Người dùng có thể điều chỉnh thứ tự rule thông qua

sẽ cập nhật những rule mới nhất vào hệ thống

Oinkmaster sẽ download tập rule đã được nén từ website snort.org sau đó

Oinkmaster sẽ tự động giải nén tập rule và bắt đầu xem xét và so sánh những rulemới và những rule hiện tại trong hệ thống, từ đó oinkmaster sẽ quyết những rule nào

sẽ cần uptates những rule nào sẽ không cần

Tùy chỉnh oinkaster

Một số option cho oinkmaster

-C Chỉ định file cấu hình thay vì sử dụng file cấu hình mặc định

-c Chỉ định snort sẽ chạy ở chế độ careful mode, trong chế độ này

-o Thư mục mà oinkmaster sẽ ghi rule mới vào

-b Thư mực mà oinkmaster sẽ backup các rule cũ

-u Chỉ định đường dẫn đến tập rules, oinkmaster hỗ trợ những loại url như sau:

file://, ftp://, http://, https://, scp://

IV Snort Output Plug-in

Snort out-put có nhiều plugin khác nhau và các plugin có nhiều điểm khác và giốngnhau Với snort người dùng có thể tạo ra plug-in riêng của mình Snort cho phép ngườidùng tạo output theo nhiều cách khác nhau

1 Output log và alertvới tốc độ nhanh

Cấu hình file snort.conf đề sử dụng unified log, unified log là một dạng binary logđược thiết kế cho việc hoạt động với tốc độ nhanh, hiệu quả ở dạng bằng cách địnhdạng file log ở dạng binary format, điều này nhằm giảm tải cho tài nguyên của hệ

thống so với các dạng log khác.Hầu hết các công cụ report hiện nay như barnyard,snortreport…điều hỗ trợ dạng unified log làm input Unified log gồm có 2 thông sốchính: tên file log và kích thước file log

Unified log góp phần làm giảm gánh nặng cho snort trong việc ghi log và tập trungtài nguyên vào giám sát và phân tích traffic hơn là tập trung ghi log Điểm lợi nhấtcủa unified log là tốc độ Hiện tại barnyard là công cụ tốt nhất trong việc xử lý fileunified log

output alert_unified: filename snort.alert, limit 128

output log_unified: filename snort.log, limit 128

Unified2 là plugin thay thế cho unified Unified2 có đặc tính tương tự như unifiednhưng có sự khác biệt về định dạng file log Unified2 có 3 loại log: packet log, alertlog và true unified log Packet log sẽ log toàn bộ header của gói tin mà nó bắt được

và được cấu hình là trong file snort.conf là log_unified2 Alert log là log dành riêngcho alert và được cấu hình là alert_unified2 Nếu người dung muốn log cả packet vàalert ta chỉ cần cấu hình trong file snort.cong như sau: unified2

Khi cần log MPLS ta có thể log được nhãn của gói tin MPLS bằng cách cấy hìnhmpls_event_types

output alert_unified2: filename snort.alert, limit 128, nostamp

output log_unified2: filename snort.log, limit 128, nostamp

output unified2: filename merged.log, limit 128, nostamp

output unified2: filename merged.log, limit 128, nostamp,

mpls_event_types

Người dùng có thể xuất file binary log với tên vào nơi lưu trử theo ý muốn của mìnhbằng cách dùng lệnh snort -l /snort/log -L test2 File log Này có thể được đọc vàphân tích bởi các chương trìn hỗ trợ binary log

Banryard

Snort cùng lúc tiếp nhận traffic từ các host đi đến snort, do đó khi traffic tăng lên thìtài nguyên của IDS lúc này sẽ càng hao tốn nhiền hơn nhất là CPU và bộ nhớ của hệthống Giải pháp cho việc này là ta có thể chia traffic ra cho nhiều sensor khác nhau

để tránh tập trung lên một sensor duy nhất Nhưng giải pháp này tốn kém trong việctriển khai thêm nhiều sensor.

Một giải pháp khác là sử dụng barnyard, barnyard đọc file unified log được xuất ra

từ snort sau đó tiến hành phân tích Nhiệm vụ của snort chỉ đơn giản là xuất ra địnhdạng Unified Binary

Dữ liệu cần được thu thập lại, định dạng sau đó xuất ra Trong trường hợp snort ghitrực tiếp và database thì snort lúc này phải alert đến database và ghi trực tiếp vàdatabase và phải đợi database xác nhận công việc ghi dữ liệu đã thành công Việcnày sẽ khó khăn hơn khi database nằm trên một host khác

Snort có khả năng xuất thông tin về một alter nào đó thành một binary file Điều nàydiễn ra rất nhanh và không cần bất cứ tiến trình nào khác Barnyard sau đó học filenày vào sau đó xuất ra snort logfile, syslog, CSV hoặc xuất vào database Barnyard

có thể được cấu hình để chạy cùng với snort và việc cấu hình cũng khá giống vớisnort

Cấu hình file Unified Binary của Snort

Trước khi sử dụng banryard ta cần cấu hình file output bên trong file snort.conf.Barnyard chỉ hỗ trợ duy nhất input là file unified2

output unified2: filename snort.log, limit 128

filename Tên của file log của snort File này được tạo ra tại thư mục ghi log

mặc định của snort (/var/log/snort)

limit

Kích thước tối đa của file binary mặc định là 128 MB Khi file đầy thìsnort sẽ ghi vào một file khác nhưng cùng một tên chỉ khác thời gianghi

config localtime Cấu hình barnyard sử dụng giờ UTC

config hostname: sensor1 Cấu hình tên của sensor khi xuất alert vào

database

config interface:eth0 Interface mà sensor tiếp nhận traffic

config filter: not port 22

Barnyard sẽ không ghi alert trên port 22, trongtrường hợp interface dùng để monitor traffic vớiinterface sử dụng SSH là cùng một interface

Mô tả hoạt động của Barnyard

11 Output log và alert vào database

Snort cho phép người dùng log trực tiếp vào database bằng cách cấu hình như sau:

output database: alert, <db_type>, user=<username>

password=<password> test dbname=<name> host=<hostname>

sensor_name=<sensor>

Snort hỗ trợ output vào các loại database sau: MSSQL, MySQL, Oracle,

PostgreSQL…

Đồng thời snort cũng cung cấp script để tạo database như sau:

Database Script Tạo Database Hệ Điều Hành

MS SQL create_mssql Microsft Windows Server

MySQL create_mysql Linux, Unix, Windows

Oracle create_oracle.sql Linux, Unix, Windows

PostgreSQL create_postgresql Linux, Unix, Windows

12 Output log và alert vào Unix syslog

Alert_syslog cho phép snort ghi log và syslog, syslog là hệ thống log chủ yếu củalinux và unix, syslog cung cấp thông tin về hệ thống, kernel, phần cứng và những

thông tin quan trọng khác Snort cho phép người dùng linh hoạt trong việc ghi logvào syslog.

Output alert_syslog: <facility><Priority>

Với facility mặc định là LOG_AUTH và những tùy chọn sau đây:

LOG_AUTH LOG_AUTHPRIV LOG_DAEMON LOG_LOCAL0 LOG_LOCAL1 LOG_LOCAL2 LOG_LOCAL3 LOG_LOCAL4 LOG_LOCAL5 LOG_LOCAL6 LOG_LOCAL7 LOG_USERVới priority mặc định là LOG_ALERT là những tùy chọn sau đây:

LOG_EMERG LOG_ALERT LOG_CRIT LOG_ERR LOG_WARNING LOG_NOTICE LOG_INFO LOG_DEBUG

Ví dụ: output alert_syslog: LOG_AUTH LOG_ALERT

13 Output log và alert vào một file cụ thể

Snort hỗ trợ fast alert và alert full mode, fast alert sẽ xuất alert ra với chỉ một dòngvào file log Dạng log này sẽ nhanh hơn so với full alert mode vì snort không cần in

ra toàn bộ header của gói tin vào file log như với full alert mode

output alert_fast: alert.fast

output alert_full: alert.full

Output của fast alert có dạng sau đây

11/05-22:08:59.705515 [**] [1:469:3] ICMP PING NMAP [**]

[Classification: Attempted Information Leak][Priority: 2] {ICMP}

192.168.206.129 -> 192.168.100.5

14 Output log và alert vào file CSV

Snort cho phép xuất log ra thành file CSV (comma-separated value)

Cú pháp như sau: output alert_csv: [<filename> [<format> [<limit>]]]

• filename: tên của log file

• format: định dạng của file log File log được xuất ra theo option mặc địnhsau đây:

timestampsiggeneratorsigid

sigrevmsgprotosrcsrcportdstdstportethsrcethdstethlentcpflags

tcpseqtcpacktcplentcpwindowttl

tosiddgmleniplenicmptypeicmpcodeicmpidicmpseq

• limit: kích thước giới hạn của file log

Ví dụ:

output alert_csv: /var/log/snort/csv.out

timestamp,msg,srcip,sport,dstip,dport,protoname,itype,icode

Phần output được định dạng như sau:

15 Output log và alert ra nhiều dạng khác nhau

Người dùng có thể cấu hình để snort xuất ra theo nhiều dạng log như ví dụ dướiđây:

output log_tcpdump: tcpdump.log

output database: log, mysql, user=root password=test dbname=db

host=localhost

output alert_unified: filename snort.alert, limit 128

output log_unified: filename snort.log, limit 128

V Network-Based và Host-Based IDS

Nhân tố làm cho snort trở nên hoạt động hiệu quả chính là vị trí và phạm vi mà snorthoạt động, trước khi tiến hành cài đặt snort ta cần phải quan tâm đến là hệ thống snortIDS đang bảo vệ đối tượng nào:

• Một server riêng lẻ

• Một hệ thống gồm nhiều server

• Một subnet

1 Nework-Based IDS

Snort là một hệ NIDS, snort chuyển trạng thái card mạng sang chế độ promiscuous

và xem xét từng gói tin mà snort bắt được và cảnh báo trên gói tin đó Muốn NIDShiệu quả thì NIDS cần kết hợp với span sport Span port cho phép tất cả traffic trongmạng được sao chép và chuyển đến NIDS, điều này làm cho NIDS có thể giám sát

được tất cả traffic trong mạng, do đó hiệu quả của việc trong việc sử dụng NIDS làrất lớn

NIDS giám sát và giữ lại traffic theo giời gian thực ngay khi dữ liệu di qua mạng.NIDS thường sử dụng 2 interface một dùng để giám sát và giữ lại traffic, mộtinterface còn lại dùng cho việc quản lý Interface dùng để giám sát và giữ lại trafficthường sẽ không được gán địa chỉ, chính điều này làm cho nó trở thành một đốitượng trong suốt trong mạng và tránh bị phát hiện

Ứng dụng mà snort NIDS sử dụng để monitor và capture traffic là libpcap Libpcap

là một thư viện được dùng bởi tcpdump, libpcap được thiết kế để thu thập dữ liệucủa các gói tin từ kernel của hệ điều hành Libpcap cung cấp dữ liệu cho NIDS từ

đó có thể phân tích được nội dung dữ liệu, phát hiện được dấu hiệu của sự tấn công,công cụ dùng để tấn công…

Phương pháp và NIDS thường dùng để phát hiện phòng chống tấn công là:

• Mẫu dữ liệu từ những cuộc tấn công trước

• Tần số truy xuất vào hệ thống

• Những sự kiện diễn ra không như bình thường

NIDS sẽ trở thành một vấn đề khó khăn khi triển khai nếu switch mà hệ thống mạngđang sử dụng không có span port và span sport không phải lúc nào cũng được hỗ trợtrên switch

16 Host-Based IDS

Giống như network-based IDS, host-based IDS cũng có khả năng giám sát và giữ lạicác gói tin Thay vì hoạt động ở chế độ promiscuous mode giống như NIDS HIDSchỉ giữ lại những gói tin của riêng cho host đó và HIDS có thể được cài lên nhiều hệđiều hành khác nhau, tuy nhiên không phải hệ điều hành nào củng có thể cài IDS.HIDS có thể giám sát từng host trong mạng ở mức độ chi tiết hơn so với NIDS.HIDS có thể giám sát từng port, từng sự kiện diễn ra trong host như sự thay đổi vềquyền của user, sự thay đổi về những file quan trọng trong hệ thống Ngoài ra HIDS

có thể kiểm tra sự toàn vẹn của những file hệ thống cũng như giám sát những tiếntrình khả nghi Về phương pháp phát hiện và phòng chống tấn công HIDS hầu nhưgiống so với NIDS

Sau đây là bảng so sánh giữa HIDS và NIDS

•Có thể giám sát được một sự kiện cụ thể

•Không phụ thuộc vào hệ thống switch

•Ảnh hưởng đến tàinguyên của host

•Hoạt động phụ thuộcvào hệ điều hành

•Tốn kém khi mởrộng