Настройки безопасности Paper и Spigot: что включить и что отключить

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

В этой статье разберём каждый файл по отдельности. Для каждой настройки объясню не просто "поставь вот это значение", а почему именно так. Понимание причин важнее копирования чужих конфигов.

server.properties: фундамент

Этот файл читается самым первым при запуске сервера. Он управляет базовым поведением vanilla Minecraft, и именно здесь находятся критически важные переключатели.

online-mode

online-mode=true

Это самая важная настройка безопасности на всём сервере. Точка. Когда online-mode=true, сервер проверяет каждого подключающегося игрока через серверы аутентификации Mojang. Это гарантирует, что игрок действительно владеет аккаунтом, под которым заходит.

Когда online-mode=false, любой может зайти под любым ником. Хочешь зайти под ником администратора? Пожалуйста. Хочешь зайти под ником другого игрока и забрать его вещи? Легко. Всё, что нужно, это поменять ник в лаунчере.

Единственное исключение: если сервер работает за прокси (Velocity, BungeeCord). В этом случае online-mode=false на бэкенд-серверах допустим, потому что аутентификацию выполняет прокси. Но тогда обязательно нужна правильная настройка форвардинга (об этом ниже).

Если у тебя standalone-сервер без прокси, online-mode должен быть true. Без вариантов.

enable-query

enable-query=false

Query-протокол позволяет внешним приложениям запрашивать информацию о сервере: список игроков, версию, описание, установленные плагины. Звучит безобидно, но на практике это создаёт два вектора атаки.

Первый: утечка информации. Атакующий получает список плагинов и их версий. Зная, что у тебя стоит AuthMe 5.6.0, он может поискать известные уязвимости для этой версии. Список онлайн-игроков помогает определить активность сервера и выбрать время для атаки.

Второй: query работает по UDP. А UDP-порт, принимающий произвольные запросы, это готовый вектор для амплификации. Атакующий может использовать твой query-порт для отражённых атак на другие серверы, и отвечать за это будешь ты.

Выключай query. Для мониторинга есть лучшие решения: плагины с API, RCON (с ограничениями), внешние мониторинг-сервисы.

enable-rcon

enable-rcon=false
rcon.port=25575
rcon.password=

RCON (Remote Console) даёт полный доступ к консоли сервера по сети. Это как SSH, только для Minecraft. И проблема ровно та же: если кто-то получит доступ к RCON, он получит полный контроль над сервером. Может выполнять любые команды, менять настройки, банить игроков, устанавливать плагины.

Если RCON не нужен, выключай. Если нужен (для автоматизации, панели управления), то:

1. Используй сложный пароль, не менее 20 символов
2. Ограничь доступ файрволом только с localhost или IP панели
3. Никогда не открывай RCON-порт наружу

# Разрешить RCON только с localhost
iptables -A INPUT -p tcp --dport 25575 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 25575 -j DROP

network-compression-threshold

network-compression-threshold=256

Этот параметр определяет минимальный размер пакета (в байтах), после которого он будет сжат. Дефолтное значение 256 означает, что пакеты больше 256 байт будут сжиматься перед отправкой.

Казалось бы, причём тут безопасность? Сжатие уменьшает трафик, но увеличивает нагрузку на CPU. Атакующий, который отправляет серверу множество маленьких пакетов, может заставить сервер тратить ресурсы на ненужную компрессию/декомпрессию.

Значение 256 считается оптимальным балансом. Если поставить слишком низко (например, 64), сервер будет сжимать почти каждый пакет, тратя CPU впустую. Если поставить -1, сжатие отключится полностью, и трафик вырастет.

Для серверов за прокси можно поставить -1, потому что сжатие выполняет прокси. Для standalone-серверов оставляй 256.

rate-limit

rate-limit=15

Ограничивает количество пакетов в секунду от одного подключения. Дефолтное значение 0 означает отсутствие лимита. Это плохо. Один клиент с модифицированным лаунчером может отправлять тысячи пакетов в секунду, перегружая сервер.

Значение 15 означает, что сервер будет кикать подключение, если оно отправляет более 15 пакетов за тик (50мс). Это достаточно для нормальной игры, но отсекает агрессивный спам.

Не путай с packet-limiter в Paper (о нём ниже). rate-limit в server.properties работает на более низком уровне, до обработки пакетов серверным ядром.

prevent-proxy-connections

prevent-proxy-connections=false

Этот параметр заставляет сервер проверять, не подключается ли игрок через прокси или VPN, используя API Mojang. Если проверка показывает, что IP-адрес игрока отличается от IP, с которого проходила аутентификация, подключение отклоняется.

На бумаге звучит полезно. На практике эта проверка вызывает несколько проблем. Во-первых, она создаёт дополнительную задержку при подключении, потому что сервер отправляет запрос к Mojang API. Во-вторых, она может блокировать легитимных игроков, которые используют VPN для повышения безопасности или из-за ограничений провайдера.

Для standalone-серверов можно включить prevent-proxy-connections=true как дополнительный слой защиты. Но если ты уже используешь плагин для блокировки VPN (или сервис вроде MineGuard, который фильтрует ботов и прокси на сетевом уровне), смысла в этой настройке мало.

За прокси (Velocity/BungeeCord) эту настройку нужно оставить false, иначе все подключения будут отклоняться, потому что IP прокси не совпадает с IP аутентификации.

max-players

max-players=100

Казалось бы, настройка вместимости, не безопасности. Но подумай: если у тебя на сервере обычно играет 30 человек, зачем держать лимит 1000? При бот-атаке все 1000 слотов будут заняты ботами, и каждый из них создаёт нагрузку на сервер.

Ставь max-players чуть выше реального онлайна. Если обычно 30 игроков, поставь 50-70. Это ограничит масштаб бот-атак и снизит нагрузку при попытке флуда подключениями.

spigot.yml: уровень выше

Spigot добавляет свой слой настроек поверх vanilla. Многие из них влияют на производительность, но некоторые критически важны для безопасности.

connection-throttle

settings:
  connection-throttle: 4000

Определяет минимальный интервал (в миллисекундах) между подключениями с одного IP-адреса. Значение 4000 означает, что один IP может подключаться не чаще раза в 4 секунды.

Зачем: при бот-атаке сотни подключений идут с каждого IP за секунду. Connection throttle блокирует повторные попытки, снижая нагрузку на процесс авторизации.

Важный нюанс: если сервер стоит за прокси (Velocity/BungeeCord), то все подключения приходят с одного IP (IP прокси). В этом случае connection-throttle нужно отключить (поставить -1), иначе он будет блокировать легитимных игроков.

# За прокси:
settings:
  connection-throttle: -1

bungeecord

settings:
  bungeecord: false

Этот флаг включает поддержку IP-форвардинга от BungeeCord. Если bungeecord: true, сервер доверяет данным о реальном IP игрока, которые передаёт прокси через специальное поле в handshake-пакете.

Проблема: если включить bungeecord: true на сервере, который не защищён прокси, любой может подделать свой IP. Это не теоретическая уязвимость, есть готовые инструменты для IP-спуфинга через BungeeCord-форвардинг. Атакующий может зайти под IP администратора и обойти IP-бан, или зайти с IP другого игрока.

Правило простое: bungeecord: true только если сервер действительно стоит за BungeeCord И порт бэкенда закрыт файрволом от внешних подключений. Во всех остальных случаях false.

Ещё лучше: вместо BungeeCord используй Velocity с modern forwarding. Подробнее об этом в нашей статье про Velocity vs BungeeCord.

moved-wrongly-threshold и moved-too-quickly-multiplier

settings:
  moved-wrongly-threshold: 0.0625
  moved-too-quickly-multiplier: 10.0

Эти параметры контролируют античит-проверки движения на уровне сервера. moved-wrongly-threshold определяет допустимое отклонение позиции игрока от ожидаемой. moved-too-quickly-multiplier задаёт множитель максимальной скорости перемещения.

Дефолтные значения достаточно мягкие и подходят для большинства серверов. Если поставить слишком строго, обычные игроки с лагами будут получать телепортации назад. Если слишком мягко, читеры смогут летать и телепортироваться без детекции.

Для PvP-серверов, где критично предотвратить speed-hack и fly, можно поставить чуть строже:

settings:
  moved-wrongly-threshold: 0.0625
  moved-too-quickly-multiplier: 8.0

Но для серьёзной защиты от читов лучше ставить плагин-античит (Grim, Vulcan), а не полагаться на встроенные проверки.

log-filter и player-shuffle

settings:
  log-filter:
    - "Moved too quickly!"
    - "moved wrongly!"

Логирование "Moved too quickly" и "moved wrongly" полезно для диагностики, но при бот-атаке эти сообщения могут забивать лог тысячами строк в секунду, создавая IO-нагрузку. Если ты настроил packet-limiter и античит, можешь добавить эти сообщения в фильтр логов.

player-shuffle: 0 (дефолт) определяет порядок обработки игроков. Значение 0 отключает перемешивание. На PvP-серверах рекомендуется поставить ненулевое значение, чтобы порядок обработки тиков не давал преимущество игрокам, подключившимся раньше.

timeout-time и restart-on-crash

settings:
  timeout-time: 30
  restart-on-crash: true

timeout-time определяет, через сколько секунд сервер считает зависшее соединение мёртвым. Дефолтные 60 секунд, это слишком много. 30 секунд достаточно для нормальной игры, но мёртвые соединения будут закрываться быстрее, освобождая ресурсы.

restart-on-crash: true автоматически перезапускает сервер при краше. Критически важно для защиты от краш-эксплойтов: если атакующий нашёл способ уронить сервер, он хотя бы поднимется обратно автоматически. Подробнее о краш-эксплойтах читай в отдельной статье.

paper-global.yml: мощные инструменты Paper

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

packet-limiter

packet-limiter:
  kick-message: '<red><lang:disconnect.exceeded_packet_rate>'
  limits:
    all:
      interval: 7.0
      max-packet-rate: 500.0
    ServerboundCommandSuggestionPacket:
      interval: 1.0
      max-packet-rate: 15.0

Это встроенный анти-краш от Paper. Packet-limiter отслеживает количество пакетов определённого типа за интервал времени и кикает клиента, если лимит превышен.

Дефолтная конфигурация: не более 500 пакетов любого типа за 7 секунд. Для ServerboundCommandSuggestionPacket (автодополнение команд) лимит строже: 15 пакетов в секунду. Почему? Потому что автодополнение команд вызывает обработку на стороне сервера, и спам этими пакетами может создать значительную нагрузку.

Для дополнительной защиты можно добавить лимиты на другие "тяжёлые" пакеты:

packet-limiter:
  kick-message: '<red><lang:disconnect.exceeded_packet_rate>'
  limits:
    all:
      interval: 7.0
      max-packet-rate: 500.0
    ServerboundCommandSuggestionPacket:
      interval: 1.0
      max-packet-rate: 15.0
    ServerboundContainerClickPacket:
      interval: 1.0
      max-packet-rate: 25.0
    ServerboundPlaceRecipePacket:
      interval: 1.0
      max-packet-rate: 5.0
    ServerboundSetCreativeModeSlotPacket:
      interval: 1.0
      max-packet-rate: 10.0

ServerboundContainerClickPacket отвечает за клики по слотам инвентаря. Спам кликами, это классический способ нагрузить сервер или дюпнуть предметы. ServerboundPlaceRecipePacket используется для автокрафта. ServerboundSetCreativeModeSlotPacket ограничивает скорость размещения предметов в креативе.

Не ставь лимиты слишком низко. Если max-packet-rate для all будет 100, обычные игроки будут кикаться при активной игре (открытие сундуков, торговля, PvP). 500 за 7 секунд это примерно 71 пакет в секунду, что достаточно для нормальной игры.

velocity-support

proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: 'сложный-секретный-ключ-из-velocity'

Если используешь Velocity как прокси, эта секция заменяет устаревший bungeecord: true в spigot.yml. Modern forwarding в Velocity использует HMAC для подписи данных игрока, что делает подделку IP невозможной (в отличие от BungeeCord).

secret должен совпадать с ключом в forwarding-secret на стороне Velocity. Используй длинный случайный ключ, не "password123".

Не включай velocity-support и bungeecord одновременно. Это не имеет смысла и может создать конфликты.

Подробнее о преимуществах Velocity перед BungeeCord мы писали в отдельной статье. Там же разбираются null-атаки и другие эксплойты, которым подвержен BungeeCord.

incoming-packet-threshold

packet-limiter:
  limits:
    all:
      interval: 7.0
      max-packet-rate: 500.0

Глобальный порог входящих пакетов. Работает совместно с packet-limiter. Если клиент превышает max-packet-rate за указанный interval, соединение разрывается.

Дефолтные 500 пакетов за 7 секунд обычно достаточно. На серверах с тяжёлым PvP (Factions, KitPvP) можно поднять до 600, потому что активный бой генерирует больше пакетов движения и атаки.

Логирование

logging:
  log-player-ip-addresses: false

По умолчанию Paper логирует IP-адреса игроков. Если ты в юрисдикции с GDPR (Европа) или просто хочешь минимизировать хранение персональных данных, выключи это. IP-адреса в логах, это утечка данных при компрометации сервера.

paper-world-defaults.yml: защита мира

Эти настройки применяются ко всем мирам по умолчанию. Многие из них предотвращают конкретные эксплойты.

max-entity-collisions

collisions:
  max-entity-collisions: 2

Ограничивает максимальное количество столкновений сущностей за тик. Дефолтное значение 8 позволяет создавать "давилки" из сущностей, которые генерируют огромное количество вычислений коллизий и роняют TPS.

Значение 2 радикально снижает нагрузку от entity cramming. Для большинства серверов 2 достаточно. На серверах с фермами животных (SMP) можно поставить 4, но выше 8 ставить не рекомендуется.

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

max-auto-save-chunks-per-tick

chunks:
  max-auto-save-chunks-per-tick: 8

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

С точки зрения безопасности: если атакующий модифицирует множество чанков (взрывы TNT, лава-касты), высокое значение означает, что сервер будет пытаться сохранить все повреждённые чанки одновременно, создавая IO-шторм.

Значение 8 обеспечивает плавное сохранение без заметных просадок TPS.

entity-per-chunk-save-limit

entity-per-chunk-save-limit:
  experience_orb: 16
  snowball: 8
  ender_pearl: 8
  arrow: 16
  fireball: 8
  small_fireball: 8
  item: 32

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

Самые важные лимиты:

• experience_orb: 16 предотвращает лаг-машины из опыта
• arrow: 16 не даёт сохранить тысячи стрел от бот-стрельбы
• item: 32 ограничивает количество выброшенных предметов

Эти лимиты не влияют на нормальную игру, но спасают от целенаправленного саботажа.

fix-entity-position-desync

fixes:
  fix-entity-position-desync: true

Исправляет рассинхронизацию позиций сущностей между сервером и клиентом. Без этого фикса некоторые читы могут эксплуатировать рассинхрон для создания невидимых сущностей или перемещения через стены. Оставляй включённым.

anti-xray

anticheat:
  anti-xray:
    enabled: true
    engine-mode: 2

Anti-Xray не является настройкой безопасности в классическом смысле, но он предотвращает эксплуатацию ресурсов сервера через рентген-читы. engine-mode: 2 заменяет скрытые руды фейковыми блоками, что создаёт нагрузку, но обеспечивает лучшую защиту. engine-mode: 1 просто скрывает руды, потребляя меньше ресурсов.

Для серверов с экономикой на ресурсах (SMP, survival) рекомендуется engine-mode: 2. Для мини-игр и PvP, где руды не важны, можно оставить engine-mode: 1 или отключить.

bukkit.yml: базовые ограничения

bukkit.yml содержит настройки, общие для всех серверов на основе CraftBukkit (включая Spigot и Paper).

connection-throttle

settings:
  connection-throttle: 4000

Работает аналогично connection-throttle в spigot.yml. На практике, если оба значения установлены, приоритет имеет spigot. Но лучше установить одинаковое значение в обоих файлах для консистентности.

Рекомендация та же: 4000 для standalone, -1 за прокси.

spawn-limits

spawn-limits:
  monsters: 50
  animals: 8
  water-animals: 3
  water-ambient: 5
  water-underground-creature: 3
  axolotls: 3
  ambient: 1

Ограничения на количество мобов в мире. Дефолтные значения vanilla завышены. 70 монстров на игрока, это слишком много для большинства серверов.

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

Значение monsters: 50 обеспечивает нормальный геймплей (мобы спавнятся, фермы работают), но не даёт перегрузить сервер.

chunk-gc

chunk-gc:
  period-in-ticks: 400

Сборщик мусора для чанков. Определяет, как часто сервер проверяет и выгружает чанки без игроков поблизости. Дефолтные 600 тиков (30 секунд) можно уменьшить до 400 (20 секунд).

Зачем: чем быстрее выгружаются ненужные чанки, тем меньше памяти занимает сервер. При атаках, связанных с генерацией новых чанков (chunk-loading exploits), быстрая выгрузка снижает накопление нагрузки.

Комплексная конфигурация: собираем всё вместе

Вот итоговый набор настроек безопасности для standalone Paper-сервера:

# server.properties
online-mode=true
enable-query=false
enable-rcon=false
network-compression-threshold=256
rate-limit=15
max-players=100
prevent-proxy-connections=false

# spigot.yml
settings:
  bungeecord: false
  connection-throttle: 4000
  timeout-time: 30
  restart-on-crash: true
  moved-wrongly-threshold: 0.0625
  moved-too-quickly-multiplier: 10.0

# paper-global.yml
packet-limiter:
  kick-message: '<red><lang:disconnect.exceeded_packet_rate>'
  limits:
    all:
      interval: 7.0
      max-packet-rate: 500.0
    ServerboundCommandSuggestionPacket:
      interval: 1.0
      max-packet-rate: 15.0
proxies:
  velocity:
    enabled: false
    online-mode: true
    secret: ''
logging:
  log-player-ip-addresses: false

# paper-world-defaults.yml
collisions:
  max-entity-collisions: 2
chunks:
  max-auto-save-chunks-per-tick: 8
entity-per-chunk-save-limit:
  experience_orb: 16
  arrow: 16
  item: 32
  snowball: 8

# bukkit.yml
settings:
  connection-throttle: 4000
spawn-limits:
  monsters: 50
  animals: 8
  water-animals: 3
  ambient: 1
chunk-gc:
  period-in-ticks: 400

Конфигурация за прокси (Velocity)

Если сервер стоит за Velocity, конфигурация отличается:

# server.properties
online-mode=false
enable-query=false
enable-rcon=false
network-compression-threshold=-1
rate-limit=0

# spigot.yml
settings:
  bungeecord: false
  connection-throttle: -1

# paper-global.yml
proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: 'ваш-секретный-ключ-из-velocity-forwarding-secret'

Обрати внимание: online-mode=false в server.properties, но online-mode: true в velocity-support. Аутентификацию выполняет Velocity, а бэкенд-сервер доверяет данным от прокси. network-compression-threshold=-1, потому что сжатие выполняет Velocity. connection-throttle: -1, потому что все подключения идут с IP прокси.

И обязательно: закрой порт бэкенд-сервера файрволом. Если порт 25565 открыт наружу при online-mode=false, любой может зайти напрямую, минуя прокси и аутентификацию.

# Разрешить подключения к бэкенду только с IP прокси
iptables -A INPUT -p tcp --dport 25565 -s IP_ПРОКСИ -j ACCEPT
iptables -A INPUT -p tcp --dport 25565 -j DROP

Чего не стоит трогать

Не все настройки нужно менять. Вот что лучше оставить по умолчанию:

• max-tick-time в server.properties. Ставить -1 ("не крашить сервер при зависании") кажется хорошей идеей, но на практике это означает, что зависший сервер будет висеть вечно вместо перезапуска. Лучше оставить дефолтные 60000 и настроить restart-on-crash: true.
• view-distance в spigot.yml. Уменьшение снижает нагрузку, но это настройка производительности, не безопасности. Не ставь ниже 6, иначе геймплей пострадает.
• allow-end и allow-nether в bukkit.yml. Отключение измерений не повышает безопасность, а только ломает геймплей.

Что конфиги не решают

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

Конфиги не защитят от DDoS-атак на сетевом уровне. Для этого нужна внешняя фильтрация трафика, например через MineGuard. Пакетные лимиты Paper отсекают краш-эксплойты, но против потока в 10 Гбит/с они бессильны.

Конфиги не заменяют файрвол. Даже с идеальными настройками server.properties, открытые порты SSH, RCON, базы данных это дыры в безопасности. Файрвол обязателен.

Конфиги не заменяют обновления. Если в Paper найдут уязвимость, никакие настройки не помогут, нужен патч. Обновляйся регулярно.

Лучший подход, это комбинация: правильные конфиги + файрвол + DDoS-защита + регулярные обновления. Каждый слой закрывает свои угрозы. Подробнее о комплексном подходе к безопасности читай в чеклисте безопасности Minecraft-сервера.

Автоматизация проверки

Не хочешь проверять конфиги вручную? Вот простой скрипт, который покажет основные проблемы:

#!/bin/bash
echo "=== Security Config Check ==="

# server.properties
if grep -q "online-mode=false" server.properties 2>/dev/null; then
  echo "[WARN] online-mode is FALSE"
fi
if grep -q "enable-query=true" server.properties 2>/dev/null; then
  echo "[WARN] query is enabled"
fi
if grep -q "enable-rcon=true" server.properties 2>/dev/null; then
  echo "[WARN] RCON is enabled"
fi
if grep -q "rate-limit=0" server.properties 2>/dev/null; then
  echo "[WARN] rate-limit is disabled"
fi

echo "=== Check complete ==="

Добавь его в cron или запускай после каждого изменения конфигурации.

Частые ошибки

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

Включённый bungeecord без прокси. Это, пожалуй, самая опасная ошибка. Админ когда-то тестировал BungeeCord, включил bungeecord: true, потом убрал прокси, но забыл выключить флаг. Теперь любой может подделать IP при подключении.

RCON с простым паролем, открытый наружу. Часто встречается на серверах с панелями управления. Панель работает на другом сервере и подключается к RCON по сети. Но порт открыт для всех, и пароль "minecraft123". Результат предсказуем.

online-mode: false на standalone без причины. Некоторые админы отключают аутентификацию "чтобы пиратки могли заходить". Это открывает двери для подмены аккаунтов. Если нужна поддержка нелицензионных клиентов, используй AuthMe или аналогичный плагин, но лучше всего работать с online-mode: true.

Слишком агрессивные лимиты пакетов. Если поставить max-packet-rate: 50 в packet-limiter, игроки будут массово кикаться при открытии инвентаря торговца или активном PvP. Тестируй лимиты на тестовом сервере перед применением на проде.

Итог

Безопасность Minecraft-сервера начинается с правильных конфигов. Не с плагинов, не с DDoS-защиты, а с пяти файлов, которые контролируют базовое поведение сервера.

Настрой server.properties, spigot.yml, paper-global.yml, paper-world-defaults.yml и bukkit.yml по рекомендациям из этой статьи. Это займёт 15 минут и закроет десятки векторов атаки, которые эксплуатируются ежедневно.

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