Безопасность серверов

UFW и firewalld: настройка firewall в Ubuntu и RHEL

Как безопасно включить UFW или firewalld, сохранить SSH-доступ, открыть сервис только доверенным адресам и проверить постоянные правила.

14 минут
абстр�актная иллюстрация правил межсетевого экрана Linux-сервера
Для Ubuntu и Debian, где выбран UFW, используйте ветку UFW; для RHEL, Rocky Linux и совместимых систем со штатным firewalld — ветку firewalld. До ограничений входящего трафика разрешите фактический SSH-порт, оставьте текущую сессию открытой и подготовьте независимую консоль. В UFW правила обычно сохраняются при включении, а в firewalld нужно отдельно контролировать runtime- и permanent-конфигурации.

Перед изменением firewall: доступ, текущий менеджер и откат

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

Версии и документация

Имена пакетов и systemd-юнитов, доступные предопределённые сервисы, механизм Netfilter и точное поведение команд зависят от выпуска ОС и версии UFW или firewalld. Сверяйте команды с официальными материалами: Ubuntu Server: Firewalls, руководство ufw в Debian, справка firewall-cmd, документация firewalld для RHEL 9 и руководство firewalld в Rocky Linux. UFW и firewalld могут использовать разные механизмы управления правилами, включая iptables и nftables; совместимость с прямыми изменениями также зависит от версии. Ручные правила рассматриваются в статьях «Настройка iptables» и «Настройка nftables», а выбор политики — в «Firewall сервера: default deny, порядок правил и политика доступа».

Подготовьте безопасное изменение

Выполните эти действия до ufw enable, изменения зоны firewalld или применения reload.

  1. 1
    Зафиксируйте административный доступ
    Запишите публичный или внутренний адрес сервера, фактический SSH-порт и адрес, с которого вы подключены. Если SSH работает не на стандартном порту 22, правило для ssh может не подойти: разрешайте реальный <SSH-порт>.
  2. 2
    Оставьте контрольную SSH-сессию
    Не закрывайте текущую SSH-сессию. Откройте вторую сессию и используйте её для проверки новых подключений после каждого изменения. Вторая сессия полезна для контроля, но не заменяет независимый аварийный канал.
  3. 3
    Подготовьте аварийный канал
    При наличии используйте отдельную локальную консоль, BMC или консоль провайдера. Убедитесь, что вход через неё возможен до изменения firewall. Защита BMC и отдельной сети управления рассматриваются в статье «Защита BMC: безопасная настройка iDRAC, iLO и отдельной сети управления».
  4. 4
    Сохраните исходное состояние и план отката
    Сохраните вывод активных правил в журнал изменения или защищённое хранилище. Определите заранее, каким действием откатите последнее правило: удалением правила UFW, удалением runtime и permanent-правила firewalld либо восстановлением ранее сохранённой конфигурации.

Риск блокировки доступа

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

Как определить UFW или firewalld и их состояние

Обычно Ubuntu и Debian используют пакет ufw, а RHEL-совместимые системы — службу firewalld. Это не правило выбора «по вкусу»: сначала выясните, какой менеджер уже установлен, включён и поддерживается вашим дистрибутивом.

Проверяет состояние UFW и его политики. Ответ `Status: inactive` означает, что UFW сейчас не применяет свою конфигурацию; не включайте его, пока не проверите другие менеджеры правил и SSH-разрешение.
sudo ufw status verbose
Проверяет firewalld. Ожидаемый результат при работающей службе — `running`. Ошибка соединения с D-Bus или иной ответ вместо `running` означает, что firewalld не активен либо недоступен.
sudo firewall-cmd --state
Показывает состояние systemd-служб, если соответствующие unit существуют. Для UFW возможны состояния, отличающиеся по выпуску ОС; окончательное состояние правил проверяйте также через `ufw status`.
systemctl is-active ufw; systemctl is-active firewalld
Показывает наличие клиентских команд и текущий ruleset nftables. Наличие `nft` или правил Netfilter само по себе не доказывает, что ими безопасно управлять вручную: выясните владельца конфигурации.
command -v ufw; command -v firewall-cmd; sudo nft list ruleset

Не включайте второй менеджер поверх действующего

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

UFW: настройка в Ubuntu и Debian

В типичной Ubuntu UFW доступен штатно; в Debian его обычно устанавливают пакетом ufw, если пакет отсутствует. Установка пакета не равна включению фильтрации. Перед ufw enable создайте правила для SSH и требуемых опубликованных сервисов.

Устанавливает UFW в Debian/Ubuntu, если он не установлен. Перед установкой убедитесь, что сервером не управляет firewalld или другой менеджер правил.
sudo apt update && sudo apt install ufw

Безопасная базовая настройка UFW

Замените плейсхолдеры значениями для своей роли сервера. <SSH-порт> — фактический порт SSH, <порт> — порт приложения.

  1. 1
    Проверьте текущее состояние
    Выполните sudo ufw status verbose. Если статус active, сначала зафиксируйте существующие правила через sudo ufw status numbered; не применяйте приведённую последовательность как сброс действующей политики.
  2. 2
    Задайте запрет входящих по умолчанию
    Выполните sudo ufw default deny incoming. Это устанавливает запрет по умолчанию для новых входящих подключений в модели UFW, но не заменяет проектирование полной политики доступа.
  3. 3
    Разрешите текущий SSH-доступ
    Для стандартного SSH используйте sudo ufw allow ssh. Если SSH слушает нестандартный порт, используйте sudo ufw allow <SSH-порт>/tcp. Если доступ администратора должен быть только из известной сети, вместо общего разрешения добавьте правило с источником: sudo ufw allow from <доверенный_IP> to any port <SSH-порт> proto tcp.
  4. 4
    Откройте только нужный сервис
    Для TCP-порта используйте sudo ufw allow <порт>/tcp, для UDP — sudo ufw allow <порт>/udp. Такая команда открывает порт для всех источников, поэтому применяйте её только для действительно публичного сервиса.
  5. 5
    Проверьте подготовленные правила
    Если UFW неактивен, выполните sudo ufw show added: команда показывает добавленные пользовательские правила до включения firewall. Если обнаружено ошибочное правило, удалите его полным обратным выражением, например sudo ufw delete allow <порт>/tcp, затем повторите проверку.
  6. 6
    Включите UFW и проверьте подключение
    Выполните sudo ufw enable, затем sudo ufw status verbose и sudo ufw status numbered. Из второй SSH-сессии откройте новое подключение к фактическому SSH-порту. Проверьте сервис с разрешённого источника; если доступ не должен быть публичным, по возможности проверьте отказ с другого адреса.

UFW: ограничить сервис одним IP-адресом или подсетью

Правило «открыть порт» и правило «разрешить порт только доверенному источнику» различаются. Второй вариант образует allowlist: указанному адресу или подсети разрешён доступ, но это не делает сервис доступным всем.

Разрешает TCP-подключения к `<порт>` только с одного IPv4- или IPv6-адреса, соответствующего его формату. Пример синтаксиса не открывает этот порт прочим источникам, если нет другого более широкого разрешающего правила.
sudo ufw allow from <доверенный_IP> to any port <порт> proto tcp
Разрешает UDP-порт источникам из CIDR-подсети, например `<подсеть>` в форме `192.0.2.0/24`. Используйте только реально доверенный диапазон, а не произвольную широкую сеть.
sudo ufw allow from <подсеть> to any port <порт> proto udp
Показывает правила UFW с номерами. Сверьте протокол, порт, источник и наличие отдельных записей для IPv6.
sudo ufw status numbered
Удаляет правило по номеру из вывода `ufw status numbered`. После удаления снова выполните `sudo ufw status numbered`: номера оставшихся правил могут измениться.
sudo ufw delete <номер_правила>

Не удаляйте правило по памяти

Номер правила зависит от текущего списка. Перед ufw delete <номер_правила> каждый раз выводите ufw status numbered и убедитесь, что удаляется именно нужное разрешение, особенно правило SSH.

UFW и IPv6

IPv4-правило не следует считать защитой IPv6: клиент может подключиться к IPv6-адресу сервера в обход IPv4-маршрута. В типичной конфигурации UFW обработка IPv6 задаётся параметром IPV6 в /etc/default/ufw; проверьте его значение и фактические правила.

Показывает значение параметра обработки IPv6, если строка присутствует в конфигурации UFW, а затем независимо выводит правила. При `IPV6=yes` UFW обычно создаёт соответствующие IPv6-правила для применимых разрешений; сверяйте вывод со своей версией UFW.
sudo grep '^IPV6=' /etc/default/ufw; sudo ufw status numbered

Как применить изменение параметра IPv6

Не считайте ufw reload универсальным способом применения изменения IPV6 в /etc/default/ufw. В зависимости от версии и пакета документация может предписывать reload либо sudo ufw disable с последующим sudo ufw enable. Перед повторным включением подтвердите правило для фактического SSH-порта и доступность независимой консоли. После применения проверьте sudo ufw status numbered и фактическое подключение по IPv6.

После изменения IPv6-параметра проверьте ufw status numbered и подключение к IPv6-адресу с разрешённого источника. Если сервер публикует сервисы по IPv6, включите их в модель доступа отдельно. Полная политика IPv4 и IPv6 описана в материале о политике firewall.

Сбрасывает конфигурацию UFW к исходному состоянию и отключает его. Это аварийное действие для контролируемого отката, а не штатный способ редактировать одно правило. После него прежние разрешения нужно создать заново.
sudo ufw reset

firewalld: настройка в RHEL и Rocky Linux

firewalld управляет правилами через зоны firewalld, сервисы, порты и дополнительные правила. В RHEL-совместимых системах пакет обычно называется firewalld, а служба — firewalld, но это нужно проверить для конкретного выпуска.

Устанавливает firewalld в RHEL/Rocky Linux, но не запускает его в рамках этой команды. Перед запуском убедитесь, что правилами не управляет UFW, ручная конфигурация или система автоматизации.
sudo dnf install firewalld

Безопасно запустите firewalld, если служба неактивна

Эта последовательность нужна перед первым запуском firewalld на удалённом сервере. Если служба уже работает, не перезапускайте её: переходите к проверке активных зон.

  1. 1
    Подтвердите состояние службы
    Выполните systemctl is-active firewalld. Если получен результат active, не используйте эту последовательность запуска. Если служба неактивна, обычный firewall-cmd не подходит для проверки конфигурации через работающий демон.
  2. 2
    Проверьте постоянную конфигурацию без запуска демона
    Убедитесь, что доступна команда firewall-offline-cmd, затем выполните sudo firewall-offline-cmd --get-default-zone и sudo firewall-offline-cmd --list-all-zones. Проверьте постоянные привязки интерфейсов и источников и определите зону, которая будет обрабатывать административный трафик. Если определить её однозначно нельзя, не запускайте firewalld удалённо без независимой консоли.
  3. 3
    Добавьте разрешение фактического SSH-порта
    Для выбранной зоны выполните sudo firewall-offline-cmd --zone=<зона> --add-port=<SSH-порт>/tcp. Для стандартного SSH можно использовать определение сервиса: sudo firewall-offline-cmd --zone=<зона> --add-service=ssh. Повторно проверьте зону через sudo firewall-offline-cmd --zone=<зона> --list-all.
  4. 4
    Запустите firewalld
    Не закрывая текущую SSH-сессию, выполните sudo systemctl enable --now firewalld. Затем проверьте sudo firewall-cmd --state и активные зоны.
  5. 5
    Проверьте новое SSH-подключение
    Откройте новую SSH-сессию с разрешённого административного адреса к фактическому порту. Только после успешной проверки переходите к сужению источников и удалению временно широкого разрешения.

Проверьте firewalld и применяемую зону

Сначала определите, какая зона обрабатывает административный трафик. Привязка источника имеет приоритет перед привязкой интерфейса; при отсутствии обеих используется зона по умолчанию.

  1. 1
    Проверьте работу службы
    Выполните sudo firewall-cmd --state. Результат running означает, что firewalld отвечает. Если получена ошибка, проверьте systemctl status firewalld и наличие пакета, но не компенсируйте это включением UFW.
  2. 2
    Посмотрите активные зоны и зону по умолчанию
    Выполните sudo firewall-cmd --get-active-zones и sudo firewall-cmd --get-default-zone. Первая команда показывает активные привязки интерфейсов и источников, вторая — зону для трафика без подходящей явной привязки.
  3. 3
    Проверьте привязку административного источника
    Сверьте адрес или подсеть, из которых приходит SSH-подключение, с полями sources в выводе активных зон. Если источник соответствует такой привязке, эта зона имеет приоритет перед зоной входящего интерфейса. Просмотрите её командой sudo firewall-cmd --zone=<зона> --list-all.
  4. 4
    При отсутствии source-привязки определите зону интерфейса
    Выполните sudo firewall-cmd --get-zone-of-interface=<интерфейс>. Найдите интерфейс по маршруту, через который приходит административный трафик, а не только по имени. Если интерфейс явно не привязан к зоне, учитывайте результат --get-default-zone.
  5. 5
    Проверьте разрешения применяемой зоны
    Выполните sudo firewall-cmd --zone=<зона> --list-all. Проверьте target, services, ports, interfaces, sources и rich rules. До смены зоны или reload убедитесь, что в применяемой зоне разрешён SSH на фактическом порту.
  6. 6
    Проверьте сервисы и порты отдельно
    Используйте sudo firewall-cmd --zone=<зона> --list-services и sudo firewall-cmd --zone=<зона> --list-ports. Пустой список портов не означает отсутствия доступа: трафик также могут разрешать сервисы, rich rules и цель зоны.

Смена зоны может изменить доступ сразу для нескольких сервисов

Зона — профиль доверия для интерфейса или источника, а не правило одного порта. Перед её назначением проверяйте все связанные интерфейсы, источники, сервисы, порты и rich rules через --list-all. Не меняйте зону управляющего интерфейса удалённо, если в целевой зоне не подтверждено разрешение SSH.

Открыть сервис или порт в зоне firewalld

Для стандартного протокола предпочтительнее сервис firewalld, если он присутствует в списке доступных сервисов: он представляет документированный набор портов. Для нестандартного приложения используйте явный порт и протокол. В примерах <зона> — проверенная зона нужного интерфейса, <сервис> — имя сервиса firewalld, <порт> — номер порта.

Добавляет сервис только в runtime-конфигурацию. Сразу проверьте результат командой `sudo firewall-cmd --zone=<зона> --list-services`; после перезагрузки это изменение не гарантированно сохранится.
sudo firewall-cmd --zone=<зона> --add-service=<сервис>
Открывает TCP-порт в runtime-конфигурации зоны для всех источников, которые попадают в эту зону. Для UDP замените `tcp` на `udp`.
sudo firewall-cmd --zone=<зона> --add-port=<порт>/tcp
Добавляет сервис одновременно в постоянную и активную конфигурации без reload. Для порта используйте тот же шаблон с `--add-port=<порт>/tcp`. После выполнения проверьте обе конфигурации.
sudo firewall-cmd --zone=<зона> --permanent --add-service=<сервис> && sudo firewall-cmd --zone=<зона> --add-service=<сервис>
Сравнивает runtime и permanent-списки сервисов. Для портов используйте `--list-ports` и `--permanent --list-ports`.
sudo firewall-cmd --zone=<зона> --list-services; sudo firewall-cmd --permanent --zone=<зона> --list-services

Ограничить доступ источником: зона или rich rule

Назначение источника зоне означает, что адрес или подсеть получает весь набор разрешений этой зоны. Перед этим проверьте все её привязки командой --list-all. Если нужен доступ одного адреса только к одному порту, обычно точнее использовать rich rule. Сначала убедитесь, что тот же сервис или порт не открыт всей зоне через services, ports или другое rich rule: точечное разрешающее правило не отменяет более широкое разрешение.

Привязывает источник, например `<подсеть>` в CIDR-форме, к зоне в runtime-конфигурации. Эта команда не открывает только один сервис: источнику будут применяться все разрешения зоны.
sudo firewall-cmd --zone=<зона> --add-source=<подсеть>
Добавляет runtime rich rule, разрешающее TCP-порт одному IPv4-источнику. Для IPv6 укажите `family="ipv6"` и IPv6-адрес. Проверьте правило через `sudo firewall-cmd --zone=<зона> --list-rich-rules`.
sudo firewall-cmd --zone=<зона> --add-rich-rule='rule family="ipv4" source address="<доверенный_IP>" port port="<порт>" protocol="tcp" accept'
Сохраняет rich rule в permanent-конфигурации и добавляет его в runtime. После команды проверьте `--list-rich-rules` с `--permanent` и без него.
sudo firewall-cmd --permanent --zone=<зона> --add-rich-rule='rule family="ipv4" source address="<доверенный_IP>" port port="<порт>" protocol="tcp" accept' && sudo firewall-cmd --zone=<зона> --add-rich-rule='rule family="ipv4" source address="<доверенный_IP>" port port="<порт>" protocol="tcp" accept'

Зона trusted не является безопасным синонимом allowlist для одного сервиса. Её модель доверия предполагает существенно более широкий допуск трафика от назначенных интерфейсов или источников. Не используйте trusted как универсальный способ открыть порт администрирования или приложения; создавайте точечное разрешение в подходящей зоне либо rich rule.

Удалить сервис, порт, источник или rich rule

Независимо пытается удалить сервис из runtime- и permanent-конфигураций. Одна из команд может сообщить, что разрешения уже нет; после выполнения отдельно проверьте оба списка. Для порта используйте `--remove-port=<порт>/tcp`.
sudo firewall-cmd --zone=<зона> --remove-service=<сервис>; sudo firewall-cmd --permanent --zone=<зона> --remove-service=<сервис>
Независимо удаляет назначение источника зоне из runtime- и permanent-конфигураций. Удаление меняет применяемую к источнику модель доверия, поэтому сначала проверьте, не используется ли привязка для SSH, а после команды сверяйте обе конфигурации.
sudo firewall-cmd --zone=<зона> --remove-source=<подсеть>; sudo firewall-cmd --permanent --zone=<зона> --remove-source=<подсеть>
Независимо удаляет rich rule из runtime- и permanent-конфигураций. Строка должна совпадать с созданным правилом; перед удалением скопируйте её из `--list-rich-rules`, а после него проверьте списки с `--permanent` и без этого параметра.
sudo firewall-cmd --zone=<зона> --remove-rich-rule='rule family="ipv4" source address="<доверенный_IP>" port port="<порт>" protocol="tcp" accept'; sudo firewall-cmd --permanent --zone=<зона> --remove-rich-rule='rule family="ipv4" source address="<доверенный_IP>" port port="<порт>" protocol="tcp" accept'

Runtime и permanent rules в firewalld

В firewalld активные и сохранённые правила — разные наборы.

КонфигурацияКогда изменение действуетReload, перезапуск или перезагрузка
runtimeСразу после успешной команды без --permanentНесохранённое изменение обычно исчезает
permanentПосле reload, перезапуска firewalld либо отдельного добавления того же правила в runtimeСохранённая конфигурация загружается снова

Команда с --permanent обычно не меняет работающий firewall немедленно. Можно добавить правило сначала с --permanent, затем тем же вызовом без него, как в примерах выше. Альтернативный путь — внести постоянные изменения и применить их через reload, но reload загружает permanent-конфигурацию и может отбросить несохранённые runtime-изменения.

Сохраняет текущую runtime-конфигурацию в permanent-конфигурацию. Используйте только после ревизии runtime-состояния: команда переносит текущий набор, а не отдельное выбранное правило.
sudo firewall-cmd --runtime-to-permanent
Перезагружает firewalld и применяет permanent-конфигурацию. До команды сравните runtime и permanent через `--list-all` и `--permanent --list-all`, поскольку несохранённые временные изменения могут исчезнуть.
sudo firewall-cmd --reload

Проверьте результат после UFW или firewalld

Проверка должна подтверждать не только наличие строки в конфигурации, но и фактический доступ.

  1. 1
    Проверьте активные правила
    Для UFW выполните sudo ufw status verbose и sudo ufw status numbered. Для firewalld используйте sudo firewall-cmd --get-active-zones и sudo firewall-cmd --zone=<зона> --list-all.
  2. 2
    Проверьте постоянную конфигурацию firewalld
    В firewalld дополнительно выполните sudo firewall-cmd --permanent --zone=<зона> --list-all. Нужный сервис, порт, источник или rich rule должен присутствовать и в runtime, и в permanent, если он обязан пережить перезагрузку.
  3. 3
    Проверьте SSH новым подключением
    Не используйте только уже открытую сессию как доказательство: она может сохраниться благодаря отслеживанию существующего соединения. Создайте новое SSH-подключение с разрешённого административного адреса к фактическому порту.
  4. 4
    Проверьте опубликованный сервис с разных источников
    Подключитесь к сервису с разрешённого IP-адреса. Если доступ ограничен allowlist, по возможности проверьте, что источник вне списка не получает доступ. Проверяйте IPv6 отдельно, если сервис имеет IPv6-адрес.
  5. 5
    Зафиксируйте изменение
    Запишите назначение правила, порт, протокол, разрешённые источники, зону firewalld или номера правил UFW и способ отката. Настройка SSH-ключей и ограничений учётных записей остаётся отдельной задачей: «Безопасная настройка SSH: ключи, root и ограничение доступа».

Границы этой инструкции

Здесь показано минимальное безопасное открытие входящих точек. Порядок обработки правил, исходящий трафик, DROP или REJECT и полная модель доступа разбираются в статье о политике firewall. Firewall не заменяет защиту от перебора: для временных блокировок по журналам используйте Fail2ban.

Термины в статье

Allowlist — перечень разрешающих записей или правил: система допускает только те субъекты, объекты, действия или значения, которые им соответствуют.
Netfilter — подсистема ядра Linux для перехвата и обработки сетевых пакетов в контрольных точках стека; правила iptables и nftables используют её механизмы.
UFW — утилита упрощённого управления правилами межсетевого экрана в Linux, создающая правила Netfilter по командам высокого уровня.
firewalld — служба управления межсетевым экраном в Linux, применяющая правила через зоны, сервисы и политики без прямого редактирования полного набора правил.
iptables — утилита Linux для управления правилами пакетной фильтрации Netfilter через таблицы, цепочки и цели; это не самостоятельный межсетевой экран.
nftables — подсистема Linux и интерфейс управления правилами Netfilter, использующие единый набор правил, выражения, множества и атомарное обновление конфигурации.
Запрет по умолчанию — политика контроля доступа, при которой разрешаются только явно разрешённые правилами обращения или действия, а всё остальное блокируется.
Зона firewalld — профиль доверия к сетевому подключению, связывающий интерфейсы или источники с набором разрешённых служб и правил фильтрации.
Межсетевой экран — средство контроля сетевого трафика, разрешающее или блокирующее его по правилам на границе или между сегментами сети.
Межсетевой экран с отслеживанием состояния — межсетевой экран, который сопоставляет пакеты с состоянием отслеживаемых соединений и потоков и применяет правила с учётом их контекста.
Отслеживание соединений в Linux — механизм Netfilter, ведущий записи о потоках и их состояниях для фильтрации с учётом состояния, NAT и правил, зависящих от направления трафика.
Правило межсетевого экрана — элемент политики фильтрации, задающий условия сопоставления трафика и действие над пакетами или соединениями.

Вопросы по теме

Все вопросы и ответы

Нужно ли разрешать SSH перед `ufw enable`?

Да. До включения UFW разрешите фактический SSH-порт: ufw allow ssh подходит только для стандартного порта 22, а для нестандартного нужен явный порт TCP. Не закрывайте текущую SSH-сессию, откройте вторую для проверки и заранее подготовьте независимую консоль или BMC на случай блокировки доступа.

Как определить, какая зона firewalld применяется к SSH?

Сначала проверьте активные зоны через firewall-cmd --get-active-zones. Если административный IP или подсеть привязаны к зоне как source, она имеет приоритет над зоной интерфейса. Иначе определите зону интерфейса командой --get-zone-of-interface=<интерфейс> и учитывайте зону по умолчанию. Перед изменениями проверьте её через --list-all.

Можно ли одновременно использовать UFW и iptables?

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

Как ограничить доступ к порту одним IP в UFW?

Добавьте правило с источником, например sudo ufw allow from <доверенный_IP> to any port <порт> proto tcp. Оно разрешает доступ к указанному TCP-порту только этому IPv4- или IPv6-адресу соответствующего формата. Проверьте список через ufw status numbered и убедитесь, что для того же порта нет более широкого разрешения для всех источников.

Почему правило firewalld пропадает после перезагрузки?

Потому что обычные команды firewall-cmd --add-service и --add-port меняют только runtime-конфигурацию. Для сохранения правила добавьте его также с --permanent, затем примените и runtime-вариант без reload. После этого отдельно сравните runtime и permanent через --list-services или --list-ports с флагом --permanent.

Нужно ли отдельно проверять правила UFW для IPv6?

Да. IPv4-правило не защищает IPv6-адрес сервера: клиент может подключиться по IPv6 в обход IPv4-маршрута. Проверьте параметр IPV6 в /etc/default/ufw, затем фактические правила через ufw status numbered. После изменения параметра проверьте подключение по IPv6 с разрешённого источника и подтвердите доступ к фактическому SSH-порту.