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

В мае 2024 года Microsoft представила довольно сложную конструкцию внедрения DNS в клиентские устройства, что может решить некоторые проблемы.

Однако независимые специалисты по безопасности беспокоятся, что таким образом Microsoft блокирует систему DNS в сетях Windows. Принятие «белого списка» разрешённых IP-адресов требует максимального доверия к администратору этого списка и угрожает потенциальными злоупотреблениями.

Новая система называется Zero Trust DNS (ZTDNS), то есть «DNS с нулевым доверием». Две её основные особенности:

  1. шифрованные и криптографически аутентифицированные соединения между клиентами конечных пользователей и DNS-серверами;
  2. возможность для администраторов жёстко ограничивать домены для резолвинга.

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

ZTDNS решает эту давнюю проблему путём интеграции DNS-движка Windows с платформой фильтрации Windows Filtering Platform — основным компонентом Windows Firewall — непосредственно в клиентские устройства.

Интеграция DNS-движка с Windows Firewall позволит изменять правила файрвола по каждому доменного имени, при этом со сквозным шифрованием. Например, организация может установить для всех своих сотрудников конкретный DNS-сервер с TLS и разрешить только определённые домены. Microsoft называет такой DNS-сервер «защитным» (protective DNS server).

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

По умолчанию файрвол использует белый список, то есть запрещает все домены, кроме списка разрешённых. Отдельный список разрешений будет содержать подсети IP-адресов, которые необходимы клиентам для запуска авторизованного ПО. Эксперт по сетевой безопасности Ройс Уильямс назвал это «своего рода двунаправленным API для уровня файрвола, так что вы можете как запускать действия (по входу *в* файрвол), так и внешние действия на основе состояния файрвола (выход *из* файрвола).



Иллюстрация выше показывает, как ZTDNS вписывается в платформу управления мобильными устройствами Mobile Device Management, которая помогает администраторам защищать и контролировать удалённые устройства, авторизованные для подключения к сети. Блокируются исходящие соединения с клиентского устройства на все IP-адреса IPv4 и IPv6, за исключением соединений с защитными DNS-серверами, серверами DHCP, DHCPv6 и NDP, необходимыми для обнаружения сети:



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



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

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

Сравнение системы с ZTDNS и без неё:



Для реализации защитных DNS-серверов и ZTDNS минимальным требованием является поддержка либо DNS по HTTPS (DoH), либо DNS по TLS (DoT), поскольку ZTDNS препятствует использованию DNS в открытом виде в Windows.

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

Microsoft опубликовала отдельную статью с подробным описанием возможных проблем в процессе внедрения ZTDNS. Сейчас технология находится в стадии приватного предпросмотра. Пока не сообщается, её включат в программу Windows Insiders или когда она станет общедоступной.

Комментарии (6)


  1. nEkToSAN
    08.09.2024 20:42
    +1

    Относительно компаний с закрытыми корп сетями: корп сети и так обычно настраивают на получение корпоративного DNS сервера, т.е. подменить запрос DNS можно только внутри самой корп сети. Риск описанный в статье не исключён, но ограничен только корп сетью компании. В плане удалённой работы, то корпоративные VPN-решения, например, VPN от Fortinet самим VPN-клиентом подменяют глобально на пк/ноуте пользователя DNS сервера, и пользователь при активном VPN обратится к корпоративному DNS серверу (мне это даже доставляло иногда неудобства, ибо надо было иногда заходить с личного пк на запрещённые компанией ресурсы. Хех). В таком случае запрос DNS с пк/ноута пользователя с компа уходит в VPN-туннель в корп сеть компании.

    Остаются компании, где подобных высоких требований по доступам в интернет с рабочего места нету. Но им скорей всего подобная функция и не будет особо важна. Хотя как знать, если для этого не надо будет покупать каких-то корпоративных подписочных лицензий (которые майки очень любят, куча разных лицензий на office365, подписки на виртуализацию в Azure... и т.д. )) ), то руководство может и нагрузить админов и такой работой).


  1. Kil1J0y
    08.09.2024 20:42

    А я не понял, а зачем? Ведь можно же поднять dot doh на корп сервере, через прямое обращение к root серверам, и там рулить правилами.


    1. dartraiden
      08.09.2024 20:42

      Читайте оригинал, там объясняется. Приложение (особенно вредоносное) может проигнорировать ваш корпоративный сервер (где вы рулите правилами) и гонять запросы к DNS-серверу, который оно предпочитает использовать (который не осуществляет фильтрацию). Ну вот не стал малварщик в своей малвари реализовывать подхват адреса корпоративного DNS из системных политик, негодяй такой. Вместо этого он встроил в малварь клиент DNS-over-HTTS, чтобы пулять запросы к https://dns.google и скрывать это от вас.

      Поэтому, чтобы не заниматься перехватом незашифрованного DNS, блокировать DoT и, что сложнее, DoH, или обнюхивать SNI (что затратно по ресурсам и с распространением ECH становится невозможным) по умолчанию блокируем весь исходящий трафик, кроме DHCP и Protective DNS. Когда приложение пытается резолвить через ZTDNS, то отрезовленные IP помещаются в белый список (если они на корп. сервере не в чёрном списке) и с ними можно установить исходящее соединение.

      Когда вредоносное приложение пытается резолвить через что-то стороннее (обычный сторонний plain-text DNS/DoT/DoH/DNSCrypt), то если оно даже и отрезолвит свой управляющий домен, то установить связь с отрезолвленным IP-адресом не сможет, потому что он не добавился в белый список.


  1. CitizenOfDreams
    08.09.2024 20:42

    Просто у существующих DNS есть фатальный недостаток.


    1. dartraiden
      08.09.2024 20:42

      У них действительно есть фатальный недостаток - они не дают возможность гарантированно себя завернуть на корпоративный резолвер.


  1. Ghost_NeverBloom
    08.09.2024 20:42

    Ох, майки...
    Теперь дошло до усложнения жизни передовых юзеров, вплоть то подобия "корпоративной сети" дома. Хотя, если эта фича и выйдет в релиз, то не факт, что до России дойдет, так же, как и большинство фич от Apple...