dxdt.ru: занимательный интернет-журнал

Вот спрашивают, что общего у DNS и радиолокации. Вообще, не так уж и много, но есть интересные параллели, о которых не часто задумываются.

Вот пример: если взглянуть на радары с немного иной, чем обычная, точки зрения, то окажется, что радар отправляет в окружающее его пространство особый “запрос”, “ответом” на который будут координаты некоторого объекта в “окружающем пространстве”. На первый взгляд, такая трактовка может показаться странной и отвлечённой. Тем не менее, главное – выбрать верный уровень абстракции. При ближайшем рассмотрении оказывается, что описанным образом моделируется работа множества вполне реальных импульсно-доплеровских РЛС в режиме сопровождения цели. В этом режиме станция отправляет ЭМ-импульсы в направлении цели (в конкретный “сегмент” окружающего пространства) и, на основе полученного “ответа” на “запрос” (отражённого сигнала), определяет новые координаты цели. Можно сказать, в ответ на запрос приходит информация об “адресации” цели в пространстве.

Неожиданно? Но в программном обеспечении систем наведения и управления, работающих с РЛС, именно так всё и происходит логически: спросили обновление координат цели у РЛС – получили ответ. DNS также отвечает на запросы: спросили про узел с заданным именем – получите ответ с IP-адресом.

А параллели начинаются дальше.

Одна из самых известных уязвимостей, связанных с DNS – “отравление кеша” (имеется в виду, понятно, кеш адресной информации резолверов и DNS-серверов). Исходная причина этой уязвимости в том, что некоторое специальное программное обеспечение не контролирует, от кого получает ответ на свой запрос, но при этом данные ответа трактует как заведомо достоверные, сохраняет в кеше и далее использует для адресации.

То есть, спросили некий DNS-сервер из “окружающего пространства Интернета” об адресе узла, пришёл ответ, а от кого он реально пришёл – от того сервера, который спрашивали, или нет – никто не проверяет. Более того, встречались и встречаются совсем уж “закритические” случаи, когда программное обеспечение при обработке “ответа” от сервера вообще не проверяет, а был ли сделан соответствующий запрос. При этом ложный ответ, который прислали злоумышленники, содержит неверную адресную информацию. В результате приложение, запросившее адрес сервера для некоторого домена, отправляется, скажем так, не туда.

Активные помехи, позволяющие срывать сопровождение цели РЛС, могут работать так: источник помех, например находящийся на борту цели, передаёт “атакующему” радару сигналы, имитирующие отражённые зондирующие импульсы радара, но при этом в имитацию вносятся искажения, изменяющие “вычисленную информацию” о цели на стороне радара. То есть, радар передаёт “запрос” – зондирующий импульс – в сторону цели и получает ложный “ответ”, похожий на отражённый целью сигнал, но на самом деле сгенерированный помехопостановщиком и содержащий неверные характеристики, реальный же “ответ” – отражение от цели – теряется из-за помех. В результате РЛС, действуя на основе ложной информации из поддельного ответа, вычисляет обновлённые координаты цели с ошибкой. За несколько итераций можно “увести” сигнал от реальной цели, так что после исчезновения помехи РЛС придётся искать цель заново.

Оба случая сильно похожи по логике явления: без проверки “валидности” источника “ответов” на свои “запросы”, и радар, и DNS-резолвер равно по одним и тем же причинам остаются с неверной информацией, оказываются одурачены. DNS-резолвер отправляет браузер интернет-пользователя на подставной фишинговый веб-сайт, а ракета с радаром пролетает мимо вражеского истребителя.

Да, конечно, причина в том, что логический фундамент при конструировании самых разных систем – он одинаковый.

При этом, как ни странно, и методы защиты схожи по логике их построения: тщательная верификация “ответов” на предмет их источника с привязкой к изменяющимся характеристикам “запроса”. Об этом, наверное, в следующий раз.

Такая субботняя заметка.

Адрес записки: https://dxdt.ru/2009/04/04/2243/