Как предотвратить подделку личности в многопользовательской игре?

Я думаю о клиентах, подделывающих IP-адреса, обманывающих других клиентов, что они являются сервером; такого рода вещи. (Я не знаю много об этом, поэтому, если это совершенно не так, пожалуйста, поправьте меня.)

Что я должен сделать, чтобы предотвратить это? Поскольку это игра в реальном времени, если бы я использовал шифрование, я бы использовал что-то быстрое и безопасное, например RC4. Должен ли я шифровать пакетные данные ключом, который сервер дает клиенту?

Если это имеет какое-то значение, я использую UDP.

Одним из возможных решений является аутентификация пользователя с использованием TCP + TLS; затем, внутри того же канала, используйте что-то вроде Диффи-Хеллмана для согласования симметричного ключа. Наконец, зашифруйте каждый пакет UDP, используя симметричный алгоритм, такой как RC4.

Технически вам не нужно использовать TCP + TLS для согласования симметричного ключа, если вы используете что-то вроде SRP - просто помните, что чистый Диффи-Хеллман уязвим для атаки MITM .

Вы можете пойти еще дальше и использовать настраиваемое поле SEQ в своих пакетах UDP (если вы используете какую-либо форму надежного UDP), чтобы реализовать форму шифрования в режиме противодействия - где вы добавляете номер SEQ к согласованному ключу для каждого пакета; что значительно усложняет атаку с использованием открытого текста.

Не позволяйте вашему серверу просто раздавать ключи по своему усмотрению - сервер подделки может так же легко раздавать свой собственный ключ; победив цель всей вашей схемы шифрования. Единственный гарантированный способ - использовать либо TLS, либо взаимные знания (например, пароль / хэш).

У меня есть давний (2 года назад) опыт взлома, самые сложные из когда-либо взломанных пакетов (и то, что я предлагаю вам использовать) - это использование метода шифрования с симметричным ключом, который Джонатан Дикинсон кратко описал. Вы должны использовать TCP + TLS, как он также упомянул. Однако он сказал встречную последовательность.

Я сталкивался со временами, когда программисты «взламывали» систему, которая была легко подделана, потому что у них была достаточно странная система подсчета, которую я мог взломать без знания программирования и алгебраической логики первого года. Пока вы выбираете правильный последовательный метод, ваша цель должна получать данные точно так, как ожидается, а также означает, что вы должны использовать TCP для наиболее безопасных операций.

Вернувшись на путь "в моем опыте", одна система, которую я нашел, работает фантастически. Последовательный метод, основанный на отправленном времени и ожидаемом времени. Поскольку пакеты всегда должны приниматься в правильном порядке, подделать пакет было практически невозможно, поскольку я никогда не мог предсказать, когда пакет будет отправлен и когда он ожидается (между одним пакетом и другим), без предварительного взлома клиентской программы.

Краткий ответ

Вкратце: каждая структура пакета также будет иметь метку времени, как при отправке до миллисекунды. Это чертовски просто, и действительно легко проверить, является ли время до / после другого времени. Причина, по которой это имеет смысл, заключается в том, что сервер все еще может принимать пакеты в порядке с подменой, без времени для аутентификации.

Это, очевидно, не единственный последовательный метод или даже лучший из всех методов. Я обнаружил, что это очень хорошо работает. В сочетании с TCP + TLS у вас не должно быть слишком много проблем.

Лично я бы не пошел за борт слишком рано. Даже если вы зашифруете свои пакеты, как рекомендует Джонатан, хакеры, вроде моего брата, просто получат доступ к данным пакета, прежде чем они будут зашифрованы. Если злоумышленники захотят войти, они найдут выход.

Теперь, когда это не так, у независимых разработчиков есть способы минимизировать ущерб, который могут нанести злоумышленники. Вы, вероятно, должны зашифровать свои исходящие пакеты, но это остановит только определенные виды атак, не обманывайте себя, думая, что теперь это "доказательство взлома". Чтобы действительно отключить хакеров, дайте клиентам как можно меньше контроля над игрой. Одна из этих больших ММО позволяла клиентам сообщать серверу, сколько XP они заработали. Угадай, что там произошло? Не делай этого. Позвольте клиенту сообщить серверу, что он хочет наложить какое-нибудь супер-заклинание на существо, а затем разрешите серверу разрешить действие и затем добавить XP, когда существо мертво. Клиенты должны быть тонкими, тупыми, терминалами, которые могут отправлять и получать команды и могут делать некоторые прогнозы (при необходимости).игра и реагировать на команды , посылаемые клиентами.

Крупные игровые компании используют вышеупомянутое в дополнение к чему-то вроде VAC или PunkBuster, чтобы предотвратить продолжающуюся известность хакеров мешать платящим клиентам. Как работают эти меры безопасности, держится в секрете, но я знаю один метод, который они используют: они сканируют работающие в данный момент приложения и сравнивают их со списками известных хаков. Как только вас поймают на мошенничестве, вы не сможете присоединиться к защищенным серверам VAC / PunkBuster.

Связанные: Логика игры на сервере! Хорошо или плохо?