Преимущества безопасности

Введение: угрозы безопасности DNS и меры по их устранению

Из-за открытой распределенной структуры системы доменных имен и использования в ней протокола пользовательских дейтаграмм (UDP) DNS уязвим для различных форм атак. Общедоступные или «открытые» рекурсивные преобразователи DNS особенно подвержены риску, поскольку они не ограничивают входящие пакеты набором допустимых исходных IP-адресов. В основном нас интересуют два распространенных типа атак:

  • Спуфинговые атаки, приводящие к отравлению кеша DNS. Существует множество различных типов спуфинга и подделки DNS, целью которых является перенаправление пользователей с законных сайтов на вредоносные веб-сайты. К ним относятся так называемые атаки Каминского , при которых злоумышленники получают авторитетный контроль над всей зоной DNS.
  • Атаки типа «отказ в обслуживании» (DoS). Злоумышленники могут запускать DDoS-атаки против самих распознавателей или захватывать распознаватели для запуска DoS-атак на другие системы. Атаки, которые используют DNS-серверы для запуска DoS-атак на другие системы, используя большой размер записи/ответа DNS, известны как атаки с усилением .

Каждый класс атак обсуждается ниже.

Атаки с отравлением кеша

Существует несколько вариантов атак с подменой DNS, которые могут привести к отравлению кеша, но общий сценарий выглядит следующим образом:

  1. Злоумышленник отправляет целевому преобразователю DNS несколько запросов на доменное имя, для которого, как ему известно, сервер не является полномочным и которое вряд ли находится в кэше сервера.
  2. Преобразователь отправляет запросы другим серверам имен (чьи IP-адреса злоумышленник также может предсказать).
  3. Тем временем злоумышленник наводняет сервер-жертву поддельными ответами, которые, как представляется, исходят от делегированного сервера имен. Ответы содержат записи, которые в конечном итоге разрешают запрошенный домен в IP-адреса, контролируемые злоумышленником. Они могут содержать записи ответов для разрешенного имени или, что еще хуже, они могут дополнительно делегировать полномочия серверу имен, принадлежащему злоумышленнику, чтобы получить контроль над всей зоной.
  4. Если один из поддельных ответов совпадает с запросом распознавателя (например, по имени запроса, типу, идентификатору и исходному порту распознавателя) и получен до ответа от подлинного сервера имен, распознаватель принимает поддельный ответ и кэширует его, а затем отбрасывает. подлинный ответ.
  5. На будущие запросы для скомпрометированного домена или зоны отвечают поддельные разрешения DNS из кэша. Если злоумышленник указал очень большое время жизни для поддельного ответа, поддельные записи остаются в кэше как можно дольше без обновления.

Отличное введение в атаки Каминского можно найти в иллюстрированном руководстве по уязвимости DNS Каминского .

DoS-атаки и атаки с усилением

Резолверы DNS подвержены обычным DoS-угрозам, от которых страдает любая сетевая система. Тем не менее, атаки с усилением вызывают особую озабоченность, поскольку преобразователи DNS являются привлекательными целями для злоумышленников, которые используют большое соотношение размеров ответов и запросов преобразователей для получения дополнительной бесплатной полосы пропускания. Резолверы, поддерживающие EDNS0 (механизмы расширения для DNS), особенно уязвимы из-за значительно большего размера пакета, который они могут вернуть.

В сценарии усиления атака происходит следующим образом:

  1. Злоумышленник отправляет запросы DNS-серверу жертвы, используя поддельный исходный IP-адрес. Запросы могут быть отправлены из одной системы или из сети систем, использующих один и тот же поддельный IP-адрес. Запросы предназначены для записей, которые, как известно злоумышленнику, приведут к гораздо большим ответам, в несколько десятков раз превышающим размер исходных запросов (отсюда и название «атака с усилением»).
  2. Сервер-жертва отправляет большие ответы на исходный IP-адрес, переданный в поддельных запросах, перегружая систему и вызывая ситуацию DoS.

Смягчения

Стандартным общесистемным решением уязвимостей DNS является DNSSEC . Однако до тех пор, пока он не будет реализован повсеместно, открытые преобразователи DNS должны самостоятельно принимать некоторые меры для смягчения последствий известных угроз. Было предложено много методов; см. IETF RFC 5452: Меры по повышению устойчивости DNS к поддельным ответам для обзора большинства из них. В Google Public DNS мы внедрили и рекомендуем следующие подходы:

  • Защита вашего кода от переполнения буфера, особенно кода, отвечающего за синтаксический анализ и сериализацию сообщений DNS.
  • Избыточное выделение машинных ресурсов для защиты от прямых DoS-атак на сами резолверы. Поскольку злоумышленникам несложно подделать IP-адреса, невозможно заблокировать запросы на основе IP-адреса или подсети; единственный эффективный способ справиться с такими атаками — просто поглотить нагрузку.
  • Внедрение базовой проверки достоверности пакетов ответа и достоверности сервера имен для защиты от простого отравления кеша. Это стандартные механизмы и проверки работоспособности, которые должен выполнять любой распознаватель кэширования, соответствующий стандартам.
  • Добавление энтропии к сообщениям запросов , чтобы снизить вероятность более сложных атак спуфинга/отравления кеша, таких как атаки Каминского. Существует множество рекомендуемых методов добавления энтропии. Ниже мы даем обзор преимуществ, ограничений и проблем каждого из этих методов и обсуждаем, как мы реализовали их в Google Public DNS.
  • Удаление повторяющихся запросов для борьбы с вероятностью «атак дня рождения».
  • Запросы ограничения скорости для предотвращения DoS-атак и атак с усилением.
  • Мониторинг службы для клиентских IP-адресов, использующих наибольшую пропускную способность и имеющих самое высокое соотношение размера ответа к запросу.

DNSSEC

Стандарт расширений безопасности доменных имен (DNSSEC) указан в нескольких RFC IETF: 4033 , 4034 , 4035 и 5155 .

Резолверы, которые реализуют атаки с отравлением кэша счетчика DNSSEC, проверяя подлинность ответов, полученных от серверов имен. Каждая зона DNS поддерживает набор пар закрытый/открытый ключ, и для каждой записи DNS генерируется и шифруется уникальная цифровая подпись с использованием закрытого ключа. Затем соответствующий открытый ключ аутентифицируется через цепочку доверия ключами, принадлежащими родительским зонам. Резолверы, совместимые с DNSSEC, отклоняют ответы, не содержащие правильных подписей. DNSSEC эффективно предотвращает подделку ответов, поскольку на практике подписи практически невозможно подделать без доступа к закрытым ключам.

По состоянию на январь 2013 г. Google Public DNS полностью поддерживает DNSSEC. Мы принимаем и пересылаем сообщения в формате DNSSEC и проверяем ответы на предмет правильной аутентификации. Мы настоятельно рекомендуем другим резольверам сделать то же самое.

Мы также кэшируем ответы NSEC, как указано в IETF RFC 8198: агрессивное использование кэша с проверкой DNSSEC . Это может уменьшить количество запросов NXDOMAIN к серверам имен, реализующим DNSSEC и использующим NSEC для отрицательных ответов.

Зашифрованные транспорты на стороне клиента

Google Public DNS предлагает поддержку зашифрованных транспортных протоколов, DNS через HTTPS и DNS через TLS . Эти протоколы предотвращают несанкционированное вмешательство, прослушивание и спуфинг, значительно повышая конфиденциальность и безопасность между клиентом и Google Public DNS. Они дополняют DNSSEC для обеспечения сквозного поиска DNS с проверкой подлинности.

Внедрение базовой проверки достоверности

Некоторое повреждение кэша DNS может быть вызвано непреднамеренными и не обязательно злонамеренными несоответствиями между запросами и ответами (например, из-за неправильно настроенного сервера имен, ошибки в программном обеспечении DNS и т. д.). Как минимум, DNS-преобразователи должны проводить проверки для подтверждения достоверности и релевантности ответов серверов имен. Мы рекомендуем (и внедряем) все следующие средства защиты:

  • Не устанавливайте бит рекурсии в исходящих запросах и всегда явно следуйте цепочкам делегирования. Отключение рекурсивного бита гарантирует, что ваш распознаватель будет работать в «итеративном» режиме, так что вы явно будете запрашивать каждый сервер имен в цепочке делегирования, а не позволите другому серверу имен выполнять эти запросы от вашего имени.
  • Отклонять подозрительные ответные сообщения. Подробнее о том, что мы считаем «подозрительным», см. ниже.
  • Не возвращайте записи A клиентам на основе связующих записей, кэшированных из предыдущих запросов. Например, если вы получаете запрос клиента для ns1.example.com, вам следует повторно разрешить адрес, а не отправлять запись A на основе кэшированных связующих записей, возвращенных с сервера имен TLD .com.

Отклонение ответов, которые не соответствуют требуемым критериям

Google Public DNS отклоняет все перечисленное ниже:

  • Неразборчивые или искаженные ответы.
  • Ответы, в которых ключевые поля не соответствуют соответствующим полям в запросе. Сюда входят идентификатор запроса, исходный IP-адрес, исходный порт, целевой IP-адрес или имя запроса. См. RFC 5452, раздел 3 для полного описания поведения подмены DNS.
  • Записи, не относящиеся к запросу.
  • Записи ответов, для которых мы не можем восстановить цепочку CNAME.
  • Записи (в ответе, полномочиях или дополнительных разделах), для которых отвечающий сервер имен не заслуживает доверия. Мы определяем «доверие» к серверу имен по его месту в цепочке делегирования для данного домена. Google Public DNS кэширует информацию о цепочке делегирования, и мы сверяем каждый входящий ответ с кэшированной информацией, чтобы определить надежность ответа отвечающего сервера имен на конкретный запрос.

Добавление энтропии к запросам

Как только распознаватель выполняет базовые проверки работоспособности, злоумышленник должен завалить распознаватель жертвы ответами, пытаясь сопоставить идентификатор запроса, порт UDP (запроса), IP-адрес (ответа) и имя запроса оригинала. запрос до того, как это сделает законный сервер имен.

К сожалению, этого нетрудно добиться, так как единственное уникально идентифицирующее поле, идентификатор запроса, имеет длину всего 16 бит (т. е. вероятность того, что он будет правильным, равна 1/65 536). Диапазон других полей также ограничен, поэтому общее количество уникальных комбинаций относительно невелико. См. RFC 5452, раздел 7 для расчета используемой комбинаторики.

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

Мы представили обновленный обзор упомянутых здесь методов на конференции DNS OARC 38 в июле 2022 года. В презентацию также включены рекомендации для операторов серверов имен.

Рандомизация исходных портов

В качестве основного шага никогда не позволяйте исходящим пакетам запросов использовать UDP-порт по умолчанию 53 или использовать предсказуемый алгоритм для назначения нескольких портов (например, простое увеличение). Используйте настолько широкий диапазон портов от 1024 до 65535, насколько это возможно в вашей системе, и используйте надежный генератор случайных чисел для назначения портов. Например, Google Public DNS использует ~ 15 бит, что позволяет использовать примерно 32 000 различных номеров портов.

Обратите внимание, что если ваши серверы развернуты за брандмауэрами, балансировщиками нагрузки или другими устройствами, выполняющими трансляцию сетевых адресов (NAT), эти устройства могут дерандомизировать порты для исходящих пакетов. Убедитесь, что вы настроили устройства NAT для отключения дерандомизации портов.

Случайный выбор серверов имен

Некоторые преобразователи при отправке запросов на корневой сервер, TLD или другие серверы имен выбирают IP-адрес сервера имен на основе кратчайшего расстояния (задержки). Мы рекомендуем рандомизировать IP-адреса назначения, чтобы добавить энтропии к исходящим запросам. В Google Public DNS мы просто случайным образом выбираем сервер имен среди настроенных серверов имен для каждой зоны, отдавая предпочтение быстрым и надежным серверам имен.

Если вы беспокоитесь о задержке, вы можете использовать диапазон времени приема-передачи (RTT) , который состоит из рандомизации в диапазоне адресов, которые находятся ниже определенного порога задержки (например, 30 мс, 300 мс и т. д.).

DNS-куки

RFC 7873 определяет параметр EDNS0 для добавления 64-битных файлов cookie в сообщения DNS. Клиент, поддерживающий файлы cookie DNS, включает случайный 64-разрядный файл cookie и дополнительно (если он известен) серверный файл cookie в запросе. Если вспомогательный сервер считает, что параметр cookie в запросе действителен, он отражает в ответе файл cookie клиента и правильный файл cookie сервера. Поддерживающий клиент может затем убедиться, что ответ пришел от ожидаемого сервера, проверив файл cookie клиента в ответе.

Если сервер имен не поддерживает файлы cookie DNS, для добавления энтропии можно использовать следующие два параметра.

Случайный регистр в именах запросов

Стандарты DNS требуют, чтобы серверы имен обрабатывали имена без учета регистра. Например, имена example.com и EXAMPLE.COM должны разрешаться в один и тот же IP-адрес 2 . Кроме того, все серверы имен, кроме небольшого меньшинства, возвращают обратно имя в ответе, как оно появилось в запросе, сохраняя исходный регистр.

Следовательно, еще один способ добавить энтропии к запросам — случайным образом изменить регистр букв в запрашиваемых доменных именах. Этот метод, также известный как «0x20», поскольку бит 0x20 используется для установки регистра букв US-ASCII, был впервые предложен в интернет-проекте IETF «Использование бита 0x20 в метках DNS для улучшения идентификации транзакций» . При использовании этого метода ответ сервера имен должен соответствовать не только имени запроса, но и регистру каждой буквы в строке имени; например, wWw.eXaMpLe.CoM или WwW.ExamPLe.COm . Это может немного добавить энтропии или совсем не добавить ее к запросам для доменов верхнего уровня и корневых доменов, но это эффективно для большинства имен хостов.

Одна существенная проблема, которую мы обнаружили при реализации этой техники, заключается в том, что некоторые серверы имен не следуют ожидаемому поведению ответа:

  • Некоторые серверы имен отвечают с полной нечувствительностью к регистру: они правильно возвращают одни и те же результаты независимо от регистра в запросе, но ответ не соответствует точному регистру имени в запросе.
  • Другие серверы имен отвечают с полным учетом регистра (в нарушение стандартов DNS): они обрабатывают эквивалентные имена по-разному в зависимости от регистра в запросе, либо вообще не отвечая, либо возвращая неверные ответы NXDOMAIN, которые точно соответствуют регистру имени в запросе. запрос.
  • Некоторые DNS-серверы работают корректно, за исключением PTR-запросов в зоне arpa .

Для обоих этих типов серверов имен изменение регистра имени запроса приведет к нежелательным результатам: для первой группы ответ будет неотличим от поддельного ответа; для второй группы ответ (если он есть) может быть совершенно неправильным.

Наше текущее решение этой проблемы состоит в том, чтобы использовать рандомизацию регистра только для серверов имен, которые, как мы знаем, правильно применяют стандарты. Мы также перечисляем соответствующие поддомены исключений для каждого из них на основе анализа наших журналов. Если ответ, который, по-видимому, пришел с этих серверов, не содержит правильного регистра, мы отклоняем ответ. Включенные серверы имен обрабатывают более 70% нашего исходящего трафика.

Добавление одноразовых меток к именам запросов

Если преобразователь не может напрямую преобразовать имя из кэша или не может напрямую запросить авторитетный сервер имен, он должен следовать рекомендациям от корневого сервера имен или сервера имен TLD. В большинстве случаев запросы к корневым серверам имен или серверам имен TLD приведут к обращению к другому серверу имен, а не к попытке преобразовать имя в IP-адрес. Поэтому для таких запросов должно быть безопасно прикреплять случайную метку к имени запроса, чтобы увеличить энтропию запроса, не рискуя ошибкой разрешить несуществующее имя. То есть, отправка запроса на ссылающийся сервер имен для имени с префиксом одноразовой метки, например entriih-f10r3.www.google.com , должна вернуть тот же результат, что и запрос для www.google.com .

Хотя на практике такие запросы составляют менее 3% исходящих запросов, при условии нормального трафика (поскольку на большинство запросов можно ответить непосредственно из кеша или одним запросом), это именно те типы запросов, которые злоумышленник пытается заставить решатель для выдачи. Таким образом, этот метод может быть очень эффективным для предотвращения эксплойтов в стиле Каминского.

Реализация этого метода требует, чтобы одноразовые метки использовались только для запросов, которые гарантированно приведут к переходу; то есть ответы, которые не содержат записей в разделе ответов. Однако при попытке определить набор таких запросов мы столкнулись с рядом проблем:

  • Некоторые серверы имен TLD с кодом страны (ccTLD) фактически являются полномочными для других TLD второго уровня (2LD). Хотя у них две метки, 2LD ведут себя так же, как TLD, поэтому они часто обрабатываются серверами имен ccTLD. Например, серверы имен .uk также являются авторитетными для зон mod.uk и nic.uk и, следовательно, для имен хостов, содержащихся в этих зонах, таких как www.nic.uk , www.mod.uk и т. д. Другими словами, запросы к серверам имен ccTLD для разрешения таких имен хостов приведут не к направлениям, а к авторитетным ответам; добавление одноразовых меток к таким именам хостов сделает имена неразрешимыми.
  • Иногда серверы имен общего TLD (gTLD) возвращают неавторизованные ответы для серверов имен. То есть некоторые имена серверов имен находятся в зоне рДВУ, а не в зоне их домена. gTLD будет возвращать неавторизованный ответ для этих имен хостов, используя любую связующую запись, которая есть в его базе данных, вместо того, чтобы возвращать ссылку. Например, сервер имен ns3.indexonlineserver.com раньше находился в зоне рДВУ .COM , а не в зоне indexonlineserver.com . Когда мы отправили запрос на сервер gTLD для n3.indexonlineserver.com , мы получили для него IP-адрес, а не реферал. Однако, если мы добавляли одноразовую метку, мы получали ссылку на indexonlineserver.com , который затем не мог разрешить имя хоста. Поэтому мы не можем добавлять одноразовые метки для серверов имен, требующих разрешения от сервера рДВУ.
  • Полномочия для зон и имен хостов со временем меняются. Это может привести к тому, что имя хоста с nonce-префиксом, которое когда-то было разрешимым, станет неразрешимым, если изменится цепочка делегирования.

Чтобы решить эти проблемы, мы настроили исключения для имен хостов, для которых мы не можем добавлять одноразовые метки. Согласно нашим журналам серверов, это имена хостов, для которых серверы имен TLD возвращают нереферальные ответы. Мы постоянно пересматриваем список исключений, чтобы убедиться, что он остается актуальным с течением времени.

Удаление повторяющихся запросов

Преобразователи DNS уязвимы для «атак дня рождения», называемых так потому, что они используют математический «парадокс дня рождения», в котором вероятность совпадения не требует большого количества входных данных. Атаки по случаю дня рождения включают в себя наводнение сервера-жертвы не только поддельными ответами, но и первоначальными запросами, в расчете на то, что преобразователь выдаст несколько запросов для разрешения одного имени. Чем больше количество отправленных исходящих запросов, тем выше вероятность того, что злоумышленник сопоставит один из этих запросов с поддельным ответом: злоумышленнику нужно всего порядка 300 запросов в процессе для 50%-й вероятности успеха при сопоставлении с поддельным ответом. ответ и 700 запросов для почти 100% успеха.

Чтобы защититься от этой стратегии атаки, вы должны обязательно отбросить все повторяющиеся запросы из исходящей очереди. Например, Google Public DNS никогда не допускает более одного необработанного запроса для одного и того же имени запроса, типа запроса и IP-адреса назначения.

Запросы ограничения скорости

Предотвращение атак типа «отказ в обслуживании» ставит перед открытыми рекурсивными преобразователями DNS несколько особых проблем:

  • Открытые рекурсивные преобразователи являются привлекательными целями для запуска усиливающих атак. Это серверы с высокой пропускной способностью и высокой надежностью, которые могут генерировать ответы большего размера, чем типичный авторитетный сервер имен, особенно если злоумышленник может внедрить большой ответ в их кэш. Любой разработчик открытой службы DNS обязан предотвратить использование своих серверов для запуска атак на другие системы.
  • Атаки усиления может быть трудно обнаружить, когда они происходят. Злоумышленники могут запустить атаку через тысячи открытых распознавателей, так что каждый распознаватель видит только небольшую часть общего объема запросов и не может извлечь четкий сигнал о том, что он был скомпрометирован.
  • Вредоносный трафик должен быть заблокирован без каких-либо нарушений или деградации службы DNS для обычных пользователей. DNS является важной сетевой службой, поэтому отключение серверов для предотвращения атаки не является вариантом, равно как и отказ в обслуживании любого заданного клиентского IP-адреса на слишком долгое время. Резолверы должны иметь возможность быстро блокировать атаку, как только она начинается, и восстанавливать полностью работоспособный сервис, как только атака заканчивается.

Наилучший подход к борьбе с DoS-атаками — ввести механизм ограничения скорости или «дросселирования». Google Public DNS реализует два вида контроля скорости:

  • Контроль скорости исходящих запросов к другим серверам имен. Чтобы защитить другие DNS-серверы имен от DoS-атак, которые могут быть запущены с наших серверов-преобразователей, Google Public DNS применяет ограничения QPS для исходящих запросов от каждого обслуживающего кластера для каждого IP-адреса DNS-сервера.

  • Контроль скорости исходящих ответов клиентам. Чтобы защитить любые другие системы от усиления и традиционных распределенных DoS-атак (ботнетов), которые могут быть запущены с наших серверов-резольверов, Google Public DNS выполняет два типа ограничения скорости клиентских запросов:

    • Для защиты от традиционных атак, основанных на томе, каждый сервер налагает ограничения на количество запросов в секунду и среднюю пропускную способность для каждого IP-клиента.
    • Для защиты от атак с усилением, в которых используются большие ответы на небольшие запросы, каждый сервер применяет максимальный средний коэффициент усиления для каждого IP-адреса клиента. Средний коэффициент усиления — это настраиваемое отношение размера ответа к размеру запроса, определяемое на основе исторических шаблонов трафика, наблюдаемых в журналах нашего сервера.

    Если DNS-запросы с одного исходного IP-адреса превышают максимальную скорость QPS, лишние запросы будут отброшены. Если DNS-запросы по UDP с одного исходного IP-адреса постоянно превышают среднюю пропускную способность или предел усиления (случайный большой ответ будет пропущен), запросы могут быть отброшены или может быть отправлен только небольшой ответ. Маленькие ответы могут быть ответом с ошибкой или пустым ответом с установленным битом усечения (чтобы большинство допустимых запросов повторялись через TCP и завершались успешно). Не все системы или программы будут повторять попытки через TCP, а DNS через TCP может быть заблокирован брандмауэрами на стороне клиента, поэтому некоторые приложения могут работать неправильно, когда ответы усекаются. Тем не менее усечение позволяет RFC-совместимым клиентам работать правильно в большинстве случаев.

  1. Примеры см. в документе Атаки с усилением DNS , а также хорошее обсуждение проблемы в целом. ↩

  2. RFC 1034, раздел 3.5 говорит: ↩

    Обратите внимание, что хотя в именах доменов разрешены буквы верхнего и нижнего регистра, регистр не имеет значения. То есть два имени с одинаковым написанием, но разным регистром следует рассматривать как идентичные.