3.4. Giải pháp phân loại và giảm thiểu tấn công DDoS dựa trên kiến trúc SDN/Openflow mở rộng
3.4.7. Đánh giá hiệu năng của giải pháp
Để đánh giá khả năng đáp ứng và hiệu năng của hệ thống về mức độ giảm thiểu tác hại tấn cơng DDoS, q trình phân tích mơ phỏng được thực hiện đối với bộ lưu lượng được capture từ mạng thực của công ty Netnam tới một máy chủ dịch vụ web trong khoảng thời gian 600s. Bộ lưu lượng gồm 2 phần: lưu lượng lành tính và lưu lượng tấn cơng được thu thập và phân lập như mô tả trong mục 3.4.2. Các tham số của hệ thống được chọn như sau:
• Thời gian timeout cho các mục luồng CF_FEs: tidle = 10s, thard = 60s. Các tham số này được lấy theo tham số luồng phổ biến mặc định của các sản phẩm bộ chuyển mạch thương mại [110].
• Qua phân tích đặc tính lưu lượng của máy chủ, căn cứ vào đặc tính thống kê của máy chủ Web hoạt động ở điều kiện bình thường trong nhiều khung giờ trong ngày và khả năng chịu tải của máy chủ, ngưỡng S1 được chọn là 300, ngưỡng S2 được chọn là 600.
• Tương tự, căn cứ đặc tính lưu lượng của máy chủ ở điều kiện bình thường và điều kiện bị tấn công, ngưỡng IAT cho tấn công DDoS được chọn ở mức 0,2ms. Theo đó, tỷ lệ IAT ở điều kiện bình thường là 0,5, tỷ lệ IAT chắc chắn ở điều kiện bị tấn công DDoS là 0,99. Tỷ lệ PpF ở điều kiện bình thường là 0,1 và chắc chắn ở điều kiện bị tấn công là 0,9.
• Lưu lượng ở trạng thái bình thường, khơng bị tấn cơng được duy trì trong suốt thời gian phân tích 10 phút. Từ giây thứ 120 bắt đầu phát lưu lượng tấn công với tổng thời gian tấn công là 5 phút, kéo dài tới hết giây thứ 420.
Độ nhạy lọc bỏ và tỷ lệ lọc bỏ nhầm
Giá trị chỉ thị đầu ra Z của hệ thống tính được sau mỗi chu kỳ thể hiện trong biểu đồ Hình 3.11.
Hình 3.11. Giá trị đầu ra của chỉ thị Z của thuật toán FDDoM và độ nhạy lọc bỏ DRF
Hình 3.12. Tỷ lệ lọc bỏ nhầm FPRF
Tỷ lệ lọc bỏ nhầm được thể hiện trong biểu đồ Hình 3.12. Kết quả về độ nhạy lọc bỏ và tỷ lệ lọc bỏ nhầm như trên có thể thấy:
• Độ nhạy lọc bỏ tại mỗi chu kỳ giám sát T đạt 92,0 đến 95,0% theo luồng.
• Nếu tính trung bình trong suốt thời gian tấn công, độ nhạy lọc bỏ đạt tới 97,5% trong
khi tỷ lệ lọc bỏ nhầm ở mức 3,6% theo lưu lượng.
Bảng 3.4 so sánh hiệu năng đo được với giải pháp áp dụng thuật toán TRW-CB trên Openflow kết hợp sFlow [21] do nhóm tác giả Kostas Giotis thực hiện (năm 2014) như đã trình bày ở chương 1 trong trường hợp lưu lượng DDoS hỗn hợp và lưu lượng tấn công quét cổng áp dụng đối với quy mô hệ thống mạng tương đồng (tốc độ mạng 100 Mbps).
Bảng 3.4. So sánh hiệu năng giải pháp FDDoM với giải pháp và mơ hình mạng tương đồng
Giải pháp Độ nhạy lọc bỏ
(DRF)
Tỷ lệ lọc bỏ nhầm
(FPRF)
TRW-CB trên Openflow kết hợp sFlow với lưu
lượng DDoS hỗn hợp 96 % 25 %
TRW-CB trên Openflow kết hợp sFlow với lưu
lượng tấn công quét cổng 96 % 10 %
FDDoM 97,50 % 3,6 %
Kết quả so sánh cho thấy, giải pháp FDDoM cho độ nhạy lọc bỏ cải thiện hơn so với giải pháp TRW-CB trên Openflow kết hợp sFlow. Trong đó, điều quan trọng là FDDoM đã giảm tỷ lệ lọc bỏ nhầm, ngay cả so sánh với trường hợp lưu lượng tấn công xác định (quét cổng). Điều này đặc biệt có ý nghĩa vì bản chất của giảm thiểu tấn công DDoS là cố gắng không làm ảnh hưởng đến quá trình trao đổi dữ liệu của các máy khách (client) lành tính tới máy chủ trong trung tâm dữ liệu.
Khả năng đáp ứng của hệ thống
- Trong các giải pháp dựa trên kiến trúc SDN/Openflow cơ bản [22], [24], [77], sau khi phát hiện tấn công, hệ thống phải tiếp tục giám sát thêm ít nhất 1 chu kỳ T nữa để phân loại lưu lượng tấn cơng và áp đặt chính sách xử lý gói tin thơng qua các mục luồng. Điều này không những làm chậm khả năng đáp ứng của hệ thống mà còn làm tăng lưu lượng trên giao diện Openflow do Bộ điều khiển truy vấn thông tin lưu lượng. Trong FDDoM, khi một máy chủ được xác định ở trạng thái “Nghi ngờ bị tấn công” hoặc “Đang bị tấn cơng”, tồn bộ lưu lượng luồng mới đến được chuyển đến SD, không chuyển tới máy chủ nội bộ cũng như tới Bộ điều khiển. Tại SD lưu lượng tấn cơng được xóa bỏ, khơng cần phải đợi thêm chu kỳ giám sát. Việc này hạn chế tối đa các luồng mới được tạo ra và giảm thiểu tải và thông tin lên bộ điều khiển, các khối phân tích bảo mật. Do vậy, mức độ đáp ứng đưa ra các chính sách an ninh của hệ thống sẽ nhanh hơn so với các phương pháp xử lý dựa trên giao diện Openflow.
- Ngoài ra, cách tiếp cận này cũng khắc phục một vấn đề phổ biến khác đó là xử lý luồng có 1 gói tin. Tấn cơng DDoS phổ biến là giả mạo IP với một số lượng lớn các luồng có 1 gói
tin gửi đến máy nạn nhân. Sau khi nhận gói tin đầu tiên và cũng là gói duy nhất của luồng, một mục luồng tương ứng sẽ được tạo ra trong OFS và kéo dài cho đến khi hết thời gian chờ gây lãng phí tài ngun. Khi có dấu hiệu chỉ có 1 gói tin trong một luồng và máy chủ trong trạng thái “Đang bị tấn công”, như đã trình bày ở các mục trên thì SS yêu cầu SP tại bộ điều khiển
hủy bỏ các luồng có 1 gói tin theo tỷ lệ Z trong OFS nhằm hạn chế sự chiếm dụng vơ ích tài nguyên của bộ chuyển mạch.
Giảm lưu lượng trên giao diện Openflow
- Theo nguyên tắc hoạt động của SDN/Openflow, một gói tin khơng khớp với bất kỳ mục
luồng hiện có nào sẽ được OFS gửi tới bộ điều khiển qua bản tin packet-in. Khi tấn công DDoS xảy ra, hàng loạt gói tin khơng khớp tạo ra ồ ạt các bản tin packet-in làm cho giao diện Openflow
tăng cao và có thể vượt ngưỡng cho phép. Ngồi ra, các gói tin trên giao diện này được mã hóa TLS, độ dư mã sẽ làm cho lưu lượng tăng cao gây nguy cơ nghẽn mạng giao diện Openflow.
- Trong FDDoM, lưu lượng được xử lý theo cơ chế trên chỉ khi máy chủ ở trạng thái “Không
bị tấn công”. Trong trường hợp máy chủ ở trạng thái "Nghi ngờ bị tấn công" hoặc "Đang bị tấn công", bản tin packet-in qua giao diện Openflow được thay thế bằng cơ chế gửi sự kiện và
gói tin tới SD. Khi phát hiện có tấn cơng, một phần các gói tin thuộc các luồng mới bị hủy bỏ (nghĩa là không được cài đặt luồng mới bởi SD). Do đó, lưu lượng chuyển tiếp đến máy chủ được giảm đáng kể. Ngồi ra, SD khơng gửi tồn bộ phần tiêu đề của gói tin đến SS thông qua SP tại bộ điều khiển, mà chỉ gửi phần hữu ích của tiêu đề như: địa chỉ IP nguồn, địa chỉ IP đích, cổng nguồn, cổng đích. Thực tế này làm cho lưu lượng Openflow giữa bộ điều khiển và bộ chuyển mạch cũng như tổng lưu lượng trên giao diện của SS được giảm đáng kể so với kiến trúc SDN/Openflow chuẩn.
Giảm chiếm dụng vùng bộ nhớ đệm trên bộ chuyển mạch biên OFS
Trên mơ hình kiến trúc SDN/Openflow chuẩn, khi một gói tin đến khơng khớp với các mục luồng hiện có trong OFS, một phần của gói tin bao gồm phần tiêu đề (header) sẽ được chuyển tiếp tới bộ điều khiển, trong khi tồn bộ nội dung của nó được lưu trữ trên bộ đệm của OFS để chờ chính sách xử lý gói tin từ bộ điều khiển. Khi tài nguyên của OFS trở nên cạn kiệt, toàn bộ nội dung của gói được chuyển tiếp đến bộ điều khiển trong bản tin packet-in. Trong các cuộc tấn công DDoS, số lượng các gói khơng khớp với các mục luồng có sẵn trong OFS tăng lên rất cao, dẫn đến cạn kiệt bộ đệm của OFS. FDDoM khắc phục được vấn đề này vì nó khơng u cầu sử dụng bộ đệm trong trường hợp trạng thái máy chủ là "Nghi ngờ bị tấn công" hoặc "Đang
Kết quả phân tích mơ phỏng về mức độ giảm mục luồng trên OFS được thể hiện trong biểu đồ Hình 3.13. So sánh giữa FDDoM với cơ chế xử lý gói tin SDN/Openflow chuẩn cho thấy số lượng luồng trong OFS được giảm đến 50% trong trường hợp có tấn cơng xảy ra.