Nghĩa các tham số cấu hình toàn cục

Một phần của tài liệu Tìm hiểu và triển khai Snort SnortSam (Trang 49)

b. Cấu hình cho giao thức TCP

preprocessor stream5_tcp: <tùy chọn>

Tùy chọn Mô tả

bind_to <ip_addr> Dãy địa chỉ IP sẽ được áp dụng chính sách này.

Mặc định là bất kỳ địa chỉ nào.

timeout <num seconds> Thời gian chờ của một phiên. Mặc định là “30”, tối thiểu là “1” và tối đa là “86400” (khoảng 1 ngày).

policy <policy_id> Chính sách này áp dụng cho hệ điều hành mục

tiêu nào.

overlap_limit <number> Giới hạn số lượng gói tin chồng chéo nhau trên một phiên. Mặc định là “0” (không giới hạn) tối đa là "255".

37

“0” (không giới hạn) và tối đa là "1073725440" (65535 dịch trái 14). Tùy chọn này được sử dụng để chống DoS.

require_3whs [<number seconds>]

Một phiên thiết lập chỉ hoàn thành khi thực hiện quá trình bắt tay 3 bước, mặc định nó được tắt. Số giây chỉ thời gian gia hạn của một phiên hiện tại. Tối thiểu là “0” (không xem xét thời gian thiết lập) và tối đa là “86400”.

detect_anomalies Phát hiện và cảnh báo sự bất thường của giao

thức TCP. Mặc định nó được tắt.

check_session_hijacking Kiểm tra kiểu tấn công TCP Session Hijacking bằng cách kiểm tra địa chỉ MAC của hai đầu kết nối có giống trong quá trình bắt tay ba bước hay không.

dont_store_large_packets Không lưu các gói tin quá lớn vào buffer trong quá trình tái phân mảnh.

dont_reassemble_async Không đợi các gói tin để tái hợp nếu lưu lượng

mạng không được tìm thấy ở cả hai hướng.

max_queued_bytes <bytes> Hạn chế số bytes đợi cho việc tái phân mảnh trên một phiên TCP. Mặc định là "1048576" (1MB). Giá trị "0" có nghĩa là không giới hạn và giá trị tối thiểu khác “0” là “1024”, tối đa là "1073741824" (1GB).

max_queued_segs <num> Hạn chế số segments đợi cho việc tái phân mảnh trên một phiên TCP. Mặc định là “2621”. Giá trị "0" nghĩa là không giới hạn, tối thiểu là “2” và tối đa là "1073741824" (1GB).

ports

<client|server|both> <all|number(s)>

Chỉ định danh sách các port ở client, server hoặc cả hai phía trong việc tái phân mảnh gói tin. Mặc định là các port: 21 23 25 42 53 80 110 111 135 136 137 139 143 445 513 514 1433 1521 2401 3306.

38

protocol

<client|server|both> <all|service name(s)>

Chỉ định danh sách các dịch vụ ở client, server hoặc cả hai phía trong việc tái phân mảnh gói tin. Mặc địch là các dịch vụ: ftp telnet smtp

nameserver dns http pop3 sunrpc dcerpc netbios- ssn imap login shell mssql oracle cvs mysql. Hình 3.4: Ý nghĩa các tham số cấu hình TCP.

c. Cấu hình cho giao thức UDP

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

Tùy chọn Mô tả

timeout <num seconds> Thời gian chờ của một phiên. Mặc định là “30”, tối thiểu là “1” và tối đa là “86400”.

ignore_any_rules Không xử lý bất kỳ luật nào any → any.

Mặc định được tắt.

Hình 3.5: Ý nghĩa các tham số cấu hình UDP.

d. Cấu hình cho giao thức ICMP

preprocessor stream5_icmp: [timeout <number secs>]

Tùy chọn Mô tả

timeout <num seconds> Thời gian chờ của một phiên. Mặc định là “30”, tối thiểu là “1” và tối đa là “86400”. Hình 3.6: Ý nghĩa các tham số cấu hình ICMP.

e. Cấu hình cho giao thức IP

preprocessor stream5_ip: [timeout <number secs>]

Tùy chọn Mô tả

timeout <num seconds> Thời gian chờ của một phiên. Mặc định là “30”, tối thiểu là “1” và tối đa là “86400”. Hình 3.7: Ý nghĩa các tham số cấu hình IP.

39 Ví dụ 1:

preprocessor stream5_global: max_tcp 8192, track_tcp yes, track_udp yes, track_icmp no

preprocessor stream5_tcp: policy first, use_static_footprint_sizes

preprocessor stream5_udp: ignore_any_rules

Ví dụ 2:

preprocessor stream5_global: track_tcp yes

preprocessor stream5_tcp: bind_to 192.168.1.0/24, policy windows

preprocessor stream5_tcp: bind_to 10.1.1.0/24, policy linux preprocessor stream5_tcp: policy solaris

3.1.3. sfPortscan

Mô-đun sfPortscan được phát triển bởi Sourcefire, nó được thiết kế nhằm phát hiện các hình thức thăm dò hệ thống trước khi tấn công. Trong giai đoạn trinh sát hệ thống, attacker sẽ xác định các giao thức mạng, dịch vụ máy chủ hoặc hệ điều hành mục tiêu. Giai đoạn chưa phải là giai đoạn xâm nhập nhưng attacker có thể thu thập được nhiều thông tin hữu ích chuẩn bị cho quá trình xâm nhập. Một công cụ quét cổng cực kỳ mạnh mẽ và phổ biến hiện nay đó nà Nmap. Nmap đầy đủ các kỹ thuật quét cổng hiện nay và sfPortscan được thiết kế nhằm chống lại những kỹ thuật quét cổng từ Nmap.

3.1.4. HTTP Inspect

HTTP đã trở thành một trong những giao thức phổ biến và thông dụng trên Internet. Nên đây mà một giao thức rất được các attacker ưa chuộng. Attacker có thể sử dụng sự linh hoạt của các Web server để cố gắng ẩn thân và che dấu hành vi tấn công trước các NIDS. Ví dụ trong mẫu sau, các mẫu phát hiện như trong Snort sẽ chỉ có thể phát hiện được dạng foo/bar mà không thể phát hiện được foo\bar.

40 http://www.abc/foo\bar\xyz.php

Ngoài ra Attacker còn có thể sử dụng vô số các kỹ thuật mã hóa dựa trên mã hex với uft-8. http_inspect sẽ chỉ xử lý trên từng gói tin, điều này có nghĩa là những chuỗi mà nó xử lý phải được tái hợp trước đó bằng tiền xử lý stream5.

Ví dụ dưới đây về các phương thức GET, chúng đều có chung một chức năng giống hệ nhau, được các webserver xử lý giống hệ nhau.

GET /../../../../etc/passwd HTTP /1.1

GET %2f..%2f..%2f..%2f..%2fetc%2 fpasswd HTTP /1.1 GET

%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%65%74%63%2f%70%61%73% 73%77%64

HTTP /1.1

Trên đây là một ví dụ về tấn công “directory traversal”, hay còn gọi với các tên khác như “dot-dot-slash”, “directory clumbing”. Là hình thức tấn công truy cập đến những file và thư mục mà được lưu bên ngoài webroot. Một hệ thống phát hiện xâm nhập hiểu được phương thức GET của giao thức HTTP nên nó sẽ cho phép request này. Tuy nhiên vấn đề là có vô hạn cách mã hóa các chuỗi độc hại dẫn đến việc nếu ta cấu hình một IDS nhằm phát hiện chuỗi độc hại này dựa trên “signature” thì không thể đảm bảo sẽ phát hiện được hết. Một cách khác đó là bình thường hóa chuỗi này, sau đó so sánh nó với một danh sách “known bad” để phát hiện.

3.2. Output

Mô-đun ouput được thêm vào Snort từ phiên bản 1.6. Chúng cho phép Snort có nhiều cấu hình linh hoạt hơn trong việc định dạng và trình bày dữ liệu đầu ra cho người quản trị hệ thống. Các mô-đun output này sẽ được khởi chạy khi một sự kiện cảnh báo hoặc yêu cầu ghi log được gọi, sau quá trình tiền xử lý và phát hiện thông qua detection engine.

Trong tập tin cấu hình của Snort ta có thể cấu hình nhiều mô-đun đầu ra khác nhau và các mô-đun này sẽ được gọi thứ tự khi có một sự kiện nào đó xảy ra. Mặc định

41

các cảnh báo và các tập tin log sẽ được ghi vào thư mục /var/log/snort hoặc bất kỳ thư mục nào mà người quản trị cấu hình.

Snort hỗ trợ nhiều mô-đun output khác nhau bao gồm:

alert_syslog: Cấu hình này cho phép Snort sẽ gửi thông báo tới syslog.

alert_fast: Các cảnh báo của Snort sẽ được in ra một cách nhanh chóng nhất.

Đây là một phương pháp ghi các cảnh báo nhanh hơn hẳn so với alert_full vì nó không cần in ra tất cả phần header của gói tin và bởi vì nó chỉ in ra trong một tập tin duy nhât.

alert_full: Các cảnh báo sẽ được in ra với đầy đủ phần header của các gói tin. Mặc định thông tin sẽ được lưu tại /var/log/snort ho ặc một thư mục được chỉ định. Snort sẽ tạo ra các thư mục con chứa các cảnh báo ứng với mỗi IP, điều này làm cho hoạt động của Snort chậm đi do đó nó không được khuyến khích sử dụng. alert_unixsock: Tùy chọn này yêu cầu thiết lập một UNIX domain socket và gửi cảnh báo tới nó. Các chương trình hoặc các tiến trình mở rộng sẽ lắng nghe trên socket đó giúp cho việc nhận các cảnh báo các các gói dữ liệu trong thời gian thực. log_tcpdump: Tùy chọn cấu hình này cho phép Snort ghi các t ập tin log ở định dạng tập tin c ủa chương trình tcpdump. Điều này đ ặc biệt hữu ích trong việc tổng hợp và phân tích các thông tin với số lượng lớn. Có rất nhiều công c ụ có thể đọc được định dạng này lên nó rất hữu ích.

csv: Đây là một định dạng lưu trữ dạng text với các trường được phân cách nhau bởi dấu phẩy. Định dạng này giúp ta có thể dễ dàng import vào các cơ sở dữ liệu.

unified và unified2: Là hai định dạng đầu ra thống nhất, phiên bản unified2

là phiên bản cải tiến của unified. Ưu điểm của phương pháp lưu trữ với các định dạng đ ầu ra thống nhất đó là: cho phép dễ dàng trong việc lưu trữ và quản lý, có tốc độ nhanh hơn hẳn so với các phương pháp khác, tập tin xuất ra khó có thể chỉnh sửa nội dung.

log_null: Tùy chọn này hữu ích trong một số trường hợp muốn tạo ra một vài quy tắc cảnh báo lưu lượng truy c ập mạng mà không muốn ghi ra các t ập tin log.

42

CHƯƠNG 4

LUẬT TRONG SNORT

Giới thiệu

“Luật” trong Snort ta có thể hiểu một cách đơn giản nó giống như các quy tắc và luật lệ trong thế giới thực. Nghĩa là nó sẽ có phần mô tả một trạng thái và hành động gì sẽ xảy ra khi trạng thái đó đúng. Một trong những điểm đáng giá nhất của Snort đó là khả năng cho phép người sử dụng có thể tự viết các luật của riêng mình hoặc tùy biến các luật có sẵn cho phù hợp với hệ thống mạng của mình. Ngoài một cơ sở dữ liệu lớn mà người sử dụng có thể download từ trang chủ của Snort, người quản trị có thể tự phát triển các luật cho hệ thống của mình. Thay vì phải phụ thuộc vào nhà cung cấp, một cơ quan bên ngoài, hoặc phải cập nhật khi có một cuộc tấn công mới hay một phương pháp khai thác lỗ hổng mới được phát hiện. Người quản trị có thể viết riêng một luật dành cho hệ thống của mình khi nhìn thấy các lưu lượng mạng bất thường và so sánh với bộ luật được cộng đồng phát triển. Ưu điểm của việc tự viết các luật là có thể tùy biến và cập nhật một cách cực kỳ nhanh chóng khi hệ thống mạng có sự bất thường.

Ví dụ:“Nếu có người cố gắng mở cửa ô tô thì còi sẽ hú.”.

Phân tích ở đây ta hành động “còi hú” sẽ được thực hiện nếu có dấu hiệu là “có người cố gắng mở cửa ô tô”.

Trong hệ thống mạng cũng vậy, ta không thể sử dụng ngôn ngữ tự nhiên hằng ngày để mô tả dấu hiệu hay trạng thái của hệ thống mạng được. Ví dụ: Nếu có một kết nối SSH có địa chỉ IP Public kết nối tới máy chủ web thì chặn lại. Mặc dù đây là một mô tả khá cụ thể, tuy nhiên Snort lại không thể hiểu được. Luật trong Snort sẽ giúp ta dễ dàng mô tả dấu hiệu này theo ngôn ngữ mà Snort có thể hiểu được.

Để biết cách viết một luật từ các dữ liệu của hệ thống ta cần phải hiểu cấu trúc của luật trong Snort như thế nào. Một luật trong Snort được chia thành hai phần đó là

43

phần header và options. Phần header bao gồm: rule action, protocol, địa chỉ ip nguồn, địa chỉ ip đích, subnetmask, port nguồn, port đích. Phần options bao gồm các thông điệp cảnh báo, thông tin các phần của gói tin sẽ được kiểm tra để xác định xem hành động nào sẽ được áp dụng.

4.1. Rule Header

Rule Header

Hình 4.1: Cấu trúc luật trong Snort.

4.1.1. Rule Action

Phần Header sẽ chứa các thông tin xác định ai, ở đâu, cái gì của một gói tin, cũng như phải làm gì nếu tất cả các thuộc tính trong luật được hiện lên. Mục đầu tiên trong một luật đó chính là phần rule action, rule action sẽ nói cho Snort biết phải làm gì khi thấy các gói tin phù hợp với các luật đã được quy định sẵn. Có 5 hành động mặc định trong Snort đó là: alert (cảnh báo), log (ghi lại log), pass (cho qua), active (kích hoạt), dynamic. Ngoài ra nếu chạy Snort ở chế độ inline còn có thêm các tùy chọn bổ sung như drop, reject và sdrop.

alert - tạo ra cảnh báo sử dụng phương pháp đã lựa chọn trước và sau đó

ghi log lại các gói tin.  log - ghi log lại các gói tin.

pass - bỏ qua gói tin đó.

active - cảnh báo và sau đó bật một dynamic rule khác để kiểm tra thêm

điều kiện của gói tin.

dynamic - duy trì trạng thái “nhàn rỗi” cho đến khi được kích hoạt bởi

một active rule sau đó hành động như một log rule

Rule

Action Protocol Src/Des Port Rule Option

44  drop - chặn gói tin đó và ghi log lại.

reject - chặn gói tin, ghi log lại và gửi trả về một thông điệp.

sdrop - chặn gói tin nhưng không ghi log lại.

hành động do user tự định nghĩa. 4.1.2. Protocol

Trường tiếp theo trong luật đó là protocol. Có 4 giao thức mà Snort hiện đang phân tích các hành vi bất thường đó là TCP, UDP, ICMP và IP.

4.1.3. IP Address

Mục tiếp theo của phần header đó là địa chỉ IP. Các địa chỉ này dùng để kiểm tra nơi đi và nơi đến của một gói tin. Địa chỉ ip đó có thể là địa chỉ của một máy đơn hoặc cũng có thể là địa chỉ của một lớp mạng. Từ khóa “any” được sử dụng để định nghĩa một địa chỉ bất kỳ.

Một địa chỉ ip sẽ được viết dưới dạng ip_address/netmask. Điều này có nghĩa là nếu netmask là /24 thì lớp mạng đó là lớp mạng C, /16 là lớp mạng B hoặc /32 là chỉ một máy đơn. Ví dụ: địa chỉ 192.168.1.0/24 có nghĩa là một dải máy có địa chỉ IP từ 192.168.1.1-192.168.1.255.

Trong hai địa chỉ IP trong một luật Snort thì sẽ có một địa chỉ IP nguồn và một địa chỉ IP đích. Việc xác định đâu là địa chỉ nguồn, đâu là địa chỉ đích phụ thuộc vào

“→”.

Ngoài ra toán tử phủ định có thể được áp dụng cho việc định địa chỉ IP. Có nghĩa là khi sử dụng toán tử này thì Snort sẽ bỏ qua việc kiểm tra địa chỉ của gói tin đó. Toán tử đó là “!”. Ngoài ra ta có thể định nghĩa một danh sách các địa chỉ IP bằng

cách viết liên tiếp chúng cách nhau bởi một dấu “,”.

Ví dụ:

alert tcp any any → ![192.168.1.0/24, 172.16.0.0/16] 80 (msg:\ “Cho phep truy cap”)

45

Port có thể được định nghĩa bằng nhiều cách. Với từ khóa “any” giống như địa chỉ IP để chỉ có thể sử dụng bất kỳ port nào. Gán một port cố định ví dụ như gán kiểm tra ở port 80 http hoặc port 22 ssh. Ngoài ra ta cũng có thể sử dụng toán tử phủ định để bỏ qua một port nào đó hoặc liệt kê một dải các port.

Ví dụ:

log udp any any → 192.168.1.0/24 1:1024 - port bất kỳ tới dãy port từ 1

- 1024.

log udp any any → 192.168.1.0/24 :6000 - port bất kỳ tới dãy port nhỏ

hơn 6000.

log udp any any → 192.168.1.0/24 500: - port bất kỳ tới dãy port lớn

hơn 500.

log udp any any → 192.168.1.0/24 !6000:6010 - port bất kỳ tới bất kỳ

port nào, bỏ qua dãy port từ 6000 – 6010.

4.1.5. Điều hướng

Toán tử hướng “→” chỉ ra đâu là hướng nguồn, đâu là hướng đích. Phần địa chỉ IP và port ở phía bên trái của toán tử được coi như là địa chỉ nguồn và port nguồn, phần bên phải được coi như địa chỉ đích và port đích. Ngoài ra còn có toán tử “<>” Snort sẽ xem cặp địa chỉ/port nguồn và đích là như nhau. Nghĩa là nó sẽ ghi/phân tích ở cả hai phía của cuộc hội thoại.

Ví dụ:

log tcp !192.168.1.0/24 any <> 192.168.1.0/24 23

4.1.6. Activate/Dynamic rule

Cặp luật này cung cấp cho Snort một khả năng rất mạnh mẽ. Active rule giống như alert rule nhưng khác một điểm là nó có thêm trường: activates. Dynamic rule giống như log rule nhưng nó có thế trường: activated_bycount.

46

activate tcp !$HOME_NET any → $Home_Net 143 (flags:PA; content: “|E8C0FFFFFF|/bin”; activates:1; msg:”IMAP buffer

Một phần của tài liệu Tìm hiểu và triển khai Snort SnortSam (Trang 49)