Какие уязвимости безопасности предоставляет DNSSEC?

Я планировал подписать мою зону DNS с DNSSEC. Моя зона, регистратор и мой DNS-сервер (BIND9) поддерживают DNSSEC. Единственный, кто не поддерживает DNSSEC, это мой вторичный поставщик серверов имен (а именно buddyns.com ).

На своем сайте они заявляют это в отношении DNSSEC:

BuddyNS не поддерживает DNSSEC, потому что он подвержен некоторым уязвимостям, не подходящим для службы DNS большого объема.

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

Что это за "уязвимые места"?

DNSSEC имеет некоторые риски, но они не связаны напрямую с отражением или усилением. В этом случае расширение размера сообщения EDNS0 - это красная сельдь. Позволь мне объяснить.

Любой обмен пакетами, который не зависит от предыдущего подтверждения личности, подвергается злоупотреблению со стороны злоумышленников DDoS, которые могут использовать этот обмен пакетами без проверки подлинности в качестве отражателя и, возможно, также в качестве усилителя. Например, ICMP (протокол, стоящий за «ping») может быть использован таким образом. Как и пакет TCP SYN, который запрашивает до 40 пакетов SYN-ACK, даже если SYN был подделан, чтобы прийти от какой-то жертвы, которая не хочет эти пакеты SYN-ACK. И, конечно, все службы UDP уязвимы для этой атаки, включая NTP, SSDP, uPNP и, как отмечалось в других ответах, включая DNS.

Большинство устройств обнаружения вторжений, предотвращения вторжений и балансировки нагрузки являются узкими местами, которые не в состоянии справиться с трафиком со «скоростью линии». Также многие маршрутизаторы не могут работать на скорости линии, а некоторые коммутаторы. Эти узкие места, будучи самым маленьким «на пути» и меньшим, чем сами ссылки, являются реальной целью DDoS-атак на основе перегрузки. Если вы можете держать чей-то брандмауэр занятым трафиком атаки, то хороший трафик не будет проходить, даже если ссылки не заполнены. И то, что замедляет брандмауэр, это не общее количество бит в секунду (которое может быть увеличено с помощью более крупных сообщений, как это делают EDNS0 и DNSSEC), а скорее общее количество пакетов в секунду.

Существует множество городских легенд о том, как DNSSEC делает DDoS хуже из-за большего размера сообщения DNSSEC, и хотя это имеет интуитивный смысл и «звучит хорошо», это просто ложь. Но если бы в этой легенде была доля правды, реальный ответ был бы в другом месте - [потому что DNSSEC всегда использует EDNS0, но EDNS0 можно использовать без DNSSEC], и многие нормальные ответы, отличные от DNSSEC, равны DNSSEC. ответ будет. Рассмотрим записи TXT, используемые для представления политик SPF или ключей DKIM. Или просто любой большой набор адресов или записей MX. Короче говоря, никакая атака не требует DNSSEC, и, следовательно, любое внимание к DNSSEC как риску DDoS является нерациональной энергией.

DNSSEC имеет риски! Его сложно использовать, и его сложнее правильно использовать. Часто это требует нового рабочего процесса для изменения данных зоны, управления регистратором, установки новых экземпляров сервера. Все это должно быть проверено и задокументировано, и всякий раз, когда что-то ломается, связанное с DNS, технология DNSSEC должна быть исследована как возможная причина. И конечный результат, если вы все сделаете правильно, будет заключаться в том, что, как подписавшая подпись зоны, ваш собственный онлайн-контент и системы будут более хрупкими для ваших клиентов. В результате, как оператора сервера на дальнем конце, контент и системы других пользователей будут более хрупкими для вас. Считается, что эти риски перевешивают преимущества, поскольку единственным преимуществом является защита данных DNS от изменения или замены в полете. Эта атака настолько редка, что не стоит всех этих усилий. Мы все надеемся, что DNSSEC когда-нибудь станет вездесущим благодаря появлению новых приложений. Но правда в том, что сегодня DNSSEC - это все затраты, без выгоды и с высокими рисками.

Поэтому, если вы не хотите использовать DNSSEC, это ваша прерогатива, но не позволяйте никому вводить вас в заблуждение, что проблема DNSSEC заключается в его роли в качестве усилителя DDoS. DNSSEC не играет необходимой роли в качестве усилителя DDoS; Существуют и другие, более дешевые способы использования DNS в качестве усилителя DDoS. Если вы не хотите использовать DNSSEC, пусть будет так, потому что вы еще не выпили помощь Kool и вы хотите быть последним (позже), а не первым (сейчас).

Серверы содержимого DNS, иногда называемые «авторитетными серверами», должны быть защищены от использования в качестве усилителей, отражающих DNS, поскольку DNS использует UDP и потому что UDP может использоваться пакетами с поддельным источником. Способ защиты сервера содержимого DNS от такого рода злоупотреблений состоит не в блокировании UDP, не в принудительном использовании TCP (с использованием трюка TC = 1), ни в блокировании ЛЮБОГО запроса, ни в отказе от DNSSEC. Ничто из этого не поможет вам. Вам нужно ограничение скорости ответов DNS(DNS RRL), полностью бесплатная технология, которая теперь присутствует на нескольких серверах имен с открытым исходным кодом, включая BIND, Knot и NSD. Вы не можете исправить проблему отражения DNS с помощью своего брандмауэра, потому что только контент-ориентированный промежуточный ящик, такой как сам DNS-сервер (с добавленным RRL), знает достаточно о запросе, чтобы иметь возможность точно угадать, что является атакой, а что нет. Я хочу еще раз подчеркнуть: DNS RRL является бесплатным, и каждый сервер авторизации должен его запускать.

В заключение я хочу разоблачить свои предубеждения. Я написал большую часть BIND8, изобрел EDNS0, и я изобрел DNS RRL. Я работаю над DNS с 1988 года как 20 с чем-то, и теперь я сердитый с 50 с чем-то, с меньшим и меньшим терпением к полуиспеченным решениям неправильно понятых проблем. Пожалуйста, примите мои извинения, если это сообщение звучит слишком похоже на "эй, дети, убирайтесь с моего газона!"

Я знаю две специфические уязвимости. Есть отражение / усиление, упомянутое Хоканом. И есть возможность зонного перечисления.

Отражение / усиление

Отражение означает атаки, при которых запросы с поддельным IP-адресом отправляются на DNS-сервер. Поддельный хост является основной жертвой атаки. DNS-сервер неосознанно отправит ответ хосту, который никогда его не запрашивал.

Усиление относится к любой атаке отражения, в которой отраженный ответ состоит из большего количества байтов или большего количества пакетов, чем исходный запрос. До DNSSEC + EDNS0 усиление таким способом позволит отправлять только до 512 байтов. С DNSSEC + EDNS0 можно отправить 4096 байт, что обычно занимает 3-4 пакета.

Существуют возможные меры по снижению этих атак, но я не знаю ни одного DNS-сервера, реализующего их.

Если IP-адрес клиента не подтвержден, DNS-сервер может отправить усеченный ответ, чтобы заставить клиента переключиться на TCP. Усеченный ответ может быть таким же коротким, как и запрос (или более коротким, если клиент использует EDNS0, а ответ - нет), что исключает усиление.

Любой клиентский IP-адрес, который завершает квитирование TCP и отправляет запрос DNS на соединение, может быть временно внесен в белый список. После внесения в белый список IP получает возможность отправлять UDP-запросы и получать UDP-ответы размером до 512 байт (4096 байт при использовании EDNS0). Если ответ UDP вызывает сообщение об ошибке ICMP, IP снова удаляется из белого списка.

Этот метод также может быть изменен с помощью черного списка, что означает, что IP-адреса клиентов по умолчанию разрешают запрашивать через UDP, но любое сообщение об ошибке ICMP приводит к тому, что IP-адрес заносится в черный список, и для выхода из черного списка требуется запрос TCP.

Растровое изображение, охватывающее все соответствующие адреса IPv4, может храниться в 444 МБ памяти. Адреса IPv6 должны быть сохранены другим способом.

Перечисление зон

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

Проблема, которая все еще сохраняется даже при использовании NSEC3, заключается в том, что злоумышленник может найти хэш каждой метки, просто запросив случайные имена. Как только у атакующего есть все хэши, на эти хэши может быть проведена атака грубой силы.

Надлежащая защита от перечисления зон потребует от злоумышленника выполнения запроса на полномочный сервер для каждого предположения. Однако в DNSSEC такой защиты не существует.

То, что приходит на ум, на самом деле относится не к DNSSEC, а к расширению EDNS0, на которое опирается DNSSEC.

EDNS0 допускает большие полезные нагрузки UDP, а большие полезные нагрузки UDP могут позволить худшие атаки отражения / усиления трафика.

Я не знаю, каков процент проверяющих распознавателей, но популярное программное обеспечение серверов имен, по-видимому, поставляется с проверкой по умолчанию, и можно легко найти некоторых известных поставщиков услуг, которые открыто о них делают проверку, таких как Comcast и общедоступные распознаватели Google.

Исходя из этого, я думаю, что процент проверяемых распознавателей, вероятно, находится в значительно лучшей форме, чем процент подписанных зон.