Я думаю про те, що клієнти підробляють IP-адреси, обманюють інших клієнтів, що вони є сервером; такі речі. (Я мало знаю про це, тому, якщо це абсолютно неправильно, будь ласка, виправте мене.)
Що мені робити, щоб цього не допустити? Оскільки це гра в режимі реального часу, якби я використовував шифрування, я використовував би щось швидке і безпечне, як RC4. Чи слід шифрувати пакетні дані ключем, який сервер надає клієнту?
Якщо це має значення, я використовую UDP.
Відповіді:
Одне можливе рішення - аутентифікувати користувача за допомогою TCP + TLS; тоді, в межах одного каналу, використовуйте щось на зразок Діффі-Хеллмана для узгодження симетричного ключа. Нарешті зашифруйте кожен UDP-пакет за допомогою симетричного алгоритму типу RC4.
Технічно вам не потрібно використовувати TCP + TLS для узгодження симетричного ключа, якщо ви використовуєте щось на зразок SRP - просто пам’ятайте, що чистий Diffie-Hellman вразливий до атаки MITM .
Ви можете піти ще далі і використовувати користувальницьке поле SEQ у своїх пакетах UDP (якщо ви використовуєте якусь форму надійної UDP), щоб реалізувати форму шифрування зустрічного режиму - де ви додасте номер SEQ до переговорного ключа для кожного пакету; зробивши це набагато складніше встановити атаку відомого простого тексту.
Не дозволяйте вашому серверу просто роздавати ключі за бажанням - сервер з підробкою може так само легко передавати його власний ключ; перемагаючи призначення всієї вашої схеми шифрування. Єдиний гарантований спосіб - це використання TLS або взаємне знання (наприклад, пароль / хеш).
Я маю віддалений (2 роки тому) досвід хакерства, найскладніші пакети, які коли-небудь зламалися (і те, що я пропоную вам використовувати), - це метод симетричного шифрування ключа, який коротко описав Джонатан Дікінсон. Ви повинні використовувати TCP + TLS, як він також згадував. Однак він сказав зустрічну послідовність.
Я зіткнувся з періодами, коли система «хакер-доказів» програмістів була легко підроблена, оскільки у них є достатньо дивна система підрахунку, що я міг би зламати її без знань про програмування та алгебраїчної логіки першого року. Поки ви вибираєте правильний послідовний метод, тоді ваша ціль повинна отримувати дані точно так, як очікувалося, а це означає, що ви повинні використовувати TCP для найбільш безпечних операцій.
Повернувшись до «в моєму досвіді», одна система, яку я знайшов, працює фантастично. Послідовний метод на основі відправленого часу та очікуваного часу. Оскільки пакети завжди повинні бути отримані в належному порядку, сфабрикувати пакет тоді було майже неможливо, оскільки я ніколи не міг передбачити, коли пакет буде надісланий і коли його очікували (між одним пакетом та іншим), не спершу злому клієнтської програми.
Коротка відповідь
Коротше кажучи: кожна структура пакетів також мала б позначення часу, як коли вона була відправлена вниз до мілісекунди. Це чорт просте, і це дуже легко перевірити, чи час до / після іншого. Причина, по якій це має сенс, полягає в тому, що сервер все ще може отримувати пакети в порядку підробки, не маючи часу на аутентифікацію.
Це, очевидно, не єдиний послідовний метод або навіть найкращий з будь-яких методів. Я лише знайшов, що працює дуже добре. У поєднанні з TCP + TLS у вас не повинно виникнути занадто багато проблем.
Особисто я не хотів би за борт занадто рано. Навіть якщо ви шифруєте свої пакети, як рекомендує Джонатан, хакери, як мій брат, просто отримають доступ до даних пакетів, перш ніж вони будуть зашифровані. Якщо зловмисні користувачі захочуть, вони знайдуть вихід.
Тепер, коли це не вдається, інді-розробникам є способи мінімізувати шкоду, яку можуть завдати зловмисні користувачі. Ймовірно, ви повинні зашифрувати свої вихідні пакети, але це зупинить лише певні види атак, не обманюйте себе думкою, що це зараз "хакерське підтвердження". Щоб справді вимкнути хакерів, надайте клієнтам якомога менше контролю за зміною гри. Одне з таких великих MMO використовувалося, щоб клієнти могли розповісти серверу, скільки XP заробили. Вгадайте, що там сталося? Не робіть цього. Дозвольте клієнту сказати серверу, що вони хочуть нанести на істоту якусь супер-заклинання, а потім нехай сервер вирішить дію, а потім додасть XP, коли істота мертва. Клієнти повинні бути тонкими, тупими, терміналами, які можуть надсилати та приймати команди, і можуть робити певні прогнози (якщо це необхідно).гра і реагувати на команди , що посилаються клієнтами.
Великі ігрові компанії використовують вищезазначене на додаток до чогось типу VAC або PunkBuster, щоб запобігти відомим хакерам продовжувати порушувати оплату клієнтів. Як працюють ці заходи безпеки, зберігається досить секретно, але я знаю один із методів, який вони використовують: вони сканують поточні програми та порівнюють їх зі списками відомих хак. Після того, як вас зловить обман, ви не зможете приєднатися до захищених серверів VAC / PunkBuster.
Пов'язане: Логіка гри на сервері! Добре чи погано?