Регламент изменений в firewall: почему каждое правило нужно подписывать

MAATRIX

Открываете iptables -L или ufw status numbered на сервере, который живёт третий год, и видите два десятка правил без единого комментария: порт 8443 для какого-то IP, диапазон 10.0.5.0/24 с доступом к базе, ещё пяток разрозненных ALLOW-строк. Никто в команде не помнит, зачем это открыто и можно ли закрыть. Проблема не в самих правилах — она в том, что их писали второпях и без единой пометки "зачем", а теперь их боятся трогать. Ниже — рабочий регламент, который решает это не героическим расследованием задним числом, а простой привычкой подписывать правило в момент его создания.

Почему неподписанные правила — это не мелочь, а системный риск

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

• Правило превращается в чёрный ящик. Никто не может сказать, обслуживает ли оно живой процесс, тестовый стенд, который свернули полгода назад, или доступ подрядчика, чей контракт давно закончился.
• Удалить его боится каждый. Логика простая и обоснованная: если правило действительно нужно, его удаление положит прод в самый неподходящий момент, а расследовать причину придётся уже в панике. Дешевле оставить как есть.
• Мусор накапливается по экспоненте. Каждое новое неподписанное правило добавляется поверх старых неподписанных, и через пару лет firewall представляет собой археологический разрез: слой за слоем decisions, каждое из которых никто не может обосновать.
• Растёт реальная площадь атаки. Забытое правило — это не абстрактный беспорядок, а конкретный открытый порт или диапазон IP, который никто не мониторит и не проверяет на актуальность. Именно такие правила чаще всего оказываются причиной инцидента — см. разбор в server-vzlomali-cherez-zabytyj-port-rekonstrukciya.
• Аудит безопасности упирается в стену. Когда приходит внешний аудитор или пора проходить сертификацию, объяснить происхождение каждого правила становится отдельным многодневным проектом вместо десяти минут чтения комментариев.

Отдельно стоит сказать про антипаттерн, который вырастает из этой же проблемы: если разобраться в правилах невозможно, у части команды возникает соблазн решить вопрос радикально — открыть всё и не разбираться. Это тупиковый путь, и почему он тупиковый, подробно разобрано в antipattern-firewall-razreshit-vsyo. Регламент ниже — это как раз способ не скатиться в эту крайность.

Принцип: правило и комментарий создаются одной командой, не двумя

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

Формат комментария — не эссе, а три обязательных поля в одну строку:

1. Зачем — какую задачу решает правило (доступ к API, проброс для мониторинга, временный доступ подрядчика).
2. Для кого — конкретный человек, сервис или команда, а не абстрактное "для разработки".
3. Когда добавлено — дата в явном виде, чтобы можно было посчитать возраст правила без раскопок в истории.

Если у правила есть плановая дата истечения (временный доступ, тестовый стенд) — она указывается тоже, четвёртым полем. Это превращает часть правил из "потенциально бессрочных" в правила с встроенным сроком годности, которые можно чистить автоматически.

Как это выглядит на практике: iptables и nftables

В iptables штатной поддержки комментариев к самим правилам в человекочитаемом виде нет, зато есть модуль comment, который решает задачу ровно для этого:

iptables -A INPUT -p tcp --dport 8443 -s 203.0.113.10 \
  -m comment --comment "API webhook для CRM партнёра; добавил Иван; 2026-03-14; см. тикет OPS-412" \
  -j ACCEPT

Комментарий виден прямо в выводе:

iptables -L INPUT -v --line-numbers | grep 8443

5    0     0 ACCEPT     tcp  --  any    any     203.0.113.10        anywhere    tcp dpt:8443
     /* API webhook для CRM партнёра; добавил Иван; 2026-03-14; см. тикет OPS-412 */

В nftables, который на конец августа 2026 года всё чаще стоит по умолчанию в свежих дистрибутивах вместо iptables, комментарии — часть синтаксиса, без дополнительных модулей:

table inet filter {
  chain input {
    tcp dport 8443 ip saddr 203.0.113.10 accept comment "API webhook CRM партнёра; Иван; 2026-03-14; OPS-412"
  }
}

Комментарий сохраняется при nft list ruleset и переживает перезапуск, если конфиг вынесен в файл /etc/nftables.conf, а не введён вручную в сессии.

Как это выглядит на практике: ufw и облачные security group

ufw — самый частый выбор на VPS, и в нём тоже есть штатное поле для комментария, о котором многие не подозревают:

ufw allow from 203.0.113.10 to any port 8443 proto tcp comment 'API webhook CRM партнёра; Иван; 2026-03-14; OPS-412'

Комментарий отображается в списке:

ufw status numbered

[ 3] 8443/tcp                   ALLOW IN    203.0.113.10   # API webhook CRM партнёра; Иван; 2026-03-14; OPS-412

Если у вас ufw без графических извращений — это самый дешёвый способ внедрить регламент прямо сегодня, без миграции на другой инструмент. Базовую настройку ufw с нуля разбирали в kak-ustanovit-i-nastroit-faervol-ufw-na-vps.

В облачных security group (AWS, Yandex Cloud, VK Cloud и подобных) поле описания у правила есть почти всегда в интерфейсе и в API — им тоже стабильно пренебрегают. Правило регламента распространяется и туда: описание заполняется в момент создания правила, а не оставляется пустым "чтобы не тормозить".

Периодическая ревизия: правила без комментария — кандидаты на удаление

Подписывать новые правила недостаточно — нужен механизм для наследия, которое уже накопилось без комментариев. Здесь регламент опирается не на память, а на расписание.

Практический процесс ревизии:

1. Раз в квартал выгружается полный список активных правил firewall.
2. Правила делятся на три группы: с комментарием и понятным назначением; с комментарием, но с истёкшим сроком (временный доступ, который пора закрыть); без комментария вообще.
3. Правила без комментария автоматически попадают в статус "кандидат на удаление" — не удаляются сразу, а выносятся в отдельный список с уведомлением ответственных.
4. По каждому кандидату даётся срок (например, две недели) на то, чтобы кто-то в команде опознал правило и либо подписал его задним числом с реальным обоснованием, либо подтвердил, что оно не нужно.
5. Неопознанные правила по истечении срока удаляются — сначала на тестовом окне, если такая возможность есть, с мониторингом трафика через это правило до отключения.

Простой скрипт для iptables, который находит правила без комментария — отправная точка для автоматизации этого шага:

#!/usr/bin/env bash
# Правила INPUT без модуля comment — кандидаты на ревизию
iptables -L INPUT -v -n --line-numbers | \
  awk '/^[0-9]/{line=$0; getline next_line; \
       if (next_line !~ /\/\* /) print line}'

Для nftables то же самое проще проверить через nft -j list ruleset и отфильтровать записи без ключа comment в JSON — это удобнее скриптовать на Python или jq, если правил много.

Периодичность в квартал — это ориентир, а не догма: на сервере с частыми изменениями (активная разработка, регулярные временные доступы подрядчиков) разумнее сверяться раз в месяц. Смежная практика — ежемесячная сверка открытых портов как таковых, отдельно от происхождения правил, описана в ezhemesyachnaya-sverka-otkrytyh-portov-na-servere.

Где регламент пересекается с журналом изменений

Комментарий в самом правиле firewall и запись в общем журнале изменений сервера — это не взаимозаменяемые вещи, а два уровня одной практики. Комментарий в правиле — это контекст, который виден в момент, когда кто-то смотрит именно на это правило: ufw status или iptables -L показывают его сразу, без похода в отдельную систему. Журнал изменений — это хронология: что, когда и в какой последовательности менялось на сервере в целом, с возможностью посмотреть diff конфига до и после.

Практическая связка: в комментарии правила достаточно короткой ссылки на тикет (OPS-412), а полное описание — почему именно такой порт, какие альтернативы рассматривались, кто согласовал — идёт в журнал изменений или трекер задач. Так комментарий остаётся коротким и читаемым прямо в выводе команды, но не теряет связи с полным контекстом. Как вести журнал изменений сервера правильно — отдельная тема, разобранная в zhurnal-izmenenij-servera-kak-vesti-pravilno.

Ещё одна смежная привычка, которая усиливает регламент: одно изменение firewall — это одна команда, один комментарий, один коммит в конфиг, а не пакет из пяти правил, добавленных одним махом "заодно". Если приходится откатывать — откатывается ровно то, что сломало, а не гадать, какое из пяти правил виновато. Подробнее про этот принцип — в pravilo-odnogo-izmeneniya-za-raz-na-servere.

Кто отвечает за соблюдение регламента

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

Если изменения firewall проходят не вручную, а через IaC-инструмент (Ansible, Terraform, конфиг в git), формат комментария удобно закрепить прямо в шаблоне правила или в шаблоне pull request — так его физически не пропустить, а не просто держать в виде договорённости на словах. Это тот случай, когда небольшая формальная обвязка экономит часы разбирательств позже.

Стоит подчеркнуть честно: регламент не защищает от ситуации, когда автор правила пишет формально верный, но бессмысленный комментарий вроде "нужно для работы" — это тоже мусор, просто оформленный. Смысл в конкретике: не "для API", а "для webhook от CRM Bitrix24, endpoint /webhook/orders, интеграция с отделом продаж". Ревьюер (если он есть) — это последний фильтр против пустых формулировок.

Частые вопросы