VIỆN ĐẠi học mở HÀ NỘi khoa công nghệ thông tin đỒ Án tốt nghiệP ĐẠi họC
Phân loại các dấu hiệu trong hệ thống IDS
tải về 0.74 Mb.
|
- Điều hướng trang này:
- 1.7.7.Một số kiến thức cơ bản về Snort
1.7.6.Phân loại các dấu hiệu trong hệ thống IDS
Hệ thống phát hiện xâm nhập phải có khả năng phân biệt giữa các hoạt động thông thường của người dùng với hoạt động bất thường để tìm ra được các tấn công nguy hiểm kịp thời. Mặc dù vậy, việc dịch các hành vi người dùng (hoặc session hệ thống người dùng hoàn chỉnh) trong một quyết định liên quan đến bảo mật phù hợp thường không đơn giản – nhiều hành vi không được dự định trước và không rõ ràng. Để phân loại các hoạt động, IDS phải lợi dụng phương pháp phát hiện dị thường, dôi khi là hành vi cơ bản hoặc các dấu hiệu tấn công… một thiết bị mô tả hành vi bất thường đã biết (phát hiện dáu hiệu) cũng được gọi là kiến thức cơ bản.
Các mẫu hành vi thông thường rất hữu ích trong việc dự đoán người dùng và hành vi hệ thống. Do đó các bộ phát hiện bất thường xây dựng profile thể hiện việc sử dụng thông thường và sau đó sử dụng dữ liệu hành vi thông thường để phát hiện sự không hợp lệ giữa các profile và nhận ra tấn công có thể. Để hợp lý với các profile sự kiện, hệ thống bị yêu cầu phải tạo ra profile người dùng ban đầu để “đào tạo” hệ thống quan tâm đến sự hợp pháp hóa hành vi người dùng. Có một vấn đề liên quan đến việc làm profile ở đây đó là: khi hệ thống được phép “học” trên chính nó, thì những kẻ xâm nhập cũng có thể đào tạo hệ thống ở điểm này, nơi mà các hành vi xâm phạm trước trở thành hành vi thông thường. Một profile không tương thích sẽ có thể được phát hiện tất cả các hoạt động xâm nhập có thể. Ngoài ra, còn có một sự cần thiết nữa đó là nâng cấp profile và “đào tạo” hệ thống, một nhiệm vụ khó khăn và tốn thời gian. Cho một tập các profile hành vi thông thường, mọi thứ không hợp với profile được lưu sẽ được coi như là một hoạt động nghi ngờ. Do đó, các hệ thống này được đặc trưng bởi hiệu quả phát hiện rất cao (chúng có thể nhận ra nhiều tấn công mặc dù tấn công đó là mới có trong hệ thống), tuy nhiên chúng lại có hiện tượng là tạo các cảnh báo sai về một số vấn đề.
Sự cần thiết về đào tạo hệ thống khi thay đổi hành vi sẽ làm hệ thống không có được phát hiện bất thường trong giai đoạn đào tạo (lỗi tiêu cực).
Thông tin xử lý hệ thống trong các hành vi bất thường và không an toàn (dấu hiệu tấn công – dựa vào các hệ thống) thường được sử dụng trong các hệ thống phát hiện xâm nhập thời gian thực (vì sự phức tạp trong tính toán của chúng không cao). Các dấu hiệu hành vi xấu được chia thành hai loại:
Có hai phương pháp chính đã kết hợp sự phát hiện dấu hiệu này:
Các phương pháp phát hiện dấu hiệu có một số ưu điểm dưới đây: tỉ lệ cảnh báo sai thấp, thuật toán đơn giản, dễ dàng tạo cơ sở dữ liệu dấu hiệu tấn công, dễ dàng bổ sung và tiêu phí hiệu suất tài nguyên hệ thống tối thiểu. Một số nhược điểm:
Các sản phẩm IDS thương mại thường sử dụng phương pháp phát hiện dấu hiệu cho hai lý do. Trước tiên, nó dễ dàng hơn trong việc cung cấp dấu hiệu liên quan đến tấn công đã biết và để gán tên đối với một tấn công. Thứ hai, cơ sở dữ liệu dấu hiệu tấn công được nâng cấp thường xuyên (bằng cách thêm các dấu hiệu tấn công mới phát hiện).
Phương pháp thứ ba về phát hiện xâm nhập khá khôn ngoan hơn hai phương pháp trước. Nó được sinh ra do nhu cầu thực tế rằng, các quản trị viên kiểm tra các hệ thống khác nhau và các thuộc tính mạng (không cần nhắm đến các vấn đề bảo mật). Thông tin đạt được trong cách này có một môi trường cụ thể không thay đổi. Phương pháp này liên quan đến sử dụng kinh nghiệm hoạt động hàng ngày của các quản trị viên như các vấn đề cơ bản cho việc phát hiện dấu hiệu bất thường. Nó có thể được xem như trường hợp đặc biệt của phương pháp Profile thông thường. Sự khác nhau ở đây nằm ở chỗ trong thực tế, một profile là một phần hiểu biết của con người. Đây là một kỹ thuật mạnh, bời vì nó cho phép xâm nhập dựa trên các kiểu tấn công không biết. Hoạt động hệ thống có thể phát hiện các thay đổi tinh vi không rõ ràng đối với chính hoạt động đó. Nó kế thừa những nhược điểm trong thực tế là con người chỉ hiểu một phần giới hạn thông tin tại một thời điểm, điều đó có nghĩa là các tấn công nào đó có thể vượt qua mà không bị phát hiện. 1.7.7.Một số kiến thức cơ bản về SnortSNORT là một IDS Software, là một sản phẩm mã nguồn mở được phát triển nhằm phát hiện những xâm nhập trái phép vào hệ thống bởi những quy tắc hay luật đã được thiết lập sẵn, những thiết lập này dựa vào những dấu hiệu, giao thức và sự dị thường. Snort sử dụng các luật được lưu trữ trong các file text, có thể được chỉnh sửa bởi người quản trị. Các luật được nhóm thành các kiểu. Các luật thuộc về mỗi loại được lưu trong các file khác nhau. File cấu hình chính của Snort là snort.conf. Snort đọc những luật này vào lúc khởi tạo và xây dựng cấu trúc dữ liệu để cung cấp các luật để bắt giữ mẫu vi phạm. Tìm ra các dấu hiệu và sử dụng chúng trong các luật là một vấn đề đòi hỏi sự tinh tế, vì càng sử dụng nhiều luật thì năng lực xử lý càng được đòi hỏi để thu thập dữ liệu trong thực tế. Snort có một tập hợp các luật được định nghĩa trước để phát hiện các hành động xâm nhập và các quản trị viên cũng có thể thêm vào các luật của chính mình. Quản trị viên cũng có thể xóa một vài luật đã được tạo trước để tránh việc báo động sai.
Snort được chia thành nhiều thành phần. Những thành phần này làm việc với nhau để phát hiên các cách tấn công cụ thể và tạo ra output theo định hướng đang được đòi hỏi. Một IDS dựa trên Snort bao gồm các thành phần chính sau đây:
Hình 3.22. Hình minh họa các thành phần của Snort Packet Decoder (Bộ phân giải mã gói) Bộ phận giải mã gói lấy các gói từ các giao diện mạng khác nhau và chuẩn bị cho việc gói tin được xử lí trước hoặc được gửi cho bộ phận phát hiện Preprocessor (Bộ phận xử lý trước) Bộ phận xử lí trước là những thành phần được sử dụng với Snort để sắp xếp hoặc chỉnh sửa gói dữ liệu trước khi bộ phận phát hiện làm một vài xử lý để tìm ra gói tin có được sử dụng bởi kẻ xâm nhập hay không. Một vài bộ phận xử lý trước cũng thực thi việc phát hiện bằng cách tìm các dấu hiệu bất thường trong header của gói tin và tạo ra các cảnh báo. Bộ phận xử lí trước là rất quan trọng trong bất kì IDS nào, chúng chuẩn bị cho các gói dữ liệu được phân tích dựa trên các luật trong bộ phận phát hiện. Kẻ tấn công sử dụng nhiều kĩ thuật khác nhau để lừa IDS theo nhiều cách. Bộ phận xử lí trước cũng được sử dụng để tái hợp các gói tin. Trên IDS, trước khi áp dụng bất kì luật nào, phải tái hợp các gói tin lại để tìm ra các dấu hiệu. Bộ phận xử lí trước trong Snort có thể tái hợp các gói tin, giải mã HTTP URI, ráp lại các dòng TCP, v.v...Những chức năng này rất quan trọng trong hệ thống phát hiện xâm nhập Dectection Engine (Bộ phận phát hiện): Đây là phần quan trọng nhất của Snort. Trách nhiệm của nó là phát hiện có sự xâm nhập tồn tại trong gói tin hay không. Bộ phận phát hiện sử dụng các luật của Snort cho mục đích này. Nếu một gói tin giống với bất kì lậut nào, một hành động tương ứng sẽ được thực hiện. Đây là bộ phận then chốt về thời gian thực thi của Snort. Dựa vào bộ máy mạnh như thế nào và bao nhiêu luật định nghĩa mà nó có thể tốn những khoảng thời gian khác nhau đối với các gói tin khác nhau. Nếu lưu lượng trên mạng là quá lớn khi Snort đang hoạt động trong chế độ NIDS, có thể mất một vài gói tin và có thể thời gian đáp ứng không chính xác. Lưu lượng trên bộ phận phát hiện phụ thuộc vào các yếu tố sau:
Bộ phận phát hiện hoạt động theo những cách khác nhau ở các phiên bản khác nhau của Snort. Trong tất cả phiên bản 1.x của Snort, bộ phận phát hiện dừng việc xử lí gói tin khi phù hợp với một luật. Dựa vào luật, bộ phận phát hiện sẽ có các hành động tương ứng. Điều này có nghĩa là nếu một gói tin phù hợp với nhiều luật, chỉ có luật đầu tiên được áp dụng mà không xem xét đến các luật còn lại. Điều này làm nảy sinh một vấn đề. Một luật có độ ưu tiên thấp sẽ tạo ra một cảnh báo có độ ưu tiên thấp, nếu một luật có độ ưu tiên cao bị xếp sau trong chuỗi luật. Vấn đề này được giải quyết trong Snort phiên bản 2, khi mà tất cả các luật được so sánh trên một gói tin trước khi tạo ra một cảnh báo. Sau khi so sánh tất cả các luật, luật có độ ưu tiên cao nhất sẽ được chọn để tạo cảnh báo. Vì bộ phận phát hiện trong phiên bản 2 đã được viết lại hoàn toàn nên nó nhanh hơn rất nhiều so với các phiên bản trước đây. Logging và Alerting System (Hệ thống ghi và cảnh báo) Phụ thuộc vào Dectection Engine phát hiện tìm thấy trong gói tin, gói tin có thể được sử dụng để ghi lại các hành vi hoặc tạo ra một cảnh báo. Các thông tin ghi lại được giữ trong các file text đơn giản hoặc các dạng khác. Output Modules (Bộ phân đầu ra) Module đầu ra hoặc plug-in có thể hoạt động theo nhiều cách phụ thuộc vào việc muốn lưu các output được tạo ra bằng hệ thống ghi và tạo cảnh báo như thế nào.
Tại sao cần Snort trong khi nó có vẻ giống các phần mềm khác như tcpdump cũng sniff packet và có thể đọc từ định dạng của libpcap. Sau đây là những lý do chứng tỏ Snort có nhiều điểm tốt trong giải pháp sniffing và phát hiện xâm nhập:
Snort có 3 chế độ hoạt động cơ bản: Cod
Snort là một Sniffer: Các công cụ sniffer mạng như tcpdump, ethereal, và Tethereal có đầy đủ các đặc tính và phân tích gói tin một cách xuất sắc nó theo dõi lượng mạng trên bộ cảm biến Snort. Trong trường hợp này, sử dụng Snort như là một sniffer là khả thi. Kết quả xuất của chế độ Snort sniffer hơi khác so với các sniffer khác. Nó rất dễ để đọc và có thể thấy thích khả năng bắt giữ gói tin nhanh của nó. Một đặc tính hay của chế độ này là việc tóm tắt lưu lượng mạng khi kết thúc việc bắt giữ gói tin. Thỉnh thoảng, nó có thể là một công cụ gỡ dối hữu dụng cho nhà quản trị. Bật chế độ sniffer cho snort bằng cờ -v: Code: #snort –v Running in packet dump mode Log directory = /var/log/Snort Initializing Network Interface eth0 --== Initializing Snort ==-- Initializing Output Plugins! Decoding Ethernet on interface eth0 --== Initialization Complete ==-- -*> Snort! <*- Version 2.1.x (Build 72) …… =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= 06/24-11:19:34.482799 64.147.136.1 -> 224.0.0.10 EIGRP TTL:2 TOS:0xC0 ID:0 IpLen:20 DgmLen:60 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= ……
Snort analyzed 38 out of 38 packets, dropping 0(0.000%) packets Breakdown by protocol: Action Stats: TCP: 1 (2.632%) ALERTS: 0 UDP: 0 (0.000%) LOGGED: 0 ICMP: 0 (0.000%) PASSED: 0 ARP: 0 (0.000%) EAPOL: 0 (0.000%) IPv6: 0 (0.000%) IPX: 0 (0.000%) OTHER: 37 (97.368%) DISCARD: 0 (0.000%) =============================================== Wireless Stats: Breakdown by type: Management Packets: 0 (0.000%) Control Packets: 0 (0.000%) Data Packets: 0 (0.000%) =============================================== Fragmentation Stats: Fragmented IP Packets: 0 (0.000%) Fragment Trackers: 0 Rebuilt IP Packets: 0 Frag elements used: 0 Discarded(incomplete): 0 Discarded(timeout): 0 Frag2 memory faults: 0 =============================================== TCP Stream Reassembly Stats: TCP Packets Used: 0 (0.000%) Stream Trackers: 0 Stream flushes: 0 Segments used: 0 Stream4 Memory Faults: 0 =============================================== Trong lúc khởi động, Snort hiển thị chế độ, thư mục ghi log, và các giao diện mà nó đang lắng nghe. Khi việc khởi động hoàn tất, Snort bắt đầu xuất các gói tin ra màn hình. Kết quả xuất này khá cơ bản : nó chỉ hiển thị các header IP,TCP/UDP/ICMP và một số cái khác. Để thoát chế độ sniffer, sử dụng Ctrl-C. Snort thoát bằng cách tạo ra một bản tóm tắt các gói tin được bắt giữ, bao gồm các giao thức, thống kê phân mảnh và tái hợp gói tin. Để xem dữ liệu ứng dụng, sử dụng cờ -d. Tùy chọn này cung cấp các kết quả chi tiết hơn: Code:
# snort –vd =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= 06/24-11:27:35.408290 ARP who-has 64.147.136.1 tell 64.147.136.144 06/24-11:27:35.408860 64.147.136.144:50507 -> 64.147.130.2:53 UDP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:57 DF Len: 29
E8 0A 01 00 00 01 00 00 00 00 00 00 03 6E 73 31 .............ns1 03 6B 73 6C 03 63 6F 6D 00 00 01 00 01 .ksl.com..... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= 06/24-11:27:35.408838 ARP reply 64.147.136.1 is-at 0 0:BC:ED:15:E4 06/24-11:27:35.409465 64.147.130.2:53 -> 64.147.136.144:50507 UDP TTL:63 TOS:0x0 ID:0 IpLen:20 DgmLen:121 DF Len: 93 E8 0A 85 80 00 01 00 01 00 02 00 01 03 6E 73 31 .............ns1 03 6B 73 6C 03 63 6F 6D 00 00 01 00 01 C0 0C 00 .ksl.com........ 01 00 01 00 00 70 80 00 04 40 93 82 02 C0 10 00 .....p...@...... 02 00 01 00 00 70 80 00 02 C0 0C C0 10 00 02 00 .....p.......... 01 00 00 70 80 00 06 03 6E 73 32 C0 10 C0 47 00 ...p....ns2...G. 01 00 01 00 00 70 80 00 04 40 93 82 03 .....p...@... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= Dữ liệu ứng dụng có thể thấy được qua các plain text trong gói tin. Trong trường hợp này, văn bản gửi từ một server DNS được thể hiện dưới dạng plain text. Để xem được chi tiết hơn, bao gồm các header lớp liên kết dữ liệu, sử dụng cờ -e. Việc sử dụng cả hai tùy chọn –d và –e sẽ cho hiển thị hầu như tất cả các dữ liệu trong gói tin: Code:
#Snort –vde =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= 06/24-11:34:00.840645 0:8:74:F3:CC:F9 -> 0 0:BC:ED:15:E4 type:0x800 len:0x47 64.147.136.144:50507 -> 64.147.130.2:53 UDP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:57 DF Len: 29 28 BF 01 00 00 01 00 00 00 00 00 00 03 6E 73 31 (............ns1 03 6B 73 6C 03 63 6F 6D 00 00 01 00 01 .ksl.com..... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= 06/24-11:34:00.841157 0 0:BC:ED:15:E4 -> 0:8:74:F3:CC:F9 type:0x800 len:0x87 64.147.130.2:53 -> 64.147.136.144:50507 UDP TTL:63 TOS:0x0 ID:0 IpLen:20 DgmLen:121 DF Len: 93 28 BF 85 80 00 01 00 01 00 02 00 01 03 6E 73 31 (............ns1 03 6B 73 6C 03 63 6F 6D 00 00 01 00 01 C0 0C 00 .ksl.com........ 01 00 01 00 00 70 80 00 04 40 93 82 02 C0 10 00 .....p...@...... 02 00 01 00 00 70 80 00 02 C0 0C C0 10 00 02 00 .....p.......... 01 00 00 70 80 00 06 03 6E 73 32 C0 10 C0 47 00 ...p....ns2...G. 01 00 01 00 00 70 80 00 04 40 93 82 03 .....p...@... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= Các chuỗi thập lục phân hiển thị nhiều dữ liệu hơn. Có địa chỉ MAC và địa chỉ IP. Khi thực hiện kiểm tra trên một mạng hoặc bắt giữ dữ liệu bằng Snort, việc bật –vde cung cấp nhiều thông tin nhất. Để lưu lại trong logfile thay vì xuất ra console, sử dụng: Code:
# snort -dve > ttooip.log. Tóm lại, đây là các tùy chọn có thể sử dụng với chế độ sniffer của Snort. Những tùy chọn này có thể chạy độc lập hoặc kết hợp với cái khác Snort là một Packet Logger: Bước tiếp theo sau khi sniffing các gói tin là ghi log chúng. Việc ghi log chỉ đơn giản bằng cách thêm tùy chọn –l, theo sau đó là thư mục muốn lưu trữ các log. Thư mục mặc định trong Snort là /var/log/snort. Nếu xác định một thư mục không tồn tại thì Snort sẽ báo một thông điệp lỗi. Có thể sử dụng các tùy chọn –d, -a và –e để điều khiển số lượng thông tin sẽ được ghi log cho mỗi gói tin. Trong ví dụ sau đây, thư mục log được thiết lập là /usr/local/log/snort, và các logfile bao gồm các payload gói tin: Code: # snort -1/usr/local/log/snort –d Khi chạy trong chế độ này, Snort thu thập mỗi gói tin nó thấy và lưu chúng trong thư mục log theo kiểu phân cấp. Nói cách khác, một thư mục mới được tạo ra cho mỗi địa chỉ được bắt giữ và dữ liệu liên quan đến địa chỉ này được lưu trong thư mục đó. Snort lưu các gói tin thành các file ASCII, với tên file được tạo ra từ giao thức và số cổng. Cách tổ chức này làm cho nhà quản trị có thể dễ dàng thấy được ai đang kết nối với mạng, số cổng và giao thức họ đang sử dụng (sử dụng ls –R để liệt kê thư mục log). Hãy nhớ xác định biến mạng của cơ quan hay tổ chức (trong file cấu hình hoặc sử dụng -h ) để xác định chỉ ghi log cho mạng của cơ quan. Cách tổ chức phân cấp này hữu dụng khi một số giới hạn các host được quan tâm hoặc muốn thoáng qua các địa chỉ IP của các host được bắt giữ. Tuy nhiên, thư mục log có thể ngày càng nhiều vì sự gia tăng thư mục và các file. Nếu ghi log tất cả lưu lượng trên một mạng lớn thì có thể sẽ bị tràn index Unix giới hạn tổng số file trong một file hệ thống) trước khi bị tràn bộ nhớ. Nếu một người nào đó thực hiện việc quét mạng và ánh xạ tất cả 65536 cổng TCP cũng như 65536 cổng UDP, sẽ đột ngột có hơn 131000 file trong một thư mục đơn. Sự bùng nổ file này có thể là một thử thách lớn cho bất kì một máy nào, và rất dễ trở thành cách tấn công DOS. Việc ghi log theo kiểu nhị phân có thể đọc được bởi Snort, tcpdump hoặc ethereal. Cách này làm tăng tốc độ và khả năng vận chuyển của việc bắt giữ gói tin. Hầu hết các hệ thống có thể bắt giữ và ghi log với tốc độ 100 Mbps mà không có vấn đề gì. Để ghi log các gói tin theo kiểu nhị phân, sử dụng –b switch. Ví dụ: Code: #snort-b -l /usr/local/log/snort/ttooip.log Khi đã thực hiện việc bắt giữ gói tin, có thể đọc lại các file vừa tạo ra bằng khóa –r. Kết quả giống như sniffer của Snort. Lưu ý rằng –r không thể sử dụng với –C. Code:
# snort -r /usr/local/log/snort/ttooip.log Ở chế độ này, Snort không giới hạn việc đọc dữ liệu nhị phân được lưu trữ trong chế độ sniffer. Snort là một NIDS: Snort là một công cụ phát hiện xâm nhập rất tốt. Khi được sử dụng như là một NIDS, Snort cung cấp khả năng phát hiện xâm nhập gần như là thời gian thực. Chúng ta sẽ xem rất nhiều cách mà Snort có thể được sử dụng như là một NIDS và tất cả các tùy chọn cấu hình có thể. Trong chế độ cảnh báo, Snort cần một file cấu hình (thật ra, chỉ cần xác định vị trí của file snort.conf là đặt Snort trong chế độ này). Vị trí mặc định của file này là /etc/snort.conf. Nếu muốn đặt ở một vị trí khác, phải sử dụng khóa –c kèm với vị trí đặt file. Các cảnh báo được đặt trong file alert trong thư mục log (mặc định là (/var/log/snort). Snort sẽ thoát ra với với một lỗi nếu file cấu hình hoặc thư mục log không tồn tại. Các cài đặt mặc định cho hầu như tất cả các mục trong file này là khá tốt (mặc dù sẽ có các cảnh báo nhầm). Biến duy nhất chúng ta mới thiết lập là biến RULE_PATH, chỉ cho Snort nơi của các file luật. File cảnh báo nằm trong thư mục /var/log/snort. File này chứa các cảnh báo được tạo ra khi Snort đang chạy. Các cảnh báo Snort được phân loại theo kiểu cảnh báo. Một luật Snort cũng xác định một mức độ ưu tiên cho một cảnh báo. Điều này cho phép lọc các cảnh báo có độ ưu tiên thấp.
Ở chế độ báo động ( alert ), Snort yêu cầu phải có file cấu hình, files cấu hình mặc định lưu ở thư mục /etc/Snort.conf, nếu file nằm ở chỗ khác ta phải dùng cờ -c để chỉ tới files đó. Các báo động sẽ lưu ở thư mục /var/log/Snort ( mặc định ).Snort sẽ thoát ra nếu file .conf và thư mục log không có. Ta có thể chỉ định loại báo động nào ví dụ như full, fast,none hoặc Unix sockets bằng cách thêm cờ -A vào dòng lệnh Lần đầu nhìn vào file Snort.conf ta có thể nhìn thấy nhiều dòng chú thích rất dễ hiểu với màu sắc dễ phân biệt, ví dụ như tạo các biến, set các đường dẫn RULE_PATH để chỉ Snort các files rules Code:
var RULE_PATH ../rules Thay đổi đường dẫn đầy đủ nơi chứa các rules var RULE_PATH /usr/local/share/Snort_rules/november_2005/rules Để cho Snort khởi động, sử dụng dòng lệnh: Snort -c /usr/local/share/Snort_rules/november_2005/rules/Snort.conf Nó sẽ hiển thị ra màn hình console Running in IDS mode …. No arguments to frag2 directive, setting defaults to: Fragment timeout: 60 seconds Fragment memory cap: 4194304 bytes Fragment min_ttl: 0 Fragment ttl_limit: 5 Fragment Problems: 0 Self preservation threshold: 500 Self preservation period: 90 Suspend threshold: 1000 Suspend period: 30 …… +++++++++++++++++++++++++++++++++++++++++++++++ +-----------------------[thresholding-config]---------------------------------- | memory-cap : 1048576 bytes +-----------------------[thresholding-global]---------------------------------- | none
+-----------------------[thresholding-local]----------------------------------- | gen-id=1 sig-id=2275 type=Threshold tracking=dst count=5 seconds=60 +-----------------------[suppression]------------------------------------------ Rule application order: ->activation->dynamic->alert->pass->log --== Initialization Complete ==-- -*> Snort! <*- Version 2.1.x (Build 24) By Martin Roesch (roesch@sourcefire.com, www.Snort.org) Tới đây ta có thể kết thúc dùng lệnh CTRL – C sẽ xuất hiện các bảng tóm tắt: ==================================================== Snort analyzed 3210 out of 3807 packets, dropping 597(15.682%) packets Breakdown by protocol: Action Stats: TCP: 2602 (68.348%) ALERTS: 6 UDP: 2 (0.053%) LOGGED: 6 ICMP: 8 (0.210%) PASSED: 0 ARP: 0 (0.000%) EAPOL: 0 (0.000%) IPv6: 0 (0.000%) IPX: 0 (0.000%) OTHER: 0 (0.000%) DISCARD: 0 (0.000%) =============================================== Wireless Stats: Breakdown by type: Management Packets: 0 (0.000%) Control Packets: 0 (0.000%) Data Packets: 0 (0.000%) =============================================== Fragmentation Stats: Fragmented IP Packets: 0 (0.000%) Fragment Trackers: 0 Rebuilt IP Packets: 0 Frag elements used: 0 Discarded(incomplete): 0 Discarded(timeout): 0 Frag2 memory faults: 0 =============================================== TCP Stream Reassembly Stats: TCP Packets Used: 2602 (68.348%) Stream Trackers: 1559 Stream flushes: 0 Segments used: 0 Stream4 Memory Faults: 0 =============================================== Final Flow Statistics ,----[ FLOWCACHE STATS ]---------- Memcap: 10485760 Overhead Bytes 16400 used(%2.287951)/blocks (239909/1564) Overhead blocks: 1 Could Hold: (73326) IPV4 count: 1563 frees: 0 low_time: 1080162455, high_time: 1080162458, diff: 0h:00:03s finds: 2612 reversed: 1022(%39.127106) find_sucess: 1049 find_fail: 1563 percent_success: (%40.160796) new_flows: 1563 Protocol: 1 (%0.306279) finds: 8 reversed: 3(%37.500000) find_sucess: 5 find_fail: 3 percent_success: (%62.500000) new_flows: 3 Protocol: 6 (%99.617152) finds: 2602 reversed: 1018(%39.123751) find_sucess: 1043 find_fail: 1559 percent_success: (%40.084550) new_flows: 1559 Protocol: 17 (%0.076570) finds: 2 reversed: 1(%50.000000) find_sucess: 1 find_fail: 1 percent_success: (%50.000000) new_flows: 1 Snort exiting Bây giờ đã có 1 file báo động trong thư mục /var/log/Snort. File sẽ bao gồm các báo động từ Snort khi đang chạy ( trong bài này có sử dụng nmap SYN scan để cho Snort báo động ) Code:
[**] [1:469:1] ICMP PING NMAP [**] [Classification: Attempted Information Leak] [Priority: 2] 03/24-15:07:35.187504 192.168.1.2 -> 192.168.1.105 ICMP TTL:51 TOS:0x0 ID:23210 IpLen:20 DgmLen:28 Type:8 Code:0 ID:1290 Seq:0 ECHO [Xref => http://www.whitehats.com/info/IDS162] [**] [1:618:5] SCAN Squid Proxy attempt [**] [Classification: Attempted Information Leak] [Priority: 2] 03/24-15:07:35.583826 192.168.1.2:49641 -> 192.168.1.105:3128 TCP TTL:44 TOS:0x0 ID:56810 IpLen:20 DgmLen:40 ******S* Seq: 0x4EB5A7C6 Ack: 0x0 Win: 0x400 TcpLen: 20 [**] [1:1421:3] SNMP AgentX/tcp request [**] [Classification: Attempted Information Leak] [Priority: 2] 03/24-15:07:35.589463 192.168.1.2:49641 -> 192.168.1.105:705 TCP TTL:44 TOS:0x0 ID:54050 IpLen:20 DgmLen:40 ******S* Seq: 0x4EB5A7C6 Ack: 0x0 Win: 0x400 TcpLen: 20 [Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0013][Xref => http:// cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0012] [**] [1:615:5] SCAN SOCKS Proxy attempt [**] [Classification: Attempted Information Leak] [Priority: 2] 03/24-15:07:35.674332 192.168.1.2:49641 -> 192.168.1.105:1080 TCP TTL:44 TOS:0x0 ID:9794 IpLen:20 DgmLen:40 ******S* Seq: 0x4EB5A7C6 Ack: 0x0 Win: 0x400 TcpLen: 20 [Xref => http://help.undernet.org/proxyscan/] [**] [1:1420:3] SNMP trap tcp [**] [Classification: Attempted Information Leak] [Priority: 2] 03/24-15:07:35.696925 192.168.1.2:49641 -> 192.168.1.105:162 TCP TTL:44 TOS:0x0 ID:41259 IpLen:20 DgmLen:40 ******S* Seq: 0x4EB5A7C6 Ack: 0x0 Win: 0x400 TcpLen: 20 [Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0013][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0012] [**] [1:1418:3] SNMP request tcp [**] [Classification: Attempted Information Leak] [Priority: 2] 03/24-15:07:35.827022 192.168.1.2:49641 -> 192.168.1.105:161 TCP TTL:44 TOS:0x0 ID:37753 IpLen:20 DgmLen:40 ******S* Seq: 0x4EB5A7C6 Ack: 0x0 Win: 0x400 TcpLen: 20 [Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0013][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0012] Ví dụ phân tích một báo động của Snort Đây là tên của báo động: [**] [1:1418:3] SNMP request tcp [**] Snort sẽ chia ra nhiều lớp cho từng loại báo động , ví dụ cái này là thuộc dang đang cố gắng đánh lừa thông tin “Attempted Information Leak” và mức độ ưu tiên của từng báo động [Classification: Attempted Information Leak] [Priority: 2] Đây là phần header và thông tin của packet là nguyên nhân gây ra báo đông: 03/24-15:07:35.827022 192.168.1.2:49641 -> 192.168.1.105:161 TCP TTL:44 TOS:0x0 ID:37753 IpLen:20 DgmLen:40 ******S* Seq: 0x4EB5A7C6 Ack: 0x0 Win: 0x400 TcpLen: 20 Snort sẽ báo động bao gồm các đường dẫn tới mô tả các rules gây ra báo động [Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0013][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0012]
File Snort.conf điều khiển mọi thứ mà Snort thấy được, làm cách nào nó có thể chống lại các cuộc tấn công, những rules nào được sử dụng khi thấy nghi ngờ, và làm cách nào nó có thể phát hiện ra được những dấu hiệu nguy hiểm tìm tàng mặc dù nó không có các tín hiệu nhận dạng cụ thể để so sánh. Để hiểu và cấu hình nó thành công khi phát triển Snort thành 1 công cụ IDS thật sự. Tôi sẽ trình bày cụ thể những kinh nghiệm hiểu biết về Snort sau đây. Để tìm hiểu nó 1 cách nhanh nhất và dễ dàng nên mở sẵn nó ra trên máy tính hoặc in nó ra giấy theo dõi cho dễ dàng. File conf được chia ra thành nhiều đoạn và có chú thích rất rõ ràng cho từng đoạn, những nội dung chính của nó gồm:
Các biến trong file conf được tạo ra thường để dễ dàng hơn trong việc theo dõi các địa chỉ IP, hoặc các port TCP, UDP được chỉ định mà nó đang lắng nghe. Mặc đinh các biến thường để giá trị là any chỉ tất cả các địa chỉ IP mà nó nhận được, nó cũng có thể là nguyên nhân gây ra nhiều báo động sai Var HOME_NET 192.168.1.1 Hoặc khi muốn chỉ định nhiều địa chỉ cùng lúc, phải có dấu ngoặc vuông để chỉ định cho cả nhóm: Var HOME_NET [192.168.1.1,192.168.14.1,10.0.0.2] Ta cũng có cách khác để chỉ định luôn cả mạng: Var HOME_NET 10.10.10.0/24 Hoặc cũng có thể gộp cả 2 cách trên vào chung 1 nhóm: Var HOME_NET [192.168.1.1,10.10.10.0/24,172.168.1.5/16,187.1.1.1/19] Nếu muốn chỉ định không dùng các ip này ngoại trừ … thì dùng thêm dấu “than” ! nghĩa là NOT Var EXTERNAL_NET !$HOME_NET Để chỉ định cho các port cũng làm tương tự ví dụng Var ORACLE_PORTS 1521 Hoặc các port không phải là port 80 Var SHELLCODE_PORTS !80
HOME_NET: chỉ định địa chỉ mạng của mình đang bảo vệ EXTERNAL_NET: các mạng bên ngoài. Các biến để chỉ định các server đang chạy các service phục vụ cho hệ thống DNS_SERVERS SMTP_SERVERS HTTP_SERVERS SQL_SERVERS TELNET_SERVERS SNMP_SERVERS …… Các port mặc định các biến khác: HTTP_PORTS SHELLCODE_PORTS ORACLE_PORTS AIM_SERVERS RULES_PATH
Snort sẽ giải mã cấu trúc các packet và so sánh cấu trúc theo những dấu hiệu đã được trang bị. Nếu packet có kích thước lạ, nhìêu cấu hình lạ không bình thường, Snort sẽ báo động. Nếu không báo động thì sẽ có 1 luợng lớn lỗi báo động sai. Ta có thể tắt chức năng này. Mặc định tất cả báo động đều bật. Để tắt 1 loại báo động cụ thể nào đó, ta nên để dấu thăng # vào trước dòng lệnh thành dòng comment ghi chú # config disable_decode_alerts # config disable_tcpopt_experimental_alerts # config disable_tcpopt_obsolete_alerts # config disable_tcpopt_ttcp_alerts # config disable_tcpopt_alerts # config disable_ipopt_alerts Ta cũng có thể thêm vào nhiều dòng lênh của Snort trong phần này của file Snort.conf. Cấu Hình Option Của Snort.conf
Tiền xử lý phục vụ cho nhiều mục đích. Nó “bình thường hoá” traffic cho các services, để chắc chắn rằng dữ liệu trong các packet Snort đang theo dõi sẽ có cơ hội tốt nhất để so sánh với các tín hiệu nhận dạng (signatures ) mà Snort đuợc trang bị. Chức năng khác của quá trình tiền xử lý là tự phòng thủ. Các cuộc tấn công được phát triển để lẩn tránh hoặc làm tràn ngập NIDS sensor, vì thế attacker có thể lợi dụng làm những công việc mình cần. Chức năng frag2 và stream4 tiền xử lý có chức năng chính để chống lại các phương pháp này. Và chức năng cuối cùng cũng là chức năng quan trọng nhất là làm cho Snort có thêm chút thông minh để phát hiện ra các cuộc tấn công mang phong cách không bình thuờng mà Snort không được trang bị trong rules. 
Hình 3.22. Bảng mô hình các gói tin đi vào ở mode preprocessor FLOW Flow preprocessor có một module là flow-portscan. Flow theo dõi tất cả traffic và giữ các track kết nối giữa hệ thống và port lạ, khi có 1 flow lạ mới thông tin sẽ chuyển qua hash (làm cho các track nhỏ hơn , nhanh hơn trong tracking các địa chỉ IP và PORTS) được lưu trữ trong bảng bộ nhớ dành sẵn. Các option cho flow preprocessor Memcap Chỉ định mức tối đa cho bộ nhớ khi tracking, mặc định là 10MB, thông số này để điều khỉên bộ nhớ của Snort khi cần Rows Chỉ định số dòng trên bảng hash, mặc định là 4,099 dòng Stats_interval Có thể chuyển tình trạng của flow preprocessor qua stdout, giá trị là một số nguyên đại diện cho thời gian tính bằng giây (s) , rất hữu ích khi dùng cho mục đích test Hash Phương pháp sử dụng hash thông tin vào bảng, có thể set hash có giá trị là 1 (byte) hoặc 2 (số nguyên ) dùng hash 2 nhanh hơn Đây là cấu hình khuyên của các nhà phát triển dùng cho flow: Preprocessor flow: stats_interval 0 hash 2 Frag2 Khi một packet đi từ mạng này qua mạng khác, nó thường cần phân mảnh thành các packet nhỏ hơn, bởi vì mạng thứ 2 sẽ giới hạn kích thuớc của packet và tất nhiên nhỏ hơn mạng đầu tiên. Và tất cả các packet nhỏ sẽ đuợc sắp xếp lại khi đến nơi. Một trong những phương pháp của attacker là dùng các packet nhỏ để lừa firewall hoặc IDS. Ví dụ: rules của Snort đang dò tìm chuỗi /users.pwd trong các section của packet, một attacker có thể tạo ra một dãy các packet rất nhỏ chỉ chứa vài byte trong data của packet, mảnh đầu tiên có thể chứa /user , và cái packet phân mảnh thứ 2 có thể chứa s.pwd, các packet này sẽ không kích hoạt báo động bởi vì nó không giống các rules nào cả, frag2 preprocessor sẽ sắp xếp sự phân mảnh này vào chung và nó sẽ dễ dàng phát hiện sự ẩn dấu đó. Hoặc một ví dụ khác các attacker có thể đưa ra 1 dung lượng quá lớn các packet đã phân mảnh nó sẽ chiếm dung lưonng của hệ thống và làm overload có thể Snort sẽ từ chối tất cả và ảnh hưởng tới các packet không liên quan, các tools mà attacker thường dùng là Fragroute, frag2 có các options để chống lại các dạng tấn công này.
Thiết lập khuyến cáo nên dùng: Preprocessor frag2 Stream4 Stream4 được thiết kế để bảo vệ Snort từ 1 dạng tấn công mới của attacker tới các NIDS sensor bằng cách gửi tràn ngập các packet chứa các chuỗi dữ liệu giống như trong rules để kích các báo động, cũng có khá nhiều tools dùng cho việc này nhưng Snort của có cách chống lại. Stream4 có 2 nhiệm vụ chính: sateful inspection ( kiểm tra tính nguyên ven ), awareness and session reassembly ( nhận biết và sắp xếp các session ) Các option của stream4
Đây là câu lệnh khuyến cáo nên dùng Code:
preprocessor stream4: detect scans, disable_evasion_alerts, timeout 60, ttl_limit 10 Stream4_reassemble Snort phản hồi những chuỗi kí tự nó đọc đuợc trong các gói tin đi qua nếu nó trùng với các kí tự nhận dạng trong signatures. Nếu attacker có thể phân chia các kí tự thành nhiều gói tin để tránh báo động của Snort, stream4_reassemble đóng vài trò sắp xếp lại các traffic giữa 2 hệ thống đàm thoại ( conversation ) của network, gia tăng khả năng match các signatures Các conversation network thường là các chương trình dùng bằng command line như Telnet, Ftp, Smtp có thể là các nguyên nhân nội dung của các packet lọt qua được hệ thống. Reassemble các traffic các services này là cần thiết để ngăn chặn các báo động lầm hoặc bỏ sót. Một kĩ thuật khác của attacker là nhúng các gói tin với các kí tự gây lỗi, reassemble vẫn có thể phát hiện được Các option của reassemble:
Câu lệnh khuyên dùng: Preprocessor stream4_reassemble: both Tiền xử lý các http inspect Có nhiều cách thông tin có thể định dạng sang các http session và cũng có nhiều loại khác nhau biểu diễn các thông tin như là các http session như multimedia, .xml, .HTML, .asp, .php, .java,….và kết quả Snort phải “massage” nội dung của các HTTP conversation để định dạng lại data phục vụ cho quá trình phát hiện tốt nhất. Có 2 kiểu cấu hình http_inspect là global và server. Global ảnh huởng trực tiếp tới http traffic ,cấu hình Server chứa các phần setting cho 1 máy server và các group servers như vậy, cái này rất thường dùng để cấu hình cho web server dùng apache hoặc IIS http_inspect (global) Có 3 option trong phần này dùng để config http traffic: Code:
iis_unicode_map Code: detect_anomalous_servers Sẽ báo động khi gặp các ports lạ không tiêu chuẩn. thường không bật chế độ này proxy_alert Nếu sử dụng proxy server cho các internet user, bật chức năng này để giám sát các user không dùng proxy để kết nối internet Đề nghị setting cho mode này: preprocessor http_inspect: global iis_unicode_map unicode.map 1252 http_inspect_server Có thể dùng option này cho servers bất kì hoặc các servers trong môi truờng làm việc của mình. hầu hết các administrator đều dùng 1 server riêng dùng cho IIS và cái khác dùng Apache servers. Trong phần trình bày này sẽ có ví dụ cụ thể. Có 2 kiều cấu hình cho http_inspetct_server là “default” và “by IP address”, kiểu “default” chỉ cấu hình cho tất cả web traffic không liên quan gì đến IP address, còn kiểu “IP address” chỉ cấu hình cho các IP đựơc chỉ định hoặc 1 dãy các IP. Có các option là: Default hoặc < IP address > Như đã trình bày ở trên Profile Có thể dùng apache hoặc chỉ dùng cho iis ta cũng có thể dùng all cho cả hai. Các bảng sau sẽ trình bày cụ thể của profile khi dùng từng loại
Option Setting flow_depth 300 chunk_encoding Báo động khi các chunks lớn hơn 500,000 bytes lis_unicode_map Map sử dụng cho mode globle ascii No non_refc_char On multi_slash No directory No apache_whitespace Yes double_decode Yes j_encode Yes bare_byte Yes lis_unicode Yes lis_backslash No lis_delimiter Yes Bảng setting cho profile "apache" Option Setting flow_depth 300 chunk_encoding Báo động khi các chunks lớn hơn 500,000 bytes ascii No non_rfc_char On multi_slash No directory No apache_whitespace Yes Bảng setting cho profile "iis" Option Setting flow_depth 300 lis_unicode_map Map sử dụng cho mode globle ascii No multi_slash No directory No double-decode Yes u_encode Yes bare_byte Yes lis_unicode Yes lis_backslash No lis_delimiter Yes apache_whitespace Yes utf_8 No non_strict On
Code:
Preprocessor http_inspect_server: server default profile all ports {80 8080 } Đây là phần cấu hình cho IIS server http_inspect_server : Preprocessor http_inspect_server: server 10.10.10.33 profile iis ports {80 8080} Còn đây là cấu hình điển hình cho Apache server: Preprocessor http_inspect_server 10.1.1.125 profile apache ports { 80 8080 }
RPC’s traffic có thể phân chia ra nhiều packet và mã hoá theo nhiều kiểu khác nhau. Rpc_decode preprocessor sẽ bình thường hoá các traffic này cũng chỉ mục đích giúp nhận diện tốt hơn trong singnatures list. List của các ports mà RPC services đang chạy đuợc cung cấp trong các dòng cấu hình. Ở đây có 4 options cho rpc_decode Alert_fragments: Báo động khi có fragmented RPC traffic No_alert_multiple_requests: Không báo động khi nhiều hơn một RPC request đuợc chứa trong một packet. No_alert_large_fragments: RPC fragments có thể lớn hơn size của các fragment hiện hành. Nếu bạn tìm lỗi xác thực, ta phải dùng chức năng này để disable No_alert_incomplete: RPC messages có thể rất lớn, có khi nó lớn hơn có MTU của mạng nó đang đi qua, nó có thể gây nhiều lỗi cho các RPC network services. Có thể tắt chức năng này để phát hiện lỗi Đây là đề nghị config rpc_decode: Preprocessor rpc_decode: 111 32771 1024 Bo Bo- Back orifice con virust nổi tiếng của các hacker trong các năm qua, dùng để điều khiển từ xa các client bị nhiễm nó, Snort có option để ngăn chặn điều này và phát hiện khá dễ dàng chỉ bằng một dòng lệnh ngắn gọn. Preprocessor bo
Dùng chức năng này để bình thuờng hoá các kí tự ,chuổi không tiêu chuẩn, lạ của traffic FTP và telnet cũng đơn giản dùng 1 câu lệnh đơn giản. Code: Preprocessor telnet_decode Flow-portscan Flow-portscan thay thế portscan2 nó nhiều chức năng hơn và mạnh hơn. Có 3 components cơ bản cho flow-portscan Scoreboards Nó phát hiện đuợc 2 loại khác nhau của host , talker và scanner. Talker là tất cả các host đang active trong mạng. còn scanner là host đang connection tới 1 port trên server ở trong mạng Uniqueness tracker: Theo dõi nếu có duy nhất 1 kết nối Server statistics tracker: Sử dụng để theo dõi thời gian của các service trên các server nhằm theo dõi các kết nối Để phát hiện các attacker scan port rất khó vì hacker có thể dùng nhiều cách khác nhau: Sau đây là các option ta có thể dùng để nâng cao hiệu quả của flow-portscan Code:
scoreboard-memcap-talker < bytes> scoreboard-rows-talker < count> scoreboard-rows-scanner < count> scoreboard-memcap-scanner < bytes> scanner-fixed-threshold < integer> scanner-sliding-threshold < integer> scanner-fixed-window < integer> scanner-sliding-window < integer> scanner-sliding-scale-factor < float> talker-fixed-threshold < integer> talker-sliding-threshold < integer> talker-fixed-window < integer> talker-sliding-window < integer> talker-sliding-scale-factor < float> unique-memcap < bytes> unique-rows < integer> server-memcap < bytes> server-rows < integer> server-watchnet < ip list in Snort notation> src-ignore-net < ip list in Snort notation> dst-ignore-net < ip list in Snort notation> tcp-penalties server-learning-time < seconds> server-ignore-limit < hit count> server-scanner-limit < hit count> alert-mode output-mode base-score < integer> dumpall <1> Đây là dòng cấu hình mẫu cho flow-portscan Code: preprocessor flow-portscan: server-watchnet [10.10.10.0/24,10.10.20.0/24] Arpspoof Arpspoof được thiết kế cho preprocessor dể detech các hoạt động spoof arp bất hợp pháp trên local nétwork. Các hacker dùng các tools man-in-the-middle attacks như ettercap hoặc arpspoof để nghe trộm giữa các máy trong mạng nội bộ. để cấu hình administrator phải biết địa chỉ MAC của card mạng, điều này thì quá dễ dàng: Sau đây là cấu hình đề nghị: Code:
# preprocessor arpspoof # preprocessor arpspoof_detect_host: 192.168.1.1 F0:AB:GH:10:12:53 Perfmonitor Một trong những khả năng rất hay của Snort là monitor tình trạng hiện tại của hể điều hành các thông số nó thể hiện nêu lên nhiều ý nghĩa mà dựa vào đó ta có thể đoán được nhiều đìều và đưa ra nhiều biện pháp điều chỉnh theo ý muốn, các thông số Snort monitor Code: Packets received Packets dropped Percentage of packets dropped Packets Received Kpackets per second Average bytes per packets Mbits per second (wire) Mbits per second (rebuilt) (Mbits trung bình Snort nhúng vào sau khi rebuil các packet) Mbits per second (total) Pattern-matching percent (Phần trăm dữ liệu average percent of data received that Snort processes in pattern matching) CPU usage (user time, system time, idle time) Alerts per second SYN packets per second SYN/ACK packet per second New sessions per second Deleted sessions per second Total sessions Max sessions during time interval Stream flushes per second Stream faults per second Stream timeouts Frag completes per second Frag inserts per second Frag deletes per second Frag flushes per second Frag timeouts Frag faults Khi dùng thêm từ “flow” , nó sẽ hiển thị tình trạng các traffic của protocal mà Snort dang soi, dùng “event” Snort sẽ mở chức năng reporting và hiển thị trạng thái số lượng signatures match, dùng từ “max” sẽ kích hoạt Snort hoạt động hết sức để nâng cao hiệu quả, dùng tư “pktcnt” điều chỉnh số lượng packets đang thực thi trước khi check thời gian sample mặc định set là 10,000. Ví dụ config và bật chức năng perfmonitor preprocessor: Code:
Preprocessor perfmonitor : time 30 events flow file stats.profile max console pktcnt 10000 Preprocessor perfmonitor: time 30 file /var/tmp/Snortstat pktcnt 10000
Snort có thể output vào các file log hoặc output ra console, nhiều administrator thích dùng các phần mềm của hãng thứ 3 (third party ) để tăng thêm chức năng giám sát của Snort, các phần mềm data database đều có thể dùng được, lưu ý trước khi cài đặt Snort muốn dùng database nào thì cần chỉ rõ khi cài đặt ví dùng dùng MySQL , khi biên dịch source thêm vào - -mysql Code:
./configure - - mysql Alert_syslog Output cấu hình theo kiểu Code: Output alert_syslog : Các option sau là một trong nhưng syslog chuẩn và syslog mặc định là LOG_AUTH; LOG_AUTH; LOG_AUTHPRIV; LOG_DAEMON; LOG_LOCAL0; LOG_LOCAL1; LOG_LOCAL2; LOG_LOCAL3; LOG_LOCAL4; LOG_LOCAL5; LOG_LOCAL6; LOG_LOCAL7; LOG_USER Các option ưu tiên sau cũng là các syslog ưu tiên chuẩn, mặc định là LOG_ALERT; LOG_EMERG; LOG_ALERT; LOG_CRIT; LOG_ERR; LOG_WARNING; LOG_NOTICE; LOG_INFO; LOG_DEBUG Đây là câu cấu hình mẫu cho alert_syslog Code:
tput alert_syslog: LOG_AUTH LOG_ALERT và câu lệnh này dành cho bản windows của Snort nhìn vào cũng dễ hiểu Code: output alert_syslog: host=192.168.1.100:80 LOG_AUTH LOG_ALERT Log_tcpdump Log này sẽ định dạng sang dạng log_tcpdump, do có rất nhiều phần mềm có thể đọc được dạng log này, khi log sẽ có timestamp đính vào file name Code: output log_tcpdump /var/log/Snort/tcpdump.out Database Khi log vào database , một khối luơng lớn thông tin của Snort sẽ được lưu trữ như các báo động (alert) , các host liên quan, các packet gây ra báo động, và ta dễ dàng log các báo động thật sự và các báo động lỗi, sai nhanh và nhiều hơn Đôi khi log vào database cũng quá tải gây ra hiện tượng thắt cổ chai dẫn đến 1 alert chỉ có thể được log trong một thời gian. Và phương pháp cấu hình Snort làm sao hợp lý nhất là các kinh nghiệm của các admin sau này ví dụ có thể dùng tuning hoặc thresholding để tạo hiệu quả hơn. Cấu trúc của câu lệnh output ra database Code: output database: Câu lệnh trên nhìn vào ta có thể hiểu ngay được ý nghĩa của nó, còn bao gồm các phần sau : Host: Địa chỉ IP của database server Port: Port của database đang lắng nghe dbname= user: username Snort sử dụng để log trong database password: Mật khẩu username Snort sử dụng để log trong database sensor_name: Tên của sensor cấu hình, có thể thểm -I trong command line sử dụng IP address thay cho tên encoding: Sử dụng mã hoá để log vào database, ví dụ kiểu hex,base64,ascii và khuyên dùng ascii detail: Có thể chỉ định details level nào log vào database, ví dụ dùng full,fast và full được khuyên dùng nhất Với các loại database cụ thể ta phải biên dịch cho đúng khi cài đặt như đã nói phần trước CODEMySQL: ./configure - -with-mysql POSTGRESQL: ./configure - -with-postresql ODBC: ./configure - -with-odbc MSSQL: Chỉ dùng cho bản windows, dùng odbc để log vào MSMSQL server ORACLE: ./configure - -with-oracle các log khác ta sẽ coi trong phần khuyến cáo của database kèm theo File Inclusion Trong file Snort.conf, câu lệnh include chỉ cho Snort đọc các file sau từ include được lưu trong filesystem của Snort sensor, giống như trong lập trình Code: $ include $RULE_PATH/bad-traffic.rules $ include $RULE_PATH/exploit.rules $ include $RULE_PATH/scan.rules Các rules trên ta có thể download trên internet, khi down về ta muốn phân nhóm hoặc chỉnh sửa,độ ưu tiên các rules ta có thể cấu hình trong file classification.config, file reference.config gồm các links tới web site với các thông tin cho tất cả các alerts, include nó rất hữu tích , nhanh gọn Code:
# include classification & priority settings include classification.config # include reference systems include reference.config Каталог: books -> luan-van-de-tai -> luan-van-de-tai-cd-dh luan-van-de-tai-cd-dh -> Thế kỷ 21, cùng với sự phát triển nh vũ bão của khoa học kỹ thuật, của công nghệ thông tin. Sự phát triển kinh tế tác động đến tất cả mọi mặt đời sống kinh tế xã hội luan-van-de-tai-cd-dh -> Phần một : Tình hình thu hút vốn đầu tư trên thị trường vốn việt nam hiện nay luan-van-de-tai-cd-dh -> TRƯỜng đẠi học cần thơ khoa công nghệ BỘ MÔN ĐIỆn tử viễn thôNG luan-van-de-tai-cd-dh -> Em xin chân thành cảm ơn! Vị Xuyên, ngày 19 tháng 5 năm 2012 sinh viêN luan-van-de-tai-cd-dh -> PHẦn I mở ĐẦu tầm quan trọng và SỰ ra đỜi của giấY luan-van-de-tai-cd-dh -> Đề tài: Tìm hiểu về vấn đề sử dụng hợp đồng mẫu trong đàm phán ký kết hợp đồng mua bán ngoại thương và thực tiễn ở Việt Nam luan-van-de-tai-cd-dh -> Đề tài phân tích thực trạng kinh doanh xuất khẩu cà phê nhân của các doanh nghiệP luan-van-de-tai-cd-dh -> Giao tiếp máy tính và thu nhận dữ liệU ĐỀ TÀI: TÌm hiểu công nghệ 4g lte luan-van-de-tai-cd-dh -> TRƯỜng đẠi học văn hóa hà NỘi khóa luận tốt nghiệP tải về 0.74 Mb. Chia sẻ với bạn bè của bạn:
|