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

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

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

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

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

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

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

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

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

Итак, чтобы сводные данные:

Родительская политика всегда имеет приоритет.

1. Группы коллекций правил обрабатываются в порядке приоритета.
2. Коллекции правил обрабатываются в порядке приоритета.
3. Правила DNAT, а затем сетевые правила, а затем правила приложения обрабатываются.

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

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

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

Начальная итерация правил DNAT:

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

Итерация правил NETWORK:

Возвращаясь к 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-сервер, если он настроен для брандмауэра. 

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

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

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

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

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

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

Примеры

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

Пример 1

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

Правило сети

• Действие: Разрешить

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

• Действие: Запретить

Результат

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

Пример 2

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

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

• Имя: Allow-collection
• Приоритет: 200
• Действие: Разрешить

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

• Имя: Deny-Collection
• Приоритет: 100
• Действие: Запретить

Результат

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

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

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

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

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

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

Это избавляет от необходимости создавать явное правило запрета для трафика из VNet-B в VNet-A.

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

• Дополнительные сведения о поведении Брандмауэр Azure NAT
• Узнайте, как развернуть и настроить Брандмауэр Azure
• Дополнительные сведения о безопасности сети Azure