Это Канонический вопрос о защите общедоступных DNS-преобразователей
Открытые DNS-серверы кажутся довольно аккуратными и удобными, поскольку они предоставляют IP-адреса, которые мы можем постоянно использовать в нашей компании независимо от того, где они расположены. Google и OpenDNS предоставляют эту функцию, но я не уверен, что хочу, чтобы эти компании имели доступ к нашим DNS-запросам.
Я хочу создать что-то подобное для нашей компании, но я много слышу об этой опасной практике (особенно в отношении атаки усиления), и я хочу убедиться, что мы делаем это правильно. Что мне нужно иметь в виду при создании такой среды?
При этом вам нужно понять несколько вещей:
Большинство людей, которые хотят создать среду такого типа, - системные администраторы. Круто, я тоже системный администратор! Часть работы заключается в понимании того, где заканчиваются ваши обязанности и начинаются чьи-то обязанности, и поверьте мне, это не та проблема, которую системные администраторы могут решить самостоятельно. Вот почему:
Настроить преобразователь DNS с выходом в Интернет очень просто. Для его создания требуется гораздо меньше исследований, чем для понимания связанных с этим рисков. Это один из тех случаев, когда благие намерения непреднамеренно приводят к проступкам (и страданиям) других.
Иногда необходимо сравнить энтузиазм с действительностью. Вот несколько сложных вопросов, которые стоит задать себе:
Это что-то, что вы хотите создать по прихоти, или это то, что у вас есть несколько миллионов долларов, которые вы можете вложить в это правильно?
У вас есть специальная группа безопасности? Специальная команда по борьбе с насилием? Есть ли у них время циклов, чтобы справиться со злоупотреблением вашей новой инфраструктурой и жалобами, которые вы получите от внешних сторон?
У тебя есть законный команда?
Когда все это будет сказано и сделано, начнут ли все эти усилия хотя бы отдаленно окупаться, приносить прибыль компании или превышать денежную стоимость устранения неудобств, которые привели вас в этом направлении?
В заключение, я знаю, что эта ветка вопросов и ответов является своего рода разочарованием для большинства из вас, кто связан с ней. Serverfault здесь для предоставления ответов, и ответ «это плохая идея, не делайте этого» обычно не воспринимается как очень полезный. Некоторые проблемы намного сложнее, чем кажется вначале, и это одна из них.
если ты хотеть Чтобы попытаться заставить эту работу работать, вы все равно можете обратиться к нам за помощью, пытаясь реализовать такое решение. Главное понимать, что проблема в слишком большой сам по себе чтобы ответ был предоставлен в удобном формате вопросов и ответов. Вы должны уже потратить значительное количество времени на изучение темы и обратиться к нам с конкретный логические проблемы, с которыми вы столкнулись во время реализации. Цель этих вопросов и ответов - дать вам лучшее представление о более широкой картине и помочь вам понять Зачем мы не можем ответить на столь широкий вопрос, как этот.
Помогите нам сохранить безопасность в Интернете! :)
Независимо от того, используете ли вы открытый рекурсор DNS или авторитетный DNS-сервер, проблема одинакова, и большинство возможных решений также одинаковы.
Лучшее решение
Файлы cookie DNS - это предлагаемый стандарт, который дает DNS-серверам возможность требовать от клиентов отправки файлов cookie, чтобы доказать, что IP-адрес клиента не был подделан. Это будет стоить одного дополнительного обхода для первого поиска, что является наименьшими накладными расходами, которые может предложить любое решение.
Резерв для старых клиентов
Поскольку DNS-файлы cookie еще не стандартизированы, конечно, будет необходимо поддерживать старых клиентов сейчас и на долгие годы.
Вы можете ограничить количество запросов от клиентов без поддержки файлов cookie DNS. Но ограничения скорости позволяют злоумышленнику легко атаковать ваш 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.