Tỷ lệ lọc bỏ nhầm được thể hiện trong biểu đồ Hình 3.12. Kết quả về độ nhạy lọc bỏ và tỷ lệ lọc bỏ nhầm như trên có thể thấy:
• Độ nhạy lọc bỏ tại mỗi chu kỳ giám sát T đạt 92,0 đến 95,0% theo luồng.
• Nếu tính trung bình trong suốt thời gian tấn cơng, độ nhạy lọc bỏ đạt tới 97,5% trong
khi tỷ lệ lọc bỏ nhầm ở mức 3,6% theo lưu lượng.
Bảng 3.4 so sánh hiệu năng đo được với giải pháp áp dụng thuật toán TRW-CB trên Openflow kết hợp sFlow [21] do nhóm tác giả Kostas Giotis thực hiện (năm 2014) như đã trình bày ở chương 1 trong trường hợp lưu lượng DDoS hỗn hợp và lưu lượng tấn công quét cổng áp dụng đối với quy mô hệ thống mạng tương đồng (tốc độ mạng 100 Mbps).
Bảng 3.4. So sánh hiệu năng giải pháp FDDoM với giải pháp và mơ hình mạng tương đồng
Giải pháp Độ nhạy lọc bỏ
(DRF)
Tỷ lệ lọc bỏ nhầm
(FPRF)
TRW-CB trên Openflow kết hợp sFlow với lưu
lượng DDoS hỗn hợp 96 % 25 %
TRW-CB trên Openflow kết hợp sFlow với lưu
lượng tấn công quét cổng 96 % 10 %
FDDoM 97,50 % 3,6 %
Kết quả so sánh cho thấy, giải pháp FDDoM cho độ nhạy lọc bỏ cải thiện hơn so với giải pháp TRW-CB trên Openflow kết hợp sFlow. Trong đó, điều quan trọng là FDDoM đã giảm tỷ lệ lọc bỏ nhầm, ngay cả so sánh với trường hợp lưu lượng tấn công xác định (quét cổng). Điều này đặc biệt có ý nghĩa vì bản chất của giảm thiểu tấn công DDoS là cố gắng không làm ảnh hưởng đến quá trình trao đổi dữ liệu của các máy khách (client) lành tính tới máy chủ trong trung tâm dữ liệu.
Khả năng đáp ứng của hệ thống
- Trong các giải pháp dựa trên kiến trúc SDN/Openflow cơ bản [22], [24], [77], sau khi phát hiện tấn cơng, hệ thống phải tiếp tục giám sát thêm ít nhất 1 chu kỳ T nữa để phân loại lưu lượng tấn cơng và áp đặt chính sách xử lý gói tin thơng qua các mục luồng. Điều này khơng những làm chậm khả năng đáp ứng của hệ thống mà còn làm tăng lưu lượng trên giao diện Openflow do Bộ điều khiển truy vấn thông tin lưu lượng. Trong FDDoM, khi một máy chủ được xác định ở trạng thái “Nghi ngờ bị tấn công” hoặc “Đang bị tấn cơng”, tồn bộ lưu lượng luồng mới đến được chuyển đến SD, không chuyển tới máy chủ nội bộ cũng như tới Bộ điều khiển. Tại SD lưu lượng tấn cơng được xóa bỏ, khơng cần phải đợi thêm chu kỳ giám sát. Việc này hạn chế tối đa các luồng mới được tạo ra và giảm thiểu tải và thông tin lên bộ điều khiển, các khối phân tích bảo mật. Do vậy, mức độ đáp ứng đưa ra các chính sách an ninh của hệ thống sẽ nhanh hơn so với các phương pháp xử lý dựa trên giao diện Openflow.
- Ngoài ra, cách tiếp cận này cũng khắc phục một vấn đề phổ biến khác đó là xử lý luồng có 1 gói tin. Tấn công DDoS phổ biến là giả mạo IP với một số lượng lớn các luồng có 1 gói
tin gửi đến máy nạn nhân. Sau khi nhận gói tin đầu tiên và cũng là gói duy nhất của luồng, một mục luồng tương ứng sẽ được tạo ra trong OFS và kéo dài cho đến khi hết thời gian chờ gây lãng phí tài ngun. Khi có dấu hiệu chỉ có 1 gói tin trong một luồng và máy chủ trong trạng thái “Đang bị tấn cơng”, như đã trình bày ở các mục trên thì SS yêu cầu SP tại bộ điều khiển
hủy bỏ các luồng có 1 gói tin theo tỷ lệ Z trong OFS nhằm hạn chế sự chiếm dụng vơ ích tài nguyên của bộ chuyển mạch.
Giảm lưu lượng trên giao diện Openflow
- Theo nguyên tắc hoạt động của SDN/Openflow, một gói tin khơng khớp với bất kỳ mục
luồng hiện có nào sẽ được OFS gửi tới bộ điều khiển qua bản tin packet-in. Khi tấn công DDoS xảy ra, hàng loạt gói tin khơng khớp tạo ra ồ ạt các bản tin packet-in làm cho giao diện Openflow
tăng cao và có thể vượt ngưỡng cho phép. Ngồi ra, các gói tin trên giao diện này được mã hóa TLS, độ dư mã sẽ làm cho lưu lượng tăng cao gây nguy cơ nghẽn mạng giao diện Openflow.
- Trong FDDoM, lưu lượng được xử lý theo cơ chế trên chỉ khi máy chủ ở trạng thái “Không
bị tấn công”. Trong trường hợp máy chủ ở trạng thái "Nghi ngờ bị tấn công" hoặc "Đang bị tấn công", bản tin packet-in qua giao diện Openflow được thay thế bằng cơ chế gửi sự kiện và
gói tin tới SD. Khi phát hiện có tấn cơng, một phần các gói tin thuộc các luồng mới bị hủy bỏ (nghĩa là không được cài đặt luồng mới bởi SD). Do đó, lưu lượng chuyển tiếp đến máy chủ được giảm đáng kể. Ngồi ra, SD khơng gửi tồn bộ phần tiêu đề của gói tin đến SS thơng qua SP tại bộ điều khiển, mà chỉ gửi phần hữu ích của tiêu đề như: địa chỉ IP nguồn, địa chỉ IP đích, cổng nguồn, cổng đích. Thực tế này làm cho lưu lượng Openflow giữa bộ điều khiển và bộ chuyển mạch cũng như tổng lưu lượng trên giao diện của SS được giảm đáng kể so với kiến trúc SDN/Openflow chuẩn.
Giảm chiếm dụng vùng bộ nhớ đệm trên bộ chuyển mạch biên OFS
Trên mơ hình kiến trúc SDN/Openflow chuẩn, khi một gói tin đến khơng khớp với các mục luồng hiện có trong OFS, một phần của gói tin bao gồm phần tiêu đề (header) sẽ được chuyển tiếp tới bộ điều khiển, trong khi toàn bộ nội dung của nó được lưu trữ trên bộ đệm của OFS để chờ chính sách xử lý gói tin từ bộ điều khiển. Khi tài nguyên của OFS trở nên cạn kiệt, tồn bộ nội dung của gói được chuyển tiếp đến bộ điều khiển trong bản tin packet-in. Trong các cuộc tấn công DDoS, số lượng các gói khơng khớp với các mục luồng có sẵn trong OFS tăng lên rất cao, dẫn đến cạn kiệt bộ đệm của OFS. FDDoM khắc phục được vấn đề này vì nó khơng u cầu sử dụng bộ đệm trong trường hợp trạng thái máy chủ là "Nghi ngờ bị tấn cơng" hoặc "Đang
Kết quả phân tích mơ phỏng về mức độ giảm mục luồng trên OFS được thể hiện trong biểu đồ Hình 3.13. So sánh giữa FDDoM với cơ chế xử lý gói tin SDN/Openflow chuẩn cho thấy số lượng luồng trong OFS được giảm đến 50% trong trường hợp có tấn cơng xảy ra.
3.5. Phát hiện và giảm thiểu tấn công SYN Flood tới mạng SDN/Openflow sử dụng cơ chế ủy nhiệm gói tin SYN tại bộ phân SDN/Openflow sử dụng cơ chế ủy nhiệm gói tin SYN tại bộ phân tích và xử lý lưu lượng
3.5.1. Đặt vấn đề
Như đã trình bày ở Chương 1 và mục 2.3 ở Chương 2, tấn công SYN Flood vẫn đang là một dạng tấn công DDoS phổ biến và nguy hiểm đối với hệ thống mạng. Ngồi mục tiêu tấn cơng là hệ thống các máy chủ, trong bối cảnh SDN/Openflow, SYN Flood còn được lợi dụng để tấn công tới một mục tiêu mới đó là làm cạn kiệt tài nguyên trên các bộ chuyển mạch (lớp hạ tầng mạng), gây thắt cổ chai trên giao diện Openflow và suy kiệt khả năng của các bộ điều khiển (lớp điều khiển) [35], [93], [94]. Đã có các giải pháp phịng chống tấn cơng SYN Flood cho kiến trúc mạng SDN/Openflow, điển hình là cơ chế Connection Migration của giải pháp Avant-Guard [28], tuy nhiên giải pháp này sử dụng kỹ thuật ủy nhiệm gói tin SYN tại bộ chuyển mạch nên khơng thể áp dụng cho các bộ chuyển mạch Openflow không hỗ trợ chức năng này. Ngồi ra việc tích hợp chức năng xử lý gói tin tại bộ chuyển mạch làm mất bản chất SDN, chia cắt kết nối TCP, đồng thời biến bộ chuyển mạch trở thành mục tiêu tấn cơng DDoS.
Giải pháp ủy nhiệm gói tin SYN trên Bộ điều khiển như đã trình bày ở mục 2.3, Chương 2 có khả năng phát hiện và giảm thiểu tấn công SYN Flood tới các máy chủ trong mạng quy mô nhỏ nhưng không xử lý được đối với các cuộc tấn 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, và 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 này trình bày đề xuất giải pháp SSG ủy nhiệm gói tin SYN trên bộ Phân tích và xử lý lưu lượng với mục tiêu:
• Giám sát được q trình bắt tay ba bước của tất cả các kết nối TCP nhằm phát hiện tấn cơng SYN Flood.
• Khi xác định có tấn công SYN Flood xảy ra, hệ thống chỉ thực hiện cài đặt mục luồng cho những kết nối hồn thành q trình bắt tay ba bước nhằm loại bỏ các gói tin SYN tấn cơng giả mạo địa chỉ IP.
• Khắc phục được những điểm tồn tại của cơ chế CM trong giải pháp Avant-Guard. Giải pháp SSG hoạt động trên cơ sở:
• Lợi dụng khả năng so khớp với các trường TCP Flags của gói tin TCP có trong chuẩn giao thức Openflow 1.5, sắp xếp các mục luồng trên bộ chuyển mạch với các action thích hợp để điều hướng các gói tin 3HS của các kết nối TCP tới thiết bị ủy nhiệm an ninh SD.
• SD phát hiện tấn cơng SYN Flood xảy ra đối với một máy chủ dựa vào số kết nối TCP dở dang (HOC) tới máy chủ trong mỗi chu kỳ giám sát:
- Nếu máy chủ không bị tấn cơng, khác với cơ chế CM, q trình 3HS được thực hiện bình thường trực tiếp giữa Internet clients và máy chủ nội bộ mà không cần ủy nhiệm kết nối TCP.
- Khi một máy chủ được xác định là nghi ngờ bị tấn cơng SYN Flood, SD duy trì một
danh sách các địa chỉ IP tin cậy có kết nối với máy chủ gần đây. Nếu một gói tin SYN đến từ một địa chỉ nằm trong danh sách địa chỉ IP tin cậy, nó được chuyển đến máy chủ để thực hiện kết nối bình thường với Internet client. Trong trường hợp địa chỉ IP nguồn của gói tin SYN khơng nằm trong danh sách tin cậy, SD xác thực địa chỉ nguồn của gói tin bằng kỹ thuật RST Cookie trước khi cho phép kết nối trực tiếp giữa Internet client và máy chủ nội bộ.
3.5.2. Cấu trúc hệ thống
Cấu trúc chi tiết về các module chức năng của SSG được mơ tả trong Hình 3.14. Trong đó:
- OFS được cấu hình, sắp xếp các mục luồng để thực hiện capture và chuyển tiếp các gói
tin 3HS và gói tin RST để chuyển tới SD và các máy chủ nội bộ.
- Bộ phân tích và xử lý lưu lượng SD thực hiện (1) giám sát q trình 3HS của các kết nối
TCP, qua đó (2) phát hiện tấn công SYN Flood và (3) xác thực địa chỉ IP nguồn của các gói tin SYN.
- Trong SSG, các khối chức năng của máy chủ an ninh mạng thuộc lớp ứng dụng được tích
hợp trong module ủy nhiệm an ninh SP chạy trực tiếp trên bộ điều khiển. Chức năng của SP bao gồm: (1) Thay đổi chính sách xử lý gói tin SYN đến tại bộ chuyển mạch khi phát hiện tấn công SYN Flood xảy ra hoặc ngược lại, và (2) cài đặt các mục luồng phục vụ trao đổi dữ liệu cho các kết nối TCP sau khi đã xác thực quá trình bắt tay ba bước.
3.5.3. Hoạt động của hệ thống
Phát hiện tấn công SYN Flood và thay đổi chính sách xử lý gói tin
SSG xác định tại mỗi thời điểm, một máy chủ ở một trong hai trạng thái: “Không bị tấn
công SYN Flood” và “Nghi ngờ bị tấn công SYN Flood”. Module SFD trên SD thực hiện phát
hiện tấn công và yêu cầu bộ điều khiển thay đổi các chính sách xử lý gói tin tương ứng. SSG áp dụng thuật tốn phát hiện tấn cơng dựa trên mơ hình dự đốn xám [132]–[134] và thuật tốn Tổng tích lũy (CUSUM) được giới thiệu bởi nhóm Wang [135]. Hình 3.15.
Tham số đầu vào cho SFD phát hiện tấn công SYN Flood là số lượng kết nối TCP dang dở
kHOC trong một chu kỳ giám sát TSFD.
kHOC = kSYN – k3HS_completed (3.17)
Trong đó: kSYN là số gói tin SYN đến máy chủ, k3HS-completed là số kết nối TCP hồn thành
Hình 3.14. Cấu trúc chi tiết và tương tác giữa các module chức năng trong giải pháp SSG
Hình 3.15. Mơ hình thuật tốn phát hiện tấn công SYN Flood đề xuất sử dụng trong SSG
Tùy theo kết quả phân loại sau mỗi chu kỳ giám sát TSFD, khi có sự thay đổi trạng thái của một máy chủ (đang từ trạng thái “Không bị tấn công SYN Flood” sang trạng thái “Nghi ngờ bị
tấn công SYN Flood” hoặc ngược lại), SFD sẽ gửi bản tin thông qua module SP yêu cầu bộ
điều khiển chỉnh sửa mục luồng FE1 để thay đổi các action như mô tả trong Bảng 3.6. Với các action này, nếu máy chủ ở trạng thái “Không bị tấn cơng”, gói tin SYN được 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ủ đang “Nghi ngờ bị tấn
công SYN Flood”, gói tin SYN được chuyển tới SD để xác thực địa chỉ nguồn của nó trước khi
chuyển tới server như mơ tả trong lưu đồ thuật tốn ở Hình 3.17.
Sắp xếp các mục luồng để capture và điều hướng các gói tin 3HS
Lợi dụng khả năng so khớp với các cờ TCP được quy định trong Openflow 1.5 [20], khả năng sắp xếp các mục luồng theo các mức ưu tiên khác nhau trong nhiều bảng luồng [136], SSG tổ chức các bảng luồng và sắp xếp các mục luồng tại OFS như trong Bảng 3.5 và Bảng 3.6 để thực hiện so khớp và capture các gói tin 3HS của các kết nối TCP và điều hướng chúng tới các máy chủ ứng dụng nội bộ, tới Internet clients hoặc tới SD. Tùy theo trạng thái của các máy chủ nội bộ, các gói tin 3HS được capture và điều hướng theo nguyên tắc:
• Nếu máy chủ ở trạng thái “Khơng bị tấn cơng”, các gói tin 3HS được điều hướng trực tiếp tới/giữa client và server. Một bản sao của các gói tin này được gửi tới SD cho mục
đích giám sát, phát hiện tấn cơng.
• Nếu máy chủ ở trạng thái “Nghi ngờ bị tấn cơng”, gói tin SYN được chuyển tới SD để
xác thực địa chỉ IP nguồn của nó trước khi gửi đến máy chủ.
Hình 3.16 mơ tả q trình capture và điều hướng các gói tin 3HS của một kết nối TCP lành tính thơng qua q trình so khớp với các mục luồng trên bộ chuyển mạch khi máy chủ ứng dụng nội bộ ở trạng thái “Không bị tấn công”.
Bảng 3.5. Tổ chức các bảng luồng trên bộ chuyển mạch OFS của SSG
Bảng
luồng Chức năng Loại mục luồng miss xảy ra Khi table-
FT1 - Capture các gói tin SYN từ client, SYN-
ACK từ server và SD để điều hướng xử lý giám sát quá trình 3HS, phát hiện tấn cơng SYN Flood
Proactive (các mục
luồng tồn tại vĩnh viễn) bảng FT2 Chuyển tới FT2 - Điều hướng các gói tin trao đổi dữ liệu
giữa client và server của các kết nối TCP sau khi hoàn thành bắt tay ba bước
Reactive (các mục luồng tồn tại cho đến khi kết nối TCP kết thúc, dựa vào idle-timeout và
hard-timeout)
Chuyển tới bảng FT3
FT3 - Capture gói tin CliACK, RST từ client,
RST từ server để xác nhận quá trình 3HS Proactive Bảng 4 Chuyển tới FT4 (và các
FT tiếp theo)
- Chứa các mục luồng cho các ứng dụng khác
Bảng 3.6. Đặc tính các mục luồng trong các bảng luồng FT1 và FT3 thực hiện giám sát quá trình bắt tay ba bước
Mục
luồng bảng luồng Thuộc loại gói tin Khớp với Xuất hiện trên cổng Action tương ứng
FE1x FT1 SYN gateway - Server ở trạng thái “Không bị tấn công”:
Chuyển tới server tương ứng và một bản sao tới SD
- Server ở trạng thái “Nghi ngờ bị tấn công”:
Chuyển tới SD
FE2x FT1 SYN SD - Chuyển tới server tương ứng
FE3x FT1 SYN-ACK server - Chuyển tới client tương ứng qua cổng gateway