SYN-флуд: самая частая DDoS-атака на Minecraft серверы

Каждый владелец Minecraft сервера рано или поздно сталкивается с DDoS-атаками. И в большинстве случаев первое, что прилетает - это SYN-флуд. Не потому что это самая сложная атака. Наоборот, потому что это самая простая и до сих пор эффективная техника, которая может положить незащищённый сервер за секунды.

Чтобы понять, как работает SYN-флуд, нужно сначала разобраться с тем, как вообще устанавливается TCP-соединение. Minecraft работает поверх TCP (Bedrock Edition использует UDP, но Java Edition - это чистый TCP), поэтому каждое подключение игрока проходит через этот процесс.

Как работает TCP three-way handshake

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

Шаг 1: SYN. Клиент отправляет серверу пакет с флагом SYN (synchronize). Этот пакет говорит: "Привет, я хочу установить соединение. Вот мой начальный sequence number."

Шаг 2: SYN-ACK. Сервер получает SYN, выделяет ресурсы для нового соединения (создаёт запись в SYN backlog), и отправляет обратно пакет SYN-ACK. Это означает: "Я тебя услышал, вот мой sequence number, подтверди."

Шаг 3: ACK. Клиент отправляет финальный ACK. Соединение установлено. Теперь можно передавать данные, и Minecraft начинает процесс login.

Весь процесс занимает обычно менее 100 миллисекунд. Но есть критический момент: между шагом 2 и шагом 3 сервер держит соединение в состоянии "полуоткрытое" (half-open). Он уже потратил ресурсы, но ещё не получил подтверждение. Именно это и эксплуатирует SYN-флуд.

Как SYN-флуд ломает сервер

Идея атаки элементарна. Атакующий отправляет тысячи (или миллионы) SYN-пакетов на порт вашего сервера. Каждый пакет приходит с поддельным IP-адресом (IP spoofing). Сервер на каждый SYN честно отвечает SYN-ACK и создаёт запись в backlog. Но SYN-ACK уходит на поддельный адрес, откуда ACK никогда не придёт.

В результате происходит следующее:

1. SYN backlog заполняется полуоткрытыми соединениями
2. Каждое полуоткрытое соединение висит в памяти, ожидая ACK (по умолчанию 75 секунд в Linux)
3. Когда backlog заполнен, сервер перестаёт принимать новые соединения
4. Реальные игроки получают "Connection timed out" или "Can't connect to server"

Стандартный размер SYN backlog в Linux - 128 или 256 записей. Даже с увеличенным backlog на 1024 записи, при скорости атаки 50 000 SYN-пакетов в секунду backlog заполняется мгновенно. При этом сама атака может генерироваться с одного арендованного сервера - для SYN-флуда не нужен ботнет.

Отдельная проблема - потребление ресурсов ядра. Каждая запись в SYN backlog занимает порядка 300-400 байт в памяти ядра. Казалось бы, немного. Но при 65535 записях это уже ~25 МБ только на очередь. Плюс ядро тратит CPU на обработку каждого входящего SYN, генерацию SYN-ACK, планирование ретрансляций. На сервере, где Java-процесс Minecraft уже потребляет большую часть ресурсов, эта дополнительная нагрузка может стать критической. softirq (обработка прерываний от сетевых пакетов) начинает забирать ядра CPU, которые нужны серверу для обработки тиков.

Почему Minecraft серверы особенно уязвимы

Minecraft сервер имеет несколько особенностей, которые делают его идеальной мишенью для SYN-флуда.

Один порт. Весь трафик идёт на один TCP-порт (обычно 25565). Атакующему не нужно распылять усилия, достаточно залить один порт.

TCP-протокол. В отличие от игр на UDP (Bedrock, CS2, Valorant), Java Edition использует TCP. Это значит, что каждое подключение требует полного хендшейка, и каждый SYN-пакет потребляет ресурсы сервера.

Публичный адрес. Большинство Minecraft серверов публикуют свой IP в списках серверов, на форумах, в Discord. Атакующий всегда знает куда бить.

Ограниченные ресурсы. Типичный Minecraft сервер работает на VPS или выделенном сервере с ограниченными сетевыми ресурсами. Даже если канал 1 Гбит/с, SYN-флуд в 500 Мбит/с уже создаст серьёзные проблемы.

Нет встроенной защиты. Ни Vanilla, ни Paper, ни Velocity не имеют встроенных механизмов защиты от SYN-флуда. Это задача уровня ОС и сети, а не приложения.

Предсказуемый порт. По умолчанию Minecraft слушает на 25565. Даже если вы измените порт, атакующий найдёт его простым сканированием. А SRV-записи DNS раскрывают порт любому желающему. В отличие от веб-серверов, где трафик может распределяться между множеством портов и сервисов, у Minecraft одна точка входа.

Длинные сессии. Minecraft-игроки держат соединения часами. Это значит, что connection tracking таблица и так загружена реальными соединениями. SYN-флуд добавляет к этому тысячи фейковых записей, и conntrack таблица может переполниться, начав дропать уже установленные соединения реальных игроков.

Как распознать SYN-флуд

Прежде чем бороться с атакой, нужно её диагностировать. Вот конкретные команды.

Проверка состояния соединений через ss

ss -s

Эта команда покажет общую статистику по сокетам. Если видите аномально высокое количество synrecv - это SYN-флуд.

ss -tnp state syn-recv | wc -l

Показывает количество соединений в состоянии SYN_RECV. Нормальное значение для Minecraft сервера с 200 игроками - 0-5. Если видите сотни или тысячи, вас атакуют.

Анализ через netstat

netstat -n | awk '/^tcp/ {print $6}' | sort | uniq -c | sort -rn

Эта команда группирует TCP-соединения по состояниям. При SYN-флуде вы увидите что-то вроде:

  4891 SYN_RECV
    47 ESTABLISHED
    12 TIME_WAIT
     3 CLOSE_WAIT

Тысячи SYN_RECV при десятках ESTABLISHED - верный признак атаки.

Мониторинг через tcpdump

tcpdump -i eth0 -n 'tcp[tcpflags] & tcp-syn != 0' -c 100

Покажет SYN-пакеты в реальном времени. При SYN-флуде вы увидите поток пакетов с разных (поддельных) IP-адресов. Обратите внимание на TTL - если он одинаковый у пакетов с разных "IP", значит пакеты на самом деле идут из одного источника.

Скорость входящих SYN-пакетов

watch -n 1 'ss -s | grep synrecv'

Мониторинг в реальном времени. Если SYN_RECV растёт на тысячи в секунду, это активная атака.

Анализ IP-адресов

ss -tn state syn-recv | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

Покажет топ-20 IP-адресов с SYN_RECV соединениями. При SYN-флуде с IP spoofing вы увидите равномерное распределение по тысячам адресов. Если атака без спуфинга - увидите несколько IP с тысячами соединений каждый.

Защита на уровне ядра Linux

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

SYN Cookies

sysctl -w net.ipv4.tcp_syncookies=1

SYN cookies - это механизм, при котором сервер не хранит состояние полуоткрытого соединения. Вместо этого он кодирует информацию о соединении прямо в sequence number SYN-ACK пакета. Когда приходит ACK, сервер восстанавливает информацию из sequence number.

Плюсы: backlog не заполняется, сервер продолжает принимать соединения. Минусы: некоторые TCP-опции (window scaling, timestamps) не работают, что может увеличить латентность. Для Minecraft это обычно не критично.

# Сделать постоянным
echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf
sysctl -p

Увеличение SYN backlog

sysctl -w net.ipv4.tcp_max_syn_backlog=65535
sysctl -w net.core.somaxconn=65535

Увеличиваем размер очереди полуоткрытых соединений. Это не решает проблему, но при включённых syncookies даёт дополнительный запас.

Уменьшение SYN-ACK retries

sysctl -w net.ipv4.tcp_synack_retries=2

По умолчанию Linux отправляет SYN-ACK повторно 5 раз, ожидая ACK. Каждая ретрансляция увеличивает время жизни полуоткрытого соединения. Уменьшаем до 2 - если ACK не пришёл за два раза, соединение сбрасывается.

Включение TCP timestamps

sysctl -w net.ipv4.tcp_timestamps=1

TCP timestamps необходимы для корректной работы SYN cookies и помогают ядру более эффективно отслеживать соединения.

Полный набор sysctl для защиты

# /etc/sysctl.conf - SYN flood mitigation
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 65535
net.core.somaxconn = 65535
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
net.core.netdev_max_backlog = 65535
net.ipv4.ip_local_port_range = 1024 65535

Применяем:

sysctl -p

Защита через iptables

Второй уровень - фильтрация на уровне netfilter/iptables. Эти правила работают в userspace и не так быстры, как XDP, но для среднего сервера их достаточно.

Ограничение скорости SYN-пакетов

iptables -A INPUT -p tcp --syn -m limit --limit 100/s --limit-burst 200 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

Принимаем максимум 100 SYN-пакетов в секунду с burst до 200. Всё что сверху - дропаем. Для Minecraft сервера с 200-300 игроками 100 SYN/s более чем достаточно, потому что игроки подключаются не каждую секунду.

Блокировка невалидных TCP-пакетов

iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
iptables -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP
iptables -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP

Эти правила отсекают пакеты с невалидными комбинациями TCP-флагов. Нормальный TCP-стек никогда не генерирует пакет с одновременно установленными SYN и FIN. Такие пакеты - это или атака, или сканирование.

Ограничение новых подключений на IP

iptables -A INPUT -p tcp --dport 25565 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP

Не более 3 одновременных новых подключений с одного IP. Обычный игрок создаёт 1 соединение. Если с одного IP идёт 3+ SYN одновременно, это подозрительно.

Использование SYNPROXY

iptables -t raw -A PREROUTING -p tcp --dport 25565 --syn -j CT --notrack
iptables -A INPUT -p tcp --dport 25565 -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

SYNPROXY - это iptables target, который реализует SYN proxy прямо в ядре. Он отвечает на SYN-пакеты вместо приложения, и только после получения валидного ACK создаёт реальное соединение к серверу. Это одна из самых эффективных iptables-защит от SYN-флуда.

Почему защиты на уровне приложения недостаточно

Иногда владельцы серверов ставят "анти-DDoS" плагины на Paper или Velocity и думают, что защищены. Это опасное заблуждение.

Minecraft плагин работает на уровне приложения (Layer 7). Когда SYN-пакет прилетает на сервер, он проходит через сетевой стек ядра, TCP/IP стек, accept queue, и только потом попадает в Java. SYN-флуд убивает сервер на этапе TCP-стека, до того как Java вообще увидит пакет.

Плагин типа "Anti-Bot" защищает от ботов, которые уже установили TCP-соединение и пытаются логиниться в Minecraft. Это другой тип атаки (Layer 7 bot flood). Против SYN-флуда плагин бесполезен, потому что соединение до него не доходит.

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

Как профессиональная DDoS-защита обрабатывает SYN-флуд

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

Фильтрация на уровне XDP/eBPF

XDP (eXpress Data Path) обрабатывает пакеты до того, как они попадают в TCP-стек ядра. Это самый быстрый способ фильтрации - пакет дропается прямо на уровне сетевого драйвера. Для SYN-флуда в 10 Гбит/с это единственный вариант, который не загрузит CPU.

SYN Proxy на уровне фильтра

Фильтр принимает SYN от клиента, отвечает SYN-ACK с SYN cookie, и ждёт ACK. Если ACK приходит и cookie валидна, фильтр устанавливает новое соединение к бекенду и связывает их. Бекенд-сервер видит только завершённые, валидированные соединения. Весь мусор остаётся на фильтре.

Анализ паттернов

Профессиональные фильтры анализируют TTL, TCP window size, MSS и другие параметры SYN-пакетов. У реальных клиентов эти значения различаются в зависимости от ОС (Windows, macOS, Linux, Android). У инструментов для генерации SYN-флуда (hping3, scapy) значения обычно дефолтные или аномальные. Это позволяет фильтровать поддельные SYN ещё до проверки cookie.

Разница между SYN-флудом и другими типами флуда

SYN-флуд часто путают с другими типами TCP-атак. Разберём отличия.

UDP Flood

UDP - протокол без установки соединения. UDP-флуд просто заливает канал мусорными пакетами. Он не эксплуатирует хендшейк, а забивает полосу пропускания. Для Java Edition (TCP) UDP-флуд менее опасен, потому что UDP-пакеты на TCP-порт просто дропаются. Но они всё равно занимают канал.

Для Bedrock Edition (UDP) ситуация обратная - UDP-флуд создаёт прямую угрозу, а SYN-флуд не работает, потому что Bedrock не использует TCP.

ACK Flood

ACK-флуд отправляет пакеты с флагом ACK без предшествующего SYN. Для stateful firewall это легко определить и дропнуть, потому что нет соответствующей записи в connection tracking. Но для stateless серверов ACK-пакеты могут дойти до приложения и вызвать RST, создавая нагрузку.

RST Flood

RST-пакеты предназначены для принудительного разрыва соединения. Если атакующий угадает sequence number активного соединения, он может разорвать соединение между игроком и сервером. Это более таргетированная атака, и она сложнее в реализации, чем SYN-флуд.

TCP Connection Flood

Полноценный TCP-флуд: атакующий завершает хендшейк (SYN → SYN-ACK → ACK) и создаёт реальные соединения. Это обходит SYN cookies, но требует от атакующего использовать реальные IP (без спуфинга), что делает его уязвимым для блокировки.

Реальные сценарии и цифры

Для понимания масштаба проблемы, несколько реальных цифр.

Типичный SYN-флуд на Minecraft сервер - от 100 000 до 5 000 000 пакетов в секунду. По объёму это 50-200 Мбит/с, что не кажется много по сравнению с 100+ Гбит/с объёмными атаками. Но SYN-флуд - это не про объём, а про исчерпание ресурсов.

Незащищённый сервер с дефолтными настройками (backlog 128) падает при 1000 SYN/s. Сервер с тюнингом sysctl (backlog 65535, syncookies) выдерживает 50 000-100 000 SYN/s, но начинает терять пакеты и увеличивать латентность. Только аппаратная или XDP-фильтрация справляется с миллионами SYN/s.

На практике атакующие часто комбинируют SYN-флуд с другими техниками. Сначала идёт SYN-флуд для перегрузки сетевого стека, затем Layer 7 бот-атака с реальными подключениями. Первая волна отвлекает ресурсы, вторая добивает. Об этих комбинированных атаках мы подробно писали в статье про тренды DDoS-атак на Minecraft в 2026.

Сценарий: атака на сервер во время ивента

Типичная ситуация: вы анонсировали PvP-турнир, на сервере 300 игроков. В момент пиковой нагрузки начинается SYN-флуд. Сервер и так работает на пределе - 16 ГБ RAM, TPS балансирует на 19.5. SYN-флуд добавляет нагрузку на CPU через softirq, TPS проседает до 15, игроки начинают жаловаться на лаги. Потом backlog переполняется, новые игроки не могут зайти. Те, кто отключился и пытается переподключиться, тоже не могут. За 10 минут вы теряете половину аудитории.

Сценарий: SYN-флуд как разведка

Иногда SYN-флуд используется не для того, чтобы положить сервер, а для разведки. Атакующий отправляет умеренный поток SYN-пакетов (5000-10000/s) и наблюдает за реакцией. Если сервер начинает отвечать медленнее, он получает информацию о его ресурсах и защите. Потом приходит настоящая атака, уже с учётом обнаруженных слабостей. Мониторинг логов и алерты на аномальный рост SYN_RECV - способ заметить такую разведку.

Чек-лист: что делать если атакуют прямо сейчас

Если вы сейчас под SYN-флудом и нужно действовать быстро:

1. Диагностика (30 секунд):

ss -s | grep synrecv
ss -tn state syn-recv | wc -l

2. Экстренное включение syncookies:

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=65535
sysctl -w net.ipv4.tcp_synack_retries=1

3. Iptables rate limiting:

iptables -I INPUT -p tcp --dport 25565 --syn -m limit --limit 50/s --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --dport 25565 --syn -j DROP

4. Если атака продолжается - подключайте профессиональную DDoS-защиту. Подробный план действий при DDoS мы описали в гайде "Minecraft сервер под DDoS: что делать".

Как не путать SYN-флуд с другими проблемами

Не каждый timeout - это DDoS. Иногда сервер лагает по другим причинам, и важно их различать.

Если ss -s показывает нормальное количество SYN_RECV (менее 10), но игроки жалуются на лаги, проблема скорее всего в самом сервере: TPS-дропы, нехватка RAM, перегруженные чанки. У нас есть отдельная статья про диагностику лагов: DDoS или серверные проблемы.

Если SYN_RECV повышен, но не критически (20-50), возможно это не атака, а просто много игроков подключаются одновременно (после рестарта сервера, или событие на сервере). Проверьте, соответствуют ли IP в SYN_RECV реальным игрокам.

Ещё один частый кейс: хостинг-провайдер включает SYN flood protection на своей стороне, которая начинает дропать легитимные SYN-пакеты при небольшой нагрузке. Симптомы выглядят как DDoS, но на самом деле это чрезмерно агрессивная фильтрация. Проверяется отключением rate limit на стороне хостинга.

Автоматизация мониторинга

Ждать, пока игроки начнут жаловаться - плохая стратегия. Простой bash-скрипт может мониторить SYN_RECV и отправлять алерт:

#!/bin/bash
THRESHOLD=100
COUNT=$(ss -tn state syn-recv | wc -l)
if [ "$COUNT" -gt "$THRESHOLD" ]; then
    echo "SYN flood alert: $COUNT SYN_RECV connections" | \
    curl -X POST -d @- https://discord.com/api/webhooks/YOUR_WEBHOOK
fi

Запускайте через cron каждые 10 секунд. Когда SYN_RECV превышает порог, вы узнаёте об атаке мгновенно, а не через 5 минут, когда игроки начнут писать в Discord "сервер лагает".

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

nstat -z | grep -i syn

Обратите внимание на TcpExtTCPReqQFullDrop - это количество SYN-пакетов, дропнутых из-за переполнения backlog. Если этот счётчик растёт, backlog заполнен и реальные игроки не могут подключиться.

Выводы по существу

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

Для небольшого сервера (до 50 игроков) обычно хватает правильной настройки sysctl + базовых правил iptables. Для серверов побольше с реальной аудиторией профессиональная DDoS-защита - не роскошь, а необходимость. Разница между потерей всех игроков на 4 часа и фильтрацией атаки без единого дисконнекта, это разница между хобби и рабочим проектом.

Настройте sysctl, добавьте iptables-правила, держите под рукой команды диагностики. И помните: SYN-флуд - это только один тип атаки. Хорошая защита закрывает все векторы одновременно.