Mirai кладёт Dyn: Twitter недоступен, и мы идём проверять DNS клиентов

21 октября с утра начали приходить сообщения о том, что Twitter, GitHub, Reddit, Spotify, Netflix и ещё пара десятков заметных сервисов недоступны из Европы и восточного побережья США. К обеду выяснилось, что атака была направлена не на сами сервисы, а на их DNS-провайдера - компанию Dyn. Ботнет Mirai накатил волнами, DNS-инфраструктура Dyn легла, и все клиенты, которые использовали Dyn как основного или единственного поставщика DNS-резолюции, пошли вслед за ней.

Мы тогда как раз разбирали исходники Mirai после их публикации в конце сентября. Атака на Dyn стала первой по-настоящему публичной демонстрацией того, что этот ботнет умеет в масштабе.

Что именно произошло

Mirai генерирует трафик с заражённых IoT-устройств - IP-камеры, роутеры, NVR-рекордеры с дефолтными паролями. Мы разбирали механику раньше: устройств в ботнете сотни тысяч, каждое может выдать несколько сотен мегабит, суммарный объём атаки - терабиты в секунду.

Dyn - авторитативный DNS-провайдер. Это не тот DNS, который стоит у вас на ноутбуке или в офисе как резолвер; это сервис, который хранит и отдаёт NS-записи для доменов клиентов. Когда браузер хочет узнать, по какому IP доступен twitter.com, запрос в конечном счёте доходит до авторитативного сервера. Если авторитативный сервер не отвечает - домен перестаёт резолвиться, и не важно, что сами серверы Twitter стоят и работают.

Именно это и произошло. Серверы Twitter физически никуда не делись. Просто никто не мог узнать их адрес - потому что Dyn под атакой не успевал отвечать на запросы.

Dyn гасили атаку несколько часов, сервис восстанавливался волнами. Всего три волны атак с небольшими перерывами - видимо, оператор проверял, насколько успешно Dyn митигирует. К вечеру сервис вернулся в норму.

Почему это зацепило таких гигантов

Twitter, GitHub, Netflix - не маленькие компании с самодельной инфраструктурой. У них серьёзные команды, бюджеты, дублирование на всех уровнях. Но DNS они доверили единственному провайдеру.

Это не глупость и не халтура - это обычная практика. Dyn - один из серьёзных игроков на рынке managed DNS с хорошей репутацией и гео-распределённой инфраструктурой. Аргументы в пользу одного провайдера понятны: единый интерфейс управления, согласованное время TTL, одна точка ответственности, предсказуемое поведение при изменениях. Технических причин разделять нагрузку между двумя DNS-провайдерами до этой атаки у большинства команд просто не было в приоритете.

После 21 октября эта логика выглядит иначе.

Что мы начали проверять у клиентов

DNS-зависимость - это не та проблема, которая сразу бросается в глаза при аудите. Проверяют firewall, сегментацию сетей, пароли, обновления. DNS-резервирование оказывается где-то на периферии, если вообще оказывается.

Мы включили в аудит инфраструктуры несколько дополнительных проверок.

Первое - на сколько авторитативных серверов настроены критичные домены. Стандарт - минимум два NS-сервера, желательно в разных AS (автономных системах). Если оба NS-сервера у одного провайдера в одной AS - один инцидент может положить оба. Это мы смотрим через dig NS domain.ru +short и проверяем ASN через whois.

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

Третье - какой TTL на A-записях критичных доменов. Если TTL выставлен в 300 секунд - резолверы клиентов будут обращаться к авторитативному серверу каждые 5 минут. Если авторитативный сервер лёг - через 5 минут кеш протух и домен перестаёт резолвиться. Если TTL 86400 - сутки работаем на кеше. Это двусторонняя история: низкий TTL хорош для быстрой смены IP, высокий - для устойчивости к падению провайдера. Баланс зависит от того, что для конкретного домена важнее.

Четвёртое - есть ли процедура смены DNS-провайдера при аварии. Звучит банально, но в нескольких инфраструктурах мы обнаружили, что доступ к панели управления DNS есть у одного человека, который сейчас в отпуске, а пароли нигде не задокументированы. Аварийный план в таком виде не работает.

Что находим

Картина у большинства клиентов примерно одинаковая. Корпоративный сайт на одном NS-провайдере, почтовые MX-записи там же, никакого резервного делегирования. TTL в диапазоне 3600-14400 - это компромисс между удобством управления и устойчивостью, но не осознанный выбор, а просто дефолт конкретной панели управления.

Самих клиентов это обычно удивляет. Не потому что они не знали про DNS - просто никогда не думали о нём как о точке отказа. Почта резервируется, серверы резервируются, бекапы настроены. DNS - «просто стоит и работает», никто не трогает.

История с Dyn показывает, что DNS - такая же инфраструктура со своими точками отказа. Просто обычно она настолько стабильна, что это незаметно.

Что рекомендуем делать

Для большинства клиентов минимальный набор - это добавить второй NS-провайдер для критичных доменов (корпоративный сайт, почта, внешние сервисы). Настройка занимает несколько часов: нужно зарегистрироваться у второго провайдера, перенести зонный файл, добавить NS-записи в делегирование у регистратора домена.

Дополнительно - поднять TTL на A и MX записях критичных доменов до разумных значений (несколько часов), если домен не требует частых изменений. Кеш резолверов на несколько часов - это буфер, который даёт время на реакцию при проблемах у провайдера.

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

Что именно произошло с Dyn в деталях - они сами пока не публиковали детальный разбор, так что оцениваем по публичным данным и поведению трафика. Но механика понятна уже сейчас, и она достаточна, чтобы сделать правильные выводы.