Настройка портов и файрвола для игрового сервера

MAATRIX GAMES

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

Зачем вообще закрывать порты, если сервер и так работает

Логика "работает — не трогай" тут не работает. По умолчанию на свежей VPS или выделенном сервере часто открыто больше, чем нужно: SSH на 22 порту без ограничений, иногда панель управления хостингом, иногда остатки сервисов от предыдущей настройки. Каждый открытый порт — это точка входа для сканеров, которые круглосуточно прощупывают весь интернет в поисках уязвимых сервисов. Боты не выбирают жертву осознанно — они сканируют диапазоны IP и стучатся во всё подряд.

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

• игровой порт (или несколько — у некоторых игр отдельно порт запроса статуса и порт данных);
• RCON-порт, если вы им пользуетесь для удалённого администрирования (см. подключение по RCON и основные команды);
• SSH-порт для администрирования самого хоста.

Всё остальное — закрыто по умолчанию, включая исходящие правила, если хотите совсем строгую конфигурацию (хотя для большинства игровых серверов достаточно ограничить входящий трафик).

TCP или UDP — не перепутайте, это критично

Частая ошибка новичков: открыть порт как TCP, хотя игра слушает его по UDP (или наоборот), и потом полчаса недоумевать, почему сервер "не виден" снаружи, хотя процесс явно запущен и в логах ошибок нет.

Разница простыми словами: TCP — с подтверждением доставки каждого пакета, чуть медленнее, зато надёжнее (используется там, где важна целостность данных — например, RCON, HTTP-запросы, некоторые панели статуса). UDP — без подтверждений, быстрее, с допустимой потерей части пакетов — то, что нужно для реального игрового трафика в реальном времени, где свежий пакет важнее гарантированной доставки старого.

Большинство игровых протоколов на выживание/шутеры используют UDP для основного игрового трафика:

Таблица — ориентир по типовым портам из документации и практики, но версия игры и конкретный конфиг сервера могут менять номера портов и добавлять дополнительные (например, отдельный порт для RCON или для Steam query). Уточняйте актуальные значения в конфиге вашей сборки перед тем, как открывать правила — не переносите таблицу бездумно.

Если сомневаетесь — откройте оба протокола на конкретном порту на время диагностики, посмотрите через ss, какой трафик реально идёт (см. ниже), а потом сузьте правило до нужного протокола. Держать оба открытыми "на всякий случай" постоянно — это лишняя поверхность атаки без пользы.

Настройка через ufw (Ubuntu/Debian)

ufw (Uncomplicated Firewall) — обёртка над iptables, которая проще читается и меньше шансов накосячить в правилах. Если у вас Ubuntu или Debian, это разумный выбор по умолчанию.

Сначала — базовая политика: всё входящее запрещено, всё исходящее разрешено (обычно этого достаточно):

sudo ufw default deny incoming
sudo ufw default allow outgoing

Дальше открываем SSH — обязательно до включения ufw, иначе рискуете сами себя запереть на удалённом сервере:

sudo ufw allow 22/tcp
# если SSH перевешен на нестандартный порт (что рекомендуется) — укажите его
sudo ufw allow 2222/tcp

Игровой порт, например для Rust (UDP):

sudo ufw allow 28015/udp
sudo ufw allow 28016/tcp comment 'rust rcon web'

Для Minecraft Java:

sudo ufw allow 25565/tcp

RCON-порт, если открываете доступ снаружи (лучше ограничить по IP, см. ниже):

sudo ufw allow from 203.0.113.10 to any port 28016 proto tcp

Последняя команда — как раз пример "точечной" настройки: доступ к RCON разрешён только с конкретного IP-адреса вашего рабочего компьютера, а не всему интернету. Это сильно снижает риск, что кто-то подберёт пароль RCON перебором — подробнее про сами команды RCON в статье про RCON-подключение.

После настройки правил включаем файрвол и проверяем статус:

sudo ufw enable
sudo ufw status verbose

Вывод покажет список правил с портами, протоколами и источниками — сверьте его с тем, что реально должно быть открыто.

Настройка через iptables (когда нужен более гибкий контроль)

Если дистрибутив не предлагает ufw по умолчанию (CentOS, некоторые минимальные образы) или нужна более тонкая настройка (лимиты на количество подключений, защита от SYN-флуда на уровне файрвола), берём iptables напрямую.

Базовая политика — тоже "запретить всё, разрешить нужное":

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

Разрешаем уже установленные соединения (без этого правила вообще ничего работать не будет, включая ответы на ваши же запросы):

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

SSH:

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

Игровой порт (пример для ARK, UDP):

iptables -A INPUT -p udp --dport 7777 -j ACCEPT
iptables -A INPUT -p udp --dport 7778 -j ACCEPT
iptables -A INPUT -p udp --dport 27015 -j ACCEPT

RCON, ограниченный конкретным IP:

iptables -A INPUT -p tcp -s 203.0.113.10 --dport 27020 -j ACCEPT

Правила iptables не сохраняются между перезагрузками сами по себе — на Debian/Ubuntu ставим iptables-persistent:

sudo apt install iptables-persistent
sudo netfilter-persistent save

На CentOS/RHEL обычно проще через firewalld (firewall-cmd --add-port=7777/udp --permanent), но принцип тот же — точечное разрешение вместо широких диапазонов.

Проверка, что реально открыто

Настроили правила — не значит, что всё именно так, как задумано. Опечатка в порту, забытое старое правило, конфликт между ufw и iptables (если оба когда-то трогали руками) — типичные причины расхождения "думаю, что открыто" и "реально открыто".

Изнутри сервера смотрим, какие процессы слушают какие порты:

ss -tulnp

Флаги: -t TCP, -u UDP, -l слушающие сокеты, -n показывать порты числом, -p — с именем процесса (нужны права root, иначе имя процесса не покажется). В выводе ищите строку с портом вашего сервера и убедитесь, что слушает именно тот процесс, который должен (например, srcds_run для CS2, java для Minecraft).

Старый добрый netstat -tulnp делает то же самое, если ss почему-то не установлен, но ss сейчас стандарт и работает быстрее на больших системах.

Снаружи — то, что видно всему интернету, а не только локально — проверяется через nmap с другой машины (со своего компьютера, не с самого сервера):

nmap -sS -p 22,25565,28015 your.server.ip

Это покажет реальную картину: что видит потенциальный сканер снаружи, а не то, что вы думаете, что открыли. Если порт, который вы закрывали, всё ещё виден снаружи как open — где-то в правилах ошибка, либо не сохранились после перезагрузки, либо хостер держит отдельный файрвол на уровне сети (у части VPS-провайдеров есть панель Security Groups поверх ОС — не забывайте проверить и её).

Типичная ошибка: диапазон портов "про запас"

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

Во-первых, лишняя поверхность атаки — каждый открытый порт теоретически может стать вектором для последующей уязвимости в софте, который вы туда посадите (сегодня там игровой сервер, завтра забыли и подняли что-то ещё для теста — а порт уже открыт файрволом).

Во-вторых, это часто маскирует реальную проблему конфигурации. Если сервер не запускается на ожидаемом порту, открытие диапазона "чтобы заработало" не чинит причину — а причина обычно в конфиге самой игры (server.cfg, startup parameters, переменные окружения) или в NAT/проброс портов на роутере, если сервер стоит дома, а не на VPS.

Правильный подход — определить точный список портов из документации игры или конфига сборки, открыть именно их, и если что-то не работает — сначала ss -tulnp на сервере (слушает ли процесс порт вообще), потом nmap снаружи (виден ли порт из интернета), и только по результатам этой диагностики менять правила файрвола точечно.

Если сервер стоит за домашним роутером, добавляется ещё один слой — проброс портов (port forwarding) на самом роутере, отдельно от файрвола ОС. Оба уровня должны совпадать по портам и протоколам, иначе трафик до ОС просто не дойдёт, а файрвол окажется ни при чём. Для домена, привязанного к серверу, полезно заодно свериться со статьёй про кастомный домен и SRV-запись — там как раз про то, как игроки находят сервер по имени вместо голого IP.

Что делать после настройки: не забыть про SSH и логи

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

• перенести SSH на нестандартный порт (не панацея, но резко снижает шум от автоматических сканеров);
• поставить fail2ban — он банит IP после нескольких неудачных попыток входа, автоматически добавляя правило в файрвол;
• отключить вход по паролю в пользу SSH-ключей (PasswordAuthentication no в /etc/ssh/sshd_config);
• ограничить RCON-доступ конкретными IP, как показано выше, а не оставлять его открытым всему интернету.

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

Частые вопросы