Уязвимость Каминского: ставим экстренные патчи DNS и меняем регламент

Вчера Дэн Каминский опубликовал подробности уязвимости DNS cache poisoning, которую он держал под замком с января. Всё это время он координировал выпуск патчей с вендорами в режиме тихого NDA - ISC, Microsoft, Cisco и ещё несколько игроков получили детали заранее и готовили фиксы параллельно. Итог: 8 июля патчи вышли одновременно. Редкое зрелище в индустрии, где обычно кто-то опаздывает или сливает за неделю до объявления.

Нам от этого не легче - надо ставить быстро.

Что за баг и почему это серьёзно

Отравление кэша DNS - не новая история, атаки на кэш описывали ещё в конце девяностых. Но Каминский нашёл способ делать это практически в реальном времени, без долгого ожидания удачного совпадения. Суть в предсказуемости transaction ID и исходного порта в DNS-запросах: если оба предсказуемы, атакующий может подменить ответ от авторитетного сервера до того, как он дойдёт до резолвера, и скормить кэшу поддельную запись.

Классический Kaminsky-метод эксплуатирует то, что резолвер спрашивает у авторитетного сервера не только саму запись, но и дополнительные данные (additional records). Атакующий флудит ответами с разными transaction ID, зная, что исходный порт фиксирован. С современными скоростями сетей это вопрос секунд, не часов.

Что это значит на практике: если кто-то отравил кэш вашего резолвера, пользователи могут попасть на поддельный сайт вместо настоящего - и браузер об этом не скажет.

Что и как мы патчили

У нас в сопровождении несколько десятков DNS-резолверов - смесь BIND на Linux и Windows DNS на контроллерах домена. Утро 9 июля началось с инвентаризации: где что стоит, какие версии, у кого уже включена рандомизация порта источника.

Картина оказалась ожидаемо пёстрой.

BIND. Большинство резолверов на BIND 9.4.x и 9.5.x. Патч вышел в виде 9.4.3 и 9.5.1-P1. На Debian и Ubuntu подтянулся через apt уже к утру; на CentOS и RHEL пришлось ждать несколько часов - EPEL и remi сработали быстрее, чем официальные репозитории вендоров. Несколько серверов пришлось патчить вручную через tarball с src.isc.org, потому что ждать было нельзя.

Windows DNS. Microsoft выпустила KB951748 - патч для Windows Server 2003 и 2008. На машинах с включённым Windows Update патч подтянулся штатно; на тех, где автообновление отключено (а таких немало в production-среде), поставили вручную через wsus или прямой msu-файл. Перезагрузка DNS-службы после установки обязательна - не лень было убедиться.

Временной ориентир от начала работы до завершения патчинга всех объектов - около восьми часов. Не рекорд, но и не катастрофа.

Проверяем рандомизацию через инструмент Каминского

Каминский вместе с раскрытием выложил онлайн-тест на doxpara.com - сервис проверяет, насколько предсказуем исходный порт вашего резолвера. Принцип простой: резолвер делает несколько запросов к серверу Каминского, тот смотрит, с каких портов приходят пакеты, и оценивает разброс.

Хорошая энтропия - это разброс от 1024 до 65535, желательно равномерный. Плохая - один фиксированный порт или маленький диапазон вроде 32768-32800, что встречалось на старых конфигурациях BIND без явного указания query-source.

Мы прогнали тест по всем резолверам до патча и после. До патча примерно треть показала недостаточную рандомизацию - либо порт был фиксирован, либо диапазон узкий. После - все прошли. Для BIND рандомизация включается в 9.4.3/9.5.1-P1 автоматически; можно явно указать в named.conf:

options {
    query-source address * port *;
};

Звёздочка в port означает «случайный из всего диапазона» - именно это и нужно.

Что поменяли в регламенте патчинга

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

Договорились с клиентами на несколько изменений:

• Критические патчи безопасности (CVSS 9+, активная эксплуатация). Ставим в течение 24 часов с момента выхода, уведомляем по факту, не заранее. Отдельный пункт в договоре о сопровождении.
• Высокий приоритет (CVSS 7-8, нет активной эксплуатации). Окно в течение 72 часов, уведомление за час.
• Плановые обновления. Остаются как были - согласованное окно раз в месяц.

Часть клиентов поморщилась от пункта про «уведомляем по факту», но в итоге согласились. Аргумент один: если DNS-резолвер отравят и пользователи окажутся на фишинговой странице, объяснять это клиенту куда неприятнее, чем «мы поставили патч без предупреждения».

Что не сделали и почему

DNSSEC как решение на корневом уровне - тема отдельная. Протокол есть, RFC есть, поддержка в BIND 9.x есть. Но цепочка доверия сейчас не замкнута: корневые зоны DNSSEC-подписанными не являются, коммерческих зон подписано мало. Развёртывать DNSSEC на резолвере при отсутствии подписанных зон - работа ради чувства собственной правоты, не ради реальной защиты. Мониторим ситуацию, но сейчас это не приоритет.

Временное решение - рандомизация порта плюс своевременный патч. Это то, что реально работает здесь и сейчас.