UFW на Ubuntu Server: базовая политика firewall без риска потерять SSH-доступ

UFW (Uncomplicated Firewall) — фронтенд для управления правилами netfilter в Linux, разработанный специально для Ubuntu. Он не заменяет iptables/nftables, а предоставляет упрощённый интерфейс для типовых задач: открытие портов, ограничение скорости подключений, работа с профилями приложений. После установки UFW по умолчанию выключен, а политики настроены так: входящий трафик — deny, исходящий — allow, пересылка (forward) — deny.

Проверка текущего состояния​


Перед любыми изменениями убедитесь, что знаете текущее состояние:

Bash:
sudo ufw status verbose

Если firewall ещё не активирован, вывод будет:

Код:
Status: inactive

Это нормально для свежеустановленного сервера. Правила, добавленные до активации, сохраняются и применяются при включении.

Главное правило: сначала SSH, потом enable​


При выполнении ufw enable происходит сброс цепочек (flush), что может разорвать существующие соединения, включая текущую SSH-сессию. Поэтому правило для SSH добавляется до активации:

Bash:
sudo ufw allow 22/tcp comment 'SSH'

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

Bash:
sudo ufw allow 2222/tcp comment 'SSH'

Только после этого включайте firewall:

Bash:
sudo ufw enable

Если вы уже подключены по SSH, ufw выдаст предупреждение и запросит подтверждение. Для автоматизации (например, в скриптах) используйте флаг --force:

Bash:
sudo ufw --force enable

После активации правила добавляются и удаляются без сброса цепочек — существующие соединения не рвутся. Исключение: изменение правил или дефолтной политики всё же вызывает flush.

Rate limiting для защиты от brute-force​


Вместо простого allow для SSH лучше использовать limit. UFW заблокирует IP-адрес, если с него инициировано 6 и более новых соединений за 30 секунд:

Bash:
sudo ufw limit 22/tcp comment 'SSH rate limit'

Это не заменяет fail2ban для сложной аналитики, но отсекает примитивные переборы паролей без дополнительной настройки.

Политики по умолчанию и их изменение​


Проверить текущие политики:

Bash:
sudo ufw status verbose

Пример вывода:

Код:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

Изменение политик:

Bash:
sudo ufw default deny incoming
sudo ufw default allow outgoing

Политика deny на входящий трафик означает, что любой порт закрыт, если для него нет явного правила allow. Это безопасная база для сервера.

Открытие портов для сервисов​


Простой синтаксис​


Bash:
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw allow 53 comment 'DNS'

Если протокол не указан, правило применяется и к TCP, и к UDP. UFW также понимает имена служб из /etc/services:

Bash:
sudo ufw allow http
sudo ufw allow https

Расширенный синтаксис с указанием источника и интерфейса​


Ограничить доступ к порту определённой подсетью:

Bash:
sudo ufw allow in on eth0 from 192.168.0.0/16 to any port 5432 proto tcp comment 'PostgreSQL LAN'

Разрешить несколько портов одной командой (максимум 15 портов, диапазон считается за 2):

Bash:
sudo ufw allow proto tcp from any to any port 80,443,8080:8090 comment 'web app'

Обратите внимание: такая группа портов управляется как единое правило — удалить из неё отдельный порт нельзя, только всё правило целиком.

Профили приложений​


UFW читает профили из /etc/ufw/applications.d/. Список доступных:

Bash:
sudo ufw app list

Пример вывода:

Код:
Available applications:
  Nginx Full
  Nginx HTTP
  Nginx HTTPS
  OpenSSH

Использование профиля вместо номера порта:

Bash:
sudo ufw allow 'Nginx Full'
sudo ufw allow 'OpenSSH'

Посмотреть, какие порты включает профиль:

Bash:
sudo ufw app info 'Nginx Full'

Управление правилами: удаление, вставка, нумерация​


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


Bash:
sudo ufw status numbered

Пример вывода:

Код:
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     LIMIT IN    Anywhere
[ 2] 80/tcp                     ALLOW IN    Anywhere
[ 3] 443/tcp                    ALLOW IN    Anywhere
[ 4] 22/tcp (v6)                LIMIT IN    Anywhere (v6)

Удаление по номеру​


Bash:
sudo ufw delete 2

При включённом IPv6 удаление по номеру убирает только одно правило (IPv4 или IPv6). Чтобы удалить оба варианта одной командой, используйте исходный синтаксис:

Bash:
sudo ufw delete allow 80/tcp

Вставка правила на определённую позицию​


Порядок правил важен: первое совпадение выигрывает. Более специфичные правила должны стоять выше общих.

Bash:
sudo ufw insert 1 deny from 10.0.0.135 to any port 22 proto tcp

Это вставит правило блокировки на первую позицию, и оно будет обработано раньше, чем общий allow на порт 22.

Prepend для динамических правил​


Bash:
sudo ufw prepend deny from 203.0.113.50

Правило добавится перед всеми существующими правилами соответствующего IP-типа (отдельно для IPv4 и IPv6).

Логирование​


По умолчанию логирование включено на уровне low. Уровни:

УровеньЧто логируется
offНичего
lowЗаблокированные пакеты, не соответствующие политике, и пакеты с ограничением скорости
mediumВсё из low + разрешённые новые соединения
highВсё из medium + все пакеты (может быстро заполнить диск)
fullВсё из high без ограничения скорости записи

Изменение уровня:

Bash:
sudo ufw logging medium

Логи пишутся в /var/log/ufw.log (или в syslog, зависит от конфигурации rsyslog). Для уровней выше medium на загруженных серверах объём логов может стать проблемой — следите за ротацией.

Логирование конкретного правила:

Bash:
sudo ufw allow 22/tcp log

IPv6​


IPv6 включён по умолчанию. Правила, записанные без указания адреса, применяются к обоим стекам. Если ufw allow 22/tcp добавлено при активном IPv6, в status numbered вы увидите два правила: одно для IPv4, второе с пометкой (v6).

Отключить IPv6-фильтрацию можно в /etc/default/ufw:

Код:
IPV6=no

После изменения требуется перезагрузка:

Bash:
sudo ufw reload

Пересылка трафика (forwarding)​


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

Bash:
sudo ufw default allow routed

И включить форвардинг в /etc/ufw/sysctl.conf:

Код:
net/ipv4/ip_forward=1
net/ipv6/conf/default/forwarding=1
net/ipv6/conf/all/forwarding=1

Правила пересылки используют ключевое слово route:

Bash:
sudo ufw route allow in on eth0 out on eth1 to 10.0.0.0/8 from 192.168.0.0/16

Интерфейсы в правилах route указываются относительно направления потока пакетов через firewall, а не относительно самого хоста.

Типичные ошибки и как их избежать​


Потеря доступа при первом включении. Самая частая ошибка — выполнить ufw enable без предварительного правила для SSH. Решение: всегда добавляйте правило до активации. Если доступ уже потерян, потребуется консольный доступ через VNC/IPMI или rescue-режим хостинга.

Удаление правила по номеру при включённом IPv6. Команда ufw delete 3 удалит только одно из двух правил (IPv4 или IPv6). Второе останется. Проверяйте status numbered после удаления.

Конфликт с Docker. Docker при запуске добавляет собственные правила в цепочку FORWARD и может создавать правила в цепочке INPUT, которые обходят UFW. Если на сервере работает Docker, проверяйте итоговое состояние через sudo ufw show raw или sudo iptables -n -L -v.

Правило не срабатывает из-за порядка. UFW обрабатывает правила последовательно, первое совпадение побеждает. Если общий deny стоит выше специфичного allow, трафик будет заблокирован. Используйте insert или prepend для корректировки порядка.

Диагностика и проверка результата​


Полное состояние firewall в формате iptables:

Bash:
sudo ufw show raw

Прослушиваемые порты и связанные с ними правила:

Bash:
sudo ufw show listening

Эта команда показывает, какие порты открыты, какой процесс их слушает и какие правила UFW влияют на каждый порт.

Список правил в том виде, в котором они были добавлены:

Bash:
sudo ufw show added

Проверка конкретного порта извне (с другой машины):

Bash:
nc -zv SERVER_IP 22
nc -zv SERVER_IP 80

Отключение и сброс​


Временное отключение (правила сохраняются):

Bash:
sudo ufw disable

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

Bash:
sudo ufw reset

Команда reset удаляет все пользовательские правила и возвращает firewall в неактивное состояние. Используйте её осторожно — восстановление потребует повторной настройки.

Итоговый минимальный набор для типового сервера​


Bash:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw limit 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable
sudo ufw status verbose

После выполнения проверьте, что SSH-сессия не прервалась и status verbose показывает ожидаемые правила. Если сервер за NAT или балансировщиком, убедитесь, что правила соответствуют реальным интерфейсам и источникам трафика.

Источники​


 
У UFW есть два класса «аналогов»:

  1. Низкоуровневые системы, которые реально управляют правилами ядра Linux: nftables, iptables.
  2. Высокоуровневые фронтенды и менеджеры, похожие на UFW по удобству: firewalld, Shorewall, ferm, CSF, графические оболочки и т.п.

Важно понимать: сам UFW — не отдельный сетевой экран в ядре. Это пользовательский интерфейс поверх netfilter, обычно работающий через iptables/iptables-nft или близкий к нему механизм.

────────────────────

Основные аналоги UFW в Linux​


1. nftables / nft


nftables — современный механизм фильтрации пакетов в ядре Linux, замена старых iptables, ip6tables, arptables, ebtables.

Это не совсем «аналог UFW» по уровню удобства, это скорее более мощный низкоуровневый аналог. Но именно он сейчас является рекомендуемым базовым уровнем для новых дистрибутивов.

Плюсы:

  • современный kernel backend;
  • единый синтаксис для IPv4, IPv6, ARP, bridge;
  • лучше масштабируется при большом числе правил;
  • поддерживает sets, maps, counters, rate limiting, conntrack, NAT, queueing;
  • удобен для сложных правил и автоматизации.

Минусы:

  • синтаксис сложнее, чем у UFW;
  • легче ошибиться и потерять SSH-доступ;
  • нужно самому продумывать порядок правил и сохранение конфигурации.

Пример просмотра текущего ruleset:

Bash:
sudo nft list ruleset

Пример базового конфига /etc/nftables.conf:

Код:
#!/usr/sbin/nft -f

flush ruleset

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

        iif lo accept
        ct state established,related accept
        ct state invalid drop

        ip protocol icmp accept
        ip6 nexthdr icmpv6 accept

        tcp dport 22 ct state new accept
        tcp dport 80 ct state new accept
        tcp dport 443 ct state new accept
    }

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

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

Проверка синтаксиса без применения:

Bash:
sudo nft -c -f /etc/nftables.conf

Применение:

Bash:
sudo nft -f /etc/nftables.conf

Если делаете это удалённо, сначала убедитесь, что SSH-порт разрешён, иначе можно потерять доступ.

────────────────────

2. iptables / iptables-nft


iptables — классический пользовательский интерфейс к netfilter. Долгие годы был стандартом де-факто.

Сейчас во многих дистрибутивах iptables работает в режиме совместимости с nftables, то есть команды iptables транслируются в правила nftables. Это часто называется iptables-nft.

Плюсы:

  • огромное количество документации и примеров;
  • привычен администраторам старой школы;
  • хорошо поддерживается скриптами, старыми панелями, хостинг-софтом;
  • подходит для простых правил.

Минусы:

  • устаревший подход по сравнению с nftables;
  • отдельные утилиты для IPv4, IPv6, ARP, bridge;
  • хуже читается при сложных правилах;
  • медленнее при больших rulesets.

Пример просмотра правил:

Bash:
sudo iptables -S
sudo ip6tables -S

Пример разрешить SSH:

Bash:
sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT

Пример сохранить правила в Debian/Ubuntu-подобной системе:

Bash:
sudo iptables-save > /etc/iptables/rules.v4
sudo ip6tables-save > /etc/iptables/rules.v6

В RHEL-подобных системах часто используется:

Bash:
sudo service iptables save

или:

Bash:
sudo iptables-save > /etc/sysconfig/iptables

────────────────────

3. firewalld


firewalld — ближайший идеологический аналог UFW, но более развитый. Используется в Fedora, RHEL, CentOS Stream, Rocky Linux, AlmaLinux, openSUSE и частично в других дистрибутивах.

Он оперирует зонами: public, home, work, internal, trusted, dmz, block, drop и т.д.

Плюсы:

  • динамическое применение правил без полного сброса соединений;
  • удобные зоны;
  • поддержка сервисов, портов, rich rules, masquerade, port forwarding;
  • есть CLI и GUI;
  • хорошо интегрирован с systemd и NetworkManager.

Минусы:

  • сложнее UFW;
  • на Debian/Ubuntu встречается реже;
  • может конфликтовать с ручными iptables-правилами или Docker, если не понимать, кто чем управляет.

Проверка состояния:

Bash:
sudo firewall-cmd --state
sudo firewall-cmd --list-all

Разрешить SSH, HTTP, HTTPS:

Bash:
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

Посмотреть активные зоны:

Bash:
sudo firewall-cmd --get-active-zones

Посмотреть правила зоны:

Bash:
sudo firewall-cmd --zone=public --list-all

GUI-утилита:

Bash:
firewall-config

────────────────────

4. Shorewall


Shorewall — высокоуровневая система конфигурации firewall на базе iptables/nftables. Хорошо подходит для маршрутизаторов, шлюзов, NAT-серверов и сетей с несколькими зонами.

Плюсы:

  • удобен для сложных сетевых топологий;
  • декларативная конфигурация;
  • хорошо подходит для multi-zone firewall;
  • есть отдельные варианты: shorewall, shorewall6, shorewall-lite.

Минусы:

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

Пример логики в /etc/shorewall/rules:

Код:
SSH(ACCEPT)     net     fw
HTTP(ACCEPT)    net     fw
HTTPS(ACCEPT)   net     fw

Проверка конфигурации:

Bash:
sudo shorewall check

Применение:

Bash:
sudo shorewall restart

────────────────────

5. ferm


ferm — компактный генератор правил для iptables/ip6tables/arptables/ebtables. Конфигурация пишется в собственном компактном синтаксисе, а ferm генерирует и применяет правила.

Плюсы:

  • компактный и читаемый конфиг;
  • удобен для инфраструктурного кода;
  • хорошо подходит для воспроизводимой настройки;
  • легче, чем Shorewall.

Минусы:

  • меньше пользователей и готовых профилей;
  • нужно знать базовую логику netfilter;
  • не такой дружелюбный, как UFW или firewalld.

Пример идеи конфига:

Код:
domain (ip ip6) table filter {
    chain INPUT {
        policy DROP;
        interface lo ACCEPT;
        mod state state (ESTABLISHED RELATED) ACCEPT;
        proto tcp dport 22 ACCEPT;
        proto tcp dport 80 ACCEPT;
        proto tcp dport 443 ACCEPT;
    }

    chain OUTPUT {
        policy ACCEPT;
    }

    chain FORWARD {
        policy DROP;
    }
}

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

Bash:
sudo ferm --noflush /etc/ferm/ferm.conf
sudo ferm /etc/ferm/ferm.conf

────────────────────

6. CSF — ConfigServer Security & Firewall​


CSF популярен на хостинг-серверах, особенно с cPanel, DirectAdmin, Webmin. Это не просто firewall, а целый набор: firewall, защита от brute-force, LFD-демон, уведомления, блокировки по странам, лимиты подключений.

Плюсы:

  • удобен для shared hosting и VPS;
  • много готовых security-функций;
  • интеграция с панелями управления;
  • автоматические блокировки подозрительных IP;
  • простые команды для allow/deny.

Минусы:

  • это уже не минималистичный аналог UFW;
  • использует iptables под капотом;
  • может быть избыточным для контейнера или простого сервера;
  • нужно аккуратно настраивать, чтобы не заблокировать себя.

Пример команд:

Bash:
sudo csf -e
sudo csf -l
sudo csf -a 203.0.113.10
sudo csf -d 198.51.100.20
sudo csf -r

Просмотр состояния:

Bash:
sudo csf -s

────────────────────

7. FireHOL


FireHOL — ещё один декларативный фронтенд для iptables. Конфигурация пишется в виде понятных правил, а FireHOL генерирует iptables-команды.

Плюсы:

  • читаемый конфиг;
  • хорошо подходит для хостов и простых маршрутизаторов;
  • декларативный подход.

Минусы:

  • менее распространён, чем UFW/firewalld/nftables;
  • завязан на iptables;
  • для современных систем часто лучше смотреть в сторону nftables.

────────────────────

8. gufw


gufw — графический фронтенд для UFW. Это не отдельный firewall, а GUI для того же UFW.

Подходит для desktop-систем, где не хочется пользоваться терминалом.

Установка в Debian/Ubuntu-подобных системах обычно:

Bash:
sudo apt install gufw

────────────────────

9. YaST Firewall


В openSUSE/SUSE есть собственный системный менеджер YaST, включая модуль firewall.

Он может управлять:

  • firewalld;
  • в старых версиях — SuSEfirewall2;
  • в современных системах чаще используется firewalld.

Это скорее дистрибутивный аналог UFW/firewalld с GUI и CLI-интеграцией.

────────────────────

10. Cockpit с модулем firewall​


Для серверов с веб-интерфейсом можно использовать Cockpit. В нём есть модуль управления firewall, обычно работающий через firewalld.

Плюсы:

  • веб-интерфейс;
  • удобно для базового администрирования;
  • подходит для RHEL/Fedora/CentOS-подобных систем.

Минусы:

  • не заменяет полноценный CLI при сложной настройке;
  • зависит от backend-менеджера, чаще всего firewalld.

────────────────────

Что находится под всеми этими инструментами​


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

  • nftables — современный механизм;
  • iptables — классический механизм, часто работающий как compatibility layer поверх nftables.

Проверить, какой backend используется в системе, можно примерно так:

Bash:
sudo nft list ruleset

Если вывод пустой или команда не найдена:

Bash:
sudo iptables -S
sudo ip6tables -S

Также полезно посмотреть, какой вариант iptables установлен:

Bash:
iptables --version

Если вывод содержит nf_tables, это iptables-nft:

Код:
iptables v1.8.x (nf_tables)

Если содержит legacy, это старый вариант:

Код:
iptables v1.8.x (legacy)

────────────────────

Что выбрать вместо UFW​


Для Ubuntu/Debian-сервера​


Если нужен простой и понятный firewall:

Bash:
sudo apt install ufw
sudo ufw limit 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

UFW остаётся хорошим выбором.

Если нужен более современный и контролируемый вариант:

  • nftables.

Если нужна динамическая модель зон:

  • firewalld.

────────────────────

Для Fedora/RHEL/Rocky/AlmaLinux​


Обычно логичнее использовать firewalld:

Bash:
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

────────────────────

Для сложного маршрутизатора или NAT-шлюза​


Лучше смотреть в сторону:

  • nftables;
  • Shorewall;
  • частично firewalld, если нужна зональная модель.

Для серьёзных сетевых правил nftables обычно предпочтительнее.

────────────────────

Для хостинга с cPanel/DirectAdmin/Webmin​


Часто используют:

  • CSF;
  • иногда APF, но он менее актуален.

CSF удобен именно в хостинговом контексте.

────────────────────

Для инфраструктуры как кода​


Хорошие варианты:

  • nftables + Ansible/шаблоны;
  • ferm;
  • firewalld через Ansible-модули;
  • Shorewall, если исторически используется.

Для воспроизводимости лучше хранить не вывод iptables-save, а декларативный конфиг:

  • /etc/nftables.conf;
  • /etc/ferm/ferm.conf;
  • firewalld-профили и rich rules;
  • Ansible-задачи.

────────────────────

Нежелательно использовать несколько менеджеров одновременно​


Не стоит одновременно держать активными, например:

  • UFW;
  • firewalld;
  • ручные iptables-правила;
  • Docker-правила;
  • libvirt-правила;
  • Kubernetes CNI-правила;
  • CSF.

Они могут перезаписывать или обходить правила друг друга.

Проверить активные сервисы:

Bash:
systemctl is-active ufw
systemctl is-active firewalld
systemctl is-active nftables
systemctl is-active iptables
systemctl is-active ip6tables
systemctl is-active csf

Посмотреть фактические правила:

Bash:
sudo nft list ruleset
sudo iptables-save
sudo ip6tables-save

────────────────────

Особенности Docker и контейнеров​


Docker часто сам добавляет правила в iptables/nftables, особенно для проброса портов. Поэтому даже при включённом UFW или firewalld контейнерные порты могут быть доступны извне.

Проверить фактические правила:

Bash:
sudo iptables -S
sudo iptables -S DOCKER
sudo iptables -S FORWARD
sudo nft list ruleset

Для Docker-хостов нужно отдельно проверять:

  • цепочку DOCKER;
  • цепочку FORWARD;
  • NAT-правила;
  • пользовательские сети Docker;
  • published ports.

────────────────────

Быстрая сравнительная ориентировка​


  • UFW — простой, хорош для Ubuntu/Debian и одиночных серверов.
  • firewalld — зонный, динамический, хорош для RHEL/Fedora и desktop/server.
  • nftables — современный, мощный, низкоуровневый, хорош для полного контроля.
  • iptables — классика, много примеров, но устаревает.
  • Shorewall — хорош для сложных шлюзов и зон.
  • ferm — компактный декларативный генератор iptables-правил.
  • CSF — хорош для хостинга и VPS с панелями управления.
  • gufw — GUI для UFW.
  • YaST Firewall — для openSUSE/SUSE.
  • Cockpit firewall module — веб-управление, обычно через firewalld.

────────────────────

Практический вывод​


Если нужен прямой аналог UFW по простоте:

  • на Ubuntu/Debian оставайтесь на UFW;
  • на Fedora/RHEL используйте firewalld;
  • если хочется GUI — gufw или firewall-config;
  • если нужен максимальный контроль и современная база — nftables;
  • если нужен хостинговый security-комбайн — CSF;
  • если нужен сложный gateway — nftables или Shorewall.

Для большинства современных Linux-серверов самая правильная долгосрочная связка выглядит так:

Код:
nftables как kernel backend
+
либо UFW/firewalld как удобный менеджер
+
аккуратное понимание Docker/libvirt/Kubernetes-правил
 
Назад
Верх Низ