Защита Project-Zomboid-сервера от DDoS-атак

Кто хочет защитить свой Project-Zomboid-сервер от DDoS-атак, должен сначала понимать, по чему атакующий вообще бьёт. Выделенный сервер занимает ровно два UDP-порта, 16261 и 16262, и оба должны быть открыты в сети, иначе подключиться не сможет никто. Эта статья идёт в том порядке, который важен в критической ситуации: сначала то, что вы можете сделать сами в ближайшие десять минут и без дополнительных расходов, затем место, где эти меры технически заканчиваются, и в конце то, что должно происходить в сети перед сервером.

Все указания относятся к выделенному серверу (Steam-App 380870) под Debian 12, Debian 13, Ubuntu 22.04 LTS или Ubuntu 24.04 LTS, как для Build 41, так и для Build 42. Конфигурационный файл называется servertest.ini и лежит в ~/Zomboid/Server/, данные мира лежат в ~/Zomboid/Saves/Multiplayer/. Команды написаны для root, если вы работаете под обычным пользователем, добавляйте перед каждой командой sudo.

Если атака идёт прямо сейчас: ничего не меняйте сейчас в servertest.ini и не перезапускайте сервер. Сначала сохраните измерения (раздел 9), после атаки их уже не будет. Перезапуск дополнительно стоит того времени, которое сервер тратит на загрузку мира, и именно это время атакующий и хочет у вас отнять.

Почему Project-Zomboid-серверы становятся целью DDoS-атак

Project Zomboid — игра с окончательной смертью и миром, который продолжает жить месяцами. Обрыв соединения посреди опасной ситуации стоит здесь больше, чем почти в любом другом жанре: персонаж потерян, и мир об этом помнит. Именно это превращает сбой в оружие. Атака в восемь вечера задевает постоянное сообщество, и задевает его там, где ему есть что терять.

К этому добавляется то, что сама атака ничего не стоит и не требует умений. Заказные сервисы атак, в этой среде их называют booter или stresser, направляются несколькими щелчками на IP-адрес и порт, а в Project Zomboid цель всегда одна и та же: 16261 UDP. У того, кто в ссоре с забаненным игроком или держит конкурирующее сообщество, тем самым есть инструмент, для которого ему не нужны ни знания, ни заметные деньги.

К этому добавляется и то, что игровой сервер вынужден публиковать свой адрес. Если в servertest.ini стоит Public=true, сервер появляется в браузере игры, а сервер со Steam-привязкой и так виден в браузере серверов Steam. Поэтому вопрос никогда не в том, найдёт ли атакующий ваш IP-адрес, а только в том, что произойдёт, когда он по нему ударит.

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

Какие порты Project-Zomboid-серверу действительно нужны

Выделенному Project-Zomboid-серверу нужны ровно два открытых порта: 16261 UDP и 16262 UDP. Официальный список портов игры не называет третьего. В servertest.ini они стоят как две отдельные директивы, второй порт не выводится из первого автоматически:

DefaultPort=16261
UDPPort=16262
SteamPort1=8766
SteamPort2=8767
RCONPort=27015
RCONPassword=

Разделение задач однозначно. 16261 UDP несёт игровой трафик и установление соединения и отвечает на запросы браузера серверов. 16262 UDP — порт для прямого подключения клиентов. Нет первого, и сервер никто не найдёт, нет второго, и ваши игроки видят запись, но всё равно не попадают внутрь. Именно отсюда берётся самое известное сообщение об ошибке в этой игре, что порт 16262 закрыт.

Два момента, которые регулярно доставляют неприятности. Первое: каждому экземпляру сервера нужны два свободных UDP-порта. Кто держит второй мир на той же машине, выделяет для него вторую пару, например 16274 и 16275, и вписывает оба значения в servertest.ini второго экземпляра. Второе: SteamPort1 и SteamPort2 стоят в конфигурационном файле со значениями 8766 и 8767, но относятся к Steam-привязке, а не к игровому трафику. Открывайте их только тогда, когда без них ваш сервер не появляется в списке Steam, а не на всякий случай.

Что вы можете сделать сами, прежде чем тратить деньги

Этот раздел самый длинный, и так задумано. Аккуратно настроенный сервер выдерживает небольшие и средние атаки собственными силами, независимо от того, у кого он стоит. Объёмную атаку он с вас не снимет, но сделает так, что дешёвые атаки останутся без эффекта и что в критической ситуации у вас будут цифры, а не догадки.

1. Инвентаризация: что слушает на самом деле

Прежде чем написать хотя бы одно правило, посмотрите, что ваш сервер предлагает наружу. Не гадайте, а смотрите:

ss -lntup

Интерес представляет колонка с локальным адресом. 0.0.0.0:16261 и [::]:16261 означают «доступен из всего интернета», 127.0.0.1:27015 означает «только локально» и разрешения не требует. Сверьте результат со своей конфигурацией, вместо того чтобы полагаться на значения по умолчанию:

grep -E "^(DefaultPort|UDPPort|SteamPort1|SteamPort2|RCONPort|Public|Open|MaxPlayers|MaxAccountsPerUser)=" ~/Zomboid/Server/servertest.ini

Взгляд атакующего даёт скан портов снаружи. Поскольку Project Zomboid использует исключительно UDP, для этого нужен UDP-скан, чистый TCP-скан игровой порт вообще не покажет:

nmap -Pn -sU -p 16261,16262,8766,8767 ВАШ.IP.АДРЕС.СЕРВЕРА
nmap -Pn -p- --min-rate 1000 ВАШ.IP.АДРЕС.СЕРВЕРА

2. Оставить открытыми только 16261 и 16262

Двух разрешений наружу хватает, всё остальное либо ограничивается, либо вообще не публикуется. В UFW это выглядит так, и именно в таком порядке, чтобы не закрыть доступ самому себе:

ufw allow 22/tcp comment "SSH"
ufw allow 16261/udp comment "Project Zomboid"
ufw allow 16262/udp comment "Project Zomboid прямое подключение"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Замените 203.0.113.10 на свой собственный адрес. Порядок при включении решает, не закроете ли вы доступ самому себе. Он описан вместе с обратным путём в статье Настройка файрвола UFW без потери доступа. Если это всё же случилось: на KVM root-серверах и выделенных серверах KernelHost вы попадёте в систему через VNC-консоль в личном кабинете, которая работает независимо от сети гостевой системы.

Пара слов о базах данных и дополнительных службах: Project Zomboid в них не нуждается. То, что кроме игры слушает на 0.0.0.0, осталось от прежней установки или от панели управления и должно быть либо привязано к 127.0.0.1, либо выключено.

3. Убрать RCON на порту 27015 из интернета

RCON — это удалённое управление сервером, и в Project Zomboid оно работает на 27015 TCP. В поставляемой servertest.ini стоит RCONPassword= без значения. Кто пользуется RCON, задаёт длинный случайный пароль, ведь протокол передаёт данные незашифрованными, а доступный RCON-порт со слабым паролем отдаёт сервер целиком, и для этого не нужен ни один пакет атакующего трафика.

Безопасный путь — вообще не открывать порт наружу и обращаться к нему через проброс порта по SSH. После этого вы работаете локально с 127.0.0.1:27015:

ssh -N -L 27015:127.0.0.1:27015 root@ВАШ.IP.АДРЕС.СЕРВЕРА

Кому RCON не нужен, оставляет поле пароля пустым, а порт закрытым. Службу, до которой нельзя достучаться, нельзя ни перебрать, ни залить потоком.

4. Ограничить интенсивность пакетов по каждому адресу источника

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

iptables -I INPUT -p udp --dport 16261:16262 -m hashlimit --hashlimit-name pz_udp --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP
iptables -L INPUT -n -v

Правило отбрасывает UDP-пакеты, как только с одного и того же адреса источника устойчиво идёт больше 400 пакетов в секунду. Значение — стартовое, а не истина в последней инстанции: сервер с 30 игроками в одном и том же городе создаёт заметно больше трафика, чем сервер с четырьмя игроками в разных углах карты, и слишком жёсткая настройка выбрасывает своих же игроков. Сначала померьте неделю в обычном режиме, а затем выставьте границу кратно выше пикового значения.

Два замечания к этому. Просто добавленные правила iptables после перезагрузки исчезают, в Debian и Ubuntu их сохраняют так:

apt-get install -y iptables-persistent
netfilter-persistent save

А при работе с UFW такие правила помещают в /etc/ufw/before.rules, иначе они пропадут при следующем ufw reload. Проверьте по счётчикам совпадений из iptables -L INPUT -n -v, достигается ли правило вообще. Если счётчики остаются на нуле, оно стоит не в том месте.

5. Разгрузить отслеживание соединений

Часто упускаемое узкое место сидит в ядре. Отслеживание соединений заводит запись и для UDP, по каждому адресу источника и порту, а поток с поддельными отправителями заполняет эту таблицу за секунды. Когда она переполняется, сервер отбрасывает и легитимные пакеты, а в логе появляется «nf_conntrack: table full». Текущее значение и верхний предел показывает:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Игровому трафику Project Zomboid отслеживание состояния не нужно, потому что состояния в UDP нет. Поэтому оба игровых порта можно держать вне этой таблицы:

iptables -t raw -I PREROUTING -p udp --dport 16261:16262 -j NOTRACK

Это заметно разгружает ядро. Важно: правило подходит только до тех пор, пока сервер получает пакеты напрямую. Кто держит перед ним преобразование адресов, например в контейнерной конструкции с пробросом портов, ставить его не должен, потому что обратное направление тогда уже не сопоставляется.

6. Защитить вход и слоты

Следующие строки ничего не стоят и работают против всего, что идёт обычным путём подключения:

Password=ДЛИННЫЙ-СЛУЧАЙНЫЙ-ПАРОЛЬ
Open=false
MaxAccountsPerUser=1
MaxPlayers=32
DenyLoginOnOverloadedServer=true

Password — это общий пароль сервера, и он отделён от учётной записи отдельного игрока. Open=false означает, что подключаться могут только те учётные записи, которые администратор завёл заранее, это и есть белый список игры. MaxAccountsPerUser ограничивает, сколько учётных записей один пользователь Steam может завести на вашем сервере, значение по умолчанию 0 означает «без ограничения». MaxPlayers с завода стоит на 32, и о значениях выше документация прямо предупреждает: подгрузка карты ухудшается, появляется рассинхронизация.

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

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

7. Сверка модов при подключении — самая дорогая секунда вашего сервера

Project Zomboid проверяет при подключении больше, чем пароль. Список модов сервера стоит в двух строках servertest.ini: WorkshopItems содержит числовые идентификаторы из Workshop, Mods — идентификаторы загрузки модов, обе строки разделены точкой с запятой. При входе клиент сверяет этот список, автоматически докачивает недостающее содержимое Workshop через Steam и только после этого получает потоком данные мира. Вдобавок при DoLuaChecksum=true сервер сравнивает контрольные суммы игровых файлов и выбрасывает клиентов, чьи файлы к его файлам не подходят.

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

DenyLoginOnOverloadedServer=true
LoginQueueEnabled=true
LoginQueueConnectTimeout=60

DenyLoginOnOverloadedServer отклоняет новые входы, пока сервер перегружен, вместо того чтобы обрывать заодно и идущую партию. LoginQueueEnabled ставит входящих в очередь, вместо того чтобы обрабатывать их одновременно, а LoginQueueConnectTimeout задаёт, сколько может длиться вход: значение по умолчанию 60 секунд, допустимы от 20 до 1200.

Одна деталь сюда же, потому что её часто решают неверно: на Linux-серверах есть задокументированная ошибка, при которой DoLuaChecksum поднимает ложную тревогу и не пускает игроков. Поэтому владельцы отключают проверку. Это понятно, но убирает контроль, который держит в стороне клиентов с изменёнными игровыми файлами. Кому приходится её отключить, тому тем строже стоит задать пароль сервера, белый список и предел учётных записей.

8. Список серверов, UPnP и собственный адрес

Здесь честность полезнее, чем выдавать желаемое за действительное: сохранить IP-адрес в тайне не получится. Public=true показывает сервер в браузере игры, а сервер со Steam-привязкой, согласно документации, и так виден в браузере серверов Steam. Значит, Public=false отнимает у вас видимость для новых игроков, но невидимым вас не делает.

Public=true
PublicName=Мой Zomboid-сервер
UPnP=false
server_browser_announced_ip=

UPnP с завода стоит на true и заставляет сервер пытаться самостоятельно настроить проброс портов на интернет-шлюзе. На арендованном сервере такого шлюза нет, попытка уходит в пустоту, и её стоит выключить. server_browser_announced_ip остаётся пустым, кроме случая, когда у вашего сервера несколько адресов и он должен появляться под одним определённым. Именно это поле понадобится вам позже снова, когда вы будете переходить на выделенный защищённый IP.

Две привычки помогают больше, чем любая настройка. Нигде не публикуйте сырой IP-адрес сами, ни в Discord-канале, ни на странице проекта, и дайте своим игрокам имя хоста. Классическая ловушка при смене адреса — старые DNS-записи: забытая A-запись на прежний адрес обесценивает любую смену.

9. Измерять, пока всё работает нормально

Самый важный шаг — тот, который почти никто не делает заранее: собрать базу для сравнения, пока всё спокойно. Без нормального значения вы после инцидента не скажете, много ли это, 40 000 пакетов в секунду, или это просто субботний вечер. С apt-get install -y vnstat sysstat измерение идёт постоянно в фоне. Во время инцидента хватает четырёх команд:

sar -n DEV 1 10
ip -s link show eth0
tcpdump -ni eth0 "udp port 16261 or udp port 16262" -c 200 -q
journalctl -u zomboid --since "-15 min" | tail -50

Первые две показывают интенсивность пакетов и счётчики отброшенных пакетов на интерфейсе, третья — короткую выборку трафика, четвёртая — сообщения сервера, если он работает как systemd-служба (имя службы подставьте своё). Для tcpdump правило одно: всегда ограничивайте объём через -c, ведь захват трафика под полной нагрузкой дополнительно нагружает и без того перегруженный сервер. Как разобрать полученные значения, описано в статье Как определить DDoS-атаку на сервере.

Где эти меры заканчиваются: полоса пропускания и интенсивность пакетов

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

Давайте посчитаем. Типовой игровой сервер подключён на 1 Гбит/с, это 125 мегабайт в секунду, и канал заполнен, как только кто-то отправит больше. Вторая величина — интенсивность пакетов, и упирается в неё обычно раньше, чем в полосу: при маленьких пакетах по 64 байта в 1 Гбит/с помещается около 1,49 миллиона пакетов в секунду, тогда как обычное серверное ядро в зависимости от CPU и сетевой карты обрабатывает лишь несколько сотен тысяч из них, прежде чем начинает отбрасывать. Значит, атака, которая не заполняет ваш канал даже на треть, способна положить сервер. Владельцы серверов описывают это словами «загрузка ведь была совсем не высокой, а всё равно всё легло».

Обычные атаки на игровые сообщества лежат в диапазоне от 5 до 50 Гбит/с, то есть от пятикратного до пятидесятикратного объёма обычного канала. Локальной настройки против такого не существует. Объёмные атаки должны заканчиваться в сети перед сервером.

Что KernelHost ставит против DDoS-атак на игровые серверы

Постоянная защита, включённая в каждый сервер

Защита от DDoS в KernelHost построена в два уровня и активна постоянно, вам не нужно ничего включать, заказывать или настраивать:

• Уровень 1: 17 Тбит/с ёмкости mitigation в глобальной scrubbing-сети. Объёмные атаки вычищаются близко к источнику, ещё до того как они дойдут до дата-центра.
• Уровень 2: фильтрация Arbor в реальном времени на 3,2 Тбит/с во Франкфурте-на-Майне. Непосредственно перед сервером распознаются и отбрасываются схемы, характерные для конкретных протоколов, пакет за пакетом.

Решают два свойства. Защита работает постоянно и не должна сначала отреагировать на атаку, поэтому нет тех первых минут, когда сервер недоступен. И null-routing не применяется: ваш IP-адрес остаётся в сети, отбрасываются только вредоносные пакеты. Тот, кто убирает IP-адрес из сети, добивается для вас того же результата, что и атакующий. Какие игры и протоколы покрыты, перечисляет статья Защита игровых серверов от DDoS в реальном времени.

Advanced DDoS Protection для проектов под постоянным обстрелом

Некоторые проекты атакуют не время от времени, а прицельно и неделями. Для них есть Advanced DDoS Protection от 50,00 € в месяц, по модели PrePaid, без минимального срока и без платы за подключение. Разница не в большей ёмкости, а в контроле:

• Выделенный защищённый IP-адрес из франкфуртского ядра сети, на который ваш сервер переводится внутри нашей сети. С вашей стороны ничего перестраивать не нужно, новый адрес вы лишь вписываете туда, где ваши игроки находят сервер.
• Самостоятельно управляемые правила защиты по портам и протоколам в личном кабинете: вы задаёте, что разрешено на 16261 и 16262 UDP, а всё остальное остаётся закрытым, и тикет для этого писать не нужно.
• Изменения вступают в силу в реальном времени, поэтому подстраивать их можно прямо во время идущей атаки.
• Подходящий профиль защиты. Для распространённых игр есть готовые профили, а для модифицированных и собственных приложений вы задаёте правила по портам и протоколам сами. Project Zomboid при этом ограничивается особенно точно, потому что весь игровой трафик идёт через два соседних UDP-порта.

Сравнение двух уровней

Большинству Project-Zomboid-серверов хватает включённой постоянной защиты вместе с аккуратной настройкой. Advanced DDoS Protection — это ответ на ситуацию, когда кто-то воспринимает происходящее лично.

Частые ошибки и их решения

«Мои игроки получают сообщение, что порт 16262 закрыт»: это не атака, а отсутствующее разрешение. Серверу нужны оба порта, 16261 UDP и 16262 UDP, причём именно правилом для UDP. Разрешение для TCP на тех же номерах не даёт ничего. Проверьте через ufw status verbose и UDP-скан снаружи, действительно ли открыты оба.

«Я сменил IP-адрес и через два часа снова был офлайн»: новый адрес атакующий получил из того же источника, что и старый, чаще всего из записи в списке серверов, от Discord-бота со статусом или из старой DNS-записи. В Project Zomboid смена стоит дополнительно: клиенты складывают данные карты локально по адресу и порту, в папке по образцу 123.45.0.12_16261_... в Zomboid/Saves. После смены каждый игрок заново скачивает исследованную карту с сервера. Значит, смена адреса — выигрыш времени с дополнительными издержками, а не решение.

«Мои правила iptables не срабатывают»: частых причин три. Правила стоят позади цепочек UFW, и дело до них не доходит. Либо они пропали после последней перезагрузки (тогда помогут netfilter-persistent save или запись в /etc/ufw/before.rules). Либо атака объёмная, и правило работает корректно, только канал уже забит. Проверьте командой iptables -L INPUT -n -v, растут ли счётчики совпадений.

«Игроки вылетают при входе, а сервер работает дальше как обычно»: это почти всегда сверка, а не атака. Причины: расхождение версий клиента и сервера, отсутствующая или устаревшая запись Workshop или несовпадающая контрольная сумма. Клиент, как правило, называет моды, которые не совпадают. Сверьте WorkshopItems и Mods строка за строкой.

«Каждые несколько минут рывки, потом снова работает»: это обычная картина коротких атак, которые идут ровно столько, пока игроки не бросят всё в раздражении. Смотрите сначала на сетевые счётчики, а не на загрузку CPU. Если sar -n DEV 1 10 и счётчики отброшенных пакетов остаются обычными, это была не атака, а нагрузка: слишком много игроков в одной и той же ячейке, дорогой мод или слишком мало оперативной памяти для Java-экземпляра.

«Мой прежний провайдер заблокировал мой IP-адрес»: это и есть null-routing. Так провайдер защищает собственную сеть, а для вас результат ничем не отличается от успешной атаки, обычно ещё на несколько часов после неё. Если сомневаетесь, спросите напрямую: трафик фильтруют или адрес уводят в null-routing. Ответ определяет вашу доступность сильнее, чем любые характеристики железа.

«В tcpdump я не вижу ничего подозрительного»: если трафик отфильтрован ещё в сети перед сервером, то до самого сервера, как и ожидается, ничего не доходит. При работающей фильтрации это нормальная картина. Верно и обратное: при насыщенном канале до вас может не дойти даже та SSH-сессия, из которой вы собирались снимать измерения. Тогда используйте VNC-консоль в личном кабинете.

Коротко о главном

• Выделенному Project-Zomboid-серверу нужны ровно два открытых порта: 16261 UDP (DefaultPort) и 16262 UDP (UDPPort). Оба стоят в servertest.ini как отдельные директивы.
• RCON работает на 27015 TCP и с завода вписан без пароля. Этому порту не место в открытом интернете, он должен быть либо ограничен вашим собственным адресом, либо закрыт.
• Сверка модов при подключении — самое дорогое место: версия, контрольная сумма, список Workshop и данные карты стоят процессорного времени, в том числе при каждой отклонённой попытке. Встроенные тормоза против этого — DenyLoginOnOverloadedServer и очередь на вход.
• Пароль сервера, Open=false и MaxAccountsPerUser=1 защищают игровую логику. Против насыщенного канала ни одна из этих настроек не работает.
• Физическая граница задана жёстко: 1 Гбит/с — это 125 мегабайт в секунду, а при пакетах размером 64 байта около 1,49 миллиона пакетов в секунду. Обычные атаки на игровые серверы лежат в диапазоне от 5 до 50 Гбит/с.
• Объёмные атаки должны заканчиваться в сети перед сервером. В KernelHost это 17 Тбит/с ёмкости mitigation в глобальной scrubbing-сети и фильтрация Arbor в реальном времени на 3,2 Тбит/с во Франкфурте-на-Майне, без доплаты и без null-routing.
• Кто находится под постоянным обстрелом, управляет фильтрацией сам через Advanced DDoS Protection: выделенный защищённый IP, правила по портам и протоколам, изменения в реальном времени, от 50,00 € в месяц.

Если ваш сервер уже работает в KernelHost, фильтрация активна, и делать для этого ничего не нужно. Если вы всё же замечаете странности, откройте тикет в поддержку, чтобы правила фильтрации подстроили под ваш IP-адрес. Во время идущей атаки с нами дополнительно можно связаться через экстренный чат WhatsApp по номеру +43 650 8209883.