Защита моего DNS-сервера Bind от медленных атак по отравлению кеша в стиле каминского

Дэн Камински описал, как DNS-серверы могут быть отравлены поддельными DNS-ответами [1]. Насколько я понимаю, проблема заключалась в том, что Камински нашел способ учитывать большинство других источников случайности в DNS-запросе, так что основным препятствием для злоумышленника было угадание идентификатора DNS-запроса (16 бит энтропии) при генерации поддельного ответ. В среднем злоумышленник может подделать ответ в пределах 32 тысяч предположений. Итак, рекомендуемое смягчение - случайное изменение исходного порта, все применили свои патчи, и все было хорошо.

За исключением того, что это только увеличило количество предположений с 32 тысяч до 134-4 тысяч. Конечно, это не может быть сделано быстро, но терпеливый злоумышленник может делать это медленно - на самом деле, Берт Хьюберт подсчитал, что атака со скоростью 100qps имеет 50% шанс успеха в течение 6 недель. [2]

У меня недостаточно репутации, чтобы размещать больше ссылок. Однако я вижу, что были рассмотрены многие технические подходы, такие как draft-wijngaards-dnsext-resolver-side-mitigation-01 и draft-vixie-dnsext-dns0x20-00 на tools.ietf.org, RFC5452, а также в Google Документы по безопасности общедоступного DNS:

1. Бит метки DNS 0x20 (т. Е. CAsE.gAmEs)

   • Bind делает это? Я не могу поверить, что Bind не реализовал бы то, что предлагала Викси
   • тем не менее, атака может вызвать запрос доменов, регистр которых нельзя существенно изменить. например. "d293823."

2. Группировка RTT, выбор IPv4 / IPv6, рандомизация исходного адреса (от wijngaards)

   • Я не думаю, что это значительно увеличит энтропию, но я бы сделал это, если Bind сможет.

3. Запрос полномочий для NS / nameserver / A / AAAA после направления (от wijngaards)

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

4. Счетчик неисправностей в режиме атаки

   • Может ли это сделать Bind?
   • Однако, если у меня есть брандмауэр с отслеживанием состояния перед DNS-сервером, счетчик проблем DNS-сервера никогда не увидит поддельные ответы, поступающие с неправильным портом назначения, верно?

5. Откат к TCP (особенно после перехода в режим атаки)

6. Спросите дважды / трижды (особенно после перехода в режим атаки)

7. Удаление повторяющихся запросов (из Google Public DNS)

К сожалению, я не вижу никаких параметров конфигурации для их включения даже в последней версии Bind.

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

[1] http://s3.amazonaws.com/dmk/DMK_BO2K8.ppt

[2] http://ds9a.nl/har-presentation-bert-hubert-3.pdf слайд 24.