Блог о безопасности FireAI

Автор FireAI Security & Research Team · Опубликовано

Зашифрованный DNS в macOS: DoH и DoT через конфигурационные профили

Зашифрованный DNS в macOS: DoH и DoT через конфигурационные профили

HTTPS скрывает то, что вы отправляете сайту, но прежде чем ваш Mac вообще сможет открыть это соединение, ему нужно задать вопрос открытым текстом: «на какой сервер указывает это имя?» Этот вопрос — DNS-запрос — по умолчанию передаётся в большинстве сетей без шифрования, а значит, ваш интернет-провайдер, администратор сети в офисе или кто угодно ещё в незащищённой Wi-Fi-сети может видеть каждый домен, который вы разрешаете, даже если сами страницы потом полностью зашифрованы.

Почему обычный DNS раскрывает данные

Традиционный DNS, стандартизированный за десятилетия до того, как HTTPS стал стандартом веба по умолчанию, отправляет запросы по обычным UDP или TCP на порт 53 без шифрования, а в большинстве домашних и публичных сетей — и без аутентификации резолвера. Оператору сети не нужно взламывать HTTPS, чтобы составить список всех посещаемых вами доменов, — достаточно просто наблюдать за вашим DNS-трафиком, который идёт открытым текстом прямо рядом. Именно так работают многие DNS-фильтры контента и некоторые формы слежки на уровне сети: не путём анализа зашифрованного трафика, а простым логированием или блокировкой запроса, который обязан произойти до того, как этот трафик вообще появится.

DoH и DoT: два способа зашифровать один и тот же запрос

Два стандарта IETF решают эту проблему, оборачивая сам DNS-запрос в шифрование. DNS-over-TLS, описанный в RFC 7858, оборачивает DNS-запросы в отдельное зашифрованное TLS-соединение на порту 853, что отличает его от обычного трафика и позволяет сети легко его опознать — а в принципе и полностью заблокировать, если сеть хочет остановить именно зашифрованный DNS. DNS-over-HTTPS, описанный в RFC 8484, вместо этого укладывает DNS-запрос в обычный HTTPS-запрос на порту 443 — том же порту, что использует почти весь обычный веб-трафик, — и это архитектурное решение делает запросы DoH куда труднее отличить от обычного просмотра сайтов, а значит и заблокировать отдельно от него.

Нативная поддержка Apple с macOS 11

Apple встроила зашифрованный DNS прямо в сетевой стек, а не оставила это на откуп сторонним приложениям, представив функцию на WWDC 2020 вместе с macOS Big Sur (macOS 11) и соответствующим релизом iOS 14. В докладе было показано два способа включить её: API NEDNSSettingsManager для программной настройки приложениями и — вариант, которым реально воспользуется большинство людей, — конфигурационный профиль с payload com.apple.dnsSettings.managed, задокументированный в справочнике Apple по управлению устройствами, который позволяет указать адрес резолвера DoH или DoT и заставить все приложения в системе использовать его по умолчанию, без стороннего программного обеспечения.

Пример конфигурационного профиля

Конфигурационный профиль — это XML property list (файл .mobileconfig), который macOS может установить через Системные настройки, стоит только дважды кликнуть по нему или перетащить его в раздел «Профили». Пример ниже указывает Mac на публичный DoH-резолвер Quad9 — широко используемый сервис, не требующий учётной записи, который по умолчанию также блокирует соединения с доменами, известными фишингом и другой опасной активностью. Перед использованием замените значения-заглушки идентификатора и UUID; у каждого настоящего профиля должен быть собственный уникальный PayloadUUID.

quad9-doh.mobileconfig
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>PayloadContent</key>
  <array>
    <dict>
      <key>PayloadType</key>
      <string>com.apple.dnsSettings.managed</string>
      <key>PayloadIdentifier</key>
      <string>com.example.dns.quad9-doh</string>
      <key>PayloadUUID</key>
      <string>REPLACE-WITH-A-UNIQUE-UUID-1</string>
      <key>PayloadVersion</key>
      <integer>1</integer>
      <key>PayloadDisplayName</key>
      <string>Quad9 Encrypted DNS (DoH)</string>
      <key>DNSSettings</key>
      <dict>
        <key>DNSProtocol</key>
        <string>HTTPS</string>
        <key>ServerURL</key>
        <string>https://dns.quad9.net/dns-query</string>
        <key>ServerAddresses</key>
        <array>
          <string>9.9.9.9</string>
          <string>149.112.112.112</string>
          <string>2620:fe::fe</string>
          <string>2620:fe::9</string>
        </array>
      </dict>
    </dict>
  </array>
  <key>PayloadDisplayName</key>
  <string>Encrypted DNS - Quad9</string>
  <key>PayloadIdentifier</key>
  <string>com.example.dns.quad9-doh.root</string>
  <key>PayloadType</key>
  <string>Configuration</string>
  <key>PayloadUUID</key>
  <string>REPLACE-WITH-A-UNIQUE-UUID-2</string>
  <key>PayloadVersion</key>
  <integer>1</integer>
</dict>
</plist>

Чтобы вместо этого использовать Cloudflare, укажите в ServerURL значение https://cloudflare-dns.com/dns-query, а в ServerAddresses — 1.1.1.1 и 1.0.0.1 (плюс 2606:4700:4700::1111 и 2606:4700:4700::1001 для IPv6); либо, чтобы использовать DNS-over-TLS вместо DoH, укажите в DNSProtocol значение TLS, а в ServerName — one.one.one.one, согласно опубликованной документации Cloudflare по DoT.

Установка

  1. Сохраните файл с расширением .mobileconfig и дважды кликните по нему, либо откройте Системные настройки, перейдите в «Конфиденциальность и безопасность», затем «Профили», и перетащите туда файл.
  2. macOS покажет содержимое payload — включая настроенный вами резолвер — прежде чем вы его подтвердите; проверяйте это каждый раз, поскольку именно через профиль злоумышленник может перенаправить ваш DNS, если вы установите профиль из непроверенного источника.
  3. Нажмите «Установить» и подтвердите свою личность. Неподписанный профиль, как этот пример, покажет статус проверки «Не подписан»; это ожидаемо для профиля, собранного вручную, и само по себе не признак вмешательства, но для чего-либо серьёзнее личного тестирования профиль стоит подписать, чтобы его целостность можно было проверить.

Проверка, что всё сработало

Не полагайтесь только на панель настроек — проверьте через терминал.

Терминал
# Show the resolvers macOS is actually configured to use
scutil --dns
# Look for your interface's resolver entry — it should now show
# the DoH/DoT server address you configured, not your router or ISP's resolver

# Confirm a lookup succeeds and see which resolver answered
dig example.com

# Cloudflare's own diagnostic page also reports whether your
# connection is using encrypted DNS when you open it in a browser
open https://1.1.1.1/help

Если scutil --dns всё ещё показывает адрес вашего роутера или резолвер вашего интернет-провайдера как активный DNS-сервер, профиль не вступил в силу — проверьте, что вы установили его в разделе «Профили», а не просто скачали, и что никакая другая сетевая настройка (см. ниже) его не перекрывает.

Подводные камни, из-за которых всё перестаёт работать незаметно

  • VPN-приложение очень часто переопределяет системные настройки DNS, пока оно подключено, направляя запросы через собственный резолвер, — проверяйте конфигурацию DNS ещё раз после подключения к VPN, а не только до.
  • Портал авторизации в Wi-Fi-сетях отелей, аэропортов и кофеен обычно не может завершить процесс входа через зашифрованный DNS, поскольку полагается на перехват обычного DNS-запроса, чтобы перенаправить вас на страницу входа; чтобы выйти в сеть, может потребоваться временно удалить или отключить профиль, а после подключения установить его снова.
  • Некоторые браузеры — среди них Firefox и Chrome — имеют собственную, отдельную настройку DoH, которая может переопределять или дублировать конфигурацию на уровне системы; проверьте сетевые настройки самого браузера, если его поведение не совпадает с тем, что показывает scutil --dns.
  • iCloud Private Relay и зашифрованный DNS решают разные, частично пересекающиеся задачи — Private Relay скрывает ваш IP-адрес от сайтов, которые вы посещаете в Safari, а зашифрованный DNS скрывает от вашей сети то, какие домены вы разрешаете; использование одного не делает другое избыточным.

Какое место здесь занимают FireAI и HisnLabs

FireAI does not provide encrypted DNS today — it is on the roadmap, not in the current release — so a configuration profile like the one above is what actually closes the DNS-leak gap; FireAI’s job is different, watching and controlling which apps get to make a connection at all once that lookup resolves.

FireAI — это собственный продукт HisnLabs: ИИ-файрвол, работающий прямо на вашем Mac. Он показывает простым языком каждое соединение, которое устанавливают ваши приложения, и позволяет вам решать, что покидает ваш Mac, — его ИИ работает локально, поэтому ваш трафик никогда не отправляется ни нам, ни кому-либо ещё. Команда исследователей безопасности HisnLabs — это те, кто поддерживает точность этих решений: они каталогизируют, какие домены являются обычной телеметрией, а какие — реальным сервисом, отслеживают страну и сеть, стоящие за соединением, и обучают локальную модель (функцию Autopilot) на реальных шаблонах трафика — и ничего из этого не покидает ваш Mac.

Вы можете прочитать о технических решениях, лежащих в его основе, или попробовать FireAI в течение 17 дней на странице FireAI от HisnLabs.

Источники