Luận án Các giải pháp phát hiện và giảm thiểu tấn công DDOS cho mạng điều khiển bằng phần mềm

g một cách độc lập theo từng gói tin đến. Các quy tắc chuyển tiếp được lưu trữ trong bảng luồng dữ liệu, được triển khai với TCAM. TCAM tiêu tốn nhiều năng lượng, đắt tiền và có giới hạn về không gian lưu trữ nên nghiên cứu cũng đi sâu phân tích bảng luồng dữ liệu này. 51 Nhóm các máy chủ nạn nhân được sử dụng để quan sát hậu quả của các cuộc tấn công DDoS dưới góc nhìn của người dùng cũng như để thu thập dữ liệu tấn công đi qua mạng SDN. Mô-đun thu thập và phân tích dữ liệu thực hiện thu thập các thông tin khác nhau thông qua năm điểm đo tại các vị trí của mạng được đánh số như trong Hình 2.3: (1) đo lưu lượng truy cập đến bộ chuyển mạch SDN, (2) đo bảng luồng dữ liệu, (3) đo lưu lượng OpenFlow giữa bộ chuyển mạch và bộ điều khiển, (4) đo xử lý dữ liệu trong bộ điều khiển và (5) đo lưu lượng truy cập đi ra khỏi mạng SDN chuyển đến nhóm máy chủ. Mặc dù khái niệm SDN đã được nghiên cứu trong nhiều năm, các công cụ phân tích để kiểm tra các gói OpenFlow vẫn còn hạn chế. Nghiên cứu sinh đã phát triển các công cụ phân tích dựa trên Scapy [104] để trích xuất thông tin quan trọng từ các tệp dữ liệu để nghiên cứu chi tiết. Các tham số được trích xuất là số luồng yêu cầu mới trên mỗi giây, băng thông, số quy tắc được cài đặt vào thiết bị chuyển mạch SDN mỗi giây, kích thước bảng luồng dữ liệu và độ trễ xử lý luồng. Để đảm bảo tính chính xác của các phép đo, tất cả các thành phần trong mô hình thử nghiệm đã được đồng bộ hóa về thời gian với giao thức NTP. 2.2.2. Thông số cấu hình mô hình thử nghiệm Quá trình cài đặt luồng trong SDN được thực hiện thường xuyên và tự động theo mô hình thực tế của mạng. Khi mạng có sự thay đổi thì luồng cũng được cập nhật theo. Tuy nhiên, nó cũng bộc lộ lỗ hổng trước các cuộc tấn công DDoS như đã thảo luận ở phần trên. Phần này tập trung vào các cuộc tấn công dựa trên giao thức và dựa trên dung lượng, vì các cuộc tấn công lớp ứng dụng chủ yếu ảnh hưởng đến lớp bảy trong mô hình OSI và không có tác động lớn lên hệ thống SDN. Không làm mất tính tổng quát, TCP-SYN flood và ICMP/UDP flood được chọn là đại diện của hai hình thức tấn công nói trên vì các tấn công khác thuộc loại này đều gây ra các hành vi mạng giống nhau. Cấu hình và tham số thử nghiệm được mô tả trong Bảng 2.1. Mẫu lưu lượng tấn công thực cũng như các cuộc tấn công mô phỏng được tạo ra bằng cách sử dụng các phần mềm giả lập lưu lượng như TCPReplay hoặc BoNeSi hoặc bằng các thiết bị tạo lưu lượng phần cứng. Trong các thử nghiệm, mạng botnet thực hiện các cuộc tấn công tràn TCP-SYN và tràn ICMP tới nạn nhân nằm trong cụm máy chủ. Vì lưu lượng phải đi qua thiết bị chuyển mạch và bộ điều khiển SDN, nên có thể quan sát tác động của các cuộc tấn công lên các thành phần SDN. Để thực hiện các thử nghiệm nhằm đánh giá giới hạn của các thiết bị SDN, lưu lượng tấn công có số luồng tăng dần lên 20,000 luồng trên giây (fps) cho TCP-SYN và độ dài gói 1,400 bytes cho ICMP. Một luồng bao gồm các gói tin dữ liệu có các thông số giống nhau: {địa chỉ IP nguồn, địa chỉ IP đích, cổng nguồn, cổng đích}. Mỗi một luồng sẽ được thiết bị chuyển mạch và bộ điều khiển xử lý theo nguyên tắc được trình bày như ở bên trên, trong Hình 2.1. 52 Bảng 2.1 Cấu hình và tham số của mô hình thử nghiệm Bộ điều khiển POX, Ryu và Floodlight cài đặt trên máy chủ phần cứng: 6 Xeon(R) 2.53 GHz, 16 Cores, 32 GB RAM Thiết bị chuyển mạch SDN Thiết bị chuyển mạch phần mềm: OvS (v2.14.90) cài đặt trên máy chủ phần cứng: 6 Xeon(R) 2.67 GHz, 24 Cores, 64 GB RAM. Thiết bị chuyển mạch phần cứng: HPE Aruba 2920 24G – J9726A Nạn nhân Máy chủ có hiệu năng cao (6 Xeon (R) 2.67 GHz, 24 Cores, 64 GB RAM) Tạo lưu lượng Phần mềm Bonesi, TCPReplay (thiết bị phần cứng: Xeon(R) 3.70 GHz, 12 Cores, 16GB RAM) OpenFlow OpenFlow 1.0 và OpenFlow 1.3 Tấn công tràn SYN Tốc độ: 5,000 fps trong 10 giây cho tất cả các thiết bị điều khiển; 10,000 fps, 15,000 fps, 20,000 fps trong 10 giây cho Floodlight; Số lượng bots: 50,000 Tấn công tràn ICMP Băng thông: 56 Mbps – 900 Mbps Số lượng bots: 50,000 Kích thước dữ liệu: 1,400 bytes Các thông số đo đạc Thiết bị điều khiển: số yêu cầu đến (packet_in), luật gửi ra (flow_mod), trễ xử lý Thiết bị chuyển mạch: khối lượng dữ liệu đến, thông lượng, kích thước bảng luồng, độ trễ Hệ thống thử nghiệm đề xuất được xây dựng chung, có thể đánh giá cho các bộ điều khiển cũng như thiết bị chuyển mạch SDN khác nhau. Do tính phổ biến cũng như ứng dụng thực tế của các bộ điều khiển nên phần này lựa chọn một số bộ điều khiển và thiết bị chuyển mạch để đánh giá như sau: - POX: là một bộ điều khiển nguồn mở phổ biến, dựa trên Python. Bên cạnh NOX [105], POX được coi là một trong những bộ điều khiển SDN sớm nhất được phát triển và được sử dụng để phát triển và tạo dạng mẫu cho các ứng dụng mạng mới nhanh hơn. Nó được cài đặt sẵn trong một số công cụ phát triển mạng SDN, ví dụ như Mininet. - Ryu: cũng là một bộ điều khiển mã nguồn mở dựa trên Python được cộng đồng nghiên cứu và phát triển sử dụng rộng rãi trong thời gian gần đây. Nó hỗ trợ các API định nghĩa sẵn và thư viện toán học Python giúp cho việc sử dụng để tạo các ứng dụng điều khiển và quản lý mạng mới dễ dàng hơn, đặc biệt là các chức năng dựa trên học máy. - Floodlight: là một bộ điều khiển mã nguồn mở dựa trên Java. Kiến trúc của Floodlight thuận lợi cho các nhà phát triển vì nó có khả năng tương thích phần mềm và phát triển ứng dụng một cách dễ dàng, bao gồm REST API. Phát triển dựa trên Java là một công nghệ có thể mở rộng và thường là công nghệ lõi trong doanh nghiệp nên Floodlight là bộ điều khiển SDN mạnh mẽ và dễ sử dụng. Floodlight được tích hợp trong một số sản phẩm thương mại và mã nguồn mở được sử dụng rộng rãi trong ngành công nghiệp mạng, bao gồm cả OpenStack. 53 - OvS [106]: một bộ chuyển đổi SDN dựa trên phần mềm nổi tiếng được thiết kế để cho phép tự động hóa mạng quy mô lớn thông qua phần mở rộng có lập trình, trong khi vẫn hỗ trợ các giao thức và giao diện quản lý tiêu chuẩn. Trong điện toán đám mây, OvS là một thành phần quan trọng cho phép ảo hóa các chức năng mạng để tạo dịch vụ chuỗi chức năng (SFC). OpenStack [107] cũng đang chạy OvS để cung cấp các dịch vụ mạng ảo hóa. - Aruba 2920 [108]: là một thiết bị chuyển mạch thương mại lớp 3 do Aruba, công ty HP Enterprise sản xuất. Aruba 2920 là bộ chuyển mạch hỗ trợ SDN chạy giao thức OpenFlow 1.0 và 1.3 với 24 cổng, trong đó có bốn cổng 10Gbps. Mặc dù Aruba có thể lưu trữ tới 2048 tuyến đường IPv4 trong bảng định tuyến của mình, nhưng không có tài liệu nào cho biết về số lượng luồng OpenFlow mà bảng lưu lượng của nó có thể chứa. Trong nghiên cứu này, nghiên cứu sinh chọn Aruba làm thiết bị chuyển mạch phần cứng để so sánh hiệu năng của nó với các giải pháp phần mềm được sử dụng rộng rãi như OvS. 2.3. Các tác động của tấn công DDoS lên kiến trúc mạng SDN 2.3.1. Tác động của tấn công DDoS lên bộ điều khiển SDN Phần này trình bày các thử nghiệm và kết quả đánh giá tác động của các cuộc tấn công DDoS lên bộ điều khiển SDN. 2.3.1.1. Tác động của tấn công giao thức lên bộ điều khiển SDN Trước tiên, thực hiện một cuộc tấn công TCP-SYN với tốc độ 5,000 fps (hoặc tương đương với 3.04 Mbps) trong 10 giây vào máy chủ qua mạng SDN. Vì địa chỉ cổng và địa chỉ IP giả mạo là duy nhất nên mỗi bản tin TCP-SYN được SDN coi là một luồng mới. Các luồng mới này tiêu thụ cả tài nguyên của bộ chuyển mạch để tra cứu bảng luồng cũng như bộ điều khiển để xử lý gói tin packet_in như đã được trình bày ở phần đầu của Chương 2. Hình 2.4a hiển thị số lượng tích lũy của luồng đến, là số gói packet_in và số lượng quy tắc luồng được mang trong các gói flow_mods đo tại POX, Ryu và Floodlight. Độ dốc của các đường cong trong Hình 2.4a biểu thị tốc độ đầu vào cũng như tốc độ xử lý của bộ điều khiển. Nếu độ dốc đầu vào và đầu ra trùng nhau, bộ điều khiển có khả năng xử lý tất cả các truy vấn luồng đầu vào, nếu không thì bộ điều khiển bị quá tải. Điều này có thể được mô tả rõ ràng hơn trong Hình 2.4b, biểu thị tốc độ xử lý của từng bộ điều khiển so với các truy vấn đến. Có thể thấy, trong khi Floodlight có thể đáp ứng tốt số lượng truy vấn ở mức 5,000 fps thì POX và Ryu đã quá tải và chỉ có thể xử lý tối đa 1,200 fps và 2,400 fps tương ứng. Mặt khác, Ryu chạy OpenFlow 1.3 (OF1.3) hoạt động kém hơn so với chạy OpenFlow 1.0 (OF1.0), chỉ có thể xử lý khoảng 1,000 fps. Trong khi đó, Floodlight với OpenFlow 1.3 vẫn có thể thích ứng với cùng thông lượng như OpenFlow 1.0. Sự phát triển của giao thức OpenFlow từ 1.0 đến 1.3 đã thúc đẩy sự ra đời của các tính năng mới như nhiều bảng luồng, so khớp OXM để mở rộng tính linh hoạt của việc so khớp, cơ chế thay đổi vai trò để có khả năng mở rộng, hỗ trợ QoS và nhiều bản tin OpenFlow mới [109]. Những thay đổi này làm tăng thêm độ phức tạp trong bộ điều khiển SDN, điều này có lẽ làm giảm hiệu năng xử lý như minh họa trong Hình 2.4. Về tác động của tấn công TCP-SYN flood đối với thiết bị chuyển mạch SDN, Hình 2.4c hiển thị số lượng tích lũy đường đi được lưu trữ trong thiết bị chuyển mạch. Như 54 được hiển thị, số lượng đường đi tăng tỷ lệ thuận với số lượng quy tắc trong các bản tin flow-mods mà thiết bị chuyển mạch nhận được từ bộ điều khiển được biểu thị trong Hình 2.4a. Điều này cho thấy rằng tất cả các thiết bị chuyển mạch có thể tiếp nhận, xử lý và cài đặt luồng mới vào bảng luồng, thắt nút cổ chai trong trường hợp này là bộ điều khiển. (a) Số lượng tích lũy của luồng đến và số luồng ra tại bộ điều khiển (b) Số luồng đến và ra trên mỗi giây (c) Kích thước bảng luồng (d) Độ trễ xử lý trong bộ điều khiển Hình. 2.4 Hiệu năng của bộ điều khiển SDN trong trường hợp 5,000 luồng TCP-SYN đến trong một giây Trong Hình 2.4d, các ô hình hộp trình bày số liệu thống kê về độ trễ xử lý trong bộ điều khiển. Trễ xử lý được tính là khoảng thời gian giữa khi packet_in đến và flow_mods được gửi đi. Trong biểu đồ này, các đường giới hạn ở cả hai đầu chiếm 5 và 95 phần trăm và các điểm ngoài hình tròn đại diện cho các giá trị độ trễ tối thiểu hoặc tối đa, cũng là phần đầu tiên (Q1/25 phần trăm) và thứ ba (Q3/75 phần trăm) phần tư được hiển thị ở cả hai đầu của hộp trung tâm. Có thể thấy, do quá tải ở bộ điều khiển, độ trễ xử lý trung bình của POX, Ryu OF1.0, Ryu OF1.3 lần lượt là 15, 6 và 20 giây, trong khi Floodlight OF1.0 và OF1.3 hoàn toàn không có độ trễ nào vì Floodlight có thể hoạt động tốt ở tốc độ 5,000 fps. 55 (a) Tổng tích lũy số luồng vào và ra (10,000 fps) (b) Độ trễ tại bộ điều khiển và OvS (10,000 fps) (c) Tổng tích lũy số luồng vào và ra (15,000 fps) (d) Độ trễ tại bộ điều khiển và OvS (15,000 fps) (e) Tổng tích lũy số luồng vào và ra (20,000 fps) (f) Độ trễ tại bộ điều khiển và OvS (20,000 fps) Hình. 2.5 Hiệu năng của bộ điều khiển Floodlight khi tấn công TCP-SYN ở tốc độ 10,000fps, 15,000fps và 20,000fps 56 Để xem xét giới hạn xử lý của Floodlight và OvS, tiếp tục tăng tốc độ tấn công lên 10,000 fps, 15,000 fps và 20,000 fps, tương đương với 6.08 Mbps, 9.12 Mbps và 12.16 Mbps tương ứng. Kết hợp kích thước bảng luồng lưu lượng, số lượng tích lũy gói tin đến packet_in và gói tin ra flow_mod (Hình 2.5a, 2.5c, 2.5e) trong cùng một hình trong từng trường hợp để dễ dàng so sánh và đánh giá hiệu năng của thiết bị chuyển mạch (xem phần 2.3.2) cũng như bộ điều khiển. Các ô trong Hình 2.5b, 2.5d, 2.5f biểu thị độ trễ xử lý của Floodlight và độ trễ gói dữ liệu tương ứng của nó đi qua OvS, được đo bằng chênh lệch giữa thời gian gửi ra và thời gian đến của gói. Tổng kết lại, tấn công TCP-SYN có hại cho bộ điều khiển, mặc dù lưu lượng tấn công là rất nhỏ. Ở tốc độ 10,000 fps như trong Hình 2.5a, Floodlight với OpenFlow 1.0 có thể đáp ứng tốt lượng truy vấn đến, vì số lượng quy tắc gửi đi (đại diện là OF1.0 flow_mod trong các hình) khớp với số lượng gói yêu cầu packet_in đến. Theo đó, độ trễ của gói dữ liệu tại OvS (OvS với OF1.0) là rất thấp như trong Hình 2.5b. Mặt khác, hiệu năng của Floodlight chạy OpenFlow 1.3 bắt đầu giảm khi kết thúc thử nghiệm (Hình 2.5a), điều này phản ánh sự biến động của độ trễ xử lý trong Hình 2.5b (Floodlight với OF1.3). Hơn nữa, độ trễ gói tại thiết bị chuyển mạch trở nên tồi tệ hơn so với độ trễ xử lý của bộ điều khiển với độ trễ gói trung bình tăng lên vào khoảng 0.72 giây như trong Hình 2.5b (OvS với OF1.3). Do đó, cần lưu ý rằng khi tỷ lệ tấn công đạt đến một mức nhất định, OvS cũng bị ảnh hưởng và góp phần làm suy giảm dịch vụ. Lý do làm tăng độ trễ gói tại thiết bị chuyển mạch SDN sẽ được thảo luận sau trong phần 2.3.2. Hiện tượng tương tự rõ ràng hơn khi tốc độ tấn công tăng lên. Ở tốc độ 15,000 fps như trong Hình 2.5c và 2.5d, Floodlight với OpenFlow 1.0 vẫn có thể hoạt động tốt, trong khi Floodlight với OpenFlow 1.3 kém hơn hẳn. Mặt khác, các đường cong biểu thị các flow_mod gửi đi và số lượng các mục trong bảng không trùng nhau, cho thấy rằng OvS không thể xử lý một số lượng rất lớn các gói flow_mod gửi đến. Hậu quả là độ trễ gói tăng lên trong mặt phẳng dữ liệu (Hình 2.5d). Trong trường hợp thử nghiệm cuối cùng (Hình 2.5e và 2.5f), ngay cả Floodlight với OpenFlow 1.0 cũng không thể chịu được một lượng lớn 20,000 luồng yêu cầu mới mỗi giây. Bảng 2.2 Mức sử dụng tài nguyên tối đa của bộ điều khiển SDN Thiết bị điều khiển POX Ryu Floodlight Dữ liệu đến (fps) 5,000 5,000 5,000 20,000 Tài nguyên CPU 100% 100% 212% 470% Tài nguyên bộ nhớ 0.1% 0.1% 2.4% 3.7% Bảng 2.2 cho biết mức sử dụng tài nguyên cao nhất của bộ điều khiển SDN trong các tình huống thử nghiệm đã nói ở trên. Vì POX và Ryu là các bộ điều khiển đơn luồng, nên trong các tình huống tải cao, cả hai đỉnh của chúng có thể đạt mức sử dụng CPU 100% (CPU 1 lõi). Ngược lại, Floodlight sử dụng tài nguyên tăng tỷ lệ thuận với lưu lượng tải. Mức sử dụng CPU của nó ở 5,000 và 20,000 fps lần lượt là 212% (mức sử dụng CPU 3 lõi) và 470% (mức sử dụng CPU 5 lõi). Kết quả cho thấy rằng Floodlight có khả năng mở rộng và mạnh mẽ hơn so với các bộ điều khiển khác nhờ triển khai đa luồng. Tóm lại, trong các cuộc tấn công dựa trên giao thức, nếu tốc độ tấn công đủ lớn, thì cả bộ điều khiển và bộ chuyển mạch SDN đều bị ảnh hưởng. Bộ điều khiển bị quá 57 tải do xử lý một số lượng lớn yêu cầu luồng mới. Mặt khác, bộ chuyển mạch không thể xử lý một số lượng lớn gói tin flow_mod được gửi bởi bộ điều khiển, dẫn đến việc chuyển tiếp các gói dữ liệu từ đầu vào đến đầu ra của nó bị chậm trễ. 2.3.1.2. Tác động của tấn công dung lượng lên bộ điều khiển SDN Trong thử nghiệm tiếp theo, tràn ICMP được sử dụng để đánh giá tác động của các cuộc tấn công dựa trên dung lượng đối với bộ điều khiển SDN. Mục đích chính của một cuộc tấn công dựa trên dung lượng là làm bão hòa kết nối của nạn nhân bằng cách gửi một lượng lớn lưu lượng truy cập đến máy chủ nạn nhân. Do đó, trong mô hình chuyển tiếp dựa trên đích thông thường, các cuộc tấn công ICMP như một cuộc tấn công theo dung lượng điển hình chỉ có tác động tiêu cực lên các đường dẫn dữ liệu chứ không ảnh hưởng đến mặt phẳng điều khiển, không phụ thuộc vào số lượng luồng mới mang lưu lượng ICMP. Trong SDN, gói ICMP được bộ điều khiển xử lý luồng như gói TCP, nhưng gói ICMP có kích thước tải trọng lớn hơn, do đó có thể gây ra tác động khác cho bộ điều khiển SDN. Để kiểm chứng, thực hiện kịch bản tấn công với 5,000 ICMP pps, tương đương tốc độ 56 Mbps trong 10 giây. Tương tự như kịch bản tấn công TCP-SYN được mô tả bên trên trong Hình 2.6b và mỗi gói ICMP là một luồng và có tải trọng 1,400 bytes. Như có thể thấy trong Hình 2.6a, tốc độ của gói packet_in đến Ryu OF1.0, POX OF1.0 và Ryu OF1.3 lần lượt khoảng 2,000, 600 và 1,000 fps, thấp hơn đáng kể so với tốc độ lưu lượng ICMP ở đầu vào của OvS là 5,000 fps. Mặt khác, trong trường hợp TCP-SYN (Hình 2.4b), các bộ điều khiển đều nhận được số luồng tương đương nhau (5,000 luồng mỗi giây). Như vậy, do bị mất gói tại OvS nên chỉ một phần nhỏ trong tổng số 5,000 yêu cầu luồng mới có thể gửi đến Ryu và POX. Trong khi đó, tốc độ gói packet_in đến Floodlight khớp với tốc độ của các luồng ICMP mới trong hệ thống. (a) Các luồng vào và ra trên một giây (b) Tổng tích lũy số luồng Hình 2.6 Các tác động của tấn công tràn ICMP lên bộ điều khiển SDN Nguyên nhân của việc này là do cơ chế điều khiển luồng của TCP [110] đã điều chỉnh tốc độ gửi theo khả năng của bộ điều khiển. Giao thức OpenFlow sử dụng TCP để trao đổi các gói tin giữa bộ điều khiển và bộ chuyển mạch SDN. Cơ chế điều khiển luồng TCP sử dụng cửa sổ nhận RWND để đảm bảo rằng bên gửi không gửi quá khả năng xử lý của bên nhận [111]. Mặt khác, do một số thiết bị chuyển mạch SDN như 58 OvS và Aruba không hỗ trợ bộ đệm bên trong, nên bộ chuyển mạch phải gửi các toàn bộ nội dung gói ICMP đóng gói trong gói packet_in lên bộ điều khiển. Hình 2.7 Kích thước cửa sổ nhận TCP của bộ điều khiển SDN khi tấn công tràn ICMP xảy ra Hình 2.7 là biểu đồ giá trị cửa sổ TCP, nó cho biết bộ điều khiển nhận và xử lý dữ liệu như thế nào. RWND là kích thước của bộ đệm nhận, trong khi giá trị Bytes in flight là lượng dữ liệu chưa được xác nhận mà người gửi đã gửi đi. Bytes in flight sẽ luôn nhỏ hơn hoặc bằng RWND [112]. Theo biểu đồ, RWND của POX và Ryu liên tục dao động và giảm xuống 0 là do các bộ điều khiển này không thể xử lý kịp lưu lượng đến, làm cho bộ đệm bị đầy, dẫn đến mất gói tại OvS. Trong trường hợp của Floodlight, đường phẳng của RWND cho thấy khả năng xử lý tốt của bộ điều khiển này. Các kết quả này cho thấy các cuộc tấn công dựa trên dung lượng trong SDN nguy hiểm hơn so với mô hình mạng thông thường vì chúng không chỉ làm bão hòa các đường dẫn dữ liệu mà còn có tác động tiêu cực trực tiếp đến bộ điều khiển. Hơn nữa, DDoS dựa trên dung lượng thậm chí có thể nguy hiểm hơn các cuộc tấn công dựa trên giao thức trong SDN. Ví dụ, kẻ tấn công có thể sử dụng một số lượng lớn botnet để gửi các gói ICMP/UDP kích thước lớn đến một địa chỉ IP ngẫu nhiên nằm trong mạng SDN đích. Thay vì tấn công đích, điều này sẽ khiến bộ đệm và tài nguyên tính toán của bộ điều khiển SDN cạn kiệt, do đó ảnh hưởng đến toàn bộ mạng. Tác động tiêu cực này có xảy ra ngay cả trong trường hợp lưu lượng ICMP tấn công ở tốc độ thấp, ví dụ như 56 Mbps, tốc độ này chưa ảnh hưởng gì đến băng thông của các kết nối. 2.3.1.3. Ảnh hưởng của việc triển khai các thuật toán mới lên hiệu năng bộ điều khiển Bộ điều khiển SDN thường được trang bị các thuật toán mới để bổ sung thêm chức năng. Ví dụ như các thuật toán phát hiện và giảm thiểu tấn công được đề xuất ở các chương tiếp theo. Bên cạnh những lợi ích, các chức năng bổ sung này ảnh hưởng lên tài nguyên của bộ điều khiển, dẫn đến suy giảm hiệu năng. Trong phần này, nghiên cứu sinh đánh giá hiệu năng của bộ điều khiển SDN khi các chức năng mới được triển khai. 59 (a) Số luồng vào và ra trên một giây (b) Tổng tích lũy số luồng Hình 2.8 Hiệu năng của bộ điều khiển Ryu, POX sau khi tích hợp thuật toán thông minh Hình 2.9 So sánh hiệu năng của bộ điều khiển khi tích hợp LoF và DNN Để đánh giá hiệu năng của thiết bị điều khiển khi tích hợp chức năng mới, đặc biệt là chức năng bảo mật mạng theo mục tiêu nghiên cứu của luận án, nghiên cứu sinh triển khai tích hợp lên bộ điều khiển thuật toán học máy LoF và DNN phát hiện phần mềm độc hại dựa trên thuật toán tạo miền (DGA) [113]. LoF đại diện cho các thuật toán học máy nhẹ, đơn giản, được đề xuất dùng để phát hiện bất thường trong thời gian thực ở phần sau. DNN dại diện cho thuật toán học máy phức tạp, được đề xuất dùng phát hiện tấn công DDoS cụ thể. Nghiên cứu sinh lựa chọn hai thuật toán này đại diện để thực hiện đánh giá. Nghiên cứu sinh cũng chọn hai bộ điều khiển Python nổi tiếng là POX và Ryu cho thử nghiệm này vì các bộ điều khiển dựa trên Python thường phù hợp hơn khi triển khai các chức năng thông minh sử dụng học máy. Trong thử nghiệm này, mô hình học máy được thực hiện trên một tập hợp đầu vào được trích xuất từ các gói packet_in trong mỗi giây để phát hiện phần mềm độc hại từ lưu lượng truy cập đến, được tạo ở tốc độ 2,000 fps. Hiệu năng của bộ điều khiển được đánh giá bằng cách so sánh tốc độ flow_mod gửi ra trong trường hợp chạy thuật toán DNN, LoF với trường hợp không chạy thuật toán. Như được hiển thị trong Hình 2.8a, việc thêm một chức năng thông minh làm giảm khả năng xử lý của cả POX và Ryu 60 tương ứng khoảng 200 và 300 fps so với các trường hợp thông thường. Kết quả tích lũy như trong Hình 2.8b cho một cái nhìn rõ ràng hơn về sự suy giảm hiệu năng này. Hình 2.9 là kết quả so sánh hiệu năng của bộ điều khiển Ryu khi tích hợp LoF và DNN. Kết quả cho thấy thuật toán LoF đơn giản nên bộ điều khiển ít bị ảnh hưởng hơn thuật toán phức tạp DNN. Khả năng xử lý của bộ điều khi tích hợp LoF cũng gần như không thay đổi so với bình thường. Như vậy, khi tích hợp tác thuật toán thông minh vào bộ điều khiển SDN ít nhiều sẽ ảnh hưởng đến khả năng xử lý của chúng. Tùy theo độ phức tạp của thuật toán tích hợp mà việc ảnh hưởng sẽ nhiều hay ít. Do đó, trong các trường hợp, cần cân bằng giữa việc triển khai thuật toán mới trong bộ điều khiển và hiệu năng của chúng. Các kết quả đánh giá tác động của tấn công DDoS lên bộ điều khiển trên cho thấy Floodlight vượt trội hơn so với POX và Ryu. Đó là do Floodlight là bộ điều khiển dựa trên Java hỗ trợ đa luồng. Trong khi đó, POX và Ryu sử dụng Python, ngôn ngữ kịch bản chỉ hỗ trợ tốt cho một luồng, do đó hạn chế khả năng mở rộng hiệu năng của nó. Mặc dù nhu cầu thiết kế bộ điều khiển hiệu năng cao là rất quan trọng vì bộ điều khiển chịu trách nhiệm quản lý toàn bộ mạng, nhưng Floodlight và các bộ điều khiển hiệu năng cao khác (ví dụ: NOX, ONOS, Beacon,...) rất khó triển khai các ứng dụng dựa trên học máy. Ngược lại, các bộ điều khiển dựa trên Python (POX và Ryu) linh hoạt hơn khi dễ dàng sử dụng các nền tảng và thư viện học máy. Trên thực tế, nhiều nhà nghiên cứu, những người đã phát triển phương pháp phòng thủ dựa trên học máy chống lại các cuộc tấn công DDoS trong mạng SDN, đã sử dụng POX và Ryu [6, 7]. 2.3.2. Tác động của tấn công DDoS lên thiết bị chuyển mạch SDN Phần này trình bày tác động của các cuộc tấn công DDoS đối với các thiết bị chuyển mạch SDN, bao gồm cả phần mềm và phần cứng. 2.3.2.1. Tìm kiếm và cập nhật bảng luồng thông tin Hình 2.5 đã chỉ ra rằng OvS phát sinh độ trễ gói tin đáng kể. Đó là do quá trình xử lý gói tin flow_mod để thêm các mục mới trong bảng luồng không theo kịp tốc độ gửi đến của gói tin flow_mod. Phần này sẽ giải thích chi tiết hơn vấn đề này. Hình 2.5c và 2.5e cho thấy việc thêm các luồng mới vào bảng luồng OvS sẽ tốn kém hơn so với việc tạo các quy tắc mới trong Floodlight. Vì đường cong giá trị tổng tích lũy số lần gửi gói tin flow_mod dốc hơn so với đường cong tổng tích lũy số mục mới được thêm vào bảng luồng. Kết quả cho thấy, trong một máy vật lý có 6 Xeon, 2,67 GHz, 24 lõi (thông số trong Bảng 2.1), OvS đã đạt đến giới hạn xử lý khoảng 10,000 quy tắc mỗi giây. Nếu tốc độ đến của các flow_mod cao hơn ngưỡng này, OvS bắt đầu xử lý không kịp bộ điều khiển. Sự suy giảm hiệu năng tại OvS là do tình trạng cạnh tranh (race condition) trong thiết bị chuyển mạch. Vấn đề này lần đầu tiên được giải quyết bởi các tác giả trong [114] nhưng không được giải thích rõ ràng. Phần này sẽ phân tích chi tiết hơn thông qua các thử nghiệm mới được phát triển. Tình trạng tranh chấp xảy ra khi các bản tin flow_mod đến từ bộ điều khiển và các gói dữ liệu đến OvS tranh chấp để truy cập đồng thời vào bảng luồng thông tin. Một là để cập nhật các mục trong bảng luồng, hai là truy cập bảng để tra cứu tìm đường đi. OvS đã triển khai cơ chế khóa 61 ofproto_mutex để xử lý vấn đề này. Tuy nhiên, nó vẫn làm giảm hiệu năng xử lý của OvS nếu số truy cập bảng luồng thông tin đủ cao. Để minh họa rõ ràng hơn, Hình 2.10 mô tả tốc độ vào và ra của các gói TCP-SYN trong OvS. Trong các thử nghiệm, tấn công tràn TCP-SYN kéo dài trong 10 giây với tốc độ đến lần lượt là 10,000 pps và 15,000 pps, tương đương với 10,000 fps và 15,000 fps gói packet_in. Bộ điều khiển được sử dụng trong thí nghiệm này là Floodlight. Trong cả hai trường hợp, trong quá trình tấn công, tốc độ gói gửi đi thấp hơn tốc độ gói tin đến. Khi cuộc tấn công dừng lại, tốc độ gói gửi đi tăng đáng kể. Điều này có thể được giải thích như sau. Trong quá trình tấn công, các gói TCP-SYN đến làm cho thiết bị chuyển mạch bắt đầu gửi các luồng yêu cầu mới tới bộ điều khiển. Đến lượt mình, bộ điều khiển sẽ cài đặt các quy tắc mới bằng cách gửi các bản tin flow_mod cho OvS, từ đó gây ra tình trạng cạnh tranh đã nói ở trên giữa các gói TCP đến và bản tin flow_mod tại bộ chuyển mạch. Khi kết thúc cuộc tấn công, vì không còn