Защита сервера CRMP — RCON, MySQL, панель и аккаунты

Модель защиты сервера CRMP

Нельзя гарантировать безопасность одной настройкой. Необходимо использовать несколько уровней защиты.

Основные уровни

• панель управления хостингом;
• учётная запись владельца;
• SSH или удалённый рабочий стол;
• операционная система;
• серверные файлы;
• RCON;
• игровая административная система;
• MySQL;
• аккаунты игроков;
• плагины и игровые скрипты;
• резервные копии;
• журналы безопасности.

Принцип минимальных прав

Каждый пользователь и сервис должен иметь только тот доступ, который необходим для его работы.

Примеры

• игровому администратору не нужен SSH;
• разработчику не всегда нужен доступ к панели оплаты;
• игровому моду не нужен MySQL-пользователь root;
• системе резервного копирования не нужен RCON;
• тестовый сервер не должен работать с основной базой;
• обычному модератору не нужна команда выдачи денег.

Чем меньше доступов имеет одна учётная запись, тем меньше ущерб при её компрометации.

Какие данные необходимо защищать

Критические серверные файлы

• server.cfg;
• конфигурация MySQL;
• игровой мод PWN и AMX;
• серверные плагины;
• filterscripts;
• файлы в scriptfiles;
• SSH-ключи;
• служебные скрипты;
• настройки автоматического запуска.

Критические секреты

• RCON-пароль;
• пароль панели хостинга;
• пароль MySQL;
• SSH-ключи;
• токены Telegram или Discord;
• ключи внешних API;
• секреты восстановления;
• пароли архивов резервных копий.

Критические данные базы

• аккаунты игроков;
• хеши паролей;
• IP-адреса;
• игровая экономика;
• транспорт и имущество;
• права администрации;
• наказания;
• журналы действий персонала.

Создайте список активов

Для каждого элемента укажите:

• где он находится;
• кто имеет доступ;
• как создаётся резервная копия;
• как быстро его восстановить;
• когда менялся пароль;
• кто отвечает за обслуживание.

Разделение уровней доступа

Владелец

Может иметь полный доступ к панели, оплате, резервным копиям и управлению персоналом.

Системный администратор

Работает с VPS, SSH, firewall, MySQL и серверным процессом. Доступ к финансовым настройкам панели ему может быть не нужен.

Разработчик

Работает с PWN, тестовой базой и журналами ошибок. Постоянный доступ к рабочей MySQL следует выдавать только при необходимости.

Главный администратор

Управляет игровым персоналом через внутриигровую систему, но не получает RCON, SSH и пароль базы.

Модератор

Получает только команды, необходимые для жалоб, наблюдения и ограниченных наказаний.

Не используйте общие аккаунты

Вместо одной учётной записи для всей команды создайте отдельный аккаунт каждому сотруднику. Тогда можно определить, кто выполнил действие, и отключить только одного пользователя.

Безопасная настройка RCON

RCON позволяет управлять серверным ядром, выполнять команды, менять параметры и останавливать процесс. Его компрометация может привести к полной потере контроля над сервером.

Пример включённого RCON

rcon 1
rcon_password ДЛИННЫЙ_УНИКАЛЬНЫЙ_ПАРОЛЬ

Основные правила

• замените значение changeme;
• не используйте название проекта;
• не используйте пароль владельца;
• не передавайте пароль игровому персоналу;
• не публикуйте полный server.cfg;
• не вводите пароль во время трансляции;
• меняйте пароль после ухода технического сотрудника;
• контролируйте неудачные попытки входа.

Отключение RCON, если он не используется

Если сервер управляется только через панель или локальную консоль, RCON можно отключить:

rcon 0

Перед отключением проверьте

• можно ли перезапустить сервер через панель;
• есть ли доступ к консоли процесса;
• не использует ли игровой мод RCON-команды;
• не настроено ли внешнее управление через RCON;
• можно ли сменить игровой пароль другим способом.

Отключение уменьшает поверхность атаки

Неиспользуемая функция не должна оставаться доступной только потому, что она включена по умолчанию.

Создание надёжного RCON-пароля

Генерация случайной строки Linux

openssl rand -hex 24

Команда создаст случайную шестнадцатеричную строку длиной 48 символов.

Пароль должен быть

• случайным;
• достаточно длинным;
• уникальным;
• сохранённым в менеджере паролей;
• известным минимальному числу людей.

Не используйте

123456
qwerty
admin
miami
crmp2026
название_проекта
ник_владельца

После смены

1. Сохраните конфигурацию.
2. Перезапустите сервер при необходимости.
3. Проверьте авторизацию.
4. Удалите старый пароль из сообщений и заметок.
5. Обновите защищённое хранилище владельца.

Контроль попыток входа в RCON

Callback OnRconLoginAttempt позволяет обнаруживать попытки внутриигровой RCON-авторизации.

Безопасное журналирование

public OnRconLoginAttempt(
 ip[],
 password[],
 success
)
{
 if (!success)
 {
 printf(
 "[SECURITY] Failed RCON login from IP %s",
 ip
 );
 }
 else
 {
 printf(
 "[SECURITY] Successful RCON login from IP %s",
 ip
 );
 }

 return 1;
}

Не записывайте параметр password

Callback передаёт введённый пароль, но сохранять его в консоль или файл нельзя. Игрок мог случайно ввести пароль от другого сервиса.

При повторных неудачах можно

• уведомить владельца;
• временно отключить игрока;
• увеличить задержку;
• записать IP и идентификатор сессии;
• временно ограничить дальнейшие попытки.

Не применяйте постоянный IP-бан автоматически

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

Защита файла server.cfg

В файле могут находиться RCON-пароль, список плагинов, игровой пароль и другие служебные параметры.

На Linux ограничьте права

sudo chown crmp:crmp \
/home/crmp/server/server.cfg

chmod 600 \
/home/crmp/server/server.cfg

Не отправляйте полный файл

Для диагностики копируйте только необходимые строки и предварительно заменяйте секреты:

rcon_password СКРЫТО
password СКРЫТО

Не храните копии

• в публичном репозитории;
• на общедоступном форуме;
• в открытом облачном документе;
• в архиве игрового мода для скачивания;
• в папке сайта;
• в клиентской сборке.

Сетевые лимиты в server.cfg

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

Пример стандартных параметров

messageslimit 500
messageholelimit 3000
ackslimit 3000
playertimeout 10000

Не уменьшайте значения вслепую

Слишком строгие ограничения могут отключать обычных игроков с нестабильным интернетом.

Изменяйте параметры только после

• анализа журналов;
• подтверждения конкретного вида флуда;
• тестирования на отдельной сборке;
• сравнения числа ложных отключений;
• сохранения исходных значений.

Защита панели управления сервером

Через панель злоумышленник может остановить сервер, заменить файлы, открыть консоль, получить резервные копии или изменить сетевые настройки.

Обязательные меры

• уникальный пароль панели;
• многофакторная аутентификация;
• отдельный аккаунт каждому сотруднику;
• HTTPS без предупреждений сертификата;
• уведомления о новых входах;
• проверка активных сессий;
• ограничение прав сотрудников;
• удаление неиспользуемых аккаунтов;
• сохранение резервных кодов MFA офлайн.

Не входите в панель

• с чужого компьютера;
• через неизвестный публичный Wi-Fi без защищённого соединения;
• по ссылке из подозрительного сообщения;
• с отключённой проверкой сертификата;
• через сохранённый пароль в общем браузере.

MFA и отдельные аккаунты панели

Многофакторная аутентификация требует дополнительного подтверждения входа помимо пароля.

Предпочтительные варианты

• аппаратный ключ безопасности;
• приложение-аутентификатор;
• защищённый push-запрос;
• одноразовые резервные коды.

Особенно важно включить MFA для

• владельца проекта;
• панели хостинга;
• регистратора домена;
• облачного хранилища копий;
• почты восстановления;
• аккаунтов с доступом к оплате;
• служебных сообществ проекта.

Не храните резервные коды

• на том же сервере;
• в общем чате;
• в незашифрованном текстовом файле;
• в скриншоте на публичном компьютере.

Контроль сессий панели

Регулярно проверяйте

• активные устройства;
• IP последних входов;
• географию подключений;
• время создания сессии;
• неизвестные API-ключи;
• добавленных пользователей;
• изменения прав.

После подозрительного входа

1. Завершите все сессии.
2. Смените пароль.
3. Перенастройте MFA.
4. Обновите резервные коды.
5. Проверьте изменения файлов.
6. Проверьте резервные копии.
7. Проверьте платёжные и сетевые настройки.

Не ограничивайтесь сменой пароля

У злоумышленника может остаться активная сессия, API-токен или добавленный аккаунт.

Защита SSH-доступа к VPS

Основные меры

• не работать постоянно под root;
• использовать отдельного администратора;
• входить по SSH-ключу;
• ограничить список пользователей;
• закрыть ненужные порты;
• следить за журналом авторизации;
• удалять старые ключи;
• устанавливать обновления безопасности.

Создание отдельного администратора

sudo adduser crmpadmin
sudo usermod -aG sudo crmpadmin

Проверьте вход новым пользователем

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

Просмотр попыток авторизации

sudo journalctl \
-u ssh \
-n 150 \
--no-pager

На некоторых системах служба может называться sshd.

Настройка входа по SSH-ключам

Создание ключа на компьютере администратора

ssh-keygen -t ed25519

Копирование открытого ключа

ssh-copy-id \
crmpadmin@IP_СЕРВЕРА

После успешной проверки можно настроить sshd

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
AllowUsers crmpadmin

Проверка конфигурации

sudo sshd -t

Перезагрузка службы

sudo systemctl reload ssh

Закрытый ключ

• не отправляйте другим людям;
• защитите парольной фразой;
• не загружайте на игровой VPS без необходимости;
• сохраните резервную защищённую копию;
• отзывайте после потери устройства.

Запуск CRMP от отдельного пользователя Linux

Игровой процесс не должен постоянно работать с правами root.

Создание системного пользователя

sudo adduser \
--system \
--group \
--home /home/crmp \
crmp

Назначение владельца

sudo chown -R \
crmp:crmp \
/home/crmp/server

Запуск

sudo -u crmp \
/home/crmp/server/samp03svr-cr

Преимущества

• процесс не получает полный доступ к системе;
• плагин ограничен правами пользователя;
• проще контролировать файлы;
• меньше ущерб при эксплуатации уязвимости;
• удобнее настраивать systemd.

Настройка прав серверных файлов

Каталоги

find /home/crmp/server \
-type d \
-exec chmod 750 {} \;

Обычные файлы

find /home/crmp/server \
-type f \
-exec chmod 640 {} \;

Исполняемый серверный файл

chmod 750 \
/home/crmp/server/samp03svr-cr

Файлы с паролями

chmod 600 \
/home/crmp/server/server.cfg

chmod 600 \
/home/crmp/server/scriptfiles/mysql.ini

Не используйте без необходимости

chmod -R 777 /home/crmp/server

Полные права всем пользователям упрощают изменение или удаление серверных файлов.

Настройка firewall на VPS

Открывайте только порты, которые действительно используются.

Пример UFW

sudo ufw default deny incoming
sudo ufw default allow outgoing

sudo ufw allow OpenSSH
sudo ufw allow 8904/udp

sudo ufw enable
sudo ufw status verbose

Перед включением

• разрешите текущий SSH-порт;
• уточните порт CRMP;
• учтите порт панели управления;
• учтите мониторинг и резервное копирование;
• проверьте правила провайдера.

Если MySQL находится на другом сервере

Разрешайте порт только с IP игрового VPS:

sudo ufw allow \
from IP_CRMP_СЕРВЕРА \
to any port 3306 \
proto tcp

Не открывайте MySQL всему интернету

sudo ufw allow 3306/tcp

Такое правило без ограничения источника нежелательно.

Защита базы данных MySQL

Основные правила

• не подключать игровой мод под root;
• создать отдельного пользователя;
• ограничить его одной базой;
• ограничить Host подключения;
• не выдавать административные права;
• не открывать порт 3306 без необходимости;
• использовать шифрование при удалённом соединении;
• регулярно проверять список пользователей;
• удалять старые учётные записи;
• не публиковать SQL-дампы.

Проверка пользователей

SELECT
 User,
 Host,
 account_locked
FROM mysql.user
ORDER BY User, Host;

Проверка прав

SHOW GRANTS
FOR 'crmp_runtime'@'127.0.0.1';

Ограничение сетевого доступа MySQL

Если база находится на том же VPS, MySQL обычно не должна слушать внешний интерфейс.

Пример настройки

[mysqld]
bind-address = 127.0.0.1

После изменения

sudo systemctl restart mysql
sudo ss -lntp | grep 3306

Ожидаемый адрес локальной базы

127.0.0.1:3306

Не используйте публичный адрес без причины

0.0.0.0:3306

Прослушивание всех интерфейсов требует строгого firewall, ограниченных пользователей и защищённого соединения.

Отдельный пользователь MySQL для игрового мода

Создание пользователя

CREATE USER
'crmp_runtime'@'127.0.0.1'
IDENTIFIED BY 'СЛОЖНЫЙ_УНИКАЛЬНЫЙ_ПАРОЛЬ';

Минимальные права рабочего мода

GRANT
 SELECT,
 INSERT,
 UPDATE,
 DELETE
ON `crmp_server`.*
TO 'crmp_runtime'@'127.0.0.1';

Проверка

SHOW GRANTS
FOR 'crmp_runtime'@'127.0.0.1';

Не выдавайте игровому моду

• GRANT OPTION;
• FILE;
• PROCESS;
• SHUTDOWN;
• глобальный доступ ON *.*;
• права управления пользователями.

Раздельные пользователи MySQL

Практическое разделение

• crmp_runtime — работа игрового мода;
• crmp_migration — обновление структуры;
• crmp_backup — создание дампов;
• crmp_readonly — просмотр статистики;
• административный пользователь — управление MySQL.

Пользователь только для чтения

CREATE USER
'crmp_readonly'@'127.0.0.1'
IDENTIFIED BY 'ОТДЕЛЬНЫЙ_ПАРОЛЬ';

GRANT SELECT
ON `crmp_server`.*
TO 'crmp_readonly'@'127.0.0.1';

Преимущества

• утечка статистического аккаунта не позволяет менять данные;
• можно отдельно отключить разработчика;
• проще проверить назначение соединения;
• пароли можно менять независимо;
• снижается риск случайного удаления таблиц.

Безопасное удалённое подключение к MySQL

Предпочтительные варианты

• база на том же VPS;
• закрытая сеть провайдера;
• VPN между серверами;
• SSH-туннель для администрирования;
• TLS-соединение MySQL;
• firewall с разрешением одного IP.

Создание пользователя для конкретного IP

CREATE USER
'crmp_runtime'@'IP_CRMP_СЕРВЕРА'
IDENTIFIED BY 'СЛОЖНЫЙ_ПАРОЛЬ';

GRANT
 SELECT,
 INSERT,
 UPDATE,
 DELETE
ON `crmp_server`.*
TO 'crmp_runtime'@'IP_CRMP_СЕРВЕРА';

Нежелательный вариант

'crmp_runtime'@'%'

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

Защита SQL-запросов игрового мода

Имя игрока, текст диалога, промокод, причина наказания и другие клиентские строки нельзя вставлять в SQL без обработки.

Предпочтительный подход

SELECT
 `id`,
 `password_hash`
FROM `accounts`
WHERE `name` = ?
LIMIT 1;

Если версия плагина не поддерживает параметры

• используйте его функцию экранирования;
• ограничивайте длину строки;
• проверяйте размер буфера;
• не формируйте имена таблиц из ввода;
• не разрешайте несколько SQL-команд;
• не выводите запросы с паролями в лог.

Асинхронный запрос не защищает от SQL-инъекции

Асинхронность предотвращает блокировку игрового потока, но не исправляет небезопасное формирование SQL.

Защита аккаунтов игроков

Система должна

• хранить только хеш пароля;
• ограничивать число попыток входа;
• использовать уникальный ID аккаунта;
• защищать асинхронные callbacks номером сессии;
• не раскрывать пароль администраторам;
• не записывать пароль в журнал;
• безопасно восстанавливать доступ;
• закрывать старые сессии после смены пароля.

Не разрешайте вход до полной загрузки

Игрок получает доступ к командам и игровому миру только после проверки пароля и загрузки обязательных данных.

Подробная настройка регистрации и авторизации CRMP

Защита аккаунтов администрации

Для персонала используйте

• отдельные аккаунты;
• уникальные длинные пароли;
• ограниченные уровни доступа;
• журнал всех опасных команд;
• дополнительное подтверждение критических действий;
• уведомления о необычных входах;
• немедленное снятие прав после ухода.

Не выдавайте права по нику в PWN

if (!strcmp(playerName, "Owner_Name"))
{
 AdminLevel[playerid] = 10;
}

Права должны загружаться из серверной базы после успешной авторизации.

Критические команды

• выдача денег;
• изменение административного уровня;
• удаление имущества;
• перманентная блокировка;
• перезапуск сервера;
• выполнение SQL;
• восстановление аккаунта.

Такие команды должны быть доступны минимальному числу сотрудников.

Безопасное хранение паролей

Нельзя хранить

password=PlayerPassword123

Нельзя сохранять пароль обратимым способом

Администратор базы не должен иметь возможность расшифровать исходные пароли игроков.

Используйте адаптивное хеширование

• Argon2id;
• bcrypt;
• scrypt;
• PBKDF2 при правильной настройке.

Не используйте быстрый SHA-256 как новую парольную систему

Быстрые функции позволяют злоумышленнику проверять большое количество вариантов после утечки базы.

Столбец хеша

`password_hash` VARCHAR(255) NOT NULL

Защита от перебора паролей

Учитывайте попытки

• на один аккаунт;
• на одну игровую сессию;
• на один IP;
• за короткий период времени;
• для административных аккаунтов отдельно.

После ошибок применяйте

• постепенно увеличивающуюся задержку;
• временную блокировку входа;
• уведомление владельца аккаунта;
• запись события безопасности;
• дополнительное подтверждение для персонала.

Не блокируйте навсегда после нескольких ошибок

Злоумышленник сможет намеренно заблокировать любой известный аккаунт.

Безопасность серверных плагинов

DLL и SO выполняют нативный машинный код и могут обращаться к файлам, сети, памяти и базе данных.

Перед установкой проверяйте

• официальный источник;
• автора;
• номер версии;
• историю изменений;
• наличие исходного кода;
• контрольную сумму;
• антивирусные результаты;
• зависимости;
• совместимость с AMX;
• поведение на тестовой машине.

Не устанавливайте архив, если

• нет информации об авторе;
• внутри находится неизвестный EXE;
• требуется отключить антивирус;
• плагин подключается к неизвестному серверу;
• архив содержит лишние скрипты запуска;
• версия не указана;
• файл найден только на случайном форуме.

После установки

• проверьте исходящие соединения;
• проверьте новые файлы;
• сравните CPU и память;
• проверьте журналы;
• сохраните предыдущую рабочую версию.

Установка и проверка плагинов CRMP

Защита исходного кода игрового мода

Не публикуйте вместе с PWN

• пароли MySQL;
• RCON-пароль;
• токены ботов;
• ключи API;
• адреса внутренних сервисов;
• секретные административные команды;
• реальные резервные копии базы.

Перед публикацией архива ищите секреты

grep -RniE \
"rcon_password|MYSQL_PASSWORD|token|api_key|secret|password" \
/home/crmp/server

Используйте систему версий

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

Удаление секрета из последнего файла недостаточно

Пароль может остаться в истории репозитория. После публикации его необходимо сменить.

Хранение паролей и токенов

Подходящие места

• менеджер паролей владельца;
• защищённый конфигурационный файл;
• переменные окружения;
• система управления секретами;
• зашифрованное офлайн-хранилище.

Не храните секреты

• в общем Telegram-чате;
• в сообщении без ограничения срока;
• в названии файла;
• в публичном репозитории;
• в клиентском коде;
• в скриншоте панели;
• в серверном журнале.

Ротация секретов

Меняйте пароль или токен:

• после ухода сотрудника;
• после утечки архива;
• после подозрительного входа;
• после заражения компьютера;
• после публикации журнала;
• после передачи доступа подрядчику;
• по установленному внутреннему графику.

Стратегия резервного копирования CRMP

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

Храните несколько независимых копий

• оперативную копию на VPS;
• копию у другого провайдера;
• офлайн-копию;
• защищённую от изменения или удаления копию;
• копию исходного кода и конфигураций.

Резервируйте

• MySQL;
• игровой мод;
• плагины;
• include-файлы;
• server.cfg;
• scriptfiles;
• systemd-службу;
• служебные скрипты;
• административные логи;
• инструкцию восстановления.

Копии должны быть

• регулярными;
• зашифрованными;
• проверяемыми;
• отделёнными от рабочей системы;
• доступными только ограниченному кругу лиц.

Создание резервной копии MySQL

Файл реквизитов для резервного пользователя

[client]
host=127.0.0.1
user=crmp_backup
password=СЛОЖНЫЙ_ПАРОЛЬ

Ограничьте права файла

sudo chmod 600 \
/root/.crmp-backup.cnf

Создание сжатого дампа

mysqldump \
--defaults-extra-file=/root/.crmp-backup.cnf \
--single-transaction \
--routines \
--triggers \
--events \
crmp_server \
| gzip \
> /home/crmp/backups/database-$(date +%F-%H%M).sql.gz

Почему пароль не указывается в команде

Пароль в аргументах или cron-задании может попасть в историю терминала, список процессов или журнал.

После создания проверьте

ls -lh \
/home/crmp/backups/database-*.sql.gz

gzip -t \
/home/crmp/backups/database-*.sql.gz

Резервное копирование файлов сервера

Создание архива

tar -czf \
/home/crmp/backups/server-$(date +%F-%H%M).tar.gz \
/home/crmp/server

Не включайте без необходимости

• старые резервные копии;
• огромные временные журналы;
• core-файлы;
• кэш;
• дубликаты сборок;
• открытые пароли в отладочных файлах.

Сохраняйте версии перед

• обновлением AMX;
• заменой плагина;
• миграцией MySQL;
• изменением server.cfg;
• обновлением системы;
• переносом на новый хостинг.

Шифрование резервных копий

Дамп базы содержит хеши паролей, IP-адреса, права администрации и экономические данные. Даже резервная копия должна быть защищена.

Пример симметричного шифрования GPG

gpg \
--symmetric \
--cipher-algo AES256 \
database-2026-07-31.sql.gz

После проверки зашифрованного файла

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

Пароль шифрования

• не должен храниться рядом с архивом;
• должен находиться у владельца;
• должен иметь резервную защищённую копию;
• не должен совпадать с панелью или MySQL.

Проверка восстановления резервных копий

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

Регулярный тест

1. Создайте отдельную тестовую базу.
2. Импортируйте последний дамп.
3. Разверните копию серверных файлов.
4. Замените реквизиты на тестовые.
5. Запустите сервер на другом порту.
6. Войдите существующим аккаунтом.
7. Проверьте имущество и экономику.
8. Проверьте административные права.
9. Зафиксируйте время восстановления.

Проверьте не только последний архив

Храните несколько поколений копий. Последний файл мог быть создан уже после повреждения или незаметного удаления данных.

Журналы безопасности и мониторинг

Проверяйте

• server_log.txt;
• ошибки MySQL;
• входы SSH;
• входы в панель;
• попытки RCON;
• изменения персонала;
• административные команды;
• экономические операции;
• изменения файлов;
• неудачные резервные копии.

Поиск подозрительных сообщений

grep -iE \
"failed|denied|error|rcon|login|password|ban|setadmin" \
server_log.txt \
| tail -n 200

Не записывайте

• пароли;
• токены;
• полные ключи API;
• секреты восстановления;
• закрытые SSH-ключи;
• полные реквизиты MySQL.

Настройте ротацию

Журналы не должны бесконтрольно занимать весь диск. При этом записи о серьёзных событиях следует хранить достаточно долго для расследования.

Регулярный аудит доступа

Ежемесячно проверяйте

• аккаунты панели;
• SSH-пользователей;
• файл authorized_keys;
• пользователей MySQL;
• игровой персонал;
• активные API-токены;
• доступ к репозиторию;
• доступ к резервным копиям;
• активные сессии;
• неиспользуемые плагины.

Проверка SSH-ключей

find /home /root \
-name authorized_keys \
-type f \
-print

Проверка заданий cron

sudo crontab -l
sudo ls -la /etc/cron.d/
sudo ls -la /etc/cron.daily/

Проверка пользователей Linux

getent passwd

После ухода сотрудника

• отключите его аккаунт;
• удалите SSH-ключ;
• отзовите токены;
• снимите игровые права;
• завершите сессии;
• смените общие секреты, которые он знал.

Безопасное обновление CRMP Server

Перед обновлением

• создайте резервную копию;
• проверьте источник файла;
• прочитайте список изменений;
• зафиксируйте версии;
• подготовьте тестовую сборку;
• проверьте совместимость плагинов;
• проверьте миграции MySQL.

Не обновляйте одновременно

• серверное ядро;
• игровой мод;
• все плагины;
• операционную систему;
• структуру базы;
• панель управления.

После установки

• проверьте загрузку плагинов;
• проверьте авторизацию;
• проверьте административные команды;
• проверьте исходящие соединения;
• проверьте новые файлы;
• следите за CPU и памятью;
• сохраните рабочую версию.

Защита CRMP от сетевых атак

Крупная DDoS-атака должна фильтроваться до игрового VPS. Один firewall внутри перегруженного сервера не восстановит уже заполненный канал.

При выборе хостинга проверяйте

• наличие защиты UDP;
• поддержку игровых протоколов;
• ёмкость фильтрации;
• время реакции поддержки;
• возможность смены IP;
• наличие закрытой сети для MySQL;
• журналы сетевых атак.

На самом сервере

• закройте ненужные порты;
• не публикуйте IP MySQL;
• используйте встроенные лимиты сообщений;
• обновляйте серверное ядро;
• не запускайте посторонние службы;
• контролируйте сетевой трафик;
• не блокируйте случайные диапазоны без анализа.

Проверка трафика Linux

sudo ss -lunp
sar -n DEV 1

Что делать при подозрении на взлом

1. Ограничьте дальнейший доступ

• закройте сервер паролем;
• снимите подозрительные права;
• завершите сессии панели;
• ограничьте SSH;
• не удаляйте журналы.

2. Сохраните доказательства

• скопируйте server_log;
• сохраните журналы панели;
• сохраните SSH-журнал;
• создайте список процессов;
• сохраните список сетевых соединений;
• зафиксируйте время происшествия.

3. Смените секреты

• пароль панели;
• RCON-пароль;
• SSH-ключи;
• пароли MySQL;
• токены ботов;
• ключи API;
• почту восстановления.

4. Проверьте систему

ps aux
sudo ss -tpn
sudo ss -lunp
sudo crontab -l
sudo find /home/crmp/server \
-type f \
-mtime -7 \
-print

5. Проверьте проект

• новых администраторов;
• выдачу денег;
• изменение имущества;
• снятые блокировки;
• добавленные плагины;
• изменения PWN и AMX;
• новых пользователей MySQL;
• изменения резервных копий.

6. Восстанавливайте только из проверенной копии

Не возвращайте заражённый плагин или изменённый скрипт вместе с архивом.

Контрольный список защиты CRMP

RCON

• значение changeme заменено;
• пароль уникален;
• обычный персонал его не знает;
• попытки входа контролируются;
• введённые пароли не записываются;
• неиспользуемый RCON отключён.

Панель и SSH

• включена MFA;
• аккаунты сотрудников разделены;
• проверены активные сессии;
• SSH использует ключи;
• root-вход ограничен;
• старые ключи удалены;
• открыты только необходимые порты.

MySQL

• игровой мод не использует root;
• пользователь ограничен одной базой;
• Host ограничен;
• нет лишних глобальных прав;
• порт 3306 не открыт всем;
• удалённое соединение защищено;
• пользователи регулярно проверяются.

Аккаунты

• пароли хешируются адаптивным алгоритмом;
• открытые пароли отсутствуют;
• работает ограничение попыток;
• права администрации хранятся на сервере;
• опасные команды журналируются;
• аккаунты бывших сотрудников отключены.

Файлы и плагины

• права файлов ограничены;
• процесс работает не от root;
• плагины получены из доверенных источников;
• версии записаны;
• секреты не находятся в репозитории;
• обновления тестируются отдельно.

Резервные копии

• копируется база;
• копируются серверные файлы;
• есть внешняя копия;
• есть офлайн или защищённая от изменения копия;
• архивы зашифрованы;
• восстановление регулярно проверяется;
• хранятся несколько поколений.

Частые вопросы по защите сервера CRMP

Нужно ли отключать RCON?

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

Можно ли выдавать RCON главному администратору?

Лучше использовать внутриигровые уровни и разрешения. RCON оставляйте владельцу и техническому специалисту.

Можно ли записывать неправильный RCON-пароль в лог?

Нет. Записывайте только IP, время и результат попытки.

Где хранить RCON-пароль?

В защищённом менеджере паролей и конфигурации с ограниченными правами.

Как защитить panel хостинга?

Включить MFA, использовать отдельные аккаунты, проверять сессии и ограничивать права сотрудников.

Можно ли использовать один аккаунт панели всей командой?

Нет. При отдельных аккаунтах проще вести аудит и отзывать доступ.

Нужно ли отключать SSH-пароли?

Вход по ключам безопаснее, но отключать пароль следует только после успешной проверки ключа и резервного способа доступа.

Можно ли запускать CRMP от root?

Не рекомендуется. Создайте отдельного системного пользователя.

Какие права устанавливать на server.cfg?

На Linux файл с секретами можно ограничить значением 600 и назначить владельцем пользователя сервера.

Нужно ли открывать порт MySQL?

Для базы на том же VPS — нет. Для удалённой базы разрешайте подключение только с IP игрового сервера.

Можно ли использовать MySQL root в моде?

Нет. Создайте отдельного пользователя с минимальными правами.

Какие права нужны игровому моду?

Обычно SELECT, INSERT, UPDATE и DELETE в одной базе. Дополнительные права выдаются только после проверки реальной необходимости.

Что опасного в пользователе @%?

Он не ограничивает источник подключения конкретным хостом.

Как защитить SQL-запросы?

Использовать параметры либо функции экранирования установленного MySQL-плагина.

Можно ли хранить пароли игроков в SHA-256?

Для новой системы лучше использовать Argon2id, bcrypt или другой адаптивный алгоритм.

Нужно ли давать разработчику рабочую базу?

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

Безопасны ли плагины DLL и SO?

Только доверенные и проверенные версии. Нативная библиотека может выполнять произвольные действия с правами серверного процесса.

Достаточно ли антивирусной проверки плагина?

Нет. Также проверяйте источник, автора, исходный код, историю версий и поведение на тестовой системе.

Где хранить резервные копии?

На нескольких независимых носителях или сервисах, включая внешнюю и офлайн-копию.

Нужно ли шифровать SQL-дамп?

Да, особенно если он переносится или хранится вне рабочего VPS.

Как проверить резервную копию?

Импортировать её в отдельную базу и запустить тестовую сборку сервера.

Как часто менять пароли?

После утечки, ухода сотрудника, подозрительного входа или передачи доступа. Периодическую ротацию можно установить внутренними правилами проекта.

Что делать первым при взломе?

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

Нужно ли сразу удалять заражённый VPS?

Сначала сохраните необходимые журналы и данные для расследования. Восстановление выполняйте из проверенной чистой копии.

Защитит ли UFW от крупного DDoS?

Нет. Для переполнения канала необходима защита на стороне хостинга или сетевого провайдера.

Официальные и технические источники

• Настройка RCON и сетевых параметров server.cfg
• Обработка попыток авторизации RCON
• Управление сервером через RCON
• Общие рекомендации по безопасности MySQL
• Создание и ограничение пользователей MySQL
• Права доступа MySQL
• Шифрование соединений MySQL
• Рекомендации OWASP по хранению паролей
• Защита систем аутентификации
• Рекомендации CISA по многофакторной аутентификации
• Рекомендации CISA по резервным копиям и восстановлению