Что виды уязвимостей системы обеспечения безопасности делает обеспечение DNSSEC, выставляют?
Я планировал подписать свою зону DNS с DNSSEC. Моя зона, регистратор и мой сервер DNS (BIND9) вся поддержка DNSSEC. Единственный, кто не поддерживает DNSSEC, является моим вторичным поставщиком сервера имен (а именно, buddyns.com).
На их веб-сайте они заявляют этот относительно DNSSEC:
BuddyNS не поддерживает DNSSEC, потому что он подвергает некоторым уязвимостям, неподходящим к большому объему сервис DNS.
Ну, я думал, что использование DNSSEC в настоящее время так или иначе сомнительно, поскольку большинство сопоставителей не проверяет, подписываются ли записи правильно. То, что я не знал, было то, что - согласно их оператору - это походит, если это выставило бы уязвимости системы обеспечения безопасности некоторого вида.
Каковы те "vulnerabilites"?
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 Aid и хотите быть последним (позже), а не первым (сейчас).
Серверы содержимого 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, и все меньше и меньше терплю недолговечные решения неправильно понятых проблем. Примите мои извинения, если это сообщение звучит слишком похоже на «Эй, дети, убирайтесь с моей лужайки!»
На ум приходит не конкретное DNSSEC, а расширение EDNS0, на которое опирается DNSSEC.
EDNS0 допускает большие полезные нагрузки UDP, а большие полезные нагрузки UDP могут допускать худшие атаки отражения / усиления трафика.
Я не знаю, каков процент проверяющих преобразователей, но популярное программное обеспечение серверов имен, похоже, поставляется с проверкой по умолчанию и можно легко найти некоторых известных поставщиков услуг, которые открыто заявляют о том, что они проводят валидацию, таких как Comcast и общедоступные преобразователи Google.
Исходя из этого, я думаю, что процент валидирующих преобразователей, вероятно, в значительно лучшей форме, чем процент подписанных зон.
Мне известно о двух конкретных уязвимостях. Есть отражение / усиление, упомянутое Хоканом. Также существует возможность перечисления зон.
Отражение / усиление
Отражение означает атаки, при которых запросы с поддельным 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 такой защиты не существует.