– Non-payload rule options

Các option tìm kiếm các dữ liệu không có trong payload. Một số option phổ biến:

  • fragoffset – Cho phép so sánh giá trị trường IP fragment offset với một giá trị hoặc một khoảng giá trị thập phân cho trước. Toán tử phủ định (!) có thể sử dụng để kiểm tra điều kiện không đúng.

Định dạng: fragoffset:[!|<|>]<number>;

  • ttl – Kiểm tra giá trị time-to-live, dùng để phát hiện việc thử traceroute. Giá trị có thể từ 0 đến 255, có thể là một khoảng (sử dụng ký hiệu -) hoặc giá trị nhất định. Các phép so sánh: nhỏ hơn (<), lớn hơn (>), nhỏ hơn hoặc bằng (<=), lớn hơn hoặc bằng (>=), bằng (=).

Định dạng: ttl:[<,>,=,<=,>=]<number>;

        ttl:[<number>]-[<number>];

  • tos – Kiểm tra giá trị trường TOS với một giá trị xác định. Toán tử phủ định (!) có thể dùng cho kiểm tra điều kiện không đúng.

Định dạng: tos:[!]<number>;

  • id – Kiểm tra trường ID với một giá trị xác định. Một vài công cụ (chương trình khai thác, scanners và các chương trình lẻ) gán giá trị đặc biệt cho trường này cho nhiều mục đích.

Định dạng: id:<number>;

  • ipopts – Kiểm tra các tùy chọn IP có hiện diện hay không, những option này có thể là: rr (Record Route), eol (End of list), nop (No Op), ts (Time Stamp), sec (IP Security), esec (IP Extended Security), lsrr (Loose Source Routing), ssrr (Strict Source Routing), satid (Stream Identifier), any (bất kỳ option IP nào). Chỉ có 1 option ipopts trong mỗi rule.

Định dạng:

ipopts:<rr|eol|nop|ts|sec|esec|lsrr|lsrre|ssrr|satid|any>;

  • fragbits – Kiểm tra các bit fragmentation (M, D) và reserved (R) được gán trong IP header. Điều kiện kiểm tra có thể thay đổi do ký tự được sử dụng kèm theo: + (phù hợp với các bit nhất định, và có thể bất kỳ bit nào phía sau), * (phù hợp với bất kỳ bit nhất định nào), ! (các bit xác định không được gán).

Định dạng: fragbits:[+*!]<[MDR]>;

  • dsize – Kiểm tra kích thước payload của gói tin, có thể dùng để kiểm tra các gói tin có kích thước không bình thường có thể gây ra buffer overflow. Kích thước để kiểm tra có thể là một khoảng hoặc một số nhất định.

Định dạng: dsize:min<>max;

         dsize:[<|>]<number>;

  • flags – Kiểm tra các bit flag TCP xác định có được bật hay không. Các bit này là F (FIN), S (SYN), R (RST), P (PSH), A (ACK), U (URG), C (CWR), E (ECE), 0 (không bit nào được bật). Điều kiện kiểm tra thay đổi do ký tự được sử dụng kèm theo: + (phù hợp với các bit nhất định, và có thể bất kỳ bit nào phía sau), * (phù hợp với bất kỳ bit nhất định nào), ! (các bit xác định không được gán).

Định dạng: flags:[!|*|+]<flag>;

  • flow – Cho phép rule chỉ được áp dụng cho một hướng nhất định của đường đi traffic. Các hướng có thể:

Định dạng: flow:[(establised|not_established|stateless)]

[,(to_client|to_server|from_client|from_server)] [,(no_stream|only_stream)][,(no_frag|only_frag)];

  • seq – Kiểm tra giá trị sequence number TCP nhất định.

Định dạng: seq:<number>;

  • ack – Kiểm tra giá trị acknowledge number TCP nhất định.

Định dạng: ack:<number>;

  • window – Kiểm tra giá trị window size TCP nhất định. Option này có thể sử dụng toán tử phủ định (!).

Định dạng: window:[!]<number>;

  • itype – Kiểm tra giá trị ICMP type. Giá trị so sánh có thể là một số hoặc một khoảng nhất định (sử dụng ký hiệu < hoặc/và >).

Định dạng: itype:min<>max;

        itype:[<|>]<number>;

  • icode – Kiểm tra giá trị ICMP code. Giá trị so sánh có thể là một số hoặc một khoảng nhất định (sử dụng ký hiệu < hoặc/và >). Giá trị ICMP code trong khoảng từ 0 đến 255, các khoảng và các phép so sánh phải đảm bảo giá trị này.

Định dạng: icode:min<>max;

        icode:[<|>]<number>;

  • icmp_id – Kiểm tra giá trị ICMP ID, vì một số kênh bí mật sử dụng ICMP tĩnh khi giao tiếp.

Định dạng: icmp_id:<number>;

  • icmp_seq – Kiểm tra giá trị sequence ICMP, vì một số kênh bí mật sử dụng ICMP tĩnh khi giao tiếp.

Định dạng: icmp_seq:<number>;

  • ip_proto – Kiểm tra header giao thức IP.

Định dạng: ip_proto:[!|>|<]<name hoặc number>;

  • sameip – Kiểm tra địa chỉ IP đích và IP nguồn có giống nhau hay không.

Định dạng: sameip;

– Post-detection rule options

Các option này là các rule trigger được thực hiện sau khi một rule đã được thực thi.

  • logto – Cho phép Snort ghi chép tất cả các gói tin phù hợp với rule vào một file log đặc biệt. Option này không hoạt động khi Snort đang chạy mở mode ghi chép nhị phân.

Định dạng: logto:“filename”;

  • session – trích xuất dữ liệu người dùng từ các TCP session, ví dụ khi gõ trong telnet, rlogin, ftp hoặc trong web. Option này có thể có 3 tham số: printable chỉ in những dữ liệu người dùng có thể đọc bình thường hoặc có thể gõ được, binary in dữ liệu dưới dạng nhị phân, all thay thế các ký tự không đọc được với giá trị thập lục phân (hệ 16) tương ứng.

Định dạng: session:[printable|binary|all];

  • tag – Ghi chép nhiều hơn cho gói tin phù hợp với rule, traffic thêm bào gồm địa chỉ nguồn hoặc/và địa chỉ đích.

Định dạng: tag:host, <count>,<metric>,<direction>;

        tag:session[,<count>,<metric>][,exclusive];

Trong đó:

host: ghi chép gói tin từ host kích hoạt tag

session: ghi chép gói tin trong phiên làm việc phù hợp với rule.

count: một số lượng <metric> để tag gói tin

metric: packets – tag host/session trong <count> gói tin, seconds – tag host/session trong <count> giây, bytes – tag host/session trong <count> bytes.

direction: src/dst – tag các gói tin chứa địa chỉ IP nguồn/đích tạo ra sự kiện khởi dầu. Chỉ dùng với host.

exclusive: tag gói tin chỉ trong phiên phù hợp đầu tiên. Chỉ dùng với session.

  • activates – Xác định một rule được thêm vào khi một sự kiện nhất định trên mạng xảy ra.

Định dạng: activates:1;

  • activated_by – Cho phép bật một rule khi một activate rule được áp dụng. Bên cạnh đó, option count được dùng chung với option activated_by, cho phép xác định số gói tin để bật rule này sau khi nó được kích hoạt.

Định dạng: activated_by count:<number>;:1;

  • replace – Dùng trong inline mode cho phép Snort thay thế nội dung phù hợp trước đó với chuỗi cho trước. 2 chuỗi này phải có cùng độ dài với nhau. Trong một rule có thể có nhiều thay thế như vậy, mỗi thay thế cho 1 nội dung.

Định dạng: replace:”<string>”;

  • detection_filter – Xác định tỷ lệ phải vượt qua ở host nguồn hoặc đích trước khi rule có thể tạo ra sự kiện. Snort đánh giá detection_filter là bước cuối cùng của giai đoạn phát hiện, sau khi đánh giá tất cả các rule option khác (bất kể vị trí của nó trong nguồn rule). Một rule có tối đa 1 option này.

Định dạng: detection_filter:\

        track <by_src|by_dst>,\

        count <c>, seconds <s>;

Trong đó:

by_src|by_dst: tỷ lệ được theo dõi ở địa chỉ IP nguồn hay đích.

count c: số lượng lần phù hợp rule lớn nhất trong s giây được cho phép trước khi vượt qua giới hạn detection filter. c phải khác 0.

seconds s: khoảng thời gian đếm count. s phải khác 0.

Kết luận:

Mỗi rule được viết nên có những phần sau:

  • Một thông điệp sử dụng từ khóa msg.
  • Phân loại rule, sử dụng từ khóa classification.
  • Sử dụng một con số để định danh cho rule với từ khóa sid.
  • Nếu lỗ hổng đã được biết, luôn sử dụng một tham chiếu đến một URL chứa nhiều thông tin hơn với từ khóa reference.
  • Sử dụng từ khóa rev trong rule để ghi lại những phiên bản khác nhau của rule.

Các rule này người dùng có thể thêm trực tiếp vào file cấu hình snort.config, tuy nhiên để thuận tiện nên để những rule này ở các file text khác, và gọi từ file cấu hình với từ khóa include.

Dynamic Modules là gì? Cho ví dụ?

Dynamic Modules: là các Preprocesser, các tính năng phát hiện, các rules có thể được phát triển như các mô hình tự động. Dynamic API giúp các thư viện được tải lên một cách tự động và cho phép module sử dụng các chức năng nhất định trong main Snort code.

Dynamic Modules có cấu trúc dữ liệu cơ bản như sau:

  • DynamicPluginMeta: cấu trúc này cho phép định nghĩa các loại dynamic module (preprocessor, detection engine, rules), thông tin phiên bản và đường dẫn tới các thư viện chia sẻ. Một thư viện chia sẻ có thể được thiết lập cả 3 loại, nhưng thường giới hạn 1 tính năng như preprocessor. Nó được định nghĩ trong h:

#define MAX_NAME_LEN 1024 #define TYPE_ENGINE 0x01#define TYPE_DETECTION 0x02#define TYPE_PREPROCESSOR 0x04 typedef struct _DynamicPluginMeta{    int type;    int major;    int minor;    int build;    char uniqueName[MAX_NAME_LEN];    char *libraryPath;} DynamicPluginMeta;

 

  • DynamicPreprocessorData: cho phép nhận dạng interface preprocessor sử dụng để tương tác với Snort. Chức năng này bao gồm việc ghi lại các chỉnh sửa cấu hình của preprocessor, khởi động, thoát và chức năng xử lí. Nó cũng bao gồm các tính năng như ghi lại log messages, lỗi, lỗi nghiêm trọng, các thông tin sửa lỗi… Cấu trúc dữ liệu này nên được khởi tạo khi preprocessor shared library được load. Nó được định nghĩa trong h.
  • DynamicEngineData: định nghĩa giao diện detection engine được sử dụng để tương tác với Snort. Nó có các tính năng tương tự như DynamicPreprocessorData và được định nghĩa trong h.
  • SFSnortPacket: cấu trúc gói tin Snort và cung cấp quyền truy cập đến tất cả các dữ liệu chứa trong một packet. Nó và các cấu trúc dữ liệu kết hợp với nó được định nghĩa tại h.
  • Dynamic Rules: có các tính năng và thành phần như một Snort Rules bình thường, nhưng được sử dụng và xây dựng theo cấu trúc dữ liệu.

Ví dụ: Ta sẽ lấy ví dụ về Rule:

Giả sử ta có 1 rule bình thường như sau:

Thì cấu trúc của một Dynamic Rules được lưu trữ trong file sid109.c là như sau:

Phát triển Snort như thế nào? 

Tham khảo (http://manual-snort-org.s3-website-us-east-1.amazonaws.com/node41.html)

Snort là một phần mềm mã nguồn mở nên ta hoàn toàn có thể tự mình thay đổi và phát triển Snort theo cách riêng của mình. Sau khi phát triển ta nên gửi bản patches của chúng ta đến snort-devel@lists.sourceforge.net. Và các Patches này khi được phát triển xong ta nên kết thúc chúng bằng lệnh diff –nu snort-orig snort-new

Ta có thể lựa chọn phát triển và cải tiến các Plugin cơ bản của Snort như là Preprocessor, Detection Plugins, Output Plugins để nó có thể tiến hành nhanh chóng và tối ưu hơn so với các phiên bản Snort cũ, hoặc có thể tới ưu hóa được trên một số máy nhất định mà chúng ta sử dụng.

Hiện nay Snort không còn sử dụng các định dạng thông thường để lưu trữ các thông tin thu thập được, mà Snort sử dụng một định dạng mới tên là Unified2.