UFW или nftables на Ubuntu VPS: базовая политика firewall и проверка правил

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

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

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

Разберем безопасную базовую политику для Ubuntu VPS: как выбрать между UFW и nftables, сохранить удаленный доступ, открыть только необходимые сервисы и проверить результат с нескольких сторон.

UFW и nftables: что именно мы настраиваем

Фильтрацию сетевого трафика в Linux выполняет подсистема Netfilter. Поверх нее работают инструменты, которыми администратор создает правила.

Упрощенно схема выглядит так:

Входящий сетевой пакет
          │
          ▼
     Linux Netfilter
          │
     ┌────┴─────┐
     │          │
    UFW      nftables
     │          │
простое      прямое
управление   управление
правилами    ruleset

Для большинства обычных VPS с SSH, веб-сервером и несколькими открытыми портами удобнее начать с UFW. Его синтаксис проще читать и сопровождать.

Прямое управление через nftables имеет смысл, когда нужны:

• более сложные цепочки правил;
• sets и maps;
• разная логика для нескольких интерфейсов;
• маршрутизация и фильтрация forwarding-трафика;
• нестандартная обработка пакетов;
• единый ruleset, которым администратор хочет управлять напрямую.

Перед изменением firewall: как не потерять SSH

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

Поэтому перед первым изменением нужно выяснить, на каком порту SSH действительно принимает соединения.

Проверить слушающие TCP-порты можно так:

sudo ss -lntp

В выводе найдите процесс SSH и адрес, на котором он слушает.

Например:

LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=742,fd=3))
LISTEN 0 128 [::]:22    [::]:*    users:(("sshd",pid=742,fd=4))

В этом примере SSH использует 22/tcp.

Если сервер настроен на другой порт, например 2222, в правилах firewall нужно разрешать именно его.

Перед дальнейшей настройкой полезно:

• открыть вторую SSH-сессию и оставить первую подключенной;
• не закрывать рабочий терминал, пока правила не проверены;
• убедиться, что у VPS есть альтернативный способ доступа через консоль провайдера;
• сохранить текущую конфигурацию firewall, если сервер уже работает в production.

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

Базовая настройка firewall через UFW

UFW подходит для большинства типовых Ubuntu VPS. Для обычного веб-сервера удобно начать с простой политики:

• входящие соединения запрещены по умолчанию;
• исходящие соединения разрешены;
• необходимые входящие сервисы открываются отдельными правилами.

Проверяем текущее состояние

sudo ufw status verbose

Если firewall еще не включен, можно получить:

Status: inactive

Задаем политику по умолчанию

sudo ufw default deny incoming
sudo ufw default allow outgoing

После этих команд не нужно сразу включать UFW. Сначала разрешим рабочий SSH-порт.

Разрешаем SSH

Если SSH работает на стандартном порту 22:

sudo ufw allow 22/tcp

Если используется другой порт, например 2222:

sudo ufw allow 2222/tcp

Число 2222 здесь только пример. Нужно подставить фактический порт сервера.

Если администратор всегда подключается с постоянного внешнего IP, SSH можно дополнительно ограничить по источнику:

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

Адрес 203.0.113.10 нужно заменить своим.

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

Открываем HTTP и HTTPS

Если VPS размещает обычный сайт:

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

Не нужно открывать остальные порты «на всякий случай».

Например, наличие PostgreSQL на сервере само по себе не означает, что порт 5432 должен быть доступен из Интернета. Если веб-приложение и база находятся на одном VPS, СУБД часто достаточно слушать локальный интерфейс.

То же относится к Redis, административным панелям и другим внутренним сервисам.

Включаем UFW

Перед включением еще раз убедитесь, что правило для рабочего SSH-порта уже добавлено.

sudo ufw enable

UFW предупредит, что команда может повлиять на существующие SSH-соединения. Если нужное правило уже создано, подтверждаем включение.

Затем проверяем:

sudo ufw status verbose

Например:

Status: active
Default: deny (incoming), allow (outgoing), disabled (routed)

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
80/tcp                     ALLOW       Anywhere
443/tcp                    ALLOW       Anywhere

После этого не закрывайте текущую SSH-сессию. Сначала попробуйте открыть новое подключение.

Смотрим правила с номерами

sudo ufw status numbered

Например:

[ 1] 22/tcp                     ALLOW IN    Anywhere
[ 2] 80/tcp                     ALLOW IN    Anywhere
[ 3] 443/tcp                    ALLOW IN    Anywhere

После этого конкретное правило можно удалить по номеру:

sudo ufw delete 2

Когда нужен nftables

Для простого VPS прямое управление nftables часто избыточно. Но если инфраструктура сложнее или администратор хочет сам контролировать полный ruleset, этот вариант дает больше возможностей.

Минимальная политика для обычного VPS может выглядеть так:

table inet filter
└─ chain input
   ├─ loopback → accept
   ├─ established, related → accept
   ├─ ICMP / ICMPv6 → accept
   ├─ SSH → accept
   ├─ HTTP → accept
   ├─ HTTPS → accept
   └─ остальное → drop

Использование семейства inet удобно тем, что одна таблица может обрабатывать IPv4 и IPv6.

Пример минимальной конфигурации:

table inet filter {
    chain input {
        type filter hook input priority 0;
        policy drop;

        iifname "lo" accept

        ct state established,related accept

        ip protocol icmp accept
        ip6 nexthdr icmpv6 accept

        tcp dport 22 accept
        tcp dport { 80, 443 } accept
    }

    chain forward {
        type filter hook forward priority 0;
        policy drop;
    }

    chain output {
        type filter hook output priority 0;
        policy accept;
    }
}

Здесь 22 снова является только примером стандартного SSH-порта.

Почему нельзя бездумно блокировать ICMPv6

ICMP иногда воспринимают только как протокол для команды ping и пытаются полностью запретить его.

Для IPv6 это особенно опасно: ICMPv6 участвует не только в диагностике, но и в работе самого сетевого стека. Поэтому базовый ruleset не должен без причины блокировать весь ICMPv6.

Проверяем конфигурацию до применения

Если ruleset сохранен, например, в файле /etc/nftables.conf, сначала проверьте синтаксис без фактического изменения активных правил:

sudo nft --check --file /etc/nftables.conf

Если команда не выводит ошибок, конфигурацию можно применить:

sudo nft --file /etc/nftables.conf

После применения сразу проверьте вторую SSH-сессию.

Просматриваем фактический ruleset

sudo nft list ruleset

Эта команда показывает правила, которые действительно загружены в систему. Это важнее, чем смотреть только содержимое конфигурационного файла: файл и текущий ruleset могут отличаться.

Как проверить, что firewall действительно работает

Проверка firewall не заканчивается командой ufw status или nft list ruleset.

Нужно проверить три разных состояния:

1. какая служба слушает порт;
2. разрешает ли соединение firewall;
3. доступен ли сервис фактически снаружи.

Проверяем, что слушает сервер

sudo ss -lntup

Например:

LISTEN 0 4096 0.0.0.0:22  0.0.0.0:*
LISTEN 0 511  0.0.0.0:80  0.0.0.0:*
LISTEN 0 511  0.0.0.0:443 0.0.0.0:*

Разрешенный порт в firewall еще не означает, что сервис действительно работает. На нем должен быть процесс, который принимает соединения.

Если UFW разрешает 443/tcp, но ни один процесс не слушает 443, HTTPS работать не будет.

И наоборот: приложение может слушать порт, но firewall не позволит обратиться к нему извне.

Проверяем UFW

sudo ufw status numbered

Для более подробного состояния:

sudo ufw status verbose

Смотрите не только на отдельные правила ALLOW, но и на политику по умолчанию.

Проверяем nftables

sudo nft list ruleset

Если сервер сложный, обратите внимание не только на собственную таблицу inet filter, но и на другие таблицы, которые могли создать контейнеры, VPN или дополнительные сервисы.

Проверяем порт с другой машины

Это принципиально важный шаг.

Проверка localhost:443 показывает только локальную доступность сервиса. Она не подтверждает прохождение входящего трафика из Интернета.

С другой Linux-машины можно проверить SSH:

nc -vz server.example.com 22

Для HTTPS:

curl -I https://server.example.com

Если SSH использует нестандартный порт:

nc -vz server.example.com 2222

Проверять лучше с внешнего узла, путь от которого похож на реальное подключение пользователя.

Типичные ошибки, безопасный откат и итоговая политика firewall

Сначала включили deny, а потом вспомнили про SSH

Если текущая SSH-сессия еще работает, не закрывайте ее.

Для UFW сначала добавьте правильное правило для фактического SSH-порта. Например, для 22/tcp:

sudo ufw allow 22/tcp

Затем проверьте новое SSH-подключение.

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

sudo ufw disable

Открыли административный сервис всему Интернету

Типичный пример — база данных:

sudo ufw allow 5432/tcp

Такая команда разрешает соединения на PostgreSQL с любого источника, если другие правила не ограничивают трафик.

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

sudo ufw allow from 203.0.113.10 to any port 5432 proto tcp

Но сначала стоит решить, нужен ли публичный доступ к СУБД вообще. Во многих схемах приложение и база взаимодействуют по локальной или приватной сети.

Порт разрешен, но приложение слушает только localhost

Допустим, firewall разрешает 8080/tcp, но команда:

sudo ss -lntp

показывает:

127.0.0.1:8080

В этом случае приложение принимает соединения только с локального хоста. Изменение UFW не заставит сервис слушать внешний интерфейс — нужно разбираться с конфигурацией самого приложения.

Одновременно меняют UFW и nftables вручную

Сервер при этом не обязательно сразу перестанет работать, но сопровождать такую схему становится сложнее.

Администратор может выполнить:

sudo ufw status

и решить, что видит полную политику, хотя часть правил была добавлена напрямую через nftables.

Для обычного VPS лучше выбрать один основной способ управления firewall и придерживаться его.

Настроили только IPv4

Если сервер имеет публичный IPv6, нужно учитывать оба сетевых стека.

Особенно опасна ситуация, когда администратор тщательно закрыл IPv4-порт, но тот же сервис остается доступен по IPv6.

После настройки проверяйте слушающие IPv6-сокеты той же командой:

sudo ss -lntup

И отдельно тестируйте внешний доступ по IPv6, если он используется.

Docker опубликован на порт, а UFW показывает, что порт закрыт

Это отдельный случай. Docker создает собственные правила фильтрации и NAT для опубликованных контейнерных портов.

Например:

docker run -p 8080:80 ...

Такой контейнер может оказаться доступным извне не так, как ожидает администратор, ориентируясь только на вывод UFW.

Подробнее production-схему контейнеров мы разобрали в статье «Docker на Linux VPS: production-развертывание, сеть, тома, HTTPS, обновления и резервное копирование».

Какую политику firewall использовать на обычном VPS

Для типового веб-сервера безопасная стартовая логика выглядит так:

Входящие:
SSH       → разрешить только если нужен
HTTP      → разрешить для веб-сервера
HTTPS     → разрешить для веб-сервера
Остальное → запретить

Исходящие:
разрешить

Внутренние сервисы:
не публиковать без необходимости

Это не универсальный ruleset для любого сервера. VPN-шлюз, Docker-host, почтовый сервер, DNS-сервер, Kubernetes-узел или маршрутизатор потребуют другой политики.

Но для обычного VPS с сайтом подход «deny by default + явно разрешенные сервисы» проще контролировать, чем длинный список случайно накопленных исключений.

Заключение

UFW и nftables решают одну базовую задачу — позволяют управлять сетевой политикой Linux-сервера, но находятся на разных уровнях сложности.

Для обычного Ubuntu VPS чаще достаточно UFW: правила легко читать, добавлять и удалять, а базовая схема с запретом входящих соединений и явным разрешением SSH, HTTP и HTTPS покрывает большинство простых веб-серверов.

Прямой nftables оправдан, когда правила становятся сложнее: появляются несколько интерфейсов, собственные sets, forwarding, маршрутизация или нетипичная сетевая логика.

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

Что почитать дальше

• Первичная настройка Ubuntu VPS после заказа — SSH, обновления, firewall и базовая подготовка системы.
• Docker на Linux VPS: production-развертывание — сеть, опубликованные порты, HTTPS, тома и эксплуатация контейнеров.
• Безопасность VPS: как защитить сервер, сайты и данные — общий hardening Linux-сервера и снижение поверхности атаки.
• Как подключиться к Linux VPS по SSH — SSH-порт, ключи, fingerprint и безопасная проверка доступа перед изменением сетевых правил.

Когда стоит обратиться к специалистам

С базовым UFW на новом веб-сервере обычно можно разобраться самостоятельно. Сложнее становится, когда сервер уже работает в production и на нем одновременно используются Docker, VPN, несколько сетевых интерфейсов, нестандартные маршруты или сервисы, доступные только отдельным подсетям.

В такой ситуации одно неверное правило может повлиять не только на SSH, но и на связь между приложениями.

Для нового проекта можно выбрать Linux VPS IPWAY и сразу настроить сетевую политику под фактический набор сервисов, не оставляя лишние порты открытыми «на всякий случай».

Кратко

• UFW удобнее для простой базовой политики Ubuntu VPS, nftables — для более сложных правил.
• Перед включением firewall сначала определите фактический SSH-порт и разрешите его.
• Во время изменения правил держите открытой рабочую SSH-сессию и проверяйте новое подключение отдельно.
• Базовая политика обычного VPS — запрет входящих соединений по умолчанию и явное разрешение необходимых сервисов.
• Разрешенный порт в firewall еще не означает, что сервис действительно слушает его.
• Проверяйте firewall не только через UFW или nftables, но и внешним подключением с другого узла.
• Не открывайте базы данных, Redis и административные сервисы всему Интернету без необходимости.
• На серверах с Docker отдельно проверяйте опубликованные контейнерные порты.