Đề tài Xây dựng giải pháp phòng chống DDoS cho máy chủ web

hỉ định thư mục để log các alert. Mặc định thư mục log là /var/log/snort, nhưng mặc định chỉ sử dụng khi Snort chạy ở -A mode . -L binary-log-file: Thiết lập filename của file binary, mặc định sẽ là thời gian thêm vào sau chữ snort.log được lưu trong log . -N: Tắt packet logging nhưng chế độ alert vẫn hoạt động và chỉ hiển thị trên màn hình console. Thường dùng để kiểm tra những file cấu hình mới . -P snap-length: Thiết lập chiều dài tối đa cho các packet capture. Thiết lập để có thể bắt hết các packet, nếu thiết lập chiều dài quá ngắn có thể không coi hết được nội dung của packet khi cần thiết . -q: Không hiển thi banner hay những thông tin khi khởi động -r tcpdump-file: Đọc file có định dạng tcpdump. -s: Gửi alert message đến syslog server. Có thể gửi ở local hay remote server . -T: Khởi động Snort ơ chế độ selt-test. Hữu ích khi debug Snort trước khi chạy ở chế độ deamon . -v: In toàn bộ packet trên console. Cẩn thận khi dùng, nó làm cho Snort chậm đi khi drop packet. -V: Hiển thị Version của Snort. -x: Hiển thị các packet “thô” cần dùng khi xem các ethernet headers và trailers . 2.2.3 Cấu trúc của file snort.conf File snort.conf bao gồm: Thiết lập mạng và cấu hình các biến Cấu hình phần giải mã (decoder) và phát hiện (detection) Cấu hình tiền xử lý (preprocessor) Cấu hình phần output File include 2.2.3.1 Thiết lập mạng và cấu hình các biến Các biến trong file conf được tạo ra thường để dễ dàng hơn trong việc theo dõi các địa chỉ IP hoặc các port TCP, UDP được chỉ định mà nó đang lắng nghe.  Mặc định các biến thường để giá trị là any chỉ tất cả các địa chỉ IP mà nó nhận được, nó cũng có thể là nguyên nhân gây ra nhiều báo động sai.  Các biến mặc định như : HOME_NET : chỉ định địa chỉ mạng của mình đang bảo vệ  EXTERNAL_NET: các mạng bên ngoài. Một số biến để chỉ định các server đang chạy các service phục vụ cho hệ thống : DNS_SERVERS  SMTP_SERVERS  HTTP_SERVERS  SQL_SERVERS  TELNET_SERVERS  SNMP_SERVERS  Các port mặc định các biến khác:  HTTP_PORTS  SHELLCODE_PORTS  ORACLE_PORTS  AIM_SERVERS  RULES_PATH Để chỉ định một địa chỉ IP, đơn giản chỉ làm theo cách sau:  var HOME_NET 192.168.1.1  Hoặc khi muốn chỉ định nhiều địa chỉ cùng lúc, phải có dấu ngoặc vuông để chỉ định cho cả nhóm:  var HOME_NET [192.168.1.1,192.168.14.1,10.0.0.2]  Ta cũng có cách khác để chỉ định luôn cả mạng:  var HOME_NET 10.10.10.0/24  Hoặc cũng có thể gộp cả 2 cách trên vào chung 1 nhóm: var HOME_NET [192.168.1.1 ,172.168.1.5/16,187.1.1.1/19]  Nếu muốn chỉ định không dùng các IP này thì dùng thêm dấu “than” ! nghĩa là NOT  var EXTERNAL_NET !$HOME_NET  Để chỉ định cho các port cũng làm tương tự ví dụng  var ORACLE_PORTS 1521  Hoặc các port không phải là port 80  var SHELLCODE_PORTS !80 2.2.3.2 Cấu hình phần giải mã ( decoder ) Các tùy chọn trong phần này: - disable_decode_alerts: Theo mặc định thì decoder alert được bật, sử dụng tùy chọn này để tắt các cảnh báo. - enable_decode_drops: Ở inline mode, snort sẽ drop các packet bị cảnh báo. - disable_ipopt_alerts: Tắt các cảnh báo về các IP packet có option lỗi. - enable_ipopt_drops: drop các IP packet cái mà bị cảnh báo có option lỗi. - disable_ttcp_alerts: Tắt các cảnh báo được tạo ra từ việc phát hiện T/TCP. - enable_ttcp_drops: Drop những packet bị cảnh báo do bị phát hiện T/TCP. - disable_tcpopt_obsolete_alerts: Tắt các cảnh báo được tạo ra khi phát hiện ra các TCP option không còn được sử dụng. - enable_tcpopt_obsolete_drops: Drop các TCP packet có các option không còn sử dụng. - disable_tcpopt_experimental_alerts: Tắt các cảnh báo được tạo ra khi phát hiện các packet TCP có các option đang trong giai đoạn thí nghiệm. - enable_tcpopt_experimental_drops: Drop các packet TCP có các option thí nghiệm. - enable_decode_oversized_alerts: Bật chức năng cảnh báo khi gói tin có chiều dài trường (IP, TCP, UDP) lớn hơn một gói mà ta bắt được. - enable_decode_oversized_drops: Drop các gói tin có chiều dài trường (IP, TCP, UDP) lớn hơn một gói mà ta bắt được. - checksum_mode: all| none| noip| notcp| noudp| noicmp| ip| tcp| udp| icmp Theo mặc định checksum được sử dụng cho IP, TCP, UDP và ICMP. Sử dụng chức năng này có thể lựa chọn sử dụng checksum cho những giao thức này. - checksum_drop: all| none| noip| notcp| noudp| noicmp| ip| tcp| udp| icmp Drop các packet có checksum hỏng 2.2.3.2 Cấu hình phát hiện (detection) search-ethod lowmem: Bật chức năng này snort sẽ sử dụng ít bộ nhớ hơn (chạy chậm hơn so với chế độ bình thường) 2.2.3.3 Cấu hình tiền xử lý (preprocessor) Frag3 Khi một packet đi từ mạng này qua mạng khác, nó thường cần phân mảnh thành các packet nhỏ hơn, bởi vì mạng thứ 2 sẽ giới hạn kích thuớc của packet và tất nhiên nhỏ hơn mạng đầu tiên. Và tất cả các packet nhỏ sẽ đuợc sắp xếp lại khi đến nơi. Một trong những phương pháp của attacker là dùng các packet nhỏ để lừa firewall hoặc IDS. Ví dụ: rules của Snort đang dò tìm chuỗi /users.pwd trong các section của packet, một attacker có thể tạo ra một dãy các packet rất nhỏ chỉ chứa vài byte trong data của packet, mảnh đầu tiên có thể chứa /user , và cái packet phân mảnh thứ 2 có thể chứa s.pwd, các packet này sẽ không kích hoạt báo động bởi vì nó không giống các rules nào cả, frag3 preprocessor sẽ sắp xếp sự phân mảnh này vào chung và nó sẽ dễ dàng phát hiện sự ẩn dấu đó. Hoặc một ví dụ khác các attacker có thể đưa ra 1 dung lượng quá lớn các packet đã phân mảnh nó sẽ chiếm dung lượng của hệ thống và làm overload có thể Snort sẽ từ chối tất cả và ảnh hưởng tới các packet không liên quan, các tools mà attacker thường dùng là Fragroute, frag2 và phiên bản mới nhất là frag3 có các options để chống lại các dạng tấn công này. Frag3 có các preprocessor : - frag3_global Có các tùy chọn : + max_frags : Số lượng phân mảnh đồng thời lớn nhất mà Snort có thể theo dõi. Mặc định là 8192. + memcap : Số lượng bộ nhớ tối đa mà Snort có thể truy cập tại bất cứ thời điểm nào. Mặc định là 4MB. + prealloc_frags : Số lượng phân mảnh riêng lẻ lớn nhất có thể xử lý cùng một lúc. Tùy chọn này được dùng thay cho tùy chọn memcap, sử dụng giá trị tĩnh để tăng hiệu suất. - frag3_engine Có các tùy chọn: + timeout: Thời gian các phân mảnh còn hiệu quả trước khi hết hạn.Mặc định là 60 giây. + ttl_limit: Giá trị time to live lớn nhất có thể chấp nhận được trong gói đầu tiên của các gói phân mảnh. Mặc định là 5. + min_ttl: Giá trị time to live nhỏ nhất có thể chấp nhận được. Mặc định là 0. + detect_anomalies: Phát hiện các gói phân mảnh không bình thường. + policy : Lựa chọn các policy cho frag3_engine. Mặc định là BSD. Xem bảng 05 để biết thêm chi tiết. + bind_to : Thiết lập địa chỉ IP cho frag3_engine. Frag3_engine chỉ hoạt động với những packet có địa chỉ đích nằm trong . Mặc định là all. Một số ví dụ: preprocessor frag3_global: prealloc_nodes 8192 preprocessor frag3_engine: policy linux, bind_to 192.168.1.0/24 preprocessor frag3_engine: policy first, bind_to [10.1.47.0/24,172.16.8.0/24] preprocessor frag3_engine: policy last, detect_anomalies Stream5 Stream5 là module dùng để quản lý các luồng dữ liệu của Snort. Stream5 thay thế cho Stream4 và Flow preprocessor. Stream5 có các preprocessor: - stream5_global Các tùy chọn : + track_tcp : Có theo dõi các phiên TCP không? Mặc định là có. + max_tcp : Số lượng lớn nhất các phiên làm việc đồng thời của TCP mà Snort phải theo dõi. Mặc định là 256000, lớn nhất là 1052672, nhỏ nhất là 1. + memcap : Dung lượng để lưu trữ các packet TCP. Mặc định là 8388608 (8 MB), lớn nhất là 1073741824 (1GB), nhỏ nhất là 32768 (32KB). + track_udp : Có theo dõi các phiên của UDP không? Mặc định là có. + max_udp : Số lượng lớn nhất các phiên làm việc đồng thời của UDP mà Snort phải theo dõi. Mặc định là 128000, lớn nhất là 1052672, nhỏ nhất là 1. + track_icmp : Có theo dõi các phiên của ICMP không? Mặc định là có. + max_icmp : Số lượng lớn nhất các phiên làm việc đồng thời của ICMP mà Snort phải theo dõi. Mặc định là 64000, lớn nhất là 1052672, nhỏ nhất là 1. + show_rebuilt_packets: Hiển thị packet sau khi xây dựng lại (dành cho debug). Mặc định là tắt. - stream5_tcp Có các tùy chọn: + bind_to : Địa chỉ IP hoặc mạng áp dụng cấu hình này. + timeout : Thời gian tạm ngưng phiên TCP. Mặc định là 30, nhỏ nhất là 1, lớn nhất là 86400 (1 ngày). + policy : Bảng các policy name: Policy Name Operating Systems First Favor first overlapped segment. Last Favor first overlapped segment. Bsd FresBSD 4.x and newer,NetBSD 2.x and newer, OpenBSD 3.x and newer. Linux Linux 2.4 and newer Old-linux Linux 2.2 and earlier Windows Windows 2000,Windows XP,Window 95/98/ME Win2003 Windows 2003 Server Vista Windows Vista Solaris Solaris 9.x and newer hpux HPUX 11 and newer Hpux10 HPUX 10 Irix Irix 6 and newer Macos MascOS 10.3 and newer Bảng 05: Tên các policy + min_ttl : Đặt giới hạn nhỏ nhất cho ttl, mặc định là 1, nhỏ nhất là 1 và lớn nhất là 255. + overlap_limit : Giới hạn số lượng packet trùng lặp trong một phiên. Mặc định là 0 (không giới hạn), nhỏ nhất là 0, lớn nhất là 255. + detect_anomalies: Phát hiện và cảnh báo những giao thức TCP bất thường. Mặc định là tắt. + don’t_store_large_packets: Mặc định là tắt. Tùy chọn này cho phép không lắp ráp lại các packet lớn, cho phép Snort hoạt động nhanh hơn, tuy nhiên nếu xẩy ra tấn công, sẽ dễ bỏ sót các cảnh báo. + max_queued_bytes : Giới hạn dung lượng queue của Snort dành để chứa các packet cho việc ghép các phân mảnh. Mặc định là 1048576 (1GB). Đặt giá trị bằng 0 nghĩa là không giới hạn, giá trị lớn nhất là 1GB, nhỏ nhất khác 0 là 1024. + max_queued_segs : Giới hạn số lượng queue để chứa các phân mảnh. Mặc định là 2601, giá trị 0 nghĩa là không giới hạn, nhỏ nhất khác 0 là 2, lớn nhất là 1073741824 (1GB). + port : Đặt giá trị các port. Mặc định là port client 21 23 25 42 53 80 110 111 135 136 137 139 143 445 513 514 1433 1521 2401 3306. - stream5_udp Có các tùy chọn: + timeout : Tương tự như của stream5_tcp, mặc định là 30, nhỏ nhất là 1, lớn nhất là 86400 (1 ngày). + ignore_any_rules : Không thực hiện dạng rule any-> any (port). Mặc định là tắt. 2.2.3.4 Cấu hình ouput Một số cấu hình out của Snort trong file config : alert_syslog Các hệ thống Unix sử dụng syslog để tập hợp các thông điệp được tạo ra bởi một hoặc nhiều hệ thống. Có một số cách khác nhau để Snort tạo ra thông tin có thể được trình bày trong syslog. Bạn có thể xác định khả năng được sử dụng bởi Snort và cũng xác định mức độ ưu tiên được gán cho các mục được tạo ra bởi Snort. Định dạng của plug-in này là:Output alert_syslog: Tùy chọn facility xác định một trong các chuẩn syslog : LOG_AUTH LOG_AUTHPRIV LOG_DAEMON LOG_LOCAL0 LOG_LOCAL1 LOG_LOCAL2 LOG_LOCAL3 LOG_LOCAL4 LOG_LOCAL5 LOG_LOCAL6 LOG_LOCAL7 LOG_USERTùy chọn priority cũng xác định một trong các ưu tiên chuẩn của syslog :LOG_EMERG LOG_ALERT LOG_CRIT LOG_ERR LOG_WARNING LOG_NOTICE LOG_INFO LOG_DEBUGĐây là một cấu hình mẫu cho output plug-in alert_syslog : output alert_syslog: LOG_AUTH LOG_ALERT Log_tcpdump Output plug in này ghi log gói tin theo định dạng tcpdump. Có nhiều ứng dụng có thể đọc định dạng này. Tùy chọn duy nhất cho output plug in này là tên file trong thông tin được ghi. Đây là một cấu hình mẫu cho log_tcpdump plug-in: output log_tcpdump /var/log/snort/tcpdump.out Cơ sở dữ liệu Plug-in cơ sở dữ liệu cho phép bạn viết nhiều cơ sở dữ liệu liên quan với nhau trên cùng một hệ thống đang chạy Snort hoặc trên một host khác. Khi ghi log vào một cơ sở dữ liệu, nhiều thông tin được ghi lại – bao gồm các cảnh báo, liên quan đến host và gói tin gây ra cảnh báo – làm cho việc phân biệt giữa các cảnh báo thật và giả dễ dàng hơn. Thỉnh thoảng việc ghi log vào một server cơ sở dữ liệu có thể gây ra nghẽn cổ chai, vì chỉ có một cảnh báo được ghi log vào 1 thời điểm. Một server cơ sở dữ liệu được cấu hình tốt có thể giải quyết vấn đề này.  Plug-in output cơ sở dữ liệu có định dạng sau : output database: , ,  Trong đó : - : Chọn log hoặc alert. Log gửi thông tin log đến cơ sở dữ liệu và alert gửi các cảnh báo. Lưu ý rằng log bao gồm các thông tin cảnh báo và thông tin gói tin tạo ra cảnh báo. Nếu bạn muốn gửi cả hai đến cơ sở dữ liệu, bạn cần chọn 2 dòng output cơ sở dữ liệu. - : Đây là nơi bạn xác định kiểu cơ sở dữ liệu mà bạn ghi log. Snort hỗ trợ các dạng sau : mysql, postgresql, oracle, odbc, and mssql.Khi cấu hình một plug-in output cơ sở dữ liệu cụ thể, thiết lập các thông số sau (không có dấu phẩy giữa các thông số) : +) host: Địa chỉ IP của server cơ sở dữ liệu. Nếu để trống, nó sẽ là máy cục bộ (local machine). +)port: Cổng mà cơ sở dữ liệu đang lắng nghe. Bạn chỉ cần xác định nếu không sử dụng cổng chuẩn. +)dbname=: Kiểu cơ sở dữ liệu bạn ghi log +)user: Username mà Snort sử dụng để ghi log vào cơ sở dữ liệu. +)password: Password được sử dụng để log vào cơ sở dữ liệu. +)sensor_name: Tên bộ cảm biến cho cấu hình này (không bắt buộc). +) encoding :Việc mã hóa được sử dụng để ghi log vào cơ sở dữ liệu. Bạn có thể xác định hex( ít tốn không gian, có thể tìm kiếm nhưng khó đọc ), base64 (nhỏ hơn plain text, không tìm kiếm được, không đọc được bởi người dùng), hoặc ASCII (lớn hơn, có thể tìm kiếm, người dùng có thể đọc được). +) detail :Bạn có thể xác định mức độ chi tiết được sử dụng để khi gửi thông tin đến cơ sở dữ liệu. Full sẽ bao gồm tất cả thông tin mà Snort thu thập, bao gồm cả header và thông tin gói tin. Fast thì nhanh hơn 1 chút, nhưng bao gồm ít thông tin hơn như tên cảnh báo, địa chỉ và cổng nguồn, đích và thời gian. Full được khuyên dùng. Unified Output unified được thiết kế để Snort lưu log một cách nhanh nhất có thể. Output unified lưu các sự kiện ở dạng nhị phân, cho phép các chương trình khác có thể đọc được . Output unified tạo ra hai loại file là alert file và log file. Alert file chứa các thông tin cơ bản của packet bị snort phát hiện (IP, protocol, port,message id ) còn log file chứa các thông tin cụ thể hơn của packet . Cấu trúc : output alert_unified: [,limit ] output log_unified: [, limit ] Chú ý: Thời gian sẽ được thêm vào cuối tên file 2.2.3.5 File include Trong file Snort.conf, câu lệnh include chỉ cho Snort đọc các file sau từ include được lưu trong filesystem của Snort sensor, giống như trong lập trình vậy. Ví dụ : $ include $RULE_PATH/bad-traffic.rules $ include $RULE_PATH/exploit.rules $ include $RULE_PATH/scan.rules  Các rules trên ta có thể download trên Internet, khi down về ta muốn phân nhóm hoặc chỉnh sửa, độ ưu tiên các rules ta có thể cấu hình trong file classification.config, file reference.config gồm các links tới trang web với các thông tin cho tất cả các alerts, include nó rất hữu ích, nhanh gọn. Ví dụ: # include classification & priority settings  include classification.config  # include reference systems  include reference.config 2.2.4 Cấu trúc của rule Rules của Snort có hai phần : rule header và rule option. Một Rule có thể phát hiện một hoặc nhiều kiểu xâm nhập. 2.2.4.1 Cấu trúc của header Header Rule Action Protocol Source Address và Port The Direction Operator Destination Address và Port Alert tcp any 1234 -> 192.168.1.0/24 any Bảng 06: Cấu trúc của rule header - Snort hỗ trợ IP Address dạng CIDR, ví dụ : 192.168.1.0/24, với tất cả các IP Snort dùng từ khóa any - Snort hỗ trợ cấu hình với một port, một dải port hoặc tất cả các port. Ví dụ: log udp any any -> 192.168.1.0/24 1:1024 log udp traffic từ bất kì ip nguồn và port nguồn nào đến mạng 192.168.1.0/24 có port đích từ 1 đến 1024. log udp any 1234 -> 192.168.1.0/24 :500 log udp traffic từ bất kì ip nguồn nào và port nguồn là 1234 đến mạng 192.168.1.0/24 có port đích nhỏ hơn 500. log udp any !53 -> 192.168.1.0/24 600: log udp traffic từ bất kì ip nguồn nào và port nguồn khác port 53 đến mạng 192.168.1.0/24 có port đích lớn hơn 600. - The Direction Operator : Có 2 loại direction operator là : + -> Chiều đi từ nguồn đến đích , bên trái dấu “->” là địa chỉ IP nguồn , port nguồn, bên phải dấu “->” là IP đích port đích. + Traffic 2 chiều. 2.2.4.2. Rule Options : Rule option theo sau rule header và được đóng gói trong dấu ngoặc đơn. Có thể có một hoặc nhiều option, được cách nhau bởi dấu phẩy. Nếu bạn sử dụng nhiều option, những option hình thành phép logic AND. Một action trong rule header chỉ được thực hiện khi tất cả các option đều đúng. Tất cả các option được định nghĩa bằng các từ khóa. Một vài option cũng chứa các tham số. Thông thường, một option có thể có 2 phần: từ khóa và đối số. Các đối số được phân biệt với từ khóa bằng dấu hai chấm. Ví dụ: msg: "Detected confidential"; Trong option này thì msg là từ khóa và "Detected confidential" là đối số của từ khóa. Các từ khóa được sử dụng trong phần option của luật Snort : - msg: Cấu trúc msg: ; Được sử dụng để ghi thông tin vào việc ghi log và cảnh báo - ack: Cấu trúc ack : TCP header chứa một trường Acknowledgement Number dài 32 bit. Trường này chỉ ra rằng sequence number kế tiếp của người gửi được mong đợi. Trường này chỉ có ý nghĩa khi cờ flag trong trường TCP được thiết lập. - classtype :config classification: name, description, priority name : tên được sử dụng cho việc phân loại. Tên được sử dụng với từ khóa classtype trong luật Snort.Description: mô tả ngắn về kiểu phân loại. Priority : thứ tự ưu tiên mặc định cho sự phân loại, có thể được chỉnh sửa bằng từ khóa priority. Priority càng thấp thì độ ưu tiên càng cao. Các luật có thể được phân loại và xếp thứ tự ưu tiên vào trong một nhóm. Để có thể hiểu hơn về từ khóa classtype, hãy xem file classification.config trong snort.conf . Mỗi dòng trong đó sẽ có cú pháp như sau : - content : Cấu trúc ontent: ; content: ; Một đặc tính quan trọng của Snort là khả năng tìm thấy một mẫu dữ liệu trong một gói tin. Mẫu đó có thể tồn tại dưới dạng một chuỗi ASCII hoặc là các kí tự thập lục phân. Giống như virut, những kẻ xâm nhập cũng có các dấu hiệu và từ khóa content để có thể tìm ra các dấu hiệu trong các gói tin.  - offset: Cấu trúc offset: : Từ khóa offset được sử dụng kết hợp với từ khóa content. Sử dụng từ khóa này, bạn có thể bắt đầu tìm kiếm từ một vị trí xác định so với vị trí bắt đầu của gói tin. Sử dụng một con số như là đối số của từ khóa này. - depth Cấu trúc depth: : Từ khóa depth cũng được sử dụng kết hợp với từ khóa content để xác định giới hạn trên của việc so sánh mẫu. Sử dụng từ khóa này, bạn có thể xác định một vị trí so với vị trí bắt đầu. Dữ liệu sau vị trí này sẽ không được tìm kiếm để so mẫu. Nếu bạn dùng cả hai từ khóa offset và depth thì bạn có thể xác định một khoảng dữ liệu thực hiện việc so sánh mẫu. - nocase Cấu trúc nocase; Từ khóa nocase được sử dụng kết hợp với từ khóa content. Nó không có đối số. Mục đích của nó là thực hiện việc tìm kiếm trong trường hợp vô tình. - content-list Cấu trúc content_list: : Từ khóa content-list được sử dụng với tên của một file như là đối số của từ khóa này. File này sẽ chứa một danh sách các chuỗi sẽ được tìm kiếm trong một gói tin. Mỗi chuỗi được đặt trên các dòng khác nhau của file. - dsize Cấu trúc dsize: [] : Từ khóa dsize được sử dụng để tìm chiều dài một phần dữ liệu của gói tin. Nhiều cách tấn công sử dụng lổ hổng tràn bộ đệm bằng cách gửi các gói tin có kích thước lớn. Sử dụng từ khóa này, bạn có thể tìm thấy các gói tin có chiều dài dữ liệu lớn hoặc nhỏ hơn một số xác định. - flags Cấu trúc flags: : Từ khóa flags được sử dụng để tìm ra bit flag nào được thiết lập trong header TCP của gói tin. Mỗi flag có thể được sử dụng như một đối số của từ khóa flags trong luật Snort. Những bit flag này được sử dụng bởi nhiều các công cụ bảo mật với nhiều mục đích trong đó có việc quét các cổng như nmap ( - fragbits Cấu trúc: fragbits: : Sử dụng từ khóa này, bạn có thể tìm ra những bit RB (Reserved Bit), DF(Don't Fragment Bit), MF(More Fragments Bit) trong header IP có được bật lên hay không. - icmp_id : Cấu trúc icmp_id: : Option icmp_id được sử dụng để phát hiện một ID cụ thể được sử dụng với một gói tin ICMP. - icmp_seq Cấu trúc icmp_seq: : Option icmp_seq giống như từ khóa icmp_id. - itype Cấu trúc itype: :Header ICMP nằm sau header IP và chứa trường type. Từ khóa itype được sử dụng để phát hiện các cách tấn công sử dụng trường type trong header ICMP của gói tin. - icode Cấu trúc icode: :Trong gói tin ICMP, header ICMP đi sau header IP. Nó chứa một trường code. Từ khóa icode được sử dụng để phát hiện trường code trong header gói tin ICMP. - ipopts Cấu trúc ipopts: :Header IPv4 cơ bản dài 20 byte. Bạn có thể thêm các tùy chọn vào header này ở cuối. Chiều dài của phần tùy chọn này có thể lên đến 40 byte. Các tùy chọn được sử dụng cho các mục đích khác nhau, bao gồm: • Record Route (rr) • Time Stamps (ts) • Loose Source Routing (lsrr) • Strict Source Routing (ssrr) - ip_proto Cấu trúc ip_proto: [!] :Từ khóa ip_proto sử dụng plug-in IP Proto để xác định số giao thức trong header IP. Từ khóa này cần một con số giao thức là đối số. Bạn cũng có thể sử dụng tên giao thức nếu nó có thể phân giải bằng file /etc/protocols. - logto Cấu trúc logto: :Từ khóa logto được sử dụng để ghi log các gói tin vào một file đặc biệt. - priority Cấu trúc priority: :Từ khóa priority gán độ ưu tiên cho một luật. - reference Cấu trúc : reference : , :Từ khóa reference có thể thêm một sự tham khảo đến thông tin tồn tại trên các hệ thống khác trên mạng. Nó không đóng một vai trò nào trong cơ chế phát hiện. Có nhiều hệ thống để tham khảo như CVE và Bugtraq. Những hệ thống này giữ các thông tin thêm về các kiểu tấn công đã được biết. Bằng việc sử dụng từ khóa này, bạn có thể kết nối đến các thông tin thêm trong thông điệp cảnh báo. - resp :Từ khóa resp là một từ khóa cực kì quan trọng. Nó có thể được sử dụng để đánh bại các hành vi của hacker bằng cách gửi các gói tin trả lời cho một host mà tạo ra một gói tin thỏa luật. Từ khóa này cũng được biết như là Flexible Response (FlexResp) và được dựa trên FlexResp plug-in. Plug-in nên được biên dịch vào Snort, sử dụng lệnh (--with-flexresp)trong script cấu hình. - sameip Từ khóa sameip được sử dụng để kiểm tra địa chỉ nguồn và đích có giống nhau hay không. Nó không có đối số. - seq Cấu trúc seq: : Từ khóa seq trong luật Snort có thể được sử dụng để kiểm tra số thứ tự sequence của gói tin TCP. - flow Từ khóa flow được sử dụng để áp dụng một luật lên các gói tin di chuyển theo một hướng cụ thể. Bạn có thể sử dụng các option với từ khóa để xác định hướng. Các option sau đây có thể được sử dụng với từ khóa này : • to_client • to_server • from_client • from_server - session Cấu trúc session: [printable|all] : Từ khóa có thể được sử dụng để gạt bỏ tất cả dữ liệu từ một phiên TCP. - sid Cấu trúc sid: : Sử dụng SID, các công cụ như ACID có thể biểu diễn luật thật sự tạo ra một cảnh báo cụ thể. - tag tag: , , [, direction] : Từ khóa tag là một từ khóa rất quan trọng khác có thể được sử dụng để ghi log các dữ liệu thêm vào từ ( hoặc đến) một host xâm nhập khi một luật được kích hoạt. Dữ liệu thêm vào có thể được phân tích sau này một cách chi tiết hơn. - tos Cấu trúc tos: : Từ khóa tos được sử dụng để phát hiện một giá trị cụ thể trong trường TOS (Type of Service) của header IP. - ttl Cấu trúc ttl: :Từ khóa ttl được sử dụng để phát hiện giá trị Time to Live trong header IP của gói tin. Từ khóa này có thể được sử dụng với tất cả các kiểu giao thức được xây dựng trên IP như ICMP, UCP và TCP. Sử dụng từ khóa ttl, bạn có thể tìm ra nếu có một người cố gắng traceroute mạng của bạn. Vấn đề duy nhất là từ khóa cần một giá trị TTL chính xác. - uricontent Cấu trúc uricontent: [!] "content string" : Từ khóa uricontent giống với từ khóa content ngoại trừ việc nó được sử dụng để tìm một chuỗi chỉ trong phần URI của gói tin. Nhận xét : Iptables là một firewall cơ bản nhất và phổ biến nhất trong môi trường Linux. Thông qua nó có thể dễ dàng hiểu được nguyên lý hoạt động của một hệ thống firewall nói chung. Snort inline thừa hưởng được tất cả các đặc điểm của Snort như dễ cấu hình, miễn phí, sử dụng rộng rãi, chạy trên nhiều nền tảng, cập nhật thường xuyên nhưng có một đặc điểm mà theo em, nó là điểm quan trọng nhất khiến cho Snort nói chung và Snort inline nói riêng có thể hoạt động ổn định là các bộ preprocessor. Các bộ preprocessor cũng chính là đặc điểm nổi bật của Snort so với các hệ thống IDS/IPS khác. Chương IV. Xây dựng giải pháp phòng chống DDoS cho máy chủ web Mô hình triển khai thực tế Giải pháp Mô hình thử nghiệm Triển khai hệ thống Kiểm tra đánh giá 1. Mô hình triển khai thực tế Mô trường mạng triển khai khi chưa có IPS: Hình 14: Mô hình mạng triển khai thực tế Trong đó , Máy chủ web có : - Sử dụng hệ điều hành Centos 5.2 . - Cài đặt apache, php, mysql là máy chủ web. Đây là một môi trường mạng rất phổ biến tại Viêt Nam vì những lý do sau: - Dễ dàng triển khai (vì mô hình mạng đơn giản) - Giá thành rẻ (Centos, apache, php, mysql đều không mất phí). - Dễ dàng vận hành, quản lý (do mô hình mạng đơn giản). Mô hình mạng triển khai hệ thống phòng chống : Hình 15: Mô hình mạng sau khi triển khai hệ thống phòng chống Việc đặt chung hệ thống phòng chống DDoS cùng với máy chủ web có nhược điểm là máy chủ web sẽ phải tiêu tốn tài nguyên hơn để phục vụ cho hệ thống phòng chống tuy nhiên do chỉ sử dụng một máy chủ nên giải pháp này sẽ tiết kiệm hơn và phù hợp hơn với các doanh nghiệp ở Việt Nam. 2. Giải pháp Qua chương 1 và chương 2, ta có thể rút ra kết luận rằng để có thể phòng và chống được DDoS cho Máy chủ web thì một mình cá nhân là không đủ, tuy nhiên em có thể đề xuất một giải pháp tình thế để phòng và chống được những vụ DDoS Web Server với quy mô nhỏ hoặc kéo dài thời gian “sống sót” của Máy chủ web để ta có thời gian phối hợp được với các bên liên quan. Trước khi đi vào phần giải pháp, ta hãy cùng xem biểu đồ luồng dữ liệu đi vào Web Server Hình 16: Luồng dữ liệu đi đến Web Server Có thể hình dung luồng dữ liệu đi như sau: Bước đầu tiên máy tính của người dùng sẽ tạo kết nối TCP với Máy chủ web Thông qua kết nối đó, request đến apache được gửi đến Máy chủ web Request được netfilter so sánh với các rule do Iptables nhập vào. Nếu request hợp lệ thì sẽ được chuyển sang user space (apache), apache nhận request, xử lý rồi trả lời cho web brower. Thông qua biểu đồ luồng dữ liệu đến Web Server ta thấy có 2 điểm mà attacker sẽ lợi dụng để tấn công DDoS vào, đó là phần kết nối TCP và request đến apache. Nếu attacker gửi rất nhiều TCP connection đến Web Server thì đến một lúc nào đó, Máy chủ web sẽ không thể nhận thêm connection nữa (queue đầy, …) và những connection của người dùng hợp pháp sẽ không được xử lý. Mặc khác, do phụ thuộc vào lượng tài nguyên (RAM) trên máy chủ nên apache chỉ có thể nhận và xử lý được một số có hạn request. Nên nếu attacker gửi càng nhiều reuquest mà những request này đến được apache thì càng ít người dùng hợp pháp được phục vụ. Qua đó, em có một số ý tưởng cho giải pháp phòng chống DDoS cho Máy chủ web đó là: Cấu hình Server để có thể nhận và xử lý được nhiều nhất số kết nối TCP/IP. Kết thúc nhanh nhất các kết nối mà không làm ảnh huởng đến người dùng hợp pháp để có thể nhận và xử lý các kết nối mới. Giới hạn số connection đến Web Server, số connection đến apache Hình 17: Luồng dữ liệu khi triển khai hệ thống phòng chống DDoS Thông qua các ý tưởng, giải pháp được đưa ra bao gồm: - Tối ưu hóa Máy chủ web ở tầng TCP/IP để server có thể nhận và xử lý nhiều kết nối nhất đồng thời có thể giải phóng các kết nối một cách nhanh nhất mà không làm ảnh hưởng đến người dùng hợp pháp. - Cài đặt module connlimit cho Iptables để giới hạn số truy cập từ một IP. - Triển khai hệ thống IPS gồm Snort inline và Iptables để chống lại các request DDoS đến máy chủ web. Em xin nhấn mạnh là hiện nay chưa có giải pháp nào tối ưu để chống lại DDoS, giải pháp em đề xuất là một trong những giải pháp đã được triển khai và đã có những thành công trong việc chống lại DDoS làm cho máy chủ web nói chung và apache nói riêng không bị quá tải, không phục vụ được cho những người dùng hợp lệ. 3. Mô hình thử nghiệm Do điều kiện khách quan nên em chỉ có thể triển khai và kiểm nghiệm trên mô hình trong mạng LAN. Mô hình thử nghiệm như sau: Hình 18: Mô hình mạng thử nghiệm Trong mô hình này: - Gồm có 5 máy tính có cấu hình là 1Gb ram, CPU 2.2Ghz trong đó có 1 máy sử dụng làm IPS/Máy chủ web (snort inline, Iptables , module ipt_connlimit, cài đặt apache, php, mysql) trên đó có cài đặt một trang web sử dụng code joomla, 4 máy còn lại đóng vai trò là attack host - Tất cả các kết nối đều là full-duplex 100Mbit/s Ethernet (100BaseT) 4. Triển khai hệ thống 4.1 Tối ưu hóa server ở tầng TCP/IP Bật chức năng tcp_syncookies : Bật chức năng này là cách đơn giản nhất để chống lại SYN flood. sysctl -w net.ipv4.tcp_syncookies=1 Đặt giá trị cho backlog queue : Giá trị tcp_max_syn_backlog sẽ quyết định có bao nhiêu gói SYN được lưu trữ. tcp_syncookies phải được bật giá trị này mới có hiệu lực. sysctl -w net.ipv4.tcp_max_syn_backlog="2048" Đặt lại số lần truyền lại gói SYN,ACK để reply lại gói SYN request. Mặc định là 5 lần tương đương với thời gian timeout của kết nối TCP là 180 giây. Đặt giá trị là 1 tương đương với thời gian timeout là 9 giây. sysctl -w net.ipv4.tcp_synack_retries="1" Bật chức năng IP spoofing protaction sysctl -w net.ipv4.conf.all.rp_filter ="1" Không chấp nhận forward broadcast sysctl -w net.ipv4.icmp_echo_ignore_broadcasts="1" Không chấp nhận source routed packet sysctl -w net.ipv4.conf.all.accept_source_route=0 Tắt ICMP redirect sysctl -w net.ipv4.conf.all.accept_redirects=1 Bật bad error message protection sysctl -w net.ipv4.icmp_ignore_bogus_error_responses=1j Một số cấu hình TCP khác : tcp_abort_on_overflow : Có 2 giá trị 0(mặc định) và 1. Nếu có giá trị là 1 kernel sẽ reset những kết nối mới khi queue đầy. tcp_fin_timeout : Mặc định là 60 giây.Giá trị của biến này quyết định kernel sẽ giữ những socket ở trạng thái FIN_WAIT-2 trong bao lâu nếu không nhận được gói ACK/FIN từ phía client tcp_orphan_retries: Mặc định là 7.Giá trị này sẽ quyết định TCP/IP stack thử ngắt kết nối ở phía client trước khi đóng kết nối từ server. somaxconn : Mặc định là 128.Giá trị này giới hạn kích thước của listen queue cho các gói new SYN ip_conntrack_max : số kết nối tcp lớn nhất mà hệ thống có thể quản lý. 4.2 Cài đặt module connlimit cho Iptables Cài rpm-build yum install rpm-build Tạo user ruby useradd -d /home/ruby -s /bin/bash ruby Đặt password cho user ruby passwd ruby Login vào user ruby Xác định version của kernel đang dùng uname -a Xác định version của Iptables đang dùng iptables -v Download các packet và đặt ở thư mục home của user wget (cùng version với kernel đang dùng) wget (cùng version với Iptables đang dùng) wget Xây dựng môi trường build cho user cd ~ mkdir -p \ rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS} echo ‘%_topdir %(echo $HOME)/rpmbuild’ > .rpmmacros Cài kernel source rpm -i kernel-2.6.18-92.1.22.e15.src.rpm cd ~/rpmbuild/SPECS rpmbuild -bp –target=`uname -m` kernel-2.6.spec Sau bước trên kernel source sẽ được tạo ra tại : ~/rpmbuild/BUILD/kernel-2.6.18/linux-2.6.18.i686 Giải nén iptables và path-o-matic-ng cd ~ tar -xvjf iptables-1.3.5.tar.bz2 tar -xvjf path-o-matic-ng-20090326.tar.bz2 Tạo và gán giá trị cho 2 biến môi trường export KERNEL_DIR=~/rpmbuild/BUILD/kernel-2.6.18/linux-2.6.18.i686 export IPTABLES_DIR=~/iptables-1.3.5/ Patch modules connlimit cd path-o-matic-ng-20090326 ./runme download ./runme connlimit Cập nhật module vào kernel cd ~/rpmbuild/BUILD/kernel-2.6.18/linux-2.6.18.i686 make oldconfig make prepare make modules_prepare cd net/ipv4/netfilter make -C ~/rpmbuild/BUILD/kernel-2.6.18/linux-2.6.18.i686 M=$PWD modules Copy new modules into update directory of the current system to set them active: sudo cp ipt_connlimit.ko /lib/modules/2.6.18-92.1.22.e15/updates sudo cd /lib/modules sudo depmod 2.6.18-92.1.22.e15 Load module ipt_connlimit sudo modprobe ipt_connlimit Sử dụng : Giới hạn chỉ có 5 connection từ một IP đến apache iptables -A INPUT -p tcp --syn --dport 80 -m connlimit -- connlimit-above 5 -j REJECT 4.3 Cài đặt Snort inline 4.3.1 Cài đặt Snort inline - Cài libnet-1.0.2a (các version mới hơn không thích hợp với snort inline ) wget tar xzvf libnet-1.0.2a.tar.gz cd Libnet-1.0.2a ./configure make make install - Cài Flex, bison, libpcap,iptables-devel,pcre, pcre-devel yum install flex bison libpcap iptables-devel pcre pcre-devel Download snort (snort-2.8.3.1.tar.gz) và rules (snortrules-snapshot-CURRENT.tar.gz) tại - Giải nén: tar -xvzf snort-2.8.3.1.tar.g - Compile và cài đặt snort : cd snort-2.8.3.1 ./configure --enable-inline --enable-flexresp make make install groupadd snort useradd -g snort snort -s /sbin/nologin mkdir /etc/snort mkdir /etc/snort/rules mkdir /var/log/snort cd etc/ cp * /etc/snort Giải nén rules tar -xvzf snortrules-snapshot-CURRENT.tar.gz cp rules/* /etc/snort/rules - Chỉnh lại rules.Sửa tất cả các rule alert sang drop cd /etc/snort_inline/rules/ for file in $(ls -1 *.rules) do sed -e 's:^alert:drop:g' ${file} > ${file}.new mv ${file}.new ${file} -f done Chỉnh sửa lại file snort.config :Mở file /etc/snort/snort.config và sửa theo các dòng sau : var HOME_NET 192.168.1.0/24 với 192.168.1.0/24 là mạng nội bộ var EXTERNAL_NET !$HOME_NET var RULE_PATH /etc/snort/rules - Tạo file snort tại /etc/init.d/snort có nội dung như sau: #!/bin/sh # # chkconfig: 2345 99 82 # description: Starts and stops the snort intrusion detection # system # # config: /etc/snort/snort.conf # processname: snort # Source function library . /etc/rc.d/init.d/functions BASE=snort DAEMON="-D -Q" INTERFACE="-i eth0" CONF="/etc/snort/snort.conf" # Check that $BASE exists. [ -f /usr/local/bin/$BASE ] || exit 0 # Source networking configuration. . /etc/sysconfig/network # Check that networking is up. [ ${NETWORKING} = "no" ] && exit 0 RETVAL=0 # See how we were called. case "$1" in start) if [ -n "`/sbin/pidof $BASE`" ]; then echo -n $"$BASE: already running" echo "" exit $RETVAL fi echo -n $"Starting ip_queue module:" lsmod | grep ip_queue >/dev/null || /sbin/modprobe ip_queue; echo -e '\t\t\t\t [ \033[32mOK\033[37m ]' echo -n $"Starting iptables rules:" #iptables -N ip_queue #iptables -I INPUT -p tcp -j ip_queue #Add new IPTABLES rules here and they will be added into the #ip_queue Ruleset iptables -I INPUT -p tcp --dport 80 -j QUEUE echo -n "Starting snort service: " export PCAP_FRAMES =32768 /usr/local/bin/$BASE $INTERFACE -c $CONF $DAEMON sleep 1 action "" /sbin/pidof $BASE RETVAL=$? [ $RETVAL -eq 0 ] && touch /var/lock/subsys/snort ;; stop) echo -n "Shutting down snort service: " killproc $BASE unset PCAP_FRAMES echo -ne $"\nRemoving iptables rules:" iptables -F iptables -X echo -e '\t\t\t\t [ \033[32mOK\033[37m ]' echo -n $"Unloading ip_queue module:" rmmod ip_queue echo -en '\t\t\t\t [ \033[32mOK\033[37m ]' RETVAL=$? echo [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/snort ;; restart|reload) $0 stop $0 start RETVAL=$? ;; status) status $BASE RETVAL=$? ;; *) echo "Usage: snort {start|stop|restart|reload|status}" exit 1 esac exit $RETVAL - Gán quyền : chmod 755 /etc/init.d/snort - Cấu hình để Snort chạy startup. chkconfig snort on 4.3.2 Tự động cập nhật rule Để tự động cập nhật rule cho Snort inline ta sẽ cài thêm chương trình oinkmaster. Nhiệm vụ chính của chương trình này là tự động download các rule mới nhất về theo lịch định sẵn. Download oinkmaster-2.0 tại : Giải nén : tar oinkmaster-2.0.tar.gz cd oinkmaster-2.0 cp oinkmaster.pl /usr/local/bin/ cp oinkmaster.conf /etc/ Vào trang đăng kí một tài khoản miễn phí để lấy oinkcode. - Mở file /etc/oinkmaster.conf và thay đổi url theo oinkcode của mình. url = - Mở file /etc/oinkmaster.conf và tìm đến dòng : # Example to make SID 1378 a 'drop' rule (valid if you're running # Snort_inline). # modifysid 1378 "^alert" | "drop" - Bỏ dấu “#” để trỏ thành : # Example to make SID 1378 a 'drop' rule (valid if you're running # Snort_inline). modifysid 1378 "^alert" | "drop" - Tiếp theo, đặt lịch cho oinkmaster tự động cập nhật rule.Trên terminal gõ crontab -e 55 00 * * * /usr/local/bin/oinkmaster.pl -o /etc/snort_inline/rules/ > /dev/null 2>&1 - Nhấn Esc rồi gõ :wq - Lệnh trên là đặt một lịch cứ vào 00:55 phút của bất kì ngày nào sẽ thực hiện cập nhật rules cho Snort inline. 4.3.3 Giải pháp kĩ thuật với vấn đề lưu log Do Snort chỉ lưu các alert vào file /var/log/snort/alert (mặc định) nên sau một thời gian file alert sẽ có kích thước rất lớn làm cho vừa lãng phí dung lượng ổ cứng vừa gây khó khăn cho người quản trị có thể xem xét các cảnh báo của Snort. Để khắc phục nhược điểm này thì có nhiều cách, em sẽ sử dụng logrotate để khác phục nhược điểm này vì logrotate là một tiện ích có sẵn của hệ điều hành Centos nói riêng và trên các hệ điều hành Linux nói chung. 4.3.3.1 Tổng quan về logrotate Logrotate là một công cụ trên các hệ thống Linux dùng để thiết lập chính sách quay vòng định kỳ cho các log file. Với Logrotate các file log có thể được định kỳ sử dụng lại theo ngày tuần tháng hay theo kích thước file log, nén, xoá bỏ file log... Hoạt động của logrotate mặc định được cấu hình tại file /etc/logrotate.conf thông qua những tham số tuỳ chọn, sau đây là một số tham số thường dùng. compress : nén những file log đã sử dụng. nocompress: ngược lại với tuỳ chọn compress . create mode owner group: khi sử dụng một file log mới, file log mới được tạo sẽ có các thuộc tính (mode, owner group). nocreate : không tạo file log mới. mail address : khi hết chu kỳ sử dụng file log sẽ được gửi tới địa chỉ (address). nomail : ngược lại với tuỳ chọn trên. daily : chu kỳ sử dụng file log theo ngày. weekly : chu kỳ sử dụng file log theo tuần. monthly : chu kỳ sử dụng file log theo tháng. rotate count : xác định số lần luân phiên sử dụng file log. size size : chu kỳ sử dụng file log được xác định theo kích thước. include /etc/logrotate.d : đọc thêm các thông tin cấu hình tại các file trong thư mục /etc/logrotate. Các tham số khai báo ở các file này có độ ưu tiên cao hơn các tham số khai báo trong file /etc/logrotate.conf. Ví dụ: weeklyrotate 4errors rootcreatecompressinclude /etc/logrotate.d/var/log/wtmp {monthlycreate 0664 root utmprotate 1}/var/log/lastlog {monthlyrotate 1} Phần mặc định xác định mỗi file log được ghi trong một tuần, chỉ lưu lại file log của bốn tuần, các thông báo lỗi của logrotate được gửi tới root, các file log lưu trữ được nén lại.Cho phép logrotate đọc thêm các thông tin cấu hình nằm tại các file trong thư mục /etc/logrotate.d File log /var/log/wtmp được ghi log trong một tháng, khi tạo file log mới file này có thuộc tính là 0664, owner là root, group là utmp, chỉ lưu thông tin log trong một tháng. File log /var/log/lastlog được ghi log trong một tháng, chỉ lưu thông tin log trong một tháng. 4.3.3.2 Xoay vòng log cho Snort Tạo file snort tại /etc/logrotate.d/ với nội dung /var/log/snort/alert { daily rotate 7 missingok notifempty sharedscripts create 0640 snort snort postrotate /etc/init.d/snort restart >/dev/null endscript } Đặt lịch cho logrotate chạy vào lúc 0h mỗi ngày. crontab -e 00 00 * * * /usr/sbin/logrotate -f /etc/logrotate.conf > /dev/null 2>&1 4.4 Thử nghiệm, đánh giá Với mục tiêu đặt ra là tăng thời gian chống chịu DDoS cho máy chủ web để những người quản trị có thời gian khắc phục, nên em xây dựng test case theo mục tiêu đã đề ra. Trước hết là tiến hành cài đặt một site joomla trên máy chủ web. Sau đây là một số hình ảnh của trang web. Hình 19: Hình trang chủ DemoDDoS Trang chủ gồm trang lý thuyết và trang phòng chống. Hình 20: Hình trang phòng chống DDoS Công cụ để đo thời gian đáp ứng được sử dụng là jmeter, một project của apache. Hình ảnh về jmeter: Hình 21: Giao diện chính của Jmeter Các bước để chuẩn bị test thời gian đáp ứng: Tạo một Thread Group : right-click vào Test plan chọn add -> Thread Group như hình : Hình 22: Tạo Thread Group Trong đó, Number of Threads là số user (concurrent connections) đến máy chủ web. Ramp-Up Period là thời gian để chạy hết số Threads đã khai báo ở trên.Ví dụ: Có 10 thread và Ramp-Up period là 100 giây thì jmeter sẽ chạy tất cả 10 thread trong 10 giây. Mỗi thread sẽ khởi động sau 10 giây sau khi thread trước nó khởi động. Loop Count là số lần lặp lại. Tạo HTTP Request Default như sau: right-click vào Thread Group chọn Add-> Config Element chọn HTTP Request Default. Nhập IP của máy chủ web như trong hình (IP của máy chủ web là 192.168.1.130) Hình 23: Tạo HTTP Default Request Để xác định thời gian đáp ứng cho trang chủ ta làm như sau: Right-click vào Thread Group chọn Add->Sampler chọn HTTP Request. Trong mục HTTP Request sửa tên thành home và gõ index.php tại Patch như trong hình Hình 24: Tạo Home Request Tương tự tạo một HTTP Request đến trang phòng chống Hình 25: Tạo HTTP Request Cuối cùng thêm vào các thông báo right-click vào Thread Group chọn Add -> Listener chọn Graph Results, Summary Report và Aggregate. Để bắt đầu kiểm tra ta chọn Run -> Start. Công cụ để DDoS được sử dụng là DOSHTTP 2.0, sau đây là các bước sẽ triển khai để thực hiện kiểm tra, đánh giá. Bước 1: Kiểm tra server khi chạy bình thường chưa có hệ thống phòng thủ và chưa bị DDoS - Đo thời gian đáp ứng của server sử dụng công cụ jmeter - Kiểm tra tài nguyên của server đang dùng Bước 2: Kiểm tra server khi cài đặt hệ thống phòng chống và chưa bị DDoS - Đo thời gian đáp ứng của server sử dụng công cụ jmeter - Kiểm tra tài nguyên của server đang dùng Bước 3: Kiểm tra server khi chưa cài hệ thống phòng chống và đang bị DDoS - Đo thời gian đáp ứng của server sử dụng công cụ jmeter - Kiểm tra tài nguyên của server đang dùng. Bước 4:Kiểm tra server khi đã cài hệ thống phòng chống và đang bị DDoS - Đo thời gian đáp ứng của server sử dụng công cụ jmeter - Kiểm tra tài nguyên của server đang dùng. Thực hiện : Bước 1: - Sử dụng công cụ jmeter với ta được đồ thị thời gian đáp ứng trung bình: Hình 26: Đồ thị thời gian đáp ứng trung bình và thông lượng (bước 1) Thông qua đồ thị ta thấy : ở điều kiện bình thường, thời gian đáp ứng trung bình là 165 ms, thông lượng là 359,865 request/phút. - Tài nguyên của hệ thống : Hình 27: Tài nguyên của hệ thống ( bước 1) Tải trung bình là giá trị CPU load trong 1, 5 và 15 phút. Như trên hình thì giá trị CPU load trong 1 phút trước là 0.59, trong 5 phút trước là 0.53 và trong 15 phút trước là 1,26. Có nghĩa là trong một phút hay năm phút trước không có tiến trình nào phải chờ để được CPU xử lý, còn trong 15 phút trước thì có 1 tiến trình đang được xử lý và 0.26 tiến trình phải chờ. Bước 2: Sử dụng công cụ jmeter với ta được đồ thị thời gian đáp ứng trung bình: Hình 28: Đồ thị thời gian đáp ứng trung bình và thông lượng ( bước 2) - Tài nguyên của hệ thống : Hình 29: Tài nguyên của hệ thống ( bước 2) So sánh kết quả giữa bước 1 và bước 2 ta thấy không có sự chênh lệch nhiều giữa thời gian đáp ứng trung bình (164 ms và 167 ms ), CPU load (0,59 và 0,64), RAM sử dụng (~ 250 Mb), SWAP (55Mb và 63 MB).Như vậy có thể kết luận sau khi cài đặt hệ thống phòng chống DDoS thì web server bị ảnh hưởng không đáng kể. Bước 3: Tài nguyên của hệ thống lúc sắp bị DDoS Hình 30: Tài nguyên của hệ thống khi sắp bị DDoS (bước 3) Bắt đầu bị DDoS, các packet đến card mạng tăng vọt Hình 31: Đồ thị traffic của mạng khi bị DDoS (bước 3) Sau tài nguyên hệ thống sau hai phút bị DDoS Hình 32: Tài nguyên của hệ thống sau hai phút bị DDoS (bước 3) Tài nguyên của hệ thống sau năm phút Hình 33: Tài nguyên của hệ thống sau năm phút bị DDoS (bước 3) Và tại thời điểm đấy không thể truy cập vào trang web Demo DDoS được. Hình 34: Hình ảnh Web site Demo DDoS Sử dụng công cụ jmeter với ta được đồ thị thời gian đáp ứng trung bình: Hình 35: Đồ thị thời gian đáp ứng trung bình và thông lượng ( bước 3) Nhận xét : - Ngay khi bắt đầu bị DDoS, số lượng packet đến card mạng của web server tăng vọt (khoảng 1300 packet/giây so với trước khi bị DDoS chỉ có khoảng 50 packet/ giây). - Sau 2 phút, có thể thấy apache đã phải tạo ra rất nhiều child process để xử lý các request đến. Khiến cho server load trung bình trong 1 phút vừa qua lên đến 25.46 , RAM còn dư 11Mb. - Sau 5 phút, server load đã lên đến 44.18, lượng RAM còn dư là khoảng 13Mb. Như vậy là apache đã đạt đến giới hạn phục vụ (RAM còn rất ít và không đổi tức là apache không thể tạo thêm child process để phục vụ request nữa) như vậy những người dùng hợp pháp gần như không thể truy cập vào web site Demo DDoS. - Trên đồ thị thời gian đáp ứng, ta nhận thấy thời gian đáp ứng trung bình tăng lên tới 32640 ms tức là 32 giây gấp gần 200 lần thời gian đáp ứng khi server hoạt động bình thường (bước 1) Bước 4: - Thêm rule cho iptable: iptables -A INPUT -m conntrack --ctstate INVALID -j DROP iptables -A INPUT -p tcp -m tcp --dport 80 -m connlimit --\ connlimit-above 20 -j DROP - Thêm rule chặn DOSHTTP 2.0 cho snort drop tcp any any -> any 80 (classtype:attempted-user;sid:5;msg:"Detect\ DoSHTTP";content:"|2e 4e 45 54 20 43 4c\ 52|";offset:54;resp:rst_rcv;) Tài nguyên hệ thống ngay trước khi bị DDoS Hình 36: Tài nguyên của hệ thống trước khi bị DDoS (bước 4) i Bắt đầu bị DDoS Hình 37: Đồ thị traffic của mạng khi bị DDoS (bước 4) Sau 2 phút bị DDoS ta nhận được: Hình 38: Tài nguyên của hệ thống sau hai phút bị DDoS (bước 4) Sau 5 phút bị DDoS: Hình 39: Tài nguyên của hệ thống sau năm phút bị DDoS (bước 4) - Sử dụng công cụ jmeter với ta được đồ thị thời gian đáp ứng trung bình: Hình 40: Đồ thị thời gian đáp ứng trung bình và thông lượng ( bước 4) Nhận xét: Sau 2 phút và 5 phút bị DDoS, giá trị server load (0,24)và đáp ứng time trung bình (182) có chênh lệch không đáng kể so với giá trị server load và đáp ứng time ở bước 1 và bước 2. RAM sử dụng tăng lên 380 MB so với ở bước 1 và bước 2 là 250 MB. RAM tăng lên do server phải kiểm tra số lượng connection từ một IP và kiểm tra các packet đến apache (Snort inline). Để server vẫn phục vụ được cho những người dùng hợp pháp trong khi bị DDoS thì theo em mức độ sử dụng tài nguyên như vậy là chấp nhận được. Rule của iptables sử dụng connlimit thì chỉ cho phép 20 connection từ một địa chỉ IP đến port 80 (http), nếu nhiều hơn thì sẽ DROP. Còn Snort inline thì sẽ kiểm tra trong các connection đi qua được firewall cái nào có chuỗi mà match với chuỗi trong rule thì cũng sẽ cũng sẽ bị DROP. Chính vì thế mà số packet đến được và được apache xử lý khá ít và toàn là packet hợp lệ nên server load khá nhỏ. Một vài nhận xét sau khi thực hiện kiểm tra đánh giá: - Hệ thống đã đáp ứng được mục tiêu đưa ra-kéo dài thời gian “phục vụ” của server khi bị DDoS. - Việc lựa chọn giá trị để giới hạn số connection từ một IP cần phải được xem xét cẩn thận để không làm ảnh hưởng đến những người dùng hợp pháp. - Do việc triển khai test trong mạng LAN và có số lượng ít máy tham gia nên chưa được sát với thực tế. Kết luận: Sau khoảng 3 tháng làm đồ án, ít nhiều em cũng đã tìm hiểu tương đối thành công về DDoS và xây dựng được thành công phương pháp phòng chống DDoS theo cách hiểu của mình. Qua những gì tìm hiểu được, em vẫn cảm thấy vẫn còn nhiều điều phải làm để có thể hoàn thiện hơn đồ án cũng như cần có sự hướng dẫn nhiều hơn nữa của các thầy cô và bạn bè. 1. Những kết quả đạt được: Theo yêu cầu đặt ra ban đầu là “Tìm hiểu DDoS và xây dựng biện pháp phòng chống DDoS cho máy chủ web”, cho đến thời điểm hiện tại đồ án đã đạt được những nội dung sau: - Phần yêu cầu: + Tìm hiểu lý thuyết về DDoS bao gồm lý thuyết chung, phân loại các kiểu DDoS, nắm được các cách xây dựng mạng Botnet, biết được một số công cụ tấn công DDoS và đặc biệt là các cách phòng chống DDoS. + Triển khai thành công hệ thống phòng chống DDoS cho máy chủ web bao gồm tìm hiểu lý thuyết và cài đặt cấu hình thành công Snort inline và module connlimit cho Iptables, nắm được một số cấu hình cơ bản về tối ưu hóa TCP/IP cho hệ điều hành Centos 5.2. - Phần mở rộng : Bên cạnh đó, trong quá trình nghiên cứu và hoàn thành đồ án, em còn tiếp thu thêm một số kết quả sau: + Tìm hiểu lý thuyết, cài đặt và bước đầu tối ưu hóa apache. + Xây dựng được một trang web trên nền joomla. + Tìm hiểu và sử dụng công cụ jmeter để kiểm tra máy chủ web. + Tìm hiểu và sử dụng công cụ wireshark để bắt gói tin phục vụ cho việc viết rule cho Snort inline. + Tìm hiểu và sử dụng công cụ Colasoft Capsa để theo dõi traffic của mạng. 2. Hướng phát triển: Trong quá trình nghiên cứu và tìm hiểu đề tài, em nhận thấy DDoS càng ngày càng có nhiều biến thể tinh vi hơn, mức độ phá hoại cũng cao hơn như DRDDoS (Distributed Reflexive Denial of Services), làm cho việc phòng chống DDoS ngày một khó khăn hơn.Dưới đây là một số hướng phát triển để nâng cao hiệu quả của hệ thống phòng chống DDoS cho máy chủ web cũng như nâng cao khả năng phòng chống DDoS cho máy chủ web. Nghiên cứu áp dụng module security của apache. Nghiên cứu triển khai hệ thống trên nhiều mô hình mạng khác nhau. Triển khai load balancing cho máy chủ web. Nghiên cứu triển khai hệ thống HONEYNET để phát hiện sớm các tấn công DDoS từ đó có những biện pháp phòng chống. Tài liệu tham khảo - Trang web: - Danh sách các tài liệu, sách giáo trình tham khảo : Network Security – Defense Against DoS/DDoS Attacks Tác giả HangChau A Defense Framework for Flooding-based DDoS Attacks (2007) Tác giả Yonghua You Internet Denial of Service: Attack and Defense Mechanisms (2004) Tác giả Jelena Mirkovic, Sven Dietrich, David Dittrich, Peter Reiher Snort manual 2.8.3 (12/2008) do Snort Project phát hành. Iptables manual.