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 - Tạo bản sao 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
hoặc server - Chuyển tới SD FE6x FT3 CliACK gateway - Chuyển tới SD
- Nếu server ở trạng thái “Không bị tấn cơng”:
Hình 3.16. Q trình capture và điều hướng các gói tin của một kết nối TCP lành tính thơng qua các mục luồng trên OFS khi máy chủ nội bộ ở trạng thái “Không bị tấn công”
Giám sát quá trình bắt tay ba bước tại SD
Quá trình 3HS của một kết nối TCP lành tính bình thường phải đảm bảo hai yêu cầu: (1) client xác nhận lại phía server một gói tin CliACK sau khi nhận được gói tin SYN-ACK và (2) Số hiệu ACK_Num của gói tin CliACK phải bằng giá trị lớn liền kề số hiệu SEQ_Num của gói tin SYN-ACK. Giám sát quá trình 3HS nhằm loại bỏ các yêu cầu kết nối TCP đến từ các địa chỉ IP giả mạo. Hình 3.17 và Hình 3.18 mơ tả sự giám sát quá trình 3HS của các yêu cầu kết nối TCP trên SD. Các địa chỉ IP tin cậy được quản lý trong một danh sách Trusted_IPs, và duy trì tồn tại trong một khoảng thời gian TIP_timeout tính từ khi gửi yêu cầu kết nối gần nhất. Những gói tin SYN có địa chỉ nguồn khơng nằm trong Trusted_IPs sẽ được xác thực xem có phải là gói tin giả mạo địa chỉ IP nguồn hay không bằng kỹ thuật RST cookie (trình bày trong mục 3.5.3.4). Nếu quá trình này xác nhận gói tin SYN đến từ một nguồn có thực, địa chỉ IP nguồn của nó được đưa vào danh sách Trusted_IPs và gói tin SYN yêu cầu kết nối lần thứ 2 từ phía client sẽ được xác thực quá trình bắt tay ba bước.
Nhằm hạn chế tấn công quét cổng (port scan) tới hệ thống, SD duy trì một danh sách
Closed_Ports chứa các cổng được xác định đang bị đóng trên các máy chủ. Sau khi nhận được
gói tin SYN từ client, nếu server trả về một gói tin RST thụ động (passive RST) tương ứng thì hệ thống hiểu rằng cổng đó đang bị đóng. Lúc này, số hiệu cổng được cập nhật vào danh sách và duy trì trong một thời gian chờ Tport_timeout. SD sẽ hủy các gói tin SYN có u cầu kết nối tới các cổng đích nằm trong Closed_Ports.
Các kết nối TCP được giám sát q trình 3HS như mơ tả trong Hình 3.18. SD duy trì một danh sách HOCs chứa các kết nối TCP dang dở. Mỗi mục tin trong danh sách HOCs tương ứng với một kết nối TCP và bao gồm các thông tin như mơ tả trong Bảng 3.7. Khi q trình 3HS của kết nối TCP được hồn thành hoặc hết thời gian chờ THOC_timeout, mục tin tương ứng sẽ bị xóa bỏ.
Hình 3.17. Lưu đồ thuật tốn q trình xử lý gói tin SYN đến tại SD
Xác thực địa chỉ IP nguồn của gói tin SYN bằng kỹ thuật RST Cookie
Xác thực địa chỉ nguồn của gói tin SYN là q trình kiểm tra xem địa chỉ nêu trong trường thông tin Source IP Address có đúng là nơi phát ra gói tin hay khơng. Cơ chế CM của Avant- Guard sử dụng kỹ thuật SYN Cookie để xác thực. Nhược điểm của kỹ thuật này là 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 trên giao thức TCP [39], quy định các gói tin trao đổi tin cậy giữa 2 thực thể (client và server) trong quá trình 3HS phải đảm bảo nguyên tắc: Mỗi bên khởi tạo một giá trị 32 bits cho số hiệu SEQ_Num và gửi cho phía đối diện. Gói tin trả lời của phía đối diện xác nhận thơng qua giá trị số hiệu ACK_Num phải bằng giá trị lớn liền kề của số hiệu SEQ_Num của gói tin nó nhận được:
ACK_Num2→1 = SEQ_Num1→2 + 1 (3.18)
Nếu quy tắc này bị phá vỡ thì phía phát hiện ra hiểu rằng đã có lỗi xảy ra và thực hiện reset lại quá trình bắt tay ba bước. Trường hợp lỗi này được phát hiện bởi client, nó sẽ gửi gói tin RST chủ động (active RST) để reset lại kết nối và 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, khi nhận được một gói tin SYN từ client, SD tạo ra gói tin SYN- ACK và gửi trả lời client với giá trị số hiệu ACK_Num khác với giá trị kế tiếp của SEQ_Num trong gói tin SYN. Hình 3.19. Đồng thời, cũng giống như SYN Cookie [51], một giá trị cookie sử dụng làm giá trị khởi tạo SEQ_Num theo chiều từ SD tới client được tạo ra bằng cách mã
SEQ_Num của gói tin SYN) và các tham số bí mật của SD.
Hình 3.18. Lưu đồ thuật tốn giám sát q trình bắt tay ba bước tại SD Bảng 3.7. Cấu trúc một mục tin trong danh sách HOCs Bảng 3.7. Cấu trúc một mục tin trong danh sách HOCs
Địa chỉ IP nguồn Địa chỉ IP đích Số hiệu cổng TCP nguồn Số hiệu cổng TCP đích Số hiệu SEQ_Num của gói tin SYN-ACK
timeout
Nếu gói tin SYN được xuất phát từ một nguồn lành tính, theo nguyên tắc nêu trên, khi nhận được gói tin SYN-ACK, client sẽ gửi lại bằng một gói tin RST với giá trị số hiệu ACK_Num bằng giá trị kế tiếp của cookie. Lúc này, SD kiểm tra tính hợp lệ của gói tin RST bằng cách mã hóa lại giá trị cookie từ các tham số kết nối TCP và tham số bí mật. Nếu giá trị cookie tính được khớp với giá trị ACM_Num trong gói tin RST, SD hiểu rằng nguồn xuất phát của gói tin SYN ban đầu là nguồn lành tính. Với cách kiểm tra như vậy, SD không phải lưu trữ thông tin trạng thái của kết nối TCP và do đó khơng bị ảnh hưởng bởi sự chiếm dụng tài nguyên bộ nhớ bởi các gói tin SYN giả mạo địa chỉ IP trong tấn cơng SYN Flood. Đồng thời, kết nối TCP chính thức không bị chia cắt như sử dụng SYN Cookie trong cơ chế CM.
Hình 3.19. Sơ đồ tuần tự quá trình xác thực địa chỉ IP nguồn của gói tin SYN bằng RST cookie
3.5.4. Phân tích và đánh giá hiệu năng
Để so sánh, đánh giá hiệu năng của SSG so với cơ chế CM của giải pháp Avant-Guard, nội dung phần này trình bày phân tích so sánh về mặt giao thức, cơ chế làm việc để thấy rõ những cải tiến của SSG dưới tác động của tấn công SYN Flood, đồng thời xây dựng mơ hình testbed và tạo ra các kịch bản tấn cơng với cường độ khác nhau và phân tích so sánh kết quả đo đạc được từ testbed. Cấu trúc của testbed được mơ tả như trong Hình 3.20. Trong đó:
- Bộ chuyển mạch OFS được xây dựng từ máy tính chạy phần mềm OpenVswitch [69] phiên bản 2.7.90 với 5 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 là một 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 được capture và xử lý bằng phần mềm DPDK [137].
tính : CPU Intel TM Core i3-2330M @ 2.2GHz, 500GB HDD, 2GB RAM.
- Lưu lượng tấn công SYN Flood được tạo ra từ công cụ BONESI [115] với tùy chọn tạo
địa chỉ IP nguồn giả mạo ngẫu nhiên, tốc độ tấn công thay đổi từ 100 pps, 200 pps đến 5.500 pps. Để đảm bảo tính tương đồng cho các cấu hình khác nhau, lưu lượng tấn cơng được ghi lại bằng công cụ WireShark [138] và phát tấn công bằng công cụ TCPReplay [116] từ mộ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 duy trì cho mỗi trường hợp tốc độ tấn cơng khác nhau là 500s.
- Lưu lượng lành tính được tạo ra từ một phần mềm chạy trên một máy tính liên tục tạo các
yêu cầu kết nối và download các tệp tin của dịch vụ FTP trên server với tốc độ 30 kết nối/s. Lưu lượng kết nối giữa client lành tính và FTP server được ghi lại bằng 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 và thời gian kết nối trung bình dưới tác động tấn cơng
SYN Flood
Hình 3.21. So sánh tỷ lệ kết nối thành công và thời gian kết nối trung bình giữa Openflow, cơ chế CM và giải pháp SSG
Mục tiêu của tấn công SYN Flood là làm cho hệ thống giảm năng lực phục vụ các 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 của các kết nối này sẽ bị giảm xuống và thời gian để các kết nối TCP lành tính thực hiện quá trình kết nối và truy xuất dữ liệu sẽ bị
tăng lên. Trong mơ hình thử nghiệm này, tỷ lệ kết nối thành cơng SCR được tính bằng tỷ lệ giữa số kết nối TCP thực hiện kết nối và download thành công tệp tin tới máy chủ FTP trên tổng số yêu cầu kết nối. Thời gian kết nối trung bình ART được tính bằng trung bình khoảng thời gian từ khi client lành tính gửi gói tin SYN u cầu kết nối đến khi client nhận được gói tin dữ liệu đầu tiên từ máy chủ FTP. Kết quả đo và thống kê SCR và ART được trình bày trong biểu đồ ở Hình 3.21. Kết quả cho thấy:
- So sánh với Openflow và cơ chế CM, SSG chịu đựng tấn công tốt hơn khi duy trì tỷ lệ
SCR ở 98% dưới tấn cơng ở tốc độ 5.500 pps trong khi CM ở mức dưới 20%, còn Openflow
chỉ đạt ở mức 3% dưới tấn công tốc độ 1.500 pps và không thể kết nối tới má chủ khi tốc độ tấn công ở mức 2.000pps.
- Kết quả cũng cho thấy có sự tương quan giữa 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 đối với cả ba giải pháp. Tuy nhiên, khi tốc độ tấn công thấp (từ mức 100 pps đến 700 pps), thời gian ART của SSG có chút cao hơn so với cơ chế CM. Nguyên nhân là do trong SSG, client phải gửi lại gói tin yêu cầu SYN lần thứ hai khi địa chỉ IP của nó khơng nằm trong danh sách địa chỉ IP tin cậy Trusted_IPs.
Sự chiếm dụng tài nguyên trên bộ chuyển mạch và trên SD
Hình 3.22 thể hiện kết quả đo sự chiếm dụng tài nguyên bộ nhớ và tài nguyên CPU trên OFS và SD của ba giải pháp trong mơ hình thử nghiệm. Kết quả cho thấy:
- Khi khơng có tấn cơng, mức độ chiếm dụng tài ngun trên OFS của SSG xấp xỉ so với
mơ hình Openflow ở mức trên 150 MB bộ nhớ và khoảng 8% tài nguyên CPU. Trong khi đó, cơ chế CM của 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 và 13%.
- Khi hệ thống chịu tấn công SYN Flood, mức chiếm dụng tài nguyên trên OFS của Openflow tăng nhanh và đạt mức 1.600 MB bộ nhớ và trên 50% tài nguyên CPU khi tốc độ tấn công ở mức 1.500 pps. Điều này minh chứng cho tấn công làm cạn kiệt tài nguyên trên lớp hạ tầng mạng khi mà các mục luồng vơ ích chiếm dụng một phần lớn tài nguyên của bộ chuyển mạch và gây ra sự suy giảm tỷ lệ kết nối thành công đã nêu ở mục 1.5.6.1. Cơ chế CM và giải pháp SSG đã giảm thiểu tác hại tấn công trên bộ chuyển mạch khi ở cùng tốc độ tấn cơng đó, mức độ chiếm dụng tài nguyên chỉ ở mức dao động khoảng 300 MB bộ nhớ và dưới 30% CPU.
- So sánh giữa cơ chế CM và giải pháp SSG cho thấy mức độ chiếm dụng tài nguyên trên
bộ chuyển mạch của SSG luôn thấp hơn cơ chế CM. Đặc biệt, khi tốc độ tấn công tăng cao (từ 2.500 pps đến 5.500 pps) cơ chế CM tiêu thụ tài nguyên CPU cao hơn nhiều so với SSG, ở mức xấp xỉ 75% trong khi của SSG chỉ khoảng 28%. Đây là nguyên nhân chính gây nên sự 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 về mức độ chiếm dụng tài nguyên và khả năng xử lý gói tin của OFS trong
SSG so với cơ chế CM là do di chuyển chức năng giám sát quá trình 3HS của các kết nối TCP từ OFS tới bộ SD. Kết quả đo và thống kê trong Hình 3.22 cũng cho thấy mức độ chiếm dụng