Xây đựng một hệ thống snort – IDS trên hệ điều hành ubuntu

BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC HOA SEN
KHOA KHOA HỌC VÀ CÔNG NGHỆ
Giảng viên hướng dẫn : Nguyễn Ngọc Như Hằng
Nhóm sinh viên thực hiện :
Nguyễn Quỳnh MSSV:070073
Phù Sử Hùng MSSV:070156
Lớp : VT071
Tháng 12 /năm 2010
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ập
thô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ười
xâ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ạng
ngừ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ện
phá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ều
hà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ấn
công và thâm nhập trong mạng. Do đó đề tài tập trung nghiên cứu vào phương thức
hoạ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ết
lậ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 qua việ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ầu
nhằ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ủa snort 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ếp
hướ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ướng
dẫ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ài
nà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 đáp
nhữ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ên
cứ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úp
cho 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ành quá 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ình nửa vòng trái đất để lấy thông tin website, mail… Hacker cũng làm những công
việc tươ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ụng hay 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ân dẫ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ủa
snort 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ết lậ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. Để xem cá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 command line 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ạy
theo 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, dectection
option, 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
option khác nhau quy định các thông tin về rule và khác detect option như sid
(snort identifier), message…Khi rule được phân tích snort sẽ tiến hành xây dựng
tất cả các rule 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ồm các dection option. Tất cả các OTN tương ứng với một header sẽ
được nhóm lại dướ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ói tin 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ói tin, 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ới
rulebase 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ện hỗ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 Detection
mode.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 dung
không thay đổi hoặc có thể bị thay đổi, reject gói tin hoặc drop gói tin mà không
cần phả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ủa inline đều có thể buffer các gói tin, nếu snort tốn quá nhiều thời gian để xử lý
gói tin trong 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ế độ inline drop 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 ra việ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ác preprocessor 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ên quan 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ói tin 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, Cisco
HDLC, 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òn decoder nào được gọi nữa. Trong khi decode snort sẽ kiểm tra tính sự hợp lệ

của gói tin 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ếp theo 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ường hợ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ều
con trỏ khác nhau trỏ đến những phần khác nhau của gói tin, điều này cho phép
snort có thể truy xuất nhanh đến những thành phần trong gói tin. Con trỏ này cho
phé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
tin cho phép các thành phần khác nhau của snort có thể thông tin cho nhau. Lúc
nào trong cấu trúc gói tin lúc này sẽ chứa con trỏ chỉ đến TCP stream tracker, IP
fragment tracker và flow tracker.
2.3 Preprocessor
Sau khi gói tin được decode nó được chuyển qua preprocessor. Preprocessor của
snort đó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ác
protocol 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ện trự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 detection
engine. 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ựa
và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ác
OTN. 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át
hiệ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ành mộ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ệc
ghi 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 trong
tậ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ớp vớ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 rule
lạ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ác rule. 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ào

khớ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ùng
cấ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ến
hà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
đa cho phép. Theo mặc định snort sẽ đưa ra cảnh báo theo rule nào khớp nhiều
nhất vớ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 output
plug-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ác
rules. 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át
sinh ra từ một rule đối với những rule quá cơ bản có thể phát sinh ra nhiều cảnh
bá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ần
trước khi rule đưa ra cảnh báo. Khi người dùng cấu hình threshold đếm đến 3 cho
mộ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ột
source 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ột hà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ới mộ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ụng nhưng trước khi hành động được ghi log lại. Bước cuối cùng mà snort phải
thực hiệ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 qua việ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ông
cho 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ên trong rule và tạo thành detection engine. Hầu hết công việc của detection
engine thự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ện xâm nhập. Một số rule option có cấu trúc phức tạp và có vai trò quan trọng
trong detection 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ực
tiế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 trong
mộ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ểm
tra 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ảm thờ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 destination
port của rule. Sau đó với mỗi destination port, snort xác định trường content string
dà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. Khi một gói tin đi vào pattern matcher, một nhóm các pattern sẽ được chọn
dựa vào destination port. Sau đó, snort sẽ chọn ra một nhóm các pettern trong các
pattern ban đầ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à rule
base 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 snort
khở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)
ac 141 22.2 400.8 493 176.4 766.6
acs 49 20.2 490.4 183 179.0 936.3
ac-std 243 7.7 399.6 836 34.0 841.4
ac-banded 76 20.0 408.9 323 178.6 781.7
ac-sparsebands 53 19.7 435.9 236 178.5 787.2
mwn 60 4.4 421.0 102 6.2 795.6
lowmem 35 3.9 458.9 57 5.1 832.4
4.3 Dynamic detection engine
Share object rule hay còn gọi là dynamic detection engine cung cấp 2 chức năng
chí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 Rule
cho phép snort cập nhật hành động tấn công một cách nhanh chóng. Thứ hai,
shared object 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ội dung 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ạp
nhất của snort, ở mode này snort phân tích traffic trong mạng, từ đó phát
hiệ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 TCP
reset 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 interface
nhậ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ông
cầ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:
Ví dụ: config layer2resets
Cấu hình trên sẽ chỉ định rằng snort sẽ dùng MAC của bridge interface làm
địa chỉ source để reset gói tin.
config layer2resets:

Cấu hình trên sẽ chỉ định snort dùng địa chỉ MAC 00:06:76:DD:5F:E3 làm
địa chỉ snort để reset gói tin.
 Thứ tự các rule trong snort inline
Activationdynamicpassdropsdroprejectalert log
 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ại
packet, traffic flow và kiểm tra traffic trong mạng để phát hiện tấn công và đưa ra
cảnh báo.
Protocol Decoder
Traffic đầu tiên phải đi vào decoder, để decode các
thông tin ban đầu.
IP Defragmentation
(frag3)
frag3 là preprocessor để xây dựng lại gói tin từ
những gói tin đã bị phân mảnh trong quá trình
truyền.
Stateful Inspection
(stream5)
stream5 sau đó sẽ kiểm tra xem gói tin đó có phải là
một phần của session hay không.
Stream Reasesembly
(Stream5)
stream5 tiến hành xây dựng lại thành 1 TCP stream
từ những thông tin nó thu được.
Application
Layer Preprocessor

Những preprocessor này được dùng để xây dựng lại
những gói tin những protocol thông thường và thậm
chí có thể đưa ra cảnh báo nếu cần.
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ằm
vượ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ủa
frag3. 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ất hiệ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ại gó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ều hà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
destination host 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 cho nhựng OS như sau:
• BSD
• BSD-right
• Linux
• First
• Last
• Windows
• Solaris
Snort phân chia hệ điều hành theo policy như sau:
Platform Type

X 2 BSD
AIX 4.3 8.9.3 BSD
Cisco IOS Last
FreeBSD BSD
HP JetDirect (printer) BSD-right
HP-UX B.10.20 BSD
HP-UX 11.00 First
IRIX 4.0.5F BSD
IRIX 6.2 BSD
IRIX 6.3 BSD
IRIX64 6.4 BSD
Linux 2.2.10 Linux
Linux 2.2.14-5.0 Linux
Linux 2.2.16-3 Linux
Linux 2.2.19-6.2.10smp Linux
Linux 2.4.7-10 Linux
Linux 2.4.9-31SGI 1.0.2smp Linux
Linux 2.4 (RedHat 7.1-7.3) Linux
MacOS (version unknown) First
NCD Thin Clients BSD
OpenBSD (version unknown) Linux
OpenBSD (version unknown) Linux
OpenVMS 7.1 BSD
OS/2 (version unknown) BSD
OSF1 V3.0 BSD
OSF1 V3.2 BSD
OSF1 V4.0,5.0,5.1 BSD
SunOS 4.1.4 BSD
SunOS 5.5.1,5.6,5.7,5.8 First
Tru64 Unix V5.0A,V5.1 BSD

Vax/VMS BSD
Windows (95/98/NT4/W2K/XP) First
5.3 Cấu hình frag3
Để frag3 có thể hoạt động thì cần ít cần ít nhất hai preprocessor khác.
frag3_global preprocessor
• max frags <number> : số lượng phân mảnh tối đa mà frag3 có thể theo
dõi mặc định là 8.192.
• 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ác
fragment node
frag3_engine preprocessor
• timeout <seconds>: thời gian timeout cho việc phân mảnh, mặc định sau
60 gói tin phân mảnh sẽ bị drop
• min_tll <value>: Giá trị TTL nhỏ nhất cho một gói tin phân mảnh, mặc
định là 1
• detect_anomalies: phát hiện những việc phân mảnh bất thường
• 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ăng
detect_anomalies phải được bật.
• min_fragment_length <number>: quy định kích thước mảnh nhỏ nhất,
kích thướ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ăng
detect_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
qua preprocessor và quy trình kiểm tra một lần nữa. Điều này có nghĩa là traffic sẽ
được phâ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 TCP
session, giống như frag3 stream5 cung cấp chức năng target-based. Ngoài ra
stream5 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úc
bằ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ên
thô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.
Target-based
Preprocessor stream5 cũng giống như frag3, stream5 đưa ra khái niệm target-
based để xử lý hiện tượng dữ liệu trùng lắp giữa những gói tin và những giao
dịch TCP bất thường. Phương pháp dùng để xử lý trùng lắp dữ liệu, TCP
Timestamps, 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ành khác nhau để có từng policy cụ thể cho từng hệ đều hành.
Stream API
Preprocessor stream5 hỗ trợ stream API, cho phép các bộ phận kiểm tra tính
hợp lệ của protocol và preprocessor cấu hình việc tập hợp gói tin theo yêu cầu
của ứng dụng ở lớp của application, xác định session nào nên bỏ qua và cập
nhật thô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
data hay dữ liệu nằm ngoài TCP windows size…những chức năng này thường

được cấ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