MAATRIX GAMES / Блог / Аудит безопасности игрового сервера перед публичным запуском

Аудит безопасности игрового сервера перед публичным запуском

MAATRIX GAMES

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

Зачем нужен именно этот чек-лист, а не общие советы

Общие рекомендации по безопасности серверов пишутся под веб-приложения и базы данных — там своя специфика. У игрового сервера риски другие: вас не будут ломать ради данных банковских карт, зато с высокой вероятностью попробуют устроить DDoS ради шутки, зайдут через RCON с дефолтным паролем, чтобы покомандовать банхаммером, или используют открытый лишний порт как точку входа для майнера на вашем VPS. Плюс у игровых серверов есть уникальная головная боль — сохранность мира и прогресса игроков, которую веб-чек-листы вообще не учитывают.

Порядок в этом гайде такой: сначала сеть (порты, файрвол), потом доступы (пароли, RCON, панель), потом сама игра (обновления, конфиги), и в конце — страховка на случай, если что-то всё равно пойдёт не так (бэкапы). Проходите по порядку, каждый пункт — реальная команда или файл, который нужно открыть и проверить, а не абстрактная рекомендация «будьте осторожны».

Порты и файрвол: закрыть всё лишнее

Первое и самое частое упущение — сервер открыт по всем портам, потому что «так проще было настраивать». На проде это ошибка: каждый открытый порт — потенциальная точка входа, и никто не обязан объяснять, зачем он открыт, если он не используется.

Проверьте, что реально слушает сервер:

sudo ss -tulpn

В выводе — список портов с именем процесса. Сверьте с тем, что должно быть открыто: игровой порт (у Minecraft это обычно 25565/tcp, у большинства Source-игр — свой UDP-диапазон плюс query-порт), SSH (обычно 22, часто стоит перенести на нестандартный), RCON-порт — и всё. Если видите что-то незнакомое — postgres на 5432 без пароля, забытый http на 8080 от тестового веб-интерфейса плагина — закрывайте немедленно.

Настройте файрвол явным белым списком через ufw:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow 25565/tcp
sudo ufw allow 25575/tcp
sudo ufw enable

Принцип — «запрещено всё, что не разрешено явно», а не наоборот. Это на порядок надёжнее, чем закрывать руками отдельные порты по мере того, как вы о них вспоминаете. Если у вас несколько игровых процессов на одной машине, распишите каждый порт отдельным правилом с комментарием (ufw allow 25565/tcp comment 'minecraft'), чтобы через полгода не гадать, что за чем открыто — подробнее об этом в статье про настройку портов и файрвола для игрового сервера.

Отдельно проверьте RCON-порт (по умолчанию для Minecraft — 25575, у Source-движка часто совпадает с игровым портом плюс query): он не должен быть виден из интернета вообще, только с локального хоста или через VPN — RCON даёт полный административный контроль, и открытый наружу без ограничения по IP он рано или поздно будет просканирован ботами.

Нужен игровой сервер?

MAATRIX GAMES — 45+ игр, деплой за минуты, DDoS-защита, автобэкапы. Тарифы от 399 ₽/мес.

Создать сервер

Пароли и RCON: избавляемся от дефолтов

Дефолтные пароли — это не гипотетическая уязвимость, а практически гарантированная дыра. Сборки серверов (готовые Docker-образы, скрипты автоустановки) часто ставят предсказуемый пароль вроде changeme или admin123, рассчитывая, что вы его смените — и очень многие этого не делают.

Пройдитесь по списку:

  • RCON-пароль. В конфиге Minecraft это server.properties, строка rcon.password=. У Source-игр (Rust, CS2, ARK) — обычно +rcon_password в параметрах запуска или отдельный конфиг. Пароль должен быть длинным и случайным — генерируйте через openssl rand -base64 24, не придумывайте руками «на глаз».
  • Панель управления (если используете веб-панель поверх сервера — Pterodactyl, AMP или встроенную панель хостинга). Смените дефолтный логин/пароль администратора сразу после первой установки, до того как панель станет доступна извне.
  • Пароль базы данных, если плагины или моды используют MySQL/PostgreSQL для хранения статистики, экономики, прав — дефолтный root без пароля или с паролем password в 2026 году всё ещё встречается пугающе часто.
  • SSH-доступ к самому VPS. Если у вас несколько администраторов, замена общего пароля на персональные SSH-ключи снимает сразу несколько рисков разом — как это сделать, разобрано в статье про SSH-ключи вместо пароля для нескольких администраторов.

Если у панели или почты администратора есть поддержка двухфакторной аутентификации — включайте её перед публичным запуском, а не после первого инцидента.

Защита SSH и панели от перебора

Даже с сильным паролем или ключом стоит закрыть саму возможность перебора — боты сканируют интернет и долбят порт 22 круглосуточно вне зависимости от того, интересен ли конкретно ваш сервер кому-то персонально. Поставьте fail2ban, который банит IP после нескольких неудачных попыток входа:

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

Дефолтная конфигурация уже покрывает SSH из коробки — этого достаточно для базового уровня защиты. Более тонкая настройка (свои джейлы под панель управления, время бана, белые списки) описана в статье про fail2ban для защиты SSH игрового сервера.

Если панель управления или RCON доступны только вам и ещё паре человек, разумный шаг — ограничить доступ по IP на уровне файрвола, а не полагаться только на пароль:

sudo ufw allow from 203.0.113.10 to any port 25575

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

Обновления: игра, плагины, моды и сама ОС

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

  • Ядро сервера актуально. Если ставили через SteamCMD — прогоните steamcmd +app_update <id> validate и убедитесь, что версия не отстаёт от официальной на недели. Для Minecraft — сверьте версию Paper/Fabric/Forge с последним стабильным билдом на официальном сайте проекта, не с тем, что скачали месяц назад.
  • Плагины и моды обновлены до версий, совместимых с текущим ядром — несовместимость версий часто открывает не только баги, но и дыры в правах доступа (например, старая версия permissions-плагина с известной уязвимостью в проверке прав).
  • Операционная система VPS пропатчена: sudo apt update && sudo apt upgrade. Отдельно проверьте, что ядро Linux не требует перезагрузки для применения security-патчей (cat /var/run/reboot-required, если файл существует — перезагрузка нужна).

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

Отдельно — конфиги. Просмотрите server.properties (Minecraft) или аналог у вашей игры построчно хотя бы раз: часто там остаются debug-флаги, включённый command block без ограничений, открытый enable-command-block=true вместе со слабыми правами по умолчанию, или online-mode=false, оставленный после локального тестирования — с выключенным online-mode сервер не проверяет лицензии Minecraft и пускает кого угодно под любым ником, включая подмену ника администратора.

Права доступа и роли администраторов

Если над сервером работает не один человек, проверьте перед запуском, у кого какой уровень доступа. Частая ошибка — выдать всем помощникам полный op/admin, потому что «так удобнее», а потом обнаружить, что кто-то случайно (или не случайно) снёс регион спавна командой в одну строку.

Разведите права по ролям заранее:

РольRCON/консольSSH на VPSПрава в игре
ВладелецПолныйПолныйПолные
Тех.администраторПолныйПо ключу, без rootПолные
МодераторОграниченный набор командНетБан/кик/мут
Билдер/ивент-мастерНетНетWorldEdit в своём регионе

Технически развести права под такую таблицу помогают permissions-плагины вроде LuckPerms. Главное на этапе аудита — убедиться, что список людей с полным доступом реально минимален и вы его помните наизусть, без «а, ну этому человеку я тоже когда-то давал op, забыл».

Если сервер стоит на VPS, который вы арендуете, а не администрируете самостоятельно с нуля, дополнительно проверьте права на файлы: конфиги и сейвы не должны быть доступны на запись всем пользователям системы (chmod 777 на директорию сервера — плохой знак, который иногда остаётся после торопливой установки по гайду из интернета).

Бэкап на месте: последний рубеж

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

Проверьте перед запуском:

  1. Бэкап настроен и реально отработал хотя бы раз — не просто прописан в cron, а проверен вручную. Мёртвая задача, которая молча падает с ошибкой третий месяц подряд, — классика.
  2. Бэкап хранится не только на том же диске, что и сам сервер — иначе при отказе диска или взломе с удалением файлов вы теряете и сервер, и его резервную копию одновременно. Вынос в облако через rclone или на S3-совместимое хранилище закрывает это в один шаг.
  3. Есть понятная процедура восстановления, а не только сам факт наличия архива — попробуйте один раз развернуть бэкап на тестовом окружении до запуска, чтобы не разбираться с этим впервые в момент паники. Практика восстановления описана в статье восстановление сервера из бэкапа.

Разумный минимум перед публичным запуском — ежедневный бэкап мира/сейвов с хранением хотя бы 3-7 последних копий и выносом за пределы основного диска.

Финальный прогон перед открытием сервера

Когда все пункты выше закрыты, сделайте последний проход — уже не по отдельным настройкам, а по сценарию «как будто вы злоумышленник, который только что узнал IP сервера»:

  • Просканируйте свой сервер снаружи (nmap -Pn ваш_IP с другой машины) и убедитесь, что видны только те порты, которые должны быть видны.
  • Попробуйте подключиться к RCON с внешнего IP, не входящего в белый список — подключение должно быть отклонено файрволом, а не паролем.
  • Проверьте, что дефолтные учётки (если сборка их создавала) либо удалены, либо у них сменены пароли.
  • Убедитесь, что версия игры и плагинов актуальна и сервер запускается с чистого перезапуска без ошибок в логе.
  • Сделайте контрольный бэкап прямо перед открытием — точку отсчёта, к которой можно откатиться, если первые часы публичного доступа пойдут не так.

Если что-то пошло не так уже после открытия — держите под рукой отдельный чек-лист диагностики упавшего сервера и, на крайний случай, план восстановления после взлома — лучше прочитать их заранее, чем искать в панике.

Нужен игровой сервер?

MAATRIX GAMES — 45+ игр, деплой за минуты, DDoS-защита, автобэкапы. Тарифы от 399 ₽/мес.

Создать сервер

Частые вопросы

Сколько времени реально занимает такой аудит на уже работающем сервере?

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

Нужно ли всё это для маленького сервера на 5-10 друзей, который не будет светиться в паблике?

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

Обязательно ли выносить бэкап в облако, или достаточно локальной копии на том же VPS?

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

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

Разумная периодичность — раз в 1-2 месяца или после любого крупного изменения инфраструктуры (новый администратор, новый плагин с сетевыми функциями, миграция на другой хостинг).

Что делать в первую очередь, если после этого чек-листа всё равно случился взлом?

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