Số lượng kết nối dang dở trên máy chủ
Mục tiêu của tấn công SYN Flood là kẻ tấn công tạo ra hàng loạt các kết nối dang dở trên máy chủ nhằm làm cạn kiệt tài nguyên kết nối mạng và máy chủ không thể thực hiện kết nối với các lưu lượng lành tính. Để đánh giá hiệu năng của giải pháp, số lượng kết nối dang dở trên máy chủ được thống kê với tần suất 1 lần/s bằng lệnh SYN-RECEIVED trong hai mơ hình: sử
dụng giải pháp SSP và phát lưu lượng tấn công trực tiếp vào máy chủ FTP cài đặt hệ điều hành Windows Server 2012 (Non SSP). Kết quả thống kê số lượng kết nối dang dở trên máy chủ ở các tốc độ tấn công s = 100 pps, 200 pps và 500 pps được thể hiện tương ứng trong Hình 2.17 a, b, c. Kết quả cho thấy:
• Ở giai đoạn đầu của quá trình phát lưu lượng tấn công, số kết nối dang dở tăng nhanh. Khi đạt đến ngưỡng cảnh báo, cơ chế bảo vệ SYN Flood của máy chủ Windows thực hiện xóa bỏ các kết nối TCP có thời gian chờ đạt mức 15s. Với tốc độ tấn cơng được duy trì đều, số lượng kết nối dang dở trong cả ba trường hợp sau thời gian quá độ được giữ ổn định ở mức xấp xỉ 1.500 HOC, 3.000 HOC và 7.500 HOC tương ứng với tốc độ tấn công 100 pps, 200 pps và 500 pps.
• Ở giải pháp SSP, các kết nối dang dở bị xóa bỏ dựa trên khơng chỉ thời gian tồn tại của từng kết nối mà còn dựa vào số lượng kết nối dang dở đang tạo ra trên máy chủ. Nhờ đó số lượng kết nối dang dở giữ ổn định ở một ngưỡng cố định xung quanh 1.000 HOC mà khơng có sự biến động lớn như ở giải pháp của Windows. Số lượng HOC giảm xấp xỉ 80% ở tốc độ tấn công 500 pps.
Thời gian tồn tại của các mục luồng trên bộ chuyển mạch
Để đánh giá ảnh hưởng của giải pháp tới hiệu năng hoạt động của kiến trúc SDN/Openflow trong đó có bộ chuyển mạch, so sánh SSP với cơ chế CM của giải pháp Avant-Guard đã trình bày ở mục 1.6.2, tham số thời gian tồn tại của các mục luồng được thống kê, tính tốn và so sánh.
• Đối với cơ chế CM, cơ chế ủy nhiệm gói tin SYN được thực hiện tại bộ chuyển mạch, sau khi xác thực quá trình bắt tay ba bước, mục luồng được tạo ra và được duy trì để thực hiện trao đổi gói tin dữ liệu, chuyển đổi cặp giá trị SEQ_Num/ACK_Num, nên thời gian tồn tại mục luồng của kết nối TCP được tính theo cơng thức:
𝑇𝑇𝐹𝐹𝐹𝐹_𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙_𝐶𝐶𝐶𝐶 = 𝑇𝑇𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙+ 𝑇𝑇𝑙𝑙𝑖𝑖𝑙𝑙𝑙𝑙𝑖𝑖𝑙𝑙𝑖𝑖𝑙𝑙𝑖𝑖𝑖𝑖𝑡𝑡− 𝑇𝑇ℎ𝑎𝑎𝑛𝑛𝑖𝑖𝑎𝑎ℎ𝑎𝑎𝑘𝑘𝑙𝑙 (2.13) trong đó:
𝑇𝑇𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙 là thời gian tồn tại thực của luồng và được tính bằng khoảng thời gian xuất hiện
gói tin đầu tiên và gói tin cuối cùng của luồng khi đi qua bộ chuyển mạch.
𝑇𝑇𝑙𝑙𝑖𝑖𝑙𝑙𝑙𝑙𝑖𝑖𝑙𝑙𝑖𝑖𝑙𝑙𝑖𝑖𝑖𝑖𝑡𝑡 là thời gian chờ của 1 luồng.
𝑇𝑇ℎ𝑎𝑎𝑛𝑛𝑖𝑖𝑎𝑎ℎ𝑎𝑎𝑘𝑘𝑙𝑙 là thời gian q trình bắt tay 3 bước cần diễn ra.
• Đối với giải pháp SSP, thời gian tồn tại mục luồng trên bộ chuyển mạch của một kết nối TCP (mục luồng FE5x trong Bảng 2.7) được tính từ khi OFS nhận gói tin SYN-ACK từ máy chủ đến khi gói tin xác nhận CliACK từ máy khách xuất hiện. Khoảng thời gian này xấp xỉ bằng khoảng thời gian bắt tay ba bước của luồng:
Để đánh giá và so sánh thời gian chiếm dụng của các mục luồng xử lý kết nối TCP của hai giải pháp trên, bộ dữ liệu CAIDA 2013 [107] được phân tích và thống kê. Các tham số của tập dữ liệu phân tích và kết quả phân tích được trình bày trong Bảng 2.8.
Bảng 2.8. Tham số và kết quả phân tích lưu lượng lành tính từ bộ dữ liệu CAIDA 2013
Số lượng máy chủ dùng để phân tích 100 máy chủ Tổng thời gian lưu lượng được phân tích 45 phút
Số luồng 3.947.883 luồng
Thời gian tồn tại trung bình của 1 luồng 𝑇𝑇𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙 18,26 s Thời gian bắt tay 3 bước trung bình 𝑇𝑇ℎ𝑎𝑎𝑛𝑛𝑖𝑖𝑎𝑎ℎ𝑎𝑎𝑘𝑘𝑙𝑙 0,93 s
Với kết quả phân tích ở Bảng 2.8, thời gian tồn tại trung bình các mục luồng của các kết nối TCP lành tính trên OFS khi áp dụng cơ chế CM của giải pháp Avant-Guard sẽ là:
TFE_life_CM = 18,26 – 0,93 = 17,33 (s)
Đối với giải pháp SSP:
TFE_life_SSP = Thandshake = 0,93 (s)
Do vậy so với cơ chế CM, SSP giảm được (17,33-0,93)/17,33 = 94% thời gian tồn tại trung bình của mục luồng tại bộ chuyển mạch. Khi thời gian các mục luồng chiếm dụng tài nguyên bộ chuyển mạch giảm xuống sẽ làm giảm tổng số lượng mục luồng tại một thời điểm, giúp cho tốc độ so khớp, xử lý các actions trên bộ chuyển mạch nhanh hơn, tăng khả năng chịu tải ngay cả khi tấn công DDoS xảy ra.
Ảnh hưởng lên bộ điều khiển khi xảy ra tấn công
Để đánh giá ảnh hưởng của giải pháp đề xuất đến Bộ điều khiển, trong quá trình thực hiện kịch bản tấn công, lượng tài nguyên sử dụng trên Bộ điều khiển được đo và thống kê ở các tốc độ tấn công khác nhau bằng công cụ htop của Linux [117] như trong Hình 2.18.
Kết quả đo và thống kê về sự chiếm dụng CPU và chiếm dụng bộ nhớ được thực hiện trong hai trường hợp SSP có và khơng thiết lập ngưỡng Chính sách xử lý gói tin được thể hiện ở trong Hình 2.19 và Hình 2.20. Kết quả cho thấy:
• Ở cả hai trường hợp (thiết lập ngưỡng và không thiết lập ngưỡng) tỷ lệ chiếm dụng CPU của Bộ điều khiển khoảng 20% khi chưa xảy ra tấn công. Và khi cường độ tấn công SYN Flood tăng dần, tỷ lệ chiếm dụng CPU tăng đều và đạt 68% ở tốc độ 1.000 pps trong trường hợp không thiết lập ngưỡng. Trong khi đó, tỷ lệ này tăng chậm và ổn định ở mức gần 50% ở cường độ tấn công 800 - 1.000 pps trong trường hợp thiết lập ngưỡng.
• Mức độ chiếm dụng dung lượng bộ nhớ giữ ổn định ở mức xấp xỉ 2GB trong cả 2 trường hợp và hầu như không thay đổi bởi tốc độ tấn cơng.
Hình 2.18. Giao diện màn hình đo sự chiếm dụng tài nguyên Bộ điều khiển ở tốc độ tấn công 700 pps