Luận án tiến sĩ Kỹ thuật viễn thông: Nghiên cứu giải pháp phát hiện và giảm thiểu tấn công từ chối dịch vụ phân tán sử dụng công nghệ SDN

Luận án được nghiên cứu với mục tiêu nhằm nghiên cứu đề xuất được các giải pháp phòng chống tấn công DDoS dựa trên kỹ thuật SDN/Openflow áp dụng cho mạng SDN quy mô nhỏ trong các bối cảnh khác nhau.

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI ĐẶNG VĂN TUYÊN NGHIÊN CỨU GIẢI PHÁP PHÁT HIỆN VÀ GIẢM THIỂU TẤN CÔNG TỪ CHỐI DỊCH VỤ PHÂN TÁN SỬ DỤNG CÔNG NGHỆ SDN LUẬN ÁN TIẾN SĨ KỸ THUẬT VIỄN THÔNG Hà Nội – 2019 BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI ĐẶNG VĂN TUYÊN NGHIÊN CỨU GIẢI PHÁP PHÁT HIỆN VÀ GIẢM THIỂU TẤN CÔNG TỪ CHỐI DỊCH VỤ PHÂN TÁN SỬ DỤNG CÔNG NGHỆ SDN Ngành: Kỹ thuật Viễn thông Mã số: 9520208 LUẬN ÁN TIẾN SĨ KỸ THUẬT VIỄN THÔNG NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS TRƯƠNG THU HƯƠNG PGS.TS NGUYỄN TÀI HƯNG Hà Nội – 2019 i LỜI CAM ĐOAN Tôi xin cam đoan kết khoa học trình bày luận án thành nghiên cứu thân suốt thời gian làm nghiên cứu sinh chưa xuất công bố tác giả khác Các kết đạt xác trung thực Hà Nội, ngày 15 tháng năm 2019 Tác giả luận án Đặng Văn Tuyên Giáo viên hướng dẫn khoa học PGS.TS Trương Thu Hương PGS.TS Nguyễn Tài Hưng ii LỜI CẢM ƠN Nghiên cứu sinh (NCS) xin gửi lời trân trọng cảm ơn đến Tập thể hướng dẫn khoa học: PGS TS Trương Thu Hương PGS TS Nguyễn Tài Hưng thầy cô giáo Bộ môn Kỹ thuật Thông tin, Viện Điện tử - Viễn thông, Trường Đại học Bách khoa Hà Nội tận tình hướng dẫn, tạo điều kiện cho NCS học tập, nghiên cứu hoàn thành Luận án NCS xin trân trọng cảm ơn Phòng Đào tạo, Trường Đại học Bách khoa Hà Nội tạo điều kiện giúp đỡ mặt thủ tục; Trường Đại học Kỹ thuật – Hậu cần CAND, gia đình đồng nghiệp tạo điều kiện mặt thời gian cho NCS nghiên cứu hồn thành Luận án Trong q trình thực đề tài nghiên cứu, thân có nhiều cố gắng giới hạn trình độ hiểu biết, kinh nghiệm thực tế, kinh nghiệm nghiên cứu khoa học nên Luận án không tránh khỏi thiếu sót NCS kính mong nhận đóng góp ý kiến nhà khoa học, cán nghiên cứu, thầy, cô giáo, bạn bè đồng nghiệp để NCS hoàn thiện lý luận khoa học lẫn thực tiễn Xin trân trọng cảm ơn Hà Nội ngày 15 tháng 05 năm 2019 NGHIÊN CỨU SINH Đặng Văn Tuyên iii MỤC LỤC LỜI CAM ĐOAN i LỜI CẢM ƠN ii MỤC LỤC iii DANH MỤC CÁC CHỮ VIẾT TẮT vii DANH MỤC HÌNH VẼ x DANH MỤC CÁC BẢNG BIỂU xiii MỞ ĐẦU xiv CHƯƠNG 1: TẤN CƠNG DDOS VÀ CÁC GIẢI PHÁP PHỊNG CHỐNG TRONG MẠNG SDN/OPENFLOW 1.1 Giới thiệu chương 1.2 Tổng quan công DDoS 1.2.1 Khái niệm 1.2.2 Phân loại công DDoS 1.2.3 Các giải pháp phịng chống DDoS dựa cơng nghệ mạng truyền thống 1.2.4 Yêu cầu thách thức giải pháp phát ngăn chặn, giảm thiểu công DDoS 1.3 Kỹ thuật mạng cấu hình phần mềm SDN 10 1.4 Giao thức OpenFlow 12 1.4.1 Cấu trúc phạm vi chuẩn hóa Openflow 13 1.4.2 Nhận dạng quản lý lưu lượng chuyển mạch Openflow 14 1.4.3 Các tin trao đổi điều khiển chuyển mạch Openflow 14 1.4.4 Quy trình xử lý gói tin Openflow 16 1.4.5 Quản lý mục luồng chuyển mạch Openflow 17 iv 1.5 Các giải pháp phòng chống DDoS dựa kiến trúc kỹ thuật SDN/Openflow 18 1.5.1 Kiến trúc nguyên lý hoạt động chung 18 1.5.2 Các kỹ thuật phát công 20 1.5.3 Các kỹ thuật ngăn chặn, giảm thiểu công 22 1.6 Tấn công DDoS tới thành phần kiến trúc mạng SDN/Openflow giải pháp phòng chống 23 1.6.1 Tấn công DDoS tới thành phần kiến trúc mạng SDN/Openflow 23 1.6.2 Kỹ thuật phát giảm thiểu công 25 1.7 Kết luận chương 27 CHƯƠNG 2: ĐỀ XUẤT GIẢI PHÁP PHÒNG CHỐNG TẤN CÔNG DDOS DỰA TRÊN DỮ LIỆU THỐNG KÊ VÀ CƠ CHẾ XỬ LÝ GÓI TIN CỦA KỸ THUẬT SDN/OPENFLOW 29 2.1 Giới thiệu chương 29 2.2 Giải pháp phát giảm thiểu cơng DDoS dựa mơ hình dự đốn làm trơn hàm mũ tham số thống kê lưu lượng 29 2.2.1 Đặt vấn đề 29 2.2.2 Kiến trúc hệ thống trạng thái hoạt động 30 2.2.3 Lựa chọn tham số số thống kê lưu lượng 32 2.2.4 Lựa chọn xây dựng mơ hình dự đốn số thống kê lưu lượng 33 2.2.5 Phát giảm thiểu công 35 2.2.6 Phân tích đánh giá hiệu giải pháp 37 2.3 Giải pháp giảm thiểu công SYN Flood dựa chế ủy nhiệm gói tin SYN điều khiển 41 2.3.1 Đặt vấn đề 41 2.3.2 Kiến trúc hệ thống đề xuất 42 2.3.3 Lựa chọn mô hình ủy nhiệm gói tin SYN 43 2.3.4 Hoạt động hệ thống SSP 44 2.3.5 Phân tích đánh giá hiệu giải pháp 51 v 2.4 Giải pháp đánh dấu gói tin PLA DFM phục vụ truy vết nguồn công 58 2.4.1 Đặt vấn đề 58 2.4.2 Khái niệm đánh dấu gói tin kỹ thuật 59 2.4.3 Đề xuất cấu trúc hoạt động PLA DFM kiến trúc mạng SDN/Openflow 61 2.4.4 So sánh đánh giá hiệu giải pháp 66 2.5 Kết luận chương 70 CHƯƠNG ĐỀ XUẤT GIẢI PHÁP PHỊNG CHỐNG TẤN CƠNG DDOS DỰA TRÊN KỸ THUẬT SDN/OPENFLOW SỬ DỤNG THÊM BỘ PHÂN TÍCH VÀ XỬ LÝ LƯU LƯỢNG 72 3.1 Giới thiệu chương 72 3.2 Những hạn chế kiến trúc kỹ thuật SDN/Openflow phòng chống công DDoS 72 3.3 Đề xuất kiến trúc mạng SDN/Openflow mở rộng sở bổ sung phân tích xử lý lưu lượng SD 73 3.3.1 Kiến trúc tổng quát 74 3.3.2 Điều khiển chuyển tiếp lưu lượng tới SD xử lý lưu lượng SD 75 3.4 Giải pháp phân loại giảm thiểu công DDoS dựa kiến trúc SDN/Openflow mở rộng thuật toán logic mờ 76 3.4.1 Đặt vấn đề 76 3.4.2 Phân tích đặc tính lưu lượng công DDoS để chọn tham số phân loại lưu lượng 76 3.4.3 Cấu trúc hệ thống 79 3.4.4 Xác định trạng thái máy chủ 79 vi 3.4.5 Chuyển tiếp gói tin thực thể hệ thống 81 3.4.6 Phân loại lưu lượng giảm thiểu cơng DDoS dựa thuật tốn suy luận logic mờ FDDoM 83 3.4.7 Đánh giá hiệu giải pháp 87 3.5 Phát giảm thiểu công SYN Flood tới mạng SDN/Openflow sử dụng chế ủy nhiệm gói tin SYN phân tích xử lý lưu lượng 91 3.5.1 Đặt vấn đề 91 3.5.2 Cấu trúc hệ thống 92 3.5.3 Hoạt động hệ thống 92 3.5.4 Phân tích đánh giá hiệu 98 3.6 Kết luận chương 104 KẾT LUẬN 106 DANH MỤC CÁC CƠNG TRÌNH ĐÃ CƠNG BỐ CỦA LUẬN ÁN 108 TÀI LIỆU THAM KHẢO 109 vii DANH MỤC CÁC CHỮ VIẾT TẮT Ký hiệu ACK Tiếng Anh ACKnowledgment Tiếng Việt Gói tin xác nhận kết nối ACK_Num Acknowledgement Number Số hiệu xác nhận API Application Programming Interface Giao diện chương trình ứng dụng ART Average Retrieve Time Thời gian kết nối trung bình AS Autonomous System Hệ tự trị ATM Asynchronous Transfer Mode Truyền liệu cận đồng CDF Cumulative Distribution Function Hàm phân phối tích lũy CliACK Client ACK Gói tin xác nhận kết nối từ client CM Connection Migration Di trú kết nối CUSUM CUmulative SUM Tổng tích lũy DC Data Center Trung tâm liệu DDoS Distributed Denial of Service Tấn công từ chối dịch vụ phân tán DFM Deterministic Flow Marking Kỹ thuật đánh dấu gói tin theo luồng DoS Denial of Service Tấn công từ chối dịch vụ DNS Domain Name System Hệ thống tên miền DPpF Deviation PpF PpF chuẩn hóa DPM Deterministic Packet Marking Kỹ thuật đánh dấu xác định DPPM Dynamic Probabilistic Packet Marking Kỹ thuật đánh dấu gói tin theo xác suất động DR Detection Rate Độ nhạy DSCP Dynamic probabilistic packet marking Kỹ thuật đánh dấu gói tin theo xác suất động DSPA Deviation SPA SPA chuẩn hóa FDDoM Fuzzy Logic-based DDoS Mitigation Phát giảm thiểu công DDoS dựa thuật toán logic mờ FIS Fuzzy Inference System Hệ suy luận mờ FTP File Transfer Protocol Giao thức truyền tệp tin FPR False Positive Rate Tỷ lệ báo động nhầm FMT Flow Monitoring Table Bảng giám sát luồng HOC Half Open Connection Kết nối dang dở 3HS Three ways Handshake Bắt tay ba bước HTTP HyperText Transfer Protocol Giao thức truyền tải siêu văn IAT Inter Arrival Time Khoảng thời gian liên gói tin viii ICMP Internet Control Message Protocol Giao thức thông báo điều khiển Internet IDS Intrusion Detection System Hệ thống phát xâm nhập IoTs Internet of Things Mạng kết nối vạn vật IP Internet Protocol Giao thức liên mạng IPS Intrusion Prevention System Hệ thống chống xâm nhập ISP Internet Service Provider Nhà cung cấp dịch vụ Internet IRC Internet Relay Chat Dịch vụ chat Internet MA Moving Average Trung bình động MPR Marked Packet Rate Tỷ lệ gói tin bị đánh dấu MSR Marked Size Rate Tỷ lệ dung lượng gói tin bị đánh dấu MT Mark Threshold Giá trị ngưỡng đánh dấu MTU Maxium Transmission Unit Ngưỡng kích thước đơn vị truyền NFV Network Functions Virtualization Ảo hóa chức mạng NTP Network Time Protocol Giao thức đồng thời gian mạng OFS OpenFlow Switch Bộ chuyển mạch Openflow ONF Open Networking Foudation Tổ chức chuẩn hóa mạng mở PN Packet Number Số gói tin PLA DFM Packet Length Adaptive Deterministic Flow Marking Đánh dấu gói tin xác định theo luồng có tương thích chiều dài gói PpF Packet number per Flow Số gói tin luồng PPM Probabilistic Packet Marking Đánh dấu gói tin theo xác suất pps packet per second Gói tin/ giây QoS Quality of Service Chất lượng dịch vụ REST API Representational State Transfer API Giao diện trao đổi dựa vào biến trạng thái RST ReSeT Gói tin hủy kết nối SAN Source Address Number Số địa IP nguồn SCR Successful Connection Rate Tỷ lệ kết nối thành công SD Security Device Thiết bị bảo mật SDH Synchronous Digital Hierarchy Hệ thống phân cấp đồng SDN Software Defined Networking Kỹ thuật mạng cấu hình phần mềm SEQ_Num Sequence Number Số hiệu SFD SYN Flood Detection Phát công SYN Flood SMR Successful Mark Rate Tỷ lệ đánh dấu thành công SOM Self Organinzing Map Bản đồ tự tổ chức SOHO Small Office/Home Office Văn phòng, quan nhỏ ix SONET Synchronous Optical NETwork Mạng quang đồng SP Security Proxy Ủy nhiệm an ninh SPA Source-port number Per Address Số cổng nguồn địa nguồn SPM SYN Proxy Module Mơ đun ủy nhiệm gói tin SYN SPN Source Port Number Số cổng nguồn mở SS Security Server Máy chủ bảo mật SSDP Simple Service Discovery Protocol Giao thức phát dịch vụ đơn giản SSG SDN-based SYN Flood Guard Chống công SYN Flood dựa vào công nghệ SDN SSP SDN based SYN Proxy Ủy nhiệm gói tin SYN dựa vào cơng nghệ SDN SSL Secure Sockets Layer Tiêu chuẩn bảo mật an toàn lớp ứng dụng SVM Support Vector Machine Máy vec-tơ hỗ trợ SYN SYNchronize Gói tin yêu cầu kết nối SYN-ACK SYNchronize ACKnowledgement Gói tin trả lời yêu cầu kết nối TCB Transmission Control Block Khối điều khiển truyền TCP Transmission Control Protocol Giao thức điều khiển truyền TOS Type Of Service Kiểu dịch vụ TLS Transport Layer Security Bảo mật tầng truyền tải TTL Time To Live Thời gian tồn TRW Threshold Random Walk Thăm dò ngưỡng TRW-CB TRW-Credit Based Thăm dò ngưỡng theo độ tin cậy UDP User Datagram Protocol Giao thức truyền gói liệu người dùng VLAN Virtual Local Area Network Mạng LAN ảo VPN Virtual Private Network Mạng riêng ảo WMA Weighted Moving Average Mơ hình trung bình động có trọng số x DANH MỤC HÌNH VẼ Hình 1.1 Lưu lượng cơng DDoS huy động từ nhiều nguồn Internet Hình 1.2 Phân loại kỹ thuật công DDoS Hình 1.3 Quá trình bắt tay ba bước kết nối TCP (a) chế công TCP SYN Flood (b) Hình 1.4 Kiến trúc mạng cấu hình phần mềm SDN 11 Hình 1.5 Cấu trúc phạm vi chuẩn hóa giao thức Openflow 13 Hình 1.6 Cấu trúc mục luồng 15 Hình 1.7 Q trình xử lý gói tin chuyển mạch theo chế đường ống 16 Hình 1.8 u cầu xử lý gói tin khơng khớp với mục luồng có sẵn chuyển mạch 17 Hình 1.9 Cấu trúc chung hệ thống giải pháp phịng chống công DDoS dựa kỹ thuật SDN/Openflow 19 Hình 1.10 Các phương pháp công tới lớp Hạ tầng mạng 24 Hình 1.11 Các phương pháp công tới Lớp điều khiển 24 Hình 1.12 Các phương pháp công tới Lớp Ứng dụng 24 Hình 1.13 Q trình xử lý gói tin kết nối TCP chế CM 26 Hình 2.1 Kiến trúc hệ thống đề xuất cho giải pháp dựa phương pháp thống kê sử dụng giải thuật dự đoán làm trơn hàm mũ 30 Hình 2.2 Sơ đồ chuyển tiếp trạng thái hệ thống cho máy chủ/dịch vụ 31 Hình 2.3 Mơ hình phát phân loại lưu lượng công 35 Hình 2.4 Giá trị số SPA (a) DSPA (b) 39 Hình 2.5 Giá trị số PpF DPpF 39 Hình 2.6 Kiến trúc hệ thống giải pháp Ủy nhiệm gói tin SYN Bộ điều khiển SSP 43 Hình 2.7 Nguyên lý hoạt động hai loại SYN proxy 44 Hình 2.8 Quá trình xử lý u cầu kết nối gói tin SYN giải pháp SSP 45 Hình 2.9 Lưu đồ trình capture xử lý gói tin bắt tay ba bước OFS 46 Hình 2.10 Lưu đồ hoạt động mơ đun SPM điều khiển 48 Hình 2.11 Thống kê CDF khoảng thời gian gói tin SYN gói tin CliACK lưu lượng mạng thực tế 50 Hình 2.12 Hiệu chỉnh thời gian chờ luồng 50 xi Hình 2.13 Sơ đồ chuyển tiếp sách xử lý gói tin SYN chuyển mạch 51 Hình 2.14 Mơ hình testbed đánh giá hiệu giải pháp SSP 52 Hình 2.15 Tỷ lệ kết nối thành cơng từ lưu lượng lành tính máy chủ chịu công DDoS với cường độ công khác 53 Hình 2.16 Thời gian kết nối trung bình lưu lượng lành tính máy chủ chịu cơng với cường độ công khác 53 Hình 2.17 Số kết nối mở máy chủ với cường độ công khác 54 Hình 2.18 Giao diện hình đo chiếm dụng tài nguyên Bộ điều khiển tốc độ công 700 pps 57 Hình 2.19 Tỷ lệ chiếm dụng CPU điều khiển cường độ công khác 57 Hình 2.20 Dung lượng nhớ bị chiếm dụng điều khiển cường độ công khác 57 Hình 2.21 Phân bố số lượng gói tin luồng từ liệu CAIDA 61 Hình 2.22 Cấu trúc hệ thống giải pháp đánh dấu gói tin PLA DFM dựa kiến trúc SDN/Openflow 62 Hình 2.23 Phân bố chiều dài gói tin thứ từ liệu CAIDA 63 Hình 2.24 Đánh dấu gói tin PLA DFM 63 Hình 2.25 Q trình đánh dấu gói tin PLA DFM Bộ điều khiển mạng SDN/Openflow 66 Hình 2.26 So sánh tác động PLA DFM tới tiêu đề gói tin luồng 67 Hình 2.27 SMR PLA DFM DFM MT=288 68 Hình 2.28 MPR PLA DFM DFM MT=288 68 Hình 2.29 MSR PLA DFM DFM MT=288 69 Hình 3.1 Kiến trúc giải pháp bổ sung phân tích xử lý lưu lượng dựa chế SDN/Openflow 74 Hình 3.2 Biểu đồ phân bố IAT lưu lượng đến 77 Hình 3.3 Phân bố số lượng gói luồng 78 Hình 3.4 Kiến trúc hệ thống đề xuất cho giải pháp phân loại giảm thiểu cơng dựa thuật tốn suy luận logic mờ FDDoM 80 Hình 3.5 Sơ đồ hệ thống máy chủ trạng thái "Không bị cơng" 82 Hình 3.6 Sơ đồ kiện Packet in máy chủ trạng thái "Nghi ngờ bị công" 83 Hình 3.7 Sơ đồ kiện “Kết thúc chu kỳ giám sát” máy chủ trạng thái "Nghi ngờ bị công" 83 Hình 3.8 Sơ đồ kiện Packet in máy chủ trạng thái "Đang bị công" 84 xii Hình 3.9 Mờ hố IAT với hai hàm thành viên Low High 85 Hình 3.10 Mờ hố PpF với hai hàm thành viên Low High 86 Hình 3.11 Giá trị đầu thị Z thuật toán FDDoM độ nhạy lọc bỏ DR F 88 Hình 3.12 Tỷ lệ lọc bỏ nhầm FPRF 88 Hình 3.13 So sánh số mục luồng tồn chuyển mạch biên OFS 90 Hình 3.14 Cấu trúc chi tiết tương tác module chức giải pháp SSG 93 Hình 3.15 Mơ hình thuật tốn phát cơng SYN Flood đề xuất sử dụng SSG 93 Hình 3.16 Quá trình capture điều hướng gói tin kết nối TCP lành tính thơng qua mục luồng OFS máy chủ nội trạng thái “Không bị cơng” 95 Hình 3.17 Lưu đồ thuật tốn q trình xử lý gói tin SYN đến SD 96 Hình 3.18 Lưu đồ thuật tốn giám sát q trình bắt tay ba bước SD 97 Hình 3.19 Sơ đồ trình xác thực địa IP nguồn gói tin SYN RST cookie 98 Hình 3.20 Cấu trúc testbed thử nghiệm đánh giá giải pháp SSG 98 Hình 3.21 So sánh tỷ lệ kết nối thành công thời gian kết nối trung bình Openflow, chế CM giải pháp SSG 99 Hình 3.22 Sự chiếm dụng tài nguyên nhớ tài nguyên CPU OFS SD giải pháp thử nghiệm 101 Hình 3.23 Sự tương tác thực thể SSG trình xử lý gói tin bắt tay ba bước kết nối lành tính 102 Hình 3.24 Sự tương tác thực thể trình xử lý gói tin SYN giả mạo địa IP chế CM giải pháp SSG 103 Hình 3.25 Mức độ gia tăng lưu lượng giao diện chuyển mạch giải pháp SSG so với chế CM 103 xiii DANH MỤC CÁC BẢNG BIỂU Bảng 1.1 Quan hệ kết phân loại giải pháp đặc tính thực lưu lượng Bảng 1.2 So sánh kỹ thuật phát giảm thiểu công DDoS tới kiến trúc mạng SDN/Openflow theo sách quy tắc xử lý gói tin 25 Bảng 2.1 Các tham số thống kê sử dụng để phát phân loại lưu lượng công DDoS 32 Bảng 2.2 Thuật toán phát công 35 Bảng 2.3 Thuật toán phân loại lưu lượng công 36 Bảng 2.4 Thuật toán Lọc bỏ lưu lượng công 37 Bảng 2.5 Độ nhạy tỷ lệ báo động nhầm phân loại lưu lượng giảm thiểu công 40 Bảng 2.6 Ví dụ cấu trúc xếp mục luồng bảng luồng SSP 47 Bảng 2.7 Cấu trúc bảng giám sát luồng FMT 48 Bảng 2.8 Tham số kết phân tích lưu lượng lành tính từ liệu CAIDA 2013 56 Bảng 2.9 Các trường số lượng gói tin yêu cầu luồng để đánh dấu DFM 60 Bảng 2.10 Một số giá trị MTU loại đường truyền phổ biến giá trị MT tương ứng64 Bảng 2.11 Kỹ thuật PLA DFM với tuỳ biến giá trị Checksum 65 Bảng 2.12 So sánh PLA DFM khác với giá trị K MT 69 Bảng 2.13 Tỷ lệ gia tăng lưu lượng PLA DFM 69 Bảng 3.1 Số lượng luồng, số lượng địa IP nguồn tổng lưu lượng gửi tới máy chủ hai liệu CAIDA Netnam 78 Bảng 3.2 Thuật toán xác định trạng thái máy chủ 80 Bảng 3.3 Các loại mục luồng dùng để điều hướng lưu chuyển gói tin hệ thống 81 Bảng 3.4 So sánh hiệu giải pháp FDDoM với giải pháp mô hình mạng tương đồng 89 Bảng 3.5 Tổ chức bảng luồng chuyển mạch OFS SSG 94 Bảng 3.6 Đặc tính mục luồng bảng luồng FT1 FT3 thực giám sát trình bắt tay ba bước 94 Bảng 3.7 Cấu trúc mục tin danh sách HOCs 97 Bảng 3.8 Đặc tính thống kê lưu lượng lành tính phân tích từ lưu lượng CAIDA 103 xiv MỞ ĐẦU Tấn công từ chối dịch vụ phân tán công nghệ SDN 1.1 Tấn công từ chối dịch vụ phân tán - Trong năm gần đây, phát triển mạnh mẽ công nghệ thông tin truyền thông cho đời hàng loạt dịch vụ mạng phục vụ hầu khắp lĩnh vực hoạt động xã hội người Các giao dịch, xử lý trao đổi thông tin, lưu trữ liệu dần chuyển sang thực trực tuyến mạng Internet Bên cạnh đó, phát triển mạnh mẽ công nghệ kết nối vạn vật (IoTs) làm cho số lượng nhu cầu lưu lượng kết nối Internet tăng lên nhanh chóng Vấn đề đảm bảo an toàn, tin cậy cho tổ chức khai thác dịch vụ đặt lên hàng đầu Với chế hình thành dựa ghép nối hệ tự trị (Autonomous System) thiếu kiểm soát chung, Internet xuất ẩn chứa nhiều nguy cơng gây an ninh mạng có hình thức cơng từ chối dịch vụ (DoS) [1], công từ chối dịch vụ phân tán (sau gọi tắt công DDoS) [2]–[4] Mặc dù không gây lỗi liệu, cơng DoS/DDoS có ảnh hưởng nghiêm trọng đến tính tin cậy, sẵn sàng tổ chức khai thác dịch vụ Internet Với kỹ thuật cơng đơn giản, cơng cụ dễ tìm, khả phát tán mã độc để huy động nguồn lực cơng dễ dàng, khó phát ngăn chặn, công DDoS ngày trở nên nguy hiểm, lợi dụng phát động công với quy mô ngày cao Các báo cáo công ty an ninh mạng cho thấy, diễn biến quy mô đợt công ngày phức tạp [5]–[7] Theo báo cáo Abor [8], ngày 27/2/2018 trang web lưu trữ mã nguồn GitHub ghi nhận đợt công DDoS với tốc độ lên tới 1,35 Tbps Qua cho thấy, cơng DDoS nguy an ninh lớn tổ chức đảm bảo chất lượng dịch vụ Internet tương lai - Sự dịch chuyển gia tăng nhu cầu làm việc, kinh doanh độc lập giải trí cá nhân, với hỗ trợ mạnh mẽ công nghệ truyền dẫn tiên tiến, phát triển dịch vụ nhà thông minh, IoTs,… mạng quy mô nhỏ (SOHO network) ngày phát triển xu thế, chiếm tỷ lệ ngày tăng kết cấu internet [9]–[11] An ninh mạng nói chung cơng DDoS nói riêng vấn đề lớn mạng quy mơ nhỏ tính đa dạng, thiếu kiểm soát thiết bị, dịch vụ mạng, trọng, quan tâm, tính chuyên nghiệp thiết kế, quản lý vận hành mạng [12]–[14] - Dựa công nghệ mạng truyền thống, nhiều giải pháp kỹ thuật nhằm phát hiện, phân loại ngăn chặn lưu lượng công DDoS đề xuất triển khai [15]–[18] Cơ chế chung giải pháp sử dụng đo, điểm dò (probe), lấy mẫu phân tích lưu lượng hệ thống mạng để cung cấp thơng tin thuộc tính lưu lượng mạng tồn hệ thống Thơng tin lưu lượng chuyển đến xử lý phân tích nhờ thuật toán phát bất thường dựa dấu hiệu cơng để xác định có cơng xảy hay khơng Khi có cơng hệ thống sử dụng thiết bị an ninh chuyên dụng tường lửa, IPS để ngăn chặn, xóa bỏ lưu lượng công Một vấn đề tồn lớn cơng nghệ mạng xv truyền thống thiết bị mạng vốn phát triển kỹ thuật xử lý gói tin theo chuẩn riêng nhà sản xuất khác nên việc cấu hình tự động, thiết lập tham số để phòng chống DDoS khó khăn Các thao tác xử lý công xảy chủ yếu thực tay, xóa bỏ, hạn chế lưu lượng thiết lập ngưỡng giới hạn dẫn tới xóa bỏ nhầm lưu lượng lành tính - Tấn cơng DDoS với kỹ thuật huy động nguồn công lớn xác sống (zombies) kỹ thuật giả mạo địa IP nguồn nên tạo lưu lượng cơng tăng đột biến khoảng thời gian ngắn, vượt khả chịu đựng dịch vụ, máy chủ hệ thống mạng đích Do chế điều khiển cứng, đóng kín, thiết bị mạng cơng nghệ mạng truyền thống tham gia ngăn chặn lưu lượng công DDoS cách tự động, làm cho giải pháp phịng chống mạng có hiệu thấp, khơng có khả phân loại xóa bỏ xác theo biến động lưu lượng mạng Các giải pháp phòng chống tập trung phát cơng, chế đóng thiết bị mạng truyền thống nên chưa có nhiều giải pháp giảm thiểu công trực tuyến - Tấn công DDoS công vào lực phục vụ hệ thống mạng Chính với cấu trúc, quy mơ, đặc điểm dịch vụ phương pháp tổ chức dịch vụ mạng khác đặc điểm phản ứng lại với lưu lượng công, khả chịu đựng công hệ thống mạng khác Không có giải pháp phịng chống cơng, tham số hệ thống áp dụng chung cho tất loại mạng, quy mô mạng, dịch vụ mạng khác Với hệ thống mạng cụ thể, người quản trị cần lựa chọn, tích hợp giải pháp khác nhau, thiết lập tham số phù hợp với đặc điểm riêng để có hiệu phịng chống tối ưu 1.2 Công nghệ SDN kỹ thuật SDN/Openflow - Với nhu cầu phát triển mạnh mẽ dịch vụ mạng Internet, cơng nghệ điện tốn đám mây, tính di động, nhu cầu thay đổi linh động, mềm dẻo tài nguyên hệ thống mạng, công nghệ mạng điều khiển phần mềm (gọi tắt công nghệ SDN) đời sở tách rời mặt phẳng điều khiển khỏi mặt phẳng liệu, cho phép quản trị, điều khiển, thiết lập sách mạng cách tập trung trừu tượng hóa tài nguyên mạng [19] Trong Openflow [20] giao thức SDN tập trung nghiên cứu, phát triển Kỹ thuật mạng SDN dựa giao thức Openflow (gọi tắt kỹ thuật SDN/Openflow) nhanh chóng thu hút nghiên cứu bước đầu ứng dụng sản phẩm phần cứng, phần mềm thương mại mã nguồn mở - Điểm khác biệt quan trọng kỹ thuật SDN/Openflow so với kỹ thuật mạng truyền thống chỗ: (1) thiết bị mạng quản lý xử lý lưu lượng theo luồng (flow), (2) khả cung cấp liệu thống kê lưu lượng nhờ đếm thống kê luồng có chuyển mạch, (3) khả điều khiển xử lý lưu lượng phần mềm lập trình, tùy biến điều khiển điều hành mạng Sự khác biệt cho phép xây dựng giải pháp quản trị, điều hành mạng quy định cấu hình chức thiết bị mạng vật lý, xử lý lưu lượng, v.v… phần mềm Bên cạnh giải pháp đề xuất ứng dụng quản trị, tổ chức dịch vụ, nâng xvi cao hiệu hệ thống mạng, SDN/Openflow nghiên cứu đề xuất ứng dụng nhiều giải pháp an ninh mạng có giải pháp phịng chống cơng DDoS [21]–[26] Những vấn đề cịn tồn Cơng nghệ SDN kỹ thuật SDN/Openflow đánh giá kỳ vọng công nghệ mạng thay cho công nghệ, kỹ thuật mạng truyền thống Khác với kỹ thuật mạng truyền thống, kỹ thuật SDN/Openflow có khả cung cấp liệu thống kê lưu lượng lập trình xử lý lưu lượng theo biến thiên đặc tính Đặc điểm phù hợp với quy trình phát giảm thiểu cơng DDoS Đã có số cơng trình nghiên cứu, đề xuất giải pháp phát giảm thiểu công DDoS dựa liệu thống kê chế xử lý gói tin kỹ thuật SDN/Openflow Tuy nhiên, giải pháp đề xuất: + Một số giải pháp đưa thuật toán phát cơng, chưa có chế phân loại giảm thiểu lưu lượng công [22] + Hầu hết dừng lại ý tưởng giải pháp, thử nghiệm với quy mô thử chức năng, chưa triển khai hệ thống thử nghiệm đo phân tích với lưu lượng thật (như) [22], [27]–[29] + Một số giải pháp tích hợp chức xử lý gói tin chuyển mạch làm chất SDN [28], [29], chế xử lý gói tin SDN/Openflow chưa ứng dụng [21], [25], [26] làm chậm thời gian đáp ứng hiệu hệ thống Vậy kỹ thuật SDN/Openflow áp dụng rộng rãi hệ thống mạng, làm để khắc phục vấn đề trên, nâng cao hiệu giải pháp phòng chống công DDoS sử dụng trực tiếp liệu thống kê lưu lượng chế xử lý gói tin kỹ thuật SDN/Openflow để áp dụng cho mạng quy mơ nhỏ mạng gia đình thiếu chế đảm bảo an toàn mà không cần bổ sung thiết bị an ninh chuyên dụng? Các trường thông tin thống kê quy định giao thức Openflow hạn chế nên liệu thống kê lưu lượng theo kỹ thuật SDN/Openflow bị giới hạn [20] Bên cạnh đó, theo triết lý SDN, giao diện Openflow vốn sử dụng cho trao đổi thơng tin điều khiển, có mã hóa Các giải pháp phịng chống cơng DDoS thực truy vấn liệu thống kê từ lớp điều khiển tới lớp hạ tầng mạng thông qua giao thức Openflow làm cho lưu lượng giao diện tăng lên, công DDoS xảy [30] Điều làm cho giải pháp phòng chống công DDoS sử dụng túy liệu thống kê chế xử lý gói tin SDN/Openflow áp dụng mạng quy mơ lưu lượng nhỏ mạng gia đình Khắc phục vấn đề này, số giải pháp phịng chống cơng cho mạng doanh nghiệp có quy mơ băng thơng cao đề xuất sử dụng phân tích lưu lượng truyền thống Snort [25], sFlow [21], [26] thay sử dụng liệu thống kê SDN/Openflow Nhược điểm giải pháp bao gồm: + Các phân tích lưu lượng túy cung cấp thơng tin đặc tính lưu lượng Bộ phân tích lưu lượng hoạt động độc lập, khơng có điều khiển theo trạng thái hệ thống mạng, chưa tận dụng chế điều khiển xử lý gói tin SDN xvii + Việc xóa bỏ lưu lượng, giảm thiểu công thực qua giao thức Openflow làm chậm thời gian đáp ứng hệ thống, sử dụng nhiều tài nguyên (các mục luồng) chuyển mạch Trong bối cảnh vậy, chế kỹ thuật SDN/Openflow làm để điều khiển hoạt động phân tích lưu lượng, sử dụng thông tin cung cấp phân tích lưu lượng để nâng cao hiệu phát giảm thiểu công giải pháp? Mục tiêu, đối tượng phạm vi nghiên cứu a) Mục tiêu nghiên cứu: Nghiên cứu đề xuất giải pháp phịng chống cơng DDoS dựa kỹ thuật SDN/Openflow áp dụng cho mạng SDN quy mô nhỏ bối cảnh khác b) Nội dung nghiên cứu: Để giải vấn đề tồn tại, với mục tiêu nghiên cứu trên, nội dung nghiên cứu Luận án bao gồm: • Nghiên cứu khác biệt đặc tính lưu lượng cơng DDoS so với lưu lượng lành tính để lựa chọn tham số, đề xuất thuật toán phù hợp với bối cảnh SDN/Openflow nhằm nâng cao hiệu phát phân loại cơng DDoS • Dựa chế xử lý gói tin kỹ thuật SDN/Openflow, đề xuất chế trao đổi liệu, tương tác thực thể mạng SDN/Openflow để áp dụng mơ hình, thuật tốn, phát triển thành giải pháp phịng chống cơng DDoS hai bối cảnh: (1) túy sử dụng liệu thống kê SDN/Openflow (2) sử dụng liệu thống kê SDN/Openfow kết hợp với phân tích xử lý lưu lượng • Nghiên cứu nguy cơng DDoS tới thành phần mạng SDN/Openflow đề xuất giải pháp phát hiện, giảm thiểu cơng c) Đối tượng nghiên cứu: • Cơng nghệ SDN, kỹ thuật SDN/Openflow • Các phương thức, kỹ thuật công DDoS phổ biến kỹ thuật mạng truyền thống mạng SDN/Openflow • Các giải pháp phòng chống DDoS dựa kỹ thuật mạng truyền thống kỹ thuật SDN/Openflow đề xuất • Các liệu lưu lượng lành tính cơng DDoS c) Phương pháp phạm vi nghiên cứu: - Phương pháp nghiên cứu luận án bao gồm nghiên cứu lý thuyết; phân tích thống kê; xây dựng mơ hình, giải pháp; lựa chọn phát triển thuật tốn; phân tích liệu mơ xây dựng hệ thống thử nghiệm, đo lường, đánh giá so sánh - Phạm vi nghiên cứu tập trung vào: • Đề xuất giải pháp phòng chống DDoS bảo vệ máy chủ hệ thống mạng quy mô nhỏ vừa văn phịng, quan nhỏ (SOHO), • Áp dụng túy kỹ thuật SDN/Openflow xviii Cấu trúc nội dung luận án Cấu trúc luận án gồm có 03 chương với nội dung tóm tắt sau: Chương Tấn công DDoS giải pháp phịng chống mạng SDN/Openflow: trình bày tổng quan công DDoS, phân loại công, kỹ thuật cơng giải pháp phịng chống DDoS dựa công nghệ mạng truyền thống; yêu cầu, thách thức phịng chống cơng tham số đánh giá hiệu giải pháp phịng chống DDoS; vấn đề an ninh mạng, cơng DDoS mạng SOHO Nội dung chương đề cập đến nguyên lý, đặc điểm kỹ thuật mạng cấu hình phần mềm SDN, giao thức Openflow; giải pháp phòng chống DDoS dựa kiến trúc kỹ thuật SDN/Openflow; công DDoS tới mạng SDN/Openflow giải pháp phòng chống đề xuất Chương Đề xuất giải pháp phịng chống cơng DDoS dựa liệu thống kê chế xử lý gói tin kỹ thuật SDN/Openflow: Nội dung Chương đề xuất giải pháp phịng chống cơng DDoS mạng SDN với quy mô băng thông nhỏ sử dụng túy liệu thống kê đặc tính lưu lượng chế xử lý gói tin kỹ thuật SDN/Openflow Có thể triển khai giải pháp cần tạo ứng dụng quản trị mạng lớp ứng dụng SDN mà không cần bổ sung thêm thiết bị chuyên dụng Các giải pháp cụ thể bao gồm: - Kỹ thuật phát giảm thiểu cơng DDoS dựa mơ hình dự đốn làm trơn hàm mũ tham số thống kê đặc tính lưu lượng, - Kỹ thuật phát ngăn chặn công SYN Flood tới máy chủ hệ thống mạng dựa chế ủy nhiệm gói tin SYN điều khiển, - Kỹ thuật đánh dấu gói tin dựa kỹ thuật SDN/Openflow phục vụ truy vết nguồn phát sinh lưu lượng công Chương Đề xuất giải pháp phịng chống cơng DDoS dựa kỹ thuật SDN/Openflow sử dụng thêm phân tích xử lý lưu lượng: Mặc dù SDN/Openflow có nhiều lợi cho xây dựng triển khai giải pháp phòng chống DDoS, kiến trúc chưa có khả cung cấp đầy đủ thơng tin đặc tính lưu lượng cho phát hiện, phân loại giảm thiểu cơng Bên cạnh đó, việc truy vấn liệu thống kê qua giao diện Openflow làm cho lưu lượng giao diện điều khiển tăng lên, dễ trở nên tắc nghẽn làm mất, suy giảm chức điều khiển, công xảy Điều giới hạn quy mô băng thông hệ thống mạng Để khắc phục vấn đề này, nội dung Chương đề xuất kiến trúc SDN mở rộng bổ sung phân tích xử lý lưu lượng điều khiển hoạt động tương tác với thực thể khác theo chế, kỹ thuật SDN/Openflow Trên sở ứng dụng kiến trúc SDN mở rộng, đề xuất 02 giải pháp phòng chống DDoS bao gồm: - Kỹ thuật phân loại giảm thiểu cơng DDoS dựa thuật tốn logic mờ, - Kỹ thuật giảm thiểu công SYN Flood vào chuyển mạch điều khiển mạng SDN/Openflow sử dụng chế ủy nhiệm gói tin SYN phân tích xử lý lưu lượng xix Các đóng góp khoa học luận án Luận án thực 02 đóng góp khoa học sau đây: Đề xuất kỹ thuật phát giảm thiểu cơng DDoS mơ hình dự đốn làm trơn hàm mũ với tham số thống kê lưu lượng; kỹ thuật đánh dấu gói tin phục vụ truy vết nguồn phát sinh lưu lượng công; kỹ thuật giảm thiểu công SYN Flood chế ủy nhiệm gói tin SYN sử dụng cơng nghệ SDN Đề xuất kiến trúc SDN/Openflow mở rộng với phân tích xử lý lưu lượng để nâng cao hiệu phát giảm thiểu công DDoS 1 CHƯƠNG TẤN CƠNG DDOS VÀ CÁC GIẢI PHÁP PHỊNG CHỐNG TRONG MẠNG SDN/OPENFLOW 1.1 Giới thiệu chương Chương trình bày tổng quan công DDoS; phân loại hình thức cơng, giải pháp phịng chống DDoS dựa công nghệ mạng truyền thống; tham số, tiêu chí đánh giá giải pháp phịng chống DDoS yêu cầu, thách thức giải pháp phòng chống DDoS Phần nội dung chương giới thiệu kiến trúc, kỹ thuật mạng cấu hình phần mềm SDN, cấu trúc phạm vi chuẩn hóa giao thức Openflow, vấn đề kỹ thuật Openflow bao gồm phạm vi chuẩn hóa, tin trao đổi thực thể, quy tắc nhận dạng luồng xử lý gói tin… Nội dung chương trình bày kết khảo sát giải pháp, kỹ thuật phát hiện, ngăn chặn, giảm thiểu công DDoS dựa kỹ thuật SDN/Openflow Phần cuối chương đề cập đến nguy công DDoS vào kiến trúc, kỹ thuật SDN/Openflow nghiên cứu, khảo sát giải pháp phòng chống tương ứng 1.2 Tổng quan công DDoS 1.2.1 Khái niệm Tấn công DoS Internet thiết kế dựa nguyên tắc tối thiểu hóa xử lý thông tin, đồng thời việc thực chuyển gói tin hệ thống mạng theo chế nỗ lực tối đa, khơng quan tâm khơng có biện pháp kiểm sốt nguồn gốc gói tin tính nguy hại Chính triết lý dẫn đến hệ lợi dụng internet để phát lưu lượng cơng khơng mục đích lấy cắp thông tin, truy nhập bất hợp pháp mà nhằm ngăn cản người dùng lành tính khác tiếp cận dịch vụ mạng internet Tấn công từ chối dịch vụ (DoS) [31] dạng công nhằm ngăn chặn người dùng hợp pháp truy nhập tới dịch vụ, tài nguyên mạng làm cho hệ thống mạng sử dụng, bị gián đoạn, chậm cách đáng kể cách làm tải tài nguyên hệ thống Đối tượng công DoS [1], [32], [33] là: • Một ứng dụng, dịch vụ • Một máy chủ, máy tính có địa cụ thể • Tồn hệ thống mạng phạm vi cụ thể Mục tiêu cụ thể cơng DoS bao gồm: • Nhằm tiêu tốn tài ngun tính tốn hệ thống đối tượng cơng băng thông, dung lượng đĩa cứng thời gian xử lý 2 • Cơ lập, cách ly đối tượng công với người dùng kỹ thuật phá vỡ thơng tin cấu hình, thơng tin định tuyến; phá vỡ trạng thái kết nối mạng; phá vỡ thành phần vật lý hệ thống mạng; làm tắc nghẽn kênh truyền… Các phương pháp cơng DoS là: • Thao tác phần cứng: Kẻ cơng tìm cách phá hủy, gây lỗi thiết bị phần cứng, gây nhiễu hệ thống • Kỹ thuật lưu lượng: Kẻ công phát lưu lượng làm lụt hệ thống đích làm lỗi giao thức truyền thông hệ thống mạng Đây kỹ thuật phổ biến tính chất đơn giản, khó bị phát • Chiếm đoạt quyền điều khiển: Kẻ cơng tìm cách chiếm quyền điều khiển máy chủ, thiết bị mạng sau tắt máy chủ, dịch vụ cấu hình giới hạn khả phục vụ dịch vụ, thay đổi bảng định tuyến thiết bị mạng để cách ly lưu lượng người dùng hợp pháp với máy chủ Tấn công DDoS Tấn công từ chối dịch vụ phân tán (DDoS) [3], [15], [34] dạng phát triển mức độ cao công DoS sử dụng kỹ thuật lưu lượng lưu lượng công huy động lúc từ nhiều máy tính khác hệ thống mạng Hình 1.1 Hình 1.1 Lưu lượng cơng DDoS huy động từ nhiều nguồn Internet 1.2.2 Phân loại công DDoS Tấn cơng DDoS phân loại theo nhiều cách khác [2], [3], [32], [33], [35], [36] Dưới số cách phân loại Phân loại theo kỹ thuật công: Theo cách phân loại [2], [3], [35], công DDoS phân thành nhóm thể sơ đồ Hình 1.2 • Tấn cơng dựa vào dung lượng lưu lượng: Nhóm bao gồm kỹ thuật chính: - Làm lụt (flooding): Kẻ công cố gắng ngăn chặn kết nối từ người dùng hợp pháp cách tạo lưu lượng khổng lồ tới mục tiêu công làm cạn kiệt tài nguyên băng thông Kỹ thuật thường dựa giao thức mạng lớp UDP flood, ICMP flood Kẻ cơng khai thác điểm yếu phần mềm, dịch vụ ứng dụng tạo nhiều kết nối giả mạo, khơng có mục đích nhằm ngăn chặn kết nối lành tính Dạng phổ biến công loại HTTP Flood với hàng triệu kết nối khơng mục đích gửi đến máy chủ Kẻ cơng sử dụng kỹ thuật thăm dị lực phục vụ máy chủ điều chỉnh tốc độ cơng tạo nên hình thức cơng dai dẳng làm suy giảm lực máy chủ công Slowloris [37] Theo báo cáo an ninh mạng thường niên Abor Networks năm 2018 [38], loại công chiếm tới 75,7% cơng Hình 1.2 Phân loại kỹ thuật công DDoS - Khuếch đại: Kỹ thuật công lợi dụng giao thức trao đổi gói tin yêu cầu/trả lời (request/response) khả giả mạo địa nguồn mạng IP Hàng loạt yêu cầu giả mạo địa nguồn địa nạn nhân gửi tới máy chủ đồng thời Giao thức trao đổi yêu cầu/trả lời có đặc tính lưu lượng yêu cầu nhỏ tin trả lời lớn gửi ạt tin trả lời tới máy nạn nhân lúc làm cho lưu lượng tới máy nạn nhân tăng đột biến, gây tải Các dịch vụ thường lợi dụng cho công dạng bao gồm máy chủ DNS, NTP, IRC,… Ngồi ra, chế trao đổi gói tin quảng bá, phản xạ hệ thống mạng lợi dụng Smurf, Fraggle [33] • Tấn cơng dựa vào lỗ hổng giao thức truyền thông mạng: Các lỗ hổng an ninh cố hữu giao thức mạng lợi dụng để phát động công theo dạng chế bắt tay ba bước (gọi tắt 3HS) giao thức TCP [39], giao thức ICMP,… Ví dụ công TCP SYN Flood [18], [40], theo giao thức TCP, nhận gói tin SYN, máy chủ (server) gửi gói tin trả lời SYN-ACK dành vùng nhớ TCB 128 KB để lưu trữ thơng tin kết nối chờ gói tin xác nhận CliACK từ máy khách (client) khoảng thời gian (lên đến 75s) trước gửi gói tin trả lời SYN-ACK (Hình 1.3 a) Lợi dụng nguyên tắc này, kẻ công huy động gửi ạt gói tin SYN tới máy chủ mà khơng gửi gói tin xác nhận CliACK dẫn đến máy chủ nhanh chóng bị cạn kiệt tài nguyên dành hết nhớ cho TCB tương ứng với kết nối dang dở (gọi tắt HOC) phục vụ kết nối lành tính khác (Hình 1.3 b) 4 Hình 1.3 Quá trình bắt tay ba bước kết nối TCP (a) chế công TCP SYN Flood (b) Phân loại theo phương thức huy động nguồn công Nguồn công yếu tố quan trọng tổ chức công DDoS Trong đợt công DDoS, kẻ công thường huy động nguồn lực công từ nhiều nguồn nhằm tạo lưu lượng công lớn vượt khả phục vụ hệ thống đồng thời che dấu nơi phát lưu lượng công Các phương thức huy động nguồn cơng bao gồm: • Giả mạo địa nguồn: Lợi dụng đặc điểm tự trị mạng Internet khơng có chế xác thực địa nguồn gói tin IP, kẻ cơng phát lưu lượng thay đổi địa IP nguồn gói tin địa IP giả mạo cách ngẫu nhiên làm cho máy chủ đích khơng thể biết nguồn phát sinh lưu lượng xác, khó phân biệt lưu lượng lành tính lưu lượng cơng • Sử dụng botnet: Botnet tập hợp gồm nhiều máy tính Internet bị lây nhiễm phần mềm độc hại (malware) mà nhờ đó, kẻ cơng điều khiển máy tính thực thi kết nối tới máy tính khác Internet theo mục đích riêng chúng mà chủ sở hữu máy tính khơng hay biết [4] Các máy tính botnet gọi xác sống Bằng kỹ thuật phát tán virus, malware, kẻ công tuyển mộ xác sống Internet huy động chúng phát sinh lưu lượng đợt công Số lượng xác sống botnet lên đến hàng triệu nên tổ chức công, lưu lượng công xác sống nhỏ, chúng tạo nên tổng lưu lượng công khổng lồ đủ làm tê liệt hệ thống mạng nạn nhân khoảng thời gian ngắn cỡ vài phút • Kết hợp sử dụng botnet giả mạo địa nguồn: Ở phương thức này, xác sống botnet phát lưu lượng công với địa IP giả mạo nhằm vơ hiệu hóa phương pháp giảm thiểu công thông thường lọc địa IP Chính kết hợp phương thức huy động nguồn công làm cho việc phát phân loại lưu lượng công, giảm thiểu cơng DDoS trở nên khó khăn 5 1.2.3 Các giải pháp phịng chống DDoS dựa cơng nghệ mạng truyền thống Vị trí triển khai giải pháp Do huy động từ nhiều nguồn khác nên lưu lượng cơng DDoS có đặc điểm nhỏ phía nguồn phát sinh lớn phía mạng nạn nhân Đặc điểm dẫn đến thực tế nguồn phát sinh lưu lượng công, việc áp dụng giải pháp ngăn chặn cơng dễ lại khó phát cơng Ngược lại mạng nạn nhân, việc phát công dễ ngăn chặn giảm thiểu công khó thực Do tính nguy hại cơng DDoS, thực tế, giải pháp phòng chống DDoS dựa công nghệ mạng truyền thống triển khai mạng nguồn phát sinh, mạng trung gian hệ thống mạng đích a) Triển khai mạng nguồn phát sinh lưu lượng Các kỹ thuật phát ngăn chặn mạng phát sinh lưu lượng chủ yếu thực định tuyến, gateway kiểm soát lưu lượng khỏi hệ thống mạng, áp dụng lọc gói tin [41], [42] nhằm ngăn chặn giả mạo địa IP không với địa trạm bên hệ thống Một số giải pháp khác thực phân tích kiểm soát lưu lượng kết nối trạm bên hệ thống mạng nguồn với Internet nhằm phát bất thường loại bỏ lưu lượng cơng DDoS [43]–[45] Tuy nhiên khơng có ràng buộc hệ thống tự trị Internet nên việc phối hợp triển khai phòng chống DDoS mạng nguồn phát sinh thực tế có hiệu thấp b) Triển khai mạng trung gian Chủ yếu thực định tuyến với lọc nhằm phát bất thường lưu lượng chuyển qua hệ thống mạng [16], [46] Một số giải pháp đề xuất bổ sung chức đánh dấu gói tin chuyển qua định tuyến nhằm hỗ trợ truy vết nguồn phát sinh lưu lượng công không dựa vào trường thơng tin địa IP nguồn gói tin công [47]–[50] Cũng giống mạng nguồn phát sinh lưu lượng công, giải pháp áp dụng mạng trung gian thực tế không mang lại hiệu cao c) Triển khai mạng máy chủ đích Đây giải pháp chủ yếu áp dụng hầu hết hệ thống mạng tham gia Internet bao gồm triển khai máy chủ (host based) thiết bị mạng (network based) Các giải pháp triển khai máy chủ thường áp dụng số loại công cụ thể SYN Cookie [51] ngăn chặn công TCP SYN Flood Nhằm tăng độ xác phát giảm thiểu công hệ thống mạng rộng lớn trung tâm liệu ISP, giải pháp phòng chống DDoS triển khai nhiều điểm hệ thống để đo lưu lượng (probe) phát hiện, giảm thiểu công nhờ thiết bị IDS, IPS, tường lửa (firewall) Các giải pháp triển khai phổ biến mạng đích bao gồm: • Phát cơng: Áp dụng thuật tốn tham số lưu lượng để xác định có cơng xảy hay khơng • Phân loại xác định lưu lượng cơng: Dựa vào đặc tính nhóm lưu lượng để phân biệt lưu lượng cơng lưu lượng lành tính • Lọc bỏ lưu lượng công: Sử dụng kỹ thuật lưu lượng để xóa bỏ lập lưu lượng cơng, giảm thiểu ảnh hưởng lưu lượng công tới máy chủ hệ thống mạng • Truy vết lưu lượng công: Khi công diễn ra, sử dụng kỹ thuật khác để xác định nguồn công đường lưu lượng công Các kỹ thuật phát công Tấn cơng DDoS phát theo hai nhóm kỹ thuật: dựa vào dấu hiệu công dựa vào bất thường lưu lượng: a) Dựa vào dấu hiệu công Được áp dụng phương thức, kỹ thuật công khai thác lỗ hổng giao thức mạng lỗ hổng ứng dụng, dịch vụ mạng Các kỹ thuật phát phải phân tích sâu nội dung tiêu đề gói tin để phát lỗi bất thường Kỹ thuật đem lại độ xác cao, nhiên địi hỏi tính tốn lớn phải phân tích sâu gói tin so sánh đặc tính lưu lượng với số lượng lớn mẫu cơng Ngồi kỹ thuật phát mẫu công b) Dựa vào bất thường lưu lượng Các kỹ thuật áp dụng phổ biến phát cơng DDoS mơ hình đặc tính lưu lượng bình thường xây dựng thống kê, cập nhật Đặc tính lưu lượng tức thời chuyển qua hệ thống so sánh với đặc tính lưu lượng bình thường Tấn cơng cho xảy có khác biệt lớn đặc tính lưu lượng tức thời với đặc tính lưu lượng bình thường [15] Kỹ thuật cịn áp dụng để phân loại lưu lượng công với lưu lượng lành tính có cơng xảy Sự khác biệt kỹ thuật phát phân loại công chỗ lựa chọn tham số mô hình đặc tính lưu lượng Một tham số mơ hình đặc tính lưu lượng phải đảm bảo hai yếu tố [52]: • Hầu hết mẫu lưu lượng lành tính phải tn thủ đặc tính lưu lượng bình thường • Mẫu lưu lượng cơng phải có khác biệt lớn so với đặc tính lưu lượng bình thường Tuy nhiên, thực tế, để xây dựng tham số mơ hình đặc tính lưu lượng thỏa mãn hai điều kiện khó Vì việc phát phân loại lưu lượng cơng thường có phần lưu lượng cơng khơng phát phát nhầm lưu lượng lành tính thành lưu lượng cơng Các kỹ thuật phát cơng DDoS bao gồm: • Sử dụng mơ hình thống kê (Statistical): Kỹ thuật xây dựng mơ hình thống kê cho tham số lưu lượng dịch vụ, máy chủ, hệ thống mạng cụ thể lưu lượng lành tính Một mẫu lưu lượng trích xuất tham số so sánh với mơ hình thống kê dựa ngưỡng tham chiếu để xác định lưu lượng lành tính hay lưu lượng cơng [53], [54] 7 • Học máy (Machine learning): Kỹ thuật học máy áp dụng rộng rãi phát xâm nhập (IDS), công DDoS phân biệt đặc tính bình thường đặc tính bất thường lưu lượng nhờ trình học [17], [55] Các phương pháp học máy khác áp dụng mạng nơ-ron [56], mạng Bayesian [57], đồ tự tổ chức SOM [58],… • Khai phá liệu (Data mining): Áp dụng tổng hợp mơ hình thống kê, phương pháp học máy với lưu lượng quy mô lớn để xây dựng, hệ thống hóa để tạo đặc điểm riêng, mơ hình cho dịch vụ, máy chủ từ áp dụng để phân biệt lưu lượng công với lưu lượng lành tính với độ xác cao Kỹ thuật địi hỏi tài ngun tính tốn lưu trữ lớn, chưa có nhiều mơ hình theo kỹ thuật đề xuất phát phân loại lưu lượng công DDoS thực tế Các kỹ thuật phịng chống giảm thiểu cơng Kỹ thuật phịng chống giảm thiểu cơng DDoS dựa công nghệ mạng truyền thống chia làm hai nhóm: triển khai máy chủ (host based) triển khai hệ thống mạng (network based) • Các giải pháp triển khai máy chủ: chủ yếu phịng chống cơng dựa vào giao thức giới hạn kết nối Để ngăn chặn công TCP SYN Flood, số hệ điều hành Linux áp dụng kỹ thuật SYN Cookie [51], hệ điều hành Windows cho phép điều chỉnh thời gian chờ TIME_WAIT [18] để hạn chế thời gian tồn TCB máy chủ Để ngăn chặn kết nối TCP, UDP, IMCP công ạt, số hệ điều hành cho phép đặt ngưỡng số lượng kết nối [31] • Các giải pháp triển khai hệ thống mạng: Trong công nghệ mạng truyền thống, đặc tính đóng kín thiết bị mạng, giải pháp phòng chống DDoS chủ yếu tập trung vào kỹ thuật đặt giới hạn kết nối lưu lượng [59] thao tác tay: - Căn vào đặc tính lưu lượng lực phục vụ máy chủ, ngưỡng giới hạn lưu lượng số lượng kết nối đồng thời Khi công xảy ra, lưu lượng thực tế vượt ngưỡng giới hạn này, lưu lượng kết nối bị xóa bỏ Điều dẫn tới giảm tỷ lệ thành công kết nối lành tính - Khi có dấu hiệu cảnh báo công xảy ra, thiết bị mạng đơn chuyển mạch, định tuyến cấu hình cách thủ công để ngăn chặn giảm thiểu công Đây nhược điểm cố hữu công nghệ mạng truyền thống phối hợp phát hiện, ngăn chặn giảm thiểu công Nguyên nhân thiết bị mạng điều khiển, cấu hình độc lập đóng kín 1.2.4 u cầu thách thức giải pháp phát ngăn chặn, giảm thiểu công DDoS Một số tham số đánh giá hiệu giải pháp a) Độ nhạy Trong công DDoS, lưu lượng công đến lúc với lưu lượng lành tính Để có giải pháp chống lại cơng, hệ thống phải có chế phát Mức độ phát là: • Phát có cơng xảy hay khơng hệ thống/máy chủ dịch vụ • Phân loại lưu lượng công khỏi lưu lượng lành tính • Lọc bỏ lưu lượng cơng để chúng không tới máy chủ gây tác hại Trong q trình phát hiện, giảm thiểu cơng tùy theo mức độ xác nhận diện lưu lượng giải pháp, lưu lượng đến xác định Bảng 1.1 [3] Bảng 1.1 Quan hệ kết phân loại giải pháp đặc tính thực lưu lượng Đặc tính thực lưu lượng Phân loại giải pháp Lành tính Tấn cơng Lành tính TN FN Tấn cơng FP TP Theo quan hệ Bảng 1.1, độ nhạy (Sensitivity) ký hiệu DR giải pháp đánh giá khả nhận diện lưu lượng công: 𝑇𝑇𝑇𝑇 (1.1) 𝑇𝑇𝑇𝑇 + 𝐹𝐹𝐹𝐹 Khi xét khả phân loại lưu lượng giải pháp, độ nhạy cụ thể thành độ nhạy phân loại DR C Khi xét khả lọc bỏ lưu lượng công, độ nhạy cụ thể thành độ nhạy lọc bỏ DR F 𝐷𝐷𝐷𝐷 = b) Tỷ lệ báo động nhầm Tỷ lệ báo động nhầm (FPR) đánh giá khả nhận diện nhầm lưu lượng lành tính thành lưu lượng cơng: 𝐹𝐹𝐹𝐹𝐹𝐹 = 𝐹𝐹𝐹𝐹 𝑇𝑇𝑇𝑇 + 𝐹𝐹𝐹𝐹 (1.2) Khi xét kết phân loại lưu lượng giải pháp, tỷ lệ báo động nhầm gọi tỷ lệ phân loại báo động nhầm FPR C Khi xét kết lọc bỏ lưu lượng công, tỷ lệ gọi tỷ lệ lọc bỏ nhầm FPR F c) Thời gian đáp ứng Tham số thời gian đáp ứng đánh giá mức độ phản hồi giải pháp phòng chống DDoS tính khoảng thời gian từ lúc lưu lượng công bắt đầu chuyển tới hệ thống mạng/máy chủ đích bắt đầu có kết phân loại trạng thái công đầu bắt đầu áp dụng sách ngăn chặn, giảm thiểu công Tùy theo chức giải pháp (phát hiện, phân loại hay ngăn chặn, giảm thiểu cơng) mà tham số tính cụ thể cho trường hợp khác d) Khả lọc bỏ Khả lọc bỏ đánh giá mức độ giảm thiểu, loại bỏ tác hại cơng mà giải pháp phịng chống công đạt Cần ý khả lọc bỏ khác với khả phát Có nhiều giải pháp phát hiện, phân loại lưu lượng công không loại bỏ ảnh hưởng lưu lượng công phát Khả lọc bỏ đo tỷ lệ lưu lượng lọc bỏ tổng số lưu lượng công e) Khả chịu đựng công Năng lực xử lý hệ thống/máy chủ khác tùy theo cấu hình hệ thống, lưu lượng kết nối đặc điểm dịch vụ máy chủ Để tăng cường lực cho máy chủ dịch vụ chạy nó, ngồi việc nâng cao cấu hình, nhà khai thác dịch vụ áp dụng giải pháp phòng chống DDoS Hiệu giải pháp tổng hợp thể mức chịu đựng công với tốc độ khác thể tham số cụ thể số lượng phiên kết nối tối đa máy chủ, băng thông tối đa kết nối, thời gian tối đa chịu đựng máy chủ với tốc độ lưu lượng công đến cụ thể… Về mặt lý thuyết, tham số có giá trị lớn tốt giúp cho giải pháp phịng chống cơng có nhiều thời gian để phân tích đưa sách cho hệ thống mạng bị công Các yêu cầu thách thức giải pháp phòng chống DDoS Theo Bawany [60], giải pháp phòng chống DDoS hiệu phải đảm bảo u cầu cụ thể sau: • Cơ chế phịng chống DDoS không làm ảnh hưởng đến hoạt động người dùng hợp pháp lưu lượng lành tính họ • Cơ chế phát cơng cần phải có giải pháp ngăn chặn giảm thiểu cơng kèm với để ngăn chặn cơng từ bên bên ngồi • Cơ chế phịng chống cơng phải hoạt động quy mô tương ứng hệ thống mạng trung tâm liệu • Giải pháp cần phải mềm dẻo, khả thích ứng cao với thay đổi quy mô dịch vụ, quy mô lưu lượng, làm tăng khả chịu đựng công hệ thống mạng • Giải pháp phải có chi phí triển khai thấp, hạn chế thấp gia tăng thiết bị phần cứng, đồng thời thay đổi quy mô khơng làm tăng tải tính tốn lưu trữ toàn hệ thống Trong bối cảnh phát triển mạnh mẽ hệ thống mạng Internet gia tăng công mạng Theo Bawany [60], thách thức đặt phịng chống DDoS kể đến: • Sự phân biệt lưu lượng lành tính lưu lượng cơng ngày khó kẻ cơng áp dụng kỹ thuật khác để lưu lượng cơng bắt chước giống với lưu lượng lành tính trạng thái đơng đúc đột ngột (flash crowd) • Dịch vụ mạng dần chuyển sang xu công nghệ đám mây, điều dẫn đến máy ảo triển khai linh động khắp nơi, điều đồng nghĩa với nguy công DDoS hệ thống mạng khơng từ bên ngồi mà xuất phát từ máy ảo bên • Các dịch vụ lưu trữ multimedia với dung lượng lớn ngày phát triển đòi hỏi hệ 10 thống mạng có băng thơng lớn, độ tin cậy cao, dẫn đến yêu cầu hiệu quy mơ mạng lớn Do giải pháp phịng chống DDoS cho hệ thống mạng tốc độ lớn trở nên khó khăn • Để đảm bảo trì tỷ lệ báo động nhầm FPR thấp thường kéo theo độ nhạy DR thấp Bên cạnh đó, tốc độ dịch vụ mạng ngày lớn dẫn đến gia tăng hình thức cơng tốc độ thấp dai dẳng (slowloris) phương thức công dễ dàng vượt qua giải pháp phát ngăn chặn • Quy mơ hệ thống mạng Internet ngày lớn tạo điều kiện cho botnet phát triển số lượng lực xác sống Điều dẫn đến cường độ quy mô công DDoS ngày lớn Với yêu cầu, thách thức trên, công DDoS mối quan tâm giải kỹ thuật kiến trúc mạng hệ Mạng quy mô nhỏ vấn đề an ninh mạng quy mô nhỏ Trước đây, dịch vụ mạng Internet chủ yếu cung cấp tập trung thông qua hệ thống máy chủ trung tâm liệu Trong năm gần đây, với phát triển mạnh mẽ công nghệ truyền dẫn đặc biệt phổ biến công nghệ truyền dẫn quang, cho phép lưu lượng kết nối Internet hai chiều người sử dụng tăng lên đáng kể Bên cạnh đó, gia tăng dịch vụ multimedia, dịch vụ truyền số liệu thiết bị, hệ thống IoTs Internet làm cho mạng quy mô nhỏ (SOHO network) [61] mạng gia đình, văn phịng quan nhỏ không đơn sử dụng dịch vụ Internet mà chuyển sang cung cấp dịch vụ quy mơ, phạm vi nhỏ Ví dụ: dịch vụ truyền hình ảnh hệ thống camera giám sát, dịch vụ truyền liệu từ thiết bị lưu trữ liệu, dịch vụ điều khiển nhà thơng minh,… Ngồi ra, xu làm việc độc lập (self-employed) ngày trở nên phổ biến làm xuất gia tăng nhu cầu kết nối Internet cung cấp dịch vụ qua mạng văn phòng nhỏ Theo Bradley Mitchell [61], mạng quy mô nhỏ sở hữu phục vụ nhu cầu làm việc nhóm nhỏ người dùng hình thành mạng LAN kết nối Internet qua đường truyền với lưu lượng thấp SOHO network thường có kết cấu đa dạng mạng có dây khơng dây với thiết bị, dịch vụ hỗn tạp Khác với tổ chức dịch vụ hệ thống máy chủ trung tâm liệu lớn, dịch vụ từ mạng SOHO thường trọng yếu tố đảm bảo an ninh, phòng chống công Nguyên nhân thiếu quan tâm mức người dùng việc tổ chức dịch vụ liệu Các vấn đề chi phí yếu tố cản trở số lượng dịch vụ quy mô lưu lượng mạng SOHO thường nhỏ, khơng tương xứng với chi phí cho triển khai giải pháp đảm bảo an ninh mạng [62]–[64] Điều dẫn đến mạng SOHO vừa mục tiêu đợt cơng mạng nói chung cơng DDoS nói riêng, vừa nơi kẻ công lợi dụng để phát tán mã độc, huy động xác sống để tham gia hoạt động xâm phạm an ninh mạng, tổ chức công DDoS 1.3 Kỹ thuật mạng cấu hình phần mềm SDN Trong vài thập niên trở lại đây, phát triển bùng nổ mạng Internet làm cho hệ 11 thống mạng không ngừng lớn mạnh số lượng lẫn quy mô, kiến trúc, sở hạ tầng Đối với nhà quản lý khai thác mạng, việc điều hành hệ thống trở nên khó khăn, hiệu hoạt động hệ thống thấp Một nguyên nhân định tuyến, chuyển mạch hệ thống mạng thiết lập cứng, vốn bị khóa kiểm sốt độc quyền cơng ty sản xuất chúng Trước thực trạng đó, ý tưởng xuất từ năm 1996, khái niệm Kỹ thuật mạng cấu hình phần mềm bắt đầu quan tâm trở lại từ cuối năm 2010 trở thành hướng nóng hổi cấp thiết với mục đích cho phép đối tác phần mềm thứ truy nhập thao tác mặt phẳng điều khiển thiết bị mạng từ xa, trực tuyến cách sử dụng giao thức mở, ví dụ Openflow [20] Tổ chức ONF thành lập xây dựng phát triển chuẩn công nghệ mạng gọi Software Defined Networking (SDN) [19] Hình 1.4 Kiến trúc mạng cấu hình phần mềm SDN Đặc trưng SDN trừu tượng hóa hệ thống mạng thành hai mặt phẳng: mặt phẳng liệu mặt phẳng điều khiển nhằm tối ưu nhiệm vụ chức hai thành phần mơ hình kiến trúc Hình 1.4 Theo đó, kiến trúc SDN gồm lớp: - Lớp hạ tầng mạng (Infrastructure layer): đồng thời mặt phẳng liệu bao gồm thiết bị phần cứng hệ thống mạng gọi chung chuyển mạch Những chuyển mạch khác với chuyển mạch theo công nghệ mạng truyền thống chỗ chúng khơng có chức điều khiển đơn thực chức chuyển tiếp xóa bỏ gói tin đến dựa thơng tin cấu hình mặt phẳng điều khiển phía Tùy theo thuật toán điều khiển xác lập mặt phẳng điều khiển mà chuyển mạch thực chức thiết bị khác công nghệ mạng truyền thống chuyển mạch lớp 2, chuyển mạch lớp 3, định tuyến, cân tải, v.v… - Lớp điều khiển (Control layer): nằm phía lớp hạ tầng mạng có chức trừu tượng hóa cung cấp tài nguyên hệ thống mạng từ lớp hạ tầng cho lớp ứng dụng phía trên, đồng thời thực thi sách xử lý gói tin từ phần mềm từ lớp ứng dụng xuống lớp hạ tầng mạng Thành phần chính, quan trọng lớp điều khiển điều khiển SDN (SDN 12 Controller), đóng vai trị não, hệ điều hành hệ thống mạng, trì viewpoint toàn cục, tập trung, quản lý cung cấp tài nguyên lớp hạ tầng mạng cho phép ứng dụng lớp cấu hình quản lý hệ thống mạng thông qua giao diện mở Trên thực tế có nhiều sản phẩm điều khiển thương mại [65] mã nguồn mở [66] Bộ điều khiển tương tác với chuyển mạch lớp hạ tầng mạng thông qua chuẩn giao thức riêng - Lớp ứng dụng (Application layer): bao gồm ứng dụng quản trị, tối ưu hóa bảo mật sách xử lý lưu lượng hệ thống mạng Các ứng dụng chạy máy chủ độc lập kết nối với điều khiển thông qua giao diện API chạy trực tiếp điều khiển tùy theo quy mô hệ thống mạng quy mô liệu ứng dụng Với triết lý quản lý giám sát tài nguyên mạng tập trung, SDN cung cấp cho phần mềm ứng dụng tồn thơng tin lớp hạ tầng mạng, sở đó, phầm mềm đưa sách áp dụng đồng bộ, thống nhất, tối ưu tồn hệ thống mạng Cơng nghệ SDN cho phép thực nghiệm nhanh chóng, mềm dẻo tối ưu hóa sách định tuyến, chuyển mạch; cho phép truy nhập từ bên vào bên chuyển mạch, định tuyến Trên sở đó, SDN giải nhiều vấn đề công nghệ mạng truyền thống gặp phải như: - Công nghệ SDN cho phép nhà mạng xác định dịch vụ mạng mà không cần kết hợp tham số kỹ thuật dịch vụ với giao diện mạng Nói cách khác SDN tách riêng việc điều khiển luồng liệu hệ thống mạng (thơng qua nhận biết, học, tính tốn định chuyển gói tin) khỏi kiến trúc topology mạng (bao gồm kết nối phần cứng, giao diện thực thể mạng) Điều có ý nghĩa quan trọng, phù hợp với đặc điểm mạng hệ với kiến trúc đám mây mềm dẻo, định vị động tài nguyên mạng, hệ thống máy tính di động, hệ thống điện toán đám mây, - Bằng chế kiểm soát, định tuyến mềm dẻo gói tin, SDN cho phép thực cách dễ dàng nhiều chức khó thực công nghệ mạng truyền thống logical grouping, điều khiển quyền truy cập, đảm bảo tham số QoS theo dịch vụ, v.v; đơn giản hóa việc xây dựng, cấu hình đảm bảo chất lượng VLAN, VPN… Mặc dù kiến trúc mạng SDN tiếp tục chuẩn hóa, phát triển, nay, có nhiều sản phẩm, hệ thống SDN triển khai thực tế hệ thống mạng B4 Google [67], hệ thống mạng truyền tải Huawei [68],… 1.4 Giao thức OpenFlow Một giao thức SDN phổ biến phát triển tích hợp số sản phẩm phần cứng Giao thức luồng mở - Openflow [20] Openflow kết nghiên cứu Đại học Stanford California, Berkeley chuẩn giao tiếp đầu tiên, cung cấp khả giao tiếp mặt phẳng điều khiển mặt phẳng liệu kiến trúc SDN Openflow cho phép điều khiển mạng truy xuất vào thiết bị mạng (bao gồm thiết bị phần cứng thiết bị ảo), thực thi sách hệ thống mạng cách tự động, mềm dẻo 13 Thông qua Openflow, điều khiển gửi tập hướng dẫn chung tới switch router hãng sản xuất hỗ trợ chế Openflow Có thể nói SDN Openflow giải pháp tiềm để tự động hóa cấu hình, nâng cấp khả đáp ứng hệ thống mạng, giảm thiểu chi phí quản trị, mở nhiều triển vọng cho nghiên cứu phát triển giải pháp tối ưu kỹ thuật mạng, nâng cao chất lượng dịch vụ, giải vấn đề hạ tầng mạng truyền thông gặp phải Cộng đồng phát triển xây dựng ứng dụng phần mềm chạy điều khiển, giải toán nâng cao hiệu năng, giám sát mạng kỹ thuật bảo mật, kỹ thuật cân tải, tiết kiệm lượng,… trung tâm liệu 1.4.1 Cấu trúc phạm vi chuẩn hóa Openflow Cấu trúc, phạm vi vị trí giao thức Openflow kiến trúc SDN mô tả Hình 1.5 Theo đó: - Phạm vi chuẩn hóa Openflow bao gồm cấu trúc chuyển mạch, giao thức trao đổi tin điều khiển điều khiển mạng (controller) chuyển mạch Openflow (OFS) - Cấu trúc chuyển mạch Openflow bao gồm phần cứng (hw) phần mềm (sw) Phần cứng gồm module quản lý xử lý trình chuyển tiếp gói tin hệ thống mạng thơng qua bảng cấu hình gọi bảng luồng Phần mềm module thực chức trung gian giao tiếp phần cứng điều khiển, cung cấp thông tin phần cứng cho điều khiển, đồng thời thực thi thao tác từ điều khiển tới phần cứng - Để đảm bảo an toàn, chống xâm nhập chiếm quyền điều khiển trái phép, giao tiếp điều khiển chuyển mạch mã hóa bảo mật có xác thực theo kỹ thuật SSL Hình 1.5 Cấu trúc phạm vi chuẩn hóa giao thức Openflow Giao thức Openflow phát triển đời phiên hoàn chỉnh 1.1 vào tháng năm 2011 liên tục phát triển nhiều cập nhật Cho tới phiên 1.5.1 bổ sung nhiều chức giải nhiều tốn khác chuyển hóa vào nhiều sản phẩm thương mại sản phẩm mã nguồn mở kể đến, bao gồm: • Các chuyển mạch thương mại HP ProCurve 3500, 3800, 5400, 2920, 8200; IBM G8264, 8316, 8052; Cisco Catalyst 3850,…; Bộ chuyển mạch mềm 14 OpenVswitch [69] • Bộ điều khiển mã nguồn mở POX [70], Ryu [71] phát triển Python; ONOS [72], OpenDaylight [73], Foodlight [74]… Java; NOX [75] Python C++,… • Các môi trường, công cụ nghiên cứu, thử nghiệm mininet [76] 1.4.2 Nhận dạng quản lý lưu lượng chuyển mạch Openflow Đối tượng xử lý thông tin chuyển mạch Openflow gói tin Nhằm đưa sách xử lý gói tin đa dạng, mềm dẻo, Openflow nhận dạng phân nhóm thơng tin nhiều mức dataframe (lớp 2), packet (lớp 3) hay datagram (lớp 4) theo luồng Sau khái niệm nhận dạng, phân nhóm quản lý lưu lượng Openflow • Luồng (flow): khái niệm dùng để nhận dạng lưu lượng sở định nghĩa trước thuộc tính Những lưu lượng có thuộc tính xuất phạm vi khoảng thời gian định chuyển mạch thuộc vào luồng Ví dụ: luồng gói tin lớp xuất phát từ địa IP nguồn, luồng gói tin xuất phát từ cổng có số hiệu port = chuyển mạch cụ thể,… • Mục luồng (flow entry): Để nhận dạng quản lý luồng, chuyển mạch sử dụng thông tin để so khớp với lưu lượng đến nhờ cấu trúc thông tin gọi mục luồng Cấu trúc mục luồng mô tả Hình 1.6 - Các trường so khớp (Match fields): bao gồm quy tắc để nhận dạng lưu lượng Các gói tin khớp với tất thơng tin quy định trường thuộc phạm vi xử lý mục luồng - Tập lệnh xử lý (Instruction sets): bao gồm lệnh, quy tắc xử lý gói tin áp dụng chuyển mạch lưu lượng mục luồng Thành phần quan trọng lệnh xử lý actions áp dụng gói tin khớp với mục luồng - Các đếm (counters): Chứa thông tin thống kê lưu lượng khớp với mục luồng - Mức ưu tiên (priority): cấp độ ưu tiên so khớp gói tin với mục luồng - Thời gian chờ (timeout): quy định thời gian tồn mục luồng theo xuất lưu lượng Để tối ưu hóa q trình nhận dạng, xử lý lưu lượng luồng theo sách mong muốn, ứng dụng quản trị mạng thiết lập trường so khớp, mức ưu tiên thời gian chờ cho mục luồng tương ứng • Bảng luồng (flow table): Openflow xếp quản lý mục luồng bảng luồng Một bảng luồng tập hợp gồm nhiều mục luồng Quản lý theo bảng luồng giúp chuyển mạch phân cụm quy tắc quản lý lưu lượng làm cho trình so khớp, nhận dạng lưu lượng tối ưu 1.4.3 Các tin trao đổi điều khiển chuyển mạch Openflow Để cấu hình, quản lý trạng thái chuyển mạch, quản lý kiện từ chuyển mạch 15 áp dụng sách xử lý gói tin, Openflow quy định cấu trúc tin trao đổi điều khiển chuyển mạch thuộc nhóm sau: Hình 1.6 Cấu trúc mục luồng Nhóm tin từ điều khiển tới chuyển mạch Các tin chủ động tạo điều khiển gửi tới chuyển mạch (Controller to Switch) sử dụng để quản lý kiểm tra trạng thái chuyển mạch, khơng địi hỏi phản hồi Nhóm tin bao gồm: • Features Request: Sử dụng thiết lập kênh truyền Nhận tin này, chuyển mạch trả lời thông tin phiên bản, cấu hình mà hỗ trợ • Configuration: Thiếp lập chỉnh sửa cấu hình tham số cho chuyển mạch • Modify-State: Chỉnh sửa thơng tin bảng luồng, thêm xóa luồng bảng luồng cụ thể • Read-State: Truy vấn thống kê từ bảng luồng, cổng luồng cụ thể • Send Packet Message: Chuyển tiếp gói tới cổng xác định chuyển mạch Nhóm tin bất đồng từ chuyển mạch Nhóm tin kiện từ chuyển mạch gửi tới điều khiển (Asynchronous Messages), giúp điều khiển cập nhật kiện hệ thống mạng trạng thái chuyển mạch Các tin bao gồm: • Packet-in: Khi gói tin đến không khớp với mục luồng chuyển mạch Bộ chuyển mạch gửi tin tới điều khiển để yêu cầu sách xử lý tương ứng • Flow - Removed: Xuất mục luồng bị xóa khỏi chuyển mạch • Port - Status: Khi có thay đổi trạng thái cổng chuyển mạch • Error Message: Khi có lỗi xảy chuyển mạch Nhóm tin hai chiều Nhóm tin gửi chuyển mạch, điều khiển (Symmetric Messages) mà khơng bắt buộc có yêu cầu trả lời: • Hello: dùng để thiết lập kết nối điều khiển chuyển mạch 16 • Echo Request/Reply: sử dụng để kiểm tra độ trễ, băng thông,… khả kênh truyền điều khiển chuyển mạch • Vendor: kiểm tra khả hỗ trợ chức bổ sung, không bắt buộc Openflow Các tin Openflow trao đổi điều khiển chuyển mạch truyền qua kênh truyền mã hóa bảo mật có xác thực SSL 1.4.4 Quy trình xử lý gói tin Openflow Openflow quy định trình xử lý lưu lượng chuyển mạch dựa nhận dạng luồng mục luồng trình bày mục 1.4.2 Các mục luồng cài đặt chỉnh sửa điều khiển thông qua tin trao đổi nêu mục 1.4.3 Quy trình xử lý gói tin đến chuyển mạch thực sau: - Các mục luồng xếp thành bảng luồng Q trình xử lý gói tin thực qua bảng luồng theo chế đường ống (pipeline) [20] Trong bảng luồng, mục luồng xếp theo thứ tự ưu tiên từ cao đến thấp Khi nhận gói tin tới, chuyển mạch thực so khớp (matching) trường tiêu đề gói tin với mục luồng bảng luồng Gói tin khớp với mục luồng trước, thuộc luồng tương ứng Khi khớp với mục luồng, tập lệnh xử lý tương ứng mục luồng thực thi Tùy theo lệnh tương ứng mục luồng khớp, q trình so khớp kết thúc tiếp tục xử lý so khớp với bảng luồng Qua bảng luồng, lệnh xử lý thao tác gói tin, action xử lý gói tin cụ thể tích lũy tập actions Các lệnh xử lý so khớp mục luồng bao gồm: Hình 1.7 Quá trình xử lý gói tin chuyển mạch theo chế đường ống • Write-Actions (actions): Thêm actions xử lý gói tin vào tập actions • Apply-Actions (actions): Thực thi action tập actions gói tin 17 • Clear actions: Xóa tồn action có tập actions áp dụng cho gói tin • Goto-Table (N): Chuyển tới so khớp với bảng luồng thứ N Quá trình so khớp thực từ bảng luồng đến bảng luồng theo thực thi lệnh có mục luồng khớp Thơng thường bảng luồng xếp thành nhóm bảng luồng xử lý đầu vào (ingress) nhóm bảng luồng xử lý đầu (egress) Hình 1.7 Kết thúc nhóm bảng luồng, tập actions thực áp dụng trực tiếp gói tin Hình 1.8 u cầu xử lý gói tin khơng khớp với mục luồng có sẵn chuyển mạch - Nếu trình so khớp bảng luồng, gói tin khơng khớp với mục luồng nào, kiện table-miss xảy chuyển mạch gửi tới điều khiển tin packet-in Các phần mềm ứng dụng điều khiển phân tích đưa sách để xử lý nhóm gói tin tương ứng với cách cài đặt chuyển mạch mục luồng Trong trình chờ đợi mục luồng cài đặt, gói tin lưu vùng đệm chuyển mạch Các gói tin luồng khớp với mục luồng chuyển mạch xử lý theo actions thiết lập mục luồng (Hình 1.8) - Trong trường hợp cụ thể, chuyển mạch cài đặt mục luồng để bắt giữ gói tin có trường thông tin thỏa mãn điều kiện cụ thể chuyển tới điều khiển action OUTPUT với số hiệu cổng OFPP_CONTROLLER 1.4.5 Quản lý mục luồng chuyển mạch Openflow Trong Openflow, mục luồng thông tin quan trọng định cách thức xử lý gói tin hệ thống mạng Mục luồng có vai trị phân nhóm gói tin thành luồng tương ứng, đưa sách chuyển mạch áp dụng gói tin Do thay đổi thường xuyên lưu lượng mạng nên mục luồng có giá trị khoảng thời gian định Để quản lý hiệu mục luồng giảm thiểu chiếm dụng tài nguyên chuyển mạch điều kiện thay đổi liên tục vậy, Openflow quy định phương thức tạo quản lý luồng Cài đặt, chỉnh sửa xóa mục luồng Trong Openflow, mục luồng cài đặt theo hai cách: - Chủ động (proactive): Bộ điều khiển chủ động cài đặt mục luồng tới chuyển mạch 18 Thông thường phương pháp áp dụng cho mục luồng tồn vĩnh viễn nhằm tạo luật xử lý gói tin ổn định suốt trình hoạt động chuyển mạch - Đáp ứng theo gói tin (reactive): Khi có kiện table-miss xảy ra, chuyển mạch tạo tin packet-in gửi tới điều khiển Bộ điều khiển vào thơng tin thuộc tính gói tin để cài đặt mục luồng tương ứng Hình 1.8 Trong trình hoạt động, phần mềm ứng dụng chỉnh sửa mục luồng có Thiết lập thời gian chờ cho mục luồng Để giới hạn thời gian tồn mục luồng chuyển mạch mục luồng khơng cịn giá trị gói tin thuộc luồng khơng cịn xuất hiện, Openflow cho phép thiết lập thời gian chờ cho mục luồng với hai tham số: (1) Thời gian chờ liên gói tin (idle timeout hay inactive timeout): khoảng thời gian tối đa chờ gói tin thuộc luồng tính từ chuyển mạch nhận gói tin sau Vượt thời gian này, luồng kết thúc mục luồng bị xóa khỏi chuyển mạch (2) Thời gian chờ cứng (hard timeout hay active timeout): khoảng thời gian tồn tối đa luồng Nếu tham số thiết lập, mục luồng đạt đến khoảng thời gian chờ hard timeout tính từ tạo ra, mục luồng bị xóa khỏi chuyển mạch gói tin luồng tương ứng có tiếp tục xuất hay khơng Mục đích thời gian chờ hard timeout để bảo vệ chuyển mạch khỏi chiếm dụng tài nguyên nhớ luồng cơng có chủ đích Tùy theo phạm vi, mục đích nhận dạng xử lý luồng, mục luồng thiết lập không thiết lập tham số thời gian chờ idle timeout hard timeout Nếu không thiết lập hai tham số này, mục luồng tồn vĩnh viễn chuyển mạch Việc thiết lập thời gian chờ cho mục luồng thực cài đặt chỉnh sửa mục luồng Thống kê mục luồng Như trình bày trên, mục luồng có chứa đếm thống kê tổng số gói tin, tổng dung lượng lưu lượng khớp với mục luồng, thời gian tồn mục luồng Trong trình hoạt động, điều khiển yêu cầu truy vấn giá trị đếm từ chuyển mạch thống kê số mục luồng tồn theo điều kiện Các số liệu thống kê từ mục luồng có ý nghĩa quan trọng khơng quản lý mục luồng mà cho ứng dụng quản trị điều hành mạng 1.5 Các giải pháp phòng chống DDoS dựa kiến trúc kỹ thuật SDN/Openflow 1.5.1 Kiến trúc nguyên lý hoạt động chung Với khả giám sát, điều khiển hệ thống mạng cách tập trung; khả lập trình, cấu hình tự động phần mềm; thay đổi sách xử lý gói tin linh động, tự động… kiến 19 trúc mạng kỹ thuật SDN/Openflow nhiều giải pháp đề xuất ứng dụng phòng chống DDoS [21]–[26], [77]–[83] Các giải pháp đề xuất thực chức phịng chống cơng khác nhau, quy mơ hệ thống mạng vị trí triển khai khác dựa cấu trúc nguyên lý hoạt động chung thể Hình 1.9 Hình 1.9 Cấu trúc chung hệ thống giải pháp phịng chống công DDoS dựa kỹ thuật SDN/Openflow Trong kiến trúc SDN/Openflow, giải pháp đề xuất phát triển gồm ứng dụng an ninh chạy máy chủ ứng dụng module điều khiển chạy Bộ điều khiển Giao tiếp phần mềm ứng dụng module điều khiển theo chuẩn REST API Trong trường hợp quy mô xử lý liệu nhỏ, phần mềm ứng dụng tích hợp module điều khiển: • Module điều khiển: Dựa nguyên tắc điều khiển hệ thống mạng xử lý gói tin, module điều khiển thực chức chính: (1) thống kê đặc tính lưu lượng, lấy mẫu gói tin để phân tích phát cơng, (2) cài đặt, chỉnh sửa mục luồng nhằm thực thi sách phịng chống cơng • Phần mềm ứng dụng: Dựa vào liệu thống kê, mẫu lưu lượng module điều khiển chuyển tới, phân tích phát cơng, xác định dấu hiệu lưu lượng cơng đưa sách xử lý lưu lượng công 20 Quá trình thu thập thơng tin lưu lượng, phát phân loại cơng, xác định sách xử lý gói tin áp đặt quy tắc xử lý tới mục luồng chuyển mạch tạo thành vịng điều khiển khép kín Trong chu trình ấy, trạng thái máy chủ, dịch vụ xác định Căn vào trạng thái máy chủ, dịch vụ cần bảo vệ thời điểm, hệ thống thực phân tích xử lý lưu lượng mạng đến theo thuật toán giải pháp tương ứng Tùy theo thuật toán phát hiện, phân loại lưu lượng công khác nhau, tham số lưu lượng sách xử lý gói tin giải pháp khác yêu cầu tính tốn mức độ xác, tính hiệu giải pháp khác 1.5.2 Các kỹ thuật phát công Điểm khác giải pháp phát công (1) nguồn thơng tin lưu lượng đầu vào (2) thuật tốn phát công Nguồn thông tin lưu lượng đầu vào Nguồn thông tin lưu lượng đầu vào sở quan trọng để xác định có cơng xảy hay không phân biệt lưu lượng cơng lưu lượng lành tính Xét khía cạnh phân tích thơng tin lưu lượng, có hai nhóm: sử dụng túy thông tin thống kê Openflow sử dụng kết hợp với phân tích lưu lượng truyền thống a) Sử dụng thông tin thống kê Openflow Lợi dụng chế, kỹ thuật SDN/Openflow, liệu thống kê từ mục luồng chuyển mạch sử dụng làm thông tin đầu vào để phát cơng Mặc dù có ưu điểm đơn giản, nhóm giải pháp cho độ xác phụ thuộc nhiều vào thuật tốn, truy vấn thơng tin lưu lượng giao diện Openflow tăng cao dẫn đến nghẽn mạng nên phù hợp với hệ thống mạng quy mô nhỏ b) Sử dụng thông tin thống kê Openflow kết hợp với phân tích lưu lượng Để tăng độ xác phát hiện, giải pháp thuộc nhóm bổ sung hệ thống mạng đầu dò (probe), thiết bị IDS, phân tích lưu lượng sFlow [21], Snort [25], [26] để phân tích cung cấp thơng tin thuộc tính lưu lượng cho phát hiện, phân loại công Ưu điểm giải pháp tăng cường độ xác phát làm cho hệ thống mạng cồng kềnh, phức tạp, phù hợp với hệ thống mạng quy mô lớn Thuật toán phát phân loại lưu lượng công Về bản, giải pháp phát công DDoS dựa kỹ thuật SDN/Openflow kế thừa nguyên lý thuật toán sử dụng giải pháp dựa cơng nghệ mạng truyền thống Các nhóm thuật toán phát bao gồm: a) Dựa vào Entropy Entropy đại lượng để đo mức độ ngẫu nhiên thuộc tính khoảng thời gian Nhóm nghiên cứu Mehdi [78] sử dụng phương pháp entropy cực ước lượng phân bố lưu lượng lành tính từ phát lưu lượng cơng từ mạng quy mơ nhỏ (văn 21 phịng, gia đình) góp phần ngăn chặn cơng DDoS nguồn Nhóm Wang [77] sử dụng tham số thống kê từ chuyển mạch biên mạng ISP tính entropy để đánh giá phân bố địa IP đích lưu lượng chuyển qua nó, từ phát cơng Nhóm Giotis [21] tính entropy để đo mức độ ngẫu nhiên địa IP nguồn đích Ưu điểm giải pháp u cầu tính tốn thấp Tuy nhiên, chủ yếu áp dụng cho mạng quy mô nhỏ, lưu lượng phát sinh nguồn [78], nơi có lưu lượng thấp áp dụng cho mạng trung gian [21], [77], nơi có phân bố địa IP lưu lượng lành tính thỏa mãn điều kiện phân bố ngẫu nhiên Đánh giá kiểm nghiệm cho thấy giải pháp có độ xác khơng cao phụ thuộc lớn vào đặc tính dịch vụ mạng cụ thể [60] b) Áp dụng thuật toán học máy Các thuật toán học máy mạng nơron, SVM, giải thuật di truyền, logic mờ, mạng Bayesian, định, nhiều giải pháp áp dụng để phát công DDoS Nhóm nghiên cứu Braga [22] đề xuất sử dụng đồ tự tổ chức SOM với tham số thuộc tính đầu vào trích xuất từ tham số thống kê mục luồng chuyển mạch Openflow Dotcenko [79] đề xuất giải pháp kết hợp đặt ngưỡng hạn chế thuật toán TRW Trong giải pháp NICE [23], nhóm nghiên cứu Chung xây dựng đồ thị cơng áp dụng mơ hình tương quan thực thể hệ thống mạng để phát cơng Nhóm Dillon đưa thuật tốn phát bất thường cách tính độ lệch chuẩn tỷ lệ số gói tin /dung lượng lấy thống kê theo chu kỳ thời gian Phát công DDoS dựa thuật tốn học máy có ưu điểm phát lưu lượng cơng có dấu hiệu khơng rõ ràng (nghi ngờ) Tuy nhiên, phương pháp địi hỏi phải có q trình học độ xác phụ thuộc nhiều vào liệu học c) Phân tích mẫu lưu lượng Phương pháp dựa giả thuyết cho lưu lượng công từ xác sống botnet điều khiển kẻ cơng thường có mẫu giống Do quan sát thấy tỷ lệ số lượng luồng có mẫu lưu lượng giống cao cơng DDoS diễn Nhóm nghiên cứu Shin [82] đề xuất tảng FRESCO phát công DDoS theo phương pháp Nhóm Jin Wang [80] đề xuất hệ thống phát dựa nhận diện hành động nghi ngờ phân tích lưu lượng thời gian thực Phương pháp phân tích mẫu lưu lượng có nhược điểm địi hỏi tính tốn lớn, phù hợp triển khai mạng truyền tải trung gian với tham số lưu lượng đơn giản, kết phân loại lưu lượng cơng có độ xác thấp [60] d) Dựa vào tỷ lệ kết nối Cơ sở giải pháp thuộc nhóm dựa giả thuyết cho xác suất kết nối thành cơng từ nguồn lành tính cao từ nguồn cơng Nhóm nghiên cứu Mehdi [78] đề xuất giải pháp giám sát lưu lượng kết nối internet từ mạng SOHO dựa trình bắt tay ba bước kết nối TCP áp dụng thuật toán TRW-CB Nếu tỷ lệ kết nối 22 không thành công từ trạm bên mạng cửa sổ thời gian cao giá trị ngưỡng thuật toán TRW-CB xác định trạm phân loại trạm nghi ngờ nhiễm phần mềm độc hại công DDoS Thuật toán TRW-CB áp dụng cho số giải pháp khác [24], [79], [82], [83] Một số giải pháp khác [80], [84] dựa giả thuyết quan sát phía máy chủ cho số yêu cầu kết nối trạm bị lây nhiễm phần mềm độc hại công DDoS thường cao so với trạm lành tính Trên sở đó, thống kê u cầu kết nối tới máy chủ, dịch vụ phát hiện, phân loại lưu lượng cơng DDoS phía mạng đích Nhóm giải pháp có ưu điểm tính toán đơn giản, dễ áp dụng, phù hợp với tất vị trí mạng triển khai (mạng nguồn, mạng trung gian mạng đích) Nhược điểm địi hỏi hệ thống sở liệu lưu trữ lớn, cơng giả mạo địa IP diễn độ nhạy thấp tỷ lệ báo động nhầm cao, chủ yếu áp dụng cho công dựa giao thức TCP 1.5.3 Các kỹ thuật ngăn chặn, giảm thiểu công Kỹ thuật SDN/Openflow xây dựng nhằm giải yêu cầu thay đổi nhanh mềm dẻo xử lý tập trung từ Bộ điều khiển Ngoài ra, chế giám sát điều khiển tập trung đảm bảo thống sách xử lý lưu lượng toàn hệ thống mạng mà cơng nghệ mạng truyền thống khơng có Sự thống đem lại hiệu khai thác ứng dụng ngăn chặn, giảm thiểu cơng nói chung cơng DDoS nói riêng [85] Khi phát cơng xảy ra, phần mềm ứng dụng phịng chống cơng u cầu điều khiển áp đặt sách xóa bỏ gói tin toàn hệ thống mạng theo điều kiện cụ thể cách cài đặt mục luồng chuyển mạch Cũng giống kỹ thuật phát cơng, có nhiều giải pháp ngăn chặn, giảm thiểu công dựa kỹ thuật SDN/Openflow đề xuất Xét chế thực hiện, giải pháp dựa vào khả cấu hình, cài đặt, chỉnh sửa mục luồng chuyển mạch Openflow để áp dụng sách lưu lượng nghi ngờ cơng trình bày Hình 1.9 Các kỹ thuật ngăn chặn giảm thiểu cơng cụ thể bao gồm: • Xóa bỏ gói tin: Khi phát cơng, Bộ điều khiển chỉnh sửa mục luồng xóa bỏ thiết lập action OUTPUT [21], [26], [81] Kỹ thuật có nhược điểm xóa bỏ nhầm gói tin lành tính • Giới hạn lưu lượng: Căn vào lực phục vụ máy chủ, sử dụng tính RATE LIMIT đo (meter) Openflow để thiết lập ngưỡng giới hạn lưu lượng [86] Cũng giống kỹ thuật Xóa bỏ gói tin, kỹ thuật xóa bỏ nhầm gói tin lành tính cơng xảy • Chặn cổng: Sử dụng thiết lập action Openflow mục luồng tương ứng để xóa bỏ tồn lưu lượng đến cổng dịch vụ cụ thể máy chủ trạng thái đóng giới hạn phục vụ [23], [25] Kỹ thuật bảo vệ máy chủ từ công quét cổng, công làm ngập băng thơng mạng Ngồi ra, kỹ thuật SDN/Openflow ứng dụng để hỗ trợ phát hiện, ngăn chặn 23 giảm thiểu công DDoS, bao gồm: • Chuyển hướng lưu lượng: Khi phát xác định dấu hiệu nghi ngờ công, lưu lượng cấu hình để chuyển đến máy khác để kiểm soát an ninh trước lưu chuyển máy chủ đích Ví dụ, sử dụng kỹ thuật CAPTCHA để xác thực người dùng [87], áp dụng kỹ thuật phân tích sâu gói tin để phát botnet [23], [25] • Phân tích nguy an ninh từ mục luồng: Thơng qua phân tích mục luồng chuyển mạch, giải pháp FlowChecker [88], FlowVisor [89], VeriFlow [90], thực phân tích, xây dựng topology mạng, đồ lưu chuyển gói tin để xác định nguy an ninh mạng có nguy cơng DDoS, từ xóa bỏ khơng cho phép cài đặt mục luồng tạo lỗ hổng cơng • Xác thực địa IP nguồn: Một vấn đề tồn cố hữu kỹ thuật mạng IP chưa có chế xác thực tính xác địa IP nguồn Điều gây nhiều vấn đề an ninh từ nạn lợi dụng công giả mạo địa IP có cơng DdoS TCP SYN Flood, ICMP Flood, Smurf, Dựa chế SDN, nhóm nghiên cứu Yao đề xuất chế xác thực địa IP nguồn giải pháp VAVE [91] • Phối hợp phịng chống cơng hệ tự trị: Cơ chế tự động hóa cấu hình hệ thống mạng nhờ giám sát, quản lý điều khiển mạng tập trung SDN/Openflow ứng dụng để trao đổi thông tin phối hợp ngăn chặn cơng DDoS Nhóm nghiên cứu Sufian Hassan [27] đề xuất giao thức trao đổi điều khiển (C-to-C communication protocol) cho phép hệ thống mạng liền kề phát triển SDN/Openflow gửi tin giúp xóa bỏ lưu lượng công tới nguồn phát sinh theo chế đẩy ngược (push-back) 1.6 Tấn công DDoS tới thành phần kiến trúc mạng SDN/Openflow giải pháp phòng chống 1.6.1 Tấn công DDoS tới thành phần kiến trúc mạng SDN/Openflow Kiến trúc mạng SDN/Openflow tách hệ thống mạng thành hai mặt phẳng với lớp: lớp hạ tầng, lớp điều khiển lớp ứng dụng quản trị mạng Bên cạnh lợi điểm ứng dụng phịng chống DDoS, mơ hình quản lý tập trung phân tách mặt phẳng, lớp SDN đồng thời mang lại nguy an ninh mạng nói chung nguy cơng DDoS nói riêng [32], [92]–[95] Với lớp, giao diện lớp chứa đựng nguy cơng mới: • Tấn cơng DDoS tới lớp ứng dụng: Khi ứng dụng bị công làm ảnh hưởng đến điều hành, hoạt động mạng có cơng DDoS Ví dụ, phần mềm bị nhiễm mã độc cài đặt sách chép, chuyển tiếp tất gói tin đến tới tất cổng gây DDoS tới toàn hệ thống • Tấn cơng DDoS tới lớp điều khiển: Tương tự lớp ứng dụng, công DDoS hướng đến lớp điều khiển gây lỗi chế chuyển tiếp gói tin, lập máy chủ 24 cách cài đặt mục luồng lỗi • Tấn công DDoS tới lớp hạ tầng mạng: Mục tiêu cơng lớp chủ yếu làm cạn kiệt tài nguyên chuyển mạch làm ngập bảng mục luồng và/hoặc làm cạn kiệt băng thông kênh điều khiển Openflow Mục tiêu cuối làm cho chuyển mạch xử lý lưu lượng đến Hình 1.10 Các phương pháp cơng tới lớp Hạ tầng mạng Hình 1.11 Các phương pháp cơng tới Lớp điều khiển Hình 1.12 Các phương pháp công tới Lớp Ứng dụng Khảo sát an ninh mạng kiến trúc SDN, Kreutz nhóm nghiên cứu [95] vectơ công có vectơ cơng DDoS, bao gồm: • Các luồng lưu lượng giả mạo: luồng hình thành từ gói tin tạo ra, chỉnh sửa, thay nhiều trường thông tin tiêu đề Các luồng sử dụng để công tới mặt phẳng điều khiển mặt phẳng liệu với mục tiêu 25 công bảng luồng tài nguyên điều khiển • Khai thác lỗ hổng chiếm quyền điều khiển chuyển mạch: Khi đó, kẻ cơng chiếm quyền điều khiển chuyển mạch sử dụng chúng để xóa bỏ, nhân bản, làm trễ chuyển tiếp gói tin hệ thống mạng tạo hàng loạt kiện packet-in để cơng điều khiển • Khai thác lỗ hổng chiếm quyền điều khiển điều khiển • Khai thác lỗ hổng chiếm quyền điều khiển ứng dụng điều hành mạng lớp ứng dụng: Khi kiểm soát điều khiển ứng dụng điều hành mạng, kẻ cơng thực điều khiển cách ly máy chủ, làm nghẽn mạng, chí vơ hiệu hóa điều khiển gây cơng DDoS tồn hệ thống mạng Trong vectơ công nêu trên, vectơ công tạo luồng giả mạo dễ thực xác định hình thức cơng phổ biến tới thành phần mạng SDN/Openflow [93], [94] Sơ đồ Hình 1.10, Hình 1.11, Hình 1.12 biểu diễn phương pháp công tới lớp hạ tầng mạng, lớp điều khiển lớp ứng dụng kiến trúc mạng SDN/Openflow [35] 1.6.2 Kỹ thuật phát giảm thiểu cơng Đã có nhiều giải pháp phát giảm thiểu công DDoS tới thành phần kiến trúc mạng SDN/Openflow [28], [35], [96]–[100] Phần lớn thuật toán phát giảm thiểu công giải pháp dựa thuật toán chế giống phát giảm thiểu công DDoS dựa công nghệ mạng truyền thống trình bày mục 1.5 Ngồi ra, số giải pháp đề xuất dựa thuật tốn phát theo sách quy tắc xử lý gói tin Nếu mục luồng phù hợp với sách, quy tắc xử lý này, lưu lượng chúng coi lành tính, ngược lại, lưu lượng cho xuất phát từ nguồn công áp dụng quy tắc xóa bỏ Bảng 1.2 [35] thống kê so sánh giải pháp phát giảm thiểu công DDoS kiến trúc SDN theo kỹ thuật Bảng 1.2 So sánh kỹ thuật phát giảm thiểu công DDoS tới kiến trúc mạng SDN/Openflow theo sách quy tắc xử lý gói tin Ảnh hưởng đến lớp Kỹ thuật giảm thiểu công Hạ tầng mạng AVANT- Sử dụng luật định nghĩa GUARD [28] trước để phát cơng TCP SYN Flood Ủy nhiệm gói tin SYN OFS kết hợp với kỹ thuật SYN Cookie Khơng Có Có DaMask [96] Dựa vào dấu hiệu công sở phân mảnh mạng Thiết lập action định nghĩa từ trước Có Có Có Xóa bỏ luồng Có Có Có OPERETTA Thiết lập sách xác thực [99] Khơng cần Khơng Có Có FlowRanger Sử dụng sách ưu tiên [97] để định giá trị tin cậy Xóa bỏ luồng Khơng Có Khơng Giải pháp SDN-based CDNi [98] Kỹ thuật phát Truy vết ngược sử dụng kỹ thuật đánh dấu Điều khiển Ứng dụng 26 SDSNM [100] Thiết lập sách xác thực phạm vi an toàn Quyết định module sách xử lý Có Có Có Trong số giải pháp trên, chế Di trú kết nối CM (Connection Migration) giải pháp Avant-Guard [28] giúp ngăn chặn hiệu công TCP SYN Flood Nguyên lý chế dựa giám sát trình bắt tay ba bước kết nối TCP từ máy khách Internet tới máy chủ cần bảo vệ Quá trình giám sát thực nhờ ủy nhiệm xử lý gói tin SYN chuyển mạch OFS, kết nối TCP hồn thành q trình bắt tay ba bước (3HS) tạo kiện packet-in gửi đến điều khiển để yêu cầu cài đặt mục luồng chuyển tiếp gói tin tới máy chủ nội hệ thống mạng Các bước thực kết nối máy khách máy chủ nội trình bày Hình 1.13 [28] Theo đó, q trình tạo kết nối TCP gồm pha: • Pha Phân loại: Gói tin SYN đến từ máy khách (bước 1) không gửi tới máy chủ mà xử lý module ủy nhiệm gói tin SYN chuyển mạch Nó trả lời máy chủ gói tin SYN-ACK (bước 2) với giá trị số hiệu khởi tạo phiên (Initial Sequence Number) tạo nhờ thuật toán SYN Cookie [51] Máy khách trả xác thực kết nối gói tin CliACK (bước 3) Nếu kết nối lành tính, gói tin CliACK có giá trị số hiệu xác thực ACK_Num phù hợp với số hiệu khởi tạo phiên SEQ_Num Module ủy nhiệm gói tin SYN sử dụng thuật toán SYN Cookie để kiểm tra phù hợp xác định kết nối lành tính, chuyển mạch khơng nhận gói tin CliACK tương ứng gói tin CliACK khơng hợp lệ, gói tin SYN cho công không xử lý bước Hình 1.13 Quá trình xử lý gói tin kết nối TCP chế CM • Pha báo cáo: Bộ chuyển mạch tạo kiện packet-in (bước 4) yêu cầu Bộ điều khiển cài đặt mục luồng xử lý kết nối TCP theo chiều từ máy khách tới máy chủ (bước 5) • Pha Di trú: Bộ chuyển mạch tạo gói tin SYN gửi tới máy chủ (bước 6) Sau nhận gói tin xác nhận từ máy chủ (bước 7), Bộ chuyển mạch tạo gói tin CliACK để xác thực kết nối (bước 8), đồng thời tạo kiện packet-in tới Bộ điều khiển yêu cầu cài đặt mục luồng xử lý kết nối theo chiều từ máy chủ tới máy khách (bước 9,10) 27 • Pha Chuyển tiếp: Sau có mục luồng xử lý gói tin theo hai chiều, máy chủ máy khách tiến hành trao đổi gói tin liệu (bước 11, 12) Với chế giám sát trình bắt tay ba bước trước cài đặt mục luồng chuyển mạch, chế CM Avant-Guard giúp cho Bộ chuyển mạch loại bỏ mục luồng vơ giá trị tạo gói tin SYN công giả mạo địa IP công TCP SYN Flood Đồng thời, chế ngăn không cho gói tin cơng SYN chuyển tới máy chủ nội cần bảo vệ bên hệ thống mạng Tuy nhiên, chế CM có nhược điểm sau: • CM sử dụng kỹ thuật SYN Cookie, vốn giải pháp sử dụng cho trạm cuối (host based) [51] chống lại công SYN flood, nên không phù hợp triển khai chuyển mạch thiết bị trung gian kết nối(network based) Bởi đó, kết nối lành tính bị chia cắt thành kết nối TCP (giữa OFS máy khách OFS máy chủ) Để liên kết hai kết nối TCP này, OFS phải trì vùng nhớ để lưu trữ trạng thái độ sai khác giá trị tham số kết nối (SEQ_Num/ACK_Num) Do cặp giá trị thay đổi, OFS phải tiêu tốn tài ngun cho tìm kiếm, mã hóa, kiểm tra, tính tốn checksum gói tin trao đổi máy chủ máy khách Điều ảnh hưởng đến hiệu xử lý OFS • Sự chia cắt kết nối TCP hai thực thể đầu cuối làm vơ hiệu hóa tham số tùy chọn khác kết nối TCP MSS, Selective ACKs, TCP Window Scaling,…[39] trình thực giám sát bắt tay ba bước • Q trình tạo gói tin SYN-ACK, xác thực gói tin CliACK kỹ thuật SYN Cookie địi hỏi tài ngun tính tốn bao gồm tạo gói tin, mã hóa giải mã cookies, tính tốn checksum,… Cơ chế CM thực tất gói tin SYN đến gói tin yêu cầu kết nối tới cổng bị đóng máy chủ Điều gây lãng phí tài ngun tính tốn OFS, làm cho OFS dễ trở thành mục tiêu công SYN flood công qt cổng Ngồi ra, việc tích hợp chế CM vào chuyển mạch làm chất SDN, triết lý SDN cố gắng chuyển phép tốn xử lý gói tin khỏi chuyển mạch 1.7 Kết luận chương Nội dung Chương trình bày lý thuyết tổng quan công DDoS, phương thức kỹ thuật phòng chống DDoS dựa công nghệ mạng truyền thống; kiến trúc kỹ thuật mạng cấu hình phần mềm SDN dựa giao thức Openflow Ngoài ra, nội dung chương khảo sát giải pháp đề xuất phát hiện, giảm thiểu công DDoS dựa kỹ thuật SDN/Openflow; công DDoS kiến trúc mạng giải pháp phịng chống Qua cho thấy: - Tấn cơng DDoS vấn nạn lớn mạng Internet; lợi dụng chế tự trị hệ thống mạng cấu thành Internet, kỹ thuật quản lý tài ngun cơng nghệ mạng truyền thống cịn nhiều điểm yếu, kẻ công phát động công DDoS nhằm suy giảm lực phục vụ hệ thống máy chủ, hệ thống mạng dựa hai kỹ thuật bản: giả mạo địa nguồn lưu lượng huy động tham gia công botnet Sự phát triển quy mô, dịch vụ, lưu lượng mạng ngày tăng; diễn biến công DDoS ngày phức tạp đặt 28 yêu cầu thách thức lớn chế, giải pháp phát hiện, phân loại lưu lượng giảm thiểu công DDoS - Sự phát triển công nghệ dịch vụ mạng, gia tăng thiết bị IoTs dẫn tới nhu cầu triển khai dịch vụ mạng quy mô nhỏ (SOHO network) ngày tăng An ninh mạng nói chung cơng DDoS nói riêng vấn đề lớn mạng quy mô nhỏ đặt nhu cầu giải pháp phịng chống cơng tương ứng đơn giản, phù hợp với chi phí thấp - Kiến trúc kỹ thuật mạng SDN đời giúp giám sát quản trị tài nguyên mạng tập trung, mềm dẻo mà cho phép triển khai nhiều ứng dụng an ninh mạng trực tuyến, thời gian thực có giải pháp phịng chống DDoS Giao thức Openflow giao thức cụ thể hóa kiến trúc mạng SDN Khả cung cấp liệu thống kê lưu lượng chế xử lý gói tin SDN/Openflow phù hợp với quy trình phát giảm thiểu cơng DDoS Đã có nhiều giải pháp đề xuất phát hiện, phân loại lưu lượng công DDoS dựa kỹ thuật SDN/Openflow Tuy nhiên, thời điểm tại, hầu hết giải pháp dừng lại nghiên cứu lý thuyết; tính chất phức tạp cơng DDoS, khơng có giải pháp mang lại hiệu triệt để Mỗi kiến trúc mạng, loại hình dịch vụ, quy mơ, kết cấu mạng cần có giải pháp, tham số bảo vệ khác - Mặt khác, kiến trúc SDN/Openflow đặt vấn đề an ninh mới, lỗ hổng cố hữu mà kẻ cơng lợi dụng, phát động công DDoS Nhiệm vụ đặt cần phải khai thác lợi SDN/Openflow phát hiện, phòng chống DDoS, đồng thời xây dựng giải pháp ngăn chặn hình thức, kỹ thuật cơng DDoS dựa kiến trúc, kỹ thuật Nội dung Chương sở lý thuyết quan trọng cho nghiên cứu, đề xuất chương luận án 29 CHƯƠNG ĐỀ XUẤT GIẢI PHÁP PHỊNG CHỐNG TẤN CƠNG DDOS DỰA TRÊN DỮ LIỆU THỐNG KÊ VÀ CƠ CHẾ XỬ LÝ GÓI TIN CỦA KỸ THUẬT SDN/OPENFLOW 2.1 Giới thiệu chương Nội dung Chương trình bày ba giải pháp đề xuất phòng chống DDoS túy dựa liệu thống kê lưu lượng chế xử lý gói tin kỹ thuật SDN/Openflow Mục tiêu giải pháp áp dụng trực tiếp cho hệ thống mạng quy mô nhỏ hỗ trợ SDN/Openflow phần mềm ứng dụng máy chủ ứng dụng SDN mà không cần bổ sung thêm thiết bị, module chuyên dụng Các giải pháp cụ thể bao gồm: - Giải pháp phát hiện, phân loại giảm thiểu công DDoS dựa tham số thống kê lưu lượng cung cấp kỹ thuật SDN/Openflow áp dụng mơ hình dự đốn làm trơn hàm mũ - Giải pháp phát giảm thiểu công SYN Flood bảo vệ hệ thống máy chủ nội dựa chế ủy nhiệm, giám sát q trình bắt tay ba bước gói tin SYN Bộ điều khiển mạng SDN/Openflow - Giải pháp đánh dấu gói tin chuyển mạch biên ISP nhằm phục vụ khả truy vết nguồn gốc phát sinh lưu lượng công trạm đích hệ thống mạng SDN/Openflow 2.2 Giải pháp phát giảm thiểu công DDoS dựa mô hình dự đốn làm trơn hàm mũ tham số thống kê lưu lượng 2.2.1 Đặt vấn đề Như trình bày chương 1, có nhiều giải pháp phát phân loại lưu lượng công DDoS dựa kỹ thuật SDN/Openflow, nhiên giải pháp tập trung vào mạng trung gian áp dụng cho mạng trung tâm liệu quy mô lớn, áp dụng thuật tốn học máy, địi hỏi liệu huấn luyện Điều dẫn đến độ nhạy phân loại suy giảm hệ thống chịu đựng mẫu cơng Điển hình số giải pháp giải pháp phát công dựa vào mơ hình SOM tham số thống kê lưu lượng từ chuyển mạch OFS nhóm tác giả Braga [22] Giải pháp lấy thống kê theo mục luồng TCP, UDP, ICMP với mục luồng gồm tham số lưu lượng Các tham số tính tốn áp dụng mơ hình SOM để phát phân loại lưu lượng công Nhược điểm giải pháp số lượng tham số truy vấn từ đếm mục luồng lớn gây trễ gia tăng lưu lượng giao diện Openflow Ngoài giải pháp đề cập đến việc phát phân loại lưu lượng cơng offline mà chưa có chế phân loại lưu lượng giảm thiểu công online Bổ sung khả phân loại giảm thiểu công, Nhóm tác giả Giotis đề xuất giải pháp thống kê lưu lượng theo cửa sổ thời gian [21] Theo đó, lưu lượng internet liên tục giám sát qua chu kỳ lấy thống kê lưu lượng giống đề xuất Braga Các tham số 30 lưu lượng thống kê áp dụng thuật toán đo độ biến thiên entropy thuộc tính (địa IP nguồn, đích địa cổng nguồn, đích) để phát cơng Khi có cơng xảy ra, hệ thống tiếp tục phân tích để phân loại luồng có độ biến thiên entropy bất thường lọc bỏ cách cài đặt mục luồng tương ứng với action xóa bỏ gói tin Nhược điểm giải pháp tương quan tỷ lệ báo động nhầm độ nhạy cao (FPR mức 32% DR đạt 95%) Hình 2.1 Kiến trúc hệ thống đề xuất cho giải pháp dựa phương pháp thống kê sử dụng giải thuật dự đoán làm trơn hàm mũ Chúng ta biết rằng, dịch vụ, máy chủ có đặc tính lưu lượng khác nhau, điều kiện hoạt động bình thường, đặc tính thống kê lưu lượng thường ổn định phạm vi thời gian (theo khung ngày) Khi có cơng xảy ra, đặc tính thống kê lưu lượng có khác biệt so với trạng thái bình thường khác biệt sử dụng làm dấu hiệu để phát công Dựa sở này, đồng thời khắc phục tồn hai giải pháp nêu trên, Luận án đề xuất phát giảm thiểu cơng dựa mơ hình dự đoán làm trơn hàm mũ tham số thống kê lưu lượng Giải pháp áp dụng cho mạng quy mô nhỏ, kết nối Internet qua gateway, nhằm ngăn chặn cơng DDoS từ bên ngồi 2.2.2 Kiến trúc hệ thống trạng thái hoạt động Giải pháp hoạt động dựa nguyên lý chung trình bày Hình 1.9, áp dụng cho mạng quy mơ nhỏ kết nối Internet qua gateway có kiến trúc Hình 2.1 Đối tượng bảo 31 vệ máy chủ dịch vụ chạy máy chủ bên mạng nội hệ thống Module Ủy nhiệm an ninh SP điều khiển thực truy vấn tham số thống kê lưu lượng từ Internet đến hệ thống mạng chuyển tới máy chủ an ninh qua giao diện REST API Khi phát xác định lưu lượng công, SP thực cài đặt sách chặn gói tin tới mục luồng chuyển mạch biên để giảm thiểu công Máy chủ an ninh SS phát công dựa mơ hình dự đốn tham số thống kê lưu lượng để xác định trạng thái công máy chủ/dịch vụ cần bảo vệ bên mạng nội Khi phát công xảy ra, SS chuyển yêu cầu lọc bỏ lưu lượng tới Điều khiển qua giao diện REST API Các trạng thái máy chủ/dịch vụ cần bảo vệ chuyển tiếp trạng thái thể sơ đồ Hình 2.2 Hệ thống giám sát trạng thái máy chủ, dịch vụ cần bảo vệ sau chu kỳ thời gian T Nếu không phát công xảy ra, máy chủ/dịch vụ tiếp tục trạng thái Giám sát Khi xác định có dấu hiệu cơng, máy chủ/dịch vụ chuyển sang trạng thái “Nghi ngờ bị công” thực lấy thống kê, chi tiết theo địa IP nguồn Sau lấy thống kê chi tiết, lưu lượng công phân loại lọc bỏ (Trạng thái “Lọc bỏ lưu lượng công”) Nếu không xác định lưu lượng công, máy chủ/dịch vụ lại chuyển trạng thái “Giám sát” Hình 2.2 Sơ đồ chuyển tiếp trạng thái hệ thống cho máy chủ/dịch vụ Để phân biệt lưu lượng máy chủ/dịch vụ cần bảo vệ, trường so khớp mục luồng xác định theo quy tắc: • Nếu đối tượng bảo vệ máy chủ, luồng xác định tham số: địa IP nguồn, địa IP đích số hiệu cổng nguồn • Nếu đối tượng bảo vệ dịch vụ chạy máy chủ, luồng xác định tham số: địa IP nguồn, địa IP đích, số hiệu cổng nguồn số hiệu cổng đích 32 2.2.3 Lựa chọn tham số số thống kê lưu lượng Các tham số thống kê lưu lượng Dựa đặc điểm lưu lượng công DDoS khả thống kê tham số lưu lượng theo chế SDN/Openflow, giải pháp lựa chọn tham số dùng cho phát cơng DDoS trình bày Bảng 2.1 Bảng 2.1 Các tham số thống kê sử dụng để phát phân loại lưu lượng công DDoS Tham số thống kê Ý nghĩa Số địa IP nguồn SAN - Chỉ số thực thể IP yêu cầu kết nối tới máy chủ/dịch vụ cửa sổ thời gian - Tùy theo đặc tính máy chủ/dịch vụ phạm vi cung cấp dịch vụ, tính chất dịch vụ, giá trị SAN máy chủ/dịch vụ khác Ngồi ra, giá trị cịn biến đổi theo khung ngày Phương pháp lấy thống kê - Đếm SS - Tăng đếm xuất địa IP nguồn tin packet-in - Khi trạng thái hoạt động bình thường, SAN nằm giới hạn phục vụ máy chủ Khi máy chủ/dịch vụ bị công DDoS, giá trị SAN thường tăng cao kẻ công huy động nhiều nguồn lưu lượng Số cổng nguồn SPN Số lượng gói tin PN - Chỉ tổng số luồng lớp kết nối tới máy chủ/dịch vụ - Đếm SS - Cũng giống SAN, tham số phụ thuộc vào tính chất, đặc điểm máy chủ/dịch vụ phạm vi cung cấp biến đổi theo khung - Khi trạng thái bị công DDoS, SPN tăng cao kẻ công cố gắng mở nhiều kết nối tới máy chủ/dịch vụ - Tăng đếm xuất cổng nguồn tin packet-in - Là số lượng gói tin trung bình luồng kết nối tới máy chủ, dịch vụ: + Khi phát cơng: tính theo giá trị trung bình máy chủ/dịch vụ - Thực Bộ điều khiển OFS + Khi phân loại lưu lượng cơng: tính theo giá trị trung bình địa IP nguồn - Gọi tin truy vấn thống kê OFPMP_FLOW _STATS - Theo đặc tính thống kê, số gói tin trung bình luồng dịch vụ cụ thể thường ổn định kẻ công biết giá trị tham số trung bình Khi cơng xảy ra, kẻ cơng thường phát động luồng có chế cơng (botnet) nên đặc tính lưu lượng đến thường giống khác so với đặc tính thống kê Sự khác biệt chọn làm dấu hiệu phát công Các số thống kê lưu lượng Từ tham số thống kê lưu lượng, sau cửa sổ thời gian T, giải pháp tính tốn số thống kê cho máy chủ/dịch vụ, là: • • Tỷ lệ số cổng trung bình mở địa IP nguồn SPA: 𝑆𝑆𝑆𝑆𝑆𝑆 = 𝑆𝑆𝑆𝑆𝑆𝑆 𝑆𝑆𝑆𝑆𝑆𝑆 Tỷ lệ số gói tin trung bình luồng PpF: (2.1) 33 Giá trị tỷ lệ số gói tin trung bình luồng tính sau: ∑SPN i=1 PN PpF = SPN SPN đó, ∑i=1 PN tổng số gói tin tổng số SPN luồng có (2.2) Khi phát công máy chủ/dịch vụ, PpF tính trung bình cho tất luồng u cầu kết nối tới máy chủ/dịch vụ Khi phân loại lưu lượng cơng, PpF tính trung bình cho địa IP nguồn 2.2.4 Lựa chọn xây dựng mơ hình dự đốn số thống kê lưu lượng Các mơ hình dự đốn phổ biến Như trình bày mục 2.1, cơng DDoS phát dựa chênh lệch số thống kê lưu lượng thực tế số dự đoán Chỉ số dự đoán dựa giả thiết lưu lượng lành tính Khi có cơng, số thống kê lưu lượng thực tế tăng cao so với số dự đoán sở để phát cơng Do đó, mức độ xác q trình tính tốn phát phụ thuộc vào mức độ xác mơ hình dự đốn Trong thực tế, có nhiều mơ hình dự đốn theo cửa sổ thời gian khác [101]–[105] Dưới số mô hình dự đốn phổ biến a) Mơ hình trung bình động Mơ hình trung bình động (MA) [101] dự đốn tham số thời điểm dựa trung bình cộng giá trị thời điểm liền kề trước Giá trị tham số dự đốn thời điểm xác định tương lại tính theo cơng thức: đó: 𝑥𝑥�𝑡𝑡+1 = ∗ (𝑥𝑥𝑡𝑡 + 𝑥𝑥𝑡𝑡−1 + ⋯ + 𝑥𝑥𝑡𝑡−𝑘𝑘+1 ) 𝑘𝑘 • k bề rộng cửa sổ, • 𝑥𝑥�𝑡𝑡+1 giá trị dự đốn thời điểm t+1, (2.3) • x i giá trị thực thời điểm thứ i Mô hình dự đốn trung bình động tính giá trị trung bình k giá trị liền trước k lớn cho kết xác Ưu điểm mơ hình tính tốn đơn giản Tuy nhiên địi hỏi lưu trữ sở liệu lớn để tính tốn giá trị dự đốn thời điểm cho mẫu tham số, đòi hỏi phải lưu trữ k tham số trước b) Mơ hình trung bình động có trọng số Mơ hình trung bình động có trọng số (WMA) [102], [104] tính tốn dự đốn dựa mơ hình WA với mẫu giá trị thời điểm trước tham gia vào giá trị dự đoán với trọng số w i khác Giá trị dự đoán giá trị mẫu thời điểm t+1 tính theo cơng thức: đó: 𝑥𝑥�𝑡𝑡+1 = ∗ (𝑤𝑤1 𝑥𝑥𝑡𝑡 + 𝑤𝑤2 𝑥𝑥𝑡𝑡−1 + ⋯ + 𝑤𝑤𝑘𝑘 𝑥𝑥𝑡𝑡−𝑘𝑘+1 ) ℎ (2.4) 34 • k bề rộng cửa sổ, • w i trọng số thành phần mẫu thứ i, • ℎ = 𝑤𝑤1 + 𝑤𝑤2 + … + 𝑤𝑤𝑘𝑘 Tùy theo đặc tính liệu, sở thống kê, trọng số w i lựa chọn để nâng cao độ xác giá trị dự đốn Bề rộng cửa sổ k lớn đặc tính thống kê cao cho kết dự đoán gần với thực tế Tuy nhiên, giống MA, mô hình WMA địi hỏi tài ngun lưu trữ giá trị mẫu lớn, khơng phù hợp với dự đốn cơng DDoS số lượng địa công tăng cao c) Mơ hình làm trơn hàm mũ Theo mơ hình dự đoán làm trơn hàm mũ (Exponential smoothing) [105], giá trị mẫu thời điểm t+1 dự đoán dựa giá trị thực giá trị dự đoán thời điểm t trước đó, giá trị gắn với trọng số dự đốn: đó: • • • 𝑥𝑥�𝑡𝑡+1 = 𝛼𝛼 𝑥𝑥𝑡𝑡 + (1 − 𝛼𝛼) 𝑥𝑥�𝑡𝑡 (2.5) 𝛼𝛼 hệ số làm trơn có giá trị nằm khoảng [0,1], 𝑥𝑥𝑡𝑡 giá trị thực mẫu thời điểm t, 𝑥𝑥� giá trị dự đoán mẫu thời điểm t Thực chất, phương pháp dự đốn bình qn đơn giản có trọng số tuân theo hàm mũ giảm dần khứ (1- 𝛼𝛼)k Việc lựa chọn hệ số 𝛼𝛼 quan trọng, phụ thuộc vào đặc tính cụ thể liệu Mơ hình dự đốn làm trơn số mũ khơng địi hỏi lưu trữ nhiều giá trị mẫu, tính tốn đơn giản dựa trạng thái hệ thống để đưa dự đoán thời điểm Tại thời điểm, hệ thống cần lưu trữ giá trị dự đốn mẫu gần Khi có liệu mẫu mới, giá trị dự đoán thời điểm tính thay cho giá trị lưu trữ cũ tiếp tục sử dụng cho tính tốn dự đốn thời điểm Xây dựng mơ hình dự đốn số thống kê lưu lượng Để giảm bớt số mẫu số lưu lượng cần lưu trữ mơ hình dự đốn, giải pháp phát phân loại lưu lượng công DDoS, mơ hình dự đốn làm trơn hàm mũ lựa chọn Như trình bày trên, hệ số 𝛼𝛼 phụ thuộc nhiều vào đặc tính lưu lượng cụ thể nên để đơn giản, phạm vi nghiên cứu, hệ số chọn với giá trị 𝛼𝛼 = 0.5 Khi giá trị dự đốn số thống kê lưu lượng tính sau: 𝑆𝑆𝑆𝑆𝑆𝑆𝐶𝐶𝐶𝐶𝐶𝐶 𝑡𝑡+1 = 𝑃𝑃𝑃𝑃𝑃𝑃𝐶𝐶𝐶𝐶𝐶𝐶 𝑡𝑡+1 = 𝑆𝑆𝑆𝑆𝑆𝑆 + 𝑆𝑆𝑆𝑆𝑆𝑆𝐶𝐶𝐶𝐶𝐶𝐶 𝑡𝑡 𝑃𝑃𝑃𝑃𝑃𝑃 + 𝑃𝑃𝑃𝑃𝑃𝑃𝐶𝐶𝐶𝐶𝐶𝐶 𝑡𝑡 (2.6) (2.7) SPA CUM PpF CUM giá trị dự đốn hay cịn gọi giá trị trung bình tích lũy, SPA PpF giá trị thực tính từ tham số thống kê thời điểm t 35 Nếu kết thuật tốn khơng phát cơng xảy ra, giá trị trung bình tích lũy tính trung bình cộng giá trị trung bình tích lũy cũ giá trị tức thời Ngược lại, có cơng xảy giá trị trung bình tích lũy cũ giữ nguyên Do đặc tính lưu lượng thường phụ thuộc vào khung ngày [106], để nâng cao tính xác, giá trị trung bình tích lũy lưu trữ tính tốn theo tham số 2.2.5 Phát giảm thiểu cơng Thuật tốn phát phân loại lưu lượng công Như trình bày trên, máy chủ, dịch vụ có đặc điểm thống kê riêng, để áp dụng chung cho máy chủ, dịch vụ hệ thống, số thống kê lưu lượng tính theo giá trị chuẩn hóa: 𝑆𝑆𝑆𝑆𝑆𝑆 − 𝑆𝑆𝑆𝑆𝑆𝑆𝐶𝐶𝐶𝐶𝐶𝐶 , 𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 = � 𝑆𝑆𝑆𝑆𝑆𝑆𝐶𝐶𝐶𝐶𝐶𝐶 0, 𝑃𝑃𝑃𝑃𝑃𝑃 − 𝑃𝑃𝑃𝑃𝑃𝑃𝐶𝐶𝐶𝐶𝐶𝐶 , 𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 = � 𝑃𝑃𝑃𝑃𝑃𝑃𝐶𝐶𝐶𝐶𝐶𝐶 0, 𝑆𝑆𝑆𝑆𝑆𝑆 ≥ 𝑆𝑆𝑆𝑆𝑆𝑆𝐶𝐶𝐶𝐶𝐶𝐶 (2.8) 𝑃𝑃𝑃𝑃𝑃𝑃 ≥ 𝑃𝑃𝑃𝑃𝑃𝑃𝐶𝐶𝐶𝐶𝐶𝐶 (2.9) 𝑆𝑆𝑆𝑆𝑆𝑆 < 𝑆𝑆𝑆𝑆𝑆𝑆𝐶𝐶𝐶𝐶𝐶𝐶 𝑃𝑃𝑃𝑃𝑃𝑃 < 𝑃𝑃𝑃𝑃𝑃𝑃𝐶𝐶𝐶𝐶𝐶𝐶 Hình 2.3 Mơ hình phát phân loại lưu lượng công Để xác định có cơng xảy hay khơng máy chủ/dịch vụ, phát công so sánh giá trị tức thời chuẩn hóa (DSPA DPpF) máy chủ/dịch vụ với giá trị ngưỡng phát 𝐾𝐾𝐷𝐷 Nếu hai giá trị tham số chuẩn hóa đạt vượt ngưỡng 𝐾𝐾𝐷𝐷 , hệ thống cho công xảy chuyển sang trạng thái “Nghi ngờ bị công” Nếu hai giá trị tham số chuẩn hóa nhỏ 𝐾𝐾𝐷𝐷 , hệ thống xác định khơng có cơng xảy tính tốn giá trị dự đốn SPA CUM , PpF CUM (được tính theo cơng thức 2.6, 2.7) lưu vào sở liệu để so sánh chu kỳ giám sát Hình 2.3 Tiến trình phát cơng cho máy chủ/dịch vụ trạng thái “Giám sát” mô tả Bảng 2.2 Bảng 2.2 Thuật toán phát công Giám sát (Máy_chủ/Dịch_vụ S) //Input: S: Địa IP máy chủ nội // Hoặc: Địa IP máy chủ nội bộ, số hiệu cổng dịch vụ cần bảo vệ máy chủ //Output: Chuyển S sang trạng thái Nghi ngờ bị công 36 // 10 11 12 Hoặc tính tốn lưu giá trị SPA CUM PpF CUM vào database Lấy tham số thống kê theo S Tính SPA, PpF cho S Lấy SPA CUM , PpF CUM S từ Database Tính DSPA, DPpF theo SPA, PpF SPA CUM , PpF CUM IF (DSPA >= K D OR DPpF >= K D ) THEN CALL Nghi ngờ bị công (S) ELSE SPA CUM = (SPA + SPA CUM )/2 PpF CUM = (PpF + PpF CUM )/2 Lưu SPA CUM , PpF CUM S vào Database CALL Giám sát (S) sau thời gian chu kỳ T ENDIF Khi máy chủ/dịch vụ xác định chuyển sang trạng thái “Nghi ngờ bị công”, hệ thống thực thống kê chi tiết địa IP nguồn có luồng gửi tới máy chủ/dịch vụ bao gồm (1) số cổng nguồn mở SP, (2) số gói tin trung bình luồng PN gửi từ địa IP nguồn tương ứng Các giá trị so sánh với giá trị trung bình tích lũy tương ứng theo hệ số lọc bỏ 𝐾𝐾𝐹𝐹 để xác định địa IP có nguồn lưu lượng công hay không 𝑆𝑆𝑃𝑃 ≥ 𝐾𝐾𝐹𝐹 (2.10) 𝑆𝑆𝑆𝑆𝑆𝑆𝐶𝐶𝐶𝐶𝐶𝐶 𝑃𝑃𝑃𝑃 ≥ 𝐾𝐾𝐹𝐹 (2.11) hoặc: 𝑃𝑃𝑃𝑃𝑃𝑃𝐶𝐶𝐶𝐶𝐶𝐶 lưu lượng xuất phát từ địa IP xét xác định lưu lượng công Hệ số lọc Nếu địa IP nguồn có: bỏ 𝐾𝐾𝐹𝐹 chọn tùy theo đặc điểm riêng máy chủ/dịch vụ đảm bảo độ nhạy DR cao giới hạn tỷ lệ báo động nhầm FPR mức thấp Tiến trình phân loại lưu lượng máy chủ/dịch vụ trạng thái “Nghi ngờ bị công” mô tả Bảng 2.3 Bảng 2.3 Thuật toán phân loại lưu lượng công Nghi ngờ bị công (Máy_chủ/Dịch_vụ S) //Input: S: Địa IP máy chủ nội // Hoặc: Địa IP máy chủ nội bộ, số hiệu cổng dịch vụ cần bảo vệ máy chủ //Output: Tập địa IP nguồn công AttackSrc[] Lấy tập hợp địa nguồn luồng kết nối Tới S: SrcAdds[n] DECLARE AttackSrc[] SET AttackSrc = Rỗng FOR EACH SrcAdd IN SrcAdds Lấy tham số thống kê theo SrcAdd Tính SP, PN theo SrcAdd IF (SP>=SPA CUM *K F OR PN>=PpF CUM *K F ) THEN Thêm phần tử SrcAdd vào AttackSrc ENDIF 37 10 11 12 13 14 15 ENDFOR IF AttackSrc Rỗng THEN CALL Lọc bỏ lưu lượng công (S, AttackSrc) ELSE CALL Giám sát (S) sau thời gian chu kỳ T ENDIF Lọc bỏ lưu lượng công Sau xử lý phân loại lưu lượng theo địa IP nguồn, phát nguồn công, hệ thống chuyển trạng thái máy chủ/dịch vụ tương ứng sang “Lọc bỏ lưu lượng cơng” Bản chất q trình yêu cầu Ủy nhiệm an ninh điều khiển gửi tin OFPT_FLOW_MOD tới chuyển mạch biên OFS để thay đổi sách xử lý gói tin từ dạng cho phép chuyển tiếp tới máy chủ (Forward) sang dạng hủy bỏ tồn gói tin (Drop) đến từ địa IP nguồn nghi ngờ Nếu không phát nguồn công nào, hệ thống quay trở trạng thái Giám sát Tiến trình lọc bỏ lưu lượng công mô tả Bảng 2.4 Bảng 2.4 Thuật toán Lọc bỏ lưu lượng công Lọc bỏ lưu lượng công (Máy_chủ/Dịch_vụ S, Tập_địa_chỉ_nguồn AttackSrc) //Input: S: Địa IP máy chủ nội // Hoặc: Địa IP máy chủ nội bộ, số hiệu cổng dịch vụ cần bảo vệ máy chủ // AttackSrc: Tập địa IP nguồn cơng //Output: Xóa bỏ gói tin đến từ nguồn công FOR EACH SrcAdd IN AttackSrc Tạo tin M loại OFPT_FLOW_MOD Đặt Match fields tin M: M Địa máy chủ/ dịch vụ: S M Địa nguồn: SrcAdd Đặt Output Action tin M: M Action = Drop packet Thực thi tin M tới OpenFlow switch ENDFOR 10 CALL Giám sát (S) sau thời gian chu kỳ T 2.2.6 Phân tích đánh giá hiệu giải pháp Phương pháp phân tích kịch công Hiệu giải pháp đánh giá thơng qua phân tích mơ liệu lành tính CAIDA 2013 [107] liệu CAIDA DDoS 2007 [108] Các gói tin từ lưu lượng đọc cơng cụ phân tích Scapy [109] lưu thơng tin thuộc tính vào hệ sở liệu phục vụ cho phân tích, thống kê Thời gian tồn luồng dựa tham số mặc định idle timeout hard timeout sản phẩm OFS thương mại tương ứng 10s 60s [110] Chu kỳ giám sát T chọn phút, giá trị thống kê tính từ luồng tồn đưa vào hệ thống phát công máy chủ bảo mật để phân tích đưa kết đầu 38 Bộ liệu CAIDA 2013 [107] liệu capture từ lưu lượng thực năm 2013 gateway trung tâm liệu trường đại học đặt San Jose, California, Mỹ với nhiều dịch vụ khác Lưu lượng kiểm định đảm bảo lưu lượng lành tính trước xóa bỏ hết phần nội dung gói tin đổi địa IP thực Bộ lưu lượng phục vụ cho mục đích nghiên cứu phù hợp với quy mô lưu lượng từ nhỏ đến lớn dựa vào kết hợp lưu lượng máy chủ liệu Trên thực tế CAIDA 2013 sử dụng cho nhiều cơng trình nghiên cứu đặc tính, kỹ thuật lưu lượng, an ninh mạng… Bộ liệu CAIDA DDoS 2007 [108] liệu capture từ lưu lượng công DDoS thực tế tới trung tâm liệu năm 2007 với quy mô lớn (về số lượng botnet tập hợp máy chủ nạn nhân) áp dụng nhiều kỹ thuật công khác Sau xác thực, lọc bỏ lưu lượng lành tính, xóa bỏ phần nội dung gói tin, đổi địa nguồn cơng thực, lưu lượng sử dụng rộng rãi, tin cậy ứng dụng phân tích thử nghiệm liên quan đến công DDoS - Từ liệu lành tính CAIDA 2013, lưu lượng 100 máy chủ lựa chọn ngẫu nhiên chạy dịch vụ khác (Web FTP) phân tích đánh dấu trạng thái không bị công với thời gian 45 phút - Bộ lưu lượng công CAIDA DDoS 2007 phân tích thời gian 45 phút Theo thống kê, phân tích từ lưu lượng này, 20 phút đầu, lưu lượng công cường độ thấp, 25 phút sau cường độ cao Trong số 100 máy chủ, máy chủ ngẫu nhiên chọn làm máy chủ bị công Server 1, số 99 máy chủ lại chọn làm máy chủ trạng thái không bị công Server Server Lưu lượng lành tính Server trộn với lưu lượng công DDoS phân tích so sánh với hai máy chủ cịn lại khoảng thời gian 90 phút Ở 45 phút đầu, máy chủ dịch vụ hoạt động trạng thái bình thường hệ thống trạng thái Giám sát Ở 45 phút tiếp theo, lưu lượng bình thường phát lặp lại kèm theo lưu lượng công Server Q trình thực mơ tính tốn chia làm giai đoạn: • Giai đoạn I: Khơng có cơng xảy (từ phút thứ 01 đến hết phút thứ 44) • Giai đoạn II: Có cơng cường độ thấp tới Server (từ phút 45 đến hết phút 64) • Giai đoạn III: Tấn công cường độ mạnh tới Server (từ phút 65 đến hết phút 89) Khả phát cơng Kết phân tích lưu lượng tính tốn số SPA, số chuẩn hóa DSPA máy chủ thể Hình 2.4 Từ kết thấy rằng: • Sự biến động giá trị SPA hai máy chủ không bị công (Server Server 3) nhỏ Và, giá trị chuẩn hóa DSPA chúng xấp xỉ • Trong với Server 1, SPA ổn định giai đoạn I tăng lên với mức độ biến động không lớn giai đoạn II (tấn công cường độ thấp) Tuy nhiên, chịu công cường độ cao giai đoạn III, SPA tăng đột biến với giá trị chuẩn hóa DSPA từ xấp xỉ 39 lên tới 160 Như biến động cho phép hệ thống phát công cường độ cao không phát giai đoạn công cường độ thấp b) a) Hình 2.4 Giá trị số SPA (a) DSPA (b) Giá trị thống kê số PpF số chuẩn hóa DPpF thể Hình 2.5 Kết cho thấy: • Tương tự SPA, PpF khơng có biến động nhiều máy chủ không bị công suốt thời gian mơ thử nghiệm Giá trị chuẩn hóa DPpF chúng khơng có biến động nhiều nhỏ 0,5 • Đối với máy chủ bị công Server 1, biến động PpF không đáng kể DPpF nhỏ 0,5 giai đoạn I Ở giai đoạn II, bị công cường độ thấp, PpF tăng mạnh từ 4,5 lên đến 18,0 DPpF theo tăng từ 0,5 lên 2,5 Ở giai đoạn III, giá trị PpF DPpF giảm xuống trì mức cao Với biến động vậy, ta chọn giá trị ngưỡng phù hợp (K D = 2) phát cơng cường độ thấp a) b) Hình 2.5 Giá trị số PpF DPpF Như vậy, cơng DDoS phát qua giám sát biến động hai số chuẩn hoá DSPA DPpF so sánh giá trị ngưỡng phát K D Trong trường hợp này, với K D = 2, công phát trường hợp công cường độ thấp công cường độ 40 cao Các giá trị thống kê điều kiện không bị cơng, máy chủ có đặc điểm cung cấp dịch vụ khác nên SPA, PpF chúng biến động khoảng giá khác Tuy nhiên, sau chuẩn hóa số DSPA, DPpF chúng hội tụ khoảng giá trị, thuận lợi cho so sánh để phát công Khả phân loại lưu lượng công Bảng 2.5 thể kết thống kê độ nhạy DR tỷ lệ báo động nhầm FPR pha phân loại lưu lượng công pha giảm thiểu (lọc bỏ) lưu lượng công với giá trị hệ số lọc bỏ khác K F = 6, 8, 10, , 26 theo tổng kích thước gói tin (bytes) Kết cho thấy với dải giá trị K F lựa chọn, giải pháp đề xuất có khả phân loại lưu lượng công với giá trị độ nhạy DR C mức cao, giữ ổn định 98,5% với tỷ lệ báo động giả thấp FPR C 0,65% Khi thay đổi giá trị K F khoảng lựa chọn DR C thay đổi khơng đáng kể trì mức cao Theo lý thuyết, nâng cao giá trị hệ số K F , tỷ lệ FPR C giảm, nhiên giá trị DR C giảm theo Đối với máy chủ có dịch vụ đặc thù tham số lưu lượng khác nhau, hệ số lọc bỏ K F chọn cho đảm bảo tỷ lệ FPR thấp trì giá trị DR mức cao Trong trường hợp này, lựa chọn K F =20-26, giá trị DR C FPR C trì mức ổn định DR C ≈ 98,7% FPR C ≈ 0,44% So sánh với giải pháp phát cơng mơ hình SOM tham số nhóm tác giả Braga [22] với giá trị DR C cao đạt 98,61 % với FPR C mức 0,59% cho thấy giải pháp sử dụng mơ hình dự đốn làm trơn hàm mũ cho tỷ lệ phân loại cao xác Khả giảm thiểu công Bảng 2.5 Độ nhạy tỷ lệ báo động nhầm phân loại lưu lượng giảm thiểu công 𝐊𝐊 𝐅𝐅 Phân loại lưu lượng Lọc bỏ lưu lượng DR C FPR C DR F FPR F 99,19 0,62 98,72 6,82 99,16 0,58 98,37 4,80 10 99,11 0,56 97,17 3,99 12 99,09 0,54 96,64 3,80 14 99,08 0,52 96,57 3,61 16 99,01 0,51 96,05 3,52 18 98,97 0,49 96,04 3,39 20 98,92 0,47 95,26 3,33 22 98,76 0,44 95,08 3,33 24 98,73 0,44 95,07 3,24 26 98,71 0,42 95,07 3,14 Kết lọc bỏ lưu lượng công thể Bảng 2.5 cho thấy giải pháp đề xuất có khả giảm thiểu công với độ nhạy lọc bỏ DR F cao, tỷ lệ lọc bỏ nhầm FPR F thấp DRF 41 trì mức 95% FPR F 7% Nếu chọn giá trị K F = 20–26, kết trì ổn định mức DR F ≈ 95,1% với FPR F ≈ 3,3% Giá trị cải thiện nhiều so sánh với giải pháp sử dụng mơ hình biến thiên entropy nhóm tác giả Giotis [21] đề xuất với kết DR F đạt 95% phải chịu tỷ lệ lọc bỏ nhầm FPR F mức 32% Nhận xét, đánh giá So sánh cấu trúc, nguyên lý, hiệu giải pháp đề xuất có phân tích lưu lượng tương đương, giải pháp phát giảm thiểu cơng dựa mơ hình dự đốn thống kê làm trơn hàm mũ có ưu điểm: • Cấu trúc hệ thống đơn giản, sử dụng túy liệu thống kê chế xử lý gói tin kỹ thuật SDN/Openflow • Địi hỏi số trường thơng tin cần truy vấn lưu trữ thấp (3 tham số/mục luồng) so với giải pháp sử dụng SOM tham số (sử dụng tham số/mục luồng) giải pháp mơ hình biến thiên entropy (4 tham số/mục luồng) • Thuật tốn đơn giản: Mỗi tham số cần tính tốn lưu trữ giá trị chu kỳ giám sát, hai giải pháp cịn lại cần phải tính tốn lưu trữ mảng giá trị để tính trung bình entropy • Cải thiện tương quan đặc tính độ nhạy tỷ lệ báo động giả pha phân loại pha giảm thiểu công Tuy nhiên, giải pháp tồn số nhược điểm: • Khi cơng DDoS giả địa nguồn xảy ra, số lượng địa nguồn tăng lên dẫn đến lượng truy vấn lấy tham số thống kê lớn, gây nguy nghẽn giao diện Openflow kết thúc chu kỳ giám sát Vì vậy, giải pháp phù hợp với hệ thống mạng quy mô nhỏ, lưu lượng thấp • Hiệu giải pháp cịn phụ thuộc vào hệ số α mơ hình dự đoán làm trơn hàm mũ, chu kỳ giám sát T Các tham số phụ thuộc vào quy mô, đặc tính liệu hệ thống mạng cụ thể 2.3 Giải pháp giảm thiểu công SYN Flood dựa chế ủy nhiệm gói tin SYN điều khiển 2.3.1 Đặt vấn đề Trong vectơ công DDoS, công SYN Flood kỹ thuật công lâu đời phương thức công phổ biến nguy hiểm Lợi dụng điểm yếu giao thức TCP trình bắt tay ba bước thiếu vắng chế kiểm soát địa IP nguồn hệ thống tự trị, kẻ cơng gửi hàng loạt gói tin SYN đến máy chủ mà khơng gửi gói tin xác nhận CliACK nhằm làm cạn kiệt tài nguyên kết nối mạng máy chủ Theo báo cáo Xu hướng công DDoS Verisign [5], hệ thống ghi nhận Quý 4, 2016 công SYN Flood đạt tốc độ 70Gbps với 50Mpps Báo cáo NexusGuard [6], công SYN Flood chiếm vị trí thứ tư sau cơng khuếch đại SSDP, UDP, ICMP số đợt công Báo cáo Kaspersky 42 Quý 2018 [111] cho thấy công SYN Flood tăng chiếm tới 57,3 % số công ghi nhận công ty Số liệu Quý [7] hãng cho thấy hình thức cơng gia tăng đáng kể chiếm tới 83,2 % số công Dựa cơng nghệ mạng truyền thống, có nhiều giải pháp phịng chống cơng SYN Flood đề xuất gồm giải pháp triển khai máy chủ (host based) SYN Cookie [51], SYN Cache [112], tăng TCP backlog [18],… giải pháp triển khai thiết bị an ninh hệ thống mạng (network based) SYN Proxy [18] Kỹ thuật SDN/Openflow đời nhanh chóng ứng dụng ngăn chặn cơng SYN Flood, điển hình chế CM giải pháp Avant-Guard [28] giải pháp cải tiến LineSwitch [29],… Tuy nhiên trình bày Chương 1, đặc tính cố hữu, nguy hiểm công TCP SYN Flood, chưa có giải pháp triệt để Với cấu hình mạng, đặc điểm dịch vụ đặc tính lưu lượng mạng cụ thể, người ta triển khai giải pháp phịng, chống cơng DDoS khác Nội dung phần trình bày vấn đề kỹ thuật giải pháp SSP (SDN based SYN Proxy) ứng dụng kỹ thuật xử lý gói tin SDN/Openflow phát giảm thiểu công SYN Flood chế ủy nhiệm xử lý gói tin SYN q trình bắt tay ba bước Bộ điều khiển Giải pháp xác định áp dụng cho mạng quy mô nhỏ SOHO văn phòng, quan nhỏ, trường học với số lượng máy chủ, lưu lượng truy cập không lớn mục tiêu chủ yếu ngăn chặn nguy cơng từ bên ngồi 2.3.2 Kiến trúc hệ thống đề xuất Dựa kiến trúc chung Hình 1.9 kiến trúc hệ thống SSP mơ tả Hình 2.6 Giải pháp áp dụng cho hệ thống mạng quy mô nhỏ SOHO kết nối với Internet qua gateway qua chuyển mạch biên Openflow Trên OFS, số hiệu cổng kết nối với Internet xác định rõ để phân biệt với cổng kết nối tới máy chủ dịch vụ bên mạng nội Lợi dụng khả so khớp với trường Flags quy định Openflow 1.5 [20], chuyển mạch OFS tổ chức mục luồng để Giám sát trình bắt tay ba bước (3HS) yêu cầu kết nối SYN từ máy khách Internet Khi trình bắt tay ba bước thực thành công, Kết hợp luồng TCP cho kết nối thực trực tiếp máy khách máy chủ nội Các trình điều khiển module SPM chạy Bộ điều khiển Với gói tin yêu cầu kết nối SYN đến từ Internet, SPM cài đặt mục luồng OFS để giám sát trình bắt tay ba bước, đồng thời Giám sát luồng cách đưa thông tin vào bảng FMT Dựa kết giám sát trình bắt tay ba bước, SPM thực Chính sách xử lý tương ứng Nếu q trình 3HS thành cơng, SPM cấu hình OFS để thực Kết hợp mục luồng TCP Ngược lại, SPM thực hủy mục luồng kết nối TCP dang dở máy chủ Chi tiết hoạt động giải pháp trình bày phần 43 Hình 2.6 Kiến trúc hệ thống giải pháp Ủy nhiệm gói tin SYN Bộ điều khiển SSP 2.3.3 Lựa chọn mơ hình ủy nhiệm gói tin SYN Ủy nhiệm gói tin SYN (SYN proxy) giải pháp phịng chống cơng TCP SYN DoS/DDoS [18] thiết bị trung gian đặt hai thực thể đầu cuối kết nối TCP làm nhiệm vụ giám sát trình 3HS Nếu q trình thành cơng, kết nối trì hai thực thể để trao đổi liệu Ngược lại, SYN proxy ngăn cản việc thiết lập kết nối hủy kết nối dang dở mở tạo máy chủ đích để giải phóng tài nguyên Có loại SYN proxy: giả gói tin SYN-ACK giả gói tin ACK Hình 2.7 mơ tả chi tiết trình xử lý kết nối TCP hai thực thể máy chủ (Server) máy khách (Client) hai loại SYN proxy hai trường hợp gói tin yêu cầu kết nối SYN đến lành tính cơng - Proxy giả gói tin SYN-ACK: Proxy đóng giả vai trị trạm đích (Server) để đảm bảo chắn kết nối từ trạm có thật, khơng giả mạo địa IP tạo kết nối thực với trạm đích Khi trao đổi liệu, proxy đứng thực chuyển đổi gói tin trạm nguồn (Client) trạm đích, cụ thể chuyển đổi cặp giá trị SEQ_Num ACK_Num gói tin theo hai chiều Ưu điểm proxy loại gói tin cơng giả mạo địa IP khơng bị gửi tới Server Server bảo vệ hồn tồn Tuy nhiên, có nhược điểm proxy phải xử lý nhiều kết nối TCP bị chia cắt số chức giao thức TCP bị vơ hiệu hóa q trình khởi tạo phiên kết nối - Proxy giả gói tin ACK: Khác với loại trên, proxy loại chuyển gói tin SYN đến trạm đích bình thường giám sát trình bắt tay ba bước Nếu khoảng thời gian chờ xác định trước, proxy khơng nhận gói tin CliACK tương ứng xác nhận, cho gói tin SYN cơng đóng giả trạm nguồn, tạo gói tin CliACK giả tương ứng gửi tới trạm đích để xác nhận kết nối đồng thời sau đó, tạo gói tin RST giả mạo để reset kết nối, giải phóng tài nguyên cho trạm đích Ưu điểm loại proxy 44 khơng can thiệp vào q trình trao đổi gói tin trạm nguồn trạm đích Tuy nhiên, nhược điểm gói tin cơng tiếp cận tới trạm đích, proxy đóng vai trị giảm thiểu ảnh hưởng mà thơi Hình 2.7 Ngun lý hoạt động hai loại SYN proxy Do thực ủy nhiệm Bộ điều khiển, giải pháp SSP lựa chọn mô hình ủy nhiệm gói tin SYN loại proxy giả gói tin ACK để giảm bớt xử lý Bộ điều khiển, đồng thời giảm lưu lượng trao đổi gói tin giao diện Openflow 2.3.4 Hoạt động hệ thống SSP Cơ sở khoa học giải pháp SSP dựa chế xử lý gói tin Openflow khả so khớp với trường Flags gói tin TCP, hệ thống thực giám sát trình bắt tay ba bước Bộ điều khiển Khi kết nối TCP hồn thành q trình bắt tay ba bước, kết nối gộp chung luồng; ngược lại thời gian giám sát cho trước, kết nối dang dở máy chủ chủ động xóa bỏ, giảm ảnh hưởng cơng SYN flood máy chủ Do thời gian thực trình bắt tay ba bước nhỏ so với thời gian tồn mục luồng, đồng thời SSP thực điều chỉnh thời gian chờ theo số kết nối dang dở máy chủ nên giảm thiểu chiếm dụng tài nguyên chuyển mạch Quá trình xử lý gói tin SYN cho kết nối TCP hệ thống SSP mơ tả Hình 2.8 • Khi nhận gói tin SYN đến, OFS capture gói tin SYN (Bước 1) chuyển tới Máy chủ đích (Bước 2) Khi công cường độ cao, số lượng gói tin SYN đến vượt khả xử lý hệ thống, gói tin SYN bị xóa bỏ 45 • Bộ chuyển mạch capture gói tin SYN-ACK trả lời từ phía máy chủ (Bước 3), gửi gói tin tới máy khách (Bước 4), đồng thời tới SPM Bộ điều khiển (Bước 4’) • SPM cài đặt mục luồng để capture gói tin CliACK tương ứng (Bước 5) • Khi máy khách gửi gói tin xác nhận CliACK (Bước 6), capture OFS gửi tới SPM (Bước 7) Hình 2.8 Quá trình xử lý yêu cầu kết nối gói tin SYN giải pháp SSP • SPM kiểm tra, xác thực gói tin CliACK (thơng qua cặp giá trị SEQ_Num ACK_Num gói tin SYN, SYN-ACK CliACK) định xử lý gói tin SYN (Bước 8): Nếu trình bắt tay ba bước hợp lệ, tiến hành gộp luồng, gói tin sau luồng trao đổi trực tiếp máy chủ máy khách (Bước 9) Nếu khơng có gói tin CliACK gói tin CliACK khơng hợp lệ, tiến hành xóa luồng SPM tạo gói tin CliACK giả, RST giả để kết thúc phiên kết nối (Bước 9) Capture xử lý gói tin bắt tay bước OFS Trong giải pháp SSP, OFS có nhiệm vụ bắt giữ gói tin bắt tay ba bước chuyển tới máy chủ đồng thời chuyển tới SPM Bộ điều khiển để giám sát trình Lưu đồ thuật tốn q trình capture gói tin bắt tay ba bước kết nối TCP mô tả Hình 2.9 Theo đó, OFS phải thực so khớp mục luồng để capture gói tin SYN (đến từ Client), SYN-ACK (đến từ Server), gói tin xác nhận CliACK Client có action xử lý tương ứng trình bày lưu đồ Để thực điều đó, SSP tổ chức mục luồng OFS: 46 • theo trật tự mức độ ưu tiên (priority) mục luồng thích hợp, • sử dụng khả so khớp với trường Flag quy định Openflow 1.5, • thiết lập loại mục luồng chủ động (proactive) đáp ứng (reactive) thích hợp Hình 2.9 Lưu đồ q trình capture xử lý gói tin bắt tay ba bước OFS Bảng 2.6 ví dụ cấu trúc, cách tổ chức, xếp bảng luồng, thiết lập thuộc tính mục luồng để thực capture gói tin bắt tay ba bước theo giải pháp SSP Hệ thống có cổng gateway kết nối Internet port_number = 1, cổng kết nối với máy chủ nội gồm port_number = 2,3,4 Mức độ ưu tiên bảng luồng thiết lập từ xuống • Flow Table 0: Gồm mục luồng loại chủ động, tồn vĩnh viễn để so khớp chọn gói SYN đến từ client (FE11, FE12, FE13), SYN-ACK đến từ server (FE2) , gói tin ACK đến từ client (FE3) Mục luồng FE4 hướng xử lý table-miss xảy bảng luồng Các mục luồng FE1x, FE2, FE3 sử dụng trường so khớp Flags để capture loại gói tin tương ứng • Flow Table 1: Bao gồm mục luồng FE5x cài đặt SPM cho kết nối TCP để so khớp capture gói CliACK xác nhận từ client hồn thành trình bắt tay bước Action tương ứng mục luồng Chuyển tới Bộ điều khiển Mỗi mục luồng thiết lập thời gian timeout thời gian chờ gói tin CliACK Nếu vượt q thời gian mà client khơng gửi gói tin CliACK xác nhận, mục luồng bị xóa 47 báo tới SPM Mục luồng FE6 hướng xử lý table-miss • Flow Table 2: Gồm mục luồng loại chủ động thiết lập hướng xử lý gói tin trao đổi liệu client server sau xác thực trình bắt tay ba bước Bảng 2.6 Ví dụ cấu trúc xếp mục luồng bảng luồng SSP Quản lý giám sát trình bắt tay ba bước Module SPM Module SPM lập trình ứng dụng bảo mật tích hợp trực tiếp điều khiển thực thi độc lập máy chủ bảo mật để giám sát trình bắt tay ba bước xử lý gói tin xác định có cơng xảy Quy trình xử lý giám sát trình bắt tay ba bước kết nối TCP SPM thể lưu đồ Hình 2.10 Các thơng tin giám sát quản lý bảng FMT có cấu trúc Bảng 2.7 • Tại kiện packet-in, gói tin đến SYN-ACK từ máy chủ cần bảo vệ, SPM tạo mục luồng capture gói tin CliACK, tính giá trị thời gian chờ tối đa t (sẽ trình bày 48 mục 2.3.4.3) thiết lập giá trị thời gian cho tham số idle timeout mục luồng Đồng thời SPM tạo mục thông tin bảng FMT để quản lý kết nối dang dở (HOC) với thơng tin thuộc tính tương ứng lưu trữ giá trị SEQ_Num Hình 2.10 Lưu đồ hoạt động mô đun SPM điều khiển Bảng 2.7 Cấu trúc bảng giám sát luồng FMT FlowID … srcIP IPs IPs IPs … srcPort Ps Ps Ps … dstIP IPd IPd IPd … dstPort Pd Pd Pd … SEQ_Num Seq Seq Seq … • Nếu gói tin đến gói tin ACK, SPM tìm mục thơng tin tương ứng bảng FMT so sánh giá trị số hiệu ACK_Num với giá trị lưu trữ SEQ_Num mục thông tin Nếu cặp giá trị khớp nhau, trình bắt tay ba bước xác thực thành công gói tin chuyển tiếp tới máy chủ đích Nếu khơng tìm thấy mục thơng tin tương ứng cặp giá trị ACK_Num SEQ_Num không khớp nhau, SPM xác định gói tin SYN đến từ nguồn khơng tin cậy, gói tin mục thơng tin tương ứng bị hủy 49 • Khi hết thời gian chờ timeout, khơng nhận gói tin CliACK tương ứng, SPM tạo gói tin ACK giả phía client để gửi tới máy chủ để kết thúc trình bắt tay ba bước sau đó, gửi gói tin RST để đóng kết nối mở HOC tương ứng máy chủ Tính tốn thời gian chờ gói CliACK luồng Theo giao thức TCP, sau nhận gói tin SYN, máy chủ tạo vùng nhớ TCB để chứa thông tin kết nối trước gửi gói tin SYN-ACK tới máy khách Vùng nhớ tồn suốt thời gian chờ TIMEWAIT đợi gói tin xác nhận CliACK từ phía máy khách Thời gian chờ kẻ công lợi dụng để trì chiếm đoạt tài nguyên nhớ TCB kết nối dang dở HOC máy chủ Tùy theo hệ điều hành, thời gian thường đặt cố định có giá trị từ 75s đến 189s [113] Để khảo sát khoảng thời gian nhận gói tin SYN gói tin CliACK lưu lượng mạng thực tế, lưu lượng lành tính CAIDA 2013 [107] phân tích cho kết thống kê CDF Hình 2.11 Kết thống kê cho thấy, gần 99% kết nối TCP lưu lượng mạng thực tế có gói tin CliACK đến sau gói tin SYN vịng 2s Do thiết lập thời gian chờ lớn không cần thiết Giá trị thời gian chờ cao đảm bảo cho kết nối thành cơng độ trễ gói tin đường truyền lớn, nhiên điều tạo hội cho chiếm dụng tài ngun vơ ích máy chủ, công SYN Flood xảy Để cân hai yếu tố này, giải pháp SSP đưa chế điều chỉnh thời gian chờ theo số lượng kết nối đến máy chủ theo công thức: đó: 𝑡𝑡 = � 𝑇𝑇1 , 𝑇𝑇2 + (𝑇𝑇1 − 𝑛𝑛−𝑁𝑁 𝑇𝑇2 )𝑒𝑒 −𝑘𝑘 𝑁𝑁 , 𝑛𝑛 ≤ 𝑁𝑁 𝑛𝑛 > 𝑁𝑁 (2.12) • n số lượng kết nối TCP dang dở tồn tới máy chủ đích, • N số kết nối TCP mở trung bình mà máy chủ phải xử lý điều kiện bình thường Trên thực tế giá trị N phụ thuộc vào đặc điểm, tính chất dịch vụ máy chủ, • 𝑇𝑇1 thời gian chờ lớn nhất, • • 𝑇𝑇2 thời gian chờ nhỏ nhất, k hệ số hiệu chỉnh Biểu đồ Hình 2.12 mô tả thay đổi thời gian chờ t theo số lượng yêu cầu kết nối tới máy chủ n Nếu số lượng yêu cầu kết nối n nhỏ ngưỡng N, giá trị t chọn 𝑇𝑇1 – thường chọn giá trị TIME_WAIT sử dụng máy chủ Nếu n vượt N, SPM điều chỉnh giảm giá trị t tương ứng với phần vượt n so với N Khi đạt đến giá trị thời gian chờ t, chưa hết thời gian TIME_WAIT, SPM chủ động gửi gói tin CliACK giả để hồn tất q trình bắt tay ba bước máy chủ sau gửi gói tin RST để kết thúc kết nối Nhờ đó, số lượng kết nối dang dở HOC máy chủ giảm xuống, tài nguyên nhớ giải phóng, phục vụ cho yêu cầu kết nối 50 Hình 2.11 Thống kê CDF khoảng thời gian gói tin SYN gói tin CliACK lưu lượng mạng thực tế Hình 2.12 Hiệu chỉnh thời gian chờ luồng Điều chỉnh thời gian chờ đồng thời giảm chiếm dụng tài ngun vơ ích OFS mục luồng tạo tương ứng với gói tin SYN công Các mục luồng tạo mà khơng có gói tin khớp, tồn hết thời gian chờ Khi công xảy ra, số lượng mục luồng vơ ích tăng lên nhanh chóng làm cạn kiệt khơng gian nhớ TCAM chuyển mạch Thiết lập ngưỡng thay đổi sách xử lý gói tin SYN OFS Năng lực xử lý chuyển mạch phụ thuộc nhiều vào cấu hình phần cứng Năng lực hữu hạn giới hạn điều kiện làm việc chuyển mạch Kẻ công DoS/DDoS thường cố gắng tạo lưu lượng vượt lực xử lý này, hệ thống khơng thể hoạt động khơng thể phục vụ kết nối bình thường khác Mỗi thiết bị thường có chế bảo vệ nhờ thiết lập ngưỡng hoạt động Giải pháp SPM sử dụng chế xử lý điều khiển tự động kỹ thuật SDN/Openflow để thiết lập ngưỡng hoạt động, bảo vệ chuyển mạch có cơng SYN Flood xảy SPM định nghĩa hai chế độ hoạt động chuyển mạch: - Chấp nhận xử lý gói tin SYN (Activated): Tất gói tin SYN đến xử lý bình thường theo quy trình mơ tả - Giới hạn xử lý gói tin SYN (Deactivated): Khi chế độ này, số ngẫu nhiên gói tin SYN theo xác suất p đặt trước xử lý Các gói tin khác bị hủy bỏ 51 Hình 2.13 Sơ đồ chuyển tiếp sách xử lý gói tin SYN chuyển mạch Sự chuyển tiếp trạng thái Activated Deactivated phụ thuộc vào số lượng kết nối dở dang n mà chuyển mạch xử lý hai ngưỡng M , M (M > M ): • M ngưỡng cao n Khi n vượt ngưỡng này, SSP chuyển sang chế độ Giới hạn xử lý gói tin SYN • M ngưỡng mức bình thường n Khi OFS làm việc chế độ Giới hạn xử lý gói tin SYN, n giảm xuống mức giá trị ngưỡng M , OFS chuyển chế độ Chấp nhận xử lý gói tin SYN, nghĩa tất gói tin SYN đến chuyển tiếp xử lý bình thường Giá trị M M xác định dựa điều kiện hoạt động bình thường chuyển mạch Sơ đồ chuyển tiếp hai trạng thái theo thay đổi giá trị n mơ tả Hình 2.13 2.3.5 Phân tích đánh giá hiệu giải pháp Mơ hình thử nghiệm testbed Hiệu giải pháp SSP kiểm nghiệm đánh giá qua mơ hình thử nghiệm Hình 2.14 Mơ hình có cấu trúc bao gồm: • Bộ điều khiển Floodlight [74] cài đặt máy tính chạy hệ điều hành Ubuntu version 14.04 với cấu hình: CPU Intel TM Core i3-2330M @ 2.2GHz, 500GB HDD, 4GB RAM • Bộ chuyển mạch OpenFlow xây dựng dựa NetGPGA [114] Card Xilinx VirtexTM-II pro 50 4x1 Gbps Ethernet; 4.5 MB SRAM 64 MB DDR2; FPGA Spartan II • Máy chủ cài đặt dịch vụ FTP cấu hình CPU Intel TM Core i3-2330M @ 2.2GHz, 500GB HDD, 4GB RAM Hệ điều hành Windows Server 2012 • Lưu lượng lành tính tạo từ phần mềm ứng dụng thực tạo 50 yêu cầu tải tệp tin tới máy chủ dịch vụ Lưu lượng công phát, biên tập công cụ BoNeSi [115] phát lại vào hệ thống TCPReplay [116] BoNeSi cấu hình với phương thức cơng SYN Flood, địa IP nguồn phát sinh ngẫu nhiên, tốc độ trường hợp giữ ổn định, tăng dần từ mức 100 pps đến vượt khả chịu tải hệ thống 52 Hình 2.14 Mơ hình testbed đánh giá hiệu giải pháp SSP Các tham số hệ thống kịch thử nghiệm để so sánh giải pháp: • Lưu lượng cơng phát với tốc độ khác từ 100 pps (gói/s) đến 1.000 pps mơ hình hệ thống khác • Bằng phương pháp thử tải hệ thống, giá trị M M chọn M = 7.500 M = 7.000, N = 500 • Căn kết thống kê biểu đồ Hình 2.11 giá trị thời gian TIME_WAIT hệ điều hành phổ biến [113], [117], giá trị T1, T2 chọn là: T1 = 15s, T2 = 2s, k = 1,5 Tỷ lệ kết nối thành công lưu lượng lành tính Mục tiêu cơng DDoS ngăn cản khơng cho lưu lượng lành tính kết nối tới máy chủ dịch vụ Một giải pháp chống công DDoS hiệu phải đảm bảo tỷ lệ kết nối thành cơng cao Trong mơ hình thử nghiệm, hai tham số đo tính tốn bao gồm: • Tỷ lệ kết nối thành cơng tính số u cầu tải tệp tin thực thành công tổng số yêu cầu phát tới máy chủ FTP • Thời gian kết nối trung bình tính khoảng thời gian từ client lành tính gửi gói tin SYN tới nhận gói tin liệu phiên kết nối từ máy chủ FTP Các tham số đo hai mơ hình SSP Openflow chuẩn với tốc độ công khác Ở mô hình Openflow chuẩn, tham số mục luồng xác định tham số: địa IP nguồn, địa IP đích, số hiệu cổng nguồn số hiệu cổng đích Với tốc độ cơng, lưu lượng công phát thời gian 100s Sau lưu lượng công phát 20s, lưu lượng lành tính phát với tốc độ 50 yêu cầu tải tệp tin/s Kích thước tệp tin máy chủ có dung lượng 2,16 MB Kết đo tham số thể biểu đồ Hình 2.15 Hình 2.16 53 Hình 2.15 Tỷ lệ kết nối thành công từ lưu lượng lành tính máy chủ chịu cơng DDoS với cường độ cơng khác Hình 2.16 Thời gian kết nối trung bình lưu lượng lành tính máy chủ chịu công với cường độ công khác Kết cho thấy: • Giải pháp SSP cải thiện đáng kể tỷ lệ kết nối thành công so với mơ hình Openflow chuẩn, đạt mức 85% tỷ lệ kết nối mơ hình Openflow chuẩn suy giảm xuống 5% tốc độ công 600pps Ở tốc độ công 700 pps, lưu lượng lành tính khơng thể kết nối tới máy chủ giải pháp Openflow, SSP trì tỷ lệ kết nối cao suy giảm xuống mức 58% tốc độ cơng 1.000 pps • Thời gian kết nối trung bình mơ hình Openflow chuẩn tăng mạnh lên đến 120ms tốc độ công 600pps giá trị tham số trì mức ổn định 10ms Tuy nhiên tốc độ công 100pps, thời gian kết nối trung bình giải pháp Openflow chuẩn thấp so với SSP chế kiểm sốt q trình bắt tay ba bước giải pháp 54 (a) (b) (c) Hình 2.17 Số kết nối mở máy chủ với cường độ công khác Số lượng kết nối dang dở máy chủ Mục tiêu công SYN Flood kẻ công tạo hàng loạt kết nối dang dở máy chủ nhằm làm cạn kiệt tài nguyên kết nối mạng máy chủ thực kết nối với lưu lượng lành tính Để đánh giá hiệu giải pháp, số lượng kết nối dang dở máy chủ thống kê với tần suất lần/s lệnh SYN-RECEIVED hai mơ hình: sử 55 dụng giải pháp SSP phát lưu lượng 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 thống kê số lượng kết nối dang dở máy chủ tốc độ công s = 100 pps, 200 pps 500 pps thể tương ứng Hình 2.17 a, b, c Kết cho thấy: • Ở giai đoạn đầu q trình phát lưu lượng cơng, số kết nối dang dở tăng nhanh Khi đạt đến ngưỡng cảnh báo, chế bảo vệ SYN Flood máy chủ Windows thực xóa bỏ kết nối TCP có thời gian chờ đạt mức 15s Với tốc độ cơng trì đều, số lượng kết nối dang dở ba trường hợp sau thời gian độ giữ ổn định mức xấp xỉ 1.500 HOC, 3.000 HOC 7.500 HOC tương ứng với tốc độ công 100 pps, 200 pps 500 pps • Ở giải pháp SSP, kết nối dang dở bị xóa bỏ dựa khơng thời gian tồn kết nối mà dựa vào số lượng kết nối dang dở tạo máy chủ Nhờ số lượng kết nối dang dở giữ ổn định ngưỡng cố định xung quanh 1.000 HOC mà khơng có biến động lớn giải pháp Windows Số lượng HOC giảm xấp xỉ 80% tốc độ công 500 pps Thời gian tồn mục luồng chuyển mạch Để đánh giá ảnh hưởng giải pháp tới hiệu hoạt động kiến trúc SDN/Openflow có chuyển mạch, so sánh SSP với chế CM giải pháp Avant-Guard trình bày mục 1.6.2, tham số thời gian tồn mục luồng thống kê, tính tốn so sánh • Đối với chế CM, chế ủy nhiệm gói tin SYN thực chuyển mạch, sau xác thực trình bắt tay ba bước, mục luồng tạo trì để thực trao đổi gói tin liệu, chuyển đổi cặp giá trị SEQ_Num/ACK_Num, nên thời gian tồn mục luồng kết nối TCP tính theo cơng thức: đó: 𝑇𝑇𝐹𝐹𝐹𝐹_𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙_𝐶𝐶𝐶𝐶 = 𝑇𝑇𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙 + 𝑇𝑇𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 − 𝑇𝑇ℎ𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎ℎ𝑎𝑎𝑎𝑎𝑎𝑎 (2.13) 𝑇𝑇𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙 thời gian tồn thực luồng tính khoảng thời gian xuất gói tin gói tin cuối luồng qua chuyển mạch 𝑇𝑇𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 thời gian chờ luồng 𝑇𝑇ℎ𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎ℎ𝑎𝑎𝑎𝑎𝑎𝑎 thời gian trình bắt tay bước cần diễn • Đối với giải pháp SSP, thời gian tồn mục luồng chuyển mạch kết nối TCP (mục luồng FE5x Bảng 2.7) tính từ OFS nhận gói tin SYN-ACK từ máy chủ đến gói tin xác nhận CliACK từ máy khách xuất Khoảng thời gian xấp xỉ khoảng thời gian bắt tay ba bước luồng: 𝑇𝑇𝐹𝐹𝐹𝐹_𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙_𝑆𝑆𝑆𝑆𝑆𝑆 = 𝑇𝑇ℎ𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎ℎ𝑎𝑎𝑎𝑎𝑎𝑎 (2.14) 56 Để đánh giá so sánh thời gian chiếm dụng mục luồng xử lý kết nối TCP hai giải pháp trên, liệu CAIDA 2013 [107] phân tích thống kê Các tham số tập liệu phân tích kết phân tích trình bày Bảng 2.8 Bảng 2.8 Tham số kết phân tích lưu lượng lành tính từ 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 phân tích 45 phút Số luồng 3.947.883 luồng Thời gian tồn trung bình luồng 𝑇𝑇𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙 18,26 s Thời gian bắt tay bước trung bình 𝑇𝑇ℎ𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎ℎ𝑎𝑎𝑎𝑎𝑎𝑎 0,93 s Với kết phân tích Bảng 2.8, thời gian tồn trung bình mục luồng kết nối TCP lành tính OFS áp dụng chế CM giải pháp Avant-Guard là: T FE_life_CM = 18,26 – 0,93 = 17,33 (s) Đối với giải pháp SSP: T FE_life_SSP = T handshake = 0,93 (s) Do so với chế CM, SSP giảm (17,33-0,93)/17,33 = 94% thời gian tồn trung bình mục luồng chuyển mạch Khi thời gian mục luồng chiếm dụng tài nguyên chuyển mạch giảm xuống làm giảm tổng số lượng mục luồng thời điểm, giúp cho tốc độ so khớp, xử lý actions chuyển mạch nhanh hơn, tăng khả chịu tải công DDoS xảy Ảnh hưởng lên điều khiển xảy công Để đánh giá ảnh hưởng giải pháp đề xuất đến Bộ điều khiển, trình thực kịch cơng, lượng tài ngun sử dụng Bộ điều khiển đo thống kê tốc độ công khác cơng cụ htop Linux [117] Hình 2.18 Kết đo thống kê chiếm dụng CPU chiếm dụng nhớ thực hai trường hợp SSP có khơng thiết lập ngưỡng Chính sách xử lý gói tin thể Hình 2.19 Hình 2.20 Kết cho thấy: • Ở hai trường hợp (thiết lập ngưỡng không thiết lập ngưỡng) tỷ lệ chiếm dụng CPU Bộ điều khiển khoảng 20% chưa xảy công Và cường độ công SYN Flood tăng dần, tỷ lệ chiếm dụng CPU tăng đạt 68% tốc độ 1.000 pps trường hợp không thiết lập ngưỡng Trong đó, tỷ lệ tăng chậm ổn định mức gần 50% cường độ công 800 - 1.000 pps trường hợp thiết lập ngưỡng • Mức độ chiếm dụng dung lượng nhớ giữ ổn định mức xấp xỉ 2GB trường hợp không thay đổi tốc độ cơng Tóm lại, thiết lập ngưỡng sách xử lý gói tin, giải pháp SSP không làm ảnh hưởng nhiều đến chiếm dụng tài nguyên Bộ điều khiển chịu công SYN Flood 57 Hình 2.18 Giao diện hình đo chiếm dụng tài nguyên Bộ điều khiển tốc độ cơng 700 pps Hình 2.19 Tỷ lệ chiếm dụng CPU điều khiển cường độ cơng khác Hình 2.20 Dung lượng nhớ bị chiếm dụng điều khiển cường độ công khác 58 Nhận xét, đánh giá Kết phân tích chạy mơ hình thử nghiệm giải pháp SSP cho thấy: • Khai thác chế xử lý gói tin kỹ thuật SDN/Openflow, SSP kết hợp khả tổ chức mục luồng OFS xử lý Bộ điều khiển để capture gói tin liên quan, giám sát xử lý trình bắt tay ba bước hoạt động ủy nhiệm gói tin SYN Bộ điều khiển • Cơ chế ủy nhiệm gói tin SYN điều khiển SSP giúp giảm đáng kể số lượng kết nối dang dở máy chủ (xấp xỉ 80% tốc độ cơng 500 pps), qua làm tăng khả chịu đựng công SYN Flood máy chủ, tăng tỷ lệ kết nối thành công lưu lượng lành tính (duy trì mức 87% Openflow suy giảm xuống mức 5% tốc độ cơng 600 pps) • SSP cịn giúp giảm đáng kể (lên tới 94%) thời gian tồn mục luồng lưu lượng lành tính so với chế CM giải pháp Avant-Guard Khi có cơng SYN Flood xảy ra, SSP không làm ảnh hưởng nhiều tới chiếm dụng tài nguyên CPU nhớ Bộ chuyển mạch, Bộ điều khiển 2.4 Giải pháp đánh dấu gói tin PLA DFM phục vụ truy vết nguồn cơng 2.4.1 Đặt vấn đề Mạng Internet hình thành dựa hợp thành hệ thống tự trị, gói tin lưu chuyển hệ thống khơng có chế kiểm sốt lưu giữ trạng thái dẫn đến kẻ công dễ dàng giả mạo địa IP nguồn thực công mạng nói chung cơng DDoS nói riêng Từ phía nạn nhân, khó biết xác nguồn cơng dựa vào gói tin đơn Chính vậy, kỹ thuật truy vết nguồn cơng (cịn gọi traceback) hình thành có nhiều giải pháp đề xuất [118]–[122], [50], [123] cho phép từ phía nạn nhân, tái tạo lại đường gói tin cụ thể biết địa vị trí mà gói tin phát địa IP nguồn chứa gói bị giả mạo hay không Traceback giải pháp phát công hay chống công trực tuyến, thời gian thực, kỹ thuật hỗ trợ để biết nguồn thực gói tin đáng ngờ lúc bị cơng sau bị cơng Kỹ thuật traceback phân thành loại chính: Kiểm tra liên kết (Link testing), Dò đường tin (Messages), Lưu giữ thơng tin (Logging), Đánh dấu gói tin (Packet Marking) Giải pháp kết hợp (Hybrid Schemes) Đã có nhiều giải pháp traceback đề xuất áp dụng dựa công nghệ mạng truyền thống Tuy nhiên, cần phải có phối hợp, huy động thực nhiều hệ thống mạng tự trị, giải pháp traceback chưa có thống chung hiệu chưa cao Trong bối cảnh SDN/Openflow hướng đến hệ thống mạng chia sẻ, cộng tác môi trường tài nguyên sách quản trị ln biến động, xu phối hợp mục tiêu tăng hiệu khai thác tài nguyên, quản trị tất yếu Vì vậy, luận án đề xuất giải pháp đánh dấu gói tin phục vụ truy vết dựa phân loại nhận dạng 59 lưu lượng theo luồng kỹ thuật SDN/Openflow có xét đến thích ứng với chiều dài gói tin luồng nhằm tăng hiệu đánh dấu (gọi tắt PLA DFM) Nội dung phần trình bày chi tiết sở kỹ thuật, cấu trúc hệ thống đánh giá hiệu giải pháp PLA DFM 2.4.2 Khái niệm đánh dấu gói tin kỹ thuật Kỹ thuật trace back đánh dấu gói tin Trong kỹ thuật traceback đánh dấu gói tin, thơng tin đánh dấu số tất định tuyến đường lưu lượng gửi tới trạm đích Thơng tin đánh dấu thường địa IP định tuyến, trạm đích sử dụng thông tin để truy vết, dựng lại đường gói tin mà khơng cần sử dụng trường địa IP nguồn nằm gói tin Thông tin đánh dấu thường chèn vào trường sử dụng phần tiêu đề gói tin IP q trình lưu chuyển tới trạm đích Có hai kỹ thuật đánh dấu gói tin đánh dấu theo xác suất PPM đánh dấu xác định DPM Kỹ thuật đánh dấu gói tin PPM DPM PPM [122] thực đánh dấu tất định tuyến đường gói tin theo tỷ lệ gói tin định tuyến với xác suất cố định p = 0,04 Thông tin đánh dấu tạo phép toán “XOR” hai địa IP hai định tuyến chia thành phân đoạn nhỏ Mỗi phân đoạn lựa chọn ngẫu nhiên lưu 16 bit trường Identification gói tin đánh dấu coi mẫu thông tin đường (path) Khi máy đích nhận đủ số lượng mẫu, đường xếp, tái tạo lại Ưu điểm PPM đơn giản, dễ thực hiện, khơng làm tăng kích thước gói tin có khối lượng tính tốn nhỏ định tuyến PPM có nhược điểm máy đích phải thực khối lượng tính tốn cao để tái tạo lại đường đi; tỷ lệ traceback thành cơng thấp xác suất ghi đè mẫu thơng tin lên gói tin đánh dấu cao [48] Một số đề xuất cải tiến đưa sử dụng xác suất thay đổi động dựa giảm dần giá trị TTL gói tin (DPPM) [50], giải pháp EAST [121] sử dụng số định danh mạng tự trị (AS) làm thông tin đánh dấu thay cho địa IP router EAST sử dụng bit trường TOS để đánh dấu tồn thơng tin đánh dấu AS đưa trọn vẹn vào gói tin Tuy nhiên, giải pháp không khắc phục vấn đề cần nhiều khối lượng tính tốn máy đích Nhóm tác giả Belenky [50], [122] đề xuất giải pháp DPM đánh dấu gói tin định tuyến biên mạng ISP Thông tin đánh dấu địa IP cổng vào định tuyến biên (32 bits) DPM sử dụng 16 bits trường Indentification để lưu thông tin đánh dấu bit Reserved Flag để thị gói tin đánh dấu (cờ) 32 bit thông tin đánh dấu phân mảnh thành phần nhỏ mà nhúng vào tiêu đề gói tin IP Mỗi phân đoạn lựa chọn với xác suất p =1/K với K số lượng gói tin cần cho q trình đánh dấu Kỹ thuật DPM traceback lại bị cơng DDoS u cầu tính tốn thấp máy đích Bên cạnh đó, giải pháp khơng làm tăng kích thước gói tin ngăn chặn công đánh dấu giả mạo Tuy nhiên tỷ lệ traceback nhầm nguồn lưu lượng 60 cao đặc biệt có cơng DDoS tới mạng đích Khắc phục hạn chế trên, giải pháp cải tiến bao gồm Extended DPM [123] Flexible DPM [47] đề xuất sử dụng thêm bit trường TOS gói tin IP để nâng khơng gian đánh dấu lên tới 25 bits/gói tin Nhờ giảm số lượng gói tin cần thiết để đánh dấu tăng tỷ lệ traceback thành cơng dẫn tới xung đột bit sử dụng cho mục đích khác quy định RFC 2474 [124], hay RFC 3168 [125] Mặc dù giải pháp nâng cấp cải thiện hiệu đánh dấu, có số vấn đề tồn bao gồm: u cầu tính tốn cịn cao, độ xác thấp Kỹ thuật đánh dấu gói tin theo luồng DFM Kỹ thuật đánh dấu gói tin theo luồng DFM đề xuất Vahid Aghaei-Foroushani [48] giải pháp nâng cấp DPM Giống DPM, DFM thực đánh dấu định tuyến biên gói tin lưu chuyển từ bên hệ thống mạng Internet Tuy nhiên DFM thực đánh dấu K gói tin luồng Trong đó, luồng TCP/UDP xác định thơng số: địa IP nguồn đích, số hiệu giao thức L4, số hiệu cổng nguồn đích; luồng ICMP xác định tham số: địa IP nguồn đích, số hiệu giao thức L4, mã code ICMP, loại ICMP ID luồng ICMP Các gói tin thuộc luồng xác định Thời gian chờ liên gói tin (inactive timeout) Thời gian tồn tối đa (active timeout) giống idle timeout hard timeout Openflow Trong DFM, thông tin đánh dấu mở rộng lên 60 bits gồm: (i) 32 bit In-portIP địa IP cổng vào định tuyến biên; (ii) 12 bit NIID giá trị địa MAC hay VLAN ID thiết bị kết nối với định tuyến; (iii) 16 bit NodeID giá trị để nhận diện trạm nguồn Số lượng gói tin cần để đánh dấu cho luồng phụ thuộc vào việc sử dụng trường tiêu đề gói tin IP chứa thông tin đánh dấu DFM sử dụng linh hoạt trường tiêu đề để đánh dấu, 16 bits Identification, bit Reserved Flag, DFM sử dụng trường sử dụng khác, bao gồm bits TOS 13 bits Fragment Offset Bảng 2.9 thể quan hệ số gói tin yêu cầu K tương ứng với trường hợp sử dụng trường thơng tin khác gói tin đánh dấu Bảng 2.9 Các trường số lượng gói tin yêu cầu luồng để đánh dấu DFM Các trường tiêu đề gói tin sử dụng Identification, Reserved Flag, TOS Fragment Offset Identification, Reserved Flag TOS Identification, Reserved Flag Fragment Offset Identification Reserved Flag Kích thước đánh dấu (bits) 37 25 30 17 K 3 Đánh dấu theo luồng giúp cho DFM giảm gần 90% số lượng gói tin đánh dấu [95] so với DPM, nhờ u cầu tính tốn q trình đánh dấu giảm Ngồi ra, DFM cung cấp khả traceback gần tới nguồn phát lưu lượng nhờ bổ sung thông tin đánh dấu chi tiết Bên cạnh đó, để tránh đánh dấu giả mạo, DFM đưa tuỳ chọn chứng thực sử dụng khố mã hố cơng khai định tuyến biên, máy đích xác minh thơng tin đánh 61 dấu loại bỏ khả sửa đổi, đánh dấu giả mạo Đánh giá hiệu DFM thơng qua phân tích lưu lượng Internet Hình 2.21 Phân bố số lượng gói tin luồng từ liệu CAIDA Để nâng cao hiệu đánh dấu tăng tỷ lệ traceback thành công, tiêu chí quan trọng cần giảm số lượng gói tin đánh dấu luồng lưu lượng Mặc dù số lượng kích thước tổng gói tin đánh dấu giảm nhiều tỷ lệ traceback thành công cao so sánh với kỹ thuật DPM, DFM cần K gói tin luồng để lưu giữ thông tin đánh dấu Khi luồng có K gói tin khơng thể đánh dấu thành cơng máy đích khơng thể traceback địa vùng phát sinh gói tin Để khảo sát tỷ lệ đánh dấu thành công kỹ thuật DFM, triệu luồng lưu lượng từ liệu CAIDA [107] [108] lựa chọn phân tích theo luồng cơng cụ Scapy [109] với giá trị inactive timeout active timeout 15 giây 30 phút (lấy theo giá trị mặc định giao thức NetFlow [126]) Kết phân tích thể đồ thị Hình 2.21 Theo kết phân tích, luồng có gói tin chiếm tỷ lệ lớn (trên 40%) Với phân bố này, chí với trường hợp K=2, tỷ lệ đánh dấu thành công thấp (dưới 60%) 2.4.3 Đề xuất cấu trúc hoạt động PLA DFM kiến trúc mạng SDN/Openflow Cấu trúc hệ thống đánh dấu PLA DFM Trong kỹ thuật DFM, số lượng gói tin cần để đánh dấu cao tỷ lệ đánh dấu thành công thấp Để tăng khả đánh dấu thành công, thông tin đánh dấu phải lưu trữ gói tin tốt Để thực điều đó, nâng số bits đánh dấu gói tin Theo nguyên tắc hoạt động SDN, gói tin luồng gửi tới Bộ điều khiển nhờ kiện table-miss thông qua tin packet-in Dựa vào chế này, Bộ điều khiển ghi thơng tin đánh dấu vào gói tin luồng trước lưu chuyển chúng Internet Dựa nguyên tắc chung Hình 1.9, cấu trúc hệ thống giải pháp đánh dấu gói tin PLA DFM mơ tả Hình 2.22 Theo đó, q trình đánh dấu gói tin thực chuyển mạch biên lưu lượng từ mạng nội Internet: 62 Hình 2.22 Cấu trúc hệ thống giải pháp đánh dấu gói tin PLA DFM dựa kiến trúc SDN/Openflow • Thơng tin đánh dấu bao gồm (i) 32 bits In-portIP, (ii) 12 bits giá trị NIID (iii) 16 bits giá trị NodeID • Module PLA DFM thực chức nhận dạng luồng chèn thơng tin đánh dấu vào gói tin luồng theo chế SDN/Openflow trước chuyển tiếp gói tin tới Internet action Packet Out • Các luồng TCP/UDP xác định tham số, luồng ICMP xác định tham số giống DFM trình bày mục 2.4.2.3 với thời gian inactive timeout activetimeout tương ứng với idle-timeout hard-timeout mục luồng quy định ứng dụng SDN/Openflow Nguyên lý đánh dấu gói tin PLA DFM a) Nguyên tắc đánh dấu PLA DFM đánh dấu theo nguyên tắc: • Đưa tối đa thơng tin đánh dấu vào gói tin nhằm giảm số lượng gói tin đánh dấu • Thiết lập giá trị ngưỡng MT để tránh phân mảnh gói tin chúng truyền qua phân đoạn mạng khác Với dung lượng thông tin đánh dấu luồng 60 bits, DFM đánh dấu trọn vẹn gói tin với trường tiêu đề đề xuất Bảng 2.9 Để giải vấn đề này, PLA DFM, trường Options sử dụng với chiều dài mở rộng tối đa bytes Tuy 63 nhiên chiều dài tổng gói tin sau đánh dấu bị tăng lên vượt ngưỡng MTU dẫn tới phân mảnh gói tin [127] Để xử lý vấn đề này, giá trị ngưỡng MT thiết lập áp dụng quy tắc: gói tin luồng nhỏ MT, trường Options sử dụng, ngược lại luồng đánh dấu theo DFM, PLA DFM cải thiện đáng kể khả đánh dấu tỷ lệ traceback thành cơng Hình 2.23 Phân bố chiều dài gói tin thứ từ liệu CAIDA b) Các trường hợp đánh dấu Dựa vào kích thước gói tin FL so với ngưỡng MT lượng thông tin đánh dấu luồng, PLA DFM thực đánh dấu theo trường hợp: • Trường hợp 1: FL ≤ MT, PLA DFM sử dụng 16 bits trường ID 48 bits trường Options để chứa thơng tin đánh dấu • Trường hợp 2: FL > MT, thông tin đánh dấu đưa vào số trường tiêu đề sử dụng K gói tin giống kỹ thuật DFM Hình 2.24 Đánh dấu gói tin PLA DFM Để tránh xung đột gây dịch vụ DSCP quy định RFC 2474 [124] ECN quy định RFC 3168 [125], PLA DFM không sử dụng trường TOS để chứa thông tin đánh dấu Do vậy, có hai trường hợp sử dụng kỹ thuật PLA DFM: 64 • K=3: Sử dụng trường Identification, Reserved Flag Fragment Offset, tổng kích thước sử dụng T= 30 bits Do có phân đoạn thơng tin đánh dấu, có M=20 bits cho việc phân mảnh thông tin đánh dấu, gói tin đánh dấu cần S=log2 (60/20) = bits dành cho thứ tự phân đoạn • K=5: Các trường Identification Reserved Flag sử dụng Trong trường hợp này, giá trị T=17, M=12 S=3 Khi thông tin đánh dấu bị chia cắt gửi gói tin khác nhau, có nhiều nguồn lúc giả mạo thuộc tính luồng gửi gói tin đến địa đích máy đích khơng phân biệt nguồn gốc phân đoạn đánh dấu nhận traceback sai Để tránh công dạng này, PLA DFM đề xuất sử dụng giá trị kiểm tra (checksum) thông tin đánh dấu Tuy nhiên, địi hỏi phải thêm khơng gian gói tin đánh dấu • Trường hợp K = 3, T = 30 bits, Marked Flag = bit, M = 20 bits dành cho phân đoạn thông tin đánh dấu, S = bits để đánh thứ tự phân đoạn có tới C = bits gói tin sử dụng để chứa giá trị checksum Do đó, trường hợp K = có đủ khơng gian chứa thơng tin đánh dấu cho tùy chọn có hay khơng sử dụng giá trị checksum • Trường hợp K = 5, T = 17 bit, Marked Flag = bit, M = 12 bits dành cho phân đoạn thông tin đánh dấu, S=3 bits để đánh thứ tự phân đoạn khơng có đủ không gian cho giá trị checksum Do vậy, để sử dụng tuỳ chọn checksum, cần có K = gói tin luồng chứa thơng tin đánh dấu với tham số M = 12, S = 3, C = c) Giá trị ngưỡng MT: Bảng 2.10 Một số giá trị MTU loại đường truyền phổ biến giá trị MT tương ứng Mạng vật lý MTU MT Point to Point (RFC1661) 296 288 ARCNET 508 500 X 25 576 568 IEEE 802.3 1492 1484 Ethernet 1500 1492 Nếu chọn giá trị MT nhỏ làm giảm tỷ lệ số lượng luồng đánh dấu theo cách này, dẫn tới tỷ lệ đánh dấu thấp hơn, lại loại bỏ nguy phân mảnh gói tin đánh dấu Giá trị MT (Bảng 2.10) lựa chọn dựa giá trị MTU nhỏ phân đoạn mạng đường truyền thơng tin phổ biến Q trình đánh dấu PLA DFM Thuật toán đánh dấu PLA DFM với tuỳ biến sử dụng giá trị checksum diễn giải Bảng 2.11 65 Bảng 2.11 Kỹ thuật PLA DFM với tuỳ biến giá trị Checksum PLA_DFM.Marking // Input: arrival_packets // Output: marked_packets 1: FOR EACH arrival_packet 2: IF arrival_packet belongs to an existed active current_flow THEN 3: IF current_flow.NeededPackets >0 THEN 4: Call current_flow.DFM_Marking with arrival_packet 5: ELSE 6: INIT new_active_flow 7: OBTAIN Marking_Information 8: IF arrival_packet.Total_length = 𝑆𝑆2 ) THEN 2: Trạng_thái_máy_chủ = “Đang_bị_tấn_công” 3: ELSE 4: IF (nf >=𝑆𝑆1 liên tiếp N lần) THEN 5: Trạng_thái_máy_chủ =“Nghi_ngờ_bị_tấn_công” 6: ELSE 7: Trạng_thái_máy_chủ = “Không_bị_tấn_công” 8: ENDIF 9: ENDIF 81 3.4.5 Chuyển tiếp gói tin thực thể hệ thống Hệ thống hoạt động theo nguyên tắc: • Khi khơng phát có cơng: gói tin đến từ Internet chuyển tiếp bình thường tới máy chủ nội theo kỹ thuật SDN/Openflow chuẩn • Khi phát nghi ngờ có cơng xảy ra: Các gói tin thuộc luồng nghi ngờ chép tới SD chuyển tới SD để phân tích xử lý SD phân tích lưu lượng áp dụng thuật toán logic mờ để xác định tỷ lệ Z số luồng lưu lượng công • Hệ thống áp dụng sách giảm thiểu cơng cách xóa bỏ luồng tồn luồng công đến theo tỷ lệ Z: Xóa bỏ luồng có gói tin trước, luồng tạo trước bị xóa trước Số lượng luồng tạo kết nối tới máy chủ luồng bị xóa phải trì cân để đảm bảo tổng số luồng cịn lại chiếm tỷ lệ 1-Z so với lúc ban đầu áp dụng thuật toán - Để thực xử lý theo nguyên tắc trên, mục luồng OFS cấu hình, thiết lập mức ưu tiên, actions thành loại mô tả Bảng 3.3 Bảng 3.3 Các loại mục luồng dùng để điều hướng lưu chuyển gói tin hệ thống Loại mục luồng CF_FE (Current Flow entry) NF_FE Trường so khớp Thời gian chờ timeout Mục đích sử dụng - idle timeout: Thiết lập thời gian chờ trung bình hai gói tin kế - Đối với luồng ICMP: địa - Tạo tiếp IP nguồn, IP đích, số chuyển tới SD - hard timeout: hiệu giao thức, loại ICMP, có yêu cầu thời gian tồn mã ICMP, số ICMP tối đa luồng - Chuyển gói tin từ internet tới máy chủ tương ứng - Địa IP đích máy - Chuyển tiếp tới Khơng thiết lập chủ SD - Chuyển gói tin thuộc luồng tới SD mà không qua giao diện Openflow - Đối với luồng TCP, UDP: Địa IP nguồn, IP đích, số hiệu giao thức, cổng dịch vụ nguồn, cổng dịch vụ đích (New Flow entry) - Có mức độ ưu tiên thấp CF_FEs SB_FE - Cổng đến SD port (Send back Flow entry) Actions - Chuyển tiếp tới cổng liên kết với máy chủ nội tương ứng (Server port, IP đích) - Chuyển tiếp tới Khơng thiết lập - Có mức độ ưu tiên cao máy chủ nội tương ứng (cổng CF_FEs dịch vụ, IP đích máy chủ) - Chuyển tiếp gói tin tới SD phục vụ phân tích an ninh - Nhận gói tin xử lý an ninh từ SD chuyển tới máy chủ tương ứng 82 Q trình trao đổi, xử lý gói tin thực thể hệ thống máy chủ trạng thái “Không bị công”, “Nghi ngờ bị công” “Đang bị công” thể Hình 3.5, Hình 3.6, Hình 3.7, Hình 3.8 Hình 3.5 Sơ đồ hệ thống máy chủ trạng thái "Khơng bị cơng" 83 Hình 3.6 Sơ đồ kiện Packet in máy chủ trạng thái "Nghi ngờ bị cơng" Hình 3.7 Sơ đồ kiện “Kết thúc chu kỳ giám sát” máy chủ trạng thái "Nghi ngờ bị công" 3.4.6 Phân loại lưu lượng giảm thiểu công DDoS dựa thuật toán suy luận logic mờ FDDoM Tại máy chủ bảo mật SS, thuật toán phân loại giảm thiểu công DDoS FDDoM đề xuất dựa hệ suy luận mờ (FIS) [79], [131] Thuật toán cho phép hệ thống tính tốn giá trị đầu dựa tham số lưu lượng đầu vào mà giá trị khơng rõ ràng nằm giới hạn thể chắn 100% lưu lượng cơng hay lưu lượng lành tính Qua thống kê lưu lượng, ta ngưỡng thị đảm bảo chắn lưu lượng công ngưỡng thị đảm bảo lưu lượng lành tính Hai giá trị ngưỡng thường 84 cách xa tạo nên khoảng giá trị chúng mà giá trị thị nằm khoảng kết đầu khơng rõ ràng để khẳng định tính chất lưu lượng mức độ thuộc lưu lượng lành tính hay lưu lượng cơng Để hệ thống nhanh chóng đưa định xử lý lưu lượng, thuật tốn logic mờ áp dụng, đầu thuật toán cho biết điều khiển cần định tỷ lệ số luồng tồn lưu lượng cơng có sách giảm thiểu tương ứng FDDoM sử dụng hệ suy luận mờ Sugeno [131] Hình 3.8 Sơ đồ kiện Packet in máy chủ trạng thái "Đang bị công" Xác định tham số làm thị phát Dựa vào kết phân tích lưu lượng cơng DDoS trình bày mục 3.4.2 hai thị đề xuất để phát công bao gồm: • IAT - tỷ lệ gói có khoảng thời gian liên gói tin phạm vi thấp Theo kết phân tích lưu lượng DDoS, giá trị lựa chọn khoảng (0 - 0,2] ms, • PpF - tỷ lệ luồng có gói tin Với máy chủ, ngưỡng l h xác định theo nguyên tắc: không bị công, giá trị thị thấp ngưỡng l, chắn bị công, giá trị thị cao ngưỡng h Tỷ lệ số luồng công cần lọc bỏ Z, xác định theo luật: NẾU lưu lượng truy cập đến máy chủ có IAT PpF thấp ngưỡng l tương ứng THÌ cho lưu lượng lành tính chuyển tiếp 100% tới máy chủ (Z = 0) NẾU IAT PpF cao ngưỡng h tương ứng THÌ lưu lượng truy cập xác định lưu lượng công lọc bỏ 100% (Z = 1) 85 Trong trường hợp hai hai thị có giá trị nằm ngưỡng thấp ngưỡng cao tương ứng, hệ thống xác định lưu lượng đến có tỷ lệ Z số luồng tồn lưu lượng công Sử dụng mô hình Sugeno [98], giá trị thị đầu Z (khoảng từ đến 1) tính theo bước chính: Mờ hóa (Fuzzification), Đánh giá luật hợp thành (Rule Evaluation), Giải mờ (Defuzzification) Mờ hoá thị phát Hình 3.9 Mờ hố IAT với hai hàm thành viên Low High Các giá trị thị đầu vào (IAT, PpF) mờ hóa thành tập mờ hàm thành viên Low High Mờ hóa thực chất xác định hàm thành viên biểu diễn mức độ giá trị thị đầu vào IAT PpF thuộc tập mờ Low High tương ứng Mức độ thuộc tập mờ trải từ (khơng thuộc) tới (thuộc hoàn toàn) Khi biểu diễn dạng đồ thị, hàm thành viên thường triển khai dạng phổ biến hình thang hình tam giác Với đặc điểm giá trị IAT PpF mơ tả trình bày mục 3.4.2 luật giảm thiểu tác hại công nêu trên, đồ hình hình thang lựa chọn với giá trị ngưỡng thống kê từ liệu lưu lượng cơng DDoS, đó: • Vùng phẳng vùng giá trị thị đầu vào thuộc hoàn toàn vào tập thành viên Low High (cạnh đỉnh hình thang) khơng thuộc vào tập thành viên (phần ngồi cạnh đáy hình thang nằm trục hồnh) • Vùng tương ứng với cạnh chéo hình thang vùng biên (boundary) nơi mà giá trị thị đầu vào khơng hồn tồn thuộc tập mờ Low High Cụ thể, đồ hình hàm thành viên mơ tả Hình 3.9, IAT nhỏ ngưỡng l = 0,8, IAT xem hoàn toàn thuộc thành viên Low(IAT) Khi IAT vượt ngưỡng h = 0,9, IAT coi hồn tồn thuộc thành viên High(IAT) Đó phần đỉnh hai hình thang tương ứng với hai hàm thành viên F Low (IAT) F High (IAT) Khi giá trị IAT nằm vùng chéo (0,8 ≤ IAT ≤ 0,9), mức độ IAT thuộc hai thành viên Low(IAT) High(IAT) mức không rõ ràng Theo mơ hình Sugeno, mức độ giá trị IAT thuộc thành viên Low(IAT) High(IAT) phản ánh công thức: 86 𝐼𝐼𝐼𝐼𝐼𝐼 − 𝑎𝑎 𝑑𝑑 − 𝐼𝐼𝐼𝐼𝐼𝐼 F𝐿𝐿𝐿𝐿𝐿𝐿 (𝐼𝐼𝐼𝐼𝐼𝐼) = max �min � , 1, � , 0� 𝑏𝑏 − 𝑎𝑎 𝑑𝑑 − 𝑐𝑐 𝐼𝐼𝐼𝐼𝐼𝐼 − 𝑎𝑎′ 𝑑𝑑′ − 𝐼𝐼𝐼𝐼𝐼𝐼 F𝐻𝐻𝐻𝐻𝐻𝐻ℎ (𝐼𝐼𝐼𝐼𝐼𝐼) = max �min � , 1, � , 0� 𝑏𝑏′ − 𝑎𝑎′ 𝑑𝑑′ − 𝑐𝑐′ (3.2) (3.3) a, b, c, d a’, b’, c’, d’ đỉnh hai hình thang biểu diễn cho hàm thành viên F Low (IAT) F High (IAT) Hình 3.10 Mờ hoá PpF với hai hàm thành viên Low High Tương tự, mức độ thuộc hàm thành viên giá trị thị PpF mô tả Hình 3.10 Theo mơ hình Sugeno với hàm liên thuộc dạng hình thang, mức độ giá trị PpF thuộc tập mờ Low(PpF) High(PpF) phản ánh công thức: 𝑃𝑃𝑃𝑃𝑃𝑃 − 𝑒𝑒 ℎ − 𝑃𝑃𝑝𝑝𝑝𝑝 F𝐿𝐿𝐿𝐿𝐿𝐿 (𝑃𝑃𝑃𝑃𝑃𝑃) = max �min � , 1, � , 0� 𝑓𝑓 − 𝑒𝑒 ℎ − 𝑔𝑔 F𝐻𝐻𝐻𝐻𝐻𝐻ℎ (𝑃𝑃𝑃𝑃𝑃𝑃) = max �min � 𝑃𝑃𝑃𝑃𝑃𝑃 − 𝑒𝑒′ ℎ′ − 𝑃𝑃𝑃𝑃𝑃𝑃 , 1, � , 0� 𝑓𝑓′ − 𝑒𝑒′ ℎ′ − 𝑔𝑔′ (3.4) (3.5) với e, f, g, h e’, f’, g’, h’ đỉnh hai hình thang biểu diễn cho hàm hợp thành F Low (PpF) F High (PpF) Xác định luật hợp thành Bước cần xác định luật điều khiển thuật toán suy luận logic mờ nhận số rõ IAT PpF Các action đầu bao gồm Chuyển tiếp (Fw – Forward) hay Xóa bỏ (Dr – Drop) Action = Fw: Chuyển tiếp tất gói tin tới máy chủ đích Action = Dr: Xóa bỏ tỷ lệ Z gói tin Dựa phân tích chế hoạt động hệ thống, có luật sau: [Rule 1]: IF IAT is Low AND PpF is Low THEN Action = Fw (3.6) [Rule 2]: IF IAT is High AND PpF is High THEN Action = Dr (3.7) [Rule 3]: IF IAT is High AND PpF is Low THEN Action = Dr (3.8) [Rule 4]: IF IAT is Low AND PpF is High THEN Action = Dr (3.9) 87 Để áp dụng mô hình Sugeno, luật xác định trọng số w i Với bốn luật nêu trên, trọng số xác định sau: [Rule 1]: [Rule 2]: [Rule 3]: [Rule 4]: 𝑤𝑤1 = 𝑚𝑚𝑚𝑚𝑚𝑚[F𝐿𝐿𝐿𝐿𝐿𝐿 (𝐼𝐼𝐼𝐼𝐼𝐼), F𝐿𝐿𝐿𝐿𝐿𝐿 (𝑃𝑃𝑃𝑃𝑃𝑃)] (3.10) 𝑤𝑤3 = 𝑚𝑚𝑚𝑚𝑚𝑚�F𝐻𝐻𝐻𝐻𝐻𝐻ℎ (𝐼𝐼𝐼𝐼𝐼𝐼), F𝐿𝐿𝐿𝐿𝐿𝐿 (𝑃𝑃𝑃𝑃𝑃𝑃)� (3.12) 𝑤𝑤2 = 𝑚𝑚𝑚𝑚𝑚𝑚�F𝐻𝐻𝐻𝐻𝐻𝐻ℎ (𝐼𝐼𝐼𝐼𝐼𝐼), F𝐻𝐻𝐻𝐻𝐻𝐻ℎ (𝑃𝑃𝑃𝑃𝑃𝑃)� (3.11) 𝑤𝑤4 = 𝑚𝑚𝑚𝑚𝑚𝑚�F𝐿𝐿𝐿𝐿𝐿𝐿 (𝐼𝐼𝐼𝐼𝐼𝐼), F𝐻𝐻𝐻𝐻𝐻𝐻ℎ (𝑃𝑃𝑃𝑃𝑃𝑃)� (3.13) F Low , F High hàm hợp thành thị đầu vào IAT PpF Các lớp hành động đầu xác định sau: Dr = 1; Fw = (3.14) Giải mờ Theo mơ hình Sugeno hệ suy luận mờ, kết hành động đầu (được đánh giá qua thị Z) hệ thống kết hợp luật với mức độ khả tương ứng Khi đó, giá trị thị đầu trung bình cộng theo trọng số giá trị đầu theo biến ngôn ngữ luật Cơ chế suy luận Cụ thể, trường hợp này, thị đầu Z tính theo cơng thức: ∑𝑁𝑁 𝑖𝑖=1 𝑤𝑤𝑖𝑖 𝑍𝑍𝑖𝑖 𝑍𝑍 = 𝑁𝑁 ∑𝑖𝑖=1 𝑤𝑤𝑖𝑖 (3.15) với N số luật Ở N = 𝑍𝑍 = 𝑤𝑤1 𝐹𝐹𝐹𝐹 + 𝑤𝑤2 𝐷𝐷𝐷𝐷 + 𝑤𝑤3 𝐷𝐷𝐷𝐷 + 𝑤𝑤4 𝐷𝐷𝐷𝐷 𝑤𝑤1 + 𝑤𝑤2 + 𝑤𝑤3 + 𝑤𝑤4 (3.16) Kết tính tốn thị đầu Z nằm khoảng giá trị [0 - 1] Giá trị cho biết máy chủ xét có trạng thái bị cơng hay không, trường hợp phát công xảy tới máy chủ giá trị cho biết tỷ lệ tổng số luồng chuyển mạch biên máy chủ thời điểm lưu lượng công cần phải loại bỏ 3.4.7 Đánh giá hiệu giải pháp Để đánh giá khả đáp ứng hiệu hệ thống mức độ giảm thiểu tác hại công DDoS, q trình phân tích mơ thực lưu lượng capture từ mạng thực công ty Netnam tới máy chủ dịch vụ web khoảng thời gian 600s Bộ lưu lượng gồm phần: lưu lượng lành tính lưu lượng công thu thập phân lập mô tả mục 3.4.2 Các tham số hệ thống chọn sau: • Thời gian timeout cho mục luồng CF_FEs: t idle = 10s, t hard = 60s Các tham số lấy theo tham số luồng phổ biến mặc định sản phẩm chuyển mạch thương mại [110] • Chu kỳ giám sát lựa chọn T = 30s 88 • Qua phân tích đặc tính lưu lượng máy chủ, vào đặc tính thống kê máy chủ Web hoạt động điều kiện bình thường nhiều khung ngày khả chịu tải máy chủ, ngưỡng S chọn 300, ngưỡng S chọn 600 • Tương tự, đặc tính lưu lượng máy chủ điều kiện bình thường điều kiện bị công, ngưỡng IAT cho cơng DDoS chọn mức 0,2ms Theo đó, tỷ lệ IAT điều kiện bình thường 0,5, tỷ lệ IAT chắn điều kiện bị công DDoS 0,99 Tỷ lệ PpF điều kiện bình thường 0,1 chắn điều kiện bị cơng 0,9 • Lưu lượng trạng thái bình thường, khơng bị cơng trì 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 công với tổng thời gian công phút, kéo dài tới hết giây thứ 420 Độ nhạy lọc bỏ tỷ lệ lọc bỏ nhầm Giá trị thị đầu Z hệ thống tính sau chu kỳ thể biểu đồ Hình 3.11 Hình 3.11 Giá trị đầu thị Z thuật tốn FDDoM độ 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 thể biểu đồ Hình 3.12 Kết độ nhạy lọc bỏ tỷ lệ lọc bỏ nhầm thấy: • Độ nhạy lọc bỏ chu kỳ giám sát T đạt 92,0 đến 95,0% theo luồng • Tỷ lệ lọc bỏ nhầm mức 5,1% 89 • Nếu tính trung bình suốt thời gian cơng, độ nhạy lọc bỏ đạt tới 97,5% 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 đo với giải pháp áp dụng thuật toán TRW-CB Openflow kết hợp sFlow [21] nhóm tác giả Kostas Giotis thực (năm 2014) trình bày chương trường hợp lưu lượng DDoS hỗn hợp lưu lượng công quét cổng áp dụng 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 giải pháp FDDoM với giải pháp mơ hình mạng tương đồng Giải pháp TRW-CB Openflow kết hợp sFlow với lưu lượng DDoS hỗn hợp TRW-CB Openflow kết hợp sFlow với lưu lượng công quét cổng FDDoM Độ nhạy lọc bỏ (DR F ) Tỷ lệ lọc bỏ nhầm (FPR F ) 96 % 25 % 96 % 10 % 97,50 % 3,6 % Kết so sánh cho thấy, giải pháp FDDoM cho độ nhạy lọc bỏ cải thiện so với giải pháp TRW-CB Openflow kết hợp sFlow Trong đó, điều quan trọng FDDoM giảm tỷ lệ lọc bỏ nhầm, so sánh với trường hợp lưu lượng công xác định (quét cổng) Điều đặc biệt có ý nghĩa chất giảm thiểu công DDoS cố gắng không làm ảnh hưởng đến trình trao đổi liệu máy khách (client) lành tính tới máy chủ trung tâm liệu Khả đáp ứng hệ thống - Trong giải pháp dựa kiến trúc SDN/Openflow [22], [24], [77], sau phát công, hệ thống phải tiếp tục giám sát thêm chu kỳ T để phân loại lưu lượng cơng áp đặt sách xử lý gói tin thông qua mục luồng Điều làm chậm khả đáp ứng hệ thống mà làm tăng lưu lượng giao diện Openflow Bộ điều khiển truy vấn thông tin lưu lượng Trong FDDoM, máy chủ xác định trạng thái “Nghi ngờ bị công” “Đang bị công”, toàn lưu lượng luồng đến chuyển đến SD, không chuyển tới máy chủ nội tới Bộ điều khiển Tại SD lưu lượng công xóa bỏ, khơng cần phải đợi thêm chu kỳ giám sát Việc hạn chế tối đa luồng tạo giảm thiểu tải thông tin lên điều khiển, khối phân tích bảo mật Do vậy, mức độ đáp ứng đưa sách an ninh hệ thống nhanh so với phương pháp xử lý dựa giao diện Openflow - Ngoài ra, cách tiếp cận khắc phục vấn đề phổ biến khác xử lý luồng có gói tin Tấn cơng DDoS phổ biến giả mạo IP với số lượng lớn luồng có gói tin gửi đến máy nạn nhân Sau nhận gói tin gói luồng, mục luồng tương ứng tạo OFS kéo dài hết thời gian chờ gây lãng phí tài ngun Khi có dấu hiệu có gói tin luồng máy chủ trạng thái “Đang bị cơng”, trình bày mục SS yêu cầu SP điều khiển 90 hủy bỏ luồng có gói tin theo tỷ lệ Z OFS nhằm hạn chế chiếm dụng vơ ích tài ngun chuyển mạch Giảm lưu lượng giao diện Openflow - Theo ngun tắc hoạt động SDN/Openflow, gói tin khơng khớp với mục luồng có OFS gửi tới điều khiển qua tin packet-in Khi cơng DDoS xảy ra, hàng loạt gói tin không khớp tạo ạt tin packet-in làm cho giao diện Openflow tăng cao vượt ngưỡng cho phép Ngồi ra, gói tin giao diện mã hóa TLS, độ dư mã làm cho lưu lượng tăng cao gây nguy nghẽn mạng giao diện Openflow - Trong FDDoM, lưu lượng xử lý theo chế máy chủ trạng thái “Không bị công” Trong trường hợp máy chủ trạng thái "Nghi ngờ bị công" "Đang bị công", tin packet-in qua giao diện Openflow thay chế gửi kiện gói tin tới SD Khi phát có cơng, phần gói tin thuộc luồng bị hủy bỏ (nghĩa không cài đặt luồng SD) Do đó, lưu lượng chuyển tiếp đến máy chủ giảm đáng kể Ngoài ra, SD khơng gửi tồn phần tiêu đề gói tin đến SS thơng qua SP điều khiển, mà gửi phần hữu ích tiêu đề như: địa IP nguồn, địa IP đích, cổng nguồn, cổng đích Thực tế làm cho lưu lượng Openflow điều khiển chuyển mạch tổng lưu lượng giao diện SS giảm đáng kể so với kiến trúc SDN/Openflow chuẩn Giảm chiếm dụng vùng nhớ đệm chuyển mạch biên OFS Trên mơ hình kiến trúc SDN/Openflow chuẩn, gói tin đến khơng khớp với mục luồng có OFS, phần gói tin bao gồm phần tiêu đề (header) chuyển tiếp tới điều khiển, toàn nội dung lưu trữ đệm OFS để chờ sách xử lý gói tin từ điều khiển Khi tài nguyên OFS trở nên cạn kiệt, tồn nội dung gói chuyển tiếp đến điều khiển tin packet-in Trong cơng DDoS, số lượng gói khơng khớp với mục luồng có sẵn OFS tăng lên cao, dẫn đến cạn kiệt đệm OFS FDDoM khắc phục vấn đề khơng u cầu sử dụng đệm trường hợp trạng thái máy chủ "Nghi ngờ bị công" "Đang bị cơng", gói tin chuyển tiếp trực tiếp đến SD, khơng qua giao diện Openflow Hình 3.13 So sánh số mục luồng tồn chuyển mạch biên OFS 91 Kết phân tích mơ mức độ giảm mục luồng OFS thể biểu đồ Hình 3.13 So sánh FDDoM với chế xử lý gói tin SDN/Openflow chuẩn cho thấy số lượng luồng OFS giảm đến 50% trường hợp có cơng xảy 3.5 Phát giảm thiểu công SYN Flood tới mạng SDN/Openflow sử dụng chế ủy nhiệm gói tin SYN phân tích xử lý lưu lượng 3.5.1 Đặt vấn đề Như trình bày Chương mục 2.3 Chương 2, công SYN Flood dạng công DDoS phổ biến nguy hiểm hệ thống mạng Ngoài mục tiêu công hệ thống máy chủ, bối cảnh SDN/Openflow, SYN Flood lợi dụng để cơng tới mục tiêu làm cạn kiệt tài nguyên chuyển mạch (lớp hạ tầng mạng), gây thắt cổ chai giao diện Openflow suy kiệt khả điều khiển (lớp điều khiển) [35], [93], [94] Đã có giải pháp phịng chống cơng SYN Flood cho kiến trúc mạng SDN/Openflow, điển hình chế Connection Migration giải pháp Avant-Guard [28], nhiên giải pháp sử dụng kỹ thuật ủy nhiệm gói tin SYN chuyển mạch nên áp dụng cho chuyển mạch Openflow không hỗ trợ chức Ngồi việc tích hợp chức xử lý gói tin chuyển mạch làm chất SDN, chia cắt kết nối TCP, đồng thời biến chuyển mạch trở thành mục tiêu công DDoS Giải pháp ủy nhiệm gói tin SYN Bộ điều khiển trình bày mục 2.3, Chương có khả phát giảm thiểu công SYN Flood tới máy chủ mạng quy mô nhỏ không xử lý công SYN Flood nhằm mục tiêu làm cạn kiệt tài nguyên Bộ chuyển mạch, Bộ điều khiển, làm lụt giao diện Openflow Sử dụng kiến trúc SDN/Openflow mở rộng, nội dung phần trình bày đề xuất giải pháp SSG ủy nhiệm gói tin SYN Phân tích xử lý lưu lượng với mục tiêu: • Giám sát trình bắt tay ba bước tất kết nối TCP nhằm phát công SYN Flood • Khi xác định có cơng SYN Flood xảy ra, hệ thống thực cài đặt mục luồng cho kết nối hồn thành q trình bắt tay ba bước nhằm loại bỏ gói tin SYN cơng giả mạo địa IP • Khắc phục điểm tồn chế CM giải pháp Avant-Guard Giải pháp SSG hoạt động sở: • Lợi dụng khả so khớp với trường TCP Flags gói tin TCP có chuẩn giao thức Openflow 1.5, xếp mục luồng chuyển mạch với action thích hợp để điều hướng gói tin 3HS kết nối TCP tới thiết bị ủy nhiệm an ninh SD • SD phát công SYN Flood xảy máy chủ dựa vào số kết nối TCP dở dang (HOC) tới máy chủ chu kỳ giám sát: 92 - Nếu máy chủ không bị cơng, khác với chế CM, q trình 3HS thực bình thường trực tiếp Internet clients máy chủ nội mà không cần ủy nhiệm kết nối TCP - Khi máy chủ xác định nghi ngờ bị công SYN Flood, SD trì danh sách địa IP tin cậy có kết nối với máy chủ gần Nếu gói tin SYN đến từ địa nằm danh sách địa IP tin cậy, chuyển đến máy chủ để thực kết nối bình thường với Internet client Trong trường hợp địa IP nguồn gói tin SYN khơng nằm danh sách tin cậy, SD xác thực địa nguồn gói tin kỹ thuật RST Cookie trước cho phép kết nối trực tiếp Internet client máy chủ nội 3.5.2 Cấu trúc hệ thống Cấu trúc chi tiết module chức SSG mô tả Hình 3.14 Trong đó: - OFS cấu hình, xếp mục luồng để thực capture chuyển tiếp gói tin 3HS gói tin RST để chuyển tới SD máy chủ nội - Bộ phân tích xử lý lưu lượng SD thực (1) giám sát trình 3HS kết nối TCP, qua (2) phát cơng SYN Flood (3) xác thực địa IP nguồn gói tin SYN - Trong SSG, khối chức máy chủ an ninh mạng thuộc lớp ứng dụng tích hợp module ủy nhiệm an ninh SP chạy trực tiếp điều khiển Chức SP bao gồm: (1) Thay đổi sách xử lý gói tin SYN đến chuyển mạch phát công SYN Flood xảy ngược lại, (2) cài đặt mục luồng phục vụ trao đổi liệu cho kết nối TCP sau xác thực trình bắt tay ba bước 3.5.3 Hoạt động hệ thống Phát cơng SYN Flood thay đổi sách xử lý gói tin SSG xác định thời điểm, máy chủ hai trạng thái: “Không bị công SYN Flood” “Nghi ngờ bị công SYN Flood” Module SFD SD thực phát công yêu cầu điều khiển thay đổi sách xử lý gói tin tương ứng SSG áp dụng thuật tốn phát cơng dựa mơ hình dự đốn xám [132]–[134] thuật tốn Tổng tích lũy (CUSUM) giới thiệu nhóm Wang [135] Hình 3.15 Tham số đầu vào cho SFD phát công SYN Flood số lượng kết nối TCP dang dở k HOC chu kỳ giám sát T SFD k HOC = k SYN – k 3HS_completed (3.17) Trong đó: k SYN số gói tin SYN đến máy chủ, k 3HS-completed số kết nối TCP hồn thành chu kỳ giám sát 93 Hình 3.14 Cấu trúc chi tiết tương tác module chức giải pháp SSG Hình 3.15 Mơ hình thuật tốn phát cơng SYN Flood đề xuất sử dụng SSG Tùy theo kết phân loại sau chu kỳ giám sát T SFD , có thay đổi trạng thái máy chủ (đang từ trạng thái “Không bị công SYN Flood” sang trạng thái “Nghi ngờ bị công SYN Flood” ngược lại), SFD gửi tin thông qua module SP yêu cầu điều khiển chỉnh sửa mục luồng FE1 để thay đổi action mô tả Bảng 3.6 Với action này, máy chủ trạng thái “Khơng bị cơng”, gói tin SYN chuyển trực tiếp tới máy chủ để giám sát bắt tay ba bước Trong trường hợp máy chủ “Nghi ngờ bị cơng SYN Flood”, gói tin SYN chuyển tới SD để xác thực địa nguồn trước chuyển tới server mơ tả lưu đồ thuật tốn Hình 3.17 Sắp xếp mục luồng để capture điều hướng gói tin 3HS Lợi dụng khả so khớp với cờ TCP quy định Openflow 1.5 [20], khả xếp mục luồng theo mức ưu tiên khác nhiều bảng luồng [136], SSG tổ chức bảng luồng xếp mục luồng OFS Bảng 3.5 Bảng 3.6 để thực so khớp capture gói tin 3HS kết nối TCP điều hướng chúng tới máy chủ ứng dụng nội bộ, tới Internet clients tới SD Tùy theo trạng thái máy chủ nội bộ, gói tin 3HS capture điều hướng theo nguyên tắc: • Nếu máy chủ trạng thái “Khơng bị cơng”, gói tin 3HS điều hướng trực tiếp tới/giữa client server Một gói tin gửi tới SD cho mục 94 đích giám sát, phát cơng • Nếu máy chủ trạng thái “Nghi ngờ bị cơng”, gói tin SYN chuyển tới SD để xác thực địa IP nguồn trước gửi đến máy chủ Hình 3.16 mơ tả q trình capture điều hướng gói tin 3HS kết nối TCP lành tính thơng qua q trình so khớp với mục luồng chuyển mạch máy chủ ứng dụng nội trạng thái “Không bị công” Bảng 3.5 Tổ chức bảng luồng chuyển mạch OFS SSG Bảng luồng FT1 Khi tablemiss xảy - Capture gói tin SYN từ client, SYN- Proactive (các mục Chuyển tới ACK từ server SD để điều hướng xử lý luồng tồn vĩnh viễn) bảng FT2 giám sát trình 3HS, phát cơng SYN Flood FT2 - Điều hướng gói tin trao đổi liệu Reactive (các mục luồng Chuyển tới client server kết nối TCP tồn kết bảng FT3 sau hoàn thành bắt tay ba bước nối TCP kết thúc, dựa vào idle-timeout hard-timeout) FT3 - Capture gói tin CliACK, RST từ client, RST từ server để xác nhận trình 3HS Chức Loại mục luồng Proactive Chuyển tới Bảng FT4 (và - Chứa mục luồng cho ứng dụng FT tiếp khác theo) Bảng 3.6 Đặc tính mục luồng bảng luồng FT1 FT3 thực giám sát trình bắt tay ba bước Mục luồng Thuộc bảng luồng Khớp với loại gói tin Xuất cổng FE1x FT1 SYN gateway FE2x FT1 SYN SD FE3x FT1 SYN-ACK server - Chuyển tới client tương ứng qua cổng gateway - Tạo gửi tới SD FE4x FT1 SYN-ACK SD - Chuyển tới client tương ứng qua cổng gateway FE5 FT3 RST gateway server FE6x FT3 CliACK gateway Action tương ứng - Server trạng thái “Không bị công”: Chuyển tới server tương ứng tới SD - Server trạng thái “Nghi ngờ bị công”: Chuyển tới SD - Chuyển tới server tương ứng - Chuyển tới SD - Chuyển tới SD - Nếu server trạng thái “Không bị cơng”: chuyển tới server 95 Hình 3.16 Q trình capture điều hướng gói tin kết nối TCP lành tính thơng qua mục luồng OFS máy chủ nội trạng thái “Không bị cơng” Giám sát q trình bắt tay ba bước SD Quá trình 3HS kết nối TCP lành tính bình thường phải đảm bảo hai u cầu: (1) client xác nhận lại phía server gói tin CliACK sau nhận gói tin SYN-ACK (2) Số hiệu ACK_Num gói tin CliACK phải giá trị lớn liền kề số hiệu SEQ_Num gói tin SYN-ACK Giám sát trình 3HS nhằm loại bỏ yêu cầu kết nối TCP đến từ địa IP giả mạo Hình 3.17 Hình 3.18 mơ tả giám sát trình 3HS yêu cầu kết nối TCP SD Các địa IP tin cậy quản lý danh sách Trusted_IPs, trì tồn khoảng thời gian T IP_timeout tính từ gửi yêu cầu kết nối gần Những gói tin SYN có địa nguồn khơng nằm Trusted_IPs xác thực xem có phải gói tin giả mạo địa IP nguồn hay khơng kỹ thuật RST cookie (trình bày mục 3.5.3.4) Nếu q trình xác nhận gói tin SYN đến từ nguồn có thực, địa IP nguồn đưa vào danh sách Trusted_IPs gói tin SYN yêu cầu kết nối lần thứ từ phía client xác thực q trình bắt tay ba bước Nhằm hạn chế công quét cổng (port scan) tới hệ thống, SD trì danh sách Closed_Ports chứa cổng xác định bị đóng máy chủ Sau nhận gói tin SYN từ client, server trả gói tin RST thụ động (passive RST) tương ứng hệ thống hiểu cổng bị đóng Lúc này, số hiệu cổng cập nhật vào danh sách trì thời gian chờ T port_timeout SD hủy gói tin SYN có yêu cầu kết nối tới cổng đích nằm Closed_Ports Các kết nối TCP giám sát trình 3HS mơ tả Hình 3.18 SD trì danh sách HOCs chứa kết nối TCP dang dở Mỗi mục tin danh sách HOCs tương ứng với kết nối TCP bao gồm thông tin mơ tả Bảng 3.7 Khi q trình 3HS kết nối TCP hoàn thành hết thời gian chờ T HOC_timeout , mục tin tương ứng bị xóa bỏ 96 Hình 3.17 Lưu đồ thuật tốn q trình xử lý gói tin SYN đến SD Xác thực địa IP nguồn gói tin SYN kỹ thuật RST Cookie Xác thực địa nguồn gói tin SYN q trình kiểm tra xem địa nêu trường thơng tin Source IP Address có nơi phát gói tin hay khơng Cơ chế CM AvantGuard sử dụng kỹ thuật SYN Cookie để xác thực Nhược điểm kỹ thuật gây chia cắt kết nối TCP Để khắc phục nhược điểm này, SSG đề xuất sử dụng kỹ thuật RST Cookie hoạt động dựa giao thức TCP [39], quy định gói tin trao đổi tin cậy thực thể (client server) trình 3HS phải đảm bảo nguyên tắc: Mỗi bên khởi tạo giá trị 32 bits cho số hiệu SEQ_Num gửi cho phía đối diện Gói tin trả lời phía đối diện xác nhận thông qua giá trị số hiệu ACK_Num phải giá trị lớn liền kề số hiệu SEQ_Num gói tin nhận được: ACK_Num 2→1 = SEQ_Num 1→2 + (3.18) Nếu quy tắc bị phá vỡ phía phát hiểu có lỗi xảy thực reset lại trình bắt tay ba bước Trường hợp lỗi phát client, gửi gói tin RST chủ động (active RST) để reset lại kết nối gửi lại gói tin yêu cầu kết nối SYN Lợi dụng nguyên tắc trên, nhận gói tin SYN từ client, SD tạo gói tin SYNACK gửi trả lời client với giá trị số hiệu ACK_Num khác với giá trị SEQ_Num gói tin SYN Hình 3.19 Đồng thời, giống SYN Cookie [51], giá trị cookie sử dụng làm giá trị khởi tạo SEQ_Num theo chiều từ SD tới client tạo cách mã hóa từ tham số kết nối TCP (địa IP nguồn, đích, số hiệu cổng nguồn, đích số hiệu 97 SEQ_Num gói tin SYN) tham số bí mật SD Hình 3.18 Lưu đồ thuật tốn giám sát trình bắt tay ba bước SD Bảng 3.7 Cấu trúc mục tin danh sách HOCs Địa IP nguồn Địa IP đích Số hiệu cổng TCP nguồn Số hiệu cổng TCP đích Số hiệu SEQ_Num gói tin SYN-ACK timeout Nếu gói tin SYN xuất phát từ nguồn lành tính, theo nguyên tắc nêu trên, nhận gói tin SYN-ACK, client gửi lại gói tin RST với giá trị số hiệu ACK_Num giá trị cookie Lúc này, SD kiểm tra tính hợp lệ gói tin RST cách mã hóa lại giá trị cookie từ tham số kết nối TCP tham số bí mật Nếu giá trị cookie tính khớp với giá trị ACM_Num gói tin RST, SD hiểu nguồn xuất phát gói tin SYN ban đầu nguồn lành tính Với cách kiểm tra vậy, SD lưu trữ thông tin trạng thái kết nối TCP khơng bị ảnh hưởng chiếm dụng tài nguyên nhớ gói tin SYN giả mạo địa IP công SYN Flood Đồng thời, kết nối TCP thức khơng bị chia cắt sử dụng SYN Cookie chế CM 98 Hình 3.19 Sơ đồ trình xác thực địa IP nguồn gói tin SYN RST cookie 3.5.4 Phân tích đánh giá hiệu Để so sánh, đánh giá hiệu SSG so với chế CM giải pháp Avant-Guard, nội dung phần trình bày phân tích so sánh mặt giao thức, chế làm việc để thấy rõ cải tiến SSG tác động cơng SYN Flood, đồng thời xây dựng mơ hình testbed tạo kịch công với cường độ khác phân tích so sánh kết đo đạc từ testbed Cấu trúc testbed mơ tả Hình 3.20 Trong đó: - Bộ chuyển mạch OFS xây dựng từ máy tính chạy phần mềm OpenVswitch [69] phiên 2.7.90 với card ethernet 1Gbps Cấu hình máy tính chạy OpenVswitch: CPU Intel TM Core i3-2330M @ 2.2 GHz, 500GB HDD, 2GB RAM - SD máy tính độc lập có cấu hình CPU Intel TM Core i3-2330M @ 2.2 GHz, 500GB HDD, 2GB RAM Các gói tin đến SD từ OFS capture xử lý phần mềm DPDK [137] Hình 3.20 Cấu trúc testbed thử nghiệm đánh giá giải pháp SSG - Bộ điều khiển Floodlight [74] cài đặt hệ điều hành Ubuntu 14.04 với cấu hình máy 99 tính : CPU Intel TM Core i3-2330M @ 2.2GHz, 500GB HDD, 2GB RAM - Lưu lượng công SYN Flood tạo từ công cụ BONESI [115] với tùy chọn tạo địa IP nguồn giả mạo ngẫu nhiên, tốc độ công thay đổi từ 100 pps, 200 pps đến 5.500 pps Để đảm bảo tính tương đồng cho cấu hình khác nhau, lưu lượng công ghi lại công cụ WireShark [138] phát công công cụ TCPReplay [116] từ máy tính kết nối với hệ thống qua cổng gateway đóng vai trị giả lập lưu lượng truy cập từ internet tới server Thời gian trì cho trường hợp tốc độ công khác 500s - Lưu lượng lành tính tạo từ phần mềm chạy máy tính liên tục tạo yêu cầu kết nối download tệp tin dịch vụ FTP server với tốc độ 30 kết nối/s Lưu lượng kết nối client lành tính FTP server ghi lại cơng cụ WireShark phục vụ cho thống kê, phân tích Tỷ lệ kết nối thành công thời gian kết nối trung bình tác động cơng SYN Flood Hình 3.21 So sánh tỷ lệ kết nối thành công thời gian kết nối trung bình Openflow, chế CM giải pháp SSG Mục tiêu công SYN Flood làm cho hệ thống giảm lực phục vụ kết nối TCP lành tính, hay nói cách khác tỷ lệ kết nối thành công kết nối bị giảm xuống thời gian để kết nối TCP lành tính thực q trình kết nối truy xuất liệu bị 100 tăng lên Trong mơ hình thử nghiệm này, tỷ lệ kết nối thành cơng SCR tính tỷ lệ số kết nối TCP thực kết nối download thành công tệp tin tới máy chủ FTP tổng số yêu cầu kết nối Thời gian kết nối trung bình ART tính trung bình khoảng thời gian từ client lành tính gửi gói tin SYN yêu cầu kết nối đến client nhận gói tin liệu từ máy chủ FTP Kết đo thống kê SCR ART trình bày biểu đồ Hình 3.21 Kết cho thấy: - So sánh với Openflow chế CM, SSG chịu đựng cơng tốt trì tỷ lệ SCR 98% công tốc độ 5.500 pps CM mức 20%, cịn Openflow đạt mức 3% cơng tốc độ 1.500 pps kết nối tới má chủ tốc độ công mức 2.000pps - Kết cho thấy có tương quan mức độ giảm tỷ lệ kết nối thành công SCR với thời gian kết nối trung bình ART ba giải pháp Tuy nhiên, tốc độ công thấp (từ mức 100 pps đến 700 pps), thời gian ART SSG có chút cao so với chế CM Nguyên nhân SSG, client phải gửi lại gói tin yêu cầu SYN lần thứ hai địa IP khơng nằm danh sách địa IP tin cậy Trusted_IPs Sự chiếm dụng tài nguyên chuyển mạch SD Hình 3.22 thể kết đo chiếm dụng tài nguyên nhớ tài nguyên CPU OFS SD ba giải pháp mơ hình thử nghiệm Kết cho thấy: - Khi khơng có công, mức độ chiếm dụng tài nguyên OFS SSG xấp xỉ so với mơ hình Openflow mức 150 MB nhớ khoảng 8% tài nguyên CPU Trong đó, chế CM Avant-Guard có mức độ chiếm dụng tài nguyên cao hơn, mức giá trị tương ứng gần 200 MB 13% - Khi hệ thống chịu công SYN Flood, mức chiếm dụng tài nguyên OFS Openflow tăng nhanh đạt mức 1.600 MB nhớ 50% tài nguyên CPU tốc độ công mức 1.500 pps Điều minh chứng cho công làm cạn kiệt tài nguyên lớp hạ tầng mạng mà mục luồng vơ ích chiếm dụng phần lớn tài nguyên chuyển mạch gây suy giảm tỷ lệ kết nối thành công nêu mục 1.5.6.1 Cơ chế CM giải pháp SSG giảm thiểu tác hại công chuyển mạch tốc độ cơng đó, mức độ chiếm dụng tài nguyên mức dao động khoảng 300 MB nhớ 30% CPU - So sánh chế CM giải pháp SSG cho thấy mức độ chiếm dụng tài nguyên chuyển mạch SSG thấp chế CM Đặc biệt, tốc độ công tăng cao (từ 2.500 pps đến 5.500 pps) chế CM tiêu thụ tài nguyên CPU cao nhiều so với SSG, mức xấp xỉ 75% SSG khoảng 28% Đây nguyên nhân gây nên sụt giảm tỷ lệ kết nối thành cơng trình bày mục 3.5.4.1 - Sự cải thiện mức độ chiếm dụng tài nguyên khả xử lý gói tin OFS SSG so với chế CM di chuyển chức giám sát trình 3HS kết nối TCP từ OFS tới SD Kết đo thống kê Hình 3.22 cho thấy mức độ chiếm dụng 101 tài nguyên SD không bị ảnh hưởng nhiều tốc độ công tăng lên So sánh với trường hợp khơng có cơng SYN Flood, tốc độ cơng cao mơ hình thử nghiệm (5.500 pps), mức độ chiếm dụng nhớ SD tăng từ 180 MB lên 300 MB tổng số 2GB nhớ, mức độ chiếm dụng CPU tăng từ 12% lên 23% Tùy theo quy mô hệ thống mạng, chọn cấu hình SD phù hợp với yêu cầu xử lý chuyển mạch kết hợp giúp cho hệ thống tăng khả chịu đựng xử lý giảm thiểu cơng SYN Flood Hình 3.22 Sự chiếm dụng tài nguyên nhớ tài nguyên CPU OFS SD giải pháp thử nghiệm Mức độ gia tăng lưu lượng giao diện chuyển mạch So sánh với chế CM, di chuyển chức giám sát trình bắt tay ba bước kết nối TCP từ OFS thực thiết bị SD độc lập gây gia tăng tổng lưu lượng giao diện OFS Nội dung phần khảo sát gia tăng hai trường hợp khơng có cơng có cơng SYN Flood a) Khi khơng có cơng SYN Flood xảy ra: So sánh trao đổi gói tin SSG (sơ đồ Hình 3.16) chế CM (sơ đồ Hình 1.13) thấy kết nối TCP lành tính, chuyển mạch OFS chế CM phải thực 10 bước trao đổi giải pháp SSG, bước Trong số đó, bước trao đổi 102 chế CM theo giao thức Openflow SSG bước Các gói tin trao đổi cịn lại gói tin 3HS Như ta biết, gói tin 3HS giao thức TCP [32] thường gói tin TCP nhỏ với kích thước xấp xỉ 60 bytes Trong đó, tương tác giao thức Openflow tin dựa giao thức TCP mã hóa bảo mật chứa nhiều thông tin khác [45] nên kích thước chúng lớn nhiều so với gói tin bắt tay ba bước 3HS Bởi vậy, khơng có cơng xảy ra, lưu lượng giao diện OFS SSG nhỏ so với giải pháp CM Hình 3.23 Sự tương tác thực thể SSG q trình xử lý gói tin bắt tay ba bước kết nối lành tính b) Khi hệ thống chịu tác động công SYN Flood: Có trường hợp xảy ra: (1) Gói tin SYN lành tính có địa IP nằm danh sách Trusted_IPs, (2) Gói tin SYN lành tính có địa IP khơng nằm Trusted_IPs (3) Gói tin SYN giả mạo địa IP Trong trường hợp (1), OFS phải thực tương tác (Hình 3.23 a) trường hợp (2) 15 (Hình 3.23 b) So sánh tương tác cho thấy lưu lượng OFS SSG giảm so với CM gói tin trường hợp tăng gói tin trường hợp Đối với trường hợp (3), số tương tác OFS CM 2, SSG (Hình 3.24) Để đánh giá mức độ gia tăng lưu lượng OFS server bị công SYN Flood, lưu lượng cơng phân tích kết hợp với lưu lượng lành tính Lưu lượng lành tính lấy thống kê từ 100 server ngẫu nhiên liệu CAIDA 2013 [107] có đặc tính mơ tả Bảng 3.8 Kết phân tích, thống kê cho trường hợp 1/4, 1/2, 3/4 tất 103 máy chủ ứng dụng nội bị công SYN Floods thể Hình 3.25 Dữ liệu cho thấy hệ thống chịu công SYN Flood, so sánh với chế CM, tổng lưu lượng cần xử lý giao diện OFS SSG tăng với tỷ lệ nhỏ, mức 1,5% trường hợp nửa số máy chủ ứng dụng nội chịu công 2,5% tất số máy chủ nội bị công với tốc độ công 5.500 pps Hình 3.24 Sự tương tác thực thể q trình xử lý gói tin SYN giả mạo địa IP chế CM giải pháp SSG Bảng 3.8 Đặc tính thống kê lưu lượng lành tính phân tích từ lưu lượng CAIDA Số lượng server phân tích Thời gian phân tích Số lượng luồng TCP Số lượng luồng tạo mới/server/giây Tổng dung lượng trung bình máy chủ theo chiều client đến server Tốc độ liệu trung bình máy chủ chiều client đến server Tốc độ liệu trung bình máy chủ tính chiều Tỷ lệ trùng địa IP nguồn với gói tin SYN trước (thời gian đợi địa IP T IP-timeout = phút) 100 servers 45 phút 3.947.883 luồng 14,62 luồng/server/giây 11.658.649,46 bytes/server 5.181,62 bits/s/server 72.404.791,51 bits/s/server 44,7 % Hình 3.25 Mức độ gia tăng lưu lượng giao diện chuyển mạch giải pháp SSG so với chế CM 104 Mức độ giảm lưu lượng giao diện Openflow giảm tải điều khiển Cả chế CM Avant-Guard giải pháp SSG hoạt động nguyên tắc giám sát trình 3HS kết nối TCP cài đặt mục luồng cho kết nối tương ứng thực thành cơng q trình 3HS Ngun tắc ngăn chiếm dụng tài ngun vơ ích mục luồng tạo từ gói tin giả mạo địa IP nguồn, đồng thời bảo vệ điều khiển bị tải thực xử lý kiện packet-in từ gói tin giả mạo Theo đó, lưu lượng Openflow chuyển mạch điều khiển giảm xuống có cơng SYN Flood xảy So sánh q trình trao đổi gói tin điều khiển thực thể chế CM chế SSG mơ tả Hình 3.24 cho thấy với kết nối lành tính TCP, SSG cần lần yêu cầu controller chế CM lần Do đó, tổng số tin trao đổi chuyển mạch điều khiển để cài đặt mục luồng cho kết nối TCP lành tính SSG giảm nửa so với chế CM Sự cải tiến giúp giảm tải điều khiển, tăng khả chịu đựng công SYN Flood Nhận xét, đánh giá - Dựa kiến trúc SDN/Openflow mở rộng, chế ủy nhiệm gói tin SYN SD khắc phục nhược điểm chế CM giải pháp Avant-Guard trì tỷ lệ kết nối cao (98% so với CM mức 20% chịu công 5.500 pps), mức độ chiếm dụng tài nguyên OFS ổn định, bị ảnh hưởng cơng SYN Flood (chiếm 28% so với CM 75% CPU công 5.500pps) với mức độ gia tăng lưu lượng thấp (2,5% tất máy chủ chịu cơng 5.500pps) - SSG áp dụng cho tất chuyển mạch Openflow hỗ trợ 1.5, giúp OFS tăng khả chịu đựng cơng, áp dụng cho mạng quy mô lớn tất chuyển mạch biên 3.6 Kết luận chương - Các giải pháp phát lọc bỏ lưu lượng công DDoS dựa liệu thống kê chế xử lý gói tin kỹ thuật SDN/Openflow có ưu điểm đơn giản, dễ triển khai mạng SDN/Openflow tồn số nhược điểm cố hữu Đó (1) thơng tin lưu lượng bị giới hạn quy đinh giao thức Openflow, (2) chế quản lý luồng theo trạng thái gây gia tăng mục luồng chuyển mạch tạo nên chiếm dụng lớn nguồn tài ngun lớp hạ tầng mạng có cơng xảy ra, đồng thời (3) lưu lượng Openflow chuyển mạch điều khiển tăng cao Những nhược điểm làm giảm tính xác phát phân loại lưu lượng công, giới hạn quy mơ lưu lượng hệ thống mạng áp dụng, ngồi cịn dễ bị kẻ công lợi dụng trở thành mục tiêu công DDoS - Để khắc phục tồn trên, giải pháp phát giảm thiểu công DDoS sử dụng liệu thống kê chế xử lý gói tin kỹ thuật SDN/Openflow kết hợp với 105 phân tích xử lý lưu lượng SD bổ sung vào hệ thống mạng Dựa khả ánh xạ cổng (mirror port), chép gói tin tới cổng, kỹ thuật SDN/Openflow điều khiển chuyển lưu lượng theo ý muốn từ OFS tới SD phần mềm lớp ứng dụng SD cung cấp đầy đủ thơng tin thuộc tính mẫu lưu lượng cho ứng dụng bảo mật lớp điều khiển Sự kết hợp phân tích xử lý lưu lượng mạng SDN/Openflow có ưu điểm: • Có thể chuyển mẫu gói tin mong muốn từ chuyển mạch tới điều khiển không qua kênh bảo mật Openflow, tránh tượng thắt cổ chai giao diện • Có thể phân tích, cung cấp thuộc tính lưu lượng mà chế thống kê Openflow không thực • SD thực sách xử lý gói tin (như Drop trực tiếp) mà không qua chế cài đặt mục luồng giúp giảm thời gian đáp ứng hệ thống lưu lượng công, giảm chiếm dụng tài nguyên mục luồng công DDoS - Ứng dụng kiến trúc SDN/Openflow mở rộng với phân tích xử lý lưu lượng SD, giải pháp phát giảm thiểu cơng thuật tốn logic mờ cho độ nhạy lọc bỏ cao, tỷ lệ lọc bỏ nhầm thấp (DR F đạt 97,5% FPR F mức 3,6% so sánh với giải pháp TRW-CB đạt DR F 96% FPR F 25%) thời gian đáp ứng nhanh chế xóa bỏ gói tin công thực SD mà không chế Openflow thông thường - Bên cạnh lợi ích mặt an ninh mạng, kỹ thuật SDN/Openflow tồn lỗ hổng mới, có nguy bị công làm cạn kiệt tài nguyên chuyển mạch, điều khiển giao diện Openflow công SYN Flood giả mạo địa IP Kế thừa từ chế CM Avant-Guard, giải pháp đề xuất SSG thực ủy nhiệm gói tin SYN phân tích xử lý lưu lượng, thay ủy nhiệm gói tin SYN chuyển mạch Kết thực nghiệm testbed cho thấy SSG khắc phục tồn chế CM, cải thiện khả chịu đựng công SYN Flood hệ thống (duy trì tỷ lệ kết nối cao 98% so với CM mức 20% chịu công 5.500 pps), mức độ chiếm dụng tài nguyên OFS ổn định, bị ảnh hưởng cơng SYN Flood (chiếm 28% so với CM 75% CPU công 5.500pps) với mức độ gia tăng lưu lượng thấp (2,5% tất máy chủ chịu công 5.500pps) Các kết nghiên cứu Chương cơng bố cơng trình: [C2], [J2], [J4] (Xem Danh mục cơng trình cơng bố trang 108) 106 KẾT LUẬN Nội dung kết đạt luận án Nội dung Luận án trình bày chương sau: - Nội dung Chương trình bày lý thuyết tổng quan công DDoS, công nghệ SDN kỹ thuật SDN/Openflow, phương thức kỹ thuật phòng chống DDoS mạng truyền thống mạng SDN/Openflow Qua cho thấy, cơng DDoS vấn nạn lớn mạng Internet, phát triển quy mô, dịch vụ, lưu lượng mạng ngày tăng; diễn biến công DDoS ngày phức tạp đặt yêu cầu thách thức lớn chế, giải pháp phát hiện, phân loại lưu lượng giảm thiểu công DDoS, đặc biệt mạng quy mô nhỏ, nơi giải pháp an ninh mạng chưa trọng Công nghệ SDN, kỹ thuật mạng SDN/Openflow hứa hẹn công nghệ thay công nghệ mạng truyền thống với nhiều ưu thế, khả xử lý lưu lượng phần mềm phù hợp với quy trình phát giảm thiểu cơng DDoS Mặt khác, kiến trúc kỹ thuật mạng tạo nên lỗ hổng cố hữu mà kẻ cơng lợi dụng, phát động công DDoS Nhiệm vụ đặt cần phải khai thác lợi SDN/Openflow phát hiện, phòng chống DDoS bối cảnh khác nhau, đồng thời xây dựng giải pháp phòng chống công DDoS tới thực thể mạng Nội dung chương sở lý thuyết cho đề xuất chương - Chương trình bày giải pháp đề xuất yêu cầu phòng chống DDoS khác mạng quy mô lưu lượng nhỏ túy dựa liệu thống kê lưu lượng chế xử lý gói tin kỹ thuật SDN/Openflow, khơng cần bổ sung thiết bị chuyên dụng Cụ thể, giải pháp đề xuất bao gồm: (1) kỹ thuật phát giảm thiểu cơng DDoS dựa mơ hình dự đoán làm trơn hàm mũ tham số thống kê lưu lượng; (2) kỹ thuật phát ngăn chặn công SYN Flood tới máy chủ hệ thống mạng dựa chế ủy nhiệm gói tin SYN điều khiển; (3) kỹ thuật đánh dấu gói tin PLA DFM hỗ trợ truy vết nguồn phát sinh lưu lượng công Các kết phân tích mơ lưu lượng cơng thực từ lưu lượng CAIDA Netnam, kết chạy mơ hình thử nghiệm testbed cho thấy hiệu giải pháp đề xuất cải thiện so với giải pháp cơng bố áp dụng trực tiếp hệ thống mạng SDN/Openflow quy mơ lưu lượng nhỏ mạng gia đình, văn phịng nhỏ Các kết chương đăng cơng trình cơng bố [C1], [J1] [J3] - Để đáp ứng yêu cầu cho mạng có quy mô lưu lượng cao giảm thời gian đáp ứng hệ thống, nội dung Chương đề xuất kiến trúc SDN/Openflow mở rộng bổ sung phân tích xử lý lưu lượng SD Khác với giải pháp đề xuất, SD hoạt động tương tác với thực thể mạng SDN điều khiển phần mềm lớp ứng dụng cung cấp đầy đủ thơng tin thuộc tính mẫu lưu lượng cho ứng dụng bảo mật lớp điều khiển Dựa kiến trúc SDN mở rộng, giải pháp phịng chống cơng DDoS kết hợp liệu thống kê lưu lượng SDN/Openflow SD làm tăng độ xác 107 phát hiện, phân loại, khơng làm tăng lưu lượng giao diện Openflow; xử lý, xóa bỏ lưu lượng cơng trực tiếp SD giúp giảm thời gian đáp ứng hệ thống Áp dụng kiến trúc SDN mở rộng, Chương đề xuất kỹ thuật phân loại giảm thiểu công DDoS dựa thuật toán logic mờ kỹ thuật giảm thiểu công SYN Flood tới mạng SDN/Openflow sử dụng chế ủy nhiệm gói tin SYN SD Các kết phân tích mơ lưu lượng công thực từ lưu lượng CAIDA Netnam, kết chạy mơ hình thử nghiệm testbed cho thấy hiệu giải pháp đề xuất cải thiện so với giải pháp công bố Các kết chương đăng cơng trình cơng bố [C2], [J2] [J4] Đóng góp khoa học luận án: Luận án thực 02 đóng góp khoa học sau đây: Đề xuất kỹ thuật phát giảm thiểu cơng DDoS mơ hình dự đốn làm trơn hàm mũ với tham số thống kê lưu lượng; kỹ thuật đánh dấu gói tin phục vụ truy vết nguồn phát sinh lưu lượng công; kỹ thuật giảm thiểu công SYN Flood chế ủy nhiệm gói tin SYN sử dụng cơng nghệ SDN Đề xuất kiến trúc SDN/Openflow mở rộng với phân tích xử lý lưu lượng để nâng cao hiệu phát giảm thiểu công DDoS Hướng phát triển luận án: Do giới hạn điều kiện triển khai hệ thống nghiên cứu, Luận án cịn số hạn chế sau: • Chưa xây dựng botnet với lưu lượng công, nguồn cơng đủ lớn để đo tính tốn hiệu xử lý thời gian thực giải pháp, ảnh hưởng lưu lượng tương tác máy chủ máy khách Do giải pháp phân loại, phát giảm thiểu công chủ yếu phân tích lưu lượng chiều, chưa đánh giá số tham số hiệu giải pháp thời gian đáp ứng, mức độ chịu tải,… Chưa nghiên cứu, đánh giá hiệu giải pháp loại công DDoS riêng Để tiếp tục nghiên cứu, phát triển kết đạt được, giải hạn chế, mở rộng phạm vi nghiên cứu ứng dụng thực tế, hướng nghiên cứu luận án đề xuất gồm: • • Nghiên cứu triển khai hệ thống mạng thật, đặc biệt, xây dựng hệ thống botnet có quy mô lớn để mô lưu lượng công lưu lượng lành tính gần giống với mạng thực • Khảo sát đo số tham số hiệu giải pháp chưa thực thời gian đáp ứng, tốc độ gia tăng lưu lượng, xác định chu kỳ giám sát tối ưu, v.v… • Tiếp tục đề xuất giải pháp phòng chống DDoS dựa kỹ thuật SDN/Openflow theo loại công sở nghiên cứu đặc tính cơng cụ cơng phổ biến có để nâng cao hiệu phát giảm thiểu công 108 DANH MỤC CÁC CƠNG TRÌNH ĐÃ CƠNG BỐ CỦA LUẬN ÁN Các cơng trình cơng bố kết trực tiếp luận án [C1] - Dang Van Tuyen, Truong Thu Huong, Nguyen Huu Thanh, Nguyen Tai Hung, Bart Buype, Didier Colle, Kris Steenhaut, (2014), “An Enhanced Deterministic Flow Marking Technique to Efficiently Support Detection of Network Spoofing Attacks”, in The 2014 International Conference on Advanced Technologies for Communications (ATC'14), Hanoi, Vietnam, Oct 15-17, 2014, pages 446-451, DOI: https://doi.org/ 10.1109/ATC.2014.7043429 [C2] - Phan Van Trung, Truong Thu Huong, Dang Van Tuyen, Duong Minh Duc, Nguyen Huu Thanh, Alan Marshall, (2015), “A Multi-Criteria-based DDoS-Attack Prevention Solution using Software Defined Networking”, in The 2015 International Conference on Advanced Technologies for Communications (ATC'15), Hochiminh City, Vietnam, Oct 14-16, 2015, pages 308-313, DOI: https://doi.org/10.1109/ ATC.2015.7388340 [J1] - Đặng Văn Tuyên, Trương Thu Hương, Nguyễn Tài Hưng, (2015), “Đề xuất giải pháp phát giảm thiểu tác hại công DDoS phương pháp thống kê dựa kỹ thuật mạng cấu hình phần mềm SDN”, Tạp chí Khoa học Công nghệ, Đại học Đà nẵng, Số 11(96)/2015, ISSN: 1859-1531, trang 208-213 [J2] - Tuyen Dang-Van, Huong Truong-Thu, (2016), “A Multi-Criteria based Software Defined Networking System Architecture for DDoS-Attack Mitigation”, REV Journal on Electronics and Communications, Radio and Electronics Association of Vietnam, ISSN: 1859-378X, Vol 6, No 3–4, July–December, 2016, pages 50-58, DOI: http://dx.doi.org/ 10.21553/rev-jec.123 [J3] - Dang Van Tuyen, Truong Thu Huong, Nguyen Huu Thanh, Pham Ngoc Nam, Nguyen Ngoc Thanh, Alan Marshall, (2018), “SDN-based SYN Proxy - A solution to enhance performance of attack mitigation under TCP SYN flood”, The Computer Journal - Section D: Security in Computer Systems and Networks, Volume 62, Issue 4, April 2019, Pages 518–534, Oxford University Press, ISSN: 0010-4620 (Online: 1460-2067) (SCIE), DOI: https://doi.org/10.1093/comjnl/bxy117 [J4] - Dang Van Tuyen, Truong Thu Huong, (2018), “SSG - A solution to prevent saturation attack on the data plane and control plane in SDN/Openflow network”, Journal of Research and Development on Information and Communication Technology, Vietnam’s Ministry of Information and Communications, ISSN: 1859-3534, DOI: http://dx.doi.org/10.32913/rd-ict.833, (Chấp nhận đăng Vol E-2, No 16, 2019) Các cơng trình cơng bố có liên quan đến luận án [C3] - Trung V Phan, Truong Van Toan, Dang Van Tuyen, Truong Thu Huong, Nguyen Huu Thanh, (2016), “OpenFlowSIA: An Optimized Protection Scheme for SoftwareDefined Networks from Flooding Attacks”, in The 2016 IEEE Sixth International Conference on Communications and Electronics (IEEE ICCE 2016), Halong, Quangninh, Vietnam, July 27-29, 2016, pages 14-18, DOI: https://doi.org/10.1109/ CCE.2016.7562606 109 TÀI LIỆU THAM KHẢO [1] Roger M Needham, “Denial of Service: An Example,” Commun ACM, vol 37, no 11, pp 42–46, Nov 1994 [2] J Mirkovic and P Reiher, “A taxonomy of DDoS attack and DDoS defense mechanisms,” ACM SIGCOMM Comput Commun Rev., vol 34, no 2, p 39, Apr 2004 [3] S T Zargar, J Joshi, and D Tipper, “A Survey of Defense Mechanisms Against Distributed Denial of Service (DDoS) Flooding Attacks,” IEEE Commun Surv Tutor., vol 15, no 4, pp 2046–2069, Apr 2013 [4] E Alomari, S Manickam, B B Gupta, S Karuppayah, and R Alfaris, “Botnet-based Distributed Denial of Service (DDoS) Attacks on Web Servers: Classification and Art,” Int J Comput Appl., vol 49, no 7, pp 24–32, Jul 2012 [5] VeriSign, Inc., “Verisign DDoS Trends Report - Volume 3, Issue - 4th Quarter 2016.” Verisign Pubic, Jan-2017 [6] Nexusguard Limited, “Threat Report - Distributed Denial of Service (DDoS) - Q3 2018.” NexusGuard, Oct-2018 [7] Kaspersky Lab., “DDoS Attacks in Q3 2018.” [Online] Available: https://securelist.com/ ddos-report-in-q3-2018/88617/ [Accessed: 07-Jan-2019] [8] A Networks, “NETSCOUT Arbor’s 2018 Annual Worldwide Infrastructure Security Report,” Arbor Networks® [Online] Available: https://www.netscout.com/report [Accessed: 20-Jan-2019] [9] T Kanti Srikantaiah and D Xiaoying, “The Internet and its impact on developing countries: examples from China and India,” Asian Libr., vol 7, no 9, pp 199–209, Sep 1998 [10] C Fu, G Zhang, J Yang, and X Liu, “Study on the contract characteristics of Internet architecture,” Enterp Inf Syst., vol 5, no 4, pp 495–513, Nov 2011 [11] J Fang, W Jintao, and T Wei, “On the Relationship between Internet and Traditional Communication Industry,” Insight - News Media, vol 1, no 1, pp 1–6, 2018 [12] L A Mohammed et al., “On the Design of SOHO Networks,” in Technological Developments in Networking, Education and Automation, Springer Netherlands, 2010, pp 555–560 [13] P Szewczyk and R Macdonald, “Broadband router security: History, challenges and future implications,” J Digit Forensics Secur Law, vol 12, no 4, pp 55–74, Jan 2017 [14] E Basinya and A Rudkovskiy, “Automatic Traffic Control System for SOHO Computer Networks,” in Recent Research in Control Engineering and Decision Making International Conference on Information Technologies: Information and Communication Technologies for Research and Industry (ICIT-2019), Saratov, Russia, 2019, pp 743– 754 110 [15] M H Bhuyan, H J Kashyap, D K Bhattacharyya, and J K Kalita, “Detecting Distributed Denial of Service Attacks: Methods, Tools and Future Directions,” Comput J., vol 57, no 4, pp 537–556, Apr 2014 [16] Y Kim, W C Lau, M C Chuah, and H J Chao, “PacketScore: a statistics-based packet filtering scheme against distributed denial-of-service attacks,” IEEE Trans Dependable Secure Comput., vol 3, no 2, pp 141–155, Apr 2006 [17] C.-F Tsai, Y.-F Hsu, C.-Y Lin, and W.-Y Lin, “Intrusion detection by machine learning: A review,” Expert Syst Appl., vol 36, no 10, pp 11994–12000, Dec 2009 [18] Eddy Wesley M., “Defenses Against TCP SYN Flooding Attacks,” Internet Protoc J., vol 9, no 4, pp 2–16, Dec 2006 [19] Open Networking Foundation, “SDN Architecture Overview Version 1.0,” 12-Dec-2013 [Online] Available: https://www.opennetworking.org/images/stories/downloads/sdnresources/technical-reports/SDN-architecture-overview-1.0.pdf [Accessed: 12-Jul2018] [20] Open Networking Foundation, “OpenFlow Switch Specification Version 1.5.1 (Protocol version 0x06),” 26-Mar-2015 [Online] Available: https://www.opennetworking.org/wpcontent/uploads/2014/10/openflow-switch-v1.5.1.pdf [Accessed: 12-Jul-2018] [21] K Giotis, C Argyropoulos, G Androulidakis, D Kalogeras, and V Maglaris, “Combining OpenFlow and sFlow for an effective and scalable anomaly detection and mitigation mechanism on SDN environments,” Comput Netw., vol 62, pp 122–136, Apr 2014 [22] R Braga, E Mota, and A Passito, “Lightweight DDoS flooding attack detection using NOX/OpenFlow,” in IEEE Local Computer Network Conference, Denver, CO, USA, 2010, pp 408–415 [23] C.-J Chung, P Khatkar, T Xing, J Lee, and D Huang, “NICE: Network Intrusion Detection and Countermeasure Selection in Virtual Network Systems,” IEEE Trans Dependable Secure Comput., vol 10, no 4, pp 198–211, Jul 2013 [24] S Lim, J Ha, H Kim, Y Kim, and S Yang, “A SDN-oriented DDoS blocking scheme for botnet-based attacks,” in 2014 Sixth International Conference on Ubiquitous and Future Networks (ICUFN), Shanghai, China, 2014, pp 63–68 [25] T Xing, D Huang, L Xu, C J Chung, and P Khatkar, “SnortFlow: A OpenFlow-based intrusion prevention system in cloud environment,” in Proceedings - 2013 2nd GENI Research and Educational Experiment Workshop, GREE 2013, Salt Lake, Utah, USA, 2013, pp 89–92 [26] T Chin, X Mountrouidou, X Li, and K Xiong, “Selective Packet Inspection to Detect DoS Flooding Using Software Defined Networking (SDN),” in 2015 IEEE 35th International Conference on Distributed Computing Systems Workshops, Columbus, OH, USA, 2015, pp 95–99 [27] Sufian Hameed and Hassan Ahmed Khan, “SDN Based Collaborative Scheme for Mitigation of DDoS Attacks,” Future Internet, vol 10, no 3, p 23, Feb 2018 [28] S Shin, V Yegneswaran, P Porras, and G Gu, “AVANT-GUARD: scalable and vigilant switch flow management in software-defined networks,” in Proceedings of the 2013 111 ACM SIGSAC conference on Computer & communications security - CCS ’13, Berlin, Germany, 2013, pp 413–424 [29] M Ambrosin, M Conti, F De Gaspari, and R Poovendran, “LineSwitch: Efficiently Managing Switch Flow in Software-Defined Networking While Effectively Tackling DoS Attacks,” in Proceedings of the 10th ACM Symposium on Information, Computer and Communications Security, New York, NY, USA, 2015, pp 639–644 [30] M Ambrosin, M Conti, F De Gaspari, and R Poovendran, “LineSwitch: Tackling Control Plane Saturation Attacks in Software-Defined Networking,” IEEEACM Trans Netw., vol 25, no 2, pp 1206–1219, Nov 2016 [31] V D Gligor, “A Note on Denial-of-Service in Operating Systems,” Softw Eng IEEE Trans On, vol SE-10, no 3, pp 320–324, Jun 1984 [32] Q Yan, F R Yu, Q Gong, and J Li, “Software-Defined Networking (SDN) and Distributed Denial of Service (DDoS) Attacks in Cloud Computing Environments: A Survey, Some Research Issues, and Challenges,” IEEE Commun Surv Tutor., vol 18, no 1, pp 602–622, Firstquarter 2016 [33] T Peng, C Leckie, and K Ramamohanarao, “Survey of Network-based Defense Mechanisms Countering the DoS and DDoS Problems,” ACM Comput Surv., vol 39, no 1, Apr 2007 [34] F Lau, S H Rubin, M H Smith, and L Trajkovic, “Distributed denial of service attacks,” in Proceedings of 2000 IEEE International Conference on Systems, man and cybernetics “Cybernetics evolving to systems, humans, organizations, and their complex interactions,” Nashville, TN, USA, 2000, vol 3, pp 2275–2280 vol.3 [35] N Dayal, P Maity, S Srivastava, and R Khondoker, “Research Trends in Security and DDoS in SDN: Research Trends in Security and DDoS in SDN,” Secur Commun Netw., vol 9, no 18, pp 6386–6411, Dec 2016 [36] C Douligeris and A Mitrokotsa, “DDoS attacks and defense mechanisms: Classification and state-of-the-art,” Comput Netw., vol 44, no 5, pp 643–666, Apr 2004 [37] O Yevsieieva and S M Helalat, “Analysis of the impact of the slow HTTP DOS and DDOS attacks on the cloud environment,” in 2017 4th International Scientific-Practical Conference Problems of Infocommunications Science and Technology (PICST), Kharkov, Ukraine, 2017, pp 519–523 [38] Abor Networks, “13th Worldwide Infrastructure Security Report,” 2018 [Online] Available: https://pages.arbornetworks.com/rs/082-KNA-087/images/13th_Worldwide_ Infrastructure_Security_Report.pdf [Accessed: 28-Dec-2018] [39] Postel, J., “Transmission Control Protocol, DAPRA Internet Program - Protocol Specification, RFC 793,” Sep-1981 [Online] Available: https://tools.ietf.org/ html/rfc793 [40] W M Eddy , “TCP SYN Flooding Attacks and Common Mitigations.” [Online] Available: https://tools.ietf.org/html/rfc4987 [Accessed: 18Nov-2018] [41] A T Mizrak, S Savage, and K Marzullo, “Detecting compromised routers via packet forwarding behavior,” IEEE Netw., vol 22, no 2, pp 34–39, Mar 2008 112 [42] K Park and H Lee, “On the Effectiveness of Route-based Packet Filtering for Distributed DoS Attack Prevention in Power-law Internets,” in Proceedings of the 2001 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications, New York, NY, USA, 2001, pp 15–26 [43] J M Gonzalez, M Anwar, and J B D Joshi, “A trust-based approach against IPspoofing attacks,” in 2011 Nineth Annual International Conference on Privacy, Security and Trust (PST 2011), Montreal, Quebec, Canada, 2011, pp 63–70 [44] J R Hughes, T Aura, and M Bishop, “Using conservation of flow as a security mechanism in network protocols,” in Proceeding 2000 IEEE Symposium on Security and Privacy (SP 2000), Berkeley, California, USA, 2000, pp 132–141 [45] J Mirkovic, G Prier, and P Reiher, “Attacking DDoS at the source,” in Proceedings of the 10th IEEE International Conference on Network Protocols (ICNP 2002), Paris, France, 2002, pp 312–321 [46] A Yaar, A Perrig, and D Song, “Pi: a path identification mechanism to defend against DDoS attacks,” in 2003 Symposium on Security and Privacy, Berkeley, CA, USA, 2003, pp 93–107 [47] Y Xiang, W Zhou, and M Guo, “Flexible Deterministic Packet Marking: An IP Traceback System to Find the Real Source of Attacks,” IEEE Trans Parallel Distrib Syst., vol 20, no 4, pp 567–580, Apr 2009 [48] V Aghaei-Foroushani and A N Zincir-Heywood, “On Evaluating IP Traceback Schemes: A Practical Perspective,” in 2013 IEEE Security and Privacy Workshops (SPW), University of California, Berkeley, USA, 2013, pp 127–134 [49] S Savage, D Wetherall, A Karlin, and T Anderson, “Practical Network Support for IP Traceback,” in Proceedings of the Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication, New York, NY, USA, 2000, pp 295–306 [50] A Belenky and N Ansari, “Tracing multiple attackers with deterministic packet marking (DPM),” in 2003 IEEE Pacific Rim Conference on Communications Computers and Signal Processing (PACRIM 2003) (Cat No.03CH37490), Victoria, BC, Canada, 2003, vol 1, pp 49–52 vol.1 [51] Daniel J Bernstein, “SYN cookies.” syncookies.html [Accessed: 30-Aug-2018] [Online] Available: https://cr.yp.to/ [52] P Gogoi, D K Bhattacharyya, B Borah, and J K Kalita, “A Survey of Outlier Detection Methods in Network Anomaly Identification,” Comput J., vol 54, no 4, pp 570–588, Apr 2011 [53] M Ahmed, A Naser Mahmood, and J Hu, “A survey of network anomaly detection techniques,” J Netw Comput Appl., vol 60, pp 19–31, Jan 2016 [54] A Patcha and J.-M Park, “An overview of anomaly detection techniques: Existing solutions and latest technological trends,” Comput Netw., vol 51, no 12, pp 3448–3470, Aug 2007 [55] M Javed, A B Ashfaq, M Z Shafiq, and S A Khayam, “On the Inefficient Use of Entropy for Anomaly Detection,” in Recent Advances in Intrusion Detection, vol 5758, 113 E Kirda, S Jha, and D Balzarotti, Eds Berlin, Heidelberg: Springer Berlin Heidelberg, 2009, pp 369–370 [56] S Mukkamala, G Janoski, and A Sung, “Intrusion detection using neural networks and support vector machines,” in Proceedings of the 2002 International Joint Conference on Neural Networks IJCNN’02 (Cat No.02CH37290), Honolulu, HI, USA, 2002, vol 2, pp 1702–1707 vol.2 [57] C Kruegel, D Mutz, W Robertson, and F Valeur, “Bayesian event classification for intrusion detection,” in 19th Annual Computer Security Applications Conference, 2003 Proceedings., Las Vegas, Nevada, USA, 2003, pp 14–23 [58] H Gunes Kayacik, A Nur Zincir-Heywood, and M I Heywood, “A hierarchical SOMbased intrusion detection system,” Eng Appl Artif Intell., vol 20, no 4, pp 439–451, Jun 2007 [59] T Komatsu and A Namatame, “On the Effectiveness of Rate-Limiting Methods to Mitigate Distributed DoS (DDoS) Attacks,” IEICE Trans Commun., vol E90-B, no 10, pp 2665–2672, Oct 2007 [60] N Z Bawany, J A Shamsi, and K Salah, “DDoS Attack Detection and Mitigation Using SDN: Methods, Practices, and Solutions,” Arab J Sci Eng., vol 42, no 2, pp 425–441, Feb 2017 [61] Bradley Mitchell, “How SOHO Routers and Networks Differ From Ordinary Ones,” Lifewire [Online] Available: https://www.lifewire.com/soho-routers-and-networksexplained-3971344 [Accessed: 02-Apr-2019] [62] A Bisong and S S M Rahman, “An Overview Of The Security Concerns In Enterprise Cloud Computing,” Int J Netw Secur Its Appl., vol 3, no 1, pp 30–45, Jan 2011 [63] D Oxenhandler, “Designing a Secure Local Area Network,” SANS Institute, 2003 [Online] Available: https://www.sans.org/reading-room/whitepapers/bestprac/ designing-secure-local-area-network-853 [Accessed: 12-Dec-2018] [64] J Hietala, “Network Security- A Guide for Small and Mid-sized Businesses,” SANS Institute, 2005 [Online] Available: https://www.sans.org/reading-room/whitepapers/ basics/network-security-guide-small-mid-sized-businesses-1539 [Accessed: 12-Dec2018] [65] “SDN Controller Vendors (SDN Controller Companies) - Part 1.” [Online] Available: https://www.sdxcentral.com/sdn/definitions/sdn-controllers/sdn-controllerscomprehensive-list/ [Accessed: 30-Dec-2018] [66] “SDN Controller Comparison Part 2: Open Source SDN Controllers.” [Online] Available: https://www.sdxcentral.com/sdn/definitions/sdn-controllers/open-source-sdncontrollers/ [Accessed: 30-Dec-2018] [67] S Jain et al., “B4: Experience with a Globally-deployed Software Defined Wan,” in Proceedings of the ACM SIGCOMM 2013 Conference on SIGCOMM, New York, NY, USA, 2013, pp 3–14 [68] “Huawei Agile Campus Network Solution Brochure (Compact Version),” Huawei Enterprise [Online] Available: https://e.huawei.com/en/material/ 114 onLineView?MaterialID=de61d5ca95954c85bd96e2e9c9108401 [Accessed: 30-Dec2018] [69] The Linux Foundation Collaborative Project, “Open vSwitch.” [Online] Available: https://www.openvswitch.org/ [Accessed: 18-Aug-2018] [70] “The POX network software platform,” GitHub [Online] Available: https://github.com/ noxrepo/pox [Accessed: 28-Aug-2018] [71] “Ryu SDN Framework.” [Online] Available: https://osrg.github.io/ryu/ [Accessed: 18Nov-2018] [72] P Berde et al., “ONOS: towards an open, distributed SDN OS,” in Proceedings of the third workshop on Hot topics in Software Defined Networking - HotSDN ’14, Chicago, Illinois, USA, 2014, pp 1–6 [73] “OpenDaylight.” [Online] Available: https://www.opendaylight.org/ [Accessed: 18Nov-2018] [74] “Floodlight OpenFlow Controller,” Project Floodlight [Online] http://www.projectfloodlight.org/floodlight/ [Accessed: 26-Sep-2018] Available: [75] NOX Repo, “The NOX Controller,” 10-Oct-2018 https://github.com/noxrepo/nox [Accessed: 18-Nov-2018] Available: [Online] [76] “Mininet: An Instant Virtual Network on your Laptop (or other PC) - Mininet.” [Online] Available: http://mininet.org/ [Accessed: 30-Dec-2018] [77] R Wang, Z Jia, and L Ju, “An Entropy-Based Distributed DDoS Detection Mechanism in Software-Defined Networking,” in Proceedings of the 2015 IEEE Trustcom/BigDataSE/ISPA - Volume 01, Washington, DC, USA, 2015, pp 310–317 [78] S A Mehdi, J Khalid, and S A Khayam, “Revisiting Traffic Anomaly Detection Using Software Defined Networking,” in Recent Advances in Intrusion Detection, vol 6961, R Sommer, D Balzarotti, and G Maier, Eds Berlin, Heidelberg: Springer Berlin Heidelberg, 2011, pp 161–180 [79] S Dotcenko, A Vladyko, and I Letenko, “A fuzzy logic-based information security management for software-defined networks,” in 16th International Conference on Advanced Communication Technology, Pyeongchang, Korea (South), 2014, pp 167–171 [80] R Jin and B Wang, “Malware Detection for Mobile Devices Using Software-Defined Networking,” in 2013 Second GENI Research and Educational Experiment Workshop, Salt Lake, UT, USA, 2013, pp 81–88 [81] C Dillon and M Berkelaar, “OpenFlow (D)DoS Mitigation.” [Online] Available: http://www.delaat.net/rp/2013-2014/p42/presentation.pdf [Accessed: 28-Dec-2018] [82] S Shin, P Porras, V Yegneswaran, M Fong, G Gu, and M Tyson, “FRESCO: Modular Composable Security Services for Software-Defined Networks,” in Network and Distributed System Security Symposium, San Diego, California, 2013, pp 1–16 [83] S E Schechter, J Jung, and A W Berger, “Fast Detection of Scanning Worm Infections,” in Proceedings of the International Workshop on Recent Advances in Intrusion Detection (RAID 2004), Sophia Antipolis, France, 2004, pp 59–81 115 [84] M M Williamson, “Throttling viruses: restricting propagation to defeat malicious mobile code,” in Proceedings of the 18th Annual Computer Security Applications Conference, 2002, Las Vegas, NV, USA, 2002, pp 61–68 [85] S T Ali, V Sivaraman, A Radford, and S Jha, “A Survey of Securing Networks Using Software Defined Networking,” IEEE Trans Reliab., vol 64, no 3, pp 1086–1097, Sep 2015 [86] A F M Piedrahita, S Rueda, D M F Mattos, and O C M B Duarte, “Flowfence: a denial of service defense system for software defined networking,” in Proceedings of the 2015 Global Information Infrastructure and Networking Symposium (GIIS 2015), Guadalajara, Mexico, 2015, pp 1–6 [87] L von Ahn, M Blum, N J Hopper, and J Langford, “CAPTCHA: Using Hard AI Problems for Security,” in Proceedings of the International Conference on the Theory and Applications of Cryptographic Techniques - Advances in Cryptology — EUROCRYPT 2003, Warsaw, Poland, 2003, pp 294–311 [88] E Al-Shaer and S Al-Haj, “FlowChecker: configuration analysis and verification of federated openflow infrastructures,” in Proceedings of the 3rd ACM workshop on Assurable and usable security configuration, Chicago, IL, USA, 2010, pp 37–44 [89] “FlowVisor: A network hypervisor,” 12-Dec-2018 [Online] https://github.com/opennetworkinglab/flowvisor [Accessed: 10-Jul-2018] Available: [90] “Network Verification Tools,” Veriflow [Online] Available: https://www.veriflow.net/ [Accessed: 02-Jan-2019] [91] G Yao, J Bi, and P Xiao, “Source address validation solution with OpenFlow/NOX architecture,” in 2011 19th IEEE International Conference on Network Protocols, Vancouver, AB, Canada, 2011, pp 7–12 [92] R Kandoi and M Antikainen, “Denial-of-service attacks in OpenFlow SDN networks,” in 2015 IFIP/IEEE International Symposium on Integrated Network Management (IM), Ottawa, Canada, 2015, pp 1322–1326 [93] P Zhang, H Wang, C Hu, and C Lin, “On Denial of Service Attacks in Software Defined Networks,” IEEE Netw., vol 30, no 6, pp 28–33, Nov 2016 [94] R Kloti, V Kotronis, and P Smith, “OpenFlow: A security analysis,” in 2013 21st IEEE International Conference on Network Protocols (ICNP), Goettingen, Germany, 2013, pp 1–6 [95] D Kreutz, F M V Ramos, and P Verissimo, “Towards secure and dependable softwaredefined networks,” in Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking - HotSDN ’13, Hong Kong, China, 2013, p 55 [96] B Wang, Y Zheng, W Lou, and Y T Hou, “DDoS Attack Protection in the Era of Cloud Computing and Software-Defined Networking,” in 2014 IEEE 22nd International Conference on Network Protocols, Raleigh, NC, USA, 2014, pp 624–629 [97] L Wei and C Fung, “FlowRanger: A request prioritizing algorithm for controller DoS attacks in Software Defined Networks,” in 2015 IEEE International Conference on Communications (ICC), London, England, 2015, pp 5254–5259 116 [98] N I Mowla, I Doh, and K Chae, “Multi-defense Mechanism against DDoS in SDN Based CDNi,” in 2014 Eighth International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing, Birmingham, UK, 2014, pp 447–451 [99] S Fichera, L Galluccio, S C Grancagnolo, G Morabito, and S Palazzo, “OPERETTA: An OPEnflow-based REmedy to mitigate TCP SYNFLOOD Attacks against web servers,” Comput Netw., vol 92, Part 1, pp 89–100, Dec 2015 [100] X Wang, M Chen, and C Xing, “SDSNM: A Software-Defined Security Networking Mechanism to Defend against DDoS Attacks,” in 2015 Ninth International Conference on Frontier of Computer Science and Technology (FCST), Dalian, China, 2015, pp 115– 121 [101] F R Johnston, J E Boyland, M Meadows, and E Shale, “Some Properties of a Simple Moving Average when Applied to Forecasting a Time Series,” J Oper Res Soc., vol 50, pp 1267–1271, Dec 1999 [102] S H Shih and C P Tsokos, “A Weighted Moving Average Process for Forecasting,” J Mod Appl Stat Methods, vol 7, no 1, pp 187–197, May 2008 [103] Bo Zhou, Dan He, and Zhili Sun, “Traffic Modeling and Prediction using ARIMA/GARCH Model,” in Modeling and Simulation Tools for Emerging Telecommunication Networks, A Nejat Ince and Ercan Topuz, Eds Springer International Publishing, 2006, pp 101–121 [104] Y Zhuang, L Chen, X S Wang, and J Lian, “A Weighted Moving Average-based Approach for Cleaning Sensor Data,” in 27th International Conference on Distributed Computing Systems (ICDCS ’07), Toronto, ON, Canada, 2007, pp 38–38 [105] R J Hyndman, A B Koehler, R D Snyder, and S Grose, “A state space framework for automatic forecasting using exponential smoothing methods,” Int J Forecast., vol 18, no 3, pp 439–454, 2002 [106] F Wamser, R Pries, D Staehle, K Heck, and P Tran-Gia, “Traffic characterization of a residential wireless Internet access,” Telecommun Syst., vol 48, no 1–2, pp 5–17, Oct 2011 [107] Center for Applied Internet Data, “The CAIDA Anonymized Internet Traces 2013 Dataset,” CAIDA [Online] Available: http://www.caida.org/data/ passive/passive_2013_dataset.xml [Accessed: 29-Sep-2018] [108] Center for Applied Internet Data, “The CAIDA ‘DDoS Attack 2007’ Dataset,” CAIDA [Online] Available: http://www.caida.org/data/passive/ddos-20070804_dataset.xml [Accessed: 07-Jan-2019] [109] Philippe Biondi and the Scapy community, “Scapy,” Scapy Project [Online] Available: https://scapy.net/ [Accessed: 18-Nov-2018] [110] Radware & NEC Corporation of America, “Denial-of-Service (DoS) Secured Virtual Tenant Networks (VTN).” Radware, Ltd, 2012 [111] Kaspersky Lab., “DDoS attacks in Q1 2018.” [Online] Available: https://securelist.com/ ddos-report-in-q1-2018/85373/ [Accessed: 07-Dec-2018] [112] J Lemon, “Resisting SYN flood DoS attacks with a SYN cache,” in Proceedings of the BSDCon 2002, San Francisco, CA, USA, pp 89–98 117 [113] S Kumar, S Member, and R S Reddy Gade, “Evaluation of Microsoft Windows Servers 2008 & 2003 against Cyber Attacks,” J Inf Secur., vol 06, no 02, pp 155–160, 2015 [114] “NetFPGA.” [Online] Available: https://netfpga.org/site/#/ [Accessed: 10-Jan-2019] [115] Markus Goldstein, “BoNeSi: the DDoS Botnet Simulator,” BoNeSi, 02-Sep-2018 [Online] Available: https://github.com/Markus-Go/bonesi [Accessed: 06-Sep-2018] [116] “Tcpreplay - Pcap editing and replaying utilities.” https://tcpreplay.appneta.com/ [Accessed: 26-Sep-2018] [Online] Available: [117] “Linux.org,” Linux.org [Online] Available: https://www.linux.org/ [Accessed: 10-Jan2019] [118] S Savage, D Wetherall, A Karlin, and T Anderson, “Network support for IP traceback,” IEEEACM Trans Netw., vol 9, no 3, pp 226–237, Jun 2001 [119] J Liu, Z.-J Lee, and Y.-C Chung, “Dynamic probabilistic packet marking for efficient IP traceback,” Comput Netw., vol 51, no 3, pp 866–882, Feb 2007 [120] V Paruchuri, A Durresi, R Kannan, and S Iyengar, “Authenticated Autonomous System Traceback,” in Proceedings of the 18th International Conference on Advanced Information Networking and Applications (AINA 2014), Fukuoka, Japan, 2004, vol 1, pp 406–413 [121] M Alenezi and M Reed, “Efficient AS DoS traceback,” in Proceedings of the International Conference on Computer Applications Technology, ICCAT 2013, Sousse,Tunisia, 2013, pp 1–5 [122] A Belenky and N Ansari, “IP traceback with deterministic packet marking,” IEEE Commun Lett., vol 7, no 4, pp 162–164, Apr 2003 [123] V K Soundar Rajam and S Shalinie, “A novel traceback algorithm for DDoS attack with marking scheme for online system,” in Proceedings of the 2012 International Conference on Recent Trends in Information Technology, Chennai, Tamil Nadu, India, 2012, pp 407–412 [124] K Nichols, D L Black, S Blake, and F Baker, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers.” [Online] Available: https://tools.ietf.org/ html/rfc2474 [Accessed: 10-Dec-2018] [125] S Floyd, K K Ramakrishnan, and D L Black, “The Addition of Explicit Congestion Notification (ECN) to IP.” [Online] Available: https://tools.ietf.org/html/rfc3168 [Accessed: 10-Jan-2019] [126] B Claise, “Cisco Systems NetFlow Services Export Version 9.” [Online] Available: https://tools.ietf.org/html/rfc3954 [Accessed: 18-Nov-2018] [127] D D Clark, “IP datagram reassembly algorithms.” https://tools.ietf.org/html/rfc815 [Accessed: 10-Jan-2019] [Online] Available: [128] W Simpson, “The Point-to-Point Protocol (PPP).” https://tools.ietf.org/html/rfc1661 [Accessed: 10-Jan-2019] [Online] Available: [129] S Shin and G Gu, “Attacking Software-defined Networks: A First Feasibility Study,” in Proceedings of the Second ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking, New York, NY, USA, 2013, pp 165–166 118 [130] S Scott-Hayward, S Natarajan, and S Sezer, “A Survey of Security in Software Defined Networks,” IEEE Commun Surv Tutor., vol 18, no 1, pp 623–654, 2016 [131] M Sugeno, Industrial Applications of Fuzzy Control New York, NY, USA: Elsevier Science Inc., 1985 [132] J L Deng, “Introduction to Grey System Theory,” J Grey Syst., vol 1, no 1, pp 1–24, Nov 1989 [133] S Liu and Y Lin, Grey Information: Theory and Practical Applications London: Springer-Verlag, 2006 [134] E Kayacan, B Ulutas, and O Kaynak, “Grey System Theory-based Models in Time Series Prediction,” Expert Syst Appl, vol 37, no 2, pp 1784–1789, Mar 2010 [135] S Wang, Q Sun, H Zou, and F Yang, “Detecting SYN flooding attacks based on traffic prediction: A demonstration of the security comm networks class file,” Secur Commun Netw., vol 5, no 10, pp 1131–1140, Oct 2012 [136] Open Networking Foundation, “OpenFlow Switch Specification Version 1.3.0 (Wire Protocol 0x04),” 25-Jun-2012 [Online] Available: https://www.opennetworking.org/ wp-content/uploads/2014/10/openflow-spec-v1.3.0.pdf [Accessed: 12-Jul-2018] [137] The Linux Foundation Projects, “Data Plane Development Kit (DPDK),” DPDK [Online] Available: https://www.dpdk.org/ [Accessed: 18-Aug-2018] [138] “Wireshark.” [Online] Available: https://www.wireshark.org/ [Accessed: 26-Sep2018]  ... GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI ĐẶNG VĂN TUYÊN NGHIÊN CỨU GIẢI PHÁP PHÁT HIỆN VÀ GIẢM THIỂU TẤN CÔNG TỪ CHỐI DỊCH VỤ PHÂN TÁN SỬ DỤNG CÔNG NGHỆ SDN Ngành: Kỹ thuật Viễn thông... lành tính phân tích từ lưu lượng CAIDA 103 xiv MỞ ĐẦU Tấn công từ chối dịch vụ phân tán công nghệ SDN 1.1 Tấn công từ chối dịch vụ phân tán - Trong năm gần đây, phát triển mạnh mẽ công nghệ thông... cho xuất phát từ nguồn công áp dụng quy tắc xóa bỏ Bảng 1.2 [35] thống kê so sánh giải pháp phát giảm thiểu công DDoS kiến trúc SDN theo kỹ thuật Bảng 1.2 So sánh kỹ thuật phát giảm thiểu công DDoS