Tài liệu Khóa luận phòng chống virus với snort

KHOA KHOA HỌC CÔNG NGHỆ NGÀNH MẠNG MÁY TÍNH LỚP VT081A BÁO CÁO ĐỀ TÀI TỐT NGHIỆP Tên sinh viên thực hiện: Giáo viên hướng dẫn: QUAN MINH TÂM LƯU THANH TRÀ Ngày nộp báo cáo: ............................................................. Người nhận báo cáo (ký tên và ghi rõ họ tên): …………………………………………………………………………………….. Tháng 07 /năm 2011 TRÍCH YẾU Đi cùng với sự phát triển không ngừng của các nhóm ngành nghề kinh tế, xã hội; lĩnh vực khoa học số cũng đã và đang dần chiếm giữ vị thế quan trọng trong xu thế phát triển chung của xã hội loài người. Nhận thấy được tầm quan trọng đó, cùng với sự yêu thích cá nhân, tôi đã tham gia khóa học chuyên ngành mạng máy tính tại trường Đại Học Hoa Sen. Bên cạnh sự nỗ lực của bản thân, cùng với sự giúp đỡ, hỗ trợ của các thầy cô, tôi đã có kết quả tốt và có được cơ hội thực hiện đề tài tốt nghiệp này. Để đạt kết quả tốt với những mục tiêu đề ra, tôi đã tham khảo thêm tư liệu bên ngoài, cùng với sự hướng dẫn trực tiếp của giáo viên Lưu Thanh Trà. Khi bắt tay vào thực hiện đề tài tốt nghiệp này, tôi mới nhận thấy được nhưng khó khăn trong kỹ thuật thực tiễn, cũng như những lỗ hổng kiến thức chưa vững chắc của bản thân để củng cố và rèn luyện thêm. Tôi luôn cố gắng để hoàn thiện các kỹ năng chuyên ngành, kiến thức cần có trong nghề không để chỉ phục vụ cho luận án tốt nghiệp này, mà đó sẽ là nền tảng tốt cho tôi trong công việc ở tương lai. 1 MỤC LỤC TRÍCH YẾU................................................................................................................. II MỤC LỤC .................................................................................................................. III ĐÁNH GIÁ CỦA GIÁO VIÊN HƯỚNG DẪN ........................................................ V LỜI CẢM ƠN ............................................................................................................ VI NHẬP ĐỀ ...................................................................................................................... 7 NỘI DUNG ĐỀ TÀI ..................................................................................................... 8 CHƯƠNG I: TỔNG QUAN IDS-IPS, SNORT..................................8 1. TỔNG QUAN IDS – IPS ........................................................................................ 8 1.1. Khái niệm ..................................................................................................................................................... 8 1.2. Phương thức phát hiện ................................................................................................................................. 9 1.3. Phân loại ....................................................................................................................................................... 9 2. TỔNG QUAN SNORT TRÊN MÃ NGUỒN MỞ ................................................ 15 2.1. Giới thiệu .................................................................................................................................................... 15 2.2. Kiến trúc Snort............................................................................................................................................ 15 2.2.1. Packet decoder ....................................................................................................................................... 16 2.2.2. Preprocessors ......................................................................................................................................... 17 2.2.3. Detection Engine.................................................................................................................................... 19 2.2.4. Outputs................................................................................................................................................... 19 3. RULES .................................................................................................................. 20 3.1. Giới thiệu .................................................................................................................................................... 20 3.2. Rule header ................................................................................................................................................. 20 3.3. Rule option ................................................................................................................................................. 22 3.3.1. Nhóm General ........................................................................................................................................ 23 3.3.2. Nhóm Payload........................................................................................................................................ 27 3.3.3 Nhóm Non-payload................................................................................................................................ 37 3.3.4 Nhóm Post-Detection ............................................................................................................................. 44 CHƯƠNG II: TRIỂN KHAI SNORT...............................................48 1. YÊU CẦU .............................................................................................................. 48 2. CÀI ĐẶT ............................................................................................................... 49 3. CẤU HÌNH CƠ BẢN............................................................................................ 51 4. SỬ DỤNG BASE THEO DÕI CẢNH BÁO ........................................................ 53 5. TÍCH HỢP XÁC ĐỊNH VÙNG CỦA ĐỊA CHỈ IP............................................. 59 6. THEO DÕI NHỮNG CẢNH BÁO SNORT TRÊN GOOGLEEARTH. ........... 60 7. TÙY CHỈNH CẤU HÌNH SNORT.CONF .......................................................... 65 CHƯƠNG III: XÂY DỰNG SNORT IPS ........................................70 1. SNORT INLINE ................................................................................................... 70 1.1. Giới thiệu .................................................................................................................................................... 70 1.2. Triển khai.................................................................................................................................................... 70 2. SNORT SAM......................................................................................................... 73 2.1. Giới thiệu .................................................................................................................................................... 73 2.2. Triển khai.................................................................................................................................................... 73 2.2.1. Triển khai SnortSam và iptables ................................................................................................................. 74 2.2.2. Triển khai SnortSam và ACL trên router Cisco .......................................................................................... 78 CHƯƠNG IV: TÌM HIỂU CÁC LUẬT DÙNG TRONG SNORT ..84 1. NGUYÊN TẮC VIẾT LUẬT ................................................................................ 84 2. KHẢO SÁT LUẬT 1 ............................................................................................. 84 3. KHẢO SÁT LUẬT 2 ............................................................................................. 85 4. KHẢO SÁT LUẬT 3 ............................................................................................. 87 5. KHẢO SÁT LUẬT 4 ............................................................................................. 89 6. KHẢO SÁT LUẬT 5 ............................................................................................. 89 7. KHẢO SÁT LUẬT 6 ............................................................................................. 90 8. KHẢO SÁT LUẬT 7 ............................................................................................. 90 9. KHẢO SÁT LUẬT 8 ............................................................................................. 94 10. KHẢO SÁT RULE CHỐNG DOS/DDOS TẠI APPLICATION LAYER ........ 100 11. PHP – SHELL UPLOAD ................................................................................... 105 KHÓ KHĂN – THUẬN LỢI ................................................................................... 108 HƯỚNG PHÁT TRIỂN TƯƠNG LAI ................................................................... 109 PHỤ LỤC .................................................................................................................. 110 1. TÀI LIỆU THAM KHẢO ................................................................................... 110 2. WEBSITE THAM KHẢO .................................................................................. 110 3. PHỤ LỤC HÌNH ẢNH ...................................................................................... 111 1 ĐÁNH GIÁ CỦA GIÁO VIÊN HƯỚNG DẪN ..................................................................................................................................... ...................................................................................................................................... ...................................................................................................................................... ...................................................................................................................................... ...................................................................................................................................... ...................................................................................................................................... ...................................................................................................................................... ...................................................................................................................................... ...................................................................................................................................... ...................................................................................................................................... ...................................................................................................................................... ...................................................................................................................................... ...................................................................................................................................... ...................................................................................................................................... ...................................................................................................................................... ...................................................................................................................................... ...................................................................................................................................... Ngày… tháng… năm… KÝ TÊN ……………………………………….. LỜI CẢM ƠN Với đề tài “Tìm hiểu và phát triển các luật để phòng chống các virus mới sử dụng hệ thống mã nguồn mở Snort”, tôi đã có dịp tiếp xúc thực tế với hệ thống IDSIPS trên môi trường mã nguồn mở và phương án triển khai trong môi trường thực tế, tiếp thu được một số dạng tấn công qua môi trường internet… Để được kết quả trên, tôi chân thành cảm ơn thầy Lưu Thanh Trà – trưởng ngành Mạng máy tính, trường Đại học Hoa Sen, đã hướng dẫn chi tiết, đề xuất những phương án mang tính chất định hướng, tạo thuận lợi cho việc nghiên cứu đề tài để tôi có thể hoàn thành quyển báo cáo này. Ngoài ra, với những kiến thức chuyên ngành thầy đã chia sẻ trong thời gian làm báo cáo sẽ thật sự giúp ích cho tôi trong công việc tương lai theo hướng xây dựng và kiện toàn bảo mật bảo mật hệ thống. Trong thời gian thực hiện nghiên cứu đề tài từ 03/2011 đến 07/2011, thầy đã hỗ trợ tôi tiếp xúc với những môi trường an ninh mạng thực tế, tạo tiền đề cho việc định hướng công việc trong tương lai. Trân trọng. 3 NHẬP ĐỀ Trong thời gian gần đây, an ninh mạng được xem như là vấn đề nan giải cho các nhà quản trị mạng và những công ty cung cấp giải pháp bảo mật… Với hàng loạt các cuộc tấn công vào các cơ quan chính phủ, công ty, ngân hàng… đã tạo nên một bài toán là:  Khắc phục cho hệ thống đã bị tấn công.  Phương án chống lại áp dụng cho những hệ mạng khác.  Cập nhật mới nhất những dạng tấn công để phòng tránh trước khi cuộc tấn công xảy ra. Với những hãng cung cấp giải pháp an ninh nổi tiếng như Kaspersky, Norton, Cisco, Checkpoint…thì giá thành triển khai cao, không thể tham khảo mã nguồn vì đây là những sản phẩm thương mại phần lớn là mã nguồn đóng (close source). Tồn tại cho việc nghiên cứu và áp dụng thực tế, Snort đã phát huy tính năng mạnh mẽ thông qua khả năng đáp ứng nhu cầu an ninh trên những hệ mạng khác nhau. Khả năng tùy biến linh động trên mã nguồn mở giúp Snort có một số lượng người dùng lớn trên thế giới, tạo nên một cộng đồng phát triển Snort có chiều rộng về số thành viên lẫn chiều sâu về kiến thức bảo mật. 4 NỘI DUNG ĐỀ TÀI CHƯƠNG I: TỔNG QUAN IDS-IPS, SNORT 1. TỔNG QUAN IDS – IPS 1.1. Khái niệm Hệ thống phát hiện xâm nhập (IDS) là một hệ thống được xây dựng cho việc phát hiện các hành vi xâm phạm (truy xuất) không hợp pháp và là một cổng theo dõi hoạt động trên hệ thống mạng hoặc một số máy trạm được chỉ định. Một IDS hoạt động dựa vào phân tích các luồng thông tin, tập tin ghi log của một (nhiều) máy trạm, router, firewall, server… sau đó những thông tin này được so sánh với những signature được lưu bên trong chính IDS. Những signature là những dấu hiệu xâm nhập đã được biết đến. Việc so sánh thông tin nguồn với những signature giúp cho IDS có thể nhận biết được thông tin di chuyển trong mạng có thể gây ra nguy cơ hoặc đang bị tấn công hay không, từ đó IDS sẽ có những cảnh báo đến người quản trị. Trong khi đó một IPS có thể đưa ra hành động để phản ứng lại những hành vi bất hợp lệ như việc ngắt kết nối hoặc hủy những packets có thể gây tổn thương cho mạng. Việc phản ứng có thể thực hiện một cách tự động hoặc có thể được chỉ định bởi quản trị viên. Ngày nay, sự khác biệt giữa IDS và IPS là không rõ ràng. Một IDS có thể thực hiện chức năng của một IPS. Một số IDS hiện nay có thể đóng vai trò như một IPS với những hành động phản ứng như là một tùy chọn. Thông thường, đối với một hệ thống mạng nhỏ thì IPS là giả pháp lựa chọn hàng đầu cho việc bảo đảm an ninh hệ thống do khả năng phát hiện, cảnh báo và ngăn chặn của IPS một cách tự động. Trong khi đó, tại những mô hình mạng quy mô lớn thì IDS chỉ có nhiệm vụ theo dõi và cảnh báo, việc ngăn chặn được giao cho những thiết bị khác an ninh chuyên dụng khác như tường lửa… Việc phân bổ nhiệm vụ này giúp cho hệ thống vận hành một cách linh động và bảo mật hơn. 5 IDS/IPS có thể là xây dựng bằng phần mềm hoặc được kết hợp vào thiết bị phần cứng. 1.2. Phương thức phát hiện Tương tự những phần mềm diệt virus hiện tại, các IDS hoạt động dựa vào 2 cách thức chính: Signature detection và Anomaly dectection. Sinatures là những dấu hiệu tích lũy các hành vi (cách thức) hoạt động trong những dạng tấn công đã được biết đến, IDS sẽ so sánh tình trạng hiện tại với cơ sở dữ liệu được lưu bên trong nó để xác định gói tin. Những signature cần được phát triển và cập nhật thường xuyên từ những nhà phát triển phần mềm hoặc thiết bị IDS/IPS. Việc cập nhật có thể là miễn phí hoặc tính phí tùy vào nhà sản xuất. Anomaly dectection: Phương thức phát hiện bất thường dựa vào cách hoạt động bình thường của IDS để phát hiện ra những bất thường có thể xuất hiện trong tương lai. Thông thường, việc phát hiện bất thường dựa vào những hồ sơ mẫu có sẵn để lấy mẫu, tìm ra những hành động nào là bình thường, từ đó những hành động tấn công không khớp với mẫu này được xem là không hợp lệ. 1.3. Phân loại Dựa vào nhiệm vụ và vị trí của IDS khi triển khai trên thực tế, IDS được chia thành 3 loại: NIDS: Network-based Intrusion Detection System. HIDS: Host-based Intrusion Detection System. DIDS: Distributed Intrusion Detection System. Network-based Intrusion Detection System 6 Hình 1: Mô hình NIDS NIDS được triển khai để theo dõi trên một phân khúc mạng hoặc một subnet, thường được bố trí tại các gateway kết nối với router, switch, firewall… Thông thường, để thiết lập một NIDS thì NIC (Network Interface Card) cần chuyển sang chế độ Promiscuous, ở chế độ này thì NIC có thể theo dõi toàn bộ lưu lương di chuyển qua mạng. NIDS khi phân tích gói tin ở chế độ stream, nghĩa là phân tích header hoặc payload của gói tin thì còn gọi là NIDS stateless. Đối với những gói tin bị phân mảnh thì NIDS sẽ cần ráp lại thành một tập tin hoàn chỉnh sau đó mới xem xét thông tin bên trong, hay còn gọi là NIDS statefull. Ưu điểm: Chi phí thấp, vì ta chỉ cần đặt NIDS tại những đoạn mạng trọng yếu, thiết bị được lắp đặt tại vị trí nhất định mà không cần cài thêm phần mềm trên toàn mạng. 7 NIDS được cài đặt và theo dõi hoàn toàn độc lập với hệ thống, không tác động đến sự vận hành trên những thiết bị khác, không bị ảnh hưởng khi trong mạng có vấn đề xảy ra. Kẻ tấn công khó có thể xóa bỏ dấu vết khi tấn công do NIDS sử dụng thông tin theo thời gian thật để ghi log. Tập tin log không thể xóa bỏ do không nằm ở máy trạm, NIDS giúp nhanh chóng phát hiện được kẻ tấn công là ai phục vụ công tác điều tra. Kẻ tấn công không thể biết sự tồn tại của IDS vì thiết bị chỉ nhận thông tin về mà không trả lời bất kỳ yêu cầu nào, nên việc phát hiện IDS là khó khăn. Tính chất theo dõi bao phủ cho toàn hệ thống mạng. Nhược điểm: Khi NIDS xử lý các gói tin trên mạng rộng hoặc có mật độ lưu thông cao sẽ dẫn đến tình trạng phân đoạn NIDS sẽ dùng tối đa hiệu xuất, có thể gây ra tình trạng nghẽn mạng gây mất gói tin dẫn đến việc bỏ qua những nguy cơ tiềm ẩn có thể. Những nhà phát triển khắc phục bằng cách cứng hóa thiết bị để tăng tốc độ làm việc của IDS Đối với những luồng thông tin bị mã hóa thì NIDS dường như không thể phát hiện được, nếu có việc tấn công từ trong kết nối VPN thì NIDS không còn phát hiện hiệu quả. Không thể biết cuộc tấn công có thành công hay không. Yêu cầu cập nhật những dấu hiệu mới là cần thiết để cho NIDS hoạt động hiệu quả. Một số hệ thống NIDS cũng gặp khó khăn khi phát hiện các cuộc tấn công mạng từ các gói tin phân mảnh. Các gói tin định dạng sai này có thể làm cho NIDS hoạt động sai và đổ vỡ. Host-based Intrusion Detection System 8 Hình 2: Mô hình HIDS HIDS có hai điểm khác nhau so với NIDS là: HIDS được cài đặt để bảo vệ những host cục bộ. Vận hành ở chế độ nonpromiscuous. Host-based IDS tìm kiếm dấu hiệu của xâm nhập vào một host cục bộ; thường sử dụng các cơ chế kiểm tra và phân tích các thông tin được logging. Nó tìm kiếm các hoạt động bất thường như login, truy nhập file không thích hợp, bước leo thang các đặc quyền không được chấp nhận. Kiến trúc IDS này thường dựa trên các luật (rule-based) để phân tích các hoạt động trong cách host, HIDS cài đặt cho việc theo dõi cácchủ, máy máy trạm, laptop… 9 Vị trí triển khai HIDS được phân tán trong toàn mạng nên đây là bất lợi khi môi trường mạng của bạn phát triển lớn hơn sau này, nghĩa là số lượng HIDS cũng cần đượng tăng lên. Ưu điểm: Do hoạt động dựa vào sự ghi nhận tập tin log nên HIDS có thể cho biết cuộc tấn công có thành công hay chưa. Giám sát cụ thể hoạt động của hệ thống, việc mà NIDS không thể đảm nhiệm như: truy cập tập tin, đổi quyền, đăng nhập trái phép… Thích nghi tốt trong môi trường chuyển mạnch, mã hóa: việc chuyển mạch và mã hoá thực hiện trên mạng và do HIDS cài đặt trên máy nên nó không bị ảnh hưởng bởi hai kỹ thuật trên (dữ liệu mã hóa đã được giải mã tại host). Chỉ áp những rule cần thiết phụ thuộc vào server đang giám sát (Web server, FTP server…) Triển khai cài đặt lên hạ tầng mạng đã có, không yêu cầu thêm thiết bị phần cứng. Nhược điểm: Giá thành cao: một số lượng HIDS phân tán trong toàn mạng đòi hỏi giá thành triển khai cao. Một số host không được bảo vệ cũng có thể là một lỗ hổng an ninh gây hại đến hệ thống, kẻ tấn công có thể lấy những thông tin xác thực, tài liệu dễ bị xâm phạm… Mật độ bao phủ thấp. Khó quản trị do các HIDS bị phân tán trong toàn mạng, HIDS cần cài đặt trên những host quan trọng dẫn đến việc cấu hình, quản lý, cập nhật là một khối lượng công việc lớn cho người điều hành hệ thống. Thông tin không đáng tin cậy, do hacker có thể xóa dấu vết sau khi xâm nhập kéo theo là việc HIDS hoạt động sai, không phát hiện được xâm nhập. 10 Không phát huy được khả năng khi một cuộc tấn côn DOS, DDOS xảy ra. Hệ thống bên trong sụp đổ kéo theo HIDS cũng mất tác dụng. Distributed Intrusion Detection System Hình 3: Mô hình DIDS DIDS là một giải pháp tổng thể trong việc xây dựng, quản lý hệ thống cảnh báo an ninh mạng. Mô hình quản lý trập trung trong DIDS giúp tăng hiệu suất giám sát hoạt động trên đường truyền mạng, giảm thiểu nguy cơ gây gián đoạn từ bất cứ vị trí nào. Để hoạt động được như vậy, thì mô hình DIDS kết hợp NIDS và HIDS, những thông tin này được quản lý tập trung tại trạm quản lý cho việc kết xuất báo cáo, cập nhật rule mới cho những IDS khác được phân bổ trong hệ thống. 11 2. TỔNG QUAN SNORT TRÊN MÃ NGUỒN MỞ 2.1. Giới thiệu Snort là một NIDS được phát triển bởi Martin Roesch, đây là một phần mềm nguồn mở, hoàn toàn miễn phí và dễ sử dụng với nhiều tính năng mạnh mẽ. Hiện tại Snort được điều hành bởi SOURCEfire và cũng nằm trong những nền tảng phát triển của hãng tường lửa nổi tiếng Checkpoint. Ưu điểm của Snort là nhẹ, mạnh mẽ, có tính tùy biến cao khi triển khai trên hệ thống và đây cũng là mục tiêu mong muốn của nhà phát triển cũng như của người sử dụng. Snort đã thể hiện được tính uyển chuyển của mình khi có thể triển khai trên nhiều nền tảng hệ điều hành x86, x64 khác nhau như: Windows, Linux, FreeBSD… và kiến trúc Sparc như: MacOSX, Solaris, HP-UX…Việc kết hợp với các thiết bị an ninh khác để chặn việc truy cập như: ACL của Cisco, Checkpoint, iptables trên Linux… cũng là một lợi điểm khi có ý định xây dựng Snort. Hiệu suất cao: Snort có thể theo dõi 24/7 với thời gian thật, nên việc phát hiện xâm nhập vào hệ thống là liên tục. Hỗ trợ mạnh mẽ giao thức TCP/IP, các giao thức khác có thể vẫn được hỗ trợ như là một tùy chọn ICMP, IPX, MPLS… Do xây dựng với kiến trúc mở, nên Snort có một lực lượng phát triển đông đảo khá lớn từ người dùng cho đến những hãng bảo mật nổi tiếng. Việc phát hiện những phương pháp tấn công thường xuyên được cập nhật nếu bạn đăng ký làm thành viên. 2.2. Kiến trúc Snort Snort có các chế độ làm việc: Packet sniffer Packet logger NIDS 12 Hình 2.2.1. 4: Quy trình thu thập, xử lý gói tin Packet decoder Luồng dữ liệu sẽ qua packet decoder trước tiên, tại đi đây những gói tin sẽ được giải mã và theo dõi những thông tin: etherner header, IP header, TCP header, payload… Snort hỗ trợ những công nghệ: Ethernet, 802.11,Token Ring, FDDI, Cisco HDLC, SLIP,PPP và OpenBSD’s PF. Những tham số cấu hình cho việc giải mã được lưu trong tập tin snort.conf Tùy vào chế độ sử dụng, decoder sẽ có những hành vi tương ứng sau khi giả mã gói tin: Packet sniffer: (Snort –v ) gói tin sau khi giải mã sẽ được hiển thị lên màn hình console. Packet logger: (Snort –l /var/log/snort) gói tin sau khi giải mã sẽ ghi vào một tập tin với cấu trúc binary hoặc mã ASCII. 13 NIDS: (Snort –c /etc/snort/etc/snort.conf) gói tin sau giải mã sẽ được khi chuyển sang quá trình Preprocessor tương ứng. Hình 5: TCP packet 2.2.2. Preprocessors Đây là một plug-in dùng cho Snort, nhiệm vụ của preprocessor là dịch những gói tin rời rạc thành định dạng chuẩn thông thường để có thể sử dụng được. Quá trình preprocessor cực kỳ hữu dụng khi có các cuộc tấn công dạng phân mảnh gói tin để đánh lừa IDS (Firewall evasion) như tấn công dạng teardrop . Tiến trình preprocessor giúp cho việc nhận định dạng tấn công một cách thuận lợi. Hình 6: Lưu đồ quy trình Prerocessor Frag3: hoạt động trên sự phân mảnh của gói tin, nối những gói bị phân mảnh 14 thành tập tin nguyên vẹn sau đó trả ngược lại decoder để phân tích nội dung bên trong. 15 Stream5: hoạt động dựa vào địa chỉ gói tin, theo dõi trên luồng thông tin, các gói tin lại đưa ngược về decoder. Trong phiên bản Snort 2.9.0 Stream5 được thay thế cho Stream4 và flow được dùng trong những phiên bản trước đó. Hình 7: Tổng thể cơ chế Snort http_inspect: cung cấp cơ chế phân giải chuỗi ký tự trở về dạng chuẩn của một cấu trúc URI, nó bỏ qua những gói tin Respond từ server đến client, chỉ xem xét những gói tin Request client đến server. Nhờ vậy, IDS có giảm được lượng từ thể thông tin không cần thiết phải theo dõi, do thông thường những gói tin tấn công xuất phát từ phía client (Client thường gởi Request và server chỉ trả lời Respond). 16 Hình 8: HTTP inspect 2.2.3. Detection Engine Các gói tin được xử lý tại preprocessor sẽ chuyển qua quá trình Detection, thật chất đây là quá trình gói tin được so sánh với các rule để xác định gói tin có hợp lệ không. Detection engine thế hệ mới tập trung vào 4 giao thức chính: TCP,UDP, IP, ICMP. Hình 2.2.4. 9: Cơ chế phát hiện (Detection Engine) Outputs 17 Khi detection phát hiện những gói tin trùng với bộ luật thì sẽ ghi nhận sự kiện và ghi log. Việc ghi log có thể xuất ra nhiều kiểu khác nhau như: database / syslog/ XML/ TCPDUMP/ Unifiled. Dữ liệu sau khi xuất có thể sử dụng bởi các chương trình phân tích log cho việc thống kê. 3. RULES 3.1. Giới thiệu Các phương thức tấn công cũng tương tự virus, hầu hết các hoạt động xâm phạm đều để lại những dấu hiệu riêng để nhận biết. Các thông tin và dấu hiệu này được sử dụng để tạo rule cho Snort. Rule là một thành phần cốt lõi cho một hệ thống IDS nhận biết được các cuộc tấn công. Những hệ thống honey pots được xây dựng nhằm thu thập các dấu hiệu tấn công, từ đó những nhà phát triển có thể cập nhật những dấu hiệu mới cho sản phẩm. Với Snort là một IDS mã nguồn mở, thì ngoài việc cập nhật rule từ nhà sản xuất (www.Snort.org) thì người dùng còn có thể phát triển riêng những rule tùy biến vào mục đích mà mình sử dụng. Những cuộc tấn công trên một gói tin được nhận biết dựa vào phần header hoặc trong payload (nội dung gói tin), các luật có thể áp dụng cho tất cả các phần khác nhau của một gói dữ liệu để có thể nhận dạng dấu hiệu tấn công. Hình 10: Cấu trúc rule Một rule có 2 phần: rule header và rule option. 3.2. Rule header 18  Action: Là phần chỉ định hành động nào sẽ được thực hiện khi các dấu hiệu của gói tin được nhận dạng chính xác. Có các hành động sau:  Alert: tạo ra một cảnh báo và ghi log.  Log: ghi log sự kiện  Pass: cho gói tin đi qua IDS mà không cần kiểm tra. Hành động này dùng khi cần tăng tốc IDS với những gói tin ta chỉ định không cần kiểm tra.  Activate: tạo cảnh báo và kích hoạt một luật khác.  Dynamic: được kích hoạt khi dùng với hành động activate  Drop: hủy gói tin và ghi lại log.  Reject: hủy gói tin, ghi log và gởi TCP reset nếu gói tin đến là gói TCP hoặc ICMP port unreachable nếu là giao thức UDP.  Sdrop: hủy gói tin, không ghi log. Các phương thức alert, log, pass, activate, dynamic là 5 hanh động chính trong Snort. Ba chức năng drop, reject, sdrop là tùy chọn dùng ở chế độ inline.  Protocol Chỉ rõ giao thức của gói tin mà ta cần kiểm tra. Snort hỗ trợ những giao thức: IP (version 4 và version 6), TCP, UDP, ICMP. Các giao thức ARP, IGRP, GRE, OSPF, RIP, IPX… sẽ phát triển trong tương lai hoặc trong phiên bản hiện tại có một số giao thức hỗ trợ như là một tùy chọn.  Address Cung cấp địa chỉ nguồn và địa chỉ đích mà luật cần theo dõi. Việc xác định địa chỉ là nguồn hay là đích phụ thuộc vào hướng (direction). Ta có thể khai báo một địa chỉ IP, lớp mạng (subnet), trên tất cả IP hoặc loại trừ một IP, subnet. Ví dụ: 19 alert tcp any any -> 192.168.1.10/32 80 (msg: “TTL=100”; ttl: 100;) #cảnh báo những gói tin có ttl=100 từ tất cả các nguồn đến webserver tại địa chi 192.168.1.10:80 alert icmp ![192.168.2.0/24] any -> any any (msg: “Ping with TTL=100”; #dùng dấu ! để phủ định những IP mà ta không muốn kiểm tra. ttl: 100;) alert icmp ![192.168.2.0/24, 192.168.8.0/24] any -> any any (msg: “Ping with TTL=100”; ttl: 100;)  Port Luật áp dụng trên những dịch vụ cụ thể dựa vào số cổng, ta có thể khai báo port chỉ định, dãy port (dùng dấu “:” ngăn cách cổng bắt đầu và cổng kết thúc) hoặc phủ định port ( dùng dấu “!” trước port muốn phủ định). alert udp any 1024:2048 -> any any (msg: “UDP ports”;) #chỉ ra dãy port mà muốn theo dõi từ 1024 đến 2048.  Direction Dùng để xác định đâu là nguồn hay đích, ta dùng những ký hiệu sau cho việc định hướng: ->, <-, <>. Ký hiệu <> dùng khi kiểm tra cả client và server. 3.3. Rule option Phần Rule Option nằm ngay sau phần Rule Header và được bao bọc trong dấu ngoặc đơn. Nếu có nhiều option thì các option sẽ được phân cách với nhau bằng dấu chấm phẩy “;”. Một option gồm 2 phần: một từ khoá và một tham số, hai phần này phân cách nhau bằng dấu hai chấm. Ví dụ: msg: “Detected confidented” #msg là từ khoá còn “Detected confidented” là tham số. Có 4 nhóm option chính : 20 general : cung cấp những thông tin về rule, không gây tác động ảnh hưởng đển hoạt dộng phát hiện của IDS payload : những option thuộc nhóm này sẽ tìm kiếm nội dụng trong payload của gói tin. non-payload: những option nhóm non-payload sẽ tìm nội dung trong phần header gói tin. post-detection: các option trong nhóm này sẽ đưa ra những hành động khi những mẫu so sánh trong nhóm pay-load và non-payload trùng khớp với gói tin. 3.3.1.  Nhóm General Msg Cú pháp: msg:""; Tạo một thông điệp cảnh ab1o khi rule được so trùng, msg tạo thuật lợi khi ta kết hợp Snort với những chương trình quản lý khác như BASE  Reference Cú pháp: reference:, ; Chức năng reference cho phép ta tham chiếu những thông tin về dạng tấn công từ những trang web bảo mật. Bảng dưới liệt kê những hệ thống hỗ trợ cho việc tham chiếu. SYSTEM bugtraq cve nessus arachnids mcafee osvdb url URL http://www.securityfocus.com/bid/ http://cve.mitre.org/cgi-bin/cvename.cgi?name= http://cgi.nessus.org/plugins/dump.php3?id= (currently down) http://www.whitehats.com/info/IDS http://vil.nai.com/vil/content/v http://osvdb.org/show/osvdb/ http:// Ví dụ: 21 alert tcp any any -> any 7070 (msg:"IDS411/dos-realaudio";flags:AP; content:"|fff4 fffd 06|"; reference:arachnids,IDS411;) log tcp any any -> any 12345 (reference:CVE, CAN-2002-1010; reference:URL,www.poc2.com; msg:" NetBus";)  Gid Cú pháp: gid:; Từ khóa gid (generator id) được sử dụng để định danh phần nào trong luật tạo ra thông báo (message), những gid do người dùng định nghĩa cần lớn hơn 1.000.000, những gid do Snort sử dụng được lưu trong file gen-msg.map trong thư mục source cài đặt Snort-2.9.0.5/etc. Từ khóa gid nên được sử dụng chung với sid  Sid Cú pháp: sid:; Sid là một số duy nhất dùng định danh cho một rule trong Snort, sid giúp dễ dàng cho việc quản lý rule. Những rule do người dùng định nghĩa cần có sid >=1.000.000, những rule do Snort phân phối có sid 100-999.999 và những sid <100 được dùng cho việc phát triển trong tương lai.  Rev Cú pháp: rev:; Chỉ số revision dùng cho việc xác định bản chỉnh sửa của luật, nhận diện phiên bản của luật, thuận tiện cho việc quản lý luật cần cập nhập. rev cũng nên dùng chung với sid. alert tcp any any -> any 80 (content:"BOB"; sid:1000983; rev:1;)  Classtype Cú pháp: classtype:; 22 Classtype attempted-admin attempted-user inappropriate-content policy-violation shellcode-detect successful-admin successful-user trojan-activity unsuccessful-user web-application-attack attempted-dos attempted-recon bad-unknown default-login-attempt denial-of-service misc-attack non-standard-protocol rpc-portmap-decode successful-dos successful-reconlargescale successful-reconlimited suspicious-filenamedetect suspicious-login system-call-detect unusual-client-portconnection web-applicationactivity icmp-event misc-activity network-scan not-suspicious protocol-commanddecode string-detect unknown tcp-connection Description Attempted Administrator Privilege Gain Attempted User Privilege Gain Inappropriate Content was Detected Potential Corporate Privacy Violation Executable code was detected Successful Administrator Privilege Gain Successful User Privilege Gain A Network Trojan was detected Unsuccessful User Privilege Gain Web Application Attack Attempted Denial of Service Attempted Information Leak Potentially Bad Traffic Attempt to login by a default username and password Detection of a Denial of Service Attack Misc Attack Detection of a non-standard protocol or event Decode of an RPC Query Denial of Service Large Scale Information Leak Priority high high high high high high high high high high medium medium medium medium medium medium medium medium medium medium Information Leak medium A suspicious filename was detected medium An attempted login using a suspicious username A systemwas calldetected was detected A client was using an unusual port medium Access to a potentially vulnerable web application Generic ICMP event Misc activity Detection of a Network Scan Not Suspicious Traffic Generic Protocol Command Decode medium A suspicious string was detected Unknown Traffic A TCP connection was detected medium medium low low low low low low low very low 23  Priority Cú pháp: priority: ; Các luật có thể được phân loại và gán cho một chỉ số độ ưu tiên để nhóm và phân biệt chúng với nhau. Để hiểu rõ hơn về từ khoá này ta đầu tiên phải hiểu được file classification.config (được load trong Snort.conf với classification.config). Mỗi dòng trong file classification.config sau: config classification: dòng include có cú pháp như name, description, priority Name: là tên dùng để phân loại, tên này sẽ được dùng với từ khoá classtype trong các luật Snort. Description: mô tả về loại lớp này priority: là một số chỉ độ ưu tiên mặc định của lớp này. Độ ưu tiên này có thể được điều chỉnh trong từ khoá priority của phần option trong luật của Snort. Ví dụ : config classification: DoS , Denial of Service Attack, 2 và trong luật: alert udp any any -> 192.168.1.0/24 6838 (msg: “DoS”; content: “server”; 6838 (msg:”DoS”; content: “server”; classtype: DoS;) alert udp any any -> 192.168.1.0/24 classtype: DoS; priority: 1;) Trong câu lệnh thứ 2 thì ta đã ghi đè lên giá trị priority mặc định của lớp đã định nghĩa.  Metadata Cú pháp: metadata:key1 value1; 24 metadata:key1 value1, key2 value2; Metadata cho phép người viết luật đính kèm theo những thông tin mô tả về luật mà họ viết, những metadata này khi khai báo cần theo một cấu trúc. Bảng bên dưới liệt kê những giá trị mà Snort hỗ trợ: o metadata chỉ có giá trị sử dụng khi một Host Atttribute Table được cung cấp. Ví dụ: alert tcp any any -> any 80 (msg:"Shared Library Rule Example"; \metadata:engine shared; metadata:soid 3|12345;) alert tcp any any -> any 80 (msg:"Shared Library Rule Example"; \metadata:engine shared, soid 3|12345;) alert tcp any any -> any 80 (msg:"HTTP Service Rule Example"; \metadata:service http;) 3.3.2.  Nhóm Payload content Cú pháp: content: [!]“” Dùng tìm kiếm nội dung được chỉ định trong luật với nội dụng gói tin. Một đặc tính quan trọng của Snort là nó có khả năng tìm một mẫu dữ liệu bên trong một gói tin. Mẫu này có thể dưới dạng chuỗi ASCII hoặc hex code (hệ 16). Ví dụ 1: alert tcp 192.168.1.0/24 any -> ![192.168.1.0/24] any (content: “GET”; msg: “GET match”;) 25 Luật trên tìm mẫu “GET” trong phần dữ liệu của tất cả các gói tin TCP có nguồn đi từ mạng 192.168.1.0/24 và đi đến các địa chỉ không thuộc mạng đó. Từ “GET” này rất hay được dùng trong các tấn công HTTP. Ví dụ 2: alert tcp 192.168.1.0/24 any -> ![192.168.1.0/24] any (content: “|47 45 54|”; msg: “GET match”;) Nội dung của luật trong ví dụ 2 tương tự ví dụ 1 nhưng phần nội dung kiểm tra được thay thế bằng một dãy số hex. Trong đó: 47 45 54 trong dãy hex tương ứng với ASCII là GET. Ta có thể dùng cả hai dạng trên trong cùng một luật với điều kiện nội dung mã ASCII đặt trong dấu ngoặc kép “” và nội dung là số hex thì đặt trong cặp dấu | |.  Nocase Cú pháp: nocase; Dùng kết hợp với từ khóa content, mục đích cho việc sử dụng nocase là tạo ra một kiểm tra với nội dung không phân biệt chữ hoa hay thường (noncasesensive) Ví dụ: alert tcp any any -> any 23 (content: "administrator"; nocase;) #so sánh chuỗi administrator không phân biệt chữ hoa hay thường.  Rawbytes Dùng kiểm tra những gói tin dạng RAW, những gói tin được giải mã trong tiến trình preprocessor sẽ được bỏ qua. alert tcp any any -> any 21 (msg:"Telnet NOP"; content:"|FF F1|"; rawbytes;)  Depth Cú pháp: depth:; 26 Dùng xác định trí kết thúc so sánh xét từ điểm offset thiết lập. alert tcp 192.168.1.0/24 any -> any any (content: “HTTP”; offset: 4; depth: 40; msg: “HTTP matched”;) #tìm nội dung từ byte thứ 4 đến byte thứ 40. Từ khoá này sẽ giúp giảm thời gian tìm kiếm khi mà đoạn dữ liệu trong gói tin là khá lớn.  Offset Cú pháp : offset:<“number”>; Dùng để xác định vị trí bắt đầu tìm kiếm (chuỗi chứa trong từ khoá content ) là offset tính từ đầu phần dữ liệu của gói tin. Ví dụ sau sẽ tìm chuỗi “HTTP” bắt đầu từ vị trí cách đầu đoạn dữ liệu của gói tin là 4 byte: alert tcp 192.168.1.0/24 any -> any any (content: “HTTP”; offset: 4; msg: “HTTP matched”;)  Distance Cú pháp: distance: <“number”>; So sánh chính xác nội dung trong content từ vị trí đầu đến khoảng cách được chỉ định trong distance.  Within Cú pháp: within:[|]; Dùng so sánh nội dung trong khoảng chỉ định từ vị trí (nội dung) xác định được đầu tiên đến vị trí (nội dung) kế tiếp. Ví dụ: content:"081660"; content:"vt081a"; within:20; #tìm trong 20 bytes tiếp theo từ vị trí 081660 được xác định, xem trong khoảng 20 bytes này có chuỗi vt081a hay không. Những trường hợp sau là hợp với rule trên: 27 081660 is member of vt081a 081660 is vt081a 081660 is studied at vt081a  http_client_body Cú pháp: http_client_body; Dùng phân tích nội dung chuỗi ký tự URI trong request message thay vì kiểm tra toàn bộ nội dung gói tin. Ví dụ: log tcp any any -> any 80 (content:"Logging PHF”; http_client_body;)  http_cookie Cú pháp: http_cookie; Dùng phát hiện nội dung trong một cookie của một http header, chúng được đặt tên Cookie trong http requests và Set-Cookie trong http responess.  http_raw_cookie Cú pháp: http_raw_cookie; Dùng tách những cookie có cấu trúc bất thường (UNNORMALIZED), chức năng này phải được dùng chung với enable_cookie.  http_header Cú pháp: http_header; Tìm nội dung chỉ rõ trong toàn bộ http header, dùng trong những header thông thường (NORMALIZED).  http_raw_header Cú pháp http_raw_header; 28 Dùng tách những header có cấu trúc bất thường (UNNORMALIZED), không dùng chung với chức năng rawbytes, http header, fast pattern.  http_method Cú pháp: http_method; Dùng so sánh phương thức trong giao thức http với content chỉ định. Ví dụ: alert tcp any any -> any 80 (content:"ABC"; content:"GET"; http_method;)  http_uri Cú pháp: http_uri; So sánh trường URI Request với content chỉ định trước đó. Ví dụ: alert tcp any any -> any 80 (content:"asd"; content:"EFG"; http_uri;) #tìm mẫu EFG tron một URI bình thường.  http_raw_uri Tương tự http_uri nhưng phân tích những gói tin không bình thường.  http_stat_code Cú pháp: http_stat_code; Phân tích trường Status code trong gói http server respone. Ví dụ: alert tcp any http_stat_code;) any -> any 80 (content:"ABC"; content:"200"; #phân tích mẫu 200(OK) trong header.  http_stat_msg 29 Cú pháp: http_stat_msg; Phân tích thông tin trong http server respone, so sánh với content trước đó. Ví dụ: alert tcp any any -> any 80 (content:"ABC"; content:"Not Found"; http_stat_msg;)  http_encode Cú pháp: http_encode:[uri|header|cookie],[!][ any any (msg:"UTF8/UEncode Encoding present"; http_encode:uri,utf8|uencode;) alert tcp any any -> any any (msg:"No UTF8"; http_encode:uri,!utf8;)  fast_pattern Cú pháp: fast_pattern:only; fast_pattern:,; fast_pattern thiết lập lại nội dung bên trong một rule, nó tăng tốc độ so nội dung mẫu với gói tin bằng cách chọn ra content có nội dung dài nhất (content có nội dung dài thì tỉ lệ chính xác cao hơn), từ đó Snort có thể quyết định nhanh chóng trong việc so mẫu trong rule.  uricontent Cú pháp: uricontent:[!]""; Ví dụ về URI: 30 URI Đường dẫn thông thường /scripts/..%c0%af../winnt/system32/cmd.exe?/ /winnt/system32/cmd.exe?/c c+ver +ver /cgi/cgi-bin/phf? bin/aaaaaaaaaaaaaaaaaaaaaaaaaa/..%252fp%68f ? Phương pháp kiểm trai uri rất quan trọng cho việc kiểm tra những hacker sử dụng kiểu tấn công upload shell lên web server để thực thi lệnh. Uri_content có thể dùng với các tùy chọn nocase, depth, offset, distance, within, fast pattern.  urilen Cú pháp: urilen:min<>max; urilen:[<|>]; Kiểm tra độ dài URI. Ví dụ: uri_len:5 uri_len:<5 uri_len:5<>10  So sánh độ dài chính xác bằng 5 bytes. So sánh độ dài nhỏ 5 bytes. So sánh độ dài lớn hơn 5 và nhỏ hơn 10 bytes. isdataat Cú pháp: isdataat:[!][, relative|rawbytes]; Kiểm tra có payload có dữ liệu hay không từ vị trí chỉ định, tùy chọn relative sẽ kiểm tra từ vị trí cuối content trước isdataat đến kết thúc.  pcre Cú pháp: pcre:[!]"(//|m)[ismxAEGRUBPHMCOIDKYS]"; 31 PCRE (Perl Compatible Regular Expression) được tích hợp từ phiên bản 2.1, dùng so sánh những trường hợp đặc biệt mà từ khóa content không kiểm tra được. Đây là một điểm mạnh trong những phiên bản mới về sau giúp cho IDS linh động hơn trong việc kiểm tra gói tin và phát hiện những cuộc tấn công dạng sử dụng gói tin bất thường. i s m Phân biệt chữ hoa, chữ thường. Kiểm tra bao gồm những dòng mới sau dấu “.” Mặc định, một chuỗi là một dòng bao gồm những ký tự. ^ đại diện cho đầu dòng và $ đại diện cho cuối dòng. Khi tùy chọn m được chỉ định thì việc kiểm tra sẽ tác động đến dòng mới trong bộ đệm. Bỏ qua ký tự khoảng trắng trong chuỗi. Mẫu cần phải được so trùng từ vị trí bắt đầu bộ đệm. Mẫu cần phải được so trùng từ vị trí cuối bộ đệm. Nghịch đảo chuỗi ký tự. So tìm mẫu toàn bộ (tương tự distance:0) So mẫu trong trường URI (tương tự uri_content và http_uri). Không cho phép những yêu cầu URI bất thường. So trùng những gói yêu cầu URL bất thường (tượng tự http_raw_uri). So trùng nội dung thân (body) của những http request bất thường (tương tự http_client_body). So những header HTTP request hoặc HTTP response (tương tự http_header) Tương tự http_raw_header. Tương tự http_method. Tương tự http_cookie. Tương tự http_raw_cookie. Tương tự http_stat_code. Tương tự http_stat_msg. Tương tự rawbytes. Chép đè những so sánh pcre đã được cấu hình hạn chế cho biểu thứ này. x A E G R U I P H D M C K S Y B O  file_data Cú pháp: file_data; file_data:mime; 32 Tùy chọn này dùng để thay thế con trỏ ( được sử dụng trong payload tại tiến trình xử lý rule) tại vị trí bắt đầu trong nội dung gói HTTP response hoặc dữ liệu trong thân gói SMTP.  base64_decode Cú pháp: base64_decode[:[bytes ][, ][offset [, relative]]]; Dùng giải mã header của gói http được mã bằng base64, dùng cho những HTTP authorization header.  base64_data Cú pháp: base64_data; Base64_data dùng giả mã payload gói tin dùng phương pháp base64, nếu trong rule tính năng này được chỉ định thì tiến trình xử lý sẽ nhảy (jump) đến phần payload để kiểm tra. base64_data phải nằm phía sau từ khóa base64_decode. Ví dụ: alert tcp any any -> any any (msg:"Authorization NTLM"; \ content:"Authorization:"; http_header; \ base64_decode:bytes 12, offset 6, relative; base64_data; \ content:"NTLMSSP"; within:8;)  byte_test Cú pháp: byte_test:, [!], , \ [, relative][, ][, string, ][, dce]; Dùng kiểm tra byte chỉ định bằng các toán tử, kiểm tra dựa trên giá trị binary hoặc chuyển từ hexa sang binary. 33  byte_jump Cú pháp: byte_jump:, \ [, relative][, multiplier ][, ][, string, ]\ [, align][, from_beginning][, post_offset ][, dce]; Đọc một phần nội dung gói tin, sau đó nhảy đến phần khác để đọc tiếp tục.  byte_extract Cú pháp: byte_extract:, , \ [, relative][, multiplier ][, ]\ [, string, ][, align ][, dce]; Dùng trích xuất một số byte chỉ định vào một biến, những biến này sẽ được sử dụng về sau tại những luật khác nhau.  fptbounce Cú pháp: ftpbounce; Dùng phát hiện tấn công ftp bounce.  asn1 Cú pháp : asn1:[bitstring_overflow][, double_overflow][, oversize_length ][, absolute_offset |relative_offset ]; Phát hiện dựa trên những phương thức mã hóa, từ đó xác định những phương thức mã hóa có thể gây hại cho server. 34  cvs Cú pháp: cvs:; Option: invalid-entry Dùng ngăn chặn phương thức tấn công bằng CVS dựa trên port mặt định 2401 và 514. cvs không tác dụng trên những luồng tin mã hóa như ssh. 3.3.3 Nhóm Non-payload  fragoffset Cú pháp: fragoffset:[!|<|>]; Dùng kiểm tra số thứ tự của gói tin phân mảnh, để kiểm tra toàn bộ gói tin bị phân mảnh ta dùng number=0. Ví dụ: alert ip any any -> any any (msg:"First Fragment"; fragbits:M; fragoffset:0;)  ttl Cú pháp: ttl:[<, >, =, <=, >=]; ttl:[]-[]; Dùng trong phiện các tấn công có dùng lệnh traceroute như nmap –A target. Ví dụ: một số trường hợp tìm những gói tin phù hợp điều kiện. ttl:<3; Time to live nhỏ hơn 5. ttl:3-5; Từ 3 đến 5. ttl:-5; Từ 0 đến 5. ttl:5-; Từ 5 đến 255.  tos 35 Cú pháp: tos:[!]; Kiểm tra TOS được chỉ định trong gói tin.  ipopts Cú pháp: ipopts:; rr eol ts sec esec lsrr lsrre ssrr satid any Record Route End of list Time Stamp IP Security IP Extended Security Loose Source Routing Loose Source Routing (For MS99-038 and CVE-1999-0909) Strict Source Routing Stream identifier any IP options are set Mỗi khai báo ipopts chỉ được dùng kiểm tra một option. Ví dụ: ipopts: lsrre ; ipopts: rr;  fragbits Cú pháp: fragbits:[+*!]<[MDR]>; Phần IP header của gói tin chứa 3 bit dùng để chống phân mảnh và tổng hợp các gói tin IP. Các bit đó là: Flag RB-Reserved Bit MF-More Fragments Bit DF-Don’t Fragment Bit Tham trong luật R M D số dùng Reserved Bit (RB) dùng để dành cho tương lai. Don’t Fragment Bit (DF): nếu bit này được thiết lập thì tức là gói tin đó không bị phân mảnh. 36 More Fragments Bit (MF): nếu được thiết lập thì tức là các phần khác của gói tin vẫn đang còn trên đường đi mà chưa tới đích. Nếu bit này không được thiết lập thì có nghĩa là đây là phần cuối cùng của gói tin (hoặc là gói duy nhất). Đôi khi các bit này bị các hacker sử dụng để tấn công và khai thác thông tin trên mạng của ta. Ví dụ, bit DF có thể được dùng để tìm MTU lớn nhất và nhỏ nhất trên đường đi từ nguồn xuất phát đến đích đến. Sử dụng fragbits, ta có thể kiểm tra xem các bit trên có được thiết lập hay không. Ví dụ luật sau sẽ phát hiện xem bit DF trong gói tin ICMP có được bật hay không: alert icmp any any -> 192.168.1.0/24 any (fragbits: D; msg: “Dont Fragment bit set”;) Ta cũng có thể dùng dấu phủ định ! trong luật này để kiểm tra khi bit không được bật: alert icmp any any -> 192.168.1.0/24 any (fragbits: !D; msg: “Dont Fragment bit not set”;)  dsize Cú pháp: dsize:min<>max; dsize:[<|>]; Dùng kiểm tra độ dài nội dung gói tin (payload), dùng phát hiện những gói tin có độ dài bất thường.  flags Cú pháp: flags:; Dùng xác định cờ trong gói TCP. F FIN - Finish (LSB in TCP Flags byte) 37 S R P A U 1 2 SYN - Synchronize sequence numbers RST - Reset PSH - Push ACK - Acknowledgment URG - Urgent CWR - Congestion Window Reduced (MSB in TCP Flags byte) ECE - ECN-Echo (If SYN, then ECN capable. Else, CE flag in IP header is set) No TCP Flags Set match on The specified bits, plus any others match if any of the specified bits are set match if the specified bits are not set 0 + * !  flow Cú pháp: flow:[(established|not_established|stateless)] [,(to_client|to_server|from_client|from_server)] [,(no_stream|only_stream)] [,(no_frag|only_frag)]; Tùy chọn to_server|from_client from_serverto_client only_stream|no_stream Stateless established|not_established only_frag| no_frag  Mô tả Gói tin từ client đến server. Gói tin từ sever đến client. Theo dõi hoặc không theo dõi những trên những gói tin đượcthái dựng lại bộ . xử lý luồng ( Bỏ qua trạng của dùng chung và stream5). Theovới dõidsize trên kết nối đã được (chưa) thiết lập. Tác dụng trên những gói bị (không bị) phân mảnh. flowbits Cú pháp: 38 flowbits:[set|unset|toggle|isset|isnotset|noalert|reset][, ][, ]; set Sets the specified state for the current flow and unsets all the other flowbits in a group when a GROUP NAME is specified. Unsets the specified state for the current flow. Sets the specified state if the state is unset and unsets all the other flowbits in a group when a GROUP NAME is specified, otherwise unsets the state if the state is set. Checks if the specified state is set. Checks if the specified state is not set. Cause the rule to not generate an alert, regardless of the rest of the detection options. Reset all states on a given flow. unset toggle isset isnotset Noalert Reset  seq Cú pháp: seq: ; Dùng tìm số sequence number trong gói TCP, chức năng này ít thường được sử dụng vì seq không cố định. Seq có thể được dùng trong những trường hợp có những chương trình gởi gói tin với số sequence nhất định nhằm mục đích flooding.  ack Cú pháp: ack:; Trong header TCP có chứa trường Acknowledgement Number với độ dài 32 bit. Trường này có ý nghĩa là chỉ ra số thứ tự tiếp theo gói tin TCP của bên gửi đang được chờ để nhận. Trường này chỉ có ý nghĩa khi mà cờ ACK được thiết lập. Các công cụ như Nmap sử dụng đặc điểm này ping một máy. Ví dụ, nó có thể gửi một gói tin TCP tới cổng 80 với cờ ACK được bật và số thứ tự là 0. Bởi vậy, bên nhận sẽ thấy gói tin không hợp lệ và sẽ gửi trở lại gói tin RST. Khi mà Nmap nhận được gói tin RST thì tức là địa chỉ đích đang “sống”. Phương pháp này vẫn làm việc tốt đối với các máy không trả lời gói tin thuộc dạng ping ICMP ECHO REQUEST. 39 Vậy để kiểm tra loại ping TCP này thì ta có thể dùng luật như sau: alert tcp any any -> 192.168.1.0/24 any (flags: A; ack: 0; msg: “TCP ping detected”)  window Cú pháp: window:[!]; Dùng so mẫu TCP window size.  itype Cú pháp: itype:min<>max; itype:[<|>]; Kiểm tra giá trị loại của gói ICMP.  icode Cú pháp: icode:min<>max; icode:[<|>]; Kiểm tra giá trị mã của gói ICMP.  icmp_id Cú pháp: icmp_id:; Dùng xác định kiểu gói tin ICMP, dùng cho phát hiện tấn công DDOS, DOS.  icmp_seq Cú pháp: icmp_seq:; 40 Tìm số sequence number trong gói ICMP, những gói tin ICMP có số sequence cố định là nguy cơ cho một cuộc tấn công DDOS. Vì vậy, chức năng này nhằm phát hiện tấn công.  rpc Cú pháp: rpc:, [|*], [|*]>; Dùng kiểm tra ứng dụng (application), phiên bản (version), thủ tục (procedure) trong những yêu cầu SUNRPC CALL. Wildcard được dùng cho procedure và version bằng dấu sao “*”. Ví dụ: alert tcp any any -> any 111 (rpc:100000, *, 3;); RPC # tìm kiếm một yêu cầ portmap GETPORT  ip_proto Cú pháp: ip_proto:[!|>|<] ; Dùng chặn những giao thức nằm trong header của gói TCP, những giao thức này được chỉ định trong tập tin /etc/protocols. Ví dụ: alert ip any any -> any any (ip_proto:igmp;) alert ip any any -> any any (ip_proto:2;) Hai rule trên cùng ý nghĩa vì igmp có số là 2, rule trên dùng theo dõi traffic igmp đi qua mạng.  sameip Cú pháp: sameip; 41 Dùng kiểm tra gói tin có IP source và destination trùng nhau, chức năng này thường ít được sử dụng hoặc chỉ để sử dụng bởi các nhà phát triển kiểm tra sản phẩm. Với dạng tấn công Land Attack, thì sameip tỏ ra hiệu quả trong việc ngăn chặn gói tin có cùng IP nguồn và đích.  stream_reassemble Cú pháp: stream_reassemble:, [, noalert][, fastpath]; Chức năng này cho bật (enable) hoặc tắt (disable) chức năng tái hợp luồng TCP. noalert: không tạo ra cảnh báo khi luật trùng với gói tin. fastpath: tạo ra tình huống có một số gói tin bị bỏ qua. stream_reassemble là một chức năng mới được pháp triển dựa trên stream5, vì thế chức năng stream5 phải được bật khi sử dụng stream_reassemble.  stream_size Cú pháp: stream_size:, , ; Cho phép theo dõi lưu lượng dựa vào số byte chỉ định. Các toán tử (operator) có thể dùng là: <, >, =, !=, <=, >=. 3.3.4 Nhóm Post-Detection  logto Cú pháp: logto:"filename"; Chỉ định vị trí ghi log khi rule được so trùng. Chức năng này co ích khi kết hợp với các rule để phát hiện các cuộc quét mạng bằng nmap, http cgi…  session Cú pháp: session: [printable|all]; 42 Chức năng này cho phép bắt những ký tự dạng clear-text và xuất ra màn hình, session hỗ trợ khá mạnh mẽ cho việc xác định kẻ tấn công xử dụng những lệnh nào xâm nhập hệ thống cũng như account, password ở dạng clear-text… Printable: hiện những ký tự đọc được. All: tất cả ký tự dạng hex.  Resp Cú pháp: resp:; Trong đó = rst_snd | rst_rcv | rst_all | reset_source | reset_dest | reset_both | cmp_net | icmp_host | icmp_port | icmp_all Resp bật tính năng active respond, hủy những kết nối nguy hại bằng cách reset kết nối đó.  React React bật tính năng active respond đến kết nối client (có thể gởi một website hoặc một nội dung chỉ định) và sau đó ngắt kết nối. react hoạt động trong chế độ passive và inline.  Tag Cú pháp: tag:, , [, direction]; Dùng đánh dấu những gói theo chỉ định, việc đánh dấu là hữu hiệu cho việc dự báo một cuộc tấn công có thể xảy ra.  Activates Cú pháp: activates:1; Chỉ định một rule khác được bật khi xuất hiện sự trùng khớp.  Activated_by Cú pháp: activate_by:1; 43 Thực thi một rule khác khi rule hiện tại xuất hiện sự trùng khớp.  Count Count phải được sử dụng cùng với activate_by, count chỉ định cho phép bao nhiêu gói tin ra ngoài từ lúc rule được thực thi. activated_by:1; count:50;  replace Cú pháp: replace: “string”; Replace được dùng trong chế độ inline cho việc thay thế một chuỗi ký tự khi có sự so trùng xuất hiện trong trường content xuất hiện gần nhất. Replace hữu hiệu cho việc phòng chống kẻ tấn công dùng những lệnh để khai khác hệ thống.  Detection_filter Cú pháp: detection_filter: track , count , seconds ; Detection_filter định nghĩa một tỷ lệ nguồn hoặc đích cần phải đi qua trước khi tạo ra sự kiện. Option track by src|by dst count c seconds s Description Rate is tracked either by source IP address or destination IP address. This means count is maintained for each unique source IP address or each unique destination The maximum number of rule matches in s seconds allowed before the detection filter limit to be exceeded. C must be nonzero. Time period over which count is accrued. The value must be nonzero. Event Suppression Cú pháp: 44 suppress \ gen_id , sig_id , \ track , ip Đây là một tính năng cho phép ngăn các cảnh báo do người quản lý chỉ định mà không cần can thiệp vào những rule đã được định nghĩa trước đó. Việc ngăn cảnh báo dựa vào cơ chế CIDR block để chỉ định dãy IP hoặc mạng muốn thực hiện. Suppression yêu cầu bắt buộc tham số gid và sid, các tham số track và ip là tùy chọn. Tính ưu tiên cảu suppression cao hơn so với thresholds, việc ngừng cảnh báo xảy ra ngay tức thời hoặc khi có lưu lượng từ dãy IP đã được chỉ định. Ví dụ: suppress gen_id 1, sig_id 1852 suppress gen_id 1, sig_id 1852, track by_src, ip 10.1.1.54 suppress gen_id 1, sig_id 1852, track by_dst, ip 10.1.1.0/24 Event logging Cú pháp: config event_queue: [max_queue [size]] [log [size]] [order_events [TYPE]] Snort hỗ trơ việc ghi log nhiều sự kiện trên một gói tin hoặc luồng tin được ưu tiên với những kiểu lồng ghép khác nhau như dựa vào max content lengh hoặc event ordering…Ta cấu hình trong tập tin snort.conf max_queue [size] log [size] Chỉ định số kích thước tối đa trong hàng đợi sự kiện. Giá trị mặc định là 8. Chỉ định số sự kiện tối đa được ghi log, nếu số sự kiện vượt qua số lượng chỉ định thì những sự kiện sau sẽ không được ghi log. Giá trị mặc định là 3. 45 order_events [TYPE] Chỉ định những cách mà sự kiện đến, có 2 kiểu là: priority: ưu tiên sự kiện được yêu cầu trước, giá trị 1 là cao nhất. content length: nội dung là những rule trước khi được xử lý trong quá trình decode và proprocessor, những rule có nội dug dài hơn sẽ được xử lý trước. 46 CHƯƠNG II: TRIỂN KHAI SNORT 1. YÊU CẦU Snort được triển khai với mục tiêu theo dõi hoạt động của mạng, vì vậy yêu cầu khắc khe về việc tối ưu máy chủ Snort là yêu cầu không thể thiếu. Snort hỗ trợ trên khá nhều hệ điều hành và nền tảng khác nhau, nên người dùng dễ dàng lựa chọn nền tảng phù hợp để triển khai trên cơ sở hạ tầng đã tồn tại trước đó. Hệ điều hành: Phụ thuộc người dùng. Thiết bị phần cứng yêu cầu cần phải đáp ứng những tiêu chí như sau: CPU: tối thiểu Pentium 4 trở lên, có thể tối ưu nếu có hỗ trợ công nghệ đa luồng (Hyper-Threading technology) vì Snort cần xử lý những luồng tin đi qua nó là khá lớn nên CPU sẽ giúp giảm thời gian xử lý. RAM: yêu cầu RAM khi thực thi Snort là khá cao, do dữ liệu phải được giữ lại để so trùng theo thứ tự nên RAM càng lớn sẽ giúp máy chủ Snort có thể chứa được nhiều hơn trên hàng đợi HDD: trong các cuộc tấn công có quy mô lớn và thường xuyên với nhiều dãy IP(s) khác nhau, thì việc ghi log cuộc tấn công đòi hỏi một dung lượng có thể đáp ứng được yêu cầu. Snort có thể ghi log thành tập tin dạng text, pcap, binary, database…Số vòng quay cho việc truy xuất vừa ghi, vừa đọc cần được quan tâm đến, vì thời điểm này máy chủ sẽ hoạt động với công suất cao để chống lại tấn công. Network Interface: để tối ưu, máy chủ Snort yêu cầu ít nhất 2 card mạng cho cả chế độ inline và IPS (hoạt động với SnortSAM). Tùy vào trường hợp sử dụng mà NIC(s) sẽ phát huy ưu điểm:với chế độ Inline (xem mục 5.1), thì 2 card mạng giúp cho đường truyền được thông suốt và trong suốt với người dùng. Còn khi kết hợp SnortSAM (xem mục 5.2) thì card thứ nhất chỉ nhận luồng tin đi vào liên tục, trong khi card còn lại có nhiệm vụ gởi những thông báo đến thiết bị chặn như firewall hoặc router. Nhiệm vụ được phân rõ trên từng card mạng giúp cho việc thông báo và chặn 47 được nhanh chóng. 48 2. CÀI ĐẶT Chuẩn bị các tập tin và gói cài đặt hỗ trợ Ta tiến hành cài các gói sau đây bằng lệnh yum: yum install httpd yum install php php-common php-gd php-cli php-mysql yum install mysql mysql-devel mysql-bench mysql-server yum install php-pear-Numbers-Roman php-pear-Numbers-Words php-pearImage-Color php-pear-Image-Canvas php-pear-Image-Graph /etc/init.d/httpd start /etc/init.d/mysqld start chkconfig httpd on chkconfig mysqld on Gói cài đặt httpd php-common php-gd php-cli php-mysql Mô tả Dịch vụ Web Apache. Các gói php. Cài đặt hệ cơ sở dữ mysql mysql-devel mysql-bench mysql-server liệu php-pear-Numbers-Roman php-pear-Numbers- MySQL. Các gói đồ họa hỗ trợ Words php-pear-Image-Color php-pear-Imageviệc kết xuất đồ thị thống kê. Canvas php-pear-Image-Graph Download các gói cài đặt sau: Tập tin libpcap-1.0.0.tar.gz pcre-8.12.tar.gz libdnet-1.11.tar.gz barnyard2-1.9.tar.gz daq-0.5.tar.gz Snort-2.9.0.5.tar.gz Các tập tin Mô tả Hỗ trợ việc bắt gói tin lưu thông. Thư viện hỗ trợ thực thi ngôn ngữ pear dùng cho php apache và những Snort. hàm API để có thể truy xuất trên nhiều Cung cấp giao thức khác nhau. Barnyard hỗ trợ việc xuất dữ liệu từ Snort, quản lý những sựcầu kiệntừgởi đếnbản cơ sở dữ trở liệuvề sau. Daq yêu phiên 2.9.0 Gói cài đặt chính chương trình Snort trên chúng ta có thể tham chiếu tại địa chỉ http://www.snort.org/start/requirements, riêng tập tin Snort-2.9.0.5.tar.gz chúng ta download tại http://www.Snort.org/snort-downloads . 49 Download tập tin chứa Rules: Tải tập tin tên Snortrules-snapshot-2905.tar.gz tại http://www.Snort.org/snort-rules. Download BASE (Basic Analysis and Security Engine), Adodb. Tiến hành tải hai tập tin: Tập tin base-1.4.4.tar.gz adodb511.tgz Đường dẫn http://sourceforge.net/projects/secureideas/files/BASE/bas e-1.4.4/ http://sourceforge.net/projects/adodb/files/adodb-php5only/adodb-511-for-php5/ Tiến hành cài đặt: Ta chép các tập tin đã tải về vào chung một thư mục, sau đó tiến hành giải nén, biên dịch và cài đặt các gói tin. Trong CLI ta chuyển đến thư mục chứa các tập tin, lần lược thực thi những lệnh sau: tar -zxvf libpcap-1.0.0.tar.gz; tar -zxvf pcre-8.12.tar.gz; tar -zxvf libdnet-1.11.tar.gz; tar -zxvf barnyard2-1.9.tar.gz; tar -zxvf daq-0.5.tar.gz; tar -zxvf snort-2.9.0.5.tar.gz; cd libpcap-1.0.0; ./configure && make && make install; cd ../pcre-8.12; ./configure && make && make install; cd ../libdnet-1.11; ./configure && make && make install; cd ../barnyard2-1.9; ./configure && make && make install; cd ../daq-0.5; ./configure && make && make install; cd ../snort-2.9.0.5; 50 ./configure --enable-ipv6 --enable-gre --enable-mpls --enable-targetbased -enable-decoder-preprocessor-rules --enable-ppm --enable-perfprofiling -enable- zlib --enable-active-response --enable-normalizer --enable-reload -enable-react -enable-flexresp3 --with-mysql --enable-dynamicplugin && make && make install cd ..; rm -rf libpcap-1.0.0 pcre-8.12 libdnet-1.11 barnyard2-1.9 daq-0.5; Ghi chú: Chúng ta có thể tạo một tập tin với phần mở rộng *.sh và nội dung như trên để thực hiện cài đặt tự động. Ta kiểm tra Snort hoạt động bằng cách thực thi lệnh như sau: [root@SnortIDS ~]#Snort –V Hình 11: Hoàn thành cài đặt 3. CẤU HÌNH CƠ BẢN Sniffing mode Tại chế độ này Snort sẽ thực thi như một chương trình bắt gói tin. Chạy Snort ở chế độ sniffing bằng cách thêm vào tham số -v (chỉ bắt gói TCP), -d (TCP, UDP, ICMP), e (bao gồm header ở layer 2). 51 Hình 12: Snort ở chế độ sniffing IDS mode Tại CLI ta lần lượt thực thi những lệnh sau: mkdir /etc/snort mkdir /var/log/snort mkdir /usr/local/lib/snort_dynamicrules tar -xvf snortrules-snapshot-2905.tar.gz -C /etc/snort cp /etc/snort/so_rules/precompiled/FC-12/i386/2.9.0.5/*.* /usr/local/lib/snort_dynamicrules Kiểm tra hoạt động tập tin cấu hình snort.conf, ta thực hiện lệnh: snort -c /etc/snort/etc/snort.conf –T Sau khi kiểm tra các đường dẫn, rules, các tham số hoạt động v.v… được cấu hình trong /etc/snort/etc/snort.conf, màn hình thông báo thành công. [root@SnortIDS ~]# Snort -c /etc/snort/etc/snort.conf -T Running in Test mode --== Initializing Snort ==-52 Initializing Output Plugins! Initializing Preprocessors! Initializing Plug-ins! Parsing Rules file "/etc/snort/etc/snort.conf" PortVar 'HTTP_PORTS' defined : [ 80 311 591 593 901 1220 1414 1830 2301 2381 2809 3128 3702 5250 7001 7777 7779 8000 8008 8028 8080 8088 8118 8123 8180:8181 8243 8280 8888 9090:9091 9443 9999 11371 ] PortVar 'SHELLCODE_PORTS' defined : [ 0:79 81:65535 ] PortVar 'ORACLE_PORTS' defined : [ 1024:65535 ] PortVar 'SSH_PORTS' defined : [ 22 ] ... Snort successfully validated the configuration! Snort exiting 4. SỬ DỤNG BASE THEO DÕI CẢNH BÁO Bước tiếp theo, ta sẽ tạo một cơ sở dữ liệu MySQL để lưu thông tin xuất từ Snort. BASE sẽ dựa vào MySQL database thống kê lượng, loại dữ liệu đi qua IDS. Tạo MySQL database. Thực thi những lệnh sau tại CLI: /etc/init.d/mysqld start #khởi động dịch vụ mysql. chkconfig mysqld on #cấu hình để mysql khởi động cùng hệ điều hành. mysqladmin -u root password 123456 #thay đổi password cho tài khoản root dùng MySQL. mysql –u root –p“123456” #đăng nhập bằng tài khoản root mysql> create database snort; #tạo một table với tên Snort. mysql> grant CREATE,INSERT,SELECT,DELETE,UPDATE on snort.* to snort; mysql>grant CREATE,INSERT,SELECT,DELETE,UPDATE on snort.* to snort@localhost; mysql> set password for snort@localhost=password("123456"); 53 Hình 14: Tạo database từ Schema mysql>mysql -u root 2.9.0.5/schemas/create_mysql snort -p"123456"MapIP
'; Hình 23: Nội dung tập tin base_stat_ipaddr.php Ta kiểm tra bằng cách duyệt đến www.hoasen.edu.vn Tại trang thống kê ta thấy được như hình dưới: Với 209.85.175.101 là địa chỉ của www.hoasen.edu.vn và liên kết MapIP là phần mà ta đã thêm vào trước đó. 59 Hình 24: Kiểm tra liên kết MapIP Nhấn vào liên kết MapIP để xác định vùng của IP. Hình 6. THEO DÕI 25: Vùng IP tên miền hoasen.edu.vn NHỮNG CẢNH BÁO SNORT TRÊN GOOGLEEARTH. 60 Việc chèn một liên kết vào base_stat_ipaddr.php trong BASE thuận lợi cho việc xác định cho một hoặc vài IP cố định, trong trường hợp có nhiều dãy IP kết hợp tấn công thì ta cần kết hợp với GoogleEarth để thống kê tình trạng vùng địa lý và lượng gói tin gởi đến máy chủ mà Snort đang bảo vệ. Để thực hiện việc này, ta sử dụng một plugin kết hợp với Snort có tên là SnoGE. SnoGE đọc thông tin từ tập tin log ghi nhận theo định dạng unifiled2 (thay thế cho unifiled sử dụng trước đó trong Snort), từ đó thống kê và chi tiết hóa dãy IP dựa trên vùng địa lý, hỗ trợ cho quản trị viên theo dõi và đánh giá quy mô tấn công. Ta có thể download phiên bản mới nhất của SnoGE tại http://code.google.com/p/snoge/downloads/list Do plugin này sử dụng Perl để hoạt động, nên yêu cầu cần có Perl trên máy Snort. yum install –y perl cpan Lần lượt thực hiện những lệnh sau trong cli: cpan -i Geo::IP::PurePerl cpan -i Module::Load cpan -i Module::Build cpan -i NetPacket::Ethernet mkdir /tmp/snoge mkdir /usr/local/share/GeoIP cd /tmp/snoge wget http://snoge.googlecode.com/files/snoge-1.8.tgz wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz wget http://snort-unifiedperl.googlecode.com/files/SnortUnified_Perl.20100308.tgz gunzip GeoLiteCity.dat.gz cp GeoLiteCity.dat /usr/local/share/GeoIP/ tar xvf SnortUnified_Perl.20100308.tgz cd SnortUnified/ 61 cp SnortUnified.pm /usr/local/lib/perl5 cp -r SnortUnified /usr/local/lib/perl5 62 tar xvf snoge-1.8.tgz cd snoge-1.8 cp unified-example.conf unified2.conf vi unified2.conf #chỉnh sửa tập tin unified2.conf để thay đổi một vài tham số. kmlfile=/var/www/html/snoge/snoge.kml sensors=hoasen.edu.vn basefilename=/var/log/snort/snort.alert classification=/etc/snort/etc/classification.config sid-msg=/etc/snort/etc/sid-msg.map gen-msg=/etc/snort/etc/gen-msg.map defaultlocation=hoasen.edu.vn updateurl=http://127.0.0.1/snoge/snoge.kml Thêm dòng sau vào tập tin /etc/snort/etc/snort.conf output alert_unified2: filename snort.alert, limit 128, nostamp Tiến hành cài GoogleEarth Snoge sau khi đọc file /var/log/snort/snort.alert sẽ thống kê thành tập tin snoge.kml (dạng tập tin chương trình GoogleEarth). Vì vậy, ta cài GoogleEarth trên linux hay windows đều được. Cài GoogleEarth ta thực hiện như sau wget https://dl-ssl.google.com/linux/direct/google-earth-stable_current_i386.rpm rpm –ivh google-earth-stable_current_i386.rpm Trường hợp thiếu gói phụ thuộc, ta cần thực hiện cài đặt gói phụ thuộc trước. Ta thực hiện lệnh traceroute đến hai địa chỉ sau traceroute vnexpress.net và traceroute idti.co.uk từ client. Thực thi lệnh sau để tiến hành xuất tập tinh cảnh báo sang dạng bản đồ: ./snoge -c unified2.conf -o /var/log/snort/snort.alert -v #lệnh này thực hiện đọc tập tin snort.alert một lần và xuất ra kết quả, trường hợp 63 muốn SnoGE cập nhật liên tục, ta dùng lệnh sau: ./snoge -c unified2.conf -r -v Hình 26: Tiến trình khởi tạo SnoGE Hình 27: Tập trin kml tạo bởi Truy cập http://127.0.0.1/snoge/ SnoGE 64 Mở tập tin snoge.kml bằng chương trình GoogleEarth. 65 Hình 28: SnoGE chỉ rõ vùng IP kết nối đến server Snoge tạo đường dẫn đến những vùng địa lý IP xuất hiện. Ngoài ra, ta còn có thể xem tình trạng tấn công theo thời gian thực (real time) khi cấu hình GoogleEarth. Hình 29: SnoGE tạo cột ước lượng cảnh báo từ vùng IP xác định 66 7. TÙY CHỈNH CẤU HÌNH SNORT.CONF Tại phần này, ta sẽ cấu hình những tham số trong tập tin snort.conf. Tại đây ta có thể cấu hình những thành phần sau: 1) Set the network variables. 2) Configure the decoder 3) Configure the base detection engine 4) Configure dynamic loaded libraries 5) Configure preprocessors 6) Configure output plugins 7) Customize your rule set 8) Customize preprocessor and decoder rule set 9) Customize shared object rule set Khai báo biến Snort có 3 loại biến: var ipvar portvar Kiểu var dùng khai báo địa chỉ IP hoặc một subnet chỉ rõ IDS cần theo dõi những mục tiêu nhất định, ipvar dùng tương tự như var nhưng hỗ trợ IPv6. Các kiểu khai báo IP: ipvar HOME_NET any #theo dõi trên tất cả địa chỉ IP. ipvar HOME_NET 192.168.1.0/24 #khai báo trên một lớp mạng. ipvar HOME_NET [192.168.1.0/24,10.0.0.0/8] #khai báo trên hai lớp mạng. ipvar HOME_NET [172.0.0.28,192.168.1.0/24,10.0.0.0/8] #khai báo một địa chỉ Ip xác định và hai lớp mạng. ipvar HOME_NET [192.168.1.0/24![192.168.1.2,192.168.1.35]] #khai báo một lớp mạng, nhưng thông không theo dõi với hai địa chỉ 192.168.1.2 và 192.168.1.35 HOME_NET: gán IP, subnet mạng bên trong. EXTERNAL_NET: gán IP, subnet mạng bên ngoài. 67 Khai báo IP các server dịch vụ: Ta có thể cấu hình các server sau trong Snort, mặc định các giá trị này là any, chúng ta nên chỉ rõ vị trí của từng server để tạo thuận lợi cho việc phát triển các rule về sau, trong các hệ thống phân tán thì việc chỉ rõ dãy IP cho cụm máy chủ là quan trọng cho việc kiểm soát: DNS_SERVERS SMTP_SERVERS HTTP_SERVERS SQL_SERVERS TELNET_SERVERS SSH_SERVERS Các kiểu khai báo port: portvar EXAMPLE 80 portvar EXAMPLE [80:90] #khai báo dãy port từ 80 đến 90. portvar EXAMPLE [80,443,539] #khai báo những port chỉ định. Cấu hình đường dẫn: var RULE_PATH /etc/snort/rules var SO_RULE_PATH /etc/snort/so_rules var PREPROC_RULE_PATH /etc/snort/preproc_rules Cấu hình decoder Đây là quá trình giải mã gói tin mà Snort bắt được, việc giải mã gói tin giúp cho việc phân tích gói tin đi vào chứa những thông tin gì từ đó quyết định hành động 68 phản ứng. Decoder phân tích dựa trên nhiều thành phần như header, IP, độ dài gói tin… Bảng dưới liệt kê các chức năng của phần decoder, mún thực hiện decoder nào thì chỉ cần bỏ dấu # phía trước. # Stop generic decode events: config disable_decode_alerts # Stop Alerts on experimental TCP options config disable_tcpopt_experimental_alerts # Stop Alerts on obsolete TCP options config disable_tcpopt_obsolete_alerts # Stop Alerts on T/TCP alerts config disable_tcpopt_ttcp_alerts # Stop Alerts on all other TCPOption type events: config disable_tcpopt_alerts # Stop Alerts on invalid ip options config disable_ipopt_alerts # Alert if value in length field (IP, TCP, UDP) is greater the length of the packet # config enable_decode_oversized_alerts # Same as above, but drop packet enable_decode_oversized_alerts) # config enable_decode_oversized_drops if in Inline mode (requires # Configure IP / TCP checksum mode config checksum_mode: all # Configure maximum number of flowbit references. information, see README.flowbits # config flowbits_size: 64 For more # Configure ports to ignore # config ignore_ports: tcp 21 6667:6671 1356 # config ignore_ports: udp 1:17 53 # Configure active response for non inline operation. For more information, see REAMDE.active 69 # config response: eth0 attempts 2 Chú ý: cần nắm rõ từng chức năng khi sử dụng. Base Detection Engine Tại phần này, ta có thể tinh chỉnh các giá trị để tối ưu việc bắt gói sao cho có hiệu quả. Dynamic libraries Chỉ rõ đường dẫn đến các thư mục chứa tập tin thư viện để Snort làm việc: # path to dynamic preprocessor libraries dynamicpreprocessor directory /usr/local/lib/snort_dynamicpreprocessor/ # path to base preprocessor engine dynamicengine /usr/local/lib/snort_dynamicengine/libsf_engine.so # path to dynamic rules libraries dynamicdetection directory /usr/local/lib/snort_dynamicrules Preprocessor Cấu hình bật/tắt bằng cách bỏ/thêm dấu # trước cấu hình preprocessor. Bước này đóng vai trò quan trọng trong cơ chế (engine) hoạt động của Snort. Các preprocessor có trong Snort bao gồm: Normalize, frag3, stream5,http_inspect, bo (Back office detection), ftp_telnet, smtp, sfportscan, arpspoof, dcerpc2, dns, ssl, sensitive_data. Những preprocessor sẽ giữ những chức năng riêng cho việc phát hiện nguy cơ tấn công, có những preprocessor phát hiện tấn công bất thường, Snort dựa vào những chỉ số cấu hình này để tham chiếu với thực tế, dẫn đến kết quả thông báo ra Output Cấu hình output 70 Đây là phần khai báo cấu trúc, kiểu kết xuật dữ liệu từ Snort đưa ra. Có các dạng xuất tiêu biểu như sau: xuất ra file log/Pcap/Database… Cấu hình tùy chọn Tại bước 8 và 9 trong tập tin cấu hình snort.conf, đây là phần cấu hình tùy chọn do người dùng chỉnh sửa nội dung khi phát triển những nhu cầu phát sinh. Những cấu hình trong phần này giúp cho người dùng dễ quản lý bật/tắt cho những kiểm tra tùy chọn khi triển khai trên thực tế. Customize your rule set Customize preprocessor and decoder rule set 71 CHƯƠNG III: XÂY DỰNG SNORT IPS 1. SNORT INLINE 1.1. Giới thiệu Snort Inline là một tùy chọn trong Snort 2.1 trở lên, nó có thể hoạt động như một IPS, chức năng inline có thể kích hoạt trong phiên bản cài đặt chính hoặc có thể cài đặt riêng từ gói snort_inline-2.6.1.5.tar.gz tại http://snortinline.sourceforge.net/download.html. Snort Inline yêu cầu cài đặt libnet, libpcap và iptables hoặc netfilter (gồm 2 gói libnfnetlink, libnetfilter_queue). Phiên bản snort 2.1 về sau hỗ trợ chế độ -daq nfq giúp cải thiện tốc độ truy vấn gói tin từ iptables so với việc truy vấn ở chế độ --daq ipq truyền thống được sử dụng trước đó. Với nhiệm vụ phục vụ cho hệ thống máy chủ thì nfq là một khuyến cáo hàng đầu cho việc triển khai Snort ở chế độ inline. Chế độ inline hoạt động dựa vào việc truy xuất queue tại iptables, từ đó thông tin phân tích sẽ được so sánh trước khi đi vào hệ thống, giảm thiểu nguy cơ gây xâm nhập vào hệ thống một các tối ưu. Vì inline nằm giữa vị trí server và các kết nối khác dẫn đến việc nếu máy chủ Snort inline gặp sự cố thì cũng dẫn đến kết nối này bị gián đoạn. 1.2. Triển khai Hình 30: Sơ đồ triển khai Snort Inline 72 Snort inline hoạt động trong suốt đối với đường truyền, vì thế tại máy chủ snort ta không cấu hình ip để tránh hacker có thể phát hiện sự tồn tại của IDS, ta cấu hình bridge 2 network interfaces (eth0, eth1) với nhau. Tại máy chủ snort, ta cấu hình trong như sau: Thêm rule mới vào cuối tập tin /etc/snort/rules/content-replace.rules (dùng kiểm tra): alert tcp any any -> 172.0.0.1 80 (msg: "Replace PhotographyBB logo"; content: "logo1.png"; nocase; replace: "logo2.png"; sid: 1000010;) # rule sẽ thực hiện thay thế chuỗi logo1.png bằng chuỗi logo2.png cho những truy xuất đến web server. Thực thi trong CLI để tạo bridge giữa 2 interfaces: ifconfig eth0 0.0.0.0 promisc up ifconfig eth1 0.0.0.0 promisc up brctl addbr br0 brctl addif br0 eth0 brctl addif br0 eth1 ifconfig br0 0.0.0.0 promisc up echo 1 > /proc/sys/net/ipv4/ip_forward #Trường hợp brctl không tồn tại thì ta cần cài thêm bridge-utils. Thực hiện cấu hình theo 1 trong 2 bảng dưới đây: Sử dụng ipq: Yêu cầu cài gói iptables-1.4.10.tar.bz2 (./configure --enable-libipq && make && make install) modprobe ip_queue iptables -F iptables -A FORWARD -j QUEUE snort -Q --daq ipq -N -c /etc/snort/etc/snort.conf Sử dụng nfq: 73 Yêu cầu cài libnfnetlink những gói trong bộ netfilter (yum -y install libnfnetlink-devel libnetfilter_queue libnetfilter_queue-devel). modprobe nfnetlink_queue modprobe nfnetlink iptables -F iptables -A FORWARD -j NFQUEUE snort -Q --daq nfq -N -c /etc/snort/etc/snort.conf Kiểm tra kết quả: Hình 31: Trang web gốc 74 Hình 2. 32: Nội dung bị thay đổi khi gói tin đi qua Snort Inline SNORT SAM 2.1. Giới thiệu SnortSam là một plug-in miễn phí hỗ trợ cho Snort, với plug-in này Snort có thể trở thành một hệ thống IPS. SnortSam nhận trách nhiệm quá trình giao tiếp, điều khiển giữa các máy cài Snort bên trong (IDS) với các hệ thống ngăn chặn chuyên dụng khác có chức năng hoạt động như firewall. Các thiết bị hiện tại SnortSam đang hỗ trợ hiện nay là khá đa dạng, phù hợp với nhiều nền tảng: CheckPoint, Cisco PIX, ACL (Router Cisco), Juniper, iptables (Linux/Unix), Microsoft ISA… SnortSam có hai phần là plug-in được cài đặt trên máy đã cài sẵn Snort và một agent chạy trên firewall hoặc một máy gần firewall để giao tiếp cho việc ngăn chặn. 2.2. Triển khai Hiện tại, khi đề tài của tôi được thực hiện, SnortSam đã phân phối phiên bản 2.7.0, hỗ trợ cho Snort từ phiên bản 2.8.0.1 – 2.9.0.3. Tiến hành download 02 tập tin: snortsam-src-2.70.tar.gz và snortsam-2.9.0.3.diff.gz 75 tại http://www.snortsam.net/download.html. 76 2 tập tin tải về được đặt tại thư mục /tmp/snortsam và thư mục chứa gói cài đặt Snort là /tmp/snort-2.9.0.5 Lần lượt thực hiện những lệnh sau trong CLI: Cài đặt SnortSam patch: #cd /tmp/snort-2.9.0.5 # patch -p1 < ../ snortsam-2.9.0.3.diff #chmod 755 autojunk.sh #./autojunk.sh Tiến hành cấu hình, biên dịch và cài đặt lại snort. #./configure && make && make install Cài đặt SnortSam source: #tar –xvf snortsam-src-2.70.tar.gz #cd snortsam #./makesnortsam.sh #cp snortsam /usr/local/bin #mkdir /etc/snortsam #cp conf/snortsam.conf.sample /etc/snortsam/snortsam.conf 2.2.1. Triển khai SnortSam và iptables Hình 33: Sơ đồ triển khai Snort Sam 77 Tại Web server, ta cấu hình lại tập tin /etc/snort/etc/snort.conf output alert_fwsam: 193.168.1.1/idspassword #idspassword là pass dùng để xác nhận thông tin khi lệnh được gởi đến firewall. Tiếp tục tạo một rule trong /etc/snort/rules/icmp.rules để kiểm tra: alert icmp any any -> 193.168.1.2 any (fragbits: D; msg: "Set Don't Fragment flag in packet"; sid: 1000001; fwsam: src,1 hour;) Tại firewall, ta cấu hình tập tin /etc/snortsam/snortsam.conf accept 193.168.1.2/24,idspassword bindip 193.168.1.1 iptables eth1 logfile /var/log/snortsam.log Tiếp tục cấu hình iptables cho việc nat địa chỉ, trong CLI, thực thi những lệnh sau: echo 1 > /proc/sys/net/ipv4/ip_forward iptables -t filter -P OUTPUT ACCEPT iptables -t filter -P INPUT ACCEPT iptables -t filter -P FORWARD ACCEPT iptables -t nat -P POSTROUTING ACCEPT iptables -t nat -P PREROUTING ACCEPT iptables -t nat -I PREROUTING -i eth1 -d 192.168.1.1 -j DNAT --todestination 193.168.1.2 iptables -t nat -I POSTROUTING -o eth1 -s 193.168.1.0/24 -d 0/0 -j MASQUERADE Sau khi cấu hình, ta khởi chạy lần lượt như sau: Tại firewall, ta thực thi lệnh snortsam /etc/snortsam/snortsam.conf. 78 Hình 34: Tiến trình khởi động Snort Sam Tại web server, ta thực thi lệnh snort –c /etc/snort/etc/snort.conf. Hình 35: Thông tin kết nối thành công đến iptables firewall Từ máy client (Windows Platform), ta tiến hành ping máy web server lần lượt với lệnh ping 193.168.1.2 thì gói tin trả về bình thường và ping 193.168.1.2 –f (ping don’t fragment) thì chỉ có 1 gói tin được đi đến đích, các gói còn lại đã bị chặn lại như hình dưới. 79 Hình 36: Kiểm tra firewall với 2 kiểu ping Kiểm tra iptables trên firewall ta thấy gói tin đã bị drop: Hình 37: Thông tin tại iptables 80 Tiến trình ngăn chặn gói tin từ địa chỉ 192.168.1.2 được xảy ra tại firewall, do iptables đảm nhận drop các gói tin. Quá trình xảy ra torng vòng 1 giờ (3600 giây), được quản lý bởi tập tin /var/db/snortsam.state và tập tin ghi log /var/log/snortsam.log. Hình 2.2.2. 38: Thông tin thông báo từ SnortSam Triển khai SnortSam và ACL trên router Cisco Hình Interface fa0/0 fa0/1 fa1/2 eth1 (IDS) Server 39: Sơ đồ trển khai SnortSam và ACL Address 192.168.1.1/24 10.0.0.1/8 Span port 10.0.0.250/8 10.0.0.2/8 Sự kết hợp giữa SnortSam để thông báo đến router ngăn chặn truy xuất trái phép là một điểm mạnh thường được áp dụng trên mô hình mạng thực tế. 81 Những 82 luồng tin đi đến webserver được Snort kiểm tra xem có hợp lệ không, nếu không hợp lệ Snort sẽ báo đến SnortSam, tiếp đến SnortSam gởi truy vấn đến cho router chặn lại những gói tin có địa chỉ nguồn gây nguy cơ xâm hại hệ thống thông qua ACL(s). Tại IDS, ta thực hiện những bước sau: Tạo tập tin snortsamacl trong thư mục /etc/snortsam với nội dung: configure terminal interface f0/0 no ip access-group snortsamacl in exit no ip access-list extended snortsamacl ip access-list extended snortsamacl snortsam-ciscoacl-begin snortsam-ciscoacl-end permit icmp any any permit tcp any any eq www deny ip any any exit interface f0/0 ip access-group snortsamacl in end Chỉnh nội dung tập tin /etc/snortsam/snortsam.conf accept 10.0.0.250/8,snortsampass bindip 10.0.0.250 logfile /var/log/snortsam.log ciscoacl 10.0.0.1 123456 cisco /etc/snortsam/snortsamacl Chỉnh sửa nội dung tập tin /etc/snort/etc/snort.conf output alert_fwsam: 10.0.0.250/snortsampass Tại router, ta thực hiện cấu hình như sau: enable config terminal hostname SnortSAM 83 no ip domain lookup int f0/0 ip add 192.168.1.1 255.255.255.0 no shut exit int f0/1 ip add 10.0.0.1 255.255.255.0 no shut exit ip nat inside source static 10.0.0.2 int f0/0 int f0/0 ip nat outside int f0/1 ip nat inside enable password cisco line vty 0 4 password 123456 login end Tại switch: enable config terminal host switch monitor session 1 source int f1/1 monitor session 1 des int fa1/2 exit Tiến hành theo dõi tại IDS bằng cách thực thi 2 lệnh sau: snortsam /etc/snortsam/snortsam.conf snort –c /etc/snort/etc/snort.conf –I eth0 84 Từ máy có IP 192.168.1.3 ta thực hiện lệnh ping 10.0.0.2 và ping 10.0.0.2 –f , kiểm tra kết quả: Hình 40: Kiểm tra firewall với 2 kiểu ping Với lệnh ping thông thường, gói tin được lưu thông bình thường. Nhưng với ping với tùy chọn –f thì gói tin bị chặn lại sau khi IDS nhận diện thành công dấu hiệu trùng với rule. Kiểm tra thông tin trên web server và router: 85 Hình 41: Thông báo khi gởi lệnh đến Router Cisco Tại IDS, ta thấy IDS gởi yêu cầu block địa chỉ nguồn của gói tin. Sau 60 giây, địa chỉ này vẫn có thể tiếp tục sử dụng. Hình 42: Thông tin thông báo giải phóng việc chặn kết nối Kiểm tra tại router, ta thấy những access-list được áp dụng để chặn nguồn gói tin: 86 Hình 43: ACL được tạo ra cho việc chặn kết nối 87 CHƯƠNG IV: TÌM HIỂU CÁC LUẬT DÙNG TRONG SNORT 1. NGUYÊN TẮC VIẾT LUẬT Một luật (rule) có thể viết trên một dòng liên tục hoặc có thể viết trên nhiều dòng. Nếu luật được viết trên nhiều dòng thì cuối dòng phải có dấu ‘\’ (slash). Ví dụ: alert tcp $HTTP_SERVERS $HTTP_PORTS -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES index of /cgi-bin/ response"; flow:from_server,established; content:"Index of /cgi-bin/"; nocase; reference:nessus,10039; classtype:bad-unknown; sid:1666; rev:5;) Luật viết trên một dòng alert tcp $HTTP_SERVERS $HTTP_PORTS -> $EXTERNAL_NET (msg:"ATTACK-RESPONSES index of /cgi-bin/ response"; \ flow:from_server,established; content:"Index of /cgi-bin/"; nocase;\ reference:nessus,10039; classtype:bad-unknown; sid:1666; rev:5;) Luật viết trên nhiều dòng any Thứ tự thực hiện các phần trong luật: Headers (msg, flow, flowbits, content, PCRE, classtype, reference, sid, rev) Tìm hiểu các luật qua những ví dụ: 2. KHẢO SÁT LUẬT 1 alert udp $HOME_NET any -> $EXTERNAL_NET any (msg:"BACKDOOR netthief runtime detection"; content:"|00 00 00 00 00 00 00 82|"; depth:8; offset:17; threshold:type limit, track by_src, count 1, seconds 600; metadata:policy security-ips alert; reference:url,www3.ca.com/securityadvisor/virusinfo/virus.aspx?ID=16078; classtype:trojan-activity; sid:7760; rev:3;) Rule có SID:7760 dùng phương pháp tìm kiếm nội dung gói tin so trùng với mẫu để xác định hoạt động cập nhật định kỳ của backdoor netthief. 88 Hình 44: Mô phòng luật 7760 content:"|00 00 00 00 00 00 00 82|"; depth:8; offset:17; Snort sẽ kiểm tra payload gói tin từ vị trí thứ 18 đến 25 với nội dung 00 00 00 00 00 00 00 82 ở dạng số hex. 3. KHẢO SÁT LUẬT 2 alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"BOTNET-CNC Clampi virus communication detected"; flow:established,to_server; content:"o=c&s=00000"; nocase; pcre:"/^POST \x2F[A- Z\d]{16} \smi"; threshold:type limit, track by_src, count 1, seconds 300; metadata:impact_flag red, service http; reference:url,www.symantec.com/security_response/writeup.jsp?docid=2008-0116165036-99; classtype:trojan-activity; sid:15423; rev:3;) Với rule có SID: 15423, chúng ta sẽ khảo sát rule với tùy chọn content và pcre. Với rule này, tôi tập trung vào việc xác định những chức năng PCRE được sử dụng trong rule, ta sẽ sử dụng pcretest trong CLI để có thể nhanh chóng xác định mẫu có thể trùng rule đang tìm kiếm. Ta có: pcre:"/^POST \x2F[A-Z\d]{16} /smi"; Tại CLI, ta thực hiện như hình dưới: 89 Hình 45: Kiểm tra cấu trúc PCRE với pcretest Giải thích: pcretest -d # Dùng chương trình pcretest để kiểm tra những chuỗi nào hợp với điều kiện, tùy chọn -d để hiển thị nội dung mà pcre biên dịch từ điều kiện ta cung cấp. re> \^POST \x2F[A-Z\d]{16} \smi xác định mẫu \^POST \x2F[A-Z\d]{16} \smi # Điều kiện ta cung cấp để pcre Phân tích nội dung PCRE biên dịch: -----------------------------------------------------------------0 56 Bra 3 ^ 4 NC POST \ #Yêu cầu phải có ký tự POST \ trong mẫu. 16 [0-9A-Za-z]{16,16} #Yêu cầu có ít nhất 16 ký tự ( A-Z a-z 0-9). 54 NC #Yêu cầu ký tự khoảng trắng ‘ ’. 56 56 Ket 59 End -----------------------------------------------------------------Capturing subpattern count = 0 Options: caseless multiline dotall #Tương đương tùy chọn -i First char at start or follows newline #Tương đương tùy chọn -m Need char = ' ' #Tương đương tùy chọn -s 90 data> POST \1A23cdFgh569dcbB alLdc1 # Chuỗi ký tự ta nhập vào xem có thỏa điều kiện hay không. Nếu kết quảdạng 0: POST \1A23cdFgh569dcbB có alLdc1 thì mẫu tin ta nhập vào thỏa điều kiện kiểm tra, ngược lại là không thỏa. 4. KHẢO SÁT LUẬT 3 alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"BOTNET-CNC Sality virus HTTP GET request"; flow:to_server,established; content:"/mrow_pin/?id"; nocase; http_uri; pcre:"/\x2Fmrow\x5Fpin\x2F\x3Fid\d+[az]{5,}\d{5}\x26rnd\x3D\d+/smi"; metadata:impact_flag red, policy balanced-ips drop, policy security-ips drop, service http; reference:url,www.threatexpert.com/report.aspx?md5=b61aaef4d4dfbddbd8126c987f b77374; classtype:trojan-activity; sid:15553; rev:4;) Với rule có SID: 15553, tôi sẽ tập trung vào phần option chính cho việc kiểm tra gói tin: flow:to_server,established; thành công đến server. #Kiểm tra những kết nối đã được thiết lập content:"/mrow_pin/?id"; nocase; http_uri; #Kiểm tra trường HTTP URI với nội dung \mrow_pin/?id không phân biệt chữ hoa, thường pcre:"/\x2Fmrow\x5Fpin\x2F\x3Fid\d+[a-z]{5,}\d{5}\x26rnd\x3D\d+/smi"; Ta dùng pcretest để biên dịch nội dung pcre nhanh chóng: 91 Hình 46: Tham chiếu nội dung PCRE với pcretest 92 Mẫu trùng với pcre có dạng: \mrow_pin/?id62343vxssse50395&rnd=74781 Ta thử nghiệm bằng cách truy cập đường dẫn http://www.tuoire.vn/mrow_pin/?id62343vxssse50395&rnd=74781 Theo dõi tại IDS, ta thấy có cảnh báo: Hình Hình 47: Metadata trong cảnh báo từ Snort 48: Nội dung gói tin thu thập được trong cảnh báo 93 5. KHẢO SÁT LUẬT 4 alert tcp $SMTP_SERVERS any -> $EXTERNAL_NET (msg:"DELETED 25 VIRUS OUTBOUND .reg file attachment"; flow:to_server,established; content:"Content-Disposition|3A|"; content:"filename=|22|"; within:30; content:".reg|22|"; within:30; nocase; classtype:suspicious-filename-detect; sid:2164; rev:5;) Hình 49: Mô phỏng luật 2164 Rule có SID: 2164 tập trung so mẫu dựa vào việc tìm kiếm một nội dung trong một khoảng xác định bằng từ khóa within. Rule sẽ tìm chuỗi Content-Disposition|3A|, từ vị trí cuối cùng của content đầu tiên, con trỏ tiếp tục tìm chuỗi filename=|22|trong 30 bytes kế tiếp. Tiếp tục từ vị trí cuối cùng của content thứ hai, con trỏ sẽ tiếp tục tìm chuỗi .reg|22| trong 30 bytes tiếp sau đó. 6. KHẢO SÁT LUẬT 5 alert tcp $EXTERNAL_NET $HTTP_PORTS -> any (msg:"WEB$HOME_NET CLIENT Sophos Anti-Virus CAB file overflow attempt"; flow:to_client,established; file_data; content:"MSCF"; byte_test:2,>,8192,22,little,relative; metadata:policy security-ips drop; reference:bugtraq,17876; reference:cve,2006-0994; classtype:attempted-admin; sid:6504; rev:6;) 94 content:"MSCF"; byte_test:2,>,8192,22,little,relative; Chuỗi MSCF sẽ được xác định trong payload. Từ vị trí đã xác định trước đó, con trỏ sẽ dịch chuyển 22 bytes, byte thứ 23 và 24 sẽ đọc ngược lại theo thứ tự byte 24, byte 23 (đọc theo little endian). Giá trị sau khi đọc 2 bytes sẽ được so sánh xem có lớn hơn giá trị 8192 (decimal) hay không. 7. KHẢO SÁT LUẬT 6 Line 17464: alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"WEB-CLIENT Sophos Anti-Virus zip file handling DoS attempt"; flow:to_client,established; content:"PK|03 04|"; content:"|0C 00|"; within:2; distance:4; content:"-|00 00 00 F9 00 00 00 05 00 FF FF|"; within:12; distance:8; metadata:policy security-ips drop, service http; reference:bugtraq,14270; reference:cve,2005-1530; classtype:attempted-dos; sid:15957; rev:2;) content:"PK|03 04|"; content:"|0C 00|"; within:2; distance:4; 8. KHẢO SÁT LUẬT 7 95 Khai thác dựa trên lỗ hổng của Mailenable buffer Overflow. Mã khai thác: tham khảo tại http://downloads.securityfocus.com/vulnerabilities/exploits/x0n3h4ck_mailenable_https.pl Phân tích kịch bản tấn công để tạo Rule: Hình 50: Nội dung mã khai thác mailenable Đoạn code tạo ra một kết nối với giao thức TCP đến đối tượng (victim) với số port là 8080 (số port có thể thay đổi tùy thuộc máy chủ cấu hình). Payload của gói tin có nội dung được gán với biến $richiesta. 96 Hình 51: Shellcode khai thác Biến $richiesta là tập hợp những chuỗi ký tự dạng hex và ascii. Trong đó ta cần quan tâm đến chuỗi 0x6c36b7 tập tin mehttps.exe) và chuỗi x0D0A (đây là chuỗi trả về (return address) từ để xác định kết thúc nội dung từ Client gởi đến, nếu trong một dãy 261 ký tự liên tục không xuất hiện chuỗi kết thúc thì luật sẽ cảnh báo. Đồng thời kiểm tra ‘GET’ và ‘Authorization:’ Thực thi code: 97 Hình 52: Thực thi tấn công lỗ hổng mailenable Hình 53: Kiểm tra kết quả Rule ngăn chặn: alert tcp $EXTERNAL_NET any -> $HOME_NET 8080 (msg:"EXPLOIT MailEnable HTTPMail buffer overflow attempt";\ flow:to_server,established; \ content:"GET";\ content:"Authorization|3A|"; nocase; isdataat:261,relative;\ #luật xem xét có dữ liệu trong 261 bytes từ vị trí cuối cùng của content: "Authorization|3A|"; hay không. content:!"|0D 0A|"; within:261\ #Luật tiếp túc kiểm tra, nếu không có chuỗi kết thúc trong 261 ký tự thì cảnh báo sẽ xuất hiện. reference:bugtraq,13350; reference:cve,2005-1348; \ reference:url,www.frsirt.com/english/advisories/2005/0383; classtype:attemptedadmin; sid:4637; rev:7;) 98 9. KHẢO SÁT LUẬT 8 Tìm hiểu và triển khai rule trên lỗi “MySQL yaSSL SSL Hello Message Buffer Overflow” Lỗi này được khai thác trên lỗi tràn bộ đệm trong phương thức xác thực yaSSL trong quá trình bắt tay (handshake) một kết nối từ client đến server. Kẻ tấn công tiêm nhiễm (inject) một đoạn code độc vào gói tin để khai thác lỗ hổng này. Ta dùng chương trình Metasploit Framwork 3.8 thực thi trên BackTrack OS cho việc thực hiện kiểm tra. Nhưng trước hết ta cần fingerprint bằng nmap. Hình 54: Tiến hành scan mục tiêu 99 Ta nhận thấy dịch vụ MySQL đang hoạt động tại port 3306 và 30000. Khởi khởi tạo cập nhật metasploit bằng lệnh msfupdate, sau đó chạy msfconsole và thực hiện như các bước sau: Hình 55: Khai thác thông qua metasploit Với phương thức tấn công này, hacker hoàn toàn có thể chiếm quyền điều khiển vào hệ thống máy chủ. Sau đây, ta sẽ phân tích mã nguồn và kịch bản của cuộc tấn công để có biện pháp ngăn chặn hợp lý. Phân tích payload: Mã nguồn tham khảo tại: 100 http://dev.metasploit.com/redmine/projects/framework/repository/revisions/8282/ent ry/modules/exploits/windows/mysql/mysql_yassl_hello.rb Payload của gói tin tấn công có chứa thành phần sau: Hình 56: Nội dung chứa trong payload gói tin Trong đó: PrependEncoder là chuỗi sẽ được thêm vào payload gói tin để khi lỗi được khai thác thành công thì attacker sẽ điều khiển shell tại server. Nhưng nếu rule được viết chỉ để ngăn những nội dung độc hại thì tình trạng cảnh báo sai (false positive) do tính xuất hiện đơn lẻ có thể xảy ra với bất kỳ gói tin nào đến. Giả sử ta có rule như sau: alert tcp any any -> $SQL_SERVERS $SQL_PORTS (msg: “MySQL yaSSL overflow”; content: “|81 C4 54 F2 FF|”; sid: 1000002;) Với rule trên thì khi theo dõi sẽ có những trở ngại như sau: 1.Hiệu suất giảm, do luật sẽ kiểm tra tất cả gói tin với nội dung chỉ định. 2.Gây ra cảnh báo sai, do chuỗi có thể xuất hiện ở những ứng dụng khác như HTTP hay FTP… và không gây nguy hiểm cho máy chủ. Để giải quyết khuyết điểm trên, ta tiếp tục phân tích kịch bản tấn công Phân tích kịch bản tấn công: Phân tích một phiên làm việc cho một kết nối đến MySQL Server: 101 Hình 57: Những gói tin trong một phiên tấn công Những gói tin do phía tấn công gởi đến Server, nếu luật được viết chỉ định rõ luồng tin (stream) thì việc kiểm tra gói tin sẽ được chuẩn sát hơn so với theo dõi toàn bộ gói tin. (ghi nhận 1) Hình 58: Tiến trình các gói tin khi xảy ra cuộc tấn công 102 Sơ đồ phiên làm việc: Client tiến hành quá trình handshake bằng cách gởi gói tin ClientHello đến server, và yêu cầu nếu handshake thành công thì sẽ dùng SSL hoặc TLS để mã hóa dữ liệu trên đường truyền. Tiến trình handshake được đóng khung màu đỏ ở hình trên. Hình 59: Nội dung trong mã nguồn Apache Nhưng trong quá trình handshake, máy chủ không kiểm tra số dữ liệu tối đa dẫn đến attacker có thể gây tràn bộ đệm. Với ID_LEN: 32 elements long, MAX_SUITE_SZ: là 64, RAN_LEN (Random): là 32. Phần được tô vàng ở hình trên gây ra overflow cho cipher trong quá trình handshake nếu đó là một giá trị lớn hơn 64. (ghi nhận 2) Trong quá trình handshake thì dữ liệu chưa được mã hóa bởi SSL hoặc TLS. (ghi nhận 3) 103 Hình 60: Gói tin chứa các tùy chọn khi kết tnối đến MySQL Client yêu cầu Server chuyển sang mã hóa SSL sau quá trình handshake thành công. Từ ghi nhận 1, 2 và 3 => rule được triển khai như sau: alert tcp $EXTERNAL_NET any -> $SQL_SERVERS $SQL_PORTS (msg:"MYSQL yaSSL SSLv2 Client Hello Message Cipher Length Buffer Overflow attempt"; \ flow:established,to_server;\ #kiểm tra những luồng đã kết nối đến Server. flowbits:isnotset,sslv2.server_hello.request;\ #không kiểm tra những gói tin Server Hello Request với mã hóa SSL. flowbits:isnotset,tlsv1.server_hello.request;\ (1) flowbits:isnotset,tlsv1.client_hello.request;\ (2) tra những gói tin yêu cầu mã hóa từ client hay # (1), (2) không TLS kiểm server. content:"|01|"; depth:1; offset:6; byte_test:2,>,64,9; \ #đọc 2 bytes dạng hex và kiểm tra có lớn hơn 64 không, nếu giá trị này lớn hơn 64 thì có thể ra overflow. flowbits:set,sslv2.client_hello.request; #kiểm tra những gói Client Hello tin Request. Rule trên đã kết hợp một loạt những quy định về flowbits để chỉ định theo dõi duy nhất việc kết nối từ client trên một phiên làm việc. Việc này giúp rule làm việc chính xác và tăng hiệu xuất làm việc trên rule. Từ khóa byte_test tỏ ra hiệu quả khi 104 kiểm tra giá trị của một số bằng các toán tử, chức năng này hữu dụng trong việc phát hiện ra những dạng tràn bộ đệm. 10. KHẢO SÁT RULE CHỐNG DOS/DDOS TẠI APPLICATION LAYER Theo khảo sát 2010 tại trang www.whitehatsec.com , dạng tấn công Slowloris HTTP Dos là 1 trong kiểu tấn công nguy hiểm gây sập hệ thống 10 đổ mạng. Slowloris HTTP DoS hoạt động chủ yếu đánh vào lớp ứng dụng hoặc nói rõ hơn là tập trung làm sập đổ hệ thống có chứa WEB-Service. Không như những giống cuộc DoS/DDoS ở layer 3 (Ping of Dead, UDP flooding) tập trung vào việc làm nghẽn băng thông của máy chủ, Slowloris HTTP DoS chỉ cần một lượng băng thông thấp (<100kbs) vẫn có thể gây ra tình trạng máy chứa WEB bị ngưng tạm thời. Hình 61: Slowloris nằm trong danh sách 10 kiểu tấn công nguy hiểm 2010 Phương thức hoạt động của dạng này tương tự như kiểu DoS bằng cờ SYN flood hoặc dạng teardrop. Slowloris tạo ra nhiều yêu cầu (Request) đến web server và giữ kết nối đó bằng cách gởi dữ liệu càng chậm càng tốt (bằng cách không tạo một kết 105 thúc bằng chuỗi ký tự \r\n\r\n, trong đó \r\n còn được biết như là CRLF). Với số kết 106 nối tăng lên liên tục dẫn đến server không thể tiếp nhận thêm nữa, dẫn đến sập đổ hệ thống. (Tham khảo RFC 2616). Tường lửa có thể chặn kiểu tấn công này bằng cách giới hạn số kết nối từ một IP đến web server hoặc khóa hoàn toàn một kết nối khi ta chắc chắn đó là host đang DoS đến server. OSI model 7.Application 6.Presentation 5.Session 4.Tranport 3.Network 2.Data link 1.Physiccal DoS attack Sloloris – Incomplete HTTP Request. SYN Flood – Incomplete TCP Handshakes. Mã khai thác tham thảo tại: http://ha.ckers.org/slowloris/ Hình 62: Mã khai thác lập trình bằng ngôn ngữ Perl Khảo sát một rule của Snort chống Slowloris: alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"SPECIFIC-THREATS Slowloris http DoS tool"; flow:established,to_server; content:"User-Agent|3A| Mozilla/4.0 |28|compatible|3B| MSIE 7.0|3B| Windows NT 5.1|3B| Trident/4.0|3B| .NET CLR 1.1.4322|3B| .NET CLR 2.0.503l3|3B| .NET CLR 3.0.4506.2152|3B| .NET CLR 3.5.30729|3B| MSOffice 12|29 0D 0A|"; http_header; content:"ContentLength|3A| 42"; http_header; detection_filter:track by_src, count 10, seconds 300; metadata:service http; reference:cve,2007-0086; classtype:attempted-dos; sid:15578; rev:3;) 107 Theo rule có sid: 15578, thì việc ngăn chặn là hữu hiệu trong một trường hợp duy nhất. Giả sử, kẻ tấn công chỉnh sửa nhỏ nội dung (chỉ cần thay hoặc xóa 1 ký tự tại trường User Agent) thì việc chặn được xem như thất bại. Chúng ta sẽ khảo sát 1 gói tin hợp lệ và một gói tin không hợp lệ trong trường hợp có sự tấn công HTTP DoS. Hình 63: Gói tin GET hợp lệ Hình trên là một yêu cầu (Request) HTTP hợp lệ, chúng được kết thúc bằng một chuỗi hex x0D x0A x0D x0A ( dạng ASCII \r\n\r\n). Hình 64: Gói tin GET không hợp lệ Gói tin Request không gởi chuỗi kết thúc hợp lệ, sẽ dẫn đến máy chủ phải tốn một dung lượng bộ nhớ để giữ kết nối từ client có dạng hex x0D x0A. Trên thử nghiệm thực tế, một đoạn mã khác được viết bằng ngôn ngữ python, tuy payload gói tin khác cũng tạo ra một kết quả tương tự làm server bị ngưng hoạt 108 động, nhưng Snort hoàn toàn không thể ngăn chặn do không trùng mẫu. Đây là loại tấn công dùng phương thức POST thay vì GET như đề cập trong Slowloris. Tham khảo mã được viết bằng python tại: https://github.com/xpn/HTTP-Post-DOS-Tool/blob/master/http_post_dos_tool.py Hình 65: Mã khai thác HTTP DoS nằng ngôn ngữ Python Đoạn mã dùng Python vẫn tạo ra một gói tin thông thường với kết thúc \r\n\r\n, nhưng có hai điều quan trọng Content-Length với giá trị cao làm cho số lượng ký tự gởi lâu đến server. Với đoạn code này, thì ta không nên dùng Snort để phát hiện vì sẽ dẫn đến việc theo dõi một khoảng thời gian khá lâu những gói tin. Giải pháp là cần cấu hình hệ thống web phù hợp để đáp ứng nhu cầu. Sau khi khảo sát mã khai thác, tôi sẽ tạo một rule khác tổng quát ngăn chặn việc HTTP DoS/DDoS bằng Slowloris. alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg: "HTTP DoS GET or POST method attemt"; \ flow:established,to_server; \ content: "get|20 2F|"; http_client_body; nocase; \ content: "post|20 2F|"; http_client_body; nocase; \ content: "|0D 0A|"; http_client_body ;/ pcre: "/^(post|get)\x20\x2f/smi"; \ pcre: "/[^\x0d\x0a]\x0d\x0a$/"; \ detection_filter:track by_src, count 10, seconds 30; \ metadata:service http; reference:cve,2007-0086; classtype:attempted-dos; sid: 1000010; rev:1;) 109 Phân tích luật: Luật này sẽ theo dõi những luồng tin đã kết nối thành công đến máy chủ web, và so những mẫu thỏa cấu trúc pcre pcre: "/^(post|get)\x20\x2f/smiP"; #Xác định chuỗi “GET \” hoặc “POST \” trong yêu cầu (Request) đến máy chủ. pcre: "/[^\x0d\x0a]\x0d\x0a$/P"; #Kiểm tra \x0d\x0a tại vị trí cuối của yêu cầu, trước đó có thể là những chuỗi hex khác nhau. Dùng pcretest để kiểm tra mẫu như hình sau: Hình 66: Kiểm tra cấu trúc PCRE cho luật chặn Sloloris Như kết quả, pcre đã so trùng mẫu có kết thúc không hợp lệ \x0D\x0A tại vị trí cuối cùng. Chú ý: khi sử dụng từ khóa PCRE, thì một kỹ thuật được sử dụng để tối ưu là Anchors, nghĩa là trước từ khóa PCRE ta dùng thêm từ khóa content với nội dung tương tự cấu trúc PCRE. Việc này giúp Snort giảm thiểu số gói tin phải xem xét nếu chỉ dùng riêng PCRE (Tham khảo “ Snort IDS and IPS Toolkit”, p.317). 110 content: "get|20 2F|"; http_client_body; nocase; \ content: "post|20 2F|"; http_client_body; nocase; \ content: "|0D 0A|"; http_client_body ;\ detection_filter:track by_src, count 10, seconds 30; (option) quan trọng trong những cảnh báo #Đây là một chức năng những luật chống DoS/DDoS. detection_filter sẽ tạo ra những luồng tin trong một khoảng thời gian nhất định. khi thỏa Phương thức này cần được xem xét kỹ trước khi áp dụng vì nó phụ thuộc vào quy mô và loại dịch vụ mà web server cung cấp. 11. PHP – SHELL UPLOAD Phần lớn các hệ thống diễn đàn hiện nay tại việt nam thường sử dụng vBulletin, Joomla, Wordpress… để xây dựng và quản trị mô hình diễn đàn (forum) phục vụ cộng đồng. Những hệ thống được liệt kê như trên tương tác với mã nguồn PHP và hệ cơ sở dữ liệu (MSSQL, MySQL, PorgreSQL…). Việc để lộ cơ sở dữ liệu hoặc không kiểm tra cấu trúc tập tin khi cho phép upload lên server sẽ dẫn đến hệ thống có thể bị mất quyền điều khiển. Hình 67: Tạo một user bất hợp lệ lên hệ thống 111 Với những phiên bản mới hiện nay, thì việc kiểm tra header của tập tin đã được đưa vào để bảo vệ cho server. Trong trường hợp PHP shell đã được cài đặt lên hệ thống, ta có thể dùng Snort cảnh báo khi hacker điều khiển hệ thống thông qua PHP shell dựa vào dấu hiệu hoạt động của code PHP. Hiện nay với những loại shell thực thi qua môi trường web được phát tán rộng rãi và khá nguy hiểm. Đối với những loại shell script này tuy là phương thức cũ nhưng vẫn gây ra hậu quả khá nghiêm trọng, việc cập nhật thêm những chủng loại mới là việc hết sức cần thiết khi phát triển những rule chống shell php. Hiện nay các loại shell phổ biến là c99.php, r57.php, php Shell 2.2 …Chúng ta có thể lọc luồng tin dựa vào trường URL để xác nhận việc upload shell lên server. Trường hợp hacker đổi tên tập tin thì chúng ta cần khảo sát thêm code của những tập tin này để phát hiện mã nguồn tấn công hoặc phương án trên Snort là phát hiện ra những tập tin có dạng 2 phần mở rộng liên tục, ví dụ c99.php.txt, r57.php.jpg v.v…Ngoài ra, việc quản lý chính sách (policy) trên phân vùng server phải được thực hiện đầy đủ và thường xuyên kiểm tra tính hiệu quả để có biện pháp ngăn chặn kịp thời. Dưới đây là bảng liệt kê một số shell nguy hiểm thường gặp trong môi trường mạng thường gfs_sh.php.txt, gặp phải: cgi.php.txt, Fatalshell.php.txt, iMHaPFtp.php.txt, mysql.php.txt, fuckphpshell.php.txt, mysql_tool.php.txt, zacosmall.php.txt, c99.php, r57.php, c999.php … Chúng ta cần tạo luật kiểm tra từ client đến server, vì thực thế lượng thông tin từ client đăng tải (upload) lên server ít hơn lượng tin từ server trả về máy client. Vì vậy để tối ưu hóa hiệu suất, ta cần kiểm tra những thông tin từ client đưa lên máy server. Luật kiểm tra được chia thành 2 hướng: Hướng 1: Tạo những luật cảnh báo cho những shell đã được biết đến trong URL để chặn kịp thời. Hướng 2: Tạo những luật cảnh báo nghi ngờ mà hướng 1 không thể phát 112 hiện như đổi tên tập tin shell, để lẩn tránh chính sách của Joomla, Wordpress… về việc giới hạn đăng tải dựa trên phần mở rộng của tập tin, luật dựa trên tìm kiếm cấu trúc linh động của PCRE. 113 Ví dụ: Joomla không cho phép tập tin có phần mở rộng *.php *.htm, nhưng cho phép đăng tải *.jpg *.gif …, việc mạo danh phần mở rộng *.php.jpg *.htm.gif … là một lỗ hổng trong quy trình quản lý. 114 KHÓ KHĂN – THUẬN LỢI Trong quá trình từ việc bắt đầu tiếp nhận đến khi hoàn thành nghiên cứu, tôi đã gặp những thuận lợi và khó khăn như sau: Thuận lợi: Với nền tảng nghiên cứu hoàn toàn trên môi trường mã nguồn mở, với kiến thức học được từ nhà trường đã giúp tôi nhiều trong việc hoàn thành đề tài. Việc kết hợp những kiến thức sưu tầm được trong lĩnh vực tấn công và bảo mật đã giúp tôi hoàn thành thí nghiệm cho việc tấn công và đưa ra những luật phòng chống phù hợp. Sự hướng dẫn tận tình từ thầy Lưu Thanh Trà đưa ra những hướng dẫn cụ thể đã giúp tôi khắc phục được những khó khăn gặp phải khi thực hiện nghiên cứu này. Khó khăn: Tôi đã gặp những khó khăn khi xuất hiện những vấn đề phát sinh, do tài liệu hướng dẫn khắc phục từ nhà sản xuất không có, phần lớn tôi nhận được giúp đỡ từ cộng đồng phát triển nguồn mở nên thời gian đáp ứng giải quyết phát sinh là khá chậm, đôi khi không có phản hồi. Tài liệu phần lớn là không chính thức và phân tán tại nhiều trang web, không đồng nhất về nội dung nên tôi cần có sự chọn lọc thông tin để kiểm tra và tiến hành thực hiện. Các hoạt động thử nghiệm tôi tiến hành giả lập trên môi trường ảo hóa, nên có thể phát sinh những lỗi khác khi áp dụng lên môi trường thực tế chưa được kiểm định trong báo cáo này. Cùng với kinh nghiệm thực tế chưa có sẵn trong thời gian học, nên đối với một số dạng tấn công mới thì tôi chưa tiếp thu được đầy đủ. Kết quả từ việc củng cố những thuận lợi, cũng như khắc phục những khó khăn, tôi đã hoàn thành quyển báo cáo này với hi vọng sẽ mang lại một phần kiến thức nhất định cho những người quan tâm đến việc phát triển IPS trên nguồn mở, mà cụ thể là Snort. 115 HƯỚNG PHÁT TRIỂN TƯƠNG LAI Với tính năng là một hệ thống nguồn mở, Snort đã phát huy được tính tùy biến mạnh mẽ trong việc kết hợp với nhiều plugin hỗ trợ khác. Với cộng đồng phát triển mã nguồn mở khá đông đảo, Snort vẫn đang tiếp tục phát triển với những tính năng ngày càng nâng cao hơn trong việc phát hiện và phòng chống những nguy cơ gây hại cho môi trường mạng. Tại Việt Nam hiện nay, số lượng người tham gia nghiên cứu phát triển Snort còn hạn chế, số lượng các nhóm chuyên nghiên cứu an ninh, lỗ hổng để viết rule, plug-in hỗ trợ Snort vẫn còn ít, gần như là không có. Trên internet, hiện nay chỉ có một lượng nhỏ các nhóm nghiên cứu Snort như: VRT (Vulnerability Research Team), Bleeding Snort (http://www.bleedingsnort.com/), Korea Snort rules (http://snortrules.wordpress.com/)… Với những đặc tính linh động như đã phân tích, tôi hoàn toàn tin tưởng rằng Snort sẽ phát triển mạnh mẽ hơn trong tương lai. Snort có thể đóng vai trò như là một NIDS với chi phí vận hành thấp, quản lý trực quan với các plug-in hỗ trợ, tùy biết luật từ người dùnng. Hiện tại, Snort được triển khai phần lớn mang tính chất nghiên cứu, chưa được áp dụng rộng rãi trên thực tế vì phần lớn các hệ mạng lựa chọn những IPS cứng, giá thành cao để bảo vệ mô hình mạng. Tôi có ý kiến đề xuất xây dựng một cộng đồng nghiên cứu và phát triển Snort tại Việt Nam, có thể thành lập nhóm tại các trường đại học, cao đẳng để nghiên cứu, cập nhật, phát triển Snort Engine, Snort rules… đóng góp cho cộng đồng người dùng nguồn mở trên thế giới và tăng kiến thức về an ninh mạng, nâng cao kỹ thuật với những loại tấn công đã biết và chưa được biết đến. Với xu hướng đó, tôi hi vọng trường Đại học Hoa Sen sẽ sớm thành lập nhóm nghiên cứu về an ninh mạng nói chung, và nghiên cứu Snort nói riêng để góp phần nâng cao kiến thức cho sinh viên ngành mạng máy tính và công nghệ thông tin. 116 PHỤ LỤC 1. TÀI LIỆU THAM KHẢO  Andrew R. Baker, Joel Esler, “Snort IDS and IPS Toolkit”, Syngress Publishing, 2007.  Andrew R. Baker, Brian Caswell, Mike Poor, “Snort 2.1 Intrusion Detection, Second Edition”, O’Reilly, USA, 2004.  Andrew Williams, Tools: Customizing “Nessus, Open Applications”, Snort, Source & Ethereal Power Security Syngress Publishing, Inc, USA, 2005.  SNORT® Users Manual 2.9.0, 2011.  STUART MCCLURE, JOEL SCAMBRAY, GEORGE KURTZ, “HACKING EXPOSED ™ 6:NETWORK SECURITY SECRETS & SOLUTIONS”, McGraw-Hill Companies, 2009  Aaron W. Bayles, “Penetration Tester’s Open Source Toolkit”, Syngress Publishing, Inc, 2007.  Michael Kavish and Tony Piltzecker, “Security+”, Syngress Publishing, Inc, USA, 2003. 2. WEBSITE THAM KHẢO  http://www.snort.org/start/documentation (Cung cấp tài liệu chính thức từ Snort).  http://snortrules.wordpress.com (Nhóm phát triển rule tại Hàn Quốc).  http://www.bleedingsnort.com/ (Cung cấp những rule từ nhóm phát triển bleedingsnort).  http://rules.emergingthreats.net/  http://www.snort.org/vrt (Nhóm phát triển rule chính thức từ Snort). 117  https://www.whitehatsec.com/ (Cung cấp những thông tin về an ninh WEB).  http://packetstormsecurity.org/ (Cung cấp những đoạn mã nguồn tấn công). 3. PHỤ LỤC HÌNH ẢNH Hình 1: Mô hình NIDS .................................................................................................... 9 Hình 1: Mô hình NIDS .................................................................................................. 10 Hình 2: Mô hình HIDS .................................................................................................. 11 Hình 2: Mô hình HIDS .................................................................................................. 12 Hình 3: Mô hình DIDS .................................................................................................. 14 Hình 4: Quy trình thu thập, xử lý gói tin ...................................................................... 16 Hình 6: Lưu đồ quy trình Prerocessor .......................................................................... 17 Hình 5: TCP packet ........................................................................................................ 17 Hình 7: Tổng thể cơ chế Snort....................................................................................... 18 Hình 8: HTTP inspect .................................................................................................... 19 Hình 9: Cơ chế phát hiện (Detection Engine) .............................................................. 19 Hình 10: Cấu trúc rule ................................................................................................... 20 Hình 11: Hoàn thành cài đặt ......................................................................................... 51 Hình 12: Snort ở chế độ sniffing ................................................................................... 52 Hình 13: Tạo user và gán quyền trên MySQL .............................................................. 53 Hình 15: Nội dung các record trong tables Snort ......................................................... 54 Hình 14: Tạo database từ Schema................................................................................. 54 Hình 16: Nội dung tập tin snort.conf thêm vào kiểu xuất dữ liệu .............................. 55 Hình 17: Chuyển BASE qua trang Setup...................................................................... 56 Hình 18: Tạo một database cho BASE .......................................................................... 56 Hình 19: Database được tạo hoàn thành ...................................................................... 57 Hình 20: Tiến trình khởi chạy Snort ............................................................................. 57 Hình 21: Cảnh báo xuất hiện tại BASE ........................................................................ 58 Hình 22: Đồ thị thống kê cảnh báo ............................................................................... 58 Hình 23: Nội dung tập tin base_stat_ipaddr.php .......................................................... 59 Hình 24: Kiểm tra liên kết MapIP ................................................................................. 60 118 Hình 25: Vùng IP tên miền hoasen.edu.vn ................................................................... 60 Hình 26: Tiến trình khởi tạo SnoGE ............................................................................. 63 Hình 27: Tập trin kml tạo bởi SnoGE ........................................................................... 63 Hình 28: SnoGE chỉ rõ vùng IP kết nối đến server ...................................................... 64 Hình 29: SnoGE tạo cột ước lượng cảnh báo từ vùng IP xác định............................. 64 Hình 30: Sơ đồ triển khai Snort Inline.......................................................................... 70 Hình 31: Trang web gốc................................................................................................. 72 Hình 32: Nội dung bị thay đổi khi gói tin đi qua Snort Inline ..................................... 73 Hình 33: Sơ đồ triển khai Snort Sam ............................................................................ 74 Hình 34: Tiến trình khởi động Snort Sam .................................................................... 76 Hình 35: Thông tin kết nối thành công đến iptables firewall ...................................... 76 Hình 36: Kiểm tra firewall với 2 kiểu ping.................................................................... 77 Hình 37: Thông tin tại iptables ...................................................................................... 77 Hình 38: Thông tin thông báo từ SnortSam ................................................................. 78 Hình 39: Sơ đồ trển khai SnortSam và ACL ................................................................. 78 Hình 40: Kiểm tra firewall với 2 kiểu ping.................................................................... 81 Hình 41: Thông báo khi gởi lệnh đến Router Cisco ..................................................... 82 Hình 42: Thông tin thông báo giải phóng việc chặn kết nối........................................ 82 Hình 43: ACL được tạo ra cho việc chặn kết nối.......................................................... 83 Hình 44: Mô phòng luật 7760........................................................................................ 85 Hình 45: Kiểm tra cấu trúc PCRE với pcretest ............................................................. 86 Hình 46: Tham chiếu nội dung PCRE với pcretest ...................................................... 87 Hình 47: Metadata trong cảnh báo từ Snort ................................................................. 88 Hình 48: Nội dung gói tin thu thập được trong cảnh báo ............................................ 88 Hình 49: Mô phỏng luật 2164........................................................................................ 89 Hình 50: Nội dung mã khai thác mailenable ................................................................ 91 Hình 51: Shellcode khai thác......................................................................................... 92 Hình 52: Thực thi tấn công lỗ hổng mailenable........................................................... 93 Hình 53: Kiểm tra kết quả.............................................................................................. 93 Hình 54: Tiến hành scan mục tiêu ................................................................................ 94 Hình 55: Khai thác thông qua metasploit ..................................................................... 95 Hình 56: Nội dung chứa trong payload gói tin ............................................................. 96 Hình 57: Những gói tin trong một phiên tấn công ....................................................... 97 Hình 58: Tiến trình các gói tin khi xảy ra cuộc tấn công ............................................ 97 119 Hình 59: Nội dung trong mã nguồn Apache................................................................. 98 Hình 60: Gói tin chứa các tùy chọn khi kết tnối đến MySQL ...................................... 99 Hình 61: Slowloris nằm trong danh sách 10 kiểu tấn công nguy hiểm 2010............ 100 Hình 62: Mã khai thác lập trình bằng ngôn ngữ Perl................................................ 101 Hình 63: Gói tin GET hợp lệ ....................................................................................... 102 Hình 64: Gói tin GET không hợp lệ ............................................................................ 102 Hình 65: Mã khai thác HTTP DoS nằng ngôn ngữ Python ...................................... 103 Hình 66: Kiểm tra cấu trúc PCRE cho luật chặn Sloloris ......................................... 104 Hình 67: Tạo một user bất hợp lệ lên hệ thống .......................................................... 105 120 121