Наша почта:
В Москве:
РФ (звонок бесплатный):
Бункер для админки: как спрятать точки управления от злоумышленников
{ Старший менеджер департамента IT в ООО Никольская Консалтинг }
Иван Пименов

Видео доклада

Презентация спикера

Бункер для админки
Сеть управления — один из тех элементов инфраструктуры, о котором вспоминают в последнюю очередь, а расплачиваются за него первыми. Доклад посвящён трудностям, с которыми можно столкнуться при проектировании и построении сети управления, и разбору гипотетической ситуации, когда злоумышленник уже смог пробраться в инфраструктуру. Задача — с помощью сетевых механизмов помешать ему продвигаться дальше.
Важное предупреждение: часть описанных приёмов носит экспериментальный характер и требует тщательной обкатки именно в вашей инфраструктуре. Прежде чем внедрять — проверяйте в изолированном сетевом сегменте.

Цикл кибератаки

Чтобы говорить об одном и том же, стоит вспомнить, как вообще происходит кибератака. У неё есть определённый цикл, и один из самых распространённых методов проникновения — фишинг.
Цикл выглядит так.
  • 1.
    Сначала разведка: злоумышленник пытается определить электронные адреса потенциальных жертв.
  • 2.
    Дальше попытка доставки вредоносного кода — отправка фишингового сообщения с вредоносным вложением, которое эксплуатирует некую уязвимость, или с вредоносной ссылкой, по которой пользователь сам скачал и сам запустил.
  • 3.
    Если ни на одном из этих шагов оборона не сработала, вредоносное приложение пытается закрепиться в системе, чтобы пережить перезагрузку.
  • 4.
    И дальше оно начинает заражать другие, более интересные узлы — это боковое перемещение (lateral movement).
Основной вопрос
насколько сложно защититься именно от бокового перемещения.
Чтобы сдержать злоумышленника, есть два больших набора инструментов.
  • Первый — аутентификация.
  • Второй — связность.
Пользовательское устройство в рассматриваемом сценарии уже скомпрометировано, то есть пользователь равен злоумышленнику. Если у него есть сетевая связность с другим узлом, остановить его может только аутентификация. Но связность можно и отрезать — об этом и пойдёт речь.

Классификация трафика по чувствительности

Полезно разделить сетевой трафик по степени чувствительности.
  • Трафик пользователей
    это фактически те команды, которые отправляет пользовательское устройство и которые необходимы для работы пользователя. Например, почта: команда на получение письма, на отправку и так далее.
  • Административный трафик
    команды на изменение поведения устройства или сервиса: смена маршрутов, правка конфигурации. Возможность отправить такую команду с пользовательского устройства быть не должна. Такой трафик обязательно нужно сегментировать так, чтобы он шёл только из сегмента, где стоят компьютеры администраторов.
  • Сервисный трафик
    выделен отдельно, потому что, как правило, происходит в автоматизированном режиме — например, репликация контроллеров домена. По сути он схож с административным, но здесь нет человека, запускающего функцию: это просто код, который исполняется и засылается на другой инстанс.
Проблема в том, что архитектура многих приложений сделана так, что административные команды идут на тот же destination port, что и пользовательские. Просто «рубануть» порт нельзя — отвалится весь пользовательский сервис.

На каком уровне фильтровать

Если речь идёт о маршрутизаторе, то часть сервисов слушает на уровне L2 — например, MAC-Winbox или MAC-Telnet у MikroTik. Обычная рекомендация — отключить их; но если очень хочется оставить, то пусть слушают только на порту, подключённом к сети управления. В этом случае при взломе пользовательского устройства доступа к этим сервисам у злоумышленника не будет. Если дальше корректно настроен firewall на L3/L4, то и к сетевому оборудованию он не пробьётся.
Дальше начинается уровень L7 — когда управляющие функции слушают по тому же порту, что и пользовательские. Отключить их на L4 не получится, потому что вместе с ними отключатся и пользовательские функции. Приходится пользоваться L7-фильтрами и отсекать конкретные административные команды, пропуская их только с source-адресов из подсети управления.

Как выглядит идеальная программа

У программы всегда есть набор функций, которые она должна выполнять. В идеале пользовательское устройство подключается на L4 по одному порту (для примера — 8000), вызывает нужные функции и получает результат.
Административные функции, меняющие поведение программы, в идеальном мире вынесены в отдельный модуль и слушают уже на другом порту. Тогда трафик спокойно отсекается на L4: если пользовательское устройство скомпрометировано, доступа к административным функциям оно не получит — связности просто нет. То же самое касается сервисных функций.

Планирование сети управления

Первый шаг — инвентаризация:
выявить, что вообще есть в инфраструктуре и можно ли этим управлять. Например, у сервера может не быть IPMI-интерфейса или BMC-контроллера — управлять нечем. Значит, либо принимаем риск, либо заменяем на то, чем можно управлять. То же с неуправляемыми коммутаторами.
Второй шаг — выбор топологии: in-band или out-of-band.
При out-of-band оборудование, к которому подключены компьютеры администраторов и автоматизированные системы управления, физически отдельное: отдельный свитч, отдельный роутер, отдельный канал связи. Серверный VLAN через отдельно стоящий физический коммутатор подключается к BMC-портам серверов. Плюс: если в production-сети возникли проблемы со связностью, до оборудования всё равно можно достучаться и что-то исправить. Минус: дорого.
При in-band отдельного физического железа нет — есть только отдельный VLAN, а оборудование общее с продакшн-сетью.
Третий шаг — выявить все потенциально опасные точки
потенциально опасные точки входа и перенести их в сеть управления, чтобы они были доступны только с устройств администраторов.
Полезный ориентир — матрица MITRE ATT&CK: она собирает виды атак и показывает, какие меры защиты помогают их предотвратить. Там же можно найти набор проблем, решаемых с помощью сети управления (мера «Network Segmentation»).

Проблемы уровня L2

Топология, где компьютеры администраторов находятся в одном сегменте с пользователями, могла прокатить 25 лет назад, но сегодня это опасная история. При заражении пользовательского устройства у злоумышленника открываются огромные просторы для сетевых атак — DoS и man-in-the-middle. Основная проблема: если компьютер администратора находится в одном сегменте с пользователями, на него можно устроить man-in-the-middle-атаку и перехватывать весь трафик, включая управляющий.
Решение — сегментация: перенести компьютеры администраторов в отдельный VLAN или в отдельный физический сегмент. Связность тогда появляется только на уровне L3.

Проблемы уровня L3

Проблемы L2 для компьютеров администраторов и управляющего трафика ушли, но остались проблемы уровня L3. Злоумышленник может устроить DoS-атаку на сегмент, где находятся компьютеры администраторов.
Лечится это двумя способами.
  • Первый
    IP firewall: когда трафик уходит на шлюз, проверяется, не подменило ли пользовательское устройство IP-адрес (например, на адрес из сегмента назначения); если подменило — такой трафик дропается.
  • Второй
    включить RP-фильтр (reverse path filtering): маршрутизатор будет сверяться с таблицей маршрутов и проверять это автоматически. IP firewall прозрачнее; при использовании RP-фильтра нужно чётко осознавать, как он работает, чтобы не сделать хуже.

Контроллер домена: LDAP

Всё отсегментировано, но пользовательскому устройству по-прежнему нужна связность с контроллером домена — иначе оно не сможет работать. А пользовательское устройство равно злоумышленник.
LDAP позволяет не только читать данные, но и записывать их. Если злоумышленник смог похитить высокопривилегированную учётную запись или если LDAP-объекты настроены некорректно, он может попытаться добавить себе привилегий. Порты 389 и 636 закрыть нельзя — они нужны клиенту для нормальной работы. Остаются LDAP-фильтры, но готовых enterprise-решений здесь практически нет: находятся в основном сторонние инструменты, выкладываемые на GitHub компаниями, занимающимися безопасностью.

Контроллер домена: RPC

Для общения Windows-клиента с контроллером домена используется механизм RPC — удалённый вызов процедур. Соответствующие порты тоже нельзя закрыть, а они открывают огромный пласт возможностей: через них можно подключиться к службам управления на контроллере домена. Например, подключиться к Task Scheduler и создать вредоносное задание в планировщике или подключиться к диспетчеру служб и создать вредоносную службу. Наличие сетевой связности создаёт возможность прыгнуть к чувствительным сервисам. Это касается не только контроллеров домена — на серверах ситуация та же; контроллер домена взят как самый критичный пример.
Транспортом для RPC может быть не только TCP/IP, но и SMB (порт 445).

Контроллер домена: named pipes

Те же функции — и Task Scheduler, и управление службами — доступны через другой механизм подключения, named pipes. Он работает поверх SMB, порт TCP/445. Заблокировать этот порт нельзя: клиенту он нужен, чтобы скачивать и применять групповые политики, а Netlogon нужен для логина под доменной учётной записью.
Злоумышленник может развернуть скрипты и использовать named pipes для подключения к критичным службам. Значит, снова придётся воспользоваться фильтрацией на уровне L7.
К счастью, у API каждой службы есть свой UUID — уникальный идентификатор. Можно воспользоваться встроенным Windows CLI-инструментом netsh rpc filter и заблокировать трафик по этому UUID. Пример правила: условие protocol со значением ncacn_np означает, что в качестве транспорта используется named pipes; дальше в условие добавляется UUID службы, к которой пропускать злоумышленника не нужно, — и такой трафик блокируется. Списки чувствительных UUID можно найти в открытых источниках.

Контроллер домена: DRS API

И всё равно не классно. Среди API, перенесённых на порты 9000/9001, есть NTDS DRS API. Контроллеры домена используют его для репликации, и в нём есть функция IDL_DRSGetNCChanges. При наличии необходимых привилегий можно вызвать эту функцию и осуществить репликацию контроллера домена, фактически похитив всё его содержимое. Не нужно даже пробираться на сам контроллер и вытаскивать файл базы — достаточно запустить команду репликации, если прав хватает.
Осложняется всё тем, что пользовательское устройство тоже использует DRS API для работы в домене — в частности, вызов IDL_DRSCrackNames. Казалось бы, можно пойти тем же путём, что и с named pipes: у каждой функции есть свой идентификатор opnum, и у опасной IDL_DRSGetNCChanges это opnum 3.

Но здесь ждёт проблема

В правиле можно было бы указать поле remote_addr_v4 — то есть сказать, что если запрос на вызов функции репликации пришёл из пользовательского сегмента, он блокируется. Однако это условие в netsh rpc filter не работает: ни в десятичном виде, ни в двоичном. Разбирательство показало, что дело не в непонимании — поле в этой CLI-утилите действительно не работает. У файрвола есть отдельный API — Windows Filtering Platform. Так что если нужно добиться, чтобы команды репликации ходили только из подсети, где стоят контроллеры домена, придётся либо брать за основу что-то open-source, либо писать правила файрвола через API.

Что отсекается легко

После самой сложной части — более простые, но не менее интересные вещи. Ряд распространённых сервисов легко отсекается на уровне L3/L4.
  • IP-телефония
    Клиентскому устройству нужны SIP и диапазон RTP. Их разрешаем, остальные порты блокируем — до функций управления пользовательское устройство не доберётся.
  • WSUS
    Здесь всё аналогично и прозрачно
  • Exchange
    Для корректной работы клиента фактически нужен TCP/443 при использовании MAPI over HTTP. Но есть нюансы — о них ниже.
  • Сервер печати
    Можно сделать отдельный VLAN с устройствами печати и разрешать от клиентов только необходимый трафик: RAW 9100, LPR 515, IPP 631. Всё остальное блокируется.
  • MikroTik
    Об интеграции в сеть управления написано достаточно много; в основном всё срезается на уровне L4 — надо просто найти нужные компоненты и перенести их в сеть управления.

Фильтрация L7 в веб-приложениях

Возьмём типичное веб-приложение — например, интернет-магазин. У него есть API, и пользовательскому устройству нужно работать только со своим API: класть в корзину, оформлять заказ. У администратора функции совсем другие: добавить товар в систему и так далее. Предположим, архитектурно приложение сделано так, что функции управления слушают на том же порту 443.
Если эндпоинты разные — например, административные функции доступны через /api/admin — можно определить, что запрос пришёл на этот эндпоинт, и разрешать его только из сети управления, блокируя пользовательский трафик. Если веб-сервер этого не поддерживает, всегда можно развернуть веб-прокси (например, nginx), который терминирует на себе TLS-соединение, фильтрует и проксирует дальше.
Ложка мёда в бочке дёгтя
Hyper-V. Microsoft в этом плане сделал очень прилично: там всё можно красиво разнести, чтобы сама платформа виртуализации не была доступна пользователю.
Финал
Главный вывод: защитить контроллер домена на сетевом уровне крайне сложно. Архитектура протоколов Windows такова, что пользовательскому устройству нужна связность ровно по тем же портам, через которые доступны самые чувствительные функции, — и на L4 эта задача не решается в принципе. Приходится спускаться на L7, работать с UUID служб и opnum функций, а иногда и упираться в неработающие условия штатных утилит.
Отсюда второй вывод, адресованный уже разработчикам: при проектировании приложений стоит всегда помнить, что функции управления лучше выделять в отдельные микросервисы, слушающие на отдельном порту. Тогда сеть управления строится тривиально — простым правилом на L4, — и жизнь администратора становится значительно легче.
Остальное — инвентаризация, честный выбор между in-band и out-of-band, вынос компьютеров администраторов в отдельный сегмент и последовательное перекрытие всего лишнего. Это не даёт гарантий, но радикально сужает пространство для бокового перемещения.
В Москве:
РФ (звонок бесплатный):
Наша почта:
GetNet
Остались вопросы?
Группа компаний VoxLink © 2011-2026