Блог з безпеки 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. Під час сеансу було запропоновано два способи ввімкнути його: NEDNSSettingsManager API для додатків, щоб налаштувати його програмним шляхом, і — варіант, який насправді використовує більшість людей — профіль конфігурації, що містить корисне навантаження com.apple.dnsSettings.managed, задокументований у довідці Apple щодо керування пристроями, який дозволяє вказати адресу DoH або DoT-розв’язувача та дозволити кожній програмі в системі використовувати його за замовчуванням, без стороннього програмного забезпечення.

Зразок профілю конфігурації

Профіль конфігурації — це список властивостей XML (файл .mobileconfig), який macOS може інсталювати за допомогою параметрів системи, якщо ви двічі клацнете його або перетягнете на панель «Профілі». Наведений нижче приклад вказує Mac на загальнодоступний розпізнавач DNS-over-HTTPS 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, згідно з опублікованою документацією DoT Cloudflare.

Встановлення

  1. Збережіть файл із розширенням .mobileconfig і двічі клацніть його або відкрийте «Параметри системи», перейдіть до «Конфіденційність і безпека», потім «Профілі» та перетягніть файл.
  2. macOS покаже вміст корисного навантаження — включно з налаштованим вами резолвером — до того, як ви його схвалите; переглядайте це кожного разу, оскільки профіль — це саме те, як зловмисник може перенаправити ваш 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.

Джерела