Whitelist vs Online Mode в Minecraft - что безопаснее?

Два параметра в server.properties, которые путают даже опытных админов: white-list и online-mode. Оба связаны с доступом игроков на сервер, но работают совершенно по-разному. Один проверяет личность игрока, другой - его присутствие в списке. И если ты неправильно настроишь хотя бы один из них, последствия могут быть от "кто-то зашёл под моим ником" до "весь мир разрушен гриферами".

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

Что такое online-mode

online-mode=true - это параметр в server.properties, который говорит серверу: "проверяй каждого подключающегося игрока через серверы Mojang". Когда игрок заходит на сервер, клиент отправляет запрос на sessionserver.mojang.com, и Mojang подтверждает, что этот аккаунт действительно принадлежит тому, кто пытается подключиться.

Что это даёт на практике:

• Каждый игрок получает уникальный UUID, привязанный к его купленному аккаунту
• Никто не может зайти под чужим ником - сервер просто не пропустит
• Все данные (инвентарь, права, банки) привязаны к UUID, а не к нику
• Скины загружаются корректно через серверы Mojang

UUID - это основа идентификации. Когда online-mode=true, UUID выглядит как 069a79f4-44e9-4726-a5be-fca90e38aaf5 и генерируется Mojang для каждого купленного аккаунта. Он не меняется, даже если игрок сменит ник. Все плагины, базы данных и мировые данные привязываются именно к этому идентификатору.

Что происходит при online-mode=false

Когда ты ставишь online-mode=false, сервер перестаёт проверять аккаунты через Mojang. Любой клиент может подключиться с любым ником. UUID генерируется оффлайн на основе ника по формуле UUID.nameUUIDFromBytes("OfflinePlayer:ИмяИгрока") - это так называемый offline UUID.

Почему это опасно:

• Любой может зайти под ником администратора и получить все его права
• UUID привязан к нику, а не к аккаунту - смена ника = потеря всех данных
• Невозможно отличить настоящего игрока от самозванца
• Бот-атаки становятся тривиальными - не нужно покупать аккаунты, просто генерируй рандомные ники

Да, offline-режим позволяет играть людям без купленного аккаунта. Но цена этого - полное отсутствие встроенной системы идентификации.

Что такое whitelist

white-list=true включает белый список - файл whitelist.json, содержащий список игроков, которым разрешено подключаться к серверу. Все остальные получают сообщение "You are not white-listed on this server!" и не могут зайти.

Управление списком простое:

/whitelist add НикИгрока
/whitelist remove НикИгрока
/whitelist list
/whitelist reload

Whitelist работает на уровне подключения - сервер проверяет ник (и UUID, если online-mode=true) ещё до того, как игрок полностью заходит на сервер. Это значит, что незнакомые люди не просто не смогут играть - они даже не увидят мир.

Whitelist + online-mode: как они взаимодействуют

Вот ключевой момент. При online-mode=true whitelist проверяет UUID игрока. При online-mode=false - только ник. Разница огромная.

С online-mode=true + whitelist: сервер проверяет, что игрок - это реально тот человек, за кого себя выдаёт (через Mojang), И что он есть в белом списке. Двойная проверка. Максимальная безопасность.

С online-mode=false + whitelist: сервер проверяет только ник. А ник может ввести кто угодно. Whitelist в этом случае - это замок на двери, ключ от которого - просто знание имени хозяина.

Cracked серверы: реальные риски

Cracked серверы (с online-mode=false) - это не просто "серверы для пиратов". Это серверы с фундаментально другой моделью безопасности, где стандартные механизмы защиты Minecraft не работают.

Вот что может пойти не так:

Кража аккаунтов. Без Mojang-аутентификации любой может зайти под любым ником. Если админ server.properties вайтлист - не поможет, потому что злоумышленник просто введёт ник админа. Без дополнительных плагинов все данные, права и инвентарь будут доступны атакующему.

Бот-атаки. На online-mode сервер бот-атака требует сотни или тысячи купленных аккаунтов (или украденных токенов). На cracked - бот просто генерирует случайные ники. Стоимость атаки падает до нуля. Бот может создать 1000 подключений в минуту с разными никами, и каждое из них сервер должен обработать.

Spoofing UUID. В offline-режиме UUID предсказуем - он считается из ника. Это значит, что атакующий может заранее вычислить UUID любого игрока и потенциально манипулировать данными.

Exploits через fake-ники. Некоторые плагины доверяют нику или UUID без дополнительной проверки. На cracked-сервере это открывает дыры - от эскалации привилегий до SQLi, если плагин не экранирует ник при запросе к базе данных.

AuthMe: костыль, который стал стандартом

Если твой сервер работает в offline-режиме, AuthMe - это первое, что ты должен установить. Он добавляет систему регистрации и логина поверх стандартного подключения.

Как это работает: при первом заходе игрок должен выполнить /register пароль пароль. При последующих заходах - /login пароль. До авторизации игрок не может двигаться, ломать блоки, писать в чат или взаимодействовать с миром.

AuthMe хранит пароли в хешированном виде (bcrypt по умолчанию), поддерживает MySQL/MariaDB, имеет защиту от брутфорса и кучу настроек. Для offline-серверов это обязательный минимум.

Но AuthMe - это не замена online-mode. Это заплатка. Вот почему:

• Игрок должен помнить ещё один пароль (и многие ставят "123456")
• Если база данных AuthMe утечёт, все аккаунты скомпрометированы
• Существуют тайминг-атаки и другие способы обхода
• Новые игроки путаются с регистрацией и уходят

Для серверов с большой аудиторией крекеров AuthMe в связке с FastLogin (автологин для лицензионных аккаунтов) - рабочая конфигурация. Но если у тебя есть возможность работать в online-mode - работай в online-mode.

Подробнее о плагинах безопасности и их настройке читай в нашем обзоре плагинов.

BungeeCord и Velocity: forwarding-режимы и безопасность

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

Legacy forwarding (BungeeCord)

Старый механизм. BungeeCord передаёт UUID и IP игрока через специальные поля в handshake-пакете. Backend-сервер слепо доверяет этим данным, если в spigot.yml стоит bungeecord: true.

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

BungeeGuard

BungeeGuard решает проблему legacy forwarding через общий секретный токен. Прокси добавляет токен в handshake, и backend-сервер проверяет его наличие. Если токена нет или он неверный - подключение отклоняется. Это простое и эффективное решение, если ты по каким-то причинам не можешь перейти на Velocity.

Modern forwarding (Velocity)

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

В конфиге Velocity это player-info-forwarding-mode = "modern", а на backend в paper-global.yml нужно указать тот же секрет. Это самый безопасный способ передачи данных об игроке в 2026 году.

Рекомендация: если строишь сеть с нуля - используй Velocity с modern forwarding. Если уже на BungeeCord и не можешь мигрировать - ставь BungeeGuard и закрывай порты.

Реальные сценарии атак

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

Сценарий 1: Угон аккаунта админа на cracked-сервере

Сервер с online-mode=false, без AuthMe. Админ с ником "ServerAdmin" имеет OP. Атакующий заходит под ником "ServerAdmin", получает все права, делает /op своему основному аккаунту, сносит spawn и банит всех. Весь процесс занимает 30 секунд.

Защита: AuthMe + сложные пароли, OP только через консоль (никогда через /op в игре), использование плагинов прав вместо OP.

Сценарий 2: Бот-флуд на cracked-сервере

Атакующий запускает ботнет, который генерирует сотни подключений в секунду с рандомными никами. Сервер тратит ресурсы на обработку каждого подключения, TPS падает, реальные игроки не могут зайти. Если AuthMe установлен - боты застревают на экране логина, но всё равно жрут ресурсы.

Защита: LimboFilter на прокси-сервере (отсеивает ботов до попадания на основной сервер), rate-limiting по IP, внешняя фильтрация трафика.

Сценарий 3: Прямое подключение к backend

Сеть серверов: BungeeCord + несколько Spigot. Админ забыл закрыть порт 25566 (один из backend-серверов). На backend стоит bungeecord: true и online-mode=false. Атакующий подключается напрямую, подделывает handshake с UUID админа, получает полный доступ.

Защита: файрвол (только прокси может подключаться к backend), BungeeGuard или переход на Velocity modern forwarding, регулярный аудит открытых портов.

Сценарий 4: UUID collision на offline-сервере

На offline-сервере UUID считается из ника. Атакующий создаёт аккаунт с ником, который даёт такой же UUID, как у целевого игрока (через перебор или специальные инструменты). Результат: доступ к инвентарю, enderchest и данным плагинов целевого игрока.

Защита: online-mode=true решает проблему полностью, так как UUID выдаётся Mojang и не зависит от ника.

Какую конфигурацию выбрать

Вот мои рекомендации в зависимости от типа сервера:

Приватный сервер для друзей: online-mode=true + white-list=true. Максимальная защита с минимальными усилиями. Никто посторонний не зайдёт.

Публичный лицензионный сервер: online-mode=true + whitelist выключен. Mojang-аутентификация обеспечивает базовую безопасность. Добавь плагины безопасности по необходимости.

Публичный cracked-сервер: online-mode=false + AuthMe + FastLogin + LimboFilter. Это минимальный набор. Без него сервер будет постоянно подвергаться атакам. И даже с ним - риски выше, чем у лицензионного.

Сеть серверов (BungeeCord/Velocity): прокси в online-mode=true, backend в online-mode=false + Velocity modern forwarding (или BungeeGuard). Файрвол на backend-серверах обязателен.

Комбинирование whitelist + online-mode

Лучший вариант для серверов, где нужен строгий контроль доступа - включить оба. online-mode=true гарантирует, что игрок - это тот, за кого себя выдаёт. white-list=true ограничивает доступ конкретным списком проверенных людей.

Это идеально для:

• Серверов в стадии разработки (чтобы случайные люди не заходили)
• Приватных серверов для сообщества
• Серверов с ценным контентом (крупные проекты, где гриферство = огромные убытки)
• Тестовых серверов, где нужно контролировать окружение

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

Checklist безопасности сервера

Вот базовый чек-лист, который стоит пройти для любого сервера:

1. online-mode=true - если нет веских причин для offline-режима
2. whitelist - включи, если сервер не публичный
3. Файрвол - закрой все порты кроме необходимых (25565 для основного, остальное через VPN или внутреннюю сеть)
4. AuthMe - обязательно для offline-серверов
5. Velocity modern forwarding - для сетей серверов
6. Бэкапы - регулярные, на отдельный сервер
7. Мониторинг - следи за подозрительными логинами и аномалиями

Больше деталей по каждому пункту - в нашем полном чек-листе безопасности.

Итого

Online-mode и whitelist решают разные задачи. Online-mode - это про аутентификацию: "ты тот, за кого себя выдаёшь?". Whitelist - это про авторизацию: "тебе разрешено сюда заходить?".

Оба механизма дополняют друг друга. Online-mode без whitelist защищает от самозванцев, но не от нежелательных гостей. Whitelist без online-mode защищает от случайных заходов, но не от целенаправленного spoofing.

Если можешь - включи оба. Если работаешь в offline-режиме - компенсируй отсутствие Mojang-аутентификации плагинами. И в любом случае - не забывай про сетевую безопасность: файрвол, правильный forwarding и внешнюю защиту от DDoS.