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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

IDPS

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

Если поставщиков удостоверений настроен в режиме предупреждения и запрета , ПОДсистема поставщиков удостоверений встроена и активируется после обработчика обработки правил. Таким образом, оба ядра создают предупреждения и могут блокировать соответствующие потоки. 

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

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

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

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

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

Если нет совпадения с ни с каким правилом сети и используется протокол HTTP, HTTPS или MSSQL, то такой пакет оценивается правилами приложения в порядке приоритета.

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

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

Примечание

Протоколы HTTP и HTTPS (с проверкой TLS) всегда заполняются брандмауэром Azure с КСФФ (X-Forwardd-for) заголовком, равным исходному исходному IP-адресу. 

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

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

Примечание

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

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

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

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

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

Примеры

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

Пример 1

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

Правило сети

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

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

  • Действие: Deny
name Тип исходного значения Источник Протокол:порт Целевые FQDN
Deny-google IP-адрес * http:80,https:443 google.com

Результат

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

Пример 2

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

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

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

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

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

Результат

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

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

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

поведение 3-стороннего подтверждения связи

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

Создание правила разрешения из VNet-A в VNet-B не означает, что новые инициированные подключения из VNet-B в VNet-A разрешены.

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

Дальнейшие действия