Поделиться через

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

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

Обработка правил с помощью классических правил

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

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

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

С помощью политики брандмауэра правила упорядочиваются в коллекциях правил и группах коллекций правил. Группы коллекций правил содержат ноль или более коллекций правил. Коллекции правил бывают типа NAT, сети или приложений. Можно определить несколько типов коллекций правил в одной группе правил. Вы можете определить ноль или больше правил в коллекции правил. Правила в коллекции правил должны иметь одинаковый тип (NAT, сеть или приложение).

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

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

Примечание.

Система всегда обрабатывает правила приложений после сетевых правил и сетевые правила после DNAT-правил независимо от группы коллекции правил, приоритета коллекции или наследования политик.

Подведение итогов.

  1. Родительская политика всегда имеет приоритет над дочерней политикой.
  2. Система обрабатывает группы коллекций правил в порядке приоритета.
  3. Система обрабатывает коллекции правил в порядке приоритетов.
  4. Система обрабатывает правила DNAT, а затем сетевые правила, а затем правила приложения.

Ниже приведен пример политики с четырьмя группами коллекций правил. BaseRCG1 и BaseRCG2 наследуются от родительской политики; ChildRCG1 и ChildRCG2 принадлежат к дочерней политике.

Подсказка

Сокращенные значения, используемые в следующих таблицах: RCG = группа коллекций правил, RC = коллекция правил. Номера приоритета варьируются от 100 (наивысший приоритет) до 65 000 (самый низкий приоритет).

Структура политики:

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

Брандмауэр выполняет итерацию по всем группам коллекций правил три раза — один раз за тип правила: DNAT, а затем сеть, а затем приложение. В каждом проходе он обрабатывает группы в порядке приоритета, а затем коллекции правил в каждой группе в порядке приоритета. В следующей таблице показана полная последовательность обработки для этого примера:

Порядок обработки

Step Коллекция правил Тип Родительский RCG
1 DNATRC1 DNAT BaseRCG1 (200)
2 DNATRC3 DNAT BaseRCG1 (200)
3 ChDNATRC3 DNAT ChildRCG2 (650)
4 NetworkRC1 Сеть BaseRCG1 (200)
5 NetworkRC2 Сеть BaseRCG2 (300)
6 ChNetRC1 Сеть ChildRCG1 (300)
7 ChNetRC2 Сеть ChildRCG2 (650)
8 AppRC2 Application BaseRCG2 (300)
9 ChAppRC1 Application ChildRCG1 (300)
10 ChAppRC2 Application ChildRCG2 (650)

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

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

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

Система обнаружения и предотвращения вторжений (IDPS)

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

При настройке IDPS в режиме оповещения и запрещения движок IDPS работает в режиме "inline" и активируется после обработки правил. Поэтому оба модуля создают оповещения и могут блокировать соответствующие потоки.

Удаление сеанса, которое выполняется системой обнаружения и предотвращения вторжений (IDPS), блокирует поток без уведомления. Это означает, что на уровне TCP не отправляется пакет RST. Поскольку система обнаружения и предотвращения вторжений (IDPS) всегда проверяет трафик после сопоставления правила сети или приложения (разрешить или запретить) и помечается в журналах, может быть зарегистрировано другое сообщение Drop, когда IDPS решает запретить сеанс из-за совпадения сигнатуры.

При включении проверки TLS брандмауэр Azure проверяет как незашифрованный, так и зашифрованный трафик.

Поддержка неявного возвращаемого трафика (TCP/UDP с отслеживанием состояния)

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

Брандмауэр Azure поддерживает эту конфигурацию. Брандмауэр Azure является с отслеживанием состояния, поэтому он позволяет возвращать трафик для установленного TCP-подключения или UDP (например, пакеты SYN-ACK/ACK для подключения, инициированного из локальной среды), даже если существует явное правило запрета в противоположном направлении. Явное правило запрета продолжает блокировать новые подключения, инициируемые из виртуальной сети Azure в локальную среду.

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

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

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

Правила приложения анализируют пакет в порядке приоритета, если сетевое правило не соответствует и если протокол HTTP, HTTPS или MSSQL.

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

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

Примечание.

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

Если правило приложения содержит проверку TLS, обработчик правил брандмауэра обрабатывает SNI, заголовок узла, а также URL-адрес, соответствующий правилу.

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

Коллекция правил инфраструктуры

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

Встроенная коллекция правил инфраструктуры включает следующие службы:

  • Доступ к вычислительной мощности к репозиторию образов платформы (PIR)
  • Доступ к хранилищу состояния управляемых дисков
  • Диагностика и журналирование Azure (MDS)

Переопределение коллекции правил инфраструктуры

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

Примечание.

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

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

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

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

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

Примеры

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

Пример 1

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

Сетевое правило — действие: разрешить

Имя. Протокол Тип источника Источник Тип назначения Адрес назначения Конечные порты
Разрешить — Интернет Протокол tcp IP-адрес * IP-адрес * 80, 443

Правило приложения — действие: запретить

Имя. Тип источника Источник Протокол:порт Целевые полные доменные имена (FQDN)
Отклонить Google IP-адрес * http:80,https:443 google.com

Результат

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

Пример 2

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

Коллекция правил сети 1 — Имя: Allow-collection, Priority: 200, Action: Allow

Имя. Протокол Тип источника Источник Тип назначения Адрес назначения Конечные порты
Разрешить SSH Протокол tcp IP-адрес * IP-адрес * двадцать два

Коллекция правил сети 2 — Имя: Deny-collection, Приоритет: 100, Действие: Отказать

Имя. Протокол Тип источника Источник Тип назначения Адрес назначения Конечные порты
Запретить SSH Протокол tcp IP-адрес * IP-адрес * двадцать два

Результат

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

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

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

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

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

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

В результате вам не нужно создавать явное правило запрета из VNet-B в VNet-A.

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

  • Last updated on