Я планировал подписать свою зону 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 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, и все меньше и меньше терплю недолговечные решения неправильно понятых проблем. Примите мои извинения, если это сообщение звучит слишком похоже на "Эй, дети, убирайтесь с моей лужайки!"
Я знаю две конкретные уязвимости. Есть отражение / усиление, упомянутое Хаканом. И есть возможность перебора зон.
Отражение / усиление
Отражение означает атаки, при которых запросы с поддельным исходным 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.
Исходя из этого, я думаю, что процент проверяющих резолверов, вероятно, находится в значительно лучшей форме, чем процент подписанных зон.