Два месяца после Dyn: пересматриваем DNS-архитектуру и разбираемся с IoT на свитчах

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

DNS: от разовой проверки к архитектурному решению

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

Главный нюанс, который вылез в нескольких клиентских инфраструктурах: два NS-сервера у одного провайдера - это не резервирование. Это ощущение резервирования. Когда упал Dyn, упали все их серверы разом - и неважно, что их NS1 стоит в Нью-Йорке, а NS2 в Амстердаме. Оператор один, пул адресов один, атака накрывает весь диапазон.

Реальное резервирование - это два независимых провайдера с разными AS. Технически это несложно: у большинства регистраторов можно прописать NS-серверы от разных компаний в одну делегационную запись. Зонный файл придётся синхронизировать - вручную или через AXFR, в зависимости от возможностей провайдеров. Это уже организационный процесс, который нужно поддерживать: поменял A-запись у основного провайдера - не забудь обновить у резервного. Некоторые провайдеры предлагают автоматическую синхронизацию через механизм secondary DNS - это удобнее, но таких пар нужно подбирать заранее.

Резервный рекурсивный резолвер - отдельная история. Это не про авторитативный DNS для ваших доменов, а про то, куда ходят ваши машины за именами. Часть клиентов держит внутренние резолверы (BIND или Unbound) и форвардит всё наружу на один-два адреса провайдера. Если провайдерский резолвер недоступен - внутри сети ничего не резолвится, даже если с авторитативными серверами всё хорошо. Минимальная страховка: добавить второй форвардер от другого провайдера или общедоступные резолверы (8.8.8.8/8.8.4.4 от Google, 208.67.222.222/208.67.220.220 от OpenDNS). Это не панацея, но сильно снижает вероятность полного DNS-ступора внутри офиса.

IoT на уровне свитча: почему VLAN в одиночку не спасает

Сегрегацию IoT в отдельный VLAN мы рекомендовали ещё в сентябре. За ноябрь посмотрели, как это реально реализовано там, где клиенты успели что-то сделать. Оказалось, что VLAN есть, но часть защитных свойств упущена на уровне конфигурации свитча.

Типичная схема: камеры видеонаблюдения вынесены в VLAN 30, серверный сегмент в VLAN 10, офис в VLAN 20. Маршрутизация между ними закрыта на уровне ACL на L3-свитче или роутере. Выглядит разумно. Но если посмотреть на конфигурацию портов доступа в IoT-VLAN - там, как правило, включён CDP/LLDP, не настроен port security, не включён DHCP snooping и не отключён spanning tree portfast с BPDU guard.

Это означает, что устройство, подключённое в IoT-порт, может попробовать представиться коммутатором (BPDU), попытаться отравить DHCP-кеш или переполнить таблицу MAC-адресов до state flooding. До серверного сегмента оно так не доберётся, если ACL настроены правильно, но устроить хаос в самом IoT-VLAN - вполне.

Минимальный набор на портах IoT-устройств:

• DHCP snooping - чтобы скомпрометированное устройство не раздавало ложные адреса соседним камерам.
• Dynamic ARP Inspection - защита от ARP-спуфинга внутри VLAN; опирается на таблицу DHCP snooping, поэтому включается в связке.
• Port security с ограничением по числу MAC-адресов - один порт, один MAC. Камера не должна вдруг «увидеть» сотню устройств за собой.
• BPDU guard - запрет STP-пакетов с клиентского порта.

На оборудовании Cisco это стандартные команды, на HP/Aruba - аналоги есть, называются чуть иначе. Конфигурация занимает час на весь коммутатор доступа, если заранее составить шаблон.

Что дальше

Полноценный аудит инфраструктуры сейчас включает оба направления - DNS-архитектуру и конфигурацию свитчей в части IoT-сегрегации. Это связанные вещи: атака на Dyn показала, что вектор угрозы идёт от IoT-устройств к DNS-инфраструктуре - не напрямую, а через объём трафика. Закрыть один конец без другого - полумера.

Что не сделали до сих пор - прокси-резолверы с логированием DNS-запросов из IoT-VLAN. Это дало бы видимость: какие внешние хосты камеры опрашивают, есть ли аномальные паттерны запросов. Реализуемо через тот же Unbound с query logging или через Pi-hole, который несколько клиентов уже рассматривают как вариант для офисного блокирования рекламы - его можно переориентировать на мониторинг IoT-трафика. Пока это в обсуждении, не в реализации.

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