Firewall / Практика

Shadow Rules в правилах межсетевого экрана: как находить, доказывать и устранять (Set Logic + практика)

Shadow rule — это правило, которое никогда не срабатывает, потому что выше в политике уже стоит более широкое правило, перехватывающее весь его трафик. На бумаге оно «есть», в реальности — не участвует в обработке пакетов. В этой статье разберёмся, почему так происходит, чем это опасно, как это формально доказать и как чинить без сюрпризов в проде.

Инструмент для практики: «Разбиение правила Firewall»

Если у тебя часто бывают задачи «убрать один порт / один хост из огромного правила» или «аккуратно сделать исключение» — попробуй утилиту для безопасного разбиения правил: она помогает мыслить правилами как множествами и избегать поломок доступа.

Открыть инструмент

Совет: сохраняй результат как артефакт к change ticket: «что было», «что стало» и какие потоки сохранены.

Содержание

1) Определение: что такое shadow rule

Shadow rule (иногда говорят unreachable rule) — это правило политики МСЭ, которое не может быть достигнуто при обработке трафика, потому что одно или несколько правил выше полностью покрывают (являются супермножеством) всех пакетов, которые могли бы его удовлетворить.

В большинстве межсетевых экранов используется логика first-match: пакет проверяется сверху вниз, и при первом совпадении применяется действие (permit/deny), а дальнейшая проверка прекращается. Поэтому «широкое permit сверху» может полностью «убить» более узкий deny ниже.

Ключевая мысль

Shadow rule — это не «мало трафика» и не «ноль хитов». Это статическое свойство конфигурации: правило недостижимо из-за структуры и порядка правил.

2) Чем это реально опасно

Shadow rules опасны не тем, что «занимают место», а тем, что создают разрыв между намерением (intent) и реальным enforcement. В результате политика выглядит безопаснее, чем она есть на самом деле.

2.1. Провал enforcement

Самый неприятный кейс: правило deny (или restriction) не работает, потому что выше стоит разрешающее правило-«ковёр». Команда уверена, что доступ закрыт, а на деле он открыт.

2.2. Аудит и комплаенс

Для проверок (PCI DSS, ISO 27001, внутренние аудиты) важно, чтобы применяемая политика соответствовала матрице доступов. Shadow rules дают «бумажные запреты», которые не исполняются. Аудитор может легко поймать это тестовым подключением.

2.3. Рост сложности и MTTR

В инцидентах инженеры проходят правило за правилом, пытаясь понять почему «не блокируется» или «не работает доступ». Shadow rules — это шум, который увеличивает Mean Time To Resolution. Плюс любой change становится страшнее: никто не уверен, что реально применяется.

3) Математика: множества и супермножества

Удобный способ мыслить правилами МСЭ — как множествами потоков. У каждого правила есть набор источников S, набор назначений D и набор сервисов/портов P. На практике правило задаёт декартово произведение: 

Rule = S × D × P

Это означает: разрешены/запрещены все комбинации «источник → назначение → сервис», которые попали в эти множества. Shadowing возникает, когда правило выше — это супермножество для правила ниже: 

(S_A × D_A × P_A) ⊇ (S_B × D_B × P_B)

Если так и при этом правило A находится выше правила B, то правило B никогда не будет достигнуто.

Почему «Any» делает всё хуже

Любой Any резко расширяет множество: P=Any почти всегда «накрывает» конкретные порты ниже, S=Any накрывает подсети и хосты, D=Any накрывает конкретные серверы. Это главная причина shadow rules.

4) Пример: permit сверху — deny снизу

Фрагмент политики:

Rule 10: PERMIT
  Source:      10.0.0.0/24
  Destination: 172.16.1.10
  Service:     TCP/80 (HTTP)

Rule 20: DENY
  Source:      10.0.0.5
  Destination: 172.16.1.10
  Service:     TCP/80 (HTTP)

Пакет от 10.0.0.5 к 172.16.1.10:80 сначала проверяется по Rule 10: источник попадает в 10.0.0.0/24, назначения и сервис совпадают → срабатывает permit, обработка остановлена. Rule 20 вообще не будет рассмотрено.

Формально: множество Rule 10 включает в себя поток Rule 20, то есть Rule 20 — shadowed. Это не «ошибка логов», а строгая логика first-match.

5) Виды shadowing

5.1. Полный shadow

Верхнее правило полностью покрывает нижнее по всем измерениям (S, D и P). Нижнее не может обработать ни одного пакета.

5.2. Частичный shadow

Верхнее правило покрывает лишь часть трафика нижнего. Тогда нижнее правило «живёт», но только для оставшейся части. Частичный shadow — коварнее: на глаз кажется, что правило работает, но оно работает не так, как ожидают.

5.3. Shadow по сервисам (service shadow)

Частый случай: сверху стоит Service: Any или «широкая группа портов», а снизу — конкретный порт. При совпадающих источниках/назначениях нижнее правило становится недостижимым.

5.4. Shadow по зонам

В NGFW часто есть зоны/интерфейсы. Более широкий allow по зонам (например Untrust→DMZ) легко «съедает» частные исключения ниже.

6) Как находить shadow rules: чек-лист

6.1. Главный метод — анализ супермножеств

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

6.2. Hit count — симптом, но не доказательство

Ноль хитов за 30–90 дней может означать shadowing, а может означать: «редкий сценарий», «резервный маршрут», «разовый доступ», «сезонная система». Поэтому hit count нельзя считать строгим признаком.

6.3. Симуляция политики

Если платформа/вендор поддерживает policy simulation / packet-tracer / traffic simulation — используй её. Она быстро показывает недостижимые правила и перекрытия.

Мини-чеклист
  • Проверить порядок: исключения должны стоять выше «ковровых» allow.
  • Проверить Any/группы: не «накрывают» ли они точные правила ниже.
  • Смотреть не только IP, но и зоны, приложения, user/group, расписания.
  • Нат/пре-нат: анализировать в правильной фазе политики.

7) Как устранять: стратегии и порядок действий

7.1. Перестановка правил (specific before general)

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

7.2. Сузить верхнее правило

Если верхнее правило слишком широкое «по историческим причинам», ограничь его: убери лишние подсети/хосты, раздели сервисы, уточни назначения. Часто это лучший вариант, если политика разрослась.

7.3. Разбить верхнее правило на несколько

Когда одно правило одновременно обслуживает разные команды/сервисы, оно неизбежно становится «ковром». Разбиение на несколько более точных правил уменьшает риск shadowing и будущих поломок.

7.4. Удалить нижнее правило (если intent больше не нужен)

Иногда shadow rule — это просто «мусор» (deprecated система, устаревшее исключение, забытый deny). Если бизнес-смысл исчез — безопаснее удалить, чем держать «бумажный контроль».

Когда нужно «разбиение правила»

Если задача звучит как «нужно убрать один порт/одного получателя/одного источника из большого allow» — это почти всегда задача разбиения, а не «удалить порт из группы». В таких случаях удобно использовать инструмент:

Разбиение правила Firewall

Практика: сначала фиксируй точный «удаляемый поток» (S×D×P), потом делай изменения так, чтобы не создать новые разрешения и не сломать старые.

8) Важные нюансы: NAT, логи, процессы

8.1. NAT и фазы обработки

Shadow-анализ нужно делать в правильной точке пайплайна (pre-NAT vs post-NAT), иначе можно ошибочно считать правило недостижимым/достижимым. Особенно это важно, когда NAT применяется в политике или в отдельном разделе NAT-правил.

8.2. «Тишина в логах» — не всегда хорошо

Shadowed deny может иметь включённое логирование, но логов не будет. Инженер думает: «трафика нет» — а на самом деле он разрешён верхним permit и просто проходит без события deny.

8.3. Change management

Если ты доказываешь shadowing через set-анализ, приложи это к тикету. Тогда правка/удаление shadow rule становится «нулевым риском» и проходит согласование быстрее.

9) FAQ

Нулевые хиты = shadow rule?

Нет. Нулевые хиты — сигнал, но не доказательство. Shadowing подтверждается только анализом супермножеств/симуляцией.

Могут ли deny правила быть shadowed?

Да. Deny ниже permit — классический сценарий. Но бывает и наоборот: deny сверху может «убить» permit ниже.

Shadow rules влияют на производительность?

На dataplane обычно минимально, но на управляемость — сильно: больше правил = сложнее ревью, дольше коммиты, больше ошибок.

Как часто делать проверку на shadow rules?

Минимум — при каждом крупном изменении и при плановых ревью (раз в квартал/полгода). Идеально — автоматизировать как «quality gate».

10) Вывод

Shadow rules — это закономерный эффект first-match логики, когда политика растёт без строгой структуры. Они опасны тем, что создают «ложную безопасность»: правило есть, но оно не исполняется.

Правильный подход — мыслить правилами как множествами потоков (S×D×P), проверять супермножества и устранять перекрытия через порядок (specific before general), сужение правил и разбиение «ковровых» allow на более точные.

Если твоя типовая задача — «вырезать один порт/хост из большого правила», то вместо опасного ручного редактирования используй: Разбиение правила Firewall.