8-900-374-94-44
5 лет гарантии
1426 просмотров
600 ₽
Розничная цена
Ограничение заказа:
Для данного товара действуют ограничения: Общая сумма заказа должна быть более 3 т.
р.
Наличие:
Наличие и срок поставки уточняйте у менеджеров
Оставить отзыв
Датчик представляет собой устройство для выдачи информационного сообщения о наличии напряжения в электрической сети в формате «СУХИЕ КОНТАКТЫ РЕЛЕ» и реализован в виде модуля с гибкими проводниками и выходной колодкой. Датчик обеспечивает гальваническую развязку выходных контактов. Позволяет получить информационный сигнал о наличии сети 220 В. Выходной сигнал — контакты реле, нормально замкнуты. Можно встроить в любой источник питания.
Датчик представляет собой устройство для выдачи информационного сообщения о наличии напряжения в электрической сети в формате“СУХИЕ КОНТАКТЫ РЕЛЕ” и реализован в виде модуля с гибкими проводниками и выходной колодкой.
Датчик подключается к электрической сети гибкими проводниками согласно фазировке. Выходные контакты выведены на клеммную колодкуACON. Датчик обеспечивает гальваническую развязку выходных контактов.
1. При наличии сетевого напряжения контакты.замкнуты
Документация:
Консультация
Задайте вопрос специалисту о ДНС-1 Датчик наличия сети
Вопрос от: Александр
Как подключить ДНС-1, чтобы при отсутствии напряжения в сети появился звуковой сигнал?
Здравствуйте.
Вам нужен будет блок питания с аккумулятором, 12В, например, https://www.aktivsb.ru/prod-3850.html
Вопрос от: вячеслав
какая обязательная нормативно-техническая документация, либо техническая документация на ДНС-1, разрешает, либо запрещает устанавливать его в клеммной распаечной коробке групповой сети (розеточной, освещения) вместе с групповыми кабелями.Либо он должен быть установлен в отдельном корпусе , либо отдельной коробке.
Самовывоз из офиса:
Пункт выдачи:*
Доставка курьером:*
Транспортные компании:
Почта России:*
* Срок доставки указан для товара в наличии на складе в Москве
Отзывы о ДНС-1:
Ваш отзыв может быть первым!
С этим товаром часто покупают:
ruРасширения безопасности DNS (DNSSEC) были разработаны для обеспечения аутентификации источника и защиты целостности данных DNS с использованием цифровых подписей. Эти цифровые подписи могут быть созданы с использованием различных алгоритмов. Этот документ определяет способ проверки распознавателей конечной системы, чтобы сообщить серверу, какие цифровые подписи и алгоритмы хеширования они поддерживают. Расширения позволяют сигнализировать о новом использовании алгоритма в клиентском коде, что позволяет администраторам зоны знать, когда можно завершить перенос алгоритма в зоне, подписанной DNSSEC.
Скачать оригинальный документ на английском языке RFC 6975 PDF
1. Введение
2. Требования к языку
3. Сигнализация DNSSEC Алгоритм Понятно (DAU), DS Хэш-Понятно (DHU), и NSEC3 Хэш-Понятно (N3U) Используя EDNS
4. Вопросы клиентов
4.1. Заглушки резольверов
4.1.1. Проверка правильности резольверов
4.1.2. Непроверяемые заглушки резольверов
4.
2. Рекурсивные резольверы
4.2.1. Проверка рекурсивных резольверов
4.2.2. Не проверяющие рекурсивные резольверы
5. Промежуточные системные соображения
6. Особенности сервера
7. Анализ трафика
8. Соображения IANA
9. Вопросы безопасности
10. Нормативные документы
Адрес автора
Это документ по отслеживанию стандартов Интернета.
Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественную рецензию и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 RFC 5741.
Информацию о текущем статусе этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу http://www.rfc-editor.org/info/rfc6975.
Copyright (c) 2013 IETF Trust и лица, указанные в качестве авторов документа.
Все права защищены.
На данный документ распространяется действие ППГ 78 и Правовые положения IETF Trust, касающиеся документов IETF (http://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны содержать текст Упрощенной лицензии BSD, как описано в Разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в Упрощенной лицензии BSD.
Расширения безопасности DNS (DNSSEC), [RFC4033], [RFC4034] и [RFC4035] были разработаны для обеспечения аутентификации источника и защиты целостности данных DNS с использованием цифровых подписей. Каждая запись ресурса (RR) цифровой подписи (RRSIG) содержит кодовый номер алгоритма, который соответствует RR открытого ключа DNSSEC (DNSKEY). Эти коды алгоритмов сообщают валидаторам, какой криптографический алгоритм использовался для генерации цифровой подписи.
Аналогично, записи RR подписывающего делегирования (DS) и записи отказа в существовании с хэшированной аутентификацией (NSEC3) используют хеш-значение как часть своих данных записи ресурса (RDATA), и, подобно алгоритмам цифровой подписи, эти алгоритмы хеширования имеют кодовые номера. Все три кода алгоритмов (RRSIG / DNSKEY, DS и NSEC3) хранятся в уникальных реестрах IANA.
Этот набор документов определяет способ проверки распознавателей конечной системы, чтобы сообщить серверу в запросе DNS, какие алгоритмы цифровой подписи и / или хеширования они поддерживают. Это делается с использованием новых опций механизмов расширения для DNS (EDNS0), указанных ниже в разделе 2 для использования в мета-RR OPT [RFC6891]. Эти три новых кода опции EDNS0 являются необязательными для реализации и использования.
Эти предложенные варианты EDNS0 служат для измерения принятия и использования новых алгоритмов цифровой подписи. Эти параметры сигнализации могут использоваться администраторами зон в качестве индикатора для измерения успешного развертывания кода, который реализует недавно развернутый алгоритм цифровой подписи, хэш DS и алгоритм хеширования NSEC3, используемый с DNSSEC.
Администратор зоны может определить, когда следует прекратить подписывание с помощью замененного алгоритма, когда сервер видит, что значительное число его клиентов сигнализирует о том, что они могут принять новый алгоритм. Обратите внимание, что это обследование может проводиться в течение нескольких лет, прежде чем наступит переломный момент.
Этот документ не стремится представить другой процесс для включения новых алгоритмов для использования с DNSSEC. В нем также не рассматривается вопрос о том, какие алгоритмы должны быть включены в какой-либо официальный список обязательных или рекомендуемых криптографических алгоритмов для использования с DNSSEC. Скорее этот документ определяет средства, с помощью которых клиентский запрос может сигнализировать набор алгоритмов и хэшей, которые он реализует.
Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119].
Спецификация EDNS0, изложенная в [RFC6891], определяет способ включения новых опций с использованием стандартизированного механизма. Эти параметры содержатся в RDATA мета-RR OPT. Этот документ определяет три новых варианта EDNS0 для клиента, чтобы указать, какие алгоритмы цифровой подписи и / или хэш-функции клиент поддерживает. Эти опции могут использоваться независимо друг от друга и МОГУТ появляться в любом порядке в OPT RR. Каждый код опции может появляться только один раз в OPT RR.
На рисунке ниже показано, как каждый параметр определяется в RDATA OPR RR, указанной в [RFC6891]:
Рисунок 1 — Как каждый параметр определяется в RDATA OPR RROPTION-CODE — это код для данной опции сигнализации. Варианты:
LIST-LENGTH — длина списка цифровых подписей или кодов алгоритмов хеширования в октетах. Каждый код алгоритма занимает один октет.
ALG-CODE — это список назначенных значений алгоритмов подписания зоны DNSSEC, алгоритмов хеширования DS или алгоритмов хеширования NSEC3 (в зависимости от используемого OPTION-CODE), который клиент объявляет поддерживаемым. Порядок значений кода может быть произвольным и НЕ ДОЛЖЕН использоваться для определения предпочтения.
Если все OPT включены в OPR RR, существует вероятность того, что OPT RR займет значительный размер в сообщении DNS. Однако в практическом плане включение всех трех параметров может занимать 22-32 октета (в среднем 6-10 алгоритмов цифровой подписи, 3-5 алгоритмов хеширования DS и 1-5 алгоритмов хеширования NSEC3), включая коды параметров EDNS0 и варианты длины в потенциальных будущих примерах.
Проверяющий распознаватель конечной системы устанавливает опцию DAU, DHU и / или N3U или их комбинацию в мета-RR OPT при отправке запроса.
Проверяющий распознаватель конечной системы ДОЛЖЕН также установить бит DNSSEC OK [RFC4035], чтобы указать, что он хочет получить RR DNSSEC в ответе.
Обратите внимание, что коды цифровой подписи PRIVATEDNS (253) и / или PRIVATEOID (254) охватывают потенциально широкий спектр алгоритмов и, вероятно, бесполезны для сервера. У клиента нет веских причин включать эти коды в свой список DAU. Аналогично, клиенты НЕ ДОЛЖНЫ включать ЗАБРОНИРОВАННЫЕ коды в любую из опций. Кроме того, клиент не обязан перечислять каждый алгоритм, который он реализует, и МОЖЕТ выбрать перечисление только тех алгоритмов, которые клиент желает сигнализировать, как понял.
Поскольку параметры DAU, DHU и / или N3U задаются только в запросе, если клиент видит эти параметры в ответе, никаких действий предпринимать не нужно, и клиент ДОЛЖЕН игнорировать значения параметров.
Как правило, средства разрешения заглушки полагаются на рекурсивный сервер (или кэш) восходящего потока для предоставления ответа.
Таким образом, оптимальная настройка параметров DAU, DSU и N3U зависит от того, выберет ли преобразователь заглушки свою собственную проверку.
Подтверждающий преобразователь заглушки устанавливает бит DNSSEC OK (DO) [RFC4035], чтобы указать, что он хочет получить дополнительные RR DNSSEC (то есть RRSIG) в ответе. Такие проверяющие распознаватели ДОЛЖНЫ включать DAU, DHU и / или опцию (и) N3U в OPT RR при отправке запроса.
Опции DAU, DHU и N3U EDNS0 НЕ ДОЛЖНЫ включаться в непроверяющие средства разрешения заглушек.
Проверяющий рекурсивный распознаватель устанавливает параметры DAU, DHU и / или N3U при выполнении рекурсии на основе своего списка алгоритмов и любых списков параметров DAU, DHU и / или N3U в запросе клиента-заглушки. Когда рекурсивный сервер получает запрос с одной или несколькими из установленных опций, рекурсивный сервер ДОЛЖЕН установить список алгоритмов для любых исходящих итеративных запросов для этой цепочки разрешений на объединение списка клиента-заглушки и списка проверяющего рекурсивного преобразователя.
Например, если список алгоритмов рекурсивного распознавателя для опции DAU равен (3, 5, 7), а список алгоритмов заглушки — (7, 8), окончательный список алгоритмов DAU будет (3, 5, 7, 8).
Если клиент включил биты DO и Checking Disabled (CD), но не включил опции (опции) DAU, DHU и / или N3U в запрос, проверяющий рекурсивный преобразователь МОЖЕТ включать эту опцию (ы) со своим собственным списком в полном объеме. Если один или несколько параметров отсутствуют, проверяющий рекурсивный преобразователь МОЖЕТ включать отсутствующие параметры с полным списком.
Валидация рекурсивных распознавателей НЕ ДОЛЖНА устанавливать опции DAU, DHU и / или N3U в окончательном ответе клиенту-заглушке.
Рекурсивные распознаватели, которые не выполняют проверку, ДОЛЖНЫ скопировать опцию (-и) DAU, DHU и / или N3U, видимые в полученных запросах, поскольку они представляют пожелания проверяющего преобразователя нисходящего потока, который выдал исходный запрос.
Промежуточные прокси (см. Раздел 4.4.2 [RFC5625]), которые понимают, что DNS РЕКОМЕНДУЕТСЯ вести себя как сопоставимый рекурсивный преобразователь при работе с опциями DAU, DHU и N3U.
Когда авторитетный сервер видит в запросе опции (опции) DAU, DHU и / или N3U в мета-RR OPT, следует обычный алгоритм для обслуживания запросов. Опции НЕ ДОЛЖНЫ запускать какую-либо специальную обработку (например, фильтрацию RRSIG в ответах) на стороне сервера.
Если параметры присутствуют, но бит DO не установлен, сервер не выполняет обработку DNSSEC, которая включает в себя любую запись параметра (ов).
Если сервер видит одну (или несколько) опций, установленных со значениями RESERVED, сервер МОЖЕТ игнорировать перекодирование этих значений.
Авторитетные серверы НЕ ДОЛЖНЫ устанавливать опции DAU, DHU и / или N3U для каких-либо ответов. Эти значения устанавливаются только в запросах.
Анализ трафикаАдминистраторы зоны, которые планируют или выполняют операцию переноса криптографического алгоритма, должны отслеживать трафик DNS-запросов и записывать количество запросов, наличие OPT RR в запросах и значения параметра (ов) DAU / DHU / N3U. ) (если представить). Этот мониторинг можно использовать для измерения развертывания клиентского кода, который реализует (и сигнализирует) конкретные алгоритмы. Описание методов, используемых для захвата трафика DNS и измерения принятия нового алгоритма, выходит за рамки этого документа.
Администраторы зон, которым необходимо соблюдать изменения в политике безопасности своей организации (в отношении использования криптографического алгоритма), могут использовать эти данные, чтобы установить контрольные даты выполнения ролловера алгоритма. Например, администраторы зоны могут использовать данные, чтобы определить, когда устаревшие алгоритмы могут быть выведены из эксплуатации без нарушения работы значительного числа клиентов.
Чтобы свести это нарушение к минимуму, администраторы зоны должны дождаться завершения переключения алгоритма, пока подавляющее большинство клиентов не сообщит, что они распознают новый алгоритм. Это может быть порядка лет, а не месяцев.
Обратите внимание, что клиенты, которые не реализуют эти параметры, вероятно, будут более старыми реализациями, которые также не будут реализовывать какой-либо недавно развернутый алгоритм.
Коды алгоритмов, используемые для идентификации алгоритмов DNSSEC, алгоритмов хеширования DS RR и алгоритмов хеширования NSEC3, уже установлены IANA. Этот документ не стремится каким-либо образом изменить этот реестр.
IANA выделила коды опций 5, 6 и 7 для опций DAU, DHU и N3U, соответственно, в реестре «Коды опций DNS EDNS0 (OPT)». Три варианта имеют статус «стандарт».
Этот документ определяет способ для клиента передать свою цифровую подпись и информацию об алгоритме хеширования в кэш или сервер.
Он не предназначен для обсуждения превосходства алгоритмов. Сигналы являются необязательными кодами, содержащимися в мета-RR OPT, используемом с EDNS. Цель этих опций — сигнализировать о новом использовании алгоритма в клиентском коде, чтобы администраторы зон знали, когда можно завершить перенос алгоритма в зоне, подписанной DNSSEC.
Существует вероятность того, что подслушиватель или сервер может сделать вывод о том, что клиент использует валидатор по наличию опций AU и / или списка кодов алгоритма. Эта утечка информации сама по себе не очень полезна для потенциального злоумышленника, но ее можно использовать для идентификации валидатора или для сужения возможных реализаций валидатора, используемых клиентом, которые могут иметь известную уязвимость, которая может быть использована злоумышленником.
[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.
[RFC4033] Arends, R., Austein, R.
, Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Resource Records for the DNS Security Extensions», RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Protocol Modifications for the DNS Security Extensions», RFC 4035, March 2005.
[RFC5625] Bellis, R., «DNS Proxy Implementation Guidelines», BCP 152, RFC 5625, August 2009.
[RFC6891] Damas, J., Graff, M., and P. Vixie, «Extension Mechanisms for DNS (EDNS(0))», STD 75, RFC 6891, April 2013.
Steve Crocker
Shinkuro Inc.
5110 Edgemoor Lane
Scott Rose
NIST
100 Bureau Dr.
Gaithersburg, MD 20899
USA
Phone: +1-301-975-8439
EMail: [email protected]
Более четырех лет назад я написал подробную статью для Security Week , в которой описывался туннелирование и сигнализация системы доменных имен (DNS), а также их использование для вредоносных программ и других вредоносных действий, а также давались разумные советы о том, как с ними бороться..jpg)
с ними. Это было, конечно, до того, как появилось отличное решение проблемы, такое как служба Infoblox Threat Insight, которая автоматически выявляет такие злоупотребления.
Однако был важный вопрос, который я не упомянул в этой статье, и исследования, проведенные группой киберразведки Infoblox и инженерной группой, работающей над Threat Insight, недавно выдвинули эту проблему на передний план. При изучении очевидного трафика туннелирования/сигнализации DNS в клиентских сетях мы неоднократно сталкивались с аномальным трафиком, который выглядит как вредоносная деятельность, но на самом деле намеренно отправляется службами и пользователями в этих клиентских сетях и в целом не является вредоносным.
Позвольте мне сделать паузу, чтобы немного рассказать об истории. Система доменных имен была введена в 1983 году для преобразования имен, понятных людям, таких как www.infoblox.com, в IP-адреса, понятные компьютерам, например 161.47.10.70. DNS-запросы, как правило, представляют собой очень маленькие пакеты данных и НЕ предназначены для передачи каких-либо данных, кроме тех, которые необходимы для выполнения служб разрешения имен.
Обратите внимание, что с годами это немного изменилось с введением механизмов аутентификации, таких как DNSSEC и DKIM; однако эти цели по-прежнему служат для передачи информации о самом доменном имени, а не для передачи других данных.
Однако протокол DNS достаточно гибок, чтобы несвязанные данные можно было вставлять в запрос DNS и отправлять в целевую сеть или из нее. В простейшей форме это называется сигнализацией DNS, когда информация кодируется в строки запросов или в записи ответов, обычно с использованием криптографической хеш-функции. Поскольку пакеты DNS очень малы, это может означать, что для небольшого количества реальных данных требуется много пакетов, поэтому производительность довольно низкая. Туннелирование DNS идет еще дальше, используя DNS-запросы для кодирования других протоколов (например, http, ftp, smtp или даже пользовательских) через сеанс DNS. Это делается с помощью тех же основных методов, которые вы используете для кодирования других передач: например, как вы делаете для настройки сети VPN.
Infoblox Threat Insight обнаруживает обе эти методологии, и для простоты мы объединяем эти методы под названием туннелирования DNS, которое наиболее знакомо рынку.
Вредоносное DNS-туннелирование представляет собой серьезную проблему в области кибербезопасности, как указано в отчете об оценке безопасности Infoblox за второй квартал 2016 года, который мы опубликовали сегодня.
Специалисты по безопасности и сетевые службы, борющиеся со злонамеренным туннелированием DNS, обычно не знают о «творческом» использовании DNS для незлонамеренных коммуникаций, что потенциально может вызвать множество ложных тревог.
Почему это? Ну, потому что эти «законные» пользователи туннелирования DNS на самом деле не злоупотребляют сетями, в которых они работают, а просто творчески подходят к своим решениям. Большинство компаний, использующих эти методы, не афишируют свое несанкционированное и неразумное использование DNS. Это создает реальную проблему для сетевых защитников, которые ищут злоумышленников, использующих DNS для управления и контроля вредоносного ПО или кражи данных, поскольку эти действия выглядят почти идентичными невредоносным службам, которые злоупотребляют DNS.
О какой деятельности идет речь? Ну, все началось еще в 1990-х годах, когда некоторые предприимчивые, но скупые люди решили помочь себе бесплатного доступа в Интернет в отелях, аэропортах и т. д. Эти люди заметили, что, хотя они были заблокированы платными стенами от доступа к Интернету напрямую через стандартный такие протоколы, как HTTP, DNS не блокировались якобы для того, чтобы разрешать имена, чтобы вы могли платить! После объединения некоторого кода в последующие годы были выпущены такие инструменты, как NSTX, DNScat и iodine, которые позволяют вам туннелировать ваши веб-сеансы и, в конечном итоге, другие протоколы, такие как электронная почта, через ваше DNS-соединение. Немного медленно, но работало и было «бесплатно». Они развились, чтобы предоставлять полные услуги VPN через DNS, и сегодня существуют десятки таких инструментов, которые находятся в свободном доступе на Github и в других местах.
Итак, помимо очевидных опасений по поводу кражи услуг, почему туннелирование DNS является такой плохой идеей, особенно для корпоративных сетей? Помимо уже описанной ложной тревоги, использование DNS для передачи данных, по определению, является умышленным неправильным использованием протокола для преднамеренного обхода меры, введенной в действие сетевым оператором.
Это может быть что-то столь же относительно безобидное, как проксирование прошлых фильтров производительности на рабочем месте, которые могут блокировать Facebook или личные службы электронной почты, на что-то более зловещее, что может подвергнуть компанию риску. Доступ сотрудников к нелегальному контенту, вредоносное ПО, взаимодействующее с командно-контрольными службами, и множество других действий — это лишь верхушка айсберга.
Однако проблемы представляют собой не только туннели — многие злоумышленники используют DNS для «сигнализации», когда формальный «туннель» для другого протокола не настроен. Это часто имеет место в сценариях с продвинутыми постоянными угрозами (APT), когда данные эксфильтрируются низко и медленно, а также при управлении и контроле ботнета. Тот факт, что DNS является ужасным транспортным механизмом из-за его ограничений скорости и пропускной способности, не является проблемой для плохих парней в этих сценариях.
Однако получается лот коммерческих продуктов также используют сигнализацию DNS для предоставления квазилегитимных услуг по передаче данных.
Примерно в то время, когда туннели DNS только начинали развиваться, у некоторых производителей оборудования присутствия клиентов (CPE) возникали проблемы с получением обновлений для своих различных потребительских кабельных и DSL-модемов или Wi-Fi-маршрутизаторов и другого оборудования в потребительских сетях и сетях малого и среднего бизнеса.
Оказалось, что интернет-провайдеры непоследовательны в разрешении различных типов трафика, и заставить людей настроить правильные соединения через их маршрутизаторы на основе NAT было очень сложно. Да, но DNS предоставляет для этого удобный механизм, и вскоре у вас были компании, выполняющие обновления программного обеспечения и другие задачи обслуживания со своей установленной базой через DNS.
В то время как большинство сетевых устройств корпоративного уровня используют надлежащие каналы связи и аутентификации для решения этих задач, внутренние отделы и филиалы часто используют более дешевое оборудование CPE, поэтому даже в полномасштабной корпоративной сети эти сигналы передаются через DNS.
.
Некоторые поставщики антивирусных (A/V) продуктов стали сторонниками DNS по тем же причинам, и при необходимости почти непрерывной связи эта проблема очень заметна. Некоторые поставщики аудио/видео настроили процедуры идентификации хэшей файлов через DNS — если вы ищете хэш-значение для подозрительного файла через имя хоста в домене, управляемом этой аудио-/видеокомпанией, вы получите ответ, сообщающий вам заражен он или нет. Довольно ловко, но опять же, вы создаете канал связи, используя неправильный протокол и потенциально открывая свою сеть для вредоносных коммуникаций. Не забывайте, что вредоносной программой заражено более одного аудио/видеопродукта.
Существует множество других категорий продуктов и услуг, в которых одна или несколько компаний обратились к туннелированию DNS по аналогичным причинам. Черт возьми, наши команды даже определили системы, выполняющие обновления сетевого времени через DNS через сигнализацию, а не через NTP, хотя NTP на самом деле предназначен для этого и работает через UDP, как и DNS!
В идеале компаниям, которым необходимо выполнять обновления и другую утвержденную передачу данных на миллионы своих устройств, следует использовать хорошо зарекомендовавший себя канал, такой как HTTPS.
Если потребности слишком специфичны или не подходят для HTTPS, они должны работать с Инженерной группой Интернета (IETF), чтобы определить правильный протокол и/или метод для этих типов услуг, даже если это требует времени и затрат, хотя, конечно, ДНС бесплатный.
В конце концов, большая проблема с этими методами заключается в том, что они обходят средства контроля, установленные командой, управляющей этой сетью. Существует много причин для таких средств контроля, и их обход открывает проблемы безопасности, соответствия и эксплуатации, а также перегружает протокол DNS и системы обнаружения аномалий, проверяющие трафик DNS. Что еще хуже, эти компании, как правило, делают это без раскрытия информации или параметров конфигурации, чтобы предотвратить неправомерное использование DNS.
Хотя сомнительно, что все остановятся, мы хотели бы, чтобы ИТ-вендоры воздерживались от продолжения этой практики, так как это значительно усложняет работу по защите DNS. В наши дни все больше и больше организаций пытаются защитить DNS и начинают понимать, какая часть этого «мусорного» DNS-трафика на самом деле проходит в их сетях.
Возможно, согласованные действия по блокированию такого трафика могут разубедить производителей полагаться на него, но это может оказаться более тяжелым испытанием, если у вас есть установленная база, полагающаяся на это плохо работающее оборудование.
Иэн Шарп, главный технолог, ATIS | 23 апреля 2020 г.
Система доменных имен (DNS), которую часто называют «телефонной книгой Интернета», представляет собой ключевую сетевую функцию, преобразующую доменные имена (например, «atis.org») в уникальные числовые IP-адреса устройств. чтобы веб-браузеры и другие приложения могли загружать интернет-ресурсы. Поскольку DNS является критически важной сетевой функцией, ее надежность и безопасность имеют огромное значение. Сейчас вносятся важные изменения в безопасность протоколов DNS. Это повлияет на все организации, предлагающие услуги DNS или зависящие от функций, реализованных в DNS.
Почти все интернет-приложения полагаются на DNS, чтобы позволить клиенту найти нужный сервер и получить другую информацию, связанную с доменом. В настоящее время подавляющее большинство (приблизительно 80%) DNS-запросов в общедоступных сетях обрабатывается интернет-провайдером (ISP) пользователя. Это позволяет интернет-провайдерам использовать DNS для удовлетворения операционных потребностей и предоставления услуг. В управляемых частных сетях, принадлежащих предприятиям и другим организациям (например, школам), пользователи часто подключаются к выделенным службам DNS, которые предлагают специальные корпоративные службы, включая службы сетевой безопасности и частные сетевые пространства имен.
В настоящее время большая часть сигналов DNS отправляется с использованием протоколов, которые не поддерживают меры безопасности, что создает риски для конфиденциальности и безопасности пользователей. Таким образом, были определены новые протоколы, реализующие криптографическую безопасность DNS и конфиденциальность данных.
Эти изменения в технологии DNS и методах реализации теперь создают как проблемы, так и возможности.
IETF стандартизировала протоколы для использования зашифрованного DNS: DNS через HTTPS (DoH) и DNS через TLS (DoT). Эти технологии могут повысить безопасность протокола DNS, однако метод развертывания и функционирования этих протоколов в значительной степени не определен. Таким образом, браузеры и мобильные операционные системы используют множество различных подходов, которые могут кардинально изменить архитектуру Интернета и оказать заметное влияние на важные функции, основанные на DNS. Хотя использование DoT и DoH может иметь преимущества для безопасности и конфиденциальности пользователей, текущие разрозненные развертывания вызывают сложные проблемы для многих заинтересованных сторон. Для решения этих проблем необходимы как организационные, так и технические меры.
DoT и DoH имеют сходные свойства криптографической безопасности, но разные протоколы инкапсуляции влияют на конструкцию системы. DoT может дать сетям некоторое представление о трафике DNS, в то время как DNS поверх DoH более незаметен и делает упор на конфиденциальность (например, чтобы справиться со средами, в которых пользователь не доверяет локальной сети). Хотя пользовательские данные защищены в обоих протоколах, сетевые администраторы могут рассматривать это как проблему сетевой безопасности и конфиденциальности.
Несмотря на то, что реализация протоколов безопасности DNS может иметь ряд положительных преимуществ, она также может конфликтовать с важными сетевыми службами, которые в настоящее время широко внедряются на основе DNS. Эти услуги включают методы защиты от вредоносного ПО и выполнения юридических обязательств, возложенных на операторов сети. DoH имеет особые последствия для безопасности, поскольку он спроектирован так, чтобы быть устойчивым к простым подходам к применению политик и мониторингу в сети.
В недавно выпущенном отчете ATIS Технические последствия конфиденциальности и безопасности DNS для сценариев сетевых служб , описывается техническое влияние протоколов безопасности DNS в ряде сетевых сценариев и определяется влияние на системы в трех основных областях:
Это связано с тем, что поддержка конфиденциальности в DoT и DoH может помешать работе любых сетевых служб, реализованных в «средних ящиках», которые полагаются на запросы и ответы DNS в виде открытого текста.Технические последствия конфиденциальности и безопасности DNS для сценариев сетевых служб представлены сценарии, которые иллюстрируют некоторые из различных контекстов, в которых может использоваться DNS, причем каждый сценарий представляет различные соображения для развертывания DoT и DoH. Эти сценарии следует использовать для принятия решений клиентами и серверами, развертывающими DoT и DoH. Они также могут использоваться организациями, затронутыми DoT и DoH, для формулирования своей стратегии.
Отчет также содержит набор тем для обсуждения, которые интернет-провайдеры, а также другие стороны могут использовать для обсуждения этих тем с конечными пользователями, администраторами корпоративных сетей и внутренними заинтересованными сторонами. Наконец, в нем представлены ключевые рекомендации для различных заинтересованных сторон по поощрению сотрудничества между всеми заинтересованными сторонами для создания технических стандартов и передовых методов развертывания DoT и DoH.