Мінімізація ризиків використання DoH та DoT
Захист від DoH та DoT
Чи контролюєте ви свій DNS трафік? Організації вкладають багато часу, грошей та зусиль у забезпечення безпеки своїх мереж. Однак однією з областей, якій часто не приділяється належної уваги, є DNS.
Хорошим оглядом ризиків, які приносить DNS є на конференції InfoSecurity.
31% обстежених класів програм-вимагачів використовували DNS для обміну ключами.
31% обстежених класів програм-вимагачів використовували DNS для обміну ключами.
Проблема серйозна. За даними дослідницької лабораторії Palo Alto Networks Unit 42, приблизно 85% шкідливих програм використовують DNS для встановлення каналу управління та контролю, дозволяючи зловмисникам легко впроваджувати шкідливі програми у вашу мережу, а також викрадати дані. З моменту створення трафік DNS в основному був незашифрованим і його легко можна було аналізувати захисними механізмами NGFW.
З'явилися нові протоколи DNS, спрямовані на підвищення конфіденційності з'єднань DNS. Вони активно підтримуються провідними постачальниками браузерів та іншими постачальниками програмного забезпечення. Незабаром у корпоративних мережах розпочнеться зростання зашифрованого DNS-трафіку. Зашифрований трафік DNS, який не аналізується засобами належним чином і дозволено, становить загрозу безпеці для компанії. Наприклад, такою загрозою є криптолокери, які використовують DNS для обміну ключами шифрування. Атакуючі зараз вимагають викуп у кілька мільйонів доларів за відновлення доступу до ваших даних. У компанії Garmin, наприклад, заплатили 10 мільйонів доларів.
При правильному налаштуванні NGFW можуть забороняти або захищати використання DNS-over-TLS (DoT) і можуть використовуватися для заборони використання DNS-over-HTTPS (DoH), що дозволяє аналізувати весь трафік DNS у вашій мережі.
Що таке шифрований DNS?
Що таке DNS
Система доменних імен (DNS) перетворює зручні для читання людині доменні імена (наприклад, адреса ) в IP-адреси (наприклад, 34.107.151.202). Коли користувач вводить доменне ім'я у веб-браузері, браузер відправляє DNS-запит на DNS-сервер, запитуючи IP-адресу, пов'язану з цим доменним ім'ям. У відповідь DNS-сервер повертає IP-адресу, яка використовуватиме цей браузер.
Запити та відповіді DNS пересилаються через мережу у вигляді звичайного тексту в незашифрованому вигляді, що робить його вразливим для шпигунства або зміни відповіді та перенаправлення браузера на шкідливі сервери. Шифрування DNS ускладнює відстеження запитів DNS або їх зміна під час передачі. Шифрування запитів і відповідей DNS захищає вас від атаки Man-in-the-Middle, виконуючи при цьому ті ж функції, що і традиційний протокол DNS (система доменних імен) з відкритим текстом.
За останні кілька років було впроваджено два протоколи шифрування DNS:
-
DNS-over-HTTPS (DoH)
-
DNS-over-TLS (DoT)
Ці протоколи мають одну спільну рису: навмисно ховають DNS-запити від будь-якого перехоплення... і безпечників організації у тому числі. Протоколи в основному використовують протокол TLS (Transport Layer Security) для встановлення зашифрованого з'єднання між клієнтом, що виконує запити, та сервером, що дозволяє запити DNS, через порт, який зазвичай не використовується для трафіку DNS.
Конфіденційність запитів DNS є величезним плюсом цих протоколів. Однак, вони створюють проблеми безпечним, які повинні стежити за мережевим трафіком і виявляти і блокувати шкідливі з'єднання. Оскільки протоколи розрізняються за своєю реалізацією, методи аналізу відрізнятимуться у DoH і DoT.
DNS через HTTPS (DoH)
DNS всередині HTTPS
DoH використовує добре відомий порт 443 для HTTPS, для якого RFC спеціально вказано, що завдання полягає в тому, щоб «змішати трафік DoH з іншим трафіком HTTPS в одному і тому ж з'єднанні», «утруднити аналіз трафіку DNS» і, таким чином, обійти заходи корпоративного контролю ( ). Протокол DoH використовує шифрування TLS та синтаксис запитів, що надається загальними стандартами HTTPS та HTTP/2, додаючи запити та відповіді DNS поверх стандартних запитів HTTP.
Ризики, пов'язані з DoH
Якщо ви не можете відрізнити звичайний HTTPS-трафік від запитів DoH, то програми всередині вашої організації можуть (і будуть) обходити локальні налаштування DNS, перенаправляючи запити на сторонні сервери, що відповідають на запити DoH, що обходить будь-який моніторинг, тобто знищує можливість контролю за DNS трафік. В ідеалі ви повинні контролювати DoH, використовуючи функції розшифрування HTTPS.
И в останній версії своїх браузерів і обидві компанії працюють над використанням DoH за замовчуванням для всіх запитів DNS. з інтеграції DoH у свої операційні системи. Мінусом є те, що не лише шановні компанії-розробники програмного забезпечення, а й зловмисники почали використовувати DoH як засіб обходу традиційних заходів корпоративного міжмережевого екрану. ( Наприклад, перегляньте наступні статті: , и .) У будь-якому випадку, як хороший, так і шкідливий трафік DoH залишиться непоміченим, залишивши організацію сліпий до зловмисного використання DoH як канал для управління шкідливим ПЗ (C2) та крадіжки конфіденційних даних.
Забезпечення видимості та контролю трафіку DoH
Як найкраще рішення для контролю DoH ми рекомендуємо налаштувати в NGFW розшифровку трафіку HTTPS та блокування трафіку DoH (назва програми: dns-over-https).
По-перше, переконайтеся, що NGFW налаштований для розшифровки HTTPS, згідно .
По-друге, створіть правило для трафіку програми «dns-over-https», як показано нижче:
Правило Palo Alto Networks NGFW для блокування DNS-over-HTTPS
Як проміжна альтернатива (якщо ваша організація не повністю реалізувала розшифрування HTTPS) NGFW можна налаштувати для застосування дії «заборонити» до ідентифікатора програми «dns-over-https», але ефект буде обмежений блокуванням певних добре відомих серверів DoH по їхньому доменному імені, так як без розшифрування HTTPS трафік DoH може бути повністю перевірений (див. і виконайте пошук за фразою "dns-over-https").
DNS через TLS (DoT)
DNS всередині TLS
У той час як протокол DoH прагне змішуватися з іншим трафіком на тому ж порту, DoT натомість за замовчуванням використовує спеціальний порт, зарезервований для цієї єдиної мети, навіть спеціально забороняючи використання того ж порту для традиційного незашифрованого трафіку DNS ( ).
Протокол DoT використовує протокол TLS для забезпечення шифрування, що інкапсулює стандартні запити протоколу DNS, з трафіком, що використовує добре відомий порт 853 ( ). Протокол DoT був розроблений, щоб спростити організаціям блокувати трафік портом, або погоджуватися на його використання, але включити розшифровку на цьому порту.
Ризики, пов'язані з DoT
Google реалізував DoT у своєму клієнті , при цьому за замовчуванням увімкнено налаштування автоматичного використання DoT, якщо він доступний. Якщо ви оцінили ризики та готові до використання DoT на рівні організації, то потрібно, щоб мережеві адміністратори явно дозволяли вихідний трафік на порт 853 через свій периметр цього нового протоколу.
Забезпечення видимості та контролю трафіку DoT
Як найкраща методика контролю за DoT ми рекомендуємо будь-яке з вищепереліченого, виходячи з вимог вашої організації:
-
Налаштуйте NGFW для розшифрування всього трафіку для порту призначення 853. Завдяки розшифруванню трафіку DoT буде відображатися як програма DNS, до якої ви можете застосувати будь-яку дію, наприклад, увімкнути передплату для контролю DGA доменів або вже наявний та anti-spyware.
-
В якості альтернативи можна повністю заблокувати движком App-ID трафік 'dns-over-tls' через порт 853. Зазвичай він заблокований за замовчуванням, жодних дій не потрібно (якщо ви спеціально не дозволили програму 'dns-over-tls' або трафік через порт 853).
Джерело: habr.com