Кратко

  • RRL сокращает повторные похожие ответы авторитетного сервера, когда поддельные UDP-запросы могут превратить его в усилитель отражённой атаки.
  • Вклад Paul Vixie был существенным, но не единоличным: ISC описывает совместные обсуждения защиты, а в записи о разработке BIND также назван Vernon Schryver.
  • Механизм объединяет классы ответов и диапазоны адресов клиентов. Это управление потоком трафика, а не аутентификация, атрибуция атаки или определение намерений.

Когда ответ становится нагрузкой для жертвы

При отражённой DNS-атаке запрос отправляется авторитетному серверу с подменённым адресом источника — адресом жертвы. Ответ сервера приходит жертве. Если он заметно больше исходного запроса, атакующий заставил сервер передать больший объём данных, чем отправил сам.

В презентации ISC 2014 года приведён пример: запрос ANY размером 36 байт для isc.org мог вызвать ответ объёмом 3 576 байт. Это иллюстрация механизма, а не универсальный коэффициент усиления для всего DNS-трафика. Размер зависит от запроса, содержимого зоны, DNSSEC, транспорта и конкретного ответа. Практический вопрос уже: сколько похожих ответов должен продолжать отправлять авторитетный сервер при повторении сходных запросов?

ISC сообщает, что к RRL привели внутренние обсуждения защитной стратегии с Полом Paul Vixie. В заявке на разработку BIND авторами исправления для BIND 9 названы Paul Vixie и Vernon Schryver. Публичные источники подтверждают важную роль Paul Vixie, но не историю об авторе-одиночке. Операционная проблема стала программным механизмом благодаря совместной работе и последующей настройке.

Профиль Internet Hall of Fame помещает этот эпизод в более широкую карьеру в DNS. В 1988 году Paul Vixie начал сопровождать BIND 4 в Digital Equipment Corporation, а позднее стал основным автором и техническим архитектором BIND 8. Он также основал MAPS, PAIX и Internet Software Consortium и получил докторскую степень в Keio University за работу, связанную с DNS и DNSSEC. Эти этапы показывают масштаб его деятельности, но не меняют совместного авторства RRL-патча, где назван и Schryver.

В BIND 9.9.4 RRL появился как необязательная функция сборки. В разделе ISC «BIND 9.10 Significant Changes» сказано, что позднее RRL вошёл в стандартную конфигурацию сборки. Это свидетельство доступности функции в BIND, но не её включения каждым оператором авторитетных серверов и не одинакового поведения всех DNS-продуктов.

Счётчик измеряет сходство, а не личность

В актуальном руководстве администратора BIND 9.20.29 описаны корзины токенов или кредитов, формируемые по сходству ответов и DNS-клиенту. Каждый ответ расходует кредит, который восполняется с заданной скоростью в течение временного окна. Оператор может ограничивать классы ответов: непустые ответы, NODATA, NXDOMAIN, делегирование, ошибки или все UDP-ответы. При превышении лимита BIND может отбрасывать или изменять отдельные ответы.

Слово «клиент» скрывает выбор политики. Документированные значения по умолчанию в BIND группируют IPv4-адреса по /24, а IPv6 — по /56: адреса одного блока учитываются вместе. За одним резолвером, компанией, университетом или провайдером доступа могут находиться множество не связанных между собой пользователей. Если один из них исчерпает лимит корзины, другой пользователь в том же префиксе может получить задержанный, усечённый или отсутствующий ответ.

Это не делает агрегацию по префиксу ошибкой автоматически. Ограничение на один адрес можно обходить, распределяя запросы между адресами; при атаке сервер также должен делить ограниченную исходящую пропускную способность. Однако ширина префикса, класс ответа и скорость имеют цену для доступности. Это явная операционная политика, а не нейтральное наблюдение за «настоящей» личностью клиента.

Настройка slip показывает компромисс особенно наглядно. При документированном значении по умолчанию slip=2 каждый второй ограниченный запрос без действительной серверной cookie получает уменьшенный ответ: BADCOOKIE, если клиент прислал cookie, иначе BIND выставляет бит усечения, чтобы резолвер повторил запрос по TCP. Некоторые ошибки нельзя усечь, поэтому они проходят с частотой, заданной slip. slip=1 отправляет усечённый ответ для каждого ограниченного ответа, отдавая приоритет целостности и доставке вместо максимального подавления отражённого трафика; slip=0 отбрасывает все ответы сверх лимита. Повторная попытка — часть конструкции защиты.

Роль службы определяет область применения

ISC рекомендует использовать RRL на авторитетных серверах. В документации также предупреждается, что на рекурсивных серверах он способен давать ложные срабатывания и замедлять клиентов, часто запрашивающих одни и те же имена; открытый рекурсивный доступ следует закрыть. Одна функция по-разному влияет на публичную авторитетную службу и на резолвер для конечных пользователей.

BIND предоставляет режим log-only, чтобы до включения ограничений наблюдать предполагаемые пороги. Среди счётчиков — RateDropped, QryDropped, RateSlipped и RespTruncated. Они показывают действие настройки, но не раскрывают личность атакующего. Наблюдаемый адрес источника может быть подменён; попадание в одну корзину не является атрибуцией.

Записка Heng Lu № 65 служит здесь только редакционной оптикой: фактическое поведение работающей реализации показывает, чем она управляет. Записка не является историческим свидетельством о Paul Vixie и не служит техническим источником о RRL. Для оценки важны работающая версия BIND, конфигурация, счётчики корзин и повторные попытки клиентов, а не наличие директивы в документе.

Подтверждённый источниками вывод ограничен. RRL может уменьшить вклад авторитетного сервера в отражённый поток похожих ответов. Одновременно он способен объединять легитимных пользователей и выбирать между доставкой и подавлением. Механизм не аутентифицирует запросы, не раскрывает мотив, не измеряет распространённость и не гарантирует, что жертва перестанет получать отражённый трафик. Вклад Paul Vixie точнее описать как участие в превращении операционной защиты в настраиваемую реализацию, пределы которой могут проверять операторы.

Источники