Как вычислять rate-limit для рекурсивного Bind?

Question

[Хесед]

Дан рекурсивный (разумеется для определённой сети, а не open resolver) Bind версии 9.10.1. Все параметры, касающиеся RRL подробно описаны в документации, однако вычисление конкретных значений проходит методом тыка.

/* текущая конфигурация */
rate-limit {
    ipv4-prefix-length 32;
    window 10;
    responses-per-second 20;
    errors-per-second 5;
    nxdomains-per-second 5;
    slip 2;
    exempt-clients {
        192.168.4.0/24;
    };
};

Пояснения:

• ipv4-prefix-length 32 - сегментация до индивидуального пользователя, а не подсетками по /24, как по умолчанию.
• errors-per-second 5 и nxdomains-per-second 5 - в более частых ответах SERVFAIL или NXDOMAIN никакой нужды нет.
• exempt-clients - исключения для служебной сети.
• responses-per-second 20 в window 10 секунд - это собственно сама магия. Вычислены эти значения были посредством наблюдения за логами и отловом легитимных запросов, попадающие под RRL. При значениях по умолчанию в RRL лог попадают запросы от:
  
  • Торрент-клиентов
  • Smart TV (в особенности LG)
  • Различных веб-приложений, интенсивно общающихся с CDN

На данный момент попытки вычислить правильные значения для responses-per-second и window привели меня к сидению в Wireshark'e, отслеживая и разглядывая запросы. Возможно, есть какой-то иной, более оптимальный и проверенный способ?

Answer 1

[brutal_lobster]

А нужен ли вам RRL? Клиенты будут рады, если их днс-запросы не будут проходить по причине волшебного числа на сервере? Вы ISP? Какая вам разница, сколько я запросов отправляю?)
Основная цель RRL - ограничение атак типа dns-amplification на authoritative сервера. К рекурсеру это слабо относится, разве что в случае записей с минимальным ttl. По вашей же ссылке об этом упоминается.

А так - почитайте про методики построения baseline в целом.

Собираете дампы по днс-запросам тем же tcpdump, с помощью tshark считаете количество запросов по каждому ойпи с различными окнами.
Либо можете написать скриптик для обработки биндового query-log. Может быть даже уже есть такой скриптик:)
Результат обрабатываете по типу bindgraph и смотрите приятные графики.

Comments

[Хесед]

Нужен, да - dnstop и чтение RRL-лого заставляет волосы шевелиться от количества паразитных запросов от ботов. Клиентов не одна и не две тысячи, многие из них являются частью ботнетов. На сервере включены DNSBL зоны, но "бомбёжка" нередка. Даже на текущем уровне фильтрации удалось уменьшить загрузку примерно в 7-9 раз. Сейчас как раз и идёт поиск "волшебных чисел" путём копания pcap логов. За ссылки на хорошие методики построения baseline буду исключитльно благодарен.

[brutal_lobster]

Нагугливается по ключевому слову за 5 минут же. Не нужно каких-то особых хороших методик. У вас есть пары зависимых значений - в вашем случае ip, кол-во запросов, размер окна, время и т.д. Вы собираете статистику и пытаетесь обнаружить корреляцию между ними - для того, чтобы успешно определять аномальные пары значений.

www.cisco.com/c/en/us/support/docs/availability/hi...

Понятно, что вы не хотите пропускать запросы ботнетов. Но рейтлимит не сильно подходит под корректную реализацию контроля - абсолютно не контролируемые false-positive. Или у вас клиенты-физики и вам всё равно?)

[Хесед]

brutal_lobster: Самые лютые ботнетчики в сети - это как-раз таки клиенты-юриков. Для них режим notification-only и индивидуальная работа. В любом случае, спасибо за ссылку, конструктив и пищу для размышлений. Пока самый значительный эффект проявился после отсекания DNSBL зон, может быть и ну его, этот RRL.