Защита MTA:SA-сервера от DDoS-атак

Сервер Multi Theft Auto: San Andreas ведёт себя под DDoS-атакой иначе, чем любой другой многопользовательский проект по GTA, потому что он одновременно предлагает три отдельные сетевые службы: игровой трафик на 22003 UDP, полноценный HTTP-сервер на 22005 TCP и ASE-запрос на 22126 UDP. Каждую из этих трёх служб можно атаковать по отдельности, и каждая отказывает по-своему. В этой статье сначала разобрано, что вы можете защитить сами и без дополнительных расходов, затем то, где эти меры упираются в физику канала, и в конце то, что действенная защита MTA:SA от DDoS должна обеспечивать в сети перед сервером.

Если атака идёт прямо сейчас, главный вопрос в том, по какой из трёх служб она бьёт. Если игроки остаются на связи, но при подключении больше не загружают ресурсы, бьёт по HTTP-серверу на 22005. Если сервер пропадает из браузера, а подключённые игроки продолжают играть как обычно, бьёт по ASE-запросу на 22126. Если все соединения обрываются одновременно, то целью является либо 22003, либо канал просто заполнен. Все указания относятся к MTA-серверу под Debian 12, Debian 13, Ubuntu 22.04 LTS или Ubuntu 24.04 LTS, команды написаны для root, если вы работаете под обычным пользователем, добавляйте перед каждой командой sudo.

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

MTA:SA-проекты — удобные мишени, потому что свой адрес они обязаны публиковать сами. Сервер появляется в игровом браузере только тогда, когда он регистрируется в мастер-списке серверов и затем отвечает на запросы снаружи. Список содержит IP-адрес и порт в открытом виде, так что предварительная разведка атакующему не нужна.

К этому добавляется сама сцена. Немецкоязычные и бразильские ролевые серверы, дрифт-серверы и переносы DayZ борются за одну и ту же аудиторию, и сбой в часы пик заметен максимально. Забаненному игроку, рассорившейся команде или конкурирующему проекту не нужны ни навыки, ни заметные деньги, чтобы испортить вечер. Заказные сервисы атак, которые на сцене называют booter или stresser, продают за несколько евро в месяц ровно два результата: увести MTA-сервер в офлайн на минуты или сделать его неиграбельным из-за скачков задержки. Что такое DDoS-атака с технической стороны и какие бывают виды атак, объясняет статья Что такое DDoS-атака.

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

Порты, о которых на самом деле идёт речь

MTA:SA-серверу нужны ровно три порта: 22003 UDP для игры, 22005 TCP для внутреннего HTTP-сервера и 22126 UDP для ASE-запроса. Третий порт — не свободно выбираемая настройка, он жёстко получается из игрового порта плюс 123. Кто поставит serverport на 22010, получит запрос на 22133.

Две тонкости так и записаны в поставляемой mtaserver.conf и регулярно ускользают от внимания. httpport может иметь то же числовое значение, что и serverport, потому что один порт работает по TCP, а другой по UDP. И serverip стоит на auto и должен там остаться: жёстко вписанное значение привязывает ASE-сокет именно к этому адресу и ломает запись в списке, как только адрес меняется.

Протокол ASE-запросов и почему он работает усилителем

ASE (All-Seeing Eye) — это чистый протокол запросов поверх UDP: ответ определяется первым байтом пакета, установления соединения нет. MTA-сервер знает пять запросов и отвечает на них на 22126:

• s — это полный ASE-запрос. Ответ начинается с EYE1 и содержит имя сервера, тип игры, имя карты, версию, наличие пароля, число игроков, полный список всех правил, заданных через setRuleValue, и затем каждого подключённого игрока с именем, счётом и пингом. У этого ответа нет ограничения по размеру.
• b и r — более компактные запросы для игрового браузера. Ответ начинается с EYE2 и в исходном коде обрезается на 1 340 байтах, чтобы избежать фрагментации.
• x отдаёт сокращённое сообщение о статусе, v только идентификатор версии ASE.

Отсюда и возникает проблема. Запрос состоит из единственного байта полезной нагрузки, то есть на проводе из 29 байт (20 байт заголовка IP, 8 байт заголовка UDP, 1 байт полезной нагрузки). Ответ с 1 400 байтами полезной нагрузки занимает на проводе 1 428 байт. Соотношение составляет примерно 49 к одному, а поскольку в UDP нет установления соединения, адрес отправителя можно подделать. Значит, атакующий способен использовать ваш сервер как усилитель против третьей цели, ни разу не зайдя в вашу игру. У полного запроса этот множитель растёт вместе с числом игроков и с каждым правилом, которое задаёт ваш игровой режим.

Против этого у MTA есть два встроенных тормоза, о которых стоит знать, потому что они объясняют, почему одни флуды срабатывают, а другие нет. Сервер отвечает на каждый адрес источника максимум на пять запросов за шесть секунд и затем игнорирует этот адрес семь секунд. Кроме того, он держит ответы в кэше десять секунд, вместо того чтобы собирать их заново на каждый запрос. Но подсчёт по каждому адресу источника полностью пропускается, как только в списке одновременно оказывается больше 100 разных адресов отправителя. Именно так и выглядит обычная картина при распределённом флуде из ботнета или с поддельными отправителями, и поэтому встроенный тормоз против серьёзной атаки не помогает.

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

Этот раздел самый длинный, и так задумано. Аккуратно настроенный MTA-сервер выдерживает небольшие и средние атаки собственными силами, независимо от того, у какого провайдера он стоит.

1. Инвентаризация: что вообще слушает сеть?

Сначала посмотрите, что ваш сервер предлагает наружу. Не гадайте, а смотрите:

ss -lntup

Ожидать следует три строки процесса MTA: 0.0.0.0:22003 по UDP, 0.0.0.0:22005 по TCP и 0.0.0.0:22126 по UDP. Если там дополнительно обнаружится база данных на 0.0.0.0:3306, веб-сервер или забытая голосовая служба, это нужно выключить. Взгляд атакующего даёт скан портов снаружи:

nmap -Pn -sU -p 22003,22126 ВАШ.IP.АДРЕС.СЕРВЕРА
nmap -Pn -p 22005 ВАШ.IP.АДРЕС.СЕРВЕРА

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

2. Оставьте открытыми только те три порта, которые MTA действительно нужны

В UFW работоспособная исходная конфигурация выглядит так, причём именно в таком порядке, чтобы не закрыть доступ самому себе:

ufw allow 22/tcp comment 'SSH'
ufw allow 22003/udp comment 'MTA игра'
ufw allow 22005/tcp comment 'MTA HTTP'
ufw allow 22126/udp comment 'MTA ASE'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Полная инструкция вместе с запасным путём есть в статье Настройка файрвола UFW. На KVM-root-серверах и выделенных серверах KernelHost в критической ситуации вы попадёте в систему через VNC-консоль в личном кабинете, даже если канал насыщен.

Базе данных в открытой сети не место. Если ss -lntp | grep 3306 показывает 0.0.0.0:3306, впишите в /etc/mysql/mariadb.conf.d/50-server.cnf строку bind-address = 127.0.0.1 и перезапустите службу.

3. Ограничьте ASE-порт, не вылетая из списка серверов

В отличие от SA-MP, у MTA:SA запрос лежит на отдельном порту, поэтому ограничивать его можно независимо от игрового процесса. Это самое большое практическое преимущество такой архитектуры: правило на 22126 не выбрасывает ни одного игрока.

С nftables в отдельной таблице, чтобы набор правил не мешал UFW:

nft add table inet mtaguard
nft add chain inet mtaguard input '{ type filter hook input priority -150 ; policy accept ; }'
nft add rule inet mtaguard input udp dport 22126 meter aseperip '{ ip saddr limit rate over 3/second burst 6 packets }' drop
nft add rule inet mtaguard input udp dport 22126 limit rate over 2000/second burst 500 packets drop
nft list table inet mtaguard

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

iptables -A INPUT -p udp --dport 22126 -m hashlimit --hashlimit-name mta_ase \
  --hashlimit-mode srcip --hashlimit-above 3/sec --hashlimit-burst 6 \
  --hashlimit-htable-expire 30000 -j DROP

Попытка закрыть порт целиком — это выбор с последствиями, а не секретный приём: без ASE ваш сервер пропадает из игрового браузера, а вместе с ним пропадает и органический приток игроков. Если вы всё же этого хотите, <ase>0</ase> недостаточно. В исходном коде открытие порта завязано на логическое ИЛИ между интернет-режимом и LAN-режимом, поэтому при <ase>0</ase> сокет остаётся открытым, пока стоит <donotbroadcastlan>0</donotbroadcastlan>. Кто действительно хочет закрыть порт, задаёт оба значения:

<ase>0</ase>
<donotbroadcastlan>1</donotbroadcastlan>

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

4. Разгрузите внутренний HTTP-сервер

HTTP-сервер на 22005 у MTA:SA — это самостоятельная поверхность атаки, потому что каждый подключающийся игрок загружает оттуда все клиентские файлы всех запущенных ресурсов. У ролевого проекта с собственными моделями это быстро оборачивается несколькими сотнями мегабайт, разложенными на сотни отдельных файлов. Встроенный сервер намеренно сделан простым: без сжатия, с фиксированным количеством рабочих потоков. Пары десятков одновременных обращений хватает, чтобы настоящие игроки минутами висели на экране загрузки.

Самая действенная мера — полностью убрать загрузки с игрового сервера. Файлы для раздачи MTA готовит для этого сам, в каталоге mods/deathmatch/resource-cache/http-client-files. Этот каталог вы отдаёте через nginx или lighttpd, а адрес вписываете в mtaserver.conf:

<httpdownloadurl>http://cdn.ваш-домен.tld/mta</httpdownloadurl>

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

Если внутренний сервер остаётся в работе, используйте его собственные ограничения. В mtaserver.conf:

<httpmaxconnectionsperclient>5</httpmaxconnectionsperclient>
<httpdosthreshold>20</httpdosthreshold>
<http_dos_exclude></http_dos_exclude>
<httpthreadcount>8</httpthreadcount>

httpmaxconnectionsperclient ограничивает одновременные соединения на клиента до 5 в допустимом диапазоне от 1 до 8. httpdosthreshold ограничивает, сколько соединений один IP-адрес может открыть за короткое время, по умолчанию 20. http_dos_exclude выводит из-под этого отдельные адреса, например вашу собственную страницу статуса. httpthreadcount задаёт число рабочих потоков, по умолчанию 8 в диапазоне от 1 до 20. Большее значение помогает при множестве мелких файлов, но отнимает процессорное время у игрового процесса.

Помните и о том, что раздаётся на том же порту. Ресурсы webadmin и resourcebrowser в поставляемой конфигурации запущены и доступны через 22005 в браузере. Панели управления без защиты в открытой сети не место: раздайте в acl.xml аккуратные права, заведите отдельную учётную запись с длинным случайным паролем и останавливайте ресурс, когда он вам не нужен.

5. Используйте встроенные ограничения в mtaserver.conf

У MTA защитных ограничений больше, чем использует большинство проектов. Часть из них жёстко задана в исходном коде, часть лежит в mtaserver.conf. Эта таблица собирает те, которые играют роль при атаке:

Три настройки заслуживают осознанного решения. maxplayers стоит на 32 и должен соответствовать действительности: каждый дополнительный слот увеличивает полный запрос и повышает число соединений, которые может занять атакующий. bandwidth_reduction стоит на medium, значение maximum заметно снижает исходящую нагрузку, но стоит точности синхронизации. А <password></password> без усилий превращает ваш сервер в закрытый круг, притом что запись в списке сохраняется: это самый быстрый стоп-кран при идущем флуде подключениями.

6. Различайте флуд подключениями и флуд событиями

Две схемы атаки метят не в канал, а в игровую логику, и их регулярно путают.

Флуд подключениями в быстром темпе устанавливает настоящие соединения, пока не заняты все слоты или пока сервер не перестаёт успевать с их установлением. MTA сам по себе ограничивает это четырьмя соединениями на адрес источника за 30 секунд и затем игнорирует адрес 30 секунд. Что именно делает этот тормоз прямо сейчас, показывает консольная команда debugjoinflood. Ограничение действует по каждому адресу, а ботнет с тысячей адресов проходит мимо него. Против этого помогают пароль на сервер, белый список в игровом режиме и ограничение интенсивности на 22003.

Флуд событиями приходит, наоборот, от уже подключённых игроков: изменённый клиент в цикле отправляет triggerServerEvent, пока у сервера не заканчивается процессорное время. Штатно MTA разрешает для этого 100 событий на игрока в секунду, а сверх того выдаёт сообщение о флуде событиями. Если ваш игровой режим использует много мелких событий, проверьте это значение, прежде чем его снижать: заданное слишком тесно, оно выбрасывает собственных игроков.

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

7. Список серверов, IP-адрес и что он выдаёт ещё

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

Проверьте вместо этого, что ваш адрес выдаёт ещё. Типичные утечки в MTA-проектах — это старые записи A и AAAA в DNS, страница проекта на той же машине, Discord-бот со статусом, публично считывающий ASE-запрос, TLS-сертификаты со старыми именами хостов и записи на форумах с первых дней проекта. Отсюда следует правило, которое многие проекты усваивают слишком поздно: если вы переезжаете на защищённый адрес, меняйте одновременно и старый. Если он остаётся, он стоит в каждой базе сканеров, и атака проходит мимо защиты.

Две записи в mtaserver.conf напрямую касаются видимости. <serverip>auto</serverip> остаётся на auto, если только вы точно не знаете, почему должно быть иначе. И <owner_email_address> должен быть заполнен: если записи нет или она неверна, это может ухудшить видимость в мастер-списке серверов.

8. Протоколирование: чтобы в нужный момент были данные

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

Во время инцидента сначала отделите три порта друг от друга. Этих четырёх команд хватает:

sar -n DEV 1 10
nstat -az | grep -E 'Udp(InDatagrams|InErrors|NoPorts|RcvbufErrors)'
tcpdump -ni eth0 -c 200 -q 'udp port 22126'
ss -tn state established '( dport = :22005 or sport = :22005 )' | wc -l

Разобрать это проще, чем кажется. Если ошибки буфера растут при низкой загрузке процессора, до вас доходит больше трафика, чем процесс успевает обработать. Если одно ядро стоит на пределе, а трафик выглядит обычным, проблема в игровом режиме, а не в сети. Если захват на 22126 показывает много пакетов с единственным байтом полезной нагрузки, это ASE-флуд. Если число открытых соединений на 22005 постоянно держится в четырёхзначном диапазоне, бьёт по HTTP-серверу. Для tcpdump правило всегда одно: ограничивайте объём через -c, ведь захват трафика под полной нагрузкой дополнительно нагружает и без того перегруженный сервер. Как разобрать полученные значения в деталях, описывает статья Как определить DDoS-атаку на сервере.

Сам журнал сервера лежит в logs/server.log, журнал скриптов в logs/scripts.log. Оба пути стоят в mtaserver.conf и их можно переназначить.

Где эти меры заканчиваются

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

Давайте посчитаем. Типовой игровой сервер подключён на 1 Гбит/с, это соответствует 125 мегабайтам в секунду, а при пакетах размером 64 байта примерно 1,49 миллиона пакетов в секунду. Атаки на игровые проекты такого масштаба обычно лежат в диапазоне от 5 до 50 Гбит/с, то есть от пятикратного до пятидесятикратного объёма вашего канала. Насколько хорошо написано ваше правило nftables за этим каналом, роли уже не играет: пакеты ваших игроков не доходят ещё раньше.

Интенсивность пакетов при этом часто упирается раньше, чем полоса. Обычное серверное ядро в зависимости от процессора и сетевой карты обрабатывает несколько сотен тысяч пакетов в секунду, а дальше начинает отбрасывать. Значит, атака, которая не заполняет ваш канал даже на треть, способна положить ваш сервер, потому что процессорное время уходит на само отбрасывание. Владельцы серверов описывают это словами «загрузка ведь была совсем не высокой, а всё равно всё легло».

У MTA:SA к этому добавляется третий предел, и он срабатывает раньше всех. Сервер читает сетевые порты в одном-единственном рабочем потоке. Флуд запросами на 22126 занимает этот поток настолько, что пакеты синхронизации настоящих игроков пропадают в приёмном буфере задолго до того, как заполнится канал. Процесс при этом не падает, он просто становится медленным, а игроки видят резиновый эффект. То же верно для HTTP-сервера: он делит процессорное время с игровым процессом.

Чтобы понимать, какие порядки величин встречаются на практике: на серверах KernelHost были отфильтрованы, среди прочего, атака мощностью более 473,4 Гбит/с при более чем 41,5 миллиона пакетов в секунду на голосовой сервер и UDP-flood мощностью более 112,2 Гбит/с при более чем 8,7 миллиона пакетов в секунду на игровой сервер. Первый случай — это примерно 473-кратная полоса и около 28-кратной интенсивности пакетов, которую вообще способен принять канал на 1 Гбит/с. Локальной настройки против такого не существует. Объёмные атаки должны заканчиваться в сети перед сервером.

Что KernelHost этому противопоставляет

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

Каждый сервер в KernelHost стоит за постоянно активной двухуровневой фильтрацией:

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

Решают три свойства. Защита активна постоянно, поэтому нет фазы обнаружения, во время которой ваш сервер уходит в офлайн. Null-routing не применяется: атакуемый адрес остаётся в сети, отбрасываются только вредоносные пакеты, а соединения настоящих игроков продолжают работать. И стоит она не дороже, а входит с момента развёртывания в каждый серверный тариф, от KVM-root-сервера через игровой сервер до выделенного сервера. Фильтрация идёт на уровнях 3, 4 и 7 на любом порту TCP или UDP, то есть одновременно на 22003 UDP, 22005 TCP и 22126 UDP. Работает это в дата-центре maincubes во Франкфурте-на-Майне (Германия). Какие игры и протоколы имеют собственные профили, показывает статья Защита игровых серверов от DDoS в реальном времени.

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

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

• Выделенный защищённый IP-адрес из франкфуртского ядра сети. Ваш сервер переводится на него внутри сети KernelHost, с вашей стороны ничего перестраивать не нужно.
• Самостоятельно управляемые правила защиты по портам и протоколам в личном кабинете. Именно в этом и суть для MTA:SA: вы задаёте отдельные правила для 22003 UDP, 22005 TCP и 22126 UDP, вместо того чтобы стричь три очень разные службы под одну гребёнку.
• Изменения вступают в силу в реальном времени, без тикета и без ожидания. Значит, подстраивать их можно прямо посреди идущей атаки.
• Профиль защиты под конкретную игру. Multi Theft Auto есть как отдельный профиль, как и веб-серверы, голосовые серверы и собственные приложения на TCP или UDP, которые помещаются за тот же защищённый адрес.

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

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

Частые ошибки и что с ними делать

«Я закрыл 22126, сервера всё равно нет ни в одном списке, но запросы продолжают приходить»: значит, сокет ещё открыт. Один только <ase>0</ase> порт не закрывает, пока задано <donotbroadcastlan>0</donotbroadcastlan>. Проверьте командой ss -lnup | grep 22126, действительно ли там больше никто не слушает.

«Игроки висят на экране загрузки, сама игра работает нормально»: это не атака на 22003, а HTTP-сервер на 22005 на пределе. Вынесите загрузки через httpdownloadurl и проверьте httpmaxconnectionsperclient и httpthreadcount.

«Сервер пропал из браузера, а игроки на нём ничего не замечают»: тогда бьёт исключительно по 22126. Для подключённых игроков это без последствий, а для притока новых нет. Правильный ответ — ограничение интенсивности на этот один порт, а не на игровой.

«Мы сменили IP-адрес и через два часа снова были офлайн»: новый адрес атакующий получил из того же источника, что и старый, обычно из записи в списке, от Discord-бота со статусным запросом или из старой DNS-записи. Смена адреса даёт время, но не решение.

«Мы поставили на 22003 предел в 20 пакетов в секунду на адрес»: это слишком тесно. Уже один игрок при активной синхронизации выходит за этот предел, а несколько игроков за одним NAT-адресом делят одну и ту же квоту. Так вы выбрасываете собственных игроков. На 22126 тесные значения, наоборот, проблем не создают.

«Мы закрыли себе доступ файрволом»: перезагрузка не помогает, потому что UFW восстанавливает свои правила при старте. В KernelHost откройте VNC-консоль в личном кабинете и выполните там ufw disable. VNC-консоль работает независимо от сети гостевой системы.

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

«Мы просто переждём атаку»: атаки, которые срабатывают, повторяют. Зафиксируйте момент времени с часовым поясом, длительность, пиковые значения и затронутый порт. Ровно эти данные нужны и в тикете в поддержку, чтобы фильтрацию подтянули прицельно.

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

• MTA:SA-серверу нужны ровно три порта: 22003 UDP для игры, 22005 TCP для внутреннего HTTP-сервера и 22126 UDP для ASE-запроса. Третий жёстко получается из игрового порта плюс 123.
• ASE-запрос лежит на отдельном порту и поэтому ограничивается, не отрезая ни одного игрока. Это важнейшее отличие от SA-MP, где игра и запрос делят один порт.
• Единственный байт запроса на 22126 порождает ответ размером до нескольких килобайт, а адрес отправителя подделывается. Значит, неограниченный ASE-порт — это одновременно и цель, и усилитель.
• Встроенные тормоза MTA действуют по каждому адресу источника: пять запросов за шесть секунд, четыре подключения за 30 секунд. При более чем 100 одновременных адресах источника подсчёт запросов пропускается, так что распределённый флуд проходит насквозь.
• Внутренний HTTP-сервер на 22005 — это самостоятельная поверхность атаки. Кто выносит загрузки через httpdownloadurl на внешний веб-сервер, убирает их из игрового процесса.
• Всё, что работает на самом сервере, решает только мелкие атаки. На 1 Гбит/с предел наступает примерно на 1,49 миллиона пакетов в секунду, независимо от качества ваших правил.
• Двухуровневая постоянная защита в KernelHost входит в каждый серверный тариф без доплаты и работает без null-routing. Кто хочет управлять правилами по портам сам, добавляет Advanced DDoS Protection от 50,00 € в месяц.

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