Đánh giá thực nghiệm

CHƯƠNG 3. PHÁT HIỆN VÀ PHÒNG CHỐNG TẤN CÔNG WEB APP-DDOS

3.6. Đánh giá thực nghiệm

3.6.1. Tạo dữ liệu thử nghiệm

Tương tự như với dạng tấn công TCP Syn Flood, đối với tấn công Web App-DDoS, chúng tôi đã nghiên cứu các công trình đã được công bố liên quan trực tiếp đến phát hiện và phòng chống tấn công Web App-DDoS để tham khảo cách thức các tác giả thực hiện đánh giá thực nghiệm đối cho các phương pháp họ đề xuất. Tuy nhiên, chúng tôi thấy rằng các nghiên cứu liên quan đến tấn công Web App-DDoS được đề cập ở 1.7 và một số nghiên cứu liên quan đến tấn công Web App-DDoS được đề cập ở chương 1 không sử dụng một dữ liệu mẫu chung nào để đánh giá thực nghiệm mà mỗi tác giả tự xây dựng môi trường thử nghiệm cho riêng mình.

Do đó, để có dữ liệu kiểm thử, chúng tôi tạo ra dữ liệu kiểm thử từ môi trường ảo được đề cập ở mục 2.6.1 như cách đã thực hiện với dạng tấn công TCP Syn Flood. Cụ thể như sau:

Các máy Client bị nhiễm mã độc sẽ định kỳ 1s, truy cập thông tin điều khiển từ C&C máy chủ thông qua giao thức http tại địa chỉ: http://lab.ais.gov.vn/ddos-control.txt. Cấu trúc của lệnh điều khiển như sau:

Dạng tấn công Địa chỉ tấn công Cổng dịch vụ Trạng thái điều khiển

webattack URL tấn công 80 Enable/disable

Bảng 3.2 Bảng cấu trúc lệnh tấn công DDoS lớp ứng dụng

Với cấu trúc lệnh trên, Các máy Client sẽ thực hiện tấn công dạng Web App-DDoS với địa chỉ URL nhận được từ C&C Server. Trong thực nghiệm này, chúng tôi thiết lập URL của đích tấn công là: http://sdh.hust.edu.vn/home/Default.aspx?scid=29&CategoryID=135.

Sau khi thực hiện tấn công giả định trong khoảng thời gian 03 phút, chúng tôi thu được tập dữ liệu được lưu trữ dưới dạng PCAP trong đó có 66.851 gói tin [2]. CSDL thu được có cấu trúc như bảng 3.1 bao gồm 1.310 yêu cầu, trong đó có cả yêu cầu tấn công và yêu cầu bình thường và được lưu trữ trong CSDL MySQL [111].

Để đánh dấu các nguồn gửi yêu cầu tấn công phục vụ việc đánh giá thử nghiệm, các yêu cầu được gửi đi từ các địa chỉ IP trong mạng botnet (trong mô hình thử nghiệm trên môi trường ảo) sẽ được đánh dấu là các nguồn gửi yêu cầu tấn công. Các IP nguồn khác không nằm trong dải địa chỉ IP của mạng botnet sẽ được đánh dấu là nguồn gửi yêu cầu bình thường.

3.6.4. Đánh giá thử nghiệm phương pháp FDDA

3.6.4.1. Kết quả xác định nguồn gửi yêu cầu tấn công theo tiêu chí tần suất

Sau khi áp dụng thuật toán đối với tập dữ liệu [2], chúng tôi tìm tần suất gửi yêu cầu của các srcIP như sau:

Sau khoảng thời gian lấy mẫu trong vòng 3 phút, chúng tôi thu được tần suất truy cập của 28 srcIP khác nhau. Trong đó có 16 srcIP tấn công. Số lượng địa chỉ srcIP thu được tương đối thấp bởi vì chúng tôi thu thập log truy cập vào website của Viện Đào tạo Sau Đại học của Trường Đại học Bách Khoa Hà Nội và website này có tần suất truy cập tương đối thấp.

Tôi chọn giá trị Δ = 10s, kết quả thực nghiệm chúng tôi thu được tần suất truy cập ứng với mỗi srcIP như sau:

SrcIP f1 f2 f3 f4 f5 f6 f7 f8 f9 f10 f11 f12 f13 f14 f15 f16 f17 f18 103.16.1.144 31 31 31 31 31 28 24 24 24 24 21 13 13 13 13 1 0 0 103.192.237.10 54 53 51 49 46 44 40 37 33 30 25 21 15 8 6 3 3 0 103.192.237.11 68 65 59 56 53 50 45 42 37 34 28 22 18 16 13 10 9 6 103.192.237.12 54 48 44 42 39 39 38 35 35 30 26 23 20 16 11 8 4 2 103.192.237.13 40 36 29 25 18 14 8 2 24 23 20 20 16 16 13 9 5 2 103.192.237.14 61 56 54 51 45 41 38 34 31 30 25 19 15 15 11 7 5 3 103.192.237.15 68 65 59 54 52 48 44 42 40 35 32 24 18 17 13 10 9 5 103.192.237.16 64 61 61 57 56 50 49 44 41 36 34 31 24 20 18 15 9 5 103.192.237.2 65 59 57 55 49 47 45 42 38 34 32 28 24 21 16 14 7 5 103.192.237.21 68 66 63 59 51 48 43 42 36 31 29 25 21 15 13 9 5 1 103.192.237.3 65 61 57 53 47 43 41 40 36 35 31 28 24 19 12 7 5 0 103.192.237.4 61 60 58 61 61 59 55 52 47 44 37 35 33 25 21 14 10 8 103.192.237.5 66 61 60 51 48 39 35 30 26 20 19 18 18 17 16 13 8 3 103.192.237.6 76 69 63 59 57 53 51 46 42 37 33 28 23 18 16 14 8 6 103.192.237.7 57 70 67 63 61 58 52 47 41 38 30 27 25 21 16 13 11 3 103.192.237.8 51 49 44 43 39 37 34 28 25 23 22 17 15 12 7 5 3 1 103.192.237.9 82 80 76 73 71 66 59 55 50 45 42 40 38 32 28 22 17 8 103.254.16.182 67 67 67 60 52 48 48 48 37 26 9 9 9 5 4 0 0 0 103.7.36.15 10 10 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 117.1.182.136 11 11 11 11 11 11 11 11 11 0 0 0 0 0 0 0 0 0 123.16.244.47 27 14 14 14 14 14 14 11 10 10 10 10 10 6 6 6 0 0 123.24.204.44 19 16 15 15 15 15 15 8 8 8 8 8 6 5 5 5 0 0

123.30.175.181 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 14.181.208.119 12 12 12 12 12 12 12 12 12 0 0 0 0 0 0 0 0 0 14.239.6.125 13 13 13 13 13 13 13 13 13 13 13 13 13 0 0 0 0 0 27.67.181.184 28 28 28 28 28 28 27 0 0 0 0 0 0 0 0 0 0 0 66.249.66.208 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 95.25.119.105 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 3 0 0

Bảng 3.3 Bảng thực nghiệm xác định tần suất truy cập

Tôi chọn số lần kiểm thử k = 18. Sau khi áp dụng thuật toán kiểm thử chúng tôi phát hiện được 12/16 nguồn gửi yêu cầu có tần suất gửi cao và đồng đều, còn 04 nguồn gửi yêu cầu còn lại chúng tôi sẽ tiếp tục xác minh sử dụng tiêu chí tương quan.

3.6.4.2. Kết quả xây dựng tập yêu cầu tương quan

Tôi thực hiện lấy mẫu log truy cập vào trang web của Viện Đào tạo Sau Đại học của Trường Đại học Bách Khoa Hà Nội từ thời điểm 17/10/2018, 18:21:22 đến 18/10/2018, 09:20:35.

Kết quả chúng tôi thu được 6.686 yêu cầu từ 372 srcIP khác nhau. Chúng tôi thiết lập tham số đầu vào cho thuật toán Association Rule với Độ hỗ trợ = 2 và độ tin cậy ≥ 50%. Kết quả chúng tôi thu được 140 tập dữ liệu tương quan.

3.6.4.3. Kết quả đánh giá thử nghiệm phương pháp FDDA

Tôi thực hiện đánh giá thực nghiệm với tập dữ liệu [2] sử dụng các tham số dưới đây được sử dụng như sau:

 Ngưỡng phát hiện yêu cầu nghi ngờ tấn công FT (requests/second).

 Số lượng yêu cầu trong tập DSus.

 Số lượng yêu cầu nghi ngờ tấn công trong tập RA.

 Tỷ lệ phát hiện đúng các nguồn gửi tấn công: Detection Rate - DR.

 Tỷ lệ phát hiện nhầm các nguồn bình thường là tấn công: False Positive - FP.

Kết quả thực nghiệm cho thấy phương pháp của chúng tôi có tỷ lệ phát hiện cao như trong bảng dưới đây:

FT DSus RA DR FP

50 250 185 75.32% 1.28%

100 500 365 92.56% 1.11%

150 750 668 94.08% 0.89%

200 1000 897 88.75% 1.47%

300 1310 863 67.89% 1.49%

Bảng 3.4 Kết quả thực nghiệm của phương pháp FDDA

Từ kết quả thực nghiệm ở trên cho thấy tỷ lệ phát hiện các nguồn gửi yêu cầu tấn công phụ thuộc vào giá trị FT. Giá trị này cần điều chỉnh cho phù hợp tương ứng với từng máy chủ cần bảo vệ.

Trường hợp giá trị FT được thiết lập quá nhỏ thì sẽ làm tăng tỷ lệ phát hiện nhầm các nguồn gửi yêu cầu bình thường là nguồn tấn công. Trường hợp giá trị FT được thiết lập quá lớn thì sẽ bỏ sót các nguồn gửi tấn công có tần suất gửi yêu cầu thấp và làm ảnh hưởng tới tỷ lệ phát hiện các nguồn gửi tấn công DR.

3.6.5. So sánh hiệu quả của phương pháp FDDA với các phương pháp khác Trong phần này, phương pháp FDDA sẽ được so sánh với các phương pháp khác. Chúng tôi sử dụng 09 tham số được tác giả Qin Liao [92] đưa ra để đánh giá thực nghiệm. Giá trị của những tham số này được tính toán từ tập dữ liệu [2] và được sử dụng làm tham số đầu vào cho thuật toán Naive Bayes (NB) [72] và KNN [86]. Các tham số bao gồm:

 sourceAddress,

 requestTimes

 diffReqTimes

 timesOfCode200

 totalLength

 sessionDuration

 sequenceOfUrlLevel

 sequenceOfRequestFrequency

 sequenceOfRequestInterval

Kết quả so sánh về hiệu quả phát hiện tấn công:

Methods Detection Rate False Positive

KNN [86] 89.03% 1.03%

NB [72] 92.47% 1.47%

FDDA 93.75% 0.89%

Bảng 3.5 Bảng so sánh kết quả thực nghiệm giữa FDDA và KNN,NB Kết quả so sánh về thời gian xử lý:

Hình 3.19 Thời gian xử lý dữ liệu kiểm thử của FDDA ,KNN và NB

Kết quả cho thấy, trên cùng tập dữ liệu kiểm thử, phương pháp FDDA có tỷ lệ phát hiện các yêu cầu tấn công cao hơn (Detection Rate - 93.75%) và tỷ lệ phát hiện nhầm yêu cầu bình thường là yêu cầu tấn công (False Positive - 0.89%) so với hai phương pháp được so sánh.

0 20 40 60 80 100 120 140

250 500 750 1000 1310 Time(s)

Số lượng yêu cầu nhận được

KNN NB PIDAD2