Làm cách nào để ngăn chặn giả mạo danh tính trong trò chơi nhiều người chơi?


9

Tôi đang nghĩ về việc khách hàng giả mạo địa chỉ IP, lừa khách hàng khác rằng họ là máy chủ; đó là những thứ (Tôi không biết nhiều về điều này, vì vậy nếu điều này là hoàn toàn sai, xin vui lòng sửa lại cho tôi.)

Tôi nên làm gì để ngăn chặn điều này? Bởi vì đây là một trò chơi thời gian thực, nếu tôi sử dụng mã hóa, tôi sẽ sử dụng thứ gì đó nhanh và an toàn như RC4. Tôi có nên mã hóa dữ liệu gói bằng một khóa mà máy chủ cung cấp cho khách hàng không?

Nếu nó làm cho bất kỳ sự khác biệt, tôi đang sử dụng UDP.

Câu trả lời:


8

Một giải pháp khả thi là xác thực người dùng bằng TCP + TLS; sau đó, trong cùng một kênh, sử dụng một cái gì đó như Diffie-Hellman để đàm phán một khóa đối xứng. Cuối cùng mã hóa từng gói UDP bằng thuật toán đối xứng như RC4.

Về mặt kỹ thuật, bạn không cần sử dụng TCP + TLS để đàm phán khóa đối xứng nếu bạn sử dụng thứ gì đó như SRP - chỉ cần nhớ rằng Diffie-Hellman sạch sẽ dễ bị tấn công MITM .

Bạn có thể đi xa hơn và sử dụng trường SEQ tùy chỉnh trong các gói UDP của mình (nếu bạn đang sử dụng một số dạng UDP đáng tin cậy) để thực hiện một hình thức mã hóa chế độ đối kháng - trong đó bạn thêm số SEQ vào khóa thương lượng cho mỗi gói; làm cho nó trở nên khó khăn hơn nhiều để thực hiện một cuộc tấn công văn bản đơn giản.

Đừng để máy chủ của bạn phát chìa khóa theo ý muốn - máy chủ 'giả mạo' có thể dễ dàng trao chìa khóa của chính nó; đánh bại mục đích của toàn bộ chương trình mã hóa của bạn. Cách duy nhất được đảm bảo là sử dụng TLS hoặc kiến ​​thức lẫn nhau (chẳng hạn như mật khẩu / hàm băm).


Bạn có thể mô tả chính xác những lỗ hổng này sẽ đóng? Tôi đã nghe nói về việc giả mạo IP và những thứ tương tự, nhưng tôi không được giáo dục về chủ đề này
liamzebedee

@ LiamE-p GameDev không phải là nơi dành cho khóa học về bảo mật; tôi cũng không có thời gian để ra tay Về cơ bản SRP và TLS (một trong hai) phải an toàn như trang web ngân hàng trực tuyến của bạn - SRP nhiều hơn với chế độ CTR. Nếu bạn cần thêm lời giải thích, bạn nên hỏi trên trang web Security SE.
Jonathan Dickinson

Điều này chắc chắn sẽ là về chủ đề bảo mật SE. Tôi sẽ gắn cờ cho một mod để di chuyển nó đến đó.
Rory Alsop

8

Tôi có một nền tảng xa (2 năm trước) về hack, các gói khó nhất từng bị bẻ khóa (và những gì tôi khuyên bạn nên sử dụng) là sử dụng một phương pháp mã hóa khóa đối xứng mà Jonathan Dickinson mô tả ngắn gọn. Bạn nên sử dụng TCP + TLS như anh ấy đã đề cập. Tuy nhiên, ông nói một chuỗi phản.

Tôi đã gặp phải thời gian mà một hệ thống "chống bằng chứng" lập trình viên dễ bị giả mạo bởi vì họ có một hệ thống đếm đủ kỳ lạ để tôi có thể bẻ khóa nó mà không cần kiến ​​thức lập trình và logic đại số năm đầu tiên. Miễn là bạn chọn một phương thức tuần tự phù hợp thì mục tiêu của bạn sẽ nhận được dữ liệu chính xác như mong đợi, cũng có nghĩa là bạn nên sử dụng TCP cho các hoạt động an toàn nhất.

Trở lại theo dõi "trong kinh nghiệm của tôi", một hệ thống tôi thấy hoạt động tuyệt vời. Một phương pháp tuần tự dựa trên thời gian gửi và thời gian dự kiến. Vì các gói phải luôn được nhận theo đúng thứ tự, nên việc giả mạo một gói gần như là không thể vì tôi không bao giờ có thể dự đoán khi nào gói sẽ được gửi và khi nào nó được mong đợi (giữa gói này và gói khác) mà không cần hack chương trình máy khách trước.

Câu trả lời ngắn

Tóm lại: Mỗi cấu trúc gói cũng sẽ có dấu thời gian như khi nó được gửi xuống mili giây. Điều đó thật đơn giản và thật dễ dàng để kiểm tra xem một thời gian là trước / sau một thời gian khác. Lý do tại sao nó có ý nghĩa tốt như vậy là bởi vì máy chủ vẫn có thể nhận các gói theo thứ tự giả mạo, mà không có thời gian để xác thực.

Đây rõ ràng không phải là phương pháp tuần tự duy nhất hoặc thậm chí là phương pháp tốt nhất trong mọi phương pháp. Nó chỉ là một cái mà tôi thấy rằng nó hoạt động rất tốt. Kết hợp với TCP + TLS, bạn không nên có quá nhiều vấn đề.


Vấn đề với các trò chơi là mọi thứ xảy ra ở cấp độ mili giây.
Jonathan Dickinson

@JonathanDickinson Điều đó hoàn toàn đúng. Nhưng đặc biệt là sử dụng UDP và khi sử dụng TCP, nên sử dụng thuật toán tính toán chết cho các hoạt động phụ mili giây và thậm chí nhiều mili giây. Đó là để hỗ trợ tốc độ, hình ảnh và một số thứ phía sau hậu trường tất nhiên. (chủ yếu liên quan đến tốc độ)
Joshua Hedges

6
Tôi đoán vào cuối ngày đó là một trò chơi chứ không phải hệ thống điều khiển vệ tinh tia tử thần. +1
Jonathan Dickinson

4

Cá nhân, tôi sẽ không quá nhiệt tình. Ngay cả khi bạn mã hóa các gói của mình như Jonathan đang khuyến nghị, các tin tặc như anh tôi sẽ chỉ truy cập dữ liệu gói trước khi được mã hóa. Nếu người dùng độc hại muốn vào, họ sẽ tìm cách vào.

Bây giờ đã hết cách, có nhiều cách để các nhà phát triển độc lập giảm thiểu thiệt hại mà người dùng độc hại có thể gây ra. Bạn có thể nên mã hóa các gói tin đi của mình, nhưng điều đó sẽ chỉ ngăn chặn một số loại tấn công nhất định, đừng dại dột nghĩ rằng bây giờ là "hack bằng chứng". Để thực sự tắt tin tặc, hãy cung cấp cho khách hàng ít quyền kiểm soát thay đổi trò chơi nhất có thể. Một trong những MMO lớn này được sử dụng để cho phép khách hàng nói với máy chủ số tiền họ kiếm được XP. Đoán xem chuyện gì đã xảy ra ở đó? Đừng làm vậy. Hãy để khách hàng nói với máy chủ rằng họ muốn sử dụng một số siêu phép trên sinh vật, sau đó để máy chủ giải quyết hành động và sau đó thêm XP khi sinh vật đó chết. Các máy khách phải mỏng, câm, các thiết bị đầu cuối có thể gửi và nhận lệnh và có thể thực hiện một số dự đoán (nếu cần).các trò chơi và phản ứng với các lệnh gửi của khách hàng.

Các công ty trò chơi lớn sử dụng những điều trên cùng với một cái gì đó như VAC hoặc PunkBuster để ngăn chặn các tin tặc nổi tiếng tiếp tục phá vỡ các khách hàng trả tiền. Làm thế nào các biện pháp bảo mật này hoạt động được giữ bí mật, nhưng tôi biết một phương pháp mà chúng sử dụng: chúng quét các ứng dụng hiện đang chạy và so sánh chúng với các danh sách hack đã biết. Một khi bạn đã bị bắt gian lận, bạn sẽ không thể tham gia các máy chủ được bảo mật VAC / PunkBuster.

Liên quan: Logic trò chơi trên máy chủ! Tốt hay xấu?

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.