Чеклист безопасности Minecraft сервера: 15 пунктов на 2026 год

Безопасность Minecraft сервера - это не разовое действие, а процесс. Ты можешь поставить самый мощный хостинг, самые крутые плагины, но если забыл закрыть RCON наружу или оставил пароль по умолчанию, всё это не имеет значения.

Этот чеклист - 15 конкретных пунктов, которые должен выполнить каждый администратор сервера в 2026 году. Не общие советы из серии "будьте осторожны", а конкретные действия с примерами конфигов и команд. Проходи по пунктам, отмечай выполненные, и к концу статьи твой сервер будет защищён на порядок лучше.

1. Обновляй серверное ПО

Звучит банально, но именно устаревшие версии - причина большинства взломов. Paper, Velocity, плагины, сам Java - всё должно быть актуальным.

Paper регулярно выпускает патчи безопасности. Когда в 2024 году обнаружили уязвимость в обработке chunk-данных, патч вышел за несколько часов. Но если ты сидишь на версии трёхмесячной давности, этот патч тебе не поможет.

Что делать конкретно:

• Подпишись на канал Paper в Discord (раздел announcements)
• Проверяй обновления плагинов хотя бы раз в неделю
• Используй Paper 1.21.x или новее
• JDK 21+ (LTS) для актуальных патчей безопасности Java

# Проверить версию Java
java -version

# Скачать последний Paper (пример)
wget https://api.papermc.io/v2/projects/paper/versions/1.21.4/builds/latest/downloads/paper-1.21.4-latest.jar

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

Отдельный момент с плагинами. Многие админы ставят плагин и забывают про него на годы. А плагин давно заброшен автором, и в нём уязвимость. Раз в месяц проходись по списку плагинов и удаляй то, что не используется. Меньше плагинов - меньше поверхность атаки.

2. Настрой файрвол

Файрвол - это первая линия обороны. Без него любой может сканировать порты твоего сервера и находить открытые сервисы.

Минимальный набор правил iptables для Minecraft сервера:

# Разрешаем established-соединения
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Разрешаем loopback
iptables -A INPUT -i lo -j ACCEPT

# SSH (поменяй порт на свой, см. пункт 4)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Minecraft (основной порт)
iptables -A INPUT -p tcp --dport 25565 -j ACCEPT

# Запрещаем всё остальное
iptables -A INPUT -j DROP

Если используешь сеть с несколькими серверами, порты бэкенд-серверов должны быть доступны только с прокси:

# Бэкенд-серверы только с localhost
iptables -A INPUT -p tcp --dport 30001:30010 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 30001:30010 -j DROP

Если хочешь разобраться подробнее, у нас есть отдельная статья по iptables для Minecraft.

Не забудь сохранить правила, чтобы они пережили ребут:

apt install iptables-persistent
netfilter-persistent save

3. SSH-ключи вместо паролей

Пароли для SSH - это прошлый век. Брутфорс атаки на SSH идут постоянно, и даже сложный пароль может быть подобран. SSH-ключи решают эту проблему полностью.

# На локальной машине: генерируем ключ
ssh-keygen -t ed25519 -C "minecraft-admin"

# Копируем на сервер
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server

# На сервере: отключаем пароли
sudo nano /etc/ssh/sshd_config

В sshd_config должны быть эти строки:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
MaxAuthTries 3

sudo systemctl restart sshd

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

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

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

4. Смени дефолтные порты

Порт 22 для SSH и 25565 для Minecraft знает каждый скрипт-кидди. Смена портов не остановит целенаправленную атаку, но отсекает 90% автоматического сканирования.

Для SSH:

# /etc/ssh/sshd_config
Port 2847  # Любой нестандартный порт

Minecraft-порт менять сложнее, потому что игроки должны его знать. Но SSH - меняй обязательно. Если у тебя сеть серверов, бэкенд-порты ставь нестандартные и закрывай файрволом (см. пункт 2).

Дополнительно можно установить fail2ban для SSH:

apt install fail2ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 2847
maxretry = 3
bantime = 3600
findtime = 600

Fail2ban будет автоматически банить IP, которые пытаются подобрать пароль или ключ к SSH.

5. Скрой реальный IP сервера

Если атакующий знает настоящий IP твоего сервера, он может бить напрямую, минуя любую защиту. Скрытие IP - критически важный шаг.

Основные способы:

• Используй прокси или DDoS-защиту (игроки подключаются к IP защиты, а не к твоему)
• Не свети IP в DNS-записях
• Не используй один IP для сайта и сервера
• Проверь исторические DNS-записи (SecurityTrails, Shodan)

Часто IP утекает через неочевидные места: логи плагинов, вебхуки Discord, панель управления. Проверь всё.

Ещё один частый источник утечки: ошибки в конфигурации DNS. Ты мог раньше привязать основной домен к серверу напрямую, а потом добавить прокси. Но историческая A-запись осталась в базах вроде SecurityTrails. Атакующий смотрит историю DNS и находит твой реальный IP за минуту. Перед включением прокси лучше сменить IP адрес сервера, если это возможно.

Мы подробно разбирали эту тему в статье о скрытии IP Minecraft сервера.

6. Velocity вместо BungeeCord

Если у тебя сеть серверов с прокси, BungeeCord - это серьёзный риск. Его система IPForward передаёт UUID игрока в plain text. Это значит, что при прямом доступе к бэкенд-серверу атакующий может зайти под любым аккаунтом.

Velocity Modern Forwarding использует HMAC-SHA256 для подписи данных. Подделать невозможно.

# velocity.toml
player-info-forwarding-mode = "modern"

# paper-global.yml на бэкенд-серверах
proxies:
  velocity:
    enabled: true
    online-mode: false
    secret: "ваш-секрет-из-forwarding.secret"

Даже если порт бэкенда случайно окажется открыт наружу, без валидной HMAC-подписи соединение будет отклонено. Это принципиально другой уровень защиты.

Подробное сравнение и гайд по миграции: Velocity vs BungeeCord.

7. Безопасная настройка server.properties

В server.properties есть несколько параметров, которые люди забывают настроить. А зря.

# Отключить query протокол
enable-query=false

# Отключить RCON (или не выставлять наружу)
enable-rcon=false

# Если RCON нужен - сложный пароль и только localhost
rcon.password=ДлинныйСложныйПароль2026!
rcon.port=25575

# Enforce secure profile
enforce-secure-profile=true

# Ограничение скорости подключения
rate-limit=10

# Спрятать online-count если нужно
hide-online-players=false

# Белый список
white-list=false
enforce-whitelist=false

Если у тебя прокси (Velocity), бэкенд-серверы должны слушать только на localhost:

server-ip=127.0.0.1
server-port=30001

Отдельно про online-mode: если сервер за прокси, online-mode ставится false на бэкенде и true на прокси. Без прокси - всегда true, если не хочешь пиратский сервер.

Ещё один важный параметр - max-players. Ставь реалистичное значение. Если у тебя обычно 50 игроков, нет смысла ставить 1000. Это не столько про безопасность, сколько про защиту от перегрузки. Если ботнет начнёт заливать ботов, ограничение слотов хотя бы частично замедлит нагрузку на сервер.

Параметр prevent-proxy-connections стоит включить, если ты не используешь прокси. Он блокирует подключения через VPN и прокси, что усложняет жизнь злоумышленникам. Но если твои игроки часто используют VPN, это вызовет проблемы.

8. Система прав доступа

Дефолтная система прав Minecraft минимальна. Тебе нужен LuckPerms.

Главные правила:

• Не давай op через ops.json. Используй группы прав
• Создай иерархию: default > vip > moderator > admin > owner
• Каждая группа получает только те права, которые ей нужны
• Никогда не давай * (все права) никакой группе

# Основные команды LuckPerms
/lp group default permission set minecraft.command.msg true
/lp group moderator permission set essentials.kick true
/lp group moderator permission set essentials.ban true
/lp group admin parent add moderator

Отдельно следи за правами плагинов. Некоторые плагины при установке дают дефолтной группе доступ к опасным командам. Проверяй plugin.yml каждого нового плагина.

WorldEdit, FAWE, Multiverse - эти плагины дают огромную власть. Права на них должны быть только у owner и, может быть, senior admin.

Распространённая ошибка: дать модераторам право на /give или /gamemode. Скомпрометированный аккаунт модератора с такими правами уничтожит экономику сервера за минуты. Модератору нужны права на кик, бан, мут и телепортацию. Всё остальное - лишнее.

Регулярно проверяй права. Используй /lp user <ник> permission info чтобы увидеть, какие права есть у конкретного игрока. Ты можешь удивиться, сколько лишних разрешений накопилось.

9. Античит

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

Популярные решения в 2026 году:

• Grim - бесплатный, открытый исходный код, хорошо ловит movement cheats
• Vulcan - платный, но более полный. Ловит combat, movement, player exploits
• Spartan - средний вариант, подходит для небольших серверов

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

# Пример минимальной настройки (зависит от плагина)
# Обычно включается в config.yml античита
punishments:
  fly:
    threshold: 10
    action: "kick %player% Unfair advantage detected"
  speed:
    threshold: 8
    action: "kick %player% Unfair advantage detected"

Помимо стандартного античита, обрати внимание на защиту от крашеров. Существуют специальные клиенты (типа Meteor, Wurst), которые отправляют невалидные пакеты или книги с огромным NBT, вызывая краш сервера или отдельных игроков. Плагины вроде Grim или отдельные решения типа PacketLimiter помогают фильтровать такие пакеты до того, как они навредят серверу.

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

10. Автоматические бэкапы

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

Минимальная схема:

• Ежедневные бэкапы мира, конфигов и базы данных
• Хранение на отдельном сервере или в облаке (не на том же диске)
• Ротация: хранить минимум 7 дневных + 4 недельных

#!/bin/bash
# Простой скрипт бэкапа
DATE=$(date +%Y-%m-%d_%H-%M)
BACKUP_DIR="/backups/minecraft"
SERVER_DIR="/opt/minecraft"

# Остановить автосохранение
screen -S minecraft -p 0 -X stuff "save-off$(printf '\r')"
screen -S minecraft -p 0 -X stuff "save-all$(printf '\r')"
sleep 5

# Бэкап
tar -czf "$BACKUP_DIR/backup-$DATE.tar.gz" \
    "$SERVER_DIR/world" \
    "$SERVER_DIR/world_nether" \
    "$SERVER_DIR/world_the_end" \
    "$SERVER_DIR/plugins"

# Включить автосохранение
screen -S minecraft -p 0 -X stuff "save-on$(printf '\r')"

# Удалить бэкапы старше 14 дней
find "$BACKUP_DIR" -name "*.tar.gz" -mtime +14 -delete

Добавь в cron:

# Каждый день в 4:00
0 4 * * * /opt/scripts/backup.sh

И обязательно проверяй бэкапы. Бэкап, который нельзя восстановить, бесполезен. Раз в месяц пробуй развернуть бэкап на тестовом сервере.

Не забудь бэкапить базу данных, если используешь MySQL/MariaDB для плагинов (LuckPerms, экономика, данные игроков):

# Бэкап MySQL базы
mysqldump -u minecraft -p minecraft_db > "$BACKUP_DIR/db-$DATE.sql"

Храни бэкапы не на том же сервере. Если сервер умрёт или будет взломан, бэкапы на нём тоже пропадут. Используй rsync на второй сервер, S3-совместимое хранилище (Backblaze B2 - дёшево), или даже обычный FTP на другой машине. Главное - физическое разделение.

11. Мониторинг ресурсов

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

Что мониторить:

• CPU - постоянная нагрузка выше 80% это проблема
• RAM - утечки памяти от плагинов
• Диск - логи и чанки могут съесть всё место
• Сеть - аномальный трафик указывает на атаку
• TPS - ниже 18 это заметные лаги

Для простого мониторинга:

# Установи htop для ручного контроля
apt install htop

# Spark - мониторинг TPS и профилирование внутри Minecraft
# Установи как плагин и используй /spark tps, /spark profiler

Для серьёзного мониторинга используй Prometheus + Grafana. Paper поддерживает экспорт метрик через spark. Настрой алерты на аномалии: резкий рост CPU, падение TPS, скачок входящего трафика.

Также полезно мониторить количество подключений. Если обычно у тебя 20-50 игроков, а вдруг стало 500 соединений - скорее всего, это бот-атака. Простой способ проверить:

# Количество TCP-соединений на порт Minecraft
ss -tn state established '( dport = :25565 )' | wc -l

# Или количество уникальных IP
ss -tn state established '( dport = :25565 )' | awk '{print $5}' | cut -d: -f1 | sort -u | wc -l

Настрой алерты в Telegram или Discord. Когда TPS падает ниже 15 или CPU выше 90%, ты должен узнать об этом мгновенно, а не через полчаса из жалоб игроков.

12. DDoS-защита

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

Что нужно понимать:

• Хостинг-провайдер обычно защищает от volumetric-атак (L3/L4), но не от application-level (L7)
• Minecraft-специфичные атаки (bot join flood, null ping, handshake flood) требуют специализированной фильтрации
• Простой TCPShield или HAProxy не поможет против продвинутых атак

Специализированная защита для Minecraft (такая как MineGuard) анализирует Minecraft-протокол и отсекает ботов на уровне handshake. Обычные L3/L4 фильтры не видят разницы между ботом и игроком, потому что оба используют одинаковые TCP-пакеты.

Если хочешь разобраться в основах, начни с нашего гайда для начинающих по защите Minecraft сервера.

Отдельно стоит упомянуть про Java-эксплойты. Log4Shell (CVE-2021-44228) в своё время затронул тысячи Minecraft серверов. Хотя этот конкретный эксплойт давно закрыт, подобные уязвимости на уровне JVM продолжают появляться. DDoS-защита не поможет от эксплойта в коде. Поэтому обновления (пункт 1) и DDoS-защита работают в связке, покрывая разные типы угроз.

13. Защита панелей управления

Pterodactyl, AMP, Multicraft - у каждого сервера есть какая-то панель управления. И часто она защищена хуже, чем сам сервер.

Чеклист для панели:

• Сильный пароль + 2FA для всех аккаунтов
• HTTPS (не HTTP) - Let's Encrypt бесплатен
• Ограничь доступ по IP если возможно
• Обновляй панель регулярно
• Отдельный поддомен (panel.example.com), не на основном IP сервера

Для Pterodactyl конкретно:

# Включить 2FA для администраторов (в настройках панели)
# Настроить nginx с SSL
apt install certbot python3-certbot-nginx
certbot --nginx -d panel.example.com

# Ограничить доступ к админке по IP в nginx
location /admin {
    allow 1.2.3.4;  # Твой IP
    deny all;
}

Wings (daemon Pterodactyl) тоже нужно защитить. Порт 8080 не должен быть доступен публично.

Если используешь SFTP для загрузки файлов, убедись что SFTP-пользователь имеет доступ только к папке сервера, а не ко всей файловой системе. Pterodactyl делает это автоматически через Docker-изоляцию, но если ты используешь обычный SFTP, настрой chroot.

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

14. Отключи ненужные фичи

Каждый открытый порт и каждый включённый сервис - это потенциальная точка входа. Отключай всё, что не используешь.

Самые частые виновники:

Query Protocol (порт 25565 UDP) - используется для серверных списков. Если ты не листишь сервер на GameTracker или подобных, отключай.

# server.properties
enable-query=false

RCON (порт 25575) - удалённая консоль. Если используешь, привяжи к localhost. Если нет - выключай.

enable-rcon=false
# Или если нужен:
enable-rcon=true
rcon.port=25575
rcon.password=ОченьСложныйПароль

# Привязать RCON к localhost через iptables
iptables -A INPUT -p tcp --dport 25575 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 25575 -j DROP

JMX Monitoring - Java Management Extensions. Если включён, даёт полный доступ к JVM. Убедись, что JMX-порт закрыт.

GeyserMC - если используешь для Bedrock-игроков, порт 19132 UDP должен быть открыт. Если не используешь - убери плагин.

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

Полезная команда для аудита открытых портов:

# Показать все порты, которые слушают
ss -tlnp

# Или через nmap (сканируй свой сервер снаружи)
nmap -sT -p 1-65535 your-server-ip

Сканируй свой сервер снаружи раз в месяц. Ты удивишься, сколько портов может быть открыто без твоего ведома: плагин поднял HTTP-сервер на порту 8123, DynMap открыл веб-интерфейс, MySQL слушает на 3306 снаружи.

15. План реагирования на инциденты

Это пункт, который все пропускают. А потом в 3 часа ночи, когда сервер лежит, судорожно гуглят "что делать".

Твой план должен содержать:

При DDoS-атаке:

1. Включить защиту / связаться с провайдером защиты
2. Проверить, не утёк ли реальный IP (если да - менять IP)
3. Сообщить игрокам через Discord
4. Логировать атаку для анализа

При взломе:

1. Немедленно отключить сервер от сети
2. Сменить все пароли (SSH, панели, RCON, БД)
3. Проверить логи - что было изменено
4. Восстановить из бэкапа (см. пункт 10)
5. Устранить уязвимость, через которую вошли
6. Сообщить игрокам, если данные могли утечь

При дюпе/эксплойте:

1. Остановить сервер
2. Откатить на бэкап до эксплойта
3. Обновить плагин, который вызвал проблему
4. Проверить ущерб экономике сервера

Запиши этот план в документ и дай доступ всем администраторам. Когда случается инцидент, нет времени думать. Нужно действовать по плану.

Контакты должны быть под рукой:

• Хостинг-провайдер (телефон, тикет-система)
• Провайдер DDoS-защиты
• Старший администратор (телефон)

Проводи "учения" раз в полгода. Притворись, что случился инцидент, и пройди по плану. Замерь время восстановления. Если восстановление из бэкапа занимает 4 часа, а ты думал что 30 минут - лучше узнать это на учениях, а не во время реального взлома.

Храни план в месте, доступном даже если сервер лежит. Google Docs, Notion, распечатанная бумажка - что угодно, кроме самого сервера. Потому что когда сервер взломан, ты не сможешь прочитать план, который лежит на этом сервере.

Итоги

Пройдёмся по чеклисту коротко:

1. ✅ Обновляй Paper, плагины, Java
2. ✅ Настрой iptables/ufw
3. ✅ SSH-ключи, без паролей
4. ✅ Нестандартные порты для SSH
5. ✅ Скрой реальный IP
6. ✅ Velocity вместо BungeeCord
7. ✅ Безопасный server.properties
8. ✅ LuckPerms, без op
9. ✅ Античит
10. ✅ Бэкапы каждый день
11. ✅ Мониторинг CPU/RAM/TPS
12. ✅ DDoS-защита
13. ✅ Защита панелей (2FA, HTTPS)
14. ✅ Отключи query, RCON, лишнее
15. ✅ План реагирования на инциденты

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

Безопасность - это не состояние, а процесс. Новые уязвимости появляются постоянно. Пересматривай этот чеклист раз в квартал и обновляй настройки.

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