FirewallD: зоны и правила на практике

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

Зоны, интерфейсы и источники

Зона — это набор правил, привязанный к интерфейсу или диапазону адресов. Интерфейс попадает в зону по явному назначению, а если его нет — в зону по умолчанию. Источники имеют приоритет над интерфейсом: адрес из 192.168.10.0/24 можно отправить в доверенную зону, даже если пакет пришёл на публичный интерфейс.

Стандартные зоны различаются политикой по умолчанию. drop молча отбрасывает входящие, block отвечает отказом, public разрешает выбранные службы, internal и home подходят для локальных сетей, trusted пропускает всё. Не назначайте trusted интерфейсу, смотрящему в интернет.

sudo firewall-cmd --state
sudo firewall-cmd --get-zones
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --get-default-zone
sudo firewall-cmd --zone=public --list-all

Команда --list-all показывает целиком: интерфейсы, источники, службы, порты, блокировки ICMP и rich rules. Если интерфейс не указан в активной зоне, он использует зону по умолчанию. Имена интерфейсов проверяйте через ip -br link, а не угадывайте по старым примерам с eth0.

Временные и постоянные правила

Без --permanent правило действует до перезагрузки или --reload. С --permanent оно записывается в конфигурацию, но не применяется сразу. Это удобно для безопасной проверки: сначала добавьте службу во временную конфигурацию, убедитесь, что доступ работает, и только потом сохраните изменения.

sudo firewall-cmd --zone=public --add-service=https
sudo firewall-cmd --zone=public --list-services
sudo firewall-cmd --runtime-to-permanent
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --check-config
sudo firewall-cmd --reload

Важная деталь: --reload отбрасывает временные изменения, которых нет в постоянной конфигурации. Если вы добавили правило без --permanent и перезагрузили службу, оно исчезнет. --complete-reload дополнительно разрывает установленные соединения; используйте его только при смене бэкенда или серьёзной правке.

Практическая схема для сервера

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

sudo firewall-cmd --permanent --zone=public --add-service=ssh
sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --permanent --zone=public --remove-service=cockpit
sudo firewall-cmd --permanent --zone=public --remove-service=dhcpv6-client
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --list-all

Если приложение слушает нестандартный порт, добавьте его явно: --add-port=8080/tcp. Сверьте фактические слушатели через ss -tulpn и закройте всё, что не должно быть доступно снаружи.

Rich rules и ограничение доступа

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

sudo firewall-cmd --permanent --new-zone=admin
sudo firewall-cmd --permanent --zone=admin --add-source=203.0.113.0/24
sudo firewall-cmd --permanent --zone=admin --add-service=ssh
sudo firewall-cmd --permanent --zone=public --remove-service=ssh
sudo firewall-cmd --reload

Для ограничения частоты используйте rich rule с limit. Помните, что правило с accept не ограничивает службу, которая уже разрешена на уровне зоны: сначала уберите общее разрешение, затем добавьте правило с лимитом. Проверять такие схемы лучше на тестовом стенде, а не на единственном сервере.

sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="198.51.100.10" port port="22" protocol="tcp" accept'
sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule port port="8080" protocol="tcp" limit value="30/m" accept'
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --list-rich-rules

Журналы и диагностика

Включите журналирование отброшенных пакетов на время разбора. Не оставляйте подробный лог навсегда: он создаёт нагрузку и быстро занимает диск. Смотрите и журнал службы, и сообщения ядра — итоговые правила работают на уровне nftables.

sudo firewall-cmd --set-log-denied=all
sudo firewall-cmd --get-log-denied
journalctl -u firewalld -f
journalctl -k -f
ss -tulpn
nmap -Pn -p 22,80,443 192.0.2.10

nmap запускайте только для собственного узла или с письменного разрешения владельца. Сравните открытые порты с тем, что показывает ss: расхождение означает, что правило не применилось, служба слушает другой адрес или трафик обходит фильтр.

Контейнеры и типичные ошибки

Docker и некоторые другие среды управляют правилами nftables самостоятельно. Опубликованный порт контейнера может быть доступен снаружи, даже если FirewallD его не разрешает. Не полагайтесь на зону public как на границу для контейнеров: привязывайте публикацию к 127.0.0.1 и ставьте reverse proxy, либо настраивайте фильтрацию на уровне контейнерной платформы.

Не смешивайте FirewallD и ufw на одной машине: два менеджера будут перезаписывать правила. Проверьте бэкенд в /etc/firewalld/firewalld.conf и не переключайте его без понимания последствий. Аварийный вариант — firewall-cmd --panic-on, но он отключает весь сетевой доступ, включая SSH; выключить можно только с консоли: firewall-cmd --panic-off.

Чек-лист

• Активная зона и интерфейсы проверены через --get-active-zones.
• Правила сохранены с --permanent и применены через --reload.
• SSH ограничен по источнику, но консольный доступ остаётся под рукой.
• Открытые порты сверены с ss -tulpn и внешней проверкой.
• Для контейнеров настроена отдельная фильтрация, а не только зона public.

Итог

FirewallD удобен, когда зоны отражают реальные роли интерфейсов, а правила проверяются до сохранения. Держите публичную зону минимальной, используйте источники для административного доступа и не забывайте о разнице между runtime и permanent. Отдельно проверяйте контейнеры и не оставляйте журналирование отказов включённым навсегда. Аккуратная схема из нескольких зон надёжнее десятков разрозненных правил.