Защита игрового сервера от DDoS и абуза

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

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

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

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

Хитрее amplification-атаки: атакующий отправляет запрос на сторонний сервер с подменённым адресом жертвы, и тот отвечает уже ей. Классика это NTP, DNS и Memcached, которые отдают в разы больше данных, чем получили. Жертва тонет в чужом трафике, а источник атаки выглядит невиновным.

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

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

На Linux файрвол настраивается через iptables или ufw. Правила простые: разрешить игровые порты, ограничить остальное, поставить лимиты на скорость входящих соединений. Ограничение числа соединений с одного адреса отсекает часть простых атак и ботов.

Дальше rate limiting на уровне приложения: ограничьте частоту запросов к игровому серверу, особенно к query-порту, который отвечает на запросы статуса. Часто именно query-порт используют как усилитель атак, поэтому его стоит защитить в первую очередь.

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

То же с веб-панелями вроде 3X-UI, Marzban или txAdmin: их интерфейс не должен висеть в открытом интернете без защиты. Ставьте сильный пароль, двухфакторку, ограничение по IP. Одна утёкшая панель управления перечёркивает всю защиту сервера.

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

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

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

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

DDoS это не единственная угроза. Абуз со стороны игроков - читы, гриферство, оскорбления - убивает сервер медленнее, но вернее. Игроки уходят не от атак, а от токсичной среды.

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

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

Для серверов на Source-движке и не только стандарт администрирования это SourceBans: веб-панель, которая ведёт список банов, причину и срок. Баны из неё применяются на всех серверах сразу, что удобно для сети из нескольких миров.

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

Для прочих игр есть аналоги: плагины ведения банов и мутов с историей. Суть одна - централизованный список наказаний вместо хаотичных банов руками в консоли. Это экономит время администрации и делает наказания предсказуемыми.

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

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

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

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

Классическое применение это SSH: fail2ban банит адрес после нескольких неудачных попыток входа. Для игрового сервера важнее закрыть панель управления, RCON и query-порт. Настройте jail под логи панели: три неудачных логина за минуту, и адрес уходит в бан на час.

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

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

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

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

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

Минимальный набор это графики нагрузки у провайдера плюс проверка доступности порта каждые несколько минут. Простые инструменты вроде Uptime Kuma пингуют сервер и присылают сообщение в Telegram или Discord, когда он перестал отвечать.

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