Nghiên cứu và phát triển nền tảng tổ chức thi tấn công phòng thủ máy tính efiens giai đoạn 1 thiết kế hệ thống và xây dựng module giao tiếp giữa các users vaf server, thành phần kiểm tra dịch vụ và tổng hợp trạng thái dịch vụ

KHMT5 GVHD: GVPB: -o0o SVTH: - 1712778 KHMT5 GVHD: GVPB: -o0o SVTH: - 1712778 - - KHOA:KH & KT Máy tính KHMT Chú ý: Sinh viên p NGÀNH: MSSV: 1712778 MT17KH3 Máy tính : tính Efiens server, thành (Building Efiens CTF Platform: System design and developing a client-server interacting module, checking service and summarizing service status) -The- phân tích , o o o Tích h , ã hi : 22/02/2021 07/06/2021 , K q , George Mason , Zalora Group N P _ _ _ KHOA KH & KT MÁY TÍNH MSSV: 1712778 (MT17KH3) -Ngày 11 tháng 08 2021 Ngành (chuyên ngành): KHMT (Building Efiens CTF Platform: System design and developing a client-server interacting module, checking service and summarizing service status) ng, K , George Mason , Zalora group 48 08 17 :3 : LV vi trình bày ách, â N : Khơng có ( ) 8.5/10 TRƯỜNG ĐẠI HỌC BÁCH KHOA KHOA KH & KT MÁY TÍNH CỘNG HỊA XÃ HỘI CHỦ NGHĨA VIỆT NAM Độc lập - Tự - Hạnh phúc -Ngày tháng 08 năm 2021 PHIẾU CHẤM BẢO VỆ LVTN (Dành cho người hướng dẫn/phản biện) Họ tên SV: Nguyễn Minh Quang MSSV: 1712778 Ngành (chuyên ngành): Khoa Học Máy Tính Đề tài: Nghiên cứu phát triển tảng tổ chức thi cơng – phịng thủ máy tính Efiens Giai đoạn 1: Thiết kế hệ thống xây dựng mô-đun giao tiếp users server, thành phần kiểm tra dịch vụ tổng hợp trạng thái dịch vụ Họ tên người hướng dẫn/phản biện: /Trần Hồng Tài Tổng quát thuyết minh: Số trang: Số chương: Số bảng số liệu: Số hình vẽ: Số tài liệu tham khảo: Phần mềm tính tốn: Hiện vật (sản phẩm) Tổng quát vẽ: - Số vẽ: Bản A1: Bản A2: Khổ khác: - Số vẽ vẽ tay Số vẽ máy tính: Những ưu điểm LVTN: - Luân văn đưa ứng dụng cụ thể sát với thực tế - Luận văn tìm hiểu ưu điểm, nhược điểm tảng, mơ hình liên quan - Đưa đề xuất để thay đổi IP tự động để cải thiện rủi DDos trình vận hành - Sử dụng phần máy tính từ users giảm cấu hình u cầu cho server - Có định hướng phát triển cho đề tài Những thiếu sót LVTN: - Phần đánh giá sử dụng giả lập chưa phân tích tình thực tế - Nên miêu tả rõ phần cài đặt vật lý hệ thống Đề nghị: Được bảo vệ  Bổ sung thêm để bảo vệ  Không bảo vệ  câu hỏi SV phải trả lời trước Hội đồng: - Cấu hình yêu cầu cho máy chủ hệ thống - Hướng xử lý trường hợp đội chơi bị kết nối trước trình thay đổi ip 10 Đánh giá chung (bằng chữ: giỏi, khá, TB): Giỏi Điểm: 8.5/10 Ký tên (ghi rõ họ tên) Trần Hồng Tài ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC BÁCH KHOA KHOA KHOA HỌC VÀ KỸ THUẬT MÁY TÍNH LUẬN VĂN TỐT NGHIỆP Nghiên cứu phát triển tảng tổ chức thi cơng – phịng thủ máy tính Efiens Giai đoạn 1: Thiết kế hệ thống xây dựng module giao tiếp users server, thành phần kiểm tra dịch vụ tổng hợp trạng thái dịch vụ Hội đồng LVTN: Khoa học máy tính Tập thể hướng dẫn: Nguyễn An Khương Khoa KH & KT Máy tính, ĐHBK Nguyễn Trí Đức George Mason University Hồng Vĩnh An Zalora Group Giảng viên phản biện: Trần Hồng Tài Khoa KH & KT Máy tính, ĐHBK Sinh viên thực hiện: Nguyễn Minh Quang 1712778 Ngày 18 tháng 10 năm 2021 Lời cam đoan Tôi xin cam đoan cơng trình nghiên cứu riêng chúng tơi hướng dẫn TS.Nguyễn An Khương, anh Nguyễn Trí Đức, anh Hoàng Vĩnh An hỗ trợ bạn Chế Minh Huy Nội dung nghiên cứu kết trung thực chưa công bố trước Các số liệu sử dụng cho q trình phân tích, nhận xét thu thập từ nhiều nguồn khác ghi rõ phần tài liệu tham khảo Nếu phát có gian lận nào, tơi xin hoàn toàn chịu trách nhiệm nội dung luận văn tốt nghiệp Trường đại học Bách Khoa thành phố Hồ Chí Minh khơng liên quan đến vi phạm tác quyền, quyền gây trình thực i Lời cảm ơn Lời nói đầu, tơi xin cảm ơn tất người giúp đỡ tơi q trình thực luận văn Đầu tiên, xin cảm ơn thầy Nguyễn An Khương, người tận tình hướng dẫn tơi q trình thực đề tài Khơng thể khơng nhắc đến anh Nguyễn Trí Đức người gợi mở ý tưởng đề tài, cố vấn kỹ thuật tham gia thiết kế hệ thống Cảm ơn bạn Chế Minh Huy, người bạn thực hệ thống Cảm ơn anh Hoàng Vĩnh An đưa gọi ý tới ý tưởng xây dựng nên kết nối chung hệ thống Tôi xin gửi lời cảm ơn đến giảng viên trường Đại học Bách Khoa Thành Phố Hồ Chí Minh, đặc biệt thầy cô Khoa Khoa học Kỹ thuật máy tính, người truyền đạt kiến thức cho suốt bốn năm học vừa qua Cuối cùng, tơi xin gửi lời cảm ơn tới gia đình, bạn bè, người động viên hỗ trợ suốt thời gian học chương trình bậc đại học ii Tóm tắt luận văn Trong thời kỳ cơng nghệ 4.0 nay, yếu tố an toàn mạng đưa lên hàng đầu Học hỏi kiến thức an tồn thơng tin thơng qua thi phương pháp thực tiễn Capture The Flag thi tíêng lĩnh vực Tuy nhiên thi chủ yếu tổ chức theo hình thức Jeopardy cịn hình thức cơng phịng thủ sát với thực tế tổ chức hạn chế Nguyên nhân nằm tảng hỗ trợ thi theo hình thức chưa thực đủ mạnh hỗ trợ tốt cho ban tổ chức Để hình thức thi tổ chức rộng rãi hơn, mục tiêu luận văn xây dựng hệ thống tảng hỗ trợ tổ chức thi Capture The Flag theo thể thức cơng phịng thủ dễ dàng việc vận hành, giảm chi phí cho ban tổ chức mà máy chủ đội chơi vận hành máy đội cung cấp iii Mục lục Lời cam đoan Lời cảm ơn Tóm tắt luận văn Mục lục Danh sách hình vẽ Danh sách thuật ngữ viết tắt i ii iii iv v vii 1 2 3 Kiến thức tảng 2.1 Capture the flag 2.2 Mạng riêng ảo - VPN 5 Giới thiệu 1.1 Đặt vấn đề 1.2 Mục tiêu phạm vi đề tài 1.2.1 Mục tiêu 1.2.2 Phạm vi đề tài 1.3 Bố cục luận văn Một số tảng phát triển 3.1 Mơ hình tảng cơng - phịng thủ iCTF 3.2 Mơ hình tảng cơng - phịng thủ saarCTF 10 3.3 Mơ hình tảng cơng - phòng thủ Cardinal 10 Phân tích thiết kế hệ thống 4.1 Đặt vấn đề 4.2 Phương pháp đề xuất 4.3 Kiến trúc đề xuất 4.3.1 Khối đội chơi - kết nối 4.3.2 Khối vận hành iv 12 12 14 14 15 18 Chương Dưới biểu đồ thể cho trình kiểm tra dịch vụ Scriptbot Hình 6.5: Biểu đồ trình kiểm tra dịch vụ thành phần kiểm tra trạng thái dịch vụ 34 Chương 6.3 Xây dựng thành phần tổng hợp trạng thái dịch vụ 6.3.1 Đặt vấn đề Như đề cập số lượng Scriptbot hoạt động phần trên, để đảm bảo hệ thống kiểm tra kịp thời cần nhiều Scriptbot hoạt động lúc Để đảm bảm nhiệm vụ phân chia hợp lý tổng hợp kết Scripttbot ta cần thành phần xử lý thành phần tổng hợp trạng thái dịch vụ - Service Status 6.3.2 Kiến trúc 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 gửi thông báo xuống ServiceStatus thông qua hệ thống API, yêu cầu chuyển hướng qua thành phần Bộ phận điều khiển Bộ phận điều khiển gửi yêu cầu lại Gamebot để nhận thông tin cập nhật đội thay đổi Round Từ thông tin trả về, thành phần Bộ phận điều khiển gửi thông tin đến thành phần Bộ phân chia công việc Ở công việc phân chia theo số lượng Scriptbot khai báo trước biến môi trường gửi yêu cầu đến Scriptbot Khi Scriptbot trả thơng tin qua hệ thống API thơng tin điều hướng tới thành phần Bộ phận tổng hợp Thông tin trạng thái dịch vụ đội lưu trữ đợi gửi thời điểm cuối tick 35 Chương 6.3.3 Kiến trúc thành phần tổng hợp trạng thái dịch vụ thực Trong trình thực 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 làm việc chưa thật hiệu có tượng Scriptbot bận rộn mà phải nhận thêm việc số Scriptbot 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 ta phải thay đổi thiết lập khởi động lại ServiceStatus • Service Status hoạt động công suất, kiểm tra lần tổng hợp kết Để giải vấn đề sinh viên định sử dụng RabbitMQ nơi để lưu trữ phân chia nhiệm vụ cho Scriptbot Và thêm chức điều khiển Scriptbot kiểm tra lại Sơ đồ module trình bày bên 36 Chương 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 kiến trúc bao gồm: • API: cổng lắng nghe 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 hoạt động ServiceStatus • Bộ tổng hợp: nơi tổng hợp thơng tin trả từ Scriptbot từ định lưu trữ thông tin lệnh cho gửi thông tin cho Scriptbot kiểm tra lại • RabbitMQ: dịch vụ hỗ trợ phân phát gói tin kiểm tra tới Scriptbot gồm hai kênh – Kênh normalCheck - kênh hoạt động thông thường: kệnh chuyển gói tin cho Scriptbot, Scriptbot nhận gói tin khác – Kênh emergencyCheck - kênh hoạt động khẩn: gói tin lưu kênh gửi tới tất Scriptbot Trong khoảng thời gian tick trận đấu Service Status hoạt động với bốn giai đoạn sau • Giai đoạn (0.4 Tick): Khởi tạo, nhận lệnh từ Gamebot, phân phát gói tin cho Scriptbot kiểm tra • Giai đoạn (0.3 Tick): Nhận kết từ Scriptbot, tổng hợp kết lần 1, gửi yêu cầu kiểm tra trường hợp không hợp lệ • Giai đoạn (0.1 Tick): Tổng hợp kết lần • Giai đoạn (0.2 Tick): Gửi kết thành phần Ranking 37 Chương Dưới hình ảnh minh hoạ cho giai đoạn hoạt động Service Status tick Hình 6.8: Các giai đoạn hoạt động Service Status tick Mỗi đầu tick, Gamebot gửi thông báo xuống ServiceStatus thông qua hệ thống API, yêu cầu 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 gửi yêu cầu lại Gamebot để nhận thông tin cập nhật đội thay đổi Round Từ thông tin trả về, thành phần Bộ phận điều khiển publish gói tin đội cần kiểm tra lên kênh normalCheck RabbitMQ Mỗi Scriptbot “rảnh rỗi” subscribe normalCheck channel, channel phân phát thông tin đội để kiểm tra Khi Scriptbot trả thông tin qua thành phần API thơng tin điều hướng tới thành phần Bộ phận tổng hợp Nếu thơng tin dịch vụ đội hoạt động bình thường kết lưu lại Nếu thơng tin dịch vụ đội không hoạt động, lúc có hai khả lý dịch vụ khơng hoạt động sau • Đội tắt dịch vụ để vá lỗi • Đội chặn yêu cầu dịch vụ từ địa IP Scriptbot sử dụng Đây hệ việc chặn địa IP đội khác từ vòng trước nên sau đổi địa IP thành phần VPN địa IP Scriptbot bị chặn Lúc tổng hợp gửi lại thông tin dịch vụ đội vào emergencyCheck channel để kiểm tra diện rộng Thông tin gửi tới tất Scriptbot Các Scriptbot vào kiểm tra gửi kết lại hệ thống API Các kết chuyển hướng lại thành phần Bộ phận tổng hợp Nếu có Scriptbot báo dịch vụ khơng hoạt động tổng hợp xác nhận dịch vụ không hoạt động - đồng nghĩa với việc đội khơng có điểm phịng thủ dịch vụ Cuối tick, thành phần Bộ phận tổng hợp gửi thông tin kết tổng hợp 38 Chương Ranking để tính tốn điểm số cho đội Dưới hai biểu đồ cho hai giai đoạn: lệnh kiểm tra lần đầu tổng hợp kết Service Status Hình 6.9: Biểu đồ phân phát việc hoạt động đầu tick 39 Chương 40 Hình 6.10: Biểu đồ xử lý kết trả từ Scriptbot Đánh giá kiểm thử 7.1 Đánh giá hiệu module kết nối users server Hiệu hệ thống thể qua thông số : số lượng đội tham gia kết nối, thời gian phản hồi, tỉ lệ đội kết nối sau đổi địa IP thành phần hệ thống Để đánh giá module sinh viên sử dụng máy chủ hệ thống cloud Amazon Web Service với máy sử dụng có cấu vCPU, tốc độ 2.5Ghz Hệ thống đánh giá gồm máy chủ đóng vai trị thành phần thay đổi địa IP mạng riêng ảo (tương đương TeamVM, Scriptbot Combot) máy chủ trung tâm lệnh điều khiển máy chủ lại (tương đương VPNServer) Trong số lượng máy chủ tăng dần sau lần thử nghiệm để xem xét thời gian phản hồi yêu cầu đổi địa IP tới VPNServer Với thiết lập sinh viên kiểm thử hệ thống kết nối có thời gian phản hồi bảng sau Bảng 7.1: Thông tin phản hồi số lượng kết nối bị theo số lượng máy chủ tham gia Số lượng máy chủ 10 15 20 30 Thời gian phản hồi(s) Kết nối bị 0.19 0.22 0.23 0.29 0.33 0 0 Dựa vào số liệu thời gian phản hồi, sinh viên thấy thời gian thực lệnh đổi 41 Chương địa IP máy chủ VPNServer tới thành phần tăng chậm so với chiều gia tăng số lượng máy chủ tham gia Ngoài số nhỏ so với vòng đấu (một vịng đấu diễn từ 5-10 phút) Vậy nên sinh viên kết luận thời gian thay đổi địa IP ảnh hưởng tới hệ thống khía cạnh thời gian Để xem xét rõ hiệu sinh viên kết hợp với kiểm tra tình trạng sử dụng CPU suốt trình thực việc thay đổi IP với VPN Server Dưới biểu đồ đường phần trăm sử dụng CPU VPNServer suốt trình thay đổi địa IP thực Hình 7.1: Biểu đồ tỉ lệ sử dụng CPU VPN Server thời gian thay đổi địa IP Trong suốt trình thay đổi địa IP VPNServer tỉ lệ sử dụng CPU máy chủ không đạt tới ngưỡng 50% máy chủ VPNServer có cấu hình tương đối thấp đề cập Và thực tế để điều hướng tồn gói tin thi VPNServer cần có cấu hình cao nhiều lần Vậy nên sinh viên kết luận thành phần không chiếm nhiều tài nguyên hệ thống suốt trình hoạt động 42 Chương 7.2 Kiểm thử thành phần thực Trong phần sinh viên thực kiển thử mức độ đơn vị với hàm chức hai thành phần: Scriptbot ServiceStatus Trong trình kiểm thử, sinh viên sử dụng thư viện testing1 có sẵn ngơn ngữ lập trình Golang cung cấp 7.2.1 Kiểm thử thành phần kiểm tra trạng thái dịch vụ Với thành phần kiểm tra trạng thái dịch vụ, sinh viên kiểm tra chức khởi tạo cấu trúc liệu từ mã nguồn tác giả dịch vụ cung cấp chức kiểm tra số dịch vụ xác định Mã nguồn kiểm tra thành phần sinh viên tải lên tại: https://github.com/lifebow/thesis_public/blob/main/ScriptBot/ test/service_test.go Các testcase sinh viên trình bày cụ thể Bảng 7.2 testing: https://pkg.go.dev/testing 43 Chương Bảng 7.2: Các mã nguồn kiểm thử mức đơn vị thành phần kiểm tra dịch vụ STT Nội dung Kết Ghi Lập danh sách mã nguồn thư mục Tìm kiếm mã nguồn Danh sách mã nguồn bên Pass thư mục có đường đường dẫn động trả dẫn động "./ServiceCheck1/challengePwn" Tìm kiếm mã nguồn Danh sách mã nguồn bên Pass thư mục có đường đường dẫn động trả dẫn động "./ServiceCheck1/challengePwn2" Tìm kiếm mã nguồn Danh sách mã nguồn bên Pass thư mục có đường đường dẫn động trả dẫn động "./ServiceCheck2/challengeWeb" Tạo cấu trúc liệu gồm dịch vụ mã nguồn từ đường dẫn Tạo cấu trúc liệu chữa Cấu trúc liệu tạo gồm hai Pass dịch vụ đường dẫn thử thách: challengePwn chalmà nguồn từ đường dẫn lengeWeb, thử thách có hai mã động "./ServiceCheck2/" nguồn kiểm tra Tạo cấu trúc liệu chữa Cấu trúc liệu tạo gồm hai Pass dịch vụ đường dẫn thử thách: challengePwn chalmà nguồn từ đường dẫn lengePwn2, thử thách có hai động "./ServiceCheck1/" mã nguồn kiểm tra Kiểm tra trạng thái dịch vụ xác định Kiểm tra dịch vụ Dịch vụ không hoạt động Pass challengeWeb địa IP: 127.0.0.1 với cổng 2224 không hoạt động Kiểm tra dịch vụ Dịch vụ hoạt động Pass challengePwn địa IP: 127.0.0.1 với cổng 2223 hoạt động 7.2.2 Kiểm thử thành phần tổng hợp trạng thái dịch vụ Với thành phần tổng hợp dịch vụ, sinh viên kiểm tra chức năng: thêm kết sau tổng hợp, thêm kết trả từ Scriptbot đổi thời gian trận đấu Mã nguồn kiểm tra thành phần sinh viên tải lên tại: https://github.com/lifebow/ 44 Chương thesis_public/blob/main/ServiceStatus/test/service_test.go Các testcase sinh viên trình bày cụ thể Bảng 7.3 Bảng 7.3: Các mã nguồn kiểm thử mức đơn vị thành phần tổng hợp dịch vụ STT Nội dung Kết Ghi Thêm kết sau tổng hợp Thêm kết dịch vụ chal- Thông tin thêm vào Pass lengePwn đội Team1 hoạt động Thêm kết dịch vụ chal- Thông tin thêm vào lengePwn đội Team1 không hoạt động Pass Thêm kết dịch vụ chal- Dịch vụ challengePwn đội Pass lengePwn đội Team1 Team1 cập nhật thành hoạt lần thứ hai để cập nhật kết động sang hoạt động Thêm kết trả từ Scriptbot Thêm kết kiểm tra Dịch vụ challengePwn Team1 Pass dịch vụ challengePwn- có hai kết kiểm tra trả Team1 kiểm tra Scriptbot1 Scriptbot2 Scriptbot1 gửi kết qủa kiểm Kết kiểm tra dịch vụ đội Pass tra dịch vụ đội Team1 Team1 cập nhật lần thứ Scriptbot1 gửi kết qủa kiểm Đội Team1 có hai kết kiểm tra Pass tra dịch vụ đội Team1 hai dịch vụ Cập nhật thông tin thời gian trận đấu Thay đổi vòng đấu Thơng tin vịng đấu thay đổi Pass Thay đổi tick đấu Thông tin tick đấu Pass thay đổi Thay đổi bốn vòng đấu thêm kết trả từ Scriptbot sau lặp lại lần Thơng tin vịng đấu thay đổi Pass sau lần, kết trả cập nhật thêm Đến lần thứ kết trả vịng xố để tối ưu nhớ 45 Tổng kết 8.1 Các kết đạt Trong trình thực đề tài, sinh viên đề xuất hệ thống tảng tổ chức thi đấu CTF theo hình thức cơng - phịng thủ cho phép số lượng đội tham gia thi đấu lớn giúp giảm tải gánh nặng máy chủ cần cung cấp cho ban tổ chức Sinh viên đưa kiến trúc tổng quát cho hệ thống, thực module kết nối users server, thành phần kiểm tra dịch vụ thành phần tổng hợp dịch vụ Thiết kế tổng quát hệ thống sinh viên đề đảm bảo đặc tả tảng tổ chức thi cơng - phịng thủ đảm bảo kết nối đội chơi với hệ thống, chức bản: cung cấp, kiểm tra “flag”, kiểm tra dịch vụ đội chơi, tổng hợp điểm hỗ trợ theo dõi trận đấu Đặc biệt, thiết kế sinh viên đề xuất giải vấn đề máy chủ tham gia trận đấu sử dụng máy chủ đội chơi tham gia trực tiếp vào hệ thống, điều giúp giảm chi phí vận hành cho ban tổ chức, giúp thi dễ triển khai Các đội chơi kết nối vào hệ thống thi đấu đảm bảo danh tính suốt q trình thi Các thành phần chế hệ thống giải vấn đề cơng DDoS đội chơi khác phát đội chơi có dấu hiệu gian lận Ngoài việc đảm bảo chức hệ thống, thành phần đảm nhiệm chức sinh viên thiết kế có khả hoạt động độc lập tránh nguy bị cơng bắc cầu suốt q trình hoạt động Module kết nối users server thực đảm bảo kết nối mạng riêng ảo chế đổi địa IP mạng suốt q trình thi đấu sử dụng tài nguyên hệ thống tốc độ xử lý máy chủ thời gian thực thi Cụm hai thành phần: thành phần kiểm tra dịch vụ thành phần tổng hợp trạng thái dịch vụ sinh viên thực hoạt động xác thiết kế đề Thành phần kiểm tra dịch vụ tăng giảm linh động theo nhu cầu thực tế hệ thống Thành 46 Chương phần tổng hợp trạng thái, ngồi chức tổng hợp thơng thường cịn có chế đưa yêu cầu kiểm tra lại dịch vụ diện rộng cách yêu cầu toàn Scriptbot vào kiểm tra giúp hỗ trợ phát gian lận 8.2 Những hạn chế hướng phát triển tương lai Hiện tại, hệ thống hoàn thiện ba module tổng số tám module thiết kế tổng thể Trong thời gian tới đề tài tiếp tục hồn thành để sớm tổ chức thi CTF theo hình thức cơng - phịng thủ Cơ chế kết nối hệ thống đổi địa IP đối tượng mạng riêng ảo theo Wireguard gặp trục trặc gặp vấn đề mạng phía đội chơi lúc hệ thống thực đổi địa Nên hệ thống phát triển thêm kênh truyền tín hiệu đảm bảo trì kết nối cập nhật lại địa IP mạng riêng ảo cho đội gặp lỗi trình Hình thức gian lận: chặn kết nối lẫn đội chơi dựa chưa giải triệt để chế phát gian lận có hệ thống Tình trạng giải cách kết hợp chế hệ thống đổi địa IP mạng riêng ảo với chế NAT Ngoài ra, hai thành phần kiểm tra dịch vụ tổng hợp dịch vụ cịn hoạt động theo lịch trình, tính ngẫu nhiên chưa cao nên bị nắm bắt trục lợi đội chơi có ý định gian lận Việc cải thiện hai thành phần học máy để thay đổi tối ưu thời gian kiểm tra dịch vụ đội giúp hệ thống dễ dàng phát đội có dấu hiệu gian lận giảm tải công việc cho thành phần hệ thống 47 Tài liệu tham khảo [1] Britannica “Virtual private network” In: June 2016 url: https://www.britannica com/technology/virtual-private-network [2] Jason A Donenfeld “WireGuard: Next Generation Kernel Network Tunnel” In: Feb 2017 url: https://www.ndss-symposium.org/wp-content/uploads/2017/09/ ndss2017_04A-3_Donenfeld_paper.pdf [3] Patrick Schmelzeisen MarkusBauer Jonas Bushart saarCTF Gameserver Framework https://github.com/MarkusBauer/saarctf-gameserver 2020 [4] Lucas McDaniel, Erik Talvi, and Brian Hay “Capture the Flag as Cyber Security Introduction” In: 2016 49th Hawaii International Conference on System Sciences (HICSS) 2016, pp 5479–5486 doi: 10.1109/HICSS.2016.677 [5] Shellfish The iCTF Framework 3.0 https : / / github com / shellphish / ictf framework 2020 [6] Vidar-team Cardinal platform https://github.com/vidar-team/Cardinal 2020 [7] Giovanni Vigna et al “Ten Years of iCTF: The Good, The Bad, and The Ugly” In: 2014 USENIX Summit on Gaming, Games, and Gamification in Security Education (3GSE 14) San Diego, CA: USENIX Association, Aug 2014 url: http://www usenix.org/conference/3gse14/summit-program/presentation/vigna 48 ... users server, thành phần kiểm tra dịch vụ tổng hợp trạng thái dịch vụ • Hiện thực phần kết nối users server, thành phần kiểm tra dịch vụ tổng hợp trạng thái dịch vụ 1. 3 Bố cục luận văn Dựa theo giai. .. VÀ KỸ THUẬT MÁY TÍNH LUẬN VĂN TỐT NGHIỆP Nghiên cứu phát triển tảng tổ chức thi cơng – phịng thủ máy tính Efiens Giai đoạn 1: Thi? ??t kế hệ thống xây dựng module giao tiếp users server, thành phần. .. tổ chức thi cơng – phịng thủ máy tính Efiens Giai đoạn 1: Thi? ??t kế hệ thống xây dựng mô-đun giao tiếp users server, thành phần kiểm tra dịch vụ tổng hợp trạng thái dịch vụ Họ tên người hướng dẫn/phản