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

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

Все указания относятся к официальному выделенному серверу от Pocketpair (Steam-App-ID 2394010) под Debian 12, Debian 13, Ubuntu 22.04 LTS или Ubuntu 24.04 LTS. Команды написаны для root, если вы работаете под обычным пользователем, добавляйте перед каждой командой sudo. Если атака идёт прямо сейчас, порядок такой: сначала измерять, потом менять. Жёсткая перезагрузка под нагрузкой отбрасывает всё, что произошло в мире с момента последнего автоматического сохранения, а измерения по инциденту после неё пропадают тоже.

Почему Palworld-серверы целенаправленно выводят из строя DDoS-атаками

Palworld-сервер — это небольшая постоянная аудитория по постоянному адресу. Выделенный сервер ограничен 32 игроками, значение задаётся через ServerPlayerMaxNum с допустимым диапазоном от 1 до 32. Тот, кто вместо этого хостит игру через меню, получает четыре места и только на то время, пока сам хозяин находится в сети. Из этих 32 мест следует всё остальное: группа играет в определённые вечерние часы, все знают друг друга, и сбой в восемь вечера задевает не часть игроков, а всех сразу.

Адрес сервера при этом не тайна. В Palworld нет посредничества через сервис издателя: игроки вписывают IP-адрес и порт в поле прямого подключения, а кто хочет дополнительно держать сервер в общедоступном списке, запускает его с -publiclobby и оставляет порт запросов отвечающим. Значит, каждый, кто хоть раз подключался, знает цель. Booter-сервис, который обстреливает этот адрес за пару евро в месяц, не требует от заказчика ни навыков, ни усилий.

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

Порты, о которых на Palworld-сервере действительно идёт речь

Palworld-серверу нужен ровно один открытый порт: 8211 UDP. Всё остальное опционально, а в некоторых ролях даже вредно, если стоит в открытом интернете. Отсюда полезное различие: DDoS-атака на порт 8211 всегда бьёт по самому игровому трафику, а атака на порт 27015 UDP — только по записи в списке серверов.

Все переключатели для этого лежат в одном-единственном файле: Pal/Saved/Config/LinuxServer/PalWorldSettings.ini, под Windows соответственно Pal\Saved\Config\WindowsServer\PalWorldSettings.ini. Он начинается со строки раздела [/Script/Pal.PalGameWorldSettings], после которой идёт единственная строка OptionSettings=(...), содержащая все настройки списком. Перенос строки внутри скобки делает всю конфигурацию недействительной, и сервер молча откатывается на значения по умолчанию. Шаблон DefaultPalWorldSettings.ini в каталоге сервера вы не правите, потому что он перезаписывается при каждом обновлении.

Palworld-сервер в цифрах

Следующие значения — основа для любого решения о правилах фильтрации и предельных величинах.

Почему порт запросов 27015 — самое уязвимое место

Порт запросов отвечает на запросы статуса в формате Steam A2S, то есть на тот же запрос, который обслуживают серверы Counter-Strike и ARK. Запрос A2S_INFO — это UDP-пакет без установления соединения размером в несколько десятков байт, а ответ с именем сервера, миром, числом игроков и состоянием игры больше во много раз. Поскольку в UDP адрес отправителя можно подделать, атакующий способен обращаться к чужим портам запросов и направлять более крупные ответы на свою настоящую цель. Ваш сервер в этом случае не жертва, а усилитель, и счёт оплачивает ваш канал.

Поэтому 8 декабря 2020 года Valve дополнила A2S_INFO предварительным челленджем: сервер сначала отвечает S2C_CHALLENGE, запрашивающий обязан вернуть токен и тем самым доказать, что не подделывает свой адрес отправителя. Это смягчает усиление, но не прекращает его, а против простого потока одинаковых запросов с настоящих адресов не работает вовсе.

Для Palworld отсюда следует важное преимущество перед движком Source: игровой трафик и запросы к серверу лежат на разных портах. В Counter-Strike 2 оба делят порт 27015, и грубое ограничение интенсивности выбрасывает там заодно и собственных игроков. В Palworld вы можете жёстко ограничить 27015 UDP или закрыть его целиком, не затронув ни одного текущего игрового соединения на 8211 UDP. Кому запись в списке не нужна, тот убирает -publiclobby и порт запросов без замены и тем самым снимает из сети целую поверхность атаки.

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

Следующие шаги не остановят объёмную атаку, этого не может никакое программное обеспечение на сервере. Зато они убирают всё, что лежит ниже: сканирование портов, потоки запросов, попытки захвата через порты администрирования и занятие всех 32 мест посторонними. Это большая часть того, что мешает Palworld-серверу в повседневной работе, и стоит это полчаса времени.

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

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

ss -lntup

Интерес представляет колонка с локальным адресом. 0.0.0.0:8211 означает «доступен из всего интернета», 127.0.0.1:8212 означает «только локально» и правила файрвола не требует. Рядом с игровым процессом на обжитом сервере часто обнаруживаются ещё панель управления, веб-сервер для отображения карты и база данных. Взгляд атакующего даёт скан портов снаружи:

nmap -Pn -sU -p 8211,27015 ВАШ.IP.АДРЕС.СЕРВЕРА
nmap -Pn -p- --min-rate 1000 ВАШ.IP.АДРЕС.СЕРВЕРА

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

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

ufw allow 22/tcp comment 'SSH'
ufw allow 8211/udp comment 'Palworld игровой трафик'
ufw allow 27015/udp comment 'Palworld Steam-запрос'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

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

3. Убрать RCON на 25575 и REST API на 8212 из интернета

Оба порта — это доступы администратора с полным контролем над сервером, и оба выключены с завода: RCONEnabled=False и RESTAPIEnabled=False. Кто их включает, должен понимать, что именно он публикует.

REST API на 8212 TCP аутентифицирует через HTTP Basic Auth с фиксированным именем пользователя admin и значением из AdminPassword, причём по незашифрованному HTTP. Значит, пароль администратора уходит по каналу в обратимом виде при каждом отдельном запросе. RCON на 25575 TCP — такой же незашифрованный текстовый протокол, и Pocketpair пометила его как устаревший в пользу REST API. Для новых установок правильный выбор — REST API, а для обоих действует одно правило: не в открытую сеть.

RESTAPIEnabled=True
RESTAPIPort=8212
AdminPassword="длинное случайное значение"

Доступ к интерфейсу вы открываете через проброс порта по SSH, после чего работаете локально с 127.0.0.1:8212:

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

Никогда не оставляйте AdminPassword пустым, ведь пустое значение — это настройка по умолчанию. Значения из openssl rand -base64 32 достаточно. То же самое относится к ServerPassword, о нём чуть ниже.

4. Ограничить порт запросов 27015, не потеряв запись в списке

Steam-пакеты без установления соединения начинаются с четырёх выставленных байт (0xffffffff), у обычного игрового трафика такого заголовка нет. На это можно повесить ограничение интенсивности по каждому адресу источника, которое тормозит запросы и сохраняет запись в списке. С nftables, загружается через nft -f:

table inet palworld {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
    }
}

Приоритет -10 обеспечивает срабатывание правила раньше цепочки фильтрации UFW, а @th,64,32 читает первые четыре байта после UDP-заголовка. С классическим iptables то же самое разделение даёт сравнение с сигнатурой A2S_INFO:

iptables -A INPUT -p udp --dport 27015 \
  -m string --algo bm --hex-string "|ffffffff54536f7572636520456e67696e6520517565727900|" \
  -m hashlimit --hashlimit-name a2sflood --hashlimit-mode srcip \
  --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

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

5. Ограничить интенсивность пакетов на 8211 UDP

На самом игровом порту верхний предел на каждый адрес источника помогает против небольших потоков из нескольких источников. В Palworld эту границу ставить сравнительно безопасно, потому что одновременно подключены самое большее 32 игрока и каждый из них занимает ровно один адрес источника:

iptables -I INPUT -p udp --dport 8211 \
  -m hashlimit --hashlimit-name palworld_udp --hashlimit-mode srcip \
  --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

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

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

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

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

6. Пароль сервера, бан-лист и 32 места против исчерпания слотов

Исчерпание слотов — самая дешёвая атака на Palworld-сервер, и полоса пропускания для неё не нужна. У выделенного сервера самое большее 32 места, значит, 32 одновременных подключений хватает, чтобы закрыть вход всему сообществу. Объёмная атака стоит заказчику денег, 32 сессии не стоят ему ничего. Это делает такой путь для небольших серверов привлекательнее любого потока.

В Palworld нет встроенного белого списка. Инструменты модерации — это кик, бан и пароль сервера, и именно пароль сервера остаётся против исчерпания слотов самой действенной отдельной мерой:

ServerPassword="значение, которое знает только ваша группа"
ServerPlayerMaxNum=32
bShowPlayerList=True
BanListURL="https://api.palworldgame.com/api/banlist.txt"

ServerPassword с завода пуст, значит, внутрь попадает любой, у кого есть IP-адрес и порт. BanListURL по умолчанию указывает на список, который ведёт Pocketpair, и его можно перенаправить на собственный текстовый файл, если вы хотите вести свои блокировки. ServerPlayerMaxNum не ставьте выше 32: более высокие значения не поддерживаются и аукнутся самое позднее при следующем обновлении. И одно должно быть ясно: пароль сервера защищает ваши места, а не ваш канал. Атакующий, который заливает сервер трафиком, вообще не собирается подключаться.

7. Разгрузить отслеживание соединений и увеличить буферы

Этот пункт объясняет сбои, которые выглядят как объёмная атака, но ею не являются. Ядро заводит для UDP-трафика записи в отслеживании соединений (conntrack), и при поддельных адресах отправителя каждый адрес означает новую запись. Когда таблица заполнена, ядро отбрасывает пакеты без разбора, атака и ваши игроки вылетают вместе, а в логе появляется «nf_conntrack: table full». Текущее значение и верхний предел показывает:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Самый действенный шаг — вообще не давать отслеживать игровой трафик, ведь Palworld управляет своими сессиями сам:

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport { 8211, 27015 } notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport { 8211, 27015 } notrack
    }
}

С iptables соответствие выглядит как iptables -t raw -A PREROUTING -p udp --dport 8211 -j NOTRACK и та же строка для OUTPUT с --sport. После этого портам нужно явное разрешение, потому что без отслеживания перестаёт работать любое правило, которое проверяет существующее состояние. Если пакеты приходят быстрее, чем серверный процесс их забирает, дополнительно переполняется приёмный буфер. Для игроков это выглядит как потеря пакетов, хотя канал свободен. Дополнение в /etc/sysctl.d/, применяется через sysctl -p:

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Нужны ли эти значения, сообщает само ядро: если UdpRcvbufErrors в nstat -az растёт, они работают. Если счётчик остаётся на нуле, настройка ничего не меняет.

8. Собирать измерения, пока не стало горячо

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

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 -c 200 "udp port 8211 or udp port 27015"

Для tcpdump правило одно: всегда ограничивайте объём через -c, ведь захват трафика под полной нагрузкой дополнительно нагружает и без того перегруженный сервер. Palworld даёт вдобавок показатель, которого нет ни у одного другого инструмента. Если REST API включён, эндпоинт метрик возвращает в том числе частоту кадров сервера, текущее число игроков и время работы:

curl -s -u admin:ВАШ_ПАРОЛЬ_АДМИНА http://127.0.0.1:8212/v1/api/metrics

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

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

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

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

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

На Palworld-сервере к этому добавляется невыгодное соотношение. Полностью занятый сервер с 32 игроками нагружает лишь малую часть канала на 1 Гбит/с. Значит, атаке не нужно быть большой, чтобы превысить обычный режим в несколько раз, и именно поэтому здесь хватает атак, которые на крупной платформе остались бы незамеченными.

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

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

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

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

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

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

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

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

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

Advanced DDoS Protection рассчитана на серверы, которые стоят в KernelHost. Кто держит свой Palworld-проект сейчас в другом месте и подвергается постоянным атакам, переносит его для этого в KernelHost, и тогда оба уровня работают с момента развёртывания.

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

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

Частые ошибки на Palworld-серверах и их решение

«Я закрыл 27015, и теперь сервер пропал из общедоступного списка»: это ожидаемое поведение, ведь запись в списке держится на порту запросов. Не блокируйте его целиком, а ограничьте пакеты без установления соединения по каждому адресу источника, как в шаге 4. Если запись в списке вам и так не нужна, оставьте порт закрытым, уберите -publiclobby и дайте своим игрокам IP-адрес и порт 8211 для прямого подключения.

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

«У сервера рывки, но канал спокоен»: в Palworld это чаще нагрузка, чем атака. Серверный процесс за время работы занимает всё больше оперативной памяти, поэтому плановая перезагрузка относится к нормальной эксплуатации, а не к аварийным мерам. Проверьте частоту кадров сервера через эндпоинт метрик и потребление памяти процессом. Если sar -n DEV 1 10 при этом не показывает ничего необычного, DDoS-атаки не было.

«Все 32 места заняты, а в игре никого не видно»: это исчерпание слотов, и бьёт оно по игровой логике, а не по каналу. Задайте ServerPassword, заблокируйте подозрительные аккаунты через бан-лист и ограничьте пакеты по каждому адресу источника на 8211 UDP.

«REST API несколько дней был доступен снаружи»: значит, ваш пароль администратора скомпрометирован, ведь HTTP Basic Auth по незашифрованному HTTP передаёт его при каждом запросе в обратимом виде. Смените AdminPassword, закройте 8212 TCP наружу и обращайтесь к интерфейсу только через проброс порта по SSH.

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

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

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

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

• Palworld-серверу нужен ровно один открытый порт: 8211 UDP. Порт запросов 27015 UDP нужен только для записи в общедоступном списке серверов.
• RCON на 25575 TCP и REST API на 8212 TCP в открытой сети не место никогда, ведь оба передают свои учётные данные незашифрованными. RCON вдобавок помечен Pocketpair как устаревший.
• Поскольку игровой трафик и запросы к серверу в Palworld лежат на разных портах, 27015 UDP можно жёстко ограничить, не затрагивая текущий игровой трафик на 8211 UDP.
• Выделенный сервер ограничен 32 местами, поэтому исчерпание слотов — самая дешёвая атака. Заданный ServerPassword против неё — самая действенная отдельная мера, ведь встроенного белого списка в Palworld нет.
• Локальные меры заканчиваются на канале: 1 Гбит/с — это 125 мегабайт в секунду, а при пакетах размером 64 байта туда помещается около 1,49 миллиона пакетов в секунду. Всё, что сверх этого, должно заканчиваться в сети перед сервером.
• В KernelHost двухуровневая постоянная защита входит в каждый серверный тариф без доплаты и активна с момента развёртывания, без null-routing. Advanced DDoS Protection с выделенным защищённым IP и самостоятельно управляемыми правилами по портам начинается от 50,00 € в месяц.

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