Комментарии 21
Копирайтеры, нагоняющие волну — они такие копирайтеры!
Вообще, угроза не в DNS, совсем не в нем. В TLS или HTTPS, в которые «обернут» DNS в этом случае — да, но не в DNS.
Я вот, в свою очередь, не понимаю двух вещей: как любое решение для безопасности собирается просматривать шифрованный трафик в принципе, и, что важнее, что оно будет с ним делать, даже если расшифрует.
Второй вопрос совсем не праздный: не так давно еще было вполне привычно гнать весь контрский трафик веб-сайтов через прокси, и на прокси можно было (https было куда менее распространен!) спокойно анализировать всё и вся. И что, разве кто-то умел тогда, имея почти весь трафик открытым, как-то бороться с локерами или воровством кредиток? Да, можно регэкспом ловить все цепочки символов, напоминающие номер кредитки, но это, мы понимаем, тупо, и обходится на раз отправкой номеров, например, в архиве.
На этом фоне вопрос про расшировку трафика как бы не существенен. Из статьи единственное, что более-менее разумно — это что трафик DoT можно зарезать по номеру порта. Остальное, в т.ч. перехват и расшифровка шифрованного трафика (да это же MITM!) требует сурового нагиба всей идеи шифрования («свои» сертификаты, и т.д.) — и не все браузеры, например, на такое поведутся…
криптолокеры, которые используют DNS для обмена ключами шифрования
Вообще, угроза не в DNS, совсем не в нем. В TLS или HTTPS, в которые «обернут» DNS в этом случае — да, но не в DNS.
Я вот, в свою очередь, не понимаю двух вещей: как любое решение для безопасности собирается просматривать шифрованный трафик в принципе, и, что важнее, что оно будет с ним делать, даже если расшифрует.
Второй вопрос совсем не праздный: не так давно еще было вполне привычно гнать весь контрский трафик веб-сайтов через прокси, и на прокси можно было (https было куда менее распространен!) спокойно анализировать всё и вся. И что, разве кто-то умел тогда, имея почти весь трафик открытым, как-то бороться с локерами или воровством кредиток? Да, можно регэкспом ловить все цепочки символов, напоминающие номер кредитки, но это, мы понимаем, тупо, и обходится на раз отправкой номеров, например, в архиве.
На этом фоне вопрос про расшировку трафика как бы не существенен. Из статьи единственное, что более-менее разумно — это что трафик DoT можно зарезать по номеру порта. Остальное, в т.ч. перехват и расшифровка шифрованного трафика (да это же MITM!) требует сурового нагиба всей идеи шифрования («свои» сертификаты, и т.д.) — и не все браузеры, например, на такое поведутся…
Вообще, угроза не в DNS, совсем не в нем.
Прочитайте вот эту презентацию компании Verisign. Там есть слайд, который говорит, что 7 (31%) из 23 исследованных ransomware использовали DNS для обмена ключами.
www.infosecurityeurope.com/__novadocuments/484127
Я вот, в свою очередь, не понимаю двух вещей: как любое решение для безопасности собирается просматривать шифрованный трафик в принципе, и, что важнее, что оно будет с ним делать, даже если расшифрует.
Речь про NGFW. В NGFW после того как трафик TLS расшифрован начинают работать другие движки, и в случае с DNS это DNS Sinkholing, Machine Learning для детекта DGA доменов, Threat Intelligence и др.
не так давно еще было вполне привычно гнать весь контрский трафик веб-сайтов через прокси
Логично, что DNS трафик никак не защищают через HTTP прокси… также как и многих других приложений, который приходится пускать в обход покси.
На этом фоне вопрос про расшировку трафика как бы не существенен.
А как тогда вы будете контролировать DoH и DoT без расшифрования TLS?
Я вообще говорю о том, что «расшифровывание шифрования» — это отличная глубокая тема, но шифрование бывает разное, и что факт, что ботнеты будут друг другу слать команды не через DoT, а через обычный нешифрованный ДНС, не убережет большую часть юзеров в первые минуты и часы — а там, если автор ботнета не дурак, он придумает и запасные методы связи. Тем о
Но вот, например, я вам дарю некую волшебную палочку (скорее, волшебное стеклышко из сказки), которая показывает вам расшированным любой обмен по сети. И дальше что, все равно же логика «пустим людей ходить всюду, и динамически отсечен опасное» так и остается сказкой. Все равно вся безопасность строится на запрете всего, чего не нужно для работы, что ок для компаний, но не очень для домашних пользователей (которым страш-ш-шно интересно запустить вот тот откровенно стремный файл!). Получается, палочка особо не помогает — не нужно знать содержимое, надо «не пущать, куда не нужно!»
А если отсекать ненужное, то о какой DoH и DoT Вы говорите — просто зарежте обращения ко внешним ДНС полностью, оставьте доступ только к доверенному подконтрольному серверу, а на том релвите только белый список доменов (добавить в него еще одну зону — по служебке).
Как-то так. Сам очень не люблю попытки организовать конторский (или национальный) catch-all сертификат «просто чтобы все чувствовали себя в безопасности», но вся риторика «вы нам дайте взглянуть, мы тут же безопасность организуем» к тому и идет, к сожалению.
Но вот, например, я вам дарю некую волшебную палочку (скорее, волшебное стеклышко из сказки), которая показывает вам расшированным любой обмен по сети. И дальше что, все равно же логика «пустим людей ходить всюду, и динамически отсечен опасное» так и остается сказкой. Все равно вся безопасность строится на запрете всего, чего не нужно для работы, что ок для компаний, но не очень для домашних пользователей (которым страш-ш-шно интересно запустить вот тот откровенно стремный файл!). Получается, палочка особо не помогает — не нужно знать содержимое, надо «не пущать, куда не нужно!»
А если отсекать ненужное, то о какой DoH и DoT Вы говорите — просто зарежте обращения ко внешним ДНС полностью, оставьте доступ только к доверенному подконтрольному серверу, а на том релвите только белый список доменов (добавить в него еще одну зону — по служебке).
Как-то так. Сам очень не люблю попытки организовать конторский (или национальный) catch-all сертификат «просто чтобы все чувствовали себя в безопасности», но вся риторика «вы нам дайте взглянуть, мы тут же безопасность организуем» к тому и идет, к сожалению.
Ну и что этот doh и Dot даёт? Для паникёров?
Даже в обычном DNS трафике нужно блокировать подключения к центрам управления бот-сетями и также туннели внутри DNS, типа TCP-over-DNS. Для понимания как очищается обычный DNS трафик в сети, видеоролик про DNS Sinkholing
НЛО прилетело и опубликовало эту надпись здесь
В статье про это и написано ;-) Что для контроля DoH и DoT нужно включать расшифрование TLS. Функция SSL Decrypt предполагает подмену сертификата (MITM)
Без MITM никуда. Фактически сейчас, без подмены сертифткатов, ngfw слабо полезен.
К сожалению 50% TLS трафика уже используют ssl pinning и проверку клиентских сертификатов, поэтому расшифровать этот трафик невозможно: обновления, мессенджеры, клиенты на телефонах и др. Поэтому контроль уже переходит на хосты, там активно развивается тема продуктов класса XDR
К сожалению ?! отлично же, в идеале нужно запретить на iOS/Android устанавливать рутовые сертификаты. и MDM сертификаты применять только к доменам входящим в организацию.
смотря с какой позиции вы смотрите: хакера или безопасника.
Рутовые сертификаты на устройстве нужны и для локального MitM с целью блокировки рекламы, например.
А почему нельзя поднять свой собственный DoH-сервер рядом с рекурсивным ресолвером и юзать его?
Мне интересно, а почему рэнсомварщики не используют свои методы шифрования на нестандартных портах? Или почему они не могут запустить сервер DoT на порту 8853 например? Только потому, что такой трафик совсем запрещён в корпоративных сетках?
Ну тогда делать C&C-сервер на дешёвых VPS-ках и на 22-ом порту. Он довольно редко блокируется :-D
Ну тогда делать C&C-сервер на дешёвых VPS-ках и на 22-ом порту. Он довольно редко блокируется :-D
Для этого и существуют исследовательские лаборатории в крупных компаниях — они изучают как работает ransomware и пишут против него защиту. Для неизвестного вредоносного кода нужны более сложные технологии и они тоже есть: специальные ловушки для техник атак, machine learning.
Если взять две точки контроля: сеть и хосты, то есть такая методика написания правил: zero trust, — когда ты разрешаешь каждому сотруднику ровно те приложения, что ему нужны по работе: DNS или DoH, RDP или SSH, если браузер, то только к необходимым категориям URL, если это Word, то ему уж непонятно зачем разрешать скачивать exe файлы. Но хакеры делают туннели внутри разрешенных приложений (или портов если межсетевой экран понимает только порты) и точно также есть методика обнаружения туннелей внутри DNS, SSH, SSL/TLS и тд… Есть методика проверки файлов и блокировки файлов по типам, по сигнатурам вирусов, по regex и тд… вариантов атак много, также как и вариантов защиты. zero trust разрешает ровно то что нужно и запрещает все остальное и все туннели и др ненужная шелуха в сети чистится.
Если взять две точки контроля: сеть и хосты, то есть такая методика написания правил: zero trust, — когда ты разрешаешь каждому сотруднику ровно те приложения, что ему нужны по работе: DNS или DoH, RDP или SSH, если браузер, то только к необходимым категориям URL, если это Word, то ему уж непонятно зачем разрешать скачивать exe файлы. Но хакеры делают туннели внутри разрешенных приложений (или портов если межсетевой экран понимает только порты) и точно также есть методика обнаружения туннелей внутри DNS, SSH, SSL/TLS и тд… Есть методика проверки файлов и блокировки файлов по типам, по сигнатурам вирусов, по regex и тд… вариантов атак много, также как и вариантов защиты. zero trust разрешает ровно то что нужно и запрещает все остальное и все туннели и др ненужная шелуха в сети чистится.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Минимизация рисков использования DNS-over-TLS (DoT) и DNS-over-HTTPS (DoH)