Аудит безопасности игрового сервера перед публичным запуском
Вы неделю настраивали сервер, накатили сборку модов, подобрали плагины, всё вроде работает — и тут встаёт вопрос: а можно уже кидать ссылку в паблик или дискорд-канал? Публичный запуск — это точка невозврата: как только IP разлетелся по игрокам, любая дыра, которую вы не закрыли, найдётся не через месяц спокойной проверки, а в первый же вечер, когда сервер набьётся под завязку. Этот чек-лист — пройтись по нему займёт от силы полчаса, а сэкономить может недели восстановления после взлома или вайпа мира гриферами.
Содержание
- Зачем нужен именно этот чек-лист, а не общие советы
- Порты и файрвол: закрыть всё лишнее
- Пароли и RCON: избавляемся от дефолтов
- Защита SSH и панели от перебора
- Обновления: игра, плагины, моды и сама ОС
- Права доступа и роли администраторов
- Бэкап на месте: последний рубеж
- Финальный прогон перед открытием сервера
Зачем нужен именно этот чек-лист, а не общие советы
Общие рекомендации по безопасности серверов пишутся под веб-приложения и базы данных — там своя специфика. У игрового сервера риски другие: вас не будут ломать ради данных банковских карт, зато с высокой вероятностью попробуют устроить 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 на директорию сервера — плохой знак, который иногда остаётся после торопливой установки по гайду из интернета).
Бэкап на месте: последний рубеж
Даже идеально закрытый по портам и паролям сервер может упасть из-за баги в моде, битого чанка мира или банальной ошибки при обновлении. Бэкап — это не пункт «на всякий случай», это обязательное условие перед тем, как пускать живых игроков: без него любая проблема первого дня превращается в потерю прогресса, за которую вам придётся извиняться перед комьюнити ещё до того, как оно успело сформироваться.
Проверьте перед запуском:
- Бэкап настроен и реально отработал хотя бы раз — не просто прописан в cron, а проверен вручную. Мёртвая задача, которая молча падает с ошибкой третий месяц подряд, — классика.
- Бэкап хранится не только на том же диске, что и сам сервер — иначе при отказе диска или взломе с удалением файлов вы теряете и сервер, и его резервную копию одновременно. Вынос в облако через
rcloneили на S3-совместимое хранилище закрывает это в один шаг. - Есть понятная процедура восстановления, а не только сам факт наличия архива — попробуйте один раз развернуть бэкап на тестовом окружении до запуска, чтобы не разбираться с этим впервые в момент паники. Практика восстановления описана в статье восстановление сервера из бэкапа.
Разумный минимум перед публичным запуском — ежедневный бэкап мира/сейвов с хранением хотя бы 3-7 последних копий и выносом за пределы основного диска.
Финальный прогон перед открытием сервера
Когда все пункты выше закрыты, сделайте последний проход — уже не по отдельным настройкам, а по сценарию «как будто вы злоумышленник, который только что узнал IP сервера»:
- Просканируйте свой сервер снаружи (
nmap -Pn ваш_IPс другой машины) и убедитесь, что видны только те порты, которые должны быть видны. - Попробуйте подключиться к RCON с внешнего IP, не входящего в белый список — подключение должно быть отклонено файрволом, а не паролем.
- Проверьте, что дефолтные учётки (если сборка их создавала) либо удалены, либо у них сменены пароли.
- Убедитесь, что версия игры и плагинов актуальна и сервер запускается с чистого перезапуска без ошибок в логе.
- Сделайте контрольный бэкап прямо перед открытием — точку отсчёта, к которой можно откатиться, если первые часы публичного доступа пойдут не так.
Если что-то пошло не так уже после открытия — держите под рукой отдельный чек-лист диагностики упавшего сервера и, на крайний случай, план восстановления после взлома — лучше прочитать их заранее, чем искать в панике.
Нужен игровой сервер?
MAATRIX GAMES — 45+ игр, деплой за минуты, DDoS-защита, автобэкапы. Тарифы от 399 ₽/мес.
Создать серверЧастые вопросы
Сколько времени реально занимает такой аудит на уже работающем сервере?
Если сервер небольшой и настраивался вами лично — 20-40 минут на первый прогон. На сложной инфраструктуре с несколькими процессами и админами — закладывайте час-полтора, особенно если придётся разводить права заново.
Нужно ли всё это для маленького сервера на 5-10 друзей, который не будет светиться в паблике?
Базовый минимум — да, всё равно: смена дефолтных паролей и закрытие лишних портов. Но если сервер реально приватный и IP не публикуется, риск ниже, и можно не заморачиваться с fail2ban и жёсткой сегментацией прав — это уже про масштаб публичного проекта.
Обязательно ли выносить бэкап в облако, или достаточно локальной копии на том же VPS?
Локальная копия лучше, чем ничего, но не защищает от отказа диска или удаления файлов при взломе. Для по-настоящему публичного сервера с живым комьюнити внешнее хранилище — не опция, а требование.
Как часто повторять такой аудит после запуска, а не только перед ним?
Разумная периодичность — раз в 1-2 месяца или после любого крупного изменения инфраструктуры (новый администратор, новый плагин с сетевыми функциями, миграция на другой хостинг).
Что делать в первую очередь, если после этого чек-листа всё равно случился взлом?
Не паникуйте и не пытайтесь чинить всё сразу вручную — сначала изолируйте сервер от сети, чтобы остановить дальнейший ущерб, затем идите по отдельному чек-листу восстановления после взлома, ссылка на который выше.