FirewallD: как временные правила превращаются в ловушку для администраторов

FirewallD: когда удобство оборачивается ловушкой

Администратор подключён к серверу по SSH и тестирует новый сайт. Он открывает порт 80, чтобы проверить доступность — правило работает. Затем запускает firewall-cmd --reload, чтобы применить постоянные настройки. Сайт снова недоступен, а SSH-сессия остаётся единственным каналом. В чём дело?

FirewallD делит конфигурацию на два уровня: runtime (текущие правила) и permanent (постоянные). Временные изменения применяются сразу, но не сохраняются. Команда --reload не просто подгружает постоянные правила — она сбрасывает все временные, не записанные в конфигурацию. Ошибка в том, что администратор забыл сохранить правило в permanent. Последствия: сайт падает, а доступ к серверу зависит от единственной сессии.

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

Зоны: не набор фильтров, а политика безопасности

FirewallD не заставляет администратора писать правила вручную. Вместо этого он предлагает предопределённые зоны: drop, block, public, external, dmz, work, home, internal, trusted. Каждая зона — это заранее настроенный набор фильтров, который можно привязать к интерфейсу или источнику трафика.

Зона external подходит для маршрутизаторов с маскарадингом, а drop полностью блокирует входящий трафик без ответа — полезно для изоляции атакующих хостов. Зона trusted даёт полный доступ без проверок, и её часто применяют к внешним интерфейсам. Это грубая ошибка: любой хост в зоне trusted может использовать сервер как ретранслятор. FirewallD не исправляет небезопасные приложения — он лишь ограничивает поверхность атаки, если зона выбрана правильно.

Администраторам стоит начинать с public и перемещать хосты во внутренние зоны (internal, home) только после проверки. Ошибка в выборе зоны оборачивается ложным чувством безопасности: FirewallD просто выполняет свою роль, а не подменяет собой анализ рисков.

Rich Language: гибкость, которая требует тестирования

Синтаксис Rich Language позволяет строить правила без низкоуровневой возни с iptables. Например, можно разрешить NFS только для подсети 192.168.1.0/24 или ограничить SSH по IP. Документация (ArchWiki, гайды) описывает базовый синтаксис, но примеры сложных сценариев — редкость.

Администраторы часто комбинируют условия: по IP, порту и времени в одном правиле. Такой подход удобен, но требует внимательного тестирования. Rich Language не панацея — это инструмент, который нужно проверять в боевых условиях. Ошибка в синтаксисе или логике условия приведёт к неожиданным блокировкам, а отладка затянется, если нет логов или чёткого понимания, какие правила сработали.

ICMP-фильтрация и ipset: неочевидные инструменты

FirewallD позволяет гибко настраивать ICMP-правила. Например, можно блокировать echo-request (ping) для уменьшения поверхности атаки или оставлять его открытым для диагностики. Это не стандартная настройка, но она полезна в сетях с повышенными требованиями к безопасности.

Ещё один инструмент — ipset. Он позволяет создавать именованные наборы IP-адресов и привязывать к ним правила. Например, белый список доверенных подсетей: ipset create trusted_networks hash:net и правило, разрешающее доступ только для этого набора. Такой подход удобен для динамических списков адресов, когда вручную править правила неэффективно.

Интеграция с контейнерами: FirewallD не всёсилен

FirewallD по умолчанию не управляет правилами Docker и Podman. Контейнеры добавляют свои цепочки в iptables/nftables, а FirewallD — свои. Если оба инструмента пытаются управлять одними и теми же портами, конфликтов не избежать.

Представьте: контейнер слушает 8080, а FirewallD открывает 80 для веб-сервера. Правила соревнуются, и результат непредсказуем. Решение — изолировать контейнеры через зоны или явно управлять правилами через --direct, но это усложняет конфигурацию. В критичных инфраструктурах лучше использовать специализированные инструменты, такие как Calico для Kubernetes, где сетевая политика реализована на уровне кластера.

FirewallD не панацея для сетей с контейнерами. Его задача — базовая сетевая гигиена, а не замена инструментов управления на уровне приложений.

Бэкенды: по умолчанию nftables, но не только

В RHEL-совместимых системах FirewallD использует nftables по умолчанию. В некоторых гайдах (например, для Rocky Linux) упоминается работа с iptables — это не ошибка, а возможность переключения через direct interface.

FirewallD управляет только своими правилами в отдельной таблице firewalld. Чужие правила (от libvirt, Docker, других инструментов) обрабатываются до правил FirewallD. Если правила FirewallD не применяются, дело может быть в конфликте с другим инструментом. Понимание бэкенда критично для отладки: не зная, кто за что отвечает, администратор теряет время на поиск причин.

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

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

Пример: проброс 12345/tcp → 22 на внутренний IP 10.20.30.40. Если хост в той же сети, маскарадинг не нужен. FirewallD гибок, но его документация не всегда отражает все сценарии. Администраторам стоит тестировать правила в боевых условиях, чтобы не попасть в ловушку избыточных или недостаточных настроек.

Политики и графические инструменты: что остаётся за кадром

FirewallD поддерживает объекты политик для фильтрации трафика между зонами. Например, правило может разрешать доступ из зоны internal в зону public, но блокировать обратный трафик. Эта функция мало освещена в гайдах, но полезна для сложных сетевых архитектур.

Для десктопов доступны графические инструменты: firewall-config (GTK3) и firewall-applet (Qt5). На серверах их редко используют — администраторы предпочитают CLI. Однако для быстрой проверки или обучения интерфейсы могут быть полезны.

Границы FirewallD: где он полезен, а где — нет

FirewallD — это не замена WAF или защиты от DDoS, а инструмент базовой сетевой гигиены. Он полезен для закрытия случайно поднятых сервисов, ограничения поверхности атаки и быстрого внедрения правил доступа через rich rules. Но он не исправляет небезопасные приложения и не защищает от атак на уровне приложений.

В сложных сетях (например, с Kubernetes) FirewallD может конфликтовать с другими инструментами управления сетью, такими как Calico. Администраторам стоит тестировать правила в боевых условиях, отслеживать логи отклонённых пакетов и понимать, что правила других инструментов могут обходить FirewallD. Для критичных инфраструктур это означает одно: не полагаться на FirewallD в одиночку.