вопросы и ответы о Azure Firewall

Общая информация

Что такое Azure Firewall?

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

Какие возможности поддерживаются Azure Firewall?

Подробный список функций Azure Firewall см. в разделе Azure Firewall функции.

Что такое типичная модель развертывания для Azure Firewall?

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

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

Как развернуть Azure Firewall?

Azure Firewall можно развернуть с помощью портала Azure, PowerShell, REST API или шаблонов. Пошаговые инструкции см. в разделе Tutorial: развертывание и настройка Azure Firewall с помощью портала Azure.

Каковы некоторые ключевые понятия Azure Firewall?

Azure Firewall использует правила и коллекции правил. Коллекция правил — это набор правил с одинаковым порядком и приоритетом. Коллекции правил выполняются в порядке приоритета. Коллекции правил DNAT имеют более высокий приоритет, чем коллекции правил сети, которые, в свою очередь, имеют более высокий приоритет, чем коллекции правил приложений. Все правила завершаются.

Есть три типа коллекций правил:

• Правила приложения: настройте полные доменные имена (FQDN), к которым можно получить доступ из виртуальной сети.
• Сетевые правила: настройте правила с исходными адресами, протоколами, портами назначения и адресами назначения.
• Правила NAT: настройте правила DNAT для разрешения входящих подключений к Интернету или интрасети (предварительная версия).

Дополнительные сведения см. в разделе Configure Azure Firewall rules.

Какие службы ведения журнала и аналитики поддерживают Azure Firewall?

Azure Firewall интегрируется с Azure Monitor для просмотра и анализа журналов. Журналы можно отправлять в Log Analytics, Azure Storage или Центры событий и анализировать с помощью таких средств, как Log Analytics, Excel или Power BI. Дополнительные сведения см. в разделе Tutorial: Мониторинг журналов Azure Firewall.

Как Azure Firewall отличается от сетевых виртуальных устройств (NVAs) в Azure Marketplace?

Azure Firewall — это управляемая облачная служба безопасности сети, которая защищает ресурсы виртуальной сети. Брандмауэр разработан как служба с полным отслеживанием состояния со встроенной высокой доступностью и неограниченной облачной масштабируемостью. Она предварительно интегрирована с поставщиками безопасности как услуги (SECaaS), чтобы повысить безопасность виртуальных сетей и соединений с Интернетом филиалов. Дополнительные сведения см. в разделе Безопасность сети Azure.

Какова разница между WAF шлюза приложений и Azure Firewall?

WAF шлюза приложений обеспечивает централизованную защиту входящего трафика для веб-приложений от распространенных эксплойтов и уязвимостей. Azure Firewall обеспечивает входящие защиты для протоколов, отличных от HTTP/S (например, RDP, SSH, FTP), защиты исходящего сетевого уровня для всех портов и протоколов, а также защиты уровня приложения для исходящего ТРАФИКА HTTP/S.

В чем разница между группами безопасности сети (NSG) и Azure Firewall?

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

Поддерживаются ли группы безопасности сети в AzureFirewallSubnet?

Azure Firewall — это управляемая служба с несколькими уровнями защиты, включая защиту платформы с NSG на уровне сетевого адаптера (недоступно для просмотра). Группы безопасности сети на уровне подсети не требуются в AzureFirewallSubnet и отключены для предотвращения прерываний работы служб.

Что такое добавленное значение Azure Firewall с частными конечными точками?

Частные конечные точки — это компонент Private Link, технология, которая позволяет взаимодействовать со службами PaaS Azure с помощью частных IP-адресов вместо общедоступных. Azure Firewall можно использовать для предотвращения доступа к общедоступным IP-адресам, что позволяет предотвратить кражу данных в Azure службах, не использующих Private Link, а также для реализации политик нулевого доверия, определяя, кто в вашей организации должен иметь доступ к этим Azure PaaS службам, поскольку Private Link по умолчанию открывает сетевой доступ для всей корпоративной сети.

Правильный дизайн для проверки трафика к частным конечным точкам с Azure Firewall зависит от сетевой архитектуры, см. дополнительные сведения в статьях Azure Firewall сценарии проверки трафика, предназначенного для частной конечной точки.

Какова дополнительная ценность Azure Firewall с точками подключения виртуальной сети?

Конечные точки службы виртуальной сети являются альтернативой Private Link для управления доступом в сеть служб PaaS Azure. Даже если клиент по-прежнему использует общедоступные IP-адреса для доступа к службе PaaS, исходная подсеть становится видимой, чтобы целевая служба PaaS могли реализовать правила фильтрации и ограничить доступ на основе каждой подсети. Подробное сравнение обоих механизмов можно найти в разделе "Сравнение частных конечных точек" и "Конечные точки службы".

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

Какова стоимость для Azure Firewall?

Сведения о ценах см. в разделе Ценообразование Azure Firewall.

Каковы известные ограничения служб для Azure Firewall?

Ограничения см. в разделе лимиты подписки и службы Azure, квоты и ограничения.

Где Azure Firewall хранит данные клиента?

Azure Firewall не перемещает или не хранит данные клиента за пределами региона, в котором он развернут.

Поддерживается ли Azure Firewall в защищенных виртуальных центрах (vWAN) в Катаре?

Нет, Azure Firewall в защищенных виртуальных центрах (vWAN) в настоящее время не поддерживается в Катаре.

Поддерживаемые возможности и функции

Поддерживает ли Azure Firewall фильтрацию входящего трафика?

Да, Azure Firewall поддерживает фильтрацию входящего и исходящего трафика. Входящий фильтр обычно используется для протоколов, отличных от HTTP, таких как RDP, SSH и FTP. Для входящего трафика HTTP и HTTPS рекомендуется использовать брандмауэр веб-приложения, например Azure Web Application Firewall (WAF) или разгрузку TLS и функции глубокой проверки пакетов Azure Firewall Premium.

Поддерживает ли Azure Firewall Basic принудительное туннелирование?

Да, Azure Firewall Basic поддерживает принудительное туннелирование.

Почему TCP ping или аналогичная утилита кажется подключается к целевому полному доменному имени, даже если правило не разрешает этот трафик?

TCP ping фактически не подключается к целевому полному доменному имени. Azure Firewall блокирует подключения к любому целевому IP-адресу или полному доменному имени (FQDN), если это не разрешено одним из правил.

Если правило не разрешает трафик, брандмауэр сам реагирует на запрос TCP-ping клиента. Этот ответ не достигает целевого IP-адреса или полного доменного имени и не фиксируется в журнале. Если правило сети явно разрешает доступ к целевому IP-адресу или полному доменному имени (FQDN), ping-запрос достигает целевого сервера, и его ответ передается обратно клиенту. Это событие заносится в журнал сетевых правил.

Поддерживает ли Azure Firewall пиринг BGP?

Нет, Azure Firewall изначально не поддерживает пиринг BGP. Однако функция маршрутов SNAT Autolearn SNAT косвенно использует BGP через Azure Route Server.

Может ли Azure Firewall передавать пакеты ESP (VPN IPSec)?

Azure Firewall изначально не поддерживает ESP (инкапсулирование полезных данных безопасности), но можно разрешить трафик ESP, настроив сетевое правило следующим образом:

конфигурация Azure Firewall (сетевое правило):

• Протокол: Любой
• Исходный порт: * (любой)
• Порт назначения: * (любой)
• Источник или назначение: укажите IP-адреса по мере необходимости

Эта конфигурация позволяет пакетам ESP (IP-протоколу 50) и другому трафику, отличному от TCP/UDP, соответствовать правилу. Однако обратите внимание, что Azure Firewall не проверяет полезные данные ESP.

Reference: если используется NSG (группа безопасности сети) вместо Azure Firewall: NSG не предоставляет прямой параметр для указания ESP (номер IP-протокола 50), но пакеты ESP могут быть разрешены с помощью следующих параметров:

• Протокол: Любой
• Порт: * (любой)
• Источник или назначение: укажите IP-адреса по мере необходимости

Recommendations:

• Для конфигураций VPN IPsec рекомендуется использовать Azure VPN Gateway.
• Рекомендуется использовать шаблон NVA (сетевого виртуального устройства) в зависимости от ваших требований.

Управление и настройка

Как остановить и запустить Azure Firewall?

Вы можете использовать Azure PowerShell для отключения и выделения ресурсов брандмауэра Azure. Процесс зависит от конфигурации.

Для брандмауэра без сетевого адаптера управления:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet, @($publicip1, $publicip2))
Set-AzFirewall -AzureFirewall $azfw

Для брандмауэра с сетевым адаптером управления:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip)
Set-AzFirewall -AzureFirewall $azfw

Для брандмауэра в защищенном виртуальном концентраторе:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$virtualhub = Get-AzVirtualHub -ResourceGroupName "vHUB RG Name" -Name "vHUB Name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Firewall RG Name"
$azfw.Allocate($virtualhub.Id)
Set-AzFirewall -AzureFirewall $azfw

Примечание.

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

Как настроить зоны доступности после развертывания?

Рекомендуется настроить зоны доступности во время первоначального развертывания. Однако их можно перенастроить после развертывания, если:

• Брандмауэр развертывается в виртуальной сети (не поддерживается в защищенных виртуальных центрах).
• Регион поддерживает зоны доступности.
• Все присоединенные общедоступные IP-адреса сконфигурированы с одинаковыми зонами.

Чтобы перенастроить зоны доступности, выполните приведенные действия.

1. Освобождение брандмауэра:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $azfw.Deallocate()
   Set-AzFirewall -AzureFirewall $azfw
   

2. Обновите конфигурацию зоны и выделите брандмауэр:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
   $pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
   $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
   $azfw.Allocate($vnet, $pip, $mgmtPip)
   $azfw.Zones = 1, 2, 3
   Set-AzFirewall -AzureFirewall $azfw
   

Существуют ли ограничения группы ресурсов брандмауэра Azure?

Да:

• Azure Firewall и виртуальная сеть должны находиться в одной группе ресурсов.
• Общедоступный IP-адрес может находиться в другой группе ресурсов.
• Все ресурсы (Azure брандмауэр, виртуальная сеть, общедоступный IP-адрес) должны находиться в одной подписке.

Что означает состояние конфигурации **Failed**?

Состояние Failed указывает, что обновление конфигурации завершилось сбоем в одном или нескольких экземплярах серверной системы. Azure Firewall остается операционным, но конфигурация может быть несогласованной. Повторите обновление до тех пор, пока состояние подготовки не изменится на "Успешно".

Как Azure Firewall обрабатывает плановые работы и незапланированные сбои?

Azure Firewall использует конфигурацию active-active с несколькими внутренними узлами. Во время планового обслуживания очистка подключений обеспечивает корректное обновление. При незапланированных сбоях новый узел заменяет неудачный, а подключение обычно восстанавливается в течение 10 секунд.

Существует ли ограничение количества символов в имени брандмауэра?

Да, имена брандмауэра ограничены 50 символами.

Почему Azure Firewall требуется размер подсети /26?

Подсеть /26 обеспечивает достаточные IP-адреса для масштабирования, так как Azure Firewall подготавливает дополнительные экземпляры виртуальных машин.

Нужно ли менять размер подсети брандмауэра по мере масштабирования службы?

Нет, для всех сценариев масштабирования достаточно подсети /26.

Как я могу увеличить пропускную способность брандмауэра?

Azure Firewall автоматически масштабируется на основе использования ЦП, пропускной способности и количества подключений. Емкость пропускной способности от 2,5 до 3 Гбит/с изначально до 30 Гбит/с (номер SKU категории "Стандартный") или 100 Гбит/с (номер SKU уровня "Премиум").

Существуют ли ограничения на число IP-адресов, поддерживаемых группами IP-адресов?

Да. Дополнительные сведения см. в разделе Azure ограничения подписки и службы, квоты и ограничения.

Можно ли переместить IP-группу в другую группу ресурсов?

Нет, в настоящее время перемещение IP-группы в другую группу ресурсов не поддерживается.

Что такое время ожидания простоя TCP для Azure Firewall?

Стандартное поведение сетевого брандмауэра заключается в том, чтобы обеспечивать активность TCP-подключений и быстро закрывать их в случае простоя. Время ожидания бездействия TCP в Azure Firewall составляет четыре минуты. Этот параметр не настраивается пользователем, но вы можете обратиться в службу поддержки Azure, чтобы увеличить время ожидания простоя для входящих и исходящих подключений до 15 минут. Нельзя изменить время простоя для трафика восток-запад.

Если период бездействия превышает значение тайм-аута, нет гарантии, что сеанс TCP или HTTP сохранится. Распространенной практикой является использование функции keep-alive в TCP. Такой подход позволяет поддерживать подключения активными в течение более длительного периода. Дополнительные сведения см. в примерах .NET.

Можно ли развернуть Azure Firewall без общедоступного IP-адреса?

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

Существует ли способ автоматического резервного копирования Azure Firewall и политик?

Да. Дополнительные сведения см. в разделе Создание резервных копий Azure Firewall и политики Azure Firewall с помощью приложения Logic Apps.

Подключение и маршрутизация

Как настроить Azure Firewall с конечными точками службы?

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

Можно ли настроить Azure Firewall в виртуальной сети хаба для переадресации и фильтрации сетевого трафика между несколькими виртуальными сетями-спицами?

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

Может ли Azure Firewall пересылать и фильтровать сетевой трафик между подсетями в одной виртуальной сети или одноранговых виртуальных сетях?

Да. Однако настройка UDR для перенаправления трафика между подсетями в одной виртуальной сети требует большего внимания. Хотя использование диапазона адресов виртуальной сети в качестве целевого префикса для UDR достаточно, это также направляет весь трафик с одного компьютера на другой компьютер в той же подсети через экземпляр Azure Firewall. Чтобы избежать этого, включите маршрут для подсети в UDR с типом следующего прыжка виртуальной сети. Управление этими маршрутами может быть весьма трудоемким и подвержено ошибкам. Рекомендуется использовать группы безопасности сети для сегментации внутренней сети, так как для этого не требуются определяемые пользователем маршруты.

Осуществляет ли Azure Firewall исходящий SNAT между частными сетями?

Azure Firewall не выполняет SNAT, если целевой IP-адрес находится в частном диапазоне IP-адресов согласно IANA RFC 1918 или IANA RFC 6598 для частных сетей. Если ваша организация использует диапазон общедоступных IP-адресов для частных сетей, Azure Firewall осуществляет SNAT, перенаправляя трафик к одному из частных IP-адресов брандмауэра в AzureFirewallSubnet. Вы можете настроить Azure Firewall так, чтобы не выполнять SNAT для вашего диапазона общедоступных IP-адресов. Для получения дополнительной информации см. раздел диапазоны частных IP-адресов для SNAT в Azure Firewall.

Кроме того, для трафика, обрабатываемого правилами приложения, всегда будет использоваться SNAT. Если вы хотите увидеть исходный IP-адрес в журналах для трафика FQDN, можно использовать правила сети с полным доменным именем назначения.

Поддерживается ли принудительное туннелирование или связывание к сетевому виртуальному модулю?

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

Azure Firewall должен иметь прямое подключение к Интернету. Если сеть AzureFirewallSubnet узнает стандартный маршрут к вашей локальной сети через BGP, вы должны переопределить его, установив пользовательский маршрут 0.0.0.0/0 с параметром NextHopType и значением Интернет, чтобы обеспечить прямое подключение к Интернету.

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

Как работают подстановочные знаки в целевых URL-адресах и целевых полных доменных именах в правилах приложений?

• URL-адрес — звездочки работают при размещении на самой правой или самой левой стороне. Если находится слева, то это не может быть частью полного доменного имени (FQDN).
• Полностью квалифицированное доменное имя - звездочки работают, если они размещены на самой левой стороне.
• GENERAL - Звездочки на самой левой стороне означают буквально все, что слева совпадает, в результате совпадают несколько поддоменов и/или потенциально нежелательные варианты доменных имен. См. следующие примеры.

Примеры:

Тип	Правило	Поддерживается?	Положительные примеры
Целевой URL	www.contoso.com	Да	www.contoso.com www.contoso.com/
Целевой URL	*.contoso.com	Да	any.contoso.com/ sub1.any.contoso.com
Целевой URL	*contoso.com	Да	example.anycontoso.com sub1.example.contoso.com contoso.com Предупреждение: использование этого шаблона может привести к потенциально нежелательным или рискованным вариациям, таким как th3re4lcontoso.com. Используйте с осторожностью.
Целевой URL	www.contoso.com/test	Да	www.contoso.com/test www.contoso.com/test/ www.contoso.com/test?with_query=1
Целевой URL	www.contoso.com/test/*	Да	www.contoso.com/test/anything Примечание. www.contoso.com/testНе совпадает (последняя косая черта)
Целевой URL	www.contoso.*/test/*	нет
Целевой URL	www.contoso.com/test?example=1	нет
Целевой URL	www.contoso.*	нет
Целевой URL	www.*contoso.com	нет
Целевой URL	www.contoso.com:8080	нет
Целевой URL	*.contoso.*	нет
Целевое доменное имя	www.contoso.com	Да	www.contoso.com
Целевое доменное имя	*.contoso.com	Да	any.contoso.com Примечание: Если вы хотите намеренно разрешить contoso.com, следует включить contoso.com в правило. В противном случае подключение удаляется по умолчанию, так как запрос не соответствует ни одному правилу.
Целевое доменное имя	*contoso.com	Да	example.anycontoso.com contoso.com
Целевое доменное имя	www.contoso.*	нет
Целевое доменное имя	*.contoso.*	нет

Разрешает ли Azure Firewall доступ к Active Directory по умолчанию?

№ Azure Firewall блокирует доступ к Active Directory по умолчанию. Чтобы разрешить доступ, настройте тег службы AzureActiveDirectory. Для получения дополнительной информации см. теги службы Azure Firewall.

Можно ли исключить полное доменное имя (FQDN) или IP-адрес из фильтрации на основе анализа угроз в Azure Firewall?

Да, для этого можно использовать Azure PowerShell:

# Add a Threat Intelligence allowlist to an Existing Azure Firewall.

# Create the allowlist with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
   -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

# Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


Set-AzFirewall -AzureFirewall $fw

Почему TCP пинг и аналогичные инструменты успешно подключаются к целевому полному доменному имени, даже если ни одно правило в Azure Firewall не разрешает этот трафик?

Пинг по протоколу TCP на самом деле не подключается к целевому FQDN. Azure Firewall не разрешает подключение к любому целевому IP-адресу или полному доменному имени, если только не существует явного правила, которое разрешает его.

Tcp ping — это уникальный вариант использования, когда, если правило не разрешено, брандмауэр сам отвечает на запрос TCP-пинга клиента, даже если TCP-пинг не достигает целевого IP-адреса или полного доменного имени. В этом случае событие не регистрируется. Если существует сетевое правило, позволяющее получить доступ к целевому IP-адресу или полному доменному имени (FQDN), то ping-запрос достигает целевого сервера, и его ответ передается клиенту. Это событие заносится в журнал сетевых правил.

Почему инструменты, такие как TCP ping и аналогичные программы, успешно подключаются к целевому FQDN/IP-адресу по портам 80, 443 и 1433, но не фиксируются в журналах Azure Firewall?

Azure Firewall выступает в качестве пассивного прослушивателя портов 80, 443 и 1433. Azure Firewall не регистрирует пакеты TCP SYN на этих портах, если трафик приложения не существует. HTTP GET-запрос и клиентское приветствие TLS регистрируются в Azure Firewall.

Существуют ли ограничения на число IP-адресов, поддерживаемых группами IP-адресов?

Да. Дополнительные сведения см. в разделе пределы, квоты и ограничения подписки и службы Azure

Можно ли переместить IP-группу в другую группу ресурсов?

Нет, в настоящее время перемещение IP-группы в другую группу ресурсов не поддерживается.

Что такое время ожидания простоя TCP для Azure Firewall?

Стандартное поведение сетевого брандмауэра заключается в том, чтобы обеспечивать активность TCP-подключений и быстро закрывать их в случае простоя. Время ожидания бездействия TCP в Azure Firewall составляет четыре минуты. Этот параметр не настраивается пользователем, но вы можете обратиться в службу поддержки Azure, чтобы увеличить время ожидания простоя для входящих и исходящих подключений до 15 минут. Нельзя изменить время простоя для трафика восток-запад.

Если период бездействия превышает значение тайм-аута, нет гарантии, что сеанс TCP или HTTP сохранится. Распространенной практикой является использование функции keep-alive в TCP. Такой подход позволяет поддерживать подключения активными в течение более длительного периода. Дополнительные сведения см. в примерах .NET.

Можно ли развернуть Azure Firewall без общедоступного IP-адреса?

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

Где Azure Firewall хранит данные клиента?

Azure Firewall не перемещает или не хранит данные клиента из региона, в который он развернут.

Существует ли способ автоматического резервного копирования Azure Firewall и политик?

Да. Дополнительные сведения см. в разделе Создание резервных копий Azure Firewall и политики Azure Firewall с помощью приложения Logic Apps.

Поддерживается ли Azure Firewall в защищенных виртуальных центрах (vWAN) в Катаре?

Нет, в настоящее время Azure Firewall в защищенных виртуальных центрах (vWAN) не поддерживается в Катаре.

Сколько одновременных подключений может поддерживать Azure Firewall?

Azure Firewall использует Azure Virtual Machines в основе, которые имеют жесткое ограничение числа подключений. Общее количество активных подключений на каждую виртуальную машину составляет 250 тыс.

Общее ограничение на брандмауэр — это ограничение подключения к виртуальной машине (250k) x количество виртуальных машин в серверном пуле брандмауэра. Azure Firewall начинается с двух виртуальных машин и масштабируется на основе использования ЦП и пропускной способности.

Что такое поведение повторного использования порта TCP/UDP SNAT в Azure Firewall?

Azure Firewall в настоящее время использует исходные порты TCP/UDP для исходящего трафика SNAT без времени ожидания. При закрытии подключения TCP/UDP используемый TCP-порт сразу же становится доступным для будущих подключений.

В качестве обходного решения для определенных архитектур вы можете развернуть и масштабировать NAT Gateway с Azure Firewall для обеспечения более широкого пула портов SNAT, что увеличивает гибкость и доступность.

Что такое поведение NAT в Azure Firewall?

Конкретное поведение NAT зависит от конфигурации брандмауэра и типа NAT, настроенного. Например, брандмауэр имеет правила DNAT для входящего трафика, а правила сети и правила приложений для исходящего трафика через брандмауэр.

Дополнительные сведения см. в разделе Характеристики NAT в Azure Firewall.

Тайм-ауты и масштабирование

Как работает осушение соединений?

Для любого планового обслуживания логика фильтрации подключений постепенно обновляет узлы серверной части. Azure Firewall ожидает 90 секунд, пока существующие подключения будут закрыты. В течение первых 45 секунд внутренний узел не принимает новые подключения, и в оставшееся время он отвечает RST на все входящие пакеты. При необходимости клиенты могут автоматически восстановить подключение с другим узлом серверной части.

Как Azure Firewall обрабатывает завершение работы экземпляра виртуальной машины во время уменьшения масштаба (внутреннего сжатия) масштабируемого набора виртуальных машин или обновления программного обеспечения флота?

Завершение работы экземпляра виртуальной машины Azure Firewall может произойти во время уменьшения масштаба в масштабируемом наборе виртуальных машин или во время обновления программного обеспечения для всех связанных экземпляров. В этих случаях новые входящие подключения балансируют нагрузку на остальные экземпляры брандмауэра и не перенаправляются в экземпляр брандмауэра вниз. Через 45 секунд брандмауэр начинает отклонять существующие подключения, отправляя пакеты TCP RST. Через 45 секунд виртуальная машина брандмауэра завершает работу. Дополнительные сведения см. в разделе Сброс TCP и время ожидания бездействия в Load Balancer.

Сколько времени требуется для масштабирования Azure Firewall?

Azure Firewall постепенно масштабируется, если средняя пропускная способность или потребление ЦП составляет 60%, или количество подключений составляет 80%. Например, он начинает масштабирование по достижении 60 % от максимальной пропускной способности. Максимальное число пропускной способности зависит от номера SKU Azure Firewall и включенных функций. Дополнительные сведения см. в разделе о производительности Azure Firewall.

Процесс масштабирования занимает от пяти до семи минут. При тестировании производительности убедитесь, что вы тестируете по крайней мере 10–15 минут и запускаете новые подключения, чтобы воспользоваться преимуществами новых созданных Azure Firewall узлов.

Как Azure Firewall обрабатывает время простоя?

Если подключение имеет время ожидания простоя (четыре минуты без действия), Azure Firewall корректно завершает подключение путем отправки пакета TCP RST.

Обслуживание, контролируемое клиентом

Какой тип обслуживания поддерживает управляемое клиентом обслуживание?

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

Можно ли получить предварительное уведомление о событии обслуживания?

Дополнительные уведомления о обслуживании Azure Firewall недоступны.

Можно ли настроить период обслуживания менее пяти часов?

Нет, требуется минимальное пятичасовое время обслуживания.

Можно ли настроить период обслуживания, отличный от ежедневного расписания?

Нет, в настоящее время окна обслуживания настраиваются на ежедневное повторение.

Существуют ли случаи, когда не удается контролировать определенные обновления?

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

Должны ли ресурсы конфигурации обслуживания находиться в том же регионе, что и Azure Firewall?

Да.

Можно ли создать несколько конфигураций обслуживания для одной Azure Firewall?

№ В настоящее время с Azure Firewall может быть связана только одна конфигурация обслуживания.

Какие SKU Azure Firewall можно настроить для использования обслуживания, контролируемого клиентом?

Все SKU Azure Firewall — Базовый, Стандартный и Премиум поддерживают обслуживание под управлением клиента.

Сколько времени нужно, чтобы политика конфигурации обслуживания стала действующей после назначения её на Azure Firewall?

Для Azure Firewall может потребоваться до 24 часов, чтобы начать следование расписанию обслуживания после того, как политика обслуживания связана.

Я запланировал окно обслуживания на будущую дату для одного из моих ресурсов Azure Firewall. Приостановлены ли действия по обслуживанию на этом ресурсе до тех пор?

Действия по обслуживанию в Azure Firewall не приостановлены в течение периода, предшествующего запланированному периоду обслуживания. В те дни, которые не включены в расписание обслуживания, регулярные операции обслуживания продолжаются в обычном режиме для ресурса.

Как узнать больше о обслуживании, управляемом клиентом, на Azure Firewall?

Дополнительные сведения см. в разделе "Настройка обслуживания, управляемого клиентом".

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

Подробный список функций Azure Firewall см. в разделе Azure Firewall функции.

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

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

Azure Firewall можно развернуть с помощью портала Azure, PowerShell, REST API или шаблонов. Пошаговые инструкции см. в разделе Tutorial: развертывание и настройка Azure Firewall с помощью портала Azure.

Azure Firewall использует правила и коллекции правил. Коллекция правил — это набор правил с одинаковым порядком и приоритетом. Коллекции правил выполняются в порядке приоритета. Коллекции правил DNAT имеют более высокий приоритет, чем коллекции правил сети, которые, в свою очередь, имеют более высокий приоритет, чем коллекции правил приложений. Все правила завершаются.

Есть три типа коллекций правил:

• Правила приложения: настройте полные доменные имена (FQDN), к которым можно получить доступ из виртуальной сети.
• Сетевые правила: настройте правила с исходными адресами, протоколами, портами назначения и адресами назначения.
• Правила NAT: настройте правила DNAT для разрешения входящих подключений к Интернету или интрасети (предварительная версия).

Дополнительные сведения см. в разделе Configure Azure Firewall rules.

Azure Firewall интегрируется с Azure Monitor для просмотра и анализа журналов. Журналы можно отправлять в Log Analytics, Azure Storage или Центры событий и анализировать с помощью таких средств, как Log Analytics, Excel или Power BI. Дополнительные сведения см. в разделе Tutorial: Мониторинг журналов Azure Firewall.

Azure Firewall — это управляемая облачная служба безопасности сети, которая защищает ресурсы виртуальной сети. Брандмауэр разработан как служба с полным отслеживанием состояния со встроенной высокой доступностью и неограниченной облачной масштабируемостью. Она предварительно интегрирована с поставщиками безопасности как услуги (SECaaS), чтобы повысить безопасность виртуальных сетей и соединений с Интернетом филиалов. Дополнительные сведения см. в разделе Безопасность сети Azure.

WAF шлюза приложений обеспечивает централизованную защиту входящего трафика для веб-приложений от распространенных эксплойтов и уязвимостей. Azure Firewall обеспечивает входящие защиты для протоколов, отличных от HTTP/S (например, RDP, SSH, FTP), защиты исходящего сетевого уровня для всех портов и протоколов, а также защиты уровня приложения для исходящего ТРАФИКА HTTP/S.

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

Azure Firewall — это управляемая служба с несколькими уровнями защиты, включая защиту платформы с NSG на уровне сетевого адаптера (недоступно для просмотра). Группы безопасности сети на уровне подсети не требуются в AzureFirewallSubnet и отключены для предотвращения прерываний работы служб.

Частные конечные точки — это компонент Private Link, технология, которая позволяет взаимодействовать со службами PaaS Azure с помощью частных IP-адресов вместо общедоступных. Azure Firewall можно использовать для предотвращения доступа к общедоступным IP-адресам, что позволяет предотвратить кражу данных в Azure службах, не использующих Private Link, а также для реализации политик нулевого доверия, определяя, кто в вашей организации должен иметь доступ к этим Azure PaaS службам, поскольку Private Link по умолчанию открывает сетевой доступ для всей корпоративной сети.

Правильный дизайн для проверки трафика к частным конечным точкам с Azure Firewall зависит от сетевой архитектуры, см. дополнительные сведения в статьях Azure Firewall сценарии проверки трафика, предназначенного для частной конечной точки.

Конечные точки службы виртуальной сети являются альтернативой Private Link для управления доступом в сеть служб PaaS Azure. Даже если клиент по-прежнему использует общедоступные IP-адреса для доступа к службе PaaS, исходная подсеть становится видимой, чтобы целевая служба PaaS могли реализовать правила фильтрации и ограничить доступ на основе каждой подсети. Подробное сравнение обоих механизмов можно найти в разделе "Сравнение частных конечных точек" и "Конечные точки службы".

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

Сведения о ценах см. в разделе Ценообразование Azure Firewall.

Ограничения см. в разделе лимиты подписки и службы Azure, квоты и ограничения.

Azure Firewall не перемещает или не хранит данные клиента за пределами региона, в котором он развернут.

Нет, Azure Firewall в защищенных виртуальных центрах (vWAN) в настоящее время не поддерживается в Катаре.

Да, Azure Firewall поддерживает фильтрацию входящего и исходящего трафика. Входящий фильтр обычно используется для протоколов, отличных от HTTP, таких как RDP, SSH и FTP. Для входящего трафика HTTP и HTTPS рекомендуется использовать брандмауэр веб-приложения, например Azure Web Application Firewall (WAF) или разгрузку TLS и функции глубокой проверки пакетов Azure Firewall Premium.

Да, Azure Firewall Basic поддерживает принудительное туннелирование.

TCP ping фактически не подключается к целевому полному доменному имени. Azure Firewall блокирует подключения к любому целевому IP-адресу или полному доменному имени (FQDN), если это не разрешено одним из правил.

Если правило не разрешает трафик, брандмауэр сам реагирует на запрос TCP-ping клиента. Этот ответ не достигает целевого IP-адреса или полного доменного имени и не фиксируется в журнале. Если правило сети явно разрешает доступ к целевому IP-адресу или полному доменному имени (FQDN), ping-запрос достигает целевого сервера, и его ответ передается обратно клиенту. Это событие заносится в журнал сетевых правил.

Нет, Azure Firewall изначально не поддерживает пиринг BGP. Однако функция маршрутов SNAT Autolearn SNAT косвенно использует BGP через Azure Route Server.

Azure Firewall изначально не поддерживает ESP (инкапсулирование полезных данных безопасности), но можно разрешить трафик ESP, настроив сетевое правило следующим образом:

конфигурация Azure Firewall (сетевое правило):

• Протокол: Любой
• Исходный порт: * (любой)
• Порт назначения: * (любой)
• Источник или назначение: укажите IP-адреса по мере необходимости

Эта конфигурация позволяет пакетам ESP (IP-протоколу 50) и другому трафику, отличному от TCP/UDP, соответствовать правилу. Однако обратите внимание, что Azure Firewall не проверяет полезные данные ESP.

Reference: если используется NSG (группа безопасности сети) вместо Azure Firewall: NSG не предоставляет прямой параметр для указания ESP (номер IP-протокола 50), но пакеты ESP могут быть разрешены с помощью следующих параметров:

• Протокол: Любой
• Порт: * (любой)
• Источник или назначение: укажите IP-адреса по мере необходимости

Recommendations:

• Для конфигураций VPN IPsec рекомендуется использовать Azure VPN Gateway.
• Рекомендуется использовать шаблон NVA (сетевого виртуального устройства) в зависимости от ваших требований.

Вы можете использовать Azure PowerShell для отключения и выделения ресурсов брандмауэра Azure. Процесс зависит от конфигурации.

Для брандмауэра без сетевого адаптера управления:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet, @($publicip1, $publicip2))
Set-AzFirewall -AzureFirewall $azfw

Для брандмауэра с сетевым адаптером управления:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip)
Set-AzFirewall -AzureFirewall $azfw

Для брандмауэра в защищенном виртуальном концентраторе:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$virtualhub = Get-AzVirtualHub -ResourceGroupName "vHUB RG Name" -Name "vHUB Name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Firewall RG Name"
$azfw.Allocate($virtualhub.Id)
Set-AzFirewall -AzureFirewall $azfw

Примечание.

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

Рекомендуется настроить зоны доступности во время первоначального развертывания. Однако их можно перенастроить после развертывания, если:

• Брандмауэр развертывается в виртуальной сети (не поддерживается в защищенных виртуальных центрах).
• Регион поддерживает зоны доступности.
• Все присоединенные общедоступные IP-адреса сконфигурированы с одинаковыми зонами.

Чтобы перенастроить зоны доступности, выполните приведенные действия.

1. Освобождение брандмауэра:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $azfw.Deallocate()
   Set-AzFirewall -AzureFirewall $azfw
   

2. Обновите конфигурацию зоны и выделите брандмауэр:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
   $pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
   $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
   $azfw.Allocate($vnet, $pip, $mgmtPip)
   $azfw.Zones = 1, 2, 3
   Set-AzFirewall -AzureFirewall $azfw
   

Да:

• Azure Firewall и виртуальная сеть должны находиться в одной группе ресурсов.
• Общедоступный IP-адрес может находиться в другой группе ресурсов.
• Все ресурсы (Azure брандмауэр, виртуальная сеть, общедоступный IP-адрес) должны находиться в одной подписке.

Состояние Failed указывает, что обновление конфигурации завершилось сбоем в одном или нескольких экземплярах серверной системы. Azure Firewall остается операционным, но конфигурация может быть несогласованной. Повторите обновление до тех пор, пока состояние подготовки не изменится на "Успешно".

Azure Firewall использует конфигурацию active-active с несколькими внутренними узлами. Во время планового обслуживания очистка подключений обеспечивает корректное обновление. При незапланированных сбоях новый узел заменяет неудачный, а подключение обычно восстанавливается в течение 10 секунд.

Да, имена брандмауэра ограничены 50 символами.

Подсеть /26 обеспечивает достаточные IP-адреса для масштабирования, так как Azure Firewall подготавливает дополнительные экземпляры виртуальных машин.

Нет, для всех сценариев масштабирования достаточно подсети /26.

Azure Firewall автоматически масштабируется на основе использования ЦП, пропускной способности и количества подключений. Емкость пропускной способности от 2,5 до 3 Гбит/с изначально до 30 Гбит/с (номер SKU категории "Стандартный") или 100 Гбит/с (номер SKU уровня "Премиум").

Да. Дополнительные сведения см. в разделе Azure ограничения подписки и службы, квоты и ограничения.

Нет, в настоящее время перемещение IP-группы в другую группу ресурсов не поддерживается.

Стандартное поведение сетевого брандмауэра заключается в том, чтобы обеспечивать активность TCP-подключений и быстро закрывать их в случае простоя. Время ожидания бездействия TCP в Azure Firewall составляет четыре минуты. Этот параметр не настраивается пользователем, но вы можете обратиться в службу поддержки Azure, чтобы увеличить время ожидания простоя для входящих и исходящих подключений до 15 минут. Нельзя изменить время простоя для трафика восток-запад.

Если период бездействия превышает значение тайм-аута, нет гарантии, что сеанс TCP или HTTP сохранится. Распространенной практикой является использование функции keep-alive в TCP. Такой подход позволяет поддерживать подключения активными в течение более длительного периода. Дополнительные сведения см. в примерах .NET.

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

Да. Дополнительные сведения см. в разделе Создание резервных копий Azure Firewall и политики Azure Firewall с помощью приложения Logic Apps.

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

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

Да. Однако настройка UDR для перенаправления трафика между подсетями в одной виртуальной сети требует большего внимания. Хотя использование диапазона адресов виртуальной сети в качестве целевого префикса для UDR достаточно, это также направляет весь трафик с одного компьютера на другой компьютер в той же подсети через экземпляр Azure Firewall. Чтобы избежать этого, включите маршрут для подсети в UDR с типом следующего прыжка виртуальной сети. Управление этими маршрутами может быть весьма трудоемким и подвержено ошибкам. Рекомендуется использовать группы безопасности сети для сегментации внутренней сети, так как для этого не требуются определяемые пользователем маршруты.

Azure Firewall не выполняет SNAT, если целевой IP-адрес находится в частном диапазоне IP-адресов согласно IANA RFC 1918 или IANA RFC 6598 для частных сетей. Если ваша организация использует диапазон общедоступных IP-адресов для частных сетей, Azure Firewall осуществляет SNAT, перенаправляя трафик к одному из частных IP-адресов брандмауэра в AzureFirewallSubnet. Вы можете настроить Azure Firewall так, чтобы не выполнять SNAT для вашего диапазона общедоступных IP-адресов. Для получения дополнительной информации см. раздел диапазоны частных IP-адресов для SNAT в Azure Firewall.

Кроме того, для трафика, обрабатываемого правилами приложения, всегда будет использоваться SNAT. Если вы хотите увидеть исходный IP-адрес в журналах для трафика FQDN, можно использовать правила сети с полным доменным именем назначения.

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

Azure Firewall должен иметь прямое подключение к Интернету. Если сеть AzureFirewallSubnet узнает стандартный маршрут к вашей локальной сети через BGP, вы должны переопределить его, установив пользовательский маршрут 0.0.0.0/0 с параметром NextHopType и значением Интернет, чтобы обеспечить прямое подключение к Интернету.

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

• URL-адрес — звездочки работают при размещении на самой правой или самой левой стороне. Если находится слева, то это не может быть частью полного доменного имени (FQDN).
• Полностью квалифицированное доменное имя - звездочки работают, если они размещены на самой левой стороне.
• GENERAL - Звездочки на самой левой стороне означают буквально все, что слева совпадает, в результате совпадают несколько поддоменов и/или потенциально нежелательные варианты доменных имен. См. следующие примеры.

Примеры:

Тип	Правило	Поддерживается?	Положительные примеры
Целевой URL	www.contoso.com	Да	www.contoso.com www.contoso.com/
Целевой URL	*.contoso.com	Да	any.contoso.com/ sub1.any.contoso.com
Целевой URL	*contoso.com	Да	example.anycontoso.com sub1.example.contoso.com contoso.com Предупреждение: использование этого шаблона может привести к потенциально нежелательным или рискованным вариациям, таким как th3re4lcontoso.com. Используйте с осторожностью.
Целевой URL	www.contoso.com/test	Да	www.contoso.com/test www.contoso.com/test/ www.contoso.com/test?with_query=1
Целевой URL	www.contoso.com/test/*	Да	www.contoso.com/test/anything Примечание. www.contoso.com/testНе совпадает (последняя косая черта)
Целевой URL	www.contoso.*/test/*	нет
Целевой URL	www.contoso.com/test?example=1	нет
Целевой URL	www.contoso.*	нет
Целевой URL	www.*contoso.com	нет
Целевой URL	www.contoso.com:8080	нет
Целевой URL	*.contoso.*	нет
Целевое доменное имя	www.contoso.com	Да	www.contoso.com
Целевое доменное имя	*.contoso.com	Да	any.contoso.com Примечание: Если вы хотите намеренно разрешить contoso.com, следует включить contoso.com в правило. В противном случае подключение удаляется по умолчанию, так как запрос не соответствует ни одному правилу.
Целевое доменное имя	*contoso.com	Да	example.anycontoso.com contoso.com
Целевое доменное имя	www.contoso.*	нет
Целевое доменное имя	*.contoso.*	нет

№ Azure Firewall блокирует доступ к Active Directory по умолчанию. Чтобы разрешить доступ, настройте тег службы AzureActiveDirectory. Для получения дополнительной информации см. теги службы Azure Firewall.

Да, для этого можно использовать Azure PowerShell:

# Add a Threat Intelligence allowlist to an Existing Azure Firewall.

# Create the allowlist with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
   -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

# Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


Set-AzFirewall -AzureFirewall $fw

Пинг по протоколу TCP на самом деле не подключается к целевому FQDN. Azure Firewall не разрешает подключение к любому целевому IP-адресу или полному доменному имени, если только не существует явного правила, которое разрешает его.

Tcp ping — это уникальный вариант использования, когда, если правило не разрешено, брандмауэр сам отвечает на запрос TCP-пинга клиента, даже если TCP-пинг не достигает целевого IP-адреса или полного доменного имени. В этом случае событие не регистрируется. Если существует сетевое правило, позволяющее получить доступ к целевому IP-адресу или полному доменному имени (FQDN), то ping-запрос достигает целевого сервера, и его ответ передается клиенту. Это событие заносится в журнал сетевых правил.

Azure Firewall выступает в качестве пассивного прослушивателя портов 80, 443 и 1433. Azure Firewall не регистрирует пакеты TCP SYN на этих портах, если трафик приложения не существует. HTTP GET-запрос и клиентское приветствие TLS регистрируются в Azure Firewall.

Да. Дополнительные сведения см. в разделе пределы, квоты и ограничения подписки и службы Azure

Нет, в настоящее время перемещение IP-группы в другую группу ресурсов не поддерживается.

Стандартное поведение сетевого брандмауэра заключается в том, чтобы обеспечивать активность TCP-подключений и быстро закрывать их в случае простоя. Время ожидания бездействия TCP в Azure Firewall составляет четыре минуты. Этот параметр не настраивается пользователем, но вы можете обратиться в службу поддержки Azure, чтобы увеличить время ожидания простоя для входящих и исходящих подключений до 15 минут. Нельзя изменить время простоя для трафика восток-запад.

Если период бездействия превышает значение тайм-аута, нет гарантии, что сеанс TCP или HTTP сохранится. Распространенной практикой является использование функции keep-alive в TCP. Такой подход позволяет поддерживать подключения активными в течение более длительного периода. Дополнительные сведения см. в примерах .NET.

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

Azure Firewall не перемещает или не хранит данные клиента из региона, в который он развернут.

Да. Дополнительные сведения см. в разделе Создание резервных копий Azure Firewall и политики Azure Firewall с помощью приложения Logic Apps.

Нет, в настоящее время Azure Firewall в защищенных виртуальных центрах (vWAN) не поддерживается в Катаре.

Azure Firewall использует Azure Virtual Machines в основе, которые имеют жесткое ограничение числа подключений. Общее количество активных подключений на каждую виртуальную машину составляет 250 тыс.

Общее ограничение на брандмауэр — это ограничение подключения к виртуальной машине (250k) x количество виртуальных машин в серверном пуле брандмауэра. Azure Firewall начинается с двух виртуальных машин и масштабируется на основе использования ЦП и пропускной способности.

Azure Firewall в настоящее время использует исходные порты TCP/UDP для исходящего трафика SNAT без времени ожидания. При закрытии подключения TCP/UDP используемый TCP-порт сразу же становится доступным для будущих подключений.

В качестве обходного решения для определенных архитектур вы можете развернуть и масштабировать NAT Gateway с Azure Firewall для обеспечения более широкого пула портов SNAT, что увеличивает гибкость и доступность.

Конкретное поведение NAT зависит от конфигурации брандмауэра и типа NAT, настроенного. Например, брандмауэр имеет правила DNAT для входящего трафика, а правила сети и правила приложений для исходящего трафика через брандмауэр.

Дополнительные сведения см. в разделе Характеристики NAT в Azure Firewall.

Для любого планового обслуживания логика фильтрации подключений постепенно обновляет узлы серверной части. Azure Firewall ожидает 90 секунд, пока существующие подключения будут закрыты. В течение первых 45 секунд внутренний узел не принимает новые подключения, и в оставшееся время он отвечает RST на все входящие пакеты. При необходимости клиенты могут автоматически восстановить подключение с другим узлом серверной части.

Завершение работы экземпляра виртуальной машины Azure Firewall может произойти во время уменьшения масштаба в масштабируемом наборе виртуальных машин или во время обновления программного обеспечения для всех связанных экземпляров. В этих случаях новые входящие подключения балансируют нагрузку на остальные экземпляры брандмауэра и не перенаправляются в экземпляр брандмауэра вниз. Через 45 секунд брандмауэр начинает отклонять существующие подключения, отправляя пакеты TCP RST. Через 45 секунд виртуальная машина брандмауэра завершает работу. Дополнительные сведения см. в разделе Сброс TCP и время ожидания бездействия в Load Balancer.

Azure Firewall постепенно масштабируется, если средняя пропускная способность или потребление ЦП составляет 60%, или количество подключений составляет 80%. Например, он начинает масштабирование по достижении 60 % от максимальной пропускной способности. Максимальное число пропускной способности зависит от номера SKU Azure Firewall и включенных функций. Дополнительные сведения см. в разделе о производительности Azure Firewall.

Процесс масштабирования занимает от пяти до семи минут. При тестировании производительности убедитесь, что вы тестируете по крайней мере 10–15 минут и запускаете новые подключения, чтобы воспользоваться преимуществами новых созданных Azure Firewall узлов.

Если подключение имеет время ожидания простоя (четыре минуты без действия), Azure Firewall корректно завершает подключение путем отправки пакета TCP RST.

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

Дополнительные уведомления о обслуживании Azure Firewall недоступны.

Нет, требуется минимальное пятичасовое время обслуживания.

Нет, в настоящее время окна обслуживания настраиваются на ежедневное повторение.

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

Да.

№ В настоящее время с Azure Firewall может быть связана только одна конфигурация обслуживания.

Все SKU Azure Firewall — Базовый, Стандартный и Премиум поддерживают обслуживание под управлением клиента.

Для Azure Firewall может потребоваться до 24 часов, чтобы начать следование расписанию обслуживания после того, как политика обслуживания связана.

Действия по обслуживанию в Azure Firewall не приостановлены в течение периода, предшествующего запланированному периоду обслуживания. В те дни, которые не включены в расписание обслуживания, регулярные операции обслуживания продолжаются в обычном режиме для ресурса.

Дополнительные сведения см. в разделе "Настройка обслуживания, управляемого клиентом".