Роль DNS в проблемах безопасности и подключения

Система доменных имен (DNS) уже давно служит основой интернет-навигации, переводя считываемые человеком доменные имена в машино-маршрутизируемые IP-адреса. По мере того, как Интернет вещей (IoT) расширяется в дома, фабрики, больницы и города, DNS приобретает новое значение - как критический фактор подключения, так и потенциальная поверхность атаки. С десятками миллиардов устройств IoT, ожидаемых в Интернете, понимание взаимодействия между DNS и безопасностью IoT больше не является обязательным для разработчиков, сетевых архитекторов и специалистов по безопасности. В этой статье исследуется двойная роль DNS в IoT: его важная функция в связи с устройствами и уникальные проблемы безопасности, которые он вводит, наряду с конкретными стратегиями для создания устойчивых, безопасных развертываний IoT.

Как DNS обеспечивает IoT-подключение

По своей сути DNS предоставляет сервис поиска, который позволяет устройствам находить друг друга и облачные сервисы, от которых они зависят. В контексте IoT устройствам часто необходимо подключаться к удаленным серверам для обработки данных, выполнения команд или обновлений прошивки. Без разрешения DNS интеллектуальный термостат не мог бы достичь конечной точки API своего поставщика, промышленный датчик не мог бы подтолкнуть телеметрию к облачной платформе, а подключенная камера не могла бы передавать кадры в мобильное приложение.

DNS работает через иерархию распределенных серверов. Когда устройству IoT необходимо решить доменное имя, оно запрашивает рекурсивный решатель (часто предоставляемый локальной сетью или ISP), который затем пересекает дерево DNS для получения авторитетного IP-адреса. Для устройств IoT с ограниченными ресурсами с ограниченной памятью и вычислительной мощностью этот процесс должен быть быстрым и эффективным. Кэширование на уровне решателя уменьшает повторные поиски, но также создает проблемы вокруг свежести кэша, когда IP-адреса часто меняются - особенно в динамических облачных средах, где балансировщики нагрузки и конечные точки CDN постоянно меняются.

В локальных сетях IoT многоадресные DNS (mDNS) и DNS Service Discovery (DNS-SD) позволяют устройствам обнаруживать друг друга без центрального сервера. Протоколы, такие как Bonjour от Apple и Avahi с открытым исходным кодом, полагаются на mDNS для поиска принтеров, медиа-серверов или узлов умного дома в одной подсети. Эти механизмы с нулевой конфигурацией упрощают настройку для потребителей, но добавляют свои собственные соображения безопасности, как обсуждается ниже.

Проблемы с подключением в IoT: когда DNS не работает

Устройства IoT часто работают в средах с прерывистой связью, строгими бюджетами мощности или ограниченной пропускной способностью. Плохо спроектированный DNS-клиент может усугубить эти проблемы. Например, если устройство использует слишком короткий срок службы (TTL) для записей DNS, оно может генерировать ненужные запросы, которые истощают время автономной работы на датчике, который передает данные только один раз в день. И наоборот, очень длинный TTL может заставить устройство продолжать нацеливаться на IP-адрес, который больше не действителен, что приводит к тайм-ауту соединения и петлям ретрансляции.

Другой распространенной проблемой является надежность DNS-решителя. Многие легкие операционные системы IoT реализуют только базовый ререшитель заглушек, который отправляет запросы непосредственно на настроенный DNS-сервер. Если этот сервер становится недоступным - из-за сетевого раздела, атаки DNS-амплификации или неправильной конфигурации - устройство может не иметь механизма резервного копирования. Это может сделать устройство не реагирующим, даже если сама сеть функциональна. Расширенные платформы IoT решают эту проблему путем встраивания устойчивых библиотек DNS-клиентов, которые поддерживают несколько восходящих резоляторов, экспоненциальное резервное копирование и резервное копирование в альтернативные методы разрешения домена (такие как DoH или DoT).

Технологии преобразования сетевых адресов (NAT) и перехода IPv6 также взаимодействуют с DNS способами, которые влияют на подключение к IoT. Истощение IPv4 привело к тому, что многие организации развертывают NAT-NAT (CGNAT), что усложняет одноранговые сценарии использования IoT, такие как голосовые помощники или дверные звонки, которые требуют прямой связи. Такие устройства часто полагаются на STUN (Session Traversal Utilities for NAT) или TURN-серверы, которые сами зависят от разрешения DNS. Неправильная настройка записей DNS для этих вспомогательных служб может вызвать сбои вызова или задержки видеопотоков.

IPv6 Promise и DNS

IPv6 устраняет необходимость в NAT и предлагает практически неограниченное адресное пространство. Однако широкое распространение остается неполным, и устройства IoT должны обрабатывать оба семейства адресов. DNS64 и NAT64 позволяют устройствам только IPv6 достигать серверов только IPv4, но этот перевод добавляет задержку и сложность. Запросы DNS, которые возвращают несколько записей AAAA (IPv6) вместе с записями A (IPv4), дают клиентам выбор, но не все стеки IoT реализуют правильный алгоритм Happy Eyeballs, что приводит к задержкам соединения, когда семейство адресов первого предпочтения недоступно.

Риски безопасности: темная сторона DNS в IoT

DNS был разработан в эпоху, когда безопасность не была приоритетом. Отсутствие аутентификации и проверки целостности делает его главной целью для различных атак. В средах IoT эти риски увеличиваются, потому что устройства часто имеют минимальные положения безопасности, ограниченные вычислительные ресурсы для криптографии и длительный срок службы без поддержки поставщиков.

DNS-спуфинг и отравление кэшем

В DNS-подделке злоумышленник впрыскивает поддельные DNS-ответы в кэш решителя. Если устройство IoT запрашивает домен для своего сервера обновления прошивки, поддельный ответ может перенаправить его на вредоносный сервер, контролируемый злоумышленником. Затем устройство загружает подделанное прошивку, которая может включать бэкдоры или вредоносное ПО. Поскольку многие устройства IoT не проверяют цифровую подпись обновлений прошивки, эта атака может быть разрушительно эффективной. Отравление кэшем может быть выполнено на рекурсивном уровне решителя или, в случае mDNS, по локальной ссылке, где ответы не аутентифицированы.

Туннелирование DNS

Туннелирование DNS — это метод, который кодирует данные из других протоколов в DNS-запросах и ответах. Злоумышленники используют тот факт, что трафик DNS часто допускается через брандмауэры, которые блокируют другие протоколы. Зараженное устройство IoT может эксфильтровывать конфиденциальные данные — такие как каналы камеры, нажатия клавиш или показания датчиков окружающей среды — путем кодирования его в DNS-запросах, отправленных на вредоносный авторитетный сервер. DNS-сервер злоумышленника декодирует данные, эффективно запустив скрытый канал по DNS. Обнаружение этого требует анализа размеров запросов, частот и энтропии доменных имен.

Усиление и отражение DDoS-атак

Поскольку пакеты ответов DNS могут быть намного больше пакетов запросов, для усиления DDoS-атак могут использоваться неправильно настроенные открытые решители. Атакующие отправляют небольшой запрос с поддельным IP-адресом источника (жертвы) на открытый решитель, который затем отправляет большой ответ жертве. Устройства IoT, которые участвуют в ботнетах, такие как штамм Mirai, часто используются для генерации трафика атаки. В то время как коэффициент усиления ниже, чем некоторые другие протоколы, усиление DNS остается общим вектором. Рост DNS-over-HTTPS (DoH) усложняет вопросы, потому что зашифрованные запросы не могут быть проверены традиционными устройствами безопасности фильтрации DNS.

Алгоритмы генерации доменов (DGA)

Многие IoT-ботнеты используют алгоритмы генерации доменов для динамического генерирования большого количества доменных имен для связи команд и управления (C2).Каждый день зараженное устройство пытается решить новый набор доменов, что затрудняет для команд безопасности блокировку сервера C2 по статическому черному списку. Анализ трафика DNS, который ищет высокие показатели NXDOMAIN-ответов (несуществующих доменов), может помочь идентифицировать зараженные устройства, но объем запросов от большого парка IoT может перегрузить системы обнаружения.

Стратегии смягчения последствий: обеспечение безопасности инфраструктуры IoT DNS

Для устранения рисков, связанных с DNS, в IoT требуется многоуровневый подход, охватывающий проектирование устройств, сетевую архитектуру и операционный мониторинг. Следующие стратегии необходимы для создания безопасных систем IoT.

Внедрение DNSSEC

Расширения безопасности DNS (DNSSEC) добавляют криптографические подписи в записи DNS, позволяя разрешающим устройствам проверять, что ответ исходит из авторитетного источника и не был подделан. В то время как DNSSEC не шифрует содержимое запроса, он предотвращает подмену и отравление кешем. Каждое устройство IoT или его локальный решатель должны проверять подписи DNSSEC. Принятие было медленным из-за сложности, но основные общедоступные решатели (например, Cloudflare 1.1.1.1 и Google Public DNS) выполняют проверку и отклоняют недействительные ответы. Для развертывания корпоративного IoT развертывание валидационного разрешающего устройства на границе сети является лучшей практикой.

Шифрование DNS трафика: DoH и DoT

DNS-over-TLS (DoT) и DNS-over-HTTPS (DoH) шифруют сам запрос, защищая от подслушивания и манипулирования на пути. Отправляя запросы DNS по защищенному каналу, эти протоколы не позволяют злоумышленнику в той же сети вводить поддельные ответы или перехватывать содержимое запроса, чтобы вывести поведение пользователя (хотя сам запрос все еще может быть зарегистрирован на решателе). Устройства IoT с ограниченными ресурсами могут бороться с накладными расходами рукопожатий TLS. Однако легкие библиотеки TLS, такие как ]wolfSSL и аппаратное ускорение на современных блоках микроконтроллеров (MCU), делают это возможным. Альтернативно, трафик DNS может быть зашифрован на уровне шлюза, действуя как безопасный экспедитор для устройств, которые не имеют встроенной поддержки DoH / DoT.

Сегментация сети и правила брандмауэра

Устройства IoT должны размещаться на изолированных VLAN с ограниченными правилами выхода. Даже если DNS устройства отравлен, сегментация сети ограничивает радиус взрыва. Брандмауэры должны позволять устройствам IoT общаться только с одобренными DNS-решителями (желательно внутренними, проверенными) и блокировать прямые исходящие DNS-запросы в общедоступный интернет. Это предотвращает обход устройством средств управления безопасностью организации с помощью другого ресслера. Для mDNS сегментирование доменов L2-вещания имеет решающее значение для предотвращения обнаружения кросс-сетей и потенциальной эксплуатации.

Регулярные обновления прошивки и безопасная загрузка

Многие IoT-атаки используют известные уязвимости, которые могли быть исправлены. Необходим автоматизированный механизм обновления по воздуху (OTA), который проверяет цифровые подписи прошивки перед установкой. Идентификацию сервера обновления следует проверять через DNS (с использованием DNSSEC или прикрепленных сертификатов), чтобы гарантировать, что устройство загружает подлинное прошивку. Защищенные механизмы загрузки, которые измеряют цепочку загрузки и отказываются запускать неподписанный код, дополнительно защищают от постоянных вредоносных программ, которые могут изменить логику разрешения DNS.

DNS-ориентированный анализ угроз

Развертывание брандмауэров DNS или фильтров контента, которые блокируют известные вредоносные домены и IP-адреса, может снизить риск связи C2. Такие службы, как Spamhaus и Cisco Umbrella, поддерживают каналы угроз в реальном времени, которые могут быть интегрированы с локальными DNS-решителями. Для IoT-парков может быть запущен автоматический ответ на инциденты при обнаружении аномальных шаблонов DNS — таких как внезапный всплеск запросов к новому домену или запросов к DGA. Аналитические платформы могут соотносить журналы DNS с идентификаторами устройств для точного определения скомпрометированных конечных точек.

Использование DoH Proxies и Stub Resolvers

Когда устройства не могут поддерживать DoH изначально, локальный прокси-сервер DoH (например, ]Stubby или ]dnscrypt-proxy ) может работать на шлюзе или краевом маршрутизаторе. Прокси получает DNS с помощью IoT-устройства, шифрует его с помощью DoH или DoT и пересылает его на безопасный восходящий разрешающий механизм. Это повышает безопасность всей подсети IoT без изменения каждого устройства. Кроме того, прокси-сервер может обеспечивать соблюдение политик, таких как блокировка запросов к неутвержденным доменам или регистрация всего трафика для аудита.

Будущие тренды: что будет дальше с DNS и IoT

По мере того, как сети IoT становятся все более сложными, индустрия разрабатывает стандарты и архитектуры DNS для удовлетворения новых требований.

DNS over QUIC (DoQ)

QUIC — это транспортный протокол, построенный на UDP, который обеспечивает зашифрованные, мультиплексированные соединения с уменьшенной задержкой. DNS over QUIC (DoQ) сочетает в себе преимущества производительности QUIC (установка соединения 0-RTT, отсутствие блокировки головы линии) с обязательным шифрованием. Для устройств IoT, чувствительных к времени установки соединения, DoQ может быть быстрее, чем DoT/DoH, особенно по ссылкам с высокой задержкой. Эксперименты по стандартизации этого подхода (RFC 9250).

Сохранение конфиденциальности DNS: Oblivious DoH

Oblivious DoH (ODoH) отделяет DNS-запрос от IP-адреса клиента с помощью двухпрокси-архитектуры: один прокси шифрует запрос и направляет его ко второму прокси, который скрывает личность клиента от решителя. Это предотвращает регистратор от регистрации того, какой клиент запрашивал какой домен. В то время как все еще экспериментально, ODoH может защитить пользователей общедоступных IoT-сервисов — таких как киоски умного города — от пассивного наблюдения.

DNS и локальное разрешение

Краевые вычисления приближают обработку к устройствам IoT, уменьшая использование задержки и пропускной способности. DNS-решители, развернутые на границе сети, могут кэшировать записи локально и обрабатывать большие объемы запросов с тысяч устройств, не достигая общедоступного Интернета. Это особенно полезно в промышленном IoT (IIoT), где надежность имеет первостепенное значение. Краевые решатели также могут быть предварительно сконфигурированы с записями обнаружения служб для локальных ресурсов - известных как DNS-SD RFC 6763 - что позволяет обнаруживать специальные устройства без зависимости от облака.

Машинное обучение для обнаружения аномалий

С огромным объемом трафика DNS из IoT-парков ручное обнаружение на основе правил недостаточно. Модели машинного обучения могут анализировать исторические шаблоны запросов DNS для каждого типа устройства и отклонений флага — например, умная лампочка внезапно разрешает домен, связанный с известным сервером управления DDoS, или датчик, запрашивающий десятки несуществующих доменов (индикатор DGA). Эти модели могут быть обучены на обычных сигнатурах трафика IoT и постоянно обновляться.

Создание DNS-устойчивой IoT-архитектуры

В конечном счете, DNS нельзя игнорировать при планировании IoT. Устойчивая архитектура включает в себя несколько уровней: прошивка защищенного устройства с проверяющими заглушками, зашифрованный транспорт через DoH / DoT, сегментированные сети, проактивный мониторинг и стратегию резервного копирования, которая позволяет избежать единичных точек отказа. DNS играет основополагающую роль в подключении, но она также представляет собой поверхность атаки, которая растет с количеством развернутых устройств.

Разработчики должны проектировать IoT-устройства с учетом устойчивости DNS - реализации экспоненциального обратного хода, нескольких адресов решателей и настойчивости кэша. Команды безопасности должны интегрировать DNS-логи в свои SIEM и использовать каналы разведки угроз для раннего обнаружения вредоносных шаблонов. И по мере развития стандартов организации должны пилотировать новые технологии, такие как DoQ и ODoH, чтобы оставаться впереди злоумышленников.

Сочетая прочную гигиену DNS с надежными методами безопасности IoT, можно использовать все возможности подключенных устройств, не создавая рисков, связанных с использованием самого базового протокола Интернета.