Я прочитал много статей на эту тему и не понимаю, как возможно отравление кэша, если:
- запрос отменяется и помечается как неудачный, если идентификатор транзакции ответа не совпадает (т.е. злоумышленники не могут подобрать идентификатор транзакции методом подбора, поскольку будет принят только первый ответ)
- Рекурсивный резолвер отправляет только 1 запрос для одного и того же домена/типа/класса за раз, что означает, что злоумышленники не могут инициировать много запросов для одного и того же домена, чтобы подобрать идентификатор транзакции методом подбора
В этой конфигурации, которая выглядит простой, как возможно отравление кэша, если злоумышленникам нужно угадать идентификатор транзакции? Заставят ли злоумышленники рекурсивный резолвер снова и снова разрешать один и тот же домен, чтобы иметь больше попыток? В таком случае это может занять часы...
решение1
В основном неточен первый пункт вашего списка:
- запрос отменяется и помечается как неудачный, если идентификатор транзакции ответа не совпадает (т.е. злоумышленники не могут подобрать идентификатор транзакции методом подбора, поскольку будет принят только первый ответ)
При получении неизвестного идентификатора транзакции этот ответ отбрасывается. Но ваше предположение о том, что невыполненный запрос каким-то образом считается неудачным, неверно.
По сути, этот сценарий атаки превращается в гонку для злоумышленника, который должен получить действительный ответ до того, как придет ответ от настоящего сервера имен.
Проблема с вашим предположением в том, что весь смысл идентификатора транзакции (+ исходный порт UDP) заключается в том, чтобы сопоставить ответ с невыполненным запросом, но когда есть ответ, в котором эти значения неверны (не соответствуют ни одному запросу), как вы можете определить, какой запрос следует считать неудачным?
И если бы вы разрешили некоторую форму частичного соответствия, как бы вы реализовали это таким образом, чтобы не заменить довольно обременительную гонку для злоумышленника на тривиально эксплуатируемую DoS-атаку?
Варианты «реальной» защиты:
- DNSSEC позволяет инициатору запроса проверять подлинность записей в ответе, что гарантирует, что сгенерированный злоумышленником ответ не будет принят для имен в подписанных зонах.
- Для запросов от некоторых форм клиентов/пересылок к серверу-резолверу DoT и DoH также позволяют избежать проблемы отравления кэша.для этого конкретного "прыжка"(DoT/DoH защищают только канал связи между двумя хостами, разрешения DNS, как правило, имеют несколько таких «прыжков»).
(Даже просто запрос по TCP улучшает конкретный сценарий в вопросе, но решения на основе криптографии, очевидно, гораздо шире с точки зрения того, с какими атаками они борются.)