Это канонический вопрос о защите общедоступных преобразователей DNS

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

Я хочу настроить что-то подобное для использования нашей компанией, но я много слышал о том, что это опасная практика (особенно в отношении атак усиления ), и я хочу убедиться, что мы делаем это правильно. Какие вещи мне нужно иметь в виду при создании среды такого типа?

Есть несколько вещей, которые вы должны понять, входя в это:

Это проблема сетевой инженерии.

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

• UDP - это протокол без сохранения состояния. Нет рукопожатия клиента.
• Запросы к DNS-серверу являются двухэтапной транзакцией без проверки подлинности (запрос, ответ). Сервер не может узнать, был ли подделан исходный IP-адрес, прежде чем он ответит.
• К тому времени, когда запрос достиг сервера, уже слишком поздно предотвращать поддельный пакет UDP. Подделка может быть предотвращена только с помощью практики, известной как входная фильтрация , тема которой освещена в документах BCP 38 и BCP 84 . Они реализуются сетевыми устройствами, расположенными перед вашим DNS-сервером.
• Мы не можем дать вам пошаговое руководство по настройке центра обработки данных от начала до конца или по внедрению этих лучших методов. Эти вещи очень специфичны для ваших собственных нужд. Формат вопросов и ответов просто не работает для этого, и этот сайт не предназначен для замены найма профессиональных людей для профессиональной работы.
• Не думайте, что ваша компания, которая слишком велика, чтобы обанкротиться, правильно внедрила входную фильтрацию.

Это не лучшая практика. Лучшая практика - не делать этого.

Настроить DNS-распознаватель в интернете очень просто. Для его создания требуется гораздо меньше исследований, чем для понимания рисков, связанных с этим. Это один из тех случаев, когда добрые намерения непреднамеренно допускают правонарушения (и страдания) других.

• Если ваш DNS-сервер ответит на любой исходный IP-адрес, который вы видите, вы используете открытый распознаватель. Они постоянно используются для усиления атак против невинных сторон. Новые системные администраторы открывают открытые средства распознавания каждый день , поэтому злоумышленникам выгодно постоянно их сканировать. На самом деле не возникает вопроса, будет ли ваш открытый распознаватель использоваться для атаки: с 2015 года это в значительной степени само собой разумеющееся. Это может быть не сразу, но это наверняка случится.
• Даже если вы применяете ACL с помощью своего программного обеспечения DNS (то есть BIND), все, что вам нужно, это ограничить количество поддельных DNS-пакетов, на которые будет отвечать ваш сервер. Важно понимать, что ваша DNS-инфраструктура может использоваться не только для атаки на устройства в ACL, но и на любые сетевые устройства между вашим DNS-сервером и устройствами, за которые он будет отвечать. Если у вас нет центра обработки данных, это проблема не только для вас.

Google и OpenDNS делают это, так почему я не могу?

Иногда необходимо сопоставить энтузиазм с реальностью. Вот несколько сложных вопросов, которые вы можете себе задать:

• Это то, что вы хотите настроить по прихоти, или у вас есть несколько миллионов долларов, чтобы инвестировать в это правильно?

• У вас есть специальная команда безопасности? Выделенная команда злоупотреблений? Есть ли у них обоих циклы, чтобы справиться со злоупотреблением вашей новой инфраструктурой и жалобами, которые вы получите от внешних сторон?

• У вас есть команда юристов ?

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

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

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

Помогите нам сохранить интернет в безопасности! :)

Независимо от того, используете ли вы открытый рекурсор DNS или авторитетный сервер DNS, проблема одна и та же, и большинство возможных решений также одинаковые.

Лучшее решение

DNS-файлы cookie - это предлагаемый стандарт, который позволяет DNS-серверам требовать от клиентов отправки файлов cookie, чтобы доказать, что IP-адрес клиента не был подделан. Это будет стоить одну дополнительную поездку туда и обратно при первом поиске, что является минимальными издержками, которые может предложить любое решение.

Резервный вариант для пожилых клиентов

Поскольку куки-файлы DNS еще не стандартизированы, конечно, будет необходимо поддерживать старых клиентов сейчас и на годы вперед.

Вы можете оценить ограничение запросов от клиентов без поддержки файлов cookie DNS. Но ограничения скорости облегчают злоумышленнику DoS вашего DNS-сервера. Помните, что некоторые DNS-серверы имеют функцию ограничения скорости, предназначенную только для авторитетных DNS-серверов. Поскольку вы спрашиваете о рекурсивном преобразователе, такие реализации ограничения скорости могут быть неприменимы к вам. Заданное ограничение скорости станет узким местом для вашего сервера, и, таким образом, злоумышленнику потребуется отправить вам меньше трафика, чтобы вызвать отклонение допустимых запросов, чем если бы не было ограничения скорости.

Одним из преимуществ ограничения скорости является то, что в случае, если злоумышленник затопит ваш DNS-сервер DNS-запросами, у вас, скорее всего, останется пропускная способность, которая позволит вам подключиться к серверу по ssh и исследовать ситуацию. Кроме того, ограничения скорости могут быть разработаны таким образом, чтобы в первую очередь отбрасывать запросы с клиентских IP-адресов, отправляющих много запросов, которых может быть достаточно, чтобы защитить вас от DoS от злоумышленников, которые не имеют доступа к подделке клиентских IP-адресов.

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

Использование TCP

Можно заставить клиента использовать TCP, отправив код ошибки, указывающий, что ответ слишком велик для UDP. Это имеет пару недостатков. Это стоит две дополнительные поездки туда и обратно. И некоторые неисправные клиенты не поддерживают это.

Стоимость двух дополнительных обращений может быть ограничена только первым запросом с использованием этого подхода:

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

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

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

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

Я не знаю, если какой-либо DNS-сервер реализовал этот подход.

Также сообщалось, что некоторые стеки TCP могут использоваться в атаках усиления. Это, однако, относится к любой службе на основе TCP, а не только к DNS. Такие уязвимости следует устранить путем обновления до версии ядра, где стек TCP был исправлен, чтобы не отправлять более одного пакета в ответ на пакет SYN.