Comments 5
А вот интересно. DNS все же редко используется в качестве универсальной базы данных. По большей части, есть стандартные запросы и стандартные ответы.
Чем весь этот сложный мониторинг городить, обрекая себя на вечное соревнование с атакующими в изобретательности, не проще ли сделать кеширующую DNS-прокси, которая отдает стандартный набор информации на стандартные запросы и просто не пропускает лишнего?
Идея, конечно, хорошая – одним действием решить все проблемы с DNS. Но тут есть два момента.
Во-первых, не всегда есть возможность влиять на защищаемую инфраструктуру. И статья в целом про обнаружение DNS-туннелей средством, не влияющим на сеть.
Во-вторых, не совсем понятно, как установка DNS-прокси позволит заблокировать канал утечки.
DNS работает с поддоменами, используя иерархическую структуру доменных имен. Даже если DNS-сервер знает IP-адрес для одного поддомена (например, first-request.pirates.com), это не означает, что он автоматически знает IP-адрес для другого поддомена (например, second-request.pirates.com). Каждый поддомен может иметь свой собственный IP-адрес и соответствующие DNS-записи.
Соответственно, если DNS-прокси не знает IP-адрес для нового домена (а он его не знает, потому что поддомен-то сгенерированный), то он сам пойдёт на внешний DNS за такой информацией – по сути, прокинет через себя туннель, доставив информацию получателю. Поэтому выглядит так, будто DNS-прокси не решит эту проблему.
Может быть, идея была в чём-то другом?
Идея, конечно, хорошая – одним действием решить все проблемы с DNS
Никто, разумеется, не предлагает одним выстрелом убить всех зайцев и нескольких охотников заодно. Ценность мониторинга тоже, разумеется, никто не оспаривает.
И статья в целом про обнаружение DNS-туннелей средством, не влияющим на сеть.
Статья в целом про то, как в массиве данных найти вредоносный паттерн. Чтобы собрать этот массив из реальной сети, в нее все равно придется включиться. Это сравнимо по степени интрузивности с заменой одного DNS-сервера (того, который уже сейчас есть, вряд ли там 8.8.8.8) на другой.
то он сам пойдёт на внешний DNS за такой информацией – по сути, прокинет через себя туннель, доставив информацию получателю.
Он очень сильно сузит этот побочный канал. К примеру, полностью отшибет канал, основанный на порядке и времени отправки запросов. Не позволит включать в запросы лишние параметры и вычистит лишние данные из ответов. Приведет к стандартному виду служебные биты, избавив их от скрытой информации. Сделает невозможным запрашивать "странные" типы записей и "странные" домены пятого уровня.
Кроме того, можно было бы ограничить запросы со "странными" метками в доменных именах (например, "H23xl43"), напоминающими сгенерированные. Вот здесь, как раз, можно было бы натренировать ИИ отличать их от нормальных. Это трудно формализовать, но человеку сразу видно, какое имя "нормальное", а какое "странное" - а на таких задачах ИИ как раз неплох. Редкие false positive срабатывания тут не очень важны, всегда можно поднапрячь админа добавить запись в список исключений.
Фактически, останется возможность манипулировать именами запрашиваемых записей и адресами/именами в ответах.
Само по себе такое сужение канала может сделать его малопригодным для конструирования сколь-либо значимой утечки.
И достоинством данного метода является то, что он понятен и поддается анализу, его эффективность можно оценить. В отличии от основанного на ИИ пассивного мониторинга, про который никогда не скажешь, он ничего не нашел потому, что ничего и не было или потому, что плохо искал.
И наконец, такая защищающая DNS-прокси - хорошее место для сбора данных с целью мониторинга, полезность которого я не отрицаю, но все-таки полагаться на него, как на основной метод защиты я бы поостерегся.
Добрый день.
А как решается проблема с туннелями при использовании dnssec? Вроде как все шифрованное...
P.S. Писал диплом по таким туннелям, лет 10 назад:) украсть данные удалось, а вот сигнатуры на IPS пришлось "подгонять")))
Добрый день!
DNSSEC (Domain Name System Security Extensions) добавляет к DNS-запросам цифровые подписи для проверки целостности и подлинности данных, но не шифрует сами поля DNS. Это означает, что содержимое запросов и ответов остаётся видимым, и модели, описанные в статье, будут работать с теми же данными, что и при обычном DNS.
Так как злоумышленники контролируют домен или поддомен, DNSSEC не сможет предотвратить туннелирование через этот домен, так как подписанные данные всё равно будут считаться подлинными. DNSSEC лишь подтверждает, что они не были изменены при передаче.
Обнаружение DNS туннелей