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

Зачем firewall нужен на VPS с первого дня

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

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

Важно отличать firewall на уровне операционной системы от сетевого firewall, который некоторые провайдеры предлагают в панели управления VPS отдельно от сервера. Это не взаимоисключающие вещи — они работают на разных уровнях и обычно дополняют друг друга. Правила на уровне ОС остаются главным инструментом, потому что не зависят от конкретного провайдера и работают одинаково при переезде на другой сервер.

Как работает firewall на Linux-сервере

В основе большинства современных дистрибутивов Linux лежат iptables или его более новый аналог nftables — низкоуровневые инструменты фильтрации пакетов, которые работают напрямую с ядром системы. Настраивать их вручную можно, но это требует понимания цепочек правил, таблиц и порядка их применения.

Поэтому для типовых задач поверх iptables/nftables обычно ставят удобную надстройку: UFW (Uncomplicated Firewall) в Ubuntu и Debian, или firewalld в CentOS/AlmaLinux и других дистрибутивах на базе RHEL. Логика у них одинаковая: вы задаёте политику по умолчанию (обычно «запретить всё входящее») и затем разрешаете конкретные порты, которые действительно нужны.

Какой именно набор инструментов будет на вашем сервере, зависит от дистрибутива — если ещё не определились с выбором ОС или хотите разобраться в общей логике администрирования Linux-сервера, это отдельная тема, подробно раскрытая в статье про Linux на VPS. Дальше в этой статье разберём настройку на примере UFW — самого частого варианта на VPS с Ubuntu.

Какие порты стоит держать открытыми

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

Порт Сервис Стоит ли открывать
22 (или свой нестандартный) SSH Да, если нужен удалённый доступ к серверу. По возможности — ограничить конкретным IP
80 HTTP Да, если сайт или сервис должен быть доступен по обычному веб-протоколу
443 HTTPS Да, если используется TLS-сертификат (в большинстве случаев так и есть)
3306 / 5432 MySQL / PostgreSQL Как правило нет — приложение обращается к базе через localhost
21 FTP Лучше не открывать: протокол передаёт данные и пароль в открытом виде, вместо него — SFTP через SSH
25 / 587 / 465 SMTP Только если сервер сам отправляет почту как почтовый сервер, иначе не нужен

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

Как настроить firewall на VPS: пошаговая инструкция на UFW

Ниже — базовая настройка на примере UFW, актуальная для Ubuntu и Debian. Порядок шагов важен: правило для SSH добавляется до включения firewall, иначе есть риск потерять доступ к серверу.

1. Обновите систему. Это не обязательный, но разумный шаг перед любой настройкой сервера.

sudo apt update && sudo apt upgrade -y

2. Убедитесь, что UFW установлен. В Ubuntu он чаще всего уже есть в системе, но проверить не помешает.

sudo apt install ufw -y

3. Разрешите SSH до того, как включите firewall. Это самый важный шаг во всей настройке. Если пропустить его и сразу включить политику «запретить всё входящее», вы потеряете удалённый доступ к серверу и восстанавливать его придётся уже через консоль провайдера.

sudo ufw allow OpenSSH

Если SSH работает на нестандартном порту (что рекомендуется — подробнее об этом в статье про SSH-подключение к VPS), разрешайте именно его:

sudo ufw allow 2222/tcp

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

sudo ufw default deny incoming
sudo ufw default allow outgoing

5. Откройте порты, которые реально нужны. Для веб-сервера обычно достаточно HTTP и HTTPS:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Если на сервере установлен Nginx, у UFW есть готовый профиль, который сразу открывает оба порта:

sudo ufw allow "Nginx Full"

6. Включите firewall. Система предупредит, что это может повлиять на существующие SSH-соединения — если правило для SSH уже добавлено (шаг 3), подтверждайте смело.

sudo ufw enable

7. Проверьте статус и список правил.

sudo ufw status verbose

8. Проверьте доступ в новой сессии. Не закрывайте текущее SSH-подключение сразу после включения firewall. Откройте новое окно терминала и убедитесь, что подключение к серверу по-прежнему работает. Если что-то настроено неправильно, старая сессия останется рабочей и позволит исправить правила без обращения в поддержку.

Firewall через iptables и nftables: когда это нужно

UFW и firewalld закрывают подавляющее большинство типовых сценариев на VPS. Прямая работа с iptables или nftables имеет смысл, если нужны сложные условия — например, тонкая фильтрация по диапазонам адресов, ограничение количества соединений в единицу времени или нестандартные цепочки правил, которые не укладываются в простые команды allow/deny.

Это более мощный, но и более требовательный к аккуратности инструмент: ошибка в правиле iptables может закрыть доступ не только злоумышленникам, но и вам самим. Если тема администрирования Linux-сервера в целом новая, разумнее начать с UFW или firewalld, а к iptables/nftables возвращаться по мере роста требований — общий обзор инструментов Linux-сервера есть в статье про Linux VPS.

Практические сценарии настройки firewall

Небольшой сайт на Nginx или Apache. Открыты только SSH, 80 и 443. Всё остальное — включая порт СУБД, если она стоит на этом же сервере, — закрыто снаружи и доступно только через localhost.

Интернет-магазин с админ-панелью. Публичные порты те же (80/443), но если есть отдельная админ-панель на нестандартном порту, логично ограничить доступ к ней конкретным IP-адресом или диапазоном, а не открывать всем:

sudo ufw allow from 203.0.113.10 to any port 8443

VPN-сервер. Здесь набор портов обычно минимальный и специфичный для протокола — например, один UDP-порт для WireGuard плюс SSH для администрирования. Веб-порты 80/443, если на сервере нет отдельного сайта, открывать не нужно.

Telegram-бот или API-сервис без публичного сайта. Часто достаточно открыть только порт, на котором бот принимает вебхуки (если используется такая схема) или который нужен для API, плюс SSH. Порты 80/443 без реального веб-сервера на них лучше не открывать «про запас».

Тестовый или staging-сервер. Как правило, наблюдается меньше внимания к нему, чем к production, а значит и риск выше. Здесь особенно уместно ограничить SSH по конкретному IP, если у вас статический адрес, а не оставлять его открытым для всего интернета.

Типичные ошибки при настройке firewall на VPS

  • Включить deny incoming, забыв разрешить SSH. Самая частая причина потери доступа к серверу у новичков.
  • Открывать порты «на всякий случай». Каждый лишний открытый порт — это лишняя точка проверки для сканеров, а не запас на будущее.
  • Не проверять правила отдельной сессией. Закрыть текущее подключение сразу после ufw enable — рискованная привычка, даже если кажется, что всё настроено правильно.
  • Оставлять базу данных доступной извне. Порт СУБД, открытый на весь интернет с одним лишь паролем в качестве защиты, — частая причина взлома.
  • Считать firewall полной защитой сервера. Это один из слоёв, а не единственная мера — полный чек-лист базовых шагов собран в статье про безопасность VPS.
  • Не следить за попытками подключения. Firewall блокирует нежелательные соединения, но если не смотреть логи и не отслеживать всплески активности, можно пропустить признаки атаки — за этим удобно следить через инструменты, описанные в статье про мониторинг VPS.
  • Забыть про firewall при первой настройке сервера. Если базовая защита не входит в чек-лист сразу после получения доступа к VPS, есть риск, что сервер какое-то время проработает вообще без фильтрации — как выстроить порядок действий с самого начала, показано в статье про первую настройку VPS.

Firewall и SSH: о чём важно помнить

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

FAQ по firewall на VPS

Нужен ли firewall, если у провайдера уже есть защита от DDoS?

Защита от DDoS на уровне провайдера работает с объёмом и характером трафика на сети, а firewall на самом сервере решает, какие порты и сервисы вообще видны извне. Это разные уровни, и они не заменяют друг друга.

Можно ли потерять доступ к серверу, включив firewall?

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

Чем UFW отличается от iptables?

UFW — упрощённый интерфейс поверх iptables/nftables для типовых задач: открыть или закрыть порт, задать политику по умолчанию. iptables и nftables дают полный контроль над правилами, но требуют больше знаний и аккуратности.

Нужно ли открывать порт базы данных, если сайт и БД на одном сервере?

Обычно нет. Если приложение и СУБД работают на одном VPS, обращение идёт через localhost, и внешний доступ к порту базы не требуется.

Как проверить, какие порты открыты на сервере?

Проще всего — команда статуса firewall на самом сервере (например, sudo ufw status verbose). Для проверки со стороны интернета используется сканирование портов с другого устройства.

Нужен ли firewall, если на сервере уже настроен VPN?

Да. VPN шифрует и туннелирует трафик между точками, но не решает задачу фильтрации по портам на самом сервере — это разные механизмы защиты.

Итог

Firewall на VPS — это не разовая настройка «для галочки», а базовый слой защиты, который стоит включать сразу после получения доступа к серверу: закрыто по умолчанию, открыто только то, что действительно используется, и обязательно с проверенным доступом по SSH до включения строгих правил. Дальше эту защиту логично дополнить остальными шагами базовой безопасности сервера.