Mục tiêu và phạm vi đề tài
Mục tiêu
Sinh viên sẽ phát triển một mô hình nền tảng để tổ chức cuộc thi CTF theo hình thức tấn công - phòng thủ, với các yêu cầu cụ thể nhằm đảm bảo tính hiệu quả và an toàn cho sự kiện.
• Dễ dàng cho việc triển khai.
• Tốc độ kết nối giữa các đội chơi nhanh và ổn định.
• Có thể tổ thức theo hình thức trực tuyến thông qua internet.
• Số lượng đội chơi tham gia lớn trên 50 đội.
• Các đội chơi được hỗ trợ giấu danh tính trong suốt quá trình thi.
• Ban tổ chức dễ dàng điều khiển, thay đổi thông tin cuộc thi trong thời gian thực.
• Phục vụ cho nhu cầu tìm hiểu về kỹ thuật.
1 CTFd: https://github.com/CTFd/CTFd
Phạm vi đề tài
Để đảm bảo nội dung nghiên cứu phù hợp với thời gian và khả năng hiện tại, sinh viên sẽ tập trung vào các điểm chính trong đề tài này.
• Thiết kế tổng quát cho nền tảng.
• Đề xuất phương thức hiện thực phần kết nối giữa các users và server, thành phần kiểm tra dịch vụ và tổng hợp trạng thái dịch vụ.
• Hiện thực phần kết nối giữa các users và server, thành phần kiểm tra dịch vụ và tổng hợp trạng thái dịch vụ.
Bố cục của luận văn
Dựa theo các giai đoạn được phân chia như trên, bố cục của đề cương có thể tóm lược như sau.
Bài viết này sẽ trình bày tổng quan về vấn đề cần giải quyết và mục tiêu của đề tài Tiếp theo, chúng tôi sẽ đề xuất kế hoạch thực hiện chi tiết và bố cục dự kiến cho nghiên cứu.
Chương 2 - Kiến thức nền tảng
Cuộc thi Capture The Flag (CTF) là một sự kiện quan trọng trong lĩnh vực an ninh mạng, nơi người tham gia thi đấu bằng cách giải quyết các bài toán liên quan đến bảo mật Để tổ chức một cuộc thi CTF hiệu quả theo hình thức tấn công - phòng thủ, cần chú trọng vào việc xây dựng hệ thống nền tảng vững chắc, bao gồm cơ sở hạ tầng kỹ thuật, hệ thống bài thi đa dạng và công cụ hỗ trợ Các yếu tố quan trọng khác bao gồm việc đảm bảo tính công bằng, minh bạch trong đánh giá và khuyến khích sự sáng tạo của người tham gia.
Chương 3 - Một số nền tảng đã và đang được phát triển
Giới thiệu về một số nền tảng đã và đang được phát triển.
Chương 4 - Một số công cụ phù hợp để phát triển hệ thống
Trình bày các công nghệ phù hợp sử dụng trong quá trình phát triển hệ thống.
Chương 5 - Thiết kế hệ thống
Trình bày về kiến trúc và mô hình vận hành của hệ thống.
Chương 6 - Hiện thực các thành phần hệ thống
Hiện thực các kết nối giữa các đội chơi và hệ thống, thành phần kiểm tra dịch vụ, thành phần tổng hợp dịch vụ.
Chương 7 - Đánh giá và kiểm thử tập trung vào việc đánh giá và nhận xét về module kết nối giữa người dùng và máy chủ Đồng thời, chương cũng thực hiện kiểm thử ở mức đơn vị cho hai thành phần là Scriptbot và ServiceStatus.
Tổng kết về luận văn và trình bày các hướng phát triển của đề tài.
Capture the flag
Capture the flag (CTF) là một cuộc thi thú vị trong lĩnh vực an toàn thông tin, nơi các đội chơi phải giải quyết các vấn đề bảo mật máy tính Mục tiêu chính của cuộc thi là tìm ra chuỗi ký tự đặc biệt, được gọi là "flag", được giấu trong các thử thách.
Các cuộc thi CTF thường được chia thành 3 hình thức như sau:
Jeopardy là một hình thức thi đấu trong đó ban tổ chức đưa ra nhiều thử thách đa dạng, phân chia theo các chủ đề như Web, Pwn, Reverse, Crypto, và Forensic Các đội chơi sẽ tìm kiếm "flag" bên trong các thử thách hoặc trên máy chủ do ban tổ chức cung cấp Điểm số được tính dựa trên số lượng "flag" mà đội đạt được và độ phức tạp của từng thử thách.
Trong hình thức thi tấn công - phòng thủ, các đội chơi sử dụng máy chủ của mình hoặc do ban tổ chức cung cấp để vận hành các dịch vụ có lỗ hổng Mỗi đội có nhiệm vụ tấn công các đội khác để lấy “flag” và đồng thời bảo vệ dịch vụ của mình khỏi các cuộc tấn công Thời gian thi đấu chia thành các vòng, với “flag” thay đổi sau mỗi vòng Điểm số được tính dựa trên số lượng “flag” thu thập được và điểm thưởng từ việc phòng thủ thành công Đây là hình thức thi thực tiễn, giúp đội ngũ bảo mật không chỉ nghiên cứu lỗ hổng mà còn phân tích nguy cơ từ các yêu cầu gửi đến dịch vụ.
3 Hình thức thi kết hơp
Là sự phối hợp của hai hình thức trên, hình thức thi được tùy biến theo người tổ chức dựa trên mục đích của cuộc thi.
Mạng riêng ảo - VPN
Mạng riêng ảo (VPN) là công nghệ giúp thiết lập kết nối an toàn trong môi trường công cộng như internet hoặc mạng riêng của nhà cung cấp dịch vụ Khi sử dụng VPN, các máy tính sẽ tương tác với nhau như trong một mạng nội bộ (LAN), đảm bảo bảo mật và riêng tư cho người dùng.
Dưới đây là một số lợi ích mà VPN mang lại:
Sử dụng VPN để truy cập mạng doanh nghiệp từ xa giúp nhân viên kết nối với tài nguyên trên mạng cục bộ, ngay cả khi gặp trở ngại về địa lý Việc này không chỉ đảm bảo an toàn cho các tài nguyên mà còn tăng cường tính bảo mật, vì chúng không phải tiếp xúc trực tiếp với internet.
Duyệt web ẩn danh thông qua VPN giúp mã hóa các yêu cầu gửi đi, đảm bảo rằng tất cả thông tin và dữ liệu trao đổi giữa người dùng và website được bảo mật và giữ kín.
Sử dụng VPN giúp bạn truy cập vào những website bị chặn do giới hạn địa lý, vì khi kết nối, thiết bị của bạn sẽ sử dụng địa chỉ IP của máy chủ VPN, từ đó vượt qua các hạn chế liên quan đến địa chỉ IP hiện tại.
Một số nền tảng đã được phát triển
Trong quá trình khảo sát các nền tảng tấn công phòng thủ, sinh viên gặp khó khăn với mã nguồn và tài liệu do ban tổ chức các cuộc thi hạn chế công bố thông tin hỗ trợ Dưới đây là ba nền tảng mã nguồn mở mà sinh viên đã tìm hiểu và dựng lại hệ thống dựa trên các mã nguồn này.
Mô hình nền tảng tấn công - phòng thủ của iCTF
Hình 3.1: Kiến trúc mô hình tấn công - phòng thủ của iCTF[7]
Mô hình nền tảng tấn công - phòng thủ iCTF là một nền tảng mã nguồn mở được phát triển bởi UCSB từ năm 2003 và hiện vẫn đang được hoàn thiện.
Kiến trúc hệ thống của iCTF bao gồm.
• VulnerableServer: Máy chủ chứa các lỗ hổng
• VPNServer: Server trung tâm kết nối các đội chơi và cả hệ thống vận hành.
• Gamebot: Thành phần tính điểm các đối mỗi Tick Tính toán điểm số cho các đội và lưu trữ điểm số các đội xuống database.
Scriptbot đảm nhận nhiệm vụ đổi flag cho các đội trong mỗi vòng và kiểm tra trạng thái dịch vụ của các đội trong khoảng thời gian nhất định trong mỗi round.
• Database: Lưu trữ trạng thái của cuộc thi.
• Scoreboard: Hiển thị thông tin điểm số các đội thi theo thời gian, cho phép mọi người theo dõi trận đấu.
• Team Interface: Cho phép các đội chơi đăng ký, là nơi nhận và kiểm tra flag các đội chơi gửi lên trong các vòng.
Hệ thống kiến trúc cho phép các đội chơi truy cập máy chủ chứa lỗ hổng qua mạng riêng ảo OpenVPN, với địa chỉ IP được ẩn nhờ cơ chế NAT 1 n-1 Mọi yêu cầu trong mạng riêng ảo sẽ được VPNServer thay đổi địa chỉ nguồn thành một IP duy nhất, giúp trộn lẫn yêu cầu của các đội chơi và quản lý Điều này không chỉ bảo vệ danh tính của các đội mà còn ngăn chặn việc chặn yêu cầu dịch vụ từ một địa chỉ IP cụ thể của đội khác.
Nếu đội chơi cố tình chặn địa chỉ IP từ VPNServer, họ sẽ ngăn cả kết nối tới VPNServer và hệ thống thi đấu, dẫn đến việc không thể tham gia trận đấu Trong hệ thống, đơn vị thời gian nhỏ nhất là tick, và một vòng đầu được hình thành từ nhiều tick Tick giúp hệ thống đồng bộ hơn và cho phép ban tổ chức điều chỉnh thời gian vòng đấu bằng cách thay đổi số lượng tick, từ đó có thể rút ngắn thời gian các vòng đấu cuối, tạo sự gấp rút và kịch tính giữa các đội thi.
Scriptbot chịu trách nhiệm kiểm tra trạng thái và phân phát "flag" đến các dịch vụ Trong quá trình thi đấu, Scriptbot quản lý đồng thời nhiều dịch vụ kiểm tra, và trong mỗi tick, nó sẽ điều khiển một dịch vụ đến dịch vụ khác.
Trong Chương 3, các đội cập nhật “flag” cho dịch vụ tương ứng Thành phần Scriptbot sẽ ra lệnh cho nhiều dịch vụ kiểm tra hoạt động bình thường của các đội và xác định sự tồn tại của “flag” Một dịch vụ có thể được kiểm tra nhiều lần trong một tick, và cả hai chức năng kiểm tra dịch vụ cũng như phân phát “flag” đều được Scriptbot thực hiện thông qua chức năng “benign”.
Thông tin về các đội chơi được Gamebot cung cấp thông qua module dispatcher sử dụng RabbitMQ, cho phép kiểm tra và cập nhật "flag" tới dịch vụ của các đội Gamebot không chỉ ra lệnh cho Scriptbot hoạt động mà còn quản lý các dịch vụ trong hệ thống và tính điểm dựa trên dữ liệu từ Scriptbot và thành phần kiểm tra "flag".
Thành phần Team Interface hỗ trợ người chơi và đội chơi giao tiếp hiệu quả với hệ thống thông qua các API công khai Người chơi có thể thực hiện các tương tác quan trọng trong trận đấu, bao gồm đăng ký tham gia, gửi “flag” từ đội khác để tính điểm, và nhận thông tin về đội có thể tấn công cũng như điểm số hiện tại của mình.
Hệ thống đã khắc phục các vấn đề như kết nối, thiết lập máy chủ cho các đội chơi, cung cấp dịch vụ tính điểm, cập nhật “flag” và ngăn chặn gian lận Điểm nổi bật trong thiết kế là đơn vị thời gian nhỏ nhất được xác định là tick thay vì các vòng Hệ thống cũng sử dụng ngôn ngữ lập trình Python, điều này mang lại lợi ích lớn cho việc phát triển và duy trì trong tương lai.
Cơ chế giấu địa chỉ IP thông qua NAT gặp khó khăn trong việc bảo vệ đội phòng thủ trước các cuộc tấn công DDoS Khi bị tấn công, đội chơi chỉ nhận diện được địa chỉ IP tấn công là địa chỉ IP chung của hệ thống, không thể ngăn chặn truy cập từ địa chỉ này mà không làm gián đoạn kết nối với hệ thống trận đấu Hệ quả là đội có thể bị tê liệt trong suốt thời gian thi đấu, dẫn đến sự mất công bằng giữa các đội chơi.
Nền tảng này sở hữu thiết kế rõ ràng và rành mạch, với các thành phần được phân chia theo chức năng riêng biệt, giúp hệ thống duy trì hoạt động bình thường ngay cả khi một thành phần gặp sự cố Sinh viên có thể học hỏi nhiều từ các chức năng và thành phần chi tiết của hệ thống trong quá trình thiết kế Tuy nhiên, việc kết nối giữa các đội sinh viên vẫn đang được xem xét thêm.
Mô hình nền tảng tấn công - phòng thủ saarCTF
Mô hình nền tảng tấn công - phòng thủ saarCTF được phát triển bởi Markus Bauer với sự hỗ trợ của Jonas Bushart và Patrick Schmelzeisen, bao gồm ba thành phần chính trong kiến trúc hệ thống.
• GameServer: Máy chủ kiểm soát thông tin trận đấu gồm các thành phần nhỏ hơn như sau.
– Control panels: Web hiển thị cho phép quản lý trận đấ.
– Round timer: gửi thông tin đến redis cache mỗi vòng.
– Scoreboard: hiển thị thông tin diễn biến trận đấu cho khán giả theo dõi.
– Flag submitter: thành phần kiểm tra “flag” do các đội gửi lên và lưu xuống database.
– Database: Database lưu trữ thông tin toàn bộ trận đấu.
– Dispatcher: Thành phần tạo và phân phát “flag” cho các đội chơi mỗi vòng.
– Checker: Bot kiểm tra dịch vụ các đội chơi theo trong một khoảng thời gian nhỏ hơn vòng là tick.
• Game Router: Server trung tâm kết nối các đội chơi và cả hệ thống vận hành.
• TeamVulnbox: máy chủ chứa các dịch vụ có các lỗ hổng do ban tổ chức cung cấp.
• TeamRouter: Thành phần hỗ trợ kết nối giữa các TeamVulnbox và GameRouter.
Nền tảng này áp dụng cơ chế kết nối tương tự như iCTF, sử dụng mạng riêng ảo OpenVPN với NAT Hệ thống được xây dựng theo kiến trúc tập trung, với các chức năng quản lý tập trung tại GameServer Ngoài những chức năng cơ bản giống iCTF, hệ thống còn hỗ trợ điều khiển trực tiếp các thành phần thông qua giao diện web.
Mô hình nền tảng tấn công - phòng thủ Cardinal
Mô hình nền tảng tấn công - phòng thủ Cardinal[6] được phát triển bởi Vidar-Team 2 và vẫn đang trong quá trình phát triển.
Hình 3.2: Màn hình theo dõi tiến trình trận đấu trực quan của Cardinal
Nền tảng này có một số đặc điểm như sau.
• Máy chủ đội chơi: máy chủ chứa các lỗ hổng do các đội chơi tự vận hành và cung cấp.
• Điều khiển trung tâm: Controller nắm vai trò toàn bộ: sinh flag, đổi flag cho các độ, kiểm tra flag và kiểm tra trạng thái dịch vụ các đội.
• Kết nối: Các đội kết nối với nhau thông qua địa chỉ IP xác định của máy chủ.
• Hỗ trợ theo dõi: Khán giả có thể theo dõi tiến trình trận đấu theo thời gian thực thông qua ứng dụng trực quan.
Hệ thống có trang quản lý trực quan hỗ trợ ban tổ chức và các đội chơi, đồng thời sử dụng ngôn ngữ lập trình Golang, giúp việc triển khai trở nên dễ dàng hơn.
Mô hình nền tảng này có một số khuyết điểm.
Hệ thống kết nối hiện tại chưa hỗ trợ tính năng ẩn danh cho các đội chơi trong quá trình thi đấu, điều này có thể gây ra sự phân biệt đối xử, chẳng hạn như đội A có thể chặn truy cập từ địa chỉ IP của đội B.
• Thành phần điều khiển trung tâm thực hiện quá nhiều việc cùng lúc, khi thành phần này gặp vấn đề sẽ dẫn tới cả hệ thống bị dừng.
Máy chủ với các lỗ hổng do đội chơi cung cấp giúp giảm chi phí vận hành cho ban tổ chức, đồng thời củng cố ý tưởng ban đầu về việc để đội chơi tự host Việc sử dụng Golang làm ngôn ngữ lập trình chính cũng mang đến những gợi ý mới cho sinh viên.
Phân tích và thiết kế hệ thống
Phương pháp đề xuất
Để giải quyết vấn đề phía trên và phù hợp với thời gian làm luận văn sinh viên đề xuất một số phương pháp như sau.
Trong quá trình cung cấp máy chủ cho các đội chơi, ban tổ chức sẽ gửi cho mỗi đội một hình ảnh của máy ảo trước mỗi trận đấu, chứa các thiết lập hệ thống máy chủ và dịch vụ có lỗ hổng Các dịch vụ này hoạt động độc lập trong một môi trường nhỏ hơn trên máy chủ, không có sự tương tác với nhau Mã bí mật, hay còn gọi là “flag”, được lưu trữ trong một chương trình hoạt động và việc cập nhật “flag” cho từng dịch vụ sẽ được thực hiện bởi một chương trình khác trong môi trường bên ngoài máy chủ sau mỗi vòng đầu.
Để đảm bảo an toàn cho các đội trong các vòng đấu, hệ thống hỗ trợ kết nối qua mạng riêng ảo (VPN) và thay đổi địa chỉ IP của từng máy chủ sau mỗi vài vòng Việc này không chỉ giúp ẩn danh các đội chơi, mà còn giảm thiểu nguy cơ bị tấn công DDoS khi danh tính bị lộ Hơn nữa, việc thay đổi địa chỉ IP còn hỗ trợ ban tổ chức trong việc phát hiện các đội có dấu hiệu tấn công DDoS, vì các cuộc tấn công sẽ nhắm vào những địa chỉ IP cũ của hệ thống.
Trong hệ thống đồng bộ thời gian, đơn vị thời gian nhỏ nhất được gọi là tick, và một vòng thi đấu bao gồm nhiều tick kết hợp Các bộ phận quản lý hoạt động dựa trên tick, trong khi các đội chơi theo dõi thời gian theo đơn vị vòng Đặc biệt, kịch bản trận đấu có thể được tăng tốc vào cuối trận bằng cách giảm số lượng tick trong các vòng.
Mỗi chức năng của hệ thống được sinh viên tách thành các thành phần độc lập, giúp dễ dàng vận hành và đảm bảo tính sẵn sàng Khi một thành phần gặp sự cố, hệ thống chỉ cần tắt thành phần đó, thay vì phải tắt cả một cụm chức năng như saarCTF.
Kiến trúc đề xuất
Khối đội chơi - kết nối
Đi sâu vào chi tiết thành phần với hình minh họa:
Hình 4.2: Kiến trúc chi tiết khối đội chơi - kết nối.
Dưới đây là cấu trúc của TeamVM máy ảo được đưa về cho các đội vận hành.
Thành phần chính hỗ trợ việc thay đổi địa chỉ IP là clientVPNChanger, giúp máy chủ của đội chơi thực hiện việc đổi địa chỉ IP trong mạng cục bộ sau mỗi vài vòng.
Flag.bin là dịch vụ hoạt động theo chu kỳ, gửi yêu cầu định kỳ tới GameBot để lấy cờ mới cho toàn bộ dịch vụ trên máy chủ và lưu trữ trong bộ nhớ của nó.
The containers include services provided by the organizers, specifically the TeanVM_challenge_x, along with a service called flag_x.bin that retrieves the corresponding flag from flag.bin.
• Thành phần hỗ trợ kết nối cho các người chơi.
Thành phần TeamVM bao gồm các máy ảo chứa dịch vụ có lỗ hổng bảo mật do ban tổ chức cung cấp Những máy ảo này sẽ được phân phát cho các đội chơi để vận hành thông qua các ảnh máy ảo Để đảm bảo tính đồng nhất giữa các đội, các dịch vụ có lỗ hổng và chương trình hỗ trợ trong tất cả máy ảo sẽ giống nhau, chỉ khác biệt ở các thiết lập định danh của từng đội Các dịch vụ chứa lỗ hổng sẽ là
Dịch vụ mục tiêu có thể chứa nhiều lỗ hổng khác nhau, cho phép đội tấn công kiểm soát và tìm kiếm "flag" để gửi về ban tổ chức Để đảm bảo tính độc lập giữa các dịch vụ trong cùng một máy ảo, TeamVM thiết kế các dịch vụ hoạt động trong các môi trường độc lập gọi là container Trong quá trình thiết kế, sinh viên nhận thấy rằng việc lưu trữ "flag" dưới dạng tệp tin tĩnh có thể bị đội phòng thủ xóa, vì vậy họ quyết định lưu trữ "flag" trong một dịch vụ hoạt động liên tục Cụ thể, "flag" được lưu trữ bên ngoài container dưới dạng flag.bin và bên trong container là flag_x.bin Khi một đội chiếm quyền kiểm soát container, họ có thể chạy dịch vụ flag_x.bin để nhận "flag" tương ứng từ flag.bin.
Flag.bin gửi yêu cầu tới GameBot để nhận "flag" sau mỗi vòng và phải xác thực rằng nó đã hoạt động liên tục ở vòng trước bằng cách chứng minh việc giữ "flag" Nếu flag.bin bị tắt, bộ nhớ dịch vụ sẽ reset và "flag" của vòng trước sẽ mất Sau khi xác thực thành công, GameBot sẽ trả lại các "flag" tương ứng cho flag.bin để lưu trữ Nếu flag.bin không thực hiện xác thực trong một vòng, đội sẽ bị coi là gian lận và không nhận được điểm thưởng phòng thủ cho vòng đó.
Cấu tạo thành phần VPN SERVER gồm hai thành phần nhỏ hơn.
• change_IP: đây là một dịch vụ hoạt động liên tục hỗ trợ việc chuyển đổi địa chỉ IP trong mạng cục bộ.
• connects là phần minh họa cho việc chuyển hướng yêu cầu của các thành phần trong mạng riêng ảo do VPN SERVER thực hiện.
Thành phần VPNServer là trung tâm kết nối giữa các máy chủ của đội chơi và hệ thống trong mạng riêng ảo, hỗ trợ chuyển hướng gói tin từ địa chỉ nguồn tới đích Ngoài việc kết nối, VPNServer còn có chức năng quan trọng là đổi địa chỉ IP trong mạng riêng ảo của các thành phần trong hệ thống Mỗi khi kết thúc vài vòng đấu, VPNServer nhận lệnh từ Gamebot để gửi yêu cầu thay đổi thông tin tới các thành phần mục tiêu và khởi động lại mạng riêng ảo với các thiết lập mới.
Đội chơi cần kết nối đến máy chủ để điều khiển, nhưng việc kết nối trực tiếp qua nhiều nút ISP có thể làm giảm tốc độ Để cải thiện tốc độ kết nối, người chơi có thể sử dụng VPN PLAYER với các gateway từ doanh nghiệp lớn, giúp giảm thiểu số lượng nút ISP cần đi qua Ví dụ, người chơi ở Châu Âu có thể kết nối vào node tại EU, trong khi người chơi ở Châu Á kết nối vào các nút tại Asia Doanh nghiệp sẽ tối ưu hóa kết nối giữa các node EU và Asia, giúp người phát triển tập trung vào việc phát triển ứng dụng mà không phải lo lắng về vấn đề kết nối Do đó, việc sử dụng VPN Player và VPN Gateway là rất cần thiết cho đội chơi.
Khối này gồm các thành phần.
Ta đi sâu vào khối vận hành thông qua kiến trúc chi tiết dưới đây.
Scriptbot là công cụ kiểm tra trạng thái dịch vụ trong hệ thống, hoạt động độc lập trong các trận đấu với nhiều Scriptbot Chúng chỉ thực hiện lệnh từ thành phần Service Status và cần mã nguồn kiểm tra do các tác giả dịch vụ cung cấp để đánh giá các chức năng cơ bản Tuy nhiên, Scriptbot không được phép kiểm tra “flag” của các đội, nhằm tránh lộ thông tin về lỗ hổng dịch vụ qua phân tích luồng tấn công Mã nguồn kiểm tra cần được tổ chức trong một cấu trúc thư mục xác định để hỗ trợ Scriptbot thiết lập các giá trị môi trường khi hoạt động.
Để kiểm tra dịch vụ của các đội chơi, thành phần Scriptbot cần kết nối với mạng riêng ảo do VPNServer thiết lập, đồng thời cũng là một trong những đối tượng được đổi địa chỉ IP trong mạng này Dưới đây là bốn chức năng chính của Scriptbot.
Kiểm tra trạng thái dịch vụ máy chủ của các đội chơi là một phần quan trọng trong quy trình vòng đấu Scriptbot sẽ gửi yêu cầu đến dịch vụ của các đội, tương tự như một đội tấn công bình thường, nhằm xác định xem dịch vụ có hoạt động hay không Kết quả kiểm tra sẽ được lưu trữ vào bộ nhớ để theo dõi hiệu suất dịch vụ.
Cuối mỗi tick, Scriptbot gửi dữ liệu về trạng thái các dịch vụ của các đội đến thành phần tổng hợp trạng thái Điều này giúp đánh giá xem dịch vụ có hoạt động hay không trong khoảng thời gian đó.
Scriptbot nhận lệnh từ thành phần tổng hợp trạng thái để kiểm tra các dịch vụ của các đội có dấu hiệu đáng ngờ.
• Phát hiện gian lận khi các đội chơi cố tình chặn kết nối từ đội chơi khác.
Với khả năng phát hiện gian lận trong các đội chơi, bài viết này tổng hợp kết quả kiểm tra từ các Scriptbot sau khi thực hiện đổi địa chỉ IP trong mạng riêng ảo mỗi vài vòng đấu Kịch bản phát hiện gian lận diễn ra như sau.
Trong một vòng đấu, đội chơi gian lận cố tình chặn kết nối từ đội khác thông qua địa chỉ IP Sau mỗi vài vòng, địa chỉ IP của đội bị chặn sẽ được thay đổi cho các Scriptbot hoạt động Khi Scriptbot sử dụng địa chỉ IP đã bị chặn để kiểm tra dịch vụ của đội gian lận, kết quả cho thấy dịch vụ không hoạt động Để xác minh tình trạng chặn địa chỉ IP, thành phần Service Status sẽ ra lệnh cho tất cả Scriptbot với các địa chỉ IP khác kiểm tra đội chơi này Nếu kết quả từ các Scriptbot không đồng nhất (có hoạt động hoặc không hoạt động), điều này chứng tỏ đội chơi đã gian lận bằng cách chặn kết nối từ đội khác.
Docker Container
Docker container là đơn vị phần mềm tiêu chuẩn, giúp đóng gói mã nguồn và dữ liệu cần thiết để chạy trên nhiều môi trường khác nhau Docker container image chứa toàn bộ mọi thứ cần thiết để chạy một ứng dụng, bao gồm mã nguồn, môi trường, công cụ, thư viện hệ thống và cấu hình Khi khởi động, Docker container image trở thành Docker container, cho phép các ứng dụng Linux chạy trên Windows hoặc MacOS Docker cung cấp môi trường độc lập cho mỗi ứng dụng, tương tự như máy ảo, nhưng tiết kiệm tài nguyên hơn nhờ chia sẻ kernel của hệ điều hành Tuy nhiên, để chạy Docker trên Windows hoặc MacOS, cần giả lập Linux kernel, do đó hiệu năng tối đa của Docker chỉ đạt được trên hệ điều hành Linux.
Việc sử dụng công nghệ Docker giúp đơn giản hóa quá trình vận hành và phân tách các ứng dụng, với mỗi dịch vụ chạy trên một Docker container riêng biệt, đảm bảo bộ nhớ độc lập Khi một đội đối thủ khai thác một dịch vụ, họ không thể tác động đến các dịch vụ khác trên cùng một máy chủ Để quản lý và giao tiếp hiệu quả với các Docker container, sinh viên sử dụng Docker-compose, giúp các đội chơi dễ dàng bật/tắt các dịch vụ một cách thuận lợi.
Hình 5.1: Kiến trúc hoạt động của docker
Wireguard
WireGuard là một ứng dụng mã nguồn mở với giao thức VPN, cho phép tạo kết nối điểm - điểm an toàn trong các cấu hình định tuyến hoặc cầu nối Chạy như một module trong nhân Linux hoặc BSD, WireGuard cải thiện hiệu suất và tiết kiệm năng lượng hơn so với IPsec và OpenVPN Được phát triển bởi Jason A Donenfeld và phát hành theo giấy phép GNU GPL phiên bản 2, WireGuard ra mắt phiên bản ổn định vào tháng 3 năm 2020 Với code base chỉ khoảng 3,800 dòng, WireGuard dễ dàng kiểm thử và vá lỗ hổng hơn so với OpenVPN và IPsec, có số dòng mã lên tới 600,000 và 400,000 tương ứng Thực nghiệm cho thấy WireGuard nhanh hơn 58% so với OpenVPN, và việc thiết lập kết nối cũng rất đơn giản, giúp người dùng dễ dàng kết nối hơn.
Go
Go là một ngôn ngữ lập trình biên dịch, kiểu tĩnh, được phát triển bởi Google bởi các nhà sáng lập Robert Griesemer, Rob Pike và Ken Thompson Với cú pháp tương tự như C, Go mang lại độ an toàn cao hơn về bộ nhớ Ngôn ngữ này thường được gọi là Golang do tên miền golang.org, nhưng tên chính thức của nó là Go.
Go là ngôn ngữ lập trình có cấu trúc đơn giản, dễ học và không sử dụng kế thừa hay class, giúp việc duy trì trở nên dễ dàng hơn Ngôn ngữ này nổi bật với khả năng hỗ trợ đa luồng mạnh mẽ, phù hợp cho các dự án yêu cầu cao về thành phần Hơn nữa, tập tin biên dịch của Go có độ phức tạp cao, bảo vệ mã nguồn hiệu quả trước các cuộc tấn công trong tổ chức thi đấu tấn công - phòng thủ.
RabbitMQ
RabbitMQ là một chương trình trung gian giúp lưu trữ và điều phối các gói tin giữa người gửi và người nhận, sử dụng kiến trúc message broker với giao thức AMQP Điểm mạnh của RabbitMQ nằm ở cơ chế bất đồng bộ, cho phép tự động phân phát gói tin mà không cần sự can thiệp của người gửi, với các gói tin được lưu trữ trong hàng đợi Người nhận chỉ cần đăng ký để nhận gói tin Hiện nay, RabbitMQ hỗ trợ bốn chế độ gửi: gửi trực tiếp, gửi theo chủ đề, gửi tới toàn bộ, và gửi theo tiêu đề Để đảm bảo tính toàn vẹn của yêu cầu, RabbitMQ cũng cung cấp tính năng yêu cầu trả về thông tin hoàn thành, giúp tránh tình trạng mất hoặc không xử lý gói tin.
RabbitMQ hoạt động như một trung gian giữa người gửi và người nhận, do đó không có ràng buộc về ngôn ngữ lập trình giữa hai bên Hiện tại, RabbitMQ hỗ trợ đa dạng các ngôn ngữ lập trình khác nhau.
Hiện thực các thành phần hệ thống
Hệ thống sinh viên được thiết kế với ba thành phần chính: kết nối giữa người dùng và máy chủ, kiểm tra trạng thái dịch vụ, và tổng hợp trạng thái dịch vụ, nhằm đảm bảo tính khả thi cho luận văn trong thời gian thực hiện.
Xây dựng hệ thống kết nối giữa các users và server
Đặt vấn đề
Trong trận đấu tấn công - phòng thủ, các đội có thể gian lận bằng cách chặn dịch vụ từ một địa chỉ IP cụ thể, gây mất công bằng Để khắc phục vấn đề này, có thể áp dụng cơ chế dịch địa chỉ mạng (Network Address Translation) Tuy nhiên, nếu một đội bị lộ danh tính, họ có nguy cơ bị tấn công DDoS, dẫn đến việc máy chủ của họ bị tê liệt trong suốt thời gian còn lại của trận đấu.
Để bảo vệ danh tính của các đội chơi, cần áp dụng một phương thức kết nối mới Một giải pháp hiệu quả là thay đổi địa chỉ IP của các đội sau mỗi vài vòng đấu, giúp ẩn danh danh tính của họ Việc này sẽ tạo ra sự an toàn hơn cho các đội trong hệ thống.
• Máy chủ của các đội chơi.
• Các thành phần hỗ trợ kiểm tra trận đấu: Scriptbot, ComBot
Kiến trúc của kết nối
Trong hệ thống, có ba đối tượng cần đổi địa chỉ IP, bao gồm máy chủ của các đội ComBot, máy chủ của Scriptbot và máy chủ của các đội chơi Do các thành phần hỗ trợ kết nối cho ba đối tượng này tương tự nhau, kiến trúc sẽ sử dụng "Abstract object" để đại diện cho ba thành phần Hình dưới đây minh họa kết nối trong kiến trúc này.
Hình 6.1: Kiến trúc kết nối VPN
Trong mỗi vòng đấu, GameBot gửi danh sách địa chỉ IP mới đến thành phần change_IP của VPN Server Thành phần này sẽ kiểm tra cấu trúc yêu cầu và xác thực thông qua một mã bí mật đã được thiết lập trước đó.
Sau khi yêu cầu xác minh thành công, thành phần change_IP sẽ sử dụng các địa chỉ IP đã cung cấp để gửi yêu cầu đến các đối tượng, kèm theo mã bí mật tương ứng với từng "Astract object" Thành phần objectVPNChanger trong mỗi "Astract object" sẽ xác thực mã bí mật và thực hiện việc đổi địa chỉ IP trong mạng nội bộ theo yêu cầu, sau đó phản hồi kết quả về thành phần change_IP trong VPN Server.
Sau khi nhận thông tin thành công, thành phần change_IP sẽ yêu cầu khởi động lại ứng dụng WireGuard với cấu hình mới cho tất cả các "Astract object" Quá trình này cần xác thực qua mã bí mật Để đảm bảo không mất gói tin trong quá trình kết nối, change_IP sẽ chờ nhận thông tin từ tất cả "Astract object" trước khi khởi động lại kết nối WireGuard với các thiết lập mới.
Dưới đây là biểu đồ tuần tự minh họa cho hoạt động của kiến trúc này.
Hình 6.2: Biểu đồ tuần tự hoạt động thay đổi địa chỉ IP
Xây dựng thành phần kiểm tra trạng thái dịch vụ
Đặt vấn đề
Điểm phòng thủ là một trong hai thành phần quan trọng mà các đội chơi có thể đạt được, được tính dựa trên số lượng dịch vụ mà đội bảo vệ thành công trong vòng đấu Để đảm bảo tính công bằng và tránh việc các đội tắt dịch vụ trong quá trình chơi, hệ thống cần có một cơ chế kiểm tra trạng thái hoạt động của dịch vụ, xác định xem dịch vụ đó đang bật hay tắt.
Mỗi đội chơi cần kiểm tra từ 4-6 dịch vụ, dẫn đến tổng số lượng dịch vụ kiểm tra lớn Để tránh quá thời gian trong một tick, hệ thống cần cho phép nhiều Scriptbot hoạt động đồng thời và chia sẻ công việc Đồng thời, để đảm bảo tính chính xác, mỗi dịch vụ của một đội có thể được kiểm tra bởi nhiều Scriptbot trong cùng một tick.
Mỗi dịch vụ đều có những lỗ hổng với thiết kế và đặc điểm riêng, vì vậy mã nguồn kiểm tra cần được điều chỉnh cho phù hợp Để đảm bảo việc kiểm tra diễn ra chính xác, các mã nguồn này phải được viết riêng bởi những người phát triển dịch vụ có lỗ hổng.
Kiến trúc của thành phần kiểm tra trạng thái dịch vụ sơ khởi
Hình 6.3: Biểu đồ kiến trúc thành phần kiểm tra trạng thái dịch vụ sơ khởi
Scriptbot là một trong ba đối tượng cần đổi địa chỉ IP trong hệ thống, với thành phần hỗ trợ kết nối mạng riêng ảo là VPN Connect Để kiểm tra các dịch vụ, Scriptbot cần có mã nguồn kiểm tra tương ứng do người ra đề cung cấp, gọi là ScriptCheck Khi hoạt động, thành phần Service của Scriptbot sẽ sử dụng các mã nguồn kiểm tra và cấu trúc thư mục chứa bên trong thành phần.
ScriptCheck để xây dựng lên một cấu trúc dữ liệu gồm các dịch vụ và đường dẫn tới mã nguồn kiểm tra dịch vụ.
Khi nhận yêu cầu kiểm tra dịch vụ từ Service Status qua hệ thống API, thành phần Service sẽ kết hợp địa chỉ máy chủ mục tiêu với các dịch vụ đã lưu trữ trong cấu trúc dữ liệu Sau đó, nó sẽ ngẫu nhiên chọn một mã nguồn kiểm tra từ bộ mã do người phát triển cung cấp, sử dụng thành phần VPN Connect để xác định trạng thái của dịch vụ tương ứng.
Kết quả trả về sẽ được thành phần Service chuyển tiếp về cho ServiceStatus.
Kiến trúc của thành phần kiểm tra trạng thái dịch vụ hiện thực
Trong quá trình phát triển và kiểm thử kiến trúc thành phần sơ khởi, sinh viên đã nhận ra một nhược điểm quan trọng, đó là hiệu quả trong việc phân chia công việc cho các Scriptbot.
Chương 6 rỗi” thì việc lại giao cho các Scriptbot đang xử lý công việc Do đó sinh viên quyết định để Scriptbot chủ động nhận việc thông qua kết nối với RabbitMQ để nhận nhiệm vụ. Scriptbot có thể nhận việc mới ngay sau khi hoàn thành việc kiểm tra các công việc hiện tại Ngoài ra việc sử dụng RabbitMQ sẽ tiện lợi hơn khi thêm hoặc bớt các Scriptbot khi hệ thống vận hành.
Bước đầu tiên trong quy trình kiểm tra trạng thái dịch vụ là sử dụng thành phần Bộ khởi tạo để xây dựng cấu trúc dữ liệu từ các tệp thi trong thư mục mã nguồn kiểm tra Cấu trúc dữ liệu này bao gồm tên dịch vụ kiểm tra và đường dẫn tới các tệp kiểm tra tương ứng.
Scriptbot kết nối với Service Status bằng việc sử dụng thành phầnRabbitmq Connec- tor Thành phần Rabbitmq Connector subscribe các channel trên RabbitMQ được dựng tại Service Status.
Mỗi khi Scriptbot “rảnh rỗi”, thành phầnRabbitmq Connectorsẽ được Service Status gửi các thông tin các đội cần kiểm tra qua các channel.
Bộ điều khiển sẽ kiểm tra định dạng dữ liệu và yêu cầu danh sách dịch vụ từ Bộ khởi tạo Đối với mỗi dịch vụ, nó sẽ chọn một mã kiểm tra và sử dụng mã này để khởi tạo dịch vụ Kiểm tra, với các tham số là địa chỉ và cổng kết nối của đội cần kiểm tra dịch vụ.
Dịch vụ Kiểm tra dựa trên địa chỉ và cổng kết nối sử dụng mạng riêng ảo để kết nối đến dịch vụ tương ứng Kết quả kiểm tra sẽ được Bộ điều khiển gửi về Service Status để tổng hợp.
Sau khi hoàn tất các dịch vụ trong danh sách, Scriptbot sẽ tiếp tục xử lý các đối tượng còn lại hoặc chờ nhận các đối tượng mới từ Service Status qua các kênh liên lạc.
Dưới đây là biểu đồ tuần tự thể hiện cho quá trình kiểm tra dịch vụ của Scriptbot.
Hình 6.5: Biểu đồ tuần tự quá trình kiểm tra dịch vụ của thành phần kiểm tra trạng thái dịch vụ
Xây dựng thành phần tổng hợp trạng thái dịch vụ
Đặt vấn đề
Để đảm bảo hệ thống kiểm tra hoạt động hiệu quả, cần có nhiều Scriptbot hoạt động đồng thời Việc phân chia nhiệm vụ hợp lý và tổng hợp kết quả từ các Scriptbot yêu cầu một thành phần xử lý, đó chính là thành phần tổng hợp trạng thái dịch vụ - Service Status.
Kiến trúc của thành phần tổng hợp trạng thái dịch vụ sơ khởi
Hình 6.6: Biểu đồ kiến trúc thành phần tổng hợp trạng thái dịch vụ sơ khởi
Mỗi đầu tick, Gamebot sẽ gửi thông báo xuống ServiceStatus thông qua hệ thống
API, yêu cầu này sẽ được chuyển hướng qua thành phần Bộ phận điều khiển.
Bộ phận điều khiển sẽ gửi yêu cầu lại Gamebot để nhận thông tin cập nhật của các đội mới được thay đổi mỗi Round.
Dựa trên thông tin thu thập được, Bộ phận điều khiển sẽ truyền dữ liệu đến Bộ phân chia công việc Tại đây, công việc sẽ được phân chia đồng đều dựa trên số lượng Scriptbot đã được định nghĩa trong biến môi trường, sau đó gửi yêu cầu đến các Scriptbot tương ứng.
Khi các Scriptbot gửi thông tin qua hệ thống API, dữ liệu sẽ được chuyển tới Bộ phận tổng hợp Trạng thái dịch vụ của các đội sẽ được lưu trữ và được gửi đi đồng thời vào cuối mỗi tick.
Kiến trúc của thành phần tổng hợp trạng thái dịch vụ hiện thực
Trong quá trình hiện thực và kiểm thử kiến trúc sơ khởi sinh viên nhận thấy có ba vấn đề phát sinh gồm.
Bộ phận phân chia công việc hiện chưa đạt hiệu quả tối ưu, dẫn đến tình trạng một số Scriptbot phải tiếp nhận thêm nhiệm vụ trong khi vẫn có những Scriptbot khác đang ở trạng thái "rảnh rỗi".
• Việc thêm bớt số lượng Scriptbot gặp nhiều khó khăn khi ta phải thay đổi thiết lập và khởi động lại cả ServiceStatus.
Dịch vụ Status hiện chỉ hoạt động với công suất hạn chế, mới chỉ thực hiện một lần kiểm tra và tổng hợp kết quả Để khắc phục vấn đề này, sinh viên đã quyết định sử dụng RabbitMQ để lưu trữ và phân chia nhiệm vụ cho các Scriptbot, đồng thời bổ sung chức năng điều khiển để các Scriptbot thực hiện kiểm tra lại Sơ đồ mô-đun này được trình bày bên dưới.
Hình 6.7: Biểu đồ kiến trúc thành phần tổng hợp trạng thái dịch vụ
Thành phần của kiến trúc bao gồm:
• API: cổng lắng nghe các yêu cầu gửi đến ServiceStatus.
• Bộ điều khiển: thành phần vận hành điều khiển các hoạt động chính của ServiceS- tatus.
Bộ tổng hợp là hệ thống thu thập và xử lý thông tin từ các Scriptbot, giúp ra quyết định về việc lưu trữ dữ liệu hoặc gửi lệnh cho các Scriptbot thực hiện kiểm tra lại thông tin.
• RabbitMQ: dịch vụ hỗ trợ phân phát các gói tin kiểm tra tới các Scriptbot gồm hai kênh chính.
– Kênh normalCheck - kênh hoạt động thông thường: kệnh chuyển từng gói tin cho các Scriptbot, các Scriptbot sẽ được nhận các gói tin khác nhau.
– Kênh emergencyCheck - kênh hoạt động khẩn: mỗi gói tin lưu trên kênh này sẽ đều được gửi tới tất cả các Scriptbot.
Trong khoảng thời gian một tick của trận đấu Service Status hoạt động với bốn giai đoạn như sau.
• Giai đoạn 1 (0.4 Tick): Khởi tạo, nhận lệnh từ Gamebot, phân phát các gói tin cho các Scriptbot kiểm tra.
• Giai đoạn 2 (0.3 Tick): Nhận kết quả từ các Scriptbot, tổng hợp kết quả lần 1, gửi yêu cầu kiểm tra các trường hợp không hợp lệ.
• Giai đoạn 3 (0.1 Tick): Tổng hợp kết quả lần 2.
• Giai đoạn 4 (0.2 Tick): Gửi kết quả về thành phần Ranking.
Dưới đây hình ảnh minh hoạ cho các giai đoạn hoạt động của Service Status trong một tick.
Hình 6.8: Các giai đoạn hoạt động của Service Status trong một tick.
Mỗi đầu tick, Gamebot sẽ gửi thông báo xuống ServiceStatus thông qua hệ thốngAPI, yêu cầu này sẽ được chuyển hướng qua thành phần Bộ phận điều khiển.
Thành phần Bộ phận điều khiển sẽ gửi yêu cầu lại Gamebot để nhận thông tin cập nhật của các đội mới được thay đổi mỗi Round.
Từ các thông tin trả về, thành phầnBộ phận điều khiểnsẽ publish các gói tin các đội cần kiểm tra lên kênh normalCheck của RabbitMQ.
Mỗi một Scriptbot “rảnh rỗi” subscribe normalCheck channel, sẽ được channel này phân phát thông tin một đội để kiểm tra.
Khi các Scriptbot gửi thông tin qua API, dữ liệu sẽ được chuyển đến Bộ phận tổng hợp Nếu dịch vụ của đội hoạt động bình thường, kết quả sẽ được lưu trữ Ngược lại, nếu dịch vụ không hoạt động, có hai lý do khả thi cho tình trạng này.
• Đội này đang tắt dịch vụ đi để vá lỗi.
Đội đã chặn yêu cầu dịch vụ từ địa chỉ IP mà Scriptbot đang sử dụng Hành động này là kết quả của việc chặn địa chỉ IP của các đội khác ở vòng trước, dẫn đến việc địa chỉ IP của Scriptbot bị chặn sau khi các thành phần trong VPN đổi địa chỉ IP.
Bộ tổng hợp sẽ gửi thông tin dịch vụ của đội vào kênh emergencyCheck để kiểm tra diện rộng Thông tin này được chuyển tới tất cả các Scriptbot, chúng sẽ cùng kiểm tra và gửi kết quả về hệ thống API Kết quả sẽ được chuyển đến Bộ phận tổng hợp Nếu bất kỳ Scriptbot nào báo cáo dịch vụ không hoạt động, bộ tổng hợp sẽ xác nhận rằng dịch vụ này không hoạt động, tức là đội này không có điểm phòng thủ cho dịch vụ đó.
Chương 6 về Ranking để tính toán điểm số cho các đội.
Dưới đây là hai biểu đồ tuần tự cho hai giai đoạn: ra lệnh kiểm tra lần đầu và tổng hợp kết quả của Service Status.
Hình 6.9: Biểu đồ tuần tự phân phát việc hoạt động mỗi đầu tick ơng6
Hình 6.10: Biểu đồ tuần tự xử lý một kết quả trả về từ Scriptbot
7 Đánh giá và kiểm thử
