Восстановление после взлома игрового сервера — чек-лист

MAATRIX GAMES

Внезапно в чате сервера админские команды пишет незнакомый ник, из инвентаря игроков пропадают вещи, а в конфиге кто-то тихо прописал себя в ops. Или проще: сервер лёг, а в логах — вход по SSH с незнакомого IP посреди ночи. Первая реакция — паника и желание всё немедленно перезапустить. Не делайте так. Ниже — порядок действий, который реально спасает сервер и минимизирует ущерб, без беготни и лишних движений.

Признаки взлома: как понять, что сервер скомпрометирован

Взлом игрового сервера редко выглядит как в кино — чаще это набор мелких аномалий, которые по отдельности можно списать на баг, а вместе складываются в картину:

• В логах RCON или консоли — команды, которые вы не выполняли: op, ban, kick, выдача предметов, телепорты.
• Новый пользователь в ops.json (Minecraft), в ServerUsers.json (Rust) или в списке админов SourceMod/Oxide, которого никто не добавлял.
• Игроки массово жалуются на пропавший лут, снесённые постройки, забаненных без причины.
• Сервер стал частью ботнета: аномальный исходящий трафик, майнер грузит CPU в 100% в состоянии простоя, процессы вроде xmrig, kdevtmpfsi в ps aux.
• В /var/log/auth.log (Debian/Ubuntu) или через journalctl -u sshd — успешные входы (Accepted password / Accepted publickey) с IP, которого вы не узнаёте.
• Изменились файлы конфигурации сервера (server.properties, oxide/config/*.json, sourcemod/configs/admins_simple.ini) без вашего участия — дата модификации не совпадает с последним вашим деплоем.
• Панель управления хостингом или FTP-доступ показывает вход с незнакомого устройства/геолокации.

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

Шаг 1. Изоляция — останавливаем сервер и отрезаем доступ

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

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

   systemctl stop minecraft-server
   # или для Rust/CS2 через screen/tmux — Ctrl+C в сессии, не kill -9

1. Закройте внешний доступ на уровне файрвола, оставив себе только SSH с текущего IP:

   ufw default deny incoming
   ufw allow from ВАШ_IP to any port 22
   ufw enable

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

1. Сделайте копию текущего состояния диска или хотя бы папки сервера до любых правок — пригодится для анализа и как страховка, если что-то пойдёт не так при очистке:

   cp -a /home/gameserver /home/gameserver_incident_$(date +%F)

1. Если сервер на VPS с полным доступом — сделайте снапшот диска средствами хостинга, это быстрее и надёжнее ручного копирования.

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

Шаг 2. Меняем все пароли, SSH-ключи и токены

Пока не знаете точку входа, считайте скомпрометированным всё, до чего мог дотянуться атакующий. Меняем по списку, ничего не пропуская:

• Пароль root/sudo-пользователя на сервере и в панели хостинга.
• SSH-ключи — сгенерируйте новую пару, впишите публичный ключ в authorized_keys, удалите старые записи и чужие ключи, которых там быть не должно. Если до сих пор входите по паролю — самое время перейти на ключи, это закрывает целый класс атак (см. SSH-ключи вместо пароля для нескольких администраторов сервера).
• RCON-пароль игрового сервера — прописан в server.properties (rcon.password) или конфиге плагина, меняется и на сервере, и в клиентах, которые к нему подключаются.
• Пароль базы данных (MySQL/MariaDB для плагинов вроде EssentialsX, экономики, LiteBans) — ALTER USER 'gameuser'@'localhost' IDENTIFIED BY 'новый_пароль';, не забудьте обновить строку подключения в конфигах плагинов.
• API-токены и вебхуки: Discord-бот сервера, интеграции с панелью, ключи облачного бэкапа (rclone, S3-совместимое хранилище).
• Пароли FTP/SFTP-доступа, если используете отдельный протокол для загрузки файлов.
• Пароль панели управления хостингом и включите двухфакторную аутентификацию, если ещё не включена — это отдельная и очень действенная линия обороны (см. двухфакторную аутентификацию для панели управления сервером).

Проверьте /etc/passwd на предмет лишних учётных записей — атакующие иногда создают себе «запасного» пользователя с sudo-правами на случай, если основной вход прикроют:

cat /etc/passwd | grep -E "/bin/bash|/bin/sh"
sudo cat /etc/sudoers.d/*

Удалите всё, что не создавали вы сами.

Шаг 3. Анализ логов: ищем точку входа

Без понимания, как злоумышленник попал внутрь, любое восстановление временное — дыра просто откроется снова. Смотрим по порядку:

# Кто и когда входил по SSH
last -20
lastb -20   # неудачные попытки — покажет, был ли брутфорс

# Журнал аутентификации (Debian/Ubuntu)
grep "Accepted" /var/log/auth.log
grep "Failed password" /var/log/auth.log | tail -50

# То же через journalctl, если auth.log нет
journalctl -u ssh --since "7 days ago" | grep -i accepted

# Активные сетевые соединения и процессы, слушающие порты
ss -tulpn

# Подозрительные процессы по нагрузке
ps aux --sort=-%cpu | head -20

# Файлы, изменённые за последние N дней — часто выдаёт бэкдор
find / -type f -mtime -5 -not -path "/proc/*" 2>/dev/null | grep -vE "^/var/log"

# Crontab — популярное место для закладки, которая переустанавливает майнер после чистки
crontab -l
ls -la /etc/cron.d/ /etc/cron.daily/

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

• Minecraft: logs/latest.log на команды от неизвестных ников, время добавления записей в ops.json и whitelist.json (сверьте timestamp файла с реальными действиями админов).
• Rust: консольный лог сервера на команды ownerid/moderatorid, изменения в oxide/data/ServerUsers.json.
• CS2/Source-игры: логи SourceMod, изменения admins_simple.ini или admins.cfg.
• Панель хостинга (если есть свой веб-интерфейс или Pterodactyl) — журнал входов в аккаунт, список активных сессий, привязанные API-ключи.

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

Шаг 4. Проверка на бэкдоры и восстановление из чистого бэкапа

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

• Лишний публичный ключ в ~/.ssh/authorized_keys (проверяйте у всех пользователей, не только у root).
• Cron-задача, которая скачивает и перезапускает вредоносный процесс по расписанию.
• Модифицированный systemd-юнит или скрипт автозапуска, который поднимает что-то помимо игрового сервера.
• Плагин или мод с изменённым кодом — если ставили что-то не из официальных источников (не с CurseForge/Modrinth для Minecraft, не из Steam Workshop/uMod для Rust) риск особенно высок.
• «Тихий» админ, добавленный в конфиг игры, который не палится в чате, пока не понадобится.

Самый надёжный способ разорвать всё это разом — не чистить руками файл за файлом, а поднять сервер с нуля на чистой ОС и накатить бэкап, сделанный до даты компрометации:

1. Определите дату взлома по логам из шага 3 — это ваша точка отсчёта.
2. Берите бэкап мира/сохранений и конфигов, датированный заведомо раньше этой точки. Свежий бэкап «за вчера» может уже содержать закладку.
3. Разворачивайте на чистом сервере (новая ОС, не тот же диск с недочищенными следами) — подробный практический разбор процесса в статье восстановление сервера из бэкапа на практике.
4. Игровые файлы (мир, сохранения) переносите, а вот системные бинарники и загрузчики сервера — переустанавливайте заново из официальных источников, не копируйте «как есть».
5. Прогоните антивирусное сканирование (rkhunter, chkrootkit) на новом сервере уже после разворачивания бэкапа — на всякий случай, если в архив бэкапа что-то попало.

Если игроки успели что-то потерять (лут, постройки) между последним чистым бэкапом и моментом взлома — честно объявите об откате в Discord/чате сервера с датой и причиной. Это менее болезненно, чем повторный взлом через неделю.

Как закрыть уязвимость и не словить повтор

После восстановления сервер снова работает, но задача не закончена — нужно закрыть саму причину, а не только последствия:

Полезные системные меры, которые стоит внедрить сразу после инцидента, если их ещё не было: ограничение доступа по IP для админ-панелей, регулярные автобэкапы по расписанию, а не «когда вспомнил», и base-line мониторинг нагрузки, чтобы аномальный скачок CPU от майнера бросался в глаза сразу, а не через неделю.

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

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