Настройка UFW / firewalld / iptables / nftables: аудит и конфигурация

Настройка UFW: где ломается фильтрация трафика

Настройка UFW выглядит как несколько команд allow — и поэтому фильтрация трафика на хосте часто оказывается декоративной. UFW не самостоятельный фильтр, а надстройка над iptables и nftables: он собирает цепочки из файлов в /etc/ufw и применяет их целиком при reload. Сбой — это обычно не «забыли правило», а неверная политика по умолчанию, порядок правил фильтрации или потеря состояния при перезагрузке.

Порядок решает больше, чем состав: фильтр срабатывает по первому совпадению, поэтому разрешение, добавленное раньше блокирующего, перекрывает его. Вторая тихая ошибка — привязка к интерфейсу: правило висит на внешнем, а трафик приходит через туннель или внутренний мост и под него просто не попадает.

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

Наконец, живучесть конфигурации: правила, добавленные вручную через iptables, после перезагрузки исчезают, а ufw без автозапуска поднимается пустым. Проверять это нужно по фактическому набору цепочек в момент загрузки, а не по выводу status.

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

Что меняется после аудита правил: измеримые эффекты

Аудит начинается со сверки трёх списков: что слушает на интерфейсах, что действительно нужно снаружи, что разрешено в правилах. Расхождение между ними и есть поверхность атаки — отладочные порты, панели администратора, СУБД, открытые «на пару дней». После чистки наружу остаётся только трафик пользователей, а доступ инженеров уходит в отдельный контур.

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

Время восстановления доступа измеряется минутами вместо часов. Типовой сбой — правило, отрезающее администратора от узла; при сохранённом консольном доступе и зафиксированном порядке применения доступ возвращает откат конфигурации, без пересборки сервера. Запрет по умолчанию здесь не мешает, а помогает: причина потери доступа видна сразу.

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

Настройка UFW и альтернативы: сравнение режимов фильтрации

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

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

Этапы работ: аудит правил, схема, настройка, проверка, передача

Аудит конфигурации начинается не с правки правил, а с инвентаризации: какие сервисы слушают порты, кто и откуда к ним обращается, где трафик идёт через балансировщик, а где напрямую. Без схемы прохождения трафика любое изменение — догадка, и первый закрытый порт ломает рабочий сценарий. Поэтому порядок внедрения жёсткий: сначала фиксируем состояние как есть, потом меняем — группами, с готовым откатом.

1. Инвентаризация сервисов. Собираем список слушающих портов и их потребителей, включая внутренние сети и офис. Здесь всплывают забытые административные порты и диапазоны, открытые «на всякий случай».
2. Снятие текущих правил. Выгружаем действующие наборы ufw, firewalld, iptables или nftables, сверяем с фактическим поведением узла, отмечаем дубли и правила, которые уже ни на что не влияют.
3. Схема прохождения трафика. По каждому маршруту фиксируем цепочку «периметр — балансировщик — приложение — база» с источником, назначением и портом. Схема становится основой и для политики, и для разбора инцидентов.
4. Проектирование политики. Запрет по умолчанию, точечные разрешения под подтверждённые маршруты, отдельные зоны для служебных сетей и порядок, при котором частные правила срабатывают раньше общих.
5. Внедрение. Применяем группами — по сервису или сегменту, сначала на тестовом узле, затем на продуктивном, в согласованное окно и с подготовленным откатом.
6. Проверка правил. Прогоняем трафик снаружи и изнутри: нужное доступно, лишнее закрыто, отказы попадают в журнал. Отдельно убеждаемся, что правила переживают перезагрузку.
7. Передача регламентов. Отдаём конфигурации в системе контроля версий, схему трафика, описание политики и порядок согласования изменений — чтобы следующая правка не начиналась с нуля.

Политики доступа, конфигурации и регламенты на выходе

Аудит не заканчивается отчётом: результат — воспроизводимый набор артефактов, по которым инфраструктуру можно пересобрать и безопасно менять. Всё, что мы правим на серверах, оседает в файлах, а не в истории команд и памяти процесса. Ниже — то, что остаётся у заказчика.

• Конфигурационные файлы правил в синтаксисе вашего стека (ufw, firewalld, nftables) — с комментарием к каждому исключению, а не только строки правил.
• Политики доступа по умолчанию: явно зафиксировано, что закрыто, что разрешено и по какому признаку правило считается лишним.
• Карта сервисов: какие порты и адреса кому нужны, кто владелец сервиса и к какому окну обслуживания он привязан.
• Адресные группы и роли: именованные наборы адресов вместо разрозненных подсетей — правка группы обновляет правила сразу во всех местах.
• Регламент изменений: кто согласует новое правило, какие проверки обязательны до публикации и через какой срок правило пересматривают.
• Схема сетевых зон и порядок прохождения трафика между ними — в виде, пригодном для передачи новому инженеру.
• Процедура отката: снимок рабочей конфигурации и последовательность возврата к нему за минуты, а не за часы разбора.
• Перечень снятых правил с причиной: устаревшие разрешения не остаются в конфигурации «на всякий случай».

Набор самодостаточен: по нему можно провести повторный аудит и увидеть, что изменилось с прошлого раза.

Кейс: как закрыли обход фильтрации на хосте с контейнерами

Что было

Этот кейс внедрения начался с внешнего сканирования: на хосте с контейнерной средой извне отвечали 23 сервиса, хотя межсетевой экран настроен и политика по умолчанию запрещала входящие. Причина оказалась не в ошибке в правилах, а в порядке обработки трафика: Docker при публикации портов пишет собственные цепочки проброса, которые срабатывают раньше пользовательских. В итоге панель метрик, админка очереди и внутренний реестр образов были доступны любому, кто знал адрес.

Что изменили

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

Метрики до и после

Доступных извне сервисов стало 4 вместо 23, остальные отвечают только внутри контейнерной сети. Внесение следующего изменения в фильтрацию занимает несколько минут вместо ручной проверки цепочек по всему хосту. Повторный аудит проводим раз в квартал: сверяем фактические правила с описанными, проверяем, не открыл ли новый сервис порт наружу, и пересматриваем цепочки после обновления контейнерной среды.

Что делать, если уже развёрнут iptables и правила живут вразнобой

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

Дальше выбор из трёх стратегий, и различаются они не объёмом работы, а ценой ошибки.

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

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

Частые технические сомнения перед стартом работ

Сомнения перед стартом обычно одни и те же: не отрежет ли новое правило удалённый доступ, как откатиться, если связь пропадёт. Опасение обоснованное — фильтр начинает работать сразу, и ошибка в одной строке закрывает вход раньше, чем вы успеваете это заметить.

Поэтому правила применяем поэтапно: сначала разрешающие для текущей сессии, потом ограничивающие, с проверкой на отдельном контуре и таймером, который вернёт прежний набор, если связь не подтвердилась. Конфигурация живёт в репозитории, поэтому любое изменение откатывается одной командой, а не восстановлением доступа через консоль провайдера.

Как вы версионируете правила?

Все наборы хранятся в системе контроля версий: видно, кто и зачем менял правило, а откат к рабочему состоянию занимает минуты. История изменений остаётся у вас, а не в переписке.

Учитываете ли вы контейнеры при публикации портов?

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

Работает ли это с адресацией нового поколения?

Да, наборы для нового протокола адресации настраиваются отдельно от привычных. Частая проблема — открытый доступ по одному типу адресов при закрытом по другому, поэтому проверяем оба варианта.

Ограничиваете ли вы панели управления?

По умолчанию панели и административные интерфейсы закрыты от внешней сети и доступны только через доверенный контур или защищённый туннель. Это убирает самый частый вектор — перебор пароля к открытой панели.

Обсудим задачу: аудит правил и план изменений

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

• Доступы: как заходим на узел — ключ или консоль, есть ли промежуточный хост, хватает ли прав, кто ещё ходит на машину. От этого зависит порядок правок, чтобы не отрезать себе вход.
• Схема сети: интерфейсы, адресация и подсети, балансировщик, VPN, обратный прокси. Без неё нельзя корректно описать источники трафика в правилах.
• Список сервисов: что слушает наружу, а что доступно только внутри узла, где TCP, а где UDP, кому извне действительно нужен доступ.
• Текущее состояние: выводы конфигурации, счётчики срабатываний, порядок цепочек и зон, не работают ли два менеджера правил одновременно.
• Ограничения: требования аудита и внутренних регламентов, согласованные исключения, сервисы, которые трогать нельзя.
• Окно изменений: допустимый простой, часы низкой нагрузки, дежурный на связи, порядок отката.

По этим данным собираем план изменений: последовательность правок, проверки до и после каждого шага, точку возврата и критерии, по которым считаем результат достигнутым. Резервная копия правил готовится до начала работ, а само окно изменений согласуем заранее. Оценка работ приходит вместе с планом: этапы, сроки и то, кто подтверждает результат на стороне заказчика.