Сурен Джамияна, программный менеджер Azure
Соавтором этого поста является Адам Стюарт, технический специалист Azure Networking.
Стандартный DNS, DNS-прокси и фильтр FQDN (для протоколов, отличных от HTTP / S и MSSQL) в брандмауэре Azure теперь доступны каждому.
Брандмауэр Azure – это брандмауэр как услуга (FWaaS), работающий в облаке, позволяющий централизованно управлять трафиком и вести лог посредством DevOps. Служба поддерживает фильтрацию на уровне приложений, NAT и сети. При этом она интегрирована в канал Microsoft Threat Intelligence, что позволяет «отсеивать» известные вредоносные IP-адреса и домены. Брандмауэр Azure максимально функционален благодаря возможности автоматического масштабирования.
Поддержка настраиваемого DNS теперь в свободном доступе
С момента запуска в сентябре 2018 года брандмауэр Azure был «заточен» для использования с Azure DNS, что позволило службе решать свои основные задачи. Пользовательский DNS позволяет настроить брандмауэр Azure для использования собственного DNS-сервера. Вы можете настроить один DNS-сервер или несколько серверов в настройках DNS брандмауэра Azure и политики брандмауэра. Кроме того, брандмауэр Azure также может разрешать имена с помощью Azure Private DNS. Виртуальная сеть, в которой находится брандмауэр Azure, должна быть связана с частной зоной Azure.
DNS-прокси также теперь общедоступен
Если DNS-прокси включен, брандмауэр Azure может обрабатывать и пересылать DNS-запросы из виртуальных сетей на выбранный DNS-сервер. Эта функция имеет решающее значение и требуется для надежной работы фильтра FQDN. Вы можете включить DNS-прокси в настройках брандмауэра и политики Azure.
Для настройки DNS-прокси требуется три шага:
-
включите DNS-прокси в настройках DNS брандмауэра Azure;
-
при необходимости настройте свой собственный DNS-сервер или используйте предоставленный по умолчанию;
-
в конце вам нужно настроить частный IP-адрес брандмауэра Azure в качестве настраиваемого DNS-сервера в соответствующих настройках вашей виртуальной сети (чтобы направить поток трафика через брандмауэр).
Прокси-сервер DNS отслеживает запросы на TCP-порт 53 и перенаправляет их в Azure DNS или указанный вам настраиваемый DNS.
Фильтрация FQDN в сетевых правилах
Теперь вы можете использовать полные доменные имена (FQDN) в сетевых правилах на основе разрешения DNS в брандмауэре Azure и брандмауэрной политике. Указанные полные доменные имена в ваших списках правил преобразуются в IP-адреса с учетом настроек DNS вашего брандмауэра. Это дает возможность фильтровать исходящий трафик с использованием полных доменных имен с любым протоколом TCP / UDP (включая NTP, SSH, RDP и т. Д.). В данном случае настоятельно рекомендуется включить прокси-сервер DNS, чтобы согласовать разрешения имен для ваших защищенных виртуальных машин и брандмауэра.
В чем разница между фильтрацией FQDN в правилах приложений и правилами сети?
Фильтр FQDN в правилах приложений для HTTP / S и MSSQL базируется на прозрачном прокси-сервере уровня приложения. Таким образом, он может различать два FQDN, которые разрешены в одном и том же IP-адресе. Это не касается фильтра FQDN в сетевых правилах, поэтому по возможности рекомендуется использовать правила приложений.
Использование брандмауэра Azure в качестве прокси-сервера DNS для обеспечения доступа к частным конечным точкам из локальной среды
Azure Private Link предоставляет возможность подключаться к службам Microsoft PaaS, включая учетные записи хранения, службы приложений и т. д. Частная конечная точка в данном случае – это сетевой интерфейс, который конфиденциально и безопасно соединяет вас со службой PaaS на основе Azure Private Link. Частные конечные точки используют IP-адрес из вашей виртуальной сети (VNet), эффективно перенося службу из вашей личной сети в облако. Такой метод обеспечивает дополнительную безопасность, поскольку он обеспечивает свободный доступ к IP-адресам службы PaaS.
Среди других достоинств Azure Private Link можно выделить использование службы Microsoft PaaS через гибридные подключения с частной адресацией (например, с помощью частного пиринга Azure ExpressRoute или Site-to-Site VPN). Однако здесь возникает проблема пересылки DNS-запросов из локальной среды в Azure Private DNS.