Настройка правил Брандмауэра Azure

  • Статья

Вы можете настроить правила NAT, правила сети и правила приложений в Брандмауэре Azure, используя классическую версию правил или политику брандмауэра. По умолчанию Брандмауэр Azure запрещает весь трафик, если вручную не определены разрешающие правила.

Обработка классической версии правил

Коллекции правил обрабатываются в соответствии с типом правила в порядке приоритета, от меньших значений к большим — от 100 до 65 000. Имя коллекции правил может содержать только буквы, цифры, символы подчеркивания, точки или дефисы. Имя должно начинаться с буквы или цифры и заканчиваться буквой, цифрой или символом подчеркивания. Максимальная длина имени составляет 80 символов.

Мы рекомендуем сначала использовать для коллекций правил номера приоритетов с шагом 100 (100, 200, 300 и т. д.), чтобы при необходимости между ними можно было добавить дополнительные коллекции правил.

Обработка правил с помощью политики брандмауэра

При использовании политики брандмауэра правила распределяются по коллекциям правил и группам коллекций правил. Группы коллекций правил могут содержать ноль или более коллекций правил. Типы коллекций правил: NAT, Network (сеть) и Applications (приложения). Вы можете определить в одной группе правил коллекции правил разных типов. Каждая коллекция правил содержит ноль или более правил. В одной коллекции все правила должны иметь одинаковый тип (NAT, Network или Application).

Правила обрабатываются в порядке приоритета групп коллекций правил и коллекций правил. Приоритет задается любым числом в диапазоне от 100 (наивысший приоритет) до 65 000 (самый низкий приоритет). Группы коллекций правил с наивысшим приоритетом обрабатываются первыми. В пределах группы коллекций правил первыми обрабатываются коллекции правил с наивысшим приоритетом (с наименьшим значением).

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

Примечание.

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

Ниже приведен пример такой политики.

Предполагая, что BaseRCG1 является приоритетом группы коллекций правил (200), которая содержит коллекции правил: DNATRC1, DNATRC3,NetworkRC1.
BaseRCG2 — это приоритет группы коллекций правил (300), содержащий коллекции правил: AppRC2, NetworkRC2.
ChildRCG1 — это приоритет группы коллекций правил (200), содержащий коллекции правил: ChNetRC1, ChAppRC1.
ChildRCG2 — это группа коллекций правил, содержащая коллекции правил: ChNetRC2, ChAppRC2,ChDNATRC3.

Как показано в следующей таблице:

Имя. Тип Приоритет Правила Унаследовано от
BaseRCG1 Группа коллекции правил 200 8 Родительская политика
DNATRC1 Коллекция правил DNAT 600 7 Родительская политика
DNATRC3 Коллекция правил DNAT 610 3 Родительская политика
NetworkRC1 Коллекция правил сети 800 1 Родительская политика
BaseRCG2 Группа коллекции правил 300 3 Родительская политика
AppRC2 Коллекция правил приложения 1200 2 Родительская политика
NetworkRC2 Коллекция правил сети 1300 1 Родительская политика
ChildRCG1 Группа коллекции правил 300 5 -
ChNetRC1 Коллекция правил сети 700 3 -
ChAppRC1 Коллекция правил приложения 900 2 -
ChildRCG2 Группа коллекции правил 650 9 -
ChNetRC2 Коллекция правил сети 1 100 2 -
ChAppRC2 Коллекция правил приложения 2000 7 -
ChDNATRC3 Коллекция правил DNAT 3000 2 -

Начальная обработка:

Процесс начинается с изучения группы коллекций правил (RCG) с наименьшим числом, которое является BaseRCG1 с приоритетом 200. В этой группе выполняется поиск коллекций правил DNAT и их оценка в соответствии с приоритетами. В этом случае DNATRC1 (приоритет 600) и DNATRC3 (приоритет 610) находятся и обрабатываются соответствующим образом.
Затем он переходит к следующему RCG, BaseRCG2 (приоритет 200), но не находит коллекции правил DNAT.
После этого он переходит к ChildRCG1 (приоритет 300), а также без коллекции правил DNAT.
Наконец, он проверка ChildRCG2 (приоритет 650) и находит коллекцию правил ChDNATRC3 (приоритет 3000).

Итерация в группах коллекций правил:

Возвращаясь к BaseRCG1, итерация продолжается, на этот раз для правил NETWORK. Найдено только NetworkRC1 (приоритет 800).
Затем он перемещается в BaseRCG2, где находится NetworkRC2 (приоритет 1300).
Переход к ChildRCG1 обнаруживает ChNetRC1 (приоритет 700) в качестве правила NETWORK.
Наконец, в ChildRCG2 он находит ChNetRC2 (приоритет 1100) в качестве коллекции правил NETWORK.

Окончательная итерация правил ПРИЛОЖЕНИЯ:

Возвращаясь к BaseRCG1, процесс выполняет итерацию правил ПРИЛОЖЕНИЯ, но не найдено.
В BaseRCG2 он определяет AppRC2 (приоритет 1200) в качестве правила ПРИЛОЖЕНИЯ.
В ChildRCG1 chAppRC1 (приоритет 900) находится в качестве правила ПРИЛОЖЕНИЯ.
Наконец, в ChildRCG2 он находит ChAppRC2 (приоритет 2000) в качестве правила ПРИЛОЖЕНИЯ.

В итоге последовательность обработки правил выглядит следующим образом: DNATRC1, DNATRC3, ChDNATRC3, NetworkRC1, NetworkRC2, ChNetRC1, ChNetRC2, AppRC2, ChAppRC1, ChAppRC2, ChAppRC2.

Этот процесс включает в себя анализ групп коллекций правил по приоритету и в каждой группе, упорядочивание правил в соответствии с их приоритетами для каждого типа правила (DNAT, NETWORK и APPLICATION).

Поэтому сначала все правила DNAT обрабатываются из всех групп коллекций правил, анализируя группы коллекций правил по порядку приоритета и упорядочив правила DNAT в каждой группе коллекций правил по порядку приоритета. Затем тот же процесс для правил NETWORK и, наконец, для правил APPLICATION.

Дополнительные сведения см. в статье Наборы правил Политики брандмауэра Azure.

Аналитика угроз

Если включена фильтрация на основе аналитики угроз, эти правила имеют наивысший приоритет и всегда обрабатываются первыми (раньше правил сети и приложений). Фильтрация на основе аналитики угроз может отклонять трафик до того, как его обработают настроенные правила. Дополнительные сведения см. в статье Фильтрация на основе аналитики угроз в Брандмауэре Azure.

IDPS

Если для IDPS настроен режим Оповещение, подсистема IDPS выполняется параллельно с логикой обработки правил и создает оповещения по совпадающим сигнатурам для потоков входящего и исходящего трафика. Оповещение по совпадающей сигнатуре IDPS сохраняется в журналах брандмауэра. Однако так как подсистема IDPS работает параллельно с обработчиком обработки правил, трафик запрещен или разрешен правилами приложения или сети может по-прежнему создавать другую запись журнала.

Если для IDPS настроен режим Оповещение и запрет, подсистема IDPS обрабатывает трафик в конвейере, после подсистемы обработки правил. Это означает, что обе эти подсистемы создают свои оповещения и могут блокировать потоки по соответствиям правил. 

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

Если включена проверка TLS, проверяется и зашифрованный, и незашифрованный трафик. 

Исходящее соединение

Правила сети и правила приложений

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

Затем правила приложения оценивают пакет в порядке приоритета, если не совпадает сетевое правило, и если протокол HTTP, HTTPS или MSSQL.

Для протокола HTTP Брандмауэр Azure ищет подходящее правило приложения по заголовку Host. Для протокола HTTPS Брандмауэр Azure ищет подходящее правило приложения только по указанию имени сервера (SNI).

В обоих случаях (для протокола HTTP и HTTP при включенной проверке TLS) брандмауэр игнорирует целевой IP-адрес в пакете и использует IP-адрес, разрешенный через DNS по значению заголовка Host. Брандмауэр ожидает получить в заголовке Host номер порта, а при его отсутствии предполагает стандартный порт 80. Если указанный в заголовке Host порт не совпадает с реальным TCP-портом, такой трафик отбрасывается. Разрешение DNS выполняется через Azure DNS или пользовательский DNS-сервер, если он настроен для брандмауэра. 

Примечание.

Пакеты протоколов HTTP и HTTPS (при включенной проверке TLS) Брандмауэр Azure всегда дополняет заголовком XFF (X-Forwarded-For) с указанием исходного IP-адреса источника. 

Если правило приложения использует проверку TLS, подсистема правил брандмауэра проверяет на соответствие правилу указание имени сервера (SNI), заголовок Host и URL-адрес.

Если совпадение с правилами приложения не будет найдено, пакет обрабатывается с использованием коллекции правил инфраструктуры. Если совпадение не обнаружено и в этом случае, пакет по умолчанию отклоняется.

Примечание.

Правила сети можно определить для протоколов TCP,UDP,ICMP или Any (любой). Вариант "Любой протокол IP" включает все протоколы IP, которые определены в документе IANA о номерах протоколов. Если целевой порт настроен явным образом, такое правило преобразуется в правило TCP+UDP. До 9 ноября 2020 года вариант Any (любой) обозначал только TCP, UDP и ICMP. Соответственно, до этой даты можно было определить правило Protocol = Any и destination ports = '*'. Если вы не намерены разрешать любой протокол IP в соответствии с текущим определением этого варианта, измените такие правила с явным указанием нужного протокола (TCP, UDP или ICMP).

Входящее соединение

Правила DNAT и правила сети

Входящий интернет-подключение можно включить, настроив преобразование сетевых адресов назначения (DNAT), как описано в разделе "Фильтрация входящего трафика с Брандмауэр Azure DNAT" с помощью портал Azure. Правила NAT имеют приоритет над правилами сети. Если совпадение найдено, трафик преобразуется в соответствии с правилом DNAT и разрешен брандмауэром. Поэтому трафик не подлежит дальнейшей обработке другими правилами сети. По соображениям безопасности рекомендуется следующий подход: добавьте определенный источник в Интернете, чтобы разрешить доступ DNAT к сети и избежать использования подстановочных знаков.

Правила приложения не применяются к входящим подключениям. Поэтому, если требуется фильтровать входящий трафик HTTP или HTTPS, следует использовать брандмауэр веб-приложения (WAF). Дополнительные сведения см. в статье Что такое брандмауэр веб-приложения Azure?

Примеры

В следующих примерах показаны результаты обработки некоторых сочетаний правил.

Пример 1

Подключение к google.com разрешено, так как обнаружено совпадающее правило сети.

Правило сети

  • Действие: Разрешить
name Протокол Source type Оригинал Тип назначения Адрес назначения Конечные порты
Разрешить — Интернет TCP IP-адрес * IP-адрес * 80, 443

Правило приложения

  • Действие: Запретить
name Source type Оригинал Протокол:порт Целевые FQDN
Deny-google IP-адрес * http:80,https:443 google.com

Результат

Подключение к google.com разрешено, так как пакет соответствует правилу сети Allow-web. На этом этапе обработка правил останавливается.

Пример 2

Трафик SSH отклоняется, потому что его блокирует коллекция запрещающих правил сети с более высоким приоритетом.

Коллекция правил сети 1

  • Имя: Allow-collection
  • Приоритет: 200
  • Действие: Разрешить
name Протокол Source type Оригинал Тип назначения Адрес назначения Конечные порты
Разрешить — SSH TCP IP-адрес * IP-адрес * 22

Коллекция правил сети 2

  • Имя: Deny-Collection
  • Приоритет: 100
  • Действие: Запретить
name Протокол Source type Оригинал Тип назначения Адрес назначения Конечные порты
Запретить — SSH TCP IP-адрес * IP-адрес * 22

Результат

Подключения SSH отклоняются, потому что их блокирует коллекция правил сети с более высоким приоритетом. На этом этапе обработка правил останавливается.

Изменения правил

Если вы измените правило так, что ранее разрешенный трафик будет запрещен, все действующие сеансы, соответствующие этому правилу, будут отброшены.

Трехстороннее подтверждение связи

Брандмауэр Azure является службой с отслеживанием состояния, поэтому он завершает трехстороннее подтверждение связи для разрешенного трафика от источника к назначению. Для примера предположим, что трафик направляется из VNet-A в VNet-B.

Создание правила, разрешающего трафик из VNet-A в VNet-B не приводит к разрешению новых подключений из VNet-B в VNet-A.

Это избавляет от необходимости создавать явное правило запрета для трафика из VNet-B в VNet-A. При создании этого правила запрета вы прерываете трехстороннее подтверждение с начального правила разрешения из виртуальной сети-A в виртуальную сеть B.

Следующие шаги