Настройка фаервола на сервере: nftables, UFW или firewalld

На одном сервере ошибка в правиле фаервола может за минуту закрыть SSH, а слишком широкое разрешение — оставить наружу базу данных или панель управления. Для Linux-сервера обычно выбирают один из трёх подходов: UFW как простой интерфейс, firewalld с зонами или nftables с прямым описанием правил. Они решают одну задачу, но отличаются контролем, удобством отката и ценой ошибки.

Сначала определите границы задачи

Ниже речь идёт о Linux-серверах с systemd и IPv4/IPv6. Примеры ориентированы на Debian 12 с nftables и Ubuntu Server 22.04 или 24.04 с UFW. Перед настройкой проверьте версии команд в своей системе: названия пакетов и поведение отдельных параметров могут отличаться.

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

Минимальный план перед изменениями:

• узнайте текущий внешний IP и способ подключения по SSH;
• проверьте, на каком порту слушает SSH;
• составьте список сервисов, доступных из интернета;
• откройте вторую SSH-сессию и не закрывайте её до проверки;
• подготовьте доступ к консоли провайдера или KVM на случай блокировки.

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

Хорошее правило фаервола не просто запрещает лишнее. Оно ещё понятно через месяц, переживает перезагрузку и не запирает администратора снаружи.

Три подхода и их цена

UFW и firewalld — не отдельные сетевые механизмы. Они управляют правилами ядра через нижележащий стек. В современных дистрибутивах таким стеком обычно выступает nftables, но пользователь работает с разными интерфейсами.

UFW: короткий путь для одного Ubuntu-сервера

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

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status verbose

Команда allow должна быть выполнена до enable. Если SSH работает на другом порту, замените 22 на фактический порт. После включения в выводе должны быть правила для SSH и веб-портов, а политика входящих соединений — deny.

Когда UFW становится тесным

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

firewalld: зоны вместо длинного списка исключений

firewalld удобен, когда сервер подключён к нескольким сетям или правила должны меняться без полной остановки сетевого стека. Его модель строится вокруг зон и сервисов. Сначала смотрят активные интерфейсы и зоны, затем меняют постоянную конфигурацию.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Важное различие — временные и постоянные изменения. Параметры без --permanent меняют активную конфигурацию, но могут исчезнуть после перезагрузки или перезапуска firewalld. Параметры с --permanent требуют --reload, чтобы попасть в работающую конфигурацию.

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

nftables: правила без промежуточного слоя

nftables стоит выбрать, когда важны предсказуемое поведение и точное описание фильтрации. Вы сами задаёте таблицу, цепочки, политики и порядок правил. За это приходится отвечать за синтаксис, IPv6 и сохранение конфигурации после перезапуска.

table inet filter {
    chain input {
        type filter hook input priority filter; 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 filter; policy drop;
    }

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

Это фрагмент синтаксиса nftables для Linux с установленным nft. Таблица inet позволяет описать IPv4 и IPv6 в одном месте. Перед применением добавьте ограничения для SSH по доверенным адресам, если это возможно, и проверьте правила в тестовом окне. Не переносите такой набор вслепую на сервер, который маршрутизирует трафик, использует Docker или выполняет функции сетевого шлюза.

Сохранение зависит от дистрибутива и пакета. В Debian обычно используют пакет nftables и его systemd-службу, но точный путь к файлу конфигурации проверьте в документации установленной версии и в unit-файле сервиса. Наличие правил в текущем ядре не означает, что они восстановятся после перезагрузки.

Как выбрать подход

• Берите UFW, если это один Ubuntu-сервер с SSH, HTTP и HTTPS, а правила меняются редко.
• Берите firewalld, если нужны зоны, несколько интерфейсов, управляемые сервисы и изменения без ручного редактирования большого файла.
• Берите nftables, если вы готовы ревьюить правила как код, тестировать IPv4 и IPv6 и самостоятельно отвечать за восстановление после перезагрузки.
• Не начинайте с iptables-legacy для новой конфигурации. Сначала выясните, не использует ли система backend nftables и нет ли старого инструмента, который перезаписывает правила.

Что ломается чаще всего

SSH закрыт сразу после включения

Причина обычно в неверном порте, неправильном интерфейсе или отсутствии разрешения до включения политики drop или deny. Используйте консоль провайдера, исправьте правило и только потом закрывайте аварийную SSH-сессию.

Правило есть, но сервис недоступен

Проверьте, слушает ли приложение нужный адрес и порт: сервис, привязанный к 127.0.0.1, не будет доступен извне независимо от фаервола. Затем проверьте DNS, security groups у облачного провайдера и локальный фаервол.

IPv6 обходит расчёт

Правило для IPv4 не всегда разрешает или запрещает тот же трафик по IPv6. Если у сервера есть AAAA-запись, проверяйте оба стека. Таблица inet в nftables помогает держать правила рядом, но не отменяет проверку.

После перезагрузки всё пропало

Вы изменили активное состояние, но не настроили загрузку конфигурации. Для firewalld проверьте постоянную конфигурацию и выполните reload. Для nftables проверьте systemd-службу и способ загрузки файла, принятый вашим дистрибутивом.

Docker открыл порт неожиданно

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

Что делать дальше

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