TCP vs UDP атаки на Minecraft: отличия и защита

Каждый раз, когда игрок подключается к Minecraft серверу, данные передаются по одному из двух транспортных протоколов: TCP или UDP. Java Edition использует TCP. Bedrock Edition использует UDP. Это не просто техническая деталь. Это определяет, какие атаки возможны, насколько они опасны и как от них защищаться.

В этой статье разберём оба протокола с точки зрения DDoS-атак. Без абстрактной теории, с реальными цифрами и конкретными рекомендациями.

TCP и UDP: базовые отличия за 2 минуты

Если вы уже знаете разницу между TCP и UDP, пропустите этот раздел. Для остальных вот суть.

TCP (Transmission Control Protocol) устанавливает соединение перед передачей данных. Трёхстороннее рукопожатие: клиент отправляет SYN, сервер отвечает SYN-ACK, клиент подтверждает ACK. Только после этого начинается обмен данными. Каждый пакет нумеруется, доставка гарантируется, потерянные пакеты пересылаются.

UDP (User Datagram Protocol) не устанавливает соединений. Пакеты отправляются без подтверждения, без нумерации, без гарантии доставки. Отправил и забыл. Это делает UDP быстрее (меньше накладных расходов), но менее надёжным.

TCP (Minecraft Java):
Client  ──SYN──>     Server
Client  <─SYN-ACK──  Server
Client  ──ACK──>     Server
Client  <──DATA──>   Server   ← установленное соединение

UDP (Minecraft Bedrock):
Client  ──PKT──>  Server     ← просто отправляет
Client  ──PKT──>  Server     ← без подтверждения
Client  ──PKT──>  Server     ← без состояния

Minecraft Java Edition слушает на TCP порту 25565. Minecraft Bedrock Edition слушает на UDP порту 19132. Некоторые серверы включают Query протокол, который работает по UDP на порту 25565. Запомните это, оно будет важно позже.

TCP атаки: классика с предсказуемым почерком

TCP-атаки на Minecraft серверы хорошо изучены и, в целом, хорошо фильтруются. Но "хорошо фильтруются" не значит "безобидны". Вот основные типы.

SYN Flood

Самая распространённая TCP-атака. Атакующий отправляет огромное количество SYN-пакетов (первый шаг рукопожатия) с поддельными IP-адресами. Сервер на каждый SYN выделяет память для полуоткрытого соединения и отправляет SYN-ACK. Ответ уходит на поддельный IP, ACK никогда не приходит. Таблица полуоткрытых соединений заполняется, новые легитимные клиенты не могут подключиться.

Для Minecraft серверов SYN flood особенно опасен, потому что Java серверы часто работают с ограниченным backlog (очередь ожидающих соединений). По умолчанию в Linux net.core.somaxconn равен 4096. При атаке в 100,000 SYN/s эта очередь забивается за доли секунды.

Типичные объёмы: от 1 до 50 Gbps. Мы видели атаки на Minecraft серверы с пиком в 30 Gbps чистого SYN flood. Подробнее о SYN flood атаках можно почитать в нашей отдельной статье.

ACK Flood

Атакующий отправляет массу TCP-пакетов с установленным ACK-флагом. Сервер получает ACK для соединений, которых не существует, и тратит ресурсы на поиск в таблице соединений. Если сервер использует conntrack (а он почти наверняка использует), каждый такой пакет вызывает lookup в хеш-таблице conntrack.

ACK flood менее эффективен, чем SYN flood, потому что пакеты без существующего соединения быстро отбрасываются. Но при достаточном объёме (10+ Gbps) нагрузка на обработку пакетов может стать проблемой.

RST Flood

Поток TCP-пакетов с флагом RST (reset). Цель: сбросить существующие соединения игроков. Если атакующий угадает sequence number активного соединения, он может принудительно разорвать его. На практике угадать sequence number сложно, поэтому RST flood обычно работает как объёмная атака, перегружая канал.

Slowloris

Изящная атака, которая не требует больших объёмов трафика. Атакующий открывает множество TCP-соединений с сервером и отправляет HTTP-заголовки (или в случае Minecraft, начальные пакеты хендшейка) очень медленно, по одному байту каждые 10-30 секунд. Сервер держит эти соединения открытыми, ожидая завершения, и в итоге исчерпывает лимит одновременных подключений.

Для Minecraft серверов Slowloris выглядит так: сотни подключений начинают хендшейк, но никогда не завершают его. Каждое такое подключение занимает слот. Когда слоты заканчиваются, реальные игроки не могут зайти.

Почему TCP-атаки проще фильтровать

TCP-атаки предсказуемы, потому что TCP по своей природе имеет состояние. У каждого соединения есть чёткий жизненный цикл: SYN, SYN-ACK, ACK, DATA, FIN. Файрвол может отслеживать это состояние и отбрасывать пакеты, которые не вписываются в ожидаемую последовательность.

SYN cookies решают проблему SYN flood почти полностью. Вместо того чтобы выделять память на каждый SYN, сервер кодирует информацию о соединении в sequence number SYN-ACK. Память выделяется только когда приходит валидный ACK с правильным sequence number. Это значит, что SYN flood с поддельными IP не занимает ни байта памяти.

Conntrack (connection tracking) позволяет отслеживать состояние каждого TCP-соединения. Пакет ACK для несуществующего соединения? Отбросить. RST с неправильным sequence number? Отбросить. Это дёшево и эффективно.

# Пример: включение SYN cookies в Linux
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# Увеличение backlog для Minecraft сервера
echo 65535 > /proc/sys/net/core/somaxconn

# Ограничение полуоткрытых соединений
echo 2048 > /proc/sys/net/ipv4/tcp_max_syn_backlog

UDP атаки: другой зверь

UDP-атаки на Minecraft серверы работают принципиально иначе. Здесь нет состояния, нет рукопожатия, нет порядка пакетов. И это создаёт огромные проблемы для защиты.

UDP Flood

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

Для Bedrock-серверов это критично: каждый входящий UDP-пакет на порт 19132 попадает в RakNet (сетевая библиотека Bedrock), который тратит ресурсы на попытку его распарсить.

Объёмы UDP flood могут быть колоссальными. Поскольку пакеты генерируются без ожидания ответа, один сервер атакующего может отправлять гигабиты мусорного трафика в секунду. Ботнет из нескольких тысяч узлов легко генерирует 100+ Gbps чистого UDP flood. И каждый пакет приходится обработать хотя бы минимально, прежде чем понять, что он мусорный.

Отдельная проблема: UDP flood на случайные порты. Если атакующий отправляет пакеты не на 19132, а на случайные порты, сервер на каждый такой пакет генерирует ICMP Port Unreachable. Это создаёт дополнительную нагрузку на CPU и может забить исходящий канал ICMP-ответами. Решение: ограничить rate ICMP через sysctl или iptables.

# Ограничение ICMP Port Unreachable
sysctl -w net.ipv4.icmp_ratelimit=100
iptables -A OUTPUT -p icmp --icmp-type port-unreachable -j DROP

Amplification атаки: где 1 байт превращается в 50

Вот здесь UDP становится по-настоящему опасным. Amplification (амплификация) использует легитимные сервисы в интернете как усилители трафика. Принцип простой:

Атакующий отправляет маленький запрос на открытый сервис (DNS, NTP, memcached)
В поле отправителя подставляет IP жертвы (spoofing)
Сервис отвечает объёмным ответом на IP жертвы
Жертва получает трафик в десятки и сотни раз больше того, что отправил атакующий

Фактор амплификации у разных протоколов:

Протокол	Фактор амплификации	Типичный объём атаки
DNS	28-54x	10-100 Gbps
NTP (monlist)	556x	50-400 Gbps
Memcached	10,000-51,000x	100-1,700 Gbps
SSDP	30x	5-50 Gbps
CLDAP	56-70x	10-100 Gbps
Chargen	358x	5-50 Gbps

Да, вы прочитали правильно. Memcached может усилить трафик в 51,000 раз. Атакующий отправляет 1 MB данных, жертва получает 51 GB. На практике таких объёмов добиться сложнее (не так много открытых memcached серверов), но 1-5 Tbps атаки через memcached были зафиксированы.

В контексте Minecraft: если ваш Bedrock-сервер сидит на IP без защиты, атака через NTP amplification с фактором 556x может сгенерировать 100+ Gbps трафика. Канал любого хостинга забьётся мгновенно.

Query Flood: атака через встроенную функцию

Minecraft Query протокол работает по UDP, обычно на порту 25565 (том же, что и Java Edition). Он возвращает информацию о сервере: количество игроков, MOTD, список плагинов, версию. Один запрос Query занимает около 9 байт. Ответ от 200 до 2000+ байт, в зависимости от количества плагинов и игроков.

Это даёт фактор амплификации от 20x до 200x. И всё это средствами самого Minecraft, без эксплуатации внешних сервисов.

# Запрос Query протокола (9 байт)
\xFE\xFD\x09\x00\x00\x00\x00

# Ответ (200-2000+ байт)
Server: MyServer
Plugins: WorldEdit, EssentialsX, LuckPerms...
Players: 50/100
...

Хуже того, многие Minecraft серверы включают Full Query, который возвращает полный список плагинов и игроков. На сервере с 50 плагинами и 100 игроками ответ Full Query может быть 3-4 KB. Фактор амплификации: 400x+.

Решение простое: отключите Query, если он вам не нужен.

# server.properties
enable-query=false

Если вам нужна информация о сервере для мониторинга, используйте Server List Ping (TCP) или RCON (с аутентификацией), а не Query.

Почему UDP сложнее фильтровать

С TCP файрвол может посмотреть на пакет и спросить: "Этот пакет принадлежит установленному соединению?" Если нет, отбросить. С UDP такого вопроса задать нельзя, потому что соединений не существует. Каждый пакет самостоятелен. Легитимный пакет от игрока Bedrock Edition выглядит точно так же, как атакующий пакет. Оба просто UDP-датаграммы на порт 19132.

Файрвол не может отличить первый пакет от нового игрока Bedrock от первого пакета в DDoS-атаке. У него нет состояния, на которое можно опереться.

Что остаётся:

Rate limiting по IP: ограничить количество пакетов в секунду с одного IP. Работает против атак с реальных IP, бесполезно против spoofed IP.
Payload inspection (DPI): анализировать содержимое UDP-пакетов. Легитимные пакеты RakNet имеют определённую структуру. Атакующие пакеты часто случайные байты. Но это дорогая операция.
Геофильтрация: отбрасывать пакеты из регионов, откуда нет игроков. Грубый метод, но эффективный.
Behavioral analysis: анализировать паттерны трафика. 10,000 UDP-пакетов в секунду с одного IP на один порт - не игрок.

# iptables: rate limiting UDP на порт Bedrock
iptables -A INPUT -p udp --dport 19132 \
  -m hashlimit \
  --hashlimit-above 100/sec \
  --hashlimit-burst 200 \
  --hashlimit-mode srcip \
  --hashlimit-name bedrock_limit \
  -j DROP

Сравнение: TCP vs UDP атаки в цифрах

Давайте сведём всё в таблицу.

Параметр	TCP атаки	UDP атаки
Minecraft Edition	Java (порт 25565)	Bedrock (порт 19132)
Типичный объём	5-50 Gbps	50-500+ Gbps
Максимальный зафиксированный	~300 Gbps	~3.5 Tbps
Амплификация	Невозможна	До 51,000x
Spoofing IP	Сложно (нужен ACK)	Тривиально
Stateful фильтрация	Эффективна	Невозможна
SYN cookies	Да	Неприменимо
Connection tracking	Да	Ограниченно
Стоимость атаки	$$$	$
Стоимость защиты	$	$$$

Обратите внимание на стоимость. TCP-атака требует реальных ресурсов: нужны серверы, которые будут завершать рукопожатия или генерировать большие объёмы пакетов. UDP-атака с амплификацией стоит почти ничего: пара скриптов, список открытых resolvers, готово.

По данным за 2026 год, UDP-атаки на Minecraft серверы составляют около 70% от общего числа DDoS-инцидентов. TCP-атаки остаются актуальными, но смещаются в сторону application-level: имитация Minecraft хендшейка, login flood, bot join.

Реальный сценарий: гибридная атака

Разберём типичный сценарий атаки на сервер, который поддерживает и Java, и Bedrock. Атакующий действует в несколько фаз.

Фаза 1: разведка. Атакующий сканирует порты сервера. Находит TCP 25565 (Java), UDP 19132 (Bedrock), UDP 25565 (Query включён). Через Query получает список плагинов и версию сервера.

Фаза 2: UDP amplification. Запускается DNS amplification на IP сервера. 5 Gbps исходящего трафика превращаются в 150 Gbps входящего. Канал сервера забит. Все игроки, и Java, и Bedrock, отключаются. Сервер теряет связь с мониторингом.

Фаза 3: SYN flood. Параллельно с UDP-атакой запускается SYN flood на порт 25565. Даже если upstream-провайдер отфильтрует часть UDP amplification, SYN flood создаёт нагрузку на conntrack и backlog. Сервер не может принимать новые TCP-соединения.

Фаза 4: bot join. После ослабления первых двух волн атакующий отправляет ботов, которые проходят TCP handshake, отправляют валидный Minecraft login и заходят на сервер. Слоты заполняются ботами, реальные игроки попадают в очередь.

Это не теория. Такие многоуровневые атаки стали стандартом в 2025-2026 годах. Защита должна работать на всех уровнях одновременно.

Разные протоколы, разные стратегии защиты

Защита Java-сервера (TCP) и Bedrock-сервера (UDP) требует разных подходов. Нельзя применить одну и ту же логику к обоим.

Защита Java Edition (TCP)

Для TCP у нас есть мощные инструменты на уровне ядра ОС:

SYN cookies - решают SYN flood без дополнительного ПО
Connection tracking (conntrack) - отслеживание состояния соединений
TCP handshake verification - проверка завершения рукопожатия перед пропуском к серверу
Application-level проверки - после установки TCP-соединения можно проверить Minecraft handshake на валидность

Слоёная защита для Java:

Уровень 1: XDP/eBPF - отброс мусорных пакетов до ядра
Уровень 2: SYN cookies - защита от SYN flood
Уровень 3: Conntrack - фильтрация по состоянию
Уровень 4: Application proxy - проверка Minecraft протокола
Уровень 5: Captcha/challenge - верификация игроков

Защита Bedrock Edition (UDP)

Для UDP мы теряем слои 2 и 3 из схемы выше. Нет SYN cookies, нет stateful conntrack. Нужно компенсировать другими методами:

Rate limiting на уровне XDP - отбрасывание пакетов выше порога до ядра
RakNet payload validation - проверка структуры пакетов Bedrock
Cookie-based verification - собственная реализация challenge-response поверх UDP
GeoIP filtering - ограничение по географии
Upstream filtering - фильтрация на уровне провайдера (BGP Flowspec)

Уровень 1: Upstream BGP Flowspec - блокировка amplification
Уровень 2: XDP/eBPF - rate limiting + payload validation
Уровень 3: Application proxy - RakNet protocol verification
Уровень 4: Behavioral analysis - паттерны трафика

Для владельцев серверов, использующих оба издания (Java и Bedrock), критически важно понимать, что одного решения для обоих протоколов не существует. Сервис защиты должен иметь отдельные модули для TCP и UDP трафика. MineGuard, например, обрабатывает Java и Bedrock трафик разными пайплайнами, каждый со своим набором правил и алгоритмов.

Minecraft Query: скрытая угроза

Отдельно стоит поговорить о Query протоколе. Многие администраторы забывают о нём, а зря.

Query работает по UDP на том же порту, что и Java Edition (25565 по умолчанию). Он включён по умолчанию во многих конфигурациях хостингов. Даже если у вас только Java Edition и вы думаете, что UDP вас не касается, Query создаёт UDP-поверхность атаки.

Три проблемы с Query:

Амплификация - маленький запрос, большой ответ. Ваш сервер может быть использован как усилитель для атаки на других.
Information disclosure - Query возвращает версию сервера, список плагинов (включая версии), IP-адреса игроков при Full Query. Это разведка перед настоящей атакой.
Resource consumption - каждый Query-запрос обрабатывается основным потоком сервера. Поток Query-запросов может вызвать TPS-дропы.

# Отключите Query в server.properties
enable-query=false

# Если Query нужен для мониторинга, ограничьте доступ через iptables
iptables -A INPUT -p udp --dport 25565 \
  -s 10.0.0.0/8 -j ACCEPT          # только из внутренней сети
iptables -A INPUT -p udp --dport 25565 -j DROP

Практические рекомендации: что сделать прямо сейчас

Независимо от того, какой у вас сервер, вот чеклист:

Для всех серверов

Отключите Query (enable-query=false)
Закройте все неиспользуемые порты (особенно UDP)
Включите файрвол и настройте whitelist портов
Не выставляйте RCON в интернет (используйте только через localhost или VPN)
Спрячьте реальный IP сервера за DDoS-защитой

Дополнительно для Java Edition (TCP)

# SYN cookies
sysctl -w net.ipv4.tcp_syncookies=1

# Увеличьте backlog
sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.tcp_max_syn_backlog=65535

# TCP timestamps (нужны для SYN cookies)
sysctl -w net.ipv4.tcp_timestamps=1

# Ограничьте retry для SYN-ACK
sysctl -w net.ipv4.tcp_synack_retries=2

Дополнительно для Bedrock Edition (UDP)

# Увеличьте буфер приёма UDP
sysctl -w net.core.rmem_max=26214400
sysctl -w net.core.rmem_default=1048576

# Rate limiting через iptables
iptables -A INPUT -p udp --dport 19132 \
  -m hashlimit \
  --hashlimit-above 50/sec \
  --hashlimit-burst 100 \
  --hashlimit-mode srcip \
  --hashlimit-name bedrock \
  -j DROP

# Закройте UDP порт 25565 если Query отключён
iptables -A INPUT -p udp --dport 25565 -j DROP

Ошибки, которые делают администраторы

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

Ошибка 1: открытые порты. На сервере открыто всё подряд: 25565 TCP и UDP, 19132, RCON на 25575, SSH на стандартном 22, иногда даже MySQL на 3306. Каждый открытый порт - это вектор атаки. Закройте всё, что не используется.

Ошибка 2: Query включён. Повторюсь, потому что это важно. Query по умолчанию включён во многих сборках. Он не нужен для работы сервера. Он нужен только для мониторинга, и даже для этого есть лучшие альтернативы.

Ошибка 3: реальный IP сервера в DNS. Если IP вашего сервера известен атакующему, он может бить напрямую, минуя любую облачную защиту. Используйте DDoS-защиту с проксированием и никогда не светите реальный IP.

Ошибка 4: нет rate limiting. Без ограничения скорости подключений один IP может отправлять тысячи запросов в секунду. Даже базовый hashlimit в iptables значительно снижает эффективность атак.

Ошибка 5: игнорирование sysctl. Дефолтные параметры Linux не рассчитаны на работу под нагрузкой. SYN cookies отключены, backlog маленький, буферы UDP минимальные. Пять минут настройки sysctl могут спасти от часа даунтайма.

Что ждёт в будущем

Тренды DDoS-атак на Minecraft серверы в 2026 году показывают смещение в сторону гибридных атак. Атакующие комбинируют TCP и UDP атаки одновременно: SYN flood забивает CPU обработкой полуоткрытых соединений, а UDP amplification забивает канал. Защита, настроенная только на один протокол, пропускает второй.

Растёт количество application-level атак: боты, имитирующие настоящих игроков, проходят TCP handshake, отправляют валидный Minecraft login и даже решают простые captcha. Это уже не про объём трафика, а про качество имитации.

На стороне защиты развиваются XDP/eBPF-решения, которые позволяют фильтровать пакеты до ядра ОС, обрабатывая миллионы пакетов в секунду на одном ядре CPU. Для UDP это особенно важно, потому что позволяет реализовать быстрый payload inspection без нагрузки на основной стек.

Итог

TCP и UDP атаки на Minecraft серверы - это два разных мира. TCP-атаки (SYN flood, ACK flood, Slowloris) опасны, но хорошо изучены и эффективно фильтруются через SYN cookies, conntrack и stateful inspection. UDP-атаки (flood, amplification, Query abuse) сложнее и опаснее: больше объёмы, проще spoofing, труднее фильтрация.

Если у вас Java Edition, убедитесь что SYN cookies включены и Query отключён. Если Bedrock, позаботьтесь о rate limiting и upstream фильтрации. Если оба, используйте защиту, которая понимает разницу между протоколами и фильтрует каждый своим набором правил.

Универсальной кнопки "защитить от всего" не существует. Но понимание того, как работают атаки на каждый протокол, это первый шаг к построению реальной защиты.

TCP vs UDP атаки на Minecraft серверы: разбор отличий