Защита серверов RAGE MP и alt:V от DDoS-атак

Сервер GTA-мультиплеера — благодарная цель для атакующих: он висит на одном-единственном IP-адресе, его порт стоит в публичном списке серверов, а любой перебой видят сразу все игроки. Эта статья сначала показывает, чего вы действительно можете добиться на собственном сервере, а затем так же честно объясняет, где эти возможности заканчиваются.

Если вы пока не уверены, идёт ли вообще атака, сначала измерьте это: статья Как определить DDoS-атаку разбирает диагностику шаг за шагом. Техническая основа описана в статье Что такое DDoS-атака.

Почему под удар так часто попадают именно RAGE MP и alt:V

Ролевая сцена вокруг GTA V маленькая, публичная и очень конкурентная. Сервер живёт за счёт постоянных игроков, а они при затяжных перебоях быстро оказываются в чужом Discord. Именно это делает атаки привлекательными: успех на часы никому не нужен, хватает нескольких минут в прайм-тайм, вечером открытия или во время объявленного вайпа.

К этому добавляется то, что искать никому не приходится. Обе платформы по желанию регистрируют ваш сервер в публичном списке: RAGE MP через announce в conf.json, alt:V через announce и token в server.toml. Кто попал в этот список, тот опубликовал свой IP-адрес и порт. Поэтому только что добавленный сервер нередко получает первые автоматические попытки соединения уже в первый час, задолго до появления первого настоящего игрока.

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

О каких портах идёт речь

Прежде чем писать первое правило, стоит понимать, какой порт для чего нужен. Обеим платформам одного порта мало.

Здесь важны две особенности. У RAGE MP порт HTTP жёстко привязан к игровому и всегда на единицу больше: перенесёте игровой порт на 22015, файловый уедет на 22016. У alt:V игровой трафик и раздача файлов делят один и тот же номер порта, один раз по UDP и один раз по TCP. Кто раздаёт файлы клиента через сеть доставки контента (параметры useCdn и cdnUrl в server.toml), тот убирает TCP-часть со своего канала. Игрового трафика по UDP это не касается.

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

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

Шаг 1: инвентаризация, что слушает наружу

ss -tulnp

Интересен столбец с локальным адресом. Всё, что стоит там на 0.0.0.0 или [::], доступно из интернета, всё на 127.0.0.1 только локально. На типичном ролевом сервере рядом с самой игрой быстро обнаруживаются база данных, кеш, веб-панель, а иногда и голосовой сервер. Каждая такая служба — отдельная поверхность атаки, и ни одна из них не обязана быть открытой только потому, что она запущена.

Шаг 2: ограничение файрвола до реально нужных портов

Для сервера RAGE MP это три разрешения: SSH, игровой порт и файловый порт. В любом случае сначала разрешите свой порт SSH, иначе последней строкой вы закроете доступ самому себе:

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 22005/udp
ufw allow 22006/tcp
ufw enable

Для alt:V оба игровых правила выглядят иначе:

ufw allow 7788/udp
ufw allow 7788/tcp

После этого проверьте командой ufw status verbose, действительно ли открыты только эти порты, и повторите ss -tulnp. Подробная настройка вместе с IPv6 и типичными ловушками, из-за которых можно потерять доступ, описана в статье Настройка файрвола UFW.

Шаг 3: убрать базу данных и кеш из сети

В большинстве гейммодов MariaDB и Redis работают на той же машине, что и игровой сервер, и адрес в интернете им тогда не нужен. В конфигурацию MariaDB (в Debian и Ubuntu это /etc/mysql/mariadb.conf.d/50-server.cnf) для этого добавляется строка:

bind-address = 127.0.0.1

А в /etc/redis/redis.conf:

bind 127.0.0.1 ::1
protected-mode yes

Затем перезапустите обе службы и проверьте результат командой ss -tulnp. Открытый кеш без пароля — это не проблема DDoS, а путь для взлома, и сканируют его круглосуточно.

Шаг 4: ограничение частоты соединений на файловом порту

Порт TCP для файлов клиента — как раз то место, где ограничение частоты на сервере действительно работает: здесь соединение устанавливается по-настоящему, а значит, есть адрес отправителя, которому можно более или менее доверять. Хватает двух правил, здесь для RAGE MP на порту 22006:

iptables -A INPUT -p tcp --dport 22006 --syn -m connlimit --connlimit-above 20 --connlimit-mask 32 -j DROP
iptables -A INPUT -p tcp --dport 22006 --syn -m hashlimit --hashlimit-name gtahttp --hashlimit-mode srcip --hashlimit-above 30/sec --hashlimit-burst 60 -j DROP

Первое правило ограничивает число одновременно открытых соединений с одного адреса источника, второе — число попыток соединения в секунду. Для alt:V в обоих местах подставьте 7788. Три замечания к этому: ufw limit здесь слишком груб и умеет только TCP, числовые значения подгоняйте под размер своих файлов клиента, а сами правила переживут перезагрузку только вместе с iptables-persistent или как запись в /etc/ufw/before.rules.

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

cat /proc/sys/net/netfilter/nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max

Когда первое значение приближается ко второму, ядро отбрасывает пакеты независимо от того, относятся они к атаке или к игроку. В системном логе тогда появляется nf_conntrack: table full, dropping packet.

Шаг 5: использовать встроенные средства обеих платформ

В обоих серверных ядрах есть настройки, придуманные ровно против злоупотребления соединениями, и по умолчанию они стоят на самом свободном значении. У RAGE MP это касается трёх ключей в conf.json:

{
    "bind": "0.0.0.0",
    "port": 22005,
    "announce": true,
    "maxplayers": 200,
    "disallow-multiple-connections-per-ip": true,
    "limit-time-of-connections-per-ip": 1000,
    "enable-http-security": true
}

Это фрагмент, остальные ключи остаются без изменений. disallow-multiple-connections-per-ip запрещает несколько одновременных соединений с одного адреса, limit-time-of-connections-per-ip задаёт минимальный интервал между двумя попытками соединения (0 отключает ограничение), а enable-http-security включает дополнительные проверки встроенного HTTP-сервера. Единицу измерения времени у среднего значения сверьте с документацией своей версии сервера, прежде чем его повышать. И учтите, что первый параметр отсекает соигроков за одним и тем же подключением, то есть соседей по общей квартире, членов одной семьи и корпоративные сети.

У alt:V соответствующие параметры находятся в server.toml:

host = '0.0.0.0'
port = 7788
players = 200
announce = true
duplicatePlayers = 4
connectionQueue = true
useEarlyAuth = true

duplicatePlayers ограничивает, сколько игроков с одного IP-адреса могут быть подключены одновременно. Значение по умолчанию равно 4096, то есть практически никакого предела. connectionQueue ставит попытки соединения в очередь вместо того, чтобы обрабатывать их все разом. useEarlyAuth ставит перед игровым сервером вход: клиент должен войти, прежде чем попадёт в ваш игровой мир, и это сразу отсеивает простые потоки соединений. Адрес страницы входа задаётся в earlyAuthUrl.

Шаг 6: белый список, пока горит

Если атака идёт через игровую механику, то есть через массовые попытки соединения, а не через чистую пропускную способность, белый список остаётся самым действенным краткосрочным средством. У alt:V для закрытого режима достаточно уже одного password в server.toml. Программно простейший вариант выглядит так, здесь для RAGE MP:

const whitelist = new Set(['ИгрокОдин', 'ИгрокДва']);

mp.events.add('playerJoin', (player) => {
    if (!whitelist.has(player.name)) {
        player.kick('Сервер сейчас закрыт.');
    }
});

И та же логика для alt:V:

import * as alt from 'alt-server';

const whitelist = new Set(['ИгрокОдин', 'ИгрокДва']);

alt.on('playerConnect', (player) => {
    if (!whitelist.has(player.name)) {
        player.kick('Сервер сейчас закрыт.');
    }
});

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

Шаг 7: запись в списке серверов и гигиена IP-адреса

Отключить запись в списке серверов (announce в false) звучит как быстрое решение, но им обычно не является. У кого ваш IP-адрес уже есть, тот доберётся до вас и дальше, а вот игроки вас больше не найдут. Смысл этот шаг приобретает только вместе со сменой IP-адреса: лишь тогда атакующий теряет свою цель.

В долгую больше пользы от чистоты в тех местах, где адрес всплывает попутно: сайт и форум держите на другой машине, старые записи DNS удаляйте (в том числе mail, ftp и тестовые имена с самого начала), Discord-ботов и статусные табло не запускайте с игрового сервера, голосовой сервер выносите отдельно. Полностью спрятать адрес игрового сервера всё равно не выйдет: игровой трафик по UDP должен приходить прямо к вам, и поставленная перед сайтом сеть доставки контента этого не меняет. Помогает здесь не маскировка, а адрес, за которым стоит фильтрация.

Шаг 8: собрать измерения, пока не стало серьёзно

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

IF=$(ip -o route get 1.1.1.1 | awk '{print $5}')
A=$(cat /sys/class/net/$IF/statistics/rx_packets) || exit 1; sleep 1; B=$(cat /sys/class/net/$IF/statistics/rx_packets); echo "$((B-A)) пакетов/с входящих на $IF"
ss -s

Запишите эти значения один раз в обычном режиме в прайм-тайм: без опорного значения любое число во время атаки бесполезно. Если ваш игровой сервер работает как служба systemd, к этому набору относится journalctl -u <имя-службы> -n 200: потоки соединений оставляют там, как правило, отчётливый след. Одно ограничение знать обязательно: внутри сервера вы измеряете только то, что до него дошло. Если перед ним стоит фильтрация, достоверное число находится в графике трафика в личном кабинете, а не в /proc.

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

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

Порядки величин такие: отдельный сервер обычно подключён на 1 Гбит/с. При самых мелких пакетах это примерно 1,5 миллиона пакетов в секунду, больше физически не пролезет. Чтобы забить такой канал, рекордная атака никому не нужна, хватает 2-5 Гбит/с. Для сравнения реально измеренная атака во франкфуртской сети KernelHost: более 473,4 Гбит/с и более 41,5 миллиона пакетов в секунду на одну-единственную службу. Это примерно в 470 раз больше гигабитного канала, и даже подключение на 10 Гбит/с отстаёт от этого в 47 раз.

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

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

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

Постоянная защита, которая уже работает на каждом сервере

В KernelHost (KernelHost GmbH, головной офис в Вене, Австрия) на каждом сервере постоянно активна двухуровневая защита от DDoS: без заказа, без настройки и без доплаты:

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

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

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

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

• выделенный защищённый IP из франкфуртского ядра, на который переключается ваш сервер, без переделок с вашей стороны,
• правила защиты, которыми вы управляете сами, по портам и протоколам, прямо в личном кабинете,
• изменения, которые применяются в реальном времени, без тикета и без ожидания,
• профиль защиты под конкретную игру, из более чем 40 профилей для игр, сервисов и протоколов, среди которых RageMP и alt:V, плюс общие профили для собственных TCP- и UDP-приложений.

Практическая разница в контроле: вы сами решаете, какой профиль работает на 22005 UDP и какое правило действует для 22006 TCP, в том числе прямо посреди атаки.

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

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

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

Блокируются IP-адреса атакующих: при UDP-потоке отправители подделаны. Так вы блокируете непричастные адреса, а в худшем случае собственных игроков. Смысл в этом есть только на соединениях TCP с полным установлением связи, то есть на файловом порту.

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

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

Больше CPU и больше RAM как ответ на DDoS: и то и другое помогает против перегруженного гейммода, а не против забитого канала. Узкое место находится перед сервером, и там более мощное железо ничего не меняет.

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

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

Если это происходит прямо сейчас

Сначала соберите измерения из шага 8, чтобы ваше обращение было убедительным: время с указанием часового пояса, затронутый IP-адрес и порт, измеренная частота пакетов с указанием направления. После этого создайте тикет в поддержку. При идущей атаке с нами можно связаться дополнительно через экстренный чат в WhatsApp по номеру +43 650 8209883. Независимый от провайдера обзор дальнейших шагов даёт статья Защита сервера от DDoS-атак.