Dns спуфинг что такое
Спуфинг электронной почты или email spoofing (от англ. spoof — обманывать, подделывать, имитировать) — это подделка адреса отправителя в электронных письмах.
Спуфинг электронной почты возможен главным образом благодаря особенностям структуры письма и отсутствию проверки служебных заголовков в основном почтовом протоколе — SMTP.
Атаки на DNS
- подмена DNS или «отравление» кэша: использование уязвимости системы для управления кэшем DNS с целью перенаправления пользователей в другое место
- DNS-туннелирование: в основном используется для обхода средств защиты от удаленных подключений
- перехват DNS: перенаправление обычного трафика DNS на другой целевой DNS-сервер путем изменения регистратора домена
- атака NXDOMAIN: проведение DDoS-атаки на авторитетный сервер DNS путем отправки неправомерных доменных запросов для получения принудительного ответа
- фантомный домен: заставляет DNS-преобразователь (DNS resolver) ждать ответа от несуществующих доменов, что приводит к снижению производительности
- атака на случайный субдомен: взломанные хосты и ботнеты проводят DDoS-атаку на действующий домен, но сосредотачивают огонь на ложных субдоменах, чтобы принудить DNS-сервер выполнять поиск записей и захватить управление над службой
- блокировка домена: представляет собой отправку множества спам-откликов для блокировки ресурсов DNS-сервера
- ботнет-атака с абонентского оборудования: совокупность компьютеров, модемов, роутеров и других устройств, концентрирующих вычислительную мощность на определенном веб-сайте для его перегрузки запросами трафика
О компании
Узнайте больше о том, кто мы, как мы работаем и почему наша главная цель – сделать цифровой мир безопасным для всех.
Алфавитный указатель
Пакет эксплойтов (exploit kit)
Парсер
Партнерская программа, партнерка
Пентест, тест на проникновение
Пентестер
Перебор по словарю
Переполнение буфера
Переполнение стека (Stack overflow)
Перехват TCP/IP (TCP/IP hijacking)
Перехват функции (хукинг)
Персистентность
Персональные данные
Песочница (sandbox)
Плагин
ПО с открытым исходным кодом
Побег из песочницы (Sandbox Escape)
Поведенческий анализ
Поверхность атаки
Подделка запросов со стороны сервера (SSRF)
Подмена DLL (DLL hijacking)
Подмена DNS (DNS spoofing)
Подмена MAC-адреса (MAC spoofing)
Подмена SIM-карты
Подстановка учетных данных
Поисковый робот
Полезная нагрузка (payload)
Полиморфизм
Политика BYOD
Порт TCP/IP
Посадочная страница, лендинг
Потенциально нежелательные программы
Потенциально опасная программа
Права cуперпользователя (root-доступ)
Предотвращение утечек информации (DLP)
Претекстинг (Pretexting)
Проверка концепции (proof of concept, PoC)
Программа-блокировщик
Программа-вымогатель как услуга (RaaS)
Программа-шифровальщик
Программно-определяемая сеть (SDN)
Программное обеспечение как услуга (Software as a Service, SaaS)
Программное обеспечение с закрытым исходным кодом (closed source software, проприетарное ПО)
Программный интерфейс приложения (application program interface, API)
Программный модуль
Продолжительные атаки повышенной сложности (advanced persistent threats, APT)
Прокси-сервер
Прошивка (Firmware)
Защита от атак типа email spoofing
Для защиты от поддельных писем на уровне компании существует набор технологий, закрывающих уязвимости протокола SMTP:
- Sender Police Framework (SPF) проверяет подлинность почтового сервера, с которого пришло письмо.
- DomainKeys Identified Mail (DKIM) защищает письмо от подделки при помощи цифровой подписи.
- Domain-based Message Authentication, Reporting and Conformance (DMARC) позволяет управлять технологиями SPF и DKIM и совершенствует их.
Минус этих защитных технологий в том, что они применяются не во всех организациях. При этом для успешной проверки подлинности письма необходимо, чтобы технология проверки поддерживалась и отправителем, и получателем. Тем не менее организация, внедрившая SPF, DKIM и/или DMARC, может защитить от подделок как минимум внутреннюю переписку.
— атака, заключающаяся в искажении данных кэша DNS -сервера, в результате чего трафик жертвы будет перенаправлен на адрес, указанный злоумышленником (вместо легитимного IP-адреса).
Поиск
Способы подмены адреса отправителя
Существует несколько разновидностей спуфинга электронной почты.
Подмена имени отправителя. В этом случае в заголовках From и Reply-to содержится реальный адрес злоумышленников, а имя отправителя подделывается. Этот вариант подмены эффективен в почтовых клиентах, которые по умолчанию отображают только имя, например в мобильных почтовых клиентах.
В качестве имени отправителя злоумышленники могу указать:
- Только поддельное имя (наименование, должность). В этом случае содержимое поля From будет выглядеть как Bob .
- Поддельное имя с поддельным адресом электронной почты. Этот прием называется ghost spoofing. В этом случае содержимое поля From будет выглядеть так: Bob .
Изменение значения полей From и Reply-to. Поскольку в протоколе SMTP не предусмотрено никаких проверок подлинности содержимого заголовков, злоумышленник может подделывать не только имя отправителя, но и адреса электронной почты в полях From и Reply-to. В этом случае у получателя практически нет возможности отличить фейковое письмо от подлинного.
Избегать ненадёжных резолверов с помощью TRR
Сети могут перестать рекомендовать ненадёжные резолверы, которые собирают данные пользователей или подделывают DNS-запросы, потому что очень немногие пользователи знают о рисках или о том, как защитить себя.
Даже для пользователей, которые знают о рисках, отдельному пользователю трудно договориться со своим провайдером или другой организацией о гарантиях, что с его DNS-запросами будут ответственно обращаться.
Тем не менее, мы изучили этих риски… и у нас есть определённое влияние. Мы долго искали компанию, которая поможет нам защитить DNS-данные пользователей. И нашли одну такую: Cloudflare.
Cloudflare предоставляет сервис рекурсивного резолвинга с политикой конфиденциальности для пользователей. Они обязались удалять все привязанные к конкретным людям данные (personally identifiable data) после 24 часов и никогда не передавать эти данные третьим лицам. Будут проводиться регулярные проверки, что данные действительно удаляются, как было обещано.
Благодаря этому у нас есть доверенный резолвер для защиты приватности пользователей. Это означает, что Firefox может игнорировать резолвер сети, а перейти сразу к Cloudflare. Теперь можно не беспокоиться, что злоумышленники используют резолвер для продажи данных пользователей или спуфинга DNS.
Почему мы выбрали один резолвер? Как и мы, Cloudflare озабочен созданием приватной службы DNS. Они вместе с нами разработали хороший прозрачный резолвер DoH. Компания с готовностью пошла на дополнительную защиту сервиса, поэтому мы рады сотрудничать с ними.
Но это не значит, что вы должны использовать Cloudflare. Пользователи могут настроить Firefox на использование любого рекурсивного резолвера с поддержкой DoH. По мере появления новых сервисов мы планируем реализовать простое обнаружение и переключение между ними.
Связаться с нами
Наша главная цель – обеспечить вашу безопасность. Мы всегда готовы ответить на ваши вопросы и оказать техническую поддержку.
Угрозы конфиденциальности и безопасности в интернете становятся серьёзнее. Мы в Mozilla внимательно их отслеживаем. Считаем своей обязанностью сделать всё возможное для защиты пользователей Firefox и их данных.
Нас беспокоят компании и организации, которые тайно собирают и продают пользовательские данные. Поэтому мы добавили защиту от слежения и создали расширение контейнера Facebook. В ближайшие месяцы появится ещё больше защитных мер.
Сейчас мы добавляем в список ещё две технологии:
Но сначала посмотрим, как веб-страницы передаются по интернету.
Когда люди объясняют, как браузер загружает веб-страницу, то обычно объясняют это так:
- Ваш браузер делает запрос GET на сервер.
- Сервер отправляет ответ, который представляет собой файл, содержащий HTML.
Но эта схема слишком упрощена. Ваш браузер не разговаривает напрямую с сервером. Наверное потому что они не близки друг другу.
Сервер может быть за тысячи километров. И вероятно, между вашим компьютером и сервером нет прямой связи.
Таким образом, прежде чем запрос попадёт из браузера на сервер, он пройдёт через несколько рук. То же самое верно для ответа.
Я думаю об этом как о школьниках, передающих друг другу записки в классе. Снаружи в записке написано, кому она предназначена. Ребёнок, написавший записку, передаст её соседу. Затем тот следующий ребёнок передаёт её одному из соседей — вероятно, не конечному получателю, а тому, кто находится в нужном направлении.
— Псст… передай это Сэнди
Проблема в том, что любой по пути может открыть записку и прочитать её. И нет никакого способа узнать заранее, по какому пути будет проходить записка, поэтому неизвестно, какие люди получат доступ к ней.
Она может оказаться в руках людей, которые сделают вредные вещи…
Например, поделятся содержанием записки со всеми.
— О, это пикантно…. Эй народ! Дэнни влюбился в Сэнди!
Или изменят ответ.
— Я тебе тоже нравлюсь?
— Хе-хе, подшучу над ним и напишу «Нет».
Другое место, где данные открыты — это DNS. Но что такое DNS?
— Пожалуйста, отправь это на 208.80.154.224
Это вызывает проблемы. Пользователям неудобно запоминать цифры IP-адреса. Хочется дать сайту запоминающееся имя… которое отложится в памяти у людей.
Вот почему у нас есть система доменных имен (DNS). Ваш браузер использует DNS для преобразования имени сайта в IP-адрес. Этот процесс — преобразование доменного имени в IP-адрес — называется разрешением имени домена или резолвингом.
Как браузер решает задачу?
Один из вариантов — завести большой список вроде телефонного справочника в браузере. Но по мере того, как появляются новые веб-сайты или перемещаются на новые серверы, будет трудно поддерживать этот список в актуальном состоянии.
Таким образом, вместо одного списка для всех доменных имён существует много небольших списков, связанных друг с другом. Это позволяет им управляться независимо.
Для получения IP-адреса, соответствующего доменному имени, необходимо найти конкретный список, который содержит нужное доменное имя. Это похоже на поиск клада.
Домен можно разделить на части.
С такими частями можно начать охоту на список, содержащий IP-адрес сайта. Но нам нужна помощь в поисках. Инструмент, который осуществляет эту охоту вместо нас и находит IP-адрес, называется резолвером.
Сервер имён TLD посоветует резолверу задать этот вопрос серверу имён Википедии.
Этот процесс называется рекурсивным разрешением, потому что приходится ходить туда и обратно, задавая разным серверам по сути один и тот же вопрос.
Я говорила, что нам нужен резолвер для помощи в поисках. Но как браузер находит этот резолвер? В общем, он спрашивает у операционной системы.
— Мне нужен резолвер. Можешь помочь?
— Конечно, позволь познакомить тебя с резолвером, который я использую
Как операционная система знает, какой резолвер использовать? Существует два возможных способа.
Вы можете настроить компьютер на использование определённого резолвера, которому доверяете. Но очень немногие люди делают это.
Вместо этого большинство просто использует настройки по умолчанию. И по умолчанию ОС будет использовать любой резолвер, какой скажет сеть. Когда компьютер подключается к сети и получает свой IP-адрес, то сеть рекомендует определённый резолвер.
— Можно мне получить IP-адрес?
— Без проблем! А если тебе понадобится резолвер, рекомендую вот этот
Это значит, что используемый резолвер может изменяться несколько раз в день. Если вы направляетесь в кафе поработать днём, то вероятно используете другой резолвер, чем утром. И так происходит даже если вы настроили свой собственный резолвер, потому что в протоколе DNS нет никакой безопасности.
Так как эта система подвергает опасности пользователей?
Обычно резолвер сообщает каждому DNS-серверу, какой домен вы ищете. Этот запрос иногда включает ваш полный IP-адрес. А если не полный адрес, то всё чаще запрос включает в себя большую часть вашего IP-адреса, что можно легко объединить с другой информацией, чтобы установить вашу личность.
Содержит большую часть вашего IP-адреса…
… и полный домен, который вы ищете
Значит, каждый сервер, который вы попросите помочь с разрешением доменных имен, видит, какой сайт вы ищете. Более того, любой по пути к этим серверам тоже видит ваши запросы.
Существует несколько способов, как подобная система подвергает риску данные пользователей. Два основных — трекинг (отслеживание) и спуфинг (подмена).
В понятие безопасности DNS входят две важные составляющие:
- Обеспечение общей целостности и доступности служб DNS, преобразовывающих имена сетевых узлов в IP-адреса
- Мониторинг активности DNS для определения возможных проблем безопасности где-либо в вашей сети
Безопасность DNS и DNSSEC
DNSSEC — это средство для проверки целостности DNS-запросов. Оно не влияет на конфиденциальность DNS. Иными словами, DNSSEC может дать вам уверенность в том, что ответ на ваш DNS-запрос не подделан, но любой злоумышленник может увидеть эти результаты в том виде, в каком они были переданы вам.
Почему DNS уязвима для атак?
Технология DNS была создана на заре развития интернета, задолго до того, как кто-либо вообще начал думать о сетевой безопасности. DNS работает без аутентификации и шифрования, вслепую обрабатывая запросы любого пользователя.
В связи с этим существует множество способов обмануть пользователя и подделать информацию о том, где на самом деле осуществляется преобразование имен в IP-адреса.
Оповещения мониторинга DNS
Возможность эффективно отслеживать трафик DNS в вашей сети на предмет подозрительных аномалий имеет решающее значение для раннего обнаружения взлома. Использование такого инструмента, как Varonis Edge даст вам возможность быть в курсе всех важных показателей и создавать профили для каждой учетной записи в вашей сети. Вы можете настроить генерацию оповещений в результате комбинации действий, происходящих за определенный период времени.
Мониторинг изменений DNS, местоположений учетной записи, а также фактов первого использования и получения доступа к конфиденциальным данным, а также активности в нерабочее время — это лишь несколько показателей, которые можно сопоставить для составления более обширной картины обнаружения.
Серьезной проблемой современности являются сетевые угрозы ИБ, то есть классы угроз, реализуемых с использованием протоколов межсетевого взаимодействия. Одним из таких протоколов является протокол системы доменных имен — DNS.
К числу угроз, использующих систему доменных имен, относятся угрозы, основанные на модификации пакетов DNS-транзакций и направленные на создание в сети ложного маршрута. Их потенциальная опасность заключается в возможности перехвата данных, передающихся между клиентами сетевых сервисов и серверами этих сервисов.
Отследить модификацию пакетов DNS-транзакций, при потенциально высокой опасности реализации в информационных системах атак довольно непросто, поэтому становятся возможными такие атаки как:
- анализ сетевого трафика;
- подмена доверенного объекта сети;
- навязывание ложного маршрута;
- внедрение ложного объекта сети.
В состав типовой компьютерной сети, реализующей подмену IP-адреса для целевого домена, входят следующие элементы:
- Клиентская ПЭВМ (Клиент).
- Интернет-провайдер (в составе: кэширующий DNS-сервер, шлюз).
- Вспомогательный клиент.
- Система доменных имен.
- Точка мониторинга (межсетевой экран, фильтр, прокси-сервер).
- Сервер информационной службы.
- Существует контролируемый DNS-сервер, отвечающий за какую-либо (любую) зону системы доменных имен.
- Клиент обслуживается интернет-провайдером с кэширующим DNS-сервером либо известен иной DNS-сервер, услугами которого пользуется клиент, и данный сервер является кэширующим.
- В момент получения DNS-ответа от контролируемого DNS-сервера в кэше DNS-сервера интернет-провайдера отсутствует запись с целевым DNS-именем узла информационной службы.
- В точке мониторинга существует база IP адресов и доменных имен целевых информационных службы, в отношении которых ведется мониторинг и управление сетевым взаимодействием с клиентом.
Согласно рекомендациям RFC 1034, RFC 1035, устанавливающих порядок функционирования, спецификацию и применение системы доменных имен, при формировании DNS-ответа допускается добавление, так называемых полей «Additional». Данные поля необходимы для записи IP-адресов вспомогательных узлов различных типов, в том числе, для предотвращения повторного обращения к DNS-серверу, в случаях, когда по определенным причинам, основной узел, запись которого передается в поле «Answer», оказывается недоступным. В случае применения предлагаемого подхода, в поле «Additional» записывается IP-адрес, ставящийся в соответствие доменному имени целевой информационной службе, но реально принадлежащий точке мониторинга – межсетевому экрану.
Такую задачу (добавление нужного нам поля) можно возложить на скрипт, имитирующий работу легитимного DNS-сервера, отвечающего за какую-либо DNS-зону, причем не важно какого уровня…
После того как в процессе разрешения заданного DNS-имени кэширующий DNS-сервер интернет-провайдера (ISP) получает DNS-ответ, то при отсутствии записей в своей кэш-памяти соответствующих записям из дополнительных полей DNS-ответа, он помещает эти записи в кэш-память. Таким образом, в кэш-память DNS-сервера интернет-провайдера помещаются записи, устанавливающие соответствие доменных имен информационных служб, для которых будет осуществляться мониторинг, и IP-адреса, принадлежащего точке мониторинга. С этого момента, в случае, если клиент формирует DNS-запрос на разрешение имени узла целевой информационной службы с доменными именем, хранящимся в кэше провайдера и сохраненного из дополнительных полей, полученных после обработки DNS запроса «вспомогательного» клиента, то DNS-сервер интернет-провайдера формирует и отправляет DNS ответ клиенту на основе данных из своего кэша.
Таким образом, клиент получает разрешение доменного имени запрошенной информационной службы с IP адресом, полученным от контролируемого DNS сервера и хранящемся в момент обработки запроса клиента интернет-провайдером в кэш-памяти провайдера. При этом IP адрес принадлежит не целевой информационной службе, запрашиваемой клиентом, а точке мониторинга. Соответственно, далее, обращение клиента к целевой информационной службе происходит по IP адресу, принадлежащему точке мониторинга.
При обращении клиента по полученному IP адресу к точке мониторинга, в которой на основании предопределенных параметров сетевой политики безопасности производится ряд управляющих воздействий. К этим действиям относится:
- Разбор полученной от клиента транзакции.
- Выработка и применение управляющих воздействий.
- Аудит полученных транзакций и произведенных действий.
- Формирование на основе данных полученной клиентской транзакции запроса к информационной службе.
Проверка представленных изысканий производилась с использованием испытательного стенда в виде компьютерной сети со следующими элементами:
- DNS-сервер на базе программного обеспечения BIND 9.4, отве-чающий за зону ".a", с доменным именем «ns.a».
- DNS-сервер на базе программного обеспечения BIND 9.4, отве-чающий за зону ".b", с доменным именем «ns.b».
- Клиентская ПЭВМ с IP адресом 10.0.33.13.
- Точка мониторинга – межсетевой экран с IP адресом 10.0.33.13.
Между DNS-серверами пересылка зон настроена таким образом, что получая запрос на разрешения доменного имени из зоны, за который отвечает другой DNS сервер, текущий DNS сервер формирует и отправляет к нему повторный DNS запрос и, получив от него ответ, формирует и отправляет DNS ответ клиенту, сформировавшему первый запрос, одновременно помещая в свою кэш-память ответ от второго DNS сервера. Таким образом, моделируется работа DNS сервера интернет-провайдера.
На 2-м этапе происходит формирование и передача DNS-запроса для доменного имени «test.b» от клиента в систему доменных имен, состоящему из DNS сервера «ns.a» и DNS сервера «ns.b». При этом первичным DNS сервером (DNS сервером интернет-провайдера) для клиента является DNS сервер «ns.a».
Спуфинг
Отправь это на 1.6.6.6… это абсолютно правильный адрес, а вовсе не поддельный сайт, который я контролирую
Опять же, здесь и сам резолвер может действовать гнусно.
Мы в Mozilla твёрдо убеждены, что несём ответственность за защиту пользователей и их данных, и поэтому работаем над устранением данных уязвимостей.
- Вы можете в конечном итоге использовать ненадёжный резолвер, который отслеживает ваши запросы или подменяет ответы от DNS-серверов.
- Маршрутизаторы по пути могут отслеживать запросы или вмешиваться таким же образом.
- DNS-серверы могут отслеживать DNS-запросы.
Как этого избежать?
Структура запроса
Применение спуфинга электронной почты
Email spoofing используется как в легитимных, так и во вредоносных целях. Легитимный спуфинг нужен:
В легитимных целях применяется только полное изменение заголовков From и Reply-to.
Возможные вредоносные цели:
Бесплатные утилиты
Наши бесплатные утилиты помогают обеспечить защиту ваших устройств на базе Windows, Mac и Android.
Пробные версии
Попробуйте наши решения. Всего за несколько кликов вы можете скачать бесплатные пробные версии нашего продукта и проверить их в действии.
DoT — DNS поверх TLS
Transport Layer Security (безопасность на транспортном уровне, TLS) — это криптографический протокол для защиты передаваемой информации по сетевому соединению. Как только между клиентом и сервером установлено безопасное соединение TLS, передаваемые данные шифруются и никакие посредники не смогут их увидеть.
Источник: University of California Irvine
Стандартные DNS-запросы передаются через UDP. Запросы и ответы можно отслеживать с помощью таких инструментов, как Wireshark. DoT шифрует эти запросы, но они по-прежнему идентифицируются как довольно отчетливый трафик UDP в сети.
- DNS-фильтрация — это распространенный способ фильтрации веб-трафика для защиты пользователей от фишинговых атак, сайтов, распространяющих вредоносные программы, или другой потенциально опасной интернет-активности в корпоративной сети. Протокол DoH обходит эти фильтры, потенциально подвергая пользователей и сеть более высокому риску.
- В текущей модели преобразования имен каждое устройство в сети в той или иной степени получает DNS-запросы из одного и того же места (из указанного DNS-сервера). DoH и, в частности, его реализация от Firefox показывают, что в будущем это может измениться. Каждое приложение на компьютере может получать данные из разных источников DNS, что значительно усложняет поиск и устранение проблем, обеспечение безопасности и моделирование рисков.
Безопасность DNS: вопросы и компоненты
- Усиление безопасности серверов и процедур управления: повышайте уровень защищенности серверов и создайте стандартный шаблон ввода в эксплуатацию
- Совершенствование протокола: внедрите DNSSEC, DoT или DoH
- Аналитика и отчетность: добавьте журнал событий DNS в SIEM-систему для дополнительного контекста при расследовании инцидентов
- Киберразведка и обнаружение угроз: подпишитесь на активный канал получения аналитических данных об угрозах
- Автоматизация: создайте максимально возможное количество сценариев, чтобы автоматизировать процессы
Что такое DNSSEC?
DNSSEC — модули безопасности службы доменных имен — используются для проверки записей DNS без необходимости знать общую информацию по каждому конкретному DNS-запросу.
DNSSEC использует ключи цифровой подписи (PKI) для подтверждения того, получены ли результаты запроса доменного имени из допустимого источника.
Внедрение DNSSEC является не только лучшей отраслевой практикой, но также эффективно помогает избежать большинство атак на DNS.
Принцип работы DNSSEC
- Записи DNS подписываются парой закрытого и закрытого ключей
- Ответы на запросы DNSSEC содержат запрошенную запись, а также подпись и открытый ключ
- Затем открытый ключ используется для сравнения подлинности записи и подписи
Атаки с использованием DNS
- Fast-Flux
- Одиночные сети Flux
- Двойные сети Flux
Структура электронного письма
Трекинг
Как я говорила выше, по полной или частичной информацию об IP-адресе несложно определить личность того, кто просит доступ к конкретному сайту. Это означает, что DNS-сервер и любой пользователь на пути к этому DNS-серверу (маршрутизатор по пути) может создать профиль пользователя. Они могут составить список всех сайтов, которые вы просмотрели.
И это ценные данные. Многие люди и компании готовы немало заплатить, чтобы увидеть вашу историю посещённых страниц.
Сколько вы готовы заплатить за информацию о том, на что смотрел Джон Доу?
Даже если бы нам не пришлось беспокоиться о потенциально гнусных DNS-серверах или маршрутизаторах по пути, всё равно есть риск, что ваши данные соберут и продадут. Потому что сам резолвер — который вам дала сеть — может оказаться ненадёжным.
Даже если вы доверяете рекомендованному резолверу от сети, то вероятно используете его только дома. Как я уже упоминала, каждый раз в кафе, отеле или в любой другой сети вам, вероятно, дадут другой резолвер. И кто знает, какова его политика сбора данных?
Кроме того, что ваши данные собираются и затем продаются без вашего ведома или согласия, систему используют ещё более опасным способом.
Что такое безопасность DNS?
Атаки на DNS
- Подмена DNS или «отравление» кэша
- Перехват DNS
Структура DNS-ответа
Проверка данного факта осуществляется командой
На основе представленных материалов проведенного эксперимента можно сделать вывод, что, при выполнении перечисленных условий и добавлению дополнительного поля «Additional» в DNS-коммутаторе при обработке запроса на разрешение доменного имени целевой информационной службы, возникает возможность осуществления контроля сетевого взаимодействия клиента и заданных информационных служб вне зависимости от их расположения и топологии компьютерной сети. Кроме этого появляется возможность мониторинга и контроля сетевого взаимодействия клиента и заданных информационных служб как на этапе установления сеанса соединения, так и на этапе информационного обмена, что не есть хорошо…
Структура пакета DNS ответа
Проверка осуществляется командой
Продукты для дома
Наши передовые решения помогают защитить то, что для вас ценно. Узнайте больше о нашей удостоенной наград защите.
Передавать как можно меньше данных, чтобы защитить пользователей от деанонимизации
Вдобавок к доверенному резолверу, который работает по протоколу DoH, мы с компанией Cloudflare работаем над дополнительными мерами безопасности.
Обычно резолвер отправляет полное имя домена каждому серверу: корневому DNS, серверу имён доменов верхнего уровня, второго уровня и т. д. Но сервер Cloudflare будет поступать иначе. Он будет отправлять только ту часть, которая имеет отношение к конкретному DNS-серверу. Это называется минимизация QNAME.
Часто резолвер также включает в запрос первые 24 бита вашего IP-адреса. Это помогает DNS-серверу узнать, где вы находитесь, и выбрать ближайший CDN. Но DNS-серверы могут использовать данную информацию для связывания друг с другом разрозненных запросов.
Вместо этого Cloudflare будет делать запрос с одного из собственных IP-адресов, который находится рядом с пользователем. Это обеспечивает геолокацию без привязки к конкретному человеку. Мы также изучаем, как реализовать ещё лучшую, тонкую балансировку нагрузки с учётом конфиденциальности.
Всё это — удаление ненужных частей домена и IP-адреса — означает, что DNS-сервер может собрать о вас гораздо меньше данных.
Эти защитные меры сокращают количество людей, которые могут видеть историю посещённых вами страниц. Но они полностью не исключают утечки данных.
То есть ваш интернет-провайдер по-прежнему способен выяснить, какие сайты вы посещаете, потому что они указаны прямо там, в SNI. Информация открыта и для маршрутизаторов, которые передают первоначальный запрос из вашего браузера на веб-сервер.
Но как только вы установили соединение с веб-сервером, всё зашифровано. И самое главное, что данное зашифрованное соединение можно использовать для любого сайта на этом сервере, а не только для того, который вы изначально запрашивали.
Почему это полезно? Потому что не нужно открывать новое соединение для подключения к этим другим сайтам. То есть вам не нужно отправлять ещё один незашифрованный первоначальный запрос с указанием SNI и раскрытием информации, на какой сайт вы идёте. Так вы можете посетить любой из других сайтов на том же сервере, не раскрывая их своему провайдеру и маршрутизаторам на пути.
С ростом популярности CDN всё больше отдельных сайтов обслуживаются одним сервером. И поскольку у вас может быть открыто несколько объединённых соединений, вы одновременно подключаетесь к нескольким общим серверам или CDN, посещая все сайты на разных серверах без утечки данных. Так что данная функция всё более эффективно работает как защитный экран.
Мы хотим включить DoH по умолчанию для всех пользователей, поскольку каждый человек заслуживает конфиденциальности и безопасности, независимо от того, знает он об утечках DNS или нет.
Но это значительное изменение, и его нужно сначала протестировать. Поэтому мы проводим исследование. Половину наших пользователей Firefox Nightly мы просим помочь собрать данные о производительности.
В тестировании используется резолвер по умолчанию, как и сейчас, но также запросы отправляются на DoH-резолвер Cloudflare. Затем мы сравниваем результат для проверки, что всё работает как положено.
Для участников исследования ответ Cloudflare DNS пока не используется. Мы просто проверяем, что всё работает, а затем выбрасываем ответ Cloudflare.
Выражаем благодарность за поддержку пользователям Nightly, которые каждый день помогают тестировать Firefox. Надеемся, что вы тоже поможете нам.
Чем бы ни занималась компания, безопасность DNS должна являться неотъемлемой частью ее плана по обеспечению безопасности. Службы обработки имен, преобразовывающие имена сетевых узлов в IP-адреса, используются буквально всеми приложениями и службами в сети.
Читайте также: