Серый список DNS и длинные интервалы повторных попыток - стандартная практика?
Интернет-провайдер моей компании внедрил то, что я буду называть DNS "серый список" (или у него есть проблема с конфигурацией) - они блокируют входящие DNS-запросы между парами [IP-адрес преобразователя, IP-адрес сервера], которые не пытались выполнить запрос в последние 60 лет. секунд. Таким образом, если первый запрос завершается неудачно, последующие запросы выполняются успешно, если с предыдущей попытки прошло менее 60 секунд. Я предполагаю, что это должно скрыть хосты от сканирования при условии, что законный распознаватель будет повторять запрос. Возможно, они даже блокируют все UDP-пакеты для борьбы со сканированием портов, но я пока не нашел способа проверить это.
Оказывается, что устройства Cisco IronPort обычно имеют интервал повторения, превышающий 60 секунд. (15 секунд, чтобы попробовать каждый дополнительный DNS-сервер, затем 60 секунд, прежде чем повторить попытку основного). Моя компания не может получать электронную почту от большинства организаций с устройствами IronPort.
Мне кажется, что по крайней мере одно из этих поведений просто неправильно. Итак, мои вопросы:
1) Каковы рекомендуемые интервалы повторения для DNS-распознавателей? Можете ли вы сослаться на RFC или другой источник, или это фактический отраслевой стандарт?
2) Является ли DNS или UDP "серый список" стандартной практикой? Рекомендации?
РЕДАКТИРОВАТЬ - некоторые дополнительные детали фона:
Это затрагивает оба DNS-сервера моей компании, как и основной сервер имен нашего провайдера. Их вторичные серверы имен, которые на самом деле находятся за пределами их сети, и серверы имен, находящиеся в восходящем направлении от любых уязвимых хостов, не затрагиваются У нас также есть второй провайдер, и DNS-запросы, поступающие по этому маршруту, не блокируются. Трассировки пакетов на нашем внешнем брандмауэре показывают, что мы отвечаем на все полученные запросы DNS - отброшенные запросы не доставляются в наши сети. Моя главная цель при задании этого вопроса - получить стандартный документ, показывающий нашему провайдеру (или, что менее вероятно, Cisco), что его поведение нарушено и его необходимо исправить.
1 ответ
DNS-серверы делятся на несколько разных групп:
- Авторитетный сервер
- Общественный рекурсор
- Непубличный рекурсор
Ни в одном из этих случаев не имеет смысла пытаться скрыть их существование. Авторитетные DNS-серверы должны быть общедоступными, чтобы выполнять задачу, для которой они были созданы. Публичный рекурсор бессмыслен, если вы пытаетесь скрыть его существование. И если вы запускаете рекурсор, который не должен быть публичным, то вместо того, чтобы пытаться скрыть его, просто блокируйте запросы к нему от неавторизованного IP-адреса клиента.
Судя по вашему вопросу, кажется, что DNS-сервер, о котором вы спрашиваете, является авторитетным для вашей зоны. Поэтому я предполагаю, что это авторитетный DNS-сервер.
Как авторитетные DNS-серверы, так и общедоступные рекурсоры получают запросы от произвольных клиентских IP-адресов, и это означает, что они потенциально могут быть использованы в атаках с усилением.
К сожалению, протокол DNS не обеспечивает хорошей защиты от таких атак. Поведение, которое вы описываете, может быть очень плохой попыткой защитить от таких атак.
Существуют способы, с помощью которых DNS-сервер может защитить от атак с усилением, не оказывая такого влияния, как вы описываете.
- Не применяйте контрмеры, когда никакой атаки не происходит. Вместо этого ищите ответы об ошибках ICMP, которые может вызвать атака, и применяйте контрмеры, когда возможная атака была обнаружена.
- Не отбрасывайте запросы, вместо этого отправьте ответ без раздела ответа и установите усеченный бит. Это приведет к тому, что любой правильный DNS-клиент будет повторять попытки, используя TCP.
- Так как TCP более устойчив к спуфингу, ответы можно отправлять, не беспокоясь об атаках с усилением.
- Запомните IP-адреса, которые успешно запрашиваются по TCP. Те могут быть разрешены для запроса через UDP в будущем.
То, что я здесь описываю, не является официальной передовой практикой, насколько мне известно, лучшее, что вы можете сделать для защиты от атак усиления с использованием протокола DNS, как это выглядит сегодня. Я не знаю ни о какой фактической реализации этого подхода.