Dns over tcp что это
Что такое DNS-туннелирование? Инструкция по обнаружению
Как работает DNS-туннелирование
Для всего в интернете есть свой отдельный протокол. И DNS поддерживает относительно простой протокол типа запрос-ответ. Если вы хотите посмотреть, как он работает, то можете запустить nslookup – основной инструмент для подачи DNS-запросов. Вы можете запросить адрес, просто указав интересующее доменное имя, например:
В нашем случае протокол ответил IP-адресом домена. В терминах DNS-протокола, я сделал запрос адреса или запрос т.н. «А»-типа. Существуют и другие типы запросов, при этом DNS-протокол будет отвечать с различным набором полей данных, которыми, как мы это позже увидим, могут воспользоваться хакеры.
Так или иначе, по своей сути DNS-протокол занимается передачей запроса на сервер и его ответа обратно клиенту. А что, если злоумышленник добавит скрытое сообщение внутрь запроса доменного имени? Например, вместо ввода вполне легитимного URL, он введёт данные, которые хочет передать:
Предположим, злоумышленник управляет DNS-сервером. Тогда он может передавать данные — например, персональные данные, — и не обязательно будет обнаружен. В конце концов, с чего вдруг DNS-запрос может стать чем-то нелегитимным?
Управляя сервером, хакеры могут подделывать ответы и отправлять данные обратно на целевую систему. Это позволяет им передавать сообщения, спрятанные в различных полях DNS-ответа, во вредоносное ПО на заражённой машине, с указаниями наподобие поиска внутри определённой папки.
«Туннелирующая» часть данной атаки заключается в сокрытии данных и команд от обнаружения системами мониторинга. Хакеры могут использовать наборы символов base32, base64 и т.д., или даже шифровать данные. Такая кодировка пройдёт незамеченной мимо простых утилит обнаружения угроз, которые осуществляют поиск по открытому тексту.
И это и есть DNS-туннелирование!
История атак через DNS-туннелирование
У всего есть начало, включая идею захвата DNS-протокола для хакерских целей. Насколько мы можем судить, первое обсуждение такой атаки проводилось Оскаром Пирсаном (Oskar Pearson) в почтовой рассылке Bugtraq в апреле 1998 года.
К 2004 году, DNS-туннелирование было представлено на Black Hat как хакерский метод в презентации Дэна Каминского (Dan Kaminsky). Таким образом, идея очень быстро переросла в настоящий инструмент атаки.
На сегодня DNS-туннелирование занимает уверенные позиции на карте потенциальных угроз (и блогеров в сфере информационной безопасности часто просят его объяснить).
Угрозы DNS-туннелирования
DNS-туннелирование – это как индикатор начала стадии плохих новостей. Каких именно? Мы уже рассказали о нескольких, но давайте их структурируем:
Выявление DNS-туннелирования
Существует два основных метода обнаружения злоупотреблением DNS: анализ нагрузки и анализ трафика.
При анализе нагрузки защищающаяся сторона ищет аномалии в данных, передаваемых в обе стороны, которые могут быть обнаружены статистическими методами: странно выглядящие имена хостов, тип DNS записи, которая не используется настолько часто, или нестандартная кодировка.
При анализе трафика оценивается число DNS запросов к каждому домену по сравнению со среднестатистическим уровнем. Злоумышленники, использующие DNS-туннелирование, будут генерировать большой объём трафика на сервер. В теории, значительно превосходящий нормальный обмен DNS-сообщениями. И это необходимо отслеживать!
Утилиты DNS-туннелирования
Если вы хотите провести собственный пентест и проверить, насколько хорошо ваша компания сможет обнаружить и отреагировать на такую активность, то для этого есть несколько утилит. Все они умеют туннелировать в режиме IP-Over-DNS:
Утилиты DNS-мониторинга
Ниже представлен список нескольких утилит, который будет полезен для обнаружения туннелирующих атак:
Микро FAQ по DNS-туннелированию
Полезнейшая информация в виде вопросов и ответов!
В: Что такое туннелирование?
О: Это просто способ передачи данных поверх существующего протокола. Лежащий в основе протокол обеспечивает выделенный канал или туннель, который потом используется для сокрытия информации, передающейся в действительности.
В: Когда был осуществлена первая атака по DNS-туннелированию?
О: Мы не знаем! Если вы знаете – дайте, пожалуйста, нам знать. Насколько нам известно, первое обсуждение атаки было инициировано Оскаром Пирсаном в почтовой рассылке Bugtraq в апреле 1998 года.
В: Какие атаки похожи на DNS-туннелирование?
О: DNS – далеко не единственный протокол, который можно использовать для туннелирования. Например, вредоносные программы по управлению и контролю (C2) часто используют HTTP для маскировки канала взаимодействия. Как и при DNS-туннелировании, хакер скрывает свои данные, но в данном случае они выглядят как трафик обычного веб-браузера, обращающегося на удалённый сайт (контролируемый злоумышленником). Это может остаться незамеченным программами мониторинга, если они не настроены воспринимать угрозу злоупотребления HTTP-протоколом в хакерских целях.
Хотите, чтобы мы помогли с обнаружением DNS-туннелирования? Ознакомьтесь с нашим модулем Varonis Edge и попробуйте бесплатное демо!
Google Public DNS тихо включили поддержку DNS over TLS
Внезапно, без предварительного анонса, на 8.8.8.8 заработал DNS over TLS. Ранее Google анонсировал только поддержку DNS over HTTPS.
Публичный резолвер от компании CloudFlare с IP-адресом 1.1.1.1 поддерживает DNS over TLS с момента запуска проекта.
Зачем это нужно
При использовании классической схемы DNS, провайдеры могут лезть своими грязными лапами в ваши DNS-пакеты, просматривать, какие домены вы запрашиваете, и подменять ответы как угодно. Этим же занимаются мошенники, подменяя резолверы на взломанных роутерах, чтобы направить пользователя на поддельный сервер.
C DNS over TLS/HTTPS запросы посылаются внутри зашифрованного тоннеля так, что провайдер не может подменить или просмотреть запрос.
А с приходом шифрования имени домена в сертификатах X.509 (ESNI) станут невозможны блокировки через DPI по SNI (Server Name Indication, специальное поле, в котором передается имя домена в первом TLS-пакете), которые сейчас применяются у некоторых крупных провайдеров.
Как это работает
На порт TCP:853 выполняется TLS-подключение, при этом проверка сертификата резолвера происходит с использованием системных корневых сертификатов, точно так же, как HTTPS в браузере. Это избавляет от необходимости добавлять какие-либо ключи вручную. Внутри тоннеля выполняется обычный DNS-запрос. Это создает меньше накладных расходов по сравнению с DNS over HTTPS, который добавляет HTTP-заголовки к запросу и ответу.
К сожалению, на текущий момент только в Android 9 (Pie) поддержка DNS over TLS встроена в системный резолвер. Инструкция по настройке для Android 9.
Для остальных систем предлагается использовать сторонний демон, а системный резолвер направлять на localhost (127.0.0.1).
Настройка на macOS
Установка
По умолчанию knot будет работать как обычный рекурсивный резолвер, подобно dnsmasq.
Редактируем конфиг
И добавляем в конец файла:
В итоге мой конфиг выглядит так:
Параметр hostname в данном случае — Common Name (CN) или Subject Alt Name (SAN) сертификата. То есть, доменное имя, для которого выпущен сертификат. По нему проверяется подлинность сертификата сервера.
Вот какие значения SAN у сертификата, который используется при подключении на 8.8.8.8:853
Любое из этих значений можно использовать в качестве параметра hostname. Если же вы будете разворачивать собственный публичный рекурсивный резолвер, у вас вряд ли получится выпустить X.509-сертификат на IP-адрес, поэтому в параметре hostname придется указывать доменное имя.
Запуск демона
Проверить, успешно ли запустился демон, можно командой:
процесс kresd должен слушать порт 53 на localhost.
Если что-то пошло не так, смотрим лог ошибок:
Проверка работы резолвера
Проверяем, что локальный резолвер отвечает корректно.
Установка в качестве системного резолвера
Если все работает правильно, можно назначить системный резолвер в свойствах сетевого адаптера:
В чем разница между DNSCrypt, DNSSEC, DNS over TLS/HTTPS.
DNSCrypt может работать по UDP и TCP. Подключение на порт 443. Для шифрования используется собственный протокол, который отличается от HTTPS. Может быть легко выделен с помощью DPI. Это скорее черновик, который тестировали до внедрения DNS over TLS/HTTPS, так как он не имеет RFC, то есть не является официальным стандартом интернета. Вероятнее всего, в скором, времени он будет полностью вытеснен последними.
DNS over TLS (DoT) — TCP-подключение происходит на порт 853, внутри тоннеля передается обычный DNS-запрос. Провайдер видит, что это DNS запрос но не может в него вмешаться. При прочих равных, в DNS over TLS должно быть чуть меньше накладных расходов на каждый запрос, чем в over HTTPS.
DNS over HTTP (DoH) — TCP-подключение на порт 443, подобно обычному HTTPS. Внутри другой формат запроса, с HTTP-заголовками. Однако для провайдера такой запрос будет виден как обычное HTTPS-подключение. Полагаю, этот протокол был придуман на случай, когда DNS-запросы к чужим серверам будут заблокированы, чтобы маскировать под обычный веб трафик. А также, чтобы браузеры могли сами резолвить домены и не создавать при этом аномальный трафик.
По сути, DNS over HTTPS и over TLS — одно и то же, с немного отличающемся форматом запросов. Оба эти протокола приняты в качестве стандартов и имеют RFC. Вероятнее всего, в ближайшее время мы увидим массовое распространение их обоих.
DNSSEC — протокол цифровой подписи DNS-записей. Не имеет отношения к шифрованию, так как все запросы передаются в открытом виде. Может работать как по старому классическому протоколу DNS, то есть UDP/TCP на порту 53, так и внутри DNS over TLS/HTTPS. Целью DNSSEC является подтверждение подлинности DNS-записи. Владелец домена может добавить публичный ключ на корневые сервера своей доменной зоны и подписывать все записи на мастер NS-серверах. По сути, к каждой DNS записи, например, A-записи или MX-записи, добавляется еще одна запись типа RRSIG, содержащая подпись. Процедура валидации DNSSEC на рекурсивном резолвере позволяет установить, действительно эта запись была создана владельцем домена.
DNS over TLS — Шифруем наши DNS запросы с помощью Stunnel и Lua
DNS (англ. Domain Name System — система доменных имён) — компьютерная распределённая система для получения информации о доменах.
TLS (англ. transport layer security — Протокол защиты транспортного уровня) — обеспечивает защищённую передачу данных между Интернет узлами.
После новости «Google Public DNS тихо включили поддержку DNS over TLS» я решил попробовать его. У меня есть Stunnel который создаст шифрованный TCP туннель. Но программы обычно общаются с DNS по UDP протоколу. Поэтому нам нужен прокси который будет пересылать UDP пакеты в TCP поток и обратно. Мы напишем его на Lua.
Вся разница между TCP и UDP DNS пакетами:
4.2.2. TCP usage
Messages sent over TCP connections use server port 53 (decimal). The message is prefixed with a two byte length field which gives the message length, excluding the two byte length field. This length field allows the low-level processing to assemble a complete message before beginning to parse it.
То есть делаем туда:
И в обратную сторону:
Настраиваем Stunnel
Пишем в stunnel.conf:
Работу тунеля можно проверить командой:
Опция ‘-vc’ заставляет nslookup использовать TCP соединение к DNS серверу вместо UDP.
Пишем скрипт
Я пишу на Lua 5.3. В нём уже доступны бинарные операции с числами. Ну и нам понадобится модуль Lua Socket.
Напишем простенькую функцию которая позволит отправить дамп пакета в консоль. Хочется видеть что делает прокси.
UDP в TCP и обратно
Пишем две функции которые будут оперировать двумя каналами передачи данных.
Обе функции сразу после запуска выполняют coroutine.yield(). Это позволяет первым вызовом передать параметры функции а дальше делать coroutine.resume(co) без дополнительных параметров.
А теперь main функция которая выполнит подготовку и запустит главный цикл.
Запускаем главную функцию. Если вдруг будет закрыто соединение мы через секунду установим его заново вызвав main.
проверяем
Запускаем наш скрипт
Проверяем работу скрипта командой
На этот раз без ‘-vc’ так так мы уже написали и запустили прокси который заворачивает UDP DNS запросы в TCP тунель.
Если всё нормально можно указать в настройках соедидения как DNS сервер «127.0.0.1»
заключение
Теперь наши DNS запросы под защитой TLS.
P.S. Не даём гуглу лишней информации о нас
Сразу после соединения Windows пытается зарегистрировать нас на DNS серверах гугла через наш туннель. Это отключается в продвинутых настройках DNS снятием галочки.
DNS или другие службы работают как на TCP, так и на UDP
В этой статье объясняется, почему некоторые службы используют протоколы TCP и UDP.
Применяется к: Windows Server 2003
Исходный номер КБ: 556000
СВОДКА
DNS и некоторые другие службы работают в обоих протоколах. Возьмем пример службы DNS. Два протокола отличаются друг от друга. TCP — это протокол, ориентированный на подключение, который требует, чтобы данные были последовательными в пункте назначения, а UDP — протоколом без подключения и не требовал последовательности данных или не требовало подключения к хосту для обеспечения согласованности данных.
Пакеты UDP меньше по размеру. Пакеты UDP не могут быть больше 512 bytes. Поэтому любому приложению необходимо, чтобы данные были переданы более 512 bytes, требуют TCP на месте. Например, DNS использует TCP и UDP по веские причины, описанные ниже. Сообщения UDP не больше 512 bytes и усечены, если больше этого размера. DNS использует TCP для передачи зоны и UDP для имени, а запросы регулярные (первичные) или обратные. UDP можно использовать для обмена небольшой информацией, в то время как TCP должен использоваться для обмена информацией размером более 512 bytes. Если клиент не получает ответа от DNS, он должен повторно перенапустить данные с помощью TCP через 3-5 секунд с интервалом.
В базе данных DNS Zone должна быть согласованность. Чтобы сделать это, DNS всегда передает данные зоны с помощью TCP, так как TCP является надежным и убедитесь, что данные зоны соответствуют, передав полную зону другим DNS-серверам, запрашивающим данные.
Проблема возникает, когда Windows 2000 серверов и продуктов Advanced Server использует динамические порты для всех выше 1023. В этом случае DNS-сервер не должен быть интернет-лицом, то есть делать все стандартные запросы для клиентских машин в сети. Маршрутизатор (ACL) должен разрешить всем входящий трафик UDP для доступа к любым высоким портам UDP, чтобы он работал.
LDAP всегда использует TCP — это верно и почему бы не UDP, так как между клиентом и сервером установлено безопасное подключение для отправки данных, и это можно сделать только с помощью TCP, а не UDP. UDP используется только при поиске контроллера домена (Kerberos) для проверки подлинности. Например, клиент домена находит контроллер домена с помощью DNS.
Community Отказ от контента решений
Корпорация Майкрософт и/или соответствующие поставщики не делают представлений о пригодности, надежности или точности сведений и связанных с ними графических данных, содержащихся в этой записи. Вся такая информация и связанная графика предоставляются «как есть» без какой-либо гарантии. Корпорация Майкрософт и/или соответствующие поставщики тем самым отключили все гарантии и условия в отношении этой информации и связанной графики, включая все подразумеваемые гарантии и условия торговой доступности, пригодность для определенной цели, рабочий труд, название и неущемление. Вы соглашаетесь, что ни в каких событиях корпорация Майкрософт и/или ее поставщики не несут ответственности за любые прямые, косвенные, штрафные, случайные, специальные, сопутствующие повреждения или любые повреждения, включая без ограничений убытки за потерю использования, данных или прибыли, возникающие из-за использования или невозможности использования сведений и связанных с ними графических элементов, содержащихся в этом деле, независимо от того, были ли они связаны с контрактом, тортом, халатностью, строгой ответственностью или иным образом, даже если корпорации Майкрософт или любому из ее поставщиков было рекомендовано о возможности ущерба.
Безопасность и защита DNS трафика
DNS traffic security and protection
Служба DNS или Domain Name System является базовым сервисом сети Интернет, а также иных сетей работающих на базе семейства протоколов TCP/IP, и используется для получение соответствия имени узла в сети соответствующему ему цифровому адресу.
Несмотря на столь простое описание DNS является, пожалуй, самой сложной по своей структуре и набору взаимодействий сетевой службой от надёжной работы которой зависит надёжная работа всех и вся.
Автор уже затрагивал вопросы функционирования DNS в цикле статей в разрезе наиболее современных и актуальных практических вопросов внедрения DNSSEC. Напомню, что DNSSEC обеспечивает удостоверение записей DNS при помощи цифровых подписей, чем защищает их от возможной подмены. Однако, при этом, все данные всегда передаются в открытом виде и никак не защищены от просмотра в процессе транзита и, при отсутствии цифровой подписи, при желании с лёгкостью могут быть модифицированы в тех или иных целях — от криминальных до цензурных.
Данная статья посвещена практическим способам защиты DNS трафика.
1. Прозрачность DNS трафика
Действительно, на момент своего создания более чем 30 лет назад вопрос защиты передаваемой через DNS информации. Поэтому несмотря на очевидность проблемы в силу исторических причин до сих пор все данные совершенно открыты в процессе транзита. Для примера можно взглянуть на них стандартными средствами операционной системы, к примеру, утилиты tcpdump.
Здесь прекрасно видны как запросы к удалённым серверам, так и их ответы.
Имея исключительно эти данные нетрудно получить полное представление о том, к каким именно ресурсам и с какой целью вы обращались. Также эти данные могут быть подменены при невозможности использования по тем или иным причинам DNSSEC, переадресовав вас, к примеру, на поддельный сайт или заблокировав доступ к определённой информации по цензурным соображениям.
Данная проблема DNS давно и широко известна интернет-сообществу. В качестве её решения было предложено к использованию два наиболее распространённых решения — DNScrypt и DNS-over-TLS, которые представляют собой инкапсуляцию DNS трафика в шифрованный канал.
2. DNScrypt
Протокол DNScrypt является первым реализованным решением для защиты DNS трафика от просмотра и намеренной модификации при транзите. По сути он представляет собой упрощённую версию TLS, где вместо цепочки доверенных сертификатов используется лишь один, который удостоверяет сервер к которому производится защищённое подключение.
DNScrypt может использовать сетевые протоколы UPD и TCP обычно используя в качестве порта 443 который является стандартным и для HTTPS.
Подробное описание как он работает есть на официальном сайте. Вкратце, вначале по имени сервера производится обращение к специальной TXT-записи DNS формата 2.dnscrypt-cert.domain.name для получения текущего ключа публичного сертификата. Например, для сервера cisco, который является псевдонимом приобретённого некоторое время назад этой компанией сервиса OpenDNS, она на момент написания статьи выглядит следующим образом.
Далее производятся соответствующие процедуры обмена и генерация сессионных ключей и начинается работа с данными в шифрованном виде.
2.1. Unbound как клиент DNScrypt
Стандартным способом использования DNScrypt является установка специального клиента dnscrypt-proxy, который доступен для множества платформ. Он выступает в качестве транслятора стандартных запросов DNS через защищённый канал к поддерживающим DNScrypt серверам (см. список публичных серверов).
Поскольку это именно прокси, он не имеет функции кэширования запросов что может негативно сказываться на производительности всех использующих Интернет приложений. В этой связи целесообразно использовать его в связке с локальных кэширующим DNS сервером.
Рассмотрим пример такой настройки совместно с популярным DNS сервером Unbound который уже ранее установлен в среде FreeBSD.
Установим прокси-сервер DNScrypt.
В данном случае будет использоваться случайный DNScrypt-сервер из списка /usr/local/share/dnscrypt-proxy/dnscrypt-resolvers.csv, включённого в дистрибутив прокси-сервера. Можно также принудительно указать предпочтительный сервер путём включения нужной опции в файл инициализации /etc/rc.conf, к примеру, вышеупомянутый сервер OpenDNS.
Сервис запущен и доступен на локальном адресе 127.0.0.1 используя порт 8053.
Теперь перенаправим запросы Unbound к работающем прокси-серверу DNScrypt. Для этого достаточно лишь добавить адрес, который использует прокси в качестве форвардера в секции forward-zone файла конфигурации /usr/local/etc/unbound/unbound.conf.
2.2. Unbound как сервер DNScrypt
Unbound имеет возможность выступать и в качестве сервера обслуживающего DNScrypt запросы.
Однако, ввиду относительной сложности работы с ключами DNScrypt, а именно необходимости генерации, ротации и контроля срока действия ключей при помощи сторонней утилиты dnscrypt-wrapper, автор не видит смысла в такой схеме использования Unbound.
Исключительно для информации лишь упомянем, что для соответствующих настроек используется специальная секция dnscrypt в файле конфигурации Unbound.
Здесь Unbound открыт для обслуживания DNScrypt запросов на порту 5443 (во избежание конфликтов использующим 443 порт HTTP-сервером) используя два набора ключей с различными сроками действия во избежание временных разрывов в работе.
3. DNS-over-TLS
Другим более современным способом защиты DNS трафика явился протокол DNS-over-TLS описанный в стандарте RFC7858, который представляет собой инкапсуляцию данных в стандартный TLS. Для доступа рекомендуется использовать порт 853.
Также как и в случае с DNScrypt предполагается, что клиент DNS, каковым обычно выступает тот же локальный кэширующий DNS, обращается к поддерживающим DNS-over-TLS удалённым серверам (см. актуальный список).
Вышеупомянутый Unbound имеет встроенную поддержку данного протокола, поэтому никакой дополнительной программной прослойки для использования, как это было в случае с DNScrypt, не требуется.
3.1. Unbound как клиент DNS-over-TLS
Для работы в качестве клиента DNS-over-TLS Unbound требует лишь список серверов в той же секции forward-zone файла конфигурации.
3.2. Unbound как сервер DNS-over-TLS
Не составлят труда и настройка Unbound в качестве сервера обслуживающего DNS-over-TLS запросы. Для этого можно использовать уже имеющиеся сертификаты TLS, например от Let’s Encrypt.
В данном случае Unbound по умолчанию обслуживает стандартные нешифрованные DNS запросы на локальном интерфейсе 127.0.0.1 и ::1, однако в данном случае понадобилось это указать в конфигурации в явном виде. Теперь также он доступен и для внешних запросов доступен исключительно по протоколу DNS-over-TLS на порту 853.
4. PROFIT!
Статья была полезной? Тогда прошу не стесняться и поддерживать деньгами через PayPal или Яндекс.Деньги.