Почему настройка файрвола Linux даёт сбои на проде
Правила фильтрации накапливаются годами: цепочки правятся под конкретный инцидент, старые записи никто не снимает, и постепенно настройка файрвола Linux превращается в археологию. Инженер, который открывает конфигурацию, видит сотни строк, но не может ответить, какая из них закрывает какой сервис и что произойдёт, если её удалить.
Отсюда два постоянных следствия. На периметре остаются открытые порты «на всякий случай» — под отладку, старый стенд, интеграцию, которая давно не нужна; каждый такой порт переживает смену команды и выпадает из обзора. И тут же обратная беда: блокировка легитимного трафика после правки одного правила — закрываешь доступ для одной подсети, а вместе с ним отваливается мониторинг, выгрузка логов или резервное копирование, ходившие по тому же диапазону.
Корень — правила без владельца. У записи нет привязки к сервису, комментария и даты ревизии, поэтому её боятся трогать и оставляют как есть. Хаос в правилах фильтрации растёт не из-за неаккуратности инженеров, а из-за того, что изменение не проверяется на тестовом контуре и не откатывается за минуту, когда что-то пошло не так.
Даже переход на декларативное описание в nftables сам по себе задачу не решает: если правила не связаны с реальным трафиком, сервисами и владельцами, порядок останется прежним. Разбираем, как это закрывается — от инвентаризации портов до изменений, которые проверяются до прода.
Что даёт единый свод правил фильтрации трафика
Правила фильтрации, разбросанные по узлам и правленые вручную через консоль, живут до первой аварии: никто не помнит, зачем открыт порт и кто его закроет. Единый свод — это одно описание политики, которое применяется на всех серверах одинаково и хранится рядом с конфигурацией остальных сервисов. Управляемая фильтрация трафика превращает сетевые доступы в версионируемый набор: изменения проходят проверку, а не вносятся «на живую» на боевом узле.
Ключевой эффект — сокращение окна простоя при изменениях. Набор правил собирается целиком и применяется одной транзакцией: nftables подменяет таблицу атомарно, поэтому соединения не рвутся на середине правки, а неудачный вариант откатывается по таймеру, если сервис не подтвердил доступность. Окно уходит с минут ручной работы до секунд, а часть изменений проходит вовсе без разрыва уже установленных соединений.
Из списка инцидентов уходит целый класс отказов: правила, забытые после снятия сервиса с узла; дубли и пересечения, где последнее совпадение перекрывает нужное; порты, открытые «на время отладки» и оставшиеся навсегда. Прозрачность сетевых доступов достигается тем, что карта «кто к кому и на каком порту» собирается из самих правил и журналов, а не восстанавливается по памяти в момент аварии.
Время восстановления сервиса перестаёт зависеть от того, кто из инженеров на смене: состояние фильтрации воспроизводится на новом узле из того же свода за минуты, а возврат к предыдущей ревизии — это откат набора, а не поиск ошибки в длинном списке строк. Политика запрета по умолчанию при этом гарантирует, что забытое правило закрывает доступ, а не открывает его.
Пакетный, зонный и облачный режимы фильтрации
Выбор инструмента фильтрации определяет, где живут правила, кто их меняет и переживут ли они обновление системы. При настройке файрвола Linux обычно выбирают между четырьмя режимами — от ручных цепочек до внешних групп безопасности.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| iptables | Готовые скрипты, точечные правила на одном хосте | Таблицы читаются линейно: с ростом числа правил растёт задержка, синтаксис не развивается |
| nftables | Сложные наборы правил, нужны множества адресов и общая логика для IPv4 и IPv6 | Старые конфигурации приходится переписывать, часть панелей управления с ним ещё не работает |
| firewalld и зонная модель фильтрации | Хосты с меняющимся профилем: офис, VPN, публичный интерфейс — переключение без пересбора цепочек | Абстракция зон скрывает низкоуровневые возможности, правила-исключения сложнее отлаживать |
| Группы безопасности облака | Машины в облаке, где фильтрация задаётся на уровне сети | Не закрывают трафик внутри хоста и между контейнерами, зависят от площадки — локальный файрвол всё равно нужен |
На практике режимы комбинируют: внешние группы безопасности отсекают лишнее до машины, локальный файрвол закрывает остальное внутри. Разбор начинаем с карты сервисов и направлений трафика.
Порядок внедрения: от инвентаризации до регламента
Правила не пишутся «на глаз»: сначала нужно понять, что реально ходит по сети, иначе закрытый порт — это либо дыра, либо упавший сервис. Работу ведём от инвентаризации к регламенту, чтобы после передачи изменения вносили ваши инженеры без нашего участия.
- Аудит сетевых правил — снимаем текущие цепочки iptables, nftables и зоны firewalld, сверяем с фактически работающими сервисами. Находим дубли и разрешения «any-any», оставшиеся от удалённых сервисов.
- Схема сетевых потоков — фиксируем, кто с кем общается: источник, назначение, порт, протокол, смысл потока. Схему согласуем с владельцами сервисов, а не только с администраторами.
- Настройка правил — запрет по умолчанию плюс явные разрешения, сгруппированные по назначению, с комментарием к каждому правилу.
- Проверка на тестовом контуре — копия топологии, реальный трафик и негативные сценарии: что именно отвалится, если закрыть лишнее.
- Контролируемый перенос правил — применяем поэтапно, со скриптом отката и окном, когда возврат занимает минуты, а не часы.
- Регламент изменений — порядок согласования правки, фиксация в системе контроля версий, периодический пересмотр устаревших разрешений.
После передачи остаётся не набор команд, а воспроизводимый процесс: правка проходит проверку на контуре и не превращается в сюрприз в три часа ночи. Регламент описывает, кто и как вносит изменения, — это снимает зависимость от конкретного человека.
Что передаём на руки: схемы, политики, регламенты
Сдаём не работающий файрвол, а набор артефактов, по которому ваша команда сможет менять конфигурацию без нас. Всё, что уходит в боевую среду, сначала фиксируется в репозитории и описании — иначе следующая правка превращается в археологию по истории команд на сервере.
- Конфигурации набора правил — в репозитории, а не только на хосте: версионируются как код, с пометкой, какой снимок применён сейчас и чем он отличается от предыдущего.
- Матрица сетевых доступов: источник, назначение, порт, протокол, кто инициирует соединение и зачем — по каждой разрешающей строке; запреты по умолчанию описаны отдельным блоком.
- Политики ограничения трафика: лимиты скорости и числа одновременных соединений по сервисам, отдельные условия для служебных подсетей и админского доступа, поведение при всплесках.
- Порядок отката изменений: как вернуть предыдущий набор, за какое время и что проверить после возврата, включая сценарий потери доступа к серверу.
- Документация по инфраструктуре: схема прохождения трафика, зоны и цепочки, места стыковки с балансировщиком и обратным прокси.
- Регламент внесения изменений: кто согласует новое правило, где оно проверяется до боевой среды и как фиксируется в журнале изменений.
- Журналирование и приёмка: какие события пишутся и куда, плюс чек-лист проверок, который ваша команда прогоняет сама и подтверждает воспроизводимость конфигурации.
Так конфигурация перестаёт зависеть от одного инженера: её можно прочитать, проверить и изменить по документу, а не по памяти.
Кейс: как закрыли периметр и убрали класс отказов
До: правила без владельца
Периметр рос стихийно: около четырёхсот правил, накопленных разными командами, треть из них — без владельца. Никто не мог объяснить, зачем открыт порт и что сломается при его закрытии, поэтому «на всякий случай» оставляли как есть. Порядок обработки не соблюдался: разрешающие правила стояли выше запрещающих, и часть трафика блокировалась не там, где ожидали. Аудит доступа растягивался на дни, а восстановление после сбоя шло руками по памяти.
Что изменили
Мы свели правила в единый реестр, сопоставили каждое с сервисом и ответственным, а логику перенесли в декларативные наборы nftables — конфигурация стала одинаковой на всех средах и версионируемой. Всё, что не подтверждено владельцем, закрыли по умолчанию, доступ выдаём по шаблону под конкретный сервис, а не правкой вручную.
Метрики до и после
- Сервисов, доступных снаружи: 46 → 11, вчетверо меньше точек входа
- Правил с подтверждённым владельцем: 31% → 100%
- Взаимные блокировки: 9 случаев за квартал → 0
- Восстановление конфигурации после сбоя: ~45 минут руками → 6 минут развёртыванием из реестра
- Проверка доступа перед релизом: 2 дня → 20 минут
Главный результат не в числе закрытых портов, а в предсказуемости: каждое правило имеет обоснование, изменение откатывается одной операцией, а новый сервис получает доступ по шаблону. Именно это убрало класс отказов, связанных с взаимными блокировками.
Чем отличается настройка фильтрации узла и периметра сети?
Фильтрация на узле отвечает на вопрос «кто может обратиться к этому сервису». Правила в nftables, iptables или firewalld описывают, какие порты слушают наружу, какие адреса допущены к управляющим интерфейсам, как обрабатываются установленные соединения. Это последний рубеж: если входной контур пропустил лишнее, отказ принимает уже сам сервер.
Защита периметра сети работает на другом уровне — там решается, какие подсети вообще видят друг друга и какие сервисы публикуются наружу. Один хост с открытым портом не должен становиться точкой входа во всю сеть, поэтому периметр описывает маршрутизацию и трансляцию адресов, а не только перечень разрешённых портов.
Сегментация внутренних сервисов добавляет третий уровень: база данных, очередь и внутренний API живут в разных сегментах, а доступ между ними открывается точечно, по связке «источник — назначение — порт». Тогда компромисс одного узла не отдаёт под удар остальные, и граница распространения атаки известна заранее.
Конфликт уровней фильтрации возникает не в самих правилах, а в их рассогласованности. Узел с политикой «запрещать всё, кроме явно разрешённого» перестаёт принимать трафик при смене периметра, а сегмент, открытый «на время отладки», остаётся открытым навсегда. Поэтому политику мы описываем сверху вниз — от периметра к узлу — и проверяем, что каждый уровень запрещает по умолчанию, а разрешения совпадают с реальным трафиком, а не с исходными предположениями.
Вопросы по совместимости и откату правил
Ядро Linux допускает сосуществование разных инструментов фильтрации: пока один набор правил работает, второй собирается и проверяется параллельно. Поэтому переход между iptables, nftables и firewalld не требует окна простоя — открытые соединения и маршруты не рвутся.
Любую правку ведём по одной схеме: правило проверяется на копии конфигурации, применяется в работающем наборе, а предыдущее состояние сохраняется отдельным снимком. Ниже — типовые сомнения, которые возникают перед такой правкой.
Можно ли держать iptables и nftables на одном узле?
Да. Инструменты работают с разными наборами внутри ядра и не мешают друг другу, пока одно соединение не описано дважды. Старый набор остаётся активным, пока новый не проверен, — только потом снимаем дубли.
Что будет, если новое правило отрежет доступ к серверу?
Снимок текущего набора сохраняется до применения, а правка вносится из отдельной сессии. Откат возвращает предыдущее состояние за секунды и не требует перезагрузки узла.
Нужно ли останавливать сервис на время правок?
Нет. Правила добавляются и снимаются в работающем наборе, установленные соединения продолжают жить. Остановка нужна только при смене самого механизма фильтрации — и то после проверки нового набора.
Как убедиться в безопасности правила до применения?
Прогоняем конфигурацию в тестовом режиме: смотрим, какие пакеты она пропускает и блокирует, сверяем с матрицей доступов. Лишние блокировки убираем до того, как правило попадёт на рабочий узел.
Обсудим задачу: разберём схему и вернёмся с планом
Чтобы оценка объёма работ опиралась на факты, а не на догадки, нам полезно увидеть вашу текущую картину: действующие наборы правил, схему зон и интерфейсов, список сервисов с входящим трафиком и то, что уже мешает работе — блокировки легитимных соединений или открытые порты, о которых никто не помнит.
В ответ возвращаем не «разберёмся на месте», а конкретный набор:
- разбор текущих цепочек и таблиц: что фактически пропускается, что блокируется и где правила дублируют друг друга;
- карта сервисов, портов и источников трафика — с пометкой, какие из них подтверждены владельцами систем;
- оценка объёма работ: сколько правил переписываем, что переносим без изменений, где нужны новые зоны;
- план внедрения с порядком перевода правил — от периферийных узлов к критичным, чтобы не терять доступ к серверу;
- схема фиксации и отката: наборы правил сохраняются до изменений, возврат к прежнему состоянию занимает минуты;
- порядок проверок после перевода: какие соединения подтверждаем вручную, какие пути держим под наблюдением;
- ответственный инженер на связи и точка, куда стекаются журналы сработавших правил.
Предлагаем обсудить задачу фильтрации предметно — по вашей схеме, а не по шаблону. Инженерная команда на связи: разберём спорные участки, покажем, как те же задачи закрывались на похожих контурах, и вернёмся с оценкой объёма работ и планом внедрения.
