Null-атаки и BungeeCord эксплойты: как защитить Minecraft сервер

Что такое null-атаки и почему они так эффективны

Если вы администрируете Minecraft сервер, рано или поздно вы столкнётесь с null-атаками. Это не классический DDoS, который забивает канал трафиком. Null-атаки работают тоньше - они отправляют серверу некорректные, пустые или специально сформированные пакеты, которые заставляют его тратить ресурсы на обработку мусора.

Суть проста: Minecraft протокол ожидает определённый формат данных. Когда приходит пакет с нулевой длиной, невалидным ID или обрезанными данными, сервер пытается его распарсить, ловит исключение и тратит на это CPU. Умножьте на тысячи соединений в секунду, и даже мощный сервер начнёт захлёбываться.

Типы null-атак на Minecraft

Null Ping

Самый простой вариант. Атакующий отправляет SLP (Server List Ping) запрос с пустым или повреждённым payload. Сервер пытается ответить на каждый такой пинг, генерирует MOTD, считает онлайн, формирует JSON-ответ. При тысячах таких запросов в секунду сервер тратит заметную часть CPU просто на ответы пингерам.

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

Null Login

Более агрессивный вариант. Бот начинает процедуру входа, отправляет Login Start пакет с пустым именем или невалидными данными. Сервер выделяет ресурсы на новую сессию, начинает обработку, а потом получает ошибку парсинга.

Особенно больно это бьёт по серверам с тяжёлыми плагинами на вход - AuthMe, LoginSecurity и подобными. Каждый фейковый логин может триггерить SQL запросы, проверки и другую логику.

Invalid Packet Length

Атакующий отправляет пакет, в заголовке которого указана одна длина, а фактически данных другое количество. Или длина указана отрицательная. Или длина указана как VarInt максимальной величины.

Некоторые реализации серверов на таком крашатся. Vanilla и Paper в целом обрабатывают это нормально, но плагины, которые парсят пакеты самостоятельно, могут упасть с OutOfMemoryError если попытаются аллоцировать буфер по указанной в пакете длине.

Protocol Manipulation

Самый изощрённый тип. Бот отправляет пакеты в неправильном порядке, использует несуществующие packet ID, или отправляет пакеты для другого состояния протокола (например, Play-пакеты во время Handshake).

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

BungeeCord: главная головная боль

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

IPForward Spoofing

Когда в BungeeCord включен ip_forwarding, он передаёт IP игрока backend-серверу через специальное поле в Handshake пакете. Проблема в том, что этот механизм не имеет никакой аутентификации. Вообще никакой.

Это значит, что если кто-то подключится напрямую к вашему backend-серверу (Spigot/Paper) и подделает Handshake пакет, он сможет войти с любым IP-адресом. А если на сервере привязка по IP, он сможет войти под любым аккаунтом.

Прямой доступ к Backend

Самая распространённая ошибка - оставить порты backend-серверов открытыми. Если ваши Spigot/Paper серверы доступны извне, атакующий может подключиться напрямую, минуя BungeeCord. При включенном bungeecord: true в spigot.yml такой сервер будет доверять любому Handshake пакету.

Я регулярно вижу серверы, где backend работает на публичном IP с открытым портом. Это как оставить заднюю дверь нараспашку.

Handshake Manipulation

BungeeCord при пересылке игрока добавляет в Handshake пакет дополнительные данные: IP игрока, UUID и данные профиля. Атакующий может сформировать пакет с произвольными данными в этих полях.

Через это можно подделать UUID игрока и войти под чужим аккаунтом со всеми правами. Для серверов в offline-mode это вообще тривиальная атака, но даже online-mode серверы уязвимы, если backend принимает UUID из Handshake без проверки.

UUID Spoofing

Расширение предыдущей атаки. BungeeCord передаёт UUID игрока backend-серверу. Если злоумышленник может подключиться к backend напрямую, он отправляет Handshake с UUID администратора и получает полные права.

На серверах с LuckPerms или подобными системами привилегий это мгновенный полный доступ. Я знаю случаи, когда через это крали донат-данные, предметы и даже доступ к консоли через плагины типа ServerUtils.

Velocity vs BungeeCord: сравнение безопасности

Velocity изначально проектировался с учётом ошибок BungeeCord. Разница существенная.

BungeeCord:

• IPForward без аутентификации
• Нет встроенной защиты backend-серверов
• Обработка пакетов часто блокирует основной поток
• Плагин BungeeGuard нужен как костыль для базовой безопасности
• Уязвимости в парсинге пакетов находят регулярно

Velocity:

• Modern forwarding с секретным ключом (HMAC)
• Backend принимает подключения только с валидной подписью
• Более строгий парсинг протокола
• Лучшая изоляция между соединениями
• Активная разработка и быстрые фиксы

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

Как защитить BungeeCord

Закройте порты backend-серверов

Это первый и самый важный шаг. Backend-серверы должны быть доступны только с IP-адреса BungeeCord.

Через iptables:

iptables -A INPUT -p tcp --dport 25565 -s BUNGEE_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 25565 -j DROP

Если BungeeCord и backend на одной машине, привяжите backend к localhost в server.properties:

server-ip=127.0.0.1

Установите BungeeGuard

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

Установка:

1. Плагин на BungeeCord - он добавляет токен в Handshake
2. Плагин на каждый backend-сервер - он проверяет токен
3. Сгенерированный токен должен совпадать

Настройте IPForward правильно

В config.yml BungeeCord:

ip_forward: true

В spigot.yml на backend:

settings:
  bungeecord: true

Но помните, что без BungeeGuard или файрвола это бесполезно. IPForward без защиты - это просто дыра.

Как защитить Velocity

Modern Forwarding

В velocity.toml:

player-info-forwarding-mode = "modern"

Velocity сгенерирует файл forwarding.secret. Этот же секрет нужно указать в настройках backend-сервера.

Для Paper в config/paper-global.yml:

proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: "скопируйте секрет из forwarding.secret"

Modern forwarding использует HMAC для подписи данных. Подделать это без знания секрета невозможно.

Дополнительные меры

В velocity.toml также стоит настроить:

show-max-players = 500
online-mode = true
force-key-authentication = true

force-key-authentication требует от клиентов подпись ключом Mojang, что отсекает большинство ботов.

Как распознать атаки в логах

Признаки null-атаки

В логах Paper/Spigot ищите:

[WARNING] Exception caught: io.netty.handler.codec.DecoderException
[WARNING] Disconnecting: Internal Exception
[INFO] [/1.2.3.4:12345] <-> InitialHandler - disconnect

Массовые DecoderException - почти гарантия null-атаки. Если видите сотни таких строк в секунду, ваш сервер под атакой.

Признаки BungeeCord эксплойта

[INFO] UUID of player Admin is 00000000-0000-0000-0000-000000000000
[WARNING] Player connected with invalid handshake data

Если игрок с ником администратора заходит с нулевым UUID или незнакомого IP, это попытка спуфинга.

Мониторинг

Настройте алерты на аномальное количество подключений. Нормальный сервер на 100 игроков получает 5-15 новых подключений в минуту. Если вы видите 500+ в минуту, что-то не так.

Когда помогают анти-бот плагины, а когда нет

Анти-бот плагины типа BotSentry, Antibot, EpicGuard работают на уровне приложения. Они проверяют поведение после подключения - скорость перемещения, отправку пакетов, капчу.

Помогают при:

• Медленных бот-атаках (десятки подключений в секунду)
• Ботах, которые пытаются войти и играть
• Спаме в чат через фейковых игроков

Не помогают при:

• Null-атаках на уровне протокола - пакет крашит обработку до того, как плагин его увидит
• Массовых подключениях (тысячи в секунду) - сервер не успевает обработать
• Атаках на Handshake/Login фазу - анти-бот плагины работают после входа

Для null-атак и protocol-level флуда нужна фильтрация до того, как пакет дойдёт до Java-сервера. Это работа для прокси-уровня или сетевого фильтра. MineGuard фильтрует такие пакеты на уровне сети ещё до того, как они попадают на ваш сервер, отсекая невалидные подключения без нагрузки на игровой процесс.

Рекомендации по плагинам

BungeeGuard

Обязателен, если используете BungeeCord. Добавляет аутентификацию между прокси и backend. Бесплатный, легковесный, без конфигурации (кроме токена).

TCPShield Plugin

Если используете TCPShield как защиту, их плагин корректно извлекает реальный IP из Proxy Protocol. Без него все игроки будут видны с IP прокси TCPShield.

EpicGuard

Один из лучших анти-ботов. Проверяет GeoIP, скорость подключений, DNSBL. Хорошо справляется с медленными бот-атаками. Не спасёт от protocol-level атак, но как дополнительный слой защиты - отличный вариант.

Geyser + Floodgate

Если поддерживаете Bedrock-клиентов, правильная настройка Floodgate предотвращает спуфинг Bedrock-аккаунтов. Неправильная - создаёт ещё одну дыру.

Почему Proxy Protocol лучше IPForward

IPForward в BungeeCord передаёт IP через модифицированный Handshake пакет. Это нестандартное решение, привязанное к экосистеме Minecraft. Proxy Protocol (HAProxy Protocol) - это индустриальный стандарт.

Преимущества Proxy Protocol:

• Стандартизирован, поддерживается множеством систем
• Работает на транспортном уровне, до парсинга Minecraft протокола
• Сложнее подделать, так как он обрабатывается до передачи данных приложению
• Совместим с любыми внешними системами защиты

Как включить:

В Velocity (velocity.toml):

haproxy-protocol = true

На backend необходим плагин для приёма Proxy Protocol (например, HAProxyDetector или встроенная поддержка в Paper).

MineGuard поддерживает Proxy Protocol из коробки, что позволяет корректно передавать реальные IP-адреса игроков на ваш сервер без IPForward и связанных с ним уязвимостей.

Чеклист безопасности

Быстрая проверка для вашего сервера:

• Backend-порты закрыты файрволом для внешних подключений
• BungeeGuard или modern forwarding настроен и работает
• online-mode включен на прокси
• Логи мониторятся на аномальные подключения
• IPForward не используется без дополнительной защиты
• На backend серверах server-ip привязан к localhost или внутреннему IP
• Установлен анти-бот плагин как дополнительный слой
• Proxy Protocol настроен, если используется внешняя защита

Если хоть один пункт не выполнен, ваш сервер уязвим. Null-атаки и BungeeCord эксплойты - это не теоретическая угроза, это то, с чем сталкивается каждый сервер с 50+ онлайном. Позаботьтесь о защите до того, как это станет проблемой.