Короткий ответ

Ревизия — календарный процесс, не «почистить в проде глазами». Снимите backup и текстовый export, сведите правила в таблицу (цепь, match, action, counter, comment, владелец, заявка), найдите any-any, shadowing, нулевые allow, WAN-дыры. Назначьте владельца или поставьте срок удаления. Мёртвое — disable на окно, потом delete. Firewall всё время включён. Не nft flush ruleset «чтобы начать с чистого».

Связанные артефакты: матрица портов, any-any, порядок.

WAN 203.0.113.10, LAN 10.0.10.0/24, DMZ 10.0.30.0/24, mgmt 10.0.99.0/24.

Симптомы и как отличить

Конфиг растёт, никто не может ответить «почему 8443 с WAN». Comment пустой. На RouterOS 400 filter lines, из них 80 с нулём packets за квартал (после честного reset в начале окна — осторожно). Аудит пишет finding.

Это не инцидент «сервис лёг». Это гигиена. Если сервис уже мёртв из‑за shadow — сначала чините поток, ревизия параллельно.

Возможные причины

  1. Нет владельца периметра.
  2. Каждый подрядчик add в конец.
  3. Ansible и ручные правки вперемешку.
  4. Страх удалить.
  5. Два шлюза, ревизия одного.

Диагностика

1. Заморозка изменения (мягкая)

Объявите freeze на add без тикета на время аудита (дни, не месяцы). Backup:

sudo nft list ruleset -a > /root/fw-review-$(date +%F).nft
sudo cp /etc/nftables.conf /root/nftables.conf.review
/system backup save name=fw-review
/export file=fw-review
/ip firewall filter print stats without-paging
/ip firewall nat print stats
/ip firewall raw print stats

Концептуально pf: dump rules+states в файл тикета.

2. Таблица правил

Колонки: id/handle, chain, in/out, src, dst, proto, port, state, action, packets, bytes, comment, owner, ticket, decision (keep/disable/delete/rewrite).

Owner пустой = decision disable в очереди, не keep.

3. Автоматические красные флаги

  • accept без src/dst/port на new
  • WAN in + admin ports
  • DMZ→LAN accept широкий
  • дубли match
  • comment temp/test/asap
  • disabled годами — либо delete, либо explaine

Включите log на кандидатов удаления на неделю.

4. Сверка с матрицей и сканом

Свой nmap 203.0.113.10 vs allow WAN. Расхождение — finding, не «сканер врёт».

Не сканируйте чужое.

Решение

Идите пакетами: сначала WAN input, потом NAT, потом forward DMZ, потом LAN. Не правьте всё за час.

Сценарий A. Нулевой allow старше SLA

Если счётчик 0 за 90 дней без reset: disable, комментарий review-disable DATE ticket. 14 дней канарейка. Delete.

Не delete established-related.

Сценарий B. Нет владельца, но counter живой

Найдите поток (dst, порт), спросите бизнес. Запишите ФИО. Если бизнес «не наше» — план сужения.

Сценарий C. Any-any

Не удаляйте в том же коммите, что десять мелочей. Отдельное окно по статье any-any.

Сценарий D. Тень

Переставьте, не копируйте третье allow. После move — функциональный тест и скан WAN.

Сценарий E. Двойной источник правды

Живой nft и git /etc/nftables.conf разъехались. С этого дня правки только файл + nft -c + reload. RouterOS: после GUI — export в git (без секретов) или только API.

Откат: backup load / nft -f снимка. Не stop службы filter.

На pfSense: disable rule (не delete) с описанием ticket, apply, окно, затем remove.

Отчёт ревизии, который можно сдать повторно через квартал

Фиксируйте в одном PDF/wiki: дата, хэш export (sha256sum fw-review.rsc), таблица правил с owner, список disable за период, результат LTE-скана 203.0.113.10, кто тестировал VPN и 443. Без хэша снимка «мы почистили» не доказать.

Пакетирование: WAN input → dstnat → forward DMZ → LAN. После каждого пакета — 15 минут канарейки, не 40 delete подряд. Orphan allow с живым counter не delete: сначала owner, потом сужение 5-tuple. Нулевой allow: disable, не drop замена без понимания match (можно открыть дыру, если это было shadow). Git /etc/nftables.conf как единственный источник: расхождение live vs файл — finding отдельным тикетом, чинится до удаления «лишнего» в GUI.

Как проверить, что проблема устранена

Чеклист отчёта ревизии:

  1. 100% правил с comment и owner (или явно orphan-disable).
  2. Нет WAN any-any new.
  3. Скан своего периметра = матрица.
  4. Бизнес-потоки из списка живы.
  5. Число правил уменьшилось или стабилизировалось, disabled очередь на delete.
  6. Дата следующей ревизии в календаре (квартал).
sudo nft list ruleset | grep -c accept

Цифра в отчёте «было/стало» с пояснением, не культ минимума любой ценой.

Автоматизация ревизии: раз в неделю cron снимает nft list ruleset -a и filter print stats на git (без секретов). Diff без заявки = находка. Скрипт не удаляет правила. Человек смотрит orphan. Для RouterOS export без show-sensitive в git, binary backup — в сейф. Если live и git разъехались больше чем на N строк — тикет «конфиг вне SCM» приоритетнее косметического delete нулевых allow.

Не удаляйте established/related и финальный drop all как «мёртвые»: у них другая роль. Мёртвые — нулевые узкие allow и дубли. Комментарий expires= просрочен — disable в том же спринте, что ревизия, не «в следующем году».

Если не помогло

  • После чистки отвалился «забытый» интегратор — верните узкий allow, не весь dump.
  • Кластер FW, ревизия одного узла.
  • IPv6 таблица не смотрели.
  • NAT скрывал, filter казался мёртвым.
  • Политика «не трогать» без владельца — эскалация, не вечный keep.

Профилактика

  • Шаблон comment: owner=; ticket=; expires=.
  • Запрет add без тикета.
  • CI grep any-any.
  • Quarterly review как изменение с CAB если нужно.
  • Учебный restore backup на стенде.

FAQ

Сколько правил «нормально»?

Сколько потоков в матрице плюс established, drop all, служебные. 400 без владельца — нет. 40 с документацией — да.

Ревизия без простоя?

Да: read-only съём, disable не delete, тесты. Простой не обязателен.

Кто владелец default drop?

Команда периметра. Allow — бизнес-владелец сервиса.

Можно ли доверить вендору «оптимизатор правил»?

Только если понимаете diff. Не авто-merge в прод.

MikroTik FastTrack учитывать?

Да, иначе counters нижних врут. В отчёте отметьте, какие потоки fasttrack.